JDK-8157991 : Performance data/impact for users to determine what jlink optimization should be selected
  • Type: Task
  • Component: tools
  • Sub-Component: jlink
  • Priority: P3
  • Status: Resolved
  • Resolution: Not an Issue
  • Submitted: 2016-05-26
  • Updated: 2017-02-16
  • Resolved: 2017-02-16
Related Reports
Relates :  
JDK-8131679 - JEP 282: jlink: The Java Linker
Relates :  
JDK-8174209 - Renumber the compress levels
Description
Feedback from Aurelio:

jlink offers these built-in optimization at the moment and maybe more in the future:
  -G, --strip-debug                 Strip debug information
  -c, --compress=2                  Enable compression of resources (level 2)

For developers to determine what options should be selected, it'd be useful to provide performance data such as impact on runtime and footprint that would help guide the jlink users.

Probably such information would publish in a user guide or some kind of documentation.
Comments
I don't think there are further changes here so I will close this issue for now.
16-02-2017
Should this issue be closed now? As we agree, --compress 0 is changed to no compression and is the default (JDK-8174209). AFAICT there is no remaining task to follow.
15-02-2017
--compress=0 is 1.5x slower than no --compress for certain javac runs, yes. It varies with size and scale of the compilation, of course. All tested images are sorted in the same way, so the startup improvement with --compress=0 on tiny applications may be because of tighter packing of class data (since the string data is moved out and packed), along with there being a relatively small number of strings we load and unpack during the early startup. Since any gain is eaten up on anything larger than a hello world it's really just a curiosity, though. --compress=none|quick|full ?
08-02-2017
Is it a fair statement to say javac with --compress=0 is 1.5x slower to javac with no compression? Does it make any difference if it runs on an image just linked with jdk.compiler? I agree to drop --compress=2. I don't know about --compress=fast which may give a false impression that will speed up the runtime. Does the 8ms startup improvement on helloworld use the sorted resource plugin?
04-01-2017
--strip-debug is enabled by default in the build for JRE images, and reduces size of the runtime image (lib/modules) by ~20% (130M -> 106M) with no effect on startup --compress=0 drops the size of lib/modules by ~30% (106M -> 69.5M), and actually seems to benefit startup in simple tests (~8 ms improvement on Hello World). --compress=1 drops the size of lib/modules by ~54% (106M -> 49M), but comes with a penalty to startup (~8ms slowdown on Hello World) --compress=2 drops the size of lib/modules by ~53% (106M -> 49.5M), but comes with an even greater penalty to startup (~13ms slowdown on Hello World) In my opinion the numeric level argument to --compress is counter-intuitive and should perhaps be called out explicitly instead (--compress=strings, --compress=zip). Since it appears the two different compression strategies are working against each other it seems that perhaps they should even be mutually exclusive (remove --compress=2). --compress=0 strikes a balance between improving startup and static footprint, --compress=1 minimizes static footprint at a small penalty to startup time.
28-12-2016
I think we should drop -compress=2 and use none, fast, small instead of numbers (or similar ilk)
28-12-2016
A more thorough examination shows that on anything larger, startup numbers using any of the --compress options are worse off. One extreme case is a quick run of javac that adds about 250ms on a run that usually takes around 500m when the JDK is built with --compress=0 The other observations still appear valid though: the two different compression schemes shouldn't be used together (--compress=2), --compress=0 gives less of a slowdown - if any - on many applications, while --compress=1 is better at compressing but has larger runtime overhead.
28-12-2016
Need some data to pass on to Docs
26-07-2016