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

List:       openjdk-hotspot-compiler-dev
Subject:    Request for review (S): CR 6889740 - G1: OpenDS fails with "unhandled exception in compiled code"
From:       Thomas.Rodriguez () Sun ! COM (Tom Rodriguez)
Date:       2009-10-29 20:52:42
Message-ID: 57030A29-818D-48FB-8AD2-977A34C6F8A0 () sun ! com
[Download RAW message or body]

looks good.

tom

On Oct 28, 2009, at 1:58 PM, john cuthbertson - Sun Microsystems wrote:

> Hi Everyone,
>
> I've tweaked the change based on feedback from Christian and Tom.  
> The new webrev can be found here:
>
> http://cr.openjdk.java.net/~johnc/6889740/webrev.1/
>
> Regards,
>
> JohnC
>
> On 10/27/09 14:51, john cuthbertson - Sun Microsystems wrote:
>> Hi Everyone,
>>
>> Can I have a couple of volunteers to review the proposed fix for  
>> this bug? The webrev can be found at http://cr.openjdk.java.net/~johnc/6889740/webrev.0/ 
>> .
>>
>> The issue is that bad code was being generated for the store  
>> operation in the null case of the aastore bytecode template. The  
>> bad code was caused by there being only one version of the  
>> store_heap_oop routine that took a Register as the second argument.  
>> When the calling code passed in NULL_WORD (0) to this routine the  
>> value was used as a Register encoding and converted to Register(0),  
>> which is rax. Thus the generated store was "mov (dst), $rax"  
>> instead of "mov (dst), $0x0". This is normally not a problem as the  
>> preceding code in the template fetches the value to be stored into  
>> rax. When the G1 pre-barrier code calls the runtime, however, the  
>> value in rax can be overwritten and the heap can become corrupted.
>>
>> Testing: OpenDS, jprt, refworkload, and the GC test suite.
>>
>> Thanks,
>>
>> JohnC
>


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

Configure | About | News | Add a list | Sponsored by KoreLogic