Garbage Collection and Energy Consumption in Java: A Controlled Study Across Workloads and JDKs

Garbage Collection and Energy Consumption in Java: A Controlled Study Across Workloads and JDKs Rahil Sharma Vrije Universiteit Amsterdam r.sharma4@student.vu.nl

arXiv:2608.19520v1 [cs.SE] 20 Aug 2026

July 2026

Abstract

at approximately 1,000 TWh in 2023 [1], corresponding to about 4% of global electricity use [2]. These estimates have increased interest in green software engineering and in design practices that reduce the energy required to develop and operate software systems [3]. The issue is particularly relevant in large-scale deployments, where modest savings at the level of an individual application may become consequential when replicated across many servers and repeated executions [4].

Garbage-collector selection is a low-effort configuration decision that can influence both the performance and energy consumption of Java applications. However, it remains unclear whether aggregate energy rankings among collectors generalise across heterogeneous applications, workload intensities, and JDK distributions. This study presents a controlled empirical evaluation of Serial, Parallel, and G1 garbage collection across three Java applications, three workload intensities, and two JDK distributions: OpenJDK and Oracle JDK. Using EnergiBridge, processor-package energy consumption and execution time were measured and complementary energy–performance metrics derived. Across all evaluated configurations, Parallel recorded the lowest mean energy consumption (839.8 J), followed closely by Serial (857.6 J) and G1 (969.0 J), but an RCBD ANOVA did not establish a statistically reliable collector effect. Workload intensity, by contrast, was a significant driver of energy consumption, with heavy workloads consuming substantially more energy than light or medium workloads regardless of collector. Energy consumption showed a moderate positive association with execution time (r = 0.33), indicating that longer-running configurations tended toward higher energy use, though the relationship was far from proportional. No statistically significant energy difference was found between OpenJDK and Oracle JDK. Overall, the results do not support a universally energy-optimal garbage collector; instead, workload intensity emerges as the more reliable lever for managing Java energy consumption, and collector selection should be treated as an application-specific tuning decision supported by measurement on the target system rather than aggregate rankings alone.

1

Developers and operators nevertheless continue to select and tune software configurations primarily for performance, reliability, and operational predictability. Energy efficiency is rarely treated as a direct configuration objective. This creates an important practical question: can configuration choices that require little or no modification to application code provide meaningful energy savings without degrading performance? Garbage-collector selection is one such configuration choice for Java applications. Java remains widely used in enterprise, server-side, and data-intensive systems [5]. On the Java Virtual Machine (JVM), garbage collection automates memory management by identifying and reclaiming objects that are no longer reachable. This process reduces the burden of manual memory management, but it also consumes processor time, affects application execution, and may introduce pauses [6]. Different garbage collectors organize this work differently, which can influence runtime behaviour, resource utilization, and consequently the total energy consumed during execution. Modern HotSpot JVMs provide several collectors designed for different performance objectives. Serial GC performs collection using a single thread and is generally intended for smaller heaps or environments with limited processing resources. Parallel GC performs collection using multiple threads and primarily targets application throughput. Garbage-First GC, commonly known as G1, divides the heap into regions and performs much of its work incrementally to balance throughput with predictable pause times [7, 8]. G1 has been the default collector in HotSpot since Java 9. Together, these three collectors

Introduction

Energy consumption is becoming an important quality concern in software engineering alongside established performance objectives such as execution time, throughput, and latency. The global electricity consumption of the information and communication technology sector was estimated 1

represent distinct and widely established approaches to garbage collection: single-threaded simplicity, parallel throughput optimization, and region-based pause-time management. These collectors were designed principally around performance and responsiveness rather than energy consumption. Their performance characteristics may therefore produce different energy outcomes, but a collector that performs well for one application may not behave similarly for another. Prior research has shown that changing the collector can reduce the energy consumption of some Java programs without necessarily sacrificing performance. In particular, Shimchenko et al. found that alternatives to the default G1 collector can be more energy efficient for certain workloads [9]. This suggests that GC selection may serve as a low-effort energy optimization. However, it does not establish that one collector is consistently preferable across applications, workload intensities, or runtime distributions. Aggregate comparisons can also conceal substantial differences between applications whose execution times, allocation patterns, and memory demands vary considerably.

garbage-collector selection as an application-specific tuning decision rather than assuming the existence of a universally energy-optimal collector. The results do not imply that GC tuning is irrelevant. Instead, they show why collector choices should be evaluated using measurements from the intended application, workload, and deployment environment.

How much does garbage-collector selection affect the energy consumption and performance of Java applications across different applications, workload intensities, and JDK distributions?

measured the energy effects of garbage collection and reported that GC activity could account for up to 37% of processor energy in their experiments [14]. Their evaluation, however, considered collectors and synthetic workloads that predate current HotSpot defaults. Nou et al. later examined the effects of JVM garbage collectors on power consumption and showed that runtime configuration can produce measurable energy differences, although their evaluation covered a comparatively limited set of benchmarks and workloads [15]. Georges et al. did not focus specifically on energy, but their recommendations concerning JVM warm-up, repeated execution, and statistical analysis remain important for reliable Java experiments [16]. More recent studies have broadened the scope of runtime-level comparisons. Ournani et al. evaluated 52 JVM distributions from eight providers using the DaCapo and Renaissance benchmark suites [17]. They found substantial variation in energy efficiency across JVM distributions and showed that parameters related to garbage collection and just-in-time compilation can influence the resulting energy profile. Their study provides broad coverage of JVM implementations, whereas the present work holds most runtime conditions constant and examines the joint effects of collector choice, workload

2

Related Work

Research on software energy consumption has examined the influence of programming languages, runtime environments, and software design decisions. Castor provides a methodological introduction to estimating the energy footprint of software, including the challenges involved in connecting hardware-level measurements to software-level decisions [10]. Currie et al. translate these concerns into development practices and organizational principles for building more sustainable software systems [11]. Procaccianti et al. classify the broader green software engineering literature into measurement, tooling, and methodological contributions, while identifying a continuing This paper examines how reliably garbage-collector selec- need for controlled empirical validation [12]. Hindle’s tion influences the energy consumption of Java applications Green Mining approach further demonstrates that changes under heterogeneous experimental conditions. A controlled made during software development can be associated with empirical study of Serial, Parallel, and G1 GC is conducted changes in energy consumption [13]. These studies establish across three Java applications, three workload intensities, the broader motivation for treating energy efficiency as a and two JDK distributions, OpenJDK and Oracle JDK. software engineering concern rather than solely a hardware For each evaluated configuration, processor-package energy problem. consumption and execution time are measured using EnergiBridge, and complementary metrics describing power Empirical studies of managed runtimes have shown and energy-performance behaviour are derived. The study that memory management can contribute materially to is guided by the following research question: application energy consumption. Contreras and Martonosi

The results distinguish between descriptive differences and statistically supported effects. Across the complete dataset, Parallel GC recorded the lowest mean energy consumption, followed closely by Serial GC, with G1 GC highest. However, the mixed-effects analysis did not establish a statistically reliable overall collector effect after accounting for variation between applications. Energy consumption showed a moderate positive association with execution time under the tested conditions, while no statistically significant energy difference was found between OpenJDK and Oracle JDK. This study makes three contributions. First, it provides a controlled comparison of three established garbage collectors across multiple Java applications, workload intensities, and JDK distributions. Second, it evaluates aggregate collector rankings together with an inferential analysis that accounts for repeated measurements and between-application heterogeneity. Third, it provides an empirical basis for treating 2

intensity, application, and JDK distribution. Wang et al. introduced GEAR, a framework for comparing garbage collectors across Java, Go, and C# through runtime-independent workload primitives [18]. Their goal was to enable equivalent cross-runtime experiments and expose collector-specific scalability and efficiency behaviour. The present study instead remains within the Java ecosystem and investigates whether energy differences among three established HotSpot collectors support a consistent practical recommendation.

claim that replacing the default G1 collector with Serial or Parallel provides a generally reliable energy optimization. Lengauer et al. provide complementary evidence concerning why such generalization may be difficult [19]. Their analysis of DaCapo, SPECjvm2008, and Scala benchmarks characterizes allocation rates, survivor ratios, object sizes, array density, GC frequency, and changes between continuous and burst allocation phases. The study shows that applications place markedly different demands on memorymanagement systems and recommends heap sizes of approximately three times the live set to permit representative GC behaviour. This heap-sizing principle is adopted in the present experimental design. Unlike Lengauer et al., however, the present study measures processor-package energy consumption and execution time directly. Their workload characterization helps explain why collector effects observed for one application may not transfer unchanged to another. Taken together, prior work establishes that garbage collection can affect energy consumption, that replacing the default collector can produce substantial savings for some applications, and that the magnitude of these effects depends on runtime configuration and application memory behaviour. To date, prior work has not specifically examined whether aggregate rankings among Serial, Parallel, and G1 remain statistically reliable in a controlled design that jointly varies application, workload intensity, and JDK distribution while accounting for repeated measurements and subject-level heterogeneity. This study addresses this narrower question. It complements earlier configurationsearch and collector-optimization research by evaluating the limits of a universal collector recommendation under heterogeneous experimental conditions.

The closest prior work is the study by Shimchenko et al., which investigated whether changing OpenJDK’s default G1 collector could reduce application energy consumption without modifying application code [9]. The authors profiled 35 Java applications drawn from four benchmark suites and evaluated Serial, Parallel, CMS, G1, ZGC, and Shenandoah under multiple heap sizes, Java versions, and collector-specific configurations. Using RAPL-based measurements, they found that replacing G1 could provide considerable energy savings for many applications. Their broad configuration search reported savings of up to 47% when configurations were selected solely for energy consumption, and up to 40% when performance degradation was limited to 5%. They also investigated machine-learning methods for predicting energy-efficient configurations and thereby reducing the cost of profiling. Shimchenko’s subsequent dissertation places this experiment within a broader programme of research on the energy efficiency of concurrent garbage collection [5]. The collector comparison established that fully concurrent collectors, particularly ZGC and Shenandoah, consumed more energy than less concurrent alternatives under the evaluated conditions. The later work therefore focused on improving concurrent collectors through dynamic heap sizing and Experimental Methodology scheduling GC work on energy-efficient or otherwise idle 3 processor cores. The dissertation consequently demonstrates both that GC selection can provide substantial 3.1 Experimental Overview and Design savings in some cases and that collector implementation A controlled experiment was conducted to examine how and scheduling can be modified to improve energy efficiency. garbage-collector selection affects the energy consumption and execution time of Java applications under different The present study begins from the same practical workload intensities and JDK distributions. Three HotSpot premise that garbage-collector selection is an accessible garbage collectors were evaluated: Serial, Parallel, and G1. configuration-level intervention, but it addresses a different Each collector was tested across light, medium, and heavy question. Shimchenko et al. investigated the maximum workload configurations using OpenJDK and Oracle JDK. savings obtainable by searching a broad space of collectors, The experiment followed a Randomized Complete Block heap sizes, Java versions, and runtime parameters. Their Design (RCBD), with Java subject acting as the blockresults establish that beneficial configurations exist, but ing variable. Blocking was necessary because differences they do not imply that a fixed collector ranking will between applications were expected to account for a subgeneralize across applications or operating conditions. This stantial proportion of the observed variation: the subjects study therefore examines whether the energy differences differed in functionality, workload implementation, execuamong Serial, Parallel, and G1 remain statistically tion time, allocation patterns, and memory demand, and reliable when workload intensity and JDK distribution comparisons made without accounting for these differences are varied and between-application heterogeneity is taken could attribute application-level variation incorrectly to into account. The aim is not to predict an optimal garbage-collector selection. Garbage collector was the priconfiguration or modify a collector. Instead, the study mary experimental factor, with Serial, Parallel, and G1 as tests the robustness of the simpler practitioner-facing its three levels; workload intensity and JDK distribution 3

Table 1: Goal-Question-Metric definition of the experiment Element

Definition

Goal

Analyse the effects of garbage-collector selection on the energy consumption and execution time of Java applications.

Purpose

Evaluate whether differences among Serial, Parallel, and G1 support a consistent collector recommendation.

Perspective

Software developers, system operators, and empirical software-engineering researchers.

Context

Three Java applications executed at three workload intensities using OpenJDK and Oracle JDK.

Question

How much does garbage-collector selection affect energy consumption and execution time across different applications, workload intensities, and JDK distributions?

Metrics

Processor-package energy consumption (J), execution time (s), and derived mean power (W).

in Section 3.7, a subsequent data-integrity check led to the exclusion of results from the benchmark subjects originally planned alongside these applications; the RCBD reported here reflects only the retained, verified experimental structure.

Figure 1: Randomized Complete Block Design for the Java garbage-collection energy experiment, restricted to the three verified application subjects. All 216 planned runs were retained for analysis.

were included as additional crossed factors. Within each block, the experimental conditions therefore combined three garbage collectors, three workload intensities, and two JDK distributions. Experimental conditions were replicated, and run order was randomized to reduce the potential influence of temporal effects, including background system activity and changes in hardware temperature. Because only three subjects were available as blocks, subject was treated as a fixed rather than random effect in the subsequent analysis (Section 3.7); descriptive collector rankings are interpreted alongside the inferential model rather than treated as evidence of a universally optimal collector.

3.2

3.3

Experimental Subjects

The experiment evaluated three Java applications: Spring PetClinic, a REST-based To-Do application, and the ANDIE image-processing tool. These subjects were selected to represent persistent, interaction-driven Java services rather than short-lived, terminating programs, so that collector behaviour could be examined under conditions closer to typical server-side deployment. The three applications differed in functionality, request or interaction patterns, and memory-allocation behaviour, which supported blocking on subject in the RCBD design described above.

Goal Definition Using the GQM Framework

3.4

Workload Configuration

The experiment was defined using the Goal-Question-Metric (GQM) framework to connect its practical objective to Each Java subject was executed under light, medium, and the research question and measured outcomes. Table 1 heavy workload configurations. These levels increased the summarizes this relationship. amount of work performed by the subject and, where applicable, the resulting allocation rate and heap pressure. The GQM definition emphasizes that the objective is not Light configurations represented comparatively limited exemerely to identify the collector with the lowest aggregate cution demands, medium configurations increased processenergy consumption. It also examines whether the observed ing and memory allocation, and heavy configurations placed differences remain consistent across applications and ex- the greatest demand on the application and its memoryperimental conditions. Energy consumption and execution management system. The classification follows the broader time are therefore considered jointly, while mean power is observation that allocation rates, survivor ratios, object used to distinguish changes in power demand from changes lifetimes, and garbage-collection frequency can differ concaused primarily by execution duration. The design speci- siderably across Java workloads [19]. Because the evaluated fied 216 experimental runs, corresponding to three applica- subjects performed different tasks, the concrete parameters tions, three garbage collectors, three workload intensities, used to instantiate light, medium, and heavy workloads two JDK distributions, and four repetitions. As described were defined separately for each subject. The workload 4

levels should therefore be interpreted as ordered intensities measure. Mean power was derived as the ratio between within each subject rather than as identical quantities of measured energy and execution time: work across all subjects. E Pmean = , t 3.5 Experiment Orchestration and Execu- where E denotes processor-package energy consumption tion in joules and t denotes execution time in seconds. Energy The experiment was automated using the and execution time were analysed together because lower ExperimentRunner framework [20], deployed on a power demand does not necessarily produce lower total dedicated Raspberry Pi 4, which initiated and monitored energy consumption when it is accompanied by a longer runs on a separate measurement laptop but did not execute execution time. the evaluated Java programs. This separation prevented the computational activity of the orchestration framework from contributing directly to the energy measurements collected on the laptop. For each run, ExperimentRunner selected the Java subject, workload intensity, JDK distribution, and garbage-collector configuration according to the randomized experimental schedule, and launched the workload in a fresh JVM. The selected collector was enabled using the corresponding JVM option: -XX:+UseSerialGC, -XX:+UseParallelGC, or -XX:+UseG1GC. OpenJDK and Oracle JDK were executed under otherwise comparable experimental conditions.

3.7

Data Preparation and Statistical Analysis

Run metadata and EnergiBridge measurements were consolidated into a common dataset for analysis. A data-integrity check performed prior to modelling identified that, for all runs drawn from the originally planned benchmark subjects, the recorded energy value was numerically consistent with a Unix millisecond timestamp rather than a physically plausible energy reading; the values decoded directly to the date and time at which each run was executed. Because this corruption affected every run in the benchmark subject families and no verified raw energy readings could be Because all three subjects were persistent or interactionrecovered for them, those subjects were excluded from driven rather than terminating programs, each session analysis in their entirety. The three application subjects required a bounded measurement window. Each application (Section 3.3) showed no evidence of this or any comparable was executed for a fixed duration corresponding to its irregularity: energy values across GC, workload, and JDK light, medium, or heavy configuration, while scripted conditions were of a magnitude and variability consistent API or interface interactions generated the workload. with physical measurement, and all 216 planned runs for EnergiBridge measurement was started immediately these subjects were retained. before each session and stopped when the configured duration elapsed. Runs were conducted under controlled The primary outcomes were processor-package energy system conditions, with non-essential activity limited consumption and execution time. Mean power was derived and pauses between executions to reduce thermal carry-over. for each run as E/t, where E is measured energy consumption and t is execution time. Descriptive summaries and A mock energy interface was also implemented to support graphical checks were first used to examine the distributions pipeline development on systems without access to Linux of the outcomes, identify potential measurement anomalies, RAPL counters. This interface was used only to test experand compare the scale of variation within and between iment orchestration and output handling. Measurements subjects. Because only three Java subjects remained produced by the mock interface were not included in the after the exclusion described above, subject was treated empirical dataset. as a fixed blocking factor rather than a random effect: a random-intercept variance component is not reliably 3.6 Energy and Performance Measurement estimable from three groups, and standard practice for RCBD designs at this scale is to model blocks as fixed. Energy and execution-time measurements were collected on Inferential analysis was therefore conducted using a the measurement laptop using EnergiBridge [21]. EnergiBfull-factorial RCBD analysis of variance (ANOVA), with ridge reads the Running Average Power Limit counters garbage collector, workload intensity, JDK distribution, exposed by the processor and records processor-package subject, and the garbage-collector-by-workload and energy consumption during program execution. Each run garbage-collector-by-JDK interactions entered as fixed generated an individual EnergiBridge CSV file containing effects. the recorded measurements. The run configuration, execution status, and resulting measurements were subsequently For energy consumption, the model can be expressed as: consolidated into a common dataset for statistical analysis. Processor-package energy consumption, measured in joules, Eijkr = β0 + βSubject,r + βGC,i + βWorkload,j + βJDK,k was the principal outcome variable. Execution time, measured in seconds, was retained as the primary performance + βGC×Workload,ij + βGC×JDK,ik + εijkr . 5

Table 2: Descriptive results by garbage collector (serviceapplication subset, n = 216). Collector

Energy (J)

Runtime (s)

Power (W)

857.6 839.8 969.0

200.0 200.0 200.0

4.49 4.31 4.96

Serial Parallel G1

where βSubject,r represents the fixed effect of block r and εijkr represents residual variation. An analogous model was used for the Energy–Delay Product. Model assumptions were evaluated through residual diagnostics and tests of distributional shape and variance homogeneity. Where the omnibus ANOVA justified pairwise comparisons among collectors or workload levels, Tukeyadjusted post-hoc contrasts were used. Statistical tests used a significance level of α = 0.05, and statistical significance was interpreted together with estimated effect sizes because a detectable difference in energy consumption does not necessarily constitute a practically meaningful optimization.

4

Figure 2: Energy consumption by garbage-collection strategy (service-application subset, n = 216). Parallel has the lowest descriptive mean, followed closely by Serial and then G1, but the distributions overlap substantially.

substantially. The RCBD ANOVA found no statistically significant main effect of garbage collector (F (2, 202) = 0.65, p = 0.524), and pairwise Tukey-adjusted comparisons among all three collectors were non-significant (all p > 0.57). The lower mean observed for Parallel should therefore be interpreted as a descriptive tendency rather than evidence that any collector was consistently more energy efficient across the three evaluated applications. Figure 3 presents the proportion of total sum of squares attributable to each experimental factor in the RCBD ANOVA. Workload accounts for the largest identifiable share of variance (11.1%), followed by subject (1.9%) and the GC-byJDK interaction (0.6%); garbage collector alone accounts for 0.6% and its interaction with workload for 0.3%. The residual (85.4%) reflects the substantial within-cell variability characteristic of energy measurements on real applications. This decomposition is descriptive; the ANOVA F -tests reported above and below remain the basis for inferential claims.

Results

This section reports the observed energy and performance patterns across garbage collectors, workload intensities, and JDK distributions, restricted to the three verified application subjects (Section 3.7). Because only three subjects remain as blocks, the inferential analysis reported here uses a fixed-block RCBD ANOVA rather than a mixedeffects model with subject as a random intercept: a randomintercept variance component is not reliably estimable from three groups, and preliminary mixed-effects fits produced unstable interaction tests as a result. Treating subject as a fixed block is standard practice for RCBD designs and is used throughout this section. The results distinguish descriptive differences from statistically supported effects.

4.1

Energy Consumption Across Garbage Collectors

Across the collected measurements, processor energy 4.2 Workload Intensity and Collector Inconsumption ranged from approximately 238 J to 3959 J, teraction with a mean of 888.8 J and a standard deviation of 773.8 J. This wide dispersion reflects the heterogeneous resource Mean energy increased monotonically across the three workdemands of the evaluated applications and workload load levels: light configurations consumed 606.7 J, medium intensities. Table 2 summarizes the descriptive results by configurations 830.0 J, and heavy configurations 1229.7 J. collector. Parallel had the lowest mean energy consumption The overall workload effect was statistically significant at 839.8 J, followed by Serial at 857.6 J and G1 at 969.0 J. (F (2, 202) = 13.18, p < 0.001). Tukey-adjusted pairwise G1 also exhibited the highest mean power, whereas mean comparisons showed that Heavy differed significantly from execution time was fixed by the bounded measurement both Light (p < 0.001) and Medium (p = 0.0036), while window and did not differ meaningfully among collectors. Light and Medium did not differ significantly from one another (p = 0.163). As shown in Figure 4, workload Figure 2 shows that this ordering was visible in the raw intensity is the clearest source of systematic variation distributions, but also that the distributions overlapped identified in this experiment. 6

Figure 3: Variance decomposition of energy consumption by experimental factor, expressed as a proportion of total sum of squares (service-application subset, n = 216).

Figure 5: Interaction between garbage collector and workload intensity (service-application subset, n = 216). Energy increases with workload for all three collectors; the interaction is not statistically significant.

that would be expected if runtime alone drove energy demand. The relationship was of comparable magnitude within each collector: r = 0.28 for Serial, r = 0.37 for Parallel, and r = 0.36 for G1 (all p < 0.02). This indicates that longer-running configurations tended toward higher energy use, but the association leaves most of the variation in energy consumption unexplained by runtime alone, most likely reflecting the influence of workload intensity and application-specific allocation behaviour. Energy–Delay Product (EDP) was examined as a joint energy–performance measure. Mean EDP was similar for Serial (187.2 × 103 J s) and Parallel (187.3 × 103 J s), and higher for G1 (216.6 × 103 J s). An RCBD ANOVA on EDP found no significant effect of collector (F (2, 205) = 0.59, p = 0.557) or of the collector-by-workload interaction (F (4, 205) = 0.30, p = 0.875), while workload intensity remained highly significant (F (2, 205) = 48.1, p < 0.001), consistent with the energy results above. As shown in Figure 6, EDP therefore mirrors the raw-energy analysis: a numerically higher mean for G1, but no statistically reliable collector effect.

Figure 4: Energy consumption by workload intensity (service-application subset, n = 216). Heavy differs significantly from Light and Medium; Light and Medium do not differ significantly from each other.

The collector-by-workload interaction was not statistically significant (F (4, 202) = 0.18, p = 0.948). Figure 5 shows broadly parallel trajectories across workload levels for all three collectors, providing no reliable evidence that increasing workload intensity changed the relative behaviour of the collectors, although G1 shows a numerically steeper descriptive increase from Light to Heavy than Serial or Parallel.

4.4

JDK Distribution

The RCBD ANOVA found no statistically significant difference in energy consumption between OpenJDK (863.2 J) and Oracle JDK (914.3 J) (F (1, 202) = 0.26, p = 0.611). The collector-by-JDK interaction was also non-significant (F (2, 202) = 0.71, p = 0.494). Table 3 reports the descriptive marginal means; although Parallel appears notably lower under OpenJDK than under Oracle JDK, this pattern 4.3 Energy–Performance Relationship is not statistically supported by the interaction test and Energy consumption and execution time were positively should be treated as sampling variation given the modest correlated overall (r = 0.33, p < 0.001), a moderate cell sizes (36 runs per JDK-by-collector cell) rather than as association rather than the near-proportional relationship evidence of JDK-dependent collector behaviour. As with the 7

collector or a reliable difference between the two evaluated JDK distributions within this reduced, three-application dataset. Collector selection may still matter for individual applications, as suggested by the numerically higher G1 means, but the direction and magnitude of that effect cannot be generalized from the aggregate evidence available here.

5

Threats to Validity

This study evaluates garbage-collector behaviour under a controlled experimental configuration, but its findings remain subject to several limitations. These limitations are discussed in terms of internal, construct, external, and conclusion validity. Figure 6: Energy–Delay Product by garbage collector 5.1 Internal Validity (service-application subset, n = 216). G1 has a numerically higher descriptive mean, but the collector effect is not Energy measurements may have been influenced by background operating-system activity, thermal variation, statistically significant. CPU scheduling, and other processes unrelated to the Table 3: Mean energy by JDK distribution and garbage experimental treatments. To limit such interference, the collector (service-application subset, descriptive only; n = device under test was dedicated to workload execution, non essential activity was restricted, and orchestration 36 per cell). was performed remotely on a Raspberry Pi. Runs were separated by cooldown periods and executed in randomized JDK Collector Energy (J) order so that transient environmental effects were less likely OpenJDK Serial 909.0 to align systematically with a particular garbage collector, OpenJDK Parallel 745.5 workload, or JDK distribution. These controls reduce, but OpenJDK G1 935.2 cannot eliminate, measurement noise. Oracle Oracle Oracle

Serial Parallel G1

806.3 934.0 1002.8

JVM initialization and JIT compilation may also influence runtime and energy, particularly during short executions. Workloads were executed in fresh JVM processes, and warmup execution was used before measurement where applicable. Nevertheless, collector heuristics and compiled code can continue to evolve during execution, meaning that not every observation necessarily represents a fully stabilized JVM state. Although the experimental factors were controlled, the study was performed on one physical device. Repeated runs therefore represent replications of configurations on the same system rather than independent replications across machines. Any unobserved device-specific behaviour may consequently affect all measurements.

collector main effect, the absence of a statistically detectable JDK difference should not be interpreted as evidence that OpenJDK and Oracle JDK are equivalent in energy consumption; no formal equivalence test was performed on this subset.

4.5

Summary of Findings

Three findings emerge from the analysis. First, Parallel and Serial had lower descriptive mean energy consumption than G1, but the RCBD ANOVA did not establish a statistically reliable collector effect, and this held for both raw energy and EDP. Second, workload intensity was the only factor to reach statistical significance, with Heavy workloads consuming significantly more energy than Light or Medium; the collector-by-workload interaction was not significant, so this effect did not depend on which collector was used. Third, execution time and energy showed a moderate, not near-proportional, positive association across all collectors, and JDK distribution produced neither a detectable main effect nor an interaction with collector. Taken together, the results do not identify a universally energy-optimal garbage

5.2

Construct Validity

Energy consumption was operationalized using the processor energy counters exposed through the Linux powercap interface and collected by EnergiBridge [21]. These measurements represent the energy domains made available by the tested AMD system; they do not capture the complete wall-socket energy consumption of the laptop. Energy used by components outside the exposed domains, including the display, storage, networking hardware, and power-conversion circuitry, may therefore be omitted. The results should accordingly be interpreted as processor-level 8

energy estimates rather than total system energy consump- adaptation over extended periods. tion.

5.4

Runtime and Energy–Delay Product provide complementary views of performance and its relationship with energy, but neither measure captures every aspect of application quality. Throughput, response-time distributions, memory pressure, and service-level requirements may alter whether a collector is preferable in a production deployment. The treatment space was also limited to Serial, Parallel, and G1 garbage collection. These collectors represent established JVM strategies with different design goals, but they do not cover the complete range of available collectors. In particular, the results do not characterize low-latency collectors such as ZGC or Shenandoah.

Conclusion Validity

Of the 216 runs planned for the three verified application subjects, all 216 passed data-quality screening and were retained for analysis, indicating that the corruption affecting the excluded benchmark subjects did not extend to this subset. Because the exclusion was systemic to entire subject families rather than scattered across individual runs, it is unlikely to have introduced the kind of condition-specific bias that partial, run-level exclusions would raise; however, it substantially reduces the number of independent blocks available to the design, from six subject families to three applications. With only three blocks, subject is treated as a fixed rather than random effect in the RCBD ANOVA (Section 3.7), which is standard practice at this scale 5.3 External Validity but means that between-subject variability is estimated, not generalized to a wider population of possible Java All measurements were collected from a single AMD applications. Ryzen 9 8940HX laptop running Ubuntu Linux and the selected OpenJDK and Oracle JDK configurations. The Energy measurements displayed substantial withinresults may differ on server-class processors, ARM systems, condition variability and broad overlap among collectors. virtual machines, cloud instances, other operating systems, Consequently, the absence of statistically significant or machines with different memory and thermal charactercollector or JDK effects should not be interpreted as istics. The findings should therefore not be generalized proof that the corresponding effects are zero. Small or directly beyond hardware and software environments subject-specific differences may remain undetected because comparable to the evaluated testbed. of measurement noise, heterogeneous workloads, and the limited number of subjects. Model diagnostics were The experiment evaluated three Java applications: Spring inspected to assess residual behaviour and the influence PetClinic, a REST-based To-Do application, and the of unusual observations, and the variance decomposition ANDIE image-processing tool, each exercised under light, reported in Section 4.1 is derived directly from the same medium, and heavy configurations. This is a small subject ANOVA sum-of-squares used for the significance tests, so pool for an RCBD design, and it is narrower than originally the two are not expected to diverge in the way that an planned: a parallel set of terminating benchmark subjects exploratory decomposition and a separately fitted model (DaCapo, the Computer Language Benchmarks Game, and can. Rosetta Code) was excluded after a data-integrity check found that their recorded energy values were corrupted at Finally, multiple descriptive comparisons were examined the source (Section 3.7), rather than for reasons related to across collectors, workloads, JDKs, and combined configtheir behaviour under test. The three retained applications urations. Configuration-level patterns should therefore be share a persistent, interaction-driven execution style; treated as exploratory unless supported by the correspondthe results therefore speak most directly to server-side ing inferential tests. In particular, non-significant mean Java services and should not be assumed to generalize differences do not justify a universal ranking of the evaluto short-lived, terminating, or batch-style Java programs, ated collectors, and the reduced subject pool means these which were not represented in the verified dataset. The conclusions should be read as applying to the three evaluated workload labels are relative to the configurations used in applications rather than to Java server-side applications in this study and should not be interpreted as standardized general. categories applicable to every Java system. Large heaps, highly concurrent applications, and latency-sensitive workloads outside the three evaluated applications may 6 Discussion produce different collector behaviour. This study examined how garbage-collector strategy, workThe application workloads were executed through bounded, load intensity, and JDK distribution relate to processor-level scripted sessions. Although this made them measurable energy consumption and execution time across three Java within the common experimental design, such sessions ap- applications. The results present a more qualified picture proximate rather than reproduce long-running production than a simple ranking of collectors. Parallel and Serial operation. They may not capture effects such as heap ageing, exhibited lower descriptive mean energy consumption than changing request distributions, traffic bursts, or collector G1, but the differences were small relative to the substantial 9

variability within each collector and were not statistically significant. Workload intensity, by contrast, was the one factor to produce a clear, statistically supported effect. Execution time and energy showed a positive but moderate association, weaker than a near-proportional relationship would imply.

Serial (r = 0.28), Parallel (r = 0.37), and G1 (r = 0.36). Configurations that ran longer tended to consume more energy, but runtime alone accounts for only a modest share of the variation in energy consumption; workload intensity and application-specific allocation behaviour evidently contribute substantially more.

6.1

This association should not be interpreted as evidence that execution time alone caused the observed energy differences. Both runtime and energy can increase because a workload performs more computation, processes more data, or places greater pressure on memory and the collector. The finding indicates a real but partial energy–performance alignment: reducing unnecessary execution time is plausibly beneficial for energy use, but it is not a reliable proxy for energy consumption on its own. The Energy–Delay Product analysis reinforced this picture. Serial and Parallel had similar, lower descriptive EDP than G1, but neither collector, workload, nor their interaction produced a statistically significant collector-related effect on EDP beyond the workload main effect already noted above. The experiment therefore did not identify a collector-attributable energy–performance trade-off, though it also cannot rule one out in individual applications outside the evaluated set.

Interpretation of the Findings

Collector differences were visible but statistically uncertain. Parallel recorded the lowest descriptive mean energy consumption (839.8 J), followed closely by Serial (857.6 J) and G1 (969.0 J). G1 therefore consumed approximately 15% more energy than Parallel and 13% more than Serial at the aggregate descriptive level. The corresponding plots showed a broadly similar ordering across several configurations. However, the energy distributions overlapped substantially, and the RCBD ANOVA did not establish a statistically significant collector effect (F (2, 202) = 0.65, p = 0.524), a result that held for both raw energy and Energy–Delay Product. The observed ranking therefore does not support the conclusion that Parallel or Serial is universally more energy-efficient than G1. Instead, it suggests a possible aggregate tendency whose reliability could not be distinguished from subject-level variation and measurement noise across the three evaluated applications. The variance decomposition in Section 4.1 attributes only a small share of total variance to collector (0.6%) relative to workload (11.1%) and residual variation (85.4%), consistent with the ANOVA result rather than in tension with it. Workload intensity was the clearest statistically supported finding. Mean energy increased from 606.7 J under light workloads to 830.0 J under medium workloads and 1229.7 J under heavy workloads. This monotonic pattern is consistent with the expectation that more demanding configurations require greater computation and therefore more energy, and unlike the collector effect, it was statistically significant (F (2, 202) = 13.18, p < 0.001). Post-hoc comparisons localized this effect to the Heavy condition: Heavy differed significantly from both Light and Medium, while Light and Medium did not differ significantly from each other. The collector-by-workload interaction was not significant, so this effect did not depend on which collector was in use; G1 showed a numerically steeper descriptive increase from Light to Heavy than Serial or Parallel, but the interaction test does not support treating this as a reliable collector-specific sensitivity to workload. Workload intensity is therefore the strongest lever identified in this experiment for managing energy consumption, and it operates independently of collector choice.

No JDK difference was established. OpenJDK and Oracle JDK produced similar descriptive energy distributions (863.2 J and 914.3 J respectively), and neither the JDK main effect (p = 0.611) nor the collector-by-JDK interaction (p = 0.494) was statistically significant. Collector behaviour therefore appeared broadly stable across the two evaluated distributions. As with the collector effect, nonsignificance here does not demonstrate that the distributions are equivalent; no formal equivalence test was performed on this dataset. The data available do not support choosing between these distributions on the basis of processor-level energy consumption alone.

6.2

Practical Implications

For application developers and operators, the findings argue against choosing a collector solely from aggregate energy rankings. Parallel and Serial had lower descriptive means than G1, but the uncertainty around these differences prevents a general recommendation. Collector selection should remain application-specific and account for throughput, latency, pause-time, memory-footprint, and stability requirements in addition to energy. By contrast, workload intensity was a reliable and substantial driver of energy consumption in this experiment, making workload-aware capacity planning a more evidence-backed lever than collector substitution for the applications studied here. The Energy and runtime were positively but only mod- moderate energy–runtime association means performance erately associated. The observed relationship between profiling is a reasonable starting point for energy work, but execution time and energy consumption was positive runtime should not be treated as a complete substitute and statistically significant but moderate in strength for direct energy measurement, since configurations with (r = 0.33, p < 0.001), with comparable correlations within similar execution times can still differ in energy demand. 10

The absence of a detectable JDK effect simplifies the choice between the two tested distributions only in a limited sense: energy measurements provide no clear reason to prefer one over the other in this testbed. Compatibility, support, licensing, operational tooling, and application performance remain independent considerations. More broadly, the results favour measurement-guided configuration over universal tuning rules. The collector with the lowest aggregate mean need not be the best option for every application, workload, or deployment environment. Teams seeking energy reductions should therefore benchmark realistic application behaviour on hardware comparable to their production systems, and should treat workload management, not just collector choice, as a primary energy lever.

6.3

Implications for Sustainable Java Systems

The findings show that energy efficiency in Java cannot be reduced to a single JVM flag. Collector choice produced observable descriptive differences, but those differences were not sufficiently consistent to establish a general collector effect, even as workload intensity emerged as a clear and substantial driver of energy demand. For sustainable software engineering, this shifts attention from searching for a universally “green” collector toward understanding how workload characteristics, execution time, allocation behaviour, and collector policy interact. JVM configuration remains relevant, but the evidence here places workload management ahead of it as a practical energy-management priority; collector choice should be evaluated as one component of a broader system rather than as an independent solution to energy inefficiency.

[3] A. Fonseca, R. Kazman, and P. Lago, “A manifesto for energy-aware software,” IEEE Software, vol. 36, no. 6, pp. 79–82, 2019. [4] G. Pinto and F. Castor, “Energy Efficiency: A New Concern for Application Software Developers,” Communications of the ACM, vol. 60, no. 12, pp. 68–75, 2017. [5] M. Shimchenko, “Optimizing Energy Efficiency of Concurrent Garbage Collection,” Ph.D. dissertation, Uppsala University, 2024. [6] M. Carpen-Amarie, P. Marlier, P. Felber, and G. Thomas, “A performance study of java garbage collectors on multicore architectures,” in Proceedings of the 6th Intl. Workshop on Programming Models and Applications for Multicores and Manycores (PMAM). ACM, 2015, pp. 20–29. [7] D. Detlefs, C. Flood, S. Heller, and T. Printezis, “Garbage-first garbage collection,” in Proceedings of the 4th International Symposium on Memory Management (ISMM). ACM, 2004, pp. 37–48. [8] Oracle Corporation, “HotSpot GC Tuning Guide: Available Collectors (Java 17),” https://docs.oracl e.com/en/java/javase/17/gctuning/available-collect ors.html, 2021, accessed 14 Sept 2025. [9] M. Shimchenko, M. Popov, and T. Wrigstad, “Analysing and predicting energy consumption of garbage collectors in openjdk,” in Proceedings of the 19th International Conference on Managed Programming Languages and Runtimes (MPLR). ACM, 2022.

[10] F. Castor, “Estimating the energy footprint of software systems: a primer,” arXiv preprint Future studies should examine this interaction using a larger arXiv:2407.11611, 2024. [Online]. Available: https: and more diverse set of subjects than was available after //arxiv.org/abs/2407.11611 data-integrity screening in this experiment, additional hardware platforms, and collectors such as ZGC and Shenan- [11] A. Currie, S. Hsu, and S. Bergman, Building Green doah. Direct wall-power measurements would complement Software. O’Reilly Media, 2025, available under the processor-level energy counters used here, while longerCC BY-NC-ND license. [Online]. Available: https: running service experiments could reveal effects related to //www.strategically.green/building-green-software heap ageing, adaptive compilation, traffic variation, and [12] G. Procaccianti, P. Lago, and I. Malavolta, “Green latency that bounded sessions may not capture. software engineering: A systematic mapping study,” in Proceedings of the 5th International Conference on References ICT for Sustainability (ICT4S), 2016, pp. 1–10. [1] Ericsson, “Sustainability in ICT – ericsson mobility [13] A. Hindle, “Green mining: A methodology of relating report,” https://www.ericsson.com/en/reports-and-p software change to power consumption,” in Proceedapers/mobility-report/articles/ict-carbon-footprint-d ings of the 9th IEEE Working Conference on Mining ecreasing, 2024, accessed: 2025-09-15. Software Repositories (MSR). IEEE, 2012, pp. 78–87. [2] Statista. (2025) Global electricity consumption 2023. [14] G. Contreras and M. Martonosi, “Techniques for realBased on data from U.S. Energy Information system characterization of java virtual machine energy Administration (EIA). [Online]. Available: https: and power behavior,” in Proceedings of the Interna//www.statista.com/statistics/280704/world-power-c tional Conference on Parallel Architectures and Compionsumption/ lation Techniques (PACT). IEEE, 2006, pp. 141–152. 11

[15] R. Nou et al., “Power consumption of java virtual machine garbage collectors,” in Proceedings of the 2017 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2017, pp. 221– 231. [16] A. Georges, D. Buytaert, and L. Eeckhout, “Statistically rigorous java performance evaluation,” ACM SIGPLAN Notices, vol. 42, no. 10, pp. 57–76, 2007. [17] Z. Ournani, M. C. Belgaid, R. Rouvoy, P. Rust, and J. Penhoat, “Evaluating the impact of Java Virtual Machines on energy consumption,” in Proceedings of the 15th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). Bari, Italy: ACM, 2021, pp. 1–11. [18] Y. Wang, W. Dou, Y. Liang, Y. Wang, W. Wang, J. Wei, and T. Huang, “Evaluating garbage collection performance across managed language runtimes,” in 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), 2025, pp. 1806–1818. [19] P. Lengauer, V. Bitto, H. Mössenböck, and M. Weninger, “A comprehensive java benchmark study on memory and garbage collection behavior of dacapo, dacapo scala, and specjvm2008,” in Proceedings of the 8th ACM/SPEC on International Conference on Performance Engineering, ser. ICPE ’17. New York, NY, USA: Association for Computing Machinery, 2017, p. 3–14. [Online]. Available: https://doi.org/10.1145/3030207.3030211 [20] S. Group, “Experimentrunner,” https://github.com/S 2-group/experiment-runner, 2025. [21] ——, “Energibridge,” https://github.com/S2-group/e nergibridge, 2025.

12

Related documents

• Optimalisasi Manajemen Thread dalam Sistem Operasi untuk Meningkatkan Kinerja Multithreading#1066974
• Java for dummies#248261
• Ontwikkelen van instrumentarium en standaarden voor het oplossen van integrale vraagstukken voor (delen van) het energiesysteem#200645
• Strategies for the integration of sustainability in biorefinery process design: A systematic review#1134177
• Beginning programming with Java for dummies#248263