Thanks David! /Staffan
On 1 feb 2013, at 06:05, David Holmes <david.hol...@oracle.com> wrote: > Hi Staffan, > > First, please refrain from doing code cleanup (long line reformatting) > alongside a fairly significant change - it makes the true changes harder to > spot. Thanks. > > Based on our discussions this all looks good to me. > > Thanks, > David > > On 18/01/2013 5:48 AM, Staffan Larsen wrote: >> This is a request for review of a fix for SA on OS X. >> >> webrev: http://cr.openjdk.java.net/~sla/8006423/webrev.00/ >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006423 >> >> The bug report contains a detailed description of the problem and the >> proposed solution. I have copied some of that text below. To verify the fix >> I have manually run jstack on OS X. >> >> Thanks, >> /Staffan >> >> >> >> In many cases when running the SA version of JStack (or other SA tools) an >> NPE is thrown in BsdThread.getContext(). The underlaying cause is that SA >> fails to read the context of the thread in the native method >> getThreadIntegerRegisterSet0() (thread_get_state returns an error). >> >> The following is my understanding of what the cause is and a suggestion for >> a fix - my experience with OS X is a bit limited so I may be off on some >> details. >> >> thread_get_state() takes a thread_t as a parameter. The value of this >> parameter comes from SA reading the value of the OSThread._thread_id field >> in the Hotspot process being debugged. This value is set in HotSpot to >> ::mach_thread_self() which is documented as "The mach_thread_self system >> call returns the calling thread's thread port." >> >> My theory is that this "thread port" in not valid when a different process >> calls thread_get_state(). Instead, the other process (SA in this case) needs >> it's own "thread port" for the thread it wants to access. >> >> There is a way to list all the thread ports in a different process (or >> "task" as they are called in Mach) via the task_threads() function. >> >> So now we have the thread ports, we just need to correlate them with the C++ >> Thread objects in the Hotspot process. One way to do this correlation is via >> the stack pointer. We can get the current value of the stack pointer (rsp) >> in SA and look through all the Thread objects to see which one the stack >> pointer belongs to (by looking at Thread._stack_base and Thread._stack_size). >> >> Another way seems to be to use the thread_info() function with the >> THREAD_IDENTIFIER_INFO parameter. This gives us a struct which has a field >> called thread_id. The comment for this field in the thread_info.h file says >> "system-wide unique 64-bit thread id". The value for this thread_id is the >> same when called from Hotspot and when called from the debugging process >> (SA), so this looks like a way to do the correlation. >> >> This requires Hotspot to store this value in OSThread and SA to first list >> all the "thread ports", then find the thread_id for each one and select the >> right "thread port" for the thread we are looking for. >> >> Using a thread_id provided by the system seems more reliable than using the >> stack pointer for correlation. >> >>
