RFR: 8319879: Stress mode to randomize incremental inlining decision

Tobias Hartmann thartmann at openjdk.org
Wed Nov 15 14:13:29 UTC 2023


On Tue, 14 Nov 2023 17:11:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I don't see -XX:-AlwaysIncrementalInline in these 2 tests. They have only -XX:-StressMethodHandleLinkerInlining which only control inlining for MH. I am not saying that adding -XX:-StressIncrementalInlining is wrong but I need explanation.

You are right, I looked at the wrong test. `AbstractRootMethod` and `DefaultRootMethod` failed in my testing but looking at it again, they also intermittently failed with `-XX:+AlwaysIncrementalInline`. I think that might be because I added `should_delay` to `CallGenerator::for_method_handle_call`. I'll check again with Roland's fix for [JDK-8319764](https://bugs.openjdk.org/browse/JDK-8319764) because these failures generated a lot of noise.

> Can we change meaning of -XX:+AlwaysIncrementalInline -XX:+StressIncrementalInlining combination?

`AlwaysIncrementalInline` is a debug flag and therefore always false in product, whereas `StressIncrementalInlining`, similar to the other stress flags that we have, is a diagnostic flag. Making it dependent on `AlwaysIncrementalInline` will essentially disable it in product.

Also, I think it would be misleading if `AlwaysIncrementalInlining` would not always lead to incremental inlining, right?

Separately, we could convert `AlwaysIncrementalInlining` to a compiler directive to enable it on a per-method basis. Because in all the use cases that I can imagine, you usually want to enable it just for a few methods and not for all. And if you want stress testing, you can now use `-XX:+StressIncrementalInlining` which is even more powerful.

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

PR Comment: https://git.openjdk.org/jdk/pull/16597#issuecomment-1812603786


More information about the hotspot-compiler-dev mailing list