Nashorn Memory Leak using Invocale.invokeFunction

[Sundararajan Athijegannathan]

Will you please send us reproduceable test case? we'll file a bug with 
that or you could file a bug as well.

Thanks
-Sundar

On 01/12/16, 5:40 AM, Jesus Luzon wrote:
> Hey folks,
>
> We are running into issues right now where repeated use of an Invocable is
> eventually causing a crash due to an OutOfMemoryError.
>
> The code snippets that are causing the crashes are:
>
>> serviceBody =
>> JSON.stringify(variables.summonerIds[0].split(',').filter(function(el)
>> {return el.length != 0})
> and
>
>> serviceBody = JSON.stringify(variables.summonerNames[0].split(','));
>
> There is some boilerplate javascript code that includes all those variables
> being referenced, but I have ommited it to make this e-mail shorter. A heap
> dump after the process crashes shows an ArrayList with an Object[] of size
> 15704907 filed with java.lang.Long objects.   A heap dump analysis before
> it crashes has made me believe that it has to do with
> *jdk.nashorn.internal.runtime.arraysDeletedArrayFilter.java* but I might be
> in the wrong here.
>
> Our service runs in *jetty-9.3.5.v20151012. *
> JRE is *openjdk version "1.8.0_111".*
> Args passed are *-Xms4g -Xmx4g -XX:NewSize=1g -XX:MaxMetaspaceSize=1g
> -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled
> -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly
> -XX:-OmitStackTraceInFastThrow*
>
> I also have the heap dump which is ~5.4G uncompressed and ~750M compressed.
> I can upload those somewhere if someone thinks they could find value in
> taking a look in it.
>
> Much thanks before hand to anyone taking a look at this. I've been trying
> to figure this out for days but looking at cecompiled Java code to solve
> this hasn't netted me any results yet.
>
> Thanks.
> Jesus Luzon