RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2]
Aleksey Shipilev
shade at openjdk.java.net
Thu Feb 25 15:40:45 UTC 2021
On Thu, 18 Feb 2021 19:31:02 GMT, Attila Szegedi <attila at openjdk.org> wrote:
>> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"
>
> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
The good test would be trying with all current GCs (Serial, Parallel, G1, Shenandoah, ZGC):
make run-test TEST=jdk/dynalink TEST_VM_OPTS=-XX:+UseSerialGC
Also, make sure that GH actions are able to run this test. You probably need to enable the workflow here -- https://github.com/szegedi/jdk/actions -- and then trigger the workflow manually on your branch (or push another commit). Then "Checks" tab would show the results.
test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 28:
> 26: * @bug 8198540
> 27: * @summary Test TypeConverterFactory is not leaking method handles
> 28: * @run main/othervm -Xmx4M TypeConverterFactoryMemoryLeakTest
I think `-Xmx4m` is risking it on some platforms that cannot go that low heap. Maybe do 128M, and bulk up the test allocations, so that GC definitely triggers?
test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 79:
> 77:
> 78: public static void main(String[] args) {
> 79: for (int count = 0; count < MAX_ITERATIONS; ++count) {
Here and later: use postfix `count++`, regular style?
-------------
Changes requested by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2617
More information about the core-libs-dev
mailing list