United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7028374 race in fix_oop_relocations for scavengeable nmethods
JDK-7028374 : race in fix_oop_relocations for scavengeable nmethods

Details
Type:
Bug
Submit Date:
2011-03-16
Status:
Closed
Updated Date:
2011-04-24
Project Name:
JDK
Resolved Date:
2011-04-24
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs21
Fixed Versions:
hs21 (b06)

Related Reports
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
I was getting ready to finish my statics fields in Class changes when I hit a failure with jbb and CMS.  I've tracked it down to a race in the machinery for updating oop relocations and the logic for making sure that a scavengable nmethod is only scanned once.  During a scavenge an nmethod can be reached for scanning in two different ways, either as a live activation on some thread stack or during the scan of scavengeable nmethods.  The scan of scavengeable nmethods does two things though.  It does the oops_do for the nmethod and then it calls fix_oop_relocations to update the generated code to match the new oop values.  The problem is that the scan of the thread stacks and the scan of the scavengable nmethods are performed concurrently so the stack scanning thread might claim the nmethod first but actually scan the nmethod after the call to fix_oop_relocations in the other thread, leaving the oops valid but the code stale.

I think the logical place to move the fix_oop_relocations call is into nmethod::oops_do_marking_epilogue.  Does this seem reasonable to anyone who understands the new nmethod scavenge code better than I do?  It seems to work fine.

                                    

Comments
EVALUATION

the description is correct.
                                     
2011-03-16
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/d673ef06fe96
                                     
2011-03-19
EVALUATION

7028374: race in fix_oop_relocations for scavengeable nmethods
Reviewed-by: kvn

In ScavengeRootsInCode mode oops could sometimes be udpated after
their relocations had been updated, resulting in stale oops in
generated code.  The fix is to move the rewriting of the relocations
to the epilogue part of the scavenge nmethods logic.  I also added
verification of the CodeCache which would have detected this problem
immediately.  The statics in Class changes will be laid on top of
these changes.  Tested with statics changes with jbb.
                                     
2011-03-22
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/d673ef06fe96
                                     
2011-03-25
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d673ef06fe96
                                     
2011-03-25
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d673ef06fe96
                                     
2011-03-25



Hardware and Software, Engineered to Work Together