[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Tue Mar 3 19:43:40 UTC 2009

On 03/03/2009 12:13 PM, Bob Lee wrote:

On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd <david.lloyd at redhat.com_ _<mailto:david.lloyd at 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.

More information about the core-libs-dev mailing list