From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55285 invoked by alias); 24 Feb 2016 01:11:44 -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 55270 invoked by uid 89); 24 Feb 2016 01:11:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=BAYES_05,RCVD_IN_SORBS_WEB,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=rob, hughes, Rob, lecturer X-HELO: server.nextmovesoftware.com Received: from server.nextmovesoftware.com (HELO server.nextmovesoftware.com) (162.254.253.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 24 Feb 2016 01:11:42 +0000 Received: from vpn11.hotsplots.net ([80.237.194.100]:54558 helo=[192.168.44.207]) by server.nextmovesoftware.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1aYNzP-0005Yu-BI; Tue, 23 Feb 2016 20:11:39 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [JAVA PATCH] Enable more array bounds check elimination From: Roger Sayle In-Reply-To: <991292478.26327859.1456249539216.JavaMail.zimbra@redhat.com> Date: Wed, 24 Feb 2016 01:11:00 -0000 Cc: Andrew Haley , java-patches@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <74FFBDDA-D906-470D-A7BA-559AAD71E76A@nextmovesoftware.com> <56CC2CB2.8020301@redhat.com> <991292478.26327859.1456249539216.JavaMail.zimbra@redhat.com> To: Andrew Hughes X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-SW-Source: 2016-q1/txt/msg00022.txt.bz2 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 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. >=20 > [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, trac= king 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=20 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-o= f-life the ahead of time compiler, specifically the translation to gimple front-en= d. 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 si= gnificantly 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 c= ited didn't capture the entirety of the discussion, and the distinct benefits/ov= erheads between gcj's runtime and the front-end itself were covered elsewhere. Thanks in advance, Roger --