RFR: 8028498: runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java asserts in RT_Baseline
stefan.johansson at oracle.com
Mon Feb 10 09:51:21 PST 2014
After a couple of offline discussions with different people I've come to
the conclusion to split out the sizing of the young generation from the
fix for this issue. I've created a new bug (JDK-8033426) for that, which
is currently out for review.
The discussions also lead to a different approach for fixing this issue.
The new proposal is to use the GC locker to prevent GCs until we are
ready to handle them and otherwise fail the VM initialization. The gc
locker has two different mechanisms for locking out the GC, one which is
used during initialization and one used to stall GCs when doing critical
JNI work. The part of the initialization that currently is locked by the
GC locker is to narrow and there is no guarantee that a GC can be
handled after the GC locker is unlocked. This fix will extend the part
that is locked and also add a check that if a GC is initiated while
locked during startup the VM exits.
On 2014-01-29 14:54, Stefan Johansson wrote:
> Please review this fix for:
> The initial young generation size has been fairly small by default
> (1.5M) and if setting ObjectAlignmentInBytes to something larger than
> the default it can causes CDS to trigger a GC when dumping the
> archive. At this point the VM is not ready to handle a GC and we will
> hit an assertion. Making sure we can handle a GC at this point is not
> trivial and the proposed solution is to alter the default sizing of
> the young generation as well as adding a safety check when dumping the
> archive to exit the VM if the young generation is too small.
> * JPRT build and test passes
> * Failing test now passes on all platforms (tested throught JPRT)
> * Verified that the GC and Runtime jtreg tests still passes
More information about the hotspot-dev