Gerrit Huizenga wrote:
> Which affects JVM in most cases. NPTL based JVMs will possibly
> obviate that problem. My guess is that in the JVM case, they have
> a bad locking model (er, a simpler 2-tier locking model instead of
> a more correct and complex 3-tier locking model) for their threading
> operations. As a result, they use either sched_yield() or used
> to use pause() to relinquish the processor so the world could change
> and they could acquire the locks they wanted.
The JVM's extensive use of sched_yield(), plus the HT scheduler causes
some pretty undesirable behaviour in SPECjbb(tm) (see disclaimer). It
starves some pieces of the benchmark so badly, that the benchmark
results are invalid. We also start to get tons of idle time as the load
goes up.
In case anybody is curious, we're trying to share more of the data that
we collect when we run the benchmarks. Most of it us useless, but
someone might find a gem or two. Here are two runs, one with HT, and
the other without. There's also a pretty busy gnuplot graph in there:
http://www.sr71.net/prof/jbb/elm3a2/
The benchmark results can be found in:
<run-name>/benchmark/SPECjbb.*
Disclaimer:
SPEC (tm) and the benchmark name SPECjbb (tm) are registered trademarks
of the Standard Performance Evaluation Corporation. The benchmarking was
conducted for research purposes only and were non-compliant with the
following deviations from the rules:
1. It was run on hardware that does not meet the SPEC
availability-to-the public criteria. The machine was an
engineering sample.
--
Dave Hansen
[email protected]
On Wed, Apr 30, 2003 at 10:40:22PM -0700, Dave Hansen wrote:
> Gerrit Huizenga wrote:
> > Which affects JVM in most cases. NPTL based JVMs will possibly
> > obviate that problem. My guess is that in the JVM case, they have
> > a bad locking model (er, a simpler 2-tier locking model instead of
> > a more correct and complex 3-tier locking model) for their threading
> > operations. As a result, they use either sched_yield() or used
> > to use pause() to relinquish the processor so the world could change
> > and they could acquire the locks they wanted.
>
> The JVM's extensive use of sched_yield(), plus the HT scheduler causes
> some pretty undesirable behaviour in SPECjbb(tm) (see disclaimer). It
> starves some pieces of the benchmark so badly, that the benchmark
> results are invalid. We also start to get tons of idle time as the load
> goes up.
Have the Blackdown folks fix that. The Solaris Threads implementation
suppresses the actual call to a yield in the HotSpot VM if it gets too
many of them bunched together in short period of time. It's really a problem
not with the JVM itself, but the Linux implementaion of their threading
glue logic... Make'm fix it. :)
I've heard that a number of folks in Blackdown want to try out the new
threading model, so this might be a good opportunity to do that... add
special thread suspension support, etc...
:)
bill