Providing users with thread type

[David Holmes]

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.

>      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?

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