review for 7157141: crash in 64 bit with corrupted oops

[Vladimir Kozlov]

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
>>>
>