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