Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Subject: Re: To ClassValue or not to ClassValue: That is the question!
To: dev@groovy.apache.org
References: <572ECD0B.1070808@span.ch>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <5730460C.608@gmx.org>
Date: Mon, 9 May 2016 10:10:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <572ECD0B.1070808@span.ch>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Mon, 09 May 2016 08:11:11 -0000


On 08.05.2016 07:22, Alain Stalder wrote:
> GROOVY-7591 "Use of ClassValue causes major memory leak",
> https://issues.apache.org/jira/browse/GROOVY-7591
>
> introduced a new System Property groovy.use.shareclasses in
> Groovy 2.4.5 and 2.4.6 which is "false" by default.
>
> But this also caused follow-up issues with garbage collection
> of "Groovy" classes, which go away if setting
> groovy.use.shareclasses=true, which was also my experience.
>
> GROOVY-7683 Memory leak when using Groovy as JSR-223 scripting language
> GROOVY-7646 Classes generated by Eval() never collected from
> Permgen/Metaspace

I think 2.4.7 will have an improved version here, that fixes the memory 
problems for ClassValue and for not ClassValue. Because both versions 
are supposed to be working, unless you fall over a JVM bug.

> "Not to ClassValue" (default):
>
> Don't do this if you parse many Groovy scripts or only load
> many classes compiled from Groovy scripts - this will fill up
> PermGen/Metaspace and blow up with an "OutOfMemoryError" and
> you will see lots of MetaMethodIndex$Entry in heap dumps. (Right?)
>
> "To ClassValue":
>
> Personally, I have not observed any issues with this setting,
> with Groovy 2.4.6 - under which circumstances would I have a
> leak with groovy.use.shareclasses=true?
>
> Can this be explained in a few sentences?
>
> There has been some very recent conversation at GROOVY-7683 by
> John Wagenleitner and Jochen Theodorou, so maybe there is a fix
> for an upcoming version in preparation?

what did happen was, that the implementation for ClassValue caused some 
refactorings on the old code, which produced a difficult to diagnose 
memory leak in the old code, as well as the new code not always working. 
The problem is that the code for ClassValue itself is still in flux.. 
just last week there had been for example discussions about replacing 
the whole map used in ClassValue... with like 4 different versions to 
choose from. Anyway... as there are still things in flux we got an 
implementation that worked sometimes and under certain circumstances, 
but not always. But I am positive those problems are fixed then in 
2.4.7... it is also not that all Groovy versions are hit by this 
problem. Any version before the ClassValue change for example is 
unaffected. A general use classvalue or not, cannot be adviced really... 
it depends on the version.

> Any news on that which could already be communicated here?

I think we should work on getting a proper 2.4.7 out and then 
communicate that people should upgrade

bye Jochen