[Vm-dev] Re: [Pharo-dev] blog post

[tim Rowledge]

> 
> Wouldn't a fixed, dedicated, class space facilitate though sharing between multiple images?
> This was a nice feature in VW, and I think it may become even more important with the trend towards multi-core.

When permspace was originally being developed it was mostly an idea to 
a) move a large chunk of the image (remember back in those days customers were screaming about the pain of having to install an entire megabyte of memory in their machines) out of the view of the general garbage collection in order to spend less time in gc
b) where possible use mmap to load 
c) where possible use mmap to share parts of the image when running multiple invocations on the same machine

I did a conceptually similar thing on the ancient Active Book variant of Eliot's BrouHaHa, but that used actually ROMmed image parts and the object table to allow any object to be modified. Again in the days of 1Mb being all you could imagine having.

Having an image format that allowed for part(s) to be fixed would be nice for application deployment. mmap sometimes allows useful space-saving and some (is it all versions by now?) can do page-copy-on-write. 

Having complete control over it ourselves would be nicer though; perhaps we could segment the image into really-truly-read-only, and rarely-written, and written-often areas. Methods are good candidates for the first, class variable dictionaries etc for the second and general run-state in the third. With suitable tricks you never even save the read-only area(s) and simply bind to them at startup. On the Active Book system I used that trick for development for several years and given the speed of disk interfaces back then it really made startup much faster. Working images were often only a few dozen kb. Lots of use cases could really benefit from a similar capability.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- A prime candidate for natural deselection.