Re: Relating dtrace thread ids to Java threads
Re: Relating dtrace thread ids to Java threads
- Subject: Re: Relating dtrace thread ids to Java threads
- From: Terry Lambert <email@hidden>
- Date: Fri, 28 Aug 2009 21:01:43 -0700
On Aug 28, 2009, at 4:17 PM, Paul Johnson wrote:
Hello, i've been trying to timestamp when context switches occur in
the kernel using this dtrace script: http://lists.apple.com/archives/perfoptimization-dev/2007/Dec/msg00011.html
. dtrace is used to gather the context switch information and
probes in the Java program is used to gather the rest of the
information.
The problem i'm having is that the thread id returned by curthread
in the dtrace script is different from the result returned by the
pthread_self() call that I make in a JNI method. The documentation
says that curthread and tid are the same as that returned
pthread_self() however I suspect that is a holdover from the solaris
docs.
The pthread_self() thread id is the address of a user space thread
state structure. The dtrace information, if it is coming from a
kernel probe, will be the address of a kernel space Mach structure.
It's not like we pass addresses from kernel space to user space, and
then trust user space to pass a valid address in the kernel and then
blindly go there and start loading kernel state. So they are not the
same thing.
Where does curthread come from and is there a way to get it using a
method in userspace?
You can use Mach calls in user space to get the kernel space thread
information. Or if you are willing to cast to a local structure
definition and have the user space code be non-portable, you can
dereference the th_thport out of the thread state structure for the
user space thread.
is there a different way to relate the data? should I just try
Solaris?
I'm aware that this will probably be non-portable and likely to
break if the kernel is changed.
Looks like a winner... see also the Libc sources for the Mac OS X
release you are running.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden