RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp
Jie Fu
fujie at loongson.cn
Fri Jan 11 05:42:09 UTC 2019
Thanks David.
Could someone from core-libs help to review it?
Thanks.
On 2019/1/11 下午1:33, David Holmes wrote:
> On 11/01/2019 3:07 pm, Jie Fu wrote:
>> 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?
>
> Not sure what "advice" you are looking for?
>
> I have reviewed it - looks fine to me (and I tested it).
>
> But I want someone from core-libs to also review it and hopefully
> sponsor it.
>
> Thanks,
> David
>
>> 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