Hi JC, not sure if that helps, but we set - originally for debugging purposes - the thread name for platforms where that is possible. This is what you see in gdb when listing threads.
On POSIX platforms this means we call some form of pthread_setname_np(), which can be queried from the outside with pthread_getname_np(). See os::set_native_thread_name(). Feels a bit wrong to rely on this though, but maybe it helps. Cheers, Thomas On Fri, Apr 19, 2019 at 4:30 PM Jean Christophe Beyler <[email protected]> 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(); > 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 <[email protected]> > 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 >
