Providing users with thread type

[Thomas Stüfe]

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 <jcbeyler at google.com>
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 <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/a2d8b46f/attachment.html>