From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60943 invoked by alias); 27 Dec 2017 03:00:49 -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 60795 invoked by uid 89); 27 Dec 2017 03:00:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_40,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=hosting, H*f:sk:CALQF7Z, R0b0t1, H*f:CAAD4mYiQ5Rs X-HELO: mail-yw0-f176.google.com Received: from mail-yw0-f176.google.com (HELO mail-yw0-f176.google.com) (209.85.161.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 27 Dec 2017 03:00:38 +0000 Received: by mail-yw0-f176.google.com with SMTP id l23so6138240ywb.13 for ; Tue, 26 Dec 2017 19:00:30 -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=3a1S8LxWsqeV/ATn8h6xWyLJS4KJkOCnjx2LPksrpF4=; b=ALFslFR988LghisduJFKg/np3BiJu3/KbcXnf7S2WSQZsD1hvIA0vpqU+Qbiqj3wj4 Pn2jh2pbH/p7jscW7ywqVP9p++QmN7jZiGOS5fRGg54IAKgSg8dZ5CMnem7Zh1Eals1t etooP9OSh1QfmcPG52zH1PkKehAmf5HybZDAoxr+/Q+tKtNdVI5XAJxcYgiMdYZd84H9 P+AKL8ekTMQ5S055oKOKDspBg8jecDYM6VDixjaL6l3qlw+F6EERv9bQvAjlxnLRZ7ss /pVsYoDifftXcWJKHEWsWwaj0U/CDVrldZ8E6SMBcS48kKgmWgzJkx3gq3J39NLk+Q7o nSXQ== X-Gm-Message-State: AKGB3mJ3pbCrQ9vfx3jvS14ZgMP2cMFmkDDGFPsUWzxj6UEBSSNtzwux ++sC/nZTTaFRl18ExiZq33u3tDf5DPlmsUk5CLY= X-Google-Smtp-Source: ACJfBosqXpTHGSuULap4YC2PdVhMR+6+PxdRxIgn60jZmsjEzgVGQILvGP7xIdxdHSAMx5G8goXMf97yifa9fXlNstA= X-Received: by 10.129.2.84 with SMTP id 81mr11544979ywc.415.1514343628508; Tue, 26 Dec 2017 19:00:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.157.2 with HTTP; Tue, 26 Dec 2017 19:00:27 -0800 (PST) In-Reply-To: References: From: R0b0t1 Date: Wed, 27 Dec 2017 03:00:00 -0000 Message-ID: Subject: Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj To: Yale Zhang Cc: java@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00004.txt.bz2 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. > "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. > > 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. > > On Sun, Dec 24, 2017 at 7:33 PM, R0b0t1 wrote: >> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang wrote: >>> Greetings. I have a patch that allows GNU java to target MingW64 >>> (host=GNU/Linux only). Are you guys still taking patches now that Java >>> has been removed from GCC 7? Or would it be more appropriate to host >>> it on my own website or instructables.com? >>> >> >> My questions in a similar vein led to the suggestion to use the last >> version that supported GCJ. Development on this version has stopped. >> >> On the other hand, I am interested in your work, and know of at least >> a few people who would be; hosting it publicly would be a good idea. >> If GCC could accept the patches I suspect it would be beneficial, but >> the people to review your contributions may no longer exist. >> >>> I also have another patch that cuts all the GUI, cryptography, and non >>> UTF8/16 charset support from libgcj. This reduces the size of >>> statically linked EXEs a lot (~27MiB to 4.5 MiB for a hello world >>> program). This is important for a legacy utility that other developers >>> use on Windows and who don't want to install a Java runtime. >>> >>> Commenting out and deleting code is a crude way to do, I know. Should >>> use conditional compilation and even explore what's causing GUI code >>> to be dragged into a hello world program. Maybe dead code removal >>> isn't working (need to compile with -ffunction-sections and >>> --gc-sections?) >>> >> >> Do your changes make it impossible to use the functionality you cut >> out? It is not really my place to say, but to me, that would be >> unsuitable for inclusion in GCC proper. >> >> I shouldn't guess, but it seems to me like the default classpath may >> just be copied into the executable. Optimization passes may not be run >> on it. >> >> Cheers, >> R0b0t1