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.