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

Andrew Haley aph at redhat.com
Wed Mar 11 14:03:23 UTC 2020


On 3/9/20 10:48 AM, Andrew Haley wrote:
> 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.

Thinking some more, ISTM that changing all this code so that it's
tested at startup rather than runtime doesn't gain us very much and
potentially closes the door future improvements in this area. I think
your patch would be smaller and simpler otherwise.

Is the overhead of that test-and-branch significant?

-- 
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



More information about the hotspot-compiler-dev mailing list