Drop GCJ AOT bits for F11?

[Andrew Overholt]

Hi,

Back when we wrote the initial Java packaging guidelines, we said that
packagers *should* include GCJ AOT bits.  Should we remove this
requirement for Fedora 11 and beyond?

Also, GCJ is still in the base install set for Fedora.  Should we remove
this and make OpenJDK a default?

Andrew

[Andrew Haley]

Andrew Overholt wrote:

>  Back when we wrote the initial Java packaging guidelines, we said
> that
>  packagers *should* include GCJ AOT bits.  Should we remove this
>  requirement for Fedora 11 and beyond?
>  
>  Also, GCJ is still in the base install set for Fedora.  Should we remove
>  this and make OpenJDK a default? 
This is a bit premature.  We still don't have the OpenJDK JIT for PPC and
ARM arches.  We're working hard on it but it's not ready yet for prime-time.
Without the JIT, OpenJDK is crushingly slow on these arches.

Having said that, there's no reason not to make OpenJDK the default on the
arches where it performs well: x86 and 8x6_64 at the monent.

Andrew.

[Andrew Overholt]

* Andrew Haley <aph(a)redhat.com&gt; [2008-11-20 11:33]:
>  Andrew Overholt wrote:
>  
>  > Back when we wrote the initial Java packaging guidelines, we said that
>  > packagers *should* include GCJ AOT bits.  Should we remove this
>  > requirement for Fedora 11 and beyond?
>  > 
>  > [...]
>  
>  This is a bit premature.  We still don't have the OpenJDK JIT for PPC and
>  ARM arches.  We're working hard on it but it's not ready yet for prime-time.
>  Without the JIT, OpenJDK is crushingly slow on these arches. 
Should Smolt stats on architecture users affect this decision?  It says
about 0.7% of users are on platforms without OpenJDK JITs.

http://smolts.org/static/stats/stats.html

Andrew

[Andrew Haley]

Andrew Overholt wrote:
>  * Andrew Haley <aph(a)redhat.com&gt; [2008-11-20 11:33]:
> > Andrew Overholt wrote:
> >
> >> Back when we wrote the initial Java packaging guidelines, we said that
> >> packagers *should* include GCJ AOT bits.  Should we remove this
> >> requirement for Fedora 11 and beyond?
> >>
> >> Also, GCJ is still in the base install set for Fedora.  Should we remove
> >> this and make OpenJDK a default?
> >
> > This is a bit premature.  We still don't have the OpenJDK JIT for PPC and
> > ARM arches.  We're working hard on it but it's not ready yet for prime-time.
> > Without the JIT, OpenJDK is crushingly slow on these arches.
>  
>  Should Smolt stats on architecture users affect this decision?  It says
>  about 0.7% of users are on platforms without OpenJDK JITs.
>  
>  http://smolts.org/static/stats/stats.html 
I was hoping to be able to keep all arches going with gcj until a
really first-rate OpenJDK solution was available everywhere.  I don't
think we want to make the useers of these arches into second- class
citizens: Fedora ARM, in particular, is great for mobile devices and
hasn't been supported for very long.  I think its usage will increase.

Sure, the number of users is low, but on lower-performance boxes the
penalty of not having gcj and gcj-compiled packages available is quite
severe.  I wouldn't object to weakening the "should" to a "may"
where
aot-compiling is a problem.  Even without precompiled applications,
gcj is still a lot faster than the OpenJDK C++ interpreter.

Andrew.

[Conrad Meyer]

On Thursday 20 November 2008 09:00:50 am Andrew Haley wrote:
>  Andrew Overholt wrote:
>  > * Andrew Haley <aph(a)redhat.com&gt; [2008-11-20 11:33]:
>  >> Andrew Overholt wrote:
>  >>> Back when we wrote the initial Java packaging guidelines, we said that
>  >>> packagers *should* include GCJ AOT bits.  Should we remove this
>  >>> requirement for Fedora 11 and beyond?
>  >>>
>  >>> Also, GCJ is still in the base install set for Fedora.  Should we
>  >>> remove this and make OpenJDK a default?
>  >>
>  >> This is a bit premature.  We still don't have the OpenJDK JIT for PPC
>  >> and ARM arches.  We're working hard on it but it's not ready yet for
>  >> prime-time. Without the JIT, OpenJDK is crushingly slow on these arches.
>  >
>  > Should Smolt stats on architecture users affect this decision?  It says
>  > about 0.7% of users are on platforms without OpenJDK JITs.
>  >
>  > http://smolts.org/static/stats/stats.html
>
>  I was hoping to be able to keep all arches going with gcj until a
>  really first-rate OpenJDK solution was available everywhere.  I don't
>  think we want to make the useers of these arches into second- class
>  citizens: Fedora ARM, in particular, is great for mobile devices and
>  hasn't been supported for very long.  I think its usage will increase.
>
>  Sure, the number of users is low, but on lower-performance boxes the
>  penalty of not having gcj and gcj-compiled packages available is quite
>  severe.  I wouldn't object to weakening the "should" to a "may"
> where
>  aot-compiling is a problem.  Even without precompiled applications,
>  gcj is still a lot faster than the OpenJDK C++ interpreter.
>
>  Andrew. 
I'm also for keeping gcj (for now). OpenJDK is great where it JITs but it's 
miserable on PPC (e.g. my laptop). I think the guidelines could say something 
about "if you run into a problem with a non trivial fix compiling gcj AOT 
bits, it's ok to drop the aot bits".

Regards,
-- 
Conrad Meyer <konrad(a)tylerc.org&gt;

[Andrew Overholt]

* Andrew Haley <aph(a)redhat.com&gt; [2008-11-20 12:00]:
>  I was hoping to be able to keep all arches going with gcj until a
>  really first-rate OpenJDK solution was available everywhere. 
Do we anticipate this happening before the F11 freeze?  When I asked
this question it wasn't meant as a "let's do it today!" kind of thing
but more a "we need to seriously think about this for F11 now that F10
is basically out the door" :) .

>  Sure, the number of users is low, but on lower-performance boxes the
>  penalty of not having gcj and gcj-compiled packages available is quite
>  severe. 
Do we have numbers on this?  I know you are correct but having hard
numbers would be nice.

Andrew

[Mark Wielaard]

On Thu, 2008-11-20 at 14:49 -0500, Andrew Overholt wrote:
>  * Andrew Haley <aph(a)redhat.com&gt; [2008-11-20 12:00]:
>  > Sure, the number of users is low, but on lower-performance boxes the
>  > penalty of not having gcj and gcj-compiled packages available is quite
>  > severe.
>  
>  Do we have numbers on this?  I know you are correct but having hard
>  numbers would be nice. 
I only have anecdotal evidence (I did these experiments a long time
ago). Running eclipse fully interpreted, through for example jamvm
(sadly not packaged for Fedora yet), is on the order of 4 to 8 times as
slow as running eclipse interpreted with gij and aot-compiled core class
libraries. And the jamvm interpreter is faster than the standard
interpreter that comes with hotspot.

Comparing gij on a pure-bytecode program versus a the same compiled aot
with gcj doesn't directly give you the correct (hard) numbers though.
Since gij will at least use the aot compiled core-library (so at least
things like your String operations and HashMaps, etc are optimized).

I believe Andrew Hughes (CCed) has a zero-on-x86 install. So he might be
able to give a real number of how much slower zero-interpreted against
full hotspot and/or a fully gcj native compiled program is.

Cheers,

Mark