RFR(XS) 8213250 CDS archive creation aborts due to metaspace object allocation failure
ioi.lam at oracle.com
Sat Nov 3 03:54:04 UTC 2018
Hi Calvin, thanks for the review.
On 11/2/18 12:30 PM, Calvin Cheung wrote:
> Hi Ioi,
> The revised webrev looks good.
> The following is removed from systemDictionaryShared.cpp:
> 831 log_info(cds, verification)("Recorded verification constraints
> for %d classes = %d bytes (avg = %.2f bytes) ", count, bytes, avg);
> Please make sure no test is expecting the above output.
I checked all CDS tests and there's no tests for that expects the above
> Line 790 in the same file is a bit too long, consider break it into 2
Done. I also broke the same line in
SystemDictionaryShared::add_verification_constraint into two lines.
> On 11/1/18, 9:47 PM, Ioi Lam wrote:
>> I've revised the webrev to get to the the root of the problem -- we
>> shouldn't allocate metaspace objects from within the VM Thread!
>> The original bug that caused the "!(DumpSharedSpaces &&
>> THREAD->is_VM_thread())" check to be added in Metaspace::allocate() was
>> UseAppCDS.java crashes with "VM thread using lock Heap_lock (not
>> allowed to block on)"
>> The fix in JDK-8196626 is just a band-aid solution -- avoiding the
>> GC. The proper fix is not to do any allocation inside the VM thread.
>> So instead of calling finalize_verification_constraints, which
>> allocates MetaspaceObjs, very late in the CDS dumping process, now we
>> call be as soon as a class has been verified.
>> - Ioi
>> On 11/1/18 11:07 AM, Ioi Lam wrote:
>>> When Metaspace::allocate() fails, usually we first try to GC to see if
>>> some MetaspaceObjs can be freed. This is an optimization to avoid
>>> expanding the metaspace.
>>> However, GC cannot run in the last phase of CDS which runs inside
>>> the VM thread.
>>> The old code just aborts the CDS dump. The fix is to unconditionally
>>> expand the
>>> metaspace without doing a GC.
>>> (During GC dump time, no classes are unloaded, so even if we force a
>>> GC, it would
>>> not free up any metaspace anyway).
>>> Before the fix, the test case (jruby) would fail to dump once a
>>> couple of times. Now
>>> it has dumped hundreds of times without failure.
>>> I am also running hs-tier 1/2
>>> - Ioi
More information about the hotspot-dev