RFR: 8329126: No native wrappers generated anymore with -XX:-TieredCompilation after JDK-8251462 [v3]

[Igor Veresov]

On Wed, 27 Mar 2024 09:59:51 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since [JDK-8251462: Simplify compilation policy](https://bugs.openjdk.org/browse/JDK-8251462), introduced in JDK 17, no native wrappers are generated any more if running with `-XX:-TieredCompilation` (i.e. native methods are not compiled any more).
>> 
>> The attached JMH benchmark demonstrate that native method calls became twice as expensive with JDK 17:
>> 
>>   public static native void emptyStaticNativeMethod();
>> 
>>   @Benchmark
>>   public static void baseline() {
>>   }
>> 
>>   @Benchmark
>>   public static void staticMethodCallingStatic() {
>>     emptyStaticMethod();
>>   }
>> 
>>   @Benchmark
>>   public static void staticMethodCallingStaticNative() {
>>     emptyStaticNativeMethod();
>>   }
>> 
>>   @Benchmark
>>   @Fork(jvmArgsAppend = "-XX:-TieredCompilation")
>>   public static void staticMethodCallingStaticNativeNoTiered() {
>>     emptyStaticNativeMethod();
>>   }
>> 
>>   @Benchmark
>>   @Fork(jvmArgsAppend = "-XX:+PreferInterpreterNativeStubs")
>>   public static void staticMethodCallingStaticNativeIntStub() {
>>     emptyStaticNativeMethod();
>>   }
>> 
>> 
>> JDK 11
>> ======
>> 
>> Benchmark                                           Mode  Cnt   Score   Error  Units
>> NativeCall.baseline                                 avgt    5   0.390 ± 0.016  ns/op
>> NativeCall.staticMethodCallingStatic                avgt    5   1.693 ± 0.053  ns/op
>> NativeCall.staticMethodCallingStaticNative          avgt    5  10.287 ± 0.754  ns/op
>> NativeCall.staticMethodCallingStaticNativeNoTiered  avgt    5   9.966 ± 0.248  ns/op
>> NativeCall.staticMethodCallingStaticNativeIntStub   avgt    5  20.384 ± 0.444  ns/op
>> 
>> 
>> JDK 17 & 21
>> ===========
>> 
>> Benchmark                                           Mode  Cnt   Score   Error  Units
>> NativeCall.baseline                                 avgt    5   0.390 ± 0.017  ns/op
>> NativeCall.staticMethodCallingStatic                avgt    5   1.852 ± 0.272  ns/op
>> NativeCall.staticMethodCallingStaticNative          avgt    5  10.648 ± 0.661  ns/op
>> NativeCall.staticMethodCallingStaticNativeNoTiered  avgt    5  20.657 ± 1.084  ns/op
>> NativeCall.staticMethodCallingStaticNativeIntStub   avgt    5  22.429 ± 0.991  ns/op
>> 
>> 
>> The issue can bee seen if we run with `-XX:+PrintCompilation -XX:+PrintInlining`. With JDK 11 we get the following output for `-XX:+TieredCompilation`:
>> 
>>     172  111    b  3       io.simonis.NativeCall::staticMethodCallingStaticNative (4 bytes)
>>                               @ 0   io.simonis.NativeCall::emptyStaticNa...
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Regarding the solution. You seem to be tapping into the `is_method_profiled()` functionality and applying the threshold rule meant for methods with MDOs, which is a bit hacky. How about a more straightforward way:


diff --git a/src/hotspot/share/compiler/compilationPolicy.cpp b/src/hotspot/share/compiler/compilationPolicy.cpp
index d61de7cc866..57173ed621c 100644
--- a/src/hotspot/share/compiler/compilationPolicy.cpp
+++ b/src/hotspot/share/compiler/compilationPolicy.cpp
@@ -1026,7 +1026,7 @@ CompLevel CompilationPolicy::common(const methodHandle& method, CompLevel cur_le
   if (force_comp_at_level_simple(method)) {
     next_level = CompLevel_simple;
   } else {
-    if (is_trivial(method)) {
+    if (is_trivial(method) || method->is_native()) {
       next_level = CompilationModeFlag::disable_intermediate() ? CompLevel_full_optimization : CompLevel_simple;
     } else {
       switch(cur_level) {


What do you think? Would that work?

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

PR Comment: https://git.openjdk.org/jdk/pull/18496#issuecomment-2023178005