On 24 May 2011 16:15, Henrik Sperre Johansen <[email protected]> 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.
