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

[harold seigel]

It is 8005076.   The 8005075 was a typo.

Thanks, Harold

On 1/3/2013 12:28 PM, Vladimir Kozlov wrote:
> Looks good.
>
> So it is 8005075 (as in Subject) or 8005076 (as in webrev) bug?
>
> Thanks,
> Vladimir
>
> On 12/20/12 10:53 AM, harold seigel wrote:
>> Hi,
>>
>> Based on Vladimir's comments, I changed the code to require that both
>> alignments need to be the same.  Here's an example of the modified
>> diagnostic:
>>
>>     The shared archive file's ObjectAlignmentInBytes of 16 does not
>>     equal the current ObjectAlignmentInBytes of 8.
>>
>> Please review this latest change at:
>> http://cr.openjdk.java.net/~hseigel/bug_8005076_3/
>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8005076_3/>
>>
>> Thank you,
>> Harold
>>
>>
>> On 12/18/2012 5:24 PM, Vladimir Kozlov wrote:
>>> But different alignment will require different encoding with
>>> compressed oops. How you solve that?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 12/18/12 1:34 PM, harold seigel wrote:
>>>> 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.
>>>>
>>>> Harold
>>>>
>>>> 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 http://cr.openjdk.java.net/~hseigel/bug_8005076/
>>>>>> <http://cr.openjdk.java.net/%7Ehseigel/bug_8005076/>
>>>>>>
>>>>>> Bug link at http://bugs.sun.com/view_bug.do?bug_id=8005076
>>>>>>
>>>>>> The changes were tested with JCK, JPRT, JTREG, and UTE tests, and 
>>>>>> with
>>>>>> hand-run tests using different ObjectAlignmentInBytes values.
>>>>>>
>>>>>> Thanks, Harold