Tony,
We will keep this general issue open as
https://bugs.openjdk.java.net/browse/JDK-8160103 and revisit later on.
— Jim
> On Jun 21, 2016, at 11:41 PM, Tony Zakula wrote:
>
> Thank you for looking into this. Much appreciated. We are working on a
> large Nashorn project we hope to share
Thank you for looking into this. Much appreciated. We are working on a
large Nashorn project we hope to share soon.
On Jun 21, 2016 8:33 AM, "Hannes Wallnöfer"
wrote:
> Unfortunately, there is a problem with invalidation of callsites that
> Sundar brought up in the review thread for the issue I
Unfortunately, there is a problem with invalidation of callsites that Sundar
brought up in the review thread for the issue I filed.
I’ve thought about it, but there isn’t any easy way to do this without giving
up significant benefits on the other side. I’m closing the issue as „won’t
fix“, but
Thank you Hannes. That would be great. We have tried using clear before
too.
@Axel - Thank you for the stats. Interesting to see that. One thing we
did was use strict mode and use Immediate Functions. This would keep
variables going to global scope I think.
Thanks,
Tony
On Wed, Jun 15, 201
I prototyped the proposed change to the clear() method. It seems to work well
and makes a lot of sense to me, so I filed a bug for it:
https://bugs.openjdk.java.net/browse/JDK-8159589
I haven’t discussed this with the other team members yet, so let’s see what
they think.
Hannes
> Am 15.06.20
Am 14.06.2016 um 22:09 schrieb Tony Zakula:
Interesting. We use on global context and create a new engine context
with each run. The initial compile of several scripts is over 100ms,
but then we see that drop to under 10ms. The context creation seems to
have very little overhead. We have not
Interesting. We use on global context and create a new engine context with
each run. The initial compile of several scripts is over 100ms, but then
we see that drop to under 10ms. The context creation seems to have very
little overhead. We have not timed that specifically though, just total
pro
Am 14/06/2016 um 17:52 schrieb Tony Zakula:
Have you tried reusing the engine and only creating a new Context for
every run?
Sure, but creating a new ScriptContext has a substantial overhead.
AFAICT sharing the engine only enables caching the compiled scripts, as
well as making Compilables wor
Have you tried reusing the engine and only creating a new Context for every
run? Also, have you turned on caching for scripts as the engine parameter?
We have seen good performance doing that. Would be interested to know if
you do.
Thanks,
Tony
On Jun 14, 2016 4:58 AM, "Axel Dörfler" wrote:
H
Hi Benjamin,
Am 14/06/2016 um 11:06 schrieb Benjamin Sieffert:
I tried doing a similar thing for a while and found there is no pretty
way to do it from the Java-side.
I think the best solution is making your JS-code have no global state,
by utilizing function scopes* and maybe small (custom, mut
Hi Axel,
I tried doing a similar thing for a while and found there is no pretty
way to do it from the Java-side.
I think the best solution is making your JS-code have no global state,
by utilizing function scopes* and maybe small (custom, mutable)
context objects that get passed around.
Generally,
Hi Hannes,
Am 14/06/2016 um 09:53 schrieb Hannes Wallnöfer:
The problem seems to be that bindings.clear() uses the ECMAScript
delete operation to clear the bindings, and that will only delete a
property if it is configurable. However, var declarations are
non-configurable and therefore „survive“
Hi Axel,
The problem seems to be that bindings.clear() uses the ECMAScript delete
operation to clear the bindings, and that will only delete a property if it is
configurable. However, var declarations are non-configurable and therefore
„survive“.
I’m not sure how to work around this, and possi
13 matches
Mail list logo
