Supported platforms
Aleksei Voitylov
aleksei.voitylov at bell-sw.com
Tue Apr 10 09:48:00 UTC 2018
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 at 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 at 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 at 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 at 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.bursie at oracle.com>
>>>>>> To: Simon Nash<simon at cjnash.com>,bren at juanantonio.info
>>>>>> Cc:build-dev at openjdk.java.net, hotspot-dev developers
>>>>>> <hotspot-dev at openjdk.java.net>
>>>>>> Subject: Re: Supported platforms
>>>>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at 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,bren at 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
>>>>
>>
More information about the build-dev
mailing list