Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
X-IMP-AUTH_USERNAME: <astalder@span.ch>
X-Original-IP: 194.191.233.117
To: dev@groovy.apache.org
From: Alain Stalder <astalder@span.ch>
Subject: Improve Groovy class loading performance and memory management
Message-ID: <57351E2A.2070304@span.ch>
Date: Fri, 13 May 2016 02:22:02 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Fri, 13 May 2016 00:22:15 -0000

Hi everybody

I had considered to submit a major feature request for Groovy with the 
text further below, because it appears to me that there might possibly 
be considerable room for improvement, but since I am not developing 
Groovy myself I thought that maybe I would just present it here and if 
people think such a feature request (or a somewhat similar one) would 
still make sense, it could still be created (by me or someone else)...

---
Improve Groovy class loading performance and memory management

Consider the maybe most typical use case of Groovy as a dynamic 
language: Within a Java VM, Groovy scripts are dynamically compiled, be 
it explicitly by using a GroovyShell or a GroovyClassLoader, or more 
implictly e.g. with a ConfigSlurper.

Qualitatively this often has the following result in the Java VM: 
Metaspace resp. PermGen, and Heap in parallel, just grow until a 
configured limit is reached (and note that there is none by default for 
Metaspace in Java 8 and later), often only then is it garbage collected. 
With Java classes, at least with simple ones, this looks often 
different, those appear to be garbage collected much more quickly.

Another qualitative difference is that loading a Groovy class and 
instantiating it seems typically to be considerably slower than 
instantiating a Java class with similar functionality, even quite 
drastically so, more than one would expect even considering the need to 
create metadata for dynamic function calls etc.

At least that has been my experience over the past few years.

Seen from very far ("management", "marketing", "sales"), this not 
optimal for a dynamic language, getting these two things right - memory 
management and class loading performace -  is arguably "core business".

Obviously Groovy classes are more complex than most Java classes and 
there is existing code and limitations of Java VMs and probably more 
issues...

But in the medium term, I think and feel that it would be good to find 
out what really impedes better performance and a more regular garbage 
collection. Possibly the problems are really hard and complex, but some 
might also be easy, and maybe some would become quite easy after some 
simple changes in the Java VM, but before such changes can be requested, 
it has to be analyzed what these could or should be.

Attached is a simple command line Java test program, ClassGCTester.java, 
that can be used to make some very basic measurements of class loading 
memory behavior and performance. The source code and a readme with two 
examples (one for Java and one for Groovy) is also at 
https://github.com/jexler/classgc, and I think it might help to 
illustrate current limitations and maybe also a little bit initially 
with analysis.
---

Note the tool at https://github.com/jexler/classgc and the readme with 
two illustrative examples - one Java class, one Groovy class - there...

Alain