This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Fwd: future JDK features: negotiatable shared heap space betweenisolates]



--- Begin Message ---
It would be nice to have isolates share heap space on demand.


This could be useful for a Swing Application, for example,
that constructs a user interface on a heap and then allows that
heap to be accessed by a Java Desktop running in another isolate:

The Java Desktop can render the user interface and send all
events the user interface generates to the isolate running the
application logic.

If the application logic isolate is terminated all objects in its
exported heap space would become null references and the
java desktop would have to react on the NullPointerException
by removing all null references from its display.

Shared heaps would also be useful in server applications
with NUMAflex <http://www.sgi.com/products/servers/numaflex.html> or similar environments.


There's some possible overlap with the Realtime Java JSR,
where different types of memory are already implemented. <http://www.sgi.com/products/servers/numaflex.html>
<>Obviously this would allow to build a Java desktop which
can display independent Java applications in its own Swing
desktop without the danger of it becoming a victim of
resource depletion by a rogue application.


A resource tracking and limitation facility for sub-isolates
also seems like a useful extension (similar to getrusage (2)).

In reply to Stefano Mazzocchi's Wishes:
> continuation support: the ability to freeze the state of a thread
> and resume it. Just implementing Thread.stop() that returns a
> Continuation object would be good enough. I don't care about making
> these continuations transportable across machines and I don't care if
> they don't work if JNI is in the mix.

Maybe this shoul be solved using isolates (http://www.bitser.net/isolate-interest/).
Stopping and even migrating an isolate to a different VM could be implemented
as methods to the Isolate class. Stopping a thread is not recommened anyway
(http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html).


Here's some example code:

---- sender ----

javax.isolate.Heap heap = new Heap ();

ui = heap[.enclosing class].new MyUserInterface ();
/* similar syntax as the syntax for specifying enclosing instances */

javax.isolate.MemoryMessage memoryMessage = new MemoryMessage (heap);
javax.isolate.tbd.ObjectReferenceMessage objectReferenceMessage = new ObjectReferenceMessage (ui);


javax.isolate.Isolate isolate = <...>

isolate.send (memoryMessage)
isolate.send (objectReferenceMessage);

---- receiver ----

Message msg = isolate.receive ();
javax.isolate.Heap heap = ((MemoryMessage) msg).getHeap ();

Message msg = isolate.receive ();
Object obj = ((ObjectReferenceMessage) msg.getObject ();
jDesktopPane.add ((JInternalFrame) obj);
--
www.citizens-initiative.org <http://www.citizens-initiative.org/>

--- End Message ---

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]