meatspace memory OOME using Nashorn and Callable

[Riccardo Maggi]

Hi Benjamin,
Thanks for your answer. At the end we were able to reduce the number of LambdaForms generated each run of the js script. It seems that the root cause was related with a recursive function that was using a big JSON object. We suspect that the generation of new Lambda was related to the fact that the recursive function was invoked with different argument types (objects and arrays) each recursion.
Do you think that a js fuction invoked with different argument types can lead to a relinking in the call site?
Thanks,
Riccardo.
--
Riccardo Maggi
Manager, Software Development
Hotels.com - An Expedia Inc. Company

From: Benjamin Sieffert <benjamin.sieffert at metrigo.de<mailto:benjamin.sieffert at metrigo.de>>
Date: mercoledì 27 gennaio 2016 11:36
To: Riccardo Maggi <maggi at venere.com<mailto:maggi at venere.com>>
Cc: "nashorn-dev at openjdk.java.net<mailto:nashorn-dev at openjdk.java.net>" <nashorn-dev at openjdk.java.net<mailto:nashorn-dev at openjdk.java.net>>
Subject: Re: meatspace memory OOME using Nashorn and Callable

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<mailto: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
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