RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp
Jie Fu
fujie at loongson.cn
Sat Jan 12 00:25:13 UTC 2019
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