From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117967 invoked by alias); 24 Feb 2016 09:53:37 -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 117933 invoked by uid 89); 24 Feb 2016 09:53:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2275, Following, justify, reckoned X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 24 Feb 2016 09:53:32 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id B7AA419D251; Wed, 24 Feb 2016 09:53:31 +0000 (UTC) Received: from zebedee.pink ([10.3.113.3]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1O9rUIw011902; Wed, 24 Feb 2016 04:53:30 -0500 Subject: Re: [JAVA PATCH] Enable more array bounds check elimination To: Roger Sayle , Andrew Hughes References: <74FFBDDA-D906-470D-A7BA-559AAD71E76A@nextmovesoftware.com> <56CC2CB2.8020301@redhat.com> <991292478.26327859.1456249539216.JavaMail.zimbra@redhat.com> From: Andrew Haley X-Enigmail-Draft-Status: N1110 Cc: java-patches@gcc.gnu.org Message-ID: <56CD7D99.1040703@redhat.com> Date: Wed, 24 Feb 2016 09:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q1/txt/msg00024.txt.bz2 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.