From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30956 invoked by alias); 24 Feb 2016 03:23:18 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 30891 invoked by uid 89); 24 Feb 2016 03:23:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=onestop, one-stop, rob, occasionally X-HELO: mx4-phx2.redhat.com Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 24 Feb 2016 03:23:15 +0000 Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u1O3NE0m021546; Tue, 23 Feb 2016 22:23:14 -0500 Date: Wed, 24 Feb 2016 03:23:00 -0000 From: Andrew Hughes To: Roger Sayle Cc: Andrew Haley , java-patches@gcc.gnu.org Message-ID: <825380221.26466514.1456284193726.JavaMail.zimbra@redhat.com> In-Reply-To: References: <74FFBDDA-D906-470D-A7BA-559AAD71E76A@nextmovesoftware.com> <56CC2CB2.8020301@redhat.com> <991292478.26327859.1456249539216.JavaMail.zimbra@redhat.com> Subject: Re: [JAVA PATCH] Enable more array bounds check elimination MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q1/txt/msg00023.txt.bz2 ----- 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 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 * 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