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

Jie Fu fujie at loongson.cn
Fri Jan 11 05:07:53 UTC 2019


Hi David,

Thank you very much. I'd like to choose option 2.
A test case is more valuable if it can be used for both interpreter and 
JIT tests.

Here is the patch based on your comments.
----------------------------------------------------------------------------------
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 
Fri Jan 11 12:55:38 2019 +0800
@@ -22,7 +22,7 @@
   */

  /* @test
- * @bug 4404702
+ * @bug 4404702 8216528
   * @summary When the RMI runtime (lazily) spawns system threads that could
   * outlive the application context in which they were (happened to be)
   * created, such threads should not inherit (thread local) data 
specific to
@@ -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...");
----------------------------------------------------------------------------------

Could you please review it and give me some advice?
Thanks.

Best regards,
Jie


On 2019/1/11 下午12:16, David Holmes wrote:
>
> I see three choices for you here :)
>
> 1. Don't try to run all tests under Xcomp but just stick to the "core" 
> sets of tests already tested by others.
>
> 2. Fix the given test as outlined. (I tested it on linux-x64 and it 
> fixed the problem.)
>
> 3. Exclude the given test from Xcomp by adding: @requires vm.compMode 
> != "Xcomp"
>
> If you chose options 2 or 3 please update the @bug line with 8216528.
>
> The core-libs folk may have more to say here and they will need to 
> provide a sponsor for the commit.
>
> Thanks,
> David
> -----



More information about the core-libs-dev mailing list