RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

[Peter Levart]

On Thu, 18 Feb 2021 19:41:21 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"
>
> @plevart can I bother you for a follow-up review of my original issue? (Alternatively, @shipilev?) Unfortunately the tests as I wrote them are flaking on somewhat loaded CI servers. Shame on me for using timing-based tests… Thanks for the consideration. 
> 
> I changed the flaky tests to use an upper limit on number of iterations instead of a maximum duration, so they won't be time sensitive anymore. I'm also running them with a separate VM using a very small max heap (4M) so the GC condition triggers quickly. Finally, I measured the number of iterations they need to succeed with this heap size; the numbers are deterministic across executions, but I also added a generous padding (least iterations needed by a test is 30, most needed is 219, I'm allowing the tests to run until 5000.)

> Unfortunately the tests as I wrote them are flaking on somewhat loaded CI servers...
> 
> I changed the flaky tests to use an upper limit on number of iterations instead of a maximum duration, so they won't be time sensitive anymore. I'm also running them with a separate VM using a very small max heap (4M) so the GC condition triggers quickly. Finally, I measured the number of iterations they need to succeed with this heap size; the numbers are deterministic across executions, but I also added a generous padding (least iterations needed by a test is 30, most needed is 219, I'm allowing the tests to run until 5000.)

I played a little with TypeConverterFactoryMemoryLeakTest. If I add `System.gc()` call and a 10ms sleep into the loop, the test succeeds after 12 iterations even if I increase the heap size considerably.
I would like 1st to understand why the MH created in the TestLinker.convertToType is actually GCed at all. And after that, why it is not GCed before 12 invocations to makeOne() are made.

What would be more interesting to test is to create a converter between a type loaded by a custom (child) ClassLoader and a system type. After that, release all hard references to the custom ClassLoader and see if the converter gets GC-ed as a result. WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2617