Fwd: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Jie Fu fujie at loongson.cn
Fri Jan 11 03:24:32 UTC 2019

I'm sorry to miss the JBS link.

JBS:  https://bugs.openjdk.java.net/browse/JDK-8216528

Could you please review it and give me some advice?

-------- Forwarded Message --------
Subject: 	RFR: JDK-8216528: 
failing with Xcomp
Date: 	Fri, 11 Jan 2019 11:16:22 +0800
From: 	Jie Fu <fujie at loongson.cn>
To: 	David Holmes <david.holmes at oracle.com>, core-libs-dev at openjdk.java.net


Please review this patch for JDK-8216528:
diff -r 02e648ae46c3 
Wed Jan 09 01:06:19 2019 +0100
Thu Jan 10 20:49:22 2019 +0800
@@ -106,7 +106,10 @@
               * context class loader-- by giving it a chance to pass away.
-            System.gc();
+            while(loaderRef.get() != null) {
+                System.gc();
+                Thread.sleep(100);
+            }

                  "waiting to be notified of loader being weakly 

The failure was caused by the lost of an OopMap item for "loaderRef" 
which was optimized out by the JIT with the liveness analysis optimization.

Key idea for this patch:
1) "loaderRef" is referenced after "System.gc()" to keep it alive, which 
prevents its corresponding OopMap being optimized out by JITs.
2) The "System.gc()"+sleep+test pattern is used, which seems more 
reliable to trigger a GC.

Could you please review it and give me some advice?

Best regards,

On 2019/1/11 上午10:40, Ao Qi wrote:
> Hi Fu Jie:
> I filed it here: https://bugs.openjdk.java.net/browse/JDK-8216528
> Cheers,
> Ao Qi
> On Fri, Jan 11, 2019 at 10:22 AM Jie Fu <fujie at loongson.cn> wrote:
>> Thanks David.
>> Hope more cases are suitable for both interpreter and JIT tests.
>> On 2019/1/11 上午10:13, David Holmes wrote:
>>> Hi Jie,
>>> On 11/01/2019 11:58 am, Jie Fu wrote:
>>>> Hi David,
>>>> Thanks and apologies.
>>> No apology needed :)
>>>> This issue was discovered by a broad -Xcomp testing with jtreg on
>>>> Loongson CPUs (MIPS compatible processors).
>>>> It was intended to test our MIPS port of OpenJDK.
>>>> We've found and fixed quite a lot of JIT bugs for our MIPS
>>>> implementation by this approach.
>>> Okay, you may well be testing more tests under Xcomp than what we
>>> regularly do, so that may well expose a number of tests that may not
>>> work at all, or which fail intermittently. I'm trying to find out if
>>> there is a relatively easy way to enumerate the tests we do run under
>>> -Xcomp.
>>> Cheers,
>>> David
>>>> I'll ask Ao Qi to file a bug on JBS and post a webrev soon.
>>>> Thanks again.
>>>> Best regards,
>>>> Jie
>>>>> For hotspot testing we have certain sets of tests that are run under
>>>>> -Xcomp, but this is obviously not one of them. Did you discover this
>>>>> by chance or because you are attempting to do broad -Xcomp testing?
>>>>> Not every test will work with Xcomp (for various reasons) and we
>>>>> aren't actively trying to make every test pass with Xcomp.
>>>>> But by all means file a bug and fix it.
>>>>> Cheers,
>>>>> David

More information about the core-libs-dev mailing list