RFR: 8214512: Jtreg test compiler/c2/Test8062950.java fails on ARM32

Rahul Raghavan rahul.v.raghavan at oracle.com
Thu Dec 6 14:03:43 UTC 2018

[Just forwarding the below review request email to hotspot-compiler-dev, 
aarch32-port-dev mailing lists also]

-------- Forwarded Message --------
Subject: RFR: 8214512: Jtreg test compiler/c2/Test8062950.java fails on 
Date: Mon, 3 Dec 2018 06:06:47 +0000
From: Nick Gasson <Nick.Gasson at arm.com>
To: hotspot-dev at openjdk.java.net <hotspot-dev at openjdk.java.net>, Boris 
Ulasevich <boris.ulasevich at bell-sw.com>
CC: nd <nd at arm.com>


Could someone please help me review this fix for a test failure on ARM32:

Bug: https://bugs.openjdk.java.net/browse/JDK-8214512
Webrev: http://cr.openjdk.java.net/~njian/8214512/webrev.0/

This fixes two assertion failures related to biased locking when C2's
bias inlining feature is disabled (-XX:-OptoBiasInlining):

MacroAssembler::atomic_cas_bool takes three register arguments plus a
temporary register for use in the CAS loop. If the caller passes
`noreg' as this temporary register (which happens in the
!OptoBiasInlining call path from MacroAssembler::fast_lock) then
MacroAssembler::atomic_cas_bool will default to using LR as a
temporary. But it's possible with C2 that LR is one of the other three
arguments which then triggers an assert_different_registers assertion
failure. Fix this by supplying an additional scratch register to
MacroAssembler::fast_lock if !OptoBiasInlining.

In the !OptoBiasInlining case MacroAssembler::fast_lock calls
MacroAssembler::biased_locking_enter to handle the case where the mark
word contains the biased lock pattern which fast_lock wouldn't
otherwise see if OptoBiasInlining was true. However in the case that
we fail to acquire the biased lock this falls through to label
`failed' and runs the normal fast_lock code that implicitly assumes
the mark word does not have the bias pattern. This means we can end up
with a BasicLock where _displaced_header contains the biased lock
pattern which is an illegal state and subsequently triggers an
assertion failure in ObjectSynchronizer::fast_exit.

The right thing to do here is branch to `done' whenever the bias lock
pattern is present and let the runtime handle the failure case.  Also
edited the comment describing MacroAssembler::biased_locking_enter to
more accurately describe what it does (the comment about `slow_case'
being optional is wrong).

Jtreg test compiler/c2/Test8062950.java now passes on ARM32 with this


More information about the hotspot-compiler-dev mailing list