8169425: Values computed by a ClassValue should not strongly reference the ClassValue

[Jochen Theodorou]

On 09.11.2016 17:47, Paul Sandoz wrote:
> Hi Peter,
>
> Good point about if such support was added it would break the API and also (with Remi) about Ephemerons.
>
> You are correct in stating the constraints in more detail regarding classes in the same loader. However, i think that is going into more detail than I would prefer for what i think is an edge case.

I would not regard that an edge case. For a dynamic language using 
ClassValue to store information, it is very easy to produce a memory 
leak with ClassValue.

> So I want in general to warn developers away from strongly referencing this ClassValue in the computed value for any associated class.
>
> If we do get strong feedback that this is a real problem we could consider adding a clever little static method like you suggest, with caveats that the computing Function might go away.

for us it is such a strong problem, that we are unable to transfer the 
old structure to use ClassValue without a major rewrite of large parts.
Just imagine a runtime that uses ClassValue and that your application, 
let it be a web application, will spawn many runtimes over time. You do 
want the runtimes and all computed values be able to be garbage 
collected. But if you will need at the same time a ClassValue to not to 
prevent a class we computed the value for from unloading and have the 
computed value alive for min(lifespan class, lifespan runtime), then you 
get a real big problem in realizing this.

As it stands for me ClassValue is only usable as a class associated 
cache with values you can recreate at any moment. That is not good 
enough for us in the general case.

If that is an edge case I still miss a major part in the 
documentation... and that is what a ClassValue should be used for 
instead of a cryptic and incomplete description of what a ClassValue is. 
And then we could talk about if the intended use and the actual 
usability fit together

bye Jcohen