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
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
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
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
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,
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
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
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
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
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 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
(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
12 matches
Mail list logo
