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: Matthias Klose <doko at ubuntu dot com>
- Cc: Jeff Law <law at redhat dot com>, 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: Tue, 12 Nov 2013 09:18:04 +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> <5280AC24 dot 4000002 at redhat dot com> <52814BCF dot 8080401 at ubuntu dot com>
On 11/11/2013 09:27 PM, Matthias Klose wrote:
> 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.
Well, yes, but we're talking about legacy systems: for legacy OpenJDK you
need legacy GCJ. There's no need for a new GCJ for porting new OpenJDK.
Andrew.