From aph at redhat.com Thu Feb 8 16:12:24 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Feb 2018 16:12:24 +0000 Subject: [sw-dev] Project proposal: RISC-V port In-Reply-To: References: Message-ID: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> 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. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From palmer at dabbelt.com Thu Feb 8 16:38:08 2018 From: palmer at dabbelt.com (Palmer Dabbelt) Date: Thu, 08 Feb 2018 08:38:08 -0800 (PST) Subject: Project proposal: RISC-V port Message-ID: [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! From aph at redhat.com Thu Feb 8 18:23:58 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 8 Feb 2018 18:23:58 +0000 Subject: [sw-dev] Project proposal: RISC-V port In-Reply-To: References: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> Message-ID: 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. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bruce at hoult.org Thu Feb 8 17:20:35 2018 From: bruce at hoult.org (Bruce Hoult) Date: Thu, 8 Feb 2018 20:20:35 +0300 Subject: [sw-dev] Project proposal: RISC-V port In-Reply-To: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> References: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> Message-ID: 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. On Thu, Feb 8, 2018 at 7:12 PM, Andrew Haley wrote: > 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. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -- > 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 at groups.riscv.org. > To post to this group, send email to sw-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce at hoult.org Thu Feb 8 19:12:22 2018 From: bruce at hoult.org (Bruce Hoult) Date: Thu, 8 Feb 2018 22:12:22 +0300 Subject: [sw-dev] Project proposal: RISC-V port In-Reply-To: References: <858dfbd1-5665-4b2a-70e2-ed790e17a2a8@redhat.com> Message-ID: 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) On Thu, Feb 8, 2018 at 9:23 PM, Andrew Haley wrote: > 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. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -- > 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 at groups.riscv.org. > To post to this group, send email to sw-dev at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.nevill at gmail.com Fri Feb 9 10:57:21 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 09 Feb 2018 10:57:21 +0000 Subject: Project proposal: RISC-V port In-Reply-To: References: Message-ID: <1518173841.2854.29.camel@gmail.com> 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. 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! From adinn at redhat.com Fri Feb 9 14:08:05 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 9 Feb 2018 14:08:05 +0000 Subject: Project proposal: RISC-V port In-Reply-To: <1518173841.2854.29.camel@gmail.com> References: <1518173841.2854.29.camel@gmail.com> Message-ID: <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> On 09/02/18 10:57, Edward Nevill wrote: > I would like to voice my support for the creation of this project. Ditto! > I am happy to devote some 'spare' time to this project, but this will > me limited to a few hours per week. I wish I could make a similar offer but unfortunately I cannot make that commitment at present. > 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. > 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. I agree. This was an enormous boost to productivity when doing the AArch64 port and I would recommend it to anyone doing a port -- especially while early chips still run the risk of hardware bugs. Andrew Haley and I did document this process, albeit only in overview, in our FOSDEM talk from 2013. I'd be happy to help anyone wishing to attempt the same trick understand in more detail how we did it -- in particular how we implemented debug support in the simulator (of course, the AArch64 sim code, including debugger is still available on sourceforge and the jdk code which used it is still in the AArch64 port repo). 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 From palmer at dabbelt.com Tue Feb 13 18:41:31 2018 From: palmer at dabbelt.com (Palmer Dabbelt) Date: Tue, 13 Feb 2018 10:41:31 -0800 (PST) Subject: Project proposal: RISC-V port In-Reply-To: <1518173841.2854.29.camel@gmail.com> Message-ID: On Fri, 09 Feb 2018 02:57:21 PST (-0800), edward.nevill at 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. > > 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! From bruce at hoult.org Tue Feb 13 18:49:38 2018 From: bruce at hoult.org (Bruce Hoult) Date: Tue, 13 Feb 2018 21:49:38 +0300 Subject: [sw-dev] Re: Project proposal: RISC-V port In-Reply-To: References: <1518173841.2854.29.camel@gmail.com> Message-ID: 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. On Tue, Feb 13, 2018 at 9:41 PM, Palmer Dabbelt wrote: > On Fri, 09 Feb 2018 02:57:21 PST (-0800), edward.nevill at 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. > > > >> 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! >>> >> > -- > 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 at groups.riscv.org. > To post to this group, send email to sw-dev at groups.riscv.org. > Visit this group at https://groups.google.com/a/gr > oups.riscv.org/group/sw-dev/. > To view this discussion on the web visit https://groups.google.com/a/gr > oups.riscv.org/d/msgid/sw-dev/mhng-793d8e1c-ea48-423c-8911- > 9fe97483f3e7%40palmer-si-x1c4. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cthalinger at twitter.com Wed Feb 14 02:56:55 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 13 Feb 2018 18:56:55 -0800 Subject: Project proposal: RISC-V port In-Reply-To: <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> Message-ID: <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> > On Feb 9, 2018, at 6:08 AM, Andrew Dinn wrote: > > On 09/02/18 10:57, Edward Nevill wrote: >> I would like to voice my support for the creation of this project. > > Ditto! > >> I am happy to devote some 'spare' time to this project, but this will >> me limited to a few hours per week. > > I wish I could make a similar offer but unfortunately I cannot make that > commitment at present. > >> 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. ?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. > >> 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. > > I agree. This was an enormous boost to productivity when doing the > AArch64 port and I would recommend it to anyone doing a port -- > especially while early chips still run the risk of hardware bugs. > > Andrew Haley and I did document this process, albeit only in overview, > in our FOSDEM talk from 2013. I'd be happy to help anyone wishing to > attempt the same trick understand in more detail how we did it -- in > particular how we implemented debug support in the simulator (of course, > the AArch64 sim code, including debugger is still available on > sourceforge and the jdk code which used it is still in the AArch64 port > repo). > > 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 From adinn at redhat.com Wed Feb 14 13:05:41 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Feb 2018 13:05:41 +0000 Subject: Project proposal: RISC-V port In-Reply-To: <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> Message-ID: 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 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 From thomas.wuerthinger at oracle.com Wed Feb 14 11:29:20 2018 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 14 Feb 2018 11:29:20 -0000 Subject: Project proposal: RISC-V port In-Reply-To: <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> Message-ID: 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. From thomas.wuerthinger at oracle.com Wed Feb 14 14:27:15 2018 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Wed, 14 Feb 2018 14:27:15 -0000 Subject: Project proposal: RISC-V port In-Reply-To: References: <1518173841.2854.29.camel@gmail.com> <6763ccdb-c0f7-46b9-809e-f476abad9407@redhat.com> <6A9A634A-59B9-4BC1-ADF0-591EAD1967AE@twitter.com> Message-ID: 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 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