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

Jochen Theodorou blackdrag at gmx.org
Mon Nov 14 23:23:51 UTC 2016


resend after I did accidentally send it to Paul directly instead of the list

On 10.11.2016 21:24, Paul Sandoz wrote:
> Hi Jochen,
>
> Can you confirm if my analysis of Groovy using ClassValue was correct:
>
> https://bugs.openjdk.java.net/browse/JDK-8136353
> AFAICT in this case the issue was not with ClassValue itself but the
> storing of computed values in a global set.

Our last "solution" was not to use ClassValue at all and restore the 
faulty pre-ClassValue logic. Because not even making those weak 
references solved the problem.

> If i understand correctly you are you raising a wider issue with the
> function of ClassValue itself, it may be insufficient for your use-case,
> and not specifically with computed values strongly referring the
> associated ClassValue?
>
> Specifically, I am struggling to unpack this bit:
>
>> 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.
> Computed values can strongly refer to the associated class, it becomes
> problematic when computed values strongly refer to the associated
> ClassValue. Is that something you require?

The problem is more how to avoid that, but still get the semantics I need.

Example... have the computed value be the meta class of a class and let 
there be a class X with a static field representing the ClassValue. Now 
create the meta class of X and let say each meta class references also 
the meta class of the super class. And of course I do want to be able to 
init and destroy the runtime thousands of times without leaving garbage 
in memory.

By doing this I have a computed value strongly referencing the 
ClassValue and I do have ClassValue pinned for VM lifetime because I 
made a metaclass of Object.

A weak reference for the computed value is no solution, since we then 
would loose modifications done to the metaclasses. And this is the 
reason why we wanted ClassValue in the first place. I can also not just 
reference the ClassValue or the class containing the field, because that 
would still keep the strong reference alive.

What is for example totally unclear to me is, what happens if the 
ClassValue itself is weakly referenced and a computed value references 
the ClassValue through that weak reference. Does ClassValue then 
possibly get collected before the computed values? If "yes" it is no 
solution again, as we would again loose meta class information. And a 
"no" most likely means another memory leak.

Even if I lift the constraint of a meta class referencing its super 
class meta class - I will have meta classes of classes from java.lang.* 
and then a memory leak

So how to solve the problem?

bye Jochen


More information about the core-libs-dev mailing list