[Vm-dev] faster snapshot support in VM?

[Igor Stasenko]

2009/7/17 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>
> OK, thanks to all,
> OS dependency is a good reason, we definitely prefer the more portable
> Smalltalk way :)
> Still, cloning an image with a HydraVM would be a portable option :)
> (Efficient if pages can be optimized for copy-on-write which is again
> an OS-dependent feature I presume...).
>
> Maybe I'll give a try in Unix just for fun, or I'll have a deeper look
> on what's going on exactly.
>

Nicolas, if your image is a complete sandbox, which using no any
external resources , then a proposed
approach makes sense. But in most cases it is not, and i don't see how
external resources, allocated by different primitives/plugins can be
safely 'cloned'/forked.
So, i think, we should focus on improving snapshot/startup code on
image side, not in VM.

> Cheers
>
> Nicolas
>
> 2009/7/17 David T. Lewis <lewis at mail.msen.com>:
>>
>> On Fri, Jul 17, 2009 at 01:36:45AM +0200, Nicolas Cellier wrote:
>>>
>>> In recent pharo thread
>>> [Pharo-project] Save and quit vs. Save - a clue to performance???
>>> it is said that saveAndQuit is amazingly fast, while save is damned slow...
>>> ... because it goes through all image startup.
>>> Cloning the vm/image could be more efficient:
>>>
>>> primFork
>>>   "return true if we are in the forked image, false in the original"
>>>
>>>   <primitive: XXX>
>>>    self error: 'fork failed'
>>>
>>> snapshot
>>>   self primFork ifTrue: [
>>>       self aboutToSnapshot.
>>>       self primSaveAndQuit.
>>>       self returnFromSnapshot].
>>>
>>
>> The primFork that you describe has been part of OSProcess for a long
>> time. The #primitiveForkSqueakprimitiveForkSqueak primitive is in the
>> unix flavor of OSProcessPlugin, so it's probably already in whatever
>> unix VM you are running today.  For what you describe, you would probably
>> want to invoke it with UnixProcess>>forkHeadlessSqueakAndDoThenQuit:
>>
>> So you can just try it and see if it gives the performance you want.
>>
>>> Apart being dependent on another feature of the OS, do you know any
>>> reason why this would not work?
>>
>> It definitely does work, but it is very OS dependent, and that's an
>> extremely good reason for not doing it as a general solution.
>>
>> I don't understand why save should be "amazingly slow".  What's going
>> on in the image startup that would cause this be become an issue? It
>> sounds to me like somebody is not checking the resuming flag in a
>> #startup: method, hence running a bunch of initialization code that
>> is not required after an image save.
>>
>> Dave
>>
>>
>



-- 
Best regards,
Igor Stasenko AKA sig.