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

[Thomas Stuefe]

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

>> CDS archive contains archived objects with identity hashes.
>> 
>> These hashes are deliberately preserved or even generated during dumping. They are generated based on a seed that is initialized randomly on a per-thread basis. These generations precede CDS dump initialization, so they are not affected by the init_random call there, nor would they be affected by [JDK-8323900](https://bugs.openjdk.org/browse/JDK-8323900).
>> 
>> A random seed will not work for dumping archives since it prevents reproducible archive generation. Therefore, when dumping, these seeds must be initiated in a reproducible way.
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final version

@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.

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

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