RFR: 8228581: Archive BigInteger constants
jianglizhou at google.com
Wed Jul 24 20:38:01 UTC 2019
On Wed, Jul 24, 2019 at 1:06 PM Claes Redestad
<claes.redestad at oracle.com> wrote:
> 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?
There are three existing design docs related to this area. They
- GC (G1) Archive heap regions, closed archive region and open archive region
- Archive object state transition
- Targeted static field pre-initialization and caching using object
- Archived mirror (j.l.Objects) objects, Strings, etc.
I don't have the internal links to those docs. I can help update the
docs once they are moved to the OpenJDK wiki.
> 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
> This patch could probably be improved by moving everything but the
> initialPowerCache to the closed archive region..
More information about the core-libs-dev