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

Jie Fu fujie at loongson.cn
Tue Jan 29 01:46:16 UTC 2019


Hi,

I agree that the simplest way to fix the issue is just adding the 
reachabilityFence.
But this patch might also fail since the VM doesn't guarantee that a GC 
would be performed.

I didn't make such patch since I've learned from Sergey and Alan that 
calling "System.gc()" several times is unreliable to trigger a gc[1].
So I still prefer the original one[2].

Thanks a lot.

Best regards,
Jie

[1] 
https://mail.openjdk.java.net/pipermail/beans-dev/2019-January/000396.html
[2] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057852.html


On 2019/1/28 下午11:39, Roger Riggs wrote:
> Hi,
>
> The simplest fix for this failing test is to add a call to 
> reachabilityFence to prevent
> the loader and loaderRef from going out of scope early.  It maintains 
> getting debug
> output on a failure.
>
> Offlist, Jie and I explored some alternate ways to write the test and 
> settled on this one.
>
> Please review:
>
> diff --git 
> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java 
> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
> --- 
> a/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
> +++ 
> b/test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
> @@ -113,11 +113,13 @@ public class RuntimeThreadInheritanceLea
>              Reference dequeued = refQueue.remove(TIMEOUT);
>              if (dequeued == null) {
>                  System.err.println(
> -                    "TEST FAILED: loader not deteced weakly reachable");
> +                    "TEST FAILED: loader not detected weakly reachable");
>                  dumpThreads();
>                  throw new RuntimeException(
>                      "TEST FAILED: loader not detected weakly reachable");
>              }
> +            Reference.reachabilityFence(loader);
> +            Reference.reachabilityFence(loaderRef);
>
>              System.err.println(
>                  "TEST PASSED: loader detected weakly reachable");
>
> Thanks, Roger
>
>
>
> On 01/11/2019 07:25 PM, Jie Fu wrote:
>> Thanks David and Roger.
>>
>>
>> On 2019年01月12日 06:52, David Holmes wrote:
>>> Hi Roger,
>>>
>>> On 12/01/2019 2:22 am, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> The proposed patch changes the test in a way that is unintended.
>>>>
>>>> Adding the infinite loop of gc() and sleep, will change the timeout 
>>>> behavior
>>>> from the existing timeout of TIMEOUT to the jtreg default timeout 
>>>> of the whole test.
>>>
>>> Partially true. If the new loop gets stuck then yes the jtreg 
>>> default timeout will apply - I don't see that is necessarily a bad 
>>> thing. The existing timeout only applies to the refQueue.remove 
>>> operation itself, you don't know how much time was spent before you 
>>> got there, nor how much will be spent after in the dumpThreads() 
>>> calls - so the jtreg timeout can still come into affect.
>>>
>>>> Further, it renders the check at lines 114-120 irrelevant since 
>>>> loaderRef.get()
>>>> will have returned null and the ref will have been enqueued by then.
>>>
>>> I wouldn't say irrelevant as it double-checks the interaction 
>>> between the ref.get() and the queue.remove() - the result of one 
>>> should imply the result of the other, but if enqueuing had a bug ....
>>>
>>>> While it is true that calling gc() only once is unreliable, a 
>>>> better fix is to
>>>> put the code from 108-120 in a loop with a fixed number of durations
>>>
>>> That would also work - say 5 loops and reduce TIMEOUT to 4000.
>>>
>>>> and add Reachability.reachabilityFence(loaderRef) to ensure the ref 
>>>> is not ignored.
>>>
>>> Adding ReachabilityFence, alone, may solve the observed problem 
>>> given one gc() seems to be working in practice (and because we don't 
>>> actually have the leaked loaders anymore because those threads 
>>> (sun.misc.GC threads) don't exist anymore).
>>>
>>> Cheers,
>>> David
>>>
>>>> Regards, Roger
>>
>>
>



More information about the core-libs-dev mailing list