Virtual thread overhead in SharedRuntime::handle_wrong_method

[Gillespie, Oli]

Hi,

I've been using virtual threads and I noticed some apparently significant overhead in SharedRuntime::handle_wrong_method.

A simple 'benchmark'/stress test profiled with async-profiler shows (among other similar stacks):

```
--- 29055613704 ns (21.14%), 288804 samples
  [ 0] ImmutableOopMap::update_register_map(frame const*, RegisterMap*) const
  [ 1] vframeStream::vframeStream(JavaThread*, bool, bool, bool)
  [ 2] SharedRuntime::find_callee_method(JavaThread*)
  [ 3] SharedRuntime::reresolve_call_site(JavaThread*)
  [ 4] SharedRuntime::handle_wrong_method(JavaThread*)
  [ 5] jdk.internal.vm.Continuation.enterSpecial
  [ 6] jdk.internal.vm.Continuation.run
  [ 7] java.lang.VirtualThread.runContinuation
  [ 8] java.lang.VirtualThread$$Lambda.0x00007ffad006e3d8.run
  [ 9] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec
  [10] java.util.concurrent.ForkJoinTask.doExec
  [11] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec
  [12] java.util.concurrent.ForkJoinPool.scan
  [13] java.util.concurrent.ForkJoinPool.runWorker
  [14] java.util.concurrent.ForkJoinWorkerThread.run
```

Is this just the expected path+cost of swapping between virtual threads, or is there something surprising happening here?

My code for the test is:

```
import java.util.concurrent.*;

public class Virt {
    public static void main(String[] args) throws Exception {
        while (true) {
            ExecutorService e = Executors.newVirtualThreadPerTaskExecutor();
            for (int i = 0; i < 100_000; i++) e.submit(Main::task);
            e.shutdown(); e.awaitTermination(100, TimeUnit.MINUTES);
        }
    }
    static void task() { }
}
```

Notes:
- I'm running with JDK21, using `java -XX:+UnlockExperimentalVMOptions -XX:-DoJVMTIVirtualThreadTransitions Virt.java` since I know async-profiler as a JVMTI agent triggers some other overheads which would be distracting in the profiling data.
- Another user saw similar behaviour in https://github.com/async-profiler/async-profiler/issues/779#issuecomment-1651225252.

Apologies if this is just totally expected behaviour, but I couldn't find any discussion on it.

Regards,

Oli



Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.