Add asserts and tracepoints in JVM_VirtualThread* functions

[babsingh]

The asserts verify that a virtual thread is only

• added once to the list; and
• removed IFF it was added to the list.

The previous and next fields of the virtual thread object are set to
null when it is removed from the list.

Tracepoints output important details to triage failures.

Related: #16249
Related: #16259

Signed-off-by: Babneet Singh sbabneet@ca.ibm.com

[babsingh]

fyi @fengxue-IS @tajila

[babsingh]

Test case

Author: @tajila

import java.time.Duration;
import java.time.Instant;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.locks.LockSupport;
import java.util.HashMap;
import java.util.stream.IntStream;

public class PinALot {

    static final Object lock = new Object();

    public static void main(String[] args) throws Exception {
        int iterations = 100_000_000;
        if (args.length > 0) {
            iterations = Integer.parseInt(args[0]);
        }
        final int ITERATIONS = iterations;

        AtomicInteger count = new AtomicInteger();

        Thread thread = Thread.ofVirtual().start(() -> {
            synchronized (lock) {
                while (count.incrementAndGet() < ITERATIONS) {
                        IntStream.range(0, 6).forEach(i -> {
                                final HashMap list = new HashMap();
                                                Thread t = Thread.ofVirtual().start(() -> {
                                                        for(int j=0; j < 100; j++) { list.put( new Object(), new Object());}
                                                        try {
                                                                Thread.sleep(1);
                                                        } catch (Throwable tr) {

                                                                tr.printStackTrace();
                                                        }
                                                });

                        });
                 LockSupport.parkNanos(1);
                }
            }
        });

        boolean terminated;
        do {
            terminated = thread.join(Duration.ofMillis(500));
            System.out.println(Instant.now() + " => " + count.get());
        } while (!terminated);

        int countValue = count.get();
        if (countValue != ITERATIONS) {
            throw new RuntimeException("count = " + countValue);
        }
    }
}

[babsingh]

The above test case produces the following GC failure: #16249 (comment). With this PR, the GC failure is no longer seen. Now, the test consistently produces the Invalid JIT return address failure: #16249 (comment).

fyi @dmitripivkine @nbhuiyan

[babsingh]

Running a personal build to verify these changes: https://hyc-runtimes-jenkins.swg-devops.com/view/OpenJ9%20-%20Personal/job/Pipeline-Build-Test-Personal/14806/

[fengxue-IS]

The code looks good.

But is this check actually needed? there is only a single location where JVM_VirtualThreadMountEnd(true) can be called from during the entire scope of a virtualthread (https://github.com/ibmruntimes/openj9-openjdk-jdk19/blob/openj9/src/java.base/share/classes/java/lang/VirtualThread.java#L282)

I don't really see how this can can occur in the code. Rather than bypassing the issue with this check, I would prefer to have an assert here and find out how a virtual thread can be firstMount more than once before adding this check.

Adding a trace point in JVM_VirtualThreadMountEnd with (vmthread, carrierObject, vthreadObject firstMount) would help to identify if there are any issues.

same for the unmount case with the only unmountBegin(true) called at https://github.com/ibmruntimes/openj9-openjdk-jdk19/blob/openj9/src/java.base/share/classes/java/lang/VirtualThread.java#L310

[babsingh]

there is only a single location where JVM_VirtualThreadMountEnd(true) can be called from during the entire scope of a virtualthread

Can JVM_VirtualThreadMountEnd(true) be invoked multiple times?

@fengxue-IS I have converted the null-checks to asserts to verify your hypothesis. I am unable to reproduce the GC issue on my end. Can you confirm locally on your machine that the GC issue is no longer seen with the previously mentioned test-case?

[fengxue-IS]

Can JVM_VirtualThreadMountEnd(true) be invoked multiple times?

No unless something went wrong in JCL that allowed a vthread to be mounted to multiple carriers

I will try this change locally, it is just java --enable-preview -Xint PinALot or does it need additional parameters?

[babsingh]

Yes, no additional parameters are needed. Also, try without -Xint to verify that only the Invalid JIT return address failure is seen. Will squash and consolidate commits once the fix has been verified.

[fengxue-IS]

I run this locally for about 2hr ~ with -Xint

2022-11-15T21:49:01.130230505Z => 14093355

have not seen the GC issue using test case provided in #16325 (comment)

[tajila]

Can you also add some tracepoints for the mount/unmount methods (all 4).

We need to capture virtualthread->cont->vmref (as thread object address is not stable) and last/firstmount.

[babsingh]

@fengxue-IS @tajila Tracepoints have been added, and the commits have been squashed.

[tajila]

jenkins compile win jdk19

[tajila]

jenkins test sanity amac jdk19