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