May 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Discussion about pharo with James robertson.

by StÃ©phane Ducasse

http://www.jarober.com/blog/blogView?showComments=true&printTitle=IM_29:_Ph… Stef

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Igor Stasenko

On 24 May 2011 15:20, Toon Verwaest <toon.verwaest(a)gmail.com> wrote: > On 05/24/2011 02:57 PM, Igor Stasenko wrote: >> >> On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision(a)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." >>> >>> When I hear "global dictionary" I think of a namespace. Perhaps >>> namespaces >>> could add efficiency to the GC. >>> >> I don't see how this could improve anything. >> During full GC, it has to mark all reachable objects, because those >> which won't be marked will be reclaimed. >> >> So, how presence of namespaces could make GC faster? > > If you know up-front that the namespace doesn't disappear, you could > separate those objects from the rest of the objects (in a separate heap) and > avoid marking/sweeping altogether. Basically a multi-heap generational GC; > with namespaces rather than just generations based on age. > Pointers going from one heap to another would have to go over a handle > table, as is usual... > Yes. Object spaces with gates between them. But this is orthogonal to Ephemerons. -- Best regards, Igor Stasenko AKA sig.

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Alexandre Bergel

Good point Toon. This is what HotSpot does actually. Alexandre On 24 May 2011, at 09:20, Toon Verwaest wrote: > On 05/24/2011 02:57 PM, Igor Stasenko wrote: >> On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision(a)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." >>> >>> When I hear "global dictionary" I think of a namespace. Perhaps namespaces >>> could add efficiency to the GC. >>> >> I don't see how this could improve anything. >> During full GC, it has to mark all reachable objects, because those >> which won't be marked will be reclaimed. >> >> So, how presence of namespaces could make GC faster? > If you know up-front that the namespace doesn't disappear, you could separate those objects from the rest of the objects (in a separate heap) and avoid marking/sweeping altogether. Basically a multi-heap generational GC; with namespaces rather than just generations based on age. > Pointers going from one heap to another would have to go over a handle table, as is usual... > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Igor Stasenko

On 24 May 2011 16:15, Henrik Sperre Johansen <henrik.s.johansen(a)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.

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Henrik Sperre Johansen

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

May 24, 2011

[Pharo-project] [Ann] Ephemerons for Cog

by Chris Cunnington

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

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Toon Verwaest

On 05/24/2011 02:57 PM, Igor Stasenko wrote: > On 24 May 2011 14:46, Chris Cunnington<smalltalktelevision(a)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." >> >> When I hear "global dictionary" I think of a namespace. Perhaps namespaces >> could add efficiency to the GC. >> > I don't see how this could improve anything. > During full GC, it has to mark all reachable objects, because those > which won't be marked will be reclaimed. > > So, how presence of namespaces could make GC faster? If you know up-front that the namespace doesn't disappear, you could separate those objects from the rest of the objects (in a separate heap) and avoid marking/sweeping altogether. Basically a multi-heap generational GC; with namespaces rather than just generations based on age. Pointers going from one heap to another would have to go over a handle table, as is usual...

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by Igor Stasenko

On 24 May 2011 14:46, Chris Cunnington <smalltalktelevision(a)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." > > When I hear "global dictionary" I think of a namespace. Perhaps namespaces > could add efficiency to the GC. > I don't see how this could improve anything. During full GC, it has to mark all reachable objects, because those which won't be marked will be reclaimed. So, how presence of namespaces could make GC faster? > Chris -- Best regards, Igor Stasenko AKA sig.

May 24, 2011

[Pharo-project] [Ann] Ephemerons for Cog

by Chris Cunnington

"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." When I hear "global dictionary" I think of a namespace. Perhaps namespaces could add efficiency to the GC. Chris

May 24, 2011

Re: [Pharo-project] [Ann] Ephemerons for Cog

by StÃ©phane Ducasse

thanks for the explanation... it is a nice form of the drawings we have on our boards. Igor implemented them since he could not resist. Stef On May 24, 2011, at 5:28 AM, Eliot Miranda wrote: > > > On Mon, May 23, 2011 at 5:47 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > What is Ephemerons? > > Smart associations that can be used to implement per-object finalization. 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. If the only references to objects referred to by ephemeron keys are through the other fields of ephemerons with otherwise unreachable keys then the these objects are collectable. The garbage collector works in two phases. First it traces all objects from the roots, topping the trace at any ephemeron whose key is unreachable. The second phase then loops until a fixed point is reached; all ephemerons with unreachable keys are added to the finalization queue and the objects reachable from the key and the ephemeron's other fields are traced. Any ephemerons with unreached keys are added to the finalization queue. This phase continues until no more ephemerons are found. Then, if the finalization queue is non-empty, the GC signals the rest of the system that there are finalizable ephemerons. The image then takes over, drain ing the ephemerons in the queue and sending e.g. mourn to each ephemeron which can then send finalize to its key and remove itself from any dictionaries in which it exists, allowing it and its key to be garbage-collected after finalization. > > What's the rationale? Often one wants to associate state with finalizable objects, such that that state refers back to the finalizable obejcts. The classic examples are views in MVC. RThe views are dependents of some model and we may want want the model to be finalized when no object (including dependents) refer to the model. But we don't want references from the dependents to keep the object alive. 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. If we replace the association with a weak key association then the references from the dependents back to the model keep the model alive. But with ephemerons there is an implicit switch, implemented by the GC, that causes the system to exclude references from the transitive closure of the dependents unless the model is reachable from the roots, excluding references from ephemeron keys. > > So ephemerons provide a mechanism for providing per-instance finalization and property lists (dependents being a special case of property list). They allow the system to detect when an object is reachable from the roots, excluding an arbitrary set of references (reachable from an ephemeron's other fields) which do not count towards an object being considered live. They allow for finalization to be managed by the system, above the VM, while the VM's job is just to determine reachability and liveness. > > make sense? clear as mud? > > best, > Eliot > > > Alexandre > > > > Le 23 mai 2011 Ã 20:43, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : > > > I felt a bit hacky today and decided to implement Ephemerons. > > > > I tried to run it on both StackVM and Cog VMs, > > it seems to work fine (at least all 4 tests, which my brain were > > capable to produce, are green. ;) > > > > > > You can find the VM code on SqS/VMMaker in package: > > VMMaker-oscog-IgorStasenko.67 > > > > Also, i created a separate issue on Cog issue tracker to track it. > > http://code.google.com/p/cog/issues/detail?id=44 > > > > The implementation may contain a bugs. So, it needs review and testing. > > Now i would like all interested parties to give a feedback and help > > integrating it into our production images. > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > >

May 24, 2011