JDK-6291370 : hs101t004 and hs101t006 hang due to biased locking
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-06-27
  • Updated: 2012-02-01
  • Resolved: 2005-07-20
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
6 b44Fixed
Description
The biased locking putback appears to have broken the following NSK tests:

    nsk/jvmti/scenarios/hotswap/HS101/hs101t004
    nsk/jvmti/scenarios/hotswap/HS101/hs101t006

Biased locking was putback to main/baseline on 2005.06.23 and sync'ed
into service_hs_baseline on 2005.06.24. The above two tests have hung
on almost every configuration since 2005.06.24.

I ran hs101t004 on producer using the same bits as nightly (Client VM)
in a 65 minute stress loop with a 10 minute job timeout. I observed
6 failures and no passes. When I added the -XX:-UseBiasedLocking option,
I observed 21 passes and no failures.

###@###.### 2005-06-27 23:26:00 GMT


I ran hs101t006 on producer using the same bits as nightly (Client VM)
in a 65 minute stress loop with a 10 minute job timeout. I observed
6 failures and no passes. When I added the -XX:-UseBiasedLocking option,
I observed 19 passes and no failures.

###@###.### 2005-06-28 02:19:09 GMT
###@###.### 2005-06-28 04:07:18 GMT
Comments
EVALUATION These hangs were caused by a poor choice of algorithm for revoking biased locks during deoptimization. When an nmethod is deoptimized, it is necessary to eagerly revoke the biases of all monitors in activations of that nmethod on all stacks so that the monitors can be migrated later. This change performs that revocation more efficiently than before and reverts the eviction loop in Deoptimization::deoptimize() to its state before biased locking was introduced. I wasn't able to reproduce the hangs as reported but definitely saw a large slowdown of these test cases which is gone with this fix. I believe this will also fix the hangs which have been seen in the runtime group's vm.full NSK runs, although I wasn't able to reproduce in isolation one of those which was reported. ###@###.### 2005-07-15 17:44:41 GMT
15-07-2005
SUGGESTED FIX http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050714112845.kbr.c2_baseline/workspace/webrevs/webrev-2005.07.14/index.html ###@###.### 2005-07-15 17:44:41 GMT
15-07-2005