Re: Project proposal: RISC-V port

[Thomas Wuerthinger]

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

Re: Project proposal: RISC-V port

[Thomas Wuerthinger]

We are working on a Graal configuration that can be competitive with C1 in 
terms of compilation times. Graal’s design is actually much closer to C1 than 
C2. Significant parts including backend and register allocation originate 
directly from a port of C1 sources from C++ to Java (e.g., 
https://github.com/beehive-lab/Maxine-VM/commit/75e69aeccaf9960c7e842de40e41f8b518273e7d).

- thomas


> On 9 Feb 2018, at 15:08, Andrew Dinn  wrote:
> 
> On 09/02/18 10:57, Edward Nevill wrote:
> 
>> I agree with the overall approach you outline below. You will
>> probably end up doing C1 anyway. The s390 port tried to do it without
>> doing C1 and they ended up doing C1.
> 
> 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.

Re: Project proposal: RISC-V port

[Palmer Dabbelt]

This is really great, thanks!  I'd be happy to have you be the RISC-V OpenJDK 
project lead.  I'm interested in contributing, at least where possible.


On Tue, 06 Mar 2018 12:01:40 PST (-0800), edward.nev...@gmail.com wrote:

Hi,

I have created a JDK issue to add RISC-V support to Zero.

https://bugs.openjdk.java.net/browse/JDK-8199138

I have a sample patch which is included in the JDK issue to add RISC-V support 
and this is currently under test (it is running under qemu so it may be some 
time!).

Once we have got Zero support in OpenJDK we can look at setting up a project to add 
C1 & C2 support (or even graal!).

I am happy to act as project lead for the RISC-V port at least in the interim. 
I am an OpenJDK committer, a member of the porters group and the aarch32 
project lead. Although I do not have very much RISC-V experience (IE. about 1 
week) I feel I could help get the project started until someone with more 
RISCV-V experience is up to speed with the OpenJDK processes.

Anyone who is interested in contributing to this project needs to have signed 
the OCA (Oracle Contributor Agreement), or work for a company that has signed 
the OCA.

http://www.oracle.com/technetwork/community/oca-486395.html

If you would be interested in contributing to this project please let me know.

All the best,
Ed.

On Thu, 2018-02-08 at 08:38 -0800, Palmer Dabbelt wrote:

[Sorry for the second email, it appears my SiFive email doesn't want to
subscribe to porters-dev.]

RISC-V is an open standard ISA stewarded by the RISC-V foundation
.  With the recent release of glibc 2.27 we now have the full
RISC-V software base released from the various upstream repositories, which
means it's time to start moving forward with the rest of the software stack.  I
ran into Erik at FOSDEM a few days ago and he suggested that we open up the
discussion of an OpenJDK port for RISC-V.  While I'm not familiar with the
RISC-V Java efforts, I did part of a Hotspot port (a bit of the template
interpreter and much of C2) to Tilera's TilePro and TileGx architectures a few
years ago so I know a bit about the OpenJDK internals.

In the RISC-V community we view Java as a very important missing component of
the software ecosystem, so I was thrilled when Erik found me at FOSDMEM and
suggested there was community interest in a port.  Unfortunately, I won't have
time to properly help out with the port (I'm maintaining Linux, as well as
co-maintaining binutils, GCC, and glibc).  That said, I'd be very happy to help
out where I can.  I think a good way to move forward might be to:

* Create a project to own the RISC-V port, which is what this email is about.
  I'm OK being the project lead, at least until we find someone who will have
* Clean up our libffi port and submit it upstream.  Stefan O'Rear is in the
  process of submitting the port now, so it should all be moving smoothly soon.
  Submit patches for our Zero port.  While I didn't do the port I don't mind
  cleaning it up and submitting it.  I've added Martin who was more involved
  with the original port.  I think he's not working on RISC-V stuff now that
  he's at Google, though.
* Move forward with a proper OpenJDK port, starting with the template
  interpreter and eventually adding C2.  I'm not sure if C1 is actually
  deprecated, but we decided not to bother with it at Tilera because it didn't
  seem worth the extra effort at the time.  Of course, this would be up to
  whomever is actually doing the work :).

There appears to be considerable community interest in a RISC-V OpenJDK port,
so my hope is that while I don't have time to directly contribute much myself
that we'll be able to get something sane up and running.  Interested users can
test on QEMU, and we've recently announced a board (and associated beta program
that provide free boards to open source developers) so there's some hardware to
run on as well.

I'd like to request that the Porters Group sponsors this project with me as the
lead.

Thanks!

Re: Project proposal: RISC-V port

[Andrew Dinn]

On 06/03/18 20:01, Edward Nevill wrote:
> I am happy to act as project lead for the RISC-V port at least in the
> interim. I am an OpenJDK committer, a member of the porters group and
> the aarch32 project lead. Although I do not have very much RISC-V
> experience (IE. about 1 week) I feel I could help get the project
> started until someone with more RISCV-V experience is up to speed
> with the OpenJDK processes.

I don't believe I am entitled to vote for Ed to be granted this role but
I will offer the opinion that he would make a great project lead -- even
if he has to rely on someone else for detailed RISC-V knowledge. His
help on the AArch64 port was immensely valuable and his experience of
how that port was done should be very helpful.

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

Re: Project proposal: RISC-V port

[Edward Nevill]

Hi,

I have created a JDK issue to add RISC-V support to Zero.

https://bugs.openjdk.java.net/browse/JDK-8199138

I have a sample patch which is included in the JDK issue to add RISC-V support 
and this is currently under test (it is running under qemu so it may be some 
time!).

Once we have got Zero support in OpenJDK we can look at setting up a project to 
add C1 & C2 support (or even graal!).

I am happy to act as project lead for the RISC-V port at least in the interim. 
I am an OpenJDK committer, a member of the porters group and the aarch32 
project lead. Although I do not have very much RISC-V experience (IE. about 1 
week) I feel I could help get the project started until someone with more 
RISCV-V experience is up to speed with the OpenJDK processes.

Anyone who is interested in contributing to this project needs to have signed 
the OCA (Oracle Contributor Agreement), or work for a company that has signed 
the OCA.

http://www.oracle.com/technetwork/community/oca-486395.html

If you would be interested in contributing to this project please let me know.

All the best,
Ed.

On Thu, 2018-02-08 at 08:38 -0800, Palmer Dabbelt wrote:
> [Sorry for the second email, it appears my SiFive email doesn't want to 
> subscribe to porters-dev.]
> 
> RISC-V is an open standard ISA stewarded by the RISC-V foundation 
> .  With the recent release of glibc 2.27 we now have the 
> full 
> RISC-V software base released from the various upstream repositories, which 
> means it's time to start moving forward with the rest of the software stack.  
> I 
> ran into Erik at FOSDEM a few days ago and he suggested that we open up the 
> discussion of an OpenJDK port for RISC-V.  While I'm not familiar with the 
> RISC-V Java efforts, I did part of a Hotspot port (a bit of the template 
> interpreter and much of C2) to Tilera's TilePro and TileGx architectures a 
> few 
> years ago so I know a bit about the OpenJDK internals.
> 
> In the RISC-V community we view Java as a very important missing component of 
> the software ecosystem, so I was thrilled when Erik found me at FOSDMEM and 
> suggested there was community interest in a port.  Unfortunately, I won't 
> have 
> time to properly help out with the port (I'm maintaining Linux, as well as 
> co-maintaining binutils, GCC, and glibc).  That said, I'd be very happy to 
> help 
> out where I can.  I think a good way to move forward might be to:
> 
> * Create a project to own the RISC-V port, which is what this email is about. 
>   
>   I'm OK being the project lead, at least until we find someone who will have
> * Clean up our libffi port and submit it upstream.  Stefan O'Rear is in the  
>   process of submitting the port now, so it should all be moving smoothly 
> soon.
>   Submit patches for our Zero port.  While I didn't do the port I don't mind  
>   cleaning it up and submitting it.  I've added Martin who was more involved  
>   with the original port.  I think he's not working on RISC-V stuff now that  
>   he's at Google, though.
> * Move forward with a proper OpenJDK port, starting with the template  
>   interpreter and eventually adding C2.  I'm not sure if C1 is actually  
>   deprecated, but we decided not to bother with it at Tilera because it 
> didn't  
>   seem worth the extra effort at the time.  Of course, this would be up to  
>   whomever is actually doing the work :).
> 
> There appears to be considerable community interest in a RISC-V OpenJDK port, 
> so my hope is that while I don't have time to directly contribute much myself 
> that we'll be able to get something sane up and running.  Interested users 
> can 
> test on QEMU, and we've recently announced a board (and associated beta 
> program 
> that provide free boards to open source developers) so there's some hardware 
> to 
> run on as well.
> 
> I'd like to request that the Porters Group sponsors this project with me as 
> the 
> lead.
> 
> Thanks!

Re: Project proposal: RISC-V port

[Andrew Dinn]

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