Re: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp

[Mandy Chung]

On 3/14/19 10:41 AM, Brent Christian wrote:

On 3/13/19 6:08 PM, Martin Buchholz wrote:

Why not Reference.reachabilityFence ?


You mean the mechanism for this precise situation.  Yeah, OK.

http://cr.openjdk.java.net/~bchristi/8220088/webrev.01/


The use of Reference.reachabilityFence is good.

You mentioned at one point that you wanted to move ForceGC
utility to test library.  This test can convert to that when
it's available.

The other part of this patch is to remove the shell test.
Some suggested cleanup:

I would suggest to use jdk.test.lib.compiler.CompilerUtils
to compile A, B and C classes. and replace getClassImplFromDataBase
with Paths.readAllBytes.

Mandy

Re: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp

[Brent Christian]

On 3/14/19 10:41 AM, Brent Christian wrote:

On 3/13/19 6:08 PM, Martin Buchholz wrote:

>>

Why not Reference.reachabilityFence ?


http://cr.openjdk.java.net/~bchristi/8220088/webrev.01/



This looks good now, yes?

-Brent

Re: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp

[Brent Christian]

On 3/13/19 6:08 PM, Martin Buchholz wrote:

Why not Reference.reachabilityFence ?


You mean the mechanism for this precise situation.  Yeah, OK.

http://cr.openjdk.java.net/~bchristi/8220088/webrev.01/

Thanks,
-Brent

Re: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp

[Andrew Haley]

On 3/14/19 1:08 AM, Martin Buchholz wrote:
> Why not Reference.reachabilityFence ?

Certainly, yes. Apart from anything else, it's much clearer and robust against
changes to HotSpot.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp

[Martin Buchholz]

Why not Reference.reachabilityFence ?

RFR 8220088 : Test "java/lang/annotation/loaderLeak/Main.java" fails with -Xcomp

[Brent Christian]

Hi,

Please review my test-only fix for 8220088[1].  Along with fixing the 
issue, I've also converted this .sh test to .java.


Webrev is here:
http://cr.openjdk.java.net/~bchristi/8220088/webrev.00/

The test does the following:
1. sets up a classloader and loads class "C" into a WeakReference
2. runs a few GCs and ensures that the C class is still live
3. clears the reference to the classloader and runs a few more GCs
4. ensures that the C class has been collected (now that its classloader 
can also be collected)


When run with -Xcomp, the test fails with:

Exception in thread "main" java.lang.AssertionError
at Main.doTest(Main.java:56)
at Main.main(Main.java:41)

This comes from the code for step 2:

  System.gc();
  System.gc();
  if (c.get() == null) throw new AssertionError();

The C class is being collected before expected.

From my testing, I believe that when the test is pre-compiled with 
-Xcomp, the VM sees that 'loader' gets null'ed out, and doesn't keep it 
alive.


My change to fix this issue is adding this check:

+ if (loader != null) { // Under -Xcomp, ensure loader is still alive
  loader = null;
+ }

There are probably other ways to accomplish this, though this worked 
well for local as well as automated testing.


The rest of the changes are for the .sh -> .java conversion.

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8220088