From david.holmes at oracle.com Tue Jun 5 04:24:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jun 2018 14:24:30 +1000 Subject: ARM port consolidation In-Reply-To: References: Message-ID: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Hi Bob, Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. I think this is a good idea. Thanks, David On 5/06/2018 6:34 AM, Bob Vandette wrote: > During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit > ARM ports and contributed them to OpenJDK. These ports have been used for > years in the embedded and mobile market, making them very stable and > having the benefit of a single source base which can produce both 32 and > 64-bit binaries. The downside of this contribution is that it resulted > in two 64-bit ARM implementations being available in OpenJDK. > > I'd like to propose that we eliminate one of the 64-bit ARM ports and > encourage everyone to enhance and support the remaining 32 and 64 bit > ARM ports. This would avoid the creation of yet another port for these chip > architectures. The reduction of competing ports will allow everyone > to focus their attention on a single 64-bit port rather than diluting > our efforts. This will result in a higher quality and a more performant > implementation. > > The community at large (especially RedHat, BellSoft, Linaro and Cavium) > have done a great job of enhancing and keeping the AArch64 port up to > date with current and new Hotspot features. As a result, I propose that > we standardize the 64-bit ARM implementation on this port. > > If there are no objections, I will file a JEP to remove the 64-bit ARM > port sources that reside in jdk/open/src/hotspot/src/cpu/arm > along with any build logic. This will leave the Oracle contributed > 32-bit ARM port and the AArch64 64-bit ARM port. > > Let me know what you all think, > Bob Vandette > > From gil at azul.com Thu Jun 7 04:23:29 2018 From: gil at azul.com (Gil Tene) Date: Thu, 7 Jun 2018 04:23:29 +0000 Subject: ARM port consolidation In-Reply-To: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: This makes sense to me on the Aarch64 side. However, on the ARM32 side, I don't think the situation is as straightforward as what is being presented below, and I think more discussion and exploration of alternatives is needed. Much like with AArch64, there is an existing, active, community-developed and community-supported AArch32 port in OpenJDK that predates Oracle's open sourcing of their ARM32 version. That port is being used by multiple downstream builds and, at least for the past year+, it seems to have had more attention and ongoing engineering commitment around it than the Oracle variant. Before making a choice of one AArch32 port vs the other (if such a choice even needs to be made), I would like to hear more about the resources being committed towards maintaining each, keeping each up to date, testing them on various platforms (e.g. including building, testing, and supporting the popular softfloat ABI variants imposed by some OS packages) and working on bug fixes as needs appear. ? Gil. > On Jun 4, 2018, at 6:24 PM, David Holmes wrote: > > Hi Bob, > > Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. > > I think this is a good idea. > > Thanks, > David > > On 5/06/2018 6:34 AM, Bob Vandette wrote: >> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >> ARM ports and contributed them to OpenJDK. These ports have been used for >> years in the embedded and mobile market, making them very stable and >> having the benefit of a single source base which can produce both 32 and >> 64-bit binaries. The downside of this contribution is that it resulted >> in two 64-bit ARM implementations being available in OpenJDK. >> I'd like to propose that we eliminate one of the 64-bit ARM ports and >> encourage everyone to enhance and support the remaining 32 and 64 bit >> ARM ports. This would avoid the creation of yet another port for these chip >> architectures. The reduction of competing ports will allow everyone >> to focus their attention on a single 64-bit port rather than diluting >> our efforts. This will result in a higher quality and a more performant >> implementation. >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features. As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic. This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. >> Let me know what you all think, >> Bob Vandette -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From david.holmes at oracle.com Thu Jun 7 04:56:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Jun 2018 14:56:08 +1000 Subject: ARM port consolidation In-Reply-To: References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> Hi Gil, On 7/06/2018 2:23 PM, Gil Tene wrote: > This makes sense to me on the Aarch64 side. > > However, on the ARM32 side, I don't think the situation is as straightforward as > what is being presented below, and I think more discussion and exploration of > alternatives is needed. > > Much like with AArch64, there is an existing, active, community-developed and > community-supported AArch32 port in OpenJDK that predates Oracle's open > sourcing of their ARM32 version. That port is being used by multiple downstream > builds and, at least for the past year+, it seems to have had more attention and > ongoing engineering commitment around it than the Oracle variant. To clarify: "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1] whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports. David [1] http://openjdk.java.net/projects/aarch32-port/ > Before making a choice of one AArch32 port vs the other (if such a choice > even needs to be made), I would like to hear more about the resources being > committed towards maintaining each, keeping each up to date, testing them on > various platforms (e.g. including building, testing, and supporting the popular > softfloat ABI variants imposed by some OS packages) and working on bug > fixes as needs appear. > ? Gil. > >> On Jun 4, 2018, at 6:24 PM, David Holmes wrote: >> >> Hi Bob, >> >> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. >> >> I think this is a good idea. >> >> Thanks, >> David >> >> On 5/06/2018 6:34 AM, Bob Vandette wrote: >>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >>> ARM ports and contributed them to OpenJDK. These ports have been used for >>> years in the embedded and mobile market, making them very stable and >>> having the benefit of a single source base which can produce both 32 and >>> 64-bit binaries. The downside of this contribution is that it resulted >>> in two 64-bit ARM implementations being available in OpenJDK. >>> I'd like to propose that we eliminate one of the 64-bit ARM ports and >>> encourage everyone to enhance and support the remaining 32 and 64 bit >>> ARM ports. This would avoid the creation of yet another port for these chip >>> architectures. The reduction of competing ports will allow everyone >>> to focus their attention on a single 64-bit port rather than diluting >>> our efforts. This will result in a higher quality and a more performant >>> implementation. >>> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >>> have done a great job of enhancing and keeping the AArch64 port up to >>> date with current and new Hotspot features. As a result, I propose that >>> we standardize the 64-bit ARM implementation on this port. >>> If there are no objections, I will file a JEP to remove the 64-bit ARM >>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >>> along with any build logic. This will leave the Oracle contributed >>> 32-bit ARM port and the AArch64 64-bit ARM port. >>> Let me know what you all think, >>> Bob Vandette > From magnus.ihse.bursie at oracle.com Thu Jun 7 09:41:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Jun 2018 11:41:41 +0200 Subject: ARM port consolidation In-Reply-To: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: From a build perspective, it would certainly simplify things if we have just a single port, so I'm in favour of this proposal. /Magnus On 2018-06-05 06:24, David Holmes wrote: > Hi Bob, > > Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. > > I think this is a good idea. > > Thanks, > David > > On 5/06/2018 6:34 AM, Bob Vandette wrote: >> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >> ARM ports and contributed them to OpenJDK.? These ports have been >> used for >> years in the embedded and mobile market, making them very stable and >> having the benefit of a single source base which can produce both 32 and >> 64-bit binaries.? The downside of this contribution is that it resulted >> in two 64-bit ARM implementations being available in OpenJDK. >> >> I'd like to propose that we eliminate one of the 64-bit ARM ports and >> encourage everyone to enhance and support the remaining 32 and 64 bit >> ARM ports. This would avoid the creation of yet another port for >> these chip >> architectures.? The reduction of competing ports will allow everyone >> to focus their attention on a single 64-bit port rather than diluting >> our efforts.? This will result in a higher quality and a more performant >> implementation. >> >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features.? As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic.? This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. >> >> Let me know what you all think, >> Bob Vandette >> >> From bob.vandette at oracle.com Thu Jun 7 14:48:16 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 7 Jun 2018 10:48:16 -0400 Subject: ARM port consolidation In-Reply-To: <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> Message-ID: <794BFAA0-6FCB-4730-9A89-B6B3F3D728BF@oracle.com> I agree with David. I do know that our implementation does run in AArch32 mode and it should be very easy to add dynamic AArch32 detection in order to make use of the few new AArch32 specific instructions such as the memory barrier instructions (LDAR/STLR). Since our current port already contains ARMv8 instruction pneumonics, we are already 1/2 way there. Bob. > On Jun 7, 2018, at 12:56 AM, David Holmes wrote: > > Hi Gil, > > On 7/06/2018 2:23 PM, Gil Tene wrote: >> This makes sense to me on the Aarch64 side. >> However, on the ARM32 side, I don't think the situation is as straightforward as >> what is being presented below, and I think more discussion and exploration of >> alternatives is needed. >> Much like with AArch64, there is an existing, active, community-developed and >> community-supported AArch32 port in OpenJDK that predates Oracle's open >> sourcing of their ARM32 version. That port is being used by multiple downstream >> builds and, at least for the past year+, it seems to have had more attention and >> ongoing engineering commitment around it than the Oracle variant. > > To clarify: > > "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1] > > whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports. > > David > > [1] http://openjdk.java.net/projects/aarch32-port/ > >> Before making a choice of one AArch32 port vs the other (if such a choice >> even needs to be made), I would like to hear more about the resources being >> committed towards maintaining each, keeping each up to date, testing them on >> various platforms (e.g. including building, testing, and supporting the popular >> softfloat ABI variants imposed by some OS packages) and working on bug >> fixes as needs appear. >> ? Gil. >>> On Jun 4, 2018, at 6:24 PM, David Holmes wrote: >>> >>> Hi Bob, >>> >>> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. >>> >>> I think this is a good idea. >>> >>> Thanks, >>> David >>> >>> On 5/06/2018 6:34 AM, Bob Vandette wrote: >>>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >>>> ARM ports and contributed them to OpenJDK. These ports have been used for >>>> years in the embedded and mobile market, making them very stable and >>>> having the benefit of a single source base which can produce both 32 and >>>> 64-bit binaries. The downside of this contribution is that it resulted >>>> in two 64-bit ARM implementations being available in OpenJDK. >>>> I'd like to propose that we eliminate one of the 64-bit ARM ports and >>>> encourage everyone to enhance and support the remaining 32 and 64 bit >>>> ARM ports. This would avoid the creation of yet another port for these chip >>>> architectures. The reduction of competing ports will allow everyone >>>> to focus their attention on a single 64-bit port rather than diluting >>>> our efforts. This will result in a higher quality and a more performant >>>> implementation. >>>> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >>>> have done a great job of enhancing and keeping the AArch64 port up to >>>> date with current and new Hotspot features. As a result, I propose that >>>> we standardize the 64-bit ARM implementation on this port. >>>> If there are no objections, I will file a JEP to remove the 64-bit ARM >>>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >>>> along with any build logic. This will leave the Oracle contributed >>>> 32-bit ARM port and the AArch64 64-bit ARM port. >>>> Let me know what you all think, >>>> Bob Vandette From dalibor.topic at oracle.com Wed Jun 13 11:52:20 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 13 Jun 2018 13:52:20 +0200 Subject: Current Status of OpenJDK 8 for mips64el In-Reply-To: References: Message-ID: <4093f9b9-2159-e4c0-9359-fd5f66c9ec46@oracle.com> On 30.05.2018 07:54, Ao Qi wrote: > Hi all, > > Here is current status of Loongson OpenJDK 8 for mips64el [1][2]: > > - currently supporting the Template Table Interpreter and C2. C1 is not > supported yet and is under development. > > - passed JCK, jcstress and some other tests > > - updated to jdk8u172-b11, the latest released jdk8u > > - widely used in Loongson's products, especially server products > > As far as I know, all of the contributors (companies or individuals) has > signed OCA. I know that jdk8u is a very old version. Is it possible to > upstream the code to the community? Hi, I think that it's too late for a new a port come into JDK 8 Updates Project at this time, with less then a year to go under the current maintainers, considering how long it would take to bring the code into OpenJDK, run through the JEP process, code reviews, etc. It's probably too late for a fresh port to make it into JDK 11, as well, with less than a month to go until rampdown starts. So my suggestion would be to start by bringing your port into the MIPS Porting Project, and then, once it's brought forward to JDK 11 and there is a build passing JCK for Java SE 11, to go through the JEP process for inclusion in a later version of the JDK. cheers, dalibor topic > > Everybody who's interested is invited in building and testing the MIPS port. > > Comments and suggestions are welcome! > > Regards, > Ao Qi > > [1] http://hg.loongnix.org/jdk8-mips64-public/ > [2] http://mail.openjdk.java.net/pipermail/porters-dev/2016-May/000544.html > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Wed Jun 13 12:05:21 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 13:05:21 +0100 Subject: Current Status of OpenJDK 8 for mips64el In-Reply-To: <4093f9b9-2159-e4c0-9359-fd5f66c9ec46@oracle.com> References: <4093f9b9-2159-e4c0-9359-fd5f66c9ec46@oracle.com> Message-ID: <22471aa1-46e3-1123-9483-a705fbeadff1@redhat.com> On 06/13/2018 12:52 PM, dalibor topic wrote: > So my suggestion would be to start by bringing your port into the MIPS > Porting Project Yes. Let us at least get a copy of the port in the OpenJDK repos; it's a useful thing to have on its own. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aoqi at loongson.cn Tue Jun 19 08:28:02 2018 From: aoqi at loongson.cn (Ao Qi) Date: Tue, 19 Jun 2018 16:28:02 +0800 Subject: Current Status of OpenJDK 8 for mips64el In-Reply-To: <4093f9b9-2159-e4c0-9359-fd5f66c9ec46@oracle.com> References: <4093f9b9-2159-e4c0-9359-fd5f66c9ec46@oracle.com> Message-ID: > > Hi, > > I think that it's too late for a new a port come into JDK 8 Updates Project > at this time, with less then a year to go under the current maintainers, > considering how long it would take to bring the code into OpenJDK, run > through the JEP process, code reviews, etc. > > It's probably too late for a fresh port to make it into JDK 11, as well, > with less than a month to go until rampdown starts. > Thank you very much for your reply and suggestion. I understand that it is too late for a new port to be into the main line of jdk8u and jdk11. > So my suggestion would be to start by bringing your port into the MIPS > Porting Project, and then, once it's brought forward to JDK 11 and there is > a build passing JCK for Java SE 11, to go through the JEP process for > inclusion in a later version of the JDK. > I think your suggestion is very reasonable, helpful and acceptable. We are willing to adopt your suggestion. However, I have one question about your suggestion. Could you explain more about bringing our port into the MIPS Porting Project? I'm not quite sure what it specifically means. Is that we can put our code into OpenJDK repository (not the main line) like aarh64 jdk8u[1] and the further development should happened according to community requirements, such as [2][3]? [1] http://hg.openjdk.java.net/aarch64-port [2] http://openjdk.java.net/bylaws [3] http://openjdk.java.net/contribute > cheers, > dalibor topic > >>