On 25 May 2010 07:47, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, May 24, 2010 at 9:35 PM, Igor Stasenko siguctua@gmail.com wrote:
Hello, i updated the weak finalization classes.
I made its behavior/protocol similar to old WeakRegistry, also all weak registry tests on new class is green.
First, file in .st then .cs
Also, don't forget about special objects array: http://bugs.squeak.org/view.php?id=7525
And sure thing, you will need a VM support for it.
But I am unsure, how to introduce a fallback code (and do we really need it)? I thought, that i could just add a simple startUp routine which does GC to see if new finalization supported by VM. Then it could pick either WeakFinalizationRegistry or old WeakRegistry. But then, it will slow down the image startup significantly, not saying that John fought hard to avoid full memory/heap walk during image startup on iPhone. So, maybe introduce an additional prim into VM, which will tell us if it supports new finalization? Or query the VM version?
Or store it in a flag in the image header flags word, accessed through vmParameterAt:put:. I would argue strongly that the VM should be backwards-compatible and the new mechanism is enabled by an image and that the enablement persists with the image rather than having to be reestablished on every startup. I can supply code examples which will make this trivial.
Please, do. I never dealt with #vmParameterAt:put: before.
best Eliot
I need your advice.
-- Best regards, Igor Stasenko AKA sig.