add support for x86_64-w64-mingw32 and cut the fat from libgcj

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

add support for x86_64-w64-mingw32 and cut the fat from libgcj

Yale Zhang
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?

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?)

appreciate your feedback,
-Yale
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

R0b0t1
On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Yale Zhang
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.

"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.


So, what changes did you want to make to GCJ?


On Sun, Dec 24, 2017 at 7:33 PM, R0b0t1 <[hidden email]> wrote:

> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

R0b0t1
On Sun, Dec 24, 2017 at 10:58 PM, Yale Zhang <[hidden email]> 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 <[hidden email]> wrote:
>> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Andrew Hughes
On 27 December 2017 at 03:00, R0b0t1 <[hidden email]> wrote:

> On Sun, Dec 24, 2017 at 10:58 PM, Yale Zhang <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Andrew Haley
In reply to this post by R0b0t1
On 25/12/17 00:33, R0b0t1 wrote:

> On Sun, Dec 24, 2017 at 1:44 PM, Yale Zhang <[hidden email]> 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.
>

We exist, but it's hard for me to understand exactly what you may have
in mind.  At some point all of the GCC branches which support GCJ will
be finished, so this isn't a long-term possibility.  I don't even know
if there are any open GCC branches with GCJ support.  Having said that,
I'm quite happy to accept mingw patches if there is a live branch to
apply them to.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Brian Jones-17
In reply to this post by Yale Zhang
I believe the idea of including only code which you specify is required came up before on the list many years ago.  Hopefully a search through archives can be instructive.

Brian

> On Dec 24, 2017, at 2:44 PM, Yale Zhang <[hidden email]> 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?
>
> 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?)
>
> appreciate your feedback,
> -Yale
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Yale Zhang
Alright, I've submitted my request & patch to bugzilla:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647

"Having said that, I'm quite happy to accept mingw patches if there is a
live branch to apply them to."
Under the target version, I saw a tentative 6.4.1, so there still could be
hope this can make it into GCC 6.


I also did the experiment of compiling libgcj with -ffunction-sections
-fdata-sections and then use --gc-sections when linking to see if that
helps remove dead code. Somehow, that instead increased the size of a
simple test program (with multithreading & sockets) from 4.54 to 4.72 MiB.

"I was hoping to keep GCJ up to date to use it for OpenJDK bootstrapping"
That paranoid? Why not use the minimal Eclipse Java compiler which
Classpath uses for bootstrapping? It sounds like ECJ can't be trusted if it
was compiled with an untrusted/unknown compiler.




On Mon, Jan 1, 2018 at 5:38 AM, Brian Jones <[hidden email]> wrote:

> I believe the idea of including only code which you specify is required
> came up before on the list many years ago.  Hopefully a search through
> archives can be instructive.
>
> Brian
>
> > On Dec 24, 2017, at 2:44 PM, Yale Zhang <[hidden email]> 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?
> >
> > 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?)
> >
> > appreciate your feedback,
> > -Yale
>
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Ricardo Wurmus

Yale Zhang <[hidden email]> writes:

> "I was hoping to keep GCJ up to date to use it for OpenJDK bootstrapping"
> That paranoid? Why not use the minimal Eclipse Java compiler which
> Classpath uses for bootstrapping? It sounds like ECJ can't be trusted if it
> was compiled with an untrusted/unknown compiler.

ECJ is a binary blob, and you need some pre-compiled Classpath binaries.

For GNU Guix we bootstrap the JDK with Jikes, SableVM, various versions
of GNU Classpath, and an older version of ECJ built from source.  The
details can be found here:

    http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/java.scm#n68

GCJ was no good bootstap compiler as it included a pre-built copy of
Classpath.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Andrew Haley
In reply to this post by Yale Zhang
On 01/01/18 21:03, Yale Zhang wrote:

> Alright, I've submitted my request & patch to bugzilla:
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647
>
> "Having said that, I'm quite happy to accept mingw patches if there is a
> live branch to apply them to."
> Under the target version, I saw a tentative 6.4.1, so there still could be
> hope this can make it into GCC 6.
>
>
> I also did the experiment of compiling libgcj with -ffunction-sections
> -fdata-sections and then use --gc-sections when linking to see if that
> helps remove dead code. Somehow, that instead increased the size of a
> simple test program (with multithreading & sockets) from 4.54 to 4.72 MiB.

I'm not surprised.  All Java code is reachable from everywhere because
of reflection and class loaders.  You can't simply use --gc-sections
because code called reflectively would fail at runtime.

> "I was hoping to keep GCJ up to date to use it for OpenJDK bootstrapping"
> That paranoid? Why not use the minimal Eclipse Java compiler which
> Classpath uses for bootstrapping? It sounds like ECJ can't be trusted if it
> was compiled with an untrusted/unknown compiler.

Indeed.  If Programming Language X is written in X, you're going to
need the previous version of X to build it.  It's so for C and for
Java.  We have a string of versions of OpenJDK going back to Version
6, and that was compiled with GCJ.  So, there's nothing to stop
someone from digging out OpenJDK 6, building that with an old GCJ, and
spooling forward to today.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj

Andrew Haley
In reply to this post by Yale Zhang
On 01/01/18 21:03, Yale Zhang wrote:
> Alright, I've submitted my request & patch to bugzilla:
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647

I see it was rejected.  We could create a GCJ 6 branch.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671