On 14/02/18 02:56, Christian Thalinger wrote:
>> On Feb 9, 2018, at 6:08 AM, Andrew Dinn <ad...@redhat.com> wrote:
>> I'd second that view. Also, C1 is more valuable than it appears e.g. it
>> is still very valuable as a companion to Graal when the latter replaces
>> C2 via JVMCI.
>
> …or don’t do C2 or C1 at all and just do Graal and use AOT :-)
>
> Everything else is a waste of time, in my very biased opinion.
This is a bit of a diversion from the original topic but it is relevant
and also a relevant subject to discuss on discuss list so here goes ...
First, let me state that I don't want to suggest that we don't pursue
Graal because that is the exact opposite of what I believe. I think
Graal is a critical tool for pursuing a lot of very interesting and
highly important goals for the JVM. However, I think the current code
base is going to need to mature for a lot longer (and, hence, require a
lot more developer input) before it will be in any way capable of
replacing C2 as the production compiler of choice.
That's not primarily a question of making it generate comparably
performant code in present or near-present circumstances (yes, Chris,
that means you :-p so don't start quoting x86 benchmark figures at me
and claiming the job is nearly done). It's also about ensuring that
Graal is capable of continuing to deliver high quality code in the face
of currently unmet and/or future requirements.
What do I mean by that? Well, I found some troubling issues with the
code base when trying to get Graal to generate decent quality AArch64
code. I would classify the problem as significant technical debt
accumulated on the way to making x86 work well (which, indeed, it does).
I suspect similar problems are going to bite a RISC-V port of Graal
(especially as regards weak vs TSO memory model). I also worry they the
same technical debt may make reliable implementation of new JVM features
more difficult than it ought to be.
C2, by contrast, is a well known implementation with well-known merits
and flaws (yeah, it's old, people have kicked the tires). So, we know
what we can and can't do with it and, in particular, how it will cater
for upcoming JVM changes.
The biggest flaw that gets cited (especially by Chris :-) is: it is so
hard to learn C2 hat only a very few people know how it works. Having
actually fixed some reasonable sized and reasonably complex things in
both Graal and C2, I'm not personally convinced that Graal is any
different in that regard.
What I find more pertinent: having been pointed at the relevant
literature some while back by John (and Kim?) -- Principles of Program
Analysis by Nielson, Nielson and Hankin -- I am of the opinion that C2
actually has a much firmer theoretical footing than I have been able to
spot in Graal. Also, I believe C2's use of the infamous sea of nodes and
its type lattice implementation means that the code sits more cleanly
and clearly within that theoretical framework than Graal does in
whatever formal model it is based on. It looks like it relies on the
same sort of theory but it's hard for me to tell how well it matches it,
given the complexity and verbosity of the Graal class base.
I know Graal has things that are 'sort-of' equivalent -- e.g. for the C2
type lattice we have Graal stamps. However, the former is clean and
complete (albeit with known failure points) whereas the Graal version
makes a real hash of reference types and then mostly ignores them,
instead relying on location types to distinguish different memory
slices. C2 cleanly and /clearly/ implements the type lattice model in
the code base and employs on it, as far as possible, to retain maximal
type info. I am not at all sure that Graal stamps live up to the
requirements for iterative graph transforms to be valid.
Oh and while we are here I'll note that location types seem to have been
shoe-horned in in a horribly messy way. Method getLocationType is
overloaded (on about 20 or so different types of access node -- yes
really) via 3 (or more?) different interfaces. However, the method also
exists in, and is called direct from, classes which don't implement any
of those interfaces. This method is used to signal the memory slice
operated on by an access, Unfortunately, it is also overloaded on
membars to return a value that poisons all memory slices. That dual
contract makes implementing a single node to model both an access
combined with a memory barrier an impossibility. That is a disaster for
an architecture like AArch64 which wants to model an instruction that
can be generated as an ldar or stlr.
Similarly, in place of the sea of nodes we have a plethora of fixed
nodes for the control flow graph and floating nodes for stuff that is
not pinned to control flow. That looks like a nice simplification but
one of the problems I came across (match rules not matching) was
precisely because this 'simplification' forced false control
dependencies onto a match set containing pure dataflow dependencies,
thus poisoning a lot of perfectly valid matches. Essentially the check
for the match reduction serialized the floating graph and fixed graph
into an arbitrarily chosen full order and then found a 'fake'
intervening side-effect because some incidental node ended up between
two of the matched nodes. In order to fix this I had to give up on using
match rules and instead introduce yet another transform phase.
No such false dependency occurs in the C2 graph. So, its match rules can
happily reduce equivalent cases. Sea of nodes control graphs may indeed
be harder to follow than the fixed node tree but that's because they
model the dependencies more cleanly. It might be possible to upgrade
Graal's matcher so it can distinguish real and fake dependencies but
that will require work -- n.b. work that is not needed when you have a
single, simple, uniform and complete representation for dependencies.
I realise most of the above detail is much more relevant to the Graal
list than to this list. However, the point is not really to air these
problems but to make it clear that issues of this significance exist and
that they point at a larger problem: maturity takes time and experience,
as do the reliability and awareness of what will and won't work that
come with it. Much as I consider Graal to be a great, ongoing experiment
I think C2 is going to be indispensable for quite some time.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
