From: R0b0t1 <r030t1@gmail.com>
To: Yale Zhang <yzhang1985@gmail.com>
Cc: java@gcc.gnu.org
Subject: Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj
Date: Wed, 27 Dec 2017 03:00:00 -0000 [thread overview]
Message-ID: <CAAD4mYiV7i7FQMxV8rK_LaeRSzg_uDezfFzbYTp4_0VFR=3JLQ@mail.gmail.com> (raw)
In-Reply-To: <CALQF7ZzPPS6X2aHGFTcN1tmWX37Zu2MHEd5gqbt+0CPt2bFPYw@mail.gmail.com>
On Sun, Dec 24, 2017 at 10:58 PM, Yale Zhang <yzhang1985@gmail.com> 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 <r030t1@gmail.com> wrote:
>> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <yzhang1985@gmail.com> 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
next prev parent reply other threads:[~2017-12-27 3:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-24 19:44 Yale Zhang
2017-12-25 0:33 ` R0b0t1
2017-12-25 4:58 ` Yale Zhang
2017-12-27 3:00 ` R0b0t1 [this message]
2018-01-01 3:42 ` Andrew Hughes
2018-01-01 9:00 ` Andrew Haley
2018-01-01 10:38 ` Brian Jones
2018-01-01 21:03 ` Yale Zhang
2018-01-02 9:58 ` Andrew Haley
2018-01-02 10:00 ` Andrew Haley
2018-01-02 10:04 ` Ricardo Wurmus
2017-12-24 19:46 Yale Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAD4mYiV7i7FQMxV8rK_LaeRSzg_uDezfFzbYTp4_0VFR=3JLQ@mail.gmail.com' \
--to=r030t1@gmail.com \
--cc=java@gcc.gnu.org \
--cc=yzhang1985@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).