 |  |  | Memory Wall Issues |
We now use the Performance Explorer to explore how the scheduling of Java threads and garbage collection interact with the memory hierarchy. Our experiments use a semispace garbage collector that divides the heap into two semispaces, from and to. The program allocates all objects in the from semispace. When garbage collector is triggered the collector copies all the live objects from the from space to the to space and switches the role of the from and to spaces. At the end of GC, all the live data is contiguous at the start of the newly-labeled from semispace.
Since Jikes RVM allocates code in the heap [3], the garbage collector moves around and compacts not just the data, but also the code that is not in the boot image (i.e., the compiler, standard libraries, etc.). The code is moved through the data cache. Thus after GC, references to instructions will miss in the instruction cache. The garbage collector does not move instructions in the boot image and thus after GC, references to these instructions may or may not miss (depending on how much of the cache is flushed by the garbage collector).
For the experiments reported in this section, we executed pseudojbb with the semispace garbage collector using the default adaptive heap size policy. The average amount of live data at the end of GC was around 25-30 MB. Before GC, the total heap space (excluding the to space) was about 100 MB.
| | | Memory Wall Issues |