Overview of excelsior JET, a high performance alternative to java virtual machines
WOSP '02 Proceedings of the 3rd international workshop on Software and performance
Experiences with Retargeting the Java Hotspot(tm) Virtual Machine
IPDPS '02 Proceedings of the 16th International Parallel and Distributed Processing Symposium
Grid-Based Asynchronous Migration of Execution Context in Java Virtual Machines
Euro-Par '00 Proceedings from the 6th International Euro-Par Conference on Parallel Processing
Constant-Time Root Scanning for Deterministic Garbage Collection
CC '01 Proceedings of the 10th International Conference on Compiler Construction
Concurrent Remembered Set Refinement in Generational Garbage Collection
Proceedings of the 2nd Java Virtual Machine Research and Technology Symposium
Proceedings of the 1st ACM/USENIX international conference on Virtual execution environments
JVM'01 Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology Symposium - Volume 1
Mostly accurate stack scanning
JVM'01 Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology Symposium - Volume 1
Hot-swapping between a mark&sweep and a mark&compact garbage collector in a generational environment
JVM'01 Proceedings of the 2001 Symposium on JavaTM Virtual Machine Research and Technology Symposium - Volume 1
| Hi-index | 0.00 |
Many garbage-collected systems, including most that involve astop-the-world phase, restrict GC to so called GC points. Insingle-threaded environments, GC points carry no overhead: when aGC must be done, the single thread is already at a GC point. Inmulti-threaded environments, however, only the thread that triggersthe GC by failing an allocation will be at a GC point. Otherthreads must be rolled forward to their next GC point before the GCcan take place. We compare, in the context of a high-performanceJavaTM virtual machine, two approaches to advancingthreads to a GC point, polling and code patching, while keeping allother factors constant. Code patching outperforms polling by anaverage of 4.7% and sometimes by as much as 11.2%, while costingonly slightly more compiled code space. Put differently, since mostprograms spend less than 1/5 of the time in GC, a 4.7% bottom-linespeedup amounts to more than a 20% reduction in the GC-relatedcosts. Patching is, however, more difficult to implement.