pthread impl detection
pthread impl detection
- Subject: pthread impl detection
- From: Paolo Molaro <email@hidden>
- Date: Mon, 20 Dec 2004 16:26:24 +0100
- Mail-followup-to: email@hidden
Hi.
In order to speedup access to thread local variables in
the code generated by the mono JIT, I'd like to inline
the code sequence directly instead of calling pthread_getspecific ().
Of course I know this is risky, since the implementation could change,
so I wrote some code to detect what pthread_getspecific()
actually does: if the code doesn't do what is expected we
fallback to the call to pthread_getspecific().
The interesting thing is that when I read the instructions
of the pthread_getspecific implementation (ie the __pthread_getspecific
code setup by the kernel), they are mostly 0, just
the first instruction is a nop.
Dump of assembler code for function pthread_getspecific:
0x90001de0 <pthread_getspecific+0>: li r4,72
0x90001de4 <pthread_getspecific+4>: ba 0xffff82c0 <__pthread_getspecific>
Dump of assembler code for function __pthread_getspecific:
0xffff82c0 <__pthread_getspecific+0>: nop
0xffff82c4 <__pthread_getspecific+4>: .long 0x0
0xffff82c8 <__pthread_getspecific+8>: .long 0x0
0xffff82cc <__pthread_getspecific+12>: .long 0x0
[...]
It's a surprise that the cpu can execute the code even if it
appears as nop/zeroes when read. I tried to mprotect the
relevant page, but that returns permission denied: it shouldn't
be read-protected though, or I'd get a SEGV reading it.
Anyway, for informational purpouses it would be interesting to know
why reading the memory area returns odd results.
Forcing the code to use the spr register 259 (as should be on the G5
machine) works and gives the expected speedup.
On the practical side: anyone has suggestions on how to reliably detect
which code sequence to use? Depending just on the processor type is
more fragile than actually checking what the code does and we'd have
to use the slower function call on Mac OSX...
Thanks.
lupus
--
-----------------------------------------------------------------
email@hidden debian/rules
email@hidden Monkeys do it better
_______________________________________________
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