Re: The problems with StringBuilders...

[Radu Racaru <radu dot racaru at gmail dot com>]

On 10/6/05, Adam Megacz <megacz@gcc.gnu.org> wrote:
>
>
> David Daney <ddaney@avtrex.com> 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.
>
That's my opinion also, for me and the apps I build close world is
always the case, and that is the main motivation to work with gcj and
static compiling. As we are now with BC ABI I think that its useful
for many applications and makes things easier to work with, but for me
and I think others, there's no motivation to go that route as for
instance I always compile from source and right now BC does nothing
for me in this case.

I know that having 2 models can be a pain to maintain, but there are
some pragmatic reasons to have a strong static compiler in the mix.

JET in their latest version took best of both worlds and now they have
an official Sun tested version with a sophisticated AOT compiler and a
good JIT, thats how they managed to license and pass the test for JVM
conformance.

Escape analysis can be implemented first only for the easiest cases,
as it's by definition an optimization developers must be aware of so
that they can tune their code at the semantic level.

Should be nice to have the developer resources at GCJ end to
experiment with different optimizations but as I understand
compatibility is the no. 1 goal so we'll have to stick to what we have
now.

Anyhow I like the progress GCJ is making and hope for more juicy stuff
to come in later :)

Radu

>   - a
>