Project Jigsaw: Phase Two
greggwon at cox.net
Mon Jul 7 17:07:00 UTC 2014
On 7/7/2014 10:42 AM, mark.reinhold at oracle.com wrote:
> 2014/7/5 20:59 -0700, krasimir.semerdzhiev at sap.com:
>> This leaves little options for maneuvering to application server providers,
>> different than restarting the app server process. That's (to date) is the
>> only reliable way to ensure that a certain application has been properly
>> unloaded, regardless how buggy its implementation is.
>> It would be great to have a more clear statement in the document (even in
>> the case that it falls in the "non requirements" section) to clarify
>> whether Jigsaw in Java 9 will have any impact/effect on the above-described
>> scenario. I certainly understand that in order to offer a way for Java EE
>> application servers to reliably unload/reload modules/applications at
>> runtime - this will most probably require an extension of the Java Language
>> Specification, which as far as I get it - is currently out of scope for the
>> Jigsaw project.
> You're right: Providing a means by which an app server can forcibly
> terminate and unload an errant application is well beyond the scope
> of Jigsaw. As Alan indicated, it's a very tough problem. I'll add
> a non-requirement in the next draft, just to be perfectly clear on
For applications where this would be most likely to occur, it would seem that
this is trivial to do by simply having the JVM mark all the code pages as
inaccessible, or otherwise unloading them from the VM allocated set. That would
fault every running thread and force the threads to exit. It's this kind of
hammer that I would really like to have. It is just far too painful to have to
track every single resource. A Class.unload() method would be very helpful, and
if you want threads unloaded to throw a particular "Error", you could provide
Class.unload(Error) which would allow some remnant code to help threads throw a
catchable Error that would allow the thread management in EE or elsewhere to
manage pools. Thread.stop(Throwable) was an attempt at this, but since it wasn't
required and spec'd appropriately with precise behavior, it hasn't been a solution.
I don't really think this is "difficult" as much as it is "detailed", and just
needs to assure two things can happen. First, the class must be evicted and
two, threads running into such a class instance, need to be stopped.
In systems where there is the notion of "versioning" the view of code should be
through vector tables which select a "version" of the "codebase", using a
version number which a thread is handed, when it starts running. The vector
table directs threads to the old or new code to create a coherent behavior
within each thread. Eventually when the new code is "committed", the old
threads, if still running, should be faulted for trying to use any old code, and
that will force them out of the system.
This doesn't have to be pretty and do everything. It just needs to be possible
to deny use of a Class object, and that needs to cause Thread termination if it
access is attempted. If there could be some type of "init process" or "parent
of all Threads" behavior too, so that it would be guaranteed that thread
termination could not be "missed", it would seem to be a perfectly plausible
thing to do.
Without such a feature, we are getting to the point where JVM process restart is
still the only solution, at that is so 1980's... We are at the point of
evolution of runtime environments where "Java" is used, really are places where
VM is the underlying memory mechanism. So, it seems like the right time to
just go ahead and use it to it's full abilities.
More information about the jigsaw-dev