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

[David M. Lloyd]

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.

- DML