RFR [JEP 220] Modular Run-Time Images - compact profiles footprint

[Alan Bateman]

On 04/12/2014 12:58, Xerxes Rånby wrote:
> The footprint of the compact profiles have been inflated by ~12Mb each 
> after the JEP 220 changes.
>
> before
> # du -s -h j2re-compact1-image
> 17.9M    j2re-compact1-image
> # du -s -h j2re-compact2-image
> 28.7M    j2re-compact2-image
> # du -s -h j2re-compact3-image
> 35.5M    j2re-compact3-image
>
> after
> # du -s -h jre-compact1
> 31.3M    jre-compact1
> # du -s -h jre-compact2
> 41.5M    jre-compact2
> # du -s -h jre-compact3
> 47.4M    jre-compact3
>
> The attached file compact1.diff.tar.gz contains the list diff of the 
> files bundled in the
> j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage
> most of the class diff is located in
>
> com/sun/security/ntlm
> com/sun/crypto
> javax/crypto
> sun/net/www/protocol/http/ntlm
> sun/net/www/protocol/ftp
> sun/net/www/protocol/mailto
> sun/net/ftp
> sun/net/smtp
> sun/net/dns
> sun/util/resources <- a lot of extra internationalized classes
> sun/security/ssl
> sun/security/ec
> sun/security/pkcs11
> sun/text/resources <- a lot of extra internationalized classes

The release file in the top directory of the runtime image gives a good 
indication as to what is going on. If you look at the value of the 
MODULES key then you'll the see the modules that are actually linked in. 
For jre-compact1 then you should see a line like this:

MODULES="java.base jdk.localedata java.scripting java.logging 
java.compact1 jdk.crypto.ec jdk.crypto.pkcs11"

The java.* modules are the modules that make up compact1, the jdk.* 
modules are additional service providers linked into the image. The 
service providers aren't strictly required to be there, we've just 
chosen to include them so that "profiles" make target gives us images 
that approximately correspond to what we had previously. If you want to 
play around with leaving them out then look in make/Images.gmk and 
COMPACT_EXTRA_MODULES. Going forward then I expect we will have a tool 
that will allow for a lot more flexibility to create images with just 
the modules that you want (and their transitive dependences of course).

So I think the bulk of the difference that you are seeing is explained 
by the service providers and mostly jdk.localedata. That module is big 
and contains all of non-US_en JRE locale data and all of the CLDR data. 
We still need to figure out what how to split this, you might recall the 
discussion on i18n-dev and jigsaw-dev where they was some recent 
discussion on this. It's also listed in JEP 200 as an open issue.

So when comparing to JDK 8 or previous JDK 9 compact profile builds then 
think of the new images has having the equivalent of both localedata.jar 
and cldrdata.jar present. If you edit COMPACT_EXTRA_MODULES to remove 
jdk.localdata.jar then it should make it easier to compare.

Another thing to point out is that rt.jar isn't everything in the legacy 
image. You need to take account of jce.jar, jsse.jar and 
ext/sunjce_provider.jar. That should explain the javax.crypto, 
com.sun.crypto and sun.security.ssl packages in your list.

Another thing to mention is the java.base module currently contains a 
few legacy items that we previously stripped out of the profiles builds 
in JDK 8. We still need to figure out what to do with these. The ftp and 
smtp protocol handlers come to mind, also the NTLM htto authentication 
scheme. At one point we have a "compat" module for legacy stuff that 
people might want for compatibility reasons. So expect some tweaking 
here, we know people focused on footprint will not thank us for bringing 
back legacy stuff.

A few final point to mention. (a) there are a few additional launchers 
(and maybe debug info/diz files if build with those) that were not there 
previously. This is a consequence of modularization where modules with 
launchers and where the classes for those launchers were previously in 
tools.jar. (b) there are some additional classes that didn't previously 
exist in JDK 9, this is to support the new image format. I expect some 
churn with those over the next few months.

So hopefully this helps to explain what you are seeing. I think folks 
might be interested in see j2re-image vs. jre and j2sdk-image vs. jdk 
sizes too.

-Alan.