Project proposal: RISC-V port

Wed Feb 14 14:27:15 UTC 2018

We welcome anybody who helps mature the code base. Different compilers have different strengths. Our focus is on improving performance of modern JVM workloads with Graal (like the one from Twitter). One can have long discussions whether this aspect or that aspect is “cleaner” or has the better “theoretical foundation”. Ultimately, the performance results are the objective measure that counts and what we care about most. 

We do have plans to improve the type system (in particular around reference types). We have however not seen scenarios where this would make a large difference for the given workload and therefore prioritised other optimisations. Compiler optimisations like loop transformations, code duplications, and inlining can help simplify the scenarios the compiler has to reason about and create additional performance opportunities without requiring a more complex type system.

As mentioned, we are working on a Graal version that has the potential to replace both C1 and C2. It is however clearly at the discretion of the OpenJDK community if/when they will pick up any of these versions in the OpenJDK source base and build. Meanwhile, we are providing our own Graal-based builds for anybody who wants to test them. We are also happy to assist any experiments with Graal.

Regards, thomas

> On 14 Feb 2018, at 14:05, Andrew Dinn <adinn at redhat.com> wrote:
> 
> On 14/02/18 02:56, Christian Thalinger wrote:
>>> On Feb 9, 2018, at 6:08 AM, Andrew Dinn <adinn at 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