David,
Sorry I was mis-remembering. Of course C1 and Minimal still exist in
the 32-bit code. Though I would be concerned that with a focus on
64-bit it will be easy for engineers to overlook things that should be
inside one of the INCLUDE_XXX guards. (Particularly as we don't do any
32-bit builds and for the most part don't even have the capability to
perform them.)
It seems like BellSoft is not alone in building 32-bit code so we hope
the community will notice if something gets broken. That said, it does
not seem like too big of a deal to have, say, Linux x86 32 bit builds
running in any build farm. This should catch most of the INCLUDE_XXX
types of errors.
-Aleksei
On 10/04/2018 12:24, David Holmes wrote:
On 10/04/2018 7:17 PM, Aleksei Voitylov wrote:
David,
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 don't recall seeing anything related to 32-bit ARM, but perhaps it's
all in areas I don't see (like compiler and gc).
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:
Sorry I was mis-remembering. Of course C1 and Minimal still exist in
the 32-bit code. Though I would be concerned that with a focus on
64-bit it will be easy for engineers to overlook things that should be
inside one of the INCLUDE_XXX guards. (Particularly as we don't do any
32-bit builds and for the most part don't even have the capability to
perform them.)
Cheers,
David
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!
-Aleksei
Cheers,
David
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.
Thanks,
-Aleksei
[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).
Cheers,
David
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
<hotspot-...@openjdk.java.net>
Subject: Re: Supported platforms
Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Simon,
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:
http://www.oracle.com/technetwork/java/javase/documentation/jdk10cert
config-4417031.html
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.
/Magnus
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).
-https://adoptopenjdk.net/releases.html
- Bellsoft provides support for 32-bit ARMv7.
-https://bell-sw.com/products.html
- Azul provides 32-bit x86 and ARMv7 binaries as well as 64-bit
x86 and aarch64.
-https://www.azul.com/downloads/zulu/
I'm sure there are several others I've missed - sorry!
- Derek
