On 19.05.2016 21:32, Peter Levart wrote:
a ClassValue instance can be thought of as a component of a compound
key. Together with a Class, they form a tuple (aClass, aClassValue) that
can be associated with an "associated value", AV. And yes, the AVs
associated with tuple containing a particular Class are strongly
reachable from that Class.

I see, I was mixing ClassValue and AV, I was more talking about AV, than ClassValue itself, though ClassValue surely plays an important role in here. Anyway, I am going for that AV is the value computed by aClassValue.

You said that the AV is strongly reachable from aClass. Can I further assume, that aClassValue is not strongly reachable from aClass? And that aClassValue can be collected independent of aClass? Can I further assume, that aClassValue can be collected even if AVs for it continue to exist?

An AV associated with a tuple (Integer.TYPE, aClassValue) -> AV can be
garbage collected. But only if aClassValue can be garbage collected 1st.

hmm... so in (aClass, aClassValue)->AV if aClassValue can be collected, AV can, but not the other way around... what about aClass? if nothing but AV is referencing aClass, can AV be garbage collected, even if aClassValue cannot? Can I extend your statement to AV can be collected only if either aClass or aClassValue can be garbage collected first?

Let us assume this is the case for now.

This is the most tricky part to get right in order to prevent leaks. If
in above example, aClassValue is reachable from the AV, then we have a
leak. The reachability of a ClassValue instance from the associated
value AV is not always obvious. One has to take into account the
following non-obvious references:

1 - each object instance has an implicit reference to its implementing class
2 - each class has a reference to its defining ClassLoader
3 - each ClassLoader has a reference to all classes defined by it
(except VM annonymous classes)
4 - each ClassLoader has a reference to all its predecessors (that it
delegates to)

Since a ClassValue instance is typically assigned to a static final
field, such instance is reachable from the class that declares the field.

I think you can get the picture from that.

yeah... that is actually problematic. Because if I keep no hard reference the ClassValue can be collected, even if the AVs still exist... meaning they would become unreachable. And if I keep one I have a memory leak... well more about in the program you have shown me later on.

Ok, let's set up the stage. If I understand you correctly, then:

Groovy runtime is loaded by whatever class loader is loading the
application (see the comment in MetaClass constructor if this is not
true).  This is either the ClassLoader.getSystemClassLoader() (the APP
class loader) if started from command line or for example Web App class
loader in a Web container.

Well, actually... if you start a script on the command line, the loader is a child to the app class loader, when used as library it could be the app loader (for example if the groovy program is precompiled) and in a tomcat like scenario it could be either the class loader for the web app, or the loader for all web apps. But let's go with the cases you mentioned first ;)

MetaClass(es) are objects implemented by Groovy runtime class(es). Let's
call them simply MetaClass.


Here's how I would do that:

public class MetaClass {

     // this list keeps MetaClass instances strongly reachable from the 
     // class(loader) since they are only weakly reachable from their associated
     // Class(es)
     private static final ArrayList<MetaClass> META_CLASS_LIST = new 

     // this WeakReference is constructed so that it keeps a strong reference
     // to a referent until releaseStrong() is called
     private static final class WeakEntry extends WeakReference<MetaClass> {
         private final AtomicReference<MetaClass> strong;

         WeakEntry(MetaClass mc) {
             strong = new AtomicReference<>(mc);

         boolean releaseStrong() {
             MetaClass mc = strong.get();
             return mc != null && strong.compareAndSet(mc, null);

     private static final ClassValue<WeakEntry> WEAK_ENTRY_CV =
         new ClassValue<WeakEntry>() {
             protected WeakEntry computeValue(Class<?> type) {
                 return new WeakEntry(new MetaClass(type));

     // the public API
     public MetaClass getInstanceFor(Class<?> type) {
         WeakEntry entry = WEAK_ENTRY_CV.get(type);
         MetaClass mc = entry.get();
         if (entry.releaseStrong()) {
             synchronized (META_CLASS_LIST) {
         return mc;

     MetaClass(Class<?> type) {
         // derive it from 'type', but don't reference it
         // strongly if Groovy runtime is loaded by a parent
         // class loader of the application class loader
         // that loads application classes  you want
         // MetaClass(es) to be derived from.

This will keep MetaClass instances isolated from the associated classes
but still keep them reachable as long as the
MetaClass.class.getClassLoader() is alive.

Is this going to help?

partially... MetaClass will realistically have a strong reference to the class the meta class is for and a lot of other classes. I will need to reference methods and fields by reflection and at some point keep them referenced. Through the declaring class I should then again have a strong reference to the class.

1_000_000.times { Eval.me("42") }

this will create 1 million classes, in 1 million classloaders, which are a child to the class loader for the Groovy runtime. Each of them will get a meta class... ignoring the list, if the strong reference to the script class in MetaClass is here enough to prevent collection, then this is a problem. The list of course is also a problem, since keeping them alive as long as MetaClass.class.getClassLoader is alive, is actually not the semantics I need.

The semantics I need is something like lifetime(AV) is roughly min(lifetime(aClass),lifetime(aClassValue)), with AV referencing aClass not influencing it being collectable, as long as this association is the only reference to AV. If it is the max of them I am in trouble.

And seeing how aClass kind of has a strong reference to AV and that if aClassValue and AV are from the same loader and if AV has a strong reference to aClass as well, it will cause aClass not being collectable for as long as the loader for aClassValue and AV exists... because aClassValue is a static value in one of the classes, and AV is not collected before aClassValue is collected and aClass is not not collected because of the reference in AV.

The "old" solution in Groovy is to keep a "global" map with weak class keys and soft references to MetaClass. This allows in theory the class being collectable, but only if the MetaClass has been collected before.. and some VMs really do not like soft referenced classes much (forced us to use the mark and sweep gc for example). Also soft references used not always to be clean up when permgen space is low. But if they are not cleaned up, then MetaClass prevents the garbage collection of the class, causing permgen problems. Not sure how that is with meta space, but from what I have seen so far, this can still happen. And of course using SoftReference means we garbage collect relatively late, and cause a big garbage collection. I cannot use weak references, because tend to be collected to fast and creating the meta class is not exactly a cheap operation.

bye Jochen

mlvm-dev mailing list

Reply via email to