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: Matthias Klose <doko at ubuntu dot com>
- To: Andrew Haley <aph at redhat dot com>, 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 22:27:43 +0100
- 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> <5280AC24 dot 4000002 at redhat dot com>
Am 11.11.2013 11:06, schrieb Andrew Haley:
> 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.
that's only partly true. Sure, when using an unreleased OpenJDK snapshot
(leading to OpenJDK 8), then you are probably correct, however doing that for a
released version of OpenJDK, it is still needed. At least for me, getting a GCJ
working for AArch64, and then using it to build the OpenJDK Zero port on AArch64
did go well. And not only that, GCJ is still working on architectures where the
OpenJDK Zero port stops working now, like mips, mipsel, s390, and where the
upstream Hotspot isn't working anymore (sparc, sparc64).
Matthias