[squeak-dev] Re: A few more arguments to instantiating object
memory based on another one
Joshua Gargus
schwa at fastmail.us
Sat Aug 16 07:46:51 UTC 2008
Klaus D. Witzel wrote:
> On Fri, 15 Aug 2008 19:24:02 +0200, Joshua Gargus wrote:
>> I think that there is a misunderstanding. I'm saying that you can
>> store a prototype of an image as a ByteArray in the main image, but
>> you wouldn't actually run a spawned interpreter using the ByteArray
>> as the object memory! You would use it to populate a separate,
>> newly-spawned HydraVM object memory.
>
> I thought about that but didn't find it interesting; this is what
> already happens when a snapshot is written and read in again.
> InterpreterSimulator, which holds the bytearray that you want (in a
> Bitmap) does this with help of its "real work" superclasses. No need
> to develop that again, IMHO.
>
Not develop it again, just use it.
>> It would actually be pretty funny to implement it the way you thought
>> I meant, in the same way that Intercal and Lolcode are funny (except
>> this would be more of an inside joke). But certainly not practical!
>>
>> (hmm, maybe we could combine them... you could spawn a new
>> interpreter with the command "I can has new interpreter?"... what do
>> you think?)
>
> Snapshit can't baby has? More humor and more imperatives, please :)
> Lolcode and Intercal are not easy for people sans English mother
> tongue :)
>
:-)
>>>> 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.
>>>
>>> When creation of bytearray versus creation of separate heap can be
>>> ignored, there would be no difference in terms of performance (it's
>>> all oops all the way down, anyways). Only that bytearrays are not
>>> usable for parallel processing.
>> Now that the confusion above has been cleared up...
>>
>> Wouldn't it be faster to spawn a new object-memory from an image in a
>> ByteArray (which requires a memcpy() and a single pass through the
>> image to relocate oops by a fixed amount)
>> compared to the scheme that Igor describes?
>
> No, there a lot of disadvantages with this. Lets' say that computing
> the desired object graph takes a minute, +100 milliseconds for your
> single pass. And thereafter your ByteArray is unusable, because for
> every change (or is it bug free? and maintenace free?) you have to go
> through the whole process again.
>
I'm trying to be clear that I think that Igor's idea is a promising way
to develop and create new object-memories. I'm simply suggesting that
once you've created an object memory (using Igor's method, or via a
declarative specification, or whatever), then it is possibly better to
have production code spawn new interpreters from a "snapshot image".
> So what is wrong with holding the desired object graph in an array
> (sometimes two arrays)?
Nothing, when you're developing. But when I have a running production
system and I decide that I need to spawn a new interpreter, I want it to
happen as fast as possible. I don't want to be doing fancy traversals
of an object graph, I'd rather memcpy() a pre-created image and run
through it once to fix offsets.
> If you really want bytes (a BitMap) out of this then you can put it
> things a new and idle Hydra thread+heap and push the button with the
> "snapshot" label on it, there you go.
Sure, that's a fine way to implement it. I don't care how it's
implemented, although simpler and reusing existing code is better.
>
> Perhaps we misunderstand each other on what the content of the object
> graph / your bytearray is?
I think that you misunderstand the contents of my bytearray; it's just a
"snapshot image" (which could, as you suggest, be created by pushing the
"snapshot" button).
It's possible that I'm overestimating the speed advantage of starting up
from a snapshot compared to creating an object-memory via Igor's method,
but I believe that I understand his general approach.
Cheers,
Josh
>
> /Klaus
>
>> (snip the rest, where we are in agreement)
>>
>> Cheers,
>> Josh
>>
>
>
More information about the Squeak-dev
mailing list
|