Re: Can't get Multithreaded Nashorn uses to Scale

2017-04-11 Thread Hannes Wallnöfer
I just downloaded 8u152 b02 from https://jdk8.java.net/download.html and the fix is included, which can be tested by running the original test code (runs about 10x faster than in previous 8u releases). Unfortunately, I don’t know when 8u152 will be released, I don’t think that date has been se

Re: Can't get Multithreaded Nashorn uses to Scale

2017-04-10 Thread Jesus Luzon
I looked in the 8u changelog and did not see anything that makes it seem like this was added, so I'm bumping this to see if someone knows the status of this and if there's any place I can just check if this has been released in a Java 8 update. On Mon, Jan 9, 2017 at 2:57 PM, Hannes Wallnöfer < ha

Re: Can't get Multithreaded Nashorn uses to Scale

2017-01-09 Thread Hannes Wallnöfer
The fix is in JDK 9 now. I will propose this to be backported this to 8u, which means it should appear in some 8u release soon, but I can’t make any promise about a specific release or date. Hannes > Am 09.01.2017 um 23:44 schrieb Jesus Luzon : > > Hey folks, > > Looked at the ticket and no

Re: Can't get Multithreaded Nashorn uses to Scale

2017-01-09 Thread Jesus Luzon
Hey folks, Looked at the ticket and noticed it has been marked as fixed. woot! Thank you so much! My team has been asking me if I can find out the date this fix will get released. I noticed the version on there (version 9) states it has no release date yet. Is there any tentative date you all hav

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-09 Thread Jesus Luzon
Wow I totally missed the var. Thanks for that! I actually had changed our code to use ThreadLocal ScriptObjectMirrors created from the CompiledScript with the following code: ScriptObjectMirror mirror = mirrorThreadLocal.get(); > > if (mirror == null) { > > Bindings bindings = compiledScript.g

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-09 Thread Hannes Wallnöfer
Jesus, I looked at this issue more in depth and there are two problems here, one on your side and one on ours: The problem with your code is that you left out the „var“ declaration of the „response“ variable in the third line of your function. This means that „response“ is allocated as a globa

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-08 Thread Jesus Luzon
I came up with a workaround which is getting us through this but it definitely seems like this is a bug. The gist is I append an arbitrary string (we made it complex on our end to make it unlikely something else has this string inside) to the key and then remove all instances of said string on the

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-08 Thread Jesus Luzon
It doesn't seem like changing to a string fixed it. We dug deeper and found a very interesting issue though. After running the invocable a few thousand times, when we put a breakpoint in ArrayData.computerIteratorKeys() and we found that it would stop at an execution from SparseArrayData with an un

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-08 Thread Hannes Wallnöfer
Yes, this is very likely to be the cause of the problem. However, I do think we should be able to handle sparse array data better, so it’s quite possible that you exposed some weak spot in our implementation. I’ll have a look into what’s going on. Hannes > Am 08.12.2016 um 00:40 schrieb Jesus

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-07 Thread Jim Laskey (Oracle)
Yes this is part of the js spec I assume you mean undefined not null. > On Dec 7, 2016, at 7:40 PM, Jesus Luzon wrote: > > Looks like the memory leak is due to the way we wrote our code and how > javascript works. I was expecting the line response[summoner.id > ] = summ

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-07 Thread Jesus Luzon
Looks like the memory leak is due to the way we wrote our code and how javascript works. I was expecting the line *response[**summoner.id **] = summoner; *to build a map but it turns out that if you use a number as the "key", javscript automatically fills the indexes in the mid

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-07 Thread Jesus Luzon
Yes, it's an array of objects which I'll paste. And yes, I'm just calling invokeFunction from many many different threads. I'm also going to go back and take a look at all the heap dumps we have to re-confirm what I mentioned. "[\n" + > " {\n" + > "\"id\": 6011511,\n"

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-07 Thread Hannes Wallnöfer
Hi Jesus, I’m trying to reproduce the problem, and just want to make sure I get the missing pieces right. You already showed us how you’re setting up the engine and the JS code you’re running. I assume the JSON code you’re parsing is a simple array of objects? And you’re just calling Invocab

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jesus Luzon
When we share one invocable across many threads and run invokeFunction it happens, such as this: ExecutorService executor = Executors.newFixedThreadPool(50); > > Invocable invocable = generateInvocable(script); > > AtomicLong count = new AtomicLong(); > > for (int i = 0; i

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jim Laskey (Oracle)
Intersting. The example you posted demonstrates this behaviour? If so I’ll file a bug and dig in. It sounds like an object is being reused across invocations and accumulating changes to the property map. — Jim > On Dec 6, 2016, at 5:12 PM, Jesus Luzon wrote: > > With more threads you are

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jesus Luzon
> > With more threads you are impacting the same 8 cores, so it will taper off > after 8 threads. If it’s a 2x4 core machine then I can see 4 being a > threshold depending on System performance. Transport: I meant if you were > using sockets to provide the script. This makes sense. This one's on

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jim Laskey (Oracle)
> On Dec 6, 2016, at 9:56 AM, Jesus Luzon wrote: > > The cost of creating a new engine is significant. So share an engine across > threads but use eval > (String > <

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jesus Luzon
> > The cost of creating a new engine is significant. So share an engine > across threads but use *eval > * > (String

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jim Laskey (Oracle)
> On Dec 6, 2016, at 9:19 AM, Jesus Luzon wrote: > > Hey Jim, > > I looked at it and I will look into loadWithNewGlobal to see what exactly it > does since it could be relevant. As for the rest, for my use case having > threads in the JS would not help. We're using Nashorn to build JSON filte

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jesus Luzon
Hey Jim, I looked at it and I will look into loadWithNewGlobal to see what exactly it does since it could be relevant. As for the rest, for my use case having threads in the JS would not help. We're using Nashorn to build JSON filters in a Dynamic Proxy Service and need any of the threads processi

Re: Can't get Multithreaded Nashorn uses to Scale

2016-12-06 Thread Jim Laskey (Oracle)
Jesus, Probably the most informative information is in this blog. https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt This example uses Executors but threads would work as well. I did a talk that looked a