[Pharo-project] [Ann] Ephemerons for Cog
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. You have ephemerons to reveal the phantom reference. Bam - then the object gets collected. As this seemed to be all about dictionaries, which I take as being synonymous with namespaces if the model and the view were in separate dictionaries, then you couldn't have the problem that ephemerons solve. I wouldn't take me all that seriously here. I'm just trying to play around after reading Eliot's post three times. Smalltalk being folklore, I'm endeavoring to get you to talk about this just a little bit more. Chris
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
On 24 May 2011 16:15, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 24.05.2011 15:30, Chris Cunnington wrote:
On 24 May 2011 14:46, Chris Cunnington <smalltalktelevision at gmail.com> 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.
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.
Cheers, Henry
-- Best regards, Igor Stasenko AKA sig.
participants (3)
-
Chris Cunnington -
Henrik Sperre Johansen -
Igor Stasenko