Re: performance problems

[Jeff Sturm <jsturm@sigma6.com>]

Tom Tromey wrote:
> 
> >>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:
> 
> Jeff> I compiled the benchmark code with -O3, I think...  I also
> Jeff> hacked the GC initialization code to bump the initial heap up to
> Jeff> 16MB.  I should probably send a patch for it.  Does anyone
> Jeff> object to an environment variable, something like GCJ_HEAP_INIT,
> Jeff> to set the initial heap size?
> 
> I'm not too thrilled with the idea of an environment variable.

For embedded targets I can understand... not every OS supports
environment variables.

> Shouldn't this be set on a per-application basis?

Maybe.  We tend to tweak heap parameters in the field.  Specifically for
the JDK, we often adjust -ms and -mx on production sites.  Gcj doesn't
have a maximum heap, so it's not as important.  Initial heap size is
still a big win for memory-intensive programs with short run durations.

If there were a supported API call for it I could live with that... even
in C++.  We couldn't add anything in Java code without breaking
compatibility.

> Two ideas:
> 
> 1. Change the default in the Boehm GC on a per-target basis.
>    For native builds we could make it larger.
>
> 2. Add a new --heap-size option to gcj and build in the number
>    at link time.  Change the GC interface (such as it is) in libgcj
>    to support setting this at initialization time.

A configurable parameter seems like a good idea.

I have no idea how to implement 2...

> Jeff> Any other thread trying to enter the monitor is going to
> Jeff> busy-loop at least until the I/O completes, potentially a very
> Jeff> long time.
> 
> This seems like a problem in LinuxThreads.  Busy-waiting is bad, and
> there's no rule that says you should only hold a mutex for a short
> period of time.

I suppose so.  I've learned the hard way though that long-term
synchronized blocks are a very bad idea.  Java synchronization is very
primitive, and there is no documented technique to query monitor status
when troubleshooting, nor any way to test lock status at runtime or
interrupt a waiting thread.  Higher-level mechanisms based on
wait/notify don't necessarily have any of these shortcomings.

OTOH busy-waits are a big win over system calls if the duration is
short.  The spinlocks aren't really a problem for well-designed code, so
I'm less motivated to fix LinuxThreads than to fix my Java code.

-- 
Jeff Sturm
jsturm@sigma6.com