[Vm-dev] [ENH] A better finalization support (VM & language side)

Igor Stasenko siguctua at gmail.com
Tue Mar 9 00:45:30 UTC 2010


On 9 March 2010 02:06, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> Thanks Igor - if you have been implementing what you've described in this
> email I'm all for it. Give me a bit of time to review the code since this
> stuff can be tricky.
>
> One thing I do recall and that you may want to check is that testing class
> membership can be tricky during GC - in fact, the introduction of a weak
> format was due to issues with determining the class of some object
> correctly. Unfortunately, I do not recall the exact details but it's
> worthwhile going through this very carefully and make sure that one can
> actually rely on a) the class pointer being valid (and not substituted while
> traversing the object) and b) the pointer in splObjs be valid (and not
> substituted).
>
> I'll give this special attention while looking through the code.
>

Yes, this is a biggest of my concern.

Also maybe i should use a #longAt:put: , or uncheckedXXX put: (forgot
the selector)
instead of
self storePointer: 1 ofObject: oop withValue:

because storePointer using the possibleRootStoreIntoValue(), which
could have unwanted effects :)

Maybe it could help you with analyzis:
 - the code touching a strong references , where all of them is
already marked as reachable
(because oop is reachable, and hence the list ivar, and hence the
list's 'first' ivar).
So, its only rearranging them a bit, but doesn't making none of them
unreachable, or even worse - making an already non-reachable object be
reachable again.

- the weak finalization check runs during sweep phase before
compaction. Which means, that objects is not changing their locations
during that phase.


> Cheers,
>  - Andreas
>
> On 3/8/2010 3:14 PM, Igor Stasenko wrote:
>>
>> Oh, and this actually an implementation of idea, we discussed earlier
>>
>> http://lists.squeakfoundation.org/pipermail/vm-dev/2009-April/002572.html
>>
>> While its not an ephemerons, its much more easier to adopt because
>> there is no need in making heavy changes to GC.
>>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list