RFR: JDK-8245168 jlink should not be treated as a "small" tool

Erik Joelsson erik.joelsson at oracle.com
Mon May 18 16:02:27 UTC 2020


On 2020-05-18 07:58, Magnus Ihse Bursie wrote:
> On 2020-05-18 15:16, Erik Joelsson wrote:
>> Should we then add the big flags instead to have some control over 
>> memory footprint, or are we trusting the default ergonomics to do the 
>> right thing on every possible build system out there?
> You make it sound like we shouldn't. :-) But seriously, I think we 
> should have some faith in our product to actually produce good default 
> values. If anything, the "small" flags were created to signal that the 
> default ergonomics didn't really apply, that we favored fastest 
> possible startup, at the expense of long-term performance.
>
Well we are making some attempt at creating a suitable set of BIG flags 
in configure based on the build system, but that is mainly to make sure 
we allocate enough resources to the javac server. On second thought I 
agree that the main reason for java flags in the build is to keep the 
footprint of most of them small. Unless there was a measurable 
performance increase using BIG for jlink, there is no point.
>  Also, this is what we do for all other tools. There is no 
> "$(JAVA_TOOL_FLAGS_BIG)". Yes, I know, there is a $(JAVA_FLAGS_BIG), 
> and we could of course turn it into a "TOOLS" version, but so far we 
> have not done that. (The difference is that the "normal" version is 
> supposed to be passed to java, like -Xmx, and the "TOOLS" version is 
> supposed to be passed to tools like javac, so they are prefixed with 
> -J like -J-Xmx.)
>
> Are you happy with this, or do you want me to change the patch to 
> include a new JAVA_TOOL_FLAGS_BIG?
>
Nah, I'm ok with it. Looks good.

/Erik

> /Magnus
>>
>> /Erik
>>
>> On 2020-05-18 03:12, Magnus Ihse Bursie wrote:
>>> The linking of the JDK image using the jlink tool takes a 
>>> considerable amount of time. However, the jlink tool is classified 
>>> as a "small java" tool in the build script. This should only be used 
>>> on quick small tools where a long startup time has a measurable 
>>> performance impact. Clearly this does not apply to jlink.
>>>
>>> The effect of removing the small tool flags are most pronounced when 
>>> running a slowdebug build. Robbin Ehn, which made me aware of this, 
>>> reduced the running time of jlink from 36 to 21 seconds on his 
>>> machine by removing the "small" flags. On a release build, the 
>>> effect is much less noticeable, but it's still worth fixing.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245168
>>> Patch inline:
>>> diff --git a/make/autoconf/spec.gmk.in b/make/autoconf/spec.gmk.in
>>> --- a/make/autoconf/spec.gmk.in
>>> +++ b/make/autoconf/spec.gmk.in
>>> @@ -642,7 +642,7 @@
>>>  JAVAC=@FIXPATH@ $(JAVAC_CMD)
>>>  JAVADOC=@FIXPATH@ $(JAVADOC_CMD)
>>>  JAR=@FIXPATH@ $(JAR_CMD)
>>> -JLINK = @FIXPATH@ $(JLINK_CMD) $(JAVA_TOOL_FLAGS_SMALL)
>>> +JLINK = @FIXPATH@ $(JLINK_CMD)
>>>  JMOD = @FIXPATH@ $(JMOD_CMD) $(JAVA_TOOL_FLAGS_SMALL)
>>>  JARSIGNER=@FIXPATH@ $(JARSIGNER_CMD)
>>>  JJS=@FIXPATH@ $(JJS_CMD) $(JAVA_TOOL_FLAGS_SMALL)
>>>
>>> /Magnus
>



More information about the build-dev mailing list