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

[Stefan Johansson]

Thanks for looking at this Coleen,

So you would prefer us to have some heap setting that "should always 
work" and apply that if we see that DumpSharedSpaces is true? I'm not 
sure which solution I like best but I can take a look at it tomorrow and 
see how such a solution would work.

Stefan

On 2014-01-29 17:07, Coleen Phillimore wrote:
>
> Stefan,
>
> I think you should go the other way.  If DumpSharedSpaces, ignore 
> options for NewSize etc and still create the archive.
>
> Coleen
>
> On 1/29/14 8:54 AM, 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
>