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

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 <

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, > >

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 =

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

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

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 >

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

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

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

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 >

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

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

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