Re: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint
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.9Mj2re-compact1-image # du -s -h j2re-compact2-image 28.7Mj2re-compact2-image # du -s -h j2re-compact3-image 35.5Mj2re-compact3-image after # du -s -h jre-compact1 31.3Mjre-compact1 # du -s -h jre-compact2 41.5Mjre-compact2 # du -s -h jre-compact3 47.4Mjre-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.
Re: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint
Quick question. Why is jdk.localedata module included in the compact profiles? The data there used to be in lib/ext/localedata.jar and lib/ext/cldrdata.jar which weren't included in those compact profiles. Naoto On 12/4/14, 5:48 AM, Alan Bateman wrote: 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.9Mj2re-compact1-image # du -s -h j2re-compact2-image 28.7Mj2re-compact2-image # du -s -h j2re-compact3-image 35.5Mj2re-compact3-image after # du -s -h jre-compact1 31.3Mjre-compact1 # du -s -h jre-compact2 41.5Mjre-compact2 # du -s -h jre-compact3 47.4Mjre-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.
Re: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint
On 04/12/2014 16:38, Naoto Sato wrote: Quick question. Why is jdk.localedata module included in the compact profiles? The data there used to be in lib/ext/localedata.jar and lib/ext/cldrdata.jar which weren't included in those compact profiles. Naoto The "profiles" make target on JDK 8 (and JDK 9 before yesterday) always included localedata.jar in the images. I would expect this would be pruned or removed before deploying to an embedded device of course, same thing for the security providers that get included by default. We've now moved to world where the runtime images are created from a set of modules and this should give a lot of flexibility once. We're just not there yet with locale data so we have to temporarily link in the big jdk.localedata module so that the profiles images have all locales. -Alan.
Re: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint
On 04.12.2014 20:11, Alan Bateman wrote: We've now moved to world where the runtime images are created from a set of modules and this should give a lot of flexibility once. We're just not there yet with locale data so we have to temporarily link in the big jdk.localedata module so that the profiles images have all locales. Just curious, how will we track the size of modules? Probably we can save this information during the build time, so regressions will be found easily? -Alan. -- Best regards, Sergey.
Re: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint
On 05/12/2014 17:57, Sergey Bylokhov wrote: On 04.12.2014 20:11, Alan Bateman wrote: We've now moved to world where the runtime images are created from a set of modules and this should give a lot of flexibility once. We're just not there yet with locale data so we have to temporarily link in the big jdk.localedata module so that the profiles images have all locales. Just curious, how will we track the size of modules? Probably we can save this information during the build time, so regressions will be found easily? Once we are a bit further then I expect we will generate a directory of modules, format TBD. This will be important to have when creating images outside of the JDK build environment, say a custom image with your application, some libraries and their transitive dependences. That might be the time to track the size, although it would really be just an indication, it may be very different when linked in to the eventual image (due to compression and other transformations that might happen at link time). -Alan
