Project proposal: RISC-V port

[Palmer Dabbelt]

RISC-V is an open standard ISA stewarded by the RISC-V foundation
<http://riscv.org>. 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!

[Corey Richardson]

On Wed, Feb 7, 2018, at 17:00, Palmer Dabbelt wrote:
> 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 absolutely love to participate in this somehow. I'm especially interested
in porting the JIT! My previous experience is mostly with Lua and small toys,
but I worked a lot on the Rust compiler.

Please keep me in the loop :)

--
cmr
http://octayn.net/
+16038524272

[Andrew Haley]

On 07/02/18 22:00, Palmer Dabbelt wrote:

> 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.

It's a multi-engineer-year project. Two engineers with deep knowledge
of HotSpot could get a bare-bones port done in a year, one doing the
assembler, C1, and template interpreter, and the other doing C2. Both
would work on the shared runtime. To get a really performant port done
would take at least twice that, probably longer.

Anyone wanting to lead a porting project had better have plenty of
time and considerable expertise, or it'll go nowhere. I'll be happy
to advise, cajole, and generally encourage, but it's going to take
boots on the ground.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[Palmer Dabbelt]

[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
<http://riscv.org>. 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!

[Bruce Hoult]

Having been involved in porting Microsoft's CoreCLR JIT to ARM (for Tizen 4.0) I'd say that's an underestimate, unless OpenJDK is somehow far better written.

I can't see either one being done without sponsorship by a major corporation.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/858dfbd1-5665-4b2a-70e2-ed790e17a2a8%40redhat.com.

[Andrew Haley]

On 08/02/18 17:20, Bruce Hoult wrote:
> Having been involved in porting Microsoft's CoreCLR JIT to ARM (for Tizen
> 4.0) I'd say that's an underestimate, unless OpenJDK is somehow far better
> written.

We have done it before. It's a lower bound.

Mind you, unless there's some real hardware available it'll take a lot
longer. For AArch64 we wrote a tiny simulator and lined it in to the
HotSpot runtime so that everything except the JIT-generated code ran
as native optimized x86-64 code. That helped a lot: if you had to run
the entire JVM in emulation you'd die waiting for it to get as far as
generating the interpreter.

[Bruce Hoult]

In two months you can have your hands on a quad core 1.5 GHz dev board with 8 GB RAM.

Though RISC-V is so easy to emulate that qemu on a recent i7 will probably be as fast or faster. (Using a root FS, chroot and binfmt_misc to set qemu as the interpreter for RISC-V ELF)

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b3649645-7269-dfe6-6367-4eafee5636a3%40redhat.com.

[Edward Nevill]

Hi,

I would like to voice my support for the creation of this project.

The process for creation of a new OpenJDK project is described at http://openjdk.java.net/projects/#new-project

The initial discussion should be sent to the general discussion list, discuss.at.openjdk.dot.java.dot.net. I have cc'd this to the general discussion list.

Assuming that the group lead of the porters project agrees to sponsor the project then the call for votes should be sent to
announce.at.openjdk.dot.java.dot.net.

Note that only current OpenJDK contributors may propose the creation of a new project. If you are not a current OpenJDK contributor I am happy to propose the project on your behalf.

http://openjdk.java.net/bylaws#contributor

I am happy to devote some 'spare' time to this project, but this will me limited to a few hours per week.

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.

Andrew Haley's suggestion of using a built in simulator is a good one. This was the approach used on the aarch64 project and it was invaluable not just in terms of development time in the absence of hardware but in terms of debuggability. Also OpenJDK depends on a huge list of packages to build. Using this approach you can build and run on x86 while all the dependant packages are being ported.

All the best,
Ed.

[Palmer Dabbelt]

On Fri, 09 Feb 2018 02:57:21 PST (-0800), edward...@gmail.com wrote:
> Hi,
>
> I would like to voice my support for the creation of this project.
>
> The process for creation of a new OpenJDK project is described at http://openjdk.java.net/projects/#new-project
>
> The initial discussion should be sent to the general discussion list, discuss.at.openjdk.dot.java.dot.net. I have cc'd this to the general discussion list.

Thanks.

> Assuming that the group lead of the porters project agrees to sponsor the project then the call for votes should be sent to
> announce.at.openjdk.dot.java.dot.net.
>
> Note that only current OpenJDK contributors may propose the creation of a new project. If you are not a current OpenJDK contributor I am happy to propose the project on your behalf.

We never submitted the Tilera port, so I'm not a contributor at all. It would
be great if you could propose the project for me.

> http://openjdk.java.net/bylaws#contributor
>
> I am happy to devote some 'spare' time to this project, but this will me limited to a few hours per week.

Well, that's about all the time I'll have as well :). I know that OpenJDK is
way more work than a spare time project, but I'm hoping that we can at least
get things started with a community effort and then see where things go from
there.

> 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.
>
> Andrew Haley's suggestion of using a built in simulator is a good one. This was the approach used on the aarch64 project and it was invaluable not just in terms of development time in the absence of hardware but in terms of debuggability. Also OpenJDK depends on a huge list of packages to build. Using this approach you can build and run on x86 while all the dependant packages are being ported.

That makes sense. IIRC there were a lot of headaches involved in getting this
all together last time, and having a simulator seems like a good idea.

[Bruce Hoult]

It would be a really good thing to have one or more EC2 AMIs available that people could just spin up on whatever instance they want and it puts them into an emulated RISC-V Linux environment. Preferably taking advantage of all the available cores. User mode qemu with a chroot and binfmt_misc could be made to work right now, and full system qemu when that supports multiple cores. Or RV8 if that gets more syscalls implemented.

And/or Docker.

I'd be happy to set that kind of thing up once I get freed up to work on RISC-V stuff full time.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/mhng-793d8e1c-ea48-423c-8911-9fe97483f3e7%40palmer-si-x1c4.

[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:

[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.

[Palmer Dabbelt]

On Wed, 07 Mar 2018 03:37:05 PST (-0800), ad...@redhat.com wrote:
> 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.

Seeing as how Ed is the only one who has submitted any patches I guess he's the
only one who's actually entitled to vote, but FWIW he sounds like a good RISC-V
port lead to me :).

[Sean Halle]

Thanks for starting this thread, Palmer.  

Good to meet everyone.

I'm Sean, at Intensivate.  We're doing an accelerator card for applications that scale to hundreds or thousands of servers.  The core is laid out and we're targeting 3GHz in 16nm.  We're also using FireSim to verify the RTL and let customers login to the accelerator hardware (on FPGA) and install their code and run it.

However, much of this code is..  in Java.  So, we're motivated to get to some form of Java running on RISC-V as soon as possible.  We just closed seed funding, and are ramping up on the JVM port.  If anyone is interested in exploring potential ways to work together on that, my email is sean...@intensivate.com  would love to talk about it.  All options are open on our end.

The goal is to do the minimum work possible to get OpenJDK up and running.  Martin (hi Martin!) looked at it, with a student, Michael.  Michael nearly completed the interpreter portion, as far as I understand, and he has made the code base public now.

From Michael:

https://bitbucket.org/mknyszek/riscv-hotspot-test/src/default/
https://bitbucket.org/mknyszek/openjdk-riscv-hotspot/src/default/
https://bitbucket.org/mknyszek/openjdk-riscv/src/default/
https://bitbucket.org/mknyszek/openjdk-riscv-jdk/src/default/
I've made all the repositories public! riscv-hotspot-test just contains some test files I've been using to try and bring up the VM, the other 3 are bona fide OpenJDK repositories with some patches on top. There's a README-RISCV file in some of them explaining how to get set up.

I've CCd Michael, in case he has time and would like to say more (he's at Google now, and for some reason that seems to keep him busy :-).

The initial idea we're looking at first is to just modify the backend code generator.  Start with the MIPS backend and modify it into RISC-V.  As far as I understand, Michael already has the interpreter (mostly) working.  We plan to pick up from there, get the interpreter solid, and in parallel start work on modifying the backend.  

There may be some complications, for example, due to differences in memory consistency model, but this first version is for in-order micro-architectures only, which we're hoping simplifies things.  Extending to out-of-order is left for later.  In addition, we are simplifying by leaving performance tuning for later.  This first version is just to have something working at reasonable performance on simple cores.  

Does this backend-only plan sound reasonable?  Do you know of any complexities that could potentially throw a monkey wrench into that?

There were some scary comments about the level of effort required (thank you for those warnings, by the way), hopefully there is a path to limit the scope of the work, by giving up performance tuning and limiting to just in-order simple cores.

Thanks,

Sean

http://intensivate.com

[lazyp...@gmail.com]

FYI The initial porting is done.

I CC'ed Yadong Wang and Dingli Zhang to this thread. He is the contact of the BishengJDK team. His team open sourced the first HotSpot JIT porting for RV64G. Dingli Zhang is our colleague who is full-time working on OpenJDK porting.

PLCT is collaborating with the BishengJDK team. We are now based on the same codebase and set up https://github.com/openjdk-riscv/ for the new united team.

The status of OpenJDK/HotSport RV64G JIT porting could be found at [2]. I've posted the initial benchmark results on the RVI sw-dev mailing list. The result is very promising. Roughly 20x improvement has been observed. We are very optimistic on the 100x speed up goal[3].

[1] https://github.com/v8-riscv/v8/wiki/Testing-Status

[2] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/HziqjQ_2o2w

[3] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/fIYoDnpqww8

2018年8月12日日曜日 3:40:42 UTC+8 sean...@gmail.com: