RFR: 8360389: Support printing from C2 compiled code
Manuel Hässig
mhaessig at openjdk.org
Mon Aug 18 09:25:15 UTC 2025
On Fri, 25 Jul 2025 09:39:00 GMT, Benoît Maillard <bmaillard at openjdk.org> wrote:
> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types.
>
> ## Usage
>
> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and
> that we compile `square` with C2.
>
> class Square {
> static int square(int a) {
> return a * a;
> }
>
> public static void main(String[] args) {
> square(9);
> }
> }
>
>
> We would like to inspect the node that contains the value returned in this method.
> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect.
>
> ```c++
> void Compile::return_values(JVMState* jvms) {
> GraphKit kit(jvms);
> Node* ret = new ReturnNode(TypeFunc::Parms,
> kit.control(),
> kit.i_o(),
> kit.reset_memory(),
> kit.frameptr(),
> kit.returnadr());
> // Add zero or 1 return values
> int ret_size = tf()->range()->cnt() - TypeFunc::Parms;
>
>
> Node* return_value;
> if (ret_size > 0) {
> kit.inc_sp(-ret_size); // pop the return value(s)
> kit.sync_jvms();
> return_value = kit.argument(0);
> ret->add_req(return_value);
>
> // <-------------------- Simply insert this
> C->make_debug_print_new<jint>("return:", initial_gvn(), return_value);
> }
>
> // bind it to root
> root()->add_req(ret);
> record_for_igvn(ret);
> initial_gvn()->transform(ret);
> }
>
>
> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square`
> and we get the following output:
>
>
> return:
> int 81
>
>
> This case is of course trivial, but more useful examples are shown later.
>
> ## Implementation
> ## Implementation
>
> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed.
>
> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor.
>
> The first argument to the runtime printing method is the printing message, a static ...
Thank you for working on this, @benoitmaillard! This will prove really useful.
I think your logic is sound, but I have some issues with the printing.
src/hotspot/share/opto/compile.cpp line 5483:
> 5481: }
> 5482:
> 5483: #endif
Suggestion:
#endif // !PRODUCT
Nit: This makes it a bit easier to follow the ifdefs.
src/hotspot/share/runtime/sharedRuntime.cpp line 268:
> 266: }
> 267:
> 268: // Runtime methods for printf-style debug nodes (same printing format as fieldDescriptor::print_on_for)
All of these methods should probably use `print_cr()` instead of the manual `\n` to provide consistent output on Windows.
src/hotspot/share/runtime/sharedRuntime.cpp line 292:
> 290: tty->print_raw("long ");
> 291: tty->print_jlong(x);
> 292: tty->print_cr("");
Suggestion:
tty->print_cr("long " JLONG_FORMAT, x);
This is a bit more concise.
src/hotspot/share/runtime/sharedRuntime.cpp line 305:
> 303: void SharedRuntime::debug_print_value(oopDesc* x) {
> 304: x->print();
> 305: }
Can you elaborate why you need an empty print?
-------------
Changes requested by mhaessig (Committer).
PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3127402275
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281768619
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281725334
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281721578
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2281726992
More information about the hotspot-dev
mailing list