<Beans Dev> Fwd: Re: [PATCH] test/jdk/java/beans/PropertyEditor/Test6397609.java failed in JITed code

Fu Jie fujie at loongson.cn
Tue Jan 8 07:18:22 UTC 2019


Hi,

It seems that triggering a GC by Alan's approach can fix some test bugs 
more effectively and more elegantly.

For example, I found 
test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java 
failed with "java -Xcomp RuntimeThreadInheritanceLeak".
The failure can be fixed just by the following change.
---------------------------------------------------------
diff -r 76f7dbf458fe 
test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
--- 
a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java 
Mon Jan 07 18:48:39 2019 -0800
+++ 
b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java 
Tue Jan 08 14:54:47 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...");
---------------------------------------------------------
So to fix bugs like Test6397609.java and 
RuntimeThreadInheritanceLeak.java failing, probably "System.gc()" is better.

Could you please also review the patch for the 
RuntimeThreadInheritanceLeak.java failing and give me some advice?
Or should we file another bug on JBS for that failure?
Thanks.

Best regards,
Jie

On 2019/1/8 上午5:54, Sergey Bylokhov wrote:
> On 07/01/2019 13:00, Alan Bateman wrote:
>> On 07/01/2019 19:32, Sergey Bylokhov wrote:
>>> :
>>>
>>> I do not see the problem in the "limit xmx" + "throw/catch OOM" + 
>>> "check the results".
>>> I guess this is only correct way to check it without possibility to 
>>> introduce infinite loop which checks weakref.get().
>>> Why don't you like it?
>> An infinite loop would imply we have a bug and the test would 
>> timeout, probably dozens of tests would timeout as we use this same 
>> idiom in several places.
>
> Even some of the core-libs tests uses OOM:
> http://hg.openjdk.java.net/jdk/jdk/file/03efcf7fc34b/test/jdk/java/util/HashMap/HashMapCloneLeak.java 
>
>
> Probably in core-libs it works for other tests because of agentvm 
> mode, when some other tests trigger gc,
> all UI and beans tests uses othervm, and most of them use OOM to 
> trigger gc.
>
>
>



More information about the beans-dev mailing list