RFR: 8228581: Archive BigInteger constants

[Claes Redestad]

Hi Joe, Jiangli,

On 2019-07-24 21:54, Jiangli Zhou wrote:
> On Wed, Jul 24, 2019 at 12:41 PM Joe Darcy <joe.darcy at oracle.com> wrote:
>>
>> Hi Claes,
>>
>> For those of us unfamiliar with the archive mechanism, can you describe
>> its semantics or send a pointer to such a description?
> 
> That's a good point. There are some design docs describing how Java
> objects and object graphs archiving work. It might be good to put
> those in OpenJDK wiki.
> 
> Best regards,
> Jiangli

getting the design up on the wiki would be great! Do you have a pointer
to the docs and/or time to work on this?

Quick outline of my understanding:

effectively at time of -Xshare:dump, the contents of the static fields
listed in heapShared.cpp will be serialized to the base CDS archive,
.e., lib/classes.jsa, and on VM.initializeFromArchive the serialized
heap state of the object graph will be mapped in, if possible.

There are closed and open archive regions, and the rules differ somewhat
between them.

Objects archived in closed archive regions must be effectively
immutable. Some mutable operations like synchronizing on objects are
allowed, but GCs are allowed to ignore these regions, so if you wrote to
a reference field pointing to something on the regular heap, you'd
not be strongly referencing that object, and this might be disastrous.
If you try to put things into the closed archive that are not
fully immutable (not all fields are final etc), you'll get a lot of
warnings to this effect.

Open regions additionally allow writing to reference fields and
referencing objects on the "regular" heap, so objects in such regions
must be scanned by GCs as if they were a "normal" heap region. The
powerCache field in this example, which is volatile, should be
acceptable.

This patch could probably be improved by moving everything but the
initialPowerCache to the closed archive region..

/Claes