Kip Macy wrote: > Yes, if we could hack the jvm to work around this without calling > sleep that would be better yet. However, making java work well is more > important than keeping the interface clean.
One possible alternative is to not honor thread priorities in the jdk by default. In hotspot/src/os/linux/vm/os_linux.cpp I see this comment: // Note: LinuxThreads only honor thread priority for real time threads. // sched_priority is ignored if policy is SCHED_OTHER. This function is // equivalent to a "noop" on current Linux platforms. OSReturn os::set_native_priority(Thread* thread, int newpri) { which leads me to believe linux doesn't honor thread priorities in the jdk. Perhaps someone could verify that on a linux box. If linux and/or windows doesn't actually honor thread priorities I don't see why we need to. IIRC, there weren't any specific JCK tests that validated a higher priority thread actually got more time then a lower one (I could be wrong on that since there was > 30k tests in the jck). So we could default UseThreadPriorities to false and make the os_sleep() call only be used when UseThreadPriorities is true (i.e. the user explicitly sets -XX:+UseThreadPriorities). Can someone check out linux to see if it indeed supports or ignores thread priorities for java programs? -Kurt _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]"