Remove 2 (out of 3) horrible hacks around Java contexts
Previously, we did not even try to kill java contexts because we
failed to do so in some cases. Now, we try to kill them just like we
kill the other contexts, even if we don't always succeed.
One difficulty comes from the fact that some threads are created from
the C++ (from the deployment file) and then attached to the JVM, while
some others are created from Java directly (when calling new
Process().start()). The C++ vs Java stack is directly inverted between
cases, complicating the try/catch logic.
In practice, in this changeset, we try harder to convert between the
C++ StopRequest and the Java ProcessKilledError at the language
boundaries.
Also, we don't assert that JavaThread::stop() can actually detach the
thread: it won't for threads that are born in Java because their Java
stack was not unwinded yet. So throw a ProcessKilledError for that.
This is not prefect either since we still need to brutally kill the
JVM after the simulation using exit(0). I added some debug functions
to get more information. Just comment the first call to exit(0) in
jmsg.cpp to see the state of all user threads that we failed to
destroy.
They are all in the C++ world, without any [Java] stack, not blocked
on any Java synchronization object. I suspect that the system thread
is terminated, but the C++ std::thread object is still referenced
somewhere, preventing it from being garbage collected. That's weird
that the JVM still waits for them before ending (and thus mandating
the last the Horrible Hack -- exit(0) in the C++ side of the JVM
system process).
Gosh this is complicated. I'd love to have something like pybind11
dealing with all that shit automatically...
