Supported platforms

Martijn Verburg martijnverburg at
Tue Apr 10 16:42:23 UTC 2018

Hi all,

Apologies for being late to the thread.  We're looking to provide a central
place for OpenJDK binaries to be produced and have some level of community
support for the more esoteric platforms.  Perhaps this is a place where you
can get some extra assistance in keeping a particular port vibrant (having
regularly tested builds helps)p.

See the following for details:

* - Build Farm overview
* (end user site)
* (join ~200 volunteers!)
* (Jenkins cluster)

It's still a work in progress but many of the OpenJDK vendors you know of
today are involved (Oracle, IBM, Red Hat, SAP et al) and so we're hopeful
that the collaboration there will help the more esoteric platforms that do
gain genuine popularity and support can flourish without adding further
burden on a single vendor.

We'll be following a very strong policy of reporting and submitting patches
upstream to OpenJDK / OpenJ9 / <insert OpenJDK variant X>, exactly how it
works today with various porting and downstream implementations today.
This isn't strictly an OpenJDK effort, so please do head over to to find out more or ping the
adoption-discuss mailing list here at OpenJDK.


On 10 April 2018 at 10:24, David Holmes <david.holmes at> 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]
>>>> [2]
>>>> [3]
>>>> [4]
>>>> [5]
>>>> [6]
>>>> 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>
>>>>>> To: Simon Nash<simon at>,bren at
>>>>>> Cc:build-dev at, hotspot-dev developers
>>>>>>     <hotspot-dev at>
>>>>>> Subject: Re: Supported platforms
>>>>>> Message-ID:<4b1f262d-b9d2-6844-e453-dd53b42b2d74 at>
>>>>>> 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  wrote:
>>>>>>>> Many thanks with the link about the Platforms supported:
>>>>>> 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
>>>>> 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

More information about the build-dev mailing list