RFR: 8292699: Improve printing of classes in native debugger [v11]
Coleen Phillimore
coleenp at openjdk.org
Fri Oct 21 19:08:12 UTC 2022
On Thu, 22 Sep 2022 18:03:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Current in gdb, you can print information about a class or method with something like
>>
>>
>> call ((InstanceKlass*)0x00000008000411b8)->print_on(tty)
>> call ((Method*)0x00007fffb4000d08)->print_codes_on(tty)
>>
>>
>> However, it's difficult to find a class or method by its name and print out its contents.
>>
>> This RFE adds 3 new functions in debug.cpp so you can easily find classes/methods and print out their contents. They all have a `flags` argument that controls the verbosity.
>>
>> - `findclass()`: class name only
>> - `findmethod()`: class name and method name
>> - `findmethod2()`: class name and method name/signature
>>
>> I also cleaned up `BytecodeTracer` to remove unnecessary complexity.
>>
>> Here are some examples:
>>
>>
>> (gdb) call findclass("java/lang/Object", 0)
>> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap'
>>
>> (gdb) call findclass("java/lang/Object", 1)
>> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap'
>> 0x00007fffb4000658 <init> : ()V
>> 0x00007fffb40010f0 finalize : ()V
>> 0x00007fffb4000f00 wait0 : (J)V
>> 0x00007fffb40008e8 equals : (Ljava/lang/Object;)Z
>> 0x00007fffb4000aa0 toString : ()Ljava/lang/String;
>> 0x00007fffb40007f0 hashCode : ()I
>> 0x00007fffb4000720 getClass : ()Ljava/lang/Class;
>> 0x00007fffb40009a0 clone : ()Ljava/lang/Object;
>> 0x00007fffb4000b50 notify : ()V
>> 0x00007fffb4000c20 notifyAll : ()V
>> 0x00007fffb4000e50 wait : (J)V
>> 0x00007fffb4001028 wait : (JI)V
>> 0x00007fffb4000d08 wait : ()V
>>
>> (gdb) call findclass("*ClassLoader", 0)
>> [0] 0x000000080007de40 jdk.internal.loader.ClassLoaders$BootClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap'
>> [1] 0x0000000800053c58 jdk.internal.loader.ClassLoaders$PlatformClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap'
>> [2] 0x0000000800053918 jdk.internal.loader.ClassLoaders$AppClassLoader, loader data: 0x00007ffff0130d10 of 'bootstrap'
>> [....]
>>
>> (gdb) call findmethod2("*ang/Object*", "wait", "()V", 0x7)
>> [0] 0x00000008000411b8 java.lang.Object, loader data: 0x00007ffff0130d10 of 'bootstrap'
>> 0x00007fffb4000d08 wait : ()V
>> 0x00007fffb4000ce8 0 fast_aload_0
>> 0x00007fffb4000ce9 1 lconst_0
>> 0x00007fffb4000cea 2 invokevirtual 38 <java/lang/Object.wait(J)V>
>> 0x00007fffb4000ced 5 return
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>
> @coleenp comments
This seems fine. I had a few comments, not many.
src/hotspot/share/interpreter/bytecodeTracer.cpp line 171:
> 169: void BytecodeTracer::trace_interpreter(const methodHandle& method, address bcp, uintptr_t tos, uintptr_t tos2, outputStream* st) {
> 170: if (TraceBytecodes && BytecodeCounter::counter_value() >= TraceBytecodesAt) {
> 171: ttyLocker ttyl; // 5065316: keep the following output coherent
We should file a a RFE to make this a leaf mutex rather than ttyLocker (which does get broken to allow safepoints!) with no_safepoint_check assuming that the printing doesn't safepoint. Good to remove the no-longer accurate comment.
src/hotspot/share/utilities/debug.cpp line 664:
> 662: }
> 663:
> 664: extern "C" JNIEXPORT void printclass(intptr_t k, int flags) {
It's weird that the function to print the method is findmethod, and the one to print the class is printclass. I see that findmethod is consistent with the 'find' functions above. Maybe this should be findclass() too.
-------------
Marked as reviewed by coleenp (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9957
More information about the hotspot-dev
mailing list