(sending this again because I wasn't subscribed the 1st time and hence it
probably got spamfiltered)
Hello everyone,
I have been sent over her from the nashorn-dev mailing list. We're having
trouble with our application getting (rather randomly) very busy with calls
to the methods mentioned in th
Am 20.09.2013 09:42, schrieb Benjamin Sieffert:
[...]
> - at the VERY core: highly repetitive javascript run via java (switched
> from rhino to nashorn recently there)
[...]
> In summary: High level of concurrency, huge number of classes and
> nmethods generated at runtime (both by jruby and nashor
Hi Jochen,
thanks for responding. I'm not really sure whether nashorn sets new
callsites every time. In profiling I only see it initally (when script
engines have just been initialized) and when the bad condition arises.
As for it being due to low memory, I'm not sure. Sometimes heap will have
bee
Am 20.09.2013 10:25, schrieb Benjamin Sieffert:
> Hi Jochen,
>
> thanks for responding. I'm not really sure whether nashorn sets new
> callsites every time. In profiling I only see it initally (when script
> engines have just been initialized) and when the bad condition arises.
it is really only a
Thanks for that insight Jochen. (I asked Benjamin to repost here to see if
anyone else has seen this issue.) Nashorn normally sets the callsite just
once, but it's possible that in low memory conditions that it is getting forced
to redo. We will investigate.
Cheers,
-- Jim
Sent from Jim's i
I think you have your answer in the stack traces.
The problem arise when you (or nashorn) call eval().
I see two solutions, either ask Nashorn guys why they create callsites
too often when you use eval() in javascript
or stop using eval() in your js script ! (if eval() is something you use
and n
Well the thing is, our maximum size (2g) for PermGen / Metaspace is never
even approached. In fact, if we don't specify an initial size, constant gc
will keep them under 200-300m (at the cost of performance). If we set an
initial size of, say, 700m, that boundary won't be grown when the app is
runn
On 09/20/2013 11:38 AM, Benjamin Sieffert wrote:
> Well the thing is, our maximum size (2g) for PermGen / Metaspace is
> never even approached. In fact, if we don't specify an initial size,
> constant gc will keep them under 200-300m (at the cost of
> performance). If we set an initial size of,
Rémi,
well I got into more detail on how we use nashorn on their mailing list,
because I supposed this wouldn't be so much the issue here. Anyway, you're
bringing up a point that they did not, so here's specifically what we do:
Each of our ~200 javascripts is set up to return a "scriptrunner" obj
Am 20.09.2013 12:56, schrieb Benjamin Sieffert:
[...]
> Then we retrieve our javascript-side "scriptrunner" object by calling
> .compile(javascript).eval() on the engine. (So we get a compiled script
> at this point, but that is not the object we store and use.)
can't you reuse the compiled script
No, I think you misunderstand me. We are keeping the javascript(!) object
we got from the compiled script and with it, I assume, we keep the compiled
script / its optimization. We are in no way re-initializing scripts /
script engines with every call.
The problem is that we don't really have anothe
John,
I don't see much value in documenting buggy behavior of early JDK7 in
JDK8 code. So, I would remove it.
Regarding the test:
31 * @run main/othervm/timeout=3600
- why do you have timeout set to 1h?
I like the idea how you count events.
As a suggestion for enhancement - maybe it's m
John,
I cleaned javadoc a little [1], so it is more readable in the browser now.
The test code looks ok, though the logic is over-complicated.
But the whole MethodHandlesTest is written in the same vein.
Best regards,
Vladimir Ivanov
diff --git a/src/share/classes/java/lang/invoke/MethodHandles
http://cr.openjdk.java.net/~jrose/8001105/webrev.00/
Summary: Replicate JVM logic for access control that makes Object.clone appear
public when applied to an array type.
See: http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html
— John
__
Hello everyone,
I have been sent over her from the nashorn-dev mailing list. We're having
trouble with our application getting (rather randomly) very busy with calls
to the methods mentioned in the topic. On jdk8, that is. On jdk7, we're
exclusively seeing setCallSiteTargetNormal. This probably ha
On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov
wrote:
> I cleaned javadoc a little [1], so it is more readable in the browser now.
Thanks; I applied those edits. I fixed the problem of a missing in a few
other places too.
> The test code looks ok, though the logic is over-complicated.
> But t
On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov
wrote:
> John,
>
> I don't see much value in documenting buggy behavior of early JDK7 in JDK8
> code. So, I would remove it.
OK. I think I had it in mainly to make sure the unit tests did something
interesting.
> Regarding the test:
> 31 * @ru
17 matches
Mail list logo
