On 03/03/2009 12:13 PM, Bob Lee wrote:
On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd <david.ll...@redhat.com
<mailto:david.ll...@redhat.com>> wrote:
If not, then there is no automatic solution possible, even with
special VM ephemeron support (this basically IS an ephemeron
implementation, after all, albeit a specialized one).
Actually, your approach is not the same as an ephemeron at all. See
http://en.wikipedia.org/wiki/Ephemeron:
"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 be 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 only 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."
All you've done is chosen a different weak association type. You're
chosen type works in some situations, but it breaks others. Ephemerons
work (in the sense that they're cleared automatically) in all
situations. This can't be emulated in the libraries.
No, actually what I've implemented *exactly* matches this definition: a
mapping where the value is held strongly until the key is known to be
garbage collected (even when the value has a reference back to the key).
The only difference between what I've done and a "real" ephemeron is that
presumably a "real" ephemeron will be able to associate the value with ANY
object, without there having to be a field for the value on that object
(this is what they're referring to by "association type").
The Class is the ephemeron key, and the GC knows it can clear the
ephemeron when the Class is no longer strongly referenced outside of the
ephemeron value.
Precisely.
- DML