[RFC] Replace Java with Go in default languages

Matthias Klose doko@ubuntu.com
Mon Nov 11 21:28:00 GMT 2013


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



More information about the Gcc mailing list