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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Jan 3 09:28:12 PST 2013


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


More information about the hotspot-runtime-dev mailing list