RFR(S) 8074312: Enable hotspot builds on 4.x Linux kernels

Tue Mar 10 02:07:01 UTC 2015

On 2015-03-09 15:03, David Holmes wrote:
> On 9/03/2015 10:29 PM, Severin Gehwolf wrote:
>> Hi David,
>>
>> Thanks for getting back to me so quickly!
>>
>> On Fri, 2015-03-06 at 07:00 +1000, David Holmes wrote:
>>> Hi Severin,
>>>
>>> On 6/03/2015 2:27 AM, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> Could someone please review the following one-liner to the hotspot 
>>>> build
>>>> files. This prevents someone from building on 4.x Linux kernels 
>>>> such as
>>>> F22, which will become available in May 2015[1].
>>>>
>>>> Currently, a JDK 9 build fails for me with:
>>>>> &2 echo "*** This OS is not supported:" `uname -a`; exit 1;
>>>> ++ uname -a
>>>> + echo '*** This OS is not supported:' Linux f22 
>>>> 4.0.0-0.rc1.git0.1.fc22.x86_64 '#1' SMP Mon Feb 23 21:15:25 UTC 
>>>> 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>> *** This OS is not supported: Linux f22 
>>>> 4.0.0-0.rc1.git0.1.fc22.x86_64 #1 SMP Mon Feb 23 21:15:25 UTC 2015 
>>>> x86_64 x86_64 x86_64 GNU/Linux
>>>> + exit 1
>>>>
>>>> The fix is to add 4 to the list of Linux kernels, similar to what was
>>>> done for 3.x kernels in JDK-7072341.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074312
>>>> webrev: 
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8074312/webrev.00/
>>>>
>>>> I'd also please need a sponsor for this change.
>>>
>>> The whole purpose of those version checks is to ensure we know there is
>>> a reasonable level of support for a platform before we enable it -
>>> anyone can make the change locally to try for themselves (and deal with
>>> the consequences). Otherwise we may as well just remove the version 
>>> checks.
>>
>> OK. Is there some form of definition for "reasonable level of support"?
>> Is being able to build hotspot and being able to run simple Java
>> programs enough? For the time being I'm fine with keeping this patch
>> local, fwiw.
>
> The main thing is not to have something that might cause newcomers a 
> lot of grief trying to build/run OpenJDK on their brand new system 
> XYZ. Chances are they haven't checked to see if XYZ is on the 
> supported platform list. :) So if it builds and runs basic programs 
> okay it should be okay.
>
>>> So I can sponsor this change for you assuming that everything does
>>> indeed build and run fine on the Linux 4 kernel.
>>
>> I can build JDK 8 fine on a F22 pre-release (x86_64):
>> $ hg paths
>> default = http://hg.openjdk.java.net/jdk8u/jdk8u
>> $ hg tip
>> changeset:   1284:e532f3672f63
>> tag:         tip
>> user:        katleman
>> date:        Wed Feb 25 12:59:47 2015 -0800
>> summary:     Added tag jdk8u60-b04 for changeset d8d408861c20
>> $ 
>> ./build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -version 
>>
>> openjdk version "1.8.0-internal"
>> OpenJDK Runtime Environment (build 
>> 1.8.0-internal-sgeholf_2015_03_09_12_00-b00)
>> OpenJDK 64-Bit Server VM (build 25.60-b05, mixed mode)
>> $ cat /etc/fedora-release
>> Fedora release 22 (Twenty Two)
>> $ gcc --version
>> gcc (GCC) 5.0.0 20150226 (Red Hat 5.0.0-0.17)
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There 
>> is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>> PURPOSE.
>>
>> Things get trickier with JDK 9. However, I don't think they're linux
>> kernel version related, but rather GCC 5 related.
>
> Interesting ...
>
>>> Also it seems Fedora22 will have gcc 5 so do we need build changes to
>>> support that as well?
>>
>> Very likely. At this point I'm still investigating what's necessary to
>> build JDK 9 on F22. While JDK 8 builds fine with this patch, JDK 9 has
>> more failures which I'm currently looking into too.
>
> ... Is that because we have additional warnings enabled in 9 and 
> -Werror ?
>
>>> Are there any major new or changed features in the linux 4 kernel that
>>> may impact the JVM?
>>
>> I don't think so. FWIW, calling the kernel version 4.0-rc1 instead of
>> 3.20 is just a majority decision from the crowd on G+[1] :) The 4.x
>> version bump does not mean there are any breaking changes. That's
>> similar to the 3.0.0.rc-1 naming instead of calling it 2.6.40, back in
>> May 2011[2].
>>
>> That begs the question: Should hotspot really be doing this kernel
>> version check? It does make sense for OS releases that use major version
>> bumps to communicate breaking changes. Not so much for the linux kernel
>> these days. There is no specific check for 3.18 or 3.16 in hotspot.
>> AFAIUI there is only a global 3.x version check. Considering that
>> 4.0-rc1 could have been called just as well 3.20 this kernel version
>> checking by default seems arbitrary. Thoughts?
>
> Yes this does seem somewhat pointless if major version number changes 
> are not based on technical changes. But I'd probably just add the 4.x 
> support and not throw it out altogether - then revisit for 5 :)
>
> So I can accept this patch as-is.
>
> Still need a second reviewer.

I agree that having the check is rather arbitrary to start with, but the 
suggested change looks good!

Cheers,
Mikael

>
> David
>
>> Cheers,
>> Severin
>>
>> [1] http://lkml.iu.edu/hypermail/linux/kernel/1502.2/04059.html
>> [2] https://lkml.org/lkml/2011/5/29/204
>>
>>> Thanks,
>>> David
>>>
>>>
>>>> Thanks,
>>>> Severin
>>>>
>>>> [1] http://fedoraproject.org/wiki/Releases/22/Schedule
>>>>
>>
>>
>>