RFR: 8319850: PrintInlining should print which methods are late inlines [v25]

[Johan Sjölen]

On Tue, 10 Dec 2024 08:29:04 GMT, Theo Weidmann <tweidmann at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/16595 @caojoshua previously suggested changes to indicate which calls were inlined late, when printing inlines. This PR re-introduces the changes from the previously closed PR and fixes a minor issue where asserts were triggered.
>> 
>> Concerns were raised by @rwestrel in the previous PR:
>> 
>>> When InlineTree::ok_to_inline() is called, some diagnostic message is recorded for the call site. Do I understand right that with this patch, if the call is inlined late, then that message is dropped and replaced by a new "late inline.." message? If that's the case, isn't it the case that sometimes the InlineTree::ok_to_inline() has some useful information that's lost when late inlining happens?
>> 
>> As already pointed out in the PR by @caojoshua, this does not matter for string/methodhandle/vector/boxing late inlines, as they are [only performed if ok_to_inline() returns true](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/doCall.cpp#L189). This is also the only call to ok_to_inline().  
>> 
>> The only other location, where late inline call generators are created, are calls to CallGenerator::for_late_inline_virtual(), which creates a LateInlineVirtualCallGenerator. LateInlineVirtualCallGenerator (introduced in https://github.com/openjdk/jdk/pull/1550) does not really perform inlining but rather performs strength reduction from virtual to static calls. As can be verified by running the according test `test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java`, this does not affect the printing for inlining:
>> 
>> 
>> 5022 1026       3       compiler.c2.irTests.TestPostParseCallDevirtualization::callHelper (7 bytes)   made not entrant
>>                               @ 1   compiler.c2.irTests.TestPostParseCallDevirtualization$I::method (0 bytes)   failed to inline: virtual call
>> 
>> 
>> Thus, as far as I can tell, the proposed changes by @caojoshua do not lose any useful information about why no inlining prior to the late inlining occurred.
>
> Theo Weidmann has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Add UDivI/L and UModI/L to no_dependent_zero_check"
>    
>    This reverts commit b72ff10ba1581372b72edeadd3cf01a97ccf1c73.
>  - Revert "Update TestSplitDivisionThroughPhi.java"
>    
>    This reverts commit 7526bafff4ea26cb45894477b33f3dd24215e667.

Hi,

It looks good, but maybe we can get rid of `make_stream` by doing something like this:

```c++
class InlinePrinter {
  stringStream* _stream;
public:
  IPInlineAttempt() : _stream(new (mtCompiler) stringStream) {
  }
  IPInlineAttempt(const IPInlineAttempt& other) : _stream(other._stream) {}

  ~IPInlineAttempt() {
    // Doesn't delete _stream on purpose,
    // in order to avoid issue with GA:s copy semantics on resize.
  }

  void deallocate_stream() {
    delete _stream;
  }
}


So we can still use the copy semantics of GA to our advantage at times :-).

Unfortunately, the `TreapCHeap` does not call destructors on deallocation. We've only used it for PODs so far, let me fix that before you integrate this.

src/hotspot/share/opto/printinlining.hpp line 42:

> 40: private:
> 41:   class IPInlineAttempt {
> 42:   private:

Style: No initial `private:` as it's private by default.

src/hotspot/share/opto/printinlining.hpp line 44:

> 42:   private:
> 43:     InliningResult _result;
> 44:     stringStream* _stream = nullptr;

Style: Put initialization into ctrs.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21899#pullrequestreview-2534905667
PR Review Comment: https://git.openjdk.org/jdk/pull/21899#discussion_r1905770817
PR Review Comment: https://git.openjdk.org/jdk/pull/21899#discussion_r1905785411