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 <[email protected]
<mailto:[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
