JDK-8012190 : Global scope should be initialized lazily
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 8u60,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-04-15
  • Updated: 2015-09-29
  • Resolved: 2015-03-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u60Fixed 9 b57Fixed
Description
Migrated from NASHORN-802

There are many properties in global scope. All are initialized by default. But many properties may not be used in script file or in a session. We could lazily initialize global's properties. Getter/Setter may be added to method - but a hidden field may be initialized within getter.
Comments
I've attached a JFR recording of test, with the thread count bumped up to 5000 instead of 100 and we are definitely looking at global object initialization overhead. What's interesting is that method handle manipulation is 17% of the total runtime - eech ... The first 5 hot methods are hashmap lookup in the java.lang.invoke package, Context.getGlobal - creating globals, the findProperty for "arguments" and "callee" for strict methods - interesting - and then non-lazily creating constructor methodhandles for all FinalScriptFunctionDatas that are instantiated from nasgen generated constructors
22-07-2014
This bug shows how much overhead the global initialization actual contains. Actual compile time in these 100 threads is less than 2 seconds on the total benchmark run, but significant bottlenecks appear in method handle creation. 100% of this method handle creation comes from * Nasgen constructors that are run during global initialization * Statically resolvind findOwnMH stuff for the NativeObject classes One rather cheap remedy would be to make sure that constructors for nasgen generated builtins are generated lazily and not on ScriptFunctionImpl instantiation time. We can also do it ultra lazy and have some kind of fallback triggering when a builtin needs to be used for the first time, triggering method handle resolution only there and then.
22-07-2014
This is not a release blocker for 8. More of a nice-to-have perf. issue
20-06-2013