Request for review 8005075: CDS archive with one alignment causes crash when run with different alignment

harold seigel harold.seigel at
Tue Dec 18 13:34:17 PST 2012

Hi Vladimir,

A bigger original alignment is okay because alignment values must be 
powers of 2.  This means that bigger alignments will always be multiples 
of smaller alignments.  So, a bigger aligned object will also meet the 
requirements of a smaller alignment.  For example, if the bigger 
alignment is 32 then the smaller alignment must be either 8 or 16.  And, 
a 32 byte aligned object is also 8 and 16 byte aligned.


On 12/18/2012 3:01 PM, Vladimir Kozlov wrote:
> Recording ObjectAlignmentInBytes in CDS is good. Thank you for doing it.
> My question is why bigger original alignment is fine? I thought CDS 
> works only when it is exactly the same.
> Thanks,
> Vladimir
> On 12/17/12 7:23 AM, harold seigel wrote:
>> Please review the following change to fix bug 8005075.
>> Summary:  This change prevents a crash when a CDS archive is created
>> with a value for -XX:+ObjectAlignmentInBytes that is smaller than the
>> ObjectAlignmentInBytes value used when running with -Xshare:on. This fix
>> stores the ObjectAlignmentInBytes in the CDS archive so that when the
>> archive is read, hotspot can compare the archive's alignment with the
>> current alignment and issue the following diagnostic if the archive's
>> alignment is too small:
>>     An error has occurred while processing the shared archive file.
>>     The shared archive file was created with a smaller Object Alignment
>>     value.
>> This webrev also cleans up some text in globals.hpp and fixes a small
>> problem with -XX:SharedReadOnlySize.  The existing code was always
>> setting SharedReadOnlySize to 14M regardless of what was requested.
>> This prevented users from being able to expand the CDS archive's
>> SharedReadOnly section.
>> Open webrev at
>> <>
>> Bug link at
>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and with
>> hand-run tests using different ObjectAlignmentInBytes values.
>> Thanks, Harold

More information about the hotspot-runtime-dev mailing list