[PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)
David M. Lloyd
david.lloyd at redhat.com
Tue Mar 3 11:43:40 PST 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
> "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.
More information about the core-libs-dev