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

Igor Stasenko siguctua at gmail.com
Tue Mar 9 00:53:22 UTC 2010


On 9 March 2010 02:45, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.
>
>
Few more word:
i assuming that accessing special objects oop is safe, because of
given line of code:
self longAt: oop + i put: nilObj.

nilObj is a special object, extracted from special objects array for
efficiency. And while it is safe to use it in that way (by replacing a
weak ref by nil), then i think it is safe to use any other object from
special objects array.
But maybe i wrong :)

>> 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list