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

[Eliot Miranda]

Hi Igor,

    you have identified a key point I was trying to explain earlier.

On Thu, Jun 2, 2011 at 5:36 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> There is one slight thing, which i had doubts about.
> Initially, when i was revising the algorithm, i followed the same road
> as in paper:
> "
> In the third phase, the collector traces the remaining objects,
> beginning at the ephemerons still on the queue. Any ephemerons
> encountered in this phase are treated as ordinary objects, and all
> fields traced’.
> "
>

This  was Barry Hayes' misunderstanding and the thing I had to fix in his
initial implementation in the VW VM, wen I finished and released VW
ephemerons.  It is not a third phase. Instead, the ephemeron detecting
process is a sub-part of GC tracing that continues until tracing reaches the
fixed point of not finding any more morning ephemerons.  Discovering a
mourning ephemeron also discovers a new root (the ephemeron) but that root
cannot be traced until all mourning ephemerons have been discovered in the
current cycle.  Once the cycle is complete then the mourning ephemerons can
be traced which in turn may discover more mourning ephemerons until the
fixed point is reached.

So the paper is wrong.  I can show you private communications between myself
and George Bosworth (the inventor of ephemerons in VSE) discussing precisely
this, but I would prefer it if you would take my word for it :)


> It means that VM will report only the topmost ephemerons (which has
> keys non-reachable from roots),
> but not consider ephemerons which are reachanble from those ones,
> which will be discovered later, when queue will be processed.
>
> The difference is, whether VM should also report nested ephemeron or not.
>

It must report nested ephemerons.


> Consider a following test:
>
> testNestedEphemerons
>
>        " test that we will get a notification from nested ephemeron"
>
>        | e key key2 val list count |
>
>        list := WeakFinalizationList forEphemerons.
>
>        e := Ephemeron newForList: list.
>
>        key := Object new.
>        key2 := Object new.
>
>        e key: key value: (
>                Array with: (
>                (Ephemeron newForList: list)
>                        key: key2 value: 1 at 2 )
>        ).
>
>        key := key2 := nil.
>        Smalltalk garbageCollect.
>
>        count := 0.
>        list finalizationAction: [:eph | count := count + 1].
>        list finalizeValues.
>
>        self assert: count = 2
>
>
> Here, the top ephemeron (e)
> should be reported as one which having almost-collectable key.
> But then VM has to mark its fields (otherwise they will be lost, and
> we don't want that before image can handle it),
> and discovers a nested ephemeron.
> But nested one also has its key almost-collectable.
> So, here the difference: should VM trace this ephemeron as usual
> object (with all slots as strong references, like paper says),
> or it should also report this ephemeron as one with almost-collectable key.
>
> By following a paper description, at this stage, a nested ephemeron
> should not be reported (so, in above test , a resulting count must be
> == 1, but not 2).
>
> This is quite obscure case (usually ephemerons not form a nested
> loops), since then it is a question, which one should be finalized
> first, and which one second.
> So, for most use cases, this difference will not affect anything.
> But if this will happen, it may lead to situation, that nested
> ephemeron won't be finalized, so you could forget to free external
> resources etc.
> That's why i think, its better to report even nested ephemerons.
> Otherwise if you finalize the topmost ephemeron and set its key (or
> values) to nil,
> then there will be no other references to nested ephemeron and it will
> be garbage collected without any notice.
> But if we report it, then image side can decide if it needs to be
> finalized or not, regardless that the only reference to given
> ephemeron are coming
> from another ephemeron , which also needs to be finalized.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

HTH
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110602/e4d5fe0f/attachment.htm