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

Nick Gasson (Arm Technology China) Nick.Gasson at arm.com
Mon Dec 17 08:26:43 UTC 2018


Hi Dean,

> Would you like to add comments as suggested by Boris?  I think 
> it's a good idea.

Sure, I've updated the webrev here:

http://cr.openjdk.java.net/~njian/8214512/webrev.1/

Thanks,
Nick


On 17/12/2018 12:59, dean.long at oracle.com wrote:
> Thanks.  Would you like to add comments as suggested by Boris?  I think 
> it's a good idea.
> 
> dl
> 
> On 12/16/18 6:00 PM, Nick Gasson (Arm Technology China) wrote:
>>
>> Hi Dean,
>>
>> Sorry for the delay. This is submitted on behalf of ARM Ltd.
>>
>> Thanks,
>>
>> Nick
>>
>> *From:* dean.long at oracle.com <dean.long at oracle.com>
>> *Sent:* 13 December 2018 12:01
>> *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:* hotspot-compiler-dev at openjdk.java.net compiler 
>> <hotspot-compiler-dev at openjdk.java.net>; nd <nd at arm.com>; 
>> aarch32-port-dev at openjdk.java.net
>> *Subject:* Re: RFR: 8214512: Jtreg test compiler/c2/Test8062950.java 
>> fails on ARM32
>>
>> Nick, can you please confirm that you are covered under the
>>
>> · ARM Ltd. - OpenJDK, MySQL
>>
>>
>> OCA agreement?  I'm guessing Arm Technology China is under ARM Ltd., 
>> judging
>> by your email domain, but please confirm.
>>
>> dl
>>
>> On 12/11/18 5:30 PM, dean.long at oracle.com 
>> <mailto:dean.long at oracle.com> wrote:
>>
>>     I can help you commit it, but first I think another review would
>>     be good.
>>
>>     dl
>>
>>     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 <mailto:dean.long at oracle.com>
>>             <dean.long at oracle.com> <mailto:dean.long at oracle.com>
>>             Sent: 12 December 2018 06:05
>>             To: Nick Gasson (Arm Technology China)
>>             <Nick.Gasson at arm.com> <mailto:Nick.Gasson at arm.com>; hotspot-
>>             dev at openjdk.java.net <mailto:dev at openjdk.java.net>; Boris
>>             Ulasevich <boris.ulasevich at bell-sw.com>
>>             <mailto:boris.ulasevich at bell-sw.com>
>>             Cc: nd <nd at arm.com> <mailto:nd at arm.com>;
>>             hotspot-compiler-dev at openjdk.java.net
>>             <mailto:hotspot-compiler-dev at openjdk.java.net> compiler
>>             <hotspot-compiler-dev at openjdk.java.net>
>>             <mailto:hotspot-compiler-dev at openjdk.java.net>; aarch32-port-
>>             dev at openjdk.java.net <mailto: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 aarch32-port-dev mailing list