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

Jie Fu fujie at loongson.cn
Fri Jan 11 03:16:22 UTC 2019


Hi,

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

              System.err.println(
                  "waiting to be notified of loader being weakly 
reachable...");
---------------------------------

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?
Thanks.

Best regards,
Jie


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