CDS narrow Klass handling plays a role for archived heap objects.
When dumping heap objects, we must recompute their narrow Klass ids since the relative positions of archived Klass instances change compared to their live counterparts in the dump time JVM.
We recompute those narrow Klass ids using the following encoding scheme:
- base = future assumed mapping start address
- shift = dump time (!) JVMs encoding shift (A)
see ArchiveHeapWriter::update_header_for_requested_obj
At CDS runtime, we load the CDS archive, then place the class space behind it. We then initialize narrow Klass encoding for the resulting combined Klass range such that:
- encoding base is the range start address (mapping base)
- encoding shift is always zero
see CompressedKlassPointers::initialize
At dump time, when initializing the JVM, we also set the encoding base to klass range start and shift to zero (also CompressedKlassPointers::initialize). That is the shift we later use for (A); hence, that shift is zero.
---
There are some small things wrong with the current code. That wrongness does not lead to errors but makes understanding the code difficult.
Mainly, the dump time VM's narrow Klass encoding scheme is irrelevant for the encoding employed on the future runtime archive since we recalculate the narrow Klass ids for archived heap objects. That means:
In CompressedKlassPointers::initialize there is no need to fix the encoding base and shift for the dump time JVM. Dump time JVM can use whatever base+shift it pleases; it can use the same code path as when CDS is off (e.g. use zero-based encoding).
In ArchiveHeapWriter::update_header_for_requested_obj, we should not use the dump time JVM shift for pre-computing the narrow Klass ids. Instead, we should use the minimal shift needed for the maximal possible future Klass range size. The comment in ArchiveHeapWriter explains this in greater detail. Thankfully, that minimal shift is exactly zero in today's hotspot.
Similarly, we should not save the dump time JVMs encoding shift as the "narrow Klass shift" into the archive, but the one we use for pre-computing the narrow Klass ids.
When dumping heap objects, we must recompute their narrow Klass ids since the relative positions of archived Klass instances change compared to their live counterparts in the dump time JVM.
We recompute those narrow Klass ids using the following encoding scheme:
- base = future assumed mapping start address
- shift = dump time (!) JVMs encoding shift (A)
see ArchiveHeapWriter::update_header_for_requested_obj
At CDS runtime, we load the CDS archive, then place the class space behind it. We then initialize narrow Klass encoding for the resulting combined Klass range such that:
- encoding base is the range start address (mapping base)
- encoding shift is always zero
see CompressedKlassPointers::initialize
At dump time, when initializing the JVM, we also set the encoding base to klass range start and shift to zero (also CompressedKlassPointers::initialize). That is the shift we later use for (A); hence, that shift is zero.
---
There are some small things wrong with the current code. That wrongness does not lead to errors but makes understanding the code difficult.
Mainly, the dump time VM's narrow Klass encoding scheme is irrelevant for the encoding employed on the future runtime archive since we recalculate the narrow Klass ids for archived heap objects. That means:
In CompressedKlassPointers::initialize there is no need to fix the encoding base and shift for the dump time JVM. Dump time JVM can use whatever base+shift it pleases; it can use the same code path as when CDS is off (e.g. use zero-based encoding).
In ArchiveHeapWriter::update_header_for_requested_obj, we should not use the dump time JVM shift for pre-computing the narrow Klass ids. Instead, we should use the minimal shift needed for the maximal possible future Klass range size. The comment in ArchiveHeapWriter explains this in greater detail. Thankfully, that minimal shift is exactly zero in today's hotspot.
Similarly, we should not save the dump time JVMs encoding shift as the "narrow Klass shift" into the archive, but the one we use for pre-computing the narrow Klass ids.
- relates to
-
JDK-8312392 ARM32 build broken since 8311035
- Resolved