Project Jigsaw: Phase Two

[Gregg Wonderly]

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
> 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