RFR: 8330027: Identity hashes of archived objects must be based on a reproducable random seed

[Thomas Stuefe]

On Thu, 11 Apr 2024 09:24:16 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 or by the changes of [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.

> > > Do we need to generate I-hash on archive generation at all?
> > 
> > 
> > Yes, see https://github.com/openjdk/jdk/blob/087e8e7f3b2d87e6dc3c4e1c49eff7bae88f1e4f/src/hotspot/share/cds/archiveHeapWriter.cpp#L532
> 
> I get that we need to _preserve_ I-hashed. But why do we ever have to generate any new ones?

That is an excellent question, and here is what I understand:

- The comment states we want to minimize the chance of runtime writes to the archived objects. I assume we do this to prevent COW on that page, such that we have the maximum effect of memory sharing between processes using the same archive.
- But this relies on archive heap region mapping not needing relocation. If we relocate, we touch every object anyway. You only avoid relocation if you manage to map at the same address. 
- The loading code [1] seems to indicate that the CDS heap region is always allocated at the end of the heap (note that we ignore the "preferred_addr" argument). Therefore, we only get the same address iff the heap has the same size and starts at the same address as at dump time. The chances of that are there, but not great, since default heap size depends on context at runtime.
- All of that is moot anyway since, with JDK-8294323, we started forcing relocation due to security reasons.

Therefore I think we don't have to actively generate ihashes.

@iklam What do you think?

[1] https://github.com/openjdk/jdk/blob/16061874ffdd1b018fe1cad7e6d8ba8bdbdbbee1/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L488

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

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