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

Mon Mar 9 12:53:55 UTC 2015

On Mon, Mar 9, 2015 at 1:29 PM, Severin Gehwolf <sgehwolf at redhat.com> 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.
>
>> 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.
>
>> 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.
>
>> 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?
>

I agree. We could leave the check for the minimum supported versions
in place, but everything greater 3 will be supported anyway (sooner or
later) so I don't see a need for such a check. We have the build wiki
[1] with the officially and community supported build platforms. If
somebody builds on a newer platfrom it's at his own risk. We shouldn't
make it unnecessarily hard for people to build on other/newer
platfroms.

Regards,
Volker

[1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms

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