Providing users with thread type

[Jean Christophe Beyler]

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();
    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;
}

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>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190419/f7426581/attachment.html>