[Vm-dev] Ephemerons - hope it is right this time :)

[Igor Stasenko]

On 2 June 2011 21:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Igor,
>
> On Thu, Jun 2, 2011 at 5:00 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>
>> I have corrected implementation, hope it is right this time :)
>>
>> If Ephemeron's key is almost-collectable (reachable only by ephemeron itself),
>> then it is reported to image side.
>
> That's not right.  The correct definition is "reachable only by ephemerons" (plural).  The way to think about it is that at any stage in the GCs trace it has traced from the roots up to, but not through ephemerons that have keys not reachable from the roots.  So it has collected the current set of ephemerons whose keys are only reachable from ephemerons.  This set of ephemerons are to mourn (be activated, to be queued for finalization) since their keys are otherwise unreachable.  This set is added to the finalization queue and now tracing continues through those ephemerons.  This subsequent tracing may also encounter a new set of ephemerons whose keys are only reachable from ephemerons.  So this set is added to the finalization queue and so on until no more objects can be traced.  The GC can now finish and all the ephemerons in the finalization queue can mourn their keys.
> This is really important as it allows one to add mounr behaviours independent of a particular object.  One can have more than one mourn action, each occurring through a different ephemeron.

> And that reminds me, in your implementation how is an object marked as being an ephemeron?  Is it a header bit or does it depend on a class?

i didn't wanted to add new special object, so to tell if given object
as ephemeron there are multiple checks:
  - an object has weak slots
  - an object has at least 2 inst vars
  - first inst var points to an instance of ClassWeakFinalizer
the above conditions are same as for weak finalization scheme which i
introduced before.
Now, if instance of ClassWeakFinalizer has 2nd instance variable == true, then
the object in question is ephemeron.

(the list of conditions is a bit long, but i just don't want to add
new special object(s), and actually the overhead is not that much ;)

Btw, i think that i found a generic "object markers" scheme, which
allows to mark an object as a special one, but dont put too much
constraints to the object itself:
imagine that an object is special, if its first ivar points to an
instance of ClassSpecialObject
and then that instance could also contain an instance variable, like a
small int number , which denoting, what kind of special object it is.

With such markers, we easily could have 2^31 various kinds of special
objects, without need of extending special objects array at all.
Another way is to use unique instances of ClassSpecialObject to denote
a kind of special object. But then image side needs to have a
registeration mechanism and communicate with VM for registering them.
Anyways,by putting in a first inst var an instance of
ClassSpecialObject, it quite cheap to check then, if given object is a
"special one".

> If it depends on a class that's an unsatisfactory, but acceptable limitation, since we can't create different types of ephemeron for different tasks.

As you can see from the list of conditions above, you can use any
class for ephemeron. Or just subclass Ephemeron class, which is what i
expect will be most often used.

> Instead, if we want different mourn behaviours they have to be based on some mapping from ephemeron to something else, such as the >dictionary an ephemeron is in (ephemerons are specifically designed to look like Associations so they can liv comfortably in Dictionaries).

Sure, at image side there is a way to decide how to mourn ephemerons
one way or another.
VM are not participating in it (it just reports ones), so there is
virtually nothing which prevents you from implementing various
mourning actions.

My implementation allows to have ephemerons with any number of
variable slots >= 1 , means:
key only
key and value
key and many values , as many as you want

> HTH
> Eliot
>

-- 
Best regards,
Igor Stasenko AKA sig.