[Isolate-interest] shared heap between isolates?
Bernhard Fastenrath
bfastenrath@mac.com
Tue, 12 Oct 2004 01:55:52 +0200
This is a multi-part message in MIME format.
--------------050201040100010207060900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Pete Soper wrote:
>>Is it possible for isolates to negotiate a shared heap space?
>>
>>
> Isolate heaps are, by definition, isolated perfectly from the heaps
>of other isolates and so there is no sharing of objects available whatsoever.
>I don't think this prevents multiple isolates contributing to the rendering of
>a single GUI but it makes for a different design exercise from the more familiar
>ones where visibility can only be controlled by class loader scoping.
>
>
A part of the isolate system is the implementation of multiple heaps
inside a single virtual machine.
The isolate systems adds to this a small process control mechanism and a
messaging mechanism
while it denies any access between heaps that does not pass through the
messaging system or
is implemented outside the virtual machine.
A system that would allow to allocate and deallocate heaps within the
same virtual machine
would allow for the same partitioning as the isolate system but it would
add advanced
resource tracking to compound application, like a java desktop running
java applications
inside its own virtual machine.
While quite often less is more and the more restrictive environment
might turn out to
be the more efficient, easier to implement or in some other way superior
in this case the
ability to have multiple heaps inside the same virtual machine and even
to share heaps
between virtual machines doesn't seem to have much impact: If the
underlying hardware
system is unable to offer shared memory between different nodes or
partitions of its
hardware system the act of sharing memory between isolates would place a
restriction
on the mobility of these isolates, as they could only be relocated as a
group.
The ability to assign different memory usage patterns to different heaps
on the other hand
seems like a feature a skilled programmer might use to his advantage.
The addition of
Java-implemented garbage collectors for custom heaps comes to mind.
Verifying the existence of a heap to which an object reference is still
available can also
be very efficient: The address space used by the heap could generate a
page fault after
the heap is deallocated. If the virtual machine encounters a page fault
upon object access
a NullPointerException could be the result, so a deallocated heap would
result in dead
object references raising a very common exception upon access.
An isolate is essentially a ThreadGroup with its own heap and no
knowledge of
other thread groups or heaps, except they are introduced as isolates and
a link
is established.
--
www.citizens-initiative.org <http://www.citizens-initiative.org/>
--------------050201040100010207060900
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Pete Soper wrote:<br>
<blockquote cite="mid200410112037.i9BKbELF003904@pjs.East.Sun.COM"
type="cite">
<blockquote type="cite">
<pre wrap="">Is it possible for isolates to negotiate a shared heap space?
</pre>
</blockquote>
<pre wrap=""> Isolate heaps are, by definition, isolated perfectly from the heaps
of other isolates and so there is no sharing of objects available whatsoever.
I don't think this prevents multiple isolates contributing to the rendering of
a single GUI but it makes for a different design exercise from the more familiar
ones where visibility can only be controlled by class loader scoping.
</pre>
</blockquote>
A part of the isolate system is the implementation of multiple heaps
inside a single virtual machine.<br>
<br>
The isolate systems adds to this a small process control mechanism and
a messaging mechanism<br>
while it denies any access between heaps that does not pass through the
messaging system or<br>
is implemented outside the virtual machine.<br>
<br>
A system that would allow to allocate and deallocate heaps within the
same virtual machine<br>
would allow for the same partitioning as the isolate system but it
would add advanced<br>
resource tracking to compound application, like a java desktop running
java applications<br>
inside its own virtual machine.<br>
<br>
While quite often less is more and the more restrictive environment
might turn out to<br>
be the more efficient, easier to implement or in some other way
superior in this case the<br>
ability to have multiple heaps inside the same virtual machine and even
to share heaps<br>
between virtual machines doesn't seem to have much impact: If the
underlying hardware<br>
system is unable to offer shared memory between different nodes or
partitions of its<br>
hardware system the act of sharing memory between isolates would place
a restriction<br>
on the mobility of these isolates, as they could only be relocated as a
group.<br>
<br>
The ability to assign different memory usage patterns to different
heaps on the other hand<br>
seems like a feature a skilled programmer might use to his advantage.
The addition of<br>
Java-implemented garbage collectors for custom heaps comes to mind.<br>
<br>
Verifying the existence of a heap to which an object reference is still
available can also<br>
be very efficient: The address space used by the heap could generate a
page fault after<br>
the heap is deallocated. If the virtual machine encounters a page fault
upon object access<br>
a NullPointerException could be the result, so a deallocated heap would
result in dead<br>
object references raising a very common exception upon access.<br>
<br>
An isolate is essentially a ThreadGroup with its own heap and no
knowledge of<br>
other thread groups or heaps, except they are introduced as isolates
and a link<br>
is established.<br>
<br>
<div class="moz-signature">-- <br>
<font size="+4">
<a href="http://www.citizens-initiative.org/">www.citizens-initiative.org</a><br>
<br>
</font>
</div>
</body>
</html>
--------------050201040100010207060900--