JDK-8012715 : G1: GraphKit accesses PtrQueue::_index as int but is size_t
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs24,hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-04-19
  • Updated: 2013-09-18
  • Resolved: 2013-04-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
JDK-8013171 - G1: C1 x86_64 barriers use 32-bit accesses to 64-bit PtrQueue::_index
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
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.
07-05-2013
Just reviewed proposed fix from Martin Doerr at SAP.
23-04-2013