Academia.eduAcademia.edu

Figure 21 – uploaded by Robin Garner

See full PDFdownloadDownload figure
Figure 5.8: The effect of varying header encodings. Geometric mean of 18 benchmarks. We now explore the header metadata design space described in Section 5.4.4.

Figure 5 8: The effect of varying header encodings. Geometric mean of 18 benchmarks. We now explore the header metadata design space described in Section 5.4.4.

Related Figures (34)

Figure 1.1: Architectural dependence on GC performance. Total running time on three architectures, geometric mean of the Spec JVM 98 benchmarks. Reproduced from Blackburn et al. [2004a].
Figure 1.1: Architectural dependence on GC performance. Total running time on three architectures, geometric mean of the Spec JVM 98 benchmarks. Reproduced from Blackburn et al. [2004a].
Table 3.1: Tracing loop time as a percentage of total GC time.
Table 3.1: Tracing loop time as a percentage of total GC time.
Table 3.2: Hardware Platforms used for the Replay Tracing Loop Cost Experiments 3.3.1.2 Tracing Costs We now use the replay tracing framework described in Section 3.2 to evaluate the dominant costs of the mark-sweep tracing loop shown in Figure 3.1. We perform our measurements using Jikes RVM and MMTk with DaCapo and SPEC benchmarks, as described in Chapter 2, and the AMD and Pentium-M architectures shown in Ta- ble 3.2.
Table 3.2: Hardware Platforms used for the Replay Tracing Loop Cost Experiments 3.3.1.2 Tracing Costs We now use the replay tracing framework described in Section 3.2 to evaluate the dominant costs of the mark-sweep tracing loop shown in Figure 3.1. We perform our measurements using Jikes RVM and MMTk with DaCapo and SPEC benchmarks, as described in Chapter 2, and the AMD and Pentium-M architectures shown in Ta- ble 3.2.
This section shows results of our experiments exploring traversal order. We measure total elapsed time for the heap traversal across all GCs in the third iteration of each benchmark, and repeat each measurement six times in order to obtain a sufficiently small confidence interval. We take the arithmetic mean of these six iterations and di- vide by the mean elapsed time for the ‘sorted’ traversal order to produce a normalised elapsed time ratio for each benchmark and traversal order. We summarise this to a single figure for the traversal order on a machine architecture by taking the geometric mean of the per-benchmark normalised figures. Table 3.7: Hardware platforms used for heap traversal order experiments.
This section shows results of our experiments exploring traversal order. We measure total elapsed time for the heap traversal across all GCs in the third iteration of each benchmark, and repeat each measurement six times in order to obtain a sufficiently small confidence interval. We take the arithmetic mean of these six iterations and di- vide by the mean elapsed time for the ‘sorted’ traversal order to produce a normalised elapsed time ratio for each benchmark and traversal order. We summarise this to a single figure for the traversal order on a machine architecture by taking the geometric mean of the per-benchmark normalised figures. Table 3.7: Hardware platforms used for heap traversal order experiments.
Figure 3.5: Effects of traversal order: major design choices
Figure 3.5: Effects of traversal order: major design choices
to an otherwise depth-first traversal, for varying buffer sizes. The data series ‘buffer
to an otherwise depth-first traversal, for varying buffer sizes. The data series ‘buffer
Figure 3.11: Edge enqueuing. Effects of partial breadth-first order
Figure 3.11: Edge enqueuing. Effects of partial breadth-first order
Table 4.1: Hardware Platforms for prefetch experiments We evaluate performance on 4 architectures, details of which are provided in Ta- ple 4.1.
Table 4.1: Hardware Platforms for prefetch experiments We evaluate performance on 4 architectures, details of which are provided in Ta- ple 4.1.
sured on our four modern architectures. Each graph shows the geometric mean of performance for the full set of 17 benchmarks drawn from DaCapo and SPEC. Results are normalized to the time for NodeSide with no prefetch. NodeSide is the configuration which most closely follows prior work [Boehm, 2000; Cher et al., 2004]. We gathered results for different heap sizes, but found that the effect of prefetch was independent of heap size. We report here the results for a fairly generous heap; three times the min imum heap size for each benchmark. We performed identical experiments on 2 and 4x heaps, and found the GC-time results were almost indistinguishable, although the overall impact of this GC-time optimization on total time obviously increases since time spent in GC goes up in smaller heaps. For completeness, Figure 4.5 shows tota time as a function of heap size. In order to maintain a consistent number of collections across the different configurations and fairly assess the effect of prefetch, we did not allow the header meta-data configurations to make use of the minor space saving due to avoiding the side bitmap.
sured on our four modern architectures. Each graph shows the geometric mean of performance for the full set of 17 benchmarks drawn from DaCapo and SPEC. Results are normalized to the time for NodeSide with no prefetch. NodeSide is the configuration which most closely follows prior work [Boehm, 2000; Cher et al., 2004]. We gathered results for different heap sizes, but found that the effect of prefetch was independent of heap size. We report here the results for a fairly generous heap; three times the min imum heap size for each benchmark. We performed identical experiments on 2 and 4x heaps, and found the GC-time results were almost indistinguishable, although the overall impact of this GC-time optimization on total time obviously increases since time spent in GC goes up in smaller heaps. For completeness, Figure 4.5 shows tota time as a function of heap size. In order to maintain a consistent number of collections across the different configurations and fairly assess the effect of prefetch, we did not allow the header meta-data configurations to make use of the minor space saving due to avoiding the side bitmap.
significant, with GC-time performance improvements ranging from 30% on the Pow- erPC 970, to around 20% on the Athlon 64. Notable degradations occur for a number of configurations on the Pentium-M. We also see that prefetch distances greater than eight provide little advantage, with longer prefetch distances degrading performance slightly on the Athlon 64.
significant, with GC-time performance improvements ranging from 30% on the Pow- erPC 970, to around 20% on the Athlon 64. Notable degradations occur for a number of configurations on the Pentium-M. We also see that prefetch distances greater than eight provide little advantage, with longer prefetch distances degrading performance slightly on the Athlon 64.
(a) Reference fields per object. Mean of all benchmarks.
(a) Reference fields per object. Mean of all benchmarks.
Table 5.3: Hardware platforms for scanning experiments.
Table 5.3: Hardware platforms for scanning experiments.
In Figure 5.7 we compare specialized scanning (Section 5.4.3) across the three object layout schemes. Specialization performs well on average compared to the baseline
In Figure 5.7 we compare specialized scanning (Section 5.4.3) across the three object layout schemes. Specialization performs well on average compared to the baseline
Figure 5.6: The effect of inlining common cases. Geometric mean of 18 benchmarks.
Figure 5.6: The effect of inlining common cases. Geometric mean of 18 benchmarks.
Figure 5.9: The effect of different levels of indirection. Geometric mean of 18 benchmarks.
Figure 5.9: The effect of different levels of indirection. Geometric mean of 18 benchmarks.
Figure 5.10: The effect of various object layout optimizations. Geometric mean of 18 benchmarks.
Figure 5.10: The effect of various object layout optimizations. Geometric mean of 18 benchmarks.
Figure 5.11: Summary, showing four metrics for six well-performing de- signs.
Figure 5.11: Summary, showing four metrics for six well-performing de- signs.
Related topics:
Computer Science
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved