The check in SharedRuntime::reresolve_call_site() "caller.is_compiled_frame() && !caller.is_deoptimized_frame()" fails when caller is Continuation.enterSpecial because it is a native method. This means that if the static callsite to Continuation.enter was patched to point to an nmethod and then the nmethod was marked non-entrant we will always call SharedRuntime::handle_wrong_method() thereafter when resolving Continuation.enter because the callsite will never be reset back to the clean state.

This issue was found after the following report in the loom-dev mailing list:

https://mail.openjdk.org/pipermail/loom-dev/2023-August/006083.html

Test from mail:

```
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(Virt::task);
            e.shutdown(); e.awaitTermination(100, TimeUnit.MINUTES);
        }
    }
    static void task() { }
}
```