Re: [JAVA PATCH] Enable more array bounds check elimination

On 24/02/16 01:11, Roger Sayle wrote:
> 
> Following the thread above, there seems to be an unclear lack of
> distinction between different aspects and roles of GCJ, that I hope
> you can clear up.
> 
> I completely agree that maintaining libjava/classpath has been a
> pain, tracking a continual moving target of a huge API, and now
> obsolete thanks to OpenJDK and IcedTea.  But what I'm interested in
> is the Free Software Foundation's ahead-of-time compiler for
> transforming Java bytecodes/class files to binary executables,
> i.e. jc1.
> 
> My understanding is that the JVM bytecode instruction set has been
> relatively stable over the ages, and that "gcj" compiles the
> contents of most modern class files without problems, it's only the
> run-time library support that hasn't kept pace with the times.
> 
> Is there any reason why gcj 7.x couldn't/doesn't use OpenJDK as its
> runtime library?

Yes.  It's important to realize that, while bytecodes are added very
infrequently, new entry points to the virtual machine are added
frequently.  Some of these are simply optimizations, but many are
needed for correct operation.  GCJ has never supported any of the
entry points required by the OpenJDK class library.

> When a better open source front-end came along (ecj), gcj switched
> to using that to reduce the overhead of tracking syntax changes to
> the Java language.  Now that a better run-time library exists,
> reducing the overhead of tracking library API changes, it seems odd
> not to switch to it, but to instead end-of-life the ahead of time
> compiler, specifically the translation to gimple front-end.

It's a lot of work, and the work gets greater with every day that
passes.  A couple of years ago I guesstimated the work that would be
involved, and I reckoned it would be at least six months, and that's
six months for me.  Nobody could do it any faster.  Now it's much
longer, more than a year.  I would love to reactivate GCJ with a
modern class library, but I can't figure out any way to justify the
time.

The other point is that it would be unsatisfying.  OpenJDK's
optimizers do many optimizations which can't be done with any
ahead-of-time compiler, so GCJ would always fall behind.

Andrew.