<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>I propose to increase the -inlinehint-threshold for Clang build:</div><div>Webrev: <a href="https://cr.openjdk.java.net/~manc/8220388/webrev.00/">https://cr.openjdk.java.net/~manc/8220388/webrev.00/</a><br></div><div><div>RFE: <a href="https://bugs.openjdk.java.net/browse/JDK-8220388">https://bugs.openjdk.java.net/browse/JDK-8220388</a></div></div><div><br></div><div>The background and performance impact is described in the RFE.</div><div>In summary, increasing the -inlinehint-threshold could noticeably reduce GC pause time for G1 when building the JVM with Clang.</div><div><br></div><div>I have a couple of questions though:</div><div>(1) I agree that a better long-term solution might be to identify those performance-critical functions and mark them with "ALWAYSINLINE" instead of "inline".</div><div>However, it might be difficult to identify all those functions, and similar issue might arise in collectors other than G1, or in other places in HotSpot.</div><div>Currently ALWAYSINLINE is rarely used across HotSpot. I'm not sure if there is a convention to prefer "inline" over "ALWAYSINLINE".<br></div><div>If we go down this path, we might end up changing many "inline" to "ALWAYSINLINE" all over the places, due to the cascading effect of inlining.</div><div><br></div><div>(2) Since this change only affects Clang build, and Clang is only officially supported for Mac OS (<a href="https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms">https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms</a>), should I send this patch to broader mailing lists such as build-dev, hotspot-dev?</div><div><br></div><div>Thanks,</div><div><div>Man<br></div></div></div></div></div></div></div></div>