Ephemerons in 3.x

I'm trying to make sense of the ephemeron behavior in 3.x and obviously I'm missing something. I think it comes down to this, from the 3.0 release notes:
--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html

On 02/05/2013 02:26 PM, Ken Treis wrote:
> I'm trying to make sense of the ephemeron behavior in 3.x and obviously
> I'm missing something. I think it comes down to this, from the 3.0
> release notes:
>
>> When in-memory garbage collection determines that the only
>> references to an object are from an (*itself unreferenced*) ephemeron,
>> this ephemeron is “fired”.

Hi Ken,

I'm afraid that the "itself unreferenced" is incorrect. The comment in
Object>>mourn is more correct.

>
> In VW, if I understand correctly, a reference to the ephemeron itself
> doesn't prevent firing. If the ephemeron itself must *also* be
> unreferenced for firing to occur, how are these expected to be used? Are
> there any examples of usage anywhere?

Ephemeron behavior in GemStone should be very similar to that in VW, but
with fewer restrictions on what kinds of objects can be ephemerons, and
the restriction that ephemerons may not be persistent. There may be
slight differences in handling some of the exotic cases (ephemerons
referenced only through ephemerons, etc.).

Please let us know if you find any incorrect or puzzling behavior in GS
ephemerons.

Regards,

-Martin
--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html

On 02/05/2013 02:26 PM, Ken Treis wrote:
> I'm trying to make sense of the ephemeron behavior in 3.x

Hi Ken,

Here's a copy of a somewhat formal definition of ephemeron behavior I
wrote when we were working on our ephemeron implementation. This is not
definitive, and may not align 100% with the actual implementation, but
it should be close. If you happen to notice any deviations in actual
behavior from this description, I'd like to hear about it.

Regards,

-Martin


Ephemeron behavior is defined below, based on but going beyond the
original Ephemeron OOPSLA 1997 paper by Barry Hayes. Other information
on ephemeron behavior may be found in the comments of methods in
Object>Finalization.

Terms. Some of these definitions go beyond semantics documented in the
paper:

* Ephemeron: Any object whose header bits indicate it is an ephemeron.
In GemStone, an ephemeron must:
  1. Be a pointer object, and
  2. Have at least one named or indexed instance variable
  and must not be any of:
    1. An NSC
    2. A large object
    3. A committed object
    4. A kind of VariableContext, GsNMethod, GsProcess, ExecBlock,
        Behavior, or SoftReference.

* Notify: To receive a #mourn message, or to be queued to definitely
receive #mourn soon. At notify time, an ephemeron becomes no longer an
ephemeron.

* GC cycle: One complete cycle of all phases of GC. For a mark-sweep
collector, a full mark-sweep.

* Key: The object referred to by the first slot of the ephemeron.

* Property: An object referred to by a slot other than the first slot of
an ephemeron.

* Reachable:
  1. An object is reachable if it is one of the VM root objects, which
includes stack temporary variables.
  2. An object is also reachable if some other reachable object contains
a reference to it.

* Reference path:
  A sequence of one or more objects. The sequence starts with a root
object, and each subsequent object in the path is directly referenced
from the object before it in the path. Every reachable object has one or
more reference paths to it, and every object with one or more reference
paths to it is reachable.

* Discoverable:
  An object is discoverable if there exists a reference path to it that
does not pass through a mournable ephemeron.

* Mournable:
  An ephemeron is mournable if it is discoverable but its key is not
discoverable.

Note that the definitions of discoverable and mournable depend on each
other, so you cannot always determine whether a single ephemeron is
mournable without determining the mournability of some or all other
ephemerons.

During each GC cycle, the VM determines the set of mournable ephemerons.
Each mournable ephemeron is then notified and its ephemeron bit is
reset, making it no longer an ephemeron.

The canonical purpose of an ephemeron is to manage object properties,
though it is also useful for other things. When managing object
properties, an ephemeron:
* Associates a key object with zero or more property objects
* Allows the collection of the key object when it becomes unreachable
* Facilitates the release of the property objects when the key becomes
unreachable


The GemStone ephemeron implementation gives the developer a great deal
of flexibility in how to implement their ephemeron objects. However, in
order for ephemeron semantics to properly operate, all ephemerons must
be "well-behaved". Up until the point that the ephemeron receives the
#mourn message, it can behave as it wishes. Once it has been notified,
though, to be well-behaved, it should either:

1. Refrain from finalizing its key, or
2. Refrain from giving any other object a reference to its key, or any
of its properties that might not be discoverable.

In most cases the the response to #mourn is to quickly complete whatever
finalization of the key is required and then to nil all of its instance
variables, but this is not strictly required in order to be well-behaved.'

--
GemStone-Smalltalk mailing list
Unsubscribe: send e-mail with the word "unsubscribe" in body (without quotes) to:
  [hidden email]
Archive: http://forum.world.st/Gemstone-Customers-f1461796.html