RFR: 8253270: Limit fastdebug inlining in G1 evacuation

[Kim Barrett]

> On Sep 17, 2020, at 5:01 AM, Albert Mingkun Yang <ayang at openjdk.java.net> wrote:
> 
> On Thu, 17 Sep 2020 08:55:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
> 
>>> Please review this change to G1 evacuation to prevent inlining of some functions in debug (particularly, fastdebug)
>>> builds. This reduces the size of the generated code to stay away from limits encountered with gcc when compiling for
>>> aarch64.  As a side benefit, this adds more call frames that might be helpful with debugging.  Testing: tier1
>>> Verified expected inlining on linux-x64 and linux-aarch64 in both release and fastdebug builds.
>> 
>> Lgtm.
> 
> If this workaround is needed due to a compiler bug, I think it's best to include a reference to the corresponding
> compiler ticket(s) so that it's possible to undo this workaround when the bug is fixed.

I looked for an existing bug report in gcc's bug tracker, but didn't find
one.  It might have been reported in some other aarch64-focused tracker.  I
didn't spend too much time looking.

I think the change is reasonable to leave in place permanently.  It does
have the mentioned side benefit.   It also speeds up compilation of that file 
in fastdebug builds by a noticeable amount.  (The fastdebug output file
is *huge*.)

> On second thought, I wonder if
> it's feasible to just raise the required compiler version, assuming this bug is fixed in later versions of gcc.

The JDK-8253169 failure occurs with gcc9.2, but not with gcc10.2, so may
have been fixed already.  Or maybe some other code generation change caused
the problem limit to not be reached with the later compiler.  I'm in favor
of reporting bugs upstream when they are found, but this one doesn't seem
likely to be worth the effort.

Increasing the mininum required gcc version for linux-aarch64 to 10.x
doesn't seem reasonable at this time, without a much better reason than this.

> PR: https://git.openjdk.java.net/jdk/pull/220