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

[Jeff Law <law at redhat dot com>]

On 11/11/13 14:48, Matthias Klose wrote:
> > The last news item related to Java was 2009 and scanning the ChangeLog doesn't
> > show significant project activity (~14 changes in 2013, most of which look like
> > routine maintenance in the language front-end.   There's even fewer changes
> > occurring in the runtime system.
>
> GCJ still plays this role for OpenJDK 6 and OpenJDK 7.
I thought OpenJDK was in a state where it no longer needed GCJ -- can 
you explain precisely how GCJ is still used here?
> These times include the time to build the libjava dependencies, boehm-gc, libffi
> and zlib.  At least these should be measured separately. boehm-gc is used too
> when configured with --enable-objc-gc. libffi (?) and zlib are used when
> building Go, so these times will be re-added when building the Go frontend.
No need to re-add, the times for anything Go depended on are accounted 
for.  However, we're now looking at replacing Java with Ada for various 
reasons.

> > Clearly switching from libjava to go would be a significant improvement in the
> > bootstrap and regression test cycle.  On the box I tested we'd see roughly at
> > 15% improvement and we'd still get testing of -fnon-call-exceptions.
>
> assuming that you did these tests on amd64, it helps to build the default
> libjava multilib variant only.  In the past I did propose to do that by default.
> Back then people did think this wasn't necessary when cutting the build time in
> half by disabling the static libjava build by default.
>
> the libjava build itself does parallelize well except for building libgcj-tools,
> so a bit of speed-up could be gained there too.
Yes, the libjava build is embarrasingly not parallel.  I don't see that 
anyone is likely to try and tackle that problem.


> the libjava tests currently don't run parallelized, however from my expericence
> these tests are not the longest running ones.  Again, maybe don't count the
> times for the boehm-gc and libffi tests.
The testsuite is a relatively small component -- if you read my message 
closely you'd see that testing libjava is roughly requivalent to testing 
go (front-end + runtime) and according to Eric testing libjava is 
roughly equivalent to testing Ada.

Reducing the build time and focusing on front-ends with a higher impact 
is really the issue we're trying to resolve.

I'll note we're not talking about removing java from GCC, just removing 
it from the set of things that have to be built & tested for each 
checkin.  One could even consider another alternative -- 
building/testing java optional during stage1, required during stage3.

Jeff