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

[Coleen Phillimore]

Harold, Thanks for fixing the hardcoded workaround in arguments. This 
looks good, especially the comments.
Can you realign the '\' in globals.hpp if they are not already.

*     product(uintx, SharedMiscDataSize,    NOT_LP64(2*M) LP64_ONLY(4*M),       \*
*!            "Size of the shareddata area adjacent to the heap  (in bytes)")   \*
*!            "Size of the shared_miscellaneous data area_  (in bytes)")   \*
*                                                                               \*
*     product(uintx, SharedMiscCodeSize,    120*K,                              \*
*!            "Size of the sharedcode area adjacent to the heap  (in bytes)")   \*
*!            "Size of the shared_miscellaneous code area_  (in bytes)")   \*
*                                                                               \

Thanks,
Coleen
*


On 1/3/2013 12:57 PM, harold seigel wrote:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130103/b7362a8c/attachment-0001.html