On 2/11/2015 5:41 PM, Per Liden wrote:
Hi David,
On 2015-11-02 07:40, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8132510
Open webrev: http://cr.openjdk.java.net/~dholmes/8132510/webrev.v2/
A simple (in principle) but wide-ranging change which should appeal to
our Code Deletion Engineer's. We implement Thread::current() using a
compiler/language-based thread-local variable eg:
static __thread Thread *_thr_current;
inline Thread* Thread::current() {
return _thr_current;
}
Do we expect the cost of calling Thread::current() to go down with this
change or will it remain about the same?
Depends on the platform and the exact circumstances, given the varied
caching and other "fast lookup" schemes previously employed (even though
this is slow-path code). I do not expect it to be slower in general but
we will be somewhat at the mercy of the particular platform
implementation. The earlier Solaris change showed mildly positive
results. I'll be starting some performance runs tomorrow.
Btw, this looks like a really nice cleanup/simplification!
Thanks,
David
cheers,
/Per
with an appropriate setter of course. By doing this we can completely
remove the platform-specific ThreadLocalStorage implementations, and the
associated os::thread_local_storage* calls, plus all the uses of
ThreadLocalStorage::thread() and ThreadLocalStorage::get_thread_slow().
This extends the previous work done on Solaris to implement
ThreadLocalStorage::thread() using compiler-based thread-locals.
We can also consolidate nearly all the os_cpu versions of
MacroAssembler::get_thread on x86 into one cpu specific one ( a special
variant is still needed for 32-bit Windows).
As a result of this change we have further potential cleanups:
- all the src/os/<os>/vm/thread_<os>.inline.hpp files are now completely
empty and could also be removed
- the MINIMIZE_RAM_USAGE define (which avoids use of the linux sp-map
"cache" on 32-bit) now has no affect and so could be completely removed
from the build system
I plan to do the MINIMIZE_RAM_USAGE removal as a follow up CR, but could
add the removal of the "inline" files to this CR if people think it
worth removing them.
I have one missing piece on Aarch64 - I need to change
MacroAssembler::get_thread to simply call Thread::current() as on other
platforms, but I don't know how to write that. I would appreciate it if
someone could give me the right code for that.
I would also appreciate comments/testing by the AIX and PPC64 folk as
well.
A concern about memory-leaks had previously been raised, but experiments
using simple C code on linux 86 and Solaris showed no issues. Also note
that Aarch64 already uses this kind of thread-local.
Thanks,
David
