Pith. sign in

REVIEW 4 major objections 5 minor 31 references

Dynamic Software Updating in Java -- Comparing Concepts and Resource Demands

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper compares four Java live-update systems and finds a systematic trade-off: the more kinds of changes a system supports, the more it costs in running time and memory.

desk verdict Useful comparative DSU study whose taxonomy and change-level ladder are solid, but the resource comparison is only partially supported due to cross-JVM confounds; worth refereeing with major revision. read the letter →

arxiv 2506.01875 v1 pith:LAQOGK3M submitted 2025-06-02 cs.SE

Danijel Mlinaric , Vedran Mornar This is my paper
classification cs.SE
keywords dynamicsoftwareupdatingJavaDAOPmodifiedJVMresourcedemandsperformancemeasurementevolutionliveupdatetrade-off
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper compares four publicly available Java dynamic software updating (DSU) systems by splitting them into two concepts: modified virtual machine approaches (mJVM), where the JVM itself is changed to support updates, and dynamic aspect-oriented programming (DAOP) approaches, where runtime weaving updates code from outside. It introduces a three-level scale of supported changes, from method body changes up to class hierarchy changes, and measures steady state overhead, update duration, post-update execution overhead, and memory use. The central finding is that the mJVM systems support the deepest changes (level 3) but systematically pay for that with higher steady-state and memory overhead, while the DAOP systems support fewer change types (level 2) and are cheaper, with update duration and post-update overhead depending on each system's internal mechanism. This matters because any long-running Java service that wants live updates must choose between how much it can change and how much performance it is willing to lose.

What carries the argument

The central machinery is the proposed categorization of Java DSU concepts and a three-level taxonomy of supported program changes. Category one, mJVM, modifies the virtual machine itself; category two, JVM agent, uses Java agent APIs to intercept class loading; category three, DAOP, uses runtime aspect weaving, implemented either as a VM modification or an agent. The change taxonomy assigns level 1 to method body changes, level 2 to adding or removing methods, fields, constructors, and classes, and level 3 to supertype and interface changes. This framework organizes the comparison, and the accompanying benchmark tool applies it by measuring steady state overhead, update duration, modified state overhead, and memory usage on a common set of modification tests.

What would settle it

Rerun the four systems with a common virtual machine and compiler configuration for all of them, or at least equalize the optimization level between the modified-JVM and DAOP systems, and check whether the overhead ordering survives. If the slower modified-JVM system's steady-state overhead drops below the DAOP systems when its compiler is set to the same optimization level as the others, the paper's conclusion that modified-JVM approaches introduce higher overhead would fail.

Watch

Extended reading notes

Core claim

The paper's central claim is that the capability of a Java DSU approach and its resource cost are tied to where the updating logic lives. Approaches built into a modified JVM can perform level 3 changes such as adding interfaces and changing supertypes, while DAOP approaches are limited to level 2 compound changes; the deeper capability carries a measurable price. In the steady state, DAOP mechanisms introduce lower overhead than modified JVM mechanisms, and memory measurements follow the same direction, although exceptions such as one modified-JVM system releasing memory after updates complicate the picture. Update duration and modified state overhead are not predetermined by the category: the fastest DAOP system updates by switching call sites with invokedynamic, the slowest DAOP system inlines bytecode at runtime, and the modified-JVM systems cluster together because both lean on the garbage collector.

Load-bearing premise

The comparison assumes that the measured overhead and memory differences come from each system's updating mechanism rather than from the different Java virtual machines, Java versions, and compiler configurations used to run them.

Editorial extensions

If this is right

  • Choosing a Java DSU approach is choosing a point on a capability-versus-resource trade-off; a system that can restructure class hierarchies will normally cost more in steady-state running time and memory than one that only exchanges method bodies.
  • For long-running services where downtime is the main cost, DAOP-based approaches are the cheaper option when the required changes stay at level 2 or below.
  • Update duration is not a proxy for category: the invokedynamic-based approach is an order of magnitude faster than the modified-JVM systems, while the bytecode-inlining approach is the slowest, so users must look at each system's mechanism.
  • The modified-state overhead is temporary for the modified-JVM systems except one whose long-term penalty indicates it discards JVM optimizations; the DAOP systems pay a persistent but small cost per call.
  • Standard HotSwap covers only level 1, so production use of DSU in Java requires one of these extended approaches.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the fastest DAOP approach extended its field-level support and added state transfer, it could plausibly cover most level 2 changes while keeping its low overhead, making it a candidate for a general-purpose DSU layer in unmodified JVMs.
  • The same classification and resource metrics could be applied to dynamic update systems in other managed runtimes to test whether the capability-cost trade-off is a general property or specific to the Java virtual machine.
  • The paper's distinction between transient and persistent modified-state overhead suggests a sharper design target: update mechanisms that avoid invalidating JIT optimizations could remove most of the long-term post-update cost.
  • A standardized update description format, which the paper leaves as future work, would make cross-approach benchmarks reproducible and could become the seed of a DSU benchmark suite for Java.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper categorizes Java dynamic software updating (DSU) concepts into modified JVM (mJVM), JVM agent, and DAOP categories, and empirically compares four publicly available approaches (Prose, Jooflux, DCEVM, Jvolve) with respect to steady-state overhead, update duration, modified-state overhead, and memory usage. The authors introduce a taxonomy of change complexity (levels 1–3), a set of micro-benchmark modification tests, and a measurement methodology. The central conclusion is that mJVM approaches support more complex changes (level 3) but pay higher steady-state and memory overhead, while DAOP approaches are cheaper but limited to level 2 changes.

Significance. If the comparative claims were valid, this would be a useful contribution because there is little prior work comparing multiple Java DSU concepts under a common measurement framework. The paper's taxonomy of change levels and its benchmark tooling are valuable, and the authors are transparent about the limitations of their helper tools and the manual adaptation of tests. The work is not circular: it is an empirical measurement study with no fitted parameters; the conclusions rest on external benchmarks rather than on assumptions encoded in the measurement procedure. However, as detailed below, a cross-VM and cross-JDK confound undermines the central resource-demand comparison, so the significance is currently conditional on a substantial revision.

major comments (4)
  1. [Section 4, Appendix] The evaluation confounds the DSU approach with the runtime system. Section 4 states that Jooflux, Prose, and DCEVM run on HotSpot with the server compiler, while Jvolve runs on Jikes RVM with the fast adaptive compiler, and the Appendix lists JDK 1.5.0_22, JDK 1.7.0_85, JDK 1.7.0, and Jikes RVM 3.0.1. Since Section 3.1 defines steady-state overhead as the percentage difference between DSU-enabled and DSU-disabled execution on each approach's own baseline, the resulting percentages are normalized to different runtimes and are not directly comparable across approaches. Consequently, the conclusion in Section 6 that mJVM approaches come 'at a price of an overhead in steady state execution' and the claim in Section 4.2 that 'DAOP introduce lower overhead compared to modified JVM' are not established: Jvolve is the only mJVM representative on a non-HotSpot VM, and its large figures (e.g., 408.38% on lusearch in Figure 4) may reflect Jikes RVM JIT, GC, or threading behavior rather than the DSU concept.
  2. [Figure 4, Table 3, Section 4.2] Figure 4 and Table 3 report mean values without error bars or confidence intervals, and the text's reference to 'below the standard deviation' is not backed by a table or graph of the standard deviations. Without measures of variance, the reader cannot determine whether differences such as Prose at 11.79% versus Jooflux at -0.11% on bloat are real or noise, and the claim of a systematic trade-off between change capability and overhead is not quantitatively supported. Table 3 similarly shows only mean memory deltas, with no spread, even though the runs used different garbage collectors (HotSpot GC versus Jikes RVM GC).
  3. [Section 4.2] The post-hoc exclusion of hsqldb for DAOP approaches and jython for DCEVM, justified only as 'possible performance gain is negligible,' is asymmetric and potentially biasing. Removing jython is particularly consequential because DCEVM shows 77.64% overhead there; excluding these benchmarks changes the aggregate pattern on which the 'DAOP lower overhead' conclusion rests. The full per-benchmark results should be reported, or a pre-defined, quantitative exclusion criterion should be given.
  4. [Section 3.2, Table 2] The update-duration comparisons in Table 2 are also confounded by the runtime differences noted above, and by tool limitations such as the statement that 'Jvolve comparison tool lacks functionality to detect change of class supertype alone.' Attributing Prose's 685.85 ms duration to 'bytecode manipulation with method inlining' versus Jooflux's 3.07 ms to 'call site switching using invokedynamic' is not a controlled comparison; at most, it characterizes the specific implementations, JDK versions, and helper tools tested, not the DAOP vs. mJVM concepts generally.
minor comments (5)
  1. [Abstract, throughout] The manuscript contains numerous typographical and grammatical errors, including 'res-ources' in the abstract, 'programing language' in Sections 1 and 2, and inconsistent comma usage; a thorough proofreading pass is needed.
  2. [Section 4.1] The authors correctly state that a universal change-description format is out of scope and that tests were manually adapted per approach. However, manual adaptation means that test equivalence across approaches is not independently verifiable; this should be identified explicitly as a threat to the validity of the cross-approach comparisons.
  3. [Table 2] The table uses asterisk symbols ('**', '***', '****') in the test column and cells, but the caption does not define all of them (the footnote explains 'indirectly supported' and 'partially supported' but the 'cannot be performed alone' symbol appears only in the table body). The caption should include a complete legend.
  4. [Section 4.2, Figure 5] Only one compound micro-benchmark (AM+MB) is used for the short-term and long-term modified-state overhead measurements, so the broad conclusion that 'modified state overhead and change duration depend on particular approach mechanisms' rests on a very narrow empirical basis. The y-axis label and the distinction between standard and DSU conditions in Figure 5 could also be clearer.
  5. [References] The reference list is inconsistent in formatting: some entries include DOIs or arXiv identifiers, others are bare technical reports, and at least one entry has a stray '$}$' artifact (reference [21]). The references should be unified and the artifact removed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper's comparisons rest on external DaCapo and custom micro-benchmark measurements, not on definitions or fitted parameters.

full rationale

This is an empirical benchmark and classification paper. The central claims (mJVM supports level-3 changes at higher steady-state/memory cost than DAOP level-2 approaches; Jooflux is cheapest but less capable) are supported by measurements of execution time, update duration, and memory usage on DaCapo 2006MR2 and custom micro-benchmarks. No parameter is fitted to the outcome being predicted, and no result is asserted by construction: the change categories (levels 1-3) are defined independently of the measured resource demands, and the overhead percentages are computed by comparing DSU-enabled environments with their own non-DSU baselines. The paper cites prior work and the authors' own earlier work (e.g., [15]) for background and adaptation techniques, but that material is not load-bearing for the empirical comparison. The possible cross-JVM confound (Jvolve on Jikes RVM with fast adaptive compiler versus HotSpot server compiler for the other approaches) is a serious validity threat to the comparative overhead conclusions, but it is a correctness/experimental-design concern, not circularity: the numbers are not derived from the conclusions. No circular step can be exhibited from the paper's text, so the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no free parameters or invented entities. Its conclusions rest on benchmark representativeness, on the non-confounded attribution of measured differences to the DSU concepts, and on the stability of the virtualized measurement environment.

assumptions (4)
  • domain assumption The DaCapo 2006MR2 benchmark suite provides representative real-world workloads for measuring steady-state overhead.
    The paper uses DaCapo to simulate common software usage scenarios (Section 4), but the suite is dated and only a subset of tests is reported.
  • domain assumption The four selected approaches (Prose, Jooflux, DCEVM, Jvolve) adequately represent the available Java DSU concepts.
    Section 4 states that public availability was the main selection criterion; pure JVM agent approaches are absent because none were publicly available.
  • domain assumption Measured differences in resource demands are attributable to the DSU approach rather than to differences in the JVM implementation or compiler configuration.
    Section 4 runs Jooflux, Prose, and DCEVM on HotSpot with the server compiler, but Jvolve on Jikes RVM with the fast adaptive compiler, and the appendix lists JDK 1.5, 1.7, and Jikes RVM 3.0.1.
  • domain assumption The virtualized environment (25% of a Xeon E5-2640, up to 8 GB RAM, Ubuntu 12.04) provides sufficient stability for timing measurements.
    Section 4 describes the environment; no error bars or variance metrics are displayed in the result figures.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Dynamic Software Updating in Java -- Comparing Concepts and Resource Demands." pith.science (2026). https://pith.science/paper/LAQOGK3M

@misc{pith2026250601875,
  author       = {Pith},
  title        = {Pith review of: Dynamic Software Updating in Java -- Comparing Concepts and Resource Demands},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LAQOGK3M}},
  note         = {Machine review of arXiv:2506.01875}
}
read the original abstract

Dynamic software updating (DSU) is an extremely useful feature to be used during the software evolution. It can be used to reduce downtime costs, for security enhancements, profiling and testing the new functionalities. There are many researches and solutions on dynamic software updating regarding diverse problems introduced by the topic, but there is a lack of research which compare various approaches concerning supported changes and demands on re-sources. In this paper we are comparing currently available con-cepts for Java programming language that deal with dynamically applied changes and impact of those changes on computer resource demands.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

31 extracted references · 31 canonical work pages

  1. [1]

    Ansaloni, D. et al. 2012. Dynamic Aspect -Oriented Programming in Java: The HotWave Experience. Transactions on Aspect-Oriented Software Development IX. G.T. Leavens et al., eds. Springer Berlin Heidelberg. 92 –122

    work page 2012

  2. [2]

    Bashar Gharaibeh et al. 2010. Towards Efficient Java Virtual Machine Support for Dynamic Deployment of Inter -type Declarations . Technical Report #321. Iowa State University

    work page 2010

  3. [3]

    Bierman, G. et al. 2008. UpgradeJ: Incremental Typechecking for Class Upgrades. ECOOP 2008 – Object-Oriented Programming: 22nd European Conference Paphos, Cyprus, July 7 -11, 2008 Proceedings. J. Vitek, ed. Spring- er Berlin Heidelberg. 235–259

    work page 2008

  4. [4]

    Blackburn, S.M. et al. 2006. The DaCapo Benchmarks: Java Benchmarking Development and Analysis. SIGPLAN Not. 41, 10 (Oct. 2006), 169–190

    work page 2006

  5. [5]

    Bockisch, C. et al. 2004. Virtual Machine Support for Dynamic Join Points. Proceedings of the 3rd International Conference on Aspect -oriented Software Development (New York, NY, USA, 2004), 83–92

    work page 2004

  6. [6]

    and Gross, T.R

    Cech Previtali, S. and Gross, T.R. 2011. Aspect -based Dynamic Software Updating: A Model and Its Empirical Evaluation. Proceedings of the Tenth In- ternational Conference on Aspect -oriented Software Development (New York, NY, USA, 2011), 105–116

    work page 2011

  7. [7]

    Chen, H. et al. 2007. POLUS: A POwerful Live Updating System. Software Engineering, 2007. ICSE 2007. 29th International Conference on (May 2007), 271–281

    work page 2007

  8. [8]

    Gharaibeh, B., Rajan, H., Chang, J.M. 2009. A quantitative cost/benefit analysis for dynamic updating. Iowa State University

    work page 2009

Show all 31 references
  1. [9]

    Gregersen, A. et al. 2014. State of the Art of Dynamic Software Updating in Java. Software Technologies . J. Cordeiro and M. van Sinderen, eds. Springer Berlin Heidelberg. 99–113

    2014

  2. [10]

    Gregersen, A.R. et al. 2009. Towards a Dynamic -update-enabled JVM. Pro- ceedings of the Workshop on AOP and Meta -Data for Software Evolution (New York, NY, USA, 2009), 2:1–2:7

    2009

  3. [11]

    and Jørgensen, B.N

    Gregersen, A.R. and Jørgensen, B.N. 2009. Dynamic Update of Java Applica- tions-Balancing Change Flexibility vs Programming Transparency. J. Softw. Maint. Evol. 21, 2 (Mar. 2009), 81–112

    2009

  4. [12]

    Gu, T. et al. 2012. Javelus: A Low Disruptive Approach to Dynamic Software Updates. Software Engineering Conference (APSEC), 2012 19th Asia -Pacific (Dec. 2012), 527–536

    2012

  5. [13]

    and Nettles, S

    Hicks, M. and Nettles, S. 2005. Dynamic Software Updating. ACM Trans. Program. Lang. Syst. 27, 6 (Nov. 2005), 1049–1096

    2005

  6. [14]

    JDPA Enhancements 1.4: https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/enhancements1.4.h tml#hotswap

  7. [15]

    and Fertalj, K

    Katic, M. and Fertalj, K. 2011. Model for Dynamic Evolution of Aspect - Oriented Software. Software Maintenance and Reengineering (CSMR), 2011 15th European Conference on (Mar. 2011), 377–380

    2011

  8. [16]

    Kiczales, G. et al. 2001. An Overview of AspectJ. Proceedings of the 15th European Conference on Object -Oriented Programming (London, UK, UK, 2001), 327–353

    2001

  9. [17]

    and Magee, J

    Kramer, J. and Magee, J. 1990. The evolving philosophers problem: dynamic change management. Software Engineering, IEEE Transactions on . 16, 11 (Nov. 1990), 1293–1306

    1990

  10. [18]

    and Swanson, E.B

    Lientz, B.P. and Swanson, E.B. 1980. Software Maintenance Management . Addison-Wesley Longman Publishing Co., Inc

    1980

  11. [19]

    Neamtiu, I. et al. 2006. Practical Dynamic Software Updating for C. SIGPLAN Not. 41, 6 (Jun. 2006), 72–83

    2006

  12. [20]

    Nicoara, A. et al. 2008. Controlled, Systematic, and Efficient Code Replace- ment for Running Java Programs. SIGOPS Oper. Syst. Rev. 42, 4 (Apr. 2008), 233–246

    2008

  13. [21]

    Payer, M. et al. 2013. DynSec: On -the-fly code rewriting and repair. Presented as part of the 5th Workshop on Hot Topics in Software Upgrades$}$ . (2013), 115–126

    2013

  14. [22]

    and Mouël, F.L

    Ponge, J. and Mouël, F.L. 2012. JooFlux: Hijacking Java 7 InvokeDynamic To Support Live Code Modifications. CoRR. abs/1210.1039, (2012)

    2012 arXiv

  15. [23]

    Popovici, A. et al. 2003. Just -In-Time Aspects: Efficient Dynamic Weaving for Java. In Proceedings of the 2nd international conference on Aspect -oriented software development (2003), 100–109

    2003

  16. [24]

    Pukall, M. et al. 2009. Flexible Runtime Program Adaptations in Java - A Comparison. Technical Report #14. School of Computer Science, University of Magdeburg

    2009

  17. [25]

    Pukall, M. et al. 2011. JavAdaptor: Unrestricted Dynamic Software Updates for Java. Proceedings of the 33rd International Conference on Software Engi- neering (New York, NY, USA, 2011), 989–991

    2011

  18. [26]

    Seifzadeh, H. et al. 2013. A survey of dynamic software updating. Journal of Software: Evolution and Process. 25, 5 (2013), 535–568

    2013

  19. [27]

    Stoyle, G. et al. 2007. Mutatis Mutandis: Safe and Predictable Dynamic Software Updating. ACM Trans. Program. Lang. Syst. 29, 4 (Aug. 2007)

    2007

  20. [28]

    Subramanian, S. et al. 2009. Dynamic Software Updates: A VM -centric Approach. SIGPLAN Not. 44, 6 (Jun. 2009), 1–12

    2009

  21. [29]

    Suvée, D. et al. 2003. JAsCo: An Aspect -oriented Approach Tailored for Component Based Software Development. Proceedings of the 2Nd Internation- al Conference on Aspect -oriented Software Development (New York, NY, USA, 2003), 21–29

    2003

  22. [30]

    Vandewoude, Y. et al. 2007. Tranquility: A Low Disruptive Alternative to Quiescence for Ensuring Safe Dynamic Updates. Software Engineering, IEEE Transactions on. 33, 12 (Dec. 2007), 856–868

    2007

  23. [31]

    Würthinger, T. et al. 2013. Unrestricted and safe dynamic code evolution for Java. Science of Computer Programming. 78, 5 (2013), 481–498

    2013

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.