see inline:

On 10/04/2018 11:00, David Holmes wrote:
Hi Aleksei,

This is all news to me. Good news, but unexpected. As far as I was aware the 32-bit ARM port was dying a slow death and would eventually get removed. 64-bit ARM is of course very much alive and well under the Aarch64 porters - though I'm unclear if you are using that code for ARMv8 or the Oracle contributed code that used to be closed?
You are welcome :) We are doing everything possible to keep it running, so I don't see any reason within OpenJDK to it being removed. Regarding ARMv8 port, we are working with Cavium, Redhat, and Linaro on supporting the AARCH64 port.

I'm also unclear whether you are pushing changes back up to OpenJDK for these platforms, or maintaining them locally? I haven't noticed anything (other than build tweaks) and am curious about the release of a Minimal VM for JDK 10 given the Minimal VM effectively died along with the stand-alone Client VM.
We push everything upstream. I'm not sure why you believe Minimal VM and Client VM died in OpenJDK 10. From what I remember, there was some decision related to Client VM for Oracle binaries, but support for C1 and Minimal VM was not removed from OpenJDK codebase. This is what I get with BellSoft Liberica binaries built from OpenJDK on Raspberry Pi:

pi@rpi-3:~ $ java -version
openjdk version "10-BellSoft" 2018-03-20
OpenJDK Runtime Environment (build 10-BellSoft+0)
OpenJDK Server VM (build 10-BellSoft+0, mixed mode)
pi@rpi-3:~ $ java -minimal -version
openjdk version "10-BellSoft" 2018-03-20
OpenJDK Runtime Environment (build 10-BellSoft+0)
OpenJDK Minimal VM (build 10-BellSoft+0, mixed mode)
pi@rpi-3:~ $ java -client -version
openjdk version "10-BellSoft" 2018-03-20
OpenJDK Runtime Environment (build 10-BellSoft+0)
OpenJDK Client VM (build 10-BellSoft+0, mixed mode)

pi@rpi-3:~ $ java -minimal -XX:+PrintFlagsFinal HW | grep C1
     bool C1OptimizeVirtualCallProfiling           = true                                  {C1 product} {default}      bool C1ProfileBranches                        = true                                  {C1 product} {default}      bool C1ProfileCalls                           = true                                  {C1 product} {default}      bool C1ProfileCheckcasts                      = true                                  {C1 product} {default}      bool C1ProfileInlinedCalls                    = true                                  {C1 product} {default}      bool C1ProfileVirtualCalls                    = true                                  {C1 product} {default}      bool C1UpdateMethodData                       = false                                 {C1 product} {default}      bool InlineSynchronizedMethods                = true                                  {C1 product} {default}      bool LIRFillDelaySlots                        = false                              {C1 pd product} {default}      bool TimeLinearScan                           = false                                 {C1 product} {default}      bool UseLoopInvariantCodeMotion               = true                                  {C1 product} {default}      intx ValueMapInitialSize                      = 11                                    {C1 product} {default}      intx ValueMapMaxLoopSize                      = 8                                     {C1 product} {default}

Minimal VM and Client VM include C1, and Server VM includes C1 and C2. All (Client VM, Server VM, Minimal VM) were tested and work as expected.

For JDK11 you will need to do some work for Condy (if not already done) as well as JFR and Nest-based Access Control (which you can see in the nestmates branch of the Valhalla repo), as you mention below. Not sure what else may be needed. There's been a lot of code refactoring and include file changes that have impact on platform specific code as well.
Thanks for the heads-up!



On 10/04/2018 5:23 PM, Aleksei Voitylov wrote:
Hi David,

Speaking about the arm/ port, BellSoft has been releasing JCK-verified binaries (as provided under the OpenJDK license) from the arm/ port for the Raspberry Pi for JDK 9 [1] for a while and recently released one for JDK 10 [2], including OpenJFX and Minimal VM support. On Raspberry Pi 2 (ARMv7) and Raspberry Pi 3 (ARMv8 chip running Raspbian) the binaries produced from this port are passing all the required testing, including the new features recently open-sourced by Oracle (such as AppCDS). As far as JDK 11 is concerned, we are keeping track of the changes, recently fixed a couple of build issues that slipped in [3, 4], are working on Minimal Value Types support and, from what I can tell, will need to look into JFR and Nest-Based Access Control. Please let us know if we missed anything and we need to prepare for some other new features for porting.

The intent is to keep the arm/ port in good shape and provide well-tested binaries for the Raspberry Pi.

I believed Oracle was aware about BellSoft producing binaries from this port [5], [6]. Based on twitter, it seems like at least some engineers at Redhat and SAP are aware about it. Let me know if there is anything else we need to do to spread the word about it with Oracle engineering. For now, Boris (cced) is the engineer at BellSoft working on supporting the arm/ port for the Raspberry Pi. Other than that, I really wonder what "stepping up to take ownership of a port" means when it's upstream, and there is some procedure we need to follow.



[1] https://bell-sw.com/java-for-raspberry-pi-9.0.4.html
[2] https://bell-sw.com/java-for-raspberry-pi.html
[3] https://bugs.openjdk.java.net/browse/JDK-8200628
[4] https://bugs.openjdk.java.net/browse/JDK-8198949
[5] https://twitter.com/java/status/981239157874941955
[6] https://twitter.com/DonaldOJDK/status/981874485979746304

We are in a situation where previously "supported" platforms (by Oracle)
are no longer supported as, AFAIK, no one has stepped up to take
ownership of said platforms - which is a requirement for getting a new
port accepted into mainline. Without such ownership the code may not
only bit-rot, it may in time be stripped out completely. Any interested
parties would then need to look at (re)forming a port project for that
platform to keep it going in OpenJDK (or of course they are free to take
it elsewhere).


On 09/04/2018 18:35, White, Derek wrote:
Hi Magnus,

-----Original Message-----
Date: Mon, 9 Apr 2018 09:55:09 +0200
From: Magnus Ihse Bursie<magnus.ihse.bur...@oracle.com>
To: Simon Nash<si...@cjnash.com>,b...@juanantonio.info
Cc:build-dev@openjdk.java.net, hotspot-dev developers
Subject: Re: Supported platforms
Content-Type: text/plain; charset=utf-8; format=flowed


On 2018-04-08 16:30, Simon Nash wrote:
On 05/04/2018 02:26,b...@juanantonio.info  wrote:
Many thanks with the link about the Platforms supported:


This appears to be a list of the platforms that are supported
(certified) by
Oracle.? Where can I find the list of platforms that are supported by
OpenJDK?? For example, what about the following platforms that don't
appear on the Oracle list:

Windows x86
Linux x86
aarch32 (ARMv7 32-bit)
aarch64 (ARMv8 64-bit)

Are all these supported for OpenJDK 9, 10 and 11?
There is actually no such thing as a "supported OpenJDK platform". While I hope things may change in the future, OpenJDK as an organization does not publicize any list of "supported" platforms. Oracle publishes a list of platforms they support, and I presume that Red Hat and SAP and others do
the same, but the OpenJDK project itself does not.

With that said, platforms which were previously supported by Oracle (like the one's you mentioned) tend to still work more-or-less well, but they
receive no or little testing, and is prone to bit rot.

Surely you meant to say "receive no or little testing BY ORACLE, and ORACLE IS NOT RESPONSIBLE FOR ANY bit rot."

I haven't found a definitive list of supported OpenJDK platforms, but have an ad-hoc list of publicly available binaries: - Major linux distros are supporting x64 and aarch64 (arm64), and probably other platforms. - AdoptOpenJDK provides tested builds for most 64-bit platforms (x64, aarch64, ppc64, s390).
- Bellsoft provides support for 32-bit ARMv7.
- Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit x86 and aarch64.

I'm sure there are several others I've missed - sorry!
  - Derek

Reply via email to