RFR (preliminary): JDK-8056999 Make hotspot builds less verbose on default log level

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Fri Sep 5 09:53:23 UTC 2014


On 2014-09-04 06:35, David Holmes wrote:
> Hi Magnus,
>
> On 1/09/2014 10:11 PM, Magnus Ihse Bursie wrote:
>> Even in the default log level ("warn"), hotspots builds are extremely
>> verbose. With the new jigsaw build system, hotspot is build in parallel
>> with the jdk, and the sheer amount of hotspot output makes the jdk
>> output practically disappear.
>>
>> This fix will make the following changes:
>> * When hotspot is build from the top dir with the default log level, all
>> repetetive and purely informative output is hidden (e.g. names of files
>> compiled, and the "INFO:" blobs).
>
> I think I probably want a default log level a little more informative 
> than that - I like to see visible progress indicators. :)
>
>> * When hotspot is build from the top dir, with any other log level
>> (info, debug, trace), all output will be there, as before.
>
> Would be nice to have fixed the excessive/repetitive INFO blocks re 
> FDS :) but that requires more than just controlling an on/off switch.
>
>> * When hotspot is build from the hotspot repo, all output will be there,
>> as before.
>>
>> Note! This is a preliminary review -- I have made the necessary changes
>> for Linux only. If this fix gets thumbs up, I'll continue and apply the
>> same pattern to the rest of the platforms. But I didn't want to do all
>> that duplication until I felt certain that I wouldn't have to change
>> something major. The changes themselves are mostly trivial, but they are
>> all over the place :-(.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056999
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8056999-less-verbose-hotspot-builds/webrev.01 
>>
>
> Seems to be some overlap with the $(QUIETLY) mechanism - but to be 
> honest I always have trouble remembering how that works. In looking at 
> it now it seems to me that "$(QUIETLY) echo" is incorrect as the text 
> is always echoed, what gets suppressed is the echoing of the echo 
> command itself - which seems pointless. So I think all "$(QUIETLY) 
> echo" should just be @echo.

I believed that QUIETLY was either set to empty or to @ (default), to 
supress output of the actual command. And yes, ever seeing the actual 
echo command as well as the output seems pointless, so it could probably 
have been @ instead.

But there is no overlap there with my fix. The QUIETLY / @ only handles 
whether the echo command itself is written by make before it is 
executed. The output is always written anyway, and that is what my fix 
deals with.


>
> But then replacing @echo with a $(ECHO) that may be silent would seem 
> a bit cleaner that "@echo $(LOG_INFO). (Not sure what you are doing in 
> the rest of the build).

So what I am doing here is applying the same pattern as we have in the 
rest of build-infra. There we have a group of macros (LOG_WARN, 
LOG_INFO, LOG_DEBUG and LOG_TRACE). The evaluate to either empty, or to 
" > /dev/null". This means that you can determine the log level you want 
this particular output to be on, and it's fairly readable what the 
intention is. E.g.:
$(ECHO) $(LOG_DEBUG) Starting clusterfrizz process now

It is non-trivial to export these to hospot, so I only copied the 
definition of the one I care about for now, LOG_INFO.

I don't think it's a good idea to change $ECHO, since it is used like this
$(ECHO) # Generated file, do not edit! > tmp/myfile.h

You *could* introduce a new $(ECHO_LOG_INFO) or so, but I don't think 
it's better. A valuable effect of the build-infra pattern is that it can 
be applied to any command (such as build tools), not just echo.

>
> print_info is nice.

Thanks.

/Magnus


More information about the hotspot-dev mailing list