Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Kim Barrett]

> On Jun 24, 2020, at 7:01 AM, Magnus Ihse Bursie 
>  wrote:
> 
> On 2020-06-18 08:34, Kim Barrett wrote:
>>> On Jun 15, 2020, at 7:41 AM, Kim Barrett  wrote:
>>> 
 On Jun 14, 2020, at 12:45 AM, Philip Race  wrote:
 
 Kim,
 
 
 Until it says in "the JDK" and not "in HotSpot" you have not addressed my 
 main point.
 Please rename the JEP.
>> After some off-list discussions I have a better idea of what Phil was
>> asking for and why. In response I've changed the JEP, replacing a few
>> occurrences of "HotSpot" with "the JDK", as described below.  All
>> other occurrences of "HotSpot" have been left as-is.
>> 
>> Title:
>> JEP 347: Adopt C++14 Language Features in HotSpot
>> =>
>> JEP 347: Adopt C++14 Language Features in the JDK
>> 
>> Summary:
>> Allow the use of selected C++14 language features in the HotSpot C++ source 
>> code.
>> =>
>> Allow the use of selected C++14 language features in the JDK C++ source code.
>> 
>> Goals:
>> The purpose of this JEP is to formally allow C++ source code changes within 
>> HotSpot to take advantage of some C++14 standard language features.
>> =>
>> The purpose of this JEP is to formally allow C++ source code changes within 
>> the JDK to take advantage of some C++14 standard language features.
>> 
> This all looks good to me.
> 
> /Magnus

Thanks.

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Magnus Ihse Bursie]

On 2020-06-18 08:34, Kim Barrett wrote:

On Jun 15, 2020, at 7:41 AM, Kim Barrett  wrote:


On Jun 14, 2020, at 12:45 AM, Philip Race  wrote:

Kim,


Until it says in "the JDK" and not "in HotSpot" you have not addressed my main 
point.
Please rename the JEP.

After some off-list discussions I have a better idea of what Phil was
asking for and why. In response I've changed the JEP, replacing a few
occurrences of "HotSpot" with "the JDK", as described below.  All
other occurrences of "HotSpot" have been left as-is.

Title:
JEP 347: Adopt C++14 Language Features in HotSpot
=>
JEP 347: Adopt C++14 Language Features in the JDK

Summary:
Allow the use of selected C++14 language features in the HotSpot C++ source 
code.
=>
Allow the use of selected C++14 language features in the JDK C++ source code.

Goals:
The purpose of this JEP is to formally allow C++ source code changes within 
HotSpot to take advantage of some C++14 standard language features.
=>
The purpose of this JEP is to formally allow C++ source code changes within the 
JDK to take advantage of some C++14 standard language features.


This all looks good to me.

/Magnus

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Kim Barrett]

> On Jun 15, 2020, at 7:41 AM, Kim Barrett  wrote:
> 
>> On Jun 14, 2020, at 12:45 AM, Philip Race  wrote:
>> 
>> Kim,
>> 
>> 
>> Until it says in "the JDK" and not "in HotSpot" you have not addressed my 
>> main point.
>> Please rename the JEP.

After some off-list discussions I have a better idea of what Phil was
asking for and why. In response I've changed the JEP, replacing a few
occurrences of "HotSpot" with "the JDK", as described below.  All
other occurrences of "HotSpot" have been left as-is.

Title:
JEP 347: Adopt C++14 Language Features in HotSpot
=>
JEP 347: Adopt C++14 Language Features in the JDK

Summary:
Allow the use of selected C++14 language features in the HotSpot C++ source 
code.
=>
Allow the use of selected C++14 language features in the JDK C++ source code.

Goals:
The purpose of this JEP is to formally allow C++ source code changes within 
HotSpot to take advantage of some C++14 standard language features.
=>
The purpose of this JEP is to formally allow C++ source code changes within the 
JDK to take advantage of some C++14 standard language features.

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Kim Barrett]

> On Jun 14, 2020, at 12:45 AM, Philip Race  wrote:
> 
> Kim,
> 
> 
> Until it says in "the JDK" and not "in HotSpot" you have not addressed my 
> main point.
> Please rename the JEP.

I think this JEP is primarily about updating the HotSpot-specific
subset of C++ and usage guidance to include some C++14 features.
HotSpot usage is already different in some ways from C++ code in other
parts of the JDK.  For example, HotSpot code doesn't use global
operator new; that isn't likely to change, and non-HotSpot code
doesn't have access to the alternatives defined and used but not
exported by HotSpot.

As a necessary prerequisite for that, the JDK build system is being
updated to enable the use of C++14 features.  It's probably possible
to limit the scope of the language change to HotSpot, but that doesn't
seem useful.  It also probably wasn't possible while Solaris was still
in the mix.

It is expected that groups responsible for other parts of the JDK will
also want to take advantage of that build change, but I think it's up
to those other groups to decide on an adoption strategy.  I have no
reason to think the choices being suggested here as appropriate for
HotSpot are appropriate JDK-wide.

I can't say whether a JEP is generally needed; maybe it's simply
"C++14 - yes" in some areas.  Also, some of the reasons for this being
a JEP no longer apply.  For example, Solaris was going to require at
least a major ABI change, and at the time the JEP was created there
was no path to C++14 for the AIX/PPC port; both of those needed
visibility and discussion that seemed best provided via the JEP
process.

> -phil.
> 
> On 6/13/20, 8:48 PM, Kim Barrett wrote:
>>> On Jun 10, 2020, at 2:26 AM, Kim Barrett  wrote:
>>> 
 On Jun 8, 2020, at 4:07 PM, Philip Race  wrote:
 BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
> For Solaris: Add the -std=c++14 compiler option. .
 So I am sure there is still some room to update the JEP :-)
>>> Yeah, I have some updates to make.  I also need to do a bit of work on the 
>>> feature lists.
>> I think the JEP updates are done now.

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Philip Race]

Kim,


Until it says in "the JDK" and not "in HotSpot" you have not addressed 
my main point.

Please rename the JEP.

-phil.

On 6/13/20, 8:48 PM, Kim Barrett wrote:

On Jun 10, 2020, at 2:26 AM, Kim Barrett  wrote:


On Jun 8, 2020, at 4:07 PM, Philip Race  wrote:
BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says

For Solaris: Add the -std=c++14 compiler option. .

So I am sure there is still some room to update the JEP :-)

Yeah, I have some updates to make.  I also need to do a bit of work on the 
feature lists.

I think the JEP updates are done now.

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Kim Barrett]

> On Jun 10, 2020, at 2:26 AM, Kim Barrett  wrote:
> 
>> On Jun 8, 2020, at 4:07 PM, Philip Race  wrote:
> 
>> BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
>>> For Solaris: Add the -std=c++14 compiler option. .
>> 
>> So I am sure there is still some room to update the JEP :-)
> 
> Yeah, I have some updates to make.  I also need to do a bit of work on the 
> feature lists.

I think the JEP updates are done now.

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Kim Barrett]

> On Jun 8, 2020, at 4:07 PM, Philip Race  wrote:
> 
> Hi Kim,
> 
> Can we amend the JEP itself to be not solely about hotspot.
> Since it affects other areas I think that
> 1) They may need to be compiled with C++14 enabled whether they use new 
> features or not
> 2) They may want - or need - to adopt C++11 or C++14 features too.
> 
> You already know that soon we will upgrade the harfbuzz 3rd party library 
> used by 2D
> and it will bring along the need to use C++11 features and I had no plan to 
> propose a JEP for that.
> So I don't want to be asked why we didn't do one when hotspot did !
> So this really ought to be a JDK JEP whilst of course explaining that hotspot 
> is expected
> to be the primary adopter.

I think this is at least mostly covered by the following paragraph from the JEP:

(This JEP does not propose any usage or style changes for C++
code in the JDK that is outside of HotSpot.  The rules are already different
for HotSpot and non-HotSpot code.  For example, C++ exceptions are
used in some non-HotSpot code, but are disallowed in HotSpot by
build-time options.  However, build consistency requirements will make
the newer language features available for use in all C++ code in the JDK.)

That’s why I cc’d the RFR to several mailing lists in addition to hotspot-dev.

Is there something additional you would like to add?

> BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
> > For Solaris: Add the -std=c++14 compiler option. .
> 
> So I am sure there is still some room to update the JEP :-)

Yeah, I have some updates to make.  I also need to do a bit of work on the 
feature lists.

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Philip Race]

Hi Kim,

Can we amend the JEP itself to be not solely about hotspot.
Since it affects other areas I think that
1) They may need to be compiled with C++14 enabled whether they use new 
features or not

2) They may want - or need - to adopt C++11 or C++14 features too.

You already know that soon we will upgrade the harfbuzz 3rd party 
library used by 2D
and it will bring along the need to use C++11 features and I had no plan 
to propose a JEP for that.

So I don't want to be asked why we didn't do one when hotspot did !
So this really ought to be a JDK JEP whilst of course explaining that 
hotspot is expected

to be the primary adopter.

BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
> For Solaris: Add the |-std=c++14| compiler option. .

So I am sure there is still some room to update the JEP :-)

-phil.

On 6/5/20, 12:52 AM, Kim Barrett wrote:

[Changes are only to the build system, but since the changes have jdk-wide
effect I’ve cc’d what I think are the relevant dev lists.]

This change is part of JEP 347; the intent is to target JDK 16.

Please review this change to the building of C++ code in the JDK to
enable the use of C++14 language features.  This change does not make
any code changes to use new features provided by C++11 or C++14.

This requires trimming the supported compiler versions, moving the
minimum supported versions forward (significantly, in some cases).
The new minimums are based on compiler documentation rather than
testing.  It may be that more recent versions are actually required.

This change needs to be tested on platforms not supported by Oracle.
The JEP test plan includes additional Oracle testing beyond what I’ve done.

CR:
https://bugs.openjdk.java.net/browse/JDK-8246032

Webrev:
https://cr.openjdk.java.net/~kbarrett/8246032/open.02/

Testing:
mach5 tier1-5 on Oracle supported platforms.

Performance testing showed no significant changes in either direction.

Build-only (no tests) for linux-arm32, linux-s390x, linux-ppc64le

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Hendrik Schreiber]

Jim,

if there isn’t a dedicated bug report for this (meaning: lack of optimization 
for macOS), please do create one so that it at least is documented somewhere.

Thank you,

-hendrik

> On Jun 5, 2020, at 13:59, Jim Laskey  wrote:
> 
> I know there was a discussion about this elsewhere but I would like to take 
> the opportunity to correct this now
> 
> make//autoconf/flags-cflags.m4:241
> 
>   elif test "x$TOOLCHAIN_TYPE" = xclang; then
> if test "x$OPENJDK_TARGET_OS" = xmacosx; then
>   # On MacOSX we optimize for size, something
>   # we should do for all platforms?
>   C_O_FLAG_HIGHEST_JVM="-Os"
>   C_O_FLAG_HIGHEST="-Os"
>   C_O_FLAG_HI="-Os"
>   C_O_FLAG_NORM="-Os"
>   C_O_FLAG_DEBUG_JVM=""
> else
>   C_O_FLAG_HIGHEST_JVM="-O3"
>   C_O_FLAG_HIGHEST="-O3"
>   C_O_FLAG_HI="-O3"
>   C_O_FLAG_NORM="-O2"
>   C_O_FLAG_DEBUG_JVM="-O0"
> fi
> C_O_FLAG_SIZE="-Os"
> C_O_FLAG_DEBUG="-O0"
> C_O_FLAG_NONE="-O0"
>   elif test "x$TOOLCHAIN_TYPE" = xxlc; then
> 
> should be changed to 
> 
>   elif test "x$TOOLCHAIN_TYPE" = xclang; then
> C_O_FLAG_HIGHEST_JVM="-O3"
> C_O_FLAG_HIGHEST="-O3"
> C_O_FLAG_HI="-O3"
> C_O_FLAG_NORM="-O2"
> C_O_FLAG_DEBUG_JVM="-O0"
> C_O_FLAG_SIZE="-Os"
> C_O_FLAG_DEBUG="-O0"
> C_O_FLAG_NONE="-O0"
>   elif test "x$TOOLCHAIN_TYPE" = xxlc; then
> 
> MacOSX has been paying a historic and significant performance penalty for no 
> valid reason.
> 
> Otherwise +1.
> 
> Cheers,
> 
> -- Jim
> 
> 
> 
>> On Jun 5, 2020, at 4:52 AM, Kim Barrett > > wrote:
>> 
>> [Changes are only to the build system, but since the changes have jdk-wide
>> effect I’ve cc’d what I think are the relevant dev lists.]
>> 
>> This change is part of JEP 347; the intent is to target JDK 16.
>> 
>> Please review this change to the building of C++ code in the JDK to
>> enable the use of C++14 language features.  This change does not make
>> any code changes to use new features provided by C++11 or C++14.
>> 
>> This requires trimming the supported compiler versions, moving the
>> minimum supported versions forward (significantly, in some cases).
>> The new minimums are based on compiler documentation rather than
>> testing.  It may be that more recent versions are actually required.
>> 
>> This change needs to be tested on platforms not supported by Oracle.
>> The JEP test plan includes additional Oracle testing beyond what I’ve done.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8246032 
>> 
>> 
>> Webrev:
>> https://cr.openjdk.java.net/~kbarrett/8246032/open.02/
>> 
>> Testing:
>> mach5 tier1-5 on Oracle supported platforms.
>> 
>> Performance testing showed no significant changes in either direction.
>> 
>> Build-only (no tests) for linux-arm32, linux-s390x, linux-ppc64le
>> 
> 

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Jim Laskey]

Hendrik,

Yes, I will file one once I have some data. The benefits are not clear cut and 
I should annotate the request with validity. :-)

Cheers,

-- Jim



> On Jun 6, 2020, at 11:13 AM, Hendrik Schreiber  wrote:
> 
> Jim,
> 
> if there isn’t a dedicated bug report for this (meaning: lack of optimization 
> for macOS), please do create one so that it at least is documented somewhere.
> 
> Thank you,
> 
> -hendrik
> 
>> On Jun 5, 2020, at 13:59, Jim Laskey > > wrote:
>> 
>> I know there was a discussion about this elsewhere but I would like to take 
>> the opportunity to correct this now
>> 
>> make//autoconf/flags-cflags.m4:241
>> 
>>   elif test "x$TOOLCHAIN_TYPE" = xclang; then
>> if test "x$OPENJDK_TARGET_OS" = xmacosx; then
>>   # On MacOSX we optimize for size, something
>>   # we should do for all platforms?
>>   C_O_FLAG_HIGHEST_JVM="-Os"
>>   C_O_FLAG_HIGHEST="-Os"
>>   C_O_FLAG_HI="-Os"
>>   C_O_FLAG_NORM="-Os"
>>   C_O_FLAG_DEBUG_JVM=""
>> else
>>   C_O_FLAG_HIGHEST_JVM="-O3"
>>   C_O_FLAG_HIGHEST="-O3"
>>   C_O_FLAG_HI="-O3"
>>   C_O_FLAG_NORM="-O2"
>>   C_O_FLAG_DEBUG_JVM="-O0"
>> fi
>> C_O_FLAG_SIZE="-Os"
>> C_O_FLAG_DEBUG="-O0"
>> C_O_FLAG_NONE="-O0"
>>   elif test "x$TOOLCHAIN_TYPE" = xxlc; then
>> 
>> should be changed to 
>> 
>>   elif test "x$TOOLCHAIN_TYPE" = xclang; then
>> C_O_FLAG_HIGHEST_JVM="-O3"
>> C_O_FLAG_HIGHEST="-O3"
>> C_O_FLAG_HI="-O3"
>> C_O_FLAG_NORM="-O2"
>> C_O_FLAG_DEBUG_JVM="-O0"
>> C_O_FLAG_SIZE="-Os"
>> C_O_FLAG_DEBUG="-O0"
>> C_O_FLAG_NONE="-O0"
>>   elif test "x$TOOLCHAIN_TYPE" = xxlc; then
>> 
>> MacOSX has been paying a historic and significant performance penalty for no 
>> valid reason.
>> 
>> Otherwise +1.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> 
>> 
>>> On Jun 5, 2020, at 4:52 AM, Kim Barrett >> > wrote:
>>> 
>>> [Changes are only to the build system, but since the changes have jdk-wide
>>> effect I’ve cc’d what I think are the relevant dev lists.]
>>> 
>>> This change is part of JEP 347; the intent is to target JDK 16.
>>> 
>>> Please review this change to the building of C++ code in the JDK to
>>> enable the use of C++14 language features.  This change does not make
>>> any code changes to use new features provided by C++11 or C++14.
>>> 
>>> This requires trimming the supported compiler versions, moving the
>>> minimum supported versions forward (significantly, in some cases).
>>> The new minimums are based on compiler documentation rather than
>>> testing.  It may be that more recent versions are actually required.
>>> 
>>> This change needs to be tested on platforms not supported by Oracle.
>>> The JEP test plan includes additional Oracle testing beyond what I’ve done.
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8246032 
>>> 
>>> 
>>> Webrev:
>>> https://cr.openjdk.java.net/~kbarrett/8246032/open.02/ 
>>> 
>>> 
>>> Testing:
>>> mach5 tier1-5 on Oracle supported platforms.
>>> 
>>> Performance testing showed no significant changes in either direction.
>>> 
>>> Build-only (no tests) for linux-arm32, linux-s390x, linux-ppc64le
>>> 
>> 
>