[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Providing users with thread type
From:       Alex Bagehot <ceeaspb () gmail ! com>
Date:       2019-04-28 21:32:40
Message-ID: CAHeneC8UmYik=D0VUT+eTsQQnsNvKw7d-ObYCvFi4Z3QvQROEQ () mail ! gmail ! com
[Download RAW message or body]

Hi Jc,
Have you seen at the work of async profiler? It may provide the kind of
visibility into VM work that you are after.
https://github.com/jvm-profiling-tools/async-profiler
As it can be driven from Linux perf events rather than SIGPROF it is able
to observe more of the system and therefore provides more insights.

Thanks,
Alex

On Thu, Apr 18, 2019 at 3:19 PM Jean Christophe Beyler <jcbeyler@google.com>
wrote:

> Hi all,
>
> When doing profiling, often users have a hard time determining what is
> happening inside libjvm.so. When doing profiling, the JVM seems like a
> black box and it is hard to differentiate between a thread doing
> GC/Compile/Actual VM work since all they get is profiles from libjvm.so but
> not what are the various profiles doing.
>
> We have a small patch that provides a method to users to ask what is the
> type of the current thread, which then provides one of those types
> (GC/Compile/Actual VM work).
>
> I'd like to ask if this seems like a reasonable thing to do and should I
> work on providing this via a JVMTI call. Something like
> GetCurrentThreadType.
>
> What do you all think? Is this sane and possible to try to push forward?
>
> Thanks for your opinions,
> Jc
>

[Attachment #3 (text/html)]

<div dir="ltr"><div dir="ltr">Hi Jc,</div><div>Have you seen at the work of async \
profiler? It may provide the kind of visibility into VM work that you are \
after.</div><div><a href="https://github.com/jvm-profiling-tools/async-profiler">https://github.com/jvm-profiling-tools/async-profiler</a><br></div><div>As \
it can be driven from Linux perf events rather than SIGPROF it is able to observe \
more of the system and therefore provides more \
insights.</div><div></div><div><br></div><div>Thanks,</div><div>Alex</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 3:19 PM \
Jean Christophe Beyler &lt;<a \
href="mailto:jcbeyler@google.com">jcbeyler@google.com</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
all,<div><br></div><div>When doing profiling, often users have a hard time \
determining what is happening inside libjvm.so. When doing profiling, the JVM seems \
like a black box and it is hard to differentiate between a thread doing \
GC/Compile/Actual VM work since all they get is profiles from libjvm.so but not what \
are the various profiles doing.</div><div><br></div><div>We have a small patch that \
provides a method to users to ask what is the type of the current thread, which then \
provides one of those types (GC/Compile/Actual VM \
work).</div><div><br></div><div>I&#39;d like to ask if this seems like a reasonable \
thing to do and should I work on providing this via a JVMTI call. Something like \
GetCurrentThreadType.</div><div><br></div><div></div><div>What  do you all think? Is \
this sane and possible to try to push forward?  <div dir="ltr" \
class="gmail-m_-2854809396081949751gmail_signature"><div \
dir="ltr"><div><br></div>Thanks for your \
opinions,<div>Jc</div></div></div></div></div> </blockquote></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]