Getting Dtraceasm profiler to work with JMH on macOS
Patrick Concannon
patrick.concannon at oracle.com
Wed Apr 8 08:56:25 UTC 2020
Hi Vsevolod,
It seems as though the patch fixes the issue regardless of the location
of the hsdis library file (my mistake), or whether csrutil is enabled or
disabled.
Calling kill with sudo doesn't seem like an ideal way to solve this
problem. Do you know if there is another way around this?
Kind regards,
Patrick
On 26/03/2020 15:48, Vsevolod Tolstopyatov wrote:
> 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
> <https://urldefense.com/v3/__https://github.com/openjdk/loom/blob/fd43a1961f3a8b92b35854cf06847f20e185c493/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c*L327__;Iw!!GqivPVa7Brio!K0jWKV3qCWssUeX-Bx9_RVM5P8GkR8JiXB-ZbPgvsHhEg93D6CYQsp8BaYrI6QpcS3X3JQ$>
> [2]
> https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/kill.2.html
> <https://urldefense.com/v3/__https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/kill.2.html__;!!GqivPVa7Brio!K0jWKV3qCWssUeX-Bx9_RVM5P8GkR8JiXB-ZbPgvsHhEg93D6CYQsp8BaYrI6QqG7uy_Tg$>
>
> --
> Best regards,
> Tolstopyatov Vsevolod
>
>
> On Fri, Feb 28, 2020 at 3:24 PM Patrick Concannon
> <patrick.concannon at oracle.com <mailto: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
>
More information about the jmh-dev
mailing list