The problems with StringBuilders...

Adam Megacz
Thu Oct 6 06:58:00 GMT 2005

David Daney <> writes:
> This is a problem with the GCJ approach.  We have this nice binary
> compatibility feature, but you have to disallow a wide range of
> optimizations in order to use it.  The JIT compilers (like Sun's
> HotSpot) can do these things because they know everything at
> run/compile time (as runtime and compile time are the same thing).

> There are a class of applications where throwing binary compatability
> away to achieve better optimization makes a lot of sense (think
> embedded systems).

Yep, this goal was exactly what drew me to the GCJ project in the
first place and motivated me to get libgcj working on Win32.  I'm glad
the project is moving forward, but it's been heading in a direction
that isn't super useful to me, which is why I've been pretty scarce
around here lately.

IMHO, right now GCJ is trying to compete with the JITs on "their
turf".  JITs will always have an easier time with binary compatability
-- by which I mean the ratio of developer effort to performance for
any fixed set of binary-compatability criterion will be higher.

But CPU-intensive, closed-world optimization is where GCJ has the
upper hand: JITs can't spend >1hr optimizing code, nor do then know
when the optimal moment to make the closed-world assumption is.

  - a

More information about the Java mailing list