United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8012715 G1: GraphKit accesses PtrQueue::_index as int but is size_t
JDK-8012715 : G1: GraphKit accesses PtrQueue::_index as int but is size_t

Details
Type:
Bug
Submit Date:
2013-04-19
Status:
Resolved
Updated Date:
2013-05-14
Project Name:
JDK
Resolved Date:
2013-04-25
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs24,hs25
Fixed Versions:
hs25 (b31)

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2013-April/010299.html

Hi all,
 
we found a bug in the G1 barriers generated by the C2 compiler.
 
In graphKit INT operations were generated to access PtrQueue::_index which
has type size_t. This is 64 bit on 64-bit machines. No problems occur on
little endian machines as long as the index fits into 32 bit, but on
big endian machines the upper part is read, which is zero. This leads
to unnecessary branches to the slow path into the runtime.
 
The fix introduces X operations where INT was used:
http://cr.openjdk.java.net/~goetz/webrevs/g1-size_t_bug/
 
This also removes a cast node.
 
We have also added a type T_X in globalDefinitions.hpp. Is there
already a mechanism to express this?
 
Please supply a bug id and review this change.
 
Best regards,
Martin
                                    

Comments
Just reviewed proposed fix from Martin Doerr at SAP.
                                     
2013-04-23
URL:   http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/d50cc62e94ff
User:  johnc
Date:  2013-04-25 07:10:26 +0000

                                     
2013-04-25
URL:   http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d50cc62e94ff
User:  amurillo
Date:  2013-05-03 18:40:10 +0000

                                     
2013-05-03
A regression test for this issue is hard since the issue only causes a problem on big endian machines and only then the symptom is unnecessary calls to the JVM runtime barrier code. 
                                     
2013-05-07



Hardware and Software, Engineered to Work Together