[Vm-dev] Re: [Pharo-project] [Ann] Ephemerons for Cog

Igor Stasenko siguctua at gmail.com
Tue May 24 17:38:23 UTC 2011


On 24 May 2011 18:42, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Tue, May 24, 2011 at 9:09 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> On 24 May 2011 16:58, Javier Burroni <javier.burroni at gmail.com> wrote:
>> >
>> > Hi Igor,
>> > It's great you have implemented Ephemerons. I'll take a look to the code asap.
>> >
>> > I've sent the following mail to the VSWE-L list like a month ago. It
>> > may (or may not) be useful for you
>> > saludos
>> > jb
>> >
>> The mail you posted is hard to follow for me, because
>> i don't really understand what 'rescued ephemeron' means.
>> Is it the one who initially seen without its key being marked, but
>> then after full graph traversal
>> has it key marked?
>
> In the above a rescued ephemeron is an ephemeron with an unreachable key, an ephemeron which should be finalized.  I don't think it is good terminology.  I prefer bereaved ephemeron, since a bereaved ephemeron is one referring to an object that would die were it not for the reference from ephemerons.  Other less poetic terms would be triggered, or active.
>

oh.. so it is straightly opposite to what i was assuming.
As to me there are no need for special terminology: it just an
ephemeron who lost its key (because it turns to be the garbage). As a
consequence of that, it no longer referencing its value strongly.


Btw, since i was reusing my previous finalization scheme for
ephemerons, when ephemeron's key dies, you will be automatically
notified, and could do anything you want for finalizing them.
Except that i didn't yet thought deeply, what better scheme we could
use there. But this is at image side anyways.

But it is more than that. You can get multiple notifications at
different stages of ephemeron:
 - as i said, you got notification, once its key dies
 - but later, if you keep ephemeron and don't throw it away, you could
also get a notification once its value dies.
 - of course if both key and value dying at the same moment (within
single GC cycle), then you got only single notification.

(btw, by writing this, i found a bug, which are already fixed).

There was a caveat with finalization which calls #weakFinalizerCheck:
for each weak reference replaced by nil for a single object.
It is incorrect, because if analyzed object contains more than 1 weak
reference, then it will call this method twice in a row, and will
create a loop in a list

list head == oop
oop next == oop

and the list tail will be lost.

The existing images are not affected by this bug, just because in
WeakFinalizerItem there is only 1 weak reference which could die,
so it is impossible by construction.

But not with Ephemerons: since for Ephemerons both key and value could
die at once, and it will trigger this bug.
So, i had to fix the #weakFinalizerCheck: to put finalizable oop into
the list only when it's 'next' field are nil.


-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list