8169425: Values computed by a ClassValue should not strongly reference the ClassValue (original) (raw)

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