Re: [RFC] Replace Java with Go in default languages

[Richard Biener <richard dot guenther at gmail dot com>]

On Mon, Nov 11, 2013 at 10:27 PM, Matthias Klose <doko@ubuntu.com> 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.  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).

At least we don't need a Java source code frontend, no?  Just keeping
the bytecode compiler and GIJ should be enough?  That way we can
strip the classpath copy of everything that isn't needed, thus not
provide a Java library.  Reduces testing coverage of GCJ to almost
zero, but ...

Richard.

>   Matthias
>