[Vm-dev] faster snapshot support in VM?
siguctua at gmail.com
Fri Jul 17 16:51:46 UTC 2009
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
So, i think, we should focus on improving snapshot/startup code on
image side, not in VM.
> 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:
>>> "return true if we are in the forked image, false in the original"
>>> <primitive: XXX>
>>> self error: 'fork failed'
>>> 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.
Igor Stasenko AKA sig.
More information about the Vm-dev