JDK-8023041 : The CDS classlist needs to be updated for JDK 8
  • Type: Bug
  • Component: performance
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-08-14
  • Updated: 2015-06-01
  • Resolved: 2013-11-14
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 Other
8 b117Fixed port-stage-ppc-aixFixed
Related Reports
Relates :  
JDK-8081587 - Improve CDS classlist generation documentation
Relates :  
JDK-8081590 - The CDS classlist needs to be updated for 8u60
Description
The current JDK 8 classlist, used to create the Class Data Sharing, archive is old, affecting performance and resulting in lots of warnings from the build about missing classes.

Also, separate updated classlists are needed for 32-bit and 64-bit systems.
Comments
I understand that they were also automatically created by the solaris 32 bit installer. If that carried over to the new 64bit installers I do not know, but it's possible.
08-11-2013
Staffan wrote: "For which JDK versions do we use CDS automatically? Only Win 32 JRE?" That's my last understanding, unless there have been changes. Also, it's only automatically created when using the installer based bundle. Ie, the CDS file is created as a late phase of the installer.
07-11-2013
2,083 classes from new generated classlist are also used by NetBeans, so we still use CDS for NetBeans. I only propose to exclude classes which are only used by NetBeans50 and not other applications (Noop, Framer, XFramer, JEdit, LimeWire). This saves us ~2Mb of footprint and provides pretty much the same startup.
01-11-2013
For which JDK versions do we use CDS automatically? Only Win 32 JRE? Since NB requires a JDK to run we might not make use of CDS in that case. Would be helpful for applications that are built using the NB framework however.
01-11-2013
Netbeans50 adds 692 extra classes, please see classlist.netbeans attached.
01-11-2013
I was not fully aware of the difference between using the classlists for CDS and for the jarfile reordering. My comments about negligeble effect and high cost to builing refers to the use for jar reordering. I have no objection for the use of classlists for CDS, which obviously gives a nice performance increase.
01-11-2013
I was mostly referring to the reordering but it makes sense that the same list of classes would be useful for CDS set.
31-10-2013
Can you clarify how many classes, and from which packages, are added when using Netbeans50 - thanks.
31-10-2013
I talked to Staffan and we agreed to generate classlist for jdk8 using the same procedure as before. So, I have generated 2 new classlist for latest jdk8-b114 by running applications from startup3 benchmark. First classlist (classlist.startup3) contains classes loaded by: Noop, Framer, XFramer, JEdit, LimeWire, NetBeans50 Second classlist (classlist.startup3-netbeans) contains classes loaded by all above apps except NetBeans50. Startup2 results on my Windows laptop are: ============================================================================== startup2.cds-off/: Benchmark Samples Mean Stdev Geomean Weight app_awt 10 220.10 4.91 0.50 app_swing 10 247.80 8.78 0.50 ============================================================================== startup2.cds-on.orig/: Benchmark Samples Mean Stdev %Diff P Significant app_awt 10 199.70 30.16 9.27 0.062 * app_swing 10 210.70 27.51 14.97 0.002 Yes ============================================================================== startup2.cds-on.startup3-netbeans/: Benchmark Samples Mean Stdev %Diff P Significant app_awt 10 182.40 27.62 17.13 0.002 Yes app_swing 10 196.40 33.18 20.74 0.001 Yes ============================================================================== startup2.cds-on.startup3: Benchmark Samples Mean Stdev %Diff P Significant app_awt 10 168.30 6.50 23.53 0.000 Yes app_swing 10 181.00 7.97 26.96 0.000 Yes ============================================================================== Footprint3_real results are: ============================================================================== footprint3.cds-off/: Benchmark Samples Mean Stdev Geomean Weight Framer 10 28675.60 37.73 0.03 JEdit 10 51504.80 105.22 0.30 LimeWire 10 64840.00 83.63 0.30 NetBeans50 10 104305.60 546.82 0.30 Noop 10 12600.40 19.64 0.03 XFramer 10 33872.00 44.38 0.04 ============================================================================== footprint3.cds-on.orig/: Benchmark Samples Mean Stdev %Diff P Significant Framer 10 31826.40 1115.79 -10.99 0.000 Yes JEdit 10 53650.00 1142.96 -4.17 0.000 Yes LimeWire 10 66405.60 282.86 -2.41 0.000 Yes NetBeans50 10 105007.60 1177.00 -0.67 0.111 * Noop 10 15441.60 980.41 -22.55 0.000 Yes XFramer 10 37643.20 21.06 -11.13 0.000 Yes ============================================================================== footprint3.cds-on.startup3-netbeans/: Benchmark Samples Mean Stdev %Diff P Significant Framer 10 31376.80 1439.58 -9.42 0.000 Yes JEdit 10 53703.20 1206.34 -4.27 0.000 Yes LimeWire 10 65249.60 548.00 -0.63 0.043 * NetBeans50 10 104188.40 871.10 0.11 0.724 * Noop 10 15652.00 1072.47 -24.22 0.000 Yes XFramer 10 38292.80 1553.79 -13.05 0.000 Yes ============================================================================== footprint3.cds-on.startup3: Benchmark Samples Mean Stdev %Diff P Significant Framer 10 33714.40 1787.46 -17.57 0.000 Yes JEdit 10 56579.20 75.96 -9.85 0.000 Yes LimeWire 10 68328.80 81.19 -5.38 0.000 Yes NetBeans50 10 105353.20 973.95 -1.00 0.010 * Noop 10 17343.60 21.54 -37.64 0.000 Yes XFramer 10 40160.80 2191.83 -18.57 0.000 Yes ============================================================================== So, full classlist (which includes classes loaded by NetBeans50 like com.sun.org.apache.xerces.*) results in addition 2Mb of footprint while providing similar startup time. So, I would recommend to don't include NetBeans classes. Btw, there are no apache classes in jdk7u04 CDS as well.
31-10-2013
Mike: are you referring to CDS benefit or jar ordering benefit? CDS gives over 30% startup improvement on simple HelloWorld. The static classlist is an attempt to get a good representative set of classes to store in the CDS archive to aid in startup for a range of different applications types - including GUI apps. However this list should have been flagged for regeneration on every release. The jar-order benefits are more questionable. I haven't looked into it myself but others report no difference between ordered and random layout.
31-10-2013
I would be curious to see just the results of classlist for just "Hello World". That would at least give us a baseline of whether this feature is useful at all. It might also be useful to compare "nothing" vs "Hello World" vs "full refworkload" vs reverse sorted versions of the same to see how much we are gaining by having a static list. If we can get most of the benefit by having a classlist that could be generated during build (by running "Hello World") then perhaps we shouldn't have a static list. One obvious concern with the current static lists is the situation we are now in with HashMap$Entry which was renamed to HashMap$Node. HashMap$Node is not in the current classlist. With no classlist HashMap and HashMap$Node would be near each other due to the naive depth first traversal that jar uses by default but with the current static list HashMap$Node is not co-located with HashMap. This likely negates the benefits of having a classlist.
31-10-2013
CDS results in better startup on desktop platforms as well. Here are the results of running latest jdk8-b113 with CDS enabled and CDS disabled. On my Windows laptop running without CDS results in up to 30% startup time regression. ============================================================================== startup2.cds_on/: Benchmark Samples Mean Stdev Geomean Weight startup2 10 185.42 7.51 app_awt 10 180.30 15.09 0.50 app_swing 10 191.10 7.53 0.50 ============================================================================== startup2.cds_off/: Benchmark Samples Mean Stdev %Diff P Significant startup2 10 236.99 5.36 -27.81 0.000 Yes app_awt 10 227.30 7.57 -26.07 0.000 Yes app_swing 10 247.20 7.32 -29.36 0.000 Yes ============================================================================== So, I guess there is no question whether we should keep CDS or not for now. The question is what representative set of applications to use to generate CDS archive. I am planning to make few experiments this week and present results by beginning next week.
30-10-2013
Jiangli has recently validated that using the classlist (e.g., with CDS enabled) there are significant startup-time and footprint saving benefits on embedded. I don't remember if she tested on desktop as well. If we are not already doing so, I think start-up/footprint performance between CDS and non-CDS VMs should be tracked regularly as part of the SQE tests.
29-10-2013
I'd like to stress my previous input on checking the validity of keeping the classlists at all. We pay a quite high price in the build system to have the classlists at all. Just keeping them "because we always had" does not seem to me to be a good enough ground to keep them. Is the perfomance impact of having class lists *at all*, vs *not* having any class lists really significant? If this is not the case, chasing what kind of tests to run does not seem to be a meaningful venue.
29-10-2013
classlist contains a lot of anonymous classes like "sun/awt/AppContext$1", which is very sensitive to (unrelated) source code changes or even changes in javac. So the classlist needs to be updated more often than "once per major release". I would propose that the performance team set up an automated profiling environment, so that the classlist can be regenerated with minimal human intervention. It should be done at least once per public release, if not once per promoted build.
18-10-2013
Given all the CDS work in progress I've added Ioi to the watch list.
18-10-2013
I think it's important to remember to check the big issue -- do the class lists help more than they hinder -- and not just blindly repeating a run of apps in a new JDK.
17-10-2013
Are these the same classlists as for jarreorder?
15-10-2013
This is effectively a dup of JDK-8005688. Also see JDK-7032727 and JDK-7033618 There are a lot of open bugs concerning the classlists - including whether they remain a valuable tool - see JDK-7032729 .
12-09-2013