[aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading

Fri Mar 27 15:32:53 UTC 2020

Thanks, that's great. It's great we have two GCs able to exercise the new barrier.

On 27/03/2020 15:30, Zhengyu Gu wrote:
> Hi Stuart,
>
> Yes, this is the same problem I saw. I filed JDK-8241765, will RFR once it passes all tests.
>
> Thanks,
>
> -Zhengyu
>
> On 3/27/20 11:28 AM, Stuart Monteith wrote:
>> Hello Zhengyu,
>>          That is the same test I had trouble with.
>>
>> One of the stack traces I had is:
>>
>> V  [libjvm.so+0x4dd538]  CompressedKlassPointers::decode_not_null(unsigned int)+0x70
>> V  [libjvm.so+0xb87130]  InterpreterRuntime::throw_ClassCastException(JavaThread*, oopDesc*)+0x148
>> j  java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal
>> J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object;
>> java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064]
>> j  TestStringDedupStress.main([Ljava/lang/String;)V+162
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xb95328]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8
>> V  [libjvm.so+0x12531d4]  invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType,
>> objArrayHandle, bool, Thread*) [clone .isra.138]+0xd74
>> V  [libjvm.so+0x125380c]  Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x1a4
>> V  [libjvm.so+0xd05280]  JVM_InvokeMethod+0x210
>> j
>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
>>
>> java.base at 15-internal
>> j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100
>> java.base at 15-internal
>> j  jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
>> java.base at 15-internal
>> j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal
>> j  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172
>> j  java.lang.Thread.run()V+11 java.base at 15-internal
>> v  ~StubRoutines::call_stub
>> V  [libjvm.so+0xb95328]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8
>> V  [libjvm.so+0xb95784]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x2ac
>> V  [libjvm.so+0xb95974]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xac
>> V  [libjvm.so+0xcefce8]  thread_entry(JavaThread*, Thread*)+0x98
>> V  [libjvm.so+0x1507cc8]  JavaThread::thread_main_inner()+0x258
>> V  [libjvm.so+0x150fdac]  JavaThread::run()+0x27c
>> V  [libjvm.so+0x150d4a4]  Thread::call_run()+0x10c
>> V  [libjvm.so+0x115ff70]  thread_native_entry(Thread*)+0x120
>> C  [libpthread.so.0+0x8880]  start_thread+0x1a0
>>
>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>> j  java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal
>> J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object;
>> java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064]
>> j  TestStringDedupStress.main([Ljava/lang/String;)V+162
>> v  ~StubRoutines::call_stub
>> j
>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
>>
>> java.base at 15-internal
>> j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100
>> java.base at 15-internal
>> j  jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6
>> java.base at 15-internal
>> j  java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal
>> j  com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172
>> j  java.lang.Thread.run()V+11 java.base at 15-internal
>> v  ~StubRoutines::call_stub
>>
>> There are variations on that theme, but that was one of the more common ones.
>>
>> Thanks,
>>          Stuart
>>
>> On 27/03/2020 14:01, Zhengyu Gu wrote:
>>> Hi Stuart,
>>>
>>> Great work!
>>>
>>> On 3/26/20 6:42 PM, Stuart Monteith wrote:
>>>> Hello,
>>>>           Please review this change to implement nmethod entry barriers on
>>>> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will
>>>> need to be separately tested and enabled - there are problems with this
>>>> on Shenandoah.
>>>
>>> I identified a problem that failed TestStringDedupStress.java, I have fix for it.
>>>
>>> Would you mind to share what else failed with Shenandoah?
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>>
>>>> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as
>>>> well as Netbeans.
>>>>
>>>> In terms of interesting features:
>>>>            With nmethod entry barriers,  immediate oops are removed by:
>>>>                   LIR_Assembler::jobject2reg  and  MacroAssembler::movoop
>>>>           This is to ensure consistency with the entry barrier, as otherwise with
>>>> an immediate we'd otherwise need an ISB.
>>>>
>>>>           I've added "-XX:DeoptNMethodBarrierALot". I found this functionality
>>>> useful in testing as deoptimisation is very infrequent. I've written it
>>>> as an atomic to avoid it happening too frequently. As it is a new
>>>> option, I'm not sure whether any more is needed than this review. A new
>>>> test has been added
>>>> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to
>>>> test GC with that option enabled.
>>>>
>>>>           BarrierSetAssembler::nmethod_entry_barrier
>>>>           This method emits the barrier code. In internal review it was suggested
>>>> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not
>>>> done this as the BarrierSetNMethod code checks the exact instruction
>>>> sequence, and I prefer to be explicit.
>>>>
>>>>           Benchmarking method entry shows an increase of around 6ns with the
>>>> nmethod entry barrier.
>>>>
>>>>
>>>> The deoptimisation code was contributed by Andrew Haley.
>>>>
>>>> The bug:
>>>>           https://bugs.openjdk.java.net/browse/JDK-8216557
>>>>
>>>> The webrev:
>>>>           http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/
>>>>
>>>>
>>>> BR,
>>>>           Stuart
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you
>>>> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other
>>>> person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>>
>>>
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you
>> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other
>> person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.