[Vm-dev] faster snapshot support in VM?

Andreas Raab andreas.raab at gmx.de
Fri Jul 17 03:15:26 UTC 2009


I'll wager a guess on the "amazingly slow" startup: Freetype.

Cheers,
   - Andreas

David T. Lewis wrote:
>  
> 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
> 


More information about the Vm-dev mailing list