<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Igor Stasenko wrote:
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap="">2008/8/15 Joshua Gargus <a class="moz-txt-link-rfc2396E" href="mailto:schwa@fastmail.us"><schwa@fastmail.us></a>:
</pre>
<blockquote type="cite">
<pre wrap="">(Wishing myself more success with writing this email before sending it :-) )
Igor Stasenko wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi folks,
soon Hydra will provide a support to instantiate new interpreter
instance from current object memory, e.g. not based on images which
residing on file system.
The main focus for this feature is to create a tiny images, with
limited behavior for off-loading processing from main interpreter to
separate worker interpreter.
Since Hydra already has mechanisms to transfer data between
interpreters, the need in initially packing new image(s) with data is
minimal.
The most important (and interesting) IMO is to define and transfer a
behavior (classes & their methods) which is minimal for solving some
problem in its domain.
</pre>
</blockquote>
<pre wrap="">Not that it's immediately relevant, but keep in mind that we'll eventually
want to be able to share behavior between images. Possibly the most
important thing is how much happier this will make the L2 caches on future
multi-core chips.
</pre>
<blockquote type="cite">
<pre wrap="">Now, why i think its more convenient than having separate images?
</pre>
</blockquote>
<pre wrap="">If you had to pick between one or the other, I can see how your argument
makes sense. However, I don't see why you can't trivially have both.
Furthermore, there are use-cases where the ability to load an image from
disk (or from the network) might be useful. More on both of these points
below.
</pre>
</blockquote>
<pre wrap=""><!---->
You can load & run image from disk. This feature is main one in
initial release of Hydra.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">First it is easier to support and distribute: you having a single
'bloated' main image which carrying all necessary code & data and
don't need to build a bunch of small images and manage them in
distribution.
Firing new interpreter instance through copying data from base heap to
new heap could be even faster than reading & running image from file,
because no disk i/o and all operations performed in memory.
</pre>
</blockquote>
<pre wrap="">This seems like an unfair comparison. A better comparison would be
comparing your method to running an image once it has already been loaded
from a file (since, of course, you can store an image as a a ByteArray in
memory just as easily as you can store your object-graph-array).
</pre>
</blockquote>
<pre wrap=""><!---->
Hmm, why its unfair? the difference lies only in the place where VM
getting info for creating new instance of interpreter:
a) by loading image from disk
b) by cloning provided set of objects to new heap from existing one.
</pre>
</blockquote>
We both agree that loading from disk is slow, and that b) can be faster
than a) because of it. However, you are the one who is arguing that
this speed difference is in itself a reason to prefer cloning a set of
object to loading an image. Since the speed difference is erased when
the image starts off as a ByteArray rather than on disk, this part of
your argument is not valid.<br>
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap="">
the rest of operations for creating and initializing new interpreter
instance is same.
Of course, producing new image is process based on some heuristics
using base image, this could take much more time, of course. But as i
said, it could be compensated by keeping precalculated data in base
image.
The extra memory requirements for two arrays (which representing new
image) can't be compared with full object memory snapshot which you
need to keep separately on disk.
</pre>
</blockquote>
That's not true. In a deployment image (ignoring developement), the
main image could contain only ByteArrays representing the images to be
spawned; the arrays you describe (and the objects they contain) would
have been garbage-collected. Therefore, the memory required is the
same.<br>
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">A primitive, which doing copy & run takes two arguments: an array of
object refs to be cloned into new heap and array of stubs in a form of
pairs (oop + index of oop in first array which will replace reference
to original oop).
Before doing anything, the primitive check if given arguments forming
a closed object memory graph e.g there is no references outside of it.
These two arrays can be pre-generated and sit in base image, so you
may have different sets of precalculated graphs for different needs
and then simply spawn new interpreter(s) at system startup.
Also, as far as you controlling development & distribution cycle, you
can keep such arrays within image and recalculate them when it needs
to.
And you can always include any mechanisms for error handling in
mini-images which could tell if anything goes wrong (like handling
unknown messages, catching bugs etc).
Also, i'm looking forward for integration with Spoon main feature -
behavior imprinting, when consumer image asks provider image to
deliver behavior required to run some code.
</pre>
</blockquote>
<pre wrap="">The technical details of your approach sound good to me (without having
thought deeply enough to provide truly constructive criticism). However...
My main concern is that your argument against separate images is
disingenuous. They won't be slower if you store them as ByteArrays within
the main image. In fact, I believe that the opposite would be true; don't
you agree? From a performance standpoint, it seems like separate images are
the better option.
</pre>
</blockquote>
<pre wrap=""><!---->
Well, if you want to do a real-time spawn & kill dozens interpreters,
then i need to disappoint you:
for initializing new interpreter instance there a lot of things
besides loading new image in memory which could make this process
really slow. First of all - this is initialization of plugins &
interpreter states.
Of couse, this could be improved by postponing plugin initialization
up to point where it really needed, but i think it will be hard to do
with current VMMaker design.
</pre>
</blockquote>
You would know better than I. If it turns out that
image-loading/object-cloning is not the bottleneck, then the
performance issue is moot (and is therefore still not a good argument
for preferring cloning vs. loading a ByteArray image ;-) )<br>
<br>
Besides, as you hint at, it makes sense to spawn/kill interpreter quite
infrequently. Instead of firing up an interpreter to perform one task
and then killing it, it makes more sense to treat it as a work-queue
processor that is idle when there is nothing to do.<br>
<br>
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Separate images allow (security implementations aside) nifty things like
mobile code... I can download an image from a server or a P2P network and
run it in my image. I don't yet know what I would do with this ability, but
as we ge more experience with the object-capability security model (hello
Newspeak!) I'm sure that there will be no shortage of good ideas.
</pre>
</blockquote>
<pre wrap=""><!---->
Surely, one could use a bytearray to instantiate new image.
Even now, you can just write new image to temp file first and then
instantiate new interpreter from that image.
And then, later we can add a primitive which could simply take new
image from bytearray.
This could be useful, but not very valuable to my thinking, since its
not adding anything new in the ways how new images could be produced.
</pre>
</blockquote>
If your main goal is to explore new ways to produce new images, then
you're right, this is not valuable at all.<br>
<br>
However, if your goals also include exploring new ways to deploy
images, then I think that it is worth thinking about.<br>
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap="">Also, don't forget about possible future use cases, when we possible
meet with model how to support cross-heap references by making images
interconnected with each other using far referencing.
With this hypothetical model, you will not need to form a closed graph
of objects, you just define a set of objects which will be cloned into
new heap, while rest references will be threated by VM as far
references to base heap.
</pre>
</blockquote>
That's interesting. I wasn't thinking of that, thanks.<br>
<br>
I'm curious about what the object-capability folks would think of this,
as opposed to loading images from ByteArrays and explicitly "injecting"
the capabilities (far-refs) that you want the spawned image to have.
Seems like it would be easy to accidentally grant more authority than
you intend.<br>
<br>
Nevertheless, it's a very cool thought.<br>
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Of course, these separate images need to be built somehow, and it seems to
me that this is where your ideas fit in (for development more than
deployment).
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, what i actually proposing is the way how you can build image &
run it without doing any file/stream based i/o, also conserving memory
space by reusing/copying already existing objects in original image.
</pre>
</blockquote>
Pardon me for missing some context whilst jumping into the middle of
this discussion. :-)<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<blockquote
cite="mid:4a5f5f320808150127s176dc5bbg5c8db5f21543cc33@mail.gmail.com"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Josh
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>