On 24 May 2011 18:42, Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, May 24, 2011 at 9:09 AM, Igor Stasenko siguctua@gmail.com wrote:
On 24 May 2011 16:58, Javier Burroni javier.burroni@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.