[Pharo-project] [Ann] Ephemerons for Cog
siguctua at gmail.com
Tue May 24 10:25:42 EDT 2011
On 24 May 2011 16:15, Henrik Sperre Johansen
<henrik.s.johansen at veloxit.no> wrote:
> On 24.05.2011 15:30, Chris Cunnington wrote:
> On 24 May 2011 14:46, Chris Cunnington <smalltalktelevision at gmail.com>
>> "But if the dependents are stored in some global dictionary from model to
>> sequence of dependents then the
>> reference from the global dictionary keeps both the model and the
>> So, how presence of namespaces could make GC faster?
> Well I'm hardly presuming to know, but if you have one dictionary acting as
> a global namespace. As far as I understood ephemerons, the
> problem is you have a single dictionary/namespace. Both the model and the
> view connect to an object. The model lets it go. The view
> doesn't. So this is an object you want to collect, because the model has let
> it go. This means you have a phantom reference that tricks
> the GC. That seems to me to be what ephemerons solve. I'm looking solely at
> the MVC Eliot mentioned, because shorn of context the
> description didn't mean anything to me.
> "An ephemeron holds onto some object via its key field in a quasi-weak
> manner such that the garbage collector will only consider the key live if it
> can be reached from the roots and not reachable by the ephemeron's other
> inst vars." <- This is the key property of ephemerons.
> In the case of weak Announcement actionBlock subscription:
> The block references it's enclosing methodContext.
> The methodContext receiver instvar references the object whose method
> created the block.
> Thus, if you keep a traditional WeakAssociation object -> block, (which you
> will if object is the subscriber) you will always have a strong reference to
> object from the value.
> If this were an ephemeral association, the references to key stored in value
> are not traversed by the gc, and thus object is not marked in
> use/subsequently GC'd.
So, lets start a contest for best Ephemeron class comment, describing
its essential difference from usual weak references!
Because currently , Ephemeron is not documented at all :)
>From my side, i will add a description of implementation detail.
In short: an Ephemerons actually work on top of already existing
finalization scheme which i introduced before.
Ephemerons fit nicely in this scheme , which enables a code reuse.
Igor Stasenko AKA sig.
More information about the Pharo-dev