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

Hi Andrew,

[Spooky, Graham Birtwistle was also my PhD examiner, and Rob Pooley a
lecturer in the department at the time].

On 23 Feb 2016, at 18:45, Andrew Hughes <[email protected]> wrote:
> Yes, I believe we agreed to regard it as deprecated in 6 and remove it
> during the lifetime of 7 [0]. As such, this patch probably needs to
> go to the 6 branch too if it's ever going to see the light of day.
> 
> [0] https://gcc.gnu.org/ml/java-patches/2015-q3/msg00041.html

Thanks for this very useful pointer.

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?

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.

To me obsoleting GNU classpath, which is holding gcj back to Java 1.5 [for
example no java.io.IOException(String,Throwable) constructor] is independent
of the potential performance benefits of a gcj compiled tomcat, eclipse or
LibreOffice.

Perhaps, I'm missing something or under-estimating the complexity of porting
the bits of OpenJDK that aren't written in Java, but I'd imagine this is significantly
simpler than attempting to update the current libjava to 1.8 and beyond.

Again apologies for being late to the discussion,  Perhaps the thread you cited
didn't capture the entirety of the discussion, and the distinct benefits/overheads
between gcj's runtime and the front-end itself were covered elsewhere.

Thanks in advance,

Roger
--