From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 7A10C3858D32 for ; Thu, 1 Dec 2022 11:50:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A10C3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.96,209,1665475200"; d="scan'208";a="91371019" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 01 Dec 2022 03:50:34 -0800 IronPort-SDR: 0XIYR+PgD4uoA6pF+tuiH8nHu9VU7jYvzHXrPm41XYzV1syj+CvkQaYNIAVmWOd4ffmcmZbT0j VklsfiQ/FNCFqASXFSKFe/J5pniqwuVBLhCBebZjv75KXakTaBMsvYhkhZk2q8skDsTCgTsW2Z i6KD0ZArLoFLk7a14qkgXX48PT/OsyA4AH0oYW/ft2ELzJfUtxttCMFPtRFPCoOsJFZzu3ic1E dzdONPC9IIqJxuDJtI9MUNXTRFhEVzkWBZHy7vHTVF4ahDKptmihQUE44tDPwBSyF3uWYPiXtr T+4= From: Thomas Schwinge To: CC: , Joseph Myers Subject: Re: Java front-end and library patches. In-Reply-To: References: <87be1195-fee5-7355-ddd-ddceedcce0a6@codesourcery.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Thu, 1 Dec 2022 12:50:25 +0100 Message-ID: <87y1rrjqbi.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On 2022-11-30T23:18:06+1100, Zopolis0 via Gcc-patches wrote: > However, patches 14-19 do need an explanation, as proven by multiple > reviews simply asking why I had made them. I'll send follow up > messages to those. Well, (at least for some of them) re-work rather than explanations. ;-) Anyway: >> Why is it now considered useful to add this front end back? > > The way I see it, the Java front end was removed due to a lack of > maintenance and improvement. To put it simply, I am going to maintain > and improve it. That is the difference between now and then. There is > more nuance, but that is the gist of it. Ha, nice! As it happens, a few months ago, I started the same task... (... but with very low priority, so have not yet gotten very far...) >> How has the series been validated? > > I'm not exactly sure what you mean by this. Testing; the integrated GCC/Java test suites, as well as possibly any external test suites. To make sure that we're (a) not regressing anything in non-Java GCC, and (b) that we're maintaining the functionality level of the "old" GCC/Java. That said, I found that the integrated GCC/Java test suites are not exactly testing all that should be tested... My approach has been to establish an "old" baseline, and then gradually rebase this onto specific GCC master branch commits, and catch up with tree-wide changes along the way. I've not gotten all too far yet; made a stop to first add more testing to the baseline, so that I can be reasonably sure that GCC/Java doesn't regress in functionality. (It's been sitting in that state for a number of months now...) It may be a somewhat more painful approach in comparison to the "all in one go" approach that you seem to have attempted (?), but it seemed more appropriate for me, as I'm only able to spend occasional small blocks of time on this. >> Would you propose to maintain the front end and libraries in future? > > I have big plans for the library, and plan to maintain that long into > the future. In regards to the actual front-end code, I will do what I > can to make sure it remains at its previous level of function, but > that is about it. I dislike working with the front end code, so I will > fix it, but I will not make sweeping changes to it. I might thus be interested in joining that effort (I'm more interested in the front end and GCC proper parts) -- but, again, this will be low-priority project for me. Gr=C3=BC=C3=9Fe Thomas > Just a brief overview of my plans for the frontend and library-- When > GCJ was first introduced it was "the free Java implementation". It was > trying to offer a bytecode compiler, a machine code compiler and a > runtime library. Clearly, this was too much, as it borrowed another > bytecode compiler and runtime library, and even then the runtime > library fell into dissaray. > > Now, we have many pieces of the puzzle. We have a bounty of free Java > bytecode compilers, and a free runtime library. The only thing missing > is a free machine code compiler, which GCJ was and is. I plan to > replace Classpath with the OpenJDK, and double down on the machine > code aspect of GCJ, dropping bytecode and interpreted support. ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955