[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8330027: Identity hashes of archived objects must be based on a reproducible random seed [v
From:       Ioi Lam <iklam () openjdk ! org>
Date:       2024-04-24 16:30:29
Message-ID: 3sAbwjT7ep_6mhXH7qUf1rP-3aT7LDb4lReCDehLLOc=.ea5078c7-e7e8-4714-967d-3a51b33044b2 () github ! com
[Download RAW message or body]

On Wed, 24 Apr 2024 15:39:26 GMT, Thomas Stuefe <stuefe@openjdk.org> wrote:

> > I think it's better to just not compute the identity hash inside the VM thread. \
> > Here's what I tried \
> > [iklam@ad95e2e](https://github.com/iklam/jdk/commit/ad95e2e8b00cb151617463af41648cdece2dfc7b)
> >  We thought that forcing the identity hash computation would increase sharing \
> > across processes, as it would mean fewer updates of the object headers during run \
> > time. However, most of the heap objects in the CDS archive are not accessible by \
> > the application (they are part of the archived module graph, etc). Also the \
> > archive contains a large number of Strings, which are unlikely to need the \
> > identity hash (String has its own hashcode() method). Since the reason is rather \
> > dubious, I think it's better to remove it and simplify the system.
> 
> I like that, that is simpler. Okay, then we will only call ihash from a single \
> thread, so a global constant seed should be fine. I should be able to assert that, \
> right?

AI think an assert can be added, since we don't allow any Java threads to be \
launched. So even test cases that run arbitrary Java code during -Xshare:dump (using \
Java agents of -XX:ArchiveHeapTestClass) will not be able to run any Java code \
outside of the main Java thread.

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

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


[prev in list] [next in list] [prev in thread] [next in thread]