meatspace memory OOME using Nashorn and Callable

[Benjamin Sieffert]

Hi Riccardo,

I once ran into a similar issue. From what you have written, I’m not quite
sure if yours is exactly the same, but anyway it might help.
Here’s the link.
http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-November/003872.html

In short: If a callsite in your JS code has more than 8 different receivers
(e.g. different subclasses of Callable), the callsite will often relink,
which generates new classes (LambdaForms, I guess) that eventually have to
be collected.

Now it’s not clear to me whether you might actually have such a callsite or
not, but this behaviour is something to keep in mind regarding MetaSpace
consumption, when working with nashorn.

Hope this helps a bit,
Benjamin

On 26 January 2016 at 11:58, Riccardo Maggi <maggi at venere.com> wrote:

> Hi,
> We are testing Nashorn usage and we have a big issue on metaspace usage.
> We can’t figure out why metaspace show a sawtooth that correspond to a grow
> and a consequent GC when its limit is reached, suggesting a class loader
> leak is somewhere. The metaspace patter was 1:1 with number of classes like
> many compilation were needed.
>
> The problem seems to be around a loop where we add callable tasks to a
> thread pool to be executed and how to pass parameters to the js function
> that represent the task logic.
> We found a solution for the high number of compiled classes using a code
> like:
>
> var tasks = arrayForTask.map(function(dataForTask, i) {
> return new Callable({
> call: function () {
> print("task A " + i);
> }
> });
> });
>
> So now classes do now grow as before but the metaspace always grows…
> I can’t find any source that clearly explain where the compiled js
> functions are stored (lambda form) into memory, I can understand that
> compilation is needed when nashorn think the js function body changed, like
> for references to different globals and so on.
> So in the end should I always expect a metaspace grow controlled by the
> GC?? even if the code has no leak? that seems to be kind of reasonable
> cause the JIT compilation is needed for a dynamic language that has no
> defined “class” structure but I can’t understand if GC should be the only
> limit to my OOME or if a leak is somewhere…
> Thanks,
> Riccardo.
>
> --
> Riccardo Maggi
> Manager, Software Development
> Hotels.com – An Expedia Inc. Company
> Venere Net S.r.l. con socio unico Via della Camilluccia 693, Roma, Italia
> Soggetta a direzione e coordinamento di Hotels.com LP Capitale 1.120.600
> (i. v.) Sociale Codice Fiscale e P.IVA 05649781001 REA di Roma 910870
>



-- 
Benjamin Sieffert
metrigo GmbH
Lagerstraße 36
20357 Hamburg

Geschäftsführer: Tobias Schlottke, Philipp Erler

Die Gesellschaft ist eingetragen beim Registergericht Hamburg HRB 120447