JDK-6767587 : missing call to make_not_entrant after deoptimizing for patching volatiles
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2008-11-05
  • Updated: 2010-12-08
  • Resolved: 2009-01-31
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
6u12Fixed 7Fixed hs11Fixed
Description
Hi Tom,

One question regarding deoptimization and C1: the StoreField and
LoadField code relies on deoptimization in case a load/store cannot be
determined to be volatile at compile time.

In the c1 runtime patch_code method, a VM_DeoptimizeFrame vm operation
is executed. What is puzzling me, is that when I follow the code of this
vm operation I don't find where the nmethod is made not entrant so that
the method will eventually be recompiled.

Indeed when I run this simple test:

public class TestDeopt {
   static class A {
	volatile int i;
   }

   static void m() {
	A a = new A();
	a.i = 0;
   }

   static public void main(String[] args) {
	m();
	m();
	m();
   }
}

With:
-client -Xcomp -XX:+PrintCompilation -XX:-Inline -XX:+TracePatching -XX:+TraceDeoptimization

I see the m method being compiled once but I see 3 "Deoptimizing for
patching volatile field reference" which proves that the compiled code
is not dropped.

Am I missing something?

Thanks,
Roland.

Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ac8fe14c93e4
13-12-2008

EVALUATION The fix for 6414800 is missing a call to make_not_entrant
05-11-2008