RFR: 8292699: Improve printing of classes in native debugger [v5]

[Ioi Lam]

On Mon, 22 Aug 2022 05:29:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi Ioi,
> 
> this looks neat. Not a full review, just some remarks:
> 
> * Not your patch, but while playing with this I found that "call help()" needs a RM, which means gdb crashes out in a non-attached thread (e.g. the primordial one). Would be nice if no RM were needed.

I think that would be too hard to do, as a lot of the printing functions depend on RM.

> * Calling "findclass" from a java thread yielded this:
> 
> ```
> (gdb) call findclass("*", 7)
> [Thread 0x7fffb28cf700 (LWP 112211) exited]
> 
> "Executing findclass"
> 
> Thread 2 "java" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff6fe17ba in assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:178
> 178       fatal("must own lock %s", lock->name());
> ...
> (gdb) bt
> #0  0x00007ffff6fe17ba in assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:178
> #1  assert_locked_or_safepoint (lock=0x7ffff0027320) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/mutexLocker.cpp:172
> #2  0x00007ffff639dcfb in ClassLoaderDataGraphIteratorBase<true>::ClassLoaderDataGraphIteratorBase (this=0x7ffff57b3390) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/runtime/handles.hpp:263
> #3  ClassLoaderDataGraph::classes_do (klass_closure=klass_closure at entry=0x7ffff57b3420) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classLoaderDataGraph.cpp:366
> #4  0x00007ffff63acbe0 in ClassPrinter::print_classes_unlocked (class_name_pattern=class_name_pattern at entry=0x7ffff7d5de80 "*", flags=flags at entry=7) at /shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/classfile/classPrinter.cpp:139
> ```

I changed ClassPrinter to use proper locking. The down side is if you call it in some narrow windows where the locks are already held, gdb would deadlock, but I think those windows are very small.

> * You could add a simple test at least as gtests, looking for some well-known classes.

I'll work on a few gtest cases.

> * instead of using int for flags, maybe use an enum class and define the bitwise combine operator? Like this:
>
> ```
>   enum class Mode : int {
>     PRINT_METHOD_NAME       = 1 << 0,
>     PRINT_BYTECODE          = 1 << 1,
>     PRINT_BYTECODE_ADDR     = 1 << 2,
>     PRINT_DYNAMIC           = 1 << 3, // extra information for invokedynamic (and dynamic constant ...)
>   };
>   
>   constexpr enum Mode operator | (enum Mode selfValue, enum Mode inValue) { return (Mode)(uint32_t(selfValue) | uint32_t(inValue)); }
> ```


The problem with 'enum class' is you can't use it easily inside gdb. You must do a lot of typing like:


call findclass("*Object", ClassPrinter::Mode::PRINT_ALL)
call findclass("*Object", ClassPrinter::Mode::PRINT_METHOD_NAME | ClassPrinter::Mode::PRINT_METHOD_ADDR)


In contrast, it's much easier to do this to enable everything.


call findclass("*Object", 0xff)

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

PR: https://git.openjdk.org/jdk/pull/9957