[Pharo-project] [Ann] Ephemerons for Cog

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Tue May 24 10:15:52 EDT 2011


On 24.05.2011 15:30, Chris Cunnington wrote:
> On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision at gmail.com  <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>>  wrote:
> >/  "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 dependents
> />/  alive."
> /
>
> >  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.

Cheers,
Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20110524/a5257c54/attachment.html>


More information about the Pharo-dev mailing list