C++11/C++14 support in XLC ?

[Kim Barrett]

> On Jul 19, 2017, at 9:06 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Wed, Jul 19, 2017 at 1:56 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> We're planning another round of compiler upgrades and platform
>> refreshes for the JDK support by Oracle. 
> 
> ..first of all, adding build-dev because that seems to be the most
> appropriate list for such discussions.

Seems as good as any for now.  hotspot-dev might be an alternative, though
there’s C++ code elsewhere in the jdk.

> For new OpenJDK releases, upgrading the minimal required platforms and
> compilers is natural and per se OK.
> 
> Requiring new C++ language features is a much more heavyweight change
> and needs careful reasoning and discussion:
> 
> - OpenJDK is not a "pure" open source project. It is also available as
> a commercial version which Oracle licenses to various customers
> (including SAP). These customers support more/different platforms than
> the ones available in the OpenJDK (i.e. we also support HPUX with
> aCC).

A compiler I'd forgotten about.

> That said, this is an OpenJDK mailing list and I won't go into
> more details here. Such issues should be addressed trough the
> corresponding license engineering channels. I just wanted to point out
> that (unfortunately) such a discussion probably won't happen
> completely in the open.
> 
> - I suppose the requirement for C++ 14 is planned only for jdk10 and
> beyond  and not for jdk8/jdk9, right? It should be clear however, that
> once we start using these new C++ features, downports of
> fixes/features will become increasingly hard. And not only if the
> fixes/feature uses the new C++ 14 features, but also if they
> indirectly rely on them. The exact amount of these costs depends on
> how many fixes/features will be downported in the future. If we really
> come to a more frequent release model (as discussed in other threads),
> this may be not that much of a problem.

I don't think there's any intent to backport such a change.  I don't
think there's a specific jdk version being targeted yet either; this
is all still in a preliminary discussion phase.  The possibility of a
more frequent release model is one of the considerations.  There is
also a substantial amount of work to be done to get to that point;
there's some problematic code in Hotspot :)

> - Related to the previous topic, I suppose you don't plan to upgrade
> the compiler requirements for already released versions of OpenJDK. Is
> this correct?

So far as I know, that's correct.  

> - SAP is currently maintaining the AIX port in the OpenJDK and we're
> willing to do that in the future. But we're not IBM and we can not
> decide about the XLC feature list. If Oracle and the OpenJDK community
> finally decide to use C++11/14 features which are not available in XLC
> we have to live with that. We can either escalate the XLC deficiencies
> to IBM and suspend the port until the compiler gets fixed. Or we can
> switch the port to use the GCC tool chain with all the pros (bigger
> compatibility with Linux platforms) and cons (porting effort, testing,
> compatibility with other AIX software compiled with XLC, compiler
> support). While the GCC alternative sounds very appealing at a first
> glance it really isn't that perfect in reality, especially not for our
> commercial SAP JVM version of OpenJDK. One problem is the fact that
> there's no official support for GCC on AIX, the other is
> compatibility. Just think you had to replace Solaris Studio by GCC on
> Solaris :)
> 
> @Tim, Jeff: could you pleas escalate this issue to XLC product
> management and get back to us with the outcome?
> 
> Finally, I'm not sure what would be the right format to discuss this
> issue (maybe a JEP, maybe an enhancement request in JBS, maybe just a
> mail thread) and how to proceed?

Right now I think email discussion like we're doing here makes sense.
More formality will be needed eventually, but doesn't seem helpful
yet.

> Pragmatically, we could already now
> start to add code which uses new C++ features as long as it is
> supported on ALL current OpenJDK platforms (and in fact we are already
> doing this as the recent "type_traits metaprogramming" change 8183927
> has demonstrated).

I wouldn't describe 8183927 as using new C++ features.  There's
nothing there that hasn't existed in other C++98 code bases for a long
time.  C++11 simply codified some existing practice in that area
(specifically Boost.TypeTraits).  C++11 also includes a number of type
traits that are at least hard, if not impossible, to implement in a
portable fashion in C++98.  So far we haven't required any of those...

> Ideally, we would come up with a fixed set of
> required features to avoid compatibility discussions for every single
> change.

I've seen this tried, and it can be pretty hard.  For example, Boost
has a long list of configuration macros for various C++98/11/14
features; that list is both interesting and daunting.  (I don't
propose we do anything similar and have multiple implementations based
on supported language features.  We already have way more than enough
of that kind of thing because of multiple platforms.)