Providing users with thread type

[Jean Christophe Beyler]

Hi David,

On Fri, Apr 19, 2019 at 6:49 PM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Jc,
>
> On 20/04/2019 12:30 am, Jean Christophe Beyler wrote:
> > Problem is that if I don't have a jthread, I can't get the name it
> > seems. Perhaps it could help if I gave more information:
> >
> > - In our JVM profiling mechanism, we have a SIGPROF (and maybe that's a
> > wrong approach :-)) that gets cycled across threads (some Java threads,
> > some are the other threads)
> >     - It is the other threads that I'm interested here to be able to
> > distinguish what they are in terms of of profiles
> >
> > Is there any way we could provide  that (not in JVMTI then)?
> >     - The only way I could imagine perhaps doing this would be perhaps
> > to have a set of other tools at the same time running (either using
> > beans before/after or JFR) but this seems crude as well (better than
> > nothing though)
> >     - I wish there was a way to just be able to get a type for those
> > internal frames while doing the actual SIGPROF handling
> >
> > FWIW, the method we expose basically is like this:
> >      Thread* current_thread =
> ThreadLocalStorage::get_thread_async_safe();
>
> We have Thread::current_or_null_safe() for that.
>

A decade old code might have rotted a bit (or been wrong from the start),
I'll change this internal code :)

>
> >      if (current_thread == NULL) {
> >        return -1;
> >      } else if (current_thread->is_Compiler_thread()) {
> >        return _activity_compile;
> >      } else if (current_thread->is_Java_thread()) {
> >        return -1;
> >      } else if (current_thread->is_GC_task_thread()) {
> >        return _activity_gc;
> >      } else if (current_thread->is_VM_thread()) {
> >        VMThread* vm_thread = (VMThread*) current_thread;
> >        VM_Operation* vm_op = vm_thread->vm_operation();
> >        if (vm_op != NULL) {
> >          switch (vm_op->type()) {
> >            case VM_Operation::VMOp_GC_HeapInspection:
> >            case VM_Operation::VMOp_GenCollectFull:
> >            case VM_Operation::VMOp_GenCollectFullConcurrent:
> >            case VM_Operation::VMOp_GenCollectForAllocation:
> >            case VM_Operation::VMOp_ParallelGCFailedAllocation:
> >            case VM_Operation::VMOp_ParallelGCSystemGC:
> >            case VM_Operation::VMOp_CGC_Operation:
> >            case VM_Operation::VMOp_CMS_Initial_Mark:
> >            case VM_Operation::VMOp_CMS_Final_Remark:
> >            case VM_Operation::VMOp_G1CollectFull:
> >            case VM_Operation::VMOp_G1CollectForAllocation:
> >            case VM_Operation::VMOp_G1IncCollectionPause:
> >              return _activity_gc;
> >            default:
> >              break;
> >          }
> >        }
> >      }
> >      return _activity_other_vm;
> > }
>
> So it's not really the thread "type" but the logical "activity". For
> "type" you'd just need a query version of Thread::print_on_error (more
> or less).


> Not at all sure where you could put this - nor clear why you need to put
> it somewhere: isn't this just something executed by your SIGPROF handler?
>

Well problem is that I'm not in the JVM at the sigprof handler level. I'm
actually in the agent, so basically from the agent's point of  view, I
don't really know what "Activity" I just stopped but would love to know. We
added internally this change to figure it out but I'd like to get it in the
open-source so that all could use it and not just us internally. Basically,
like I said ,when using open-source profilers, this would help divide up
the "libjvm.so" bucket that a lot of profilers are getting.

Thanks for your insight as always,
Jc



> David
>
> > It's crude but we believe it is effective to at least "bucketize" the
> > internals while doing our profiling.
> >
> > Thanks for your input,
> > Jc
> >
> > On Fri, Apr 19, 2019 at 9:01 AM Alan Bateman <Alan.Bateman at oracle.com
> > <mailto:Alan.Bateman at oracle.com>> wrote:
> >
> >     On 19/04/2019 00:12, David Holmes wrote:
> >      >
> >      > I think it would be difficult to put something like this in JVM TI
> >      > given that the use of threads within the JVM are purely an
> >      > implementation detail and not standardized in any way. And many of
> >      > those threads are hidden from JVM TI anyway.
> >      >
> >      > The names of threads are the normal way to see what "type" of
> thread
> >      > you're dealing with.
> >     Right, JVM TI only deals with "Java threads" (jthread object) and
> >     has no
> >     knowledge about other threads. It might be possible to use its
> >     extension
> >     mechanism to provide information about other threads but it wouldn't
> be
> >     interoperable with anything that use jtherad objects.
> >
> >     -Alan
> >
> >
> >
> > --
> >
> > Thanks,
> > Jc
>


-- 

Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190419/c1205002/attachment-0001.html>