On Sat, Feb 18, 2017 at 11:46 PM, GitHub noreply@github.com wrote:
Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 0076679f0aa45970e6774f69d84f7e81d548bc40 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/0076679f0aa45970e67... Author: Eliot Miranda eliot.miranda@gmail.com Date: 2017-02-18 (Sat, 18 Feb 2017)
Log Message:
CogVM source as per VMMaker.oscog-eem.2134
Move the SpurPlanningCompactor to tip. It is now ready for prime time. SpurPlanningCompactor is a three-finger algorithm that slides objects down to the first finger, which points at the first free object, from the first unpinned, marked object, while stepping around intervening pinned objects pointed at by the third finger.
Great to see this progress. Thanks Eliot.
Just curious about the strategy of handling pinned objects during Image save/load. Could the pinned memory possibly be considered to have been invalidated much like when the VM exits? And thus the VM could move and compress the pinned objects at some point, or automatically unpin all objects in a saved Image?
Or are their cases where the pin is useful to persist across saves? Maybe if an external library relies on one pinned object refering to the memory location of another pinned in some domain document structure? Thus it is Image's responsibility to unpin all objects to minimise Image size? I guess unpinning by the Image would be best at Image load rather when saving since the Image may continue.
cheers -ben