Date: 25 Sep 2007 20:54:45 +0200 From: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr> To: Kurt Miller <kurt@intricatesoftware.com> Cc: Daniel Eischen <deischen@freebsd.org>, davidxu@freebsd.org, freebsd-java@freebsd.org Subject: Re: Massive performance loss from OS::sleep hack Message-ID: <wpps061sp6.fsf@heho.snv.jussieu.fr> In-Reply-To: <200709182213.00777.kurt@intricatesoftware.com> References: <46EC1B55.4060202@FreeBSD.org> <200709180721.48995.kurt@intricatesoftware.com> <46F0243A.8020902@FreeBSD.org> <200709182213.00777.kurt@intricatesoftware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Kurt Miller <kurt@intricatesoftware.com> writes: > On Tuesday 18 September 2007 03:17:14 pm Kris Kennaway wrote: > > 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. > > > > > > For 7.0 and up default UseThreadPriorities to true and always > > > use pthread_yield(). For < 7.0 default UseThreadPriorities to > > > false and conditionally use pthread_yield()/os_sleep(). User's > > > can toggle UseThreadPriorities with the command line argument > > > -XX:+UseThreadPriorities > > > > Do we know that 6.x requires the old behaviour? Maybe it can default to > > on there too. Otherwise this looks good to my eyeball (but the > > DEFAULT_LD_LIBRARY_PATH change looks unrelated) > > > > -#define DEFAULT_LD_LIBRARY_PATH "/usr/lib" /* See ld.so.1(1) */ > > +#define DEFAULT_LD_LIBRARY_PATH "/usr/lib:/usr/local/lib" /* See > > ld.so.1(1) > > Yea I messed up the DEFAULT_LD_LIBRARY_PATH part. I didn't intend > to change that segment of the existing os_bsd.cpp patch. > > Regarding 6.x it either needs UseThreadPriorities defaulted to false > or the os_sleep hack. After discussing the options with Daniel we > agree that defaulting UseThreadPriorities to false and eliminating > the os_sleep hack for all versions is the most consitant approach. I use libthr with jdk15 on 6.x for at least a year and notice the following after this change : - on i386-UP systems my programs continue to work properly when using libthr - on a 4-way amd64-SMP system it very easily stucks java ( top(1) giving it in 'umtx'-state and 265% or so CPU). switching back to standard libpthread makes the program working as before. - this is reproducable for me by using libthr for javac as well : just compile a bunch of java files and javac hangs Is this due to a difference in libthr between 6.x and -current or some subtility in thread yielding between UP and SMP systems? I didn't tes yet with '-XX:+UseThreadPriorities' but can do so if you judge it useful. Regards, Arno
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wpps061sp6.fsf>