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

List:       openjdk-hotspot-gc-dev
Subject:    review for 7157141: crash in 64 bit with corrupted oops
From:       vladimir.kozlov () oracle ! com (Vladimir Kozlov)
Date:       2012-03-28 15:24:56
Message-ID: 4F732D48.3080102 () oracle ! com
[Download RAW message or body]

On 3/28/12 8:06 AM, Tom Rodriguez wrote:
> 
> On Mar 27, 2012, at 10:14 PM, Vladimir Kozlov wrote:
> 
> > Tom,
> > 
> > Can you put parenthesis around Card table start, end addresses output to indicate \
> > that it is range?
> 
> I'll add that.
> 
> > Should we also remove relocation from far polling page code in MachEpilogNode and \
> > safePoint_poll_far?
> 
> The one in poll_far needs it because it's the actual trapping instruction for the \
> poll.  The lea one is benign since the relocation is only performed if the polling \
> page isn't far and the lea is only used if it is far.  The reason the card table \
> confusion got us into trouble was because we emitted the lea form in the \
> loadConP_poll when it wasn't far.  Since I'd like to try to get this into 7u4, I \
> don't want to change too much.  There are some other things I'd like to clean up so \
> I'd like to delay that for now.

OK.

Thanks,
Vladimir

> 
> tom
> 
> > 
> > Vladimir
> > 
> > On 3/27/12 9:32 PM, Tom Rodriguez wrote:
> > > http://cr.openjdk.java.net/~never/7157141
> > > 39 lines changed: 18 ins; 19 del; 2 mod; 24524 unchg
> > > 
> > > 7157141: crash in 64 bit with corrupted oops
> > > Reviewed-by:
> > > 
> > > The fix for 6964776 introduced a new match pattern for cases where the
> > > polling page is far from the code cache and must be materialized as a
> > > 64 bit value.  In the very rare case that the byte_map_base for the
> > > card table and the polling page end up at the same address it's
> > > possible for this code to incorrectly trigger when emitting card mark
> > > code, resulting in incorrect card marks.  It requires a bit of a
> > > confluence of events since the OS has to hand out unlucky values for
> > > the card table and polling page and C2 has to emits the unlucky
> > > sequence as well.  Changing the heap size would cause those values to
> > > change and the problem to disappear. -XX:+VerifyRememberedSets finds
> > > the issue fairly quickly.  The issue is new in JDK7/hs21 and only
> > > occurs on x64.  The simplest fix is to simply remove the special
> > > handling of immP_poll and allow the poll page to be handled just like
> > > any other constant when it can't be handled as a RIP relative value.
> > > Tested with failing program from original report and runthese with and
> > > without -XX:+ForceUnreachable to exercise the new path.
> > > 
> > > I also added some code to dump the card table space, byte_map_base and
> > > polling page in the hs_err.  The output looks like this:
> > > 
> > > Heap
> > > PSYoungGen      total 39424K, used 675K [0xfffffd7fcc000000, \
> > > 0xfffffd7fcec00000, 0xfffffd7ff6c00000) eden space 33792K, 2% used \
> > > [0xfffffd7fcc000000,0xfffffd7fcc0a8fc8,0xfffffd7fce100000) from space 5632K, 0% \
> > > used [0xfffffd7fce680000,0xfffffd7fce680000,0xfffffd7fcec00000) to   space \
> > > 5632K, 0% used [0xfffffd7fce100000,0xfffffd7fce100000,0xfffffd7fce680000) \
> > > ParOldGen       total 86016K, used 0K [0xfffffd7f76c00000, 0xfffffd7f7c000000, \
> > > 0xfffffd7fcc000000) object space 86016K, 0% used \
> > > [0xfffffd7f76c00000,0xfffffd7f76c00000,0xfffffd7f7c000000) PSPermGen       \
> > > total 22528K, used 2754K [0xfffffd7f71a00000, 0xfffffd7f73000000, \
> > > 0xfffffd7f76c00000) object space 22528K, 12% used \
> > > [0xfffffd7f71a00000,0xfffffd7f71cb0b38,0xfffffd7f73000000) 
> > > Card table byte_map: 0xfffffd7f71200000,0xfffffd7f7162a000 byte_map_base: \
> > > 0xff7ffd80b1673000 
> > > Polling page: 0xfffffd7fff170000
> > > 
> 


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