Use of deprecated `Thread.stop` prevents interruption on Java 20+

[Jengamon]

Steps to reproduce

1. Install a JDK/JRE for Java 20 or later.
2. Open an Ammonite REPL using that JDK/JRE (using Scala 3, but that isn't too relevant maybe)
3. Run the line while true do () (Scala 3)
4. Attempt to Ctrl-C
5. You should see

Exception in thread "SIGINT handler" java.lang.UnsupportedOperationException
        at java.base/java.lang.Thread.stop(Thread.java:1705)
        at ammonite.repl.Repl.$anonfun$action$5(Repl.scala:191)
        at ammonite.repl.Signaller$$anon$1.handle(Signaller.scala:21)
        at jdk.unsupported/sun.misc.Signal$InternalMiscHandler.handle(Signal.java:198)
        at java.base/jdk.internal.misc.Signal$1.run(Signal.java:218)
        at java.base/java.lang.Thread.run(Thread.java:1623)

because in Java 20 (https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/Thread.html#stop()) the function has been "removed" and apparently should be replaced with Thread.interrupt and interruption checking/allowing on the execution thread.

The problematic line seems to be here:

Ammonite/amm/repl/src/main/scala/ammonite/repl/Repl.scala

Line 191 in 084f7f4

interp.mainThread.stop()

Expected behavior

I expected to be able to interrupt long running programs, which was one of the advertised benefits of Ammonite-REPL.

Environment

Ammonite: 3.0.0-M0-53-084f7f4e
Scala: 3.3.1
Java: 20

[alexarchambault]

A problem here, IIUC, is that there's no real substitute for Thread.stop when users want to stop code like while (true) {} (or any code that keeps the CPU busy doing computation, rather than waiting for I/O and the like).

[lihaoyi]

I suspect it might be possible to re implement this using JNI, but I'm not familiar enough with the JVM C API to know for sure

[rednaxelafx]

Bypassing the public Java API to reach into the JVM for the stop() implementation isn't going to be portable, or supported in the long run. There is indeed no replacement for the stop() due to its semantics being problematic in the first place (i.e. skips proper unwinding of the stack)

The thing about being a REPL though is that you sort of have control over the compiler, at least for the part that was entered through the REPL. It might be possible to artificially add in a "blackhole"-style empty method at the backedges of all the loops to allow interrupts to have an anchor point to deliver to.

For reference, here's JDK8 HotSpot JVM/Linux's Thread.interrupt() and Thread.isInterrupted()'s underlying implementation.
https://github.com/openjdk/jdk8u-dev/blob/master/hotspot/src/os/linux/vm/os_linux.cpp#L4508-L4547
Essentially a fenced-write and a fenced-read on a boolean flag on the thread. So yeah the target thread won't notice this until it proactively checks the isInterrupted flag and does something about it.

[lihaoyi]

We don't actually have full control over the compiler due to Scala's binary dependencies; people pull in all sorts of Java/Scala jars from maven central or other projects those come pre-compiled.

We could do a bytecode rewrite on load using a JVM agent. That's pretty invasive, and may hurt performance, but I've done it before in https://github.com/lihaoyi/6858

[Jengamon]

...SecurityManager is also on track for removal https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/SecurityManager.html

[lefou]

...SecurityManager is also on track for removal https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/SecurityManager.html

Looks like a secret conspiracy to make threads immortal. 🤣

[hodsonus]

Running into this as well with java 24