Hi Jochen, Can you confirm if my analysis of Groovy using ClassValue was correct:
https://bugs.openjdk.java.net/browse/JDK-8136353 <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. 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? Paul. > On 10 Nov 2016, at 00:51, Jochen Theodorou <blackd...@gmx.org> wrote: > > > > 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
