RFR: 8360389: Support printing from C2 compiled code
Tobias Hartmann
thartmann at openjdk.org
Mon Aug 18 07:07:00 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 ...
Great work Benoît! This will be very useful for debugging.
With the current changes, we only support adding printing during parsing, i.e. when `GraphKit` is available. I think it would be great if we could add printing after parsing, for example only once a specific IGVN or loop optimization happened. Do you think that's feasible?
src/hotspot/share/opto/graphKit.hpp line 784:
> 782: address call_addr = CAST_FROM_FN_PTR(address, SharedRuntime::debug_print<TT...>);
> 783:
> 784: Node* str_node = new ConPNode(TypeRawPtr::make(((address) str)));
Don't you need a `transform` here?
src/hotspot/share/opto/runtime.cpp line 1787:
> 1785: switch (parm->bottom_type()->basic_type()) {
> 1786: case T_BOOLEAN:
> 1787: fields[(*argp)++] = TypeInt::BOOL;
I think you can use `Type::get_const_basic_type(parm->bottom_type()->basic_type())` here and special case `T_DOUBLE` / `T_LONG`.
src/hotspot/share/opto/runtime.cpp line 1813:
> 1811: break;
> 1812: case T_OBJECT:
> 1813: fields[(*argp)++] = TypePtr::NOTNULL;
I think passing null should be okay as well, right? I would use `TypeInstPtr::BOTTOM` here, which will be taking care of by `Type::get_const_basic_type`.
-------------
PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3060479577
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2234764495
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2234762106
PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2234763252
More information about the hotspot-dev
mailing list