Massive performance loss from OS::sleep hack
Arno J. Klaassen
arno at heho.snv.jussieu.fr
Tue Sep 25 12:25:17 PDT 2007
Hello,
Kurt Miller <kurt at 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
More information about the freebsd-java
mailing list