[JAVA PATCH] Enable more array bounds check elimination

[Andrew Hughes]

----- Original Message -----
> 
> Hi Andrew,
> 
> [Spooky, Graham Birtwistle was also my PhD examiner, and Rob Pooley a
> lecturer in the department at the time].
> 

Heh, have you been Googling me? :-)

> On 23 Feb 2016, at 18:45, Andrew Hughes <gnu.andrew@redhat.com> 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.

I wouldn't be too sure on this. Bytecode changes were introduced in 7 & 8,
notably invokedynamic. I'm not sure if gcj can handle this. Andrew Haley
would know more, as I believe he's been keeping it on life support these
last few years.

> 
> Is there any reason why gcj 7.x couldn't/doesn't use OpenJDK as its runtime
> library?

I don't think there's any particular technical reason, though one would have
to investigate further to know for sure. The idea was mused when OpenJDK first
appeared but no-one has doing the porting work in the last (nearly) nine years.

>From working on supporting CACAO+OpenJDK and JamVM+OpenJDK (also former Classpath
JVMs), it's not just a one-stop porting effort. Oracle regularly make changes
to what is still an undocumented interface between the JVM and the OpenJDK
class library, and we've had to do our best to mirror these changes in
CACAO and JamVM e.g. [0].

> 
> 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.

The difference is that then gcj had an active community of people working on it
and a strong need to do that in order to support 1.5. It wasn't just a case
of ecj being 'better'. The alternative would have been to implement support
for the 1.5 features, like generics and annotations, in the old gcj frontend.
Given there was already a FOSS implementation of this work, using ecj was
the quicker solution.

> 
> 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.

Actually, Classpath has had that since 2014:

    Add missing IOException constructors.
    
    2014-05-07  Andrew John Hughes  <gnu_andrew@member.fsf.org>
    
        * java/io/IOException.java:
        (IOException(String,Throwable)): Add missing constructor.
        (IOException(Throwable)): Likewise.


and a number of other changes beyond 1.5. Classpath is not holding back gcj
and has technically seen more development than gcj has recently. It will continue
to be used to bootstrap IcedTea.

gcj doesn't use Classpath directly, but rather instead maintains a fork which
has to be occasionally merged with upstream. This hasn't been done in over
three years: http://git.savannah.gnu.org/cgit/classpath.git/log/?ofs=50

> 
> 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.
> 

It is but it still needs someone to do it. This move also doesn't mean that
can't happen in the future. The code will still be available. It's not
going to disappear completely. But keeping it as part of GCC means it has
to be maintained and kept in sync with the rest of GCC, as well as being
built and tested. This all adds overhead for GCC developers who aren't
really interested in gcj. gcj also adds a significant size footprint
as it bundles pre-compiled class files for the entire class library.

FWIW, from my side, an OpenJDK-using gcj would defeat its usefulness for me,
as I use it to bootstrap OpenJDK/IcedTea. If gcj started requiring OpenJDK
to run, it would no longer help in this situation; effectively it would
introduce a circular dependency.

> 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
> --
> 
> 

I hope that helps clarify the issues involved,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222