From zuismanm at gmail.com  Sun Jun  2 20:20:00 2019
From: zuismanm at gmail.com (Moshe Zuisman)
Date: Sun, 2 Jun 2019 23:20:00 +0300
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
Message-ID: <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>

Hi David.
I have updated to Visual studio 2017 15.9.12.
Build still fails, while now works much longer and pass much more steps:




























































*$ makeBuilding target 'default (exploded-image)' in configuration
'windows-x86_64-normal-server-release'Compiling 8 files for
BUILD_TOOLS_LANGTOOLSCreating hotspot/variant-server/tools/adlc/adlc.exe
from 13 file(s)Compiling 2 files for BUILD_JVMTI_TOOLSCompiling 1 files for
BUILD_JFR_TOOLSCompiling 12 properties into resource bundles for
jdk.jdepsCompiling 7 properties into resource bundles for
jdk.jshellWarning: No mercurial configuration present and no
.src-revParsing 2 properties into enum-like class for jdk.compilerCompiling
13 properties into resource bundles for jdk.javadocCompiling 19 properties
into resource bundles for jdk.compilerCompiling 117 files for
BUILD_java.compiler.interimCompiling 394 files for
BUILD_jdk.compiler.interimCreating
support/modules_libs/java.base/server/jvm.dll from 855 file(s)Creating
hotspot/variant-server/libjvm/gtest/jvm.dll from 91 file(s)Creating
hotspot/variant-server/libjvm/gtest/gtestLauncher.exe from 1
file(s)Compiling 299 files for BUILD_jdk.javadoc.interimCompiling 162 files
for BUILD_TOOLS_JDKSjavac server failed to initialize: No port file values
materialized. Giving up after 60369 msProcess output:<End of process
output>Process exit code: 0IOException caught during compilation: Server
failed to initialize: No port file values materialized. Giving up after
60369 msmake[3]: *** [CompileToolsJdk.gmk:48:
/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/buildtoo/jdk_tools_classes/_the.BUILD_TOOLS_JDK_batch]
Error 1make[2]: *** [make/Main.gmk:85: buildtools-jdk] Error 2make[2]: ***
Waiting for unfinished jobs....Compiling 188 files for
BUILD_jdk.rmic.interimNote: Some input files use or override a deprecated
API.Note: Recompile with -Xlint:deprecation for
details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
error C2220: warning treated as error -o 'object' file
generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
warning C4305: 'argument': truncation fm 'const intx' to 'double'make[3]:
*** [lib/CompileJvm.gmk:151:
/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
Error 1make[3]: *** Waiting for unfinished jobs....make[2]: ***
[make/Main.gmk:257: hotspot-server-libs] Error 2ERROR: Build failed for
target 'default (exploded-image)' in configuration
'windows-x86_64-normal-server-release' (exit code 2)=== Output from failing
command(s) repeated here ===* For target
buildtools_jdk_tools_classes__the.BUILD_TOOLS_JDK_batch:Sjavac server
failed to initialize: No port file values materialized. Giving up after
60369 msProcess output:<End of process output>Process exit code:
0IOException caught during compilation: Server failed to initialize: No
port file values materialized. Giving up after 60369 ms* For target
hotspot_variant-server_libjvm_objs_jvmFlagRangeList.obj:jvmFlagRangeList.cppc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
error C2220: warning treated as error -o 'object' file
generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
warning C4305: 'argument': truncation fm 'const intx' to 'double'   ...
(rest of output omitted)* All command lines available in
/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/make-support/ilure-logs.===
End of repeated output ===No indication of failed target found.Hint: Try
searching the build log for '] Error'.Hint: See
doc/building.html#troubleshooting for assistance.make[1]: ***
[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305:
main] Error 2make: ***
[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186:
default] Error 2*

??, 31 ??? 2019 ?. ? 08:47, David Holmes <david.holmes at oracle.com>:

> Hi Moshe,
>
> Can you update your VS 2017 installation? The only difference I can spot
> is that we are using
>
> Microsoft Visual Studio 2017 15.9.6
>
> with
>
> Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1
>
> while you have:
>
> Visual Studio 2017 Developer Command Prompt v15.0.26228.86
>
> with
>
> [Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25027
>
> David
> -----
>
> On 31/05/2019 1:55 am, Moshe Zuisman wrote:
> > Hi David. I have done it. with same result.
> > I have added --debug-configure flag.. Attaching full configure output..
> >
> > I am stuck with this issue and right now - have no idea - how to get out
> > of this "blind alley"...
> >
> > ??, 30 ??? 2019 ?. ? 12:46, David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>>:
> >
> >     Hi Moshe,
> >
> >     can you try running configure with --disable-precompiled-headers
> >
> >     Thanks,
> >     David
> >
> >     On 30/05/2019 6:26 pm, Moshe Zuisman wrote:
> >      > Configuration summary:
> >      > ====================================================
> >      > The existing configuration has been successfully updated in
> >      >
> >
>  /cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release
> >      > using configure arguments
> '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'.
> >      >
> >      > Configuration summary:
> >      > * Debug level:    release
> >      > * HS debug level: product
> >      > * JVM variants:   server
> >      > * JVM features:   server: 'aot cds cmsgc compiler1 compiler2
> >     epsilongc
> >      > g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc
> >     serialgc
> >      > services vm-structs'
> >      > * OpenJDK target: OS: windows, CPU architecture: x86, address
> >     length: 64
> >      > * Version string:
> 11-internal+0-adhoc.ADPRODcuser.jdk11-1ddf9a99e4ad
> >      > (11-internal)
> >      >
> >      > Tools summary:
> >      > * Environment:    cygwin version 3.0.7(0.338/5/3) (root at
> >      > /cygdrive/c/cygwin64)
> >      > * Boot JDK:       java version "11.0.3" 2019-04-16 LTS  Java(TM)
> SE
> >      > Runtime Environment 18.9 (build 11.0.3+12-LTS)  Java HotSpot(TM)
> >     64-Bit
> >      > Server VM 18.9 (build 11.0.3+12-LTS, mixed mode)   (at
> >      > /cygdrive/c/jdk-11.0.3)
> >      > * Toolchain:      microsoft (Microsoft Visual Studio 2017)
> >      > * C Compiler:     Version 19.10.25027 (at
> >      >
> >
>  /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl)
> >      > * C++ Compiler:   Version 19.10.25027 (at
> >      >
> >
>  /cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl)
> >      >
> >      > Build performance summary:
> >      > * Cores to use:   2
> >      > * Memory limit:   8191 MB
> >      >
> >      > WARNING: The result of this configuration has overridden an older
> >      > configuration. You *should* run 'make clean' to make sure you get
> a
> >      > proper build. Failure to do so might result in strange build
> >     problems.
> >      >
> >      > ??, 30 ??? 2019 ?. ? 00:58, David Holmes <david.holmes at oracle.com
> >     <mailto:david.holmes at oracle.com>
> >      > <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com
> >>>:
> >      >
> >      >     Can you provide the configuration summary produced by
> configure?
> >      >
> >      >     It's an issue with precompiled headers but I've no idea what.
> >      >
> >      >     David
> >      >
> >      >     On 30/05/2019 5:21 am, Moshe Zuisman wrote:
> >      >      > I  thought, that may be probleem ressults form some
> specific
> >      >      > configuration on my  machine (for example I have 2 version
> of
> >      >     MSVCc -
> >      >      > 2012 and 2017.
> >      >      > So I created clean VmWare Virtual machine and installed
> their
> >      >     only MSVC
> >      >      > 2017 and cygwin. And tried to build OPEN JDK theeir. and
> >     got exactly
> >      >      > same  failure.
> >      >      >
> >      >      > ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman
> >     <zuismanm at gmail.com <mailto:zuismanm at gmail.com>
> >      >     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>
> >      >      > <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>
> >     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>>>:
> >      >      >
> >      >      >     I am using
> >      >      >
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
> >      >      >
> >       <http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281>
> >      >      >
> >      >      >
> >      >      >     ??, 29 ??? 2019 ?. ? 08:35, David Holmes
> >      >     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
> >     <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
> >      >      >     <mailto:david.holmes at oracle.com
> >     <mailto:david.holmes at oracle.com>
> >      >     <mailto:david.holmes at oracle.com
> >     <mailto:david.holmes at oracle.com>>>>:
> >      >      >
> >      >      >         Hi Moshe,
> >      >      >
> >      >      >         On 29/05/2019 2:15 am, Moshe Zuisman wrote:
> >      >      >          > I am trying to build OPEN jdk 11 on cygwin with
> >     MSVC 2017
> >      >      >          >
> >      >      >
> >      >
> >
>  _________________________________________________________________________
> >      >      >
> >      >      >         VS 2017 is the official supported compiler for
> >     building
> >      >     OpenJDK
> >      >      >         11 [1]
> >      >      >         and we don't see any issues. What version of the
> 11u
> >      >     source are you
> >      >      >         trying to compile?
> >      >      >
> >      >      >         David
> >      >      >
> >      >      >         [1]
> >      >      >
> >
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> >      >      >
> >      >      >          >
> >      >      >          >
> >      >      >
> >      >
> >
>  *c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366):
> >      >      >          > warning C4577: 'noexcept' used with no
> >     exception handling
> >      >      >         mode specified;
> >      >      >          > termination on exception is not guaranteed.
> Specify
> >      >      >         /EHscmake[3]: ***
> >      >      >          > [lib/CompileJvm.gmk:151:
> >      >      >          >
> >      >      >
> >      >
> >
>  /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj]
> >      >      >          > Error 1make[3]: *** Waiting for unfinished
> >      >     jobs....make[2]: ***
> >      >      >          > [make/Main.gmk:257: hotspot-server-libs] Error
> >      >     2make[2]: ***
> >      >      >         Waiting for
> >      >      >          > unfinished jobs....ERROR: Build failed for
> >     target 'default
> >      >      >          > (exploded-image)' in configuration
> >      >      >         'windows-x86_64-normal-server-release'
> >      >      >          > (exit code 2)=== Output from failing command(s)
> >      >     repeated here
> >      >      >         ===* For
> >      >      >          > target
> >      >      >          >
> >      >      >
> >      >
> >
>  hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366):
> >      >      >          > error C2220: warning treated as error - no
> >     'object' file
> >      >      >          >
> >      >      >
> >      >
> >
>  generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366):
> >      >      >          > warning C4577: 'noexcept' used with no
> >     exception handling
> >      >      >         mode specified;
> >      >      >          > termination on exception is not guaranteed.
> >     Specify /EHsc
> >      >      >           ... (rest of
> >      >      >          > output omitted)* All command lines available in
> >      >      >          >
> >      >      >
> >      >
> >
>  /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/make-support/failure-logs.===
> >      >      >          > End of repeated output ===No indication of
> >     failed target
> >      >      >         found.Hint: Try
> >      >      >          > searching the build log for '] Error'.Hint: See
> >      >      >          > doc/building.html#troubleshooting for
> >      >     assistance.make[1]: ***
> >      >      >          >
> >      >      >
> >      >
> >
>  [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305:
> >      >      >          > main] Error 2make: ***
> >      >      >          >
> >      >      >
> >      >
> >
>  [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186:
> >      >      >          > default] Error 2*
> >      >      >          >
> >      >      >
> >      >
> >
>


From kim.barrett at oracle.com  Sun Jun  2 21:34:11 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 2 Jun 2019 17:34:11 -0400
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
Message-ID: <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>

> On Jun 2, 2019, at 4:20 PM, Moshe Zuisman <zuismanm at gmail.com> wrote:
> 
> Hi David.
> I have updated to Visual studio 2017 15.9.12.
> Build still fails, while now works much longer and pass much more steps:
> 
> details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> error C2220: warning treated as error -o 'object' file
> generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> warning C4305: 'argument': truncation fm 'const intx' to 'double'make[3]:
> *** [lib/CompileJvm.gmk:151:
> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
> Error 1make[3]: *** Waiting for unfinished jobs....make[2]: ***

This looks like JDK-8212052, which is marked as fixed in JDK 11.0.2.




From david.holmes at oracle.com  Mon Jun  3 06:47:11 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 3 Jun 2019 16:47:11 +1000
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
Message-ID: <8aebd453-7f98-4d9e-9a98-7ba056e768ce@oracle.com>

On 3/06/2019 6:20 am, Moshe Zuisman wrote:
> Hi David.
> I have updated to Visual studio 2017 15.9.12.
> Build still fails, while now works much longer and pass much more steps:
> 
> /$ make
> Building target 'default (exploded-image)' in configuration 
> 'windows-x86_64-normal-server-release'
> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s)
> Compiling 2 files for BUILD_JVMTI_TOOLS
> Compiling 1 files for BUILD_JFR_TOOLS
> Compiling 12 properties into resource bundles for jdk.jdeps
> Compiling 7 properties into resource bundles for jdk.jshell
> Warning: No mercurial configuration present and no .src-rev

Not sure how significant that is.

> Parsing 2 properties into enum-like class for jdk.compiler
> Compiling 13 properties into resource bundles for jdk.javadoc
> Compiling 19 properties into resource bundles for jdk.compiler
> Compiling 117 files for BUILD_java.compiler.interim
> Compiling 394 files for BUILD_jdk.compiler.interim
> Creating support/modules_libs/java.base/server/jvm.dll from 855 file(s)
> Creating hotspot/variant-server/libjvm/gtest/jvm.dll from 91 file(s)
> Creating hotspot/variant-server/libjvm/gtest/gtestLauncher.exe from 1 
> file(s)
> Compiling 299 files for BUILD_jdk.javadoc.interim
> Compiling 162 files for BUILD_TOOLS_JDK
> Sjavac server failed to initialize: No port file values materialized. 
> Giving up after 60369 ms

Sorry I have no idea how sjavac is initialized or why it might fail to 
initialize. Hopefully Erik or Tim can chime in.

> Process output:
> <End of process output>
> Process exit code: 0
> IOException caught during compilation: Server failed to initialize: No 
> port file values materialized. Giving up after 60369 ms
> make[3]: *** [CompileToolsJdk.gmk:48: 
> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/buildtoo/jdk_tools_classes/_the.BUILD_TOOLS_JDK_batch] 
> Error 1
> make[2]: *** [make/Main.gmk:85: buildtools-jdk] Error 2
> make[2]: *** Waiting for unfinished jobs....
> Compiling 188 files for BUILD_jdk.rmic.interim
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
> error C2220: warning treated as error -o 'object' file generated
> c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
> warning C4305: 'argument': truncation fm 'const intx' to 'double'
> make[3]: *** [lib/CompileJvm.gmk:151: 
> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj] 

As Kim stated this issue should be fixed already, but I can't readily 
tell whether the version you are using contains the fix.

David
-----

> Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2
> 
> ERROR: Build failed for target 'default (exploded-image)' in 
> configuration 'windows-x86_64-normal-server-release' (exit code 2)
> 
> === Output from failing command(s) repeated here ===
> * For target buildtools_jdk_tools_classes__the.BUILD_TOOLS_JDK_batch:
> Sjavac server failed to initialize: No port file values materialized. 
> Giving up after 60369 ms
> Process output:
> <End of process output>
> Process exit code: 0
> IOException caught during compilation: Server failed to initialize: No 
> port file values materialized. Giving up after 60369 ms
> * For target hotspot_variant-server_libjvm_objs_jvmFlagRangeList.obj:
> jvmFlagRangeList.cpp
> c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
> error C2220: warning treated as error -o 'object' file generated
> c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): 
> warning C4305: 'argument': truncation fm 'const intx' to 'double'
>  ? ?... (rest of output omitted)
> 
> * All command lines available in 
> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/make-support/ilure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> Hint: Try searching the build log for '] Error'.
> Hint: See doc/building.html#troubleshooting for assistance.
> 
> make[1]: *** 
> [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305: 
> main] Error 2
> make: *** 
> [/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186: 
> default] Error 2/
> 
> ??, 31 ??? 2019 ?. ? 08:47, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>>:
> 
>     Hi Moshe,
> 
>     Can you update your VS 2017 installation? The only difference I can
>     spot
>     is that we are using
> 
>     Microsoft Visual Studio 2017 15.9.6
> 
>     with
> 
>     Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27026.1
> 
>     while you have:
> 
>     Visual Studio 2017 Developer Command Prompt v15.0.26228.86
> 
>     with
> 
>     [Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25027
> 
>     David
>     -----
> 
>     On 31/05/2019 1:55 am, Moshe Zuisman wrote:
>      > Hi David. I have done it. with same result.
>      > I have added?--debug-configure flag.. Attaching full configure
>     output..
>      >
>      > I am stuck with this issue and right now - have no idea - how to
>     get out
>      > of this "blind alley"...
>      >
>      > ??, 30 ??? 2019 ?. ? 12:46, David Holmes <david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>
>      > <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>>:
>      >
>      >? ? ?Hi Moshe,
>      >
>      >? ? ?can you try running configure with --disable-precompiled-headers
>      >
>      >? ? ?Thanks,
>      >? ? ?David
>      >
>      >? ? ?On 30/05/2019 6:26 pm, Moshe Zuisman wrote:
>      >? ? ? > Configuration summary:
>      >? ? ? > ====================================================
>      >? ? ? > The existing configuration has been successfully updated in
>      >? ? ? >
>      >   
>      ?/cygdrive/c/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release
>      >? ? ? > using configure arguments
>     '--with-boot-jdk=/cygdrive/c/jdk-11.0.3'.
>      >? ? ? >
>      >? ? ? > Configuration summary:
>      >? ? ? > * Debug level: ? ?release
>      >? ? ? > * HS debug level: product
>      >? ? ? > * JVM variants: ? server
>      >? ? ? > * JVM features: ? server: 'aot cds cmsgc compiler1 compiler2
>      >? ? ?epsilongc
>      >? ? ? > g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc
>      >? ? ?serialgc
>      >? ? ? > services vm-structs'
>      >? ? ? > * OpenJDK target: OS: windows, CPU architecture: x86, address
>      >? ? ?length: 64
>      >? ? ? > * Version string:
>     11-internal+0-adhoc.ADPRODcuser.jdk11-1ddf9a99e4ad
>      >? ? ? > (11-internal)
>      >? ? ? >
>      >? ? ? > Tools summary:
>      >? ? ? > * Environment: ? ?cygwin version 3.0.7(0.338/5/3) (root at
>      >? ? ? > /cygdrive/c/cygwin64)
>      >? ? ? > * Boot JDK: ? ? ? java version "11.0.3" 2019-04-16 LTS
>      ?Java(TM) SE
>      >? ? ? > Runtime Environment 18.9 (build 11.0.3+12-LTS) ?Java
>     HotSpot(TM)
>      >? ? ?64-Bit
>      >? ? ? > Server VM 18.9 (build 11.0.3+12-LTS, mixed mode) ? (at
>      >? ? ? > /cygdrive/c/jdk-11.0.3)
>      >? ? ? > * Toolchain: ? ? ?microsoft (Microsoft Visual Studio 2017)
>      >? ? ? > * C Compiler: ? ? Version 19.10.25027 (at
>      >? ? ? >
>      >   
>      ?/cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl)
>      >? ? ? > * C++ Compiler: ? Version 19.10.25027 (at
>      >? ? ? >
>      >   
>      ?/cygdrive/c/progra~2/mib055~1/2017/profes~1/vc/tools/msvc/1410~1.250/bin/hostx86/x64/cl)
>      >? ? ? >
>      >? ? ? > Build performance summary:
>      >? ? ? > * Cores to use: ? 2
>      >? ? ? > * Memory limit: ? 8191 MB
>      >? ? ? >
>      >? ? ? > WARNING: The result of this configuration has overridden
>     an older
>      >? ? ? > configuration. You *should* run 'make clean' to make sure
>     you get a
>      >? ? ? > proper build. Failure to do so might result in strange build
>      >? ? ?problems.
>      >? ? ? >
>      >? ? ? > ??, 30 ??? 2019 ?. ? 00:58, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>      >? ? ?<mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
>      >? ? ? > <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>>>:
>      >? ? ? >
>      >? ? ? >? ? ?Can you provide the configuration summary produced by
>     configure?
>      >? ? ? >
>      >? ? ? >? ? ?It's an issue with precompiled headers but I've no
>     idea what.
>      >? ? ? >
>      >? ? ? >? ? ?David
>      >? ? ? >
>      >? ? ? >? ? ?On 30/05/2019 5:21 am, Moshe Zuisman wrote:
>      >? ? ? >? ? ? > I? thought, that may be probleem ressults form some
>     specific
>      >? ? ? >? ? ? > configuration on my? machine (for example I have 2
>     version of
>      >? ? ? >? ? ?MSVCc -
>      >? ? ? >? ? ? > 2012 and 2017.
>      >? ? ? >? ? ? > So I created clean VmWare Virtual machine and
>     installed their
>      >? ? ? >? ? ?only MSVC
>      >? ? ? >? ? ? > 2017 and cygwin. And tried to build OPEN JDK
>     theeir. and
>      >? ? ?got exactly
>      >? ? ? >? ? ? > same? failure.
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > ??, 29 ??? 2019 ?. ? 09:40, Moshe Zuisman
>      >? ? ?<zuismanm at gmail.com <mailto:zuismanm at gmail.com>
>     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>
>      >? ? ? >? ? ?<mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>
>     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>>
>      >? ? ? >? ? ? > <mailto:zuismanm at gmail.com
>     <mailto:zuismanm at gmail.com> <mailto:zuismanm at gmail.com
>     <mailto:zuismanm at gmail.com>>
>      >? ? ?<mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>
>     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>>>>:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ?I am using
>      >? ? ? >? ? ? >
>     http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
>      >? ? ? >? ? ? >
>      >     
>      ?<http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281>
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ???, 29 ??? 2019 ?. ? 08:35, David Holmes
>      >? ? ? >? ? ?<david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>
>      >? ? ?<mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com> <mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>>
>      >? ? ? >? ? ? >? ? ?<mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>
>      >? ? ?<mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
>      >? ? ? >? ? ?<mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>
>      >? ? ?<mailto:david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>>>>>:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ?Hi Moshe,
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ?On 29/05/2019 2:15 am, Moshe Zuisman wrote:
>      >? ? ? >? ? ? >? ? ? ? ? > I am trying to build OPEN jdk 11 on
>     cygwin with
>      >? ? ?MSVC 2017
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?_________________________________________________________________________
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ?VS 2017 is the official supported compiler for
>      >? ? ?building
>      >? ? ? >? ? ?OpenJDK
>      >? ? ? >? ? ? >? ? ? ? ?11 [1]
>      >? ? ? >? ? ? >? ? ? ? ?and we don't see any issues. What version
>     of the 11u
>      >? ? ? >? ? ?source are you
>      >? ? ? >? ? ? >? ? ? ? ?trying to compile?
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ?David
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ?[1]
>      >? ? ? >? ? ? >
>      > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?*c:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366):
>      >? ? ? >? ? ? >? ? ? ? ? > warning C4577: 'noexcept' used with no
>      >? ? ?exception handling
>      >? ? ? >? ? ? >? ? ? ? ?mode specified;
>      >? ? ? >? ? ? >? ? ? ? ? > termination on exception is not
>     guaranteed. Specify
>      >? ? ? >? ? ? >? ? ? ? ?/EHscmake[3]: ***
>      >? ? ? >? ? ? >? ? ? ? ? > [lib/CompileJvm.gmk:151:
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/objs/BUILD_LIBJVM_pch.obj]
>      >? ? ? >? ? ? >? ? ? ? ? > Error 1make[3]: *** Waiting for unfinished
>      >? ? ? >? ? ?jobs....make[2]: ***
>      >? ? ? >? ? ? >? ? ? ? ? > [make/Main.gmk:257: hotspot-server-libs]
>     Error
>      >? ? ? >? ? ?2make[2]: ***
>      >? ? ? >? ? ? >? ? ? ? ?Waiting for
>      >? ? ? >? ? ? >? ? ? ? ? > unfinished jobs....ERROR: Build failed for
>      >? ? ?target 'default
>      >? ? ? >? ? ? >? ? ? ? ? > (exploded-image)' in configuration
>      >? ? ? >? ? ? >? ? ? ? ?'windows-x86_64-normal-server-release'
>      >? ? ? >? ? ? >? ? ? ? ? > (exit code 2)=== Output from failing
>     command(s)
>      >? ? ? >? ? ?repeated here
>      >? ? ? >? ? ? >? ? ? ? ?===* For
>      >? ? ? >? ? ? >? ? ? ? ? > target
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_pch.obj:BUILD_LIBJVM_pch.cppc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366):
>      >? ? ? >? ? ? >? ? ? ? ? > error C2220: warning treated as error - no
>      >? ? ?'object' file
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?generatedc:\progra~2\mib055~1\2017\profes~1\vc\tools\msvc\1410~1.250\include\exception(366):
>      >? ? ? >? ? ? >? ? ? ? ? > warning C4577: 'noexcept' used with no
>      >? ? ?exception handling
>      >? ? ? >? ? ? >? ? ? ? ?mode specified;
>      >? ? ? >? ? ? >? ? ? ? ? > termination on exception is not guaranteed.
>      >? ? ?Specify /EHsc
>      >? ? ? >? ? ? >? ? ? ? ? ?... (rest of
>      >? ? ? >? ? ? >? ? ? ? ? > output omitted)* All command lines
>     available in
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/make-support/failure-logs.===
>      >? ? ? >? ? ? >? ? ? ? ? > End of repeated output ===No indication of
>      >? ? ?failed target
>      >? ? ? >? ? ? >? ? ? ? ?found.Hint: Try
>      >? ? ? >? ? ? >? ? ? ? ? > searching the build log for ']
>     Error'.Hint: See
>      >? ? ? >? ? ? >? ? ? ? ? > doc/building.html#troubleshooting for
>      >? ? ? >? ? ?assistance.make[1]: ***
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:305:
>      >? ? ? >? ? ? >? ? ? ? ? > main] Error 2make: ***
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?[/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/make/Init.gmk:186:
>      >? ? ? >? ? ? >? ? ? ? ? > default] Error 2*
>      >? ? ? >? ? ? >? ? ? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >
> 

From nick.gasson at arm.com  Mon Jun  3 06:58:39 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 3 Jun 2019 14:58:39 +0800
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
Message-ID: <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>

Hi Kim,

> If I'm reading the gcc documentation for __sync_add_and_fetch
> correctly, I think the following (completely untested) should work,
> and won't cause Andrew to (I think rightly) complain about
> type-punning reinterpret_casts.
>
> Though I wonder if this is a clang bug. (See below.)
>
> template<size_t byte_size>
> struct Atomic::PlatformAdd
>   : Atomic::AddAndFetch<Atomic::PlatformAdd<byte_size> >
> {
>   template<typename I, typename D>
>   D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const {
>     // Cast to work around clang pointer arithmetic bug.
>     return PrimitiveConversions::cast<D>(__sync_add_and_fetch(dest, add_value));
>   }
> }

This fails with:

/home/nicgas01/jdk/src/hotspot/share/metaprogramming/primitiveConversions.hpp:162:10: error: invalid use of incomplete type 'struct PrimitiveConversions::Cast<char*, char*, true, void>'
   return Cast<T, U>()(x);
          ^~~~~~~~~~~~

I think because all the specialisations of PrimitiveConversions are only
enabled if T is an integral type and here it's char*?

>
> The key bit from the documentation is "Operations on pointer arguments
> are performed as if the operands were of the uintptr_t type."
>
> The bug description says this warning only arises with clang.  It
> seems like clang is overdoing that as-if, and treating it literally as
> uintptr_t all the way through to the result type.
>

I think Clang is actually complaining about the argument types
mismatching here. According to the GCC docs the __sync_add_and_fetch
prototype looks like:

type __sync_add_and_fetch (type *ptr, type value, ...)

I guess Clang infers type=char* from the first argument, and complains
that the second argument is unsigned long. So Clang gives an error for
the following but GCC accepts it:

  char *ptr;
  unsigned long val;
  __sync_add_and_fetch(&ptr, val);

Another way round this is to use __atomic_add_fetch instead which both
Clang and GCC accept:

  template<typename I, typename D>
  D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const {
    D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE);
    FULL_MEM_BARRIER;
    return res;
  }

> Or don't change the code at all here, and say that clang is not (currently) a supported
> compiler for this platform.

Yes, that's an option too :-). But we should change the configure script
to give an error on --with-toolchain-type=clang on AArch64.

Thanks,
Nick


From zuismanm at gmail.com  Mon Jun  3 07:06:18 2019
From: zuismanm at gmail.com (Moshe Zuisman)
Date: Mon, 3 Jun 2019 10:06:18 +0300
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
Message-ID: <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>

Hi.
Probably I do not understand something in source control system of Open JDK
projeck.
I have gone to :
https://hg.openjdk.java.net/jdk/jdk11
and clicked last label:
"9 months ago jwilhelm Added tag jdk-11+28 for changeset
76072a077ee1default tip"
arrived to:
https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
and downloaded zip with sources.

How have I to download latest fixed source of JDK 11.0.2?


??, 3 ???. 2019 ?. ? 00:34, Kim Barrett <kim.barrett at oracle.com>:

> > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman <zuismanm at gmail.com> wrote:
> >
> > Hi David.
> > I have updated to Visual studio 2017 15.9.12.
> > Build still fails, while now works much longer and pass much more steps:
> >
> >
> details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> > error C2220: warning treated as error -o 'object' file
> >
> generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> > warning C4305: 'argument': truncation fm 'const intx' to 'double'make[3]:
> > *** [lib/CompileJvm.gmk:151:
> >
> /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
> > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: ***
>
> This looks like JDK-8212052, which is marked as fixed in JDK 11.0.2.
>
>
>


From shade at redhat.com  Mon Jun  3 07:12:32 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 3 Jun 2019 09:12:32 +0200
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
 <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
Message-ID: <87337dff-6f16-734e-af07-e1e4ec6a7422@redhat.com>

On 6/3/19 9:06 AM, Moshe Zuisman wrote:
> I have gone to : https://hg.openjdk.java.net/jdk/jdk11

That is not the latest jdk11 source. It is a stabilization tree for jdk11 GA -- notice the last
commit there.

Up-to-date 11u tree is here:
  http://hg.openjdk.java.net/jdk-updates/jdk11u

-Aleksey



From david.holmes at oracle.com  Mon Jun  3 07:20:02 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 3 Jun 2019 17:20:02 +1000
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
 <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
Message-ID: <76e55196-cde1-89a4-c559-3a0b1718e4cf@oracle.com>

On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
> Hi.
> Probably I do not understand something in source control system of Open 
> JDK projeck.
> I have gone to :
> https://hg.openjdk.java.net/jdk/jdk11
> and clicked last label:
> "9 months ago jwilhelm Added tag jdk-11+28 for changeset 
> 76072a077ee1default tip"
> arrived to:
> https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
> and downloaded zip with sources.

Thats JDK 11 GA version.

> How have I to download latest fixed source of JDK 11.0.2?

11.0.2 is one of the JDK 11 update releases. You previously indicated 
that you were using 11u sources at:

  http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281

which seems to be a somewhat arbitrary point in 11u development. If you 
want a specific release, rather than latest dev sources then use the 
appropriate tag to update your sources to that level:

http://hg.openjdk.java.net/jdk-updates/jdk11u/tags

So if you clone

http://hg.openjdk.java.net/jdk-updates/jdk11u/

then do:

hg update -r jdk-11.0.2-ga

that should get you to the final 11.0.2 sources.

That all said, the fix Kim was referring to appears to have gone into 
11u 3 months before the date of the sources you indicated you were using.

Hope that helps.

David
-----

> 
> ??, 3 ???. 2019 ?. ? 00:34, Kim Barrett <kim.barrett at oracle.com 
> <mailto:kim.barrett at oracle.com>>:
> 
>      > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman <zuismanm at gmail.com
>     <mailto:zuismanm at gmail.com>> wrote:
>      >
>      > Hi David.
>      > I have updated to Visual studio 2017 15.9.12.
>      > Build still fails, while now works much longer and pass much more
>     steps:
>      >
>      >
>     details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
>      > error C2220: warning treated as error -o 'object' file
>      >
>     generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
>      > warning C4305: 'argument': truncation fm 'const intx' to
>     'double'make[3]:
>      > *** [lib/CompileJvm.gmk:151:
>      >
>     /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
>      > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: ***
> 
>     This looks like JDK-8212052, which is marked as fixed in JDK 11.0.2.
> 
> 


From aph at redhat.com  Mon Jun  3 08:32:13 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 3 Jun 2019 09:32:13 +0100
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
Message-ID: <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>

On 6/3/19 7:58 AM, Nick Gasson wrote:
> 
>> If I'm reading the gcc documentation for __sync_add_and_fetch
>> correctly, I think the following (completely untested) should work,
>> and won't cause Andrew to (I think rightly) complain about
>> type-punning reinterpret_casts.
>>
>> Though I wonder if this is a clang bug. (See below.)

It's arguably a mistake in the GCC documentation, but adding two
pointers is not well defined whereas adding a pointer and an integer
is.

>> template<size_t byte_size>
>> struct Atomic::PlatformAdd
>>   : Atomic::AddAndFetch<Atomic::PlatformAdd<byte_size> >
>> {
>>   template<typename I, typename D>
>>   D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const {
>>     // Cast to work around clang pointer arithmetic bug.
>>     return PrimitiveConversions::cast<D>(__sync_add_and_fetch(dest, add_value));
>>   }
>> }
> 
> This fails with:
> 
> /home/nicgas01/jdk/src/hotspot/share/metaprogramming/primitiveConversions.hpp:162:10: error: invalid use of incomplete type 'struct PrimitiveConversions::Cast<char*, char*, true, void>'
>    return Cast<T, U>()(x);
>           ^~~~~~~~~~~~
> 
> I think because all the specialisations of PrimitiveConversions are only
> enabled if T is an integral type and here it's char*?
> 
>>
>> The key bit from the documentation is "Operations on pointer arguments
>> are performed as if the operands were of the uintptr_t type."
>>
>> The bug description says this warning only arises with clang.  It
>> seems like clang is overdoing that as-if, and treating it literally as
>> uintptr_t all the way through to the result type.
>>
> 
> I think Clang is actually complaining about the argument types
> mismatching here. According to the GCC docs the __sync_add_and_fetch
> prototype looks like:
> 
> type __sync_add_and_fetch (type *ptr, type value, ...)
> 
> I guess Clang infers type=char* from the first argument, and complains
> that the second argument is unsigned long. So Clang gives an error for
> the following but GCC accepts it:
> 
>   char *ptr;
>   unsigned long val;
>   __sync_add_and_fetch(&ptr, val);
> 
> Another way round this is to use __atomic_add_fetch instead which both
> Clang and GCC accept:
> 
>   template<typename I, typename D>
>   D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const {
>     D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE);
>     FULL_MEM_BARRIER;
>     return res;
>   }

I could live with that.

>> Or don't change the code at all here, and say that clang is not
>> (currently) a supported compiler for this platform.
> 
> Yes, that's an option too :-). But we should change the configure script
> to give an error on --with-toolchain-type=clang on AArch64.

I don't think there's any need to boycott the whole compiler because
of this bug. It would make more sense to try to get clang fixed.

Maybe for now put the cast in #ifdef CLANG ?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From robin.westberg at oracle.com  Mon Jun  3 08:36:40 2019
From: robin.westberg at oracle.com (Robin Westberg)
Date: Mon, 3 Jun 2019 10:36:40 +0200
Subject: RFR: 8223678: Add Visual Studio Code workspace generation support
 (for native code)
In-Reply-To: <e8aecff1-9362-2541-3ba6-631dcf2f881f@oracle.com>
References: <BB4F04C6-AE27-4AA6-8BA2-B868A59414FC@oracle.com>
 <b1a09b53-0dcb-4adf-1652-a172ef9a1647@oracle.com>
 <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com>
 <48ff6be3-b2f2-68e2-8082-abba17d0dcc2@oracle.com>
 <A7FA08D4-7E38-4269-AE7B-E8F2108D4A1D@oracle.com>
 <e8aecff1-9362-2541-3ba6-631dcf2f881f@oracle.com>
Message-ID: <04B1C957-E7D6-4516-9543-8210BC8593EB@oracle.com>

Hi Erik,

> On 31 May 2019, at 18:15, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello Robin,
> 
> On 2019-05-31 05:26, Robin Westberg wrote:
>> Hi Erik,
>> 
>>> On 29 May 2019, at 17:22, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>> 
>>> Thanks, looks good!
>> Thanks for reviewing! Unfortunately I had to do a few more general changes to get the ?ccls" indexer working properly as well, hope you don?t mind taking another look:
>> 
>> Webrevs:
>>  - Full: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03/
>>  - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.02-03/
> 
> Looks good!
> 
> I sure appreciate adding tests when modifying the hairier utility macros.

Thanks again for reviewing!

I did a small tweak to the settings of one of the optional indexers (ccls), perhaps not something that needs a detailed review, but here?s the final version that I?m thinking of pushing:

Webrev:
 - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.04/
 - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03-04/

Best regards,
Robin

> 
> /Erik
> 
>> Best regards,
>> Robin
>> 
>>> /Erik
>>> 
>>> On 2019-05-29 06:52, Robin Westberg wrote:
>>>> Hi Erik,
>>>> 
>>>> Thanks for taking a look!
>>>> 
>>>>> On 28 May 2019, at 15:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>> 
>>>>> Hello Robin,
>>>>> 
>>>>> Looks good.
>>>>> 
>>>>> Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor.
>>>> Sure, did a bit of reflowing and updated some formatting in order to look more like the other .md files.
>>>> 
>>>> Webrevs:
>>>>  - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.02/
>>>>  - Inc: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01-02/
>>>> 
>>>> Best regards,
>>>> Robin
>>>> 
>>>>> /Erik
>>>>> 
>>>>> On 2019-05-27 09:03, Robin Westberg wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE.
>>>>>> 
>>>>>> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html].
>>>>>> 
>>>>>> Issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223678
>>>>>> 
>>>>>> Webrev:
>>>>>> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/
>>>>>> 
>>>>>> Testing:
>>>>>> Manual testing on Linux, MacOS and Windows
>>>>>> 
>>>>>> Thanks Erik Joelsson for taking a look at an earlier version of it!
>>>>>> 
>>>>>> Best regards,
>>>>>> Robin



From nick.gasson at arm.com  Mon Jun  3 09:08:45 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 3 Jun 2019 17:08:45 +0800
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
Message-ID: <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>

Hi Andrew,

On 03/06/2019 16:32, Andrew Haley wrote:
> 
> I don't think there's any need to boycott the whole compiler because
> of this bug. It would make more sense to try to get clang fixed.
> 
> Maybe for now put the cast in #ifdef CLANG ?
> 

I think I'd rather put the __atomic_fetch_add in an #ifdef CLANG? This 
seems a bit neater than casting the integer argument to a pointer.

Did you have any thoughts about os::current_stack_pointer() from my 
earlier email?


Thanks,
Nick


From aph at redhat.com  Mon Jun  3 10:24:04 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 3 Jun 2019 11:24:04 +0100
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
Message-ID: <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>

On 6/3/19 10:08 AM, Nick Gasson wrote:
> Hi Andrew,
> 
> On 03/06/2019 16:32, Andrew Haley wrote:
>>
>> I don't think there's any need to boycott the whole compiler because
>> of this bug. It would make more sense to try to get clang fixed.
>>
>> Maybe for now put the cast in #ifdef CLANG ?
>>
> 
> I think I'd rather put the __atomic_fetch_add in an #ifdef CLANG? This 
> seems a bit neater than casting the integer argument to a pointer.

I guess the solution which uses __atomic_add_fetch instead is best.

> Did you have any thoughts about os::current_stack_pointer() from my 
> earlier email?

We need to know what it's used for to know which solution is right. I'm
guessing the primary use case is asynchronous runtime stack probes, used
by debugging tools.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From nick.gasson at arm.com  Mon Jun  3 10:36:10 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 3 Jun 2019 18:36:10 +0800
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
Message-ID: <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>

Hi Andrew,

> 
> We need to know what it's used for to know which solution is right. I'm
> guessing the primary use case is asynchronous runtime stack probes, used
> by debugging tools.
> 

Yes, we also have os::stack_shadow_pages_available() which uses it to 
calculate how much space there is between the current SP and the end of 
the stack. In this case I think it's ok as long as we don't return a 
value that's *above* the actual stack pointer. And os::current_frame(), 
which constructs a `frame' object using the FP of the caller, but the SP 
will point into the frame of os::current_frame(), so it seems it's 
already inaccurate.

There's also a comment in os_linux.cpp that says "Don't use 
os::current_stack_pointer(), as its result can be slightly below current
stack pointer". So I'm wondering if we can simplify this a lot and use 
__builtin_frame_address(0) which will give us the FP in 
os::current_stack_pointer (ought to be the caller's SP - 16). Zero does 
this currently. And maybe we can replace _get_previous_fp() with 
__builtin_frame_address(1)?

Thanks,
Nick


From aph at redhat.com  Mon Jun  3 11:03:53 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 3 Jun 2019 12:03:53 +0100
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
Message-ID: <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>

Hi,

On 6/3/19 11:36 AM, Nick Gasson wrote:
> 
>> We need to know what it's used for to know which solution is right. I'm
>> guessing the primary use case is asynchronous runtime stack probes, used
>> by debugging tools.
>>
> 
> Yes, we also have os::stack_shadow_pages_available() which uses it to 
> calculate how much space there is between the current SP and the end of 
> the stack. In this case I think it's ok as long as we don't return a 
> value that's *above* the actual stack pointer. And os::current_frame(), 
> which constructs a `frame' object using the FP of the caller, but the SP 
> will point into the frame of os::current_frame(), so it seems it's 
> already inaccurate.

Eww.

> There's also a comment in os_linux.cpp that says "Don't use 
> os::current_stack_pointer(), as its result can be slightly below current
> stack pointer". So I'm wondering if we can simplify this a lot and use 
> __builtin_frame_address(0) which will give us the FP in 
> os::current_stack_pointer (ought to be the caller's SP - 16). Zero does 
> this currently. And maybe we can replace _get_previous_fp() with 
> __builtin_frame_address(1)?

Let's make os::current_stack_pointer() noinline, then make it return
__builtin_frame_address(0).

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From erik.joelsson at oracle.com  Mon Jun  3 15:52:01 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 3 Jun 2019 08:52:01 -0700
Subject: RFR: 8223678: Add Visual Studio Code workspace generation support
 (for native code)
In-Reply-To: <04B1C957-E7D6-4516-9543-8210BC8593EB@oracle.com>
References: <BB4F04C6-AE27-4AA6-8BA2-B868A59414FC@oracle.com>
 <b1a09b53-0dcb-4adf-1652-a172ef9a1647@oracle.com>
 <01BD2934-BC92-42A4-B6DC-C977359F0FA2@oracle.com>
 <48ff6be3-b2f2-68e2-8082-abba17d0dcc2@oracle.com>
 <A7FA08D4-7E38-4269-AE7B-E8F2108D4A1D@oracle.com>
 <e8aecff1-9362-2541-3ba6-631dcf2f881f@oracle.com>
 <04B1C957-E7D6-4516-9543-8210BC8593EB@oracle.com>
Message-ID: <609c5ce5-b9fa-fd7f-2a63-322a219c60ec@oracle.com>

Looks good.

/Erik

On 2019-06-03 01:36, Robin Westberg wrote:
> Hi Erik,
>
>> On 31 May 2019, at 18:15, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Hello Robin,
>>
>> On 2019-05-31 05:26, Robin Westberg wrote:
>>> Hi Erik,
>>>
>>>> On 29 May 2019, at 17:22, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>
>>>> Thanks, looks good!
>>> Thanks for reviewing! Unfortunately I had to do a few more general changes to get the ?ccls" indexer working properly as well, hope you don?t mind taking another look:
>>>
>>> Webrevs:
>>>   - Full: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03/
>>>   - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.02-03/
>> Looks good!
>>
>> I sure appreciate adding tests when modifying the hairier utility macros.
> Thanks again for reviewing!
>
> I did a small tweak to the settings of one of the optional indexers (ccls), perhaps not something that needs a detailed review, but here?s the final version that I?m thinking of pushing:
>
> Webrev:
>   - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.04/
>   - Inc: http://cr.openjdk.java.net/~rwestberg/8223678/webrev.03-04/
>
> Best regards,
> Robin
>
>> /Erik
>>
>>> Best regards,
>>> Robin
>>>
>>>> /Erik
>>>>
>>>> On 2019-05-29 06:52, Robin Westberg wrote:
>>>>> Hi Erik,
>>>>>
>>>>> Thanks for taking a look!
>>>>>
>>>>>> On 28 May 2019, at 15:52, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>>
>>>>>> Hello Robin,
>>>>>>
>>>>>> Looks good.
>>>>>>
>>>>>> Adding of ide.md is very nice, but could you try to format it like testing.md and building.md in regards to line lengths? I believe we are trying for 80 chars in those to make them read reasonably in a standard editor.
>>>>> Sure, did a bit of reflowing and updated some formatting in order to look more like the other .md files.
>>>>>
>>>>> Webrevs:
>>>>>   - Full: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.02/
>>>>>   - Inc: https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01-02/
>>>>>
>>>>> Best regards,
>>>>> Robin
>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> On 2019-05-27 09:03, Robin Westberg wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please review this change that adds build system support for generating a Visual Studio Code workspace configured for working with the JDK native code. It configures the default C/C++ IntelliSense Engine to allow code completion/navigation and similar features. It also configures two executable targets (gtestLauncher and java) that can be built and debugged from the IDE.
>>>>>>>
>>>>>>> The main target is "make vscode-project?, additional information can be found in doc/ide.[md|html].
>>>>>>>
>>>>>>> Issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223678
>>>>>>>
>>>>>>> Webrev:
>>>>>>> https://cr.openjdk.java.net/~rwestberg/8223678/webrev.01/
>>>>>>>
>>>>>>> Testing:
>>>>>>> Manual testing on Linux, MacOS and Windows
>>>>>>>
>>>>>>> Thanks Erik Joelsson for taking a look at an earlier version of it!
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Robin


From erik.joelsson at oracle.com  Mon Jun  3 22:55:43 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 3 Jun 2019 15:55:43 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
Message-ID: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>

This is a fix for a problem brought up on this list [1]. The main issue 
is that when cross compiling, and creating a buildjdk during the build, 
the UnixConstants.java cannot necessarily be reused between the target 
JDK and the buildjdk. While investigating this, I came to the conclusion 
that we really should stop trying to reuse anything between the buildjdk 
and target JDK. It's just becoming too complex to maintain (due to the 
intricate interactions with the interim-image, generate-link-opt-data 
and exploded-image-optimize targets, causing circular dependencies and 
endless incremental rebuilds).

So this fix simply removes all the reuse of buildtools, gensrc and java 
compilation when creating a buildjdk. Hopefully this is making Main.gmk 
a bit less convoluted.

While working on this, I came up with the idea of adding a log prefix 
functionality, to more easily discern which log lines were printed by 
the buildjdk build and which were part of the normal build. I liked this 
a lot so including that in the same fix, and applied it to the bootcycle 
build as well.

Bug: https://bugs.openjdk.java.net/browse/JDK-8217739

Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html

/Erik

[1] 
http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html



From kim.barrett at oracle.com  Tue Jun  4 03:03:30 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 3 Jun 2019 23:03:30 -0400
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
Message-ID: <8F37D029-DE22-4CE5-981C-A87CB97C7690@oracle.com>

> On Jun 3, 2019, at 4:32 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 6/3/19 7:58 AM, Nick Gasson wrote:
>> 
>>> If I'm reading the gcc documentation for __sync_add_and_fetch
>>> correctly, I think the following (completely untested) should work,
>>> and won't cause Andrew to (I think rightly) complain about
>>> type-punning reinterpret_casts.
>>> 
>>> Though I wonder if this is a clang bug. (See below.)
> 
> It's arguably a mistake in the GCC documentation, but adding two
> pointers is not well defined whereas adding a pointer and an integer
> is.

Yes, the gcc documentation seems to be a bit botched here.  But there
is also the semantic description, e.g. for __sync_OP_and_fetch:

    { *ptr OP= value; return *ptr; }

>> Another way round this is to use __atomic_add_fetch instead which both
>> Clang and GCC accept:
>> 
>>  template<typename I, typename D>
>>  D add_and_fetch(I add_value, D volatile* dest, atomic_memory_order order) const {
>>    D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE);
>>    FULL_MEM_BARRIER;
>>    return res;
>>  }
> 
> I could live with that.

The __atomic_xxx operations seem to have the same documentation
issues.  It's strange that clang would get one set right and the other
wrong.  But okay, using them seems like a good workaround. And maybe
someday the order argument will be used to select the barriers to use.



From tim.bell at oracle.com  Tue Jun  4 14:53:40 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 04 Jun 2019 07:53:40 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
Message-ID: <5CF685F4.3050305@oracle.com>

Erik:

Looks good.

Tim

> This is a fix for a problem brought up on this list [1]. The main issue
> is that when cross compiling, and creating a buildjdk during the build,
> the UnixConstants.java cannot necessarily be reused between the target
> JDK and the buildjdk. While investigating this, I came to the conclusion
> that we really should stop trying to reuse anything between the buildjdk
> and target JDK. It's just becoming too complex to maintain (due to the
> intricate interactions with the interim-image, generate-link-opt-data
> and exploded-image-optimize targets, causing circular dependencies and
> endless incremental rebuilds).
>
> So this fix simply removes all the reuse of buildtools, gensrc and java
> compilation when creating a buildjdk. Hopefully this is making Main.gmk
> a bit less convoluted.
>
> While working on this, I came up with the idea of adding a log prefix
> functionality, to more easily discern which log lines were printed by
> the buildjdk build and which were part of the normal build. I liked this
> a lot so including that in the same fix, and applied it to the bootcycle
> build as well.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>
> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>
> /Erik
>
> [1]
> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html





From erik.joelsson at oracle.com  Tue Jun  4 16:00:17 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 4 Jun 2019 09:00:17 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <5CF685F4.3050305@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
Message-ID: <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>

Thanks!

During testing, I found an intermittent race issue. The command line 
that runs the interim langtools version of javac still always points to 
the buildtools/interim-langtools dir of the normal build. This variable 
also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only 
changed in buildjdk-spec.gmk.in:

http://cr.openjdk.java.net/~erikj/8217739/webrev.02/

/Erik

On 2019-06-04 07:53, Tim Bell wrote:
> Erik:
>
> Looks good.
>
> Tim
>
>> This is a fix for a problem brought up on this list [1]. The main issue
>> is that when cross compiling, and creating a buildjdk during the build,
>> the UnixConstants.java cannot necessarily be reused between the target
>> JDK and the buildjdk. While investigating this, I came to the conclusion
>> that we really should stop trying to reuse anything between the buildjdk
>> and target JDK. It's just becoming too complex to maintain (due to the
>> intricate interactions with the interim-image, generate-link-opt-data
>> and exploded-image-optimize targets, causing circular dependencies and
>> endless incremental rebuilds).
>>
>> So this fix simply removes all the reuse of buildtools, gensrc and java
>> compilation when creating a buildjdk. Hopefully this is making Main.gmk
>> a bit less convoluted.
>>
>> While working on this, I came up with the idea of adding a log prefix
>> functionality, to more easily discern which log lines were printed by
>> the buildjdk build and which were part of the normal build. I liked this
>> a lot so including that in the same fix, and applied it to the bootcycle
>> build as well.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>>
>> /Erik
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html 
>>
>
>
>


From zuismanm at gmail.com  Tue Jun  4 16:20:39 2019
From: zuismanm at gmail.com (Moshe Zuisman)
Date: Tue, 4 Jun 2019 19:20:39 +0300
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <76e55196-cde1-89a4-c559-3a0b1718e4cf@oracle.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
 <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
 <76e55196-cde1-89a4-c559-3a0b1718e4cf@oracle.com>
Message-ID: <CAFASMLTZb5-206Ah_rrgsAUCnqBjBBDp9pW=gqaOQRkeACd9-g@mail.gmail.com>

Hi. Thank for your recomendation!
Although I did not success to run "hg update -r jdk-11.0.2-ga" - got :
"abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg not
found)!"
But since I from begining cloned jdk-11.0.2 label form site - I suppose it
gives equavalent result.

And finally I was able to pass compilation (make)
But "make test" fails any where:
to get it clear form begening - I donladed latest stabel jtreg and
configured with it:
 ./configure --with-jtreg=/cygdrive/c/jtreg






















































*$ make testBuilding target 'test' in configuration
'windows-x86_64-normal-server-release'Warning: No mercurial configuration
present and no .src-revCompiling 31 files for BUILD_JRTFSCompiling 27 files
for BUILD_FAILURE_HANDLERCreating
support/test/failure_handler/timeoutHandler.dll from 1 file(s)Creating
support/modules_libs/java.base/jrt-fs.jarc:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
error: no suitable method found for save(Map<CAP#1,CAP#2>)
rp.save(map);          ^    method InterviewParameters.save(File) is not
applicable      (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
File)    method InterviewParameters.save(Map<String,String>) is not
applicable      (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
Map<String,String>)  where CAP#1,CAP#2 are fresh type-variables:    CAP#1
extends Object from capture of ?    CAP#2 extends Object from capture of
?Note: Some input files use or override a deprecated API.Note: Recompile
with -Xlint:deprecation for details.Note: Some messages have been
simplified; recompile with -Xdiags:verbose to get full output1
errormake[3]: *** [BuildFailureHandler.gmk:54:
/cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch]
Error 1make[2]: *** [make/Main.gmk:516: build-test-failure-handler] Error
2make[2]: *** Waiting for unfinished jobs....ERROR: Build failed for target
'test' in configuration 'windows-x86_64-normal-server-release' (exit code
2)Stopping sjavac server=== Output from failing command(s) repeated here
===* For target
support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
error: no suitable method found for save(Map<CAP#1,CAP#2>)
rp.save(map);          ^    method InterviewParameters.save(File) is not
applicable      (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
File)    method InterviewParameters.save(Map<String,String>) is not
applicable      (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
Map<String,String>)  where CAP#1,CAP#2 are fresh type-variables:    CAP#1
extends Object from capture of ?    CAP#2 extends Object from capture of
?Note: Some input files use or override a deprecated API.Note: Recompile
with -Xlint:deprecation for details.   ... (rest of output omitted)* All
command lines available in
/cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/make-support/failure-logs.===
End of repeated output ===No indication of failed target found.Hint: Try
searching the build log for '] Error'.Hint: See
doc/building.html#troubleshooting for assistance.make[1]: ***
[/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:305: main] Error 2make: ***
[/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:186: test] Error 2*

??, 3 ???. 2019 ?. ? 10:20, David Holmes <david.holmes at oracle.com>:

> On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
> > Hi.
> > Probably I do not understand something in source control system of Open
> > JDK projeck.
> > I have gone to :
> > https://hg.openjdk.java.net/jdk/jdk11
> > and clicked last label:
> > "9 months ago jwilhelm Added tag jdk-11+28 for changeset
> > 76072a077ee1default tip"
> > arrived to:
> > https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
> > and downloaded zip with sources.
>
> Thats JDK 11 GA version.
>
> > How have I to download latest fixed source of JDK 11.0.2?
>
> 11.0.2 is one of the JDK 11 update releases. You previously indicated
> that you were using 11u sources at:
>
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
>
> which seems to be a somewhat arbitrary point in 11u development. If you
> want a specific release, rather than latest dev sources then use the
> appropriate tag to update your sources to that level:
>
> http://hg.openjdk.java.net/jdk-updates/jdk11u/tags
>
> So if you clone
>
> http://hg.openjdk.java.net/jdk-updates/jdk11u/
>
> then do:
>
> hg update -r jdk-11.0.2-ga
>
> that should get you to the final 11.0.2 sources.
>
> That all said, the fix Kim was referring to appears to have gone into
> 11u 3 months before the date of the sources you indicated you were using.
>
> Hope that helps.
>
> David
> -----
>
> >
> > ??, 3 ???. 2019 ?. ? 00:34, Kim Barrett <kim.barrett at oracle.com
> > <mailto:kim.barrett at oracle.com>>:
> >
> >      > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman <zuismanm at gmail.com
> >     <mailto:zuismanm at gmail.com>> wrote:
> >      >
> >      > Hi David.
> >      > I have updated to Visual studio 2017 15.9.12.
> >      > Build still fails, while now works much longer and pass much more
> >     steps:
> >      >
> >      >
> >
>  details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> >      > error C2220: warning treated as error -o 'object' file
> >      >
> >
>  generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> >      > warning C4305: 'argument': truncation fm 'const intx' to
> >     'double'make[3]:
> >      > *** [lib/CompileJvm.gmk:151:
> >      >
> >
>  /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
> >      > Error 1make[3]: *** Waiting for unfinished jobs....make[2]: ***
> >
> >     This looks like JDK-8212052, which is marked as fixed in JDK 11.0.2.
> >
> >
>


From erik.joelsson at oracle.com  Tue Jun  4 21:53:10 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 4 Jun 2019 14:53:10 -0700
Subject: RFR: JDK-8209381: Default CDS classlist generation should run with an
 explicit locale setting
Message-ID: <acd74a85-2dc4-b104-f0e8-ff9090be344e@oracle.com>

Hello,

Please review this fix for the default CDS classlist generation. This 
patch adds an explicit English locale to the generation command to make 
the build less dependent on the locale it is running in, and produce the 
same classlist regardless.

Thanks to Ioi who helped me verify that the patch actually works.

Bug: https://bugs.openjdk.java.net/browse/JDK-8209381

Webrev: http://cr.openjdk.java.net/~erikj/8209381/webrev.01/index.html

/Erik



From david.holmes at oracle.com  Tue Jun  4 23:25:20 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 5 Jun 2019 09:25:20 +1000
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <CAFASMLTZb5-206Ah_rrgsAUCnqBjBBDp9pW=gqaOQRkeACd9-g@mail.gmail.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
 <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
 <76e55196-cde1-89a4-c559-3a0b1718e4cf@oracle.com>
 <CAFASMLTZb5-206Ah_rrgsAUCnqBjBBDp9pW=gqaOQRkeACd9-g@mail.gmail.com>
Message-ID: <22acd655-89ff-0437-daf1-613f4a00f8b9@oracle.com>

On 5/06/2019 2:20 am, Moshe Zuisman wrote:
> Hi. Thank for your recomendation!
> Although I did not success to run "hg update -r jdk-11.0.2-ga" - got : 
> "abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg not 
> found)!"

I don't know how you are "cloning" things but you are not getting an 
actual mercurial repository out of the process!

> But since I from begining cloned?jdk-11.0.2 label form site - I suppose 
> it gives equavalent result.
> 
> And finally I was able to pass compilation (make)
> But "make test" fails any where:
> to get it clear form begening - I donladed latest stabel jtreg and 
> configured with it:
>  ?./configure --with-jtreg=/cygdrive/c/jtreg

Latest jtreg may not be suitable for 11u. The specified version 
(make/conf/jib-profiles.js) is 4.2-b12

David
-----

> /$ make test
> Building target 'test' in configuration 
> 'windows-x86_64-normal-server-release'
> Warning: No mercurial configuration present and no .src-rev
> Compiling 31 files for BUILD_JRTFS
> Compiling 27 files for BUILD_FAILURE_HANDLER
> Creating support/test/failure_handler/timeoutHandler.dll from 1 file(s)
> Creating support/modules_libs/java.base/jrt-fs.jar
> c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123: 
> error: no suitable method found for save(Map<CAP#1,CAP#2>)
>  ? ? ? ? rp.save(map);
>  ? ? ? ? ? ^
>  ? ? method InterviewParameters.save(File) is not applicable
>  ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to File)
>  ? ? method InterviewParameters.save(Map<String,String>) is not applicable
>  ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to 
> Map<String,String>)
>  ? where CAP#1,CAP#2 are fresh type-variables:
>  ? ? CAP#1 extends Object from capture of ?
>  ? ? CAP#2 extends Object from capture of ?
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some messages have been simplified; recompile with -Xdiags:verbose 
> to get full output
> 1 error
> make[3]: *** [BuildFailureHandler.gmk:54: 
> /cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch] 
> Error 1
> make[2]: *** [make/Main.gmk:516: build-test-failure-handler] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> ERROR: Build failed for target 'test' in configuration 
> 'windows-x86_64-normal-server-release' (exit code 2)
> Stopping sjavac server
> 
> === Output from failing command(s) repeated here ===
> * For target 
> support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:
> c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123: 
> error: no suitable method found for save(Map<CAP#1,CAP#2>)
>  ? ? ? ? rp.save(map);
>  ? ? ? ? ? ^
>  ? ? method InterviewParameters.save(File) is not applicable
>  ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to File)
>  ? ? method InterviewParameters.save(Map<String,String>) is not applicable
>  ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to 
> Map<String,String>)
>  ? where CAP#1,CAP#2 are fresh type-variables:
>  ? ? CAP#1 extends Object from capture of ?
>  ? ? CAP#2 extends Object from capture of ?
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>  ? ?... (rest of output omitted)
> 
> * All command lines available in 
> /cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/make-support/failure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> Hint: Try searching the build log for '] Error'.
> Hint: See doc/building.html#troubleshooting for assistance.
> 
> make[1]: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:305: main] Error 2
> make: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:186: test] Error 2
> /
> 
> ??, 3 ???. 2019 ?. ? 10:20, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>>:
> 
>     On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
>      > Hi.
>      > Probably I do not understand something in source control system
>     of Open
>      > JDK projeck.
>      > I have gone to :
>      > https://hg.openjdk.java.net/jdk/jdk11
>      > and clicked last label:
>      > "9 months ago jwilhelm Added tag jdk-11+28 for changeset
>      > 76072a077ee1default tip"
>      > arrived to:
>      > https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
>      > and downloaded zip with sources.
> 
>     Thats JDK 11 GA version.
> 
>      > How have I to download latest fixed source of JDK 11.0.2?
> 
>     11.0.2 is one of the JDK 11 update releases. You previously indicated
>     that you were using 11u sources at:
> 
>     http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
> 
>     which seems to be a somewhat arbitrary point in 11u development. If you
>     want a specific release, rather than latest dev sources then use the
>     appropriate tag to update your sources to that level:
> 
>     http://hg.openjdk.java.net/jdk-updates/jdk11u/tags
> 
>     So if you clone
> 
>     http://hg.openjdk.java.net/jdk-updates/jdk11u/
> 
>     then do:
> 
>     hg update -r jdk-11.0.2-ga
> 
>     that should get you to the final 11.0.2 sources.
> 
>     That all said, the fix Kim was referring to appears to have gone into
>     11u 3 months before the date of the sources you indicated you were
>     using.
> 
>     Hope that helps.
> 
>     David
>     -----
> 
>      >
>      > ??, 3 ???. 2019 ?. ? 00:34, Kim Barrett <kim.barrett at oracle.com
>     <mailto:kim.barrett at oracle.com>
>      > <mailto:kim.barrett at oracle.com <mailto:kim.barrett at oracle.com>>>:
>      >
>      >? ? ? > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman
>     <zuismanm at gmail.com <mailto:zuismanm at gmail.com>
>      >? ? ?<mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>> wrote:
>      >? ? ? >
>      >? ? ? > Hi David.
>      >? ? ? > I have updated to Visual studio 2017 15.9.12.
>      >? ? ? > Build still fails, while now works much longer and pass
>     much more
>      >? ? ?steps:
>      >? ? ? >
>      >? ? ? >
>      >   
>      ?details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
>      >? ? ? > error C2220: warning treated as error -o 'object' file
>      >? ? ? >
>      >   
>      ?generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
>      >? ? ? > warning C4305: 'argument': truncation fm 'const intx' to
>      >? ? ?'double'make[3]:
>      >? ? ? > *** [lib/CompileJvm.gmk:151:
>      >? ? ? >
>      >   
>      ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
>      >? ? ? > Error 1make[3]: *** Waiting for unfinished
>     jobs....make[2]: ***
>      >
>      >? ? ?This looks like JDK-8212052, which is marked as fixed in JDK
>     11.0.2.
>      >
>      >
> 


From IOI.LAM at ORACLE.COM  Tue Jun  4 23:59:02 2019
From: IOI.LAM at ORACLE.COM (Ioi Lam)
Date: Tue, 4 Jun 2019 16:59:02 -0700
Subject: RFR: JDK-8209381: Default CDS classlist generation should run
 with an explicit locale setting
In-Reply-To: <acd74a85-2dc4-b104-f0e8-ff9090be344e@oracle.com>
References: <acd74a85-2dc4-b104-f0e8-ff9090be344e@oracle.com>
Message-ID: <B20BC7CA-8A97-4764-B5BA-B99639FB4D44@ORACLE.COM>

Looks good! Thanks for the patch.

Ioi

> On Jun 4, 2019, at 2:53 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> Please review this fix for the default CDS classlist generation. This patch adds an explicit English locale to the generation command to make the build less dependent on the locale it is running in, and produce the same classlist regardless.
> 
> Thanks to Ioi who helped me verify that the patch actually works.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209381
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8209381/webrev.01/index.html
> 
> /Erik
> 



From tim.bell at oracle.com  Wed Jun  5 00:10:39 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 04 Jun 2019 17:10:39 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
Message-ID: <5CF7087F.2020702@oracle.com>

Erik:

OK - version 2 looks good.

Tim


> Thanks!
>
> During testing, I found an intermittent race issue. The command line
> that runs the interim langtools version of javac still always points to
> the buildtools/interim-langtools dir of the normal build. This variable
> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> changed in buildjdk-spec.gmk.in:
>
> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>
> /Erik
>
> On 2019-06-04 07:53, Tim Bell wrote:
>> Erik:
>>
>> Looks good.
>>
>> Tim
>>
>>> This is a fix for a problem brought up on this list [1]. The main issue
>>> is that when cross compiling, and creating a buildjdk during the build,
>>> the UnixConstants.java cannot necessarily be reused between the target
>>> JDK and the buildjdk. While investigating this, I came to the conclusion
>>> that we really should stop trying to reuse anything between the buildjdk
>>> and target JDK. It's just becoming too complex to maintain (due to the
>>> intricate interactions with the interim-image, generate-link-opt-data
>>> and exploded-image-optimize targets, causing circular dependencies and
>>> endless incremental rebuilds).
>>>
>>> So this fix simply removes all the reuse of buildtools, gensrc and java
>>> compilation when creating a buildjdk. Hopefully this is making Main.gmk
>>> a bit less convoluted.
>>>
>>> While working on this, I came up with the idea of adding a log prefix
>>> functionality, to more easily discern which log lines were printed by
>>> the buildjdk build and which were part of the normal build. I liked this
>>> a lot so including that in the same fix, and applied it to the bootcycle
>>> build as well.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>>>
>>> /Erik
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
>>>
>>
>>
>>



From tim.bell at oracle.com  Wed Jun  5 00:14:15 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 04 Jun 2019 17:14:15 -0700
Subject: RFR: JDK-8209381: Default CDS classlist generation should run
 with an explicit locale setting
In-Reply-To: <B20BC7CA-8A97-4764-B5BA-B99639FB4D44@ORACLE.COM>
References: <acd74a85-2dc4-b104-f0e8-ff9090be344e@oracle.com>
 <B20BC7CA-8A97-4764-B5BA-B99639FB4D44@ORACLE.COM>
Message-ID: <5CF70957.9070806@oracle.com>

Erik:

Looks good to me as well.

Tim

On 06/04/19 16:59, Ioi Lam wrote:
> Looks good! Thanks for the patch.
>
> Ioi
>
>> On Jun 4, 2019, at 2:53 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review this fix for the default CDS classlist generation. This patch adds an explicit English locale to the generation command to make the build less dependent on the locale it is running in, and produce the same classlist regardless.
>>
>> Thanks to Ioi who helped me verify that the patch actually works.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209381
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8209381/webrev.01/index.html
>>
>> /Erik
>>
>



From aoqi at loongson.cn  Wed Jun  5 04:48:43 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Wed, 5 Jun 2019 12:48:43 +0800
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
Message-ID: <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>

Hi Erik,

Thank you a lot for taking care of this. I mainly like your approach.
I tested the patch by cross building mips64-zero, by which we found
this problem. However, it seems the problem still exists. The reason I
found is that UnixConstants.java of buildjdk is generated by cross
compiler, so the macro definitions are defined by the target. Here is
a preliminary workaround for your reference only (only worked for
gcc):

$ hg diff make/gensrc/GensrcMisc.gmk
diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
--- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
+++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
@@ -61,6 +61,13 @@
   CPP_FLAGS += -nologo
 endif

+ifeq ($(CREATING_BUILDJDK), true)
+  # Only worked for gcc
+  TEMP_CPP=gcc -E
+else
+  TEMP_CPP=$(CPP)
+endif
+
 # Generate a java source file from a template through the C
preprocessor for the
 # target system. First extract the copyright notice at the start of the file.
 # Run the preprocessor. Filter out the default compiler stderr output on
@@ -71,7 +78,7 @@
 define generate-preproc-src
  $(call MakeDir, $(@D))
  ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
-   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
+   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
        2> >($(GREP) -v '^$(<F)$$' >&2) \
        | $(NAWK) '/@@START_HERE@@/,0' \
        |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
FILE - DO NOT EDIT/' \


Cheers,
Ao Qi

On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>
> Thanks!
>
> During testing, I found an intermittent race issue. The command line
> that runs the interim langtools version of javac still always points to
> the buildtools/interim-langtools dir of the normal build. This variable
> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> changed in buildjdk-spec.gmk.in:
>
> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>
> /Erik
>
> On 2019-06-04 07:53, Tim Bell wrote:
> > Erik:
> >
> > Looks good.
> >
> > Tim
> >
> >> This is a fix for a problem brought up on this list [1]. The main issue
> >> is that when cross compiling, and creating a buildjdk during the build,
> >> the UnixConstants.java cannot necessarily be reused between the target
> >> JDK and the buildjdk. While investigating this, I came to the conclusion
> >> that we really should stop trying to reuse anything between the buildjdk
> >> and target JDK. It's just becoming too complex to maintain (due to the
> >> intricate interactions with the interim-image, generate-link-opt-data
> >> and exploded-image-optimize targets, causing circular dependencies and
> >> endless incremental rebuilds).
> >>
> >> So this fix simply removes all the reuse of buildtools, gensrc and java
> >> compilation when creating a buildjdk. Hopefully this is making Main.gmk
> >> a bit less convoluted.
> >>
> >> While working on this, I came up with the idea of adding a log prefix
> >> functionality, to more easily discern which log lines were printed by
> >> the buildjdk build and which were part of the normal build. I liked this
> >> a lot so including that in the same fix, and applied it to the bootcycle
> >> build as well.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
> >>
> >> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
> >>
> >> /Erik
> >>
> >> [1]
> >> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
> >>
> >
> >
> >


From zuismanm at gmail.com  Wed Jun  5 07:40:45 2019
From: zuismanm at gmail.com (Moshe Zuisman)
Date: Wed, 5 Jun 2019 10:40:45 +0300
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <22acd655-89ff-0437-daf1-613f4a00f8b9@oracle.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
 <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
 <76e55196-cde1-89a4-c559-3a0b1718e4cf@oracle.com>
 <CAFASMLTZb5-206Ah_rrgsAUCnqBjBBDp9pW=gqaOQRkeACd9-g@mail.gmail.com>
 <22acd655-89ff-0437-daf1-613f4a00f8b9@oracle.com>
Message-ID: <CAFASMLSxSCB-ukQVBeinXFQD54ncy2Q-q7AurjLQNbg1B=f_2Q@mail.gmail.com>

Hi David.
2 questions.


   1. I as was told here - downloaded JDK sources from
   http://hg.openjdk.java.net/jdk-updates/jdk11u/
   <http://hg.openjdk.java.net/jdk-updates/jdk11u/> .  I can not perform  "hg
   update -r jdk-11.0.2-ga", since I get:
   " "abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg
   not found)!"  "
   And really - in director, that I get after extracting there is not ".hg"
   2. When I took jtreg  4.2-b12, most tests passes, but I still fail at:

















*D rectory
   "C:\jdk11u-11.0.2-ga\build\windows-x86_64-normal-server-release\testoutput\jaxp_all\JTwork"
   not found: creating^M Directory
   "C:\jdk11u-11.0.2-ga\build\windows-x86_64-normal-server-release\testoutput\jaxp_all\JTreport"
   not found: creating^M Error: Unexpected exception occurred!
   java.lang.NoSuchMethodError:
   com.sun.javatest.regtest.agent.JDK_Version.compareTo(Lcom/sun/javatest/regtest/agent/JDK_Version;)I^M
   java.lang.NoSuchMethodError:
   com.sun.javatest.regtest.agent.JDK_Version.compareTo(Lcom/sun/javatest/regtest/agent/JDK_Version;)I^M
           at
   com.sun.javatest.regtest.config.JDK.getSystemModules(JDK.java:405)^M
     at
   com.sun.javatest.regtest.config.RegressionParameters.getModulesFilter(RegressionParameters.java:202)^M
           at
   com.sun.javatest.regtest.config.RegressionParameters.getRelevantTestFilter(RegressionParameters.java:177)^M
           at
   com.sun.javatest.InterviewParameters.getFilters(InterviewParameters.java:767)^M
           at com.sun.javatest.Harness.createTreeIterator(Harness.java:811)^M
           at com.sun.javatest.Harness.runTests(Harness.java:701)^M         at
   com.sun.javatest.Harness.batch(Harness.java:400)^M         at
   com.sun.javatest.regtest.tool.Tool.batchHarness(Tool.java:1824)^M
   at com.sun.javatest.regtest.tool.Tool.run(Tool.java:1216)^M         at
   com.sun.javatest.regtest.tool.Tool.run(Tool.java:962)^M         at
   com.sun.javatest.regtest.tool.Tool.main(Tool.java:134)^M         at
   com.sun.javatest.regtest.Main.main(Main.java:58)^M Missing file:
   C:/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/testoutput/jaxp_all/JTreport/text/summary.txt
   EXIT CODE: 6*




??, 5 ???. 2019 ?. ? 02:25, David Holmes <david.holmes at oracle.com>:

> On 5/06/2019 2:20 am, Moshe Zuisman wrote:
> > Hi. Thank for your recomendation!
> > Although I did not success to run "hg update -r jdk-11.0.2-ga" - got :
> > "abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg not
> > found)!"
>
> I don't know how you are "cloning" things but you are not getting an
> actual mercurial repository out of the process!
>
> > But since I from begining cloned jdk-11.0.2 label form site - I suppose
> > it gives equavalent result.
> >
> > And finally I was able to pass compilation (make)
> > But "make test" fails any where:
> > to get it clear form begening - I donladed latest stabel jtreg and
> > configured with it:
> >   ./configure --with-jtreg=/cygdrive/c/jtreg
>
> Latest jtreg may not be suitable for 11u. The specified version
> (make/conf/jib-profiles.js) is 4.2-b12
>
> David
> -----
>
> > /$ make test
> > Building target 'test' in configuration
> > 'windows-x86_64-normal-server-release'
> > Warning: No mercurial configuration present and no .src-rev
> > Compiling 31 files for BUILD_JRTFS
> > Compiling 27 files for BUILD_FAILURE_HANDLER
> > Creating support/test/failure_handler/timeoutHandler.dll from 1 file(s)
> > Creating support/modules_libs/java.base/jrt-fs.jar
> >
> c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
>
> > error: no suitable method found for save(Map<CAP#1,CAP#2>)
> >          rp.save(map);
> >            ^
> >      method InterviewParameters.save(File) is not applicable
> >        (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to File)
> >      method InterviewParameters.save(Map<String,String>) is not
> applicable
> >        (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
> > Map<String,String>)
> >    where CAP#1,CAP#2 are fresh type-variables:
> >      CAP#1 extends Object from capture of ?
> >      CAP#2 extends Object from capture of ?
> > Note: Some input files use or override a deprecated API.
> > Note: Recompile with -Xlint:deprecation for details.
> > Note: Some messages have been simplified; recompile with -Xdiags:verbose
> > to get full output
> > 1 error
> > make[3]: *** [BuildFailureHandler.gmk:54:
> >
> /cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch]
>
> > Error 1
> > make[2]: *** [make/Main.gmk:516: build-test-failure-handler] Error 2
> > make[2]: *** Waiting for unfinished jobs....
> >
> > ERROR: Build failed for target 'test' in configuration
> > 'windows-x86_64-normal-server-release' (exit code 2)
> > Stopping sjavac server
> >
> > === Output from failing command(s) repeated here ===
> > * For target
> > support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:
> >
> c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
>
> > error: no suitable method found for save(Map<CAP#1,CAP#2>)
> >          rp.save(map);
> >            ^
> >      method InterviewParameters.save(File) is not applicable
> >        (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to File)
> >      method InterviewParameters.save(Map<String,String>) is not
> applicable
> >        (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
> > Map<String,String>)
> >    where CAP#1,CAP#2 are fresh type-variables:
> >      CAP#1 extends Object from capture of ?
> >      CAP#2 extends Object from capture of ?
> > Note: Some input files use or override a deprecated API.
> > Note: Recompile with -Xlint:deprecation for details.
> >     ... (rest of output omitted)
> >
> > * All command lines available in
> >
> /cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/make-support/failure-logs.
> > === End of repeated output ===
> >
> > No indication of failed target found.
> > Hint: Try searching the build log for '] Error'.
> > Hint: See doc/building.html#troubleshooting for assistance.
> >
> > make[1]: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:305: main]
> Error 2
> > make: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:186: test] Error 2
> > /
> >
> > ??, 3 ???. 2019 ?. ? 10:20, David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>>:
> >
> >     On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
> >      > Hi.
> >      > Probably I do not understand something in source control system
> >     of Open
> >      > JDK projeck.
> >      > I have gone to :
> >      > https://hg.openjdk.java.net/jdk/jdk11
> >      > and clicked last label:
> >      > "9 months ago jwilhelm Added tag jdk-11+28 for changeset
> >      > 76072a077ee1default tip"
> >      > arrived to:
> >      > https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
> >      > and downloaded zip with sources.
> >
> >     Thats JDK 11 GA version.
> >
> >      > How have I to download latest fixed source of JDK 11.0.2?
> >
> >     11.0.2 is one of the JDK 11 update releases. You previously indicated
> >     that you were using 11u sources at:
> >
> >     http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
> >
> >     which seems to be a somewhat arbitrary point in 11u development. If
> you
> >     want a specific release, rather than latest dev sources then use the
> >     appropriate tag to update your sources to that level:
> >
> >     http://hg.openjdk.java.net/jdk-updates/jdk11u/tags
> >
> >     So if you clone
> >
> >     http://hg.openjdk.java.net/jdk-updates/jdk11u/
> >
> >     then do:
> >
> >     hg update -r jdk-11.0.2-ga
> >
> >     that should get you to the final 11.0.2 sources.
> >
> >     That all said, the fix Kim was referring to appears to have gone into
> >     11u 3 months before the date of the sources you indicated you were
> >     using.
> >
> >     Hope that helps.
> >
> >     David
> >     -----
> >
> >      >
> >      > ??, 3 ???. 2019 ?. ? 00:34, Kim Barrett <kim.barrett at oracle.com
> >     <mailto:kim.barrett at oracle.com>
> >      > <mailto:kim.barrett at oracle.com <mailto:kim.barrett at oracle.com>>>:
> >      >
> >      >      > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman
> >     <zuismanm at gmail.com <mailto:zuismanm at gmail.com>
> >      >     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>>
> wrote:
> >      >      >
> >      >      > Hi David.
> >      >      > I have updated to Visual studio 2017 15.9.12.
> >      >      > Build still fails, while now works much longer and pass
> >     much more
> >      >     steps:
> >      >      >
> >      >      >
> >      >
> >
>  details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> >      >      > error C2220: warning treated as error -o 'object' file
> >      >      >
> >      >
> >
>  generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
> >      >      > warning C4305: 'argument': truncation fm 'const intx' to
> >      >     'double'make[3]:
> >      >      > *** [lib/CompileJvm.gmk:151:
> >      >      >
> >      >
> >
>  /cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
> >      >      > Error 1make[3]: *** Waiting for unfinished
> >     jobs....make[2]: ***
> >      >
> >      >     This looks like JDK-8212052, which is marked as fixed in JDK
> >     11.0.2.
> >      >
> >      >
> >
>


From david.holmes at oracle.com  Wed Jun  5 08:12:38 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 5 Jun 2019 18:12:38 +1000
Subject: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017
In-Reply-To: <CAFASMLSxSCB-ukQVBeinXFQD54ncy2Q-q7AurjLQNbg1B=f_2Q@mail.gmail.com>
References: <CAFASMLT1pkQiFg3f5o=PT4y5bN1qUZevEJuYAZZjsL_4OD5aOw@mail.gmail.com>
 <ea969f8a-a7f3-f309-3948-7b5d1dd8f0c3@oracle.com>
 <CAFASMLTUYwRdXC+Mb1ZUo1vCZmeLJXzCi79VL5T8hLZcpDMuZQ@mail.gmail.com>
 <CAFASMLSSx58j3e6DKEhXUv8Rt66r0fkTngAvTwKbmogJx1sNCQ@mail.gmail.com>
 <9b66c58b-12ba-1060-0cec-363917ebef38@oracle.com>
 <CAFASMLRYBb+==R1nvYzeoPi+e71rKV2PONBhZD_VRA1RfxWUgQ@mail.gmail.com>
 <5e3519d0-18a6-7a31-0381-96d8853d098c@oracle.com>
 <CAFASMLRzVzUYJKFh4NbrChF9tnHHug=MjvYLp5dxrvXObR3CkQ@mail.gmail.com>
 <1160ccd0-6ee7-13aa-0bff-10c07ee05615@oracle.com>
 <CAFASMLT_DxRM+6RkpT7OpR877ovd79Ke8COfuidVEUhaUR-SRA@mail.gmail.com>
 <89E732EF-5961-4C92-B102-A3B1B2943974@oracle.com>
 <CAFASMLQR_MH0BdWMsAOfBnUgW5CBF5u8XsGrLgn_LED+KVOL4g@mail.gmail.com>
 <76e55196-cde1-89a4-c559-3a0b1718e4cf@oracle.com>
 <CAFASMLTZb5-206Ah_rrgsAUCnqBjBBDp9pW=gqaOQRkeACd9-g@mail.gmail.com>
 <22acd655-89ff-0437-daf1-613f4a00f8b9@oracle.com>
 <CAFASMLSxSCB-ukQVBeinXFQD54ncy2Q-q7AurjLQNbg1B=f_2Q@mail.gmail.com>
Message-ID: <b31d93b3-0659-f8e1-cb44-778724ebce86@oracle.com>

On 5/06/2019 5:40 pm, Moshe Zuisman wrote:
> Hi David.
> 2 questions.
> 
>  1. I as was told here - downloaded JDK sources from
>     http://hg.openjdk.java.net/jdk-updates/jdk11u/
>     <http://hg.openjdk.java.net/jdk-updates/jdk11u/>?.? I can not
>     perform "hg update -r jdk-11.0.2-ga", since I get:
>     " "abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg
>     not?found)!"? "
>     And really - in director, that I get after extracting there is not ".hg"

Ah you downloaded the zip file, you didn't use hg to actually create a 
clone of the repository. I'd recommend creating a proper clone.

>  2. When I took jtreg 4.2-b12, most tests passes, but I still fail at:
>     /D rectory
>     "C:\jdk11u-11.0.2-ga\build\windows-x86_64-normal-server-release\testoutput\jaxp_all\JTwork"
>     not found: creating^M
>     Directory
>     "C:\jdk11u-11.0.2-ga\build\windows-x86_64-normal-server-release\testoutput\jaxp_all\JTreport"
>     not found: creating^M
>     Error: Unexpected exception occurred! java.lang.NoSuchMethodError:
>     com.sun.javatest.regtest.agent.JDK_Version.compareTo(Lcom/sun/javatest/regtest/agent/JDK_Version;)I^M
>     java.lang.NoSuchMethodError:
>     com.sun.javatest.regtest.agent.JDK_Version.compareTo(Lcom/sun/javatest/regtest/agent/JDK_Version;)I^M
>      ? ? ? ? at
>     com.sun.javatest.regtest.config.JDK.getSystemModules(JDK.java:405)^M
>      ? ? ? ? at

I suggest you take that to jtreg-use at openjdk.java.net. They should be 
able to help.

David
-----

>     com.sun.javatest.regtest.config.RegressionParameters.getModulesFilter(RegressionParameters.java:202)^M
>      ? ? ? ? at
>     com.sun.javatest.regtest.config.RegressionParameters.getRelevantTestFilter(RegressionParameters.java:177)^M
>      ? ? ? ? at
>     com.sun.javatest.InterviewParameters.getFilters(InterviewParameters.java:767)^M
>      ? ? ? ? at
>     com.sun.javatest.Harness.createTreeIterator(Harness.java:811)^M
>      ? ? ? ? at com.sun.javatest.Harness.runTests(Harness.java:701)^M
>      ? ? ? ? at com.sun.javatest.Harness.batch(Harness.java:400)^M
>      ? ? ? ? at
>     com.sun.javatest.regtest.tool.Tool.batchHarness(Tool.java:1824)^M
>      ? ? ? ? at com.sun.javatest.regtest.tool.Tool.run(Tool.java:1216)^M
>      ? ? ? ? at com.sun.javatest.regtest.tool.Tool.run(Tool.java:962)^M
>      ? ? ? ? at com.sun.javatest.regtest.tool.Tool.main(Tool.java:134)^M
>      ? ? ? ? at com.sun.javatest.regtest.Main.main(Main.java:58)^M
>     Missing file:
>     C:/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/testoutput/jaxp_all/JTreport/text/summary.txt
>     EXIT CODE: 6/
> 
> 
> 
> 
> ??, 5 ???. 2019 ?. ? 02:25, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>>:
> 
>     On 5/06/2019 2:20 am, Moshe Zuisman wrote:
>      > Hi. Thank for your recomendation!
>      > Although I did not success to run "hg update -r jdk-11.0.2-ga" -
>     got :
>      > "abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga'
>     (.hg not
>      > found)!"
> 
>     I don't know how you are "cloning" things but you are not getting an
>     actual mercurial repository out of the process!
> 
>      > But since I from begining cloned?jdk-11.0.2 label form site - I
>     suppose
>      > it gives equavalent result.
>      >
>      > And finally I was able to pass compilation (make)
>      > But "make test" fails any where:
>      > to get it clear form begening - I donladed latest stabel jtreg and
>      > configured with it:
>      >? ?./configure --with-jtreg=/cygdrive/c/jtreg
> 
>     Latest jtreg may not be suitable for 11u. The specified version
>     (make/conf/jib-profiles.js) is 4.2-b12
> 
>     David
>     -----
> 
>      > /$ make test
>      > Building target 'test' in configuration
>      > 'windows-x86_64-normal-server-release'
>      > Warning: No mercurial configuration present and no .src-rev
>      > Compiling 31 files for BUILD_JRTFS
>      > Compiling 27 files for BUILD_FAILURE_HANDLER
>      > Creating support/test/failure_handler/timeoutHandler.dll from 1
>     file(s)
>      > Creating support/modules_libs/java.base/jrt-fs.jar
>      >
>     c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
> 
>      > error: no suitable method found for save(Map<CAP#1,CAP#2>)
>      >? ? ? ? ? rp.save(map);
>      >? ? ? ? ? ? ^
>      >? ? ? method InterviewParameters.save(File) is not applicable
>      >? ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted
>     to File)
>      >? ? ? method InterviewParameters.save(Map<String,String>) is not
>     applicable
>      >? ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
>      > Map<String,String>)
>      >? ? where CAP#1,CAP#2 are fresh type-variables:
>      >? ? ? CAP#1 extends Object from capture of ?
>      >? ? ? CAP#2 extends Object from capture of ?
>      > Note: Some input files use or override a deprecated API.
>      > Note: Recompile with -Xlint:deprecation for details.
>      > Note: Some messages have been simplified; recompile with
>     -Xdiags:verbose
>      > to get full output
>      > 1 error
>      > make[3]: *** [BuildFailureHandler.gmk:54:
>      >
>     /cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch]
> 
>      > Error 1
>      > make[2]: *** [make/Main.gmk:516: build-test-failure-handler] Error 2
>      > make[2]: *** Waiting for unfinished jobs....
>      >
>      > ERROR: Build failed for target 'test' in configuration
>      > 'windows-x86_64-normal-server-release' (exit code 2)
>      > Stopping sjavac server
>      >
>      > === Output from failing command(s) repeated here ===
>      > * For target
>      >
>     support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:
>      >
>     c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
> 
>      > error: no suitable method found for save(Map<CAP#1,CAP#2>)
>      >? ? ? ? ? rp.save(map);
>      >? ? ? ? ? ? ^
>      >? ? ? method InterviewParameters.save(File) is not applicable
>      >? ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted
>     to File)
>      >? ? ? method InterviewParameters.save(Map<String,String>) is not
>     applicable
>      >? ? ? ? (argument mismatch; Map<CAP#1,CAP#2> cannot be converted to
>      > Map<String,String>)
>      >? ? where CAP#1,CAP#2 are fresh type-variables:
>      >? ? ? CAP#1 extends Object from capture of ?
>      >? ? ? CAP#2 extends Object from capture of ?
>      > Note: Some input files use or override a deprecated API.
>      > Note: Recompile with -Xlint:deprecation for details.
>      >? ? ?... (rest of output omitted)
>      >
>      > * All command lines available in
>      >
>     /cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/make-support/failure-logs.
>      > === End of repeated output ===
>      >
>      > No indication of failed target found.
>      > Hint: Try searching the build log for '] Error'.
>      > Hint: See doc/building.html#troubleshooting for assistance.
>      >
>      > make[1]: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:305:
>     main] Error 2
>      > make: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:186: test]
>     Error 2
>      > /
>      >
>      > ??, 3 ???. 2019 ?. ? 10:20, David Holmes <david.holmes at oracle.com
>     <mailto:david.holmes at oracle.com>
>      > <mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>>>:
>      >
>      >? ? ?On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
>      >? ? ? > Hi.
>      >? ? ? > Probably I do not understand something in source control
>     system
>      >? ? ?of Open
>      >? ? ? > JDK projeck.
>      >? ? ? > I have gone to :
>      >? ? ? > https://hg.openjdk.java.net/jdk/jdk11
>      >? ? ? > and clicked last label:
>      >? ? ? > "9 months ago jwilhelm Added tag jdk-11+28 for changeset
>      >? ? ? > 76072a077ee1default tip"
>      >? ? ? > arrived to:
>      >? ? ? > https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
>      >? ? ? > and downloaded zip with sources.
>      >
>      >? ? ?Thats JDK 11 GA version.
>      >
>      >? ? ? > How have I to download latest fixed source of JDK 11.0.2?
>      >
>      >? ? ?11.0.2 is one of the JDK 11 update releases. You previously
>     indicated
>      >? ? ?that you were using 11u sources at:
>      >
>      > http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
>      >
>      >? ? ?which seems to be a somewhat arbitrary point in 11u
>     development. If you
>      >? ? ?want a specific release, rather than latest dev sources then
>     use the
>      >? ? ?appropriate tag to update your sources to that level:
>      >
>      > http://hg.openjdk.java.net/jdk-updates/jdk11u/tags
>      >
>      >? ? ?So if you clone
>      >
>      > http://hg.openjdk.java.net/jdk-updates/jdk11u/
>      >
>      >? ? ?then do:
>      >
>      >? ? ?hg update -r jdk-11.0.2-ga
>      >
>      >? ? ?that should get you to the final 11.0.2 sources.
>      >
>      >? ? ?That all said, the fix Kim was referring to appears to have
>     gone into
>      >? ? ?11u 3 months before the date of the sources you indicated you
>     were
>      >? ? ?using.
>      >
>      >? ? ?Hope that helps.
>      >
>      >? ? ?David
>      >? ? ?-----
>      >
>      >? ? ? >
>      >? ? ? > ??, 3 ???. 2019 ?. ? 00:34, Kim Barrett
>     <kim.barrett at oracle.com <mailto:kim.barrett at oracle.com>
>      >? ? ?<mailto:kim.barrett at oracle.com <mailto:kim.barrett at oracle.com>>
>      >? ? ? > <mailto:kim.barrett at oracle.com
>     <mailto:kim.barrett at oracle.com> <mailto:kim.barrett at oracle.com
>     <mailto:kim.barrett at oracle.com>>>>:
>      >? ? ? >
>      >? ? ? >? ? ? > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman
>      >? ? ?<zuismanm at gmail.com <mailto:zuismanm at gmail.com>
>     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>
>      >? ? ? >? ? ?<mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>
>     <mailto:zuismanm at gmail.com <mailto:zuismanm at gmail.com>>>> wrote:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? > Hi David.
>      >? ? ? >? ? ? > I have updated to Visual studio 2017 15.9.12.
>      >? ? ? >? ? ? > Build still fails, while now works much longer and pass
>      >? ? ?much more
>      >? ? ? >? ? ?steps:
>      >? ? ? >? ? ? >
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?details.c:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
>      >? ? ? >? ? ? > error C2220: warning treated as error -o 'object' file
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?generatedc:/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341):
>      >? ? ? >? ? ? > warning C4305: 'argument': truncation fm 'const
>     intx' to
>      >? ? ? >? ? ?'double'make[3]:
>      >? ? ? >? ? ? > *** [lib/CompileJvm.gmk:151:
>      >? ? ? >? ? ? >
>      >? ? ? >
>      >     
>      ?/cygdrive/c/Git_Repos/open_jdk_11/jdk11-1ddf9a99e4ad/jdk11-1ddf9a99e4ad/build/windows-x86_64-normal-server-release/hotspot/riant-server/libjvm/objs/jvmFlagRangeList.obj]
>      >? ? ? >? ? ? > Error 1make[3]: *** Waiting for unfinished
>      >? ? ?jobs....make[2]: ***
>      >? ? ? >
>      >? ? ? >? ? ?This looks like JDK-8212052, which is marked as fixed
>     in JDK
>      >? ? ?11.0.2.
>      >? ? ? >
>      >? ? ? >
>      >
> 


From jonathan.gibbons at oracle.com  Wed Jun  5 15:21:04 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 5 Jun 2019 08:21:04 -0700
Subject: RFR XXS,docs JDK-8225346: Convert file to HTML5
Message-ID: <0619e7fe-80d2-009d-66be-4ac2ba70bc40@oracle.com>

Please review a trivial fix to change the doctype for a file from HTML 4 
to HTML 5. This gets the file off the doccheck radar.

No webrev; patch below.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8225346

$ hg diff -R open
diff -r f4df9d4201cc make/data/docs-resources/index.html
--- a/make/data/docs-resources/index.html??? Tue Jun 04 16:50:25 2019 -0700
+++ b/make/data/docs-resources/index.html??? Wed Jun 05 08:11:55 2019 -0700
@@ -1,4 +1,4 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<!DOCTYPE html>
 ?<!--
 ? Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
 ? DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.




From lance.andersen at oracle.com  Wed Jun  5 15:21:55 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 5 Jun 2019 11:21:55 -0400
Subject: RFR XXS,docs JDK-8225346: Convert file to HTML5
In-Reply-To: <0619e7fe-80d2-009d-66be-4ac2ba70bc40@oracle.com>
References: <0619e7fe-80d2-009d-66be-4ac2ba70bc40@oracle.com>
Message-ID: <745C1658-441B-4501-9331-861B362D0E7D@oracle.com>

+1
> On Jun 5, 2019, at 11:21 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a trivial fix to change the doctype for a file from HTML 4 to HTML 5. This gets the file off the doccheck radar.
> 
> No webrev; patch below.
> 
> -- Jon
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225346
> 
> $ hg diff -R open
> diff -r f4df9d4201cc make/data/docs-resources/index.html
> --- a/make/data/docs-resources/index.html    Tue Jun 04 16:50:25 2019 -0700
> +++ b/make/data/docs-resources/index.html    Wed Jun 05 08:11:55 2019 -0700
> @@ -1,4 +1,4 @@
> -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
> +<!DOCTYPE html>
>  <!--
>   Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
>   DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>





From erik.joelsson at oracle.com  Wed Jun  5 15:37:06 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Jun 2019 08:37:06 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
Message-ID: <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>

Hello Ao Qi,

In my testing, I tried building ppc64le (which I first identified as 
generating a UnixConstants.java that differed from an x64 build). With 
this patch, the buildjdk and target version of UnixConstants.java differ 
the same way. How did you configure your build? I'm suspecting something 
in the setup of the buildjdk compilers is different from my configuration.

/Erik

On 2019-06-04 21:48, Ao Qi wrote:
> Hi Erik,
>
> Thank you a lot for taking care of this. I mainly like your approach.
> I tested the patch by cross building mips64-zero, by which we found
> this problem. However, it seems the problem still exists. The reason I
> found is that UnixConstants.java of buildjdk is generated by cross
> compiler, so the macro definitions are defined by the target. Here is
> a preliminary workaround for your reference only (only worked for
> gcc):
>
> $ hg diff make/gensrc/GensrcMisc.gmk
> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> @@ -61,6 +61,13 @@
>     CPP_FLAGS += -nologo
>   endif
>
> +ifeq ($(CREATING_BUILDJDK), true)
> +  # Only worked for gcc
> +  TEMP_CPP=gcc -E
> +else
> +  TEMP_CPP=$(CPP)
> +endif
> +
>   # Generate a java source file from a template through the C
> preprocessor for the
>   # target system. First extract the copyright notice at the start of the file.
>   # Run the preprocessor. Filter out the default compiler stderr output on
> @@ -71,7 +78,7 @@
>   define generate-preproc-src
>    $(call MakeDir, $(@D))
>    ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>          2> >($(GREP) -v '^$(<F)$$' >&2) \
>          | $(NAWK) '/@@START_HERE@@/,0' \
>          |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> FILE - DO NOT EDIT/' \
>
>
> Cheers,
> Ao Qi
>
> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Thanks!
>>
>> During testing, I found an intermittent race issue. The command line
>> that runs the interim langtools version of javac still always points to
>> the buildtools/interim-langtools dir of the normal build. This variable
>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
>> changed in buildjdk-spec.gmk.in:
>>
>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>>
>> /Erik
>>
>> On 2019-06-04 07:53, Tim Bell wrote:
>>> Erik:
>>>
>>> Looks good.
>>>
>>> Tim
>>>
>>>> This is a fix for a problem brought up on this list [1]. The main issue
>>>> is that when cross compiling, and creating a buildjdk during the build,
>>>> the UnixConstants.java cannot necessarily be reused between the target
>>>> JDK and the buildjdk. While investigating this, I came to the conclusion
>>>> that we really should stop trying to reuse anything between the buildjdk
>>>> and target JDK. It's just becoming too complex to maintain (due to the
>>>> intricate interactions with the interim-image, generate-link-opt-data
>>>> and exploded-image-optimize targets, causing circular dependencies and
>>>> endless incremental rebuilds).
>>>>
>>>> So this fix simply removes all the reuse of buildtools, gensrc and java
>>>> compilation when creating a buildjdk. Hopefully this is making Main.gmk
>>>> a bit less convoluted.
>>>>
>>>> While working on this, I came up with the idea of adding a log prefix
>>>> functionality, to more easily discern which log lines were printed by
>>>> the buildjdk build and which were part of the normal build. I liked this
>>>> a lot so including that in the same fix, and applied it to the bootcycle
>>>> build as well.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>>>>
>>>> /Erik
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
>>>>
>>>
>>>


From erik.joelsson at oracle.com  Wed Jun  5 16:06:06 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Jun 2019 09:06:06 -0700
Subject: RFR XXS,docs JDK-8225346: Convert file to HTML5
In-Reply-To: <0619e7fe-80d2-009d-66be-4ac2ba70bc40@oracle.com>
References: <0619e7fe-80d2-009d-66be-4ac2ba70bc40@oracle.com>
Message-ID: <025204d7-1882-9d0c-afb2-c4ef32a1b414@oracle.com>

Looks good.

/Erik

On 2019-06-05 08:21, Jonathan Gibbons wrote:
> Please review a trivial fix to change the doctype for a file from HTML 
> 4 to HTML 5. This gets the file off the doccheck radar.
>
> No webrev; patch below.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225346
>
> $ hg diff -R open
> diff -r f4df9d4201cc make/data/docs-resources/index.html
> --- a/make/data/docs-resources/index.html??? Tue Jun 04 16:50:25 2019 
> -0700
> +++ b/make/data/docs-resources/index.html??? Wed Jun 05 08:11:55 2019 
> -0700
> @@ -1,4 +1,4 @@
> -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
> +<!DOCTYPE html>
> ?<!--
> ? Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> ? DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>
>


From erik.joelsson at oracle.com  Wed Jun  5 17:33:47 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Jun 2019 10:33:47 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
 <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
Message-ID: <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>

Never mind, I found the issue. The reason it worked for me was that we 
set SYSROOT_CFLAGS for both the target and the build compiler (from 
using devkits for them). The preprocessor for the target would then act 
correctly given the --sysroot parameter pointing to a sysroot for the 
build system.

I'm working on a patch where PPC gets overridden with the build compiler 
in buildjdk-spec.gmk.

/Erik

On 2019-06-05 08:37, Erik Joelsson wrote:
> Hello Ao Qi,
>
> In my testing, I tried building ppc64le (which I first identified as 
> generating a UnixConstants.java that differed from an x64 build). With 
> this patch, the buildjdk and target version of UnixConstants.java 
> differ the same way. How did you configure your build? I'm suspecting 
> something in the setup of the buildjdk compilers is different from my 
> configuration.
>
> /Erik
>
> On 2019-06-04 21:48, Ao Qi wrote:
>> Hi Erik,
>>
>> Thank you a lot for taking care of this. I mainly like your approach.
>> I tested the patch by cross building mips64-zero, by which we found
>> this problem. However, it seems the problem still exists. The reason I
>> found is that UnixConstants.java of buildjdk is generated by cross
>> compiler, so the macro definitions are defined by the target. Here is
>> a preliminary workaround for your reference only (only worked for
>> gcc):
>>
>> $ hg diff make/gensrc/GensrcMisc.gmk
>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
>> @@ -61,6 +61,13 @@
>> ??? CPP_FLAGS += -nologo
>> ? endif
>>
>> +ifeq ($(CREATING_BUILDJDK), true)
>> +? # Only worked for gcc
>> +? TEMP_CPP=gcc -E
>> +else
>> +? TEMP_CPP=$(CPP)
>> +endif
>> +
>> ? # Generate a java source file from a template through the C
>> preprocessor for the
>> ? # target system. First extract the copyright notice at the start of 
>> the file.
>> ? # Run the preprocessor. Filter out the default compiler stderr 
>> output on
>> @@ -71,7 +78,7 @@
>> ? define generate-preproc-src
>> ?? $(call MakeDir, $(@D))
>> ?? ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
>> -?? $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>> +?? $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>> ???????? 2> >($(GREP) -v '^$(<F)$$' >&2) \
>> ???????? | $(NAWK) '/@@START_HERE@@/,0' \
>> ???????? |? $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
>> FILE - DO NOT EDIT/' \
>>
>>
>> Cheers,
>> Ao Qi
>>
>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson 
>> <erik.joelsson at oracle.com> wrote:
>>> Thanks!
>>>
>>> During testing, I found an intermittent race issue. The command line
>>> that runs the interim langtools version of javac still always points to
>>> the buildtools/interim-langtools dir of the normal build. This variable
>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
>>> changed in buildjdk-spec.gmk.in:
>>>
>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>>>
>>> /Erik
>>>
>>> On 2019-06-04 07:53, Tim Bell wrote:
>>>> Erik:
>>>>
>>>> Looks good.
>>>>
>>>> Tim
>>>>
>>>>> This is a fix for a problem brought up on this list [1]. The main 
>>>>> issue
>>>>> is that when cross compiling, and creating a buildjdk during the 
>>>>> build,
>>>>> the UnixConstants.java cannot necessarily be reused between the 
>>>>> target
>>>>> JDK and the buildjdk. While investigating this, I came to the 
>>>>> conclusion
>>>>> that we really should stop trying to reuse anything between the 
>>>>> buildjdk
>>>>> and target JDK. It's just becoming too complex to maintain (due to 
>>>>> the
>>>>> intricate interactions with the interim-image, generate-link-opt-data
>>>>> and exploded-image-optimize targets, causing circular dependencies 
>>>>> and
>>>>> endless incremental rebuilds).
>>>>>
>>>>> So this fix simply removes all the reuse of buildtools, gensrc and 
>>>>> java
>>>>> compilation when creating a buildjdk. Hopefully this is making 
>>>>> Main.gmk
>>>>> a bit less convoluted.
>>>>>
>>>>> While working on this, I came up with the idea of adding a log prefix
>>>>> functionality, to more easily discern which log lines were printed by
>>>>> the buildjdk build and which were part of the normal build. I 
>>>>> liked this
>>>>> a lot so including that in the same fix, and applied it to the 
>>>>> bootcycle
>>>>> build as well.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>>>>>
>>>>> Webrev: 
>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>>>>>
>>>>> /Erik
>>>>>
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html 
>>>>>
>>>>>
>>>>
>>>>


From erik.joelsson at oracle.com  Wed Jun  5 20:46:52 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Jun 2019 13:46:52 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
 <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
 <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>
Message-ID: <e1ede98d-0bca-009a-76cf-77ef07360657@oracle.com>

Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03

The change is in buildjdk-spec.gmk.in where CPP is now also overridden.

/Erik

On 2019-06-05 10:33, Erik Joelsson wrote:
> Never mind, I found the issue. The reason it worked for me was that we 
> set SYSROOT_CFLAGS for both the target and the build compiler (from 
> using devkits for them). The preprocessor for the target would then 
> act correctly given the --sysroot parameter pointing to a sysroot for 
> the build system.
>
> I'm working on a patch where PPC gets overridden with the build 
> compiler in buildjdk-spec.gmk.
>
> /Erik
>
> On 2019-06-05 08:37, Erik Joelsson wrote:
>> Hello Ao Qi,
>>
>> In my testing, I tried building ppc64le (which I first identified as 
>> generating a UnixConstants.java that differed from an x64 build). 
>> With this patch, the buildjdk and target version of 
>> UnixConstants.java differ the same way. How did you configure your 
>> build? I'm suspecting something in the setup of the buildjdk 
>> compilers is different from my configuration.
>>
>> /Erik
>>
>> On 2019-06-04 21:48, Ao Qi wrote:
>>> Hi Erik,
>>>
>>> Thank you a lot for taking care of this. I mainly like your approach.
>>> I tested the patch by cross building mips64-zero, by which we found
>>> this problem. However, it seems the problem still exists. The reason I
>>> found is that UnixConstants.java of buildjdk is generated by cross
>>> compiler, so the macro definitions are defined by the target. Here is
>>> a preliminary workaround for your reference only (only worked for
>>> gcc):
>>>
>>> $ hg diff make/gensrc/GensrcMisc.gmk
>>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
>>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
>>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
>>> @@ -61,6 +61,13 @@
>>> ??? CPP_FLAGS += -nologo
>>> ? endif
>>>
>>> +ifeq ($(CREATING_BUILDJDK), true)
>>> +? # Only worked for gcc
>>> +? TEMP_CPP=gcc -E
>>> +else
>>> +? TEMP_CPP=$(CPP)
>>> +endif
>>> +
>>> ? # Generate a java source file from a template through the C
>>> preprocessor for the
>>> ? # target system. First extract the copyright notice at the start 
>>> of the file.
>>> ? # Run the preprocessor. Filter out the default compiler stderr 
>>> output on
>>> @@ -71,7 +78,7 @@
>>> ? define generate-preproc-src
>>> ?? $(call MakeDir, $(@D))
>>> ?? ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
>>> -?? $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>>> +?? $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>>> ???????? 2> >($(GREP) -v '^$(<F)$$' >&2) \
>>> ???????? | $(NAWK) '/@@START_HERE@@/,0' \
>>> ???????? |? $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
>>> FILE - DO NOT EDIT/' \
>>>
>>>
>>> Cheers,
>>> Ao Qi
>>>
>>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson 
>>> <erik.joelsson at oracle.com> wrote:
>>>> Thanks!
>>>>
>>>> During testing, I found an intermittent race issue. The command line
>>>> that runs the interim langtools version of javac still always 
>>>> points to
>>>> the buildtools/interim-langtools dir of the normal build. This 
>>>> variable
>>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
>>>> changed in buildjdk-spec.gmk.in:
>>>>
>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>>>>
>>>> /Erik
>>>>
>>>> On 2019-06-04 07:53, Tim Bell wrote:
>>>>> Erik:
>>>>>
>>>>> Looks good.
>>>>>
>>>>> Tim
>>>>>
>>>>>> This is a fix for a problem brought up on this list [1]. The main 
>>>>>> issue
>>>>>> is that when cross compiling, and creating a buildjdk during the 
>>>>>> build,
>>>>>> the UnixConstants.java cannot necessarily be reused between the 
>>>>>> target
>>>>>> JDK and the buildjdk. While investigating this, I came to the 
>>>>>> conclusion
>>>>>> that we really should stop trying to reuse anything between the 
>>>>>> buildjdk
>>>>>> and target JDK. It's just becoming too complex to maintain (due 
>>>>>> to the
>>>>>> intricate interactions with the interim-image, 
>>>>>> generate-link-opt-data
>>>>>> and exploded-image-optimize targets, causing circular 
>>>>>> dependencies and
>>>>>> endless incremental rebuilds).
>>>>>>
>>>>>> So this fix simply removes all the reuse of buildtools, gensrc 
>>>>>> and java
>>>>>> compilation when creating a buildjdk. Hopefully this is making 
>>>>>> Main.gmk
>>>>>> a bit less convoluted.
>>>>>>
>>>>>> While working on this, I came up with the idea of adding a log 
>>>>>> prefix
>>>>>> functionality, to more easily discern which log lines were 
>>>>>> printed by
>>>>>> the buildjdk build and which were part of the normal build. I 
>>>>>> liked this
>>>>>> a lot so including that in the same fix, and applied it to the 
>>>>>> bootcycle
>>>>>> build as well.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>>>>>>
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html 
>>>>>>
>>>>>>
>>>>>
>>>>>


From joe.darcy at oracle.com  Wed Jun  5 21:40:24 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 05 Jun 2019 14:40:24 -0700
Subject: JDK 14 RFR of JDK-8214546: Start of release updates for JDK 14
Message-ID: <5CF836C8.8070609@oracle.com>

Hello,

Please have an early review the start-of-release builds updates for JDK 
14 ahead of the upcoming fork:

     http://cr.openjdk.java.net/~darcy/jdk14-fork.2/

Unlike previous start-of-release changesets, this one also includes the 
"symbol" data used by javac --release.

After the next JDK 13 build promotes, I'll do a clean regeneration of  
the symbol data based on that build. I'll also resync and do at least 
one more build and test cycle, etc.

Thanks,

-Joe

--- old/make/autoconf/version-numbers    2019-05-17 09:42:34.896000000 -0700
+++ new/make/autoconf/version-numbers    2019-05-17 09:42:34.532000000 -0700
@@ -25,18 +25,18 @@

  # Default version numbers to use unless overridden by configure

-DEFAULT_VERSION_FEATURE=13
+DEFAULT_VERSION_FEATURE=14
  DEFAULT_VERSION_INTERIM=0
  DEFAULT_VERSION_UPDATE=0
  DEFAULT_VERSION_PATCH=0
  DEFAULT_VERSION_EXTRA1=0
  DEFAULT_VERSION_EXTRA2=0
  DEFAULT_VERSION_EXTRA3=0
-DEFAULT_VERSION_DATE=2019-09-17
-DEFAULT_VERSION_CLASSFILE_MAJOR=57  # "`$EXPR $DEFAULT_VERSION_FEATURE 
+ 44`"
+DEFAULT_VERSION_DATE=2020-03-17
+DEFAULT_VERSION_CLASSFILE_MAJOR=58  # "`$EXPR $DEFAULT_VERSION_FEATURE 
+ 44`"
  DEFAULT_VERSION_CLASSFILE_MINOR=0
-DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13"
-DEFAULT_JDK_SOURCE_TARGET_VERSION=13
+DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13 14"
+DEFAULT_JDK_SOURCE_TARGET_VERSION=14
  DEFAULT_PROMOTED_VERSION_PRE=ea

  LAUNCHER_NAME=openjdk



From erik.joelsson at oracle.com  Wed Jun  5 22:00:24 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 5 Jun 2019 15:00:24 -0700
Subject: JDK 14 RFR of JDK-8214546: Start of release updates for JDK 14
In-Reply-To: <5CF836C8.8070609@oracle.com>
References: <5CF836C8.8070609@oracle.com>
Message-ID: <1748488a-a01c-0c6d-0ac9-18ecbfbe6864@oracle.com>

The build changes look good, and I'm happy to see that we are now down 
to just changing the version-numbers file.

/Erik

On 2019-06-05 14:40, Joseph D. Darcy wrote:
> Hello,
>
> Please have an early review the start-of-release builds updates for 
> JDK 14 ahead of the upcoming fork:
>
> ??? http://cr.openjdk.java.net/~darcy/jdk14-fork.2/
>
> Unlike previous start-of-release changesets, this one also includes 
> the "symbol" data used by javac --release.
>
> After the next JDK 13 build promotes, I'll do a clean regeneration of? 
> the symbol data based on that build. I'll also resync and do at least 
> one more build and test cycle, etc.
>
> Thanks,
>
> -Joe
>
> --- old/make/autoconf/version-numbers??? 2019-05-17 09:42:34.896000000 
> -0700
> +++ new/make/autoconf/version-numbers??? 2019-05-17 09:42:34.532000000 
> -0700
> @@ -25,18 +25,18 @@
>
> ?# Default version numbers to use unless overridden by configure
>
> -DEFAULT_VERSION_FEATURE=13
> +DEFAULT_VERSION_FEATURE=14
> ?DEFAULT_VERSION_INTERIM=0
> ?DEFAULT_VERSION_UPDATE=0
> ?DEFAULT_VERSION_PATCH=0
> ?DEFAULT_VERSION_EXTRA1=0
> ?DEFAULT_VERSION_EXTRA2=0
> ?DEFAULT_VERSION_EXTRA3=0
> -DEFAULT_VERSION_DATE=2019-09-17
> -DEFAULT_VERSION_CLASSFILE_MAJOR=57? # "`$EXPR 
> $DEFAULT_VERSION_FEATURE + 44`"
> +DEFAULT_VERSION_DATE=2020-03-17
> +DEFAULT_VERSION_CLASSFILE_MAJOR=58? # "`$EXPR 
> $DEFAULT_VERSION_FEATURE + 44`"
> ?DEFAULT_VERSION_CLASSFILE_MINOR=0
> -DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13"
> -DEFAULT_JDK_SOURCE_TARGET_VERSION=13
> +DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13 14"
> +DEFAULT_JDK_SOURCE_TARGET_VERSION=14
> ?DEFAULT_PROMOTED_VERSION_PRE=ea
>
> ?LAUNCHER_NAME=openjdk
>


From david.holmes at oracle.com  Wed Jun  5 23:05:32 2019
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 6 Jun 2019 09:05:32 +1000
Subject: JDK 14 RFR of JDK-8214546: Start of release updates for JDK 14
In-Reply-To: <1748488a-a01c-0c6d-0ac9-18ecbfbe6864@oracle.com>
References: <5CF836C8.8070609@oracle.com>
 <1748488a-a01c-0c6d-0ac9-18ecbfbe6864@oracle.com>
Message-ID: <ad28cafc-6e79-6c80-d67d-46b241790efa@oracle.com>

+1 :)

David

On 6/06/2019 8:00 am, Erik Joelsson wrote:
> The build changes look good, and I'm happy to see that we are now down 
> to just changing the version-numbers file.
> 
> /Erik
> 
> On 2019-06-05 14:40, Joseph D. Darcy wrote:
>> Hello,
>>
>> Please have an early review the start-of-release builds updates for 
>> JDK 14 ahead of the upcoming fork:
>>
>> ??? http://cr.openjdk.java.net/~darcy/jdk14-fork.2/
>>
>> Unlike previous start-of-release changesets, this one also includes 
>> the "symbol" data used by javac --release.
>>
>> After the next JDK 13 build promotes, I'll do a clean regeneration of 
>> the symbol data based on that build. I'll also resync and do at least 
>> one more build and test cycle, etc.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/make/autoconf/version-numbers??? 2019-05-17 09:42:34.896000000 
>> -0700
>> +++ new/make/autoconf/version-numbers??? 2019-05-17 09:42:34.532000000 
>> -0700
>> @@ -25,18 +25,18 @@
>>
>> ?# Default version numbers to use unless overridden by configure
>>
>> -DEFAULT_VERSION_FEATURE=13
>> +DEFAULT_VERSION_FEATURE=14
>> ?DEFAULT_VERSION_INTERIM=0
>> ?DEFAULT_VERSION_UPDATE=0
>> ?DEFAULT_VERSION_PATCH=0
>> ?DEFAULT_VERSION_EXTRA1=0
>> ?DEFAULT_VERSION_EXTRA2=0
>> ?DEFAULT_VERSION_EXTRA3=0
>> -DEFAULT_VERSION_DATE=2019-09-17
>> -DEFAULT_VERSION_CLASSFILE_MAJOR=57? # "`$EXPR 
>> $DEFAULT_VERSION_FEATURE + 44`"
>> +DEFAULT_VERSION_DATE=2020-03-17
>> +DEFAULT_VERSION_CLASSFILE_MAJOR=58? # "`$EXPR 
>> $DEFAULT_VERSION_FEATURE + 44`"
>> ?DEFAULT_VERSION_CLASSFILE_MINOR=0
>> -DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13"
>> -DEFAULT_JDK_SOURCE_TARGET_VERSION=13
>> +DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13 14"
>> +DEFAULT_JDK_SOURCE_TARGET_VERSION=14
>> ?DEFAULT_PROMOTED_VERSION_PRE=ea
>>
>> ?LAUNCHER_NAME=openjdk
>>


From mikael.vidstedt at oracle.com  Thu Jun  6 00:51:36 2019
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Wed, 5 Jun 2019 17:51:36 -0700
Subject: JDK 14 RFR of JDK-8214546: Start of release updates for JDK 14
In-Reply-To: <5CF836C8.8070609@oracle.com>
References: <5CF836C8.8070609@oracle.com>
Message-ID: <3E5F4DBF-A342-426A-9662-135597C65BB6@oracle.com>


Looks good! Still a bunch of mechanical changes, but it?s far from obvious that spending more time automating this will save any significant time.

Cheers,
Mikael

> On Jun 5, 2019, at 2:40 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please have an early review the start-of-release builds updates for JDK 14 ahead of the upcoming fork:
> 
>    http://cr.openjdk.java.net/~darcy/jdk14-fork.2/
> 
> Unlike previous start-of-release changesets, this one also includes the "symbol" data used by javac --release.
> 
> After the next JDK 13 build promotes, I'll do a clean regeneration of  the symbol data based on that build. I'll also resync and do at least one more build and test cycle, etc.
> 
> Thanks,
> 
> -Joe
> 
> --- old/make/autoconf/version-numbers    2019-05-17 09:42:34.896000000 -0700
> +++ new/make/autoconf/version-numbers    2019-05-17 09:42:34.532000000 -0700
> @@ -25,18 +25,18 @@
> 
> # Default version numbers to use unless overridden by configure
> 
> -DEFAULT_VERSION_FEATURE=13
> +DEFAULT_VERSION_FEATURE=14
> DEFAULT_VERSION_INTERIM=0
> DEFAULT_VERSION_UPDATE=0
> DEFAULT_VERSION_PATCH=0
> DEFAULT_VERSION_EXTRA1=0
> DEFAULT_VERSION_EXTRA2=0
> DEFAULT_VERSION_EXTRA3=0
> -DEFAULT_VERSION_DATE=2019-09-17
> -DEFAULT_VERSION_CLASSFILE_MAJOR=57  # "`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
> +DEFAULT_VERSION_DATE=2020-03-17
> +DEFAULT_VERSION_CLASSFILE_MAJOR=58  # "`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
> DEFAULT_VERSION_CLASSFILE_MINOR=0
> -DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13"
> -DEFAULT_JDK_SOURCE_TARGET_VERSION=13
> +DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13 14"
> +DEFAULT_JDK_SOURCE_TARGET_VERSION=14
> DEFAULT_PROMOTED_VERSION_PRE=ea
> 
> LAUNCHER_NAME=openjdk
> 



From joe.darcy at oracle.com  Thu Jun  6 01:02:48 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 05 Jun 2019 18:02:48 -0700
Subject: JDK 14 RFR of JDK-8214546: Start of release updates for JDK 14
In-Reply-To: <3E5F4DBF-A342-426A-9662-135597C65BB6@oracle.com>
References: <5CF836C8.8070609@oracle.com>
 <3E5F4DBF-A342-426A-9662-135597C65BB6@oracle.com>
Message-ID: <5CF86638.8050202@oracle.com>

Right; after several rounds of refinement, it is tedious but not 
difficult to make the current set of mechanical changes.

Adding the --release information in the initial push is a new 
improvement in this iteration.

The factor that bounds how fast this work can be done is the build + 
test cycle so I wouldn't judge any significant efforts to reduce the 
number of files that need to be modified to have favorable cost/benefit 
ratios.

Cheers,

-Joe

On 6/5/2019 5:51 PM, Mikael Vidstedt wrote:
> Looks good! Still a bunch of mechanical changes, but it?s far from obvious that spending more time automating this will save any significant time.
>
> Cheers,
> Mikael
>
>> On Jun 5, 2019, at 2:40 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>>
>> Hello,
>>
>> Please have an early review the start-of-release builds updates for JDK 14 ahead of the upcoming fork:
>>
>>     http://cr.openjdk.java.net/~darcy/jdk14-fork.2/
>>
>> Unlike previous start-of-release changesets, this one also includes the "symbol" data used by javac --release.
>>
>> After the next JDK 13 build promotes, I'll do a clean regeneration of  the symbol data based on that build. I'll also resync and do at least one more build and test cycle, etc.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/make/autoconf/version-numbers    2019-05-17 09:42:34.896000000 -0700
>> +++ new/make/autoconf/version-numbers    2019-05-17 09:42:34.532000000 -0700
>> @@ -25,18 +25,18 @@
>>
>> # Default version numbers to use unless overridden by configure
>>
>> -DEFAULT_VERSION_FEATURE=13
>> +DEFAULT_VERSION_FEATURE=14
>> DEFAULT_VERSION_INTERIM=0
>> DEFAULT_VERSION_UPDATE=0
>> DEFAULT_VERSION_PATCH=0
>> DEFAULT_VERSION_EXTRA1=0
>> DEFAULT_VERSION_EXTRA2=0
>> DEFAULT_VERSION_EXTRA3=0
>> -DEFAULT_VERSION_DATE=2019-09-17
>> -DEFAULT_VERSION_CLASSFILE_MAJOR=57  # "`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
>> +DEFAULT_VERSION_DATE=2020-03-17
>> +DEFAULT_VERSION_CLASSFILE_MAJOR=58  # "`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
>> DEFAULT_VERSION_CLASSFILE_MINOR=0
>> -DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13"
>> -DEFAULT_JDK_SOURCE_TARGET_VERSION=13
>> +DEFAULT_ACCEPTABLE_BOOT_VERSIONS="12 13 14"
>> +DEFAULT_JDK_SOURCE_TARGET_VERSION=14
>> DEFAULT_PROMOTED_VERSION_PRE=ea
>>
>> LAUNCHER_NAME=openjdk
>>



From aoqi at loongson.cn  Thu Jun  6 02:49:53 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Thu, 6 Jun 2019 10:49:53 +0800
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <e1ede98d-0bca-009a-76cf-77ef07360657@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
 <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
 <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>
 <e1ede98d-0bca-009a-76cf-77ef07360657@oracle.com>
Message-ID: <CALjzQn5qK-B=nmddZKXscfaNav6Y9XBsB3wUz4KvQUqmYYEvCw@mail.gmail.com>

On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>
> Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03

I (as an Author) am ok with this fix. mips64el zero cross build passed
and javac (to test open a file) worked.

UnixConstants.java of build:
.../usr/bin/cc -E -x c -I...

UnixConstants.java of target:
.../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
--sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...

Thanks,
Ao Qi
>
> The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
>
> /Erik
>
> On 2019-06-05 10:33, Erik Joelsson wrote:
> > Never mind, I found the issue. The reason it worked for me was that we
> > set SYSROOT_CFLAGS for both the target and the build compiler (from
> > using devkits for them). The preprocessor for the target would then
> > act correctly given the --sysroot parameter pointing to a sysroot for
> > the build system.
> >
> > I'm working on a patch where PPC gets overridden with the build
> > compiler in buildjdk-spec.gmk.
> >
> > /Erik
> >
> > On 2019-06-05 08:37, Erik Joelsson wrote:
> >> Hello Ao Qi,
> >>
> >> In my testing, I tried building ppc64le (which I first identified as
> >> generating a UnixConstants.java that differed from an x64 build).
> >> With this patch, the buildjdk and target version of
> >> UnixConstants.java differ the same way. How did you configure your
> >> build? I'm suspecting something in the setup of the buildjdk
> >> compilers is different from my configuration.
> >>
> >> /Erik
> >>
> >> On 2019-06-04 21:48, Ao Qi wrote:
> >>> Hi Erik,
> >>>
> >>> Thank you a lot for taking care of this. I mainly like your approach.
> >>> I tested the patch by cross building mips64-zero, by which we found
> >>> this problem. However, it seems the problem still exists. The reason I
> >>> found is that UnixConstants.java of buildjdk is generated by cross
> >>> compiler, so the macro definitions are defined by the target. Here is
> >>> a preliminary workaround for your reference only (only worked for
> >>> gcc):
> >>>
> >>> $ hg diff make/gensrc/GensrcMisc.gmk
> >>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> >>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> >>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> >>> @@ -61,6 +61,13 @@
> >>>     CPP_FLAGS += -nologo
> >>>   endif
> >>>
> >>> +ifeq ($(CREATING_BUILDJDK), true)
> >>> +  # Only worked for gcc
> >>> +  TEMP_CPP=gcc -E
> >>> +else
> >>> +  TEMP_CPP=$(CPP)
> >>> +endif
> >>> +
> >>>   # Generate a java source file from a template through the C
> >>> preprocessor for the
> >>>   # target system. First extract the copyright notice at the start
> >>> of the file.
> >>>   # Run the preprocessor. Filter out the default compiler stderr
> >>> output on
> >>> @@ -71,7 +78,7 @@
> >>>   define generate-preproc-src
> >>>    $(call MakeDir, $(@D))
> >>>    ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> >>> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> >>> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> >>>          2> >($(GREP) -v '^$(<F)$$' >&2) \
> >>>          | $(NAWK) '/@@START_HERE@@/,0' \
> >>>          |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> >>> FILE - DO NOT EDIT/' \
> >>>
> >>>
> >>> Cheers,
> >>> Ao Qi
> >>>
> >>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
> >>> <erik.joelsson at oracle.com> wrote:
> >>>> Thanks!
> >>>>
> >>>> During testing, I found an intermittent race issue. The command line
> >>>> that runs the interim langtools version of javac still always
> >>>> points to
> >>>> the buildtools/interim-langtools dir of the normal build. This
> >>>> variable
> >>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> >>>> changed in buildjdk-spec.gmk.in:
> >>>>
> >>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
> >>>>
> >>>> /Erik
> >>>>
> >>>> On 2019-06-04 07:53, Tim Bell wrote:
> >>>>> Erik:
> >>>>>
> >>>>> Looks good.
> >>>>>
> >>>>> Tim
> >>>>>
> >>>>>> This is a fix for a problem brought up on this list [1]. The main
> >>>>>> issue
> >>>>>> is that when cross compiling, and creating a buildjdk during the
> >>>>>> build,
> >>>>>> the UnixConstants.java cannot necessarily be reused between the
> >>>>>> target
> >>>>>> JDK and the buildjdk. While investigating this, I came to the
> >>>>>> conclusion
> >>>>>> that we really should stop trying to reuse anything between the
> >>>>>> buildjdk
> >>>>>> and target JDK. It's just becoming too complex to maintain (due
> >>>>>> to the
> >>>>>> intricate interactions with the interim-image,
> >>>>>> generate-link-opt-data
> >>>>>> and exploded-image-optimize targets, causing circular
> >>>>>> dependencies and
> >>>>>> endless incremental rebuilds).
> >>>>>>
> >>>>>> So this fix simply removes all the reuse of buildtools, gensrc
> >>>>>> and java
> >>>>>> compilation when creating a buildjdk. Hopefully this is making
> >>>>>> Main.gmk
> >>>>>> a bit less convoluted.
> >>>>>>
> >>>>>> While working on this, I came up with the idea of adding a log
> >>>>>> prefix
> >>>>>> functionality, to more easily discern which log lines were
> >>>>>> printed by
> >>>>>> the buildjdk build and which were part of the normal build. I
> >>>>>> liked this
> >>>>>> a lot so including that in the same fix, and applied it to the
> >>>>>> bootcycle
> >>>>>> build as well.
> >>>>>>
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
> >>>>>>
> >>>>>> Webrev:
> >>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
> >>>>>>
> >>>>>> /Erik
> >>>>>>
> >>>>>> [1]
> >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>


From aoqi at loongson.cn  Thu Jun  6 03:28:26 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Thu, 6 Jun 2019 11:28:26 +0800
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <CALjzQn5qK-B=nmddZKXscfaNav6Y9XBsB3wUz4KvQUqmYYEvCw@mail.gmail.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
 <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
 <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>
 <e1ede98d-0bca-009a-76cf-77ef07360657@oracle.com>
 <CALjzQn5qK-B=nmddZKXscfaNav6Y9XBsB3wUz4KvQUqmYYEvCw@mail.gmail.com>
Message-ID: <CALjzQn5REQt4WxWXiLJdA-cfpQ+OKoDyqyyv4XDaZ3atsePbow@mail.gmail.com>

On Thu, Jun 6, 2019 at 10:49 AM Ao Qi <aoqi at loongson.cn> wrote:
>
> On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson <erik.joelsson at oracle.com> wrote:
> >
> > Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03

Another question: should "[bootcycle] " be displayed during make
bootcycle-images? If yes, should we remove line 164 "LOG_PREFIX :=" of
http://cr.openjdk.java.net/~erikj/8217739/webrev.03/make/common/MakeBase.gmk.html
?

>
> I (as an Author) am ok with this fix. mips64el zero cross build passed
> and javac (to test open a file) worked.
>
> UnixConstants.java of build:
> .../usr/bin/cc -E -x c -I...
>
> UnixConstants.java of target:
> .../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
> --sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...
>
> Thanks,
> Ao Qi
> >
> > The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
> >
> > /Erik
> >
> > On 2019-06-05 10:33, Erik Joelsson wrote:
> > > Never mind, I found the issue. The reason it worked for me was that we
> > > set SYSROOT_CFLAGS for both the target and the build compiler (from
> > > using devkits for them). The preprocessor for the target would then
> > > act correctly given the --sysroot parameter pointing to a sysroot for
> > > the build system.
> > >
> > > I'm working on a patch where PPC gets overridden with the build
> > > compiler in buildjdk-spec.gmk.
> > >
> > > /Erik
> > >
> > > On 2019-06-05 08:37, Erik Joelsson wrote:
> > >> Hello Ao Qi,
> > >>
> > >> In my testing, I tried building ppc64le (which I first identified as
> > >> generating a UnixConstants.java that differed from an x64 build).
> > >> With this patch, the buildjdk and target version of
> > >> UnixConstants.java differ the same way. How did you configure your
> > >> build? I'm suspecting something in the setup of the buildjdk
> > >> compilers is different from my configuration.
> > >>
> > >> /Erik
> > >>
> > >> On 2019-06-04 21:48, Ao Qi wrote:
> > >>> Hi Erik,
> > >>>
> > >>> Thank you a lot for taking care of this. I mainly like your approach.
> > >>> I tested the patch by cross building mips64-zero, by which we found
> > >>> this problem. However, it seems the problem still exists. The reason I
> > >>> found is that UnixConstants.java of buildjdk is generated by cross
> > >>> compiler, so the macro definitions are defined by the target. Here is
> > >>> a preliminary workaround for your reference only (only worked for
> > >>> gcc):
> > >>>
> > >>> $ hg diff make/gensrc/GensrcMisc.gmk
> > >>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> > >>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> > >>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> > >>> @@ -61,6 +61,13 @@
> > >>>     CPP_FLAGS += -nologo
> > >>>   endif
> > >>>
> > >>> +ifeq ($(CREATING_BUILDJDK), true)
> > >>> +  # Only worked for gcc
> > >>> +  TEMP_CPP=gcc -E
> > >>> +else
> > >>> +  TEMP_CPP=$(CPP)
> > >>> +endif
> > >>> +
> > >>>   # Generate a java source file from a template through the C
> > >>> preprocessor for the
> > >>>   # target system. First extract the copyright notice at the start
> > >>> of the file.
> > >>>   # Run the preprocessor. Filter out the default compiler stderr
> > >>> output on
> > >>> @@ -71,7 +78,7 @@
> > >>>   define generate-preproc-src
> > >>>    $(call MakeDir, $(@D))
> > >>>    ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> > >>> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> > >>> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> > >>>          2> >($(GREP) -v '^$(<F)$$' >&2) \
> > >>>          | $(NAWK) '/@@START_HERE@@/,0' \
> > >>>          |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> > >>> FILE - DO NOT EDIT/' \
> > >>>
> > >>>
> > >>> Cheers,
> > >>> Ao Qi
> > >>>
> > >>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
> > >>> <erik.joelsson at oracle.com> wrote:
> > >>>> Thanks!
> > >>>>
> > >>>> During testing, I found an intermittent race issue. The command line
> > >>>> that runs the interim langtools version of javac still always
> > >>>> points to
> > >>>> the buildtools/interim-langtools dir of the normal build. This
> > >>>> variable
> > >>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> > >>>> changed in buildjdk-spec.gmk.in:
> > >>>>
> > >>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
> > >>>>
> > >>>> /Erik
> > >>>>
> > >>>> On 2019-06-04 07:53, Tim Bell wrote:
> > >>>>> Erik:
> > >>>>>
> > >>>>> Looks good.
> > >>>>>
> > >>>>> Tim
> > >>>>>
> > >>>>>> This is a fix for a problem brought up on this list [1]. The main
> > >>>>>> issue
> > >>>>>> is that when cross compiling, and creating a buildjdk during the
> > >>>>>> build,
> > >>>>>> the UnixConstants.java cannot necessarily be reused between the
> > >>>>>> target
> > >>>>>> JDK and the buildjdk. While investigating this, I came to the
> > >>>>>> conclusion
> > >>>>>> that we really should stop trying to reuse anything between the
> > >>>>>> buildjdk
> > >>>>>> and target JDK. It's just becoming too complex to maintain (due
> > >>>>>> to the
> > >>>>>> intricate interactions with the interim-image,
> > >>>>>> generate-link-opt-data
> > >>>>>> and exploded-image-optimize targets, causing circular
> > >>>>>> dependencies and
> > >>>>>> endless incremental rebuilds).
> > >>>>>>
> > >>>>>> So this fix simply removes all the reuse of buildtools, gensrc
> > >>>>>> and java
> > >>>>>> compilation when creating a buildjdk. Hopefully this is making
> > >>>>>> Main.gmk
> > >>>>>> a bit less convoluted.
> > >>>>>>
> > >>>>>> While working on this, I came up with the idea of adding a log
> > >>>>>> prefix
> > >>>>>> functionality, to more easily discern which log lines were
> > >>>>>> printed by
> > >>>>>> the buildjdk build and which were part of the normal build. I
> > >>>>>> liked this
> > >>>>>> a lot so including that in the same fix, and applied it to the
> > >>>>>> bootcycle
> > >>>>>> build as well.
> > >>>>>>
> > >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
> > >>>>>>
> > >>>>>> Webrev:
> > >>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
> > >>>>>>
> > >>>>>> /Erik
> > >>>>>>
> > >>>>>> [1]
> > >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>


From andy.herrick at oracle.com  Wed Jun  5 23:46:04 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 5 Jun 2019 19:46:04 -0400
Subject: RFR: JDK-8223080: Build team code review requests.
Message-ID: <9c0f12f0-ae74-6b49-fd9e-1dc79c4d9d49@oracle.com>

Please review the jpackage fix for bug [1] at [2].

This is a fix for the JDK-8200758-branch branch of the open sandbox 
repository (jpackage).

[1] https://bugs.openjdk.java.net/browse/JDK-8223080
[2] http://cr.openjdk.java.net/~herrick/8223080/

/Andy



From erik.joelsson at oracle.com  Thu Jun  6 14:31:33 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 6 Jun 2019 07:31:33 -0700
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <CALjzQn5REQt4WxWXiLJdA-cfpQ+OKoDyqyyv4XDaZ3atsePbow@mail.gmail.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
 <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
 <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>
 <e1ede98d-0bca-009a-76cf-77ef07360657@oracle.com>
 <CALjzQn5qK-B=nmddZKXscfaNav6Y9XBsB3wUz4KvQUqmYYEvCw@mail.gmail.com>
 <CALjzQn5REQt4WxWXiLJdA-cfpQ+OKoDyqyyv4XDaZ3atsePbow@mail.gmail.com>
Message-ID: <f379100c-2c7f-f109-5d53-9ae7bfa2a8f5@oracle.com>

Hello,

On 2019-06-05 20:28, Ao Qi wrote:
> On Thu, Jun 6, 2019 at 10:49 AM Ao Qi <aoqi at loongson.cn> wrote:
>> On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>> Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03
> Another question: should "[bootcycle] " be displayed during make
> bootcycle-images? If yes, should we remove line 164 "LOG_PREFIX :=" of
> http://cr.openjdk.java.net/~erikj/8217739/webrev.03/make/common/MakeBase.gmk.html
> ?

It seems you are right. I assumed that by setting LOG_PREFIX on the make 
command line, it would override. I think it's cleaner to initiate the 
variable to empty so that any accidental setting in the environment 
doesn't interfere. This works for the buildjdk call, which calls 
Main.gmk, but doesn't seem to work for bootcycle, which calls Init.gmk.

For now I will just refrain from initializing it in MakeBase.gmk.

Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.04

>> I (as an Author) am ok with this fix. mips64el zero cross build passed
>> and javac (to test open a file) worked.

Thanks!

/Erik

>>
>> UnixConstants.java of build:
>> .../usr/bin/cc -E -x c -I...
>>
>> UnixConstants.java of target:
>> .../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
>> --sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...
>>
>> Thanks,
>> Ao Qi
>>> The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
>>>
>>> /Erik
>>>
>>> On 2019-06-05 10:33, Erik Joelsson wrote:
>>>> Never mind, I found the issue. The reason it worked for me was that we
>>>> set SYSROOT_CFLAGS for both the target and the build compiler (from
>>>> using devkits for them). The preprocessor for the target would then
>>>> act correctly given the --sysroot parameter pointing to a sysroot for
>>>> the build system.
>>>>
>>>> I'm working on a patch where PPC gets overridden with the build
>>>> compiler in buildjdk-spec.gmk.
>>>>
>>>> /Erik
>>>>
>>>> On 2019-06-05 08:37, Erik Joelsson wrote:
>>>>> Hello Ao Qi,
>>>>>
>>>>> In my testing, I tried building ppc64le (which I first identified as
>>>>> generating a UnixConstants.java that differed from an x64 build).
>>>>> With this patch, the buildjdk and target version of
>>>>> UnixConstants.java differ the same way. How did you configure your
>>>>> build? I'm suspecting something in the setup of the buildjdk
>>>>> compilers is different from my configuration.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2019-06-04 21:48, Ao Qi wrote:
>>>>>> Hi Erik,
>>>>>>
>>>>>> Thank you a lot for taking care of this. I mainly like your approach.
>>>>>> I tested the patch by cross building mips64-zero, by which we found
>>>>>> this problem. However, it seems the problem still exists. The reason I
>>>>>> found is that UnixConstants.java of buildjdk is generated by cross
>>>>>> compiler, so the macro definitions are defined by the target. Here is
>>>>>> a preliminary workaround for your reference only (only worked for
>>>>>> gcc):
>>>>>>
>>>>>> $ hg diff make/gensrc/GensrcMisc.gmk
>>>>>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
>>>>>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
>>>>>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
>>>>>> @@ -61,6 +61,13 @@
>>>>>>      CPP_FLAGS += -nologo
>>>>>>    endif
>>>>>>
>>>>>> +ifeq ($(CREATING_BUILDJDK), true)
>>>>>> +  # Only worked for gcc
>>>>>> +  TEMP_CPP=gcc -E
>>>>>> +else
>>>>>> +  TEMP_CPP=$(CPP)
>>>>>> +endif
>>>>>> +
>>>>>>    # Generate a java source file from a template through the C
>>>>>> preprocessor for the
>>>>>>    # target system. First extract the copyright notice at the start
>>>>>> of the file.
>>>>>>    # Run the preprocessor. Filter out the default compiler stderr
>>>>>> output on
>>>>>> @@ -71,7 +78,7 @@
>>>>>>    define generate-preproc-src
>>>>>>     $(call MakeDir, $(@D))
>>>>>>     ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
>>>>>> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>>>>>> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
>>>>>>           2> >($(GREP) -v '^$(<F)$$' >&2) \
>>>>>>           | $(NAWK) '/@@START_HERE@@/,0' \
>>>>>>           |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
>>>>>> FILE - DO NOT EDIT/' \
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Ao Qi
>>>>>>
>>>>>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
>>>>>> <erik.joelsson at oracle.com> wrote:
>>>>>>> Thanks!
>>>>>>>
>>>>>>> During testing, I found an intermittent race issue. The command line
>>>>>>> that runs the interim langtools version of javac still always
>>>>>>> points to
>>>>>>> the buildtools/interim-langtools dir of the normal build. This
>>>>>>> variable
>>>>>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
>>>>>>> changed in buildjdk-spec.gmk.in:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>>>>>>>
>>>>>>> /Erik
>>>>>>>
>>>>>>> On 2019-06-04 07:53, Tim Bell wrote:
>>>>>>>> Erik:
>>>>>>>>
>>>>>>>> Looks good.
>>>>>>>>
>>>>>>>> Tim
>>>>>>>>
>>>>>>>>> This is a fix for a problem brought up on this list [1]. The main
>>>>>>>>> issue
>>>>>>>>> is that when cross compiling, and creating a buildjdk during the
>>>>>>>>> build,
>>>>>>>>> the UnixConstants.java cannot necessarily be reused between the
>>>>>>>>> target
>>>>>>>>> JDK and the buildjdk. While investigating this, I came to the
>>>>>>>>> conclusion
>>>>>>>>> that we really should stop trying to reuse anything between the
>>>>>>>>> buildjdk
>>>>>>>>> and target JDK. It's just becoming too complex to maintain (due
>>>>>>>>> to the
>>>>>>>>> intricate interactions with the interim-image,
>>>>>>>>> generate-link-opt-data
>>>>>>>>> and exploded-image-optimize targets, causing circular
>>>>>>>>> dependencies and
>>>>>>>>> endless incremental rebuilds).
>>>>>>>>>
>>>>>>>>> So this fix simply removes all the reuse of buildtools, gensrc
>>>>>>>>> and java
>>>>>>>>> compilation when creating a buildjdk. Hopefully this is making
>>>>>>>>> Main.gmk
>>>>>>>>> a bit less convoluted.
>>>>>>>>>
>>>>>>>>> While working on this, I came up with the idea of adding a log
>>>>>>>>> prefix
>>>>>>>>> functionality, to more easily discern which log lines were
>>>>>>>>> printed by
>>>>>>>>> the buildjdk build and which were part of the normal build. I
>>>>>>>>> liked this
>>>>>>>>> a lot so including that in the same fix, and applied it to the
>>>>>>>>> bootcycle
>>>>>>>>> build as well.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
>>>>>>>>>
>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>


From aoqi at loongson.cn  Thu Jun  6 14:45:04 2019
From: aoqi at loongson.cn (Ao Qi)
Date: Thu, 6 Jun 2019 22:45:04 +0800
Subject: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from
 target in BuildJDK when cross compiling
In-Reply-To: <f379100c-2c7f-f109-5d53-9ae7bfa2a8f5@oracle.com>
References: <f28f7244-dc54-52bf-4b93-9051d8964b32@oracle.com>
 <5CF685F4.3050305@oracle.com>
 <a84979ad-11d2-9dc0-4095-66228454db17@oracle.com>
 <CALjzQn4hkqTZQmekuZgJSTTQXKA7zZWB-B5dq=KPfMCXt6z-jg@mail.gmail.com>
 <d2da3a1e-6c62-2b14-f939-854672bd77ab@oracle.com>
 <1870607e-09da-2667-3529-07b1feda71bc@oracle.com>
 <e1ede98d-0bca-009a-76cf-77ef07360657@oracle.com>
 <CALjzQn5qK-B=nmddZKXscfaNav6Y9XBsB3wUz4KvQUqmYYEvCw@mail.gmail.com>
 <CALjzQn5REQt4WxWXiLJdA-cfpQ+OKoDyqyyv4XDaZ3atsePbow@mail.gmail.com>
 <f379100c-2c7f-f109-5d53-9ae7bfa2a8f5@oracle.com>
Message-ID: <CALjzQn7wmieq335kffHu50o=vTmjM6EKDvd3kniMaCS5KN6B8A@mail.gmail.com>

On Thu, Jun 6, 2019 at 10:31 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>
> Hello,
>
> On 2019-06-05 20:28, Ao Qi wrote:
> > On Thu, Jun 6, 2019 at 10:49 AM Ao Qi <aoqi at loongson.cn> wrote:
> >> On Thu, Jun 6, 2019 at 4:46 AM Erik Joelsson <erik.joelsson at oracle.com> wrote:
> >>> Here is a new webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.03
> > Another question: should "[bootcycle] " be displayed during make
> > bootcycle-images? If yes, should we remove line 164 "LOG_PREFIX :=" of
> > http://cr.openjdk.java.net/~erikj/8217739/webrev.03/make/common/MakeBase.gmk.html
> > ?
>
> It seems you are right. I assumed that by setting LOG_PREFIX on the make
> command line, it would override. I think it's cleaner to initiate the
> variable to empty so that any accidental setting in the environment
> doesn't interfere. This works for the buildjdk call, which calls
> Main.gmk, but doesn't seem to work for bootcycle, which calls Init.gmk.
>
> For now I will just refrain from initializing it in MakeBase.gmk.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.04

Looks good. Thanks for fixing this!

Cheers,
Ao Qi
>
> >> I (as an Author) am ok with this fix. mips64el zero cross build passed
> >> and javac (to test open a file) worked.
>
> Thanks!
>
> /Erik
>
> >>
> >> UnixConstants.java of build:
> >> .../usr/bin/cc -E -x c -I...
> >>
> >> UnixConstants.java of target:
> >> .../usr/bin/mips64el-linux-gnuabi64-gcc -E -x c
> >> --sysroot=/home/aoqi//chroots/mips64el_stretch/ -I...
> >>
> >> Thanks,
> >> Ao Qi
> >>> The change is in buildjdk-spec.gmk.in where CPP is now also overridden.
> >>>
> >>> /Erik
> >>>
> >>> On 2019-06-05 10:33, Erik Joelsson wrote:
> >>>> Never mind, I found the issue. The reason it worked for me was that we
> >>>> set SYSROOT_CFLAGS for both the target and the build compiler (from
> >>>> using devkits for them). The preprocessor for the target would then
> >>>> act correctly given the --sysroot parameter pointing to a sysroot for
> >>>> the build system.
> >>>>
> >>>> I'm working on a patch where PPC gets overridden with the build
> >>>> compiler in buildjdk-spec.gmk.
> >>>>
> >>>> /Erik
> >>>>
> >>>> On 2019-06-05 08:37, Erik Joelsson wrote:
> >>>>> Hello Ao Qi,
> >>>>>
> >>>>> In my testing, I tried building ppc64le (which I first identified as
> >>>>> generating a UnixConstants.java that differed from an x64 build).
> >>>>> With this patch, the buildjdk and target version of
> >>>>> UnixConstants.java differ the same way. How did you configure your
> >>>>> build? I'm suspecting something in the setup of the buildjdk
> >>>>> compilers is different from my configuration.
> >>>>>
> >>>>> /Erik
> >>>>>
> >>>>> On 2019-06-04 21:48, Ao Qi wrote:
> >>>>>> Hi Erik,
> >>>>>>
> >>>>>> Thank you a lot for taking care of this. I mainly like your approach.
> >>>>>> I tested the patch by cross building mips64-zero, by which we found
> >>>>>> this problem. However, it seems the problem still exists. The reason I
> >>>>>> found is that UnixConstants.java of buildjdk is generated by cross
> >>>>>> compiler, so the macro definitions are defined by the target. Here is
> >>>>>> a preliminary workaround for your reference only (only worked for
> >>>>>> gcc):
> >>>>>>
> >>>>>> $ hg diff make/gensrc/GensrcMisc.gmk
> >>>>>> diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
> >>>>>> --- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
> >>>>>> +++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
> >>>>>> @@ -61,6 +61,13 @@
> >>>>>>      CPP_FLAGS += -nologo
> >>>>>>    endif
> >>>>>>
> >>>>>> +ifeq ($(CREATING_BUILDJDK), true)
> >>>>>> +  # Only worked for gcc
> >>>>>> +  TEMP_CPP=gcc -E
> >>>>>> +else
> >>>>>> +  TEMP_CPP=$(CPP)
> >>>>>> +endif
> >>>>>> +
> >>>>>>    # Generate a java source file from a template through the C
> >>>>>> preprocessor for the
> >>>>>>    # target system. First extract the copyright notice at the start
> >>>>>> of the file.
> >>>>>>    # Run the preprocessor. Filter out the default compiler stderr
> >>>>>> output on
> >>>>>> @@ -71,7 +78,7 @@
> >>>>>>    define generate-preproc-src
> >>>>>>     $(call MakeDir, $(@D))
> >>>>>>     ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> >>>>>> -   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> >>>>>> +   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
> >>>>>>           2> >($(GREP) -v '^$(<F)$$' >&2) \
> >>>>>>           | $(NAWK) '/@@START_HERE@@/,0' \
> >>>>>>           |  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> >>>>>> FILE - DO NOT EDIT/' \
> >>>>>>
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ao Qi
> >>>>>>
> >>>>>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
> >>>>>> <erik.joelsson at oracle.com> wrote:
> >>>>>>> Thanks!
> >>>>>>>
> >>>>>>> During testing, I found an intermittent race issue. The command line
> >>>>>>> that runs the interim langtools version of javac still always
> >>>>>>> points to
> >>>>>>> the buildtools/interim-langtools dir of the normal build. This
> >>>>>>> variable
> >>>>>>> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> >>>>>>> changed in buildjdk-spec.gmk.in:
> >>>>>>>
> >>>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
> >>>>>>>
> >>>>>>> /Erik
> >>>>>>>
> >>>>>>> On 2019-06-04 07:53, Tim Bell wrote:
> >>>>>>>> Erik:
> >>>>>>>>
> >>>>>>>> Looks good.
> >>>>>>>>
> >>>>>>>> Tim
> >>>>>>>>
> >>>>>>>>> This is a fix for a problem brought up on this list [1]. The main
> >>>>>>>>> issue
> >>>>>>>>> is that when cross compiling, and creating a buildjdk during the
> >>>>>>>>> build,
> >>>>>>>>> the UnixConstants.java cannot necessarily be reused between the
> >>>>>>>>> target
> >>>>>>>>> JDK and the buildjdk. While investigating this, I came to the
> >>>>>>>>> conclusion
> >>>>>>>>> that we really should stop trying to reuse anything between the
> >>>>>>>>> buildjdk
> >>>>>>>>> and target JDK. It's just becoming too complex to maintain (due
> >>>>>>>>> to the
> >>>>>>>>> intricate interactions with the interim-image,
> >>>>>>>>> generate-link-opt-data
> >>>>>>>>> and exploded-image-optimize targets, causing circular
> >>>>>>>>> dependencies and
> >>>>>>>>> endless incremental rebuilds).
> >>>>>>>>>
> >>>>>>>>> So this fix simply removes all the reuse of buildtools, gensrc
> >>>>>>>>> and java
> >>>>>>>>> compilation when creating a buildjdk. Hopefully this is making
> >>>>>>>>> Main.gmk
> >>>>>>>>> a bit less convoluted.
> >>>>>>>>>
> >>>>>>>>> While working on this, I came up with the idea of adding a log
> >>>>>>>>> prefix
> >>>>>>>>> functionality, to more easily discern which log lines were
> >>>>>>>>> printed by
> >>>>>>>>> the buildjdk build and which were part of the normal build. I
> >>>>>>>>> liked this
> >>>>>>>>> a lot so including that in the same fix, and applied it to the
> >>>>>>>>> bootcycle
> >>>>>>>>> build as well.
> >>>>>>>>>
> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
> >>>>>>>>>
> >>>>>>>>> Webrev:
> >>>>>>>>> http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
> >>>>>>>>>
> >>>>>>>>> /Erik
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>


From andy.herrick at oracle.com  Thu Jun  6 22:52:40 2019
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 6 Jun 2019 18:52:40 -0400
Subject: RFR: JDK-8223080: Build team code review requests.
In-Reply-To: <51001a4d-fcd7-6693-9f16-68025f2142a7@oracle.com>
References: <9c0f12f0-ae74-6b49-fd9e-1dc79c4d9d49@oracle.com>
 <51001a4d-fcd7-6693-9f16-68025f2142a7@oracle.com>
Message-ID: <5fb2c885-483f-4864-5e63-88b4d1f7ef19@oracle.com>

tried to bcc build-dev on this, but not sure if it got thru.

/Andy


On 6/5/2019 9:43 PM, David Holmes wrote:
> Hi Andy,
>
> Build changes should be reviewed on build-dev at openjdk.java.net.
>
> Cheers,
> David
>
> On 6/06/2019 9:46 am, Andy Herrick wrote:
>> Please review the jpackage fix for bug [1] at [2].
>>
>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>> repository (jpackage).
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8223080
>> [2] http://cr.openjdk.java.net/~herrick/8223080/
>>
>> /Andy
>>



From erik.joelsson at oracle.com  Fri Jun  7 16:05:56 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 7 Jun 2019 09:05:56 -0700
Subject: RFR: JDK-8223080: Build team code review requests.
In-Reply-To: <5fb2c885-483f-4864-5e63-88b4d1f7ef19@oracle.com>
References: <9c0f12f0-ae74-6b49-fd9e-1dc79c4d9d49@oracle.com>
 <51001a4d-fcd7-6693-9f16-68025f2142a7@oracle.com>
 <5fb2c885-483f-4864-5e63-88b4d1f7ef19@oracle.com>
Message-ID: <aa60ccb3-afd6-6303-7566-5a7f9861baac@oracle.com>

Looks good.

I don't know which list you sent this to originally, but bcc:ing 
build-dev is not a good idea. I'm on a lot of openjdk email lists, many 
of which I don't follow closely. So to keep up I use a lot of mail 
filtering and if build-dev is not in the to or cc list, there is a big 
risk I would never see the email.

/Erik

On 2019-06-06 15:52, Andy Herrick wrote:
> tried to bcc build-dev on this, but not sure if it got thru.
>
> /Andy
>
>
> On 6/5/2019 9:43 PM, David Holmes wrote:
>> Hi Andy,
>>
>> Build changes should be reviewed on build-dev at openjdk.java.net.
>>
>> Cheers,
>> David
>>
>> On 6/06/2019 9:46 am, Andy Herrick wrote:
>>> Please review the jpackage fix for bug [1] at [2].
>>>
>>> This is a fix for the JDK-8200758-branch branch of the open sandbox 
>>> repository (jpackage).
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8223080
>>> [2] http://cr.openjdk.java.net/~herrick/8223080/
>>>
>>> /Andy
>>>
>


From jonathan.gibbons at oracle.com  Fri Jun  7 20:58:13 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 7 Jun 2019 13:58:13 -0700
Subject: RFR: JDK-8224257: fix issues in files generated by pandoc
Message-ID: <3e8c0291-5d10-3246-c386-c5cccd9afad8@oracle.com>

Please review an update to the tool used to post-process files generated 
by pandoc.

In HTML 5, it is not enough to put `scope="row` on selected cells in the 
table,
the cells must also be converted to `<th>`. To counteract any potential 
change
in the visual appearance, the style attribute for the cell is also updated.

Tested by doing a visual comparison with meld of the files generated 
before/after
the change.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8224257
Webrev: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/webrev.00/
Docs: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/docs/





From mandy.chung at oracle.com  Fri Jun  7 21:17:20 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 7 Jun 2019 14:17:20 -0700
Subject: RFR: JDK-8224257: fix issues in files generated by pandoc
In-Reply-To: <3e8c0291-5d10-3246-c386-c5cccd9afad8@oracle.com>
References: <3e8c0291-5d10-3246-c386-c5cccd9afad8@oracle.com>
Message-ID: <f87156c9-c15c-b680-b73f-2f15c528d770@oracle.com>

This patch looks fine to me.? Nothing is obviously not right.? I picked 
a couple of specs to sanity check and they look right to me.

Mandy

On 6/7/19 1:58 PM, Jonathan Gibbons wrote:
> Please review an update to the tool used to post-process files 
> generated by pandoc.
>
> In HTML 5, it is not enough to put `scope="row` on selected cells in 
> the table,
> the cells must also be converted to `<th>`. To counteract any 
> potential change
> in the visual appearance, the style attribute for the cell is also 
> updated.
>
> Tested by doing a visual comparison with meld of the files generated 
> before/after
> the change.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224257
> Webrev: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/webrev.00/
> Docs: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/docs/
>
>
>


From jonathan.gibbons at oracle.com  Fri Jun  7 21:31:53 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 7 Jun 2019 14:31:53 -0700
Subject: RFR: JDK-8224257: fix issues in files generated by pandoc
In-Reply-To: <f87156c9-c15c-b680-b73f-2f15c528d770@oracle.com>
References: <3e8c0291-5d10-3246-c386-c5cccd9afad8@oracle.com>
 <f87156c9-c15c-b680-b73f-2f15c528d770@oracle.com>
Message-ID: <825edecc-7541-1852-c96b-530faef4c00e@oracle.com>

Thanks

-- Jon


On 06/07/2019 02:17 PM, Mandy Chung wrote:
> This patch looks fine to me.? Nothing is obviously not right.? I 
> picked a couple of specs to sanity check and they look right to me.
>
> Mandy
>
> On 6/7/19 1:58 PM, Jonathan Gibbons wrote:
>> Please review an update to the tool used to post-process files 
>> generated by pandoc.
>>
>> In HTML 5, it is not enough to put `scope="row` on selected cells in 
>> the table,
>> the cells must also be converted to `<th>`. To counteract any 
>> potential change
>> in the visual appearance, the style attribute for the cell is also 
>> updated.
>>
>> Tested by doing a visual comparison with meld of the files generated 
>> before/after
>> the change.
>>
>> -- Jon
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224257
>> Webrev: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/webrev.00/
>> Docs: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/docs/
>>
>>
>>



From erik.joelsson at oracle.com  Fri Jun  7 22:03:52 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 7 Jun 2019 15:03:52 -0700
Subject: RFR: JDK-8224257: fix issues in files generated by pandoc
In-Reply-To: <3e8c0291-5d10-3246-c386-c5cccd9afad8@oracle.com>
References: <3e8c0291-5d10-3246-c386-c5cccd9afad8@oracle.com>
Message-ID: <cfb7702a-fd4d-d628-2538-907bd8d878ac@oracle.com>

Looks good from a build perspective.

/Erik

On 2019-06-07 13:58, Jonathan Gibbons wrote:
> Please review an update to the tool used to post-process files 
> generated by pandoc.
>
> In HTML 5, it is not enough to put `scope="row` on selected cells in 
> the table,
> the cells must also be converted to `<th>`. To counteract any 
> potential change
> in the visual appearance, the style attribute for the cell is also 
> updated.
>
> Tested by doing a visual comparison with meld of the files generated 
> before/after
> the change.
>
> -- Jon
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224257
> Webrev: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/webrev.00/
> Docs: http://cr.openjdk.java.net/~jjg/8225489-pandoc-tables/docs/
>
>
>


From jonathan.gibbons at oracle.com  Fri Jun  7 23:36:03 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 7 Jun 2019 16:36:03 -0700
Subject: RFR: XXS,doc JDK-8225496: typo in fix for JDK-8224257
Message-ID: <12bee48c-7112-9f16-60c1-f82066e69acf@oracle.com>

The fix for? JDK-8224257 had a transposition typo, putting a ';' outside 
a quoted string instead of inside it.

JBS: https://bugs.openjdk.java.net/browse/JDK-8225496

-- Jon


$ hg diff -R open
diff -r fd61ef6c4091 make/jdk/src/classes/build/tools/fixuppandoc/Main.java
--- a/make/jdk/src/classes/build/tools/fixuppandoc/Main.java??? Fri Jun 
07 14:32:48 2019 -0700
+++ b/make/jdk/src/classes/build/tools/fixuppandoc/Main.java??? Fri Jun 
07 16:31:17 2019 -0700
@@ -558,7 +558,7 @@
 ???????????????????????? out.write(style);
 ???????????????????????? out.write(m.group("after"));
 ???????????????????? } else {
-??????????????????????? out.write(" style=\"font-weight: normal; 
text-align:left\"; ");
+??????????????????????? out.write(" style=\"font-weight: normal; 
text-align:left;\" ");
 ???????????????????????? out.write(attrs);
 ???????????????????? }
 ???????????????????? out.write(" scope=\"row\"");


From mandy.chung at oracle.com  Fri Jun  7 23:38:44 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 7 Jun 2019 16:38:44 -0700
Subject: RFR: XXS,doc JDK-8225496: typo in fix for JDK-8224257
In-Reply-To: <12bee48c-7112-9f16-60c1-f82066e69acf@oracle.com>
References: <12bee48c-7112-9f16-60c1-f82066e69acf@oracle.com>
Message-ID: <4994408f-75a0-4df6-e5f8-5ff21a4e7bda@oracle.com>

+1.? Missed this in the review.

Mandy

On 6/7/19 4:36 PM, Jonathan Gibbons wrote:
> The fix for? JDK-8224257 had a transposition typo, putting a ';' 
> outside a quoted string instead of inside it.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225496
>
> -- Jon
>
>
> $ hg diff -R open
> diff -r fd61ef6c4091 
> make/jdk/src/classes/build/tools/fixuppandoc/Main.java
> --- a/make/jdk/src/classes/build/tools/fixuppandoc/Main.java Fri Jun 
> 07 14:32:48 2019 -0700
> +++ b/make/jdk/src/classes/build/tools/fixuppandoc/Main.java Fri Jun 
> 07 16:31:17 2019 -0700
> @@ -558,7 +558,7 @@
> ???????????????????????? out.write(style);
> ???????????????????????? out.write(m.group("after"));
> ???????????????????? } else {
> -??????????????????????? out.write(" style=\"font-weight: normal; 
> text-align:left\"; ");
> +??????????????????????? out.write(" style=\"font-weight: normal; 
> text-align:left;\" ");
> ???????????????????????? out.write(attrs);
> ???????????????????? }
> ???????????????????? out.write(" scope=\"row\"");
>


From ali.ince at gmail.com  Sun Jun  9 14:20:11 2019
From: ali.ince at gmail.com (Ali Ince)
Date: Sun, 9 Jun 2019 15:20:11 +0100
Subject: Advice on how to do DISABLED_WARNINGS in jdk8u-dev
Message-ID: <65d537cb-0857-fb6a-1111-2d895236bc98@gmail.com>

Hi All,

I'm trying to get jdk8u to be built with VS2017.

This requires disabling several warnings for several libraries (as been 
done in later versions of the openjdk, like [1]) however jdk8u doesn't 
have the DISABLED_WARNINGS_$(TOOLCHAIN_TYPE) [2] argument support in 
SetupNativeCompilation target [3]. I have investigated the possibility 
of back-porting JDK-8074096, which first introduced DISABLED_WARNINGS 
into jdk9 but that seemed not very feasible.

I've already progressed with adding -Wd flags to CFLAGS_windows 
overrides in corresponding places but not sure if this would be the 
right approach to do this.

I will be grateful if someone could advise me on what approach I should 
proceed?

Best regards,

Ali

[1] 
http://hg.openjdk.java.net/jdk-updates/jdk11u/file/640251cdca05/make/lib/Awt2dLibraries.gmk#l519
[2] 
http://hg.openjdk.java.net/jdk-updates/jdk11u/file/640251cdca05/make/common/NativeCompilation.gmk#l381
[3] 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/file/f0f617923ceb/make/common/NativeCompilation.gmk#l135


From weijun.wang at oracle.com  Mon Jun 10 02:30:50 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 10 Jun 2019 10:30:50 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
References: <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
 <20190215214502.GB4046@twosigma.com>
 <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>
 <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
Message-ID: <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>

Updated webrev at

   http://cr.openjdk.java.net/~weijun/6722928/webrev.08/

@build-dev guys, I realize I've never included you in this code review. Please take a look.

@Valerie, All comments accepted except for one (see below). In fact, I think I found a bug in gss_release_context that it might release a cred handle passed in, so I add a isLocalCred flag. However, I test it on my local Windows and it seems the same handle can be FreeCredentialsHandle and then used and then freed again.

> On Jun 7, 2019, at 10:45 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi, Max,
> 
> <gssapi.h>
> 
> - line 424: the "(used to be const)" comment can now be removed.
> 
> <sspi.cpp>
> 
> - line 396-403: on line 338, there is no need to go to err as no memory has been allocated. What happens when jumping to err but the variables, i.e. value and name, have not been declared? Line 400-401 seems not used as there is no more goto err after line 391.
> 
> - line 528: the size of buffer here is 4*len + 1, but then when calling WideCharToMultiByte, the 6th argument is len. Seems inconsistent? line 534: shouldn't we free "buffer" here?
> 
> - line 596: free cred allocated on line 588? line 610 and 617: free cred and cred->phCredK? line 638 and 644, 648 and 653: free cred, cred->phCredK and cred->phCredS?
> 
> - line 829: free the context handle allocated on line 807? line 879: free newCred? line 901: no memory de-allocation before returning error? line 921: seems redundant given line 918.
> 
> - line 1071: based on gss api doc, context_handle should be set to GSS_C_NO_CONTEXT after deletion.
> 
> - line 1333: what about secBuff[1].pvBuffer?

According to the DecryptMessage spec, "The encrypted message is decrypted in place, overwriting the original contents of its buffer". I've printed out both secBuff[0].pvBuffer and secBuff[1].pvBuffer after the decryption and the latter is indeed inside the former.

> 
> - line 1390, 1393, 1397: call gss_release_oid_set before returning failure?
> 
> - line 1471: should we return an error code here when FormatMessage() call failed?
> 
> Rest looks fine.
> 
> Thanks,
> 
> Valerie

Thanks,
Max

[1] https://docs.microsoft.com/en-us/windows/desktop/api/sspi/nf-sspi-decryptmessage

> 
> On 6/4/2019 2:52 AM, Weijun Wang wrote:
>> I uploaded an updated webrev in place. The only changes are:
>> 
>> 1. s/SSPI_TRACE/SSPI_BRIDGE_TRACE/ in sspi.cpp
>> 2. Several copyright year updates.
>> 3. Remove one unused import.
>> 
>> Thanks,
>> Max
>> 
>>> On May 30, 2019, at 11:18 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Here is the latest webrev
>>> 
>>>   http://cr.openjdk.java.net/~weijun/6722928/webrev.07/



From erik.joelsson at oracle.com  Mon Jun 10 16:15:03 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jun 2019 09:15:03 -0700
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
References: <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
 <20190215214502.GB4046@twosigma.com>
 <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>
 <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
 <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
Message-ID: <d0ea07d0-8564-4e5b-e898-6fbdff10134a@oracle.com>

Hello Max,

I believe $(call FindSrcDirsForLib, $(MODULE), sspi_bridge) for SRC is 
the default so you shouldn't need to specify it explicitly, or did you 
experience some problems with the default that I'm missing?

/Erik

On 2019-06-09 19:30, Weijun Wang wrote:
> Updated webrev at
>
>     http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>
> @build-dev guys, I realize I've never included you in this code review. Please take a look.
>
> @Valerie, All comments accepted except for one (see below). In fact, I think I found a bug in gss_release_context that it might release a cred handle passed in, so I add a isLocalCred flag. However, I test it on my local Windows and it seems the same handle can be FreeCredentialsHandle and then used and then freed again.
>
>> On Jun 7, 2019, at 10:45 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi, Max,
>>
>> <gssapi.h>
>>
>> - line 424: the "(used to be const)" comment can now be removed.
>>
>> <sspi.cpp>
>>
>> - line 396-403: on line 338, there is no need to go to err as no memory has been allocated. What happens when jumping to err but the variables, i.e. value and name, have not been declared? Line 400-401 seems not used as there is no more goto err after line 391.
>>
>> - line 528: the size of buffer here is 4*len + 1, but then when calling WideCharToMultiByte, the 6th argument is len. Seems inconsistent? line 534: shouldn't we free "buffer" here?
>>
>> - line 596: free cred allocated on line 588? line 610 and 617: free cred and cred->phCredK? line 638 and 644, 648 and 653: free cred, cred->phCredK and cred->phCredS?
>>
>> - line 829: free the context handle allocated on line 807? line 879: free newCred? line 901: no memory de-allocation before returning error? line 921: seems redundant given line 918.
>>
>> - line 1071: based on gss api doc, context_handle should be set to GSS_C_NO_CONTEXT after deletion.
>>
>> - line 1333: what about secBuff[1].pvBuffer?
> According to the DecryptMessage spec, "The encrypted message is decrypted in place, overwriting the original contents of its buffer". I've printed out both secBuff[0].pvBuffer and secBuff[1].pvBuffer after the decryption and the latter is indeed inside the former.
>
>> - line 1390, 1393, 1397: call gss_release_oid_set before returning failure?
>>
>> - line 1471: should we return an error code here when FormatMessage() call failed?
>>
>> Rest looks fine.
>>
>> Thanks,
>>
>> Valerie
> Thanks,
> Max
>
> [1] https://docs.microsoft.com/en-us/windows/desktop/api/sspi/nf-sspi-decryptmessage
>
>> On 6/4/2019 2:52 AM, Weijun Wang wrote:
>>> I uploaded an updated webrev in place. The only changes are:
>>>
>>> 1. s/SSPI_TRACE/SSPI_BRIDGE_TRACE/ in sspi.cpp
>>> 2. Several copyright year updates.
>>> 3. Remove one unused import.
>>>
>>> Thanks,
>>> Max
>>>
>>>> On May 30, 2019, at 11:18 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>
>>>> Here is the latest webrev
>>>>
>>>>    http://cr.openjdk.java.net/~weijun/6722928/webrev.07/


From erik.joelsson at oracle.com  Mon Jun 10 19:37:42 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jun 2019 12:37:42 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts file
Message-ID: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>

Since JDK-8193255, when we started generating the cacerts file in the 
build, the build compare baseline builds have started failing. It seems 
the cacerts binary file has some non determinism built in so it doesn't 
get generated exactly the same given the same input. This patch adds 
special handling when comparing that file by comparing the output of 
"keytool -list" on the files instead.

Bug: https://bugs.openjdk.java.net/browse/JDK-8225392

Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/

/Erik



From valerie.peng at oracle.com  Mon Jun 10 21:43:49 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 10 Jun 2019 14:43:49 -0700
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
References: <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
 <20190215214502.GB4046@twosigma.com>
 <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>
 <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
 <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
Message-ID: <a40abad5-d83b-7ffb-dbac-0dd9befdc637@oracle.com>

Hi Max,

Thanks for the clarification on DecryptMessage. Updated webrev looks fine.

Regards,
Valerie

On 6/9/2019 7:30 PM, Weijun Wang wrote:
> Updated webrev at
>
>     http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>
> @build-dev guys, I realize I've never included you in this code review. Please take a look.
>
> @Valerie, All comments accepted except for one (see below). In fact, I think I found a bug in gss_release_context that it might release a cred handle passed in, so I add a isLocalCred flag. However, I test it on my local Windows and it seems the same handle can be FreeCredentialsHandle and then used and then freed again.
>
>> On Jun 7, 2019, at 10:45 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi, Max,
>>
>> <gssapi.h>
>>
>> - line 424: the "(used to be const)" comment can now be removed.
>>
>> <sspi.cpp>
>>
>> - line 396-403: on line 338, there is no need to go to err as no memory has been allocated. What happens when jumping to err but the variables, i.e. value and name, have not been declared? Line 400-401 seems not used as there is no more goto err after line 391.
>>
>> - line 528: the size of buffer here is 4*len + 1, but then when calling WideCharToMultiByte, the 6th argument is len. Seems inconsistent? line 534: shouldn't we free "buffer" here?
>>
>> - line 596: free cred allocated on line 588? line 610 and 617: free cred and cred->phCredK? line 638 and 644, 648 and 653: free cred, cred->phCredK and cred->phCredS?
>>
>> - line 829: free the context handle allocated on line 807? line 879: free newCred? line 901: no memory de-allocation before returning error? line 921: seems redundant given line 918.
>>
>> - line 1071: based on gss api doc, context_handle should be set to GSS_C_NO_CONTEXT after deletion.
>>
>> - line 1333: what about secBuff[1].pvBuffer?
> According to the DecryptMessage spec, "The encrypted message is decrypted in place, overwriting the original contents of its buffer". I've printed out both secBuff[0].pvBuffer and secBuff[1].pvBuffer after the decryption and the latter is indeed inside the former.
>
>> - line 1390, 1393, 1397: call gss_release_oid_set before returning failure?
>>
>> - line 1471: should we return an error code here when FormatMessage() call failed?
>>
>> Rest looks fine.
>>
>> Thanks,
>>
>> Valerie
> Thanks,
> Max
>
> [1] https://docs.microsoft.com/en-us/windows/desktop/api/sspi/nf-sspi-decryptmessage
>
>> On 6/4/2019 2:52 AM, Weijun Wang wrote:
>>> I uploaded an updated webrev in place. The only changes are:
>>>
>>> 1. s/SSPI_TRACE/SSPI_BRIDGE_TRACE/ in sspi.cpp
>>> 2. Several copyright year updates.
>>> 3. Remove one unused import.
>>>
>>> Thanks,
>>> Max
>>>
>>>> On May 30, 2019, at 11:18 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>
>>>> Here is the latest webrev
>>>>
>>>>    http://cr.openjdk.java.net/~weijun/6722928/webrev.07/


From david.holmes at oracle.com  Mon Jun 10 23:23:28 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Jun 2019 09:23:28 +1000
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
Message-ID: <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>

Hi Erik,

On 11/06/2019 5:37 am, Erik Joelsson wrote:
> Since JDK-8193255, when we started generating the cacerts file in the 
> build, the build compare baseline builds have started failing. It seems 
> the cacerts binary file has some non determinism built in so it doesn't 
> get generated exactly the same given the same input. This patch adds 
> special handling when comparing that file by comparing the output of 
> "keytool -list" on the files instead.

Seems a reasonable approach.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/

Code changes seem fine. I'm assuming this formulation doesn't run into the:

Warning: use -cacerts option to access cacerts keystore

that you get if you actually point keytool to the cacerts files in the 
JDK image:

 > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass 
changeit > certs.1
Warning: use -cacerts option to access cacerts keystore

Thanks,
David
-----

> /Erik
> 


From erik.joelsson at oracle.com  Mon Jun 10 23:37:27 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Jun 2019 16:37:27 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
Message-ID: <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>


On 2019-06-10 16:23, David Holmes wrote:
> Hi Erik,
>
> On 11/06/2019 5:37 am, Erik Joelsson wrote:
>> Since JDK-8193255, when we started generating the cacerts file in the 
>> build, the build compare baseline builds have started failing. It 
>> seems the cacerts binary file has some non determinism built in so it 
>> doesn't get generated exactly the same given the same input. This 
>> patch adds special handling when comparing that file by comparing the 
>> output of "keytool -list" on the files instead.
>
> Seems a reasonable approach.
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>
> Code changes seem fine.
Thanks!
> I'm assuming this formulation doesn't run into the:
>
> Warning: use -cacerts option to access cacerts keystore
>
> that you get if you actually point keytool to the cacerts files in the 
> JDK image:
>
> > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
> build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass 
> changeit > certs.1
> Warning: use -cacerts option to access cacerts keystore
>
I did not see that. I would guess it's because I'm not running keytool 
from the images/jdk/bin dir, but in most cases from the jdk/bin dir (the 
exploded image), or in the cross compilation case, it's running from the 
buildjdk. I just tried it manually, and it seems the warning is only 
printed if trying to list the cacerts file from the same image.

/Erik

> Thanks,
> David
> -----
>
>> /Erik
>>


From weijun.wang at oracle.com  Mon Jun 10 23:58:57 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Jun 2019 07:58:57 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <d0ea07d0-8564-4e5b-e898-6fbdff10134a@oracle.com>
References: <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
 <20190215214502.GB4046@twosigma.com>
 <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>
 <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
 <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
 <d0ea07d0-8564-4e5b-e898-6fbdff10134a@oracle.com>
Message-ID: <919250C3-9662-43EB-A171-9A9E9309C7C6@oracle.com>



> On Jun 11, 2019, at 12:15 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello Max,
> 
> I believe $(call FindSrcDirsForLib, $(MODULE), sspi_bridge) for SRC is the default so you shouldn't need to specify it explicitly, or did you experience some problems with the default that I'm missing?

I don't remember. I must have copied it from somewhere. The only special thing about this target is that it includes a header file from the shared area.

I am running make again to see if it's useless.

Thanks,
Max


> 
> /Erik
> 
> On 2019-06-09 19:30, Weijun Wang wrote:
>> Updated webrev at
>> 
>>    http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
>> 
>> @build-dev guys, I realize I've never included you in this code review. Please take a look.
>> 
>> @Valerie, All comments accepted except for one (see below). In fact, I think I found a bug in gss_release_context that it might release a cred handle passed in, so I add a isLocalCred flag. However, I test it on my local Windows and it seems the same handle can be FreeCredentialsHandle and then used and then freed again.
>> 
>>> On Jun 7, 2019, at 10:45 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>> 
>>> Hi, Max,
>>> 
>>> <gssapi.h>
>>> 
>>> - line 424: the "(used to be const)" comment can now be removed.
>>> 
>>> <sspi.cpp>
>>> 
>>> - line 396-403: on line 338, there is no need to go to err as no memory has been allocated. What happens when jumping to err but the variables, i.e. value and name, have not been declared? Line 400-401 seems not used as there is no more goto err after line 391.
>>> 
>>> - line 528: the size of buffer here is 4*len + 1, but then when calling WideCharToMultiByte, the 6th argument is len. Seems inconsistent? line 534: shouldn't we free "buffer" here?
>>> 
>>> - line 596: free cred allocated on line 588? line 610 and 617: free cred and cred->phCredK? line 638 and 644, 648 and 653: free cred, cred->phCredK and cred->phCredS?
>>> 
>>> - line 829: free the context handle allocated on line 807? line 879: free newCred? line 901: no memory de-allocation before returning error? line 921: seems redundant given line 918.
>>> 
>>> - line 1071: based on gss api doc, context_handle should be set to GSS_C_NO_CONTEXT after deletion.
>>> 
>>> - line 1333: what about secBuff[1].pvBuffer?
>> According to the DecryptMessage spec, "The encrypted message is decrypted in place, overwriting the original contents of its buffer". I've printed out both secBuff[0].pvBuffer and secBuff[1].pvBuffer after the decryption and the latter is indeed inside the former.
>> 
>>> - line 1390, 1393, 1397: call gss_release_oid_set before returning failure?
>>> 
>>> - line 1471: should we return an error code here when FormatMessage() call failed?
>>> 
>>> Rest looks fine.
>>> 
>>> Thanks,
>>> 
>>> Valerie
>> Thanks,
>> Max
>> 
>> [1] https://docs.microsoft.com/en-us/windows/desktop/api/sspi/nf-sspi-decryptmessage
>> 
>>> On 6/4/2019 2:52 AM, Weijun Wang wrote:
>>>> I uploaded an updated webrev in place. The only changes are:
>>>> 
>>>> 1. s/SSPI_TRACE/SSPI_BRIDGE_TRACE/ in sspi.cpp
>>>> 2. Several copyright year updates.
>>>> 3. Remove one unused import.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
>>>>> On May 30, 2019, at 11:18 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>> 
>>>>> Here is the latest webrev
>>>>> 
>>>>>   http://cr.openjdk.java.net/~weijun/6722928/webrev.07/



From Nico.Williams at twosigma.com  Mon Jun 10 23:56:35 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 10 Jun 2019 23:56:35 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
References: <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
 <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
Message-ID: <20190610235635.GL7457@twosigma.com>

On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
> Updated webrev at
> 
>    http://cr.openjdk.java.net/~weijun/6722928/webrev.08/

 - src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java

   Ugh, I never noticed GSSUtil.useMSInterop().  This really should not
   be needed.  I believe a proper implementation of RFC4178 wouldn't
   need it.

   I can't expect you to do that, but can we have a bug opened for this?

 - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java

   Shouldn't the sspi_bridge.dll be in the lib directory?

 - src/java.security.jgss/share/native/libj2gss/NativeFunc.h
 - src/java.security.jgss/share/native/libj2gss/gssapi.h

   These continue to have improper constification.

   There should be no function arguments of type "const gss_...".

   I've a PR for Heimdal to fix this in Heimdal.  It was very
   mechanical: search the prototypes and function definitions for

       \<const[^I ]*gss_

   then change that to gss_const_... then fix all the warnings and
   errors that came up when building the result.

 - All remaining commentary will be about
   src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp

  - CHECK_*() macros

    Macro bodies should not end in a semi-colon.

    If these were public and since these macro bodies are all if
    statements, you should wrap them in do { } while (0), but since
    they're private we can make sure that all uses are correct.

  - gss_import_name() doesn't check that the first two bytes of the
    input buffer are the expected token ID when the name-type is
    GSS_C_NT_EXPORTED_NAME.

  - gss_import_name() doesn't check that the third byte of the input
    buffer is 0 when the name-type is GSS_C_NT_EXPORTED_NAME.

  - gss_compare_name(), this code will not distinguish a name of the
    form 'foo@' from 'foo\@'

       434     if (l1 < l2 && n2[l1] != L'@'
       435             || l2 < l1 && n1[l2] != L'@') {
       436         return GSS_S_COMPLETE; // different
       437     }

    Honestly, this is not the most serious problem because nothing
    really should be using gss_compare_name(), but you do use it... and
    anyways, it's wrong.

    Perhaps the gss_name_struct struct should have a length of realm or
    length-of-not-realm-part field to make this check easier.

  - gss_compare_name(), do not use NORM_IGNORECASE

  - gss_canonicalize_name() should check that mech_type is Kerberos

I'll continue later.  I'm in gss_init_sec_context(), about 58% of the
way through.

Nico
-- 


From weijun.wang at oracle.com  Tue Jun 11 00:39:34 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Jun 2019 08:39:34 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
Message-ID: <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>

The "keytool -list" output contains a creation data (I know it's useless now), so if THIS_FILE and THAT_FILE happen to be created on different dates then you will see difference.

--Max

> On Jun 11, 2019, at 7:37 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> 
> On 2019-06-10 16:23, David Holmes wrote:
>> Hi Erik,
>> 
>> On 11/06/2019 5:37 am, Erik Joelsson wrote:
>>> Since JDK-8193255, when we started generating the cacerts file in the build, the build compare baseline builds have started failing. It seems the cacerts binary file has some non determinism built in so it doesn't get generated exactly the same given the same input. This patch adds special handling when comparing that file by comparing the output of "keytool -list" on the files instead.
>> 
>> Seems a reasonable approach.
>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>> 
>> Code changes seem fine.
> Thanks!
>> I'm assuming this formulation doesn't run into the:
>> 
>> Warning: use -cacerts option to access cacerts keystore
>> 
>> that you get if you actually point keytool to the cacerts files in the JDK image:
>> 
>> > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit > certs.1
>> Warning: use -cacerts option to access cacerts keystore
>> 
> I did not see that. I would guess it's because I'm not running keytool from the images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded image), or in the cross compilation case, it's running from the buildjdk. I just tried it manually, and it seems the warning is only printed if trying to list the cacerts file from the same image.
> 
> /Erik
> 
>> Thanks,
>> David
>> -----
>> 
>>> /Erik
>>> 



From weijun.wang at oracle.com  Tue Jun 11 01:05:06 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Jun 2019 09:05:06 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
Message-ID: <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>

keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"

would exclude the date (which has its own line).

--Max

> On Jun 11, 2019, at 8:39 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> The "keytool -list" output contains a creation data (I know it's useless now), so if THIS_FILE and THAT_FILE happen to be created on different dates then you will see difference.
> 
> --Max
> 
>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> 
>> 
>> On 2019-06-10 16:23, David Holmes wrote:
>>> Hi Erik,
>>> 
>>> On 11/06/2019 5:37 am, Erik Joelsson wrote:
>>>> Since JDK-8193255, when we started generating the cacerts file in the build, the build compare baseline builds have started failing. It seems the cacerts binary file has some non determinism built in so it doesn't get generated exactly the same given the same input. This patch adds special handling when comparing that file by comparing the output of "keytool -list" on the files instead.
>>> 
>>> Seems a reasonable approach.
>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>> 
>>> Code changes seem fine.
>> Thanks!
>>> I'm assuming this formulation doesn't run into the:
>>> 
>>> Warning: use -cacerts option to access cacerts keystore
>>> 
>>> that you get if you actually point keytool to the cacerts files in the JDK image:
>>> 
>>>> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit > certs.1
>>> Warning: use -cacerts option to access cacerts keystore
>>> 
>> I did not see that. I would guess it's because I'm not running keytool from the images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded image), or in the cross compilation case, it's running from the buildjdk. I just tried it manually, and it seems the warning is only printed if trying to list the cacerts file from the same image.
>> 
>> /Erik
>> 
>>> Thanks,
>>> David
>>> -----
>>> 
>>>> /Erik
>>>> 
> 



From david.holmes at oracle.com  Tue Jun 11 02:09:26 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Jun 2019 12:09:26 +1000
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
Message-ID: <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>

Hi Max,

On 11/06/2019 11:05 am, Weijun Wang wrote:
> keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
> 
> would exclude the date (which has its own line).

I don't see any "Creation Date" entry when I run the tool:

 > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/support/interim-image/lib/security/cacerts 
-storepass changeit | grep Creat
 >

It only appears with the -rfc option which Erik hasn't used.

David
-----

> --Max
> 
>> On Jun 11, 2019, at 8:39 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> The "keytool -list" output contains a creation data (I know it's useless now), so if THIS_FILE and THAT_FILE happen to be created on different dates then you will see difference.
>>
>> --Max
>>
>>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>
>>>
>>> On 2019-06-10 16:23, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>> On 11/06/2019 5:37 am, Erik Joelsson wrote:
>>>>> Since JDK-8193255, when we started generating the cacerts file in the build, the build compare baseline builds have started failing. It seems the cacerts binary file has some non determinism built in so it doesn't get generated exactly the same given the same input. This patch adds special handling when comparing that file by comparing the output of "keytool -list" on the files instead.
>>>>
>>>> Seems a reasonable approach.
>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>
>>>> Code changes seem fine.
>>> Thanks!
>>>> I'm assuming this formulation doesn't run into the:
>>>>
>>>> Warning: use -cacerts option to access cacerts keystore
>>>>
>>>> that you get if you actually point keytool to the cacerts files in the JDK image:
>>>>
>>>>> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit > certs.1
>>>> Warning: use -cacerts option to access cacerts keystore
>>>>
>>> I did not see that. I would guess it's because I'm not running keytool from the images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded image), or in the cross compilation case, it's running from the buildjdk. I just tried it manually, and it seems the warning is only printed if trying to list the cacerts file from the same image.
>>>
>>> /Erik
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>> /Erik
>>>>>
>>
> 


From weijun.wang at oracle.com  Tue Jun 11 02:11:50 2019
From: weijun.wang at oracle.com (Oracle)
Date: Tue, 11 Jun 2019 02:11:50 +0000 (UTC)
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
Message-ID: <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>


    
    	
    	But you should see the date on the same line as the alias and the type.?
?Max
    	

    	?? Outlook for iOS
    
  



On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" <david.holmes at oracle.com> wrote:










Hi Max,

On 11/06/2019 11:05 am, Weijun Wang wrote:
> keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
> 
> would exclude the date (which has its own line).

I don't see any "Creation Date" entry when I run the tool:

 > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore 
build/linux-x64-debug/support/interim-image/lib/security/cacerts 
-storepass changeit | grep Creat
 >

It only appears with the -rfc option which Erik hasn't used.

David
-----

> --Max
> 
>> On Jun 11, 2019, at 8:39 AM, Weijun Wang  wrote:
>>
>> The "keytool -list" output contains a creation data (I know it's useless now), so if THIS_FILE and THAT_FILE happen to be created on different dates then you will see difference.
>>
>> --Max
>>
>>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson  wrote:
>>>
>>>
>>> On 2019-06-10 16:23, David Holmes wrote:
>>>> Hi Erik,
>>>>
>>>> On 11/06/2019 5:37 am, Erik Joelsson wrote:
>>>>> Since JDK-8193255, when we started generating the cacerts file in the build, the build compare baseline builds have started failing. It seems the cacerts binary file has some non determinism built in so it doesn't get generated exactly the same given the same input. This patch adds special handling when comparing that file by comparing the output of "keytool -list" on the files instead.
>>>>
>>>> Seems a reasonable approach.
>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>
>>>> Code changes seem fine.
>>> Thanks!
>>>> I'm assuming this formulation doesn't run into the:
>>>>
>>>> Warning: use -cacerts option to access cacerts keystore
>>>>
>>>> that you get if you actually point keytool to the cacerts files in the JDK image:
>>>>
>>>>> ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass changeit > certs.1
>>>> Warning: use -cacerts option to access cacerts keystore
>>>>
>>> I did not see that. I would guess it's because I'm not running keytool from the images/jdk/bin dir, but in most cases from the jdk/bin dir (the exploded image), or in the cross compilation case, it's running from the buildjdk. I just tried it manually, and it seems the warning is only printed if trying to list the cacerts file from the same image.
>>>
>>> /Erik
>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>> /Erik
>>>>>
>>
> 







From david.holmes at oracle.com  Tue Jun 11 02:17:13 2019
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Jun 2019 12:17:13 +1000
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
 <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
Message-ID: <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>

On 11/06/2019 12:11 pm, Oracle wrote:
> But you should see the date on the same line as the alias and the type.

Ah I see. I was looking at the output from an old version of cacerts 
that shows things like:

verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...

but now all those old dates are the current build date:

verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...

I'm not sure exactly what gets compared with these comparison builds, so 
can't say if this is an issue.

Thanks,
David

> ?Max
> 
> ?? Outlook for iOS <https://aka.ms/o0ukef>
> 
> 
> 
> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Max,
> 
>     On 11/06/2019 11:05 am, Weijun Wang wrote:
>     > keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
>     > 
>     > would exclude the date (which has its own line).
> 
>     I don't see any "Creation Date" entry when I run the tool:
> 
>       > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>     build/linux-x64-debug/support/interim-image/lib/security/cacerts
>     -storepass changeit | grep Creat
>       >
> 
>     It only appears with the -rfc option which Erik hasn't used.
> 
>     David
>     -----
> 
>     > --Max
>     > 
>     >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> The "keytool -list" output contains a creation data (I
>     know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>     created on different dates then you will see difference. >> >> --Max
>      >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>      >>> On 2019-06-10 16:23, David Holmes wrote: >>>> Hi Erik, >>>>
>      >>>> On 11/06/2019 5:37 am, Erik Joelsson wrote: >>>>> Since
>     JDK-8193255, when we started generating the cacerts file in the
>     build, the build compare baseline builds have started failing. It
>     seems the cacerts binary file has some non determinism built in so
>     it doesn't get generated exactly the same given the same input. This
>     patch adds special handling when comparing that file by comparing
>     the output of "keytool -list" on the files instead. >>>> >>>> Seems
>     a reasonable approach. >>>> >>>>> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>> >>>>> Webrev:
>     http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>> >>>> Code
>     changes seem fine. >>> Thanks! >>>> I'm assuming this formulation
>     doesn't run into the: >>>> >>>> Warning: use -cacerts option to
>     access cacerts keystore >>>> >>>> that you get if you actually point
>     keytool to the cacerts files in the JDK image: >>>> >>>>>
>     ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>     build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>     changeit > certs.1 >>>> Warning: use -cacerts option to access
>     cacerts keystore >>>> >>> I did not see that. I would guess it's
>     because I'm not running keytool from the images/jdk/bin dir, but in
>     most cases from the jdk/bin dir (the exploded image), or in the
>     cross compilation case, it's running from the buildjdk. I just tried
>     it manually, and it seems the warning is only printed if trying to
>     list the cacerts file from the same image. >>> >>> /Erik >>> >>>>
>     Thanks, >>>> David >>>> ----- >>>> >>>>> /Erik >>>>> >> >
> 


From erik.joelsson at oracle.com  Tue Jun 11 14:06:02 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 11 Jun 2019 07:06:02 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
 <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
 <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
Message-ID: <3d8a69a3-2131-16b5-e0bb-670d675809db@oracle.com>

Thanks Max, I will incorporate that.

Removing the date will make the comparison more flexible for sure. Most 
of the time, both builds are generated on the same day, but if a build 
happens to run across midnight (which may more common than one thinks 
considering that many build machines are in UTC and I'm working in PT), 
this could certainly become an issue. Another common use case for me is 
creating a baseline build, then working on a fix over a few days, 
comparing to the same baseline.

/Erik

On 2019-06-10 19:17, David Holmes wrote:
> On 11/06/2019 12:11 pm, Oracle wrote:
>> But you should see the date on the same line as the alias and the type.
>
> Ah I see. I was looking at the output from an old version of cacerts 
> that shows things like:
>
> verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
> digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...
>
> but now all those old dates are the current build date:
>
> verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
> digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...
>
> I'm not sure exactly what gets compared with these comparison builds, 
> so can't say if this is an issue.
>
> Thanks,
> David
>
>> ?Max
>>
>> ?? Outlook for iOS <https://aka.ms/o0ukef>
>>
>>
>>
>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? Hi Max,
>>
>> ??? On 11/06/2019 11:05 am, Weijun Wang wrote:
>> ??? > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
>> "Creation date"
>> ??? > ??? > would exclude the date (which has its own line).
>>
>> ??? I don't see any "Creation Date" entry when I run the tool:
>>
>> ????? > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>> build/linux-x64-debug/support/interim-image/lib/security/cacerts
>> ??? -storepass changeit | grep Creat
>> ????? >
>>
>> ??? It only appears with the -rfc option which Erik hasn't used.
>>
>> ??? David
>> ??? -----
>>
>> ??? > --Max
>> ??? > ??? >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> 
>> The "keytool -list" output contains a creation data (I
>> ??? know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>> ??? created on different dates then you will see difference. >> >> --Max
>> ???? >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>> ???? >>> On 2019-06-10 16:23, David Holmes wrote: >>>> Hi Erik, >>>>
>> ???? >>>> On 11/06/2019 5:37 am, Erik Joelsson wrote: >>>>> Since
>> ??? JDK-8193255, when we started generating the cacerts file in the
>> ??? build, the build compare baseline builds have started failing. It
>> ??? seems the cacerts binary file has some non determinism built in so
>> ??? it doesn't get generated exactly the same given the same input. This
>> ??? patch adds special handling when comparing that file by comparing
>> ??? the output of "keytool -list" on the files instead. >>>> >>>> Seems
>> ??? a reasonable approach. >>>> >>>>> Bug:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>> >>>>> Webrev:
>> ??? http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>> >>>> Code
>> ??? changes seem fine. >>> Thanks! >>>> I'm assuming this formulation
>> ??? doesn't run into the: >>>> >>>> Warning: use -cacerts option to
>> ??? access cacerts keystore >>>> >>>> that you get if you actually point
>> ??? keytool to the cacerts files in the JDK image: >>>> >>>>>
>> ??? ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>> ??? build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>> ??? changeit > certs.1 >>>> Warning: use -cacerts option to access
>> ??? cacerts keystore >>>> >>> I did not see that. I would guess it's
>> ??? because I'm not running keytool from the images/jdk/bin dir, but in
>> ??? most cases from the jdk/bin dir (the exploded image), or in the
>> ??? cross compilation case, it's running from the buildjdk. I just tried
>> ??? it manually, and it seems the warning is only printed if trying to
>> ??? list the cacerts file from the same image. >>> >>> /Erik >>> >>>>
>> ??? Thanks, >>>> David >>>> ----- >>>> >>>>> /Erik >>>>> >> >
>>


From erik.joelsson at oracle.com  Tue Jun 11 14:48:50 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 11 Jun 2019 07:48:50 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
 <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
 <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
Message-ID: <7634ac29-475a-2442-279f-04d4c15cc10c@oracle.com>

New webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.02

Filtering out the date and adding a sort. All my builds yesterday 
resulted in cacerts files with the same order of the keys, but today the 
order changed. Looking through the source (JavaKeyStore.engineStore()), 
the store method just iterates over the keys of a Hashtable, so the 
order is indeed random. I think it would be a good idea to add a sort 
there to make our tools better at reproducible output.

I also fixed a bug in compare.sh which prevented me from running a 
compare of just the cacerts files using the filter functionality.

/Erik

On 2019-06-10 19:17, David Holmes wrote:
> On 11/06/2019 12:11 pm, Oracle wrote:
>> But you should see the date on the same line as the alias and the type.
>
> Ah I see. I was looking at the output from an old version of cacerts 
> that shows things like:
>
> verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
> digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...
>
> but now all those old dates are the current build date:
>
> verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
> digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...
>
> I'm not sure exactly what gets compared with these comparison builds, 
> so can't say if this is an issue.
>
> Thanks,
> David
>
>> ?Max
>>
>> ?? Outlook for iOS <https://aka.ms/o0ukef>
>>
>>
>>
>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>
>> ??? Hi Max,
>>
>> ??? On 11/06/2019 11:05 am, Weijun Wang wrote:
>> ??? > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
>> "Creation date"
>> ??? > ??? > would exclude the date (which has its own line).
>>
>> ??? I don't see any "Creation Date" entry when I run the tool:
>>
>> ????? > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>> build/linux-x64-debug/support/interim-image/lib/security/cacerts
>> ??? -storepass changeit | grep Creat
>> ????? >
>>
>> ??? It only appears with the -rfc option which Erik hasn't used.
>>
>> ??? David
>> ??? -----
>>
>> ??? > --Max
>> ??? > ??? >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> 
>> The "keytool -list" output contains a creation data (I
>> ??? know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>> ??? created on different dates then you will see difference. >> >> --Max
>> ???? >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>> ???? >>> On 2019-06-10 16:23, David Holmes wrote: >>>> Hi Erik, >>>>
>> ???? >>>> On 11/06/2019 5:37 am, Erik Joelsson wrote: >>>>> Since
>> ??? JDK-8193255, when we started generating the cacerts file in the
>> ??? build, the build compare baseline builds have started failing. It
>> ??? seems the cacerts binary file has some non determinism built in so
>> ??? it doesn't get generated exactly the same given the same input. This
>> ??? patch adds special handling when comparing that file by comparing
>> ??? the output of "keytool -list" on the files instead. >>>> >>>> Seems
>> ??? a reasonable approach. >>>> >>>>> Bug:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>> >>>>> Webrev:
>> ??? http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>> >>>> Code
>> ??? changes seem fine. >>> Thanks! >>>> I'm assuming this formulation
>> ??? doesn't run into the: >>>> >>>> Warning: use -cacerts option to
>> ??? access cacerts keystore >>>> >>>> that you get if you actually point
>> ??? keytool to the cacerts files in the JDK image: >>>> >>>>>
>> ??? ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>> ??? build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>> ??? changeit > certs.1 >>>> Warning: use -cacerts option to access
>> ??? cacerts keystore >>>> >>> I did not see that. I would guess it's
>> ??? because I'm not running keytool from the images/jdk/bin dir, but in
>> ??? most cases from the jdk/bin dir (the exploded image), or in the
>> ??? cross compilation case, it's running from the buildjdk. I just tried
>> ??? it manually, and it seems the warning is only printed if trying to
>> ??? list the cacerts file from the same image. >>> >>> /Erik >>> >>>>
>> ??? Thanks, >>>> David >>>> ----- >>>> >>>>> /Erik >>>>> >> >
>>


From weijun.wang at oracle.com  Tue Jun 11 14:53:53 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 11 Jun 2019 22:53:53 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <3d8a69a3-2131-16b5-e0bb-670d675809db@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
 <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
 <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
 <3d8a69a3-2131-16b5-e0bb-670d675809db@oracle.com>
Message-ID: <4E9B1664-2EB1-43E9-939D-BD5D263F1E0C@oracle.com>

In JKS the certs are stored in a Hashtable so there is no defined order. If we migrate it to another store type (we are planning for it) there can be another order. Maybe this won;t be an issue, the order is at least not random.

Or maybe I can update keytool to always list the entries in alphabetical order.

--Max

> On Jun 11, 2019, at 10:06 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Thanks Max, I will incorporate that.
> 
> Removing the date will make the comparison more flexible for sure. Most of the time, both builds are generated on the same day, but if a build happens to run across midnight (which may more common than one thinks considering that many build machines are in UTC and I'm working in PT), this could certainly become an issue. Another common use case for me is creating a baseline build, then working on a fix over a few days, comparing to the same baseline.
> 
> /Erik
> 
> On 2019-06-10 19:17, David Holmes wrote:
>> On 11/06/2019 12:11 pm, Oracle wrote:
>>> But you should see the date on the same line as the alias and the type.
>> 
>> Ah I see. I was looking at the output from an old version of cacerts that shows things like:
>> 
>> verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
>> digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...
>> 
>> but now all those old dates are the current build date:
>> 
>> verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
>> digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...
>> 
>> I'm not sure exactly what gets compared with these comparison builds, so can't say if this is an issue.
>> 
>> Thanks,
>> David
>> 
>>> ?Max
>>> 
>>> ?? Outlook for iOS <https://aka.ms/o0ukef>
>>> 
>>> 
>>> 
>>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>> 
>>>     Hi Max,
>>> 
>>>     On 11/06/2019 11:05 am, Weijun Wang wrote:
>>>     > keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
>>>     >     > would exclude the date (which has its own line).
>>> 
>>>     I don't see any "Creation Date" entry when I run the tool:
>>> 
>>>       > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>> build/linux-x64-debug/support/interim-image/lib/security/cacerts
>>>     -storepass changeit | grep Creat
>>>       >
>>> 
>>>     It only appears with the -rfc option which Erik hasn't used.
>>> 
>>>     David
>>>     -----
>>> 
>>>     > --Max
>>>     >     >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> The "keytool -list" output contains a creation data (I
>>>     know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>>>     created on different dates then you will see difference. >> >> --Max
>>>      >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>>>      >>> On 2019-06-10 16:23, David Holmes wrote: >>>> Hi Erik, >>>>
>>>      >>>> On 11/06/2019 5:37 am, Erik Joelsson wrote: >>>>> Since
>>>     JDK-8193255, when we started generating the cacerts file in the
>>>     build, the build compare baseline builds have started failing. It
>>>     seems the cacerts binary file has some non determinism built in so
>>>     it doesn't get generated exactly the same given the same input. This
>>>     patch adds special handling when comparing that file by comparing
>>>     the output of "keytool -list" on the files instead. >>>> >>>> Seems
>>>     a reasonable approach. >>>> >>>>> Bug:
>>>     https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>> >>>>> Webrev:
>>>     http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>> >>>> Code
>>>     changes seem fine. >>> Thanks! >>>> I'm assuming this formulation
>>>     doesn't run into the: >>>> >>>> Warning: use -cacerts option to
>>>     access cacerts keystore >>>> >>>> that you get if you actually point
>>>     keytool to the cacerts files in the JDK image: >>>> >>>>>
>>>     ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>>     build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>>>     changeit > certs.1 >>>> Warning: use -cacerts option to access
>>>     cacerts keystore >>>> >>> I did not see that. I would guess it's
>>>     because I'm not running keytool from the images/jdk/bin dir, but in
>>>     most cases from the jdk/bin dir (the exploded image), or in the
>>>     cross compilation case, it's running from the buildjdk. I just tried
>>>     it manually, and it seems the warning is only printed if trying to
>>>     list the cacerts file from the same image. >>> >>> /Erik >>> >>>>
>>>     Thanks, >>>> David >>>> ----- >>>> >>>>> /Erik >>>>> >> >
>>> 



From erik.joelsson at oracle.com  Tue Jun 11 14:59:25 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 11 Jun 2019 07:59:25 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <4E9B1664-2EB1-43E9-939D-BD5D263F1E0C@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
 <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
 <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
 <3d8a69a3-2131-16b5-e0bb-670d675809db@oracle.com>
 <4E9B1664-2EB1-43E9-939D-BD5D263F1E0C@oracle.com>
Message-ID: <be2c24cc-e948-c8a6-2633-7ad3468c3636@oracle.com>

On 2019-06-11 07:53, Weijun Wang wrote:
> In JKS the certs are stored in a Hashtable so there is no defined order. If we migrate it to another store type (we are planning for it) there can be another order. Maybe this won;t be an issue, the order is at least not random.

Hm, I thought the Hashtable would be random, but perhaps it stable as 
long as elements the elements are added in a stable order? In that case, 
then adding a sort when reading the files in the build tool would be 
enough to guarantee a stable order.

Note that it's OK for the order to change with future changes to the 
implementation. What we like to avoid is just different output from the 
same sources.

> Or maybe I can update keytool to always list the entries in alphabetical order.

That would be appreciated. From a build point of view, we like to 
minimize any randomness in the build results.

/Erik

> --Max
>
>> On Jun 11, 2019, at 10:06 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Thanks Max, I will incorporate that.
>>
>> Removing the date will make the comparison more flexible for sure. Most of the time, both builds are generated on the same day, but if a build happens to run across midnight (which may more common than one thinks considering that many build machines are in UTC and I'm working in PT), this could certainly become an issue. Another common use case for me is creating a baseline build, then working on a fix over a few days, comparing to the same baseline.
>>
>> /Erik
>>
>> On 2019-06-10 19:17, David Holmes wrote:
>>> On 11/06/2019 12:11 pm, Oracle wrote:
>>>> But you should see the date on the same line as the alias and the type.
>>> Ah I see. I was looking at the output from an old version of cacerts that shows things like:
>>>
>>> verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
>>> digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...
>>>
>>> but now all those old dates are the current build date:
>>>
>>> verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
>>> digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...
>>>
>>> I'm not sure exactly what gets compared with these comparison builds, so can't say if this is an issue.
>>>
>>> Thanks,
>>> David
>>>
>>>> ?Max
>>>>
>>>> ?? Outlook for iOS <https://aka.ms/o0ukef>
>>>>
>>>>
>>>>
>>>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>>
>>>>      Hi Max,
>>>>
>>>>      On 11/06/2019 11:05 am, Weijun Wang wrote:
>>>>      > keytool -keystore .. -storepass changeit -list -rfc | grep -v "Creation date"
>>>>      >     > would exclude the date (which has its own line).
>>>>
>>>>      I don't see any "Creation Date" entry when I run the tool:
>>>>
>>>>        > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>>> build/linux-x64-debug/support/interim-image/lib/security/cacerts
>>>>      -storepass changeit | grep Creat
>>>>        >
>>>>
>>>>      It only appears with the -rfc option which Erik hasn't used.
>>>>
>>>>      David
>>>>      -----
>>>>
>>>>      > --Max
>>>>      >     >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> The "keytool -list" output contains a creation data (I
>>>>      know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>>>>      created on different dates then you will see difference. >> >> --Max
>>>>       >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>>>>       >>> On 2019-06-10 16:23, David Holmes wrote: >>>> Hi Erik, >>>>
>>>>       >>>> On 11/06/2019 5:37 am, Erik Joelsson wrote: >>>>> Since
>>>>      JDK-8193255, when we started generating the cacerts file in the
>>>>      build, the build compare baseline builds have started failing. It
>>>>      seems the cacerts binary file has some non determinism built in so
>>>>      it doesn't get generated exactly the same given the same input. This
>>>>      patch adds special handling when comparing that file by comparing
>>>>      the output of "keytool -list" on the files instead. >>>> >>>> Seems
>>>>      a reasonable approach. >>>> >>>>> Bug:
>>>>      https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>> >>>>> Webrev:
>>>>      http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>> >>>> Code
>>>>      changes seem fine. >>> Thanks! >>>> I'm assuming this formulation
>>>>      doesn't run into the: >>>> >>>> Warning: use -cacerts option to
>>>>      access cacerts keystore >>>> >>>> that you get if you actually point
>>>>      keytool to the cacerts files in the JDK image: >>>> >>>>>
>>>>      ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>>>      build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>>>>      changeit > certs.1 >>>> Warning: use -cacerts option to access
>>>>      cacerts keystore >>>> >>> I did not see that. I would guess it's
>>>>      because I'm not running keytool from the images/jdk/bin dir, but in
>>>>      most cases from the jdk/bin dir (the exploded image), or in the
>>>>      cross compilation case, it's running from the buildjdk. I just tried
>>>>      it manually, and it seems the warning is only printed if trying to
>>>>      list the cacerts file from the same image. >>> >>> /Erik >>> >>>>
>>>>      Thanks, >>>> David >>>> ----- >>>> >>>>> /Erik >>>>> >> >
>>>>


From sgehwolf at redhat.com  Tue Jun 11 17:04:25 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 11 Jun 2019 19:04:25 +0200
Subject: PING? Re: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like
 testing in OpenJDK 8u
In-Reply-To: <38f5d5d356e7dba6162ff1cee7752ccebf0aff65.camel@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <a0695f0d-2e9e-772f-8cbb-b83f8a08bda3@redhat.com>
 <38f5d5d356e7dba6162ff1cee7752ccebf0aff65.camel@redhat.com>
Message-ID: <45b47e3ce7f233211fe57b9364caffe598206432.camel@redhat.com>

Hi!

Any more thoughts on this? It would be nice to get this reviewed :)

Thanks,
Severin

On Thu, 2019-05-23 at 11:53 +0200, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Thu, 2019-05-23 at 09:34 +0100, Andrew Dinn wrote:
> > Hi Severin,
> > 
> > On 22/05/2019 17:34, Severin Gehwolf wrote:
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
> > >         (includes changes to top/hotspot/jdk/langtools repos)
> > > 
> > > Example excerpt from a run:
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
> > > 
> > > Thoughts?
> > Unfortunately, my makefile fu is too limited to provide a reliable
> > review of the patch (I'm mostly just surprised it took so few changes to
> > achieve). However, I can still wholeheartedly applaud this endeavour and
> > its present outcome.
> 
> :) Great.
> 
> > As you say tuning the test group can be done over time as a follow-up.
> > The important thing is to quickly place devs in a position to easily
> > check that fixes have no unintended side-effects. Very nice!
> 
> Thanks for looking this over!
> 
> Cheers,
> Severin



From weijun.wang at oracle.com  Tue Jun 11 23:35:28 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jun 2019 07:35:28 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190610235635.GL7457@twosigma.com>
References: <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
 <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
 <20190610235635.GL7457@twosigma.com>
Message-ID: <41B62B2B-446B-4347-B4B3-DC93C1DEC3B6@oracle.com>

Oops, I almost wanted to push my changeset yesterday and saw your mail.

Non of your comment are showstoppers. I'd like to push my current change and file a follow on bug on them.

And DLLs have been in bin all the time.

Thanks,
Max

> On Jun 11, 2019, at 7:56 AM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>> 
>>   http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
> 
> - src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java
> 
>   Ugh, I never noticed GSSUtil.useMSInterop().  This really should not
>   be needed.  I believe a proper implementation of RFC4178 wouldn't
>   need it.
> 
>   I can't expect you to do that, but can we have a bug opened for this?
> 
> - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
> 
>   Shouldn't the sspi_bridge.dll be in the lib directory?
> 
> - src/java.security.jgss/share/native/libj2gss/NativeFunc.h
> - src/java.security.jgss/share/native/libj2gss/gssapi.h
> 
>   These continue to have improper constification.
> 
>   There should be no function arguments of type "const gss_...".
> 
>   I've a PR for Heimdal to fix this in Heimdal.  It was very
>   mechanical: search the prototypes and function definitions for
> 
>       \<const[^I ]*gss_
> 
>   then change that to gss_const_... then fix all the warnings and
>   errors that came up when building the result.
> 
> - All remaining commentary will be about
>   src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
> 
>  - CHECK_*() macros
> 
>    Macro bodies should not end in a semi-colon.
> 
>    If these were public and since these macro bodies are all if
>    statements, you should wrap them in do { } while (0), but since
>    they're private we can make sure that all uses are correct.
> 
>  - gss_import_name() doesn't check that the first two bytes of the
>    input buffer are the expected token ID when the name-type is
>    GSS_C_NT_EXPORTED_NAME.
> 
>  - gss_import_name() doesn't check that the third byte of the input
>    buffer is 0 when the name-type is GSS_C_NT_EXPORTED_NAME.
> 
>  - gss_compare_name(), this code will not distinguish a name of the
>    form 'foo@' from 'foo\@'
> 
>       434     if (l1 < l2 && n2[l1] != L'@'
>       435             || l2 < l1 && n1[l2] != L'@') {
>       436         return GSS_S_COMPLETE; // different
>       437     }
> 
>    Honestly, this is not the most serious problem because nothing
>    really should be using gss_compare_name(), but you do use it... and
>    anyways, it's wrong.
> 
>    Perhaps the gss_name_struct struct should have a length of realm or
>    length-of-not-realm-part field to make this check easier.
> 
>  - gss_compare_name(), do not use NORM_IGNORECASE
> 
>  - gss_canonicalize_name() should check that mech_type is Kerberos
> 
> I'll continue later.  I'm in gss_init_sec_context(), about 58% of the
> way through.
> 
> Nico
> -- 



From david.holmes at oracle.com  Wed Jun 12 02:31:04 2019
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Jun 2019 12:31:04 +1000
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <7634ac29-475a-2442-279f-04d4c15cc10c@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <f0af1088-446e-1140-7ffb-1ae503b2e452@oracle.com>
 <6cbdab16-d91b-eae0-3d50-721bca86abab@oracle.com>
 <2B9A71BD-2149-4A77-A135-C42FBE0057BB@oracle.com>
 <AD3EB7EA-49BC-44C3-827D-0D77469CFD77@oracle.com>
 <3caec950-4994-dcfa-cb10-8ed122f5cc86@oracle.com>
 <74CE60960C160DA6.D6529CF7-FB29-4A1E-9BFF-A0220AF5C3C5@mail.outlook.com>
 <af17b399-0a65-4b4a-cfa7-85d4d04c164f@oracle.com>
 <7634ac29-475a-2442-279f-04d4c15cc10c@oracle.com>
Message-ID: <ef7135a6-12e2-a635-988b-297ac301270d@oracle.com>

Hi Erik,

On 12/06/2019 12:48 am, Erik Joelsson wrote:
> New webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.02
> 
> Filtering out the date and adding a sort. All my builds yesterday 
> resulted in cacerts files with the same order of the keys, but today the 
> order changed. Looking through the source (JavaKeyStore.engineStore()), 
> the store method just iterates over the keys of a Hashtable, so the 
> order is indeed random. I think it would be a good idea to add a sort 
> there to make our tools better at reproducible output.

Seems quite reasonable.

Thanks,
David

> I also fixed a bug in compare.sh which prevented me from running a 
> compare of just the cacerts files using the filter functionality.
> 
> /Erik
> 
> On 2019-06-10 19:17, David Holmes wrote:
>> On 11/06/2019 12:11 pm, Oracle wrote:
>>> But you should see the date on the same line as the alias and the type.
>>
>> Ah I see. I was looking at the output from an old version of cacerts 
>> that shows things like:
>>
>> verisignclass2g2ca [jdk], Jun 12, 2018, trustedCertEntry, ...
>> digicertassuredidg3 [jdk], Nov 30, 2017, trustedCertEntry,...
>>
>> but now all those old dates are the current build date:
>>
>> verisignclass2g2ca [jdk], Jun 10, 2019, trustedCertEntry, ...
>> digicertassuredidg3 [jdk], Jun 10, 2019, trustedCertEntry, ...
>>
>> I'm not sure exactly what gets compared with these comparison builds, 
>> so can't say if this is an issue.
>>
>> Thanks,
>> David
>>
>>> ?Max
>>>
>>> ?? Outlook for iOS <https://aka.ms/o0ukef>
>>>
>>>
>>>
>>> On Tue, Jun 11, 2019 at 10:09 AM +0800, "David Holmes" 
>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> ??? Hi Max,
>>>
>>> ??? On 11/06/2019 11:05 am, Weijun Wang wrote:
>>> ??? > keytool -keystore .. -storepass changeit -list -rfc | grep -v 
>>> "Creation date"
>>> ??? > ??? > would exclude the date (which has its own line).
>>>
>>> ??? I don't see any "Creation Date" entry when I run the tool:
>>>
>>> ????? > ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>> build/linux-x64-debug/support/interim-image/lib/security/cacerts
>>> ??? -storepass changeit | grep Creat
>>> ????? >
>>>
>>> ??? It only appears with the -rfc option which Erik hasn't used.
>>>
>>> ??? David
>>> ??? -----
>>>
>>> ??? > --Max
>>> ??? > ??? >> On Jun 11, 2019, at 8:39 AM, Weijun Wang wrote: >> >> 
>>> The "keytool -list" output contains a creation data (I
>>> ??? know it's useless now), so if THIS_FILE and THAT_FILE happen to be
>>> ??? created on different dates then you will see difference. >> >> --Max
>>> ???? >> >>> On Jun 11, 2019, at 7:37 AM, Erik Joelsson wrote: >>> >>>
>>> ???? >>> On 2019-06-10 16:23, David Holmes wrote: >>>> Hi Erik, >>>>
>>> ???? >>>> On 11/06/2019 5:37 am, Erik Joelsson wrote: >>>>> Since
>>> ??? JDK-8193255, when we started generating the cacerts file in the
>>> ??? build, the build compare baseline builds have started failing. It
>>> ??? seems the cacerts binary file has some non determinism built in so
>>> ??? it doesn't get generated exactly the same given the same input. This
>>> ??? patch adds special handling when comparing that file by comparing
>>> ??? the output of "keytool -list" on the files instead. >>>> >>>> Seems
>>> ??? a reasonable approach. >>>> >>>>> Bug:
>>> ??? https://bugs.openjdk.java.net/browse/JDK-8225392 >>>>> >>>>> Webrev:
>>> ??? http://cr.openjdk.java.net/~erikj/8225392/webrev.01/ >>>> >>>> Code
>>> ??? changes seem fine. >>> Thanks! >>>> I'm assuming this formulation
>>> ??? doesn't run into the: >>>> >>>> Warning: use -cacerts option to
>>> ??? access cacerts keystore >>>> >>>> that you get if you actually point
>>> ??? keytool to the cacerts files in the JDK image: >>>> >>>>>
>>> ??? ./build/linux-x64-debug/images/jdk/bin/keytool -list -keystore
>>> ??? build/linux-x64-debug/images/jdk/lib/security/cacerts -storepass
>>> ??? changeit > certs.1 >>>> Warning: use -cacerts option to access
>>> ??? cacerts keystore >>>> >>> I did not see that. I would guess it's
>>> ??? because I'm not running keytool from the images/jdk/bin dir, but in
>>> ??? most cases from the jdk/bin dir (the exploded image), or in the
>>> ??? cross compilation case, it's running from the buildjdk. I just tried
>>> ??? it manually, and it seems the warning is only printed if trying to
>>> ??? list the cacerts file from the same image. >>> >>> /Erik >>> >>>>
>>> ??? Thanks, >>>> David >>>> ----- >>>> >>>>> /Erik >>>>> >> >
>>>


From martinrb at google.com  Wed Jun 12 02:53:05 2019
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Jun 2019 19:53:05 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
Message-ID: <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>

Google culture really likes build output determinism, and we recently built
our own cacerts generator.

To get determinism, we are using cert digest as alias (must have a unique
alias, but value doesn't seem to matter much), and using cert notBefore
instead of current (build) timestamp.

On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Since JDK-8193255, when we started generating the cacerts file in the
> build, the build compare baseline builds have started failing. It seems
> the cacerts binary file has some non determinism built in so it doesn't
> get generated exactly the same given the same input. This patch adds
> special handling when comparing that file by comparing the output of
> "keytool -list" on the files instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>
> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>
> /Erik
>
>


From weijun.wang at oracle.com  Wed Jun 12 02:59:25 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jun 2019 10:59:25 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
Message-ID: <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>

Good idea about the creation time.

--Max

> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Google culture really likes build output determinism, and we recently built our own cacerts generator.
> 
> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
> 
> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Since JDK-8193255, when we started generating the cacerts file in the 
> build, the build compare baseline builds have started failing. It seems 
> the cacerts binary file has some non determinism built in so it doesn't 
> get generated exactly the same given the same input. This patch adds 
> special handling when comparing that file by comparing the output of 
> "keytool -list" on the files instead.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
> 
> /Erik
> 



From nick.gasson at arm.com  Wed Jun 12 09:35:32 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Wed, 12 Jun 2019 17:35:32 +0800
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
Message-ID: <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>

Hi Andrew,

Sorry for the delay, I've put an updated webrev here:

http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/

Changes since the last patch:

* Replaced ~((1<<12) - 1) with -1u<<12

* Use __atomic_add_fetch in Atomic::PlatformAdd #ifdef __clang__

* Use __builtin_frame_address(0) in os::current_frame()

* Use placement new / copy assignment in pf()

I also replaced the call to _get_previous_fp() in os::current_frame() with

   *(intptr_t **)__builtin_frame_address(0);

As it generates the same code and avoids the `register intptr_t **fp 
__asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also 
the following comment in _get_previous_fp seems to be wrong:

   // fp is for this frame (_get_previous_fp). We want the fp for the
   // caller of os::current_frame*(), so go up two frames. However, for
   // optimized builds, _get_previous_fp() will be inlined, so only go
   // up 1 frame in that case.
   #ifdef _NMT_NOINLINE_
     return **(intptr_t***)fp;
   #else
     return *fp;
   #endif

Even on -O0 gcc won't generate a stack frame for this function so if 
_NMT_NOINLINE_ is defined you get the caller's caller's FP rather than 
the caller's FP. I just deleted the function as it's not used anywhere else.

BTW we can't use __builtin_frame_address(1) as GCC gives a warning when 
this is called with a non-zero argument (-Wframe-address).

Tested jtreg hotspot_all_no_apps and jdk_core (gcc 7.3).


Thanks,
Nick


On 03/06/2019 19:03, Andrew Haley wrote:
> Hi,
> 
> On 6/3/19 11:36 AM, Nick Gasson wrote:
>>
>>> We need to know what it's used for to know which solution is right. I'm
>>> guessing the primary use case is asynchronous runtime stack probes, used
>>> by debugging tools.
>>>
>>
>> Yes, we also have os::stack_shadow_pages_available() which uses it to
>> calculate how much space there is between the current SP and the end of
>> the stack. In this case I think it's ok as long as we don't return a
>> value that's *above* the actual stack pointer. And os::current_frame(),
>> which constructs a `frame' object using the FP of the caller, but the SP
>> will point into the frame of os::current_frame(), so it seems it's
>> already inaccurate.
> 
> Eww.
> 
>> There's also a comment in os_linux.cpp that says "Don't use
>> os::current_stack_pointer(), as its result can be slightly below current
>> stack pointer". So I'm wondering if we can simplify this a lot and use
>> __builtin_frame_address(0) which will give us the FP in
>> os::current_stack_pointer (ought to be the caller's SP - 16). Zero does
>> this currently. And maybe we can replace _get_previous_fp() with
>> __builtin_frame_address(1)?
> 
> Let's make os::current_stack_pointer() noinline, then make it return
> __builtin_frame_address(0).
> 


From weijun.wang at oracle.com  Wed Jun 12 14:50:18 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jun 2019 22:50:18 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
Message-ID: <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>

Hi Erik,

Are you going to fix this bug soon?

I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.

Thanks,
Max

> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Good idea about the creation time.
> 
> --Max
> 
>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
>> 
>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
>> 
>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Since JDK-8193255, when we started generating the cacerts file in the 
>> build, the build compare baseline builds have started failing. It seems 
>> the cacerts binary file has some non determinism built in so it doesn't 
>> get generated exactly the same given the same input. This patch adds 
>> special handling when comparing that file by comparing the output of 
>> "keytool -list" on the files instead.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>> 
>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>> 
>> /Erik
>> 
> 



From weijun.wang at oracle.com  Wed Jun 12 15:41:51 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jun 2019 23:41:51 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
Message-ID: <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>

This is my version of the fix:

   http://cr.openjdk.java.net/~weijun/8225392/webrev.00/

Now you can still compare cacerts bit by bit.

Thanks,
Max

> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi Erik,
> 
> Are you going to fix this bug soon?
> 
> I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.
> 
> Thanks,
> Max
> 
>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Good idea about the creation time.
>> 
>> --Max
>> 
>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
>>> 
>>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
>>> 
>>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
>>> 
>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>> Since JDK-8193255, when we started generating the cacerts file in the 
>>> build, the build compare baseline builds have started failing. It seems 
>>> the cacerts binary file has some non determinism built in so it doesn't 
>>> get generated exactly the same given the same input. This patch adds 
>>> special handling when comparing that file by comparing the output of 
>>> "keytool -list" on the files instead.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>> 
>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>> 
>>> /Erik
>>> 
>> 
> 



From martinrb at google.com  Wed Jun 12 16:16:17 2019
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 12 Jun 2019 09:16:17 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
Message-ID: <CA+kOe09ukMy+NkRSOqU57Z5p8KmdRDEfm+MOGWEzYjU8-Hmkug@mail.gmail.com>

I'm not a security engineer, but:
- consider creating static finals for e.g. "Mighty Aphrodite" just to give
it a symbolic name.
- VerifyCACerts probably fails when the jdk is configured with a different
cacerts file (but the JDK doesn't preserve configuration information - how
could one fix it?)
Many downstream organizations will configure a different cacerts.

On Wed, Jun 12, 2019 at 8:42 AM Weijun Wang <weijun.wang at oracle.com> wrote:

> This is my version of the fix:
>
>    http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>
> Now you can still compare cacerts bit by bit.
>
> Thanks,
> Max
>
> > On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com>
> wrote:
> >
> > Hi Erik,
> >
> > Are you going to fix this bug soon?
> >
> > I am inspired by Martin's words and would like to update
> GenerateCacerts.java so that as long as the certs and their aliases are
> unchanged, the output cacerts will always be the same. I can send out a
> code review today.
> >
> > Thanks,
> > Max
> >
> >> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com>
> wrote:
> >>
> >> Good idea about the creation time.
> >>
> >> --Max
> >>
> >>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com>
> wrote:
> >>>
> >>> Google culture really likes build output determinism, and we recently
> built our own cacerts generator.
> >>>
> >>> To get determinism, we are using cert digest as alias (must have a
> unique alias, but value doesn't seem to matter much), and using cert
> notBefore instead of current (build) timestamp.
> >>>
> >>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <
> erik.joelsson at oracle.com> wrote:
> >>> Since JDK-8193255, when we started generating the cacerts file in the
> >>> build, the build compare baseline builds have started failing. It
> seems
> >>> the cacerts binary file has some non determinism built in so it
> doesn't
> >>> get generated exactly the same given the same input. This patch adds
> >>> special handling when comparing that file by comparing the output of
> >>> "keytool -list" on the files instead.
> >>>
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
> >>>
> >>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
> >>>
> >>> /Erik
> >>>
> >>
> >
>
>


From erik.joelsson at oracle.com  Wed Jun 12 16:38:55 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Jun 2019 09:38:55 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
Message-ID: <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>

Hello Max,

Much appreciated! I will need to have this fixed one way or other in JDK 
13, so depending on if you get your fix there in time, I will retract my 
proposal. If your fix only hits 14, I will push mine to 13.

/Erik

On 2019-06-12 08:41, Weijun Wang wrote:
> This is my version of the fix:
>
>     http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>
> Now you can still compare cacerts bit by bit.
>
> Thanks,
> Max
>
>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Hi Erik,
>>
>> Are you going to fix this bug soon?
>>
>> I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.
>>
>> Thanks,
>> Max
>>
>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>
>>> Good idea about the creation time.
>>>
>>> --Max
>>>
>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
>>>>
>>>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
>>>>
>>>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
>>>>
>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>> Since JDK-8193255, when we started generating the cacerts file in the
>>>> build, the build compare baseline builds have started failing. It seems
>>>> the cacerts binary file has some non determinism built in so it doesn't
>>>> get generated exactly the same given the same input. This patch adds
>>>> special handling when comparing that file by comparing the output of
>>>> "keytool -list" on the files instead.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>
>>>> /Erik
>>>>


From sean.mullan at oracle.com  Wed Jun 12 18:39:23 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 12 Jun 2019 14:39:23 -0400
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
Message-ID: <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>

Using the certificate's notBefore date as the KeyStore entry creation 
date is misleading since many of these root certs were not integrated 
into the JDK until after they were created by the CA. Can we somehow 
extract the last revision time of each PEM file instead? That is more 
aligned with the previous creation date that we used.

--Sean

On 6/12/19 12:38 PM, Erik Joelsson wrote:
> Hello Max,
> 
> Much appreciated! I will need to have this fixed one way or other in JDK 
> 13, so depending on if you get your fix there in time, I will retract my 
> proposal. If your fix only hits 14, I will push mine to 13.
> 
> /Erik
> 
> On 2019-06-12 08:41, Weijun Wang wrote:
>> This is my version of the fix:
>>
>> ??? http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>
>> Now you can still compare cacerts bit by bit.
>>
>> Thanks,
>> Max
>>
>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> 
>>> wrote:
>>>
>>> Hi Erik,
>>>
>>> Are you going to fix this bug soon?
>>>
>>> I am inspired by Martin's words and would like to update 
>>> GenerateCacerts.java so that as long as the certs and their aliases 
>>> are unchanged, the output cacerts will always be the same. I can send 
>>> out a code review today.
>>>
>>> Thanks,
>>> Max
>>>
>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> 
>>>> wrote:
>>>>
>>>> Good idea about the creation time.
>>>>
>>>> --Max
>>>>
>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> 
>>>>> wrote:
>>>>>
>>>>> Google culture really likes build output determinism, and we 
>>>>> recently built our own cacerts generator.
>>>>>
>>>>> To get determinism, we are using cert digest as alias (must have a 
>>>>> unique alias, but value doesn't seem to matter much), and using 
>>>>> cert notBefore instead of current (build) timestamp.
>>>>>
>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson 
>>>>> <erik.joelsson at oracle.com> wrote:
>>>>> Since JDK-8193255, when we started generating the cacerts file in the
>>>>> build, the build compare baseline builds have started failing. It 
>>>>> seems
>>>>> the cacerts binary file has some non determinism built in so it 
>>>>> doesn't
>>>>> get generated exactly the same given the same input. This patch adds
>>>>> special handling when comparing that file by comparing the output of
>>>>> "keytool -list" on the files instead.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>>
>>>>> /Erik
>>>>>


From gnu.andrew at redhat.com  Wed Jun 12 19:34:45 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 12 Jun 2019 20:34:45 +0100
Subject: RFR: [8u] JDK-8223219: Backport of JDK-8199552 to OpenJDK 8 leads to
 duplicate -fstack-protector flags, overriding --with-extra-cflags
Message-ID: <6821a980-84c8-5fae-9006-701d31168bc0@redhat.com>

Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8223219/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8223219

There's quite a long story to this one, more detail of which is in the
bug report. In short, JDK-8199552 was backported as part of a CPU with
no review and so little explanation for the changes contained therein,
which differ from the same change in OpenJDK 11.

The end result is that -fstack-protector is added for only two
architectures - x86 and x86_64 - and it ends up appearing twice for the
JDK part of the build, the second appearance overriding any options
specified using --with-extra-cflags. This is a problem for distros which
may want to use -fstack-protector-strong instead. This patch simplifies
it down to one addition for all architectures.

We've been using this patch (or a variant of it) since the January CPU
on all architectures we build on (AArch64, s390, s390x, ppc, ppc64,
ppc64le, x86 & x86_64) without known issues.

Before patch:

 [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
-Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT
-D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -fstack-protector
-D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
-DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
-I/home/andrew/builder/8u-dev/jdk/include/linux
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common
-O2 -pipe -march=core2 -mno-tls-direct-seg-refs -Wno-error=return-type
-Wno-error=deprecated-declarations -fno-strict-aliasing
-fstack-protector -fno-delete-null-pointer-checks -fno-lifetime-dse
-fPIC -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/nativ\
e/java/lang/fdlibm/include

After patch (the -fstack-protector duplicate after -fno-strict-aliasing
is gone):

 [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
-Wno-unused-parameter -Wformat=2 -pipe -fstack-protector -D_GNU_SOURCE
-D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1
-D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
-DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
-I/home/andrew/builder/8u-dev/jdk/include/linux
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
-I/home/andrew/proje\
cts/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common -O2 -pipe
-march=core2 -ggdb -mno-tls-direct-seg-refs -Wno-error=return-type
-Wno-error=deprecated-declarations -fno-strict-aliasing
-fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC
-I/home/andrew/builder/8u-dev/jdk/gensrc_headers
-I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/include

Ok to push?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From erik.joelsson at oracle.com  Wed Jun 12 20:01:15 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Jun 2019 13:01:15 -0700
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
Message-ID: <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>

Hello,

We cannot rely on querying mercurial at build time. The source must be 
buildable from a source distribution.

/Erik

On 2019-06-12 11:39, Sean Mullan wrote:
> Using the certificate's notBefore date as the KeyStore entry creation 
> date is misleading since many of these root certs were not integrated 
> into the JDK until after they were created by the CA. Can we somehow 
> extract the last revision time of each PEM file instead? That is more 
> aligned with the previous creation date that we used.
>
> --Sean
>
> On 6/12/19 12:38 PM, Erik Joelsson wrote:
>> Hello Max,
>>
>> Much appreciated! I will need to have this fixed one way or other in 
>> JDK 13, so depending on if you get your fix there in time, I will 
>> retract my proposal. If your fix only hits 14, I will push mine to 13.
>>
>> /Erik
>>
>> On 2019-06-12 08:41, Weijun Wang wrote:
>>> This is my version of the fix:
>>>
>>> ??? http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>>
>>> Now you can still compare cacerts bit by bit.
>>>
>>> Thanks,
>>> Max
>>>
>>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi Erik,
>>>>
>>>> Are you going to fix this bug soon?
>>>>
>>>> I am inspired by Martin's words and would like to update 
>>>> GenerateCacerts.java so that as long as the certs and their aliases 
>>>> are unchanged, the output cacerts will always be the same. I can 
>>>> send out a code review today.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Good idea about the creation time.
>>>>>
>>>>> --Max
>>>>>
>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz 
>>>>>> <martinrb at google.com> wrote:
>>>>>>
>>>>>> Google culture really likes build output determinism, and we 
>>>>>> recently built our own cacerts generator.
>>>>>>
>>>>>> To get determinism, we are using cert digest as alias (must have 
>>>>>> a unique alias, but value doesn't seem to matter much), and using 
>>>>>> cert notBefore instead of current (build) timestamp.
>>>>>>
>>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson 
>>>>>> <erik.joelsson at oracle.com> wrote:
>>>>>> Since JDK-8193255, when we started generating the cacerts file in 
>>>>>> the
>>>>>> build, the build compare baseline builds have started failing. It 
>>>>>> seems
>>>>>> the cacerts binary file has some non determinism built in so it 
>>>>>> doesn't
>>>>>> get generated exactly the same given the same input. This patch adds
>>>>>> special handling when comparing that file by comparing the output of
>>>>>> "keytool -list" on the files instead.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>>>
>>>>>> /Erik
>>>>>>


From sean.mullan at oracle.com  Wed Jun 12 20:15:23 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 12 Jun 2019 16:15:23 -0400
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
Message-ID: <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>

On 6/12/19 4:01 PM, Erik Joelsson wrote:
> Hello,
> 
> We cannot rely on querying mercurial at build time. The source must be 
> buildable from a source distribution.

I had a feeling it wouldn't work but thought I would ask anyway.

Well, offhand I can't think of any better solution than notBefore then, 
unless we included it as a comment in the PEM file, and then extracted 
it. With notBefore, someone might be curious about why some keystore 
entries were created so long ago (ex: the earliest notBefore date is 
1996). But the creationDate doesn't really have any usefulness for 
cacerts, so it's probably ok.

--Sean

> 
> /Erik
> 
> On 2019-06-12 11:39, Sean Mullan wrote:
>> Using the certificate's notBefore date as the KeyStore entry creation 
>> date is misleading since many of these root certs were not integrated 
>> into the JDK until after they were created by the CA. Can we somehow 
>> extract the last revision time of each PEM file instead? That is more 
>> aligned with the previous creation date that we used.
>>
>> --Sean
>>
>> On 6/12/19 12:38 PM, Erik Joelsson wrote:
>>> Hello Max,
>>>
>>> Much appreciated! I will need to have this fixed one way or other in 
>>> JDK 13, so depending on if you get your fix there in time, I will 
>>> retract my proposal. If your fix only hits 14, I will push mine to 13.
>>>
>>> /Erik
>>>
>>> On 2019-06-12 08:41, Weijun Wang wrote:
>>>> This is my version of the fix:
>>>>
>>>> ??? http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>>>
>>>> Now you can still compare cacerts bit by bit.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Hi Erik,
>>>>>
>>>>> Are you going to fix this bug soon?
>>>>>
>>>>> I am inspired by Martin's words and would like to update 
>>>>> GenerateCacerts.java so that as long as the certs and their aliases 
>>>>> are unchanged, the output cacerts will always be the same. I can 
>>>>> send out a code review today.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Good idea about the creation time.
>>>>>>
>>>>>> --Max
>>>>>>
>>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz 
>>>>>>> <martinrb at google.com> wrote:
>>>>>>>
>>>>>>> Google culture really likes build output determinism, and we 
>>>>>>> recently built our own cacerts generator.
>>>>>>>
>>>>>>> To get determinism, we are using cert digest as alias (must have 
>>>>>>> a unique alias, but value doesn't seem to matter much), and using 
>>>>>>> cert notBefore instead of current (build) timestamp.
>>>>>>>
>>>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson 
>>>>>>> <erik.joelsson at oracle.com> wrote:
>>>>>>> Since JDK-8193255, when we started generating the cacerts file in 
>>>>>>> the
>>>>>>> build, the build compare baseline builds have started failing. It 
>>>>>>> seems
>>>>>>> the cacerts binary file has some non determinism built in so it 
>>>>>>> doesn't
>>>>>>> get generated exactly the same given the same input. This patch adds
>>>>>>> special handling when comparing that file by comparing the output of
>>>>>>> "keytool -list" on the files instead.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>>>>
>>>>>>> /Erik
>>>>>>>


From kim.barrett at oracle.com  Thu Jun 13 00:45:45 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 12 Jun 2019 20:45:45 -0400
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
 <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
Message-ID: <937B29BB-266F-4D62-9FCB-3F2DE6A8376E@oracle.com>

> On Jun 12, 2019, at 5:35 AM, Nick Gasson <Nick.Gasson at arm.com> wrote:
> 
> Hi Andrew,
> 
> Sorry for the delay, I've put an updated webrev here:
> 
> http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/

Since I've been commenting on some parts, I decided I might as well
look at all of it.  So here's a review.  I don't need to re-review any
of the suggested changes.

------------------------------------------------------------------------------
src/hotspot/cpu/aarch64/frame_aarch64.cpp
 772     reg_map = (RegisterMap*)os::malloc(sizeof(RegisterMap), mtNone);

Use NEW_C_HEAP_OBJ(RegisterMap, mtNone)

------------------------------------------------------------------------------
src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp
 384         fcmpd(v26, 0.0);                          // if NE then jx == 2. else it's 1 or 0

and 

 388         fcmpd(v7, 0.0);                           // v7 == 0 => jx = 0. Else jx = 1

EOL comments no longer aligned with others nearby.

------------------------------------------------------------------------------
src/hotspot/cpu/aarch64/vm_version_aarch64.cpp
 180       if ((p = strchr(buf, ':'))) {

Hotspot Coding Style says not to use implicit bool, instead using
explicit comparisons, e.g. this should be

 180       if ((p = strchr(buf, ':')) != NULL) {

That would have avoided the warning in the first place.

And yes, I know there are lots of violations of that guideline.

------------------------------------------------------------------------------
src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp
  43 #ifdef __clang__
  44     D res = __atomic_add_fetch(dest, add_value, __ATOMIC_RELEASE);
  45     FULL_MEM_BARRIER;
  46     return res;
  47 #else

Is there a reason to conditionalize use of __atomic_add_fetch for
clang and continue to use __sync_add_and_fetch for gcc, rather than
using __atomic_add_fetch unconditionally?

Is __ATOMIC_RELEASE and a following FULL_MEM_BARRIER the right usage
to get the equivalent of __sync_add_and_fetch?  Or should
__ATOMIC_SEQ_CST be used?  Or should the latter be actively avoided?
I remember some discussion and questions in that area, about how to
implement memory_order_seq_cst on ARM processors, but wasn't paying
close attention since I don't deal with ARM much.

Andrew?  I'll happily defer to you here.

------------------------------------------------------------------------------
src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp

I didn't review the stuff around os::current_stack_pointer and
os::current_frame.

------------------------------------------------------------------------------
src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s
 162         prfum   pldl1keep, [s, #-256]

I didn't review this change.

------------------------------------------------------------------------------



From weijun.wang at oracle.com  Thu Jun 13 01:34:49 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 13 Jun 2019 09:34:49 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
Message-ID: <970CBC8A-DE0B-46C0-95FD-EE912E2B7438@oracle.com>

I plan to fix it in JDK 13. --Max

> On Jun 13, 2019, at 12:38 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello Max,
> 
> Much appreciated! I will need to have this fixed one way or other in JDK 13, so depending on if you get your fix there in time, I will retract my proposal. If your fix only hits 14, I will push mine to 13.
> 
> /Erik
> 
> On 2019-06-12 08:41, Weijun Wang wrote:
>> This is my version of the fix:
>> 
>>    http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>> 
>> Now you can still compare cacerts bit by bit.
>> 
>> Thanks,
>> Max



From weijun.wang at oracle.com  Thu Jun 13 01:37:31 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 13 Jun 2019 09:37:31 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <CA+kOe09ukMy+NkRSOqU57Z5p8KmdRDEfm+MOGWEzYjU8-Hmkug@mail.gmail.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <CA+kOe09ukMy+NkRSOqU57Z5p8KmdRDEfm+MOGWEzYjU8-Hmkug@mail.gmail.com>
Message-ID: <162ADDBA-5D91-4EF3-B457-F8AC16A6C836@oracle.com>



> On Jun 13, 2019, at 12:16 AM, Martin Buchholz <martinrb at google.com> wrote:
> 
> I'm not a security engineer, but:
> - consider creating static finals for e.g. "Mighty Aphrodite" just to give it a symbolic name.

That method is copied from JavaKeyStore.java. Keeping it 100% unchanged gives me more confidence I'm write the file correctly.

> - VerifyCACerts probably fails when the jdk is configured with a different cacerts file (but the JDK doesn't preserve configuration information - how could one fix it?)
> Many downstream organizations will configure a different cacerts.

I don't have a solution. Maybe in your repo you can @ignore this test.

Thanks,
Max

> 
> On Wed, Jun 12, 2019 at 8:42 AM Weijun Wang <weijun.wang at oracle.com> wrote:
> This is my version of the fix:
> 
>    http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
> 
> Now you can still compare cacerts bit by bit.
> 
> Thanks,
> Max
> 
> > On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> > 
> > Hi Erik,
> > 
> > Are you going to fix this bug soon?
> > 
> > I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.
> > 
> > Thanks,
> > Max
> > 
> >> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> >> 
> >> Good idea about the creation time.
> >> 
> >> --Max
> >> 
> >>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
> >>> 
> >>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
> >>> 
> >>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
> >>> 
> >>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
> >>> Since JDK-8193255, when we started generating the cacerts file in the 
> >>> build, the build compare baseline builds have started failing. It seems 
> >>> the cacerts binary file has some non determinism built in so it doesn't 
> >>> get generated exactly the same given the same input. This patch adds 
> >>> special handling when comparing that file by comparing the output of 
> >>> "keytool -list" on the files instead.
> >>> 
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
> >>> 
> >>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
> >>> 
> >>> /Erik
> >>> 
> >> 
> > 
> 



From weijun.wang at oracle.com  Thu Jun 13 01:52:08 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 13 Jun 2019 09:52:08 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
Message-ID: <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>

Hi Sean,

The previous fix for JDK-8193255 already made the creation date useless. Before that, each time cacerts was regenerated the date changed. I compared cacerts of different releases and the same cert have difference creation dates.

The only other solution I can think of is to look at make/autoconf/version-numbers and use the DEFAULT_VERSION_DATE=2019-09-17 there.

Have you reviewed the code changes? You can see I stored the hash of the whole file into the test. This means anyone updating the CA certs will have to create cacerts and calculate the correct hash and update this test. I suppose this won't be a hassle.

Thanks,
Max

> On Jun 13, 2019, at 4:15 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 6/12/19 4:01 PM, Erik Joelsson wrote:
>> Hello,
>> We cannot rely on querying mercurial at build time. The source must be buildable from a source distribution.
> 
> I had a feeling it wouldn't work but thought I would ask anyway.
> 
> Well, offhand I can't think of any better solution than notBefore then, unless we included it as a comment in the PEM file, and then extracted it. With notBefore, someone might be curious about why some keystore entries were created so long ago (ex: the earliest notBefore date is 1996). But the creationDate doesn't really have any usefulness for cacerts, so it's probably ok.
> 
> --Sean
> 
>> /Erik
>> On 2019-06-12 11:39, Sean Mullan wrote:
>>> Using the certificate's notBefore date as the KeyStore entry creation date is misleading since many of these root certs were not integrated into the JDK until after they were created by the CA. Can we somehow extract the last revision time of each PEM file instead? That is more aligned with the previous creation date that we used.
>>> 
>>> --Sean
>>> 
>>> On 6/12/19 12:38 PM, Erik Joelsson wrote:
>>>> Hello Max,
>>>> 
>>>> Much appreciated! I will need to have this fixed one way or other in JDK 13, so depending on if you get your fix there in time, I will retract my proposal. If your fix only hits 14, I will push mine to 13.
>>>> 
>>>> /Erik
>>>> 
>>>> On 2019-06-12 08:41, Weijun Wang wrote:
>>>>> This is my version of the fix:
>>>>> 
>>>>>     http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>>>> 
>>>>> Now you can still compare cacerts bit by bit.
>>>>> 
>>>>> Thanks,
>>>>> Max
>>>>> 
>>>>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Erik,
>>>>>> 
>>>>>> Are you going to fix this bug soon?
>>>>>> 
>>>>>> I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.
>>>>>> 
>>>>>> Thanks,
>>>>>> Max
>>>>>> 
>>>>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>>> 
>>>>>>> Good idea about the creation time.
>>>>>>> 
>>>>>>> --Max
>>>>>>> 
>>>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
>>>>>>>> 
>>>>>>>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
>>>>>>>> 
>>>>>>>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
>>>>>>>> 
>>>>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>>>> Since JDK-8193255, when we started generating the cacerts file in the
>>>>>>>> build, the build compare baseline builds have started failing. It seems
>>>>>>>> the cacerts binary file has some non determinism built in so it doesn't
>>>>>>>> get generated exactly the same given the same input. This patch adds
>>>>>>>> special handling when comparing that file by comparing the output of
>>>>>>>> "keytool -list" on the files instead.
>>>>>>>> 
>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>>>> 
>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>>>>> 
>>>>>>>> /Erik
>>>>>>>> 



From weijun.wang at oracle.com  Thu Jun 13 02:48:02 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 13 Jun 2019 10:48:02 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190610235635.GL7457@twosigma.com>
References: <20190320161023.GD9177@twosigma.com>
 <A02E8406-1612-4BDC-8567-4D6084BF4798@oracle.com>
 <a97d4633-24bb-136c-2299-cb6396bd0b86@gmx.net>
 <D9F110A3-574E-4020-9932-8B417229296C@oracle.com>
 <4359183E-61A7-4B12-A3AB-E06E8469410C@oracle.com>
 <20190529172354.GH7457@twosigma.com>
 <E22A6D8C-8568-4296-BE52-4543525171E7@oracle.com>
 <E331B623-96B7-4B89-862D-41A3DC12B7AD@oracle.com>
 <a9166756-fe1d-eddc-4ffb-f47bce16fcbc@oracle.com>
 <C9185653-2B6C-41AE-9D1B-A4EA3BD06926@oracle.com>
 <20190610235635.GL7457@twosigma.com>
Message-ID: <CF26D825-F911-45BD-8F33-145BC59F66F6@oracle.com>

I've filed https://bugs.openjdk.java.net/browse/JDK-8225687.

> On Jun 11, 2019, at 7:56 AM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> On Mon, Jun 10, 2019 at 10:30:50AM +0800, Weijun Wang wrote:
>> Updated webrev at
>> 
>>   http://cr.openjdk.java.net/~weijun/6722928/webrev.08/
> 
> - src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java
> 
>   Ugh, I never noticed GSSUtil.useMSInterop().  This really should not
>   be needed.  I believe a proper implementation of RFC4178 wouldn't
>   need it.

I tried but scared away by MS-SPNG's appendix on which version of Windows supports which style of mechListMic. Now that Java only supports one underlying mechanism this field is looks not so crucial.

> 
>   I can't expect you to do that, but can we have a bug opened for this?

There was one at https://bugs.openjdk.java.net/browse/JDK-6773898.

> 
> - src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
> 
>   Shouldn't the sspi_bridge.dll be in the lib directory?

The DLLs have always been in /bin. Maybe it's more easily loadable by java.exe.

> 
> - src/java.security.jgss/share/native/libj2gss/NativeFunc.h
> - src/java.security.jgss/share/native/libj2gss/gssapi.h
> 
>   These continue to have improper constification.
> 
>   There should be no function arguments of type "const gss_...".
> 
>   I've a PR for Heimdal to fix this in Heimdal.  It was very
>   mechanical: search the prototypes and function definitions for
> 
>       \<const[^I ]*gss_
> 
>   then change that to gss_const_... then fix all the warnings and
>   errors that came up when building the result.

OK.

> 
> - All remaining commentary will be about
>   src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
> 
>  - CHECK_*() macros
> 
>    Macro bodies should not end in a semi-colon.

OK.

> 
>    If these were public and since these macro bodies are all if
>    statements, you should wrap them in do { } while (0), but since
>    they're private we can make sure that all uses are correct.
> 
>  - gss_import_name() doesn't check that the first two bytes of the
>    input buffer are the expected token ID when the name-type is
>    GSS_C_NT_EXPORTED_NAME.

OK.

> 
>  - gss_import_name() doesn't check that the third byte of the input
>    buffer is 0 when the name-type is GSS_C_NT_EXPORTED_NAME.

OK.

> 
>  - gss_compare_name(), this code will not distinguish a name of the
>    form 'foo@' from 'foo\@'
> 
>       434     if (l1 < l2 && n2[l1] != L'@'
>       435             || l2 < l1 && n1[l2] != L'@') {
>       436         return GSS_S_COMPLETE; // different
>       437     }
> 
>    Honestly, this is not the most serious problem because nothing
>    really should be using gss_compare_name(), but you do use it... and
>    anyways, it's wrong.

Yes, it's called in GSSLibStub.c and those are the functions I must support.

> 
>    Perhaps the gss_name_struct struct should have a length of realm or
>    length-of-not-realm-part field to make this check easier.
> 
>  - gss_compare_name(), do not use NORM_IGNORECASE

But I do notice that "Administrator" can also be named "administrator", and "HTTP/host" can also be "http/host".

> 
>  - gss_canonicalize_name() should check that mech_type is Kerberos

OK.

> 
> I'll continue later.  I'm in gss_init_sec_context(), about 58% of the
> way through.

Please.

Thanks,
Max

> 
> Nico
> -- 



From nick.gasson at arm.com  Thu Jun 13 08:36:02 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Thu, 13 Jun 2019 16:36:02 +0800
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <937B29BB-266F-4D62-9FCB-3F2DE6A8376E@oracle.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
 <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
 <937B29BB-266F-4D62-9FCB-3F2DE6A8376E@oracle.com>
Message-ID: <de7d8ed9-0bd0-05e5-d82d-1434947c8c72@arm.com>

Hi Kim,

Thanks for the feedback. I'll make these changes.

> 
> Is there a reason to conditionalize use of __atomic_add_fetch for
> clang and continue to use __sync_add_and_fetch for gcc, rather than
> using __atomic_add_fetch unconditionally?

I think I did it that way because I didn't want to affect the build with 
gcc, but actually gcc compiles this to the same instructions with either 
variant so we can get rid of the #ifdef.

> 
> Is __ATOMIC_RELEASE and a following FULL_MEM_BARRIER the right usage
> to get the equivalent of __sync_add_and_fetch?  Or should
> __ATOMIC_SEQ_CST be used?  Or should the latter be actively avoided?
> I remember some discussion and questions in that area, about how to
> implement memory_order_seq_cst on ARM processors, but wasn't paying
> close attention since I don't deal with ARM much.
> 

It generates the same instruction sequence as the existing 
__sync_fetch_and_add.

The __sync_XXX builtins have a full barrier at the end [1], so GCC 
compiles this to:

.L2:
         ldxr    w2, [x1]
         add     w2, w2, w0
         stlxr   w3, w2, [x1]    ; Store release
         cbnz    w3, .L2
         dmb     ish             ; Full barrier
         mov     w0, w2
         ret

Whereas using the __atomic builtin with __ATOMIC_SEQ_CST we get two 
half-barriers like this:

.L2:
         ldaxr   w2, [x1]        ; Load acquire
         add     w2, w2, w0
         stlxr   w3, w2, [x1]    ; Store release
         cbnz    w3, .L2
         mov     w0, w2
         ret


Thanks,
Nick


[1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html


From aph at redhat.com  Thu Jun 13 09:12:04 2019
From: aph at redhat.com (Andrew Haley)
Date: Thu, 13 Jun 2019 10:12:04 +0100
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
 <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
Message-ID: <4995a613-796b-9370-e8e7-808598529d7a@redhat.com>

On 6/12/19 10:35 AM, Nick Gasson wrote:
> I also replaced the call to _get_previous_fp() in os::current_frame() with
> 
>    *(intptr_t **)__builtin_frame_address(0);
> 
> As it generates the same code and avoids the `register intptr_t **fp 
> __asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also 
> the following comment in _get_previous_fp seems to be wrong:
> 
>    // fp is for this frame (_get_previous_fp). We want the fp for the
>    // caller of os::current_frame*(), so go up two frames. However, for
>    // optimized builds, _get_previous_fp() will be inlined, so only go
>    // up 1 frame in that case.
>    #ifdef _NMT_NOINLINE_
>      return **(intptr_t***)fp;
>    #else
>      return *fp;
>    #endif

All of this seems horribly fragile. I'll have a look at what this is supposed
to be used for and think about a stable and robust way to do it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From sgehwolf at redhat.com  Thu Jun 13 11:59:16 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 13 Jun 2019 13:59:16 +0200
Subject: RFR: [8u] JDK-8223219: Backport of JDK-8199552 to OpenJDK 8
 leads to duplicate -fstack-protector flags, overriding --with-extra-cflags
In-Reply-To: <6821a980-84c8-5fae-9006-701d31168bc0@redhat.com>
References: <6821a980-84c8-5fae-9006-701d31168bc0@redhat.com>
Message-ID: <e9e97ece9688d7b1d8dcf9840f6fd657afb55eed.camel@redhat.com>

Hi Andrew,

On Wed, 2019-06-12 at 20:34 +0100, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8223219/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223219
> 
> There's quite a long story to this one, more detail of which is in the
> bug report. In short, JDK-8199552 was backported as part of a CPU with
> no review and so little explanation for the changes contained therein,
> which differ from the same change in OpenJDK 11.
> 
> The end result is that -fstack-protector is added for only two
> architectures - x86 and x86_64 - and it ends up appearing twice for the
> JDK part of the build, the second appearance overriding any options
> specified using --with-extra-cflags. This is a problem for distros which
> may want to use -fstack-protector-strong instead. This patch simplifies
> it down to one addition for all architectures.
> 
> We've been using this patch (or a variant of it) since the January CPU
> on all architectures we build on (AArch64, s390, s390x, ppc, ppc64,
> ppc64le, x86 & x86_64) without known issues.
> 
> Before patch:
> 
>  [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
> -Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT
> -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -fstack-protector
> -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
> -DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
> -I/home/andrew/builder/8u-dev/jdk/include/linux
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common
> -O2 -pipe -march=core2 -mno-tls-direct-seg-refs -Wno-error=return-type
> -Wno-error=deprecated-declarations -fno-strict-aliasing
> -fstack-protector -fno-delete-null-pointer-checks -fno-lifetime-dse
> -fPIC -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/nativ\
> e/java/lang/fdlibm/include
> 
> After patch (the -fstack-protector duplicate after -fno-strict-aliasing
> is gone):
> 
>  [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
> -Wno-unused-parameter -Wformat=2 -pipe -fstack-protector -D_GNU_SOURCE
> -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1
> -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
> -DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
> -I/home/andrew/builder/8u-dev/jdk/include/linux
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
> -I/home/andrew/proje\
> cts/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common -O2 -pipe
> -march=core2 -ggdb -mno-tls-direct-seg-refs -Wno-error=return-type
> -Wno-error=deprecated-declarations -fno-strict-aliasing
> -fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC
> -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/include
> 
> Ok to push?

This looks reasonable to me.

Thanks,
Severin



From sean.mullan at oracle.com  Thu Jun 13 21:00:30 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 13 Jun 2019 17:00:30 -0400
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
 <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
Message-ID: <8db82641-c307-3076-ceab-72975eacd138@oracle.com>

On 6/12/19 9:52 PM, Weijun Wang wrote:
> Hi Sean,
> 
> The previous fix for JDK-8193255 already made the creation date useless. Before that, each time cacerts was regenerated the date changed. I compared cacerts of different releases and the same cert have difference creation dates.
> 
> The only other solution I can think of is to look at make/autoconf/version-numbers and use the DEFAULT_VERSION_DATE=2019-09-17 there.

Yes, a possibility, use the GA release date, which maybe "makes more 
sense" as a creation date, although a bit odd to have creation dates in 
the future before GA.

I'll leave it up to you. I think nobody really looks at the creationDate.

> Have you reviewed the code changes? You can see I stored the hash of the whole file into the test. This means anyone updating the CA certs will have to create cacerts and calculate the correct hash and update this test. I suppose this won't be a hassle.

Not really, since you had to update VerifyCACerts anyway whenever a 
change to cacerts was made, but what's the benefit of the hash? Are you 
worried the cacerts binary will be corrupted somehow, or you just want 
extra assurance something didn't go wrong?

It might be useful to run older versions of keytool against the cacerts 
binary you created - this would give you more assurance that your 
hand-coded format is correct. I would also try various commands, etc.

--Sean

> 
> Thanks,
> Max
> 
>> On Jun 13, 2019, at 4:15 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 6/12/19 4:01 PM, Erik Joelsson wrote:
>>> Hello,
>>> We cannot rely on querying mercurial at build time. The source must be buildable from a source distribution.
>>
>> I had a feeling it wouldn't work but thought I would ask anyway.
>>
>> Well, offhand I can't think of any better solution than notBefore then, unless we included it as a comment in the PEM file, and then extracted it. With notBefore, someone might be curious about why some keystore entries were created so long ago (ex: the earliest notBefore date is 1996). But the creationDate doesn't really have any usefulness for cacerts, so it's probably ok.
>>
>> --Sean
>>
>>> /Erik
>>> On 2019-06-12 11:39, Sean Mullan wrote:
>>>> Using the certificate's notBefore date as the KeyStore entry creation date is misleading since many of these root certs were not integrated into the JDK until after they were created by the CA. Can we somehow extract the last revision time of each PEM file instead? That is more aligned with the previous creation date that we used.
>>>>
>>>> --Sean
>>>>
>>>> On 6/12/19 12:38 PM, Erik Joelsson wrote:
>>>>> Hello Max,
>>>>>
>>>>> Much appreciated! I will need to have this fixed one way or other in JDK 13, so depending on if you get your fix there in time, I will retract my proposal. If your fix only hits 14, I will push mine to 13.
>>>>>
>>>>> /Erik
>>>>>
>>>>> On 2019-06-12 08:41, Weijun Wang wrote:
>>>>>> This is my version of the fix:
>>>>>>
>>>>>>      http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>>>>>
>>>>>> Now you can still compare cacerts bit by bit.
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>>>>
>>>>>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Erik,
>>>>>>>
>>>>>>> Are you going to fix this bug soon?
>>>>>>>
>>>>>>> I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>>
>>>>>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Good idea about the creation time.
>>>>>>>>
>>>>>>>> --Max
>>>>>>>>
>>>>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
>>>>>>>>>
>>>>>>>>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
>>>>>>>>>
>>>>>>>>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
>>>>>>>>>
>>>>>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>>>>> Since JDK-8193255, when we started generating the cacerts file in the
>>>>>>>>> build, the build compare baseline builds have started failing. It seems
>>>>>>>>> the cacerts binary file has some non determinism built in so it doesn't
>>>>>>>>> get generated exactly the same given the same input. This patch adds
>>>>>>>>> special handling when comparing that file by comparing the output of
>>>>>>>>> "keytool -list" on the files instead.
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>>>>>
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>>>>>>
>>>>>>>>> /Erik
>>>>>>>>>
> 


From weijun.wang at oracle.com  Fri Jun 14 05:49:18 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 14 Jun 2019 13:49:18 +0800
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <8db82641-c307-3076-ceab-72975eacd138@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
 <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
 <8db82641-c307-3076-ceab-72975eacd138@oracle.com>
Message-ID: <37E5040A-BB5D-43A4-B926-ED63FAA4AD9C@oracle.com>



> On Jun 14, 2019, at 5:00 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 6/12/19 9:52 PM, Weijun Wang wrote:
>> Hi Sean,
>> The previous fix for JDK-8193255 already made the creation date useless. Before that, each time cacerts was regenerated the date changed. I compared cacerts of different releases and the same cert have difference creation dates.
>> The only other solution I can think of is to look at make/autoconf/version-numbers and use the DEFAULT_VERSION_DATE=2019-09-17 there.
> 
> Yes, a possibility, use the GA release date, which maybe "makes more sense" as a creation date, although a bit odd to have creation dates in the future before GA.
> 
> I'll leave it up to you. I think nobody really looks at the creationDate.

I'll use notBefore, it does not change forever.

> 
>> Have you reviewed the code changes? You can see I stored the hash of the whole file into the test. This means anyone updating the CA certs will have to create cacerts and calculate the correct hash and update this test. I suppose this won't be a hassle.
> 
> Not really, since you had to update VerifyCACerts anyway whenever a change to cacerts was made, but what's the benefit of the hash? Are you worried the cacerts binary will be corrupted somehow, or you just want extra assurance something didn't go wrong?

I just want extra assurance that the output is indeed consistent.

> 
> It might be useful to run older versions of keytool against the cacerts binary you created - this would give you more assurance that your hand-coded format is correct. I would also try various commands, etc.

I can hack only 3 lines of JavaKeyStore.java itself and generate the identical cacerts. Therefore it should be a genuine JKS file.

BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"?

Thanks,
Max

> 
> --Sean
> 
>> Thanks,
>> Max
>>> On Jun 13, 2019, at 4:15 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> On 6/12/19 4:01 PM, Erik Joelsson wrote:
>>>> Hello,
>>>> We cannot rely on querying mercurial at build time. The source must be buildable from a source distribution.
>>> 
>>> I had a feeling it wouldn't work but thought I would ask anyway.
>>> 
>>> Well, offhand I can't think of any better solution than notBefore then, unless we included it as a comment in the PEM file, and then extracted it. With notBefore, someone might be curious about why some keystore entries were created so long ago (ex: the earliest notBefore date is 1996). But the creationDate doesn't really have any usefulness for cacerts, so it's probably ok.
>>> 
>>> --Sean
>>> 
>>>> /Erik
>>>> On 2019-06-12 11:39, Sean Mullan wrote:
>>>>> Using the certificate's notBefore date as the KeyStore entry creation date is misleading since many of these root certs were not integrated into the JDK until after they were created by the CA. Can we somehow extract the last revision time of each PEM file instead? That is more aligned with the previous creation date that we used.
>>>>> 
>>>>> --Sean
>>>>> 
>>>>> On 6/12/19 12:38 PM, Erik Joelsson wrote:
>>>>>> Hello Max,
>>>>>> 
>>>>>> Much appreciated! I will need to have this fixed one way or other in JDK 13, so depending on if you get your fix there in time, I will retract my proposal. If your fix only hits 14, I will push mine to 13.
>>>>>> 
>>>>>> /Erik
>>>>>> 
>>>>>> On 2019-06-12 08:41, Weijun Wang wrote:
>>>>>>> This is my version of the fix:
>>>>>>> 
>>>>>>>     http://cr.openjdk.java.net/~weijun/8225392/webrev.00/
>>>>>>> 
>>>>>>> Now you can still compare cacerts bit by bit.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>> 
>>>>>>>> On Jun 12, 2019, at 10:50 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hi Erik,
>>>>>>>> 
>>>>>>>> Are you going to fix this bug soon?
>>>>>>>> 
>>>>>>>> I am inspired by Martin's words and would like to update GenerateCacerts.java so that as long as the certs and their aliases are unchanged, the output cacerts will always be the same. I can send out a code review today.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Max
>>>>>>>> 
>>>>>>>>> On Jun 12, 2019, at 10:59 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> Good idea about the creation time.
>>>>>>>>> 
>>>>>>>>> --Max
>>>>>>>>> 
>>>>>>>>>> On Jun 12, 2019, at 10:53 AM, Martin Buchholz <martinrb at google.com> wrote:
>>>>>>>>>> 
>>>>>>>>>> Google culture really likes build output determinism, and we recently built our own cacerts generator.
>>>>>>>>>> 
>>>>>>>>>> To get determinism, we are using cert digest as alias (must have a unique alias, but value doesn't seem to matter much), and using cert notBefore instead of current (build) timestamp.
>>>>>>>>>> 
>>>>>>>>>> On Mon, Jun 10, 2019 at 12:40 PM Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>>>>>>>> Since JDK-8193255, when we started generating the cacerts file in the
>>>>>>>>>> build, the build compare baseline builds have started failing. It seems
>>>>>>>>>> the cacerts binary file has some non determinism built in so it doesn't
>>>>>>>>>> get generated exactly the same given the same input. This patch adds
>>>>>>>>>> special handling when comparing that file by comparing the output of
>>>>>>>>>> "keytool -list" on the files instead.
>>>>>>>>>> 
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225392
>>>>>>>>>> 
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8225392/webrev.01/
>>>>>>>>>> 
>>>>>>>>>> /Erik
>>>>>>>>>> 



From sean.mullan at oracle.com  Fri Jun 14 11:55:25 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Jun 2019 07:55:25 -0400
Subject: RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <37E5040A-BB5D-43A4-B926-ED63FAA4AD9C@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
 <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
 <8db82641-c307-3076-ceab-72975eacd138@oracle.com>
 <37E5040A-BB5D-43A4-B926-ED63FAA4AD9C@oracle.com>
Message-ID: <4c0dbe74-7067-8f75-7ca1-1758bba46e93@oracle.com>

On 6/14/19 1:49 AM, Weijun Wang wrote:
> BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"?

Yes, I think that is useful.

--Sean


From weijun.wang at oracle.com  Fri Jun 14 15:33:56 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 14 Jun 2019 23:33:56 +0800
Subject: [13] RFR: JDK-8225392: Comparison builds are failing due to cacerts
 file
In-Reply-To: <4c0dbe74-7067-8f75-7ca1-1758bba46e93@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
 <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
 <8db82641-c307-3076-ceab-72975eacd138@oracle.com>
 <37E5040A-BB5D-43A4-B926-ED63FAA4AD9C@oracle.com>
 <4c0dbe74-7067-8f75-7ca1-1758bba46e93@oracle.com>
Message-ID: <3048617A-B466-4EE7-B146-B8ED8E6FEEE8@oracle.com>

Here is the updated webrev

  http://cr.openjdk.java.net/~weijun/8225392/webrev.01/

The only change is ordering in 'keytool -list' and its test.

Thanks,
Max

> On Jun 14, 2019, at 7:55 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 6/14/19 1:49 AM, Weijun Wang wrote:
>> BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"?
> 
> Yes, I think that is useful.
> 
> --Sean



From erik.joelsson at oracle.com  Fri Jun 14 16:26:04 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jun 2019 09:26:04 -0700
Subject: [13] RFR: JDK-8225392: Comparison builds are failing due to
 cacerts file
In-Reply-To: <3048617A-B466-4EE7-B146-B8ED8E6FEEE8@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
 <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
 <8db82641-c307-3076-ceab-72975eacd138@oracle.com>
 <37E5040A-BB5D-43A4-B926-ED63FAA4AD9C@oracle.com>
 <4c0dbe74-7067-8f75-7ca1-1758bba46e93@oracle.com>
 <3048617A-B466-4EE7-B146-B8ED8E6FEEE8@oracle.com>
Message-ID: <aa18487e-5bf8-3018-1dcd-64f298e80be2@oracle.com>

I'm happy with this.

/Erik

On 2019-06-14 08:33, Weijun Wang wrote:
> Here is the updated webrev
>
>    http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
>
> The only change is ordering in 'keytool -list' and its test.
>
> Thanks,
> Max
>
>> On Jun 14, 2019, at 7:55 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 6/14/19 1:49 AM, Weijun Wang wrote:
>>> BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"?
>> Yes, I think that is useful.
>>
>> --Sean


From aph at redhat.com  Fri Jun 14 17:20:08 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 14 Jun 2019 18:20:08 +0100
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
 <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
Message-ID: <a4e7cf1b-f243-78fa-1466-5f383c5978a0@redhat.com>

Hi,

On 6/12/19 10:35 AM, Nick Gasson wrote:

> Sorry for the delay, I've put an updated webrev here:
> 
> http://cr.openjdk.java.net/~ngasson/8224851/webrev.1/
> 
> Changes since the last patch:
> 
> * Replaced ~((1<<12) - 1) with -1u<<12
> 
> * Use __atomic_add_fetch in Atomic::PlatformAdd #ifdef __clang__
> 
> * Use __builtin_frame_address(0) in os::current_frame()
> 
> * Use placement new / copy assignment in pf()
> 
> I also replaced the call to _get_previous_fp() in os::current_frame() with
> 
>    *(intptr_t **)__builtin_frame_address(0);
> 
> As it generates the same code and avoids the `register intptr_t **fp 
> __asm__ (SPELL_REG_FP);' declaration which clang doesn't support. Also 
> the following comment in _get_previous_fp seems to be wrong:
> 
>    // fp is for this frame (_get_previous_fp). We want the fp for the
>    // caller of os::current_frame*(), so go up two frames. However, for
>    // optimized builds, _get_previous_fp() will be inlined, so only go
>    // up 1 frame in that case.
>    #ifdef _NMT_NOINLINE_
>      return **(intptr_t***)fp;
>    #else
>      return *fp;
>    #endif
> 
> Even on -O0 gcc won't generate a stack frame for this function so if 
> _NMT_NOINLINE_ is defined you get the caller's caller's FP rather than 
> the caller's FP. I just deleted the function as it's not used anywhere else.
> 
> BTW we can't use __builtin_frame_address(1) as GCC gives a warning when 
> this is called with a non-zero argument (-Wframe-address).
> 
> Tested jtreg hotspot_all_no_apps and jdk_core (gcc 7.3).

OK, that's all good. Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From martinrb at google.com  Fri Jun 14 19:25:15 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 14 Jun 2019 12:25:15 -0700
Subject: jdk 14 version string scheme changed?
Message-ID: <CA+kOe0-5Bje9naPG5UyFS3FBnJ3aTX7qPXDDv19S6oujjqK5gw@mail.gmail.com>

The first jdk14 build reports:
openjdk full version "14-ea+1-1"
while jdk13 has:
openjdk full version "13-ea+25"

The trailing "-1" looks like a bug - is it intentional?


From erik.joelsson at oracle.com  Fri Jun 14 19:57:24 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jun 2019 12:57:24 -0700
Subject: jdk 14 version string scheme changed?
In-Reply-To: <CA+kOe0-5Bje9naPG5UyFS3FBnJ3aTX7qPXDDv19S6oujjqK5gw@mail.gmail.com>
References: <CA+kOe0-5Bje9naPG5UyFS3FBnJ3aTX7qPXDDv19S6oujjqK5gw@mail.gmail.com>
Message-ID: <ecd49158-6f6d-bf64-46f9-93d1fe529a98@oracle.com>

Hello Martin,

It is intentional. The extra number is our internal CI build number. 
 From JDK 14 we have decided to stop rebuilding for promotion and 
instead use a build already built and tested in our CI.

The new number is part of the $OPT string as defined in JEP-223 [1].

"$OPT, matching|([-a-zA-Z0-9\.]+)|--- Additional build information, if 
desired.In the case of an|internal|build this will often contain the 
date and time of the build."

Note that the addition of this particular number is only done on builds 
published by Oracle. Other publishers of OpenJDK binaries are free to 
add their additional information in that string, and AFAIK it's common 
practice to do so.

/Erik

[1] https://openjdk.java.net/jeps/223

On 2019-06-14 12:25, Martin Buchholz wrote:
> The first jdk14 build reports:
> openjdk full version "14-ea+1-1"
> while jdk13 has:
> openjdk full version "13-ea+25"
>
> The trailing "-1" looks like a bug - is it intentional?


From martinrb at google.com  Fri Jun 14 20:51:38 2019
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 14 Jun 2019 13:51:38 -0700
Subject: jdk 14 version string scheme changed?
In-Reply-To: <ecd49158-6f6d-bf64-46f9-93d1fe529a98@oracle.com>
References: <CA+kOe0-5Bje9naPG5UyFS3FBnJ3aTX7qPXDDv19S6oujjqK5gw@mail.gmail.com>
 <ecd49158-6f6d-bf64-46f9-93d1fe529a98@oracle.com>
Message-ID: <CA+kOe09hG7YTkmZvQcvZ1WXH6=wBes2z6FQ=6-i7LjwTG2Jfzw@mail.gmail.com>

Thanks!

(OPT is harder to parse out than I expected ...)

On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello Martin,
>
> It is intentional. The extra number is our internal CI build number. From
> JDK 14 we have decided to stop rebuilding for promotion and instead use a
> build already built and tested in our CI.
>
> The new number is part of the $OPT string as defined in JEP-223 [1].
>
> "$OPT, matching ([-a-zA-Z0-9\.]+) --- Additional build information, if
> desired. In the case of an internal build this will often contain the
> date and time of the build."
>
> Note that the addition of this particular number is only done on builds
> published by Oracle. Other publishers of OpenJDK binaries are free to add
> their additional information in that string, and AFAIK it's common practice
> to do so.
>
> /Erik
>
> [1] https://openjdk.java.net/jeps/223
> On 2019-06-14 12:25, Martin Buchholz wrote:
>
> The first jdk14 build reports:
> openjdk full version "14-ea+1-1"
> while jdk13 has:
> openjdk full version "13-ea+25"
>
> The trailing "-1" looks like a bug - is it intentional?
>
>


From erik.joelsson at oracle.com  Fri Jun 14 20:53:53 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 14 Jun 2019 13:53:53 -0700
Subject: jdk 14 version string scheme changed?
In-Reply-To: <CA+kOe09hG7YTkmZvQcvZ1WXH6=wBes2z6FQ=6-i7LjwTG2Jfzw@mail.gmail.com>
References: <CA+kOe0-5Bje9naPG5UyFS3FBnJ3aTX7qPXDDv19S6oujjqK5gw@mail.gmail.com>
 <ecd49158-6f6d-bf64-46f9-93d1fe529a98@oracle.com>
 <CA+kOe09hG7YTkmZvQcvZ1WXH6=wBes2z6FQ=6-i7LjwTG2Jfzw@mail.gmail.com>
Message-ID: <d22be501-9eaa-f1a3-1969-5a03588c1552@oracle.com>

The configure script has parsing logic for interpreting a full version 
string and splitting it into all the parts if you need inspiration.

/Erik

On 2019-06-14 13:51, Martin Buchholz wrote:
> Thanks!
>
> (OPT is harder to parse out than I expected ...)
>
> On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson 
> <erik.joelsson at oracle.com <mailto:erik.joelsson at oracle.com>> wrote:
>
>     Hello Martin,
>
>     It is intentional. The extra number is our internal CI build
>     number. From JDK 14 we have decided to stop rebuilding for
>     promotion and instead use a build already built and tested in our CI.
>
>     The new number is part of the $OPT string as defined in JEP-223 [1].
>
>     "$OPT, matching|([-a-zA-Z0-9\.]+)|--- Additional build
>     information, if desired.In the case of an|internal|build this will
>     often contain the date and time of the build."
>
>     Note that the addition of this particular number is only done on
>     builds published by Oracle. Other publishers of OpenJDK binaries
>     are free to add their additional information in that string, and
>     AFAIK it's common practice to do so.
>
>     /Erik
>
>     [1] https://openjdk.java.net/jeps/223
>
>     On 2019-06-14 12:25, Martin Buchholz wrote:
>>     The first jdk14 build reports:
>>     openjdk full version "14-ea+1-1"
>>     while jdk13 has:
>>     openjdk full version "13-ea+25"
>>
>>     The trailing "-1" looks like a bug - is it intentional?
>


From sean.mullan at oracle.com  Fri Jun 14 21:10:36 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Jun 2019 17:10:36 -0400
Subject: [13] RFR: JDK-8225392: Comparison builds are failing due to
 cacerts file
In-Reply-To: <3048617A-B466-4EE7-B146-B8ED8E6FEEE8@oracle.com>
References: <5a87fe50-f56a-b9d9-1953-145aceeeeed7@oracle.com>
 <CA+kOe08XC5G4=Xr+5gArdEWu_SymDDZqJcJi19M9RB5JXqkF7g@mail.gmail.com>
 <AA0D6EEE-C26D-495E-9E7D-E5DAF27F81CD@oracle.com>
 <3F81998C-DE69-44C5-AF93-DD6A347F2DF6@oracle.com>
 <FBE122C2-3F8C-4931-BA5A-4D4BE267EB19@oracle.com>
 <736c9af3-b8cf-754f-1f67-31b105a97047@oracle.com>
 <f70a16d4-18dc-32d9-eaaa-373edd182e29@oracle.com>
 <6c9a295c-32b0-b383-07b0-c551252f732e@oracle.com>
 <7662f9b7-d35b-7061-37c5-3ea342823eaa@oracle.com>
 <1AA7BB4F-841C-4442-8AC6-A7C8E9F4A264@oracle.com>
 <8db82641-c307-3076-ceab-72975eacd138@oracle.com>
 <37E5040A-BB5D-43A4-B926-ED63FAA4AD9C@oracle.com>
 <4c0dbe74-7067-8f75-7ca1-1758bba46e93@oracle.com>
 <3048617A-B466-4EE7-B146-B8ED8E6FEEE8@oracle.com>
Message-ID: <5dd3f8a1-0bc7-b8ee-bd68-62ef3950ea0f@oracle.com>

On 6/14/19 11:33 AM, Weijun Wang wrote:
> Here is the updated webrev
> 
>    http://cr.openjdk.java.net/~weijun/8225392/webrev.01/
> 
> The only change is ordering in 'keytool -list' and its test.

Looks fine.

--Sean

> 
> Thanks,
> Max
> 
>> On Jun 14, 2019, at 7:55 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 6/14/19 1:49 AM, Weijun Wang wrote:
>>> BTW, something not related but similar: Do you like me to also sort aliases alphabetically in the output of "keytool -list"?
>>
>> Yes, I think that is useful.
>>
>> --Sean
> 


From nick.gasson at arm.com  Mon Jun 17 07:46:52 2019
From: nick.gasson at arm.com (Nick Gasson)
Date: Mon, 17 Jun 2019 15:46:52 +0800
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <a4e7cf1b-f243-78fa-1466-5f383c5978a0@redhat.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
 <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
 <a4e7cf1b-f243-78fa-1466-5f383c5978a0@redhat.com>
Message-ID: <2119382e-9999-a911-d030-e6932ef424dd@arm.com>

On 15/06/2019 01:20, Andrew Haley wrote:
> 
> OK, that's all good. Thanks.
> 

Thanks Andrew. Please double check this final webrev is ok to push:

http://cr.openjdk.java.net/~ngasson/8224851/webrev.2/

It's webrev.1 plus Kim's review comments.


Nick


From aph at redhat.com  Mon Jun 17 08:13:30 2019
From: aph at redhat.com (Andrew Haley)
Date: Mon, 17 Jun 2019 09:13:30 +0100
Subject: RFR: 8224851: AArch64: fix warnings and errors with Clang and GCC
 8.3
In-Reply-To: <2119382e-9999-a911-d030-e6932ef424dd@arm.com>
References: <5c150ab2-e99f-e2b7-9b9f-bd80ac1d0d2c@arm.com>
 <4890e74d-8ee0-3f0a-1fc0-5bce82dc7663@redhat.com>
 <04beb363-f4a4-e509-dd90-9d2df1a044d5@arm.com>
 <57D13B0D-5362-4975-871D-7E9F3D3D1B37@oracle.com>
 <0869b095-caa6-dbb1-6364-bb7cf6abaf1c@arm.com>
 <9657115c-3b44-5812-c5d6-c96edf852cd3@redhat.com>
 <94de2466-4b73-7091-17ee-7168114df1ee@arm.com>
 <0b355166-4bb7-7de2-b30b-9a481aa085a2@redhat.com>
 <a52ab315-cde2-c8a0-c02e-02d7c5a2d5a7@arm.com>
 <f2d34a09-33df-d139-f767-599abf516f00@redhat.com>
 <e914a724-58ab-c8d0-edc3-3f2981578f3a@arm.com>
 <a4e7cf1b-f243-78fa-1466-5f383c5978a0@redhat.com>
 <2119382e-9999-a911-d030-e6932ef424dd@arm.com>
Message-ID: <901dc528-802f-529f-6a20-9a93f45b7ba3@redhat.com>

On 6/17/19 8:46 AM, Nick Gasson wrote:
> Thanks Andrew. Please double check this final webrev is ok to push:
> 
> http://cr.openjdk.java.net/~ngasson/8224851/webrev.2/
> 
> It's webrev.1 plus Kim's review comments.

OK, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From gnu.andrew at redhat.com  Mon Jun 17 15:48:26 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 17 Jun 2019 16:48:26 +0100
Subject: RFR: [8u] JDK-8223219: Backport of JDK-8199552 to OpenJDK 8 leads
 to duplicate -fstack-protector flags, overriding --with-extra-cflags
In-Reply-To: <6821a980-84c8-5fae-9006-701d31168bc0@redhat.com>
References: <6821a980-84c8-5fae-9006-701d31168bc0@redhat.com>
Message-ID: <a3f40eb4-e261-a5b4-a713-55b168fe6e94@redhat.com>



On 12/06/2019 20:34, Andrew John Hughes wrote:
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8223219/webrev.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8223219
> 
> There's quite a long story to this one, more detail of which is in the
> bug report. In short, JDK-8199552 was backported as part of a CPU with
> no review and so little explanation for the changes contained therein,
> which differ from the same change in OpenJDK 11.
> 
> The end result is that -fstack-protector is added for only two
> architectures - x86 and x86_64 - and it ends up appearing twice for the
> JDK part of the build, the second appearance overriding any options
> specified using --with-extra-cflags. This is a problem for distros which
> may want to use -fstack-protector-strong instead. This patch simplifies
> it down to one addition for all architectures.
> 
> We've been using this patch (or a variant of it) since the January CPU
> on all architectures we build on (AArch64, s390, s390x, ppc, ppc64,
> ppc64le, x86 & x86_64) without known issues.
> 
> Before patch:
> 
>  [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
> -Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT
> -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -fstack-protector
> -D_LP64=1 -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
> -DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
> -I/home/andrew/builder/8u-dev/jdk/include/linux
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common
> -O2 -pipe -march=core2 -mno-tls-direct-seg-refs -Wno-error=return-type
> -Wno-error=deprecated-declarations -fno-strict-aliasing
> -fstack-protector -fno-delete-null-pointer-checks -fno-lifetime-dse
> -fPIC -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/nativ\
> e/java/lang/fdlibm/include
> 
> After patch (the -fstack-protector duplicate after -fno-strict-aliasing
> is gone):
> 
>  [7] CFLAGS := -Wall -Wno-parentheses -Wextra -Wno-unused
> -Wno-unused-parameter -Wformat=2 -pipe -fstack-protector -D_GNU_SOURCE
> -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LP64=1
> -D_LITTLE_ENDIAN -DLINUX -DARCH='"amd64"' -Damd64 -DNDEBUG
> -DRELEASE='"1.8.0-internal"' -I/home/andrew/builder/8u-dev/jdk/include
> -I/home/andrew/builder/8u-dev/jdk/include/linux
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/solaris/javavm/export
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/common
> -I/home/andrew/proje\
> cts/openjdk/upstream/jdk8u-dev/jdk/src/solaris/native/common -O2 -pipe
> -march=core2 -ggdb -mno-tls-direct-seg-refs -Wno-error=return-type
> -Wno-error=deprecated-declarations -fno-strict-aliasing
> -fno-delete-null-pointer-checks -fno-lifetime-dse -fPIC
> -I/home/andrew/builder/8u-dev/jdk/gensrc_headers
> -I/home/andrew/projects/openjdk/upstream/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/include
> 
> Ok to push?
> 
> Thanks,
> 

Ping? Still needs an 8u reviewer.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From erik.joelsson at oracle.com  Mon Jun 17 20:04:07 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 17 Jun 2019 13:04:07 -0700
Subject: RFR: JDK-8226269: Race in SetupProcessMarkdown
Message-ID: <4cd603f4-4262-6905-9084-2ee517e84f94@oracle.com>

In SetupProcessMarkdown, if a POST_PROCESS command is given, there is a 
potential race. This is caused by the call to ExecuteWithLog in the 
recipe for the post process command where the command redirects stdout 
to a file. ExecuteWithLog documents that if such a construct is used, 
then the command must be run in a sub shell (by putting it between 
parentheses) (see JDK-8158629).

This patch adds parentheses around the affect command. I have verified 
that the exploded image no longer gets any empty man pages. This fix is 
intended for JDK 13.

Bug: https://bugs.openjdk.java.net/browse/JDK-8226269

Webrev: http://cr.openjdk.java.net/~erikj/8226269/webrev.01/

/Erik



From tim.bell at oracle.com  Mon Jun 17 20:11:49 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 17 Jun 2019 13:11:49 -0700
Subject: RFR: JDK-8226269: Race in SetupProcessMarkdown
In-Reply-To: <4cd603f4-4262-6905-9084-2ee517e84f94@oracle.com>
References: <4cd603f4-4262-6905-9084-2ee517e84f94@oracle.com>
Message-ID: <5D07F405.2070202@oracle.com>

Erik:

> This patch adds parentheses around the affect command. I have verified
> that the exploded image no longer gets any empty man pages. This fix is
> intended for JDK 13.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226269
>
> Webrev: http://cr.openjdk.java.net/~erikj/8226269/webrev.01/

Looks good.

Tim



From alexandre.iline at oracle.com  Tue Jun 18 22:44:43 2019
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 18 Jun 2019 15:44:43 -0700
Subject: RFR JDK-8226359: Switch to JCov build which supports byte code
 version 58
Message-ID: <47309653-A3FE-4FD1-A6F9-E8FA69F00F82@oracle.com>

Hi, 

Can you please take a look on a small change to switch to a newer JCov build.

This is the whole change:

$ hg diff
diff -r 17f24c0e2f01 make/conf/jib-profiles.js
--- a/make/conf/jib-profiles.js Tue Jun 18 18:38:53 2019 +0100
+++ b/make/conf/jib-profiles.js Tue Jun 18 07:36:23 2019 -0800
@@ -1041,7 +1041,7 @@
             // build_number: "b07",
             // file: "bundles/jcov-3_0.zip",
             organization: common.organization,
-            revision: "3.0-57-support+1.0",
+            revision: "3.0-58-support+1.0",
             ext: "zip",
             environment_name: "JCOV_HOME",
         },


Thank you.

Shura

Bug: https://bugs.openjdk.java.net/browse/JDK-8226359


From daniel.smith at oracle.com  Tue Jun 18 23:05:09 2019
From: daniel.smith at oracle.com (Dan Smith)
Date: Tue, 18 Jun 2019 17:05:09 -0600
Subject: RFR: 8226325: Support building of filtered spec bundles
Message-ID: <DFBD800F-158F-496C-8727-CF9F129BC0F0@oracle.com>

See this webrev for some enhancements to the documentation-building capabilities of the build system.

http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00 <http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00>



From matthias.baesken at sap.com  Wed Jun 19 07:51:18 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 19 Jun 2019 07:51:18 +0000
Subject: jdk/jdk (+jdk12)  Build failure on OSX 10.11
Message-ID: <AM6PR02MB507860E89D25D4DF9B53253E93E50@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  that   NSWindowStyleMaskDocModalWindow  is used since :

https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189

8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Which is 10.12+ functionality . See

https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskdocmodalwindow?language=objc

NSWindowStyleMaskDocModalWindow
The window is a document-modal panel (or a subclass of NSPanel<https://developer.apple.com/documentation/appkit/nspanel?language=objc>).
macOS 10.12+



I would prefer to test for  minimum  10.12  already  in  configure  , what do you think ?

Best regards, Matthias



From matthias.baesken at sap.com  Wed Jun 19 11:32:58 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 19 Jun 2019 11:32:58 +0000
Subject: jdk/jdk (+jdk12)  Build failure on OSX 10.11
Message-ID: <AM6PR02MB50781AF7DC4678C9DC78ED1193E50@AM6PR02MB5078.eurprd02.prod.outlook.com>

We could add a check  for  the existing OS_VERSION_MAJOR  variable   ,   this shows the kernel version but from my understanding the  kernel  to OSX mapping is pretty stable
e.g.  something like :


diff -r 7cf925f385fe make/autoconf/toolchain.m4
--- a/make/autoconf/toolchain.m4        Wed Jun 19 08:43:23 2019 +0200
+++ b/make/autoconf/toolchain.m4        Wed Jun 19 13:28:37 2019 +0200
@@ -224,6 +224,11 @@
   VALID_TOOLCHAINS=${!toolchain_var_name}
   if test "x$OPENJDK_TARGET_OS" = xmacosx; then
+    # check for min. OSX 10.12 (kernel version 16.X from uname)
+    if test $OS_VERSION_MAJOR -lt 16; then
+      AC_MSG_ERROR([OSX version 10.12 / kernel version 16 or higher is required])
+    fi
+
     if test -n "$XCODEBUILD"; then
       # On Mac OS X, default toolchain to clang after Xcode 5
       XCODE_VERSION_OUTPUT=`"$XCODEBUILD" -version 2>&1 | $HEAD -n 1`


(  or  use  the  sw_vers command  and check the output

sw_vers -productVersion
10.12.6

)

What do you think ?


Best regards, Matthias


From: Baesken, Matthias
Sent: Mittwoch, 19. Juni 2019 09:51
To: 'build-dev at openjdk.java.net' <build-dev at openjdk.java.net>
Cc: Schuenemann, Rene <rene.schuenemann at sap.com>
Subject: jdk/jdk (+jdk12) Build failure on OSX 10.11

Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  that   NSWindowStyleMaskDocModalWindow  is used since :

https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189

8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Which is 10.12+ functionality . See

https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskdocmodalwindow?language=objc

NSWindowStyleMaskDocModalWindow
The window is a document-modal panel (or a subclass of NSPanel<https://developer.apple.com/documentation/appkit/nspanel?language=objc>).
macOS 10.12+



I would prefer to test for  minimum  10.12  already  in  configure  , what do you think ?

Best regards, Matthias



From erik.joelsson at oracle.com  Wed Jun 19 17:25:49 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 19 Jun 2019 10:25:49 -0700
Subject: RFR JDK-8226359: Switch to JCov build which supports byte code
 version 58
In-Reply-To: <47309653-A3FE-4FD1-A6F9-E8FA69F00F82@oracle.com>
References: <47309653-A3FE-4FD1-A6F9-E8FA69F00F82@oracle.com>
Message-ID: <c1d5fb28-c969-0195-3051-1d4ae16a90b9@oracle.com>

Looks good.

/Erik

On 2019-06-18 15:44, Alexandre (Shura) Iline wrote:
> Hi,
>
> Can you please take a look on a small change to switch to a newer JCov build.
>
> This is the whole change:
>
> $ hg diff
> diff -r 17f24c0e2f01 make/conf/jib-profiles.js
> --- a/make/conf/jib-profiles.js Tue Jun 18 18:38:53 2019 +0100
> +++ b/make/conf/jib-profiles.js Tue Jun 18 07:36:23 2019 -0800
> @@ -1041,7 +1041,7 @@
>               // build_number: "b07",
>               // file: "bundles/jcov-3_0.zip",
>               organization: common.organization,
> -            revision: "3.0-57-support+1.0",
> +            revision: "3.0-58-support+1.0",
>               ext: "zip",
>               environment_name: "JCOV_HOME",
>           },
>
>
> Thank you.
>
> Shura
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226359


From erik.joelsson at oracle.com  Wed Jun 19 17:29:38 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 19 Jun 2019 10:29:38 -0700
Subject: jdk/jdk (+jdk12) Build failure on OSX 10.11
In-Reply-To: <AM6PR02MB507860E89D25D4DF9B53253E93E50@AM6PR02MB5078.eurprd02.prod.outlook.com>
References: <AM6PR02MB507860E89D25D4DF9B53253E93E50@AM6PR02MB5078.eurprd02.prod.outlook.com>
Message-ID: <56f4925d-07b1-35cf-0133-2a209e85ee48@oracle.com>

Are you sure it's 10.11 that is the problem and not the version of Xcode?

/Erik

On 2019-06-19 00:51, Baesken, Matthias wrote:
> Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  that   NSWindowStyleMaskDocModalWindow  is used since :
>
> https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189
>
> 8208543: [macos] Support for apple.awt.documentModalSheet incomplete
>
> Which is 10.12+ functionality . See
>
> https://developer.apple.com/documentation/appkit/nswindowstylemask/nswindowstylemaskdocmodalwindow?language=objc
>
> NSWindowStyleMaskDocModalWindow
> The window is a document-modal panel (or a subclass of NSPanel<https://developer.apple.com/documentation/appkit/nspanel?language=objc>).
> macOS 10.12+
>
>
>
> I would prefer to test for  minimum  10.12  already  in  configure  , what do you think ?
>
> Best regards, Matthias
>


From ioi.lam at oracle.com  Wed Jun 19 17:41:37 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 19 Jun 2019 10:41:37 -0700
Subject: RFR(XS) 8226404,bootcycle build uses wrong CDS archive
Message-ID: <5eb07017-87c5-2428-acd9-51e93cd3d802@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8226404

When doing "make bootcycle-images", we would attempt to use the newly built
JDK with a CDS archive generated by the BOOT_JDK. This could cause the build
to fail (the underlying cause is JDK-8226406 "JVM fails to detect mismatched
or corrupt CDS archive").

Here's a simple fix (to override the -Xshare:auto specified in spec.gmk.in):

$ hg diff ./autoconf/bootcycle-spec.gmk.in
diff -r d57d61aafef9 make/autoconf/bootcycle-spec.gmk.in
--- a/make/autoconf/bootcycle-spec.gmk.in??? Thu Jun 13 13:43:34 2019 -0700
+++ b/make/autoconf/bootcycle-spec.gmk.in??? Wed Jun 19 10:01:31 2019 -0700
@@ -62,3 +62,5 @@
 ?endif
 ?# The bootcycle JVM arguments may differ from the original boot jdk.
 ?JAVA_FLAGS_BIG := @BOOTCYCLE_JVM_ARGS_BIG@
+# The bootcycle JVM cannot use the configure-support/classes.jsa 
generated by the original boot jdk.
+JAVA_FLAGS += -Xshare:off


We could try to fix the bootcycle build to use the proper classes.jsa, 
but I am
not sure if enough people use it to worth the effort.


Thanks
- Ioi


From erik.joelsson at oracle.com  Wed Jun 19 18:21:14 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 19 Jun 2019 11:21:14 -0700
Subject: RFR: 8226325: Support building of filtered spec bundles
In-Reply-To: <DFBD800F-158F-496C-8727-CF9F129BC0F0@oracle.com>
References: <DFBD800F-158F-496C-8727-CF9F129BC0F0@oracle.com>
Message-ID: <5f8ead09-4dac-6060-5ad6-89c74583961b@oracle.com>

Hello Dan,

Please at least add a comment above SPEC_FILTER explaining how it can be 
used and the format it accepts.

Docs.gmk:492: I would recommend breaking after the =. We generally do 
this for (at least) multi-line macro definitions to make them stand out 
more. See make/common/Utils.gmk for examples.

691-693: Please indent properly (4 spaces).

Nice that you found a way to get rid of the SPECS_BOTTOM_FILE_$n files, 
those were an annoying construct. Looks good except for the style nits!

/Erik

On 2019-06-18 16:05, Dan Smith wrote:
> See this webrev for some enhancements to the documentation-building capabilities of the build system.
>
> http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00 <http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00>
>


From erik.joelsson at oracle.com  Wed Jun 19 19:35:45 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 19 Jun 2019 12:35:45 -0700
Subject: RFR(XS) 8226404: bootcycle build uses wrong CDS archive
In-Reply-To: <5eb07017-87c5-2428-acd9-51e93cd3d802@oracle.com>
References: <5eb07017-87c5-2428-acd9-51e93cd3d802@oracle.com>
Message-ID: <7bc5b624-2b1e-0a90-6e96-4ac07d83386b@oracle.com>

Hello,

I would suggest this change instead. Then the bootcycle bootjdk is free 
to use any CDS archive it happens to have (which it usually does since 
we create it by default).

http://cr.openjdk.java.net/~erikj/8226404/webrev.01/

/Erik

On 2019-06-19 10:41, Ioi Lam wrote:
> https://bugs.openjdk.java.net/browse/JDK-8226404
>
> When doing "make bootcycle-images", we would attempt to use the newly 
> built
> JDK with a CDS archive generated by the BOOT_JDK. This could cause the 
> build
> to fail (the underlying cause is JDK-8226406 "JVM fails to detect 
> mismatched
> or corrupt CDS archive").
>
> Here's a simple fix (to override the -Xshare:auto specified in 
> spec.gmk.in):
>
> $ hg diff ./autoconf/bootcycle-spec.gmk.in
> diff -r d57d61aafef9 make/autoconf/bootcycle-spec.gmk.in
> --- a/make/autoconf/bootcycle-spec.gmk.in??? Thu Jun 13 13:43:34 2019 
> -0700
> +++ b/make/autoconf/bootcycle-spec.gmk.in??? Wed Jun 19 10:01:31 2019 
> -0700
> @@ -62,3 +62,5 @@
> ?endif
> ?# The bootcycle JVM arguments may differ from the original boot jdk.
> ?JAVA_FLAGS_BIG := @BOOTCYCLE_JVM_ARGS_BIG@
> +# The bootcycle JVM cannot use the configure-support/classes.jsa 
> generated by the original boot jdk.
> +JAVA_FLAGS += -Xshare:off
>
>
> We could try to fix the bootcycle build to use the proper classes.jsa, 
> but I am
> not sure if enough people use it to worth the effort.
>
>
> Thanks
> - Ioi


From ioi.lam at oracle.com  Wed Jun 19 20:01:57 2019
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 19 Jun 2019 13:01:57 -0700
Subject: RFR(XS) 8226404: bootcycle build uses wrong CDS archive
In-Reply-To: <7bc5b624-2b1e-0a90-6e96-4ac07d83386b@oracle.com>
References: <5eb07017-87c5-2428-acd9-51e93cd3d802@oracle.com>
 <7bc5b624-2b1e-0a90-6e96-4ac07d83386b@oracle.com>
Message-ID: <d3375753-143b-27ee-a2a4-72474d2acf5c@oracle.com>

Looks good! Please push this version instead of mine :-)

- Ioi

On 6/19/19 12:35 PM, Erik Joelsson wrote:
> Hello,
>
> I would suggest this change instead. Then the bootcycle bootjdk is 
> free to use any CDS archive it happens to have (which it usually does 
> since we create it by default).
>
> http://cr.openjdk.java.net/~erikj/8226404/webrev.01/
>
> /Erik
>
> On 2019-06-19 10:41, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8226404
>>
>> When doing "make bootcycle-images", we would attempt to use the newly 
>> built
>> JDK with a CDS archive generated by the BOOT_JDK. This could cause 
>> the build
>> to fail (the underlying cause is JDK-8226406 "JVM fails to detect 
>> mismatched
>> or corrupt CDS archive").
>>
>> Here's a simple fix (to override the -Xshare:auto specified in 
>> spec.gmk.in):
>>
>> $ hg diff ./autoconf/bootcycle-spec.gmk.in
>> diff -r d57d61aafef9 make/autoconf/bootcycle-spec.gmk.in
>> --- a/make/autoconf/bootcycle-spec.gmk.in??? Thu Jun 13 13:43:34 2019 
>> -0700
>> +++ b/make/autoconf/bootcycle-spec.gmk.in??? Wed Jun 19 10:01:31 2019 
>> -0700
>> @@ -62,3 +62,5 @@
>> ?endif
>> ?# The bootcycle JVM arguments may differ from the original boot jdk.
>> ?JAVA_FLAGS_BIG := @BOOTCYCLE_JVM_ARGS_BIG@
>> +# The bootcycle JVM cannot use the configure-support/classes.jsa 
>> generated by the original boot jdk.
>> +JAVA_FLAGS += -Xshare:off
>>
>>
>> We could try to fix the bootcycle build to use the proper 
>> classes.jsa, but I am
>> not sure if enough people use it to worth the effort.
>>
>>
>> Thanks
>> - Ioi



From andrewluotechnologies at outlook.com  Wed Jun 19 21:45:17 2019
From: andrewluotechnologies at outlook.com (Andrew Luo)
Date: Wed, 19 Jun 2019 21:45:17 +0000
Subject: [PATCH] Detect WSL2 as WSL
Message-ID: <BY5PR13MB3377F6E1484F7D9D9B26D44CA1E50@BY5PR13MB3377.namprd13.prod.outlook.com>

Hi Everyone,

Now that a preview of WSL2 is available for testing (https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/), I decided to experiment a little bit and tried compiling OpenJDK with WSL2.  To correctly detect WSL2, however, I had to make a minor change in config.guess to account for that fact that "Microsoft" in the output of "uname -r" has changed to lowercase:

WSL1: 4.4.0-17763-Microsoft
WSL2: 4.19.43-microsoft-standard

Patch is inline.  One thing to note, however, is that WSL2 does not fully work yet due to a bug.  I have investigated the issue and filed the bug with Microsoft (https://github.com/microsoft/WSL/issues/4161).

Thanks,

-Andrew

diff -r 5eeee2cc94f5 make/autoconf/build-aux/config.guess
--- a/make/autoconf/build-aux/config.guess        Fri Jun 14 20:30:10 2019 -0700
+++ b/make/autoconf/build-aux/config.guess     Mon Jun 17 23:14:56 2019 -0700
@@ -63,7 +63,7 @@
# Test and fix wsl
echo $OUT | grep x86_64-unknown-linux-gnu > /dev/null 2> /dev/null
if test $? = 0; then
-  uname -r | grep Microsoft > /dev/null 2> /dev/null
+  uname -r | grep -i microsoft > /dev/null 2> /dev/null
   if test $? = 0; then
     OUT="x86_64-pc-wsl"
   fi


From erik.joelsson at oracle.com  Wed Jun 19 22:06:16 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 19 Jun 2019 15:06:16 -0700
Subject: [PATCH] Detect WSL2 as WSL
In-Reply-To: <BY5PR13MB3377F6E1484F7D9D9B26D44CA1E50@BY5PR13MB3377.namprd13.prod.outlook.com>
References: <BY5PR13MB3377F6E1484F7D9D9B26D44CA1E50@BY5PR13MB3377.namprd13.prod.outlook.com>
Message-ID: <51716e11-e855-3db2-aa39-ae57aad7cb87@oracle.com>

Looks good to me. Do you need a sponsor for this?

/Erik

On 2019-06-19 14:45, Andrew Luo wrote:
> Hi Everyone,
>
> Now that a preview of WSL2 is available for testing (https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/), I decided to experiment a little bit and tried compiling OpenJDK with WSL2.  To correctly detect WSL2, however, I had to make a minor change in config.guess to account for that fact that "Microsoft" in the output of "uname -r" has changed to lowercase:
>
> WSL1: 4.4.0-17763-Microsoft
> WSL2: 4.19.43-microsoft-standard
>
> Patch is inline.  One thing to note, however, is that WSL2 does not fully work yet due to a bug.  I have investigated the issue and filed the bug with Microsoft (https://github.com/microsoft/WSL/issues/4161).
>
> Thanks,
>
> -Andrew
>
> diff -r 5eeee2cc94f5 make/autoconf/build-aux/config.guess
> --- a/make/autoconf/build-aux/config.guess        Fri Jun 14 20:30:10 2019 -0700
> +++ b/make/autoconf/build-aux/config.guess     Mon Jun 17 23:14:56 2019 -0700
> @@ -63,7 +63,7 @@
> # Test and fix wsl
> echo $OUT | grep x86_64-unknown-linux-gnu > /dev/null 2> /dev/null
> if test $? = 0; then
> -  uname -r | grep Microsoft > /dev/null 2> /dev/null
> +  uname -r | grep -i microsoft > /dev/null 2> /dev/null
>     if test $? = 0; then
>       OUT="x86_64-pc-wsl"
>     fi


From andrewluotechnologies at outlook.com  Wed Jun 19 22:09:21 2019
From: andrewluotechnologies at outlook.com (Andrew Luo)
Date: Wed, 19 Jun 2019 22:09:21 +0000
Subject: [PATCH] Detect WSL2 as WSL
In-Reply-To: <51716e11-e855-3db2-aa39-ae57aad7cb87@oracle.com>
References: <BY5PR13MB3377F6E1484F7D9D9B26D44CA1E50@BY5PR13MB3377.namprd13.prod.outlook.com>
 <51716e11-e855-3db2-aa39-ae57aad7cb87@oracle.com>
Message-ID: <BY5PR13MB33774B6D37B595D93EDC3601A1E50@BY5PR13MB3377.namprd13.prod.outlook.com>

Yes, that would be great if you could sponsor.

Thanks,

-Andrew

-----Original Message-----
From: Erik Joelsson <erik.joelsson at oracle.com> 
Sent: Wednesday, June 19, 2019 3:06 PM
To: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net
Subject: Re: [PATCH] Detect WSL2 as WSL

Looks good to me. Do you need a sponsor for this?

/Erik

On 2019-06-19 14:45, Andrew Luo wrote:
> Hi Everyone,
>
> Now that a preview of WSL2 is available for testing (https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/), I decided to experiment a little bit and tried compiling OpenJDK with WSL2.  To correctly detect WSL2, however, I had to make a minor change in config.guess to account for that fact that "Microsoft" in the output of "uname -r" has changed to lowercase:
>
> WSL1: 4.4.0-17763-Microsoft
> WSL2: 4.19.43-microsoft-standard
>
> Patch is inline.  One thing to note, however, is that WSL2 does not fully work yet due to a bug.  I have investigated the issue and filed the bug with Microsoft (https://github.com/microsoft/WSL/issues/4161).
>
> Thanks,
>
> -Andrew
>
> diff -r 5eeee2cc94f5 make/autoconf/build-aux/config.guess
> --- a/make/autoconf/build-aux/config.guess        Fri Jun 14 20:30:10 2019 -0700
> +++ b/make/autoconf/build-aux/config.guess     Mon Jun 17 23:14:56 2019 -0700
> @@ -63,7 +63,7 @@
> # Test and fix wsl
> echo $OUT | grep x86_64-unknown-linux-gnu > /dev/null 2> /dev/null if 
> test $? = 0; then
> -  uname -r | grep Microsoft > /dev/null 2> /dev/null
> +  uname -r | grep -i microsoft > /dev/null 2> /dev/null
>     if test $? = 0; then
>       OUT="x86_64-pc-wsl"
>     fi

From erik.joelsson at oracle.com  Thu Jun 20 17:18:03 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 20 Jun 2019 10:18:03 -0700
Subject: [PATCH] Detect WSL2 as WSL
In-Reply-To: <BY5PR13MB33774B6D37B595D93EDC3601A1E50@BY5PR13MB3377.namprd13.prod.outlook.com>
References: <BY5PR13MB3377F6E1484F7D9D9B26D44CA1E50@BY5PR13MB3377.namprd13.prod.outlook.com>
 <51716e11-e855-3db2-aa39-ae57aad7cb87@oracle.com>
 <BY5PR13MB33774B6D37B595D93EDC3601A1E50@BY5PR13MB3377.namprd13.prod.outlook.com>
Message-ID: <e4c86aef-781e-50ad-4f5a-40dcb556de60@oracle.com>

Done.

https://bugs.openjdk.java.net/browse/JDK-8226521

/Erik

On 2019-06-19 15:09, Andrew Luo wrote:
> Yes, that would be great if you could sponsor.
>
> Thanks,
>
> -Andrew
>
> -----Original Message-----
> From: Erik Joelsson <erik.joelsson at oracle.com>
> Sent: Wednesday, June 19, 2019 3:06 PM
> To: Andrew Luo <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net
> Subject: Re: [PATCH] Detect WSL2 as WSL
>
> Looks good to me. Do you need a sponsor for this?
>
> /Erik
>
> On 2019-06-19 14:45, Andrew Luo wrote:
>> Hi Everyone,
>>
>> Now that a preview of WSL2 is available for testing (https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/), I decided to experiment a little bit and tried compiling OpenJDK with WSL2.  To correctly detect WSL2, however, I had to make a minor change in config.guess to account for that fact that "Microsoft" in the output of "uname -r" has changed to lowercase:
>>
>> WSL1: 4.4.0-17763-Microsoft
>> WSL2: 4.19.43-microsoft-standard
>>
>> Patch is inline.  One thing to note, however, is that WSL2 does not fully work yet due to a bug.  I have investigated the issue and filed the bug with Microsoft (https://github.com/microsoft/WSL/issues/4161).
>>
>> Thanks,
>>
>> -Andrew
>>
>> diff -r 5eeee2cc94f5 make/autoconf/build-aux/config.guess
>> --- a/make/autoconf/build-aux/config.guess        Fri Jun 14 20:30:10 2019 -0700
>> +++ b/make/autoconf/build-aux/config.guess     Mon Jun 17 23:14:56 2019 -0700
>> @@ -63,7 +63,7 @@
>> # Test and fix wsl
>> echo $OUT | grep x86_64-unknown-linux-gnu > /dev/null 2> /dev/null if
>> test $? = 0; then
>> -  uname -r | grep Microsoft > /dev/null 2> /dev/null
>> +  uname -r | grep -i microsoft > /dev/null 2> /dev/null
>>      if test $? = 0; then
>>        OUT="x86_64-pc-wsl"
>>      fi


From erik.joelsson at oracle.com  Thu Jun 20 17:39:05 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 20 Jun 2019 10:39:05 -0700
Subject: RFR: JDK-8058539: Platform specific source files may not end up in
 src.zip
Message-ID: <6d3aec6e-cb92-55e4-f26d-1572ec41b03a@oracle.com>

For both java and native source files, we have a feature in the build 
which allows overriding based on file name for more specific version 
(i.e. OS specific overrides shared). This works quite well and is used 
in several locations. It does however break down when building src.zip. 
The file with the newest modification date gets picked by the zip 
utility, which essentially makes it random. Luckily the kind of files 
that are overridden this way are usually rather fringe so very few 
people probably care. Even so, the build should be correct, so here is a 
patch that fixes it.

I've added a loop that looks for duplicate files in the given source 
roots and adds any but the first found to exclude lists. I was afraid 
this would add noticeable time to incremental rebuilds, but I found a 
way to work around this by putting this calculation in the recipe for 
the zip file. The drawback is that we cannot remove these files from the 
prerequisites list, so we may trigger unnecessary rebuilds of zip files. 
However, since the number of src files that are handled this way is so 
small, I believe that to be a very rare situation and that it's much 
more valuable to avoid doing the calculation most of the time instead. 
(On my machine, without this hack, incremental rebuild of "make 
zip-source" went from 2.7s to 3.2s, which is noticeable enough IMO, with 
the hack, there is no difference.)

Bug: https://bugs.openjdk.java.net/browse/JDK-8058539

Webrev: http://cr.openjdk.java.net/~erikj/8058539/webrev.01/

/Erik
<https://bugs.openjdk.java.net/browse/JDK-8058539>



From daniel.smith at oracle.com  Thu Jun 20 18:11:15 2019
From: daniel.smith at oracle.com (Dan Smith)
Date: Thu, 20 Jun 2019 12:11:15 -0600
Subject: RFR: 8226325: Support building of filtered spec bundles
In-Reply-To: <5f8ead09-4dac-6060-5ad6-89c74583961b@oracle.com>
References: <DFBD800F-158F-496C-8727-CF9F129BC0F0@oracle.com>
 <5f8ead09-4dac-6060-5ad6-89c74583961b@oracle.com>
Message-ID: <A843669E-055F-4C58-88DD-2FAD5EFB3CC4@oracle.com>

Fixed.

I also added a dependency for docs-specs-zip in Main.gmk, which I noticed is necessary to get gensrc to happen (these dependencies are a bit messy, but that's the status quo).

http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.01

> On Jun 19, 2019, at 12:21 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello Dan,
> 
> Please at least add a comment above SPEC_FILTER explaining how it can be used and the format it accepts.
> 
> Docs.gmk:492: I would recommend breaking after the =. We generally do this for (at least) multi-line macro definitions to make them stand out more. See make/common/Utils.gmk for examples.
> 
> 691-693: Please indent properly (4 spaces).
> 
> Nice that you found a way to get rid of the SPECS_BOTTOM_FILE_$n files, those were an annoying construct. Looks good except for the style nits!
> 
> /Erik
> 
> On 2019-06-18 16:05, Dan Smith wrote:
>> See this webrev for some enhancements to the documentation-building capabilities of the build system.
>> 
>> http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00 <http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00>
>> 



From erik.joelsson at oracle.com  Thu Jun 20 18:20:50 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 20 Jun 2019 11:20:50 -0700
Subject: RFR: 8226325: Support building of filtered spec bundles
In-Reply-To: <A843669E-055F-4C58-88DD-2FAD5EFB3CC4@oracle.com>
References: <DFBD800F-158F-496C-8727-CF9F129BC0F0@oracle.com>
 <5f8ead09-4dac-6060-5ad6-89c74583961b@oracle.com>
 <A843669E-055F-4C58-88DD-2FAD5EFB3CC4@oracle.com>
Message-ID: <cd215e72-5190-0b62-ac4f-ed1d7f4c49e7@oracle.com>

Looks good from build perspective.

/Erik

On 2019-06-20 11:11, Dan Smith wrote:
> Fixed.
>
> I also added a dependency for docs-specs-zip in Main.gmk, which I noticed is necessary to get gensrc to happen (these dependencies are a bit messy, but that's the status quo).
>
> http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.01
>
>> On Jun 19, 2019, at 12:21 PM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Hello Dan,
>>
>> Please at least add a comment above SPEC_FILTER explaining how it can be used and the format it accepts.
>>
>> Docs.gmk:492: I would recommend breaking after the =. We generally do this for (at least) multi-line macro definitions to make them stand out more. See make/common/Utils.gmk for examples.
>>
>> 691-693: Please indent properly (4 spaces).
>>
>> Nice that you found a way to get rid of the SPECS_BOTTOM_FILE_$n files, those were an annoying construct. Looks good except for the style nits!
>>
>> /Erik
>>
>> On 2019-06-18 16:05, Dan Smith wrote:
>>> See this webrev for some enhancements to the documentation-building capabilities of the build system.
>>>
>>> http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00 <http://cr.openjdk.java.net/~dlsmith/jdk/8226325/webrev.00>
>>>


From erik.joelsson at oracle.com  Thu Jun 20 21:13:40 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 20 Jun 2019 14:13:40 -0700
Subject: RFR: JDK-8226538: find-files.gmk gets corrupted if tab completion is
 used before running make first
Message-ID: <3a470eb6-1b54-0eff-e3be-dd0c50de6437@oracle.com>

In a new build configuration, if the user hits tab to complete a make 
target before running any other make target, the generated file 
find-tests.gmk gets corrupted, causing tons of strange make debug output 
to be printed in the console on each subsequent make invocation.

This is caused by the tab completion script which invokes make with the 
-p flag (to print the make database), which FindTests.gmk inadvertently 
propagates into the call to TestMake.gmk where it extracts the test-make 
sub targets into find-test.gmk. This causes make to dump its database 
into find-test.gmk, which includes the definition of MAKEFLAGS with the 
value for -p set. After this, all calls to make will include 
find-tests.gmk, which will set MAKEFLAGS to a value including -p, 
causing make to spit out the database again and again.

The main problem here is that we rely on capturing stdout from calling a 
sub make target. This is a bad practice since there are plenty of ways 
the user may change what make prints. We have had trouble with this in 
the past and were already trying to protect ourselves from similar 
problems. I could not find an easy way to add protection against this 
particular flag, so instead, I'm changing TestMake.gmk to accept an 
input parameter for a target file to which the list of targets is 
printed to instead of stdout. This solves the fundamental design problem.

Bug: https://bugs.openjdk.java.net/browse/JDK-8226538

Webrev: http://cr.openjdk.java.net/~erikj/8226538/webrev.01/

/Erik



From tim.bell at oracle.com  Fri Jun 21 03:20:32 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 20 Jun 2019 20:20:32 -0700
Subject: RFR: JDK-8226538: find-files.gmk gets corrupted if tab completion
 is used before running make first
In-Reply-To: <3a470eb6-1b54-0eff-e3be-dd0c50de6437@oracle.com>
References: <3a470eb6-1b54-0eff-e3be-dd0c50de6437@oracle.com>
Message-ID: <5D0C4D00.7010808@oracle.com>

Erik:

> I'm changing TestMake.gmk to accept an
> input parameter for a target file to which the list of targets is
> printed to instead of stdout. This solves the fundamental design problem.

Sounds good.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8226538
>
> Webrev: http://cr.openjdk.java.net/~erikj/8226538/webrev.01/

Looks good to me.

Tim



From guru at unixarea.de  Fri Jun 21 19:39:48 2019
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 21 Jun 2019 19:39:48 +0000
Subject: changing version infomation string of 'java -version'
Message-ID: <20190621193948.GA3196@c720-r349041>


Hello,

We have ported OpenJDK to our Solaris SPARC servers and have a small
issue now:

The (older) Oracle Java says about the version:

sisis at srap13dsr1:> jdk1.8.0_31/bin/java -version
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

Our compilation of OpenJDK says:

sisis at srap13dsr1:> openjdk8/bin/java -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-sisis_2019_05_23_13_28-b00)
OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)

So far so good. The problem is that our software packages which need
Java are checking during installation the version string of Java and this
a bit hardwired. This would mean updating our packages so that they
accept the new OpenJDK. Or is there any correct configuration way to let
OpenJDK's Java punch the old version string 'java version "1.8.0_31"' ?

Thanks

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: ???????? ????????????! Thank you very much, Russian liberators!


From erik.joelsson at oracle.com  Fri Jun 21 17:48:27 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 21 Jun 2019 10:48:27 -0700
Subject: changing version infomation string of 'java -version'
In-Reply-To: <20190621193948.GA3196@c720-r349041>
References: <20190621193948.GA3196@c720-r349041>
Message-ID: <0a871d01-900b-2957-912c-26b4c3b253a1@oracle.com>

Hello Matthias,

The update version (the 31 in this case) you can set using the configure 
parameter --with-update-version=31. In JDK8u, the source does not know 
the correct value for this version number, so the distributor who builds 
it needs to know and set it correctly.

-Erik

On 2019-06-21 12:39, Matthias Apitz wrote:
> Hello,
>
> We have ported OpenJDK to our Solaris SPARC servers and have a small
> issue now:
>
> The (older) Oracle Java says about the version:
>
> sisis at srap13dsr1:> jdk1.8.0_31/bin/java -version
> java version "1.8.0_31"
> Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
>
> Our compilation of OpenJDK says:
>
> sisis at srap13dsr1:> openjdk8/bin/java -version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build 1.8.0-internal-sisis_2019_05_23_13_28-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)
>
> So far so good. The problem is that our software packages which need
> Java are checking during installation the version string of Java and this
> a bit hardwired. This would mean updating our packages so that they
> accept the new OpenJDK. Or is there any correct configuration way to let
> OpenJDK's Java punch the old version string 'java version "1.8.0_31"' ?
>
> Thanks
>
> 	matthias
>


From sgehwolf at redhat.com  Fri Jun 21 18:13:30 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 21 Jun 2019 20:13:30 +0200
Subject: changing version infomation string of 'java -version'
In-Reply-To: <20190621193948.GA3196@c720-r349041>
References: <20190621193948.GA3196@c720-r349041>
Message-ID: <99ce8d860a7daf007696ae791e0cc9c8dd615d2f.camel@redhat.com>

Hi,

On Fri, 2019-06-21 at 19:39 +0000, Matthias Apitz wrote:
> Hello,
> 
> We have ported OpenJDK to our Solaris SPARC servers and have a small
> issue now:
> 
> The (older) Oracle Java says about the version:
> 
> sisis at srap13dsr1:> jdk1.8.0_31/bin/java -version
> java version "1.8.0_31"
> Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
> 
> Our compilation of OpenJDK says:
> 
> sisis at srap13dsr1:> openjdk8/bin/java -version
> openjdk version "1.8.0-internal"
> OpenJDK Runtime Environment (build 1.8.0-internal-sisis_2019_05_23_13_28-b00)
> OpenJDK 64-Bit Server VM (build 25.71-b00, mixed mode)
> 
> So far so good. The problem is that our software packages which need
> Java are checking during installation the version string of Java and this
> a bit hardwired. This would mean updating our packages so that they
> accept the new OpenJDK. Or is there any correct configuration way to let
> OpenJDK's Java punch the old version string 'java version "1.8.0_31"' ?

There are a couple of things you need to know. First off, is this going
to be a tag which got deemed GA, like jdk8u212-b03 from [1]? Otherwise
you should make it clear (via version output) that this is *not* a GA
release, but an internal build. It could look like the one you've
posted. The EA builds identify as such. Example:

$ ./openjdk-8u222-b06/bin/java -version
openjdk version "1.8.0_222-ea"
OpenJDK Runtime Environment (build 1.8.0_222-ea-b06)
OpenJDK 64-Bit Server VM (build 25.222-b06, mixed mode)

Having said that, the upstream OpenJDK 8u project builds[2] have build
scripts which could give some guidance (for such a jdk8u212-b03 GA
build):

https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/blob/jdk8u212-b03/build-openjdk8.sh#L29

That produces this -version output:

$ ./openjdk-8u212-b03/bin/java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b03)
OpenJDK 64-Bit Server VM (build 25.212-b03, mixed mode)

HTH,
Severin

[1] http://hg.openjdk.java.net/jdk8u/jdk8u
[2] https://adoptopenjdk.net/upstream.html



From jonathan.gibbons at oracle.com  Sat Jun 22 00:22:59 2019
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 21 Jun 2019 17:22:59 -0700
Subject: RFR: S,13 JDK-8226628 The copyright footer should be enclosed in
 <footer>
Message-ID: <fa05aaf8-64d6-537a-d60b-ed8147d8da45@oracle.com>

Please review a small change to make/Docs.gmk so that the copyright 
footer added to specs pages is enclosed in <footer>...</footer>.

JBS: https://bugs.openjdk.java.net/browse/JDK-8226628

-- Jon


$ hg diff -R open
diff -r 179204eb9444 make/Docs.gmk
--- a/make/Docs.gmk???? Fri Jun 21 12:09:07 2019 -0700
+++ b/make/Docs.gmk???? Fri Jun 21 17:14:56 2019 -0700
@@ -532,7 +532,7 @@
 ?# file. The number 0-2 below represent how many extra directory levels 
down
 ?# below the specs dir the specs html file is located. Each file name is
 ?# stored in a variable SPECS_BOTTOM_FILE_$n where $n is 0, 1 or 2.
-SPECS_BOTTOM = <hr/>$(COPYRIGHT_BOTTOM)
+SPECS_BOTTOM = <footer><hr/>$(COPYRIGHT_BOTTOM)</footer>
 ?# The legal dir is one ../ below the specs dir, so start with one ../.
 ?specs_bottom_rel_path := ../
 ?$(foreach n, 0 1 2, \



From lance.andersen at oracle.com  Sat Jun 22 00:38:29 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 21 Jun 2019 20:38:29 -0400
Subject: RFR: S, 13 JDK-8226628 The copyright footer should be enclosed in
 <footer>
In-Reply-To: <fa05aaf8-64d6-537a-d60b-ed8147d8da45@oracle.com>
References: <fa05aaf8-64d6-537a-d60b-ed8147d8da45@oracle.com>
Message-ID: <31EA0194-EB35-458E-9527-DA7A648CA309@oracle.com>

+1
> On Jun 21, 2019, at 8:22 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a small change to make/Docs.gmk so that the copyright footer added to specs pages is enclosed in <footer>...</footer>.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8226628
> 
> -- Jon
> 
> 
> $ hg diff -R open
> diff -r 179204eb9444 make/Docs.gmk
> --- a/make/Docs.gmk     Fri Jun 21 12:09:07 2019 -0700
> +++ b/make/Docs.gmk     Fri Jun 21 17:14:56 2019 -0700
> @@ -532,7 +532,7 @@
>  # file. The number 0-2 below represent how many extra directory levels down
>  # below the specs dir the specs html file is located. Each file name is
>  # stored in a variable SPECS_BOTTOM_FILE_$n where $n is 0, 1 or 2.
> -SPECS_BOTTOM = <hr/>$(COPYRIGHT_BOTTOM)
> +SPECS_BOTTOM = <footer><hr/>$(COPYRIGHT_BOTTOM)</footer>
>  # The legal dir is one ../ below the specs dir, so start with one ../.
>  specs_bottom_rel_path := ../
>  $(foreach n, 0 1 2, \
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>





From andrewluotechnologies at outlook.com  Sat Jun 22 05:33:43 2019
From: andrewluotechnologies at outlook.com (Andrew Luo)
Date: Sat, 22 Jun 2019 05:33:43 +0000
Subject: [PATCH] Enable /permissive- in OpenJDK source code
Message-ID: <BY5PR13MB33772F09056C5EAAA30B5DB6A1E60@BY5PR13MB3377.namprd13.prod.outlook.com>

Hi Everyone,

Inline is a patch to enable /permissive- in the OpenJDK source code.  Recent changes have already been made to allow the OpenJDK source to compile with /permissive-:

http://hg.openjdk.java.net/jdk/jdk/rev/feb860d41612
http://hg.openjdk.java.net/jdk/jdk/rev/55dc1385d1b7
http://hg.openjdk.java.net/jdk/jdk/rev/f67269c129f9

For those that are wondering what /permissive- does: https://devblogs.microsoft.com/cppblog/permissive-switch/

Feedback/comments are always welcome.

Thanks,

-Andrew

diff -r 72bbc930d7b6 make/autoconf/flags-cflags.m4
--- a/make/autoconf/flags-cflags.m4       Sat Jun 22 02:03:41 2019 +0200
+++ b/make/autoconf/flags-cflags.m4    Fri Jun 21 22:24:10 2019 -0700
@@ -164,7 +164,7 @@
   case "${TOOLCHAIN_TYPE}" in
     microsoft)
       DISABLE_WARNING_PREFIX="-wd"
-      CFLAGS_WARNINGS_ARE_ERRORS="-WX"
+      CFLAGS_WARNINGS_ARE_ERRORS="-WX -permissive-"
       WARNINGS_ENABLE_ALL="-W3"
       DISABLED_WARNINGS="4800"


From david.holmes at oracle.com  Sat Jun 22 14:37:41 2019
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 22 Jun 2019 07:37:41 -0700
Subject: [PATCH] Enable /permissive- in OpenJDK source code
In-Reply-To: <BY5PR13MB33772F09056C5EAAA30B5DB6A1E60@BY5PR13MB3377.namprd13.prod.outlook.com>
References: <BY5PR13MB33772F09056C5EAAA30B5DB6A1E60@BY5PR13MB3377.namprd13.prod.outlook.com>
Message-ID: <3b5b6296-56f2-7b45-5755-e43af365cf85@oracle.com>

Hi Andrew,

On 21/06/2019 10:33 pm, Andrew Luo wrote:
> Hi Everyone,
> 
> Inline is a patch to enable /permissive- in the OpenJDK source code.  Recent changes have already been made to allow the OpenJDK source to compile with /permissive-:
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/feb860d41612
> http://hg.openjdk.java.net/jdk/jdk/rev/55dc1385d1b7
> http://hg.openjdk.java.net/jdk/jdk/rev/f67269c129f9
> 
> For those that are wondering what /permissive- does: https://devblogs.microsoft.com/cppblog/permissive-switch/
> 
> Feedback/comments are always welcome.

Probably needs to be done conditionally based on VS version. Although 
VS2017 is the official compiler for 13 (now 14) I think older versions 
are still in use.

Thanks,
David

> Thanks,
> 
> -Andrew
> 
> diff -r 72bbc930d7b6 make/autoconf/flags-cflags.m4
> --- a/make/autoconf/flags-cflags.m4       Sat Jun 22 02:03:41 2019 +0200
> +++ b/make/autoconf/flags-cflags.m4    Fri Jun 21 22:24:10 2019 -0700
> @@ -164,7 +164,7 @@
>     case "${TOOLCHAIN_TYPE}" in
>       microsoft)
>         DISABLE_WARNING_PREFIX="-wd"
> -      CFLAGS_WARNINGS_ARE_ERRORS="-WX"
> +      CFLAGS_WARNINGS_ARE_ERRORS="-WX -permissive-"
>         WARNINGS_ENABLE_ALL="-W3"
>         DISABLED_WARNINGS="4800"
> 


From iris.clark at oracle.com  Sun Jun 23 05:30:13 2019
From: iris.clark at oracle.com (Iris Clark)
Date: Sat, 22 Jun 2019 22:30:13 -0700 (PDT)
Subject: RFR: S, 13 JDK-8226628 The copyright footer should be enclosed in
 <footer>
In-Reply-To: <fa05aaf8-64d6-537a-d60b-ed8147d8da45@oracle.com>
References: <fa05aaf8-64d6-537a-d60b-ed8147d8da45@oracle.com>
Message-ID: <376a33b7-91c6-4948-83bc-0cb0b8791847@default>

Hi, Jon.

> JBS: https://bugs.openjdk.java.net/browse/JDK-8226628

Looks good.  Thanks for taking care of this.

Iris


From sgehwolf at redhat.com  Mon Jun 24 13:48:35 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 24 Jun 2019 15:48:35 +0200
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams on
 GNU/Linux (glibc)
Message-ID: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>

Hi,

Could I please get reviews for this 8u only change? The JDK 8u build
logic for launcher files includes linker version script files (a.k.a
mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
as local. When the symbol is not visible to the dynamic loader, glibc
will use a legacy stdio implementation instead. This is a historic, x86
(32bit) only glibc issue, I've been told.

The suggested fix is to mark _IO_stdin_used as global in the linker
version script on x86 (32bit) so that the non-legacy implementation of
stdio will be used for launcher files of OpenJDK 8u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8226392
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226392/01/webrev/

Testing: "eu-readelf --symbols=.dynsym /path/to/java | grep _IO". I.e. manual
         on a x86 build.

Note that JDK 11+ have _IO_stin_used visible already.

I can add the same to other arches map files if that's preferred (it
should be harmless). For now, I've opted to add it to x86 only where we
know this is a problem.

Thanks,
Severin



From fweimer at redhat.com  Mon Jun 24 13:54:33 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 24 Jun 2019 15:54:33 +0200
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams on
 GNU/Linux (glibc)
In-Reply-To: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
 (Severin Gehwolf's message of "Mon, 24 Jun 2019 15:48:35 +0200")
References: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
Message-ID: <87h88fay1y.fsf@oldenburg2.str.redhat.com>

* Severin Gehwolf:

> Could I please get reviews for this 8u only change? The JDK 8u build
> logic for launcher files includes linker version script files (a.k.a
> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> as local. When the symbol is not visible to the dynamic loader, glibc
> will use a legacy stdio implementation instead. This is a historic, x86
> (32bit) only glibc issue, I've been told.

It may impact other historic GNU/Linux targets, but I don't think they
have OpenJDK ports.  POWER and Z are 64-bit only, I assume.

Thanks,
Florian


From gnu.andrew at redhat.com  Mon Jun 24 14:12:37 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 24 Jun 2019 15:12:37 +0100
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams on
 GNU/Linux (glibc)
In-Reply-To: <87h88fay1y.fsf@oldenburg2.str.redhat.com>
References: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
 <87h88fay1y.fsf@oldenburg2.str.redhat.com>
Message-ID: <5008ce8a-c026-9ac0-d440-4601d6ca1bae@redhat.com>



On 24/06/2019 14:54, Florian Weimer wrote:
> * Severin Gehwolf:
> 
>> Could I please get reviews for this 8u only change? The JDK 8u build
>> logic for launcher files includes linker version script files (a.k.a
>> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
>> as local. When the symbol is not visible to the dynamic loader, glibc
>> will use a legacy stdio implementation instead. This is a historic, x86
>> (32bit) only glibc issue, I've been told.
> 
> It may impact other historic GNU/Linux targets, but I don't think they
> have OpenJDK ports.  POWER and Z are 64-bit only, I assume.
> 
> Thanks,
> Florian
> 

OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From gnu.andrew at redhat.com  Mon Jun 24 14:13:29 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 24 Jun 2019 15:13:29 +0100
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams on
 GNU/Linux (glibc)
In-Reply-To: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
References: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
Message-ID: <e18b1533-673f-013d-b4f7-32aa13262484@redhat.com>



On 24/06/2019 14:48, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get reviews for this 8u only change? The JDK 8u build
> logic for launcher files includes linker version script files (a.k.a
> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> as local. When the symbol is not visible to the dynamic loader, glibc
> will use a legacy stdio implementation instead. This is a historic, x86
> (32bit) only glibc issue, I've been told.
> 
> The suggested fix is to mark _IO_stdin_used as global in the linker
> version script on x86 (32bit) so that the non-legacy implementation of
> stdio will be used for launcher files of OpenJDK 8u.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226392
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226392/01/webrev/
> 
> Testing: "eu-readelf --symbols=.dynsym /path/to/java | grep _IO". I.e. manual
>          on a x86 build.
> 
> Note that JDK 11+ have _IO_stin_used visible already.
> 
> I can add the same to other arches map files if that's preferred (it
> should be harmless). For now, I've opted to add it to x86 only where we
> know this is a problem.
> 
> Thanks,
> Severin
> 

Looks good.

Please flag the bug with jdk8u-fix-request to request approval.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From fweimer at redhat.com  Mon Jun 24 14:52:15 2019
From: fweimer at redhat.com (Florian Weimer)
Date: Mon, 24 Jun 2019 16:52:15 +0200
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams on
 GNU/Linux (glibc)
In-Reply-To: <5008ce8a-c026-9ac0-d440-4601d6ca1bae@redhat.com> (Andrew John
 Hughes's message of "Mon, 24 Jun 2019 15:12:37 +0100")
References: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
 <87h88fay1y.fsf@oldenburg2.str.redhat.com>
 <5008ce8a-c026-9ac0-d440-4601d6ca1bae@redhat.com>
Message-ID: <87tvcf9gtc.fsf@oldenburg2.str.redhat.com>

* Andrew John Hughes:

> On 24/06/2019 14:54, Florian Weimer wrote:
>> * Severin Gehwolf:
>> 
>>> Could I please get reviews for this 8u only change? The JDK 8u build
>>> logic for launcher files includes linker version script files (a.k.a
>>> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
>>> as local. When the symbol is not visible to the dynamic loader, glibc
>>> will use a legacy stdio implementation instead. This is a historic, x86
>>> (32bit) only glibc issue, I've been told.
>> 
>> It may impact other historic GNU/Linux targets, but I don't think they
>> have OpenJDK ports.  POWER and Z are 64-bit only, I assume.
>> 
>> Thanks,
>> Florian
>> 
>
> OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.

Oh.  I did not know this.

I looked at a recent internal s390 build, and found this:

Symbol table [ 6] '.dynsym' contains 8 entries:
 1 local symbol  String table: [ 7] '.dynstr'
  Num:    Value   Size Type    Bind   Vis          Ndx Name
    0: 00000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
    1: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_deregisterTMCloneTable
    2: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
    3: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _Jv_RegisterClasses
    4: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_registerTMCloneTable
    5: 00400474      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main at GLIBC_2.0 (2)
    6: 00400494      0 FUNC    GLOBAL DEFAULT    UNDEF JLI_Launch at SUNWprivate_1.1 (3)
    7: 004007b8      4 OBJECT  GLOBAL DEFAULT       16 _IO_stdin_used

Same for a ppc build:

Symbol table [ 6] '.dynsym' contains 8 entries:
 1 local symbol  String table: [ 7] '.dynstr'
  Num:    Value   Size Type    Bind   Vis          Ndx Name
    0: 00000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
    1: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_deregisterTMCloneTable
    2: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
    3: 00000000      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main at GLIBC_2.0 (2)
    4: 00000000      0 FUNC    GLOBAL DEFAULT    UNDEF JLI_Launch at SUNWprivate_1.1 (3)
    5: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _Jv_RegisterClasses
    6: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_registerTMCloneTable
    7: 100007ac      4 OBJECT  GLOBAL DEFAULT       15 _IO_stdin_used

Any binary which references __libc_start_main at GLIBC_2.0 and which does
not export _IO_stdin_used in .dynsym (.symtab does not count) has this
issue, irrespective of the architecture.  The key point is support for
the glibc 2.0 ABI level (as indicated by the GLIBC_2.0 symbol version).
Architectures which joined in glibc 2.1 or later do not have this
fallback code (although the _IO_stdin_used marker symbol is sometimes
still there, quite unnecessarily).

So these two builds one does not have the issue.  The build is from May,
so it can't have Severin's fix yet
(java-1.8.0-openjdk-1.8.0.222.b04-1.el7, in case you wonder), and the
i686 build does show the issue.

Thanks,
Florian


From gnu.andrew at redhat.com  Mon Jun 24 14:57:46 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Mon, 24 Jun 2019 15:57:46 +0100
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams on
 GNU/Linux (glibc)
In-Reply-To: <87tvcf9gtc.fsf@oldenburg2.str.redhat.com>
References: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
 <87h88fay1y.fsf@oldenburg2.str.redhat.com>
 <5008ce8a-c026-9ac0-d440-4601d6ca1bae@redhat.com>
 <87tvcf9gtc.fsf@oldenburg2.str.redhat.com>
Message-ID: <40a36219-245d-aecd-259f-6dea7fb4087d@redhat.com>



On 24/06/2019 15:52, Florian Weimer wrote:
> * Andrew John Hughes:
> 
>> On 24/06/2019 14:54, Florian Weimer wrote:
>>> * Severin Gehwolf:
>>>
>>>> Could I please get reviews for this 8u only change? The JDK 8u build
>>>> logic for launcher files includes linker version script files (a.k.a
>>>> mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
>>>> as local. When the symbol is not visible to the dynamic loader, glibc
>>>> will use a legacy stdio implementation instead. This is a historic, x86
>>>> (32bit) only glibc issue, I've been told.
>>>
>>> It may impact other historic GNU/Linux targets, but I don't think they
>>> have OpenJDK ports.  POWER and Z are 64-bit only, I assume.
>>>
>>> Thanks,
>>> Florian
>>>
>>
>> OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.
> 
> Oh.  I did not know this.
> 
> I looked at a recent internal s390 build, and found this:
> 
> Symbol table [ 6] '.dynsym' contains 8 entries:
>  1 local symbol  String table: [ 7] '.dynstr'
>   Num:    Value   Size Type    Bind   Vis          Ndx Name
>     0: 00000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
>     1: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_deregisterTMCloneTable
>     2: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
>     3: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _Jv_RegisterClasses
>     4: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_registerTMCloneTable
>     5: 00400474      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main at GLIBC_2.0 (2)
>     6: 00400494      0 FUNC    GLOBAL DEFAULT    UNDEF JLI_Launch at SUNWprivate_1.1 (3)
>     7: 004007b8      4 OBJECT  GLOBAL DEFAULT       16 _IO_stdin_used
> 
> Same for a ppc build:
> 
> Symbol table [ 6] '.dynsym' contains 8 entries:
>  1 local symbol  String table: [ 7] '.dynstr'
>   Num:    Value   Size Type    Bind   Vis          Ndx Name
>     0: 00000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
>     1: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_deregisterTMCloneTable
>     2: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
>     3: 00000000      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main at GLIBC_2.0 (2)
>     4: 00000000      0 FUNC    GLOBAL DEFAULT    UNDEF JLI_Launch at SUNWprivate_1.1 (3)
>     5: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _Jv_RegisterClasses
>     6: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_registerTMCloneTable
>     7: 100007ac      4 OBJECT  GLOBAL DEFAULT       15 _IO_stdin_used
> 
> Any binary which references __libc_start_main at GLIBC_2.0 and which does
> not export _IO_stdin_used in .dynsym (.symtab does not count) has this
> issue, irrespective of the architecture.  The key point is support for
> the glibc 2.0 ABI level (as indicated by the GLIBC_2.0 symbol version).
> Architectures which joined in glibc 2.1 or later do not have this
> fallback code (although the _IO_stdin_used marker symbol is sometimes
> still there, quite unnecessarily).
> 
> So these two builds one does not have the issue.  The build is from May,
> so it can't have Severin's fix yet
> (java-1.8.0-openjdk-1.8.0.222.b04-1.el7, in case you wonder), and the
> i686 build does show the issue.
> 
> Thanks,
> Florian
> 

Ah good, sounds like it is just an x86-32 issue then.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From sgehwolf at redhat.com  Mon Jun 24 15:21:00 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 24 Jun 2019 17:21:00 +0200
Subject: [8u] 8226392: Launcher should not enable legacy stdio streams
 on GNU/Linux (glibc)
In-Reply-To: <87tvcf9gtc.fsf@oldenburg2.str.redhat.com>
References: <cd6465ef4ede604a6ed053bfd84b8802b934736e.camel@redhat.com>
 <87h88fay1y.fsf@oldenburg2.str.redhat.com>
 <5008ce8a-c026-9ac0-d440-4601d6ca1bae@redhat.com>
 <87tvcf9gtc.fsf@oldenburg2.str.redhat.com>
Message-ID: <7bdd04c425baae33ace7b87252bf34643181ed4a.camel@redhat.com>

On Mon, 2019-06-24 at 16:52 +0200, Florian Weimer wrote:
> * Andrew John Hughes:
> 
> > On 24/06/2019 14:54, Florian Weimer wrote:
> > > * Severin Gehwolf:
> > > 
> > > > Could I please get reviews for this 8u only change? The JDK 8u build
> > > > logic for launcher files includes linker version script files (a.k.a
> > > > mapfiles). The script file for x86 (32bit) marks symbol _IO_stdin_used
> > > > as local. When the symbol is not visible to the dynamic loader, glibc
> > > > will use a legacy stdio implementation instead. This is a historic, x86
> > > > (32bit) only glibc issue, I've been told.
> > > 
> > > It may impact other historic GNU/Linux targets, but I don't think they
> > > have OpenJDK ports.  POWER and Z are 64-bit only, I assume.
> > > 
> > > Thanks,
> > > Florian
> > > 
> > 
> > OpenJDK is built on s390 (31-bit) and ppc (32-bit) for RHEL 7.
> 
> Oh.  I did not know this.
> 
> I looked at a recent internal s390 build, and found this:
> 
> Symbol table [ 6] '.dynsym' contains 8 entries:
>  1 local symbol  String table: [ 7] '.dynstr'
>   Num:    Value   Size Type    Bind   Vis          Ndx Name
>     0: 00000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
>     1: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_deregisterTMCloneTable
>     2: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
>     3: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _Jv_RegisterClasses
>     4: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_registerTMCloneTable
>     5: 00400474      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main at GLIBC_2.0 (2)
>     6: 00400494      0 FUNC    GLOBAL DEFAULT    UNDEF JLI_Launch at SUNWprivate_1.1 (3)
>     7: 004007b8      4 OBJECT  GLOBAL DEFAULT       16 _IO_stdin_used
> 
> Same for a ppc build:
> 
> Symbol table [ 6] '.dynsym' contains 8 entries:
>  1 local symbol  String table: [ 7] '.dynstr'
>   Num:    Value   Size Type    Bind   Vis          Ndx Name
>     0: 00000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
>     1: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_deregisterTMCloneTable
>     2: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
>     3: 00000000      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main at GLIBC_2.0 (2)
>     4: 00000000      0 FUNC    GLOBAL DEFAULT    UNDEF JLI_Launch at SUNWprivate_1.1 (3)
>     5: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _Jv_RegisterClasses
>     6: 00000000      0 NOTYPE  WEAK   DEFAULT    UNDEF _ITM_registerTMCloneTable
>     7: 100007ac      4 OBJECT  GLOBAL DEFAULT       15 _IO_stdin_used
> 
> Any binary which references __libc_start_main at GLIBC_2.0 and which does
> not export _IO_stdin_used in .dynsym (.symtab does not count) has this
> issue, irrespective of the architecture.  The key point is support for
> the glibc 2.0 ABI level (as indicated by the GLIBC_2.0 symbol version).
> Architectures which joined in glibc 2.1 or later do not have this
> fallback code (although the _IO_stdin_used marker symbol is sometimes
> still there, quite unnecessarily).
> 
> So these two builds one does not have the issue.  The build is from May,
> so it can't have Severin's fix yet
> (java-1.8.0-openjdk-1.8.0.222.b04-1.el7, in case you wonder), and the
> i686 build does show the issue.

This makes sense to me. ppc 32bit and s390 31bit builds are Zero. So is
the arm 32 Fedora build for JDK 8. When we look at the linker commands
for the java executable we see:

Zero (arm32):

Linking executable java
/usr/bin/gcc -Wl,-z,relro -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Xlinker --hash-style=both -Xlinker -z -Xlinker defs -Xlinker -z -Xlinker noexecstack -Xlinker -O1 -Xlinker --allow-shlib-undefined -Xlinker -rpath -Xlinker \$ORIGIN/../lib/arm/jli -Xlinker -rpath -Xlinker \$ORIGIN/../lib/arm   -lpthread -Xlinker -soname=lib.so  -o /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.arm/openjdk/build/jdk8.build/jdk/objs/java_objs/java /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.arm/openjdk/build/jdk8.build/jdk/objs/java_objs/main.o   -lz  -L/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.arm/openjdk/build/jdk8.build/jdk/lib/arm/jli -ljli -ldl -lc

x86 from the same build:

Linking executable java
/usr/bin/gcc -Wl,-z,relro -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Xlinker --hash-style=both -Xlinker -z -Xlinker defs -Xlinker -z -Xlinker noexecstack -Xlinker -O1 -Xlinker --allow-shlib-undefined -Xlinker -rpath -Xlinker \$ORIGIN/../lib/i386/jli -Xlinker -rpath -Xlinker \$ORIGIN/../lib/i386   -lpthread -Xlinker -soname=lib.so -Xlinker -version-script=/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/jdk/make/mapfiles/launchers/mapfile-x86  -o /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/java /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/build/jdk8.build/jdk/objs/java_objs/main.o   -lz  -L/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.212.b04-4.fc31.i386/openjdk/build/jdk8.build/jdk/lib/i386/jli -ljli -ldl -lc

So the x86-32 build uses '-Xlinker -version-script ...' while the Zero
build does not. The version script (or mapfile) screws this up.

Thanks,
Severin



From sgehwolf at redhat.com  Tue Jun 25 09:04:11 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 25 Jun 2019 11:04:11 +0200
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
Message-ID: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>

Hi,

Could somebody please review this 8u backport? The build system in 8 is
different, especially hotspot makefiles. Note, libjsig.so is part of
the hotspot build. The patch is different in 8 (over 11) due to this
reason. This is a Linux-only change and should be low risk. Thoughts?

Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/

Change in JDK 11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e

Testing: Manual build of slowdebug/fastdebug/release on x86_64.
Fastdebug/release builds receive the -O3 flag, slowdebug not. As
expected.

Thanks,
Severin



From matthias.baesken at sap.com  Tue Jun 25 11:01:22 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 25 Jun 2019 11:01:22 +0000
Subject: jdk/jdk (+jdk12) Build failure on OSX 10.11
In-Reply-To: <56f4925d-07b1-35cf-0133-2a209e85ee48@oracle.com>
References: <AM6PR02MB507860E89D25D4DF9B53253E93E50@AM6PR02MB5078.eurprd02.prod.outlook.com>
 <56f4925d-07b1-35cf-0133-2a209e85ee48@oracle.com>
Message-ID: <AM6PR02MB507857678FB4A4C27C556B3A93E30@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello,  it comes  from the  MacOSX SDK,  the value

NSWindow.h:61:    NSWindowStyleMaskDocModalWindow 		= 1 << 6,

can be found  in   MacOSX10.12.sdk   and    MacOSX10.13.sdk  .
From the info I found here :

https://en.wikipedia.org/wiki/Xcode#Xcode_7.0_-_11.x_(since_Free_On-Device_Development)

XCode 8 and higher   come with at least   MacOSX  SDK   10.12  .
So checking for  the Xcode version might make more sense .


Best regards, Matthias


> -----Original Message-----
> From: Erik Joelsson <erik.joelsson at oracle.com>
> Sent: Mittwoch, 19. Juni 2019 19:30
> To: Baesken, Matthias <matthias.baesken at sap.com>; 'build-
> dev at openjdk.java.net' <build-dev at openjdk.java.net>
> Cc: Schuenemann, Rene <rene.schuenemann at sap.com>
> Subject: Re: jdk/jdk (+jdk12) Build failure on OSX 10.11
> 
> Are you sure it's 10.11 that is the problem and not the version of Xcode?
> 
> /Erik
> 
> On 2019-06-19 00:51, Baesken, Matthias wrote:
> > Hello,  I noticed that we fail  on OSX 10.11  in the build   .  Reason is  that
> NSWindowStyleMaskDocModalWindow  is used since :
> >
> > https://hg.openjdk.java.net/jdk/jdk/rev/6daafebf8189
> >
> > 8208543: [macos] Support for apple.awt.documentModalSheet incomplete
> >
> > Which is 10.12+ functionality . See
> >
> >
> https://developer.apple.com/documentation/appkit/nswindowstylemask/n
> swindowstylemaskdocmodalwindow?language=objc
> >
> > NSWindowStyleMaskDocModalWindow
> > The window is a document-modal panel (or a subclass of
> NSPanel<https://developer.apple.com/documentation/appkit/nspanel?lang
> uage=objc>).
> > macOS 10.12+
> >
> >
> >
> > I would prefer to test for  minimum  10.12  already  in  configure  , what do
> you think ?
> >
> > Best regards, Matthias
> >

From christoph.langer at sap.com  Tue Jun 25 18:14:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 25 Jun 2019 18:14:45 +0000
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
Message-ID: <AM6PR02MB5192CEA26AC906D4A39DEA918AE30@AM6PR02MB5192.eurprd02.prod.outlook.com>

Hi Severin,

I think this is good.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 25. Juni 2019 11:04
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
> 
> Hi,
> 
> Could somebody please review this 8u backport? The build system in 8 is
> different, especially hotspot makefiles. Note, libjsig.so is part of
> the hotspot build. The patch is different in 8 (over 11) due to this
> reason. This is a Linux-only change and should be low risk. Thoughts?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210761/jdk8/01/webrev/
> 
> Change in JDK 11: http://hg.openjdk.java.net/jdk-
> updates/jdk11u/rev/e7aa96dc0b1e
> 
> Testing: Manual build of slowdebug/fastdebug/release on x86_64.
> Fastdebug/release builds receive the -O3 flag, slowdebug not. As
> expected.
> 
> Thanks,
> Severin


From volker.simonis at gmail.com  Wed Jun 26 08:29:51 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 26 Jun 2019 10:29:51 +0200
Subject: CFV: New Build Group Member: Matthias Baesken
Message-ID: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>

I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.

Matthias is a long standing member of the JVM team at SAP. He's main
areas of expertise are the build system, compilers/porting and
security updates. He's a JDK Reviewer who has contributed more than
90 changes within the last two years [1], many of which were build
system related.

Votes are due by 10 July 2019, 12:00 CET.

Only current Members of the Build Group [2] are eligible
to vote on this nomination.  Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [3].

Volker Simonis

[1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100
[2] http://openjdk.java.net/census#build
[3] http://openjdk.java.net/groups/#member-vote


From volker.simonis at gmail.com  Wed Jun 26 08:30:27 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 26 Jun 2019 10:30:27 +0200
Subject: CFV: New Build Group Member: Matthias Baesken
In-Reply-To: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
References: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
Message-ID: <CA+3eh12GOi8zp0J=bEP337t1OUT208H0fQkD7pdGkj6EzC_sZA@mail.gmail.com>

Vote: yes

On Wed, Jun 26, 2019 at 10:29 AM Volker Simonis
<volker.simonis at gmail.com> wrote:
>
> I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.
>
> Matthias is a long standing member of the JVM team at SAP. He's main
> areas of expertise are the build system, compilers/porting and
> security updates. He's a JDK Reviewer who has contributed more than
> 90 changes within the last two years [1], many of which were build
> system related.
>
> Votes are due by 10 July 2019, 12:00 CET.
>
> Only current Members of the Build Group [2] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [3].
>
> Volker Simonis
>
> [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/groups/#member-vote


From sgehwolf at redhat.com  Wed Jun 26 09:01:35 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 26 Jun 2019 11:01:35 +0200
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <AM6PR02MB5192CEA26AC906D4A39DEA918AE30@AM6PR02MB5192.eurprd02.prod.outlook.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <AM6PR02MB5192CEA26AC906D4A39DEA918AE30@AM6PR02MB5192.eurprd02.prod.outlook.com>
Message-ID: <ab838ca896ca7f863c10d11dcf6b4247661e05c9.camel@redhat.com>

Hi Christoph,

On Tue, 2019-06-25 at 18:14 +0000, Langer, Christoph wrote:
> Hi Severin,
> 
> I think this is good.

Thanks for the review!

Cheers,
Severin

> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> > Severin Gehwolf
> > Sent: Dienstag, 25. Juni 2019 11:04
> > To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> > Cc: build-dev <build-dev at openjdk.java.net>
> > Subject: [8u] RFR: 8210761: libjsig is being compiled without
> > optimization
> > 
> > Hi,
> > 
> > Could somebody please review this 8u backport? The build system in
> > 8 is
> > different, especially hotspot makefiles. Note, libjsig.so is part
> > of
> > the hotspot build. The patch is different in 8 (over 11) due to
> > this
> > reason. This is a Linux-only change and should be low risk.
> > Thoughts?
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > 8210761/jdk8/01/webrev/
> > 
> > Change in JDK 11: http://hg.openjdk.java.net/jdk-
> > updates/jdk11u/rev/e7aa96dc0b1e
> > 
> > Testing: Manual build of slowdebug/fastdebug/release on x86_64.
> > Fastdebug/release builds receive the -O3 flag, slowdebug not. As
> > expected.
> > 
> > Thanks,
> > Severin



From gnu.andrew at redhat.com  Wed Jun 26 12:04:33 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 26 Jun 2019 13:04:33 +0100
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
Message-ID: <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>



On 25/06/2019 10:04, Severin Gehwolf wrote:
> Hi,
> 
> Could somebody please review this 8u backport? The build system in 8 is
> different, especially hotspot makefiles. Note, libjsig.so is part of
> the hotspot build. The patch is different in 8 (over 11) due to this
> reason. This is a Linux-only change and should be low risk. Thoughts?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/
> 
> Change in JDK 11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e
> 
> Testing: Manual build of slowdebug/fastdebug/release on x86_64.
> Fastdebug/release builds receive the -O3 flag, slowdebug not. As
> expected.
> 
> Thanks,
> Severin
> 

The 11u fix applies to all 'unix' platforms, as far as I can see. Should
the 8u equivalent not also be applied to the solaris, bsd and aix
subdirectories as well for consistency?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From thomas.stuefe at gmail.com  Wed Jun 26 12:21:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 26 Jun 2019 14:21:21 +0200
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
Message-ID: <CAA-vtUzK0MmAgpWSs-x=pxKC=p3co7MGKkyJWGRFEEE2nGRVpg@mail.gmail.com>

I'd be okay with doing this on AIX if Christoph is.

One curious question though about the original bug, was this really a
measurable performance issue? I would have thought that libjsig is not
invoked often enough for this to make a difference..

Cheers, Thomas



On Wed, Jun 26, 2019 at 2:05 PM Andrew John Hughes <gnu.andrew at redhat.com>
wrote:

>
>
> On 25/06/2019 10:04, Severin Gehwolf wrote:
> > Hi,
> >
> > Could somebody please review this 8u backport? The build system in 8 is
> > different, especially hotspot makefiles. Note, libjsig.so is part of
> > the hotspot build. The patch is different in 8 (over 11) due to this
> > reason. This is a Linux-only change and should be low risk. Thoughts?
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
> > webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/
> >
> > Change in JDK 11:
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e
> >
> > Testing: Manual build of slowdebug/fastdebug/release on x86_64.
> > Fastdebug/release builds receive the -O3 flag, slowdebug not. As
> > expected.
> >
> > Thanks,
> > Severin
> >
>
> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
> the 8u equivalent not also be applied to the solaris, bsd and aix
> subdirectories as well for consistency?
>
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>
>


From sgehwolf at redhat.com  Wed Jun 26 12:27:42 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 26 Jun 2019 14:27:42 +0200
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <CAA-vtUzK0MmAgpWSs-x=pxKC=p3co7MGKkyJWGRFEEE2nGRVpg@mail.gmail.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
 <CAA-vtUzK0MmAgpWSs-x=pxKC=p3co7MGKkyJWGRFEEE2nGRVpg@mail.gmail.com>
Message-ID: <75a72160774933d29118f065fa113cbc5030f36e.camel@redhat.com>

On Wed, 2019-06-26 at 14:21 +0200, Thomas St?fe wrote:
> 
> One curious question though about the original bug, was this really a
> measurable performance issue? I would have thought that libjsig is
> not invoked often enough for this to make a difference..

It's a matter of missed optimizations. We've got tooling in RHEL 8
which checks for native libraries which aren't being optimized. This
was one of the flagged libs throughout all of OpenJDK. While it
probably isn't needed for performance reasons, it's probly also just an
oversight that opt flags didn't get passed properly for this library.
It shouldn't do any harm.

Thanks,
Severin



From thomas.stuefe at gmail.com  Wed Jun 26 12:31:53 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 26 Jun 2019 14:31:53 +0200
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <75a72160774933d29118f065fa113cbc5030f36e.camel@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
 <CAA-vtUzK0MmAgpWSs-x=pxKC=p3co7MGKkyJWGRFEEE2nGRVpg@mail.gmail.com>
 <75a72160774933d29118f065fa113cbc5030f36e.camel@redhat.com>
Message-ID: <CAA-vtUyMxPdjLXt-ZF-E+qiHBe2UNUhBONXZemRN_VZps8G_1Q@mail.gmail.com>

On Wed, Jun 26, 2019 at 2:27 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> On Wed, 2019-06-26 at 14:21 +0200, Thomas St?fe wrote:
> >
> > One curious question though about the original bug, was this really a
> > measurable performance issue? I would have thought that libjsig is
> > not invoked often enough for this to make a difference..
>
> It's a matter of missed optimizations. We've got tooling in RHEL 8
> which checks for native libraries which aren't being optimized. This
> was one of the flagged libs throughout all of OpenJDK. While it
> probably isn't needed for performance reasons, it's probly also just an
> oversight that opt flags didn't get passed properly for this library.
> It shouldn't do any harm.
>

Thanks for clarifying!

Cheers, Thomas


> Thanks,
> Severin
>
>


From christoph.langer at sap.com  Wed Jun 26 12:47:41 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 26 Jun 2019 12:47:41 +0000
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
Message-ID: <AM6PR02MB51927C3BFE7386B7BABE2B698AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>

> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
> the 8u equivalent not also be applied to the solaris, bsd and aix
> subdirectories as well for consistency?

+1 We can test this for AIX.

Cheers
Christoph


From erik.joelsson at oracle.com  Wed Jun 26 12:53:22 2019
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 26 Jun 2019 05:53:22 -0700
Subject: CFV: New Build Group Member: Matthias Baesken
In-Reply-To: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
References: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
Message-ID: <41f84c86-5781-4c24-e877-67e8ffd542c6@oracle.com>

Vote: yes

/Erik

On 2019-06-26 01:29, Volker Simonis wrote:
> I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.
>
> Matthias is a long standing member of the JVM team at SAP. He's main
> areas of expertise are the build system, compilers/porting and
> security updates. He's a JDK Reviewer who has contributed more than
> 90 changes within the last two years [1], many of which were build
> system related.
>
> Votes are due by 10 July 2019, 12:00 CET.
>
> Only current Members of the Build Group [2] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [3].
>
> Volker Simonis
>
> [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/groups/#member-vote


From sgehwolf at redhat.com  Wed Jun 26 13:02:59 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 26 Jun 2019 15:02:59 +0200
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
Message-ID: <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com>

On Wed, 2019-06-26 at 13:04 +0100, Andrew John Hughes wrote:
> 
> On 25/06/2019 10:04, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review this 8u backport? The build system in 8 is
> > different, especially hotspot makefiles. Note, libjsig.so is part of
> > the hotspot build. The patch is different in 8 (over 11) due to this
> > reason. This is a Linux-only change and should be low risk. Thoughts?
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/
> > 
> > Change in JDK 11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e
> > 
> > Testing: Manual build of slowdebug/fastdebug/release on x86_64.
> > Fastdebug/release builds receive the -O3 flag, slowdebug not. As
> > expected.
> > 
> > Thanks,
> > Severin
> > 
> 
> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
> the 8u equivalent not also be applied to the solaris, bsd and aix
> subdirectories as well for consistency?

Here you go:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/02/webrev/

I cannot really test on bsd, solaris or aix, though :( Appreciate any
testers for those platforms.

Thanks,
Severin



From christoph.langer at sap.com  Wed Jun 26 13:11:10 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 26 Jun 2019 13:11:10 +0000
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
 <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com>
Message-ID: <AM6PR02MB519263A68006914F011F05108AE20@AM6PR02MB5192.eurprd02.prod.outlook.com>

> Here you go:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8210761/jdk8/02/webrev/
> 
> I cannot really test on bsd, solaris or aix, though :( Appreciate any
> testers for those platforms.

I pulled the patch into our test environment. It will be run for AIX and solaris there. Will let you know the results...

/Christoph


From tim.bell at oracle.com  Wed Jun 26 13:13:16 2019
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 26 Jun 2019 06:13:16 -0700
Subject: CFV: New Build Group Member: Matthias Baesken
In-Reply-To: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
References: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
Message-ID: <5D136F6C.5000402@oracle.com>

Vote: yes

Tim

On 06/26/19 01:29, Volker Simonis wrote:
> I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.



From gnu.andrew at redhat.com  Wed Jun 26 15:26:18 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Wed, 26 Jun 2019 16:26:18 +0100
Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization
In-Reply-To: <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com>
References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com>
 <dc500399-a141-ee92-d8bb-3d490d5d55fa@redhat.com>
 <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com>
Message-ID: <f5f0b835-b1bc-41ee-8608-ace29851fd6a@redhat.com>



On 26/06/2019 14:02, Severin Gehwolf wrote:
> On Wed, 2019-06-26 at 13:04 +0100, Andrew John Hughes wrote:
>>
>> On 25/06/2019 10:04, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could somebody please review this 8u backport? The build system in 8 is
>>> different, especially hotspot makefiles. Note, libjsig.so is part of
>>> the hotspot build. The patch is different in 8 (over 11) due to this
>>> reason. This is a Linux-only change and should be low risk. Thoughts?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210761
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/01/webrev/
>>>
>>> Change in JDK 11: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e7aa96dc0b1e
>>>
>>> Testing: Manual build of slowdebug/fastdebug/release on x86_64.
>>> Fastdebug/release builds receive the -O3 flag, slowdebug not. As
>>> expected.
>>>
>>> Thanks,
>>> Severin
>>>
>>
>> The 11u fix applies to all 'unix' platforms, as far as I can see. Should
>> the 8u equivalent not also be applied to the solaris, bsd and aix
>> subdirectories as well for consistency?
> 
> Here you go:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/02/webrev/
> 

This looks good. Thanks.

> I cannot really test on bsd, solaris or aix, though :( Appreciate any
> testers for those platforms.

Yeah, I expected this. I think we have two choices with these kind of
patches; either we apply changes only for GNU/Linux & let it diverge
from other platforms, or, when the fix is identical, as in this case, we
apply the fix across them all.

I think the latter is the better solution, especially when it is applied
to all platforms on the original JDK version, as it leaves anyone
working on that platform at a later date with just fixing any problems
raised by the changes, rather than being faced with having to go through
a backlog of changes.

As it stands, it sounds like only *BSD will be in this situation anyway,
thanks to Christoph's testing. Assuming that goes fine, I'm happy for
this to be pushed.

> 
> Thanks,
> Severin
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From magnus.ihse.bursie at oracle.com  Thu Jun 27 08:38:47 2019
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 27 Jun 2019 10:38:47 +0200
Subject: CFV: New Build Group Member: Matthias Baesken
In-Reply-To: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
References: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
Message-ID: <6fc8a01d-c49e-d9b0-e470-80ddccc861ae@oracle.com>

Vote: yes

/Magnus

On 2019-06-26 10:29, Volker Simonis wrote:
> I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.
>
> Matthias is a long standing member of the JVM team at SAP. He's main
> areas of expertise are the build system, compilers/porting and
> security updates. He's a JDK Reviewer who has contributed more than
> 90 changes within the last two years [1], many of which were build
> system related.
>
> Votes are due by 10 July 2019, 12:00 CET.
>
> Only current Members of the Build Group [2] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [3].
>
> Volker Simonis
>
> [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/groups/#member-vote



From sgehwolf at redhat.com  Thu Jun 27 09:06:47 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 27 Jun 2019 11:06:47 +0200
Subject: [8u] RFR: 8226870: OpenJDK 8u JRE contains clhsdb and hsdb launchers
Message-ID: <ed2ddb53a947870164092ec4d2c0504c53d23d82.camel@redhat.com>

Hi,

Could I get a review for this simple 8u-only build fix? After the 8u
backport of JDK-8059038, the JRE images have the serviceability agent
launchers, but the SA jar, sa-jdi.jar, is only in the JDK. They are
non-functional in the j2re-image after a build currently. This patch
filters clhsdb and hsdb via NOT_JRE_BIN_FILES.

Bug: https://bugs.openjdk.java.net/browse/JDK-8226870
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226870/01/webrev/

Before:

$ ls j2sdk-image/bin/
appletviewer  hsdb  jarsigner  javadoc  java-rmi.cgi  jdb    jinfo  jps         jstack  keytool       pack200     rmid         serialver   unpack200  xjc
clhsdb        idlj  java       javah    jcmd          jdeps  jjs    jrunscript  jstat   native2ascii  policytool  rmiregistry  servertool  wsgen
extcheck      jar   javac      javap    jconsole      jhat   jmap   jsadebugd   jstatd  orbd          rmic        schemagen    tnameserv   wsimport
$ ls j2re-image/bin/
clhsdb  hsdb  java  jjs  keytool  orbd  pack200  policytool  rmid  rmiregistry  servertool  tnameserv  unpack200

After:

$ ls j2sdk-image/bin/
appletviewer  hsdb  jarsigner  javadoc  java-rmi.cgi  jdb    jinfo  jps         jstack  keytool       pack200     rmid         serialver   unpack200  xjc
clhsdb        idlj  java       javah    jcmd          jdeps  jjs    jrunscript  jstat   native2ascii  policytool  rmiregistry  servertool  wsgen
extcheck      jar   javac      javap    jconsole      jhat   jmap   jsadebugd   jstatd  orbd          rmic        schemagen    tnameserv   wsimport
$ ls j2re-image/bin/
java  jjs  keytool  orbd  pack200  policytool  rmid  rmiregistry  servertool  tnameserv  unpack200

Sorry about this.

Thanks,
Severin



From shade at redhat.com  Thu Jun 27 09:10:49 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 27 Jun 2019 11:10:49 +0200
Subject: [8u] RFR: 8226870: OpenJDK 8u JRE contains clhsdb and hsdb
 launchers
In-Reply-To: <ed2ddb53a947870164092ec4d2c0504c53d23d82.camel@redhat.com>
References: <ed2ddb53a947870164092ec4d2c0504c53d23d82.camel@redhat.com>
Message-ID: <2d083d70-0735-beaa-0fc0-b77b55d16f8a@redhat.com>

On 6/27/19 11:06 AM, Severin Gehwolf wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226870
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226870/01/webrev/

Looks good to me.

-- 
Thanks,
-Aleksey



From sgehwolf at redhat.com  Thu Jun 27 09:25:36 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 27 Jun 2019 11:25:36 +0200
Subject: [8u] RFR: 8226870: OpenJDK 8u JRE contains clhsdb and hsdb
 launchers
In-Reply-To: <2d083d70-0735-beaa-0fc0-b77b55d16f8a@redhat.com>
References: <ed2ddb53a947870164092ec4d2c0504c53d23d82.camel@redhat.com>
 <2d083d70-0735-beaa-0fc0-b77b55d16f8a@redhat.com>
Message-ID: <1aaaf724f77ccce085146a3cefb0a2e18af4994f.camel@redhat.com>

On Thu, 2019-06-27 at 11:10 +0200, Aleksey Shipilev wrote:
> On 6/27/19 11:06 AM, Severin Gehwolf wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8226870
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226870/01/webrev/
> 
> Looks good to me.

Thanks for the review, Aleksey!

Cheers,
Severin



From shade at redhat.com  Thu Jun 27 09:58:48 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 27 Jun 2019 11:58:48 +0200
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
Message-ID: <57ec91d1-bd31-848b-2baa-61d24514cd9d@redhat.com>

On 5/22/19 6:34 PM, Severin Gehwolf wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
>         (includes changes to top/hotspot/jdk/langtools repos)

Excellent work! I eyeballed makefile changes and they seem fine (not an expert, though).

hotspot:

*) Test exclusion question. Do we really want to exclude these tests from tier1? I would rather see
them included and make them fail in regular runs. This would put pressure on fixing them for 8u...

 150 # Right now tier1 runs all hotspot tests except RTM tests,
 151 # and one serviceability test which seems flakey.
 152 hotspot_tier1 = \
 153   :jdk \
 154   -compiler/rtm \
 155   -serviceability/sa/jmap-hashcode/Test8028623.java

Ran it on my current jdk8u-dev:

$ CONF=linux-x86_64-normal-server-fastdebug make images test TEST=tier1

Summary: langtools_tier1
FAILED: tools/javac/lambda/LambdaParserTest.java
TEST STATS: name=langtools_tier1  run=3113  pass=3112  fail=1

Summary: hotspot_tier1
FAILED: compiler/ciReplay/TestSA.sh
FAILED: compiler/intrinsics/bmi/verifycode/TZcntTestL.java
FAILED: gc/arguments/TestAggressiveHeap.java
FAILED: runtime/RedefineObject/TestRedefineObject.java
FAILED: runtime/StackGap/testme.sh
TEST STATS: name=hotspot_tier1  run=729  pass=724  fail=5

Summary: jdk_tier1
TEST STATS: name=jdk_tier1  run=1379  pass=1379  fail=0

$ echo $?
2

So, summary is there, exit code is right, and some tests are failing (which is good for testing this
patch!).

-- 
Thanks,
-Aleksey



From sgehwolf at redhat.com  Thu Jun 27 11:20:53 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 27 Jun 2019 13:20:53 +0200
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <57ec91d1-bd31-848b-2baa-61d24514cd9d@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <57ec91d1-bd31-848b-2baa-61d24514cd9d@redhat.com>
Message-ID: <da028b7d695499db0fab18b577d899fc9a579307.camel@redhat.com>

On Thu, 2019-06-27 at 11:58 +0200, Aleksey Shipilev wrote:
> On 5/22/19 6:34 PM, Severin Gehwolf wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
> >         (includes changes to top/hotspot/jdk/langtools repos)
> 
> Excellent work! I eyeballed makefile changes and they seem fine (not an expert, though).

Thanks for the review, Aleksey!

> hotspot:
> 
> *) Test exclusion question. Do we really want to exclude these tests from tier1? I would rather see
> them included and make them fail in regular runs. This would put pressure on fixing them for 8u...
> 
>  150 # Right now tier1 runs all hotspot tests except RTM tests,
>  151 # and one serviceability test which seems flakey.
>  152 hotspot_tier1 = \
>  153   :jdk \
>  154   -compiler/rtm \
>  155   -serviceability/sa/jmap-hashcode/Test8028623.java

I'm not sure about it. We could exclude nothing and go from there.
However, the more tests we have failing from the get-go the less useful
it is to enforce tier1 tests to always pass for JDK 8u (bad
signal/noise ratio). I'd be OK for Test8028623.java, but the
compiler/rtm tests, I'm not so sure... Thoughts?

> Ran it on my current jdk8u-dev:
> 
> $ CONF=linux-x86_64-normal-server-fastdebug make images test TEST=tier1
> 
> Summary: langtools_tier1
> FAILED: tools/javac/lambda/LambdaParserTest.java
> TEST STATS: name=langtools_tier1  run=3113  pass=3112  fail=1
> 
> Summary: hotspot_tier1
> FAILED: compiler/ciReplay/TestSA.sh
> FAILED: compiler/intrinsics/bmi/verifycode/TZcntTestL.java
> FAILED: gc/arguments/TestAggressiveHeap.java
> FAILED: runtime/RedefineObject/TestRedefineObject.java
> FAILED: runtime/StackGap/testme.sh
> TEST STATS: name=hotspot_tier1  run=729  pass=724  fail=5
> 
> Summary: jdk_tier1
> TEST STATS: name=jdk_tier1  run=1379  pass=1379  fail=0

This seems about right for fastdebug builds.

> $ echo $?
> 2
> 
> So, summary is there, exit code is right, and some tests are failing (which is good for testing this
> patch!).

Any suggestions on how to proceed with this? Do you want me to do a v3
with no hotspot tests excluded? It would be nice if I could get this
patch off of my queue ;-)

Thanks,
Severin



From shade at redhat.com  Thu Jun 27 11:27:53 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 27 Jun 2019 13:27:53 +0200
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <da028b7d695499db0fab18b577d899fc9a579307.camel@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <57ec91d1-bd31-848b-2baa-61d24514cd9d@redhat.com>
 <da028b7d695499db0fab18b577d899fc9a579307.camel@redhat.com>
Message-ID: <588e7535-8e11-7a21-b98f-c28a9436dd0a@redhat.com>

On 6/27/19 1:20 PM, Severin Gehwolf wrote:
> On Thu, 2019-06-27 at 11:58 +0200, Aleksey Shipilev wrote:
>> On 5/22/19 6:34 PM, Severin Gehwolf wrote:
>> hotspot:
>>
>> *) Test exclusion question. Do we really want to exclude these tests from tier1? I would rather see
>> them included and make them fail in regular runs. This would put pressure on fixing them for 8u...
>>
>>  150 # Right now tier1 runs all hotspot tests except RTM tests,
>>  151 # and one serviceability test which seems flakey.
>>  152 hotspot_tier1 = \
>>  153   :jdk \
>>  154   -compiler/rtm \
>>  155   -serviceability/sa/jmap-hashcode/Test8028623.java
> 
> I'm not sure about it. We could exclude nothing and go from there.
> However, the more tests we have failing from the get-go the less useful
> it is to enforce tier1 tests to always pass for JDK 8u (bad
> signal/noise ratio). I'd be OK for Test8028623.java, but the
> compiler/rtm tests, I'm not so sure... Thoughts?

From my perspective, new test profile would inevitably show some (new) failures.

We would need to work to fix those failures before we can rely on low SNR in tier1. Ignoring tests
may skip over the tests that need attention during that transitional period. We don't ignore the
tests that are failing right now in fastdebug, right? Same thing here.

In other words, I would rather see tier1 suite to land, and then work on fixing/ignoring tests once
we understand how/if they are fixable.

-- 
Thanks,
-Aleksey



From sgehwolf at redhat.com  Thu Jun 27 11:50:32 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 27 Jun 2019 13:50:32 +0200
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <588e7535-8e11-7a21-b98f-c28a9436dd0a@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <57ec91d1-bd31-848b-2baa-61d24514cd9d@redhat.com>
 <da028b7d695499db0fab18b577d899fc9a579307.camel@redhat.com>
 <588e7535-8e11-7a21-b98f-c28a9436dd0a@redhat.com>
Message-ID: <1024c3784109f0c5ba403a0ab7f94215b3ba48b0.camel@redhat.com>

On Thu, 2019-06-27 at 13:27 +0200, Aleksey Shipilev wrote:
> On 6/27/19 1:20 PM, Severin Gehwolf wrote:
> > On Thu, 2019-06-27 at 11:58 +0200, Aleksey Shipilev wrote:
> > > On 5/22/19 6:34 PM, Severin Gehwolf wrote:
> > > hotspot:
> > > 
> > > *) Test exclusion question. Do we really want to exclude these tests from tier1? I would rather see
> > > them included and make them fail in regular runs. This would put pressure on fixing them for 8u...
> > > 
> > >  150 # Right now tier1 runs all hotspot tests except RTM tests,
> > >  151 # and one serviceability test which seems flakey.
> > >  152 hotspot_tier1 = \
> > >  153   :jdk \
> > >  154   -compiler/rtm \
> > >  155   -serviceability/sa/jmap-hashcode/Test8028623.java
> > 
> > I'm not sure about it. We could exclude nothing and go from there.
> > However, the more tests we have failing from the get-go the less useful
> > it is to enforce tier1 tests to always pass for JDK 8u (bad
> > signal/noise ratio). I'd be OK for Test8028623.java, but the
> > compiler/rtm tests, I'm not so sure... Thoughts?
> 
> From my perspective, new test profile would inevitably show some (new) failures.
> 
> We would need to work to fix those failures before we can rely on low SNR in tier1. Ignoring tests
> may skip over the tests that need attention during that transitional period. We don't ignore the
> tests that are failing right now in fastdebug, right? Same thing here.
> 
> In other words, I would rather see tier1 suite to land, and then work on fixing/ignoring tests once
> we understand how/if they are fixable.

OK. Updated langtools/hotspot webrevs with no exclusions. jdk had no
exclusions to begin with:

http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/

Thoughts?

Thanks,
Severin




From shade at redhat.com  Thu Jun 27 11:54:34 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 27 Jun 2019 13:54:34 +0200
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <1024c3784109f0c5ba403a0ab7f94215b3ba48b0.camel@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <57ec91d1-bd31-848b-2baa-61d24514cd9d@redhat.com>
 <da028b7d695499db0fab18b577d899fc9a579307.camel@redhat.com>
 <588e7535-8e11-7a21-b98f-c28a9436dd0a@redhat.com>
 <1024c3784109f0c5ba403a0ab7f94215b3ba48b0.camel@redhat.com>
Message-ID: <99c4d53f-a8b5-bf99-1759-43da38523b7b@redhat.com>

On 6/27/19 1:50 PM, Severin Gehwolf wrote:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/

Looks fine to me.

-- 
Thanks,
-Aleksey



From gnu.andrew at redhat.com  Thu Jun 27 16:36:30 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 27 Jun 2019 17:36:30 +0100
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
Message-ID: <fa7a56a1-16c2-9bdc-e824-e5f25b9d5c1e@redhat.com>



On 22/05/2019 17:34, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get reviews for this minimal implementation of a tier1-
> like test set for JDK 8u? The implementation is rather barebones as I
> don't think it's worth rewriting the build system just for a command
> that runs a certain set of tests across a select set of repositories.
> I've re-used existing work in Makefiles as much as possible. After this
> patch one can do:
> 
> $ make test TEST="tier1"
> 
> Inspiration came from JDK 11u's tier1. As for prior art to this, I've
> only found "make test" to be working for JDK 8u from the top level.
> Yet, it doesn't run any hotspot tests, exits with a zero code on test
> failures and doesn't present a summary at the end. Overall not a nice
> developer experience.
> 
> This patch makes it easier for a developers tests. It presents a
> summary at the end, returns non-zero on test failures so this can get
> used in CI and runs hotspot tests.
> 
> As a follow-on we can work on fixing/excluding tests so that we always
> have a passing set of tests for developers to run before a checkin.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
>         (includes changes to top/hotspot/jdk/langtools repos)
> 
> Example excerpt from a run:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

Is there a reason for creating new tier definitions here rather than
backporting the existing ones?

https://bugs.openjdk.java.net/browse/JDK-8075543

The subtasks also cover nashorn & jaxp which are missed here. jaxp would
need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From igor.ignatyev at oracle.com  Thu Jun 27 22:25:02 2019
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 27 Jun 2019 15:25:02 -0700
Subject: RFR(S) [13] : 8226910 : make it possible to use jtreg's -match via
 run-test framework
Message-ID: <8B6A5349-A39A-4AE0-980D-5C336C339DE7@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8226910/webrev.00/index.html
> 25 lines changed: 18 ins; 3 del; 4 mod;

Hi all,

could you please review this small patch which adds JTREG_RUN_PROBLEM_LISTS options to run-test framework? when JTREG_RUN_PROBLEM_LISTS is set to true, jtreg will use problem lists as values of -match: instead of -exclude, which effectively means it will run only problem listed tests.

doc/building.html got changed when I ran update-build-docs, I can exclude it from the patch, but it seems it will keep changing every time we run update-build-docs, so I decided to at least bring it up.

JBS: https://bugs.openjdk.java.net/browse/JDK-8226910
webrev: http://cr.openjdk.java.net/~iignatyev//8226910/webrev.00/index.html

Thanks,
-- Igor

From sgehwolf at redhat.com  Fri Jun 28 09:52:06 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 28 Jun 2019 11:52:06 +0200
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <fa7a56a1-16c2-9bdc-e824-e5f25b9d5c1e@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <fa7a56a1-16c2-9bdc-e824-e5f25b9d5c1e@redhat.com>
Message-ID: <a2b126a5d579d0beb7e7fd1b7a5e65ec2d1bd6cb.camel@redhat.com>

Hi Andrew,

On Thu, 2019-06-27 at 17:36 +0100, Andrew John Hughes wrote:
> 
> On 22/05/2019 17:34, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get reviews for this minimal implementation of a tier1-
> > like test set for JDK 8u? The implementation is rather barebones as I
> > don't think it's worth rewriting the build system just for a command
> > that runs a certain set of tests across a select set of repositories.
> > I've re-used existing work in Makefiles as much as possible. After this
> > patch one can do:
> > 
> > $ make test TEST="tier1"
> > 
> > Inspiration came from JDK 11u's tier1. As for prior art to this, I've
> > only found "make test" to be working for JDK 8u from the top level.
> > Yet, it doesn't run any hotspot tests, exits with a zero code on test
> > failures and doesn't present a summary at the end. Overall not a nice
> > developer experience.
> > 
> > This patch makes it easier for a developers tests. It presents a
> > summary at the end, returns non-zero on test failures so this can get
> > used in CI and runs hotspot tests.
> > 
> > As a follow-on we can work on fixing/excluding tests so that we always
> > have a passing set of tests for developers to run before a checkin.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
> >         (includes changes to top/hotspot/jdk/langtools repos)
> > 
> > Example excerpt from a run:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> > 
> 
> Is there a reason for creating new tier definitions here rather than
> backporting the existing ones?

Yes. The tests in JDK 8 are significantly different from JDK 11. Most
notably the number of tests available and defined test groups.
Backporting the JDK 11 changes seems like fitting a square peg into a
round hole.

The JDK 8u "tier1" could only be a rough approximation of the JDK 11
"tier1" at best. There is also no intention to make the test output
100% identical to JDK 11 as bringing back those changes would be too
invasive.

I believe the proposed patch is a reasonable minimal patch which aids
8u developer's testing.

> https://bugs.openjdk.java.net/browse/JDK-8075543
> 
> The subtasks also cover nashorn & jaxp which are missed here. jaxp would
> need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg.

Sure. We can consider adding later tiers in upcoming work. That's not
the priority, though. Note that tier1 tests in JDK 11 only run
jdk/lantools/hotspot tests. The intention of this initial patch would
be to have some testing "baseline" covering a reasonable set of repos
and tests.

Thanks,
Severin



From matthias.baesken at sap.com  Fri Jun 28 11:43:07 2019
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 28 Jun 2019 11:43:07 +0000
Subject: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode
 10.2 on macosx
Message-ID: <AM6PR02MB507841174CC9D39EAF07125293FC0@AM6PR02MB5078.eurprd02.prod.outlook.com>

Hello please review this  small fix for a compile issue  on OSX .
Today I  compiled   jdk/jdk   on a machine  with   XCode 10.2  . It worked pretty well .
However this small issue showed up .


In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33:
/open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error:
comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch]


And here XCode 10 is correct ,    JVMTI_REFERENCE_ARRAY_ELEMENT   is from a different  enumeration type  and should be replaced  with the value  from the correct  enumeration type   .

Bug / webrev :

https://bugs.openjdk.java.net/browse/JDK-8226943

http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/


Thanks, Matthias



From gnu.andrew at redhat.com  Fri Jun 28 13:45:31 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 28 Jun 2019 14:45:31 +0100
Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in
 OpenJDK 8u
In-Reply-To: <a2b126a5d579d0beb7e7fd1b7a5e65ec2d1bd6cb.camel@redhat.com>
References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com>
 <fa7a56a1-16c2-9bdc-e824-e5f25b9d5c1e@redhat.com>
 <a2b126a5d579d0beb7e7fd1b7a5e65ec2d1bd6cb.camel@redhat.com>
Message-ID: <eae285cd-50a2-92d4-9df5-8ea0c5db8178@redhat.com>

On 28/06/2019 10:52, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Thu, 2019-06-27 at 17:36 +0100, Andrew John Hughes wrote:
>>
>> On 22/05/2019 17:34, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could I please get reviews for this minimal implementation of a tier1-
>>> like test set for JDK 8u? The implementation is rather barebones as I
>>> don't think it's worth rewriting the build system just for a command
>>> that runs a certain set of tests across a select set of repositories.
>>> I've re-used existing work in Makefiles as much as possible. After this
>>> patch one can do:
>>>
>>> $ make test TEST="tier1"
>>>
>>> Inspiration came from JDK 11u's tier1. As for prior art to this, I've
>>> only found "make test" to be working for JDK 8u from the top level.
>>> Yet, it doesn't run any hotspot tests, exits with a zero code on test
>>> failures and doesn't present a summary at the end. Overall not a nice
>>> developer experience.
>>>
>>> This patch makes it easier for a developers tests. It presents a
>>> summary at the end, returns non-zero on test failures so this can get
>>> used in CI and runs hotspot tests.
>>>
>>> As a follow-on we can work on fixing/excluding tests so that we always
>>> have a passing set of tests for developers to run before a checkin.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222737
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/
>>>         (includes changes to top/hotspot/jdk/langtools repos)
>>>
>>> Example excerpt from a run:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> Severin
>>>
>>
>> Is there a reason for creating new tier definitions here rather than
>> backporting the existing ones?
> 
> Yes. The tests in JDK 8 are significantly different from JDK 11. Most
> notably the number of tests available and defined test groups.
> Backporting the JDK 11 changes seems like fitting a square peg into a
> round hole.
> 
> The JDK 8u "tier1" could only be a rough approximation of the JDK 11
> "tier1" at best. There is also no intention to make the test output
> 100% identical to JDK 11 as bringing back those changes would be too
> invasive.
> 
> I believe the proposed patch is a reasonable minimal patch which aids
> 8u developer's testing.
> 
>> https://bugs.openjdk.java.net/browse/JDK-8075543
>>
>> The subtasks also cover nashorn & jaxp which are missed here. jaxp would
>> need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg.
> 
> Sure. We can consider adding later tiers in upcoming work. That's not
> the priority, though. Note that tier1 tests in JDK 11 only run
> jdk/lantools/hotspot tests. The intention of this initial patch would
> be to have some testing "baseline" covering a reasonable set of repos
> and tests.
> 
> Thanks,
> Severin
> 

I'm not talking about JDK 11 changes. These are changes in JDK 9.

For example,

https://hg.openjdk.java.net/jdk9/dev/jdk/rev/cd4aea326e89

adds groups to two tiers, all of which exist in 8u as well. It's not
clear where the list in your patch comes from and it appears to add a
bunch of arbitrary other tests beyond the tier 1 defined in the JDK 9
change.

It would make more sense to me to backport JDK-8075544 & JDK-8075573 as
pre-requisites rather than creating completely new definitions.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew



From kim.barrett at oracle.com  Sat Jun 29 16:38:12 2019
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sat, 29 Jun 2019 12:38:12 -0400
Subject: CFV: New Build Group Member: Matthias Baesken
In-Reply-To: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
References: <CA+3eh13Y29yOMS3VByv-BEqTGgLjsKkRA1LgZRpDVrMMTAx1-w@mail.gmail.com>
Message-ID: <BAD76F37-9E26-43AD-8C3A-404E55DE8CA0@oracle.com>

vote: yes

> On Jun 26, 2019, at 4:29 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> I hereby nominate Matthias Baesken (mbaesken) to Membership in the Build Group.
> 
> Matthias is a long standing member of the JVM team at SAP. He's main
> areas of expertise are the build system, compilers/porting and
> security updates. He's a JDK Reviewer who has contributed more than
> 90 changes within the last two years [1], many of which were build
> system related.
> 
> Votes are due by 10 July 2019, 12:00 CET.
> 
> Only current Members of the Build Group [2] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [3].
> 
> Volker Simonis
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=((author(%22mbaesken%22)%20and%20not%20desc(%22Contributed-by%22))%20or%20desc(%22Contributed-by%3A%20matthias.baesken%40sap.com%22))%20and%20not%20merge()&revcount=100
> [2] http://openjdk.java.net/census#build
> [3] http://openjdk.java.net/groups/#member-vote