|Kris Kennaway||Sep 15, 2007 10:49 am|
|Kris Kennaway||Sep 15, 2007 12:08 pm|
|Daniel Eischen||Sep 15, 2007 3:37 pm|
|Daniel Eischen||Sep 15, 2007 9:47 pm|
|Kip Macy||Sep 15, 2007 10:52 pm|
|Kris Kennaway||Sep 16, 2007 3:16 am|
|Daniel Eischen||Sep 16, 2007 8:45 am|
|Kurt Miller||Sep 16, 2007 9:06 am|
|Kurt Miller||Sep 16, 2007 9:06 am|
|Kip Macy||Sep 16, 2007 12:56 pm|
|Alfred Perlstein||Sep 16, 2007 6:16 pm|
|Kurt Miller||Sep 16, 2007 6:47 pm|
|David Xu||Sep 16, 2007 7:33 pm|
|Kurt Miller||Sep 18, 2007 4:21 am|
|Daniel Eischen||Sep 18, 2007 5:29 am|
|Kurt Miller||Sep 18, 2007 7:15 am|
|Daniel Eischen||Sep 18, 2007 10:08 am|
|Kurt Miller||Sep 18, 2007 10:28 am|
|Daniel Eischen||Sep 18, 2007 11:00 am|
|Kris Kennaway||Sep 18, 2007 12:16 pm|
|Kurt Miller||Sep 18, 2007 7:12 pm|
|Kris Kennaway||Sep 19, 2007 3:16 am|
|Subject:||Massive performance loss from OS::sleep hack|
|From:||Kurt Miller (ku...@intricatesoftware.com)|
|Date:||Sep 18, 2007 7:15:53 am|
Daniel Eischen wrote:
On Tue, 18 Sep 2007, Kurt Miller wrote:
David Xu confirmed for me that pthread_yield() does give some time to lower priority threads on 7.0 using thr. Attached and inline are two patches for the 1.5 port that is how I suggest the issue be addressed.
I don't think you should rely on pthread_yield() doing that, it is dependent on the scheduler, and if you are running in SCHED_FIFO/SCHED_RR, it won't work with libthr either. Currently, you can only run in SCHED_FIFO or SCHED_RR as root using libthr, but that hopefully won't always be true.
Shoot I forgot to mention a few things in my last email... The c test program I resurrected from 18 months ago had
in it. The jdk doesn't set the schedpolicy it uses the default one. That line was left over from my testing different policies under kse to see if I could work- around the problem. Since the jdk doesn't set the policy, I believe we don't need to be concerned with SCHED_FIFO and SCHED_RR.
I think the way that will always work is to lower the priority and raise it back again after the yield, when using thread priorities. This should work for libthr, libc_r, and libkse under all versions of the OS.
On the surface this sounded promising, but I can envision at least one case where temporarily lowering a thread priority will not work very well. Take three threads A, B & C each with different priorities: A highest, C lowest. Let's say A is in a busy loop calling Thread.Yield(). B is in a busy loop also calling Thread.Yield(). C is doing something that needs some time slices every so often. A calls Thread.Yield(), lowers priority to C's level, B gets some time next, it calls Thread.Yield(), lowers priority to C's level. A, B, C are all at equal level now. Perhaps C will get some time first, or B, or A. Suppose the order is C first, B next. A will only get a time slice if B continues to call yield and by chance the system schedules A before B. The behavior becomes non-deterministic. The worst case is A is starved.
Also to make matters a bit more complicated there are non-java threads to contend with too. There could be some non-java locking involved as well. It would require an investment of someone else's time to work all the potential issues out.
As for knobs, it would be nice to be able to turn off the default lowering and raising of priorities for Thread.yield() even when using thread priorities. Most likely, the only applications that relies on that behavior are the TCK tests themselves. I certainly wouldn't expect Thread.yield() to allow a lower priority thread to run.
Considering Sun's reluctance to correct the TCK test, I would venture a guess that there are applications out there that rely on Thread.Yield() to give time to lower priority threads (in-spite of the significant amount of Java books, white papers, certification tests, etc that say not to do that).
Are you allowed to supply knobs when running the TCK tests? Or does the JVM have to do the right thing by default?
The JVM gets certified on the default threading library for the standard options. Generally the non-standard options (-Xfoo) are not certified. Attempting to certify the JVM for multiple threading libraries, os versions, architectures, and options would be cost prohibitive.
I believe what I've suggested provides a solution to the performance issue (at the expense of supporting thread priorities on < 7.0), while not introducing unexpected or non-certifiable behavior.
Motivated people on this list should file bug reports w/Sun against the Thread.Yield() API. It is about time Sun clarify the expected behavior of of Thread.Yield() with respect to thread priorities.
At a minimum the current description of Thread.Yield() is in conflict with JSR-133: JavaTM Memory Model and Thread Specification, Section 12: "The Java specification does not guarantee preemptive multithreading or any kind of fairness guarantee. There is no hard guarantee that any thread will surrender the CPU and allow other threads to be scheduled." Not to mention the 10 years of non-official publications that say not to rely on Thread.Yield() to do anything portable at all.