This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Replace Java with Go in default languages
- From: Andrew Haley <aph at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Alec Teal <a dot teal at warwick dot ac dot uk>, Eric Botcazou <ebotcazou at adacore dot com>, Ian Lance Taylor <iant at google dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 11 Nov 2013 10:06:28 +0000
- Subject: Re: [RFC] Replace Java with Go in default languages
- Authentication-results: sourceware.org; auth=none
- References: <527D63DB dot 3090801 at redhat dot com> <CAKOQZ8yw7gXgu+ndC+PKnPE_7_OcULv4LOC0u88-fA2QJUZA9A at mail dot gmail dot com> <1711331 dot F5Of0QNJ0b at polaris> <527E5852 dot 2080900 at warwick dot ac dot uk> <527E5AE4 dot 1020208 at redhat dot com> <52804D6E dot 8040807 at redhat dot com>
On 11/11/2013 03:22 AM, Jeff Law wrote:
> On 11/09/13 08:55, Andrew Haley wrote:
>> On 11/09/2013 03:44 PM, Alec Teal wrote:
>>> If Java must go, and it must have a replacement Ada makes sense. The
>>> issues with Go (sadly, you guys are doing superb work) do make sense.
>>>
>>> I don't know enough about Java (the GCC front end and such) to know if
>>> it should go, if it does go why should it be replaced?
>>
>> It always was very useful for detecting bugs in GCC: the code flow tends
>> to trigger bugs that don't get detected by the usual GCC testsuites.
> That's certaily been the case in the past, but I'm seeing less and less
> of that now. If we can get coverage of the non-call-exceptions paths
> and cut 15% off the build/test cycle, then I think it's worth it.
>
> I'd even be willing to explicitly make this a trial and reinstate GCJ if
> we find that GCJ is catching problems not caught by the existing default
> language & runtime systems.
>
> Andrew -- my big question is what's the state of OpenJDK for other
> architectures. The most obvious being ARM(64), but in general, what's
> the process for bootstrapping OpenJDK on a new target
It's no different from porting GCC/libc. You have to write an
assembler back end, the native parts of the runtime library, a
bytecode interpreter, relocs for the runtime linker, and the compiler
back end. Call it two programmer-years to get something decent
working.
> and is GCJ an integral part of that process.
We have used GCJ in the past when porting OpenJDK because OpenJDK
wasn't cross-compilable, but that's fixed now: we can cross-compile
from a host which already has OpenJDK. So we don't need GCJ for that.
Andrew.