JDK-8023279 : footprint regression in b75 due to jfxrt.jar
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-08-19
  • Updated: 2014-01-17
  • Resolved: 2013-12-10
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
8 b121Fixed 9Fixed
Related Reports
Cloners :  
JDK-8029878 - footprint regression in b75 due to jfxrt.jar - reopened
Relates :  
JDK-8003171 - Need to move jfxrt.jar from lib/ to lib/ext/
Description
Footprint for a simple hello world app increases by 600kb from b74 to b75 due to
the including of jfxrt.jar. JDK-8003171 seems to be the likely candidate for causing
this regression.
Comments
Kevin is correct, the change is in Master but RE builds are not able to find the javafx-ext-meta-index file. Build log (http://jre.us.oracle.com/java/re/jdk/8/promoted/ea/b121/logs/build-linux-i586.log) has the warning of missing file: Warning: /HUDSON/workspace/8-2-build-linux-i586/jdk8/1114/COBUNDLE/linux-i586/javafx-ext-meta-index not found meta-index file will not be updated
03-01-2014
This issue cannot be verified with install DS builds for Windows. DS builds use RE promoted outputdirs from previous week and javafx makefile target does not get run which is responsible for adding jfxrt.jar meta-index to JAVA_HOME/lib/ext/meta-index file. However this can be verified with Windows JPRT builds which are full builds: http://bus2001067.us.oracle.com/archives/2013/12/2013-12-16-053535.hudson.workspace/bundles/windows_i586_6.1-product-install.zip http://bus2001067.us.oracle.com/archives/2013/12/2013-12-16-053535.hudson.workspace/bundles/windows_x64_6.1-product-install.zip
16-12-2013
I chatted with IM about this and I think the issue is that JDK-8023279 just hasn't got to master yet.
10-12-2013
Cloned this issued and closing this one again
10-12-2013
Staffan - issues should not be re-opened after a change has been pushed as the JIRA number can not be re-used. So I suggest restoring the fields and open a new bug.
10-12-2013
The meta-index file does not contain the javafx-ext-meta-index in the promoted builds. Probably need to work with RE to make sure the update Makefile is being called correctly
10-12-2013
Release team: Approved for fixing
25-11-2013
Justification for 8-critical-request: This is critical as meta-index for jfxrt.jar must be present in jre/lib/ext/meta-index file for minimizing the footprint.
25-11-2013
Install PIT uses JPRT builds which uses local directory to bundle javafx cobundles and they seems to be missing this new javafx-ext-meta-index file, created an issue for JPRT JDK-8028807.
21-11-2013
I pushed a fix for https://javafx-jira.kenai.com/browse/RT-34325 that will be in the FX prepromoted bundles for b117. The file is named: javafx-ext-meta-index and is in the same directory as javafx-runtime-for-cobundle.zip, etc.
19-11-2013
After evaluating this bug, and discussing it with the install team, we will fix this bug as follows: 1) Modify the JavaFX build to generate a "javafx-ext-meta-index" file in in the same exports directory as javafx-runtime-for-cobundle.zip, etc. I have filed a new issue on the JavaFX side -- https://javafx-jira.kenai.com/browse/RT-34325 -- to track this 2) Modify the install Makefile to append this file to look for the existence of the new "javafx-ext-meta-index" file in the JavaFX cobundle directory and append it to the lib/ext/meta-index file in both the JDK and JRE. Something like: cat $JAVAFX_EXT_META_INDEX_FILE >> lib/ext/meta-index This is the least intrusive change to the install Makefile, and keeps a better separation between the JavaFX build and the JDK build. I will get the JavaFX changes into our build prior to b117 on Monday, Nov 18.
16-11-2013
OK, I'll work on a fix.
01-11-2013
Release team: We're rejecting this one since perf (Staffan) had said earlier that they wanted this fixed in JDK 8. We're putting this on critical-watch so work can continue on this one. Please sync up with Staffan Friberg on this one.
25-10-2013
I would question whether this is a stopper for the JDK8 embedded releases. Are they impacted by this? It will impact Fusion Apps if they deliver ob JDK8 before 8u20. The FA delivery plans should be examined to be sure. I think Staffan might have answers for both these.. Staffan?
22-10-2013
SQE OK with deferral.
22-10-2013
Requesting deferral to JDK 8u20. This isn't a difficult fix, but there is not sufficient time to implement it and fully test it on all platforms prior to ZBB. It would be nice to fix it, but I don't think this is a showstopper for the JDK8 release.
22-10-2013
I think the problem with jfxrt.jar is that it is being copied into the JRE image after it is created, hence missed by the build step that generates meta-index
03-10-2013
The meta-index provides for a way for the jvm to skip a jar when searching for a class - asumming the meta-index is up to date. It does this by providing the packages associated with the jar, so it would know for example that if we are looking for com/sun/nio we only need to look into zipfs.jar # zipfs.jar META-INF/services/java.nio.file.spi.FileSystemProvider com/sun/nio/ Looking at ext/meta-index in a recent jre, I see that we do have some of the jar information, but none from jfxrt.jar, which is a big jar to search. Good practice would suggest that meta-index is created when *all* in the bundled jars are in place so that the packages listed for each jar present are there.
02-10-2013
Can someone please provide more information about meta-index? I originally implemented adding jfxrt.jar (along with other jfx bits) being co-bundled during the install build but there was no mention of meta index needing to be updated - hence the install build does not do any index updating.
02-10-2013
I will try that manually, and if that resolves the problem, then incorporate that into the install Makefile where the jfxrt.jar file is imported.
02-09-2013
The dependent FX issue -- https://javafx-jira.kenai.com/browse/RT-32438 -- is now fixed so I think the remaining work is to include the index entries from jfxrt.jar into the meta-index file.
02-09-2013
Part of the issue is that jfxrt.jar itself is not indexed. See https://javafx-jira.kenai.com/browse/RT-32438
20-08-2013
The changes are JDK-8003171 may be incomplete, someone needs to track down where the scripts or make files are for the co-bundling.
20-08-2013
From Alan Bateman: I just checked our promoted builds and it looks like jfxrt.jar is being added to the ext directory but meta-index is not updated. This means it will be opened during the class loading of any class as there is no way to know what is in this JAR file. I see the JAR file has 7000 entries (looks like they don't strip directories) so that is going to be a big central directory to map and search. The meta-index is generated during the JDK images build, looks like the whatever pulls in the JavaFX bits will need to be updated to add to the meta-index file too.
19-08-2013
From Oleg Mazurov: If I run: [bash]# java -Dsun.misc.URLClassPath.debug=true Noop I get URLClassPath.getResource("Noop.class") Opening file:/export/home/oleg/EXTDIR/jre1.8.0/lib/ext/jfxrt.jar java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1308) at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:687) at sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:683) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:682) at sun.misc.URLClassPath$JarLoader.<init>(URLClassPath.java:655) at sun.misc.URLClassPath$3.run(URLClassPath.java:373) at sun.misc.URLClassPath$3.run(URLClassPath.java:363) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.URLClassPath.getLoader(URLClassPath.java:362) at sun.misc.URLClassPath.getLoader(URLClassPath.java:339) at sun.misc.URLClassPath.getResource(URLClassPath.java:205) at java.net.URLClassLoader$1.run(URLClassLoader.java:357) at java.net.URLClassLoader$1.run(URLClassLoader.java:354) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:353) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.lang.ClassLoader.loadClass(ClassLoader.java:410) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:518) URLClassPath.getResource("Noop.class") It's the same on Linux and Windows (presumably all platforms).
19-08-2013