Thread.strop removed: how to deal with a rogue ScriptEngine thread?

[Christian Humer]

Hi Francois,

Graal.js, the JavaScript implementation on top of GraalVM, supports reliable timeouts of *any* JavaScript code. Including endless loops without bodies.

* How to use it:* 

http://www.graalvm.org/docs/graalvm-as-a-platform/embed/#reliable-timeouts-for-malicious-code

* How it works:* 

We use the HotSpots safe point mechanism to trigger a deoptimization for the optimized machine code generated for while(true). For example, safe points are also used whenever the garbage collector needs to intercept the execution and do its work.
After the deoptimization, we next use the Truffle instrumentation framework to insert a forced stack unwind on the next statement executed. A force stack unwind is implemented using an exception thrown by the instrumentation. The forced stack unwind will skip any finally blocks of the language, therefore the context needs to be closed, as the application state is invalid after that. It does *not* rely on Thread#stop for its implementation..

More info on how to migrate from Nashorn: https://medium.com/graalvm/oracle-graalvm-announces-support-for-nashorn-migration-c04810d75c1f

Hope this is helpful,

- Christian Humer



> On 7/23/18 8:55 AM, Francois wrote:
> Hello,
> 
> I'm not sure at all it is the correct mailing list for that, so sorry if it is not, and please let me know where I should post my concerns.
> 
> So, in JDK 11, the long term deprecated Thread.stop() will is removed (https://bugs.openjdk.java.net/browse/JDK-8204243), and I have an use case that I don't know how to deal with afterwards.
> 
> We use nashorm to provides user with a embeded scripting languageon our plateform. Only simple things are accessible, and we try to forbid dangerous things like killing the host process, deleting the underlying filesystem, or infinite, not pause-to-look-for-Thread.interrupt while loops.
> The first two kind of problem are easely managed with a custom security manager and a thread factory that uses itfor starting the sandboxed process (ie: nashorn.eval).
> 
> But I don't know how to manage the while(true){} loop. In that case, the nashorn thread does not respond to Thread.interrupt (it is a wide source of surpise and wonders on the internet, see for example: https://stackoverflow.com/questions/1601246/java-scripting-api-how-to-stop-the-evaluation/1601465#1601465 and the problem is more generally that Java ScriptEngine API does not provide a way to interrupt underlying process ounce started). So I used to have a timeout counter and a Thread.stop() on it. Ido understand that it could still raise problems, even with the custom threadfactory and the very specific use case, but it was the only solution I knew of at hand.
> 
> But now, I don't have any at all to prevent an user to start unstoppable thread (by malice or by error).
> 
> Any help would be much appreciated on that topic.