RFR (XS): 8220388: Increase -inlinehint-threshold for Clang to avoid G1 pause time regression

[Man Cao]

(Adding build-dev at openjdk.java.net)
Maybe some one from build-dev could review or comment on this change?

-Man

On Mon, Mar 11, 2019 at 12:55 PM Man Cao <manc at google.com> wrote:

> Thanks for the suggestion.
> Yes, I agree it makes sense to increase -inlinehint-threshold only for
> "release" build.
> However, I'm not sure if adding per-file CXX flags in JvmOverrideFiles.gmk
> is a better approach.
> The root problem is that Clang is more likely to ignore the "inline"
> keyword than GCC, causing unexpected performance problems. G1 pause time
> could be just one of many potential performance problems.
> If we take the effort to identify which files need the
> -inlinehint-threshold flag, we'd better take a step further to identify the
> functions that should be ALWAYSINLINE.
>
> Thus I think it is more maintainable to do one the following:
> (1) Identify the functions that should be "ALWAYSINLINE" instead of
> "inline", and avoid adding "-inlinehint-threshold" for Clang altogether.
> This requires much more work.
> (2) Increase "-inlinehint-threshold" for all files in "release" build for
> Clang.
> Note that -inlinehint-threshold is different from -inline-threshold, as
> -inlinehint-threshold only affects methods marked as "inline" and shouldn't
> unnecessarily bloat up the binary size for release build.
>
> So I added an extra guard "x$DEBUG_LEVEL" = xrelease;" in flags-cflags.m4:
> https://cr.openjdk.java.net/~manc/8220388/webrev.01/
>
> -Man
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190426/ad0bc2b0/attachment.htm>