public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Yale Zhang <yzhang1985@gmail.com>, Brian Jones <cbjones1@gmail.com>
Cc: java@gcc.gnu.org
Subject: Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj
Date: Tue, 02 Jan 2018 09:58:00 -0000	[thread overview]
Message-ID: <6a6ed9c1-bd53-3106-b257-a68c7d5e0351@redhat.com> (raw)
In-Reply-To: <CALQF7ZxNf=FON4AH4v5nw+V+yEP7JpOTToejt3ABVUhRx7usNA@mail.gmail.com>

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	other threads:[~2018-01-02  9:58 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
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 [this message]
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=6a6ed9c1-bd53-3106-b257-a68c7d5e0351@redhat.com \
    --to=aph@redhat.com \
    --cc=cbjones1@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).