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

dean.long at oracle.com dean.long at oracle.com
Wed Dec 12 01:30:29 UTC 2018

I can help you commit it, but first I think another review would be good.


On 12/11/18 5:15 PM, Nick Gasson (Arm Technology China) wrote:
>> Hi Nick.  This change looks good to me.
> Thanks Dean. Could you help me to commit this patch if it doesn't need other reviews?
> Nick
>> -----Original Message-----
>> From: dean.long at oracle.com <dean.long at oracle.com>
>> Sent: 12 December 2018 06:05
>> To: Nick Gasson (Arm Technology China) <Nick.Gasson at arm.com>; hotspot-
>> dev at openjdk.java.net; Boris Ulasevich <boris.ulasevich at bell-sw.com>
>> Cc: nd <nd at arm.com>; hotspot-compiler-dev at openjdk.java.net compiler
>> <hotspot-compiler-dev at openjdk.java.net>; aarch32-port-
>> dev at openjdk.java.net
>> Subject: Re: RFR: 8214512: Jtreg test compiler/c2/Test8062950.java fails on
>> ARM32
>> Hi Nick.  This change looks good to me.
>> dl
>> On 12/2/18 10:06 PM, Nick Gasson wrote:
>>> Hi,
>>> 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
>>> patch.
>>> Thanks,
>>> Nick

More information about the hotspot-compiler-dev mailing list