Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
>
> Andrew Overholt wrote:
>
> > * Kevin Kofler <kevin.kofler@xxxxxxxxx> [2009-01-29 15:10]:
> >> Unfortunately, OpenJDK's JIT is actually faster than GCJ's native
> >> code.
> >> :-(
> >
> > Why is this unfortunate?
>
> Because it means GCJ sucks at generating native code.
Well, I suppose this depends on whether your glass is half empty or
half full. In the main I'm pleased with gcj's performance: the fact
that it's in the same ball park as the HotSpot server JIT in many
cases makes me very pleased indeed. HotSpot is a tremendous piece of
software, custom written for Java and very highly tuned. gcj's
performance is no shame at all.
I'm not saying that gcj couldn't be improved, of course. We should be
doing more to eliminate array bounds checks, for example, and we could
in principle do escape analysis to remove locks and convert heap
allocation to stack allocation. Also, we don't inline as much as
perhaps we could.
> In principle, native code should be more efficient because you don't
> have to go and recompile that bytecode all the time.
This is a popular naive view, but it isn't true. A JIT has many
advantages over a static compiler for langauges like Java. For
example, invoke{virtual,interface} can first be compiled
optimistically, on the assumption that it will always be executed with
the same target class; only if that turns out to be untrue will the
call be deoptimized to full virtual dispatch. Also, things like
vtable and field offsets and static field addresses can be hard-coded
by a JIT because the target classes are fully resolved by the time the
JIT is invoked. Finally, a JIT has easy access to profile data to
choose what to optimize and inline.
> That a JIT manages to do better than GCJ's native code is a sad
> state of affairs. I wish we had a decent AOT compiler for Java so we
> can get rid of the slow bytecode once and for all. As it is now,
> Java code is a lot slower than compiled code, and GCJ only makes it
> worse instead of better.
Well, everyone is entitled to an opinion, I suppose. I don't think
there is any justification for this one.
Andrew.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
