JDK-8145606 : [TESTBUG] MonitorInflationTest.java should be rewritten to be more predictable
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2015-12-16
  • Updated: 2016-01-28
  • Resolved: 2015-12-24
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 9
9 b103Fixed
Related Reports
Relates :  
JDK-8145587 - MonitorInflationTest fails with 'Deflating object ' missing from stdout/stderr
Description
As of this version:

http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/8c188166869d/test/runtime/logging/MonitorInflationTest.java

$ java -Xlog:monitorinflation=debug -version 
[0.129s][debug ][monitorinflation] Inflating object 0x0000000411006db0 , mark 0x00007f6760002c02 , type java.lang.ref.Reference$Lock 
[0.129s][debug ][monitorinflation] Inflating object 0x00000004110078b0 , mark 0x00007f6760004c02 , type java.lang.Object 
[0.144s][debug ][monitorinflation] Inflating object 0x000000041100b1a0 , mark 0x00007f6760004b02 , type java.lang.ref.ReferenceQueue$Lock 
java version "9-internal" 
Java(TM) SE Runtime Environment (build 9-internal+0-2015-12-15-132951.iklam.jdk9rt) 
Java HotSpot(TM) 64-Bit Server VM (build 9-internal+0-2015-12-15-132951.iklam.jdk9rt, mixed mode) 
[0.226s][debug ][monitorinflation] Deflating object 0x00000004110078b0 , mark 0x00007f6760004c02 , type java.lang.Object 

The test assums that when running "java -version", some locks must have been inflated and at least one monitor must have been deflated. The single deflation, in the above output, is for the monitor that has been previously inflated here: 

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007ffff040d000 nid=0x7976 runnable [0x00007ffecfb80000] 
   java.lang.Thread.State: WAITING (on object monitor) 
   JavaThread state: _thread_in_vm 
Thread: 0x00007ffff040d000 [0x7976] State: _running _has_called_back 0 _at_poll_safepoint 0 
   JavaThread state: _thread_in_vm 
 1 - frame( sp=0x00007ffecfb80590, unextended_sp=0x00007ffecfb80590, fp=0x00007ffecfb805e8, pc=0x00007fffdd7b0898) 
java.lang.Object.wait(Native Method) 
 2 - frame( sp=0x00007ffecfb805f8, unextended_sp=0x00007ffecfb80608, fp=0x00007ffecfb80660, pc=0x00007fffdd7924f3) 
java.lang.Object.wait(Object.java:516) 
 3 - frame( sp=0x00007ffecfb80670, unextended_sp=0x00007ffecfb80670, fp=0x00007ffecfb806c8, pc=0x00007fffdd7924f3) 
sun.misc.VM.awaitBooted(VM.java:175) 
 4 - frame( sp=0x00007ffecfb806d8, unextended_sp=0x00007ffecfb806e8, fp=0x00007ffecfb80728, pc=0x00007fffdd7924f3) 
java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:208) 

But this is really JDK internal implementation code, and could change. In fact, it has changed in the latest jake repo (the VM.awaitBooted) method has been removed. 

We need to rewrite the test case to perform specific actions to ensure that monitor are inflated and/or deflated, without no dependency on internal JDK implementations.
Comments
I suggested that simple "java -version" was sufficient because it did show the inflation and deflation. I didn't examine the exact monitors involved to see if they might someday not be inflated/deflated. It is easy to inflate a monitor - just call Object.wait. However deflation has to rely on the usual ugly System.gc() loops that we hope go long enough to force an internal action we can't otherwise directly control.
17-12-2015