JDK-8160000 : Runtime.version() cause startup regressions in 9+119
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-06-21
  • Updated: 2016-07-12
  • Resolved: 2016-06-27
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 9
9 b126Fixed
Related Reports
Relates :  
JDK-8160457 - VersionProps.versionNumbers() is broken
Relates :  
JDK-8160564 - TEST: Add a test to check the implementation of VersionProps.versionNumbers()
Description
9-b119 introduces startup and footprint performance regressions across most platforms. 

It's been determined this is due to changes in java.util.regex which eagerly initialize java.lang.invoke.LambdaMetafactory, while also creating a number of lambdas. See JDK-81600302 for a related bug to try and reduce the initial startup and footprint hit of loading j.u.regex after 9-b119.

To address this startup and footprint regression we should simplify the creation of the java.lang.Runtime.Version returned by Runtime.version(): since the constituents are known at build time, and we already generate java.runtime.version property etc into java.lang.VersionProps, putting constants with the constituents in VersionProps will be a good startup optimization.

---

Client applications are showing footprint regressions with Noop/ModNoop (1.5MB), Framer/ModFramer (200kb), and XFramer/ModXFramer(1MB) on linux and Noop/ModNoop (1.5mb) on Windows. Client startup also impacts these same apps, but the magnitudes of these increases are small (nearly 40ms for Noop on linux, but only signgle digit ms for other apps). 

Server footprint  is mostly Noop/ModNoop regressions measuring about 2MB, except on Solaris-sparcv9 where it measures 10MB and Solaris-x64 where it measures about 4mb. Jetty shows some minor footprint regressions in Solaris-sarcv9 and Solaris-x64. Server startup is also mostly Noop/ModNoom measuring about 40ms on linux and windows, but up to 80ms on Solaris-sparc and 50ms on Solaris-x86.
Comments
Alternatively adding properties to java.lang.VersionProps at build-time: http://cr.openjdk.java.net/~redestad/8160000/webrev.1/
25-06-2016
PoC patch to pregenerate Runtime.Version: http://cr.openjdk.java.net/~redestad/8160000/webrev.0/
23-06-2016
It would appear this is due to a chain of changes. First, MR-JAR causing jdk.Version (soon to be Runtime.Version) to be loaded, eagerly pulling in regex on anything that touches a Jar file (as all our startup measures do), and then in 9-b119 a big push of changes to java.util.regex[1] which, amongst other things, eagerly create a number of lambdas, e.g., java.util.Pattern.ALL. Fixing this could entail making java.util.regex be more cautious to create lambdas before they are needed (put all static lambdas in a holder class), and/or getting rid of the regex dependency in Version. This latter could possibly be done by precomputing the Version object in a jlink plugin. [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d0c319c32334
23-06-2016
Address map comparisons are attached. These comparisons are avaialble for linux and solaris runs. The tools don't work with windows mapping data.
21-06-2016
ILW = M,H,H therefore the initial priority is set to P2. The fact that both startup and footprint are affected and that it's across all platforms influenced this priority level.
21-06-2016