United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6826736 CMS: core dump with -XX:+UseCompressedOops
JDK-6826736 : CMS: core dump with -XX:+UseCompressedOops

Details
Type:
Bug
Submit Date:
2009-04-06
Status:
Resolved
Updated Date:
2010-05-08
Project Name:
JDK
Resolved Date:
2009-07-29
Component:
hotspot
OS:
linux_suse_sles_10
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u14
Fixed Versions:
hs16 (b07)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
We get somewhat frequent process crashes with JDK 6_14 b04 running on x4100s -- by frequent, I mean that we are doing 24-hour stress tests, and we will get a failure maybe 20% of the time.

We never get an actual core file, though the hs_err file is attached (the error reported is always the same). I have been unable to reproduce this reliably, or with smaller heaps or less testing time. We have only observed this on our Linux machines (also are testing Solaris x86).

                                    

Comments
EVALUATION

Not reproducible under test conditions (shared machine lab) or with latest 6u14 fcs candidate.
                                     
2009-05-28
EVALUATION

The bug has resurfaced, albeit with lower frequency, in testing by submitter; hence reopening investigation.
                                     
2009-06-08
EVALUATION

The bug reproduces with not only CMS, but also UseParallelGC and (now, with compressed oops!) UseG1GC.
It is now believed that this is a compiler2 optimization issue perhaps related to 6851282.
                                     
2009-07-15
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5314d85ffd54
                                     
2009-07-23
SUGGESTED FIX

Fix deoptimization code and OopMapSet::all_do() to check for 
such oops values. During deoptimization convert them to NULL.
Ignore them and NULL oops for GC.
                                     
2009-07-23
PUBLIC COMMENTS

Problem:
Compiled code may produce decoded oop = narrow_oop_base
when a narrow oop implicit null check is used.
The narrow_oop_base could be NULL or be the address
of the page below heap depending on the used mode of
compressed oops. Such decoded oop could live across
a safepoint and as result referenced in oopMap and debug info.
The implicit NULL exception code checks for such oop value
but deoptimization code and GC does not. And this cause
the problem.

Solution:
Fix deoptimization code and OopMapSet::all_do() to check for 
such oops values. During deoptimization convert them to NULL.
Ignore them and NULL oops for GC.
                                     
2009-07-23
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/5314d85ffd54
                                     
2009-07-27



Hardware and Software, Engineered to Work Together