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
As exposed on the issue #6173 comments, currently, OkHttp's daemon threads (Watchdog & TaskRunner) won't exit when getting interrupted, they stay alive until the keepalive has been exceeded, which seems to be 60s.
In traditional applications, this doesn't seem to be a problem, but in Native Image Isolates it is.
On a GraalVM Native Image Isolate situation, the expected workflow is to allow code to execute isolated, and these Isolates can be created and destroyed at will. They are essentialy, a small disjoint heap that is cheap to create and destroy quickly.
The pre-requisite to destroying them is that no Threads must be currently executing, so, the logic is that before destroying an Isolate, each thread that is currently running withing such Isolate is interrupted, and then wait until all threads have exited.
If threads don't exit, the Thread currently managing the destruction of such isolate will stay stuck until such threads exit, and of course, the isolate will continue using memory that could be freed.
This is the case of OkHttp, since the interrupt doesn't seem to do anything, the thread just waits for 60s and then when the OkHttp daemon threads exit, it proceeds to destroy the isolate.
Opening this issue to ask if this can be done, and to generate some discussion about the possible solutions and their implications.
As exposed on the issue #6173 comments, currently, OkHttp's daemon threads (Watchdog & TaskRunner) won't exit when getting interrupted, they stay alive until the keepalive has been exceeded, which seems to be 60s.
In traditional applications, this doesn't seem to be a problem, but in Native Image Isolates it is.
On a GraalVM Native Image Isolate situation, the expected workflow is to allow code to execute isolated, and these Isolates can be created and destroyed at will. They are essentialy, a small disjoint heap that is cheap to create and destroy quickly.
The pre-requisite to destroying them is that no Threads must be currently executing, so, the logic is that before destroying an Isolate, each thread that is currently running withing such Isolate is interrupted, and then wait until all threads have exited.
If threads don't exit, the Thread currently managing the destruction of such isolate will stay stuck until such threads exit, and of course, the isolate will continue using memory that could be freed.
This is the case of OkHttp, since the interrupt doesn't seem to do anything, the thread just waits for 60s and then when the OkHttp daemon threads exit, it proceeds to destroy the isolate.
Opening this issue to ask if this can be done, and to generate some discussion about the possible solutions and their implications.
Blog post about Isolates
https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e
Some documentation on the Isolate API
https://www.graalvm.org/reference-manual/native-image/C-API/
The text was updated successfully, but these errors were encountered: