[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-mlvm-dev
Subject: Re: Number of Apps per JVM
From: Mark Roos <mroos () roos ! com>
Date: 2014-01-13 18:13:00
Message-ID: OFCF7D9BFB.FAF9CCC3-ON88257C5F.0061D02E-88257C5F.00641196 () roos ! com
[Download RAW message or body]
This is a multipart message in MIME format.
This is a multipart message in MIME format.
--=_alternative 0063DDCE88257C5F_=
Content-Type: text/plain; charset="US-ASCII"
Both the Waratek and IBM multi Tenant JVMs demonstrate that the options of
one app per jvm
or many apps per jvm can be efficient and isolated. But I believe that
both of these require that
objects be serialized in order to be sent between apps. My question was
about avoiding the cost
of this serialization.
My use case is one of the parallelization of a operation across several
cores. It would be convenient
to split the tasks to each core while enforcing cross core immutable state
but allowing in core
mutable state. Kilim approaches this by controlling the references
between objects such that one
can transfer an object to another sandbox by ensuring that the objects are
only referenced via the
roots of the sandbox ( thus making them invisible within other sandboxes).
One could think of
this as relinking a set of objects. Squeak ( a Smalltalk ) had the
concept of image segments which
would be like a GC/heap region. These could be connected and disconnected
via a single reference.
All of these seem to require an object structure designed to support this.
What I was wondering
is if anyone as seen an alternative approach which would not need to know
which objects may need
to be moved.
Think of this as an Actor model where objects can be passed as parts of
messages
thx
mark
--=_alternative 0063DDCE88257C5F_=
Content-Type: text/html; charset="US-ASCII"
<font size=2 face="sans-serif">Both the Waratek and IBM multi Tenant JVMs
demonstrate that the options of one app per jvm</font>
<br><font size=2 face="sans-serif">or many apps per jvm can be efficient
and isolated. But I believe that both of these require that</font>
<br><font size=2 face="sans-serif">objects be serialized in order to be
sent between apps. My question was about avoiding the cost </font>
<br><font size=2 face="sans-serif">of this serialization.</font>
<br>
<br><font size=2 face="sans-serif">My use case is one of the parallelization
of a operation across several cores. It would be convenient</font>
<br><font size=2 face="sans-serif">to split the tasks to each core while
enforcing cross core immutable state but allowing in core</font>
<br><font size=2 face="sans-serif">mutable state. Kilim approaches
this by controlling the references between objects such that one</font>
<br><font size=2 face="sans-serif">can transfer an object to another sandbox
by ensuring that the objects are only referenced via the</font>
<br><font size=2 face="sans-serif">roots of the sandbox ( thus making them
invisible within other sandboxes). One could think of</font>
<br><font size=2 face="sans-serif">this as relinking a set of objects.
Squeak ( a Smalltalk ) had the concept of image segments which</font>
<br><font size=2 face="sans-serif">would be like a GC/heap region. These
could be connected and disconnected via a single reference.</font>
<br><font size=2 face="sans-serif">All of these seem to require an object
structure designed to support this. What I was wondering</font>
<br><font size=2 face="sans-serif">is if anyone as seen an alternative
approach which would not need to know which objects may need</font>
<br><font size=2 face="sans-serif">to be moved. </font>
<br>
<br><font size=2 face="sans-serif">Think of this as an Actor model where
objects can be passed as parts of messages</font>
<br>
<br><font size=2 face="sans-serif">thx</font>
<br><font size=2 face="sans-serif">mark</font>
--=_alternative 0063DDCE88257C5F_=--
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic