From: Pushparaj M. <pus...@gm...> - 2013-05-07 17:39:08
|
Hi, I need help regarding Good resources to start understanding the Code Cache Management in JikesRVM? Thanks Pushparaj |
From: Eliot M. <mo...@cs...> - 2013-05-08 19:40:20
|
On 5/7/2013 1:39 PM, Pushparaj Motamari wrote: > I need help regarding Good resources to start understanding the Code Cache Management in JikesRVM? Dear Pushparaj -- AFAIK it is not something I would actually call a cache. Code gets generated for some methods as part of the system build process (namely for those methods needed by the system itself). When the system is about to run a method that has not yet been compiled, then the method will be compiled. The default policy will use the "baseline" (non-optimizing) compiler. There are various controls that can override the policy. If a method is seen to be executed frequently enough, it will be re-compiled with the optimizing compiler -- sometimes multiple times (at increasing levels of optimization). Future calls go to the latest version, and it is even possible to redirect calls *currently in progress* to new code using a technique called On Stack Replacement (OSR). If you want to grasp that, I recommend reading the conference paper about it. Anyway, as newer version are compiled, older ones fall into disuse, but AFAIK the space is not reclaimed. Compiled code resides in a space separate from the main garbage collected heap, and is never moved by the GC, which means that references to code, or positions within code (e.g., return addresses) do not have to be updated. (If I am wrong about the space being reclaimed, then clearly it is managed by a mark-sweep / free-list kind of technique.) So, is the space management you wanted to know about, really, or the recompilation policies? Regards -- Eliot Moss |
From: Michael B. <mik...@cs...> - 2013-05-08 20:53:41
|
On 05/08/2013 03:39 PM, Eliot Moss wrote: > On 5/7/2013 1:39 PM, Pushparaj Motamari wrote: > >> I need help regarding Good resources to start understanding the Code Cache Management in JikesRVM? > Dear Pushparaj -- AFAIK it is not something I would actually > call a cache. Code gets generated for some methods as part of > the system build process (namely for those methods needed by > the system itself). When the system is about to run a method > that has not yet been compiled, then the method will be compiled. > The default policy will use the "baseline" (non-optimizing) > compiler. There are various controls that can override the > policy. > > If a method is seen to be executed frequently enough, it will > be re-compiled with the optimizing compiler -- sometimes multiple > times (at increasing levels of optimization). Future calls > go to the latest version, and it is even possible to redirect > calls *currently in progress* to new code using a technique > called On Stack Replacement (OSR). If you want to grasp that, > I recommend reading the conference paper about it. > > Anyway, as newer version are compiled, older ones fall into > disuse, but AFAIK the space is not reclaimed. Compiled code > resides in a space separate from the main garbage collected > heap, and is never moved by the GC, which means that references > to code, or positions within code (e.g., return addresses) > do not have to be updated. (If I am wrong about the space > being reclaimed, then clearly it is managed by a mark-sweep / > free-list kind of technique.) Old versions of compiled methods can be reclaimed if they're no longer executing (i.e., not on the stack). A starting place for seeing how that's done is CompiledMethods.snipObsoleteCompiledMethods() By default, USE_CODE_SPACE is true, and (machine) code is allocated into special code spaces that are non-moving spaces. However, if USE_CODE_SPACE is false, then it looks like code is allocated into the default space, which could be a moving space. Assuming that's right, then I'm not entirely sure how pointers to code are updated. At least some calls are indirect: they go through TIBs (virtual dispatch) or the JTOC (static methods), so just updating these tables is sufficient. Are all calls indirect, or are there direct calls in the code that need to be updated by updating pointers in the code itself? I suspect that all calls are performed indirectly rather than having absolute hard-coded callee addresses in the code. Cheers, Mike > > So, is the space management you wanted to know about, really, > or the recompilation policies? > > Regards -- Eliot Moss > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
From: David P G. <gr...@us...> - 2013-05-08 22:12:21
|
Michael Bond <mik...@cs...> wrote on 05/08/2013 04:53:32 PM: > > By default, USE_CODE_SPACE is true, and (machine) code is allocated into > special code spaces that are non-moving spaces. However, if > USE_CODE_SPACE is false, then it looks like code is allocated into the > default space, which could be a moving space. Assuming that's right, > then I'm not entirely sure how pointers to code are updated. At least > some calls are indirect: they go through TIBs (virtual dispatch) or the > JTOC (static methods), so just updating these tables is sufficient. Are > all calls indirect, or are there direct calls in the code that need to > be updated by updating pointers in the code itself? I suspect that all > calls are performed indirectly rather than having absolute hard-coded > callee addresses in the code. > Independent of USE_CODE_SPACE, all calls in Jikes RVM are indirect. (even static calls indirect through the JTOC). On the plus side, this makes adaptive recompilation very simple (install a new version of the code simply by updating a TIB/JTOC pointer). On the minus side, we are likely losing at least some performance by indirecting on every call. I'd started working on implementing support for direct (pc-relative) calls back at OOPSLA'07 in Montreal, but never completed it. I still have a patch set kicking around if anyone wants to take another run at it. I figured it was going to take me a month +/- of solid work to make all the needed changes (pc relative calls on both platforms, still supporting GC of code, adaptive recompilation, etc). --dave |
From: Pushparaj M. <pus...@gm...> - 2013-05-12 00:53:21
|
Hi, Thank you for your replies, I am looking for space management. Thank you Pushparaj On Thu, May 9, 2013 at 3:40 AM, David P Grove <gr...@us...> wrote: > Michael Bond <mik...@cs...> wrote on 05/08/2013 04:53:32 > PM: > > > > > > By default, USE_CODE_SPACE is true, and (machine) code is allocated into > > special code spaces that are non-moving spaces. However, if > > USE_CODE_SPACE is false, then it looks like code is allocated into the > > default space, which could be a moving space. Assuming that's right, > > then I'm not entirely sure how pointers to code are updated. At least > > some calls are indirect: they go through TIBs (virtual dispatch) or the > > JTOC (static methods), so just updating these tables is sufficient. Are > > all calls indirect, or are there direct calls in the code that need to > > be updated by updating pointers in the code itself? I suspect that all > > calls are performed indirectly rather than having absolute hard-coded > > callee addresses in the code. > > > > Independent of USE_CODE_SPACE, all calls in Jikes RVM are indirect. (even > static calls indirect through the JTOC). On the plus side, this makes > adaptive recompilation very simple (install a new version of the code > simply by updating a TIB/JTOC pointer). On the minus side, we are likely > losing at least some performance by indirecting on every call. > > I'd started working on implementing support for direct (pc-relative) calls > back at OOPSLA'07 in Montreal, but never completed it. I still have a > patch set kicking around if anyone wants to take another run at it. I > figured it was going to take me a month +/- of solid work to make all the > needed changes (pc relative calls on both platforms, still supporting GC of > code, adaptive recompilation, etc). > > --dave > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |
From: Pushparaj M. <pus...@gm...> - 2013-05-12 02:10:46
|
Continuing to the previous mail, if USE_CODE_SPACE is true and the space allocated for the code is full, then how the jikes rvm replaces the existing code.? Thanks Pushparaj On Sun, May 12, 2013 at 6:23 AM, Pushparaj Motamari <pus...@gm...>wrote: > Hi, > > Thank you for your replies, I am looking for space management. > > Thank you > > Pushparaj > > On Thu, May 9, 2013 at 3:40 AM, David P Grove <gr...@us...> wrote: > >> Michael Bond <mik...@cs...> wrote on 05/08/2013 04:53:32 >> PM: >> >> >> > >> > By default, USE_CODE_SPACE is true, and (machine) code is allocated >> into >> > special code spaces that are non-moving spaces. However, if >> > USE_CODE_SPACE is false, then it looks like code is allocated into the >> > default space, which could be a moving space. Assuming that's right, >> > then I'm not entirely sure how pointers to code are updated. At least >> > some calls are indirect: they go through TIBs (virtual dispatch) or the >> > JTOC (static methods), so just updating these tables is sufficient. Are >> > all calls indirect, or are there direct calls in the code that need to >> > be updated by updating pointers in the code itself? I suspect that all >> > calls are performed indirectly rather than having absolute hard-coded >> > callee addresses in the code. >> > >> >> Independent of USE_CODE_SPACE, all calls in Jikes RVM are indirect. (even >> static calls indirect through the JTOC). On the plus side, this makes >> adaptive recompilation very simple (install a new version of the code >> simply by updating a TIB/JTOC pointer). On the minus side, we are likely >> losing at least some performance by indirecting on every call. >> >> I'd started working on implementing support for direct (pc-relative) >> calls back at OOPSLA'07 in Montreal, but never completed it. I still have >> a patch set kicking around if anyone wants to take another run at it. I >> figured it was going to take me a month +/- of solid work to make all the >> needed changes (pc relative calls on both platforms, still supporting GC of >> code, adaptive recompilation, etc). >> >> --dave >> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > |
From: Eliot M. <mo...@cs...> - 2013-05-12 02:15:48
|
On 5/11/2013 10:10 PM, Pushparaj Motamari wrote: > Continuing to the previous mail, > > if USE_CODE_SPACE is true and the space allocated for the code is full, then how the jikes rvm > replaces the existing code.? I admit that I am not intimately familiar with the details here, but I *think* it doesn't. If it runs out, it runs out. As noted before, the space is managed via mark-sweep collection and free-list allocation, so unreachable code bodies are reclaimed and the space may be reused, but I believe that if the space permitted by configuration and/or command line options is exhausted, that's it. It will not go around discarding reachable methods. As I said before, I do not believe it works as a cache. If I am wrong, I will be glad to be corrected! Regards -- Eliot Moss |