[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Request for review 8005075: CDS archive with one alignment causes crash when run with different alig
From:       coleen.phillimore () oracle ! com (Coleen Phillimore)
Date:       2012-12-20 19:43:59
Message-ID: 50D36A7F.3020805 () oracle ! com
[Download RAW message or body]


I think this looks good.  The fail_continue should just stop using the 
shared archive if you have -Xshare:auto.  I believe it only prints a 
message and dies if you have -Xshare:on.   The default for server is 
-Xshare:off right now but someday it might be -Xshare:auto if we get the 
performance problems resolved. (-XX:+RewriteBytecodes is off for CDS and 
affects server performance)

Coleen

On 12/20/2012 01:53 PM, 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/20121220/f252cf99/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]