Getting Dtraceasm profiler to work with JMH on macOS

[Vsevolod Tolstopyatov]

Hi,

>Paul provided the small patch (below) that explicitly sends a signal
to the sudo process to make sure dtrace spits out the required results.

The implementation of 'Process.destroy' sends SIGTERM [1] anyway, though
manpage for OS X kill [2] claims that EPERM should be returned if "The
sending process is not the superuser and its effective user id does not
match the effective user-id of the receiving process",
but I am failing to reproduce this behaviour on Catalina. This change (kill
with sudo) is worth integrating to avoid spurious errors when EPERM is
returned. It seems like this might be the cause of the crash in
'DTraceAsmProfiler.afterTrial' you recently reported (if so, it can be
easily workarounded by running the java process with superuser privileges
as well).
It would be nice to have a stable reproducer though to be 100% sure that
the actual problem is fixed.

>This avoids the pain of breaking out of the mac sandbox for preloading
libraries

Could you please elaborate on what exactly did you mean here? If I got it
right, it's a PrintAssembly issue rather than a JMH one.

[1]
https://github.com/openjdk/loom/blob/fd43a1961f3a8b92b35854cf06847f20e185c493/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c#L327
[2]
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/kill.2.html

--
Best regards,
Tolstopyatov Vsevolod


On Fri, Feb 28, 2020 at 3:24 PM Patrick Concannon <
patrick.concannon at oracle.com> wrote:

> Hi,
>
> It seems the Dtraceasm profiler does not work with JMH on macOS, and a
> couple of hacks are needed in order to get it working consistently. I
> spoke to Paul Sandoz about this issue, and he was able to provide me
> with the workaround described below.
>
> When using dtraceasm, a dtrace process is executed that samples the
> program counter of processes, and the sampling results are then streamed
> to a file.  The first issue is that the output file is not getting
> updated with samples when JMH kills the dtrace process.
> Paul provided the small patch (below) that explicitly sends a signal to
> the sudo process to make sure dtrace spits out the required results.  He
> mentioned that this might be something to do with the Java
> implementation of Process.destroy.
>
>
> diff -r 1a48e97d9dea
> jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java
> ---
> a/jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java
> Fri Feb 14 09:42:04 2020 +0100
> +++
> b/jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java
> Mon Feb 24 12:20:48 2020 -0800
> @@ -87,6 +87,9 @@
>               throw new IllegalStateException("DTrace needs the forked
> VM PID, but it is not initialized");
>           }
> +        long dtracePid = dtraceProcess.pid();
> +        Utils.tryWith("sudo", "kill", "-15", Long.toString(dtracePid));
> +
>           Collection<String> messages = Utils.destroy(dtraceProcess);
>           if (!messages.isEmpty()) {
>               throw new IllegalStateException(messages.toString());
>
>
> As well as applying the patch above, you also have to ensure the hsdis
> library is preloaded when running the JVM. The easiest way to ensure
> this is to place it in the current directory. This avoids the pain of
> breaking out of the mac sandbox for preloading libraries. This issue was
> previously discussed here:
> http://mail.openjdk.java.net/pipermail/jmh-dev/2018-January/002686.html.
>
>
> While the solution above works, it is not ideal. I wanted to send this
> email to the list to see if there was any interest in possibly finding a
> more permanent solution to this?
>
>
> Kind regards,
>
> Patrick
>
>