From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110168 invoked by alias); 1 Jan 2018 03:42:19 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 110156 invoked by uid 89); 1 Jan 2018 03:42:18 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=winter, continued, niche, enabling X-HELO: mail-ot0-f194.google.com Received: from mail-ot0-f194.google.com (HELO mail-ot0-f194.google.com) (74.125.82.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 01 Jan 2018 03:42:17 +0000 Received: by mail-ot0-f194.google.com with SMTP id w4so11101406otg.3 for ; Sun, 31 Dec 2017 19:42:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iMwPnmJjphpmGIec2IrN+Z3ID4dSive/QMVHpj4B45c=; b=FTPz+TACzA7RUIOasKT3EQodFQpALdTJgiioV0a2nmZXwv+NnP9gJmtbxL1OIbbMbg 1zSy49V7Aog3X/I5kgV6xp+8PX5RYnidiUvTXNjQcwKGsfRfhJtOYSivNs1LjYZoE0B6 DpK9XUl/j1hr93bKNL8WbDBxfjaSueQOuJ4NAhsb3ecGuIVRfO+wtoNZDj9wUuRrnBxb txuOAsMF20tiszAhKy9LkZH2Hv/ynw/hYfJK7YlC8YVE384a8XwWhGyuBn0CAhe+g2lL NaOK3GKWi06uHUA9AJ//p2uR/jplAyQ9PjpGrV1LbV/NCg6nmTNbmv9AREAfAlLjy3Mm VzYw== X-Gm-Message-State: AKGB3mKdyEjPl3lnBloD5xspNYy32gOFB0oN4kZPbm5SnTTcfxUKfvwg UlvCIm0aNvnM/N/9R80IJG4xviXvETuzeODsP5PZEg== X-Google-Smtp-Source: ACJfBotFnMn6cM/UD4h+8zKFIxWRj+ub3SPndA+YEsomJLAUEQ2LfIOsl06AIs/9Wf0qM8q2iOPSi4pnabooVWPrkps= X-Received: by 10.157.12.182 with SMTP id b51mr34915104otb.161.1514778135349; Sun, 31 Dec 2017 19:42:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.20.176 with HTTP; Sun, 31 Dec 2017 19:42:14 -0800 (PST) In-Reply-To: References: From: Andrew Hughes Date: Mon, 01 Jan 2018 03:42:00 -0000 Message-ID: Subject: Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj To: R0b0t1 Cc: Yale Zhang , java Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00000.txt.bz2 On 27 December 2017 at 03:00, R0b0t1 wrote: > On Sun, Dec 24, 2017 at 10:58 PM, Yale Zhang wrote: >> Hurray, this list is still alive! >> >> Here's what I plan to do. If I don't hear from any maintainers in the >> next 2 weeks, I'll submit the MingW64 patch to the GCC Bugzilla. But >> not much hope there because I already submitted a few other bugs >> almost all still remain as "unconfirmed". So then I'll just post it on >> my Google personal site or maybe write something on instructables.com. >> Or maybe I already did enough by uploading to this list. >> > > This sounds okay, but instructables is very niche. I would recommend > putting your code on GitHub somehow. You can probably move faster than > 2 weeks to submit it to the tracker - this list is very inactive. I'll second the idea of GitHub. I'm pretty sure most of the people still "exist" - no-one died as far as I'm aware - but they have indeed moved onto other pastures and are unlikely to want to review patches. The reason GCJ was eventually deleted was because just keeping it buildable with the rest of GCC was becoming an unnecessary burden. It's probably worth noting that this isn't just any two weeks. For many countries, this is winter holiday season and, even when the project was heavily active, I doubt you'd have got a response on Christmas Eve / Christmas Day. > >> "Do your changes make it impossible to use the functionality you cut out?" >> >> Correct, I would not propose adding this to libjava as is. Most of the >> bloat can't be removed by the compiler because it might be used or >> even if it's never used, the compiler doesn't know any better. >> >> an example would be >> UI: >> >> System() >> { >> if (showVMConsole) >> { >> // show VM console GUI >> } >> } >> I haven't proven this but that's my guess how a simple hello world >> program drags Swing into the EXE. >> >> As you suspected, there could be unused dead code that the linker >> should remove. I haven't confirmed any cases. For dead code removal to >> happen, I think it's necessary to compile with -ffunction-sections and >> -fdata-sections and link with --gc-sections. I can check if they're on >> and if not, how much additional space is saved by enabling them. >> > > This is a question I think you should ask about on the general GCC > list, as it receives more traffic. At least one past GCJ maintainer > still comments. > > I think it is possible that libjava never sees optimization. I do not > know enough about the internals of GCC to know for certain, but I can > think of two reasons: > 1) As a separate library, it is not possible to do dead code removal > as it is not being compiled. > 2) GCJ always includes the entire library. > > If it is #2, I think it is due to reasons like you outlined - the > entire default classpath may be extremely interdependent. GCJ is still > fairly incomplete. > I don't know much about the GCJ internals either, but I am still (technically) the GNU Classpath maintainer, which is/was upstream of GCJ. There are quite a number of options already that allow the scope of the library to be limited. Are you making use of these? >> >> So, what changes did you want to make to GCJ? >> > > I was hoping to keep GCJ up to date to use it for OpenJDK > bootstrapping. It would keep the trusted codebase for FOSS systems > smaller than it currently is. > This is pretty much my continued interest in it, but I'm tending towards alternate solutions than trying to maintain GCJ. See: https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2813 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222