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

[David Holmes]

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.

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
>>>
>
>
>