RFR: 7194254 jstack reports wrong thread priorities

[Dmytro Sheyko]

David,

Maybe it makes sense to do some little corrections in format specifiers:

    st->print("#" INT64_FORMAT " ", java_lang_Thread::thread_id(thread_oop));
    if (java_lang_Thread::is_daemon(thread_oop))  st->print("daemon ");
    st->print("prio=" INT32_FORMAT " ", java_lang_Thread::priority(thread_oop));

instead of

    st->print("#%ld ", java_lang_Thread::thread_id(thread_oop));
    if (java_lang_Thread::is_daemon(thread_oop))  st->print("daemon ");
    st->print("prio=%d ", java_lang_Thread::priority(thread_oop));

Thanks,
Dmytro


> Date: Fri, 7 Sep 2012 16:54:32 +1000
> From: david.holmes at oracle.com
> To: hotspot-dev at openjdk.java.net
> CC: dmytro_sheyko at hotmail.com; serviceability-dev at openjdk.java.net
> Subject: RFR: 7194254 jstack reports wrong thread priorities
> 
> This is a formal request for review for the patch contributed by Dymtro 
> Sheyko as discussed previously here:
> 
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-August/006376.html
> 
> I am one reviewer of course.
> 
> The webrev is here:
> 
> http://cr.openjdk.java.net/~dholmes/7194254/webrev.v1/
> 
> The fix has two components:
> 
> 1. It fixes a bug in os::get_priority that assumed a more positive 
> integer was always higher priority than a less positive one.
> 
> 2. It addresses the problem that os::get_priority is often inexact when 
> desiring the Java thread priority (because the mapping from Java 
> priority to OS priority is often M:1) by not using it in 
> Threads::print_on. Instead Threads::print_on will always report the 
> native OS priority, and JavaThread::print_on() will print the 
> java.lang.Thread.getId() value together with the 
> java.lang.Thread.getPriority() value.
> 
> This change in output affects all stackdumps including crash logs and 
> thread dumps (including those shown by jstack).
> 
> There is also a test program to check jstack output. I'll be doing some 
> additional validation while the RFR is in progress.
> 
> Thanks,
> David