RFR: 8330027: Identity hashes of archived objects must be based on a reproducible random seed [v3]

[Ioi Lam]

On Thu, 18 Apr 2024 07:55:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> @iklam @calvinccheung could you take another look please?
> 
> I rewrote this patch to be both minimally invasive and as bulletproof against concurrent activity as possible.
> 
> My thoughts on this:
> 
> * just initializing the global seed of os::random with a constant makes the ihash vulnerable against concurrent calls to os::random in unrelated threads. At the minimum, it makes us vulnerable against the order of thread start and number of thread starts since each thread constructor did call os::random to init its ihash seed
> * My first patch version constified the ihash seed in the Thread constructor, but that still leaves us somewhat vulnerable against the same problem
> * This version - also the simplest in my opinion - makes ihash seed generation lazy, on-demand only, the first time a thread generates an ihash. That is the most robust version, since when dumping, only two threads ever generate ihashes - the initial java thread, and the VM thread. Since both run sequentially, not concurrently, the order of ihash generations is deterministic, and since we restrict the seed initialization to those threads that actually do generate ihashes, we can be reasonably safe of getting the same random numbers.

This PR doesn't help CDS in terms of making the contents of archived heap objects deterministic.

The dumping of archived heap objects is very sensitive to (Java thread) context switching: if two concurrent Java threads call `Object.identityHashcode()` on the same object, then the hashcode inside the header of this object will have deterministic values. We cannot easily recover from this with post-processing, as the shapes of the archived hashtables are influenced by the hashcode, and the CDS code doesn't know how to repack the hashtables in Java.

As a result, during `java -Xshare:dump`, we disable the launching of all new Java threads, so there's only a single (main) Java thread running the whole time

https://github.com/openjdk/jdk/blob/235ba9a7025964b1e43149c7102e26b82b2081ad/src/hotspot/share/prims/jvm.cpp#L2948-L2963

Even if we apply this PR, we still cannot run more than one Java thread. Conversely, if we stick to a single Java thread, then the complexity in this PR is not needed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18735#issuecomment-2064961679