You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(1) |
2
|
|
3
|
4
|
5
(2) |
6
(3) |
7
|
8
(2) |
9
(3) |
|
10
(3) |
11
(5) |
12
(1) |
13
|
14
(21) |
15
(6) |
16
(4) |
|
17
(9) |
18
(13) |
19
(15) |
20
(15) |
21
(11) |
22
(16) |
23
(4) |
|
24
|
25
(8) |
26
(4) |
27
(3) |
28
(1) |
29
|
30
(2) |
|
From: Julian S. <js...@ac...> - 2002-11-17 18:10:17
|
On Sunday 17 November 2002 5:34 pm, Jeremy Fitzhardinge wrote: > On Sun, 2002-11-17 at 04:40, Julian Seward wrote: > > > So you mean have a structure per basic block, which contains as one of > > > its elements the entrypoint for its generated code, or if there is no > > > generated code, the entrypoint of "patch_me"? This is OK, but it would > > > be nice not to have an indirect jump in the generated code, since this > > > makes branch prediction much harder. A nice absolute unconditional > > > jump makes things easiest on the CPU. > > > > Um, yes, that (the ld.so scheme) requires a seperate entry point per > > jump-target, which is a complication we don't want. > > Eh? I don't understand. Doesn't every BB have a distinct entry point > anyway? My understanding of the ld.so scheme (which may be wrong!) is: Initially a call to (eg) printf is sent to a stub function (which perhaps lives in the PLT, the procedure linkage table?). This invokes the dynamic linker, to find the address of the real printf. The linker overwrites this stub with a jump to the real address, and jumps onwards there. Second and subsequent calls to printf still jump to the stub, but that simply makes a second jump to the real code. So once the initial lookup is done, there is a 1-insn overhead for all subsequent calls, which is not bad. This scheme has the advantage that neither the caller nor callee has to be patched, since that would negate the advantages of text segments shared between multiple processes. Only each processes' PLT(s?) need be modified, but these are relatively small. Does this clarify? Does you know if this is even correct? J |
|
From: Jeremy F. <je...@go...> - 2002-11-17 17:34:57
|
On Sun, 2002-11-17 at 04:40, Julian Seward wrote:
> > So you mean have a structure per basic block, which contains as one of
> > its elements the entrypoint for its generated code, or if there is no
> > generated code, the entrypoint of "patch_me"? This is OK, but it would
> > be nice not to have an indirect jump in the generated code, since this
> > makes branch prediction much harder. A nice absolute unconditional jump
> > makes things easiest on the CPU.
>
> Um, yes, that (the ld.so scheme) requires a seperate entry point per
> jump-target, which is a complication we don't want.
Eh? I don't understand. Doesn't every BB have a distinct entry point
anyway?
J
|
|
From: Josef W. <Jos...@gm...> - 2002-11-17 14:25:50
|
On Sunday 17 November 2002 08:16, Jeremy Fitzhardinge wrote: > On Sat, 2002-11-16 at 15:25, Josef Weidendorfer wrote: > > On Saturday 16 November 2002 19:17, Jeremy Fitzhardinge wrote: > > > On Sat, 2002-11-16 at 04:09, Julian Seward wrote: > > > ... > > > > > > > When an unchained translation wants to make a jump to a known > > > > (orig)address, it pushes the orig-address it wants to call, and > > > > *calls* "patch_me" which is a short piece of assembly code. This > > > > pops the args (orig-addr) and also pops the return address -- whi= ch > > > > points just after the call insn on the original translation.=20 > > > > patch_me can arrange to find the translation and patch the caller= to > > > > jump directly to it. > > > > Just an idea: Why not simply use indirect jumps and patching the jump > > address, same as the symbol resolving with calls to shared lib functi= ons > > is doing? The jump address would be initialised to "patch_me" and lat= er > > to the translated code (by patch_me). > > You wouldn't need chained/unchained versions or patching generated co= de, > > and whenever discarding a translation, set the according jump address > > back to "patch_me". > > Seems way easier for me in a first step. > > So you mean have a structure per basic block, which contains as one of > its elements the entrypoint for its generated code, or if there is no Yes. I meant just a table of entry points with indirect jumps at the end of the translated BBs using this table. > generated code, the entrypoint of "patch_me"? This is OK, but it would > be nice not to have an indirect jump in the generated code, since this > makes branch prediction much harder. A nice absolute unconditional jum= p Is branch prediction with indirect jumps always a problem for the CPU=20 hardware? Perhaps register relative, loading the register a few cycles be= fore=20 the jump? Then the pipeline shouldn't stall.=20 But that needs a register. OK, go with patching the generated code. Another idea: If two BBs are to be executed unconditionally after each ot= her, couldn't you try to put them in the translation cache direct behind each = other=20 with no jump at all? Perhaps padding with some NOPs if a jump will be nee= ded=20 later on... Josef > makes things easiest on the CPU. > > > J |
|
From: Julian S. <js...@ac...> - 2002-11-17 12:33:12
|
> So you mean have a structure per basic block, which contains as one of > its elements the entrypoint for its generated code, or if there is no > generated code, the entrypoint of "patch_me"? This is OK, but it would > be nice not to have an indirect jump in the generated code, since this > makes branch prediction much harder. A nice absolute unconditional jump > makes things easiest on the CPU. Um, yes, that (the ld.so scheme) requires a seperate entry point per jump-target, which is a complication we don't want. I think I declare a red herring on this one. J |
|
From: Julian S. <js...@ac...> - 2002-11-17 12:30:58
|
> On Sat, 16 Nov 2002, Julian Seward wrote: > > - how to cleanly deal with jumps to unknown addresses, which always > > require a lookup > > Dynamo has some kind of table for these. That seems unavoidable. We'd probably just recycle the current arrangement, or perhaps a simplified version of it, in this case. Bear in mind that x86 RET instructions are going to pull an original address off the stack and jump to it, so there will still me a significant minority of such lookups needed. > > Finally -- and this is the last part of the trick -- whenever we want to > > move or discard any translations, we first unchain *all* of them. > > I think Dynamo actually flushes the entire code cache in this situation. > But it doesn't have LRU eviction, and their code cache seems to be a lot > smaller. So maybe that's not relevant. Yes, there's a tradeoff between complexity of the cache management and expense of translation. Since we've got a hugely expensive translator by JIT standards (10s of 000s of cycles / byte of generated code) we have to a have a more complex arrangement designed to minimise the miss rate. > Also, w.r.t. indirect jumps, I think Dynamo encodes a lot of them as > direct jumps and then checks before making the jump that the direct jump > is to the right place. This somehow turns out as a win... Yes, known trick. I think VMware probably does this too (it's a light weight JIT, in effect). (How VMware works is really described in an earlier paper from Stanford; I can dig it out if anyone wants). Nevertheless I think this is an optimisation/complication which is probably beyond what we'd want. Mark, I hope we're not flooding you with junk mail. You haven't said a word so far :) and so perhaps you have been abducted by aliens? J |
|
From: Nicholas N. <nj...@ca...> - 2002-11-17 11:12:11
|
Hi, I can't add a lot to this discussion, but I have been reading about Dynamo... On Sat, 16 Nov 2002, Julian Seward wrote: > - how to cleanly deal with jumps to unknown addresses, which always require > a lookup Dynamo has some kind of table for these. > Finally -- and this is the last part of the trick -- whenever we want to > move or discard any translations, we first unchain *all* of them. I think Dynamo actually flushes the entire code cache in this situation. But it doesn't have LRU eviction, and their code cache seems to be a lot smaller. So maybe that's not relevant. Also, w.r.t. indirect jumps, I think Dynamo encodes a lot of them as direct jumps and then checks before making the jump that the direct jump is to the right place. This somehow turns out as a win... N |
|
From: Jeremy F. <je...@go...> - 2002-11-17 07:16:24
|
On Sat, 2002-11-16 at 15:25, Josef Weidendorfer wrote:
> On Saturday 16 November 2002 19:17, Jeremy Fitzhardinge wrote:
> > On Sat, 2002-11-16 at 04:09, Julian Seward wrote:
> > ...
> > > When an unchained translation wants to make a jump to a known
> > > (orig)address, it pushes the orig-address it wants to call, and *calls*
> > > "patch_me" which is a short piece of assembly code. This pops the args
> > > (orig-addr) and also pops the return address -- which points just after
> > > the call insn on the original translation. patch_me can arrange to find
> > > the translation and patch the caller to jump directly to it.
>
> Just an idea: Why not simply use indirect jumps and patching the jump address,
> same as the symbol resolving with calls to shared lib functions is doing?
> The jump address would be initialised to "patch_me" and later to the
> translated code (by patch_me).
> You wouldn't need chained/unchained versions or patching generated code, and
> whenever discarding a translation, set the according jump address back to
> "patch_me".
> Seems way easier for me in a first step.
So you mean have a structure per basic block, which contains as one of
its elements the entrypoint for its generated code, or if there is no
generated code, the entrypoint of "patch_me"? This is OK, but it would
be nice not to have an indirect jump in the generated code, since this
makes branch prediction much harder. A nice absolute unconditional jump
makes things easiest on the CPU.
J
|
|
From: Julian S. <js...@ac...> - 2002-11-17 03:20:24
|
> > > When an unchained translation wants to make a jump to a known > > > (orig)address, it pushes the orig-address it wants to call, and *calls* > > > "patch_me" which is a short piece of assembly code. This pops the args > > > (orig-addr) and also pops the return address -- which points just after > > > the call insn on the original translation. patch_me can arrange to > > > find the translation and patch the caller to jump directly to it. > > Just an idea: Why not simply use indirect jumps and patching the jump > address, same as the symbol resolving with calls to shared lib functions is > doing? The jump address would be initialised to "patch_me" and later to the > translated code (by patch_me). > You wouldn't need chained/unchained versions or patching generated code, > and whenever discarding a translation, set the according jump address back > to "patch_me". > Seems way easier for me in a first step. Josef I don't really know how the shared lib stuff works. Can you explain in a little more detail how your proposal would work? Thanks, J |
|
From: Josef W. <Jos...@gm...> - 2002-11-17 00:26:05
|
On Saturday 16 November 2002 19:17, Jeremy Fitzhardinge wrote: > On Sat, 2002-11-16 at 04:09, Julian Seward wrote: > ... > > When an unchained translation wants to make a jump to a known > > (orig)address, it pushes the orig-address it wants to call, and *call= s* > > "patch_me" which is a short piece of assembly code. This pops the ar= gs > > (orig-addr) and also pops the return address -- which points just aft= er > > the call insn on the original translation. patch_me can arrange to f= ind > > the translation and patch the caller to jump directly to it. Just an idea: Why not simply use indirect jumps and patching the jump add= ress,=20 same as the symbol resolving with calls to shared lib functions is doing? The jump address would be initialised to "patch_me" and later to the=20 translated code (by patch_me). You wouldn't need chained/unchained versions or patching generated code, = and=20 whenever discarding a translation, set the according jump address back to= =20 "patch_me". Seems way easier for me in a first step. Sorry if I'm totally wrong here :-) Josef |