An ephemeron is a data structure that solves two related problems in garbage collected systems. On the one hand, an ephemeron provides a notification when some object is about to be collected. On the other hand, an ephemeron allows data to be associated with some object without creating a reference to that object that will prevent the object from being collected. An ephemeron is a key-value pair, where the key is the object that the ephemeron guards, notifying the system when that object is collectable, and the value can be any data associated with the object such as a property list, and which may be empty. Since the elements of the property list may refer back to the key, they may prevent collection of that key. But the ephemeron is treated specially by the garbage collector. The value field is not traced until the key is found to be reachable from the system roots other than through ephemeron keys. The set of ephemerons whose keys are only reachable from ephemeron keys are then holding onto keys that are ready to be collected; these objects are not reachable from the roots except through ephemerons. When the garbage collector detects such a set, the ephemerons are queued for notification and their keys and values are traced. Hence ephemerons both detect objects that are ready for collection and break the cycles that can prevent objects from being collected.
In computer science, finalization occurs when a garbage collector (GC) informs an application that an object is "almost collectable". It is used to help an application maintain its invariants. Weak references may be used by a garbage collector to determine the objects that are almost collectable. Seen both as key-value pairs, the main difference between weak references and an ephemerons is the way the garbage collector treats them. For weak references, the garbage collector always follows the value in the key-value pair. For ephemerons, instead, the garbage collector doesn't follow the value but queues the ephemeron for further observation at a second stage: after the first tracing phase is done, it runs through the queue looking at each ephemeron and if its key was seen, then it follows its value. This subtle difference impacts in graphs with some kinds of cycles, where weak pairs do not describe correctly that an object ought to be "almost collectable". For example, consider a key-value pair with weak references where the key is an object and the value is a set of properties attached to the object. It is expected that when the object is ready to be collected, the properties will also go away. But if the value, possibly transitively, maps to its own key (the object), then the object will never be collected. If an ephemeron was used instead, the value wouldn't have been followed unless the object was proved alive, solving the cycle. Ephemerons are similar to weak pairs, but an object in an ephemeron's key field may be classed as "almost collectable" even if it is reachable from the ephemeron's value fields.[1]
An ephemeron is an object which refers strongly to its contents as long as the ephemeron's key is not garbage collected, and weakly from then on. Ephemerons solve a problem which is commonly found when trying to "attach" properties to objects by using a registry. When some property should be attached to an object, the property should (in terms of GC behavior) typically have the life-time that an instance variable of this object would have. However, this is complicated by having an external association between the object and its property such as:
property --------- registry --------- association --------- object
Here, the registry (a third party) will hold onto the association itself which would require manual removal from the registry (instead of automated garbage collection). While this problem can always be solved in any given concrete situation by using one of the various weak association types, choosing the 'right' kind of association depends on a variety of factors some of which can change dynamically.
Ephemerons solve this problem by defining that the 'contents' (value) of an ephemeron will be held strongly until the key is known to be garbage collected. From then on, the contents of the ephemeron will be held weakly. Therefore, the contents of an ephemeron can become eligible for garbage collection if and only if the key is garbage collectable which is the exact behavior which we would observe for an instance variable of the object.
Ephemerons were first invented by George Bosworth while he worked at Digitalk. They were used as the finalization mechanism in Visual Smalltalk Enterprise. Today ephemerons are available in most Smalltalk dialects as well as many other languages with automatic garbage collection.
Several dialects of Smalltalk include ephemerons as built-in features or as additional packages. For example, GNU Smalltalk[2] and Squeak.[3]
Lua does not contain a separate ephemeron construct, but its table data structures may be set to holds its keys, values, or both in a weak fashion. If the keys are held weakly, but values are held strongly, the table will act like an ephemeron. Lua 5.4 also introduces metatable behavior that helps to construct ephemeron-like data structures.[4]
Languages such as C#, F#, and VB.NET, as of .NET Framework 4.0, have support in the ConditionalWeakTable class.[5] The underlying ephemeron mechanism (DependentHandle) used to be private until .NET 6.
An implementation of an OCaml ephemeron type was presented in 2014[6] and added to the standard library in release 4.03.[7]
The Racket dialect of Lisp has support for ephemerons in its runtime system. There, ephemerons are used in combination with weak mappings to allow the garbage collector to free key-value pairs even if the value holds a reference to a key.[8]
A SRFI (Scheme Request for Implementation) defines an API for Ephemerons for the Scheme language.[9] However, not all Scheme implementations support all SRFIs.