RFR: 8028498: runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java asserts in RT_Baseline

[Stefan Johansson]

Hi again =)

Don't spend time on the current webrev (02). I've gotten some more 
comments on the proposed fix and will look at a solution that allow us 
to remove the GC locker usage during initialization.

Cheers,
Stefan

On 2014-02-10 18:51, Stefan Johansson wrote:
> Hi again,
>
> 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.
>
> New webrev:
> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.01/
>
> Thanks,
> Stefan
>
> On 2014-01-29 14:54, Stefan Johansson wrote:
>> Hi,
>>
>> Please review this fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8028498
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sjohanss/8028498/webrev.00/
>>
>> Summary:
>> 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.
>>
>> Testing:
>> * 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
>>
>> Cheers,
>> Stefan
>