RFR: 8319850: PrintInlining should print which methods are late inlines [v21]
theoweidmannoracle
duke at openjdk.org
Fri Nov 29 08:15:30 UTC 2024
> 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.
theoweidmannoracle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
- Merge branch 'master' into 8319850
- Add missing header
- Update memory management and use treap
- Fix style
- Derecursify locate
- Merge branch 'master' into 8319850
- Change comment style
- Change is_enabled to old pattern
- Fix TestDuplicatedLateInliningOutput
- Fix BCI -1
- ... and 17 more: https://git.openjdk.org/jdk/compare/6168806a...44aabf62
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/21899/files
- new: https://git.openjdk.org/jdk/pull/21899/files/5364a488..44aabf62
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=21899&range=20
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=21899&range=19-20
Stats: 22548 lines in 530 files changed: 10874 ins; 8708 del; 2966 mod
Patch: https://git.openjdk.org/jdk/pull/21899.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/21899/head:pull/21899
PR: https://git.openjdk.org/jdk/pull/21899
More information about the hotspot-compiler-dev
mailing list