Kris Kennaway wrote:
Hi,
I have been running the volano java benchmark
(http://www.volano.com/benchmarks.html) on an 8-core i386 system, and
out of the box jdk15 on FreeBSD performs extremely poorly. The system
is more than 90% idle, and profiling shows that the ~800 threads in the
benchmark are spending most of their time doing short nanosleep() calls.
I traced it to the following FreeBSD-specific hack in the jdk:
// XXXBSD: understand meaning and workaround related to yield
...
// XXXBSD: done differently in 1.3.1, take a look
int os::sleep(Thread* thread, jlong millis, bool interruptible) {
assert(thread == Thread::current(), "thread consistency check");
...
if (millis <= 0) {
// NOTE: workaround for bug 4338139
if (thread->is_Java_thread()) {
ThreadBlockInVM tbivm((JavaThread*) thread);
// BSDXXX: Only use pthread_yield here and below if the system thread
// scheduler gives time slices to lower priority threads when yielding.
#ifdef __FreeBSD__
os_sleep(MinSleepInterval, interruptible);
#else
pthread_yield();
#endif
When I removed this hack (i.e. revert to pthread_yield()) I got an
immediate 7-fold performance increase, which brings FreeBSD performance
on par with Solaris.
What is the reason why this code is necessary? Does FreeBSD's
sched_yield() really have different semantics to the other operating
systems, or was this a libkse bug that was being worked around?
Kris
Yeah, our sched_yield() really works well, in kernel, if the thread
scheduling policy is SCHED_OTHER (time-sharing), scheduler temporarily
lowers its priority to PRI_MAX_TIMESHARE, it is enough to give some CPU
time to other threads. Why doesn't the UNIX time-sharing work for java ?
Regards,
David Xu
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
