Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8275867

Make ImmutableCollections deterministic if running with TraceBytecodes/StopInterpreterAt



    • Enhancement
    • Resolution: Won't Fix
    • P4
    • tbd
    • None
    • hotspot
    • 9


      HotSpot provides the command line options `TraceBytecodes` and `StopInterpreterAt` which can be quite handy when debugging some issues which occur very early during VM strartup.

      Unfortunately, JDK-8139233 randomized the iteration order of immutable collections which are used quite early (starting around bytecode ~600). This can change the absolute execution index of subsequent bytecodes significantly (e.g. the index of the applications main method which is executed around bytecode 130_000 can vary by up to 100 bytecodes). Obviously, this behavior also makes the `StopInterpreterAt`option almost useless.

      I therefor propose to introduce a new diagnost JVM flag (e.g. `-XX:+DeterministicVMStartup`) which suppresses the iteration randomization of `ImmutableCollections`. The option will be off by default to not change the current behavior and only be activated if the user sets `TraceBytecodes` or `StopInterpreterAt`.

      I can imagine that apart from HotSpot debugging, this option can also be useful for debugging Java programs which use immutable collections.

      The reason why I propose to fix this issue in the VM instead of fixing it in the class library (e.g. with the help of a property) is that the static initializer of `ImmutableCollections` already calls into the VM anyway in order to initialize its salt value. This is required because CDS/`-Xshare:dump` also requires a deterministic iteration order to guarantee reproducible builds (JDK-8241071). Fixing this in the VM also makes it easier to fix `TraceBytecodes`/`StopInterpreterAt` in a simple way.


        Issue Links



              simonis Volker Simonis
              simonis Volker Simonis
              0 Vote for this issue
              7 Start watching this issue