JDK-6716785 : implicit null checks not triggering with CompressedOops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs13,6u6p
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,linux_suse_sles_10
  • CPU: x86
  • Submitted: 2008-06-19
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7 Other
6u14Fixed 7Fixed hs13Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
See comments.

EVALUATION This fix has been checked in for both hs13 (snapshot for b03) and in hs14.

EVALUATION Add code to allocate extra space for java heap (either 1 page or alignment) and unprotect so that implicit null exceptions at heap_base + 1 page fault.

SUGGESTED FIX The ultimate fix should be in runtime, in the short term we may want to have some variant of -UseImplicitNullChecks for narrow oops in C2.

EVALUATION Implict null checks under CompressedOops are not triggering a change on control flow. It appears that the heap_base+1 page is still writeable, so the generated code does not SEGV as expected.