Re: [Help-smalltalk] faster startup 2/n

[Mike Anderson]

Paolo Bonzini wrote:
> A slightly trickier one.  If we don't save directly from the object 
> area, but allocate temporary memory for that, we can save different data 
> than what is in the object memory.  So, we can kill CallinProcesses when 
> saving, and we can force looking up CFunctionDescriptor addresses the 
> first time they are called.  Finally, we can map the interpreter's 
> primitives to what is in the image, rather than patch the 
> CompiledMethods so that they match the primitive numbers that were 
> selected at compile time.

It seems to me that this has other benefits than just speed; making it 
easier to re-load images that link with C libraries.

Is it necessarily correct to kill a call-in process, though? Say the 
process in question was a GUI event that triggered a long-running 
calculation. There wouldn't be anywhere to return a result to, but it 
would be the side-effects (displaying the results in the GUI) that were 
important.

I'm interested because I'm still interested in the idea of persistent 
Smalltalk images, although I've changed direction slightly from the gsti 
idea. It would be useful to have a clear idea of what the contract is 
for an image restart.

Mike