<div dir="ltr">Thanks for the review.<div><br></div>I don't know the internals of GCC well enough to explain this issue, but it is related to function template instantiation due to g1ConcurrentMark.inline.hpp.<div>I'm looking at objdump output of g1BarrierSet.cpp in order to diagnose a performance difference between Clang and GCC builds. Once g1ConcurrentMark.inline.hpp gets transitively included, g1BarrierSet.o contains many instantiations of function templates unrelated to the G1BarrierSet class.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Man</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 13, 2018 at 11:15 PM Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Nov 14, 2018, at 1:29 AM, Man Cao <<a href="mailto:manc@google.com" target="_blank">manc@google.com</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> Could anyone review this small cleanup patch that noticeably reduces size of build output (and likely build time)?<br>
> <br>
> Webrev: <a href="https://cr.openjdk.java.net/~manc/8213829/webrev.00/" rel="noreferrer" target="_blank">https://cr.openjdk.java.net/~manc/8213829/webrev.00/</a><br>
> RFE: <a href="https://bugs.openjdk.java.net/browse/JDK-8213829" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8213829</a><br>
> <br>
> Thanks,<br>
> Man<br>
<br>
Change looks good.<br>
<br>
But I don’t understand the underlying problem.  I would have guessed the include guards would prevent<br>
things that would lead to increased build size or build times (and possibly prevent compilation due to<br>
forward references, but that’s clearly not been happening).<br>
<br>
<br>
</blockquote></div>