Message11500

James Mudd, thanks for identifying the performance regression as due
to the fix for #2514.

Resolving this problem is one of a number of JSR 223 fixes that should
be addressed. Unfortunately there is no single answer on what to do
here because in some cases users need the sys module to be isolated;
and in other cases, that costs too much in terms of performance. Some
details from my email on June 13 to jython-dev:

> I took a detailed look at
> http://bugs.jython.org/issue2513. Unfortunately there is no easy fix
> for this problem as stated, because org.python.jsr223.ScriptEngine,
> via org.python.util.PythonInterepreter, relies on
> org.python.core.PySystemState (= sys in Python), which effectively
> collects together global state for Python, either directly, such as
> sys.stdout, or indirectly, via sys.modules and any globals within
> those modules. The mechanism that ScriptEngine uses to put locals on
> a thread local will not work here, because this is maintained by a
> separate entity in Python, the frame object (= PyFrame in Jython);
> there is no such support for sys.stdout, etc, to be looked up from
> the thread.

JavaScript has similar issues, and the Nashorn implementation
addresses this by extending the JSR223 API to enable better
configuration of the relevant tradeoffs. So again quoting from my email:

> There is a possible solution, but it's not feasible at this point in
> the release cycle and needs to be deferred to later. Instead of
> always attempting to reuse PySystemState, Jython's JSR223 should
> instead support a model where new PySystemState objects can be
> attached to a ScriptEngine. I believe this is similar to what
> Nashorn supports with its --global-per-engine property (also
> configurable some other ways, see the notes). Regardless of exact
> similarity, this is how we would have to do it:

> ScriptEngine engine = factory.getScriptEngine(new String[] { "--global-per-engine" });

> (https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes)