[aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1

[Andrew Haley]

On 3/9/20 7:00 AM, Nick Gasson wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8240353
> Webrev: http://cr.openjdk.java.net/~ngasson/8240353/webrev.0/
>
> Runtime1::generate_code_for is missing an implementation for
> dtrace_object_alloc and LIR_Assembler::emit_unwind_handler is
> missing a call to SharedRuntime::dtrace_method_exit.
>
> Currently the interpreter always checks the value of
> DTraceMethodProbes on every method entry/exit, but as far as I can
> tell, this value can only be changed after startup by
> share/services/dtraceAttacher.cpp and that is only built on
> Solaris. With this patch the interpreter code to enable these probes
> is only generated if the appropriate command line options are
> passed. Might be worth making the same change in the other
> non-Solaris ports.

I wonder what the actual intent was here, and whether anyone has a use
for being able to enable dtrace method probes late.

> MacroAssembler::SkipIfEqual is unused now so could be removed.

> Tested jtreg hotspot_all_no_apps and jdk tier1 with
> -XX:+ExtendedDTraceProbes.
>
> Also used bpftrace to check the method_entry, method_return, and
> object_alloc probes are triggered correctly. E.g.
>
>   bpftrace -e 'usdt::hotspot:method__entry { printf("tid:%d, class:%s, name:%s, sig:%s\n", arg0, str(arg1, arg2), str(arg3, arg4), str(arg5, arg6)); }' -p `pidof java`
>
> But this needs the very latest bpftrace/libbcc due to some other
> issues on AArch64.

Hmm, what a pain. Can you tell us what you did to make this work? What
packages you built and installed?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671