Academia.eduAcademia.edu

Figure 9 – uploaded by Laurent Daynes

See full PDFdownloadDownload figure
Figure 8. Footprint of metaspaces, grouped by class loader type. NAT RENEE ROMIRT TE RAGAN T OMe REIN RR! RAITT CE STEEN BE iio eS Sane Wena a NS MEN LO AT ~The DaC apo benchmark Harness class loader (or Harness loader for short) is an artefact of the DaCapo benchmark suite: it is used to instantiate and run the benchmarks. In a regular application, most of the classes it defines would be defined by the system loader. Reflective class loaders are created for fast reflective invocation to define a single invocation stub class.

Figure 8 Footprint of metaspaces, grouped by class loader type. NAT RENEE ROMIRT TE RAGAN T OMe REIN RR! RAITT CE STEEN BE iio eS Sane Wena a NS MEN LO AT ~The DaC apo benchmark Harness class loader (or Harness loader for short) is an artefact of the DaCapo benchmark suite: it is used to instantiate and run the benchmarks. In a regular application, most of the classes it defines would be defined by the system loader. Reflective class loaders are created for fast reflective invocation to define a single invocation stub class.

Related Figures (11)

Figure 1. Linkset graph and metaspaces.
Figure 1. Linkset graph and metaspaces.
Figure 2. Two heaps with their generations consisting of regions allocated from a region pool.
Figure 2. Two heaps with their generations consisting of regions allocated from a region pool.
Figure 3. Metaspace implementation.
Figure 3. Metaspace implementation.
Figure 4. Class descriptors and mirrors.
Figure 4. Class descriptors and mirrors.
Figure 5. Costs of full collection phases for COMP.
Figure 5. Costs of full collection phases for COMP.
Table 2. Heap sizes used. We choose a multiple of 32 MB that is larger than the maximum live heap size measured at the end of full collections in multiple runs of the benchmark.
Table 2. Heap sizes used. We choose a multiple of 32 MB that is larger than the maximum live heap size measured at the end of full collections in multiple runs of the benchmark.
Figure 6. References visited during full collections. The line be- tween the bars separates the references emanating from the applica- tion heap (bottom) from those emanating from the permanent gen- eration (top).
Figure 6. References visited during full collections. The line be- tween the bars separates the references emanating from the applica- tion heap (bottom) from those emanating from the permanent gen- eration (top).
Figure 7. Full collection performance of META and COMP.
Figure 7. Full collection performance of META and COMP.
Table 5. Percentage of unoccupied space in metaspace. Table 5 shows how much of this assigned memory is unoccu- pied. Unoccupied space includes the space at the end of the cur rent fixed-size chunk, which available for allocation, and the space left in the other chunks, which cannot be used for allocation and is therefore wasted.
Table 5. Percentage of unoccupied space in metaspace. Table 5 shows how much of this assigned memory is unoccu- pied. Unoccupied space includes the space at the end of the cur rent fixed-size chunk, which available for allocation, and the space left in the other chunks, which cannot be used for allocation and is therefore wasted.
Figure 9. Full collection performance of COMP-, META- and META+. Table 4. Memory usage for META compared to COMP
Figure 9. Full collection performance of COMP-, META- and META+. Table 4. Memory usage for META compared to COMP
Related topics:
Memory ManagementGarbage Collection
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved