You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the issue
Isolate thread can't be stopped with Isolates.tearDownIsolate(isolateThread) when isolateThread has child Java threads (created from inside Context) alive.
Steps to reproduce the issue
Create a JavaScript function that calls some long-running Java code (heavy computation or http-request that keeps connection alive)
Create Isolate thread, that creates JavaScript context and evaluates this JS function
Set timeout for execution and call context.close(true) from a new thread when the time finishes.
Perform Isolates.tearDownIsolate(isolateThread);
Expected result
IsolateThread and all related resources are discarded after timeout. Related heavy Java computation task is stopped.
Actual result
IsolateThread can't be teared down till Java - related task is finished.
Describe GraalVM and your environment:
GraalVM version : GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02, mixed mode, sharing)
JDK major version: openjdk 11.0.7 2020-04-14
OS: MacOS Catalina 10.15.5 (19F101)
Architecture: 19.5.0 Darwin Kernel Version 19.5.0; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64
More details
Consider adding the --native-image-info and --verbose flags when building your native image and paste output below.
Note: IF we try to execute pure JS endless function (for ex. while(true)) (without calling endless Java job from inside JavaScript), IsolateThread can be killed with Isolates.tearDownIsolate(isolateThread); as expected
AndreiYu
changed the title
Graalvm Isolate thread not being killed when related threads spawned in Context are alive
Graalvm Isolate thread not being killed when related Java threads spawned in Context are alive
Jun 26, 2020
Thank you @AndreiYu for your report. Calling tearDownIsolate uses a cooperative approach: it calls Thread.interrupt on each live thread, then wait until the threads have exited. It's the responsibility of the code running in the threads to handle the interrupt accordingly. Forcibly terminating threads is generally undesirable because it likely leads to resource leakages. @woess@chumer what's the expected behavior of a Truffle execution in this scenario?
it calls Thread.interrupt on each live thread, then wait until the threads have exited. It's the responsibility of the code running in the threads to handle the interrupt accordingly. Forcibly terminating threads is generally undesirable because it likely leads to resource leakages.
Peter, Thank you for the clarification, is it possible, for ex. to allow forcibly terminate such threads inside tearDownIsolate if they were created as daemons? I tried this option as well, but daemon threads seem to behave just the same way as ordinary threads do. It could be a useful tool in hands of a developer since he could mark such Isolate-dependent thread as available to be forcibly killed and not put potential memory-leakage logic such as URL connection and IO write/read operations inside .
No, the problem with resource leakage is the same with daemon threads. Even when a programmer carefully avoids leakage of application resources, there are several internal mechanisms which could cause trouble here.
Describe the issue
Isolate thread can't be stopped with
Isolates.tearDownIsolate(isolateThread)
when isolateThread has child Java threads (created from inside Context) alive.Steps to reproduce the issue
context.close(true)
from a new thread when the time finishes.Isolates.tearDownIsolate(isolateThread);
Expected result
IsolateThread and all related resources are discarded after timeout. Related heavy Java computation task is stopped.
Actual result
IsolateThread can't be teared down till Java - related task is finished.
Describe GraalVM and your environment:
More details
Consider adding the
--native-image-info
and--verbose
flags when building your native image and paste output below.Note: IF we try to execute pure JS endless function (for ex.
while(true)
) (without calling endless Java job from inside JavaScript), IsolateThread can be killed withIsolates.tearDownIsolate(isolateThread);
as expectedSeems that the same issue has already been reported here: graalvm/graalvm-demos#33
Here is some test code to have a look closer look graalvm_native_isolates_issue
Thank you.
The text was updated successfully, but these errors were encountered: