[Ann] Ephemerons for Cog
Locked
 
|
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. |
|
|
What is Ephemerons?
Alexandre Le 23 mai 2011 à 20:43, Igor Stasenko <[hidden email]> 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. > |
|
|
On Mon, May 23, 2011 at 5:47 PM, Alexandre Bergel <[hidden email]> 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
|
|
|
In reply to this post by abergel
On 24 May 2011 02:47, Alexandre Bergel <[hidden email]> wrote:
> What is Ephemerons? > http://portal.acm.org/citation.cfm?id=263733&coll=portal&dl=ACM Here the paper, if Eliot's explanation is not enough. > Alexandre > > > > Le 23 mai 2011 à 20:43, Igor Stasenko <[hidden email]> 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. >> > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Eliot Miranda-2
Thanks Eliot for this description.
Alexandre On 23 May 2011, at 23:28, Eliot Miranda wrote: > > > On Mon, May 23, 2011 at 5:47 PM, Alexandre Bergel <[hidden email]> 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 <[hidden email]> 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. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: [Ann] Ephemerons for Cog
|
|
In reply to this post by Eliot Miranda-2
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 <[hidden email]> 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 <[hidden email]> 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. > > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |