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

[David Holmes]

Hi Jie,

On 11/01/2019 1:24 pm, Jie Fu wrote:
> I'm sorry to miss the JBS link.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8216528
> 
> Could you please review it and give me some advice?
> Thanks.

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
-----

> 
> 
> -------- Forwarded Message --------
> Subject: 	RFR: JDK-8216528: 
> test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java 
> failing with Xcomp
> Date: 	Fri, 11 Jan 2019 11:16:22 +0800
> From: 	Jie Fu <fujie at loongson.cn>
> To: 	David Holmes <david.holmes at oracle.com>, core-libs-dev at openjdk.java.net
> 
> 
> 
> Hi,
> 
> Please review this patch for JDK-8216528:
> ---------------------------------
> 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 
> Thu Jan 10 20:49:22 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...");
> ---------------------------------
> 
> The failure was caused by the lost of an OopMap item for "loaderRef" 
> which was optimized out by the JIT with the liveness analysis optimization.
> 
> Key idea for this patch:
> 1) "loaderRef" is referenced after "System.gc()" to keep it alive, which 
> prevents its corresponding OopMap being optimized out by JITs.
> 2) The "System.gc()"+sleep+test pattern is used, which seems more 
> reliable to trigger a GC.
> 
> Could you please review it and give me some advice?
> Thanks.
> 
> Best regards,
> Jie
> 
> 
> On 2019/1/11 上午10:40, Ao Qi wrote:
>> Hi Fu Jie:
>>
>> I filed it here: https://bugs.openjdk.java.net/browse/JDK-8216528
>>
>> Cheers,
>> Ao Qi
>>
>> On Fri, Jan 11, 2019 at 10:22 AM Jie Fu <fujie at loongson.cn> wrote:
>>> Thanks David.
>>> Hope more cases are suitable for both interpreter and JIT tests.
>>>
>>>
>>> On 2019/1/11 上午10:13, David Holmes wrote:
>>>> Hi Jie,
>>>>
>>>> On 11/01/2019 11:58 am, Jie Fu wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks and apologies.
>>>> No apology needed :)
>>>>
>>>>> This issue was discovered by a broad -Xcomp testing with jtreg on
>>>>> Loongson CPUs (MIPS compatible processors).
>>>>> It was intended to test our MIPS port of OpenJDK.
>>>>> We've found and fixed quite a lot of JIT bugs for our MIPS
>>>>> implementation by this approach.
>>>> Okay, you may well be testing more tests under Xcomp than what we
>>>> regularly do, so that may well expose a number of tests that may not
>>>> work at all, or which fail intermittently. I'm trying to find out if
>>>> there is a relatively easy way to enumerate the tests we do run under
>>>> -Xcomp.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> I'll ask Ao Qi to file a bug on JBS and post a webrev soon.
>>>>> Thanks again.
>>>>>
>>>>> Best regards,
>>>>> Jie
>>>>>
>>>>>
>>>>>> For hotspot testing we have certain sets of tests that are run under
>>>>>> -Xcomp, but this is obviously not one of them. Did you discover this
>>>>>> by chance or because you are attempting to do broad -Xcomp testing?
>>>>>> Not every test will work with Xcomp (for various reasons) and we
>>>>>> aren't actively trying to make every test pass with Xcomp.
>>>>>>
>>>>>> But by all means file a bug and fix it.
>>>>>>
>>>>>> Cheers,
>>>>>> David
>