On 7/7/2014 10:42 AM, mark.reinh...@oracle.com wrote:
2014/7/5 20:59 -0700, krasimir.semerdzh...@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
this.
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.
Gregg Wonderly
