RFR: 8271461: CompileCommand support for hidden class methods

[Jie Fu]

On Thu, 29 Jul 2021 22:59:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't believe this can actually work as the name of the hidden class may not be the same from run to run. The mangled name is formed from the address of the instanceKlass.

Thanks @dholmes-ora for your review.

I don't think so.

For the jdk/incubator/vector/Int512VectorTests.java crash bug mentioned by @PaulSandoz [1], the crashed hidden class method is the same during my experiments (on my machine always jdk.incubator.vector.IntVector$$Lambda$327/0x00000008010cad20::apply).

Current CompileTask:
C2:  10672 1251    b        jdk.incubator.vector.IntVector$$Lambda$327/0x00000008010cad20::apply (12 bytes)

Stack: [0x000070000bf83000,0x000070000c083000],  sp=0x000070000c07e900,  free space=1006k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x11feda9]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e9
V  [libjvm.dylib+0x11ff42b]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x5db6fd]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.dylib+0xccb29]  vshiftI_varNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0xb9
V  [libjvm.dylib+0xe40c72]  PhaseOutput::scratch_emit_size(Node const*)+0x302
V  [libjvm.dylib+0xe35ada]  PhaseOutput::shorten_branches(unsigned int*)+0x50a
V  [libjvm.dylib+0xe3521a]  PhaseOutput::Output()+0xc0a
V  [libjvm.dylib+0x581d41]  Compile::Code_Gen()+0x511
V  [libjvm.dylib+0x57ee07]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, bool, DirectiveSet*)+0x1ac7
V  [libjvm.dylib+0x46e279]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x109
V  [libjvm.dylib+0x59bc7f]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x93f
V  [libjvm.dylib+0x59b120]  CompileBroker::compiler_thread_loop()+0x2c0
V  [libjvm.dylib+0x11544e3]  JavaThread::thread_main_inner()+0x273
V  [libjvm.dylib+0x115423c]  JavaThread::run()+0x45c
V  [libjvm.dylib+0x1151277]  Thread::call_run()+0x177
V  [libjvm.dylib+0xe25660]  thread_native_entry(Thread*)+0x150
C  [libsystem_pthread.dylib+0x6109]  _pthread_start+0x94
C  [libsystem_pthread.dylib+0x1b8b]  thread_start+0xf


And for another performance analysis case, the inlined hidden class method is always the same during my experiments (on my machine always org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar$$Lambda$67/0x00000008010213a8::apply).

  11746  100             org.openjdk.bench.jdk.incubator.vector.operation.jmh_generated.ByteScalar_GT_jmhTest::GT_thrpt_jmhStub (53 bytes)
                            @ 7   java.lang.System::nanoTime (0 bytes)   (intrinsic)
                            @ 17   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::GT (91 bytes)   force inline by CompileCommand
                              @ 8   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar$$Lambda$67/0x00000008010213a8::apply (9 bytes)   inline (hot)
                               -> TypeProfile (179/179 counts) = org/openjdk/bench/jdk/incubator/vector/operation/ByteScalar$$Lambda$67+0x00000008010213a8
                                @ 5   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::lambda$new$8 (5 bytes)   inline (hot)
                              @ 25   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar$$Lambda$68/0x00000008010215c8::apply (9 bytes)   inline (hot)
                               -> TypeProfile (179/179 counts) = org/openjdk/bench/jdk/incubator/vector/operation/ByteScalar$$Lambda$68+0x00000008010215c8
                                @ 5   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::lambda$new$9 (5 bytes)   inline (hot)
                              @ 66   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::gt (11 bytes)   inline (hot)
                              @ 87   org.openjdk.jmh.infra.Blackhole::consume (28 bytes)   disallowed by CompileCommand
                            @ 17   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::GT (91 bytes)   force inline by CompileCommand
                              @ 8   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar$$Lambda$67/0x00000008010213a8::apply (9 bytes)   inline (hot)
                               -> TypeProfile (179/179 counts) = org/openjdk/bench/jdk/incubator/vector/operation/ByteScalar$$Lambda$67+0x00000008010213a8
                                @ 5   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::lambda$new$8 (5 bytes)   inline (hot)
                              @ 25   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar$$Lambda$68/0x00000008010215c8::apply (9 bytes)   inline (hot)
                               -> TypeProfile (179/179 counts) = org/openjdk/bench/jdk/incubator/vector/operation/ByteScalar$$Lambda$68+0x00000008010215c8
                                @ 5   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::lambda$new$9 (5 bytes)   inline (hot)
                              @ 66   org.openjdk.bench.jdk.incubator.vector.operation.ByteScalar::gt (11 bytes)   inline (hot)
                              @ 87   org.openjdk.jmh.infra.Blackhole::consume (28 bytes)   disallowed by CompileCommand
                            @ 34   java.lang.System::nanoTime (0 bytes)   (intrinsic)


That's why I say it's helpful for debugging and performance analysis.
Thanks.

[1] https://github.com/openjdk/jdk/pull/4924#issuecomment-888684163

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

PR: https://git.openjdk.java.net/jdk/pull/4926