From jjg at openjdk.java.net  Tue Dec  1 02:21:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 1 Dec 2020 02:21:02 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
Message-ID: <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>

On Mon, 30 Nov 2020 14:27:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
>> -updating and moving tests into test/langtools, so that it is easier to run them.
>> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
>> -fixing the -Xprint annotation processor to print record component annotations.
>> 
>> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests on Windows - normalizing line endings.

Looks mostly OK; some minor comments inline.

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 110:

> 108:                                               "--add-exports", "jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED",
> 109:                                               "--add-exports", "jdk.javadoc/jdk.javadoc.internal.api=ALL-UNNAMED",
> 110:                                               "--add-exports", "jdk.javadoc/jdk.javadoc.internal.tool=ALL-UNNAMED",

I'm surprised CreateSymbolsTest needs access to javadoc internals; is it because you're adding all of toolbox in lines 93, 94? Would it be better to filter out the classes you don't want to compile, such as `JavadocTask` and `JavapTask` ?

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 54:

> 52: import java.util.Enumeration;
> 53: import java.util.jar.JarEntry;
> 54: import java.util.jar.JarFile;

weird order of imports

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 238:

> 236:                            "t.Visible",
> 237:                            "package t;\n\n" +
> 238: //                           "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX

Is this line still supposed to be here?

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 270:

> 268:                            "t.Visible",
> 269:                            "package t;\n\n" +
> 270: //                           "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX

Is this line still supposed to be here?

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 307:

> 305:     }
> 306: 
> 307: //    @Test XXX

Another XXX line

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513:

> 511:                              public java.util.List<java.lang.String> l();
> 512:                            }
> 513:                            """,

I don't understand why the lines with `\n` in a text block

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 69:

> 67:             System.err.println("Warning: cannot find CreateSymbols, skipping.");
> 68:             return ;
> 69:         }

I can believe this test is worth just a warning, because you're trying to reach into the `make` directory, but the subsequent checks for `CreateSymbolsTestImpl.java` and `toolbox.*` seem worthy of errors, not warnings. On the other hand, I accept that all of these checks are very unlikely to fail, so maybe it doesn't matter.

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 30:

> 28:  * @modules java.compiler
> 29:  *          jdk.compiler
> 30:  *          jdk.javadoc

See related comments in code ... seems strange to need `jdk.javadoc`.

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 121:

> 119:         }
> 120: 
> 121:         URLClassLoader cl = new URLClassLoader(new URL[] {testClasses.toUri().toURL(), compileDir.toUri().toURL()});

line 132: the name of the local variable `createSymbols` seems more specific than the method might imply!

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From ihse at openjdk.java.net  Tue Dec  1 10:14:04 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 1 Dec 2020 10:14:04 GMT
Subject: RFR: 8257487: Include configuration name in summary
Message-ID: <fY084GvoQH00mVPeBC3TsmJRQrgX5Yjo2HDZPLJuAr4=.43601c82-7374-488f-9e33-10bee3d067c0@github.com>

According to the enhancement request:

It would be nice and convenient to include the configuration name in the configuration summary, for example ("Name" being new):

Configuration summary:
* Name: my-conf
* Debug level: release
* HS debug level: product
* JVM variants: server
...

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

Commit messages:
 - 8257487: Include configuration name in summary

Changes: https://git.openjdk.java.net/jdk/pull/1534/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1534&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257487
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1534.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1534/head:pull/1534

PR: https://git.openjdk.java.net/jdk/pull/1534


From shade at openjdk.java.net  Tue Dec  1 10:26:56 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 1 Dec 2020 10:26:56 GMT
Subject: RFR: 8257487: Include configuration name in summary
In-Reply-To: <fY084GvoQH00mVPeBC3TsmJRQrgX5Yjo2HDZPLJuAr4=.43601c82-7374-488f-9e33-10bee3d067c0@github.com>
References: <fY084GvoQH00mVPeBC3TsmJRQrgX5Yjo2HDZPLJuAr4=.43601c82-7374-488f-9e33-10bee3d067c0@github.com>
Message-ID: <JYmZc2L9e4XYeeQ2W1oDdWfxA51RUUQKl6ZCaGqeB4s=.53c8275e-e17e-4c11-a59d-4add3171f382@github.com>

On Tue, 1 Dec 2020 10:09:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to the enhancement request:
> 
> It would be nice and convenient to include the configuration name in the configuration summary, for example ("Name" being new):
> 
> Configuration summary:
> * Name: my-conf
> * Debug level: release
> * HS debug level: product
> * JVM variants: server
> ...

I was under impression it was printed already, but it is not! Current build only prints the configuration path in `build`, which you can derive the config name from it. Printing the configuration name explicitly would be a nice touch for sure. Looks good.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1534


From ihse at openjdk.java.net  Tue Dec  1 11:06:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 1 Dec 2020 11:06:55 GMT
Subject: Integrated: 8257487: Include configuration name in summary
In-Reply-To: <fY084GvoQH00mVPeBC3TsmJRQrgX5Yjo2HDZPLJuAr4=.43601c82-7374-488f-9e33-10bee3d067c0@github.com>
References: <fY084GvoQH00mVPeBC3TsmJRQrgX5Yjo2HDZPLJuAr4=.43601c82-7374-488f-9e33-10bee3d067c0@github.com>
Message-ID: <wxsR7SEfrAAvPieAYs7zKWgRCLTfC4ayPJefZ6MMQlk=.edf5264d-5449-4c69-8008-d43414b670ba@github.com>

On Tue, 1 Dec 2020 10:09:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to the enhancement request:
> 
> It would be nice and convenient to include the configuration name in the configuration summary, for example ("Name" being new):
> 
> Configuration summary:
> * Name: my-conf
> * Debug level: release
> * HS debug level: product
> * JVM variants: server
> ...

This pull request has now been integrated.

Changeset: 60f2ba9a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/60f2ba9a
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8257487: Include configuration name in summary

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/1534


From jlahoda at openjdk.java.net  Tue Dec  1 11:18:11 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 11:18:11 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v4]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <U3ej9FB3f8Wl4FUWDdoOfudJkzvCJHHMBAV0OllsQ0Y=.85f9098f-18aa-4911-8708-fd4790a87fcc@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/a3f79aba..9ab7153a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=02-03

  Stats: 28 lines in 2 files changed: 5 ins; 11 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

PR: https://git.openjdk.java.net/jdk/pull/1480


From jlahoda at openjdk.java.net  Tue Dec  1 12:08:58 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 12:08:58 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
 <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
Message-ID: <AoKBfvbBw_pm22ChROZMWUw4rmQqD4PnzVwiUeB4Zqw=.b3e3d000-d189-4c82-b541-e511969e8a05@github.com>

On Tue, 1 Dec 2020 01:43:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests on Windows - normalizing line endings.
>
> test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513:
> 
>> 511:                              public java.util.List<java.lang.String> l();
>> 512:                            }
>> 513:                            """,
> 
> I don't understand why the lines with `\n` in a text block

There is a combination of factors here:
-jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks
-textblocks only remove indentation that is common on all lines.

So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list):
-do some trick to have the common indent, but no trailing whitespace. '\n' is one of them.
-not indent the text block
-do some post-processing on the text block's value or the actual test output, to make them match
-not use textblocks

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From jlahoda at openjdk.java.net  Tue Dec  1 12:13:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 12:13:56 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
 <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
Message-ID: <ojnncDORSwm7P2PAdPgcQmUDW0IK7kb5L943h_aVo6o=.4c527c1c-4402-4fe6-94f3-678a0b843858@github.com>

On Tue, 1 Dec 2020 02:18:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests on Windows - normalizing line endings.
>
> Looks mostly OK; some minor comments inline.

Thanks for the comments Jon! I've tried to resolve them here:
https://github.com/openjdk/jdk/pull/1480/commits/9ab7153a4f301dc77c02dd1ffda247cf7cdeb5ea

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From chegar at openjdk.java.net  Tue Dec  1 12:35:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 1 Dec 2020 12:35:58 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v4]
In-Reply-To: <U3ej9FB3f8Wl4FUWDdoOfudJkzvCJHHMBAV0OllsQ0Y=.85f9098f-18aa-4911-8708-fd4790a87fcc@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <U3ej9FB3f8Wl4FUWDdoOfudJkzvCJHHMBAV0OllsQ0Y=.85f9098f-18aa-4911-8708-fd4790a87fcc@github.com>
Message-ID: <LV5hG7uuNjTrASTJz8Csj7zajJ1aNFUtwZN3LxK4ilw=.fd64c5b0-3730-4713-a226-f1a92688c0ff@github.com>

On Tue, 1 Dec 2020 11:18:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
>> -updating and moving tests into test/langtools, so that it is easier to run them.
>> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
>> -fixing the -Xprint annotation processor to print record component annotations.
>> 
>> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From erikj at openjdk.java.net  Tue Dec  1 22:54:02 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 1 Dec 2020 22:54:02 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in deps
 files
Message-ID: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>

After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.

When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

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

Commit messages:
 - Handle multiple prereqs on the same line

Changes: https://git.openjdk.java.net/jdk/pull/1548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257547
  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548

PR: https://git.openjdk.java.net/jdk/pull/1548


From ihse at openjdk.java.net  Wed Dec  2 10:05:03 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2020 10:05:03 GMT
Subject: RFR: 8257224: JDK-8251549 didn't update building.html
Message-ID: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>

JDK-8251549 updated doc/building.md for building with git, but did not include corresponding updates to doc/building.html.

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

Commit messages:
 - 8257224: JDK-8251549 didn't update building.html

Changes: https://git.openjdk.java.net/jdk/pull/1557/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1557&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257224
  Stats: 39 lines in 1 file changed: 4 ins; 23 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1557.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1557/head:pull/1557

PR: https://git.openjdk.java.net/jdk/pull/1557


From sundar at openjdk.java.net  Wed Dec  2 10:21:59 2020
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 2 Dec 2020 10:21:59 GMT
Subject: RFR: 8257224: JDK-8251549 didn't update building.html
In-Reply-To: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>
References: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>
Message-ID: <Dvu_MtmfR5q-fTn3DDjqIdi9jn_h8HYILqHUXcB91Aw=.26d05ded-351f-44e8-b50a-f1b8142a4ac2@github.com>

On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> JDK-8251549 updated doc/building.md for building with git, but did not include corresponding updates to doc/building.html.

Marked as reviewed by sundar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1557


From shade at openjdk.java.net  Wed Dec  2 10:21:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 2 Dec 2020 10:21:59 GMT
Subject: RFR: 8257224: JDK-8251549 didn't update building.html
In-Reply-To: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>
References: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>
Message-ID: <LC00S9Q37a0WlqTNjC0R2-koSXlsAQaqTiIuAPaaOQw=.94795cf2-57b3-4ceb-95f6-48c13623f4c0@github.com>

On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> JDK-8251549 updated doc/building.md for building with git, but did not include corresponding updates to doc/building.html.

Looks good!

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1557


From ihse at openjdk.java.net  Wed Dec  2 10:22:04 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2020 10:22:04 GMT
Subject: RFR: 8257533: legacy-jre-image includes jpackage and jlink tools
Message-ID: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>

JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result that the legacy-jre-image builds a run-time image that contains the package and jlink tools. This seems to be an oversight as these tools should not be in the equivalent of what we knew in the past as the "JRE".

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

Commit messages:
 - 8257533: legacy-jre-image includes jpackage and jlink tools

Changes: https://git.openjdk.java.net/jdk/pull/1559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1559&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257533
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1559/head:pull/1559

PR: https://git.openjdk.java.net/jdk/pull/1559


From ihse at openjdk.java.net  Wed Dec  2 10:22:01 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2020 10:22:01 GMT
Subject: Integrated: 8257224: JDK-8251549 didn't update building.html
In-Reply-To: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>
References: <f0R7rKtuIjmbFJVajcw22tmOsTRc4GH3YIx06loRPMc=.0141374c-2658-43c5-97ff-93e8c9d4d786@github.com>
Message-ID: <lpQHIb2GNwVG5HFMmjaHHXJNQocPZx4hgMP4oo8gCN8=.474811e6-2041-4c4f-8b0a-1624f885aa4c@github.com>

On Wed, 2 Dec 2020 10:01:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> JDK-8251549 updated doc/building.md for building with git, but did not include corresponding updates to doc/building.html.

This pull request has now been integrated.

Changeset: e7ca0c4a
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e7ca0c4a
Stats:     39 lines in 1 file changed: 4 ins; 23 del; 12 mod

8257224: JDK-8251549 didn't update building.html

Reviewed-by: sundar, shade

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

PR: https://git.openjdk.java.net/jdk/pull/1557


From alanb at openjdk.java.net  Wed Dec  2 10:25:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 2 Dec 2020 10:25:57 GMT
Subject: RFR: 8257533: legacy-jre-image includes jpackage and jlink tools
In-Reply-To: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>
References: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>
Message-ID: <CiE_cO--EewkvoJx9LbP2AlrcN7V4nXskRUVRIERZZo=.e1e6b8fa-19ad-4766-ab6b-729744a580b4@github.com>

On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result that the legacy-jre-image builds a run-time image that contains the package and jlink tools. This seems to be an oversight as these tools should not be in the equivalent of what we knew in the past as the "JRE".

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1559


From sundar at openjdk.java.net  Wed Dec  2 10:29:55 2020
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 2 Dec 2020 10:29:55 GMT
Subject: RFR: 8257533: legacy-jre-image includes jpackage and jlink tools
In-Reply-To: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>
References: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>
Message-ID: <VIYVN1rpbYRXtfbPKqxMN_2MhlrF1ASfi1Q19G8CPZY=.c4f3dd6d-acc5-4c0a-82e4-27ce9422abea@github.com>

On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result that the legacy-jre-image builds a run-time image that contains the package and jlink tools. This seems to be an oversight as these tools should not be in the equivalent of what we knew in the past as the "JRE".

Marked as reviewed by sundar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1559


From ihse at openjdk.java.net  Wed Dec  2 10:33:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2020 10:33:56 GMT
Subject: Integrated: 8257533: legacy-jre-image includes jpackage and jlink
 tools
In-Reply-To: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>
References: <H9uQKbLC2cXO26R9wtpsOxh2tNZwb_pcbx_EwdXsmDQ=.522409ab-bb8f-4a8a-bf53-b3e09041872d@github.com>
Message-ID: <GduSpYZQ6HqULQMZJGfRRXny1aiUIVEzDLifJdNc-Rk=.94d7fd3d-dc02-400d-a563-8553860ea348@github.com>

On Wed, 2 Dec 2020 10:16:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> JEP 343 added jdk.jpackage to Module.gmk/JRE_TOOL_MODULES with the result that the legacy-jre-image builds a run-time image that contains the package and jlink tools. This seems to be an oversight as these tools should not be in the equivalent of what we knew in the past as the "JRE".

This pull request has now been integrated.

Changeset: bff68f1f
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bff68f1f
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8257533: legacy-jre-image includes jpackage and jlink tools

Reviewed-by: alanb, sundar

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

PR: https://git.openjdk.java.net/jdk/pull/1559


From ihse at openjdk.java.net  Wed Dec  2 10:37:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2020 10:37:55 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files
In-Reply-To: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
Message-ID: <K5eNr0BEs086ZId1nQ-uIpCVIy46CixqmJJgMshJIQ0=.64cc90c4-e319-4aa1-b518-05eb2e340a88@github.com>

On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
> 
> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

As before, regex is write-only code. :-& But I think this does what you claim it to do. :)

I'm not sure how hard it would be to add unit testing of this function (probably quite tricky), but it's starting to get close to the point were it's worth it.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1548


From tbell at openjdk.java.net  Wed Dec  2 17:44:55 2020
From: tbell at openjdk.java.net (Tim Bell)
Date: Wed, 2 Dec 2020 17:44:55 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files
In-Reply-To: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
Message-ID: <QkO8gY6uLo2e5bMh6wC6373I4amVOfYZ_C2ofSiManM=.11df0f97-d40a-44ca-b8fd-4330e16e388e@github.com>

On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
> 
> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

As @magicus wrote - this is subtle but looks OKAY.

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

Marked as reviewed by tbell (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1548


From erikj at openjdk.java.net  Wed Dec  2 17:55:18 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 17:55:18 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v2]
In-Reply-To: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
Message-ID: <yq8okSWOFvk5P1SZ-DE8gRwG6kDG-VLzxLBGSDjZSY4=.bd717e36-3a8e-4045-9c90-e061be5aa37b@github.com>

> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
> 
> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Added test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1548/files
  - new: https://git.openjdk.java.net/jdk/pull/1548/files/3164af58..9f8a7edb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=00-01

  Stats: 71 lines in 2 files changed: 70 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548

PR: https://git.openjdk.java.net/jdk/pull/1548


From erikj at openjdk.java.net  Wed Dec  2 18:54:17 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 18:54:17 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v3]
In-Reply-To: <QkO8gY6uLo2e5bMh6wC6373I4amVOfYZ_C2ofSiManM=.11df0f97-d40a-44ca-b8fd-4330e16e388e@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
 <QkO8gY6uLo2e5bMh6wC6373I4amVOfYZ_C2ofSiManM=.11df0f97-d40a-44ca-b8fd-4330e16e388e@github.com>
Message-ID: <vRqj9pRxdG3t12F2-34wXM5thpMhvIAhk6VAROc7JD0=.3aef21d2-c268-4b3a-ab32-277e02f59028@github.com>

On Wed, 2 Dec 2020 17:41:54 GMT, Tim Bell <tbell at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make newline splitting work with BSD tar to make tests pass on macosx
>
> As @magicus wrote - this is subtle but looks OKAY.

I added a test as suggested. This uncovered some portability issues as the test failed on Macosx. I have modified the fix-deps-file macro even more to make it portable for all the versions of sed we are currently using.

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From erikj at openjdk.java.net  Wed Dec  2 18:54:17 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 18:54:17 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v3]
In-Reply-To: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
Message-ID: <pEMHOw5_6TAIC9LhKOk6pX5ztSYowDeWEy9gm2eCGTY=.e57c6213-47f7-4c98-a6e0-9a1f761d16a3@github.com>

> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
> 
> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Make newline splitting work with BSD tar to make tests pass on macosx

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1548/files
  - new: https://git.openjdk.java.net/jdk/pull/1548/files/9f8a7edb..0c854066

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=01-02

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548

PR: https://git.openjdk.java.net/jdk/pull/1548


From tbell at openjdk.java.net  Wed Dec  2 20:03:56 2020
From: tbell at openjdk.java.net (Tim Bell)
Date: Wed, 2 Dec 2020 20:03:56 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v2]
In-Reply-To: <yq8okSWOFvk5P1SZ-DE8gRwG6kDG-VLzxLBGSDjZSY4=.bd717e36-3a8e-4045-9c90-e061be5aa37b@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
 <yq8okSWOFvk5P1SZ-DE8gRwG6kDG-VLzxLBGSDjZSY4=.bd717e36-3a8e-4045-9c90-e061be5aa37b@github.com>
Message-ID: <302tzOibX0Y18VdTHt82lStnlQYvnQo3ghrTkOjcS7s=.f820e3d6-1f5d-4f34-9e59-a09fb4f5e210@github.com>

On Wed, 2 Dec 2020 17:55:18 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
>> 
>> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test

test/make/TestFixDepsFile.gmk line 60:

> 58: 	$(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected
> 59: 	$(ECHO) " /foo/baz" >> $(DEPS_FILE).expected
> 60: 	$(DIFF) $(DEPS_FILE).expected $(DEPS_FILE)

Does this need to be:
$(DIFF) $(DEPS_FILE).expected $(DEPS_FILE).tmp

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From prr at openjdk.java.net  Wed Dec  2 20:22:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 2 Dec 2020 20:22:55 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
Message-ID: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>

On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ?
>> If I read the doc below it is in the 10.10 SDK and later.
>> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ
>
> Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection.

I wonder if we should be "upping" that to something later.
10.9 is over 7 years old and has been out of support for what - 4 years ?

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From javalists at cbfiddle.com  Wed Dec  2 20:45:43 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 2 Dec 2020 12:45:43 -0800
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
Message-ID: <4988ADB2-C1C2-4331-9D87-55C0A9A7B70A@cbfiddle.com>

> On Dec 2, 2020, at 12:22 PM, Phil Race <prr at openjdk.java.net> wrote:
> 
> On Wed, 2 Dec 2020 20:04:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:
> 
>>> Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ?
>>> If I read the doc below it is in the 10.10 SDK and later.
>>> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ
>> 
>> Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection.
> 
> I wonder if we should be "upping" that to something later.
> 10.9 is over 7 years old and has been out of support for what - 4 years ?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1569
> 

I know people running 10.10 and I try to keep my Java code running on 10.10, so I would suggest that.

However, my experience is that JDK 14 and later refuse to run on 10.10.

The metadata is conflicting:

The Info.plist has JVMMinimumSystemVersion 10.6.0

libjli.dylib has LC_VERSION_MIN_MACOSX 10.9

However, libjvm has LC_VERSION_MIN_MACOSX 10.13, and that is enough to prevent it from running.



From akozlov at openjdk.java.net  Wed Dec  2 21:35:57 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 2 Dec 2020 21:35:57 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
Message-ID: <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>

On Wed, 2 Dec 2020 20:19:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> Unfortunately, no. AFAIK, the minimum target version is 10.9 https://github.com/openjdk/jdk/blob/master/make/autoconf/flags.m4#L133, so I had to keep indirection.
>
> I wonder if we should be "upping" that to something later.
> 10.9 is over 7 years old and has been out of support for what - 4 years ?

Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From erikj at openjdk.java.net  Wed Dec  2 21:43:59 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 21:43:59 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v2]
In-Reply-To: <302tzOibX0Y18VdTHt82lStnlQYvnQo3ghrTkOjcS7s=.f820e3d6-1f5d-4f34-9e59-a09fb4f5e210@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
 <yq8okSWOFvk5P1SZ-DE8gRwG6kDG-VLzxLBGSDjZSY4=.bd717e36-3a8e-4045-9c90-e061be5aa37b@github.com>
 <302tzOibX0Y18VdTHt82lStnlQYvnQo3ghrTkOjcS7s=.f820e3d6-1f5d-4f34-9e59-a09fb4f5e210@github.com>
Message-ID: <wpiTwfV1InGBmFN-8dUv9htxDHGf7gGRlYEkMzwGN-Y=.613d414a-396f-4c5f-bcba-315cc733baad@github.com>

On Wed, 2 Dec 2020 20:01:08 GMT, Tim Bell <tbell at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test
>
> test/make/TestFixDepsFile.gmk line 60:
> 
>> 58: 	$(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected
>> 59: 	$(ECHO) " /foo/baz" >> $(DEPS_FILE).expected
>> 60: 	$(DIFF) $(DEPS_FILE).expected $(DEPS_FILE)
> 
> Does this need to be:
> $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE).tmp

No, the fix-deps-file macro takes file.tmp as input and outputs into file, so $(DEPS_FILE) is the output file from the macro in this case.

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From erikj at openjdk.java.net  Wed Dec  2 21:59:55 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 21:59:55 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
 <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>
Message-ID: <l5rkAkv1wM7b463AVNOT0e-oLaEU_xU2ASmb6x97-8E=.019d536f-8979-4208-8486-5447022d3c56@github.com>

On Wed, 2 Dec 2020 21:32:46 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> I wonder if we should be "upping" that to something later.
>> 10.9 is over 7 years old and has been out of support for what - 4 years ?
>
> Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9

The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used.

So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4.

The discrepancy in Info.plist was fixed in JDK-8252145.

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From erikj at openjdk.java.net  Wed Dec  2 22:03:54 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 22:03:54 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <l5rkAkv1wM7b463AVNOT0e-oLaEU_xU2ASmb6x97-8E=.019d536f-8979-4208-8486-5447022d3c56@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
 <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>
 <l5rkAkv1wM7b463AVNOT0e-oLaEU_xU2ASmb6x97-8E=.019d536f-8979-4208-8486-5447022d3c56@github.com>
Message-ID: <afT-kCFb7JGW9uHnfugYFNyOITYVG5otQqIEzaD8O_E=.72ebd4ae-5913-41e2-8826-03bd514fcac9@github.com>

On Wed, 2 Dec 2020 21:57:15 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Interesting, I still able to run the build after this change on macOS 10.9.5. I use jdk image and there is no LC_VERSION_MIN_MACOSX in libjvm. libjli, libjava have one, and it's 10.9
>
> The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used.
> 
> So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4.
> 
> The discrepancy in Info.plist was fixed in JDK-8252145.

We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug.

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From erikj at openjdk.java.net  Wed Dec  2 22:06:55 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 22:06:55 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <afT-kCFb7JGW9uHnfugYFNyOITYVG5otQqIEzaD8O_E=.72ebd4ae-5913-41e2-8826-03bd514fcac9@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
 <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>
 <l5rkAkv1wM7b463AVNOT0e-oLaEU_xU2ASmb6x97-8E=.019d536f-8979-4208-8486-5447022d3c56@github.com>
 <afT-kCFb7JGW9uHnfugYFNyOITYVG5otQqIEzaD8O_E=.72ebd4ae-5913-41e2-8826-03bd514fcac9@github.com>
Message-ID: <bwEdvPo6Qv7nuHC4tfp1IsHsDtYzRVPMb6FTVMXE-n8=.d95e3c74-4112-4e39-abff-60128e15fe22@github.com>

On Wed, 2 Dec 2020 22:00:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The current intention is to be consistent with the min system version and it's currently set to 10.9. If libjvm.dylib gets a different value, then that would be a bug, but note that this could also vary depending on how the build is configured and the compiler version used.
>> 
>> So far, I have only bumped this version once, and that was because the toolchain required it when switching to Clang from GCC. Keeping it low is nice for backwards compatibility. That said, I don't see a problem with increasing this value to 10.10 if it's needed for something. Even 10.10 was EOL a long time ago now. The current value is set in make/autoconf/flags.m4.
>> 
>> The discrepancy in Info.plist was fixed in JDK-8252145.
>
> We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug.

Filed https://bugs.openjdk.java.net/browse/JDK-8257633

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From tbell at openjdk.java.net  Wed Dec  2 22:37:57 2020
From: tbell at openjdk.java.net (Tim Bell)
Date: Wed, 2 Dec 2020 22:37:57 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v3]
In-Reply-To: <pEMHOw5_6TAIC9LhKOk6pX5ztSYowDeWEy9gm2eCGTY=.e57c6213-47f7-4c98-a6e0-9a1f761d16a3@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
 <pEMHOw5_6TAIC9LhKOk6pX5ztSYowDeWEy9gm2eCGTY=.e57c6213-47f7-4c98-a6e0-9a1f761d16a3@github.com>
Message-ID: <gw6SsktRW8lZ77Iwme8CtQ1PmrkA50Rg-dQqLg9hERg=.e49020f2-8a00-4420-b6f8-0e832833ae6b@github.com>

On Wed, 2 Dec 2020 18:54:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
>> 
>> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make newline splitting work with BSD tar to make tests pass on macosx

Marked as reviewed by tbell (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From tbell at openjdk.java.net  Wed Dec  2 22:37:58 2020
From: tbell at openjdk.java.net (Tim Bell)
Date: Wed, 2 Dec 2020 22:37:58 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v2]
In-Reply-To: <wpiTwfV1InGBmFN-8dUv9htxDHGf7gGRlYEkMzwGN-Y=.613d414a-396f-4c5f-bcba-315cc733baad@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
 <yq8okSWOFvk5P1SZ-DE8gRwG6kDG-VLzxLBGSDjZSY4=.bd717e36-3a8e-4045-9c90-e061be5aa37b@github.com>
 <302tzOibX0Y18VdTHt82lStnlQYvnQo3ghrTkOjcS7s=.f820e3d6-1f5d-4f34-9e59-a09fb4f5e210@github.com>
 <wpiTwfV1InGBmFN-8dUv9htxDHGf7gGRlYEkMzwGN-Y=.613d414a-396f-4c5f-bcba-315cc733baad@github.com>
Message-ID: <fWYKrOQJug0b0LijshqGwKDqvuKsvaYr53YzNyp-YhE=.1e7f9555-71ed-4bcf-af8b-f15663196f3b@github.com>

On Wed, 2 Dec 2020 21:41:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> test/make/TestFixDepsFile.gmk line 60:
>> 
>>> 58: 	$(ECHO) " $(WORKSPACE_ROOT)/bar/baz \\" >> $(DEPS_FILE).expected
>>> 59: 	$(ECHO) " /foo/baz" >> $(DEPS_FILE).expected
>>> 60: 	$(DIFF) $(DEPS_FILE).expected $(DEPS_FILE)
>> 
>> Does this need to be:
>> $(DIFF) $(DEPS_FILE).expected $(DEPS_FILE).tmp
>
> No, the fix-deps-file macro takes file.tmp as input and outputs into file, so $(DEPS_FILE) is the output file from the macro in this case.

OK

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From erikj at openjdk.java.net  Wed Dec  2 22:51:11 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 2 Dec 2020 22:51:11 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v4]
In-Reply-To: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
Message-ID: <UlMcZnBqgng9k0bJmzYwz0CeZq0VF9bmF-vkYjv0gi8=.e38e8242-6f32-48c1-aa85-5af5a0f4f140@github.com>

> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
> 
> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Fixed comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1548/files
  - new: https://git.openjdk.java.net/jdk/pull/1548/files/0c854066..d0039c3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1548&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1548/head:pull/1548

PR: https://git.openjdk.java.net/jdk/pull/1548


From ihse at openjdk.java.net  Wed Dec  2 22:51:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Dec 2020 22:51:12 GMT
Subject: RFR: JDK-8257547: Handle multiple prereqs on the same line in
 deps files [v4]
In-Reply-To: <UlMcZnBqgng9k0bJmzYwz0CeZq0VF9bmF-vkYjv0gi8=.e38e8242-6f32-48c1-aa85-5af5a0f4f140@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
 <UlMcZnBqgng9k0bJmzYwz0CeZq0VF9bmF-vkYjv0gi8=.e38e8242-6f32-48c1-aa85-5af5a0f4f140@github.com>
Message-ID: <b-XySlSRMcGk7rIFsgoONG12MH-UtL7XyumZ8BszYp4=.5114a94a-cd3d-4c31-a31d-edd3c380ff82@github.com>

On Wed, 2 Dec 2020 22:48:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
>> 
>> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed comment

Marked as reviewed by ihse (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From dholmes at openjdk.java.net  Thu Dec  3 04:41:01 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Dec 2020 04:41:01 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
Message-ID: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>

The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html

Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:

sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)

signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.

We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.

A CSR request has been filed.

Testing: hotspot/jtreg/runtime/signal tests

Thanks,
David

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

Commit messages:
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

Changes: https://git.openjdk.java.net/jdk/pull/1587/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1587&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257572
  Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1587.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1587/head:pull/1587

PR: https://git.openjdk.java.net/jdk/pull/1587


From akozlov at openjdk.java.net  Thu Dec  3 06:52:55 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 3 Dec 2020 06:52:55 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <bwEdvPo6Qv7nuHC4tfp1IsHsDtYzRVPMb6FTVMXE-n8=.d95e3c74-4112-4e39-abff-60128e15fe22@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
 <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>
 <l5rkAkv1wM7b463AVNOT0e-oLaEU_xU2ASmb6x97-8E=.019d536f-8979-4208-8486-5447022d3c56@github.com>
 <afT-kCFb7JGW9uHnfugYFNyOITYVG5otQqIEzaD8O_E=.72ebd4ae-5913-41e2-8826-03bd514fcac9@github.com>
 <bwEdvPo6Qv7nuHC4tfp1IsHsDtYzRVPMb6FTVMXE-n8=.d95e3c74-4112-4e39-abff-60128e15fe22@github.com>
Message-ID: <HQ_6ipJBnfR5D_0cyb0pvfyDZAFAZxU9ZZ6UN5bP3i0=.2acb269f-141a-4ae8-b022-e87b0fc6f75d@github.com>

On Wed, 2 Dec 2020 22:04:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We are indeed missing the macos-version-min argument when linking libjvm.dylib. This is a bug.
>
> Filed https://bugs.openjdk.java.net/browse/JDK-8257633

Thanks for taking care of those issues. To be clear, there is no real need to bump the version for this PR, 10.9 is fine. This PR just proposes another way to implement the workaround for 10.9.

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From jlahoda at openjdk.java.net  Thu Dec  3 09:22:18 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 09:22:18 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v5]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <bG8PpoaqCnD_mWq0sKWSkOgOmiEyvsrpbn9v5hRTWuM=.a4206e56-1a5b-493e-9e47-7156166c74fa@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Blank lines do not count for the text block indentation, removing them.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/9ab7153a..3aaaf28c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=03-04

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

PR: https://git.openjdk.java.net/jdk/pull/1480


From jlahoda at openjdk.java.net  Thu Dec  3 09:39:57 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 09:39:57 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <AoKBfvbBw_pm22ChROZMWUw4rmQqD4PnzVwiUeB4Zqw=.b3e3d000-d189-4c82-b541-e511969e8a05@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
 <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
 <AoKBfvbBw_pm22ChROZMWUw4rmQqD4PnzVwiUeB4Zqw=.b3e3d000-d189-4c82-b541-e511969e8a05@github.com>
Message-ID: <xOMtcIuGAh5GjnRpur2DBvpFfpO9gMlL6EG_CNzuCNo=.b7e25569-1e26-4029-98f3-be2c998675f4@github.com>

On Tue, 1 Dec 2020 12:06:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513:
>> 
>>> 511:                              public java.util.List<java.lang.String> l();
>>> 512:                            }
>>> 513:                            """,
>> 
>> I don't understand why the lines with `\n` in a text block
>
> There is a combination of factors here:
> -jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks
> -textblocks only remove indentation that is common on all lines.
> 
> So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list):
> -do some trick to have the common indent, but no trailing whitespace. '\n' is one of them.
> -not indent the text block
> -do some post-processing on the text block's value or the actual test output, to make them match
> -not use textblocks

I stand corrected here - blank lines do not count when the common indent is computed. Removed here:
https://github.com/openjdk/jdk/pull/1480/commits/3aaaf28c23ddda71c77ca9923e02e5f3502cde3b

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From ihse at openjdk.java.net  Thu Dec  3 11:19:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 11:19:57 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
Message-ID: <jW3NqS3CRZeiKwOclF2f42m-95S4nyeirqxIdpngUtQ=.fc6b2ae3-c832-4fe1-89a3-9245494edb1c@github.com>

On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> 
> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
> 
> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
> 
> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
> 
> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
> 
> A CSR request has been filed.
> 
> Testing: hotspot/jtreg/runtime/signal tests
> 
> Thanks,
> David

As we say in Swedish: ?ntligen! :-)

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1587


From alanb at openjdk.java.net  Thu Dec  3 11:26:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 3 Dec 2020 11:26:55 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
Message-ID: <NjaciBq8F-62SO1B-ggIxySEUUPbCR2-CWAEGulN6oU=.9eb3dda7-3df1-42d8-aebb-12fe7368db22@github.com>

On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> 
> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
> 
> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
> 
> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
> 
> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
> 
> A CSR request has been filed.
> 
> Testing: hotspot/jtreg/runtime/signal tests
> 
> Thanks,
> David

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1587


From david.holmes at oracle.com  Thu Dec  3 11:29:39 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Dec 2020 21:29:39 +1000
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <jW3NqS3CRZeiKwOclF2f42m-95S4nyeirqxIdpngUtQ=.fc6b2ae3-c832-4fe1-89a3-9245494edb1c@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <jW3NqS3CRZeiKwOclF2f42m-95S4nyeirqxIdpngUtQ=.fc6b2ae3-c832-4fe1-89a3-9245494edb1c@github.com>
Message-ID: <ff3fb211-30bb-800c-d3b0-781d605a238d@oracle.com>

On 3/12/2020 9:19 pm, Magnus Ihse Bursie wrote:
> On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>>
>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
>>
>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
>>
>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
>>
>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
>>
>> A CSR request has been filed.
>>
>> Testing: hotspot/jtreg/runtime/signal tests
>>
>> Thanks,
>> David
> 
> As we say in Swedish: ?ntligen! :-)
> 
> Build changes look good.

Thanks for the review Magnus!

David
-----

> -------------
> 
> Marked as reviewed by ihse (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/1587
> 


From david.holmes at oracle.com  Thu Dec  3 11:30:14 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Dec 2020 21:30:14 +1000
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <NjaciBq8F-62SO1B-ggIxySEUUPbCR2-CWAEGulN6oU=.9eb3dda7-3df1-42d8-aebb-12fe7368db22@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <NjaciBq8F-62SO1B-ggIxySEUUPbCR2-CWAEGulN6oU=.9eb3dda7-3df1-42d8-aebb-12fe7368db22@github.com>
Message-ID: <ae5b60ce-7259-b1a5-a186-cc28338104f6@oracle.com>

On 3/12/2020 9:26 pm, Alan Bateman wrote:
> On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>>
>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
>>
>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
>>
>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
>>
>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
>>
>> A CSR request has been filed.
>>
>> Testing: hotspot/jtreg/runtime/signal tests
>>
>> Thanks,
>> David
> 
> Marked as reviewed by alanb (Reviewer).

Thanks for the Review Alan!

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1587
> 


From erikj at openjdk.java.net  Thu Dec  3 14:07:01 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 3 Dec 2020 14:07:01 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
Message-ID: <YCsP7qJXNzgw5XjQcgIY4Dk1KlO5pRJYqcNYOvVi16g=.abeaf05c-2a50-46d7-a68d-b9d7c57a96a9@github.com>

On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> 
> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
> 
> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
> 
> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
> 
> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
> 
> A CSR request has been filed.
> 
> Testing: hotspot/jtreg/runtime/signal tests
> 
> Thanks,
> David

make/modules/java.base/Lib.gmk line 131:

> 129: ifeq ($(call isTargetOsType, unix), true)
> 130:   ifeq ($(STATIC_BUILD), false)
> 131:     LIBJSIG_CFLAGS += -DHOTSPOT_VM_DISTRO='"$(HOTSPOT_VM_DISTRO)"'

In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag.

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

PR: https://git.openjdk.java.net/jdk/pull/1587


From ihse at openjdk.java.net  Thu Dec  3 14:28:10 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 14:28:10 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv)
Message-ID: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>

For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.

This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).

Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.

This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

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

Commit messages:
 - 8257679: Improved unix compatibility layer in Windows build (winenv)

Changes: https://git.openjdk.java.net/jdk/pull/1597/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257679
  Stats: 4686 lines in 51 files changed: 1875 ins; 2474 del; 337 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From dcubed at openjdk.java.net  Thu Dec  3 14:42:58 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Dec 2020 14:42:58 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
Message-ID: <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>

On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> 
> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
> 
> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
> 
> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
> 
> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
> 
> A CSR request has been filed.
> 
> Testing: hotspot/jtreg/runtime/signal tests
> 
> Thanks,
> David

Thumbs up on the jsig.c change. No comment on the Lib.gmk change.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1587


From ihse at openjdk.java.net  Thu Dec  3 15:30:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 15:30:15 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Missed my last bugfix for fixpath.sh...

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1597/files
  - new: https://git.openjdk.java.net/jdk/pull/1597/files/855751f3..c00d5a99

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Thu Dec  3 16:49:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 16:49:57 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v2]
In-Reply-To: <m5KdIZFS3vxqpvImobjesvU849cYjKqo7An4kVXfWpg=.823ecd78-c275-4ada-b6ad-e1345942fc4d@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <p-tMkl2oYim20DfuLi76-c3EiiAyqd49KTb8MujW1XM=.585b069c-fe9a-4ebc-aefe-ac93f5cb6154@github.com>
 <A6hSlg7ci_t4WHzd-HT3qga-j0eGdM00tWnAoWPBWKg=.5595fc9e-f04c-4c62-abfa-295e54975399@github.com>
 <m5KdIZFS3vxqpvImobjesvU849cYjKqo7An4kVXfWpg=.823ecd78-c275-4ada-b6ad-e1345942fc4d@github.com>
Message-ID: <QZ9Nm25lovRS369kg_OIn5hhldRLn_nuuvdAHxCPz7s=.8c008155-78b2-44ef-869a-9b27fe85ef84@github.com>

On Mon, 30 Nov 2020 15:44:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Thanks for all the comments.
>> 
>>> - 40-50 min builds seem to be excessive for just the hotspot build, do youknow what exactly takes that long? Is this for release and debug each or both combined?
>> 
>> It's for each of them. Installing a specific version of MSVC and creating the devkit take each ~10min. Thinking about it,  there is a opportunity to cache the devkit and do the MSVC installer invocation only if no cached devkit is available.
>> 
>> Here is an example run if you want to have a closer look:
>> https://github.com/lewurm/openjdk/runs/1434118318?check_suite_focus=true
>> 
>>> - Is it worth the cycles to build both release *and* debug? How probable is
>> it that a non-win-aarch-dev will break one but not the other? I presume
>> developers on the windows aarch project will have tested the build locally
>> before pushing.
>> 
>> Fair, I'll remove one of them (as suggested by Aleksey in another comment, I'll keep the debug one).
>
> Generating a devkit every time we build seems like a pretty big waste of time. The OpenJDK build is expected to work without devkits, using an installed Visual Studio. Is this not possible with the Windows aarch64 build? If not, then that really should be fixed.

FWIW, here is a patch on top of my winenv rewrite that adds windows-aarch64 support on Github Actions:
https://github.com/magicus/openjdk-sandbox/compare/winenv-rewrite...magicus:winenv-aarch64-gha?expand=1

I've used it while developing the winenv rewrite, but pulled it out of the final integration so as to not mix in the question of enabling more build platforms on GHA in the discussion of the rewrite.

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

PR: https://git.openjdk.java.net/jdk/pull/1379


From erikj at openjdk.java.net  Thu Dec  3 21:14:02 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 3 Dec 2020 21:14:02 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
Message-ID: <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>

On Thu, 3 Dec 2020 15:30:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
>> 
>> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
>> 
>> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
>> 
>> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed my last bugfix for fixpath.sh...

Overall this is very nice. Some comments and questions inline.

make/CreateJmods.gmk line 172:

> 170:   endif
> 171: else # not java.base
> 172:   ifeq ($(call isTargetOs, windows)+$(CREATING_BUILDJDK), true+false)

This looks strange. Why would CREATING_BUILDJDK be relevant here?

make/TestImage.gmk line 34:

> 32: 
> 33: ifeq ($(call isTargetOs, windows), true)
> 34:   FIXPATH_COPY := $(TEST_IMAGE_DIR)/bin/fixpath.sh

If fixpath.sh is now a static shell script in make/scripts, there is no need to transport it through the test image, is there?

make/autoconf/toolchain.m4 line 838:

> 836:     else
> 837:       if test "x$TOOLCHAIN_TYPE" = xmicrosoft; then
> 838:         # If we got no  devkit, we need to go hunting for the proper env

Double space

make/autoconf/util_paths.m4 line 401:

> 399:             if test "x$4" != xNOFIXPATH; then
> 400:               [ if [[ $FIXPATH != "" && $result =~ ^"$FIXPATH " ]]; then ]
> 401:                 result="\$FIXPATH ${result#"$FIXPATH "}"

Maybe I'm missing something, but is this unconditionally adding fixpath to any executable based just on if FIXPATH is set? Shouldn't there be a conditional on if the executable is Windows or Unix type?

make/autoconf/util_paths.m4 line 482:

> 480: ###############################################################################
> 481: # Add FIXPATH prefix to variable. Normally this is done by UTIL_LOOKUP_PROGS
> 482: # or UTIL_FIXUP_EXECUTABLE, but in some circumstances this have to be done

this _has_ to be done

make/common/JavaCompilation.gmk line 232:

> 230:       $1_JAVAC_PORT_FILE := $$(call FixPath, $$(JAVAC_SERVER_DIR)/server.port)
> 231: 
> 232:       # The servercmd specified how to launch the server. This will be executed

specifies

make/common/JavaCompilation.gmk line 241:

> 239: 
> 240:       $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE)
> 241: 	$(ECHO) portfile=$$($1_JAVAC_PORT_FILE) > $$@

Did you consider using WriteFile here?

make/modules/java.base/Copy.gmk line 48:

> 46: ################################################################################
> 47: # Copy the microsoft runtime libraries on windows
> 48: ifeq ($(call isTargetOs, windows)+$(CREATING_BUILDJDK), true+false)

Is the problem here that we don't have build versions of the runtime libraries so we simply trust that they are present on the build host instead?

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From erikj at openjdk.java.net  Thu Dec  3 21:45:58 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 3 Dec 2020 21:45:58 GMT
Subject: Integrated: JDK-8257547: Handle multiple prereqs on the same line in
 deps files
In-Reply-To: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
References: <QJG_Ugi0RP_7YUNWcHKcvHqjMrEjygs7JqcBdkSAn_c=.4a249348-7f7d-44e0-8591-548f6c729694@github.com>
Message-ID: <weEiTHpqwFqsGJxV6pbeIqVzjXnzbC3cW9VkmsIqQuI=.d5593538-9403-40ab-aa9b-ba44d380cad0@github.com>

On Tue, 1 Dec 2020 22:49:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> After fixing JDK-8256810 and starting to look into backporting it, I discovered more potential failing cases. Certain versions of GCC may sometimes output multiple prerequisite files on the same line. I think the easiest way to handle this new issue is to split such lines.
> 
> When splitting lines, we need to make sure to not just split on any space. Some compilers output the : of the rule with a leading space, and already split lines will have a space before the backslash.

This pull request has now been integrated.

Changeset: 36209b70
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36209b70
Stats:     85 lines in 3 files changed: 80 ins; 0 del; 5 mod

8257547: Handle multiple prereqs on the same line in deps files

Reviewed-by: ihse, tbell

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

PR: https://git.openjdk.java.net/jdk/pull/1548


From jvernee at openjdk.java.net  Thu Dec  3 22:24:54 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 3 Dec 2020 22:24:54 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
Message-ID: <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>

On Thu, 3 Dec 2020 21:11:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed my last bugfix for fixpath.sh...
>
> Overall this is very nice. Some comments and questions inline.

Hey,

Since I often work on Windows I'm taking this for a spin, but the current patch fails during `configure` for me with:

configure: Using default toolchain microsoft (Microsoft Visual Studio)
configure: Found Visual Studio installation at /cygdrive/j/progra~2/micros~1/2019/community/ using --with-tools-dir
configure: Found Microsoft Visual Studio 2019
configure: Trying to extract Visual Studio environment variables for x86_64
configure: using /cygdrive/j/progra~2/micros~1/2019/community//vc/auxiliary/build/vcvarsx86_amd64.bat
configure: Setting extracted environment variables for x86_64
fixpath: failure: Directory containing path 'usr\local\bin' does not exist
checking that Visual Studio variables have been correctly extracted... ok
checking for cl... [not found]
configure: error: Could not find a C compiler.
configure exiting with result code 1

I think this is because I have my VS installation in a non-default directory passed to `--with-tools-dir`. This is the configure command:

bash configure \
  --with-conf-name=windows-release \
  --with-boot-jdk='/cygdrive/c/Program Files/Java/jdk-15' \
  --with-jtreg=/cygdrive/h/libs/jtreg-5.1-b01/ \
  --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
  --with-toolchain-version=2019 \
  --with-jmh=/cygdrive/h/libs/jmh

(Note that `--with-tools-dir` requires a Windows path for some reason, otherwise configure complains that the VS installation is not valid).

---

Cross-compiling to Linux with WSL works with:

bash configure \
  --build=x86_64-unknown-linux-gnu \
  --host=x86_64-unknown-linux-gnu \
  --with-jtreg=/mnt/h/libs/jtreg-5.1-b01 \
  --with-conf-name=linux-release \
  --with-boot-jdk=/usr/lib/jvm/jdk-15 \
  --with-jmh=/mnt/h/libs/jmh

But trying to configure for Windows on WSL with:

bash configure \
  --with-conf-name=windows-release-wsl \
  --with-boot-jdk='/mnt/c/Program Files/Java/jdk-15' \
  --with-jtreg=/mnt/h/libs/jtreg-5.1-b01/ \
  --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
  --with-toolchain-version=2019 \
  --with-jmh=/mnt/h/libs/jmh

Fails with:

configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 56895: -version: command not found
configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
configure exiting with result code 1

This is not a configuration I normally use though. Since I've had problems with WSL I usually use Cygwin, so the configure command might not be right (am I missing a target platform flag here? According to the build docs Windows is the default).

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Thu Dec  3 22:44:00 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 22:44:00 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
Message-ID: <47tQsE72gVpC2iR1NdFpZutr0mQYA6nYYDIbaf9gW1g=.c3eaf0fe-66c0-4d0d-a560-345887db0887@github.com>

On Thu, 3 Dec 2020 15:20:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed my last bugfix for fixpath.sh...
>
> make/CreateJmods.gmk line 172:
> 
>> 170:   endif
>> 171: else # not java.base
>> 172:   ifeq ($(call isTargetOs, windows)+$(CREATING_BUILDJDK), true+false)
> 
> This looks strange. Why would CREATING_BUILDJDK be relevant here?

If we are creating a buildjdk (which really means we are cross-compiling), we must not meddle with the Windows runtime dll:s, since they are for the target CPU architecture. To be *fully* correct, we should really turn the Windows runtime dll:s into a "normal"/BUILD_ split version, like with SYSROOT etc. 

But since this is just used locally for building, I'm assuming the build system has these runtime DLLs installed already. There seems to be no point in wasting time preparing a buildjdk with files that are just bundled for installation.

Maybe there's a better way to express this, but the only thing I could get a hold of for the fact that we are creating a build-JDK (that is, not targeting the normal OPENJDK_TARGET_CPU) was the CREATING_BUILDJDK variable.

> make/TestImage.gmk line 34:
> 
>> 32: 
>> 33: ifeq ($(call isTargetOs, windows), true)
>> 34:   FIXPATH_COPY := $(TEST_IMAGE_DIR)/bin/fixpath.sh
> 
> If fixpath.sh is now a static shell script in make/scripts, there is no need to transport it through the test image, is there?

I assume you are right. Even though it bothers me to my bone that we just check out the complete source for testing, instead of building a proper test image. :) I'll fix.

> make/common/JavaCompilation.gmk line 241:
> 
>> 239: 
>> 240:       $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE)
>> 241: 	$(ECHO) portfile=$$($1_JAVAC_PORT_FILE) > $$@
> 
> Did you consider using WriteFile here?

Yes, I tried that first. And pulled my hair a couple of times. Turns out there is no way (that I could find, at least) to get WriteFile to write multiple lines.

> make/modules/java.base/Copy.gmk line 48:
> 
>> 46: ################################################################################
>> 47: # Copy the microsoft runtime libraries on windows
>> 48: ifeq ($(call isTargetOs, windows)+$(CREATING_BUILDJDK), true+false)
> 
> Is the problem here that we don't have build versions of the runtime libraries so we simply trust that they are present on the build host instead?

Yes. And this applies to the other fix above as well. Hm. Maybe it is enough to avoid copying them here, and then I don't need the patch in CreateJmods.gmk

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Thu Dec  3 22:52:00 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 22:52:00 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
Message-ID: <DhIkCnkTN6AvUzSwRRmiVsacj6Gh2EEJ4-boUnSHHzs=.2a1f0096-fa38-4170-a6c3-29e59e33b847@github.com>

On Thu, 3 Dec 2020 20:04:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missed my last bugfix for fixpath.sh...
>
> make/autoconf/util_paths.m4 line 401:
> 
>> 399:             if test "x$4" != xNOFIXPATH; then
>> 400:               [ if [[ $FIXPATH != "" && $result =~ ^"$FIXPATH " ]]; then ]
>> 401:                 result="\$FIXPATH ${result#"$FIXPATH "}"
> 
> Maybe I'm missing something, but is this unconditionally adding fixpath to any executable based just on if FIXPATH is set? Shouldn't there be a conditional on if the executable is Windows or Unix type?

I agree it is a bit hairy. Perhaps not ideal; even though this is a rewrite it has suffered some legacy "lava flow" itself, being in development for so long.

The idea here is. that NOFIXPATH (or not) as $4 is passed to UTIL_FIXUP_EXECUTABLE. If it is set, then UTIL_FIXUP_EXECUTABLE will never prepend FIXPATH. Otherwise, UTIL_FIXUP_EXECUTABLE will do the check you are requesting, and see if we are on Windows and it is a non-unix-aware executable, and if so, prepend FIXPATH.

So when we come back to UTIL_LOOKUP_PROGS, if we don't have NOFIXPATH, and we are on Windows (FIXPATH is non-empty) and the path we got from UTIL_FIXUP_EXECUTABLE starts with FIXPATH, then we remove all instances of FIXPATH, and prepend a single FIXPATH instance.

While seems like unneccessary work. I ran into situations where I got a double FIXPATH prefix. It might have been the result of some other bug that is fixed by now, but costs very little to keep this as a safeguard. It should get a comment, though, describing what it does.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Thu Dec  3 22:55:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 22:55:55 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
Message-ID: <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>

On Thu, 3 Dec 2020 22:21:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Overall this is very nice. Some comments and questions inline.
>
> Hey,
> 
> Since I often work on Windows I'm taking this for a spin, but the current patch fails during `configure` for me with:
> 
> configure: Using default toolchain microsoft (Microsoft Visual Studio)
> configure: Found Visual Studio installation at /cygdrive/j/progra~2/micros~1/2019/community/ using --with-tools-dir
> configure: Found Microsoft Visual Studio 2019
> configure: Trying to extract Visual Studio environment variables for x86_64
> configure: using /cygdrive/j/progra~2/micros~1/2019/community//vc/auxiliary/build/vcvarsx86_amd64.bat
> configure: Setting extracted environment variables for x86_64
> fixpath: failure: Directory containing path 'usr\local\bin' does not exist
> checking that Visual Studio variables have been correctly extracted... ok
> checking for cl... [not found]
> configure: error: Could not find a C compiler.
> configure exiting with result code 1
> 
> I think this is because I have my VS installation in a non-default directory passed to `--with-tools-dir`. This is the configure command:
> 
> bash configure \
>   --with-conf-name=windows-release \
>   --with-boot-jdk='/cygdrive/c/Program Files/Java/jdk-15' \
>   --with-jtreg=/cygdrive/h/libs/jtreg-5.1-b01/ \
>   --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
>   --with-toolchain-version=2019 \
>   --with-jmh=/cygdrive/h/libs/jmh
> 
> (Note that `--with-tools-dir` requires a Windows path for some reason, otherwise configure complains that the VS installation is not valid).
> 
> ---
> 
> Cross-compiling to Linux with WSL works with:
> 
> bash configure \
>   --build=x86_64-unknown-linux-gnu \
>   --host=x86_64-unknown-linux-gnu \
>   --with-jtreg=/mnt/h/libs/jtreg-5.1-b01 \
>   --with-conf-name=linux-release \
>   --with-boot-jdk=/usr/lib/jvm/jdk-15 \
>   --with-jmh=/mnt/h/libs/jmh
> 
> But trying to configure for Windows on WSL with:
> 
> bash configure \
>   --with-conf-name=windows-release-wsl \
>   --with-boot-jdk='/mnt/c/Program Files/Java/jdk-15' \
>   --with-jtreg=/mnt/h/libs/jtreg-5.1-b01/ \
>   --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
>   --with-toolchain-version=2019 \
>   --with-jmh=/mnt/h/libs/jmh
> 
> Fails with:
> 
> configure: Found potential Boot JDK using configure arguments
> configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
> configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 56895: -version: command not found
> configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
> configure exiting with result code 1
> 
> This is not a configuration I normally use though. Since I've had problems with WSL I usually use Cygwin, so the configure command might not be right (am I missing a target platform flag here? According to the build docs Windows is the default).
> 
> (I'll continue investigating as well)

@JornVernee Thanks for your feedback! I'll have a closer look at your examples, and see if I can reproduce them in my own environment. One question, your first example, was this from a Cygwin environment?

As a general comment, the idea is that paths to configure options should be in "unix" style. If that is not accepted, it is a bug. (Otoh, I try hard to be tolerant and accept Windows style or mixed-style ("c:/windows") paths as well, but this is not guaranteed to work.)

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Thu Dec  3 22:59:04 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 3 Dec 2020 22:59:04 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
Message-ID: <AIZ3625tkTJ_44UQ-wsdbqygrDn8sT8QGO6gO6H1Prk=.ca702e64-dca8-4009-95d2-b3f8b989b621@github.com>

On Thu, 3 Dec 2020 22:21:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Overall this is very nice. Some comments and questions inline.
>
> Hey,
> 
> Since I often work on Windows I'm taking this for a spin, but the current patch fails during `configure` for me with:
> 
> configure: Using default toolchain microsoft (Microsoft Visual Studio)
> configure: Found Visual Studio installation at /cygdrive/j/progra~2/micros~1/2019/community/ using --with-tools-dir
> configure: Found Microsoft Visual Studio 2019
> configure: Trying to extract Visual Studio environment variables for x86_64
> configure: using /cygdrive/j/progra~2/micros~1/2019/community//vc/auxiliary/build/vcvarsx86_amd64.bat
> configure: Setting extracted environment variables for x86_64
> fixpath: failure: Directory containing path 'usr\local\bin' does not exist
> checking that Visual Studio variables have been correctly extracted... ok
> checking for cl... [not found]
> configure: error: Could not find a C compiler.
> configure exiting with result code 1
> 
> I think this is because I have my VS installation in a non-default directory passed to `--with-tools-dir`. This is the configure command:
> 
> bash configure \
>   --with-conf-name=windows-release \
>   --with-boot-jdk='/cygdrive/c/Program Files/Java/jdk-15' \
>   --with-jtreg=/cygdrive/h/libs/jtreg-5.1-b01/ \
>   --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
>   --with-toolchain-version=2019 \
>   --with-jmh=/cygdrive/h/libs/jmh
> 
> (Note that `--with-tools-dir` requires a Windows path for some reason, otherwise configure complains that the VS installation is not valid).
> 
> ---
> 
> Cross-compiling to Linux with WSL works with:
> 
> bash configure \
>   --build=x86_64-unknown-linux-gnu \
>   --host=x86_64-unknown-linux-gnu \
>   --with-jtreg=/mnt/h/libs/jtreg-5.1-b01 \
>   --with-conf-name=linux-release \
>   --with-boot-jdk=/usr/lib/jvm/jdk-15 \
>   --with-jmh=/mnt/h/libs/jmh
> 
> But trying to configure for Windows on WSL with:
> 
> bash configure \
>   --with-conf-name=windows-release-wsl \
>   --with-boot-jdk='/mnt/c/Program Files/Java/jdk-15' \
>   --with-jtreg=/mnt/h/libs/jtreg-5.1-b01/ \
>   --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
>   --with-toolchain-version=2019 \
>   --with-jmh=/mnt/h/libs/jmh
> 
> Fails with:
> 
> configure: Found potential Boot JDK using configure arguments
> configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
> configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 56895: -version: command not found
> configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
> configure exiting with result code 1
> 
> This is not a configuration I normally use though. Since I've had problems with WSL I usually use Cygwin, so the configure command might not be right (am I missing a target platform flag here? According to the build docs Windows is the default).
> 
> (I'll continue investigating as well)

> @JornVernee Thanks for your feedback! I'll have a closer look at your examples, and see if I can reproduce them in my own environment. One question, your first example, was this from a Cygwin environment?

Yes, sorry, the first example is from running in Cygwin. The problem might be with the Windows path then.
 
> As a general comment, the idea is that paths to configure options should be in "unix" style. If that is not accepted, it is a bug. (Otoh, I try hard to be tolerant and accept Windows style or mixed-style ("c:/windows") paths as well, but this is not guaranteed to work.)

Okay, the problem might be with the Windows path then. I'll see if I can make some changes and get it to accept a unix path as well.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Thu Dec  3 23:01:55 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 3 Dec 2020 23:01:55 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
Message-ID: <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>

On Thu, 3 Dec 2020 22:52:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hey,
>> 
>> Since I often work on Windows I'm taking this for a spin, but the current patch fails during `configure` for me with:
>> 
>> configure: Using default toolchain microsoft (Microsoft Visual Studio)
>> configure: Found Visual Studio installation at /cygdrive/j/progra~2/micros~1/2019/community/ using --with-tools-dir
>> configure: Found Microsoft Visual Studio 2019
>> configure: Trying to extract Visual Studio environment variables for x86_64
>> configure: using /cygdrive/j/progra~2/micros~1/2019/community//vc/auxiliary/build/vcvarsx86_amd64.bat
>> configure: Setting extracted environment variables for x86_64
>> fixpath: failure: Directory containing path 'usr\local\bin' does not exist
>> checking that Visual Studio variables have been correctly extracted... ok
>> checking for cl... [not found]
>> configure: error: Could not find a C compiler.
>> configure exiting with result code 1
>> 
>> I think this is because I have my VS installation in a non-default directory passed to `--with-tools-dir`. This is the configure command:
>> 
>> bash configure \
>>   --with-conf-name=windows-release \
>>   --with-boot-jdk='/cygdrive/c/Program Files/Java/jdk-15' \
>>   --with-jtreg=/cygdrive/h/libs/jtreg-5.1-b01/ \
>>   --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
>>   --with-toolchain-version=2019 \
>>   --with-jmh=/cygdrive/h/libs/jmh
>> 
>> (Note that `--with-tools-dir` requires a Windows path for some reason, otherwise configure complains that the VS installation is not valid).
>> 
>> ---
>> 
>> Cross-compiling to Linux with WSL works with:
>> 
>> bash configure \
>>   --build=x86_64-unknown-linux-gnu \
>>   --host=x86_64-unknown-linux-gnu \
>>   --with-jtreg=/mnt/h/libs/jtreg-5.1-b01 \
>>   --with-conf-name=linux-release \
>>   --with-boot-jdk=/usr/lib/jvm/jdk-15 \
>>   --with-jmh=/mnt/h/libs/jmh
>> 
>> But trying to configure for Windows on WSL with:
>> 
>> bash configure \
>>   --with-conf-name=windows-release-wsl \
>>   --with-boot-jdk='/mnt/c/Program Files/Java/jdk-15' \
>>   --with-jtreg=/mnt/h/libs/jtreg-5.1-b01/ \
>>   --with-tools-dir='J:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools' \
>>   --with-toolchain-version=2019 \
>>   --with-jmh=/mnt/h/libs/jmh
>> 
>> Fails with:
>> 
>> configure: Found potential Boot JDK using configure arguments
>> configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
>> configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 56895: -version: command not found
>> configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
>> configure exiting with result code 1
>> 
>> This is not a configuration I normally use though. Since I've had problems with WSL I usually use Cygwin, so the configure command might not be right (am I missing a target platform flag here? According to the build docs Windows is the default).
>> 
>> (I'll continue investigating as well)
>
> @JornVernee Thanks for your feedback! I'll have a closer look at your examples, and see if I can reproduce them in my own environment. One question, your first example, was this from a Cygwin environment?
> 
> As a general comment, the idea is that paths to configure options should be in "unix" style. If that is not accepted, it is a bug. (Otoh, I try hard to be tolerant and accept Windows style or mixed-style ("c:/windows") paths as well, but this is not guaranteed to work.)

@magicus Ah dang, I tested passing `--with-tools-dir` a unix path before but messed up the drive letter. So, passing unix path to `--with-tools-dir` works after all (though IIRC this wasn't the case in the past).

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Thu Dec  3 23:27:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 3 Dec 2020 23:27:56 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
Message-ID: <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>

On Thu, 3 Dec 2020 22:59:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee Thanks for your feedback! I'll have a closer look at your examples, and see if I can reproduce them in my own environment. One question, your first example, was this from a Cygwin environment?
>> 
>> As a general comment, the idea is that paths to configure options should be in "unix" style. If that is not accepted, it is a bug. (Otoh, I try hard to be tolerant and accept Windows style or mixed-style ("c:/windows") paths as well, but this is not guaranteed to work.)
>
> @magicus Ah dang, I tested passing `--with-tools-dir` a unix path before but messed up the drive letter. So, passing unix path to `--with-tools-dir` (i.e. `--with-tools-dir='/cygdrive/j/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools'`) works after all (though IIRC this wasn't the case in the past).

@JornVernee Yes, this can certainly have been wrong in the past. That's one of the things that I've fixed with this patch, making sure we handle paths correctly :-)

Does this mean the patch works for you on both Cygwin and WSL now?

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Thu Dec  3 23:33:54 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 3 Dec 2020 23:33:54 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
Message-ID: <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>

On Thu, 3 Dec 2020 23:25:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @magicus Ah dang, I tested passing `--with-tools-dir` a unix path before but messed up the drive letter. So, passing unix path to `--with-tools-dir` (i.e. `--with-tools-dir='/cygdrive/j/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools'`) works after all (though IIRC this wasn't the case in the past).
>
> @JornVernee Yes, this can certainly have been wrong in the past. That's one of the things that I've fixed with this patch, making sure we handle paths correctly :-)
> 
> Does this mean the patch works for you on both Cygwin and WSL now?

@magicus No, the same problems still remain. I seem to have narrowed down the first error to the `set-vs-env.sh` script.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Thu Dec  3 23:55:55 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 3 Dec 2020 23:55:55 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v2]
In-Reply-To: <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
Message-ID: <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>

On Thu, 3 Dec 2020 23: 31:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee Yes, this can certainly have been wrong in the past. That's one of the things that I've fixed with this patch, making sure we handle paths correctly :-)
>> 
>> Does this mean the patch works for you on both Cygwin and WSL now?
>
> @magicus No, the same problems still remain. I seem to have narrowed down the first error to the `set-vs-env.sh` script; the PATH it extracts for VS_PATH contains `usr\local\bin` for some reason.
> 
> <values that seem to come from vcvars>
> C:\windows\system32
> H:\cygwin64\bin
> usr\local\bin
> H:\cygwin64\usr\local\bin
> H:\cygwin64\bin
> <contents of system PATH>

Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin PATH in .bash_profile. If I remove that I get a little further.

But the same command fails later on a path with a space in it:

fixpath: failure: Path '/cygdrive/c/progra~2/ati technologies/ati.ace/core-static' contains space

Looks like a missing short/8dot3 path for one directory. I'll try to get it working on my end. I'll take further questions offline to keep this thread focused on the review.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 08:57:22 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 08:57:22 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v3]
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <IvIyS6Xii2TlKfvqW76lM8r3y9s53TDmt9zACaaJ8yM=.8763f66d-4c57-4bff-a58a-100b8865716c@github.com>

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Address remarks in code review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1597/files
  - new: https://git.openjdk.java.net/jdk/pull/1597/files/c00d5a99..20f26190

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=01-02

  Stats: 32 lines in 7 files changed: 5 ins; 18 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 08:57:23 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 08:57:23 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v3]
In-Reply-To: <47tQsE72gVpC2iR1NdFpZutr0mQYA6nYYDIbaf9gW1g=.c3eaf0fe-66c0-4d0d-a560-345887db0887@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <47tQsE72gVpC2iR1NdFpZutr0mQYA6nYYDIbaf9gW1g=.c3eaf0fe-66c0-4d0d-a560-345887db0887@github.com>
Message-ID: <6s5z7bRKH7JPCgS3bW2LWrWluROgWboeWiW393QZvhM=.14a7f3ae-7b17-49b7-9642-8e245a71f828@github.com>

On Thu, 3 Dec 2020 22:36:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/CreateJmods.gmk line 172:
>> 
>>> 170:   endif
>>> 171: else # not java.base
>>> 172:   ifeq ($(call isTargetOs, windows)+$(CREATING_BUILDJDK), true+false)
>> 
>> This looks strange. Why would CREATING_BUILDJDK be relevant here?
>
> If we are creating a buildjdk (which really means we are cross-compiling), we must not meddle with the Windows runtime dll:s, since they are for the target CPU architecture. To be *fully* correct, we should really turn the Windows runtime dll:s into a "normal"/BUILD_ split version, like with SYSROOT etc. 
> 
> But since this is just used locally for building, I'm assuming the build system has these runtime DLLs installed already. There seems to be no point in wasting time preparing a buildjdk with files that are just bundled for installation.
> 
> Maybe there's a better way to express this, but the only thing I could get a hold of for the fact that we are creating a build-JDK (that is, not targeting the normal OPENJDK_TARGET_CPU) was the CREATING_BUILDJDK variable.

I reverted this change, and added a comment when we copy the libs.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 10:28:30 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 10:28:30 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective module
Message-ID: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 

These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 

This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

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

Commit messages:
 - Update references in test
 - Step 2: Update references
 - First stage, move actual data files

Changes: https://git.openjdk.java.net/jdk/pull/1611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257733
  Stats: 78 lines in 1575 files changed: 3 ins; 1 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Fri Dec  4 10:32:11 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 10:32:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

To facilitate review, here is a list on how the different directories under make/data has moved.

**To java.base:**
* blacklistedcertsconverter
* cacerts
* characterdata
* charsetmapping
* cldr
* currency
* lsrdata
* publicsuffixlist
* tzdata
* unicodedata

**To java.desktop:**
* dtdbuilder
* fontconfig
* macosxicons
* x11wrappergen

**To jdk.compiler:**
* symbols

**To jdk.jdi:**
* jdwp

**Remaining in make:**
* bundle
* docs-resources
* macosxsigning
* mainmanifest

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From alanb at openjdk.java.net  Fri Dec  4 11:17:12 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 11:17:12 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
Message-ID: <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>

On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>
> To facilitate review, here is a list on how the different directories under make/data has moved.
> 
> **To java.base:**
> * blacklistedcertsconverter
> * cacerts
> * characterdata
> * charsetmapping
> * cldr
> * currency
> * lsrdata
> * publicsuffixlist
> * tzdata
> * unicodedata
> 
> **To java.desktop:**
> * dtdbuilder
> * fontconfig
> * macosxicons
> * x11wrappergen
> 
> **To jdk.compiler:**
> * symbols
> 
> **To jdk.jdi:**
> * jdwp
> 
> **Remaining in make:**
> * bundle
> * docs-resources
> * macosxsigning
> * mainmanifest

Are you proposing any text or guidelines to be added to JEP 201 as part of this?

I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Fri Dec  4 11:42:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 11:42:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
Message-ID: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>

On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To facilitate review, here is a list on how the different directories under make/data has moved.
>> 
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsrdata
>> * publicsuffixlist
>> * tzdata
>> * unicodedata
>> 
>> **To java.desktop:**
>> * dtdbuilder
>> * fontconfig
>> * macosxicons
>> * x11wrappergen
>> 
>> **To jdk.compiler:**
>> * symbols
>> 
>> **To jdk.jdi:**
>> * jdwp
>> 
>> **Remaining in make:**
>> * bundle
>> * docs-resources
>> * macosxsigning
>> * mainmanifest
>
> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
> 
> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

@AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.

I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Fri Dec  4 11:42:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 11:42:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
Message-ID: <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>

On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
>> 
>> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.
>
> @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.
> 
> I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From alanb at openjdk.java.net  Fri Dec  4 12:33:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 12:33:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
Message-ID: <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>

On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> And I can certainly move jdwp.spec to java.base instead. 

If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Fri Dec  4 12:49:35 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 12:49:35 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v4]
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <j9oWAYK3hur1tIS5ktNpTQFKc3uZXhwdBlw_LE1ovsw=.6b8927c5-76f2-47a5-807c-72baeb63efe6@github.com>

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Make fixpath import ignore bad paths while importing path lists

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1597/files
  - new: https://git.openjdk.java.net/jdk/pull/1597/files/20f26190..5b7a7490

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=02-03

  Stats: 57 lines in 2 files changed: 15 ins; 3 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 12:49:35 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 12:49:35 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v4]
In-Reply-To: <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
Message-ID: <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>

On Thu, 3 Dec 2020 23:53:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @magicus No, the same problems still remain. I seem to have narrowed down the first error to the `set-vs-env.sh` script; the PATH it extracts for VS_PATH contains `usr\local\bin` for some reason.
>> 
>> <values that seem to come from vcvars>
>> C:\windows\system32
>> H:\cygwin64\bin
>> usr\local\bin
>> H:\cygwin64\usr\local\bin
>> H:\cygwin64\bin
>> <contents of system PATH>
>
> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin PATH in .bash_profile. If I remove that I get a little further.
> 
> But the same command fails later on a path with a space in it:
> 
> fixpath: failure: Path '/cygdrive/c/progra~2/ati technologies/ati.ace/core-static' contains space
> 
> Looks like a missing short/8dot3 path for one directory. I'll try to get it working on my end. I'll take further questions offline to keep this thread focused on the review.

@JornVernee I have now pushed a fix that will make `fixpath import` ignore invalid or unknown paths be ignored. Please try again with it.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From erikj at openjdk.java.net  Fri Dec  4 14:08:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:08:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
Message-ID: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>

On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it.
>
>> And I can certainly move jdwp.spec to java.base instead. 
> 
> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.

My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From erikj at openjdk.java.net  Fri Dec  4 14:08:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:08:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
Message-ID: <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>

On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> And I can certainly move jdwp.spec to java.base instead. 
>> 
>> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.
>
> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.

Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From erikj at openjdk.java.net  Fri Dec  4 14:20:14 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:20:14 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v4]
In-Reply-To: <47tQsE72gVpC2iR1NdFpZutr0mQYA6nYYDIbaf9gW1g=.c3eaf0fe-66c0-4d0d-a560-345887db0887@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <47tQsE72gVpC2iR1NdFpZutr0mQYA6nYYDIbaf9gW1g=.c3eaf0fe-66c0-4d0d-a560-345887db0887@github.com>
Message-ID: <L6aaxO-3w_Q7eCnDcLxFyKM68dV90vwEAIylvMHmaK0=.74c15582-0506-416a-8855-08f0021d9f92@github.com>

On Thu, 3 Dec 2020 22:39:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/common/JavaCompilation.gmk line 241:
>> 
>>> 239: 
>>> 240:       $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE)
>>> 241: 	$(ECHO) portfile=$$($1_JAVAC_PORT_FILE) > $$@
>> 
>> Did you consider using WriteFile here?
>
> Yes, I tried that first. And pulled my hair a couple of times. Turns out there is no way (that I could find, at least) to get WriteFile to write multiple lines.

Fair enough.

>> make/autoconf/util_paths.m4 line 401:
>> 
>>> 399:             if test "x$4" != xNOFIXPATH; then
>>> 400:               [ if [[ $FIXPATH != "" && $result =~ ^"$FIXPATH " ]]; then ]
>>> 401:                 result="\$FIXPATH ${result#"$FIXPATH "}"
>> 
>> Maybe I'm missing something, but is this unconditionally adding fixpath to any executable based just on if FIXPATH is set? Shouldn't there be a conditional on if the executable is Windows or Unix type?
>
> I agree it is a bit hairy. Perhaps not ideal; even though this is a rewrite it has suffered some legacy "lava flow" itself, being in development for so long.
> 
> The idea here is. that NOFIXPATH (or not) as $4 is passed to UTIL_FIXUP_EXECUTABLE. If it is set, then UTIL_FIXUP_EXECUTABLE will never prepend FIXPATH. Otherwise, UTIL_FIXUP_EXECUTABLE will do the check you are requesting, and see if we are on Windows and it is a non-unix-aware executable, and if so, prepend FIXPATH.
> 
> So when we come back to UTIL_LOOKUP_PROGS, if we don't have NOFIXPATH, and we are on Windows (FIXPATH is non-empty) and the path we got from UTIL_FIXUP_EXECUTABLE starts with FIXPATH, then we remove all instances of FIXPATH, and prepend a single FIXPATH instance.
> 
> While seems like unneccessary work. I ran into situations where I got a double FIXPATH prefix. It might have been the result of some other bug that is fixed by now, but costs very little to keep this as a safeguard. It should get a comment, though, describing what it does.

Comment is good for me, thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From erikj at openjdk.java.net  Fri Dec  4 14:20:12 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:20:12 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v4]
In-Reply-To: <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
Message-ID: <N7k4rv_agyEWGmOlOIeebYeChIq-75KgPCphJmokD8w=.34eeb5b9-ac18-40d0-9f0d-792bb442fa0b@github.com>

On Fri, 4 Dec 2020 12:45:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin PATH in .bash_profile. If I remove that I get a little further.
>> 
>> But the same command fails later on a path with a space in it:
>> 
>> fixpath: failure: Path '/cygdrive/c/progra~2/ati technologies/ati.ace/core-static' contains space
>> 
>> Looks like a missing short/8dot3 path for one directory. I'll try to get it working on my end. I'll take further questions offline to keep this thread focused on the review.
>
> @JornVernee I have now pushed a fix that will make `fixpath import` ignore invalid or unknown paths be ignored. Please try again with it.

This looks good to me now, but seems GHA aren't completely ok with it yet.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Fri Dec  4 14:25:13 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 4 Dec 2020 14:25:13 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v4]
In-Reply-To: <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
Message-ID: <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08mlo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>

On Fri, 4 Dec 2020 12:45:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin PATH in .bash_profile. If I remove that I get a little further.
>> 
>> But the same command fails later on a path with a space in it:
>> 
>> fixpath: failure: Path '/cygdrive/c/progra~2/ati technologies/ati.ace/core-static' contains space
>> 
>> Looks like a missing short/8dot3 path for one directory. I'll try to get it working on my end. I'll take further questions offline to keep this thread focused on the review.
>
> @JornVernee I have now pushed a fix that will make `fixpath import` ignore invalid or unknown paths be ignored. Please try again with it.

@magicus Thanks! But, now I get the same error as the GH action: https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80

Looks like `-a` is not supported in my shell. I can make the error go away locally with:

diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
index ae5ca1f8a28..c7737a23eb8 100644
--- a/make/scripts/fixpath.sh
+++ b/make/scripts/fixpath.sh
@@ -207,7 +207,7 @@ function import_command_line() {
     if ! [[ $arg =~ ^" "+$ ]]; then
       import_path "$arg"

-      if [[ "$result" != "" -a "$imported" = "" ]]; then
+      if [[ "$result" != "" ]] && [[ "$imported" = "" ]]; then
         imported="$result"
       else
         imported="$imported:$result"
But I'm not sure that does the same thing.

After that, I can confirm that both path issues with Cygwin are resolved (`usr\local\bin` and paths with spaces don't cause a hard failure anymore).

---

The issue with WSL still remains though:

configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 57167: -version: command not found
configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
configure exiting with result code 1

Line 57167 in generated-configure.sh is this:

    # Now join together the path and the arguments once again
    new_complete="$prefix$new_path$arguments"

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From erikj at openjdk.java.net  Fri Dec  4 14:50:20 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:50:20 GMT
Subject: RFR: JDK-8257633: Missing -mmacosx-version-min=X flag when linking
 libjvm
Message-ID: <x_8zkGG3mpXKunYI1FU4jBt6Ge1T7TB63V1CLWOpWQo=.0a71e980-fa0b-4e6c-822c-19adc39b59fc@github.com>

We have historically provided -mmacosx-version-min=10.9.0 flags when compiling and linking all our native executables and libraries on Macosx. That flag seems to have disappeared when linking libjvm. This is sometimes causing our macosx builds to not be able to run on older versions of macosx.

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

Commit messages:
 - Add -macosx-version-min to libjvm ldflags

Changes: https://git.openjdk.java.net/jdk/pull/1623/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1623&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257633
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1623.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1623/head:pull/1623

PR: https://git.openjdk.java.net/jdk/pull/1623


From ihse at openjdk.java.net  Fri Dec  4 15:17:37 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 15:17:37 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <3agsL041hMjT_5pyM4KRcTFTR06rUaIi4JAj8MUN4Uk=.2618ccad-af7c-472b-a17a-4876ea7d8dcc@github.com>

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix  syntax error in fixpath.sh

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1597/files
  - new: https://git.openjdk.java.net/jdk/pull/1597/files/5b7a7490..b8a2412a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 15:20:14 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 15:20:14 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
Message-ID: <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>

On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.
>
> Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?

@erikj79 Good point, that makes much more sense.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From jvernee at openjdk.java.net  Fri Dec  4 16:00:14 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 4 Dec 2020 16:00:14 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08mlo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
Message-ID: <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>

On Fri, 4 Dec 2020 14:22:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee I have now pushed a fix that will make `fixpath import` ignore invalid or unknown paths be ignored. Please try again with it.
>
> @magicus Thanks! But, now I get the same error as the GH action: https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80
> 
> Looks like `-a` is not supported in my shell. I can make the error go away locally with:
> 
> diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
> index ae5ca1f8a28..c7737a23eb8 100644
> --- a/make/scripts/fixpath.sh
> +++ b/make/scripts/fixpath.sh
> @@ -207,7 +207,7 @@ function import_command_line() {
>      if ! [[ $arg =~ ^" "+$ ]]; then
>        import_path "$arg"
> 
> -      if [[ "$result" != "" -a "$imported" = "" ]]; then
> +      if [[ "$result" != "" ]] && [[ "$imported" = "" ]]; then
>          imported="$result"
>        else
>          imported="$imported:$result"
> But I'm not sure that does the same thing.
> 
> After that, I can confirm that both path issues with Cygwin are resolved (`usr\local\bin` and paths with spaces don't cause a hard failure anymore).
> 
> ---
> 
> The issue with WSL still remains though:
> 
> configure: Found potential Boot JDK using configure arguments
> configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
> configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 57167: -version: command not found
> configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
> configure exiting with result code 1
> 
> Line 57167 in generated-configure.sh is this:
> 
>     # Now join together the path and the arguments once again
>     new_complete="$prefix$new_path$arguments"

Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).

With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From erikj at openjdk.java.net  Fri Dec  4 17:37:17 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 17:37:17 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
Message-ID: <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>

On Fri, 4 Dec 2020 15:57:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @magicus Thanks! But, now I get the same error as the GH action: https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80
>> 
>> Looks like `-a` is not supported in my shell. I can make the error go away locally with:
>> 
>> diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
>> index ae5ca1f8a28..c7737a23eb8 100644
>> --- a/make/scripts/fixpath.sh
>> +++ b/make/scripts/fixpath.sh
>> @@ -207,7 +207,7 @@ function import_command_line() {
>>      if ! [[ $arg =~ ^" "+$ ]]; then
>>        import_path "$arg"
>> 
>> -      if [[ "$result" != "" -a "$imported" = "" ]]; then
>> +      if [[ "$result" != "" ]] && [[ "$imported" = "" ]]; then
>>          imported="$result"
>>        else
>>          imported="$imported:$result"
>> But I'm not sure that does the same thing.
>> 
>> After that, I can confirm that both path issues with Cygwin are resolved (`usr\local\bin` and paths with spaces don't cause a hard failure anymore).
>> 
>> ---
>> 
>> The issue with WSL still remains though:
>> 
>> configure: Found potential Boot JDK using configure arguments
>> configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
>> configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 57167: -version: command not found
>> configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
>> configure exiting with result code 1
>> 
>> Line 57167 in generated-configure.sh is this:
>> 
>>     # Now join together the path and the arguments once again
>>     new_complete="$prefix$new_path$arguments"
>
> Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).
> 
> With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.

Do you see any significant difference in build times compared to before the patch?

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 18:04:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 18:04:12 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
 <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
Message-ID: <YcAce1zigLJVARACNnWacOMJdcP2cC1k_yWfEYHSZg0=.5201464b-2932-4076-a458-dd955204247a@github.com>

On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).
>> 
>> With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.
>
> Do you see any significant difference in build times compared to before the patch?

The line numbers in the generated configure script seems to be mismatched; that can't have been the actual failing line.

This actual failing line is line 79 in boot-jdk.m4:

  BOOT_JDK_VERSION_OUTPUT=`$java_to_test $USER_BOOT_JDK_OPTIONS -version 2>&1`

If $java_to_test (and $USER_BOOT_JDK_OPTIONS) is empty,  then we try to execute `-version` and get this output. So the question is, why is java_to_test empty? The two preceding lines are:


          java_to_test="$BOOT_JDK/bin/java"
          UTIL_FIXUP_EXECUTABLE(java_to_test)

Sp java_to_test should be `/mnt/c/Program Files/Java/jdk-15/bin/java`. And obviously UTIL_FIXUP_EXECUTABLE rewrites this to the empty string. Why that is so, I don't know. Perhaps an issue with the space in the path.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From mgronlun at openjdk.java.net  Fri Dec  4 18:08:59 2020
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 4 Dec 2020 18:08:59 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default)
Message-ID: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>

Greetings,

please help review this enhancement to let JFR sample object allocations by default.

A description is provided in the JIRA issue.

Thanks
Markus

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

Commit messages:
 - defensive initialization check
 - Whitespace errors
 - JFR Event Throttling

Changes: https://git.openjdk.java.net/jdk/pull/1624/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257602
  Stats: 2607 lines in 43 files changed: 2346 ins; 238 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1624/head:pull/1624

PR: https://git.openjdk.java.net/jdk/pull/1624


From ihse at openjdk.java.net  Fri Dec  4 18:10:18 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 18:10:18 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
Message-ID: <hcdUUXGmat261Y0twS2vy20Stv0cB8IVBdFHRIv9SqM=.51099d6e-14c4-4d6c-9ed1-715c0854dc33@github.com>

On Fri, 4 Dec 2020 15:57:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @magicus Thanks! But, now I get the same error as the GH action: https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80
>> 
>> Looks like `-a` is not supported in my shell. I can make the error go away locally with:
>> 
>> diff --git a/make/scripts/fixpath.sh b/make/scripts/fixpath.sh
>> index ae5ca1f8a28..c7737a23eb8 100644
>> --- a/make/scripts/fixpath.sh
>> +++ b/make/scripts/fixpath.sh
>> @@ -207,7 +207,7 @@ function import_command_line() {
>>      if ! [[ $arg =~ ^" "+$ ]]; then
>>        import_path "$arg"
>> 
>> -      if [[ "$result" != "" -a "$imported" = "" ]]; then
>> +      if [[ "$result" != "" ]] && [[ "$imported" = "" ]]; then
>>          imported="$result"
>>        else
>>          imported="$imported:$result"
>> But I'm not sure that does the same thing.
>> 
>> After that, I can confirm that both path issues with Cygwin are resolved (`usr\local\bin` and paths with spaces don't cause a hard failure anymore).
>> 
>> ---
>> 
>> The issue with WSL still remains though:
>> 
>> configure: Found potential Boot JDK using configure arguments
>> configure: Potential Boot JDK found at /mnt/c/Program Files/Java/jdk-15 is not a working JDK; ignoring
>> configure: Output from java -version was: /mnt/h/cygwin64/home/Jorn/cygwin-projects-new/git-jdk2/build/.configure-support/generated-configure.sh: line 57167: -version: command not found
>> configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
>> configure exiting with result code 1
>> 
>> Line 57167 in generated-configure.sh is this:
>> 
>>     # Now join together the path and the arguments once again
>>     new_complete="$prefix$new_path$arguments"
>
> Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).
> 
> With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.

@JornVernee Ah, sorry, I missed that you had added yet another comment, with the solution! :-) I'll have a look at why the space is problematic. 

Do I understand you correctly that the same path to Java worked on Cygwin but failed on WSL?

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Fri Dec  4 18:14:12 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 4 Dec 2020 18:14:12 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <hcdUUXGmat261Y0twS2vy20Stv0cB8IVBdFHRIv9SqM=.51099d6e-14c4-4d6c-9ed1-715c0854dc33@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
 <hcdUUXGmat261Y0twS2vy20Stv0cB8IVBdFHRIv9SqM=.51099d6e-14c4-4d6c-9ed1-715c0854dc33@github.com>
Message-ID: <zjyfiNFDn8Uq9IyR21WG6YruZslWu0hv1oUcWvLiPzA=.2aa1d04c-9e21-49cd-a205-bc93b3028035@github.com>

On Fri, 4 Dec 2020 18:07:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).
>> 
>> With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.
>
> @JornVernee Ah, sorry, I missed that you had added yet another comment, with the solution! :-) I'll have a look at why the space is problematic. 
> 
> Do I understand you correctly that the same path to Java worked on Cygwin but failed on WSL?

@magicus Yes, that is correct. The path worked on Cygwin but not on WSL.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 18:23:16 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 18:23:16 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
 <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
Message-ID: <fYMhXI8JDipAhxrUwg1AG8QhhiKkkbnteH6bVnjGX74=.262ce012-9b4f-433d-800e-781526885f89@github.com>

On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).
>> 
>> With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.
>
> Do you see any significant difference in build times compared to before the patch?

@erikj79 The big difference is the shell script fixpath, as opposed to a native fixpath.exe. I've gone to great pains to make sure the "exec" pathway in fixpath.sh contains no external calls, but only native bash constructs, to avoid forks, which are expensive at Windows. With that said, fixpath.sh is still slower than fixpath.exe. A typical invocation with fixpath.sh is about 30 ms slower than fixpath.exe;  that is, in average 0.079 s instead of  0.047 s. (This is on Cygwin; on WSL fixpath.sh executes basically instantaneously.) This do translate to longer build times, but I have a hard time getting a proper value. The fluctuation in build times is so large so it's hard to say with certainty, but e.g. on GitHub Actions the build time increased from 53-57 minutes typically, to 58-62 minutes typically.  On my personal machine, I could get more reliable and repeatable results. There the time taken to build hotspot increased from 4 min 45 s to 4 min 53 s.

All these values are from running on Cygwin. The build times on WSL noticeably faster. (As a follow-up bug, I intend to migrate the GitHub Action script to running on WSL instead of Cygwin.) On machine, the build time decreased from over. 15 minutes, to under 13, when going from Cygwin to WSL.

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Fri Dec  4 18:29:14 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 4 Dec 2020 18:29:14 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v5]
In-Reply-To: <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
 <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
Message-ID: <GMLzH05Ydb3IFFcIHIkya3JKWYXjljrvmYhBiqINzuI=.814e5af5-e31b-4d92-9cfc-7617ba7988fa@github.com>

On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Ok, after looking at `set -x` output WSL seems to have a problem with the space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that Program Files dir does have an 8dot3 name).
>> 
>> With that I can build `images` on both Cygwin and WSL. Build times are about 29 mins and 18 mins respectively.
>
> Do you see any significant difference in build times compared to before the patch?

@erikj79 I don't really see a significant difference in the build time of `images` on my machine when comparing before and after the patch (but, as Magnus says, the build times tend to fluctuate, so it's hard to get an accurate assessment. Maybe the difference is a couple of minutes. Not that big a deal for a 30-ish minute build).

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 18:54:32 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 18:54:32 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v6]
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <dTqtn0j6bgb_VE83is3HajHTLWpTDjHkpF0PG5s1YkM=.d49ed511-2198-4513-b319-63910d189ad1@github.com>

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix for .exe on WSL in fixpath.sh

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1597/files
  - new: https://git.openjdk.java.net/jdk/pull/1597/files/b8a2412a..41cee7d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=04-05

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From ihse at openjdk.java.net  Fri Dec  4 18:54:33 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 18:54:33 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v6]
In-Reply-To: <GMLzH05Ydb3IFFcIHIkya3JKWYXjljrvmYhBiqINzuI=.814e5af5-e31b-4d92-9cfc-7617ba7988fa@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <Rr5cfYpufUTH13i0mWztb3s6PRV-B6qnCv5aY2tq_6g=.e5617759-e99f-4f17-998d-71c2b0caadde@github.com>
 <YS9RWmRX6umtlYBsuvPN-1rkTM1EbujT8iR8nXTFBco=.bc878810-9503-486d-9a2f-e23dc595e567@github.com>
 <YxP1wHBkfi7FduPO41s296RA_fqrLlsk4_9CWCyfqEo=.4c1d2f4e-0f27-4309-a149-c44d1a916d87@github.com>
 <QIFMicEPvi58xRu-bdflk-AcSGPhTnNaN68Bo22BgH8=.1809c236-ff06-4937-8a9b-2a102b60a0bb@github.com>
 <C-XrHcb9DvLFy-nHNaPdkb0aujcl6-MlUg_HpbE7Pqo=.6637cd7a-e88e-45a7-bc6e-7f51dfae9687@github.com>
 <Ub1dEZs37e01p5utBVrjsPeR36M2upJ7jRYM5vWsUdE=.92155a4e-1773-4955-ae51-93d6f903da84@github.com>
 <qIXRmMZa0ciLpUMOzjh92s4ThBM1wfiUFcISLp3J_Bk=.2f5a4e8a-86cb-4f0e-8f10-2b393feae505@github.com>
 <yWMRT63lpKhpQFyuM6hdeiblwtgoN-ravReH0af96Ms=.2282d160-73e8-4d56-918c-e93b05621503@github.com>
 <eVTDGvocw405Pieq0zdAvZpsLZWOCeWybUu1UK1PBaQ=.6824d552-ee64-49a4-ad9a-1177723ffb06@github.com>
 <vvb35_J6cJw4NUwW6t5_U7C9F04zQVkh08m
 lo0zusig=.1049917a-8a88-4070-90b5-3a95233e2ea4@github.com>
 <Kuk6-svU4WKSF-MBEE9A5pPyU-OD2kKPuWJSF-hI2T0=.c8c9068d-8928-4915-b0da-af9db0140f3f@github.com>
 <WdEJMOnTVmBxciud8-RnpyAA078odRBMTJsYRntgSVU=.911aa8fc-b5c3-4c96-a7aa-8af6308b8573@github.com>
 <GMLzH05Ydb3IFFcIHIkya3JKWYXjljrvmYhBiqINzuI=.814e5af5-e31b-4d92-9cfc-7617ba7988fa@github.com>
Message-ID: <tEh8oHjT0qS_ovPOhtLpSEzZkph81Vrnd5algYZ_eME=.0f9b64e5-33fc-4899-a93c-625ef86481a5@github.com>

On Fri, 4 Dec 2020 18:26:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Do you see any significant difference in build times compared to before the patch?
>
> @erikj79 I don't really see a significant difference in the build time of `images` on my machine when comparing before and after the patch (but, as Magnus says, the build times tend to fluctuate, so it's hard to get an accurate assessment. Maybe the difference is a couple of minutes. Not that big a deal for a 30-ish minute build).

@JornVernee I have reproed the issue, identified the problem and pushed a patch. Please try again!

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jvernee at openjdk.java.net  Fri Dec  4 19:24:13 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 4 Dec 2020 19:24:13 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v6]
In-Reply-To: <dTqtn0j6bgb_VE83is3HajHTLWpTDjHkpF0PG5s1YkM=.d49ed511-2198-4513-b319-63910d189ad1@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <dTqtn0j6bgb_VE83is3HajHTLWpTDjHkpF0PG5s1YkM=.d49ed511-2198-4513-b319-63910d189ad1@github.com>
Message-ID: <_dPUe5GCq6yXNfLg8bZLtpPwLozAZ5kDkYe5NgPDD6g=.eff938a0-9f25-4e64-87c4-d96917b0e6b4@github.com>

On Fri, 4 Dec 2020 18:54:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
>> 
>> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
>> 
>> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
>> 
>> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for .exe on WSL in fixpath.sh

Thanks for the fixes! "Works on my machine" now (Cygwin and WSL).

(FWIW, next week is the fork for RDP1 I believe, so might want to wait with pushing until after that)

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

Marked as reviewed by jvernee (Committer).

PR: https://git.openjdk.java.net/jdk/pull/1597


From mikael at openjdk.java.net  Fri Dec  4 20:05:11 2020
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Fri, 4 Dec 2020 20:05:11 GMT
Subject: RFR: JDK-8257633: Missing -mmacosx-version-min=X flag when
 linking libjvm
In-Reply-To: <x_8zkGG3mpXKunYI1FU4jBt6Ge1T7TB63V1CLWOpWQo=.0a71e980-fa0b-4e6c-822c-19adc39b59fc@github.com>
References: <x_8zkGG3mpXKunYI1FU4jBt6Ge1T7TB63V1CLWOpWQo=.0a71e980-fa0b-4e6c-822c-19adc39b59fc@github.com>
Message-ID: <0HKJGT5oBc0XIgHs5gkUjBlHFJvOkeiY2xL_-LZWwiM=.550fa6af-0ac6-43b2-846f-b5ef3cec339d@github.com>

On Fri, 4 Dec 2020 14:44:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> We have historically provided -mmacosx-version-min=10.9.0 flags when compiling and linking all our native executables and libraries on Macosx. That flag seems to have disappeared when linking libjvm. This is sometimes causing our macosx builds to not be able to run on older versions of macosx.

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1623


From dholmes at openjdk.java.net  Fri Dec  4 21:18:25 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 4 Dec 2020 21:18:25 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Looks good - 99% sym stuff :)

Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17.

src/hotspot/share/opto/type.cpp line 827:

> 825:     tty->print("this meet t = ");  mt->dump(); tty->cr();
> 826:     fatal("meet not commutative");
> 827:   }

Merge issue??

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226:

> 224:         REIFIABLE_TYPES_INSTANCEOF(JDK16, Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL),
> 225:         RECORDS(JDK16, Fragments.FeatureRecords, DiagKind.PLURAL),
> 226:         SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL),

Is this changed because it is still preview?

test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp line 27:

> 25: #include "precompiled.hpp"
> 26: 
> 27: #if defined(AARCH64) && !defined(ZERO)

Another merge issue.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From darcy at openjdk.java.net  Fri Dec  4 21:18:24 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Dec 2020 21:18:24 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
Message-ID: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>

Start of JDK 17 updates.

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

Commit messages:
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

Changes: https://git.openjdk.java.net/jdk/pull/1531/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257450
  Stats: 7522 lines in 76 files changed: 7463 ins; 0 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From darcy at openjdk.java.net  Fri Dec  4 21:18:26 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Dec 2020 21:18:26 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
Message-ID: <RS0Rrb2Y9eXAkmTK329-XMjyges2w0ZgdTC_SZ1wsUU=.56a864c4-eb3b-4377-9e50-cacba75bb09e@github.com>

On Tue, 1 Dec 2020 07:33:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226:
> 
>> 224:         REIFIABLE_TYPES_INSTANCEOF(JDK16, Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL),
>> 225:         RECORDS(JDK16, Fragments.FeatureRecords, DiagKind.PLURAL),
>> 226:         SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL),
> 
> Is this changed because it is still preview?

Right; JEP 397: "Sealed Classes (Second Preview)" is PTT for JDk 16.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From darcy at openjdk.java.net  Fri Dec  4 21:23:18 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Dec 2020 21:23:18 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
Message-ID: <aEIXWZVOaU_jBt6s_VlfTERREpWRy9qZsg_m6GOiimI=.961d6ffd-b55f-46a9-96ab-61b9c781ebdd@github.com>

On Tue, 1 Dec 2020 07:38:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Looks good - 99% sym stuff :)
> 
> Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17.

Usual start of release update:

* Expected version number updates in the make system
* New set of data files to support --release 16 in javac
* Update to various version-related langtools APIs and tests
* Minor N -> N+1 updates in vm and vm tests

One javadoc test that failed under the new version was fixed before this PR was sent out.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From erikj at openjdk.java.net  Fri Dec  4 21:38:11 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 21:38:11 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <5-1l9r81KZj0_g84xfhxSzfzrjggP8SzM1dpOkk5r_Q=.a8e26b00-c810-4458-abd7-131c92aeee02@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Build changes look good and I'm happy there are so few of them!

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1531


From erikj at openjdk.java.net  Fri Dec  4 21:44:14 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 21:44:14 GMT
Subject: Integrated: JDK-8257633: Missing -mmacosx-version-min=X flag when
 linking libjvm
In-Reply-To: <x_8zkGG3mpXKunYI1FU4jBt6Ge1T7TB63V1CLWOpWQo=.0a71e980-fa0b-4e6c-822c-19adc39b59fc@github.com>
References: <x_8zkGG3mpXKunYI1FU4jBt6Ge1T7TB63V1CLWOpWQo=.0a71e980-fa0b-4e6c-822c-19adc39b59fc@github.com>
Message-ID: <Jo5n_J6kcmRoVvSEQEMf5r6iAEK0vV9fUzUBFUiq4jk=.92b31953-0e65-447a-a961-6d73c4f54152@github.com>

On Fri, 4 Dec 2020 14:44:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> We have historically provided -mmacosx-version-min=10.9.0 flags when compiling and linking all our native executables and libraries on Macosx. That flag seems to have disappeared when linking libjvm. This is sometimes causing our macosx builds to not be able to run on older versions of macosx.

This pull request has now been integrated.

Changeset: 51d325e6
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51d325e6
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8257633: Missing -mmacosx-version-min=X flag when linking libjvm

Reviewed-by: mikael

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

PR: https://git.openjdk.java.net/jdk/pull/1623


From erikj at openjdk.java.net  Fri Dec  4 23:06:18 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 23:06:18 GMT
Subject: RFR: JDK-8257789: Fix incremental build of test-image and bundles
Message-ID: <mLL79BJY-PSoql444bHtEOlm49wAdE5N6U1Eo8svzvs=.141c8c42-6342-4c35-9fd6-644b9e028474@github.com>

When building the test-bundle incrementally, it always gets rebuilt. This is caused by the prepare-test-image target in TestImage.gmk, where we create a README file as part of a recipe for a PHONY target. This means that the README is always rebuilt, which in turn triggers downstream rebuilds. This is generally a bad pattern that should be avoided.

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

Commit messages:
 - Use target var in recipe
 - Move readme creation to its own target

Changes: https://git.openjdk.java.net/jdk/pull/1635/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1635&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257789
  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1635.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1635/head:pull/1635

PR: https://git.openjdk.java.net/jdk/pull/1635


From ihse at openjdk.java.net  Sat Dec  5 01:13:34 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Sat, 5 Dec 2020 01:13:34 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v7]
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Extract only the actual contents added to the PATH by VS SetEnv.cmd.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1597/files
  - new: https://git.openjdk.java.net/jdk/pull/1597/files/41cee7d1..ef81e1f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1597&range=05-06

  Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1597.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1597/head:pull/1597

PR: https://git.openjdk.java.net/jdk/pull/1597


From iris at openjdk.java.net  Sat Dec  5 01:37:14 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 5 Dec 2020 01:37:14 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <Qm7rFfBjXUwEryKrvSlMVO8ojj1onPhfGGGo9kVze14=.6ffd9c05-f2c9-406f-a004-a549e7591437@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From dlsmith at openjdk.java.net  Sat Dec  5 01:52:21 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 5 Dec 2020 01:52:21 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
Message-ID: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>

Integration of JEP 390, addressing the following issues:

8252180: [JEP 390] Deprecate wrapper class constructors for removal
8254047: [JEP 390] Revise "value-based class" & apply to wrappers
8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased
8252183: [JEP 390] Add 'lint' warning for @ValueBased classes
8257027: [JEP 390] Diagnose synchronization on @ValueBased classes

See https://github.com/openjdk/valhalla/tree/jep390 for development history.

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

Commit messages:
 - Merge
 - 8257776: [valhalla:jep390] Add disclaimer about future changes to value-based classes
 - 8254275: [valhalla/jep390] Revise "value-based class" & apply to wrappers
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes
 - Merge
 - 8256663: [test] Deprecated use of new Double in jshell ImportTest
 - 8253962: Add @ValueBased to unmodifable Collection implementation classes
 - 8256002: Cleanup of Wrapper changes
 - Merge
 - 8254271: Development to deprecate wrapper class constructors for removal
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/93b6ab56...7c5e5bfe

Changes: https://git.openjdk.java.net/jdk/pull/1636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1636&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252180
  Stats: 902 lines in 114 files changed: 489 ins; 121 del; 292 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1636/head:pull/1636

PR: https://git.openjdk.java.net/jdk/pull/1636


From dlsmith at openjdk.java.net  Sat Dec  5 03:07:11 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 5 Dec 2020 03:07:11 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <ame4i0yLoLSpT6rwqcO20lQzYRBLR9FiyD7EKHAKltA=.b12c8d8b-e470-45df-bb0c-1f7330be9545@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal
> - Revise "value-based class" & apply to wrappers
> - Define & apply annotation jdk.internal.ValueBased
> - Add 'lint' warning for @ValueBased classes
> - Diagnose synchronization on @ValueBased classes
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

I've updated the description to provide an overview for those unfamiliar with this work. Reviewers are welcome, including those who have previously reviewed a subset of these changes.

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

PR: https://git.openjdk.java.net/jdk/pull/1636


From mikael at openjdk.java.net  Sat Dec  5 03:20:12 2020
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 5 Dec 2020 03:20:12 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Marked as reviewed by mikael (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From david.holmes at oracle.com  Sat Dec  5 05:22:10 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 5 Dec 2020 15:22:10 +1000
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <YCsP7qJXNzgw5XjQcgIY4Dk1KlO5pRJYqcNYOvVi16g=.abeaf05c-2a50-46d7-a68d-b9d7c57a96a9@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <YCsP7qJXNzgw5XjQcgIY4Dk1KlO5pRJYqcNYOvVi16g=.abeaf05c-2a50-46d7-a68d-b9d7c57a96a9@github.com>
Message-ID: <e46b3c80-5d01-9037-cc6a-684479be7bcb@oracle.com>

Hi Erik,

On 4/12/2020 12:07 am, Erik Joelsson wrote:
> On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>>
>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
>>
>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
>>
>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
>>
>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
>>
>> A CSR request has been filed.
>>
>> Testing: hotspot/jtreg/runtime/signal tests
>>
>> Thanks,
>> David
> 
> make/modules/java.base/Lib.gmk line 131:
> 
>> 129: ifeq ($(call isTargetOsType, unix), true)
>> 130:   ifeq ($(STATIC_BUILD), false)
>> 131:     LIBJSIG_CFLAGS += -DHOTSPOT_VM_DISTRO='"$(HOTSPOT_VM_DISTRO)"'
> 
> In general, I would prefer if a flag like this was just inlined in the SetupJdkLibrary call, as there are no complex conditionals for setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is dead and not set anywhere in the build, so could also just be removed and replaced with your new -D flag.

I thought about just inlining it but it seemed "obvious" that 
LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it 
there - taking care to expand it in case it was set directly on the 
command-line. It also followed what is done for LIBJLI_CFLAGS.

I can change it if you insist but this code will be very short-lived as 
I can remove it again in 17 once I no longer need the deprecation warning.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1587
> 


From david.holmes at oracle.com  Sat Dec  5 05:27:10 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 5 Dec 2020 15:27:10 +1000
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>
Message-ID: <914d5630-fd3e-7f1e-25ca-f811a4a4a3a4@oracle.com>

On 4/12/2020 12:42 am, Daniel D.Daugherty wrote:
> On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>>
>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
>>
>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
>>
>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
>>
>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
>>
>> A CSR request has been filed.
>>
>> Testing: hotspot/jtreg/runtime/signal tests
>>
>> Thanks,
>> David
> 
> Thumbs up on the jsig.c change. No comment on the Lib.gmk change.

Thanks for the review Dan!

David


> -------------
> 
> Marked as reviewed by dcubed (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/1587
> 


From stuefe at openjdk.java.net  Sat Dec  5 15:26:11 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 5 Dec 2020 15:26:11 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>
Message-ID: <yU3Idh2yzLfftjm-w3u6ShFNgI7SkzFp_eFKx6b6irU=.44750925-90b7-4cb9-a298-384deded733d@github.com>

On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
>> 
>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>> 
>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
>> 
>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
>> 
>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
>> 
>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
>> 
>> A CSR request has been filed.
>> 
>> Testing: hotspot/jtreg/runtime/signal tests
>> 
>> Thanks,
>> David
>
> Thumbs up on the jsig.c change. No comment on the Lib.gmk change.

Hi David,

I am fine with this, but since this is possibly a breaking change would this not need a release note?

..Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/1587


From david.holmes at oracle.com  Sun Dec  6 10:12:33 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 6 Dec 2020 20:12:33 +1000
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <yU3Idh2yzLfftjm-w3u6ShFNgI7SkzFp_eFKx6b6irU=.44750925-90b7-4cb9-a298-384deded733d@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>
 <yU3Idh2yzLfftjm-w3u6ShFNgI7SkzFp_eFKx6b6irU=.44750925-90b7-4cb9-a298-384deded733d@github.com>
Message-ID: <1b51b51d-5e2b-5742-c586-a8d6a6671fd3@oracle.com>

Hi Thomas,

On 6/12/2020 1:26 am, Thomas Stuefe wrote:
> On Thu, 3 Dec 2020 14:40:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:
> 
>>> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
>>>
>>> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
>>>
>>> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
>>>
>>> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
>>>
>>> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
>>>
>>> A CSR request has been filed.
>>>
>>> Testing: hotspot/jtreg/runtime/signal tests
>>>
>>> Thanks,
>>> David
>>
>> Thumbs up on the jsig.c change. No comment on the Lib.gmk change.
> 
> Hi David,
> 
> I am fine with this, but since this is possibly a breaking change would this not need a release note?

Well it isn't breaking anything at this stage as we are just issuing a 
deprecation warning. :) But yes I have filed a release note as well.

Thanks,
David

> ..Thomas
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1587
> 


From stuefe at openjdk.java.net  Sun Dec  6 10:26:14 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sun, 6 Dec 2020 10:26:14 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <yU3Idh2yzLfftjm-w3u6ShFNgI7SkzFp_eFKx6b6irU=.44750925-90b7-4cb9-a298-384deded733d@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <PvCk8E1lvMUx6uG95jyDcUCz3Z7BF-QuqdBPhRIDVZY=.41ff7966-9264-4024-a21e-6d89c11d477b@github.com>
 <yU3Idh2yzLfftjm-w3u6ShFNgI7SkzFp_eFKx6b6irU=.44750925-90b7-4cb9-a298-384deded733d@github.com>
Message-ID: <1slEjsG2houlKUZGV24e4J3PrNEIFVZco4-5rvcUD_Y=.2869ceb6-1d9f-4110-a941-d41cdc10c0a7@github.com>

On Sat, 5 Dec 2020 15:23:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thumbs up on the jsig.c change. No comment on the Lib.gmk change.
>
> Hi David,
> 
> I am fine with this, but since this is possibly a breaking change would this not need a release note?
> 
> ..Thomas

> > 
> > Hi David,
> > I am fine with this, but since this is possibly a breaking change would this not need a release note?
> 
> Well it isn't breaking anything at this stage as we are just issuing a
> deprecation warning. :) But yes I have filed a release note as well.
> 
> Thanks,
> David

Hi David,

:) Thanks. The warning might elude customers until JDK17 comes around and things stop working. With signal chaining being out of scope for the typical java consultant, the expertise may have gone so customers may need to look for someone changing and recompiling their native solution. Or bug vendors to do so.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/1587


From mgronlun at openjdk.java.net  Sun Dec  6 13:37:03 2020
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 6 Dec 2020 13:37:03 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default) [v2]
In-Reply-To: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
Message-ID: <f1FMPaRO8Sykya6eSlUicMd_5DO0tcv8yJDs-akvAME=.967629fd-56ce-4d61-82c6-c7d1d1ed542f@github.com>

> Greetings,
> 
> please help review this enhancement to let JFR sample object allocations by default.
> 
> A description is provided in the JIRA issue.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  General ObjectAllocationSample event definition

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1624/files
  - new: https://git.openjdk.java.net/jdk/pull/1624/files/dba878aa..196d254d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=00-01

  Stats: 23 lines in 2 files changed: 0 ins; 18 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1624/head:pull/1624

PR: https://git.openjdk.java.net/jdk/pull/1624


From mgronlun at openjdk.java.net  Sun Dec  6 21:03:05 2020
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 6 Dec 2020 21:03:05 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default) [v3]
In-Reply-To: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
Message-ID: <L6FcXhruKLoooKrw6toj0w-1yRTgGftRblhIVPCrS6g=.a08e2f94-2214-43ad-a1ed-efbac3e10610@github.com>

> Greetings,
> 
> please help review this enhancement to let JFR sample object allocations by default.
> 
> A description is provided in the JIRA issue.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  ObjectAllocationSample event definition with weight

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1624/files
  - new: https://git.openjdk.java.net/jdk/pull/1624/files/196d254d..6918f0c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=01-02

  Stats: 30 lines in 6 files changed: 3 ins; 11 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1624/head:pull/1624

PR: https://git.openjdk.java.net/jdk/pull/1624


From burban at openjdk.java.net  Mon Dec  7 08:52:16 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 7 Dec 2020 08:52:16 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v7]
In-Reply-To: <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>
Message-ID: <VbAjBno1a8Y62wEkNk5r2kbSkFeDiMmPH7-VvtnV12g=.c6337c53-32de-43f8-988f-e4c8c177d8d1@github.com>

On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
>> 
>> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
>> 
>> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
>> 
>> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract only the actual contents added to the PATH by VS SetEnv.cmd.

make/autoconf/boot-jdk.m4 line 66:

> 64:     if test "x$BOOT_JDK_FOUND" = xmaybe; then
> 65:       # Do we have a bin/java?
> 66:       if test ! -x "$BOOT_JDK/bin/java" && test ! -x "$BOOT_JDK/bin/java.exe"; then

`BOOTJDK_CHECK_BUILD_JDK` also needs those updates I believe

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From burban at openjdk.java.net  Mon Dec  7 09:41:17 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 7 Dec 2020 09:41:17 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v7]
In-Reply-To: <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>
Message-ID: <nNQF1c8GDZYcRED1zd0Odd5qQLW8alozBGyolgfT-rg=.a2cb6c7f-f61b-4f5b-8691-0c4693ae3782@github.com>

On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
>> 
>> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
>> 
>> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
>> 
>> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract only the actual contents added to the PATH by VS SetEnv.cmd.

Tested the cross compilation bits with a win-aarch64 build from win-x86_64:
- Cygwin: `--openjdk-target=aarch64-unknown-cygwin --with-boot-jdk=/cygdrive/c/work/jdk-16+22`
- WSL1: `--openjdk-target=aarch64-unknown-cygwin --with-boot-jdk=/mnt/c/work/jdk-16+22`

And smoke tested each one on win-aarch64 with `jtreg:tier1_compiler_1`.


Cosmetic: I get a bunch of warnings for non-existing paths in `$PATH` during configure on the wsl1 build, e.g.:
configure: Setting extracted environment variables for x86_64



I'll give the "native compilation" on win-aarch64 a try again when this change has landed. Some bits (e.g. config.guess) required for it have made it into this PR, but some things are still missing (e.g. choose x86 binaries for MSVC, since no native bits are available for MSVC).

Thank you for the hard work on this!

make/autoconf/toolchain_microsoft.m4 line 632:

> 630:       [path to Microsoft Windows Kit UCRT DLL dir (Windows only) @<:@probed@:>@])])
> 631: 
> 632:   if test "x$USE_UCRT" = "xtrue" && test "x$OPENJDK_TARGET_CPU" != xaarch64; then

?

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

Marked as reviewed by burban (Author).

PR: https://git.openjdk.java.net/jdk/pull/1597


From erik.joelsson at oracle.com  Mon Dec  7 13:35:34 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 7 Dec 2020 05:35:34 -0800
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <e46b3c80-5d01-9037-cc6a-684479be7bcb@oracle.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <YCsP7qJXNzgw5XjQcgIY4Dk1KlO5pRJYqcNYOvVi16g=.abeaf05c-2a50-46d7-a68d-b9d7c57a96a9@github.com>
 <e46b3c80-5d01-9037-cc6a-684479be7bcb@oracle.com>
Message-ID: <79401edc-2a12-4cb2-91d0-7a9b2e99887f@oracle.com>


On 2020-12-04 21:22, David Holmes wrote:
> Hi Erik,
>
> On 4/12/2020 12:07 am, Erik Joelsson wrote:
>>
>> In general, I would prefer if a flag like this was just inlined in 
>> the SetupJdkLibrary call, as there are no complex conditionals for 
>> setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is 
>> dead and not set anywhere in the build, so could also just be removed 
>> and replaced with your new -D flag.
>
> I thought about just inlining it but it seemed "obvious" that 
> LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it 
> there - taking care to expand it in case it was set directly on the 
> command-line. It also followed what is done for LIBJLI_CFLAGS.
>
> I can change it if you insist but this code will be very short-lived 
> as I can remove it again in 17 once I no longer need the deprecation 
> warning.
>
If you think there is a case for overriding this on the command line, 
then sure, we can keep it. From what I can see, this is just a left over 
from when some more complicated logic was needed, or these flags needed 
to be reused somewhere else. In the case of libjli, we reuse the flags 
in several different versions of the SetupJdkLibrary call for libjli. 
That said, I won't insist strongly on this.

/Erik




From erikj at openjdk.java.net  Mon Dec  7 13:41:12 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Dec 2020 13:41:12 GMT
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
Message-ID: <GfJMYGDdbBgsYGseVBwTvFs9nA7uA_ObUwmRyik_DOE=.ad6ec129-6c09-4896-abc2-9d79dbc53dc8@github.com>

On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> 
> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
> 
> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
> 
> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
> 
> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
> 
> A CSR request has been filed.
> 
> Testing: hotspot/jtreg/runtime/signal tests
> 
> Thanks,
> David

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1587


From ihse at openjdk.java.net  Mon Dec  7 14:27:45 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:27:45 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move to share/data, and move jdwp.spec to java.se

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/8e775e40..f0047704

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=00-01

  Stats: 56 lines in 1565 files changed: 1 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Mon Dec  7 14:28:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:28:06 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
 <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
 <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>
Message-ID: <kxhbRD192TEhTH1lD3HBgly5Z1cKWEwKwyQLH88LCQc=.527bba0f-bf8c-4a11-a95d-228d628f5d91@github.com>

On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.
> 
> Rendered as markdown, it would look somewhat like this:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.

I hope I understood the purpose of the `lib` directory correctly. Our only instance of this is for `java.base/*/lib/security/default.policy`.

I also noted that jdk.hotspot.agent violates this scheme by having a top-level `test` and `doc` directories, apart from `share` and the OS directories. The purposes of these two directories are not clear to me. The tests in `test` are definitely never executed. I don't know if this is an omission, or if they should be removed. The documentation in `doc` is not exported to the end product, nor is it references in any developer documentation. That too should either be removed, or moved to a more suitable home.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Mon Dec  7 14:28:05 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:28:05 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
 <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
Message-ID: <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>

On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?
>
> @erikj79 Good point, that makes much more sense.

I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:

    src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*
                            legal/*
                            data/*
                            man/*
                            lib/*

where:

  - $MODULE is a module name (_e.g._, `java.base`);

  - The `share` directory contains shared, cross-platform code, as
    before;

  - The `$OS` directory contains operating-system-specific code, as
    before, where `$OS` is one of `unix`, `windows`, _etc._;

  - The `classes` directory contains Java source files and resource files
    organized into a directory tree reflecting their API `$PACKAGE`
    hierarchy, as before;

  - The `native` directory contains C or C++ source files, as before but
    organized differently:

    - The `include` directory contains C or C++ header files intended to
      be exported for external use (_e.g._, `jni.h`);

    - C or C++ source files are placed in a `$LIBRARY` directory, whose
      name is that of the shared library or DLL into which the compiled
      code will be linked (_e.g._, `libjava` or `libawt`); and, finally,

  - The `conf` directory contains configuration files meant to be edited
    by end users (_e.g._, `net.properties`).

  - The `legal` directory contains legal notices.

  - The `data` directory contains data files needed for building the module.

  - The `man` directory contains man pages in nroff or markdown format.

  - The `lib` directory contains configuration files not meant to be edited
    by end users.

Rendered as markdown, it would look somewhat like this:

    src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*
                            legal/*
                            data/*
                            man/*
                            lib/*

where:

  - $MODULE is a module name (_e.g._, `java.base`);

  - The `share` directory contains shared, cross-platform code, as
    before;

  - The `$OS` directory contains operating-system-specific code, as
    before, where `$OS` is one of `unix`, `windows`, _etc._;

  - The `classes` directory contains Java source files and resource files
    organized into a directory tree reflecting their API `$PACKAGE`
    hierarchy, as before;

  - The `native` directory contains C or C++ source files, as before but
    organized differently:

    - The `include` directory contains C or C++ header files intended to
      be exported for external use (_e.g._, `jni.h`);

    - C or C++ source files are placed in a `$LIBRARY` directory, whose
      name is that of the shared library or DLL into which the compiled
      code will be linked (_e.g._, `libjava` or `libawt`); and, finally,

  - The `conf` directory contains configuration files meant to be edited
    by end users (_e.g._, `net.properties`).

  - The `legal` directory contains legal notices.

  - The `data` directory contains data files needed for building the module.

  - The `man` directory contains man pages in nroff or markdown format.

  - The `lib` directory contains configuration files not meant to be edited
    by end users.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From erikj at openjdk.java.net  Mon Dec  7 14:32:12 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 7 Dec 2020 14:32:12 GMT
Subject: RFR: 8257679: Improved unix compatibility layer in Windows build
 (winenv) [v7]
In-Reply-To: <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
 <uuC2XzUYrruhQ8Yga1BsKYpAttqXvmKv29GVCV8Mhtg=.6e3c8fd7-4f3a-4419-bbd9-f6b3a3bd9823@github.com>
Message-ID: <pJKRe2fe79VpRXR84SVWoT7R_QNS075XHrULXpkvt7I=.3c3600a3-c015-4722-8ac3-eb7a23dfbbd3@github.com>

On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
>> 
>> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
>> 
>> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
>> 
>> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract only the actual contents added to the PATH by VS SetEnv.cmd.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From tbell at openjdk.java.net  Mon Dec  7 14:39:10 2020
From: tbell at openjdk.java.net (Tim Bell)
Date: Mon, 7 Dec 2020 14:39:10 GMT
Subject: RFR: JDK-8257789: Fix incremental build of test-image and bundles
In-Reply-To: <mLL79BJY-PSoql444bHtEOlm49wAdE5N6U1Eo8svzvs=.141c8c42-6342-4c35-9fd6-644b9e028474@github.com>
References: <mLL79BJY-PSoql444bHtEOlm49wAdE5N6U1Eo8svzvs=.141c8c42-6342-4c35-9fd6-644b9e028474@github.com>
Message-ID: <dMVBYkK2bZISjZ8Dffp_jO-3--ctosiQ1076aEtbT7c=.74f25ba3-a67d-4738-a1b4-100022ef5b96@github.com>

On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When building the test-bundle incrementally, it always gets rebuilt. This is caused by the prepare-test-image target in TestImage.gmk, where we create a README file as part of a recipe for a PHONY target. This means that the README is always rebuilt, which in turn triggers downstream rebuilds. This is generally a bad pattern that should be avoided.

Looks good.

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

Marked as reviewed by tbell (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1635


From rriggs at openjdk.java.net  Mon Dec  7 15:08:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 7 Dec 2020 15:08:12 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <Fl-cWTaz17dK2mrEvx318D5ScjkL-up3gtWVzo9x9d4=.83b8febf-1f03-43f6-b836-b44c648e5801@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal (rriggs)
> - Revise "value-based class" & apply to wrappers (dlsmith)
> - Define & apply annotation jdk.internal.ValueBased (rriggs)
> - Add 'lint' warning for @ValueBased classes (sadayapalam)
> - Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

For the core libraries parts looks ok.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1636


From hseigel at openjdk.java.net  Mon Dec  7 15:53:14 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 7 Dec 2020 15:53:14 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <DBXljSbfnxVvTWaB3vWYuroiHOTlz8ZVqocZR4JffNw=.1fbca489-56da-4190-ad5a-2fd42512ff59@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal (rriggs)
> - Revise "value-based class" & apply to wrappers (dlsmith)
> - Define & apply annotation jdk.internal.ValueBased (rriggs)
> - Add 'lint' warning for @ValueBased classes (sadayapalam)
> - Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

The hotspot changes look good.  In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent.  Currently, it only tests primitive classes.

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

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1636


From ihse at openjdk.java.net  Mon Dec  7 16:00:16 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 16:00:16 GMT
Subject: Integrated: 8257679: Improved unix compatibility layer in Windows
 build (winenv)
In-Reply-To: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
References: <-Z68txK4QoA01Gc3WkmO75osOXM52uaOln53uv1IT_0=.3efdca4b-a3bc-49a7-8904-f849a9378308@github.com>
Message-ID: <3edROHaKuVT2N0OU_YU8meDTDL2zLsO1UzwycxKRi8o=.a8d37c57-2977-49d0-8792-3acea2966778@github.com>

On Thu, 3 Dec 2020 14:19:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For the build to work on Windows, we need a unix compatibility layer (known as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The build system then needs to adapt various aspect to get the build to work in this winenv. Over time, our current solutions (which were never that well-designed) has collapsed into an unmaintainable mess.
> 
> This rewrite takes on a fresh approach, by giving up on the native "fixpath.exe" converter, and instead relying on a platform-independent shell script "fixpath.sh", which can dynamically adapt to the current winenv. It also provides a proper framework on how to categorize, and support, different winenvs. As a result, we now easily support Cygwin, Msys2, WSL1 and WSL2 (the latter is unfortunately not mature enough to be able to compile the JDK).
> 
> Furthermore, this rewrite removes all the kludges and hacks that were put in place all over the code base, and consolidates all tricky part of handling the winenv to basically two places: setting up in configure, and run-time handling by fixpath.sh.
> 
> This patch also cleans up our handling of how we detect tools in configure, and makes a proper framework for cross-compilation on Windows.

This pull request has now been integrated.

Changeset: d29c78da
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d29c78da
Stats:     4737 lines in 50 files changed: 1908 ins; 2492 del; 337 mod

8257679: Improved unix compatibility layer in Windows build (winenv)

Reviewed-by: erikj, jvernee, burban

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

PR: https://git.openjdk.java.net/jdk/pull/1597


From jlahoda at openjdk.java.net  Mon Dec  7 16:13:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 16:13:13 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>
Message-ID: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com>

On Sat, 5 Dec 2020 03:17:56 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Marked as reviewed by mikael (Reviewer).

The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these may need an update. Sorry about that.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From lfoltan at openjdk.java.net  Mon Dec  7 16:25:13 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 7 Dec 2020 16:25:13 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <DBXljSbfnxVvTWaB3vWYuroiHOTlz8ZVqocZR4JffNw=.1fbca489-56da-4190-ad5a-2fd42512ff59@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
 <DBXljSbfnxVvTWaB3vWYuroiHOTlz8ZVqocZR4JffNw=.1fbca489-56da-4190-ad5a-2fd42512ff59@github.com>
Message-ID: <daRqe8BueKkQgPH9tjRo4guncvyjbw6wdG6szQDOXgY=.be84a3cc-ec84-47c6-8633-19206ee7525b@github.com>

On Mon, 7 Dec 2020 15:50:55 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
>> 
>> Development has been broken into 5 tasks, each with its own JBS issue:
>> - Deprecate wrapper class constructors for removal (rriggs)
>> - Revise "value-based class" & apply to wrappers (dlsmith)
>> - Define & apply annotation jdk.internal.ValueBased (rriggs)
>> - Add 'lint' warning for @ValueBased classes (sadayapalam)
>> - Diagnose synchronization on @ValueBased classes (lfoltan)
>> 
>> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
>> 
>> CSRs have also been completed or are nearly complete:
>> 
>> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
>> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
>> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
>> 
>> Here's an overview of the files changed:
>> 
>> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
>> 
>> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
>> 
>> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
>> 
>> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
>> 
>> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
>> 
>> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
>> 
>> - `src/java.management.rmi`: removing uses of wrapper class constructors.
>> 
>> - `src/java.xml`: removing uses of wrapper class constructors.
>> 
>> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
>> 
>> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
>> 
>> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
>> 
>> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
>> 
>> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.
>
> The hotspot changes look good.  In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent.  Currently, it only tests primitive classes.

@hseigel thank you for the review.  I have created https://bugs.openjdk.java.net/browse/JDK-8257836 as an RFE to address additional testing.
Lois

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

PR: https://git.openjdk.java.net/jdk/pull/1636


From burban at openjdk.java.net  Mon Dec  7 19:31:25 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 7 Dec 2020 19:31:25 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v3]
In-Reply-To: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
Message-ID: <s6JKXXHjBmzsxjDNBjeJbzBX9alFyXE4-lPMAqvC0VA=.faa469b2-d216-44eb-8514-444f71a8ed39@github.com>

> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
> 
> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
> 
> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.

Bernhard Urban-Forster has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - change default target to hotspot and align with updated x64 bits
 - remove devkit usage on win-aarch64
 - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
 - todo note for caching devkit
 - remove release build
 - move windows_aarch64_build next to other builds
 - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
 - remove fixpath.exe workaround
 - 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow
   
   This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
   
   Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
   
   Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.

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

Changes: https://git.openjdk.java.net/jdk/pull/1379/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1379&range=02
  Stats: 119 lines in 1 file changed: 117 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1379.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1379/head:pull/1379

PR: https://git.openjdk.java.net/jdk/pull/1379


From burban at openjdk.java.net  Mon Dec  7 19:34:26 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Mon, 7 Dec 2020 19:34:26 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v4]
In-Reply-To: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
Message-ID: <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>

> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
> 
> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
> 
> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.

Bernhard Urban-Forster has updated the pull request incrementally with one additional commit since the last revision:

  merge mistakes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1379/files
  - new: https://git.openjdk.java.net/jdk/pull/1379/files/34d1ea24..4a1e08d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1379&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1379&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1379.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1379/head:pull/1379

PR: https://git.openjdk.java.net/jdk/pull/1379


From jjg at openjdk.java.net  Mon Dec  7 19:35:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:35:17 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

I have reviewed all lines in the patch file with or near instances of `jdk.compiler`

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From darcy at openjdk.java.net  Mon Dec  7 19:38:41 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 19:38:41 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/4187d66f..f6a64473

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=00-01

  Stats: 12681 lines in 254 files changed: 8255 ins; 3285 del; 1141 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From darcy at openjdk.java.net  Mon Dec  7 19:50:16 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 19:50:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>
 <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com>
Message-ID: <7YT7teNjF9GmNGWPa_u40xyn_BGgZdxNhcjls6u1Hjs=.5d7bad6b-12ad-4d20-a8ad-d31a74c7a392@github.com>

On Mon, 7 Dec 2020 16:10:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 
> 
> The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these may need an update. Sorry about that.

After a merge, the tests in that directory still pass. Will keep merging in new changes and do at least more more test run before pushing. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From jjg at openjdk.java.net  Mon Dec  7 20:18:16 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 20:18:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
Message-ID: <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>

On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - JDK-8257450
>  - JDK-8257450

I've read all the files, and approve all the langtools related ones (i.e. not hotspot)
As you've noticed elsewhere, there's a pending conflict with Magnus' work to move files around.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 108:

> 106: 
> 107:     /**
> 108:       * 16, tbd

The "tbd" can presumably be filled in now

test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:

> 105:                 { 61,   0,  Set.of(STATIC, TRANSITIVE) },
> 106: 
> 107:                 { 62,   0,  Set.of()},                       // JDK 18

This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release?

test/langtools/tools/javac/preview/classReaderTest/Client.preview.out line 1:

> 1: - compiler.warn.preview.feature.use.classfile: Bar.class, 17

Is this a test can could be automated? (i.e. no manual change per release?)

test/langtools/tools/javac/versions/Versions.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545 8000961 8030610 8028546 8188870 8173382 8173382 8193290 8205619 8028563 8245147 8245586 8257453

long lines are annoying

test/langtools/tools/javac/versions/Versions.java line 297:

> 295:        expectedPass(args, List.of("New7.java", "New8.java", "New10.java", "New11.java",
> 296:                                   "New14.java", "New15.java"));
> 297:         expectedFail(args, List.of("New16.java"));

(minor) looks like bad indentation

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1531


From jlahoda at openjdk.java.net  Mon Dec  7 20:18:21 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 20:18:21 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
Message-ID: <Jz0yzt0iCBxSsgO9i2wbb1KI9lMuphTnKtZv6CRxqFg=.c2b17566-f847-4b2e-8b3e-f04459e41157@github.com>

On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - JDK-8257450
>  - JDK-8257450

Marked as reviewed by jlahoda (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From jwilhelm at openjdk.java.net  Mon Dec  7 20:25:16 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 7 Dec 2020 20:25:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
Message-ID: <rp80Vgj0VdB_CsPictg1wkOOCE4WTZqNeU_-CLg1Y08=.c147742d-f902-4dc9-ae91-aeaff06294d5@github.com>

On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - JDK-8257450
>  - JDK-8257450

Marked as reviewed by jwilhelm (Reviewer).

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 234:

> 232:      * @since 17
> 233:      */
> 234:     RELEASE_17;

Would it make sense to have a RELEASE_LATEST for the cases that are just updated to the latest release every six months?

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From ihse at openjdk.java.net  Mon Dec  7 20:49:17 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 20:49:17 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v4]
In-Reply-To: <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>
Message-ID: <HgX893I_CDtTqxqen6UHVDRtnBpUXpZWlXIp3_TrY5I=.0cbe503c-7899-4b40-a947-54414c7d9ec1@github.com>

On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
>> 
>> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
>> 
>> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.
>
> Bernhard Urban-Forster has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge mistakes

This looks good now. It adds ~15 minutes of build time (and unfortunately ~10 minutes to download prereqs), which is quite acceptable.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1379


From darcy at openjdk.java.net  Mon Dec  7 21:20:14 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 21:20:14 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
 <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>
Message-ID: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com>

On Mon, 7 Dec 2020 20:08:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8257450
>>  - Update tests.
>>  - Merge branch 'master' into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>
> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:
> 
>> 105:                 { 61,   0,  Set.of(STATIC, TRANSITIVE) },
>> 106: 
>> 107:                 { 62,   0,  Set.of()},                       // JDK 18
> 
> This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release?

I've had similar thoughts; that strikes me as a fine RFE for after this fork. I see what the code is doing, but haven't delved into the module system details to understand exactly the rationale for these tests. In any case, filed the RFE JDK-8257856: "Make ClassFileVersionsTest.java robust to JDK version updates."

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From david.holmes at oracle.com  Mon Dec  7 21:52:12 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 8 Dec 2020 07:52:12 +1000
Subject: RFR: 8257572: Deprecate the archaic signal-chaining interfaces:
 sigset and signal
In-Reply-To: <79401edc-2a12-4cb2-91d0-7a9b2e99887f@oracle.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
 <YCsP7qJXNzgw5XjQcgIY4Dk1KlO5pRJYqcNYOvVi16g=.abeaf05c-2a50-46d7-a68d-b9d7c57a96a9@github.com>
 <e46b3c80-5d01-9037-cc6a-684479be7bcb@oracle.com>
 <79401edc-2a12-4cb2-91d0-7a9b2e99887f@oracle.com>
Message-ID: <f4470ae6-2d83-0a9d-5fe0-f25a39bf5b91@oracle.com>

On 7/12/2020 11:35 pm, Erik Joelsson wrote:
> 
> On 2020-12-04 21:22, David Holmes wrote:
>> Hi Erik,
>>
>> On 4/12/2020 12:07 am, Erik Joelsson wrote:
>>>
>>> In general, I would prefer if a flag like this was just inlined in 
>>> the SetupJdkLibrary call, as there are no complex conditionals for 
>>> setting it. Looking a bit further, the variable LIBJSIG_CFLAGS is 
>>> dead and not set anywhere in the build, so could also just be removed 
>>> and replaced with your new -D flag.
>>
>> I thought about just inlining it but it seemed "obvious" that 
>> LIBJSIG_CFLAGS existed exactly for this purpose, so I simply set it 
>> there - taking care to expand it in case it was set directly on the 
>> command-line. It also followed what is done for LIBJLI_CFLAGS.
>>
>> I can change it if you insist but this code will be very short-lived 
>> as I can remove it again in 17 once I no longer need the deprecation 
>> warning.
>>
> If you think there is a case for overriding this on the command line, 
> then sure, we can keep it. From what I can see, this is just a left over 
> from when some more complicated logic was needed, or these flags needed 
> to be reused somewhere else. In the case of libjli, we reuse the flags 
> in several different versions of the SetupJdkLibrary call for libjli. 
> That said, I won't insist strongly on this.

Thanks Erik I appreciate that as I just want to get this pushed ASAP.

David

> /Erik
> 
> 


From dholmes at openjdk.java.net  Mon Dec  7 21:59:12 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 7 Dec 2020 21:59:12 GMT
Subject: Integrated: 8257572: Deprecate the archaic signal-chaining
 interfaces: sigset and signal
In-Reply-To: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
References: <XBHjXOEVFwYZddR54QOji0giKNN80HYMqFo-m_53H54=.251e05f4-e254-4596-8a0b-a168d69b0b7b@github.com>
Message-ID: <PTPFP7hg9AULS99dWtL3RGMbcScW0e61LnM-BrJqlzw=.d8dadf85-411e-4cc8-bc93-d86139e2c7e4@github.com>

On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and supported three different Linux signal API's: sigset, signal and sigaction:
> 
> https://docs.oracle.com/javase/8/docs/technotes/guides/vm/signal-chaining.html
> 
> Only sigaction is a Posix supported API for multi-threaded processes, that we can use cross-platform. Both signal and sigset are obsolete and have undefined behaviour in a multi-threaded process. From the Linux man pages:
> 
> sigset: This API is obsolete: new applications should use the POSIX signal API (sigaction(2), sigprocmask(2), etc.)
> 
> signal: The behavior of signal() varies across UNIX versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead.
> 
> We should deprecate the use of signal and sigset in JDK 16 with a view to their removal in JDK 17.
> 
> A CSR request has been filed.
> 
> Testing: hotspot/jtreg/runtime/signal tests
> 
> Thanks,
> David

This pull request has now been integrated.

Changeset: 149a02f9
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/149a02f9
Stats:     7 lines in 2 files changed: 7 ins; 0 del; 0 mod

8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal

Reviewed-by: ihse, alanb, dcubed, erikj

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

PR: https://git.openjdk.java.net/jdk/pull/1587


From darcy at openjdk.java.net  Mon Dec  7 22:44:17 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 22:44:17 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <rp80Vgj0VdB_CsPictg1wkOOCE4WTZqNeU_-CLg1Y08=.c147742d-f902-4dc9-ae91-aeaff06294d5@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
 <rp80Vgj0VdB_CsPictg1wkOOCE4WTZqNeU_-CLg1Y08=.c147742d-f902-4dc9-ae91-aeaff06294d5@github.com>
Message-ID: <UtJBi5TfjEl2UGdNSgwEZeb4GKeLi0HEWr6US7Pe52s=.a71a3b90-85d4-4b65-a351-5474064c8bb3@github.com>

On Mon, 7 Dec 2020 20:20:58 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8257450
>>  - Update tests.
>>  - Merge branch 'master' into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 234:
> 
>> 232:      * @since 17
>> 233:      */
>> 234:     RELEASE_17;
> 
> Would it make sense to have a RELEASE_LATEST for the cases that are just updated to the latest release every six months?

That kind of design was considered and rejected with the API was initially added. The use of enum constants in annotations must be an actual enum constant, not just a static final field pointing to a particular enum value. It would be possible to conceptually alias RELEASE_LATEST with whatever actual constant was the latest (16, then 17, then 18...), but that would cause issues with other uses of the API.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From ihse at openjdk.java.net  Tue Dec  8 01:40:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 01:40:12 GMT
Subject: RFR: JDK-8257789: Fix incremental build of test-image and bundles
In-Reply-To: <mLL79BJY-PSoql444bHtEOlm49wAdE5N6U1Eo8svzvs=.141c8c42-6342-4c35-9fd6-644b9e028474@github.com>
References: <mLL79BJY-PSoql444bHtEOlm49wAdE5N6U1Eo8svzvs=.141c8c42-6342-4c35-9fd6-644b9e028474@github.com>
Message-ID: <lrNWsRGz4mc5yCwSBUtqnGoSEhArLovuxox6TC2asA4=.c5b7b7ba-f1d6-4ad7-ae46-68e479f29c1d@github.com>

On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When building the test-bundle incrementally, it always gets rebuilt. This is caused by the prepare-test-image target in TestImage.gmk, where we create a README file as part of a recipe for a PHONY target. This means that the README is always rebuilt, which in turn triggers downstream rebuilds. This is generally a bad pattern that should be avoided.

Marked as reviewed by ihse (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1635


From mchung at openjdk.java.net  Tue Dec  8 02:43:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 02:43:19 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
Message-ID: <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>

On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`

Hi Magnus,

I see the motivation of moving these build files for better identification of ownership.   Placing them under
`src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From darcy at openjdk.java.net  Tue Dec  8 03:33:31 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 03:33:31 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v3]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <tRUP2fV-wQaGbVthcyNveUMh91W74e_w9llIA-cpJnk=.054f9e97-3bbf-426f-a8a8-8050b7b6fae2@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/f6a64473..96e75b08

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=01-02

  Stats: 851 lines in 29 files changed: 560 ins; 163 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From minqi at openjdk.java.net  Tue Dec  8 05:45:20 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 8 Dec 2020 05:45:20 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <TguKP3F3tuAgdzImLvrt5s35nBTy1w6msEIGYNmWsq8=.0c36bee0-a2d6-48c0-84a8-a60b31e1df28@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request incrementally with 32 additional commits since the last revision:

 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - 8257805: Add compiler/blackhole tests to tier1
   
   Reviewed-by: kvn
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/dd9ae050...f7958306

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1657/files
  - new: https://git.openjdk.java.net/jdk/pull/1657/files/dd9ae050..f7958306

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=01-02

  Stats: 8052 lines in 156 files changed: 4548 ins; 2755 del; 749 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

PR: https://git.openjdk.java.net/jdk/pull/1657


From darcy at openjdk.java.net  Tue Dec  8 06:12:35 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 06:12:35 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v4]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <xrNV9DXjcpcs6lplCqKzf84x6PGIA4K0Dw2XP64ufAY=.df6f2f6a-13ad-4a77-a21b-006d70cc72b7@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/96e75b08..342c8650

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From shade at openjdk.java.net  Tue Dec  8 07:02:14 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Dec 2020 07:02:14 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v4]
In-Reply-To: <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>
Message-ID: <mdjmAEpxmagFq7e6N6y90XV8chqFADBAMX_faj78wSE=.87234f5b-a563-4304-b82e-d290a19d4e6f@github.com>

On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
>> 
>> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
>> 
>> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.
>
> Bernhard Urban-Forster has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge mistakes

Minor nits.

.github/workflows/submit.yml line 954:

> 952:           --with-boot-jdk="$env:BOOT_JDK"
> 953:           --with-jtreg="$env:JT_HOME"
> 954:           --with-gtest="$env:GTEST"

Ditto for `--with-jtreg`, `--with-gtest`.

.github/workflows/submit.yml line 956:

> 954:           --with-gtest="$env:GTEST"
> 955:           --with-default-make-target="hotspot"
> 956:           --enable-jtreg-failure-handler

Ditto for `--enable-jtreg-failure-handler`.

.github/workflows/submit.yml line 930:

> 928:           name: transient_jtreg_${{ needs.prerequisites.outputs.bundle_id }}
> 929:           path: ~/jtreg/
> 930:         if: steps.jtreg_restore.outcome == 'failure'

Since we are not running tests, and only build hotspot, we can skip jtreg and gtest additions in this job. Saves a few cycles? This would be similar to what "Linux additional" does.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1379


From shade at openjdk.java.net  Tue Dec  8 07:02:15 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Dec 2020 07:02:15 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v4]
In-Reply-To: <mdjmAEpxmagFq7e6N6y90XV8chqFADBAMX_faj78wSE=.87234f5b-a563-4304-b82e-d290a19d4e6f@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>
 <mdjmAEpxmagFq7e6N6y90XV8chqFADBAMX_faj78wSE=.87234f5b-a563-4304-b82e-d290a19d4e6f@github.com>
Message-ID: <8daExVszcK5qLhWmLys3tRdEKpoyyaSuEDLPSGLE4sc=.031c3e04-c404-4ad0-84a1-1bb3b25662a6@github.com>

On Tue, 8 Dec 2020 06:58:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Bernhard Urban-Forster has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge mistakes
>
> Minor nits.

Also merge from master to get the clean workflow run everywhere?

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

PR: https://git.openjdk.java.net/jdk/pull/1379


From alanb at openjdk.java.net  Tue Dec  8 07:48:13 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 07:48:13 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
 <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>
 <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com>
Message-ID: <fLe7ehwFz63gQW31NJtcGKZLmnVNlaD7kjzrssybjG4=.d8213b0e-8b37-496a-a570-74bbf844d15e@github.com>

On Mon, 7 Dec 2020 21:14:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:
>> 
>>> 105:                 { 61,   0,  Set.of(STATIC, TRANSITIVE) },
>>> 106: 
>>> 107:                 { 62,   0,  Set.of()},                       // JDK 18
>> 
>> This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release?
>
> I've had similar thoughts; that strikes me as a fine RFE for after this fork. I see what the code is doing, but haven't delved into the module system details to understand exactly the rationale for these tests. In any case, filed the RFE JDK-8257856: "Make ClassFileVersionsTest.java robust to JDK version updates."

There was a change to JVMS 4.7.25 in Java 10 to add a rule for the requires_flags that are allowed. This is why this test started was created to test 53.0 vs. 54.0 class files. It wasn't intended to be a burden to update at each release so I'll re-implement it.

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From ihse at openjdk.java.net  Tue Dec  8 08:30:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 08:30:12 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
Message-ID: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>

On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`
>
> Hi Magnus,
> 
> I see the motivation of moving these build files for better identification of ownership.   Placing them under
> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?

@mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!

This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec  8 08:35:13 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 08:35:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
Message-ID: <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>

On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Magnus,
>> 
>> I see the motivation of moving these build files for better identification of ownership.   Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?
>
> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
> 
> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.

Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From alanb at openjdk.java.net  Tue Dec  8 12:18:20 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 12:18:20 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
Message-ID: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>

On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>> 
>> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.

The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From erik.joelsson at oracle.com  Tue Dec  8 14:05:28 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 8 Dec 2020 06:05:28 -0800
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
Message-ID: <c7811a03-ceba-1482-ae36-1c3bf5e0eed3@oracle.com>


On 2020-12-08 00:30, Magnus Ihse Bursie wrote:
> On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>
>>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`
>> Hi Magnus,
>>
>> I see the motivation of moving these build files for better identification of ownership.   Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?
> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>
> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
I strongly agree with Magnus for all the same reasons. To me, the data 
files are clearly a form of source code that should be considered owned 
by the component teams. I'm honestly perplexed over why this is being 
argued against.

/Erik

> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec  8 14:48:18 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 14:48:18 GMT
Subject: RFR: 8257905: Make fixpath.sh more liberal in accepting paths
 embedded in arguments
Message-ID: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>

When calling a Windows tool that needs an argument on the form `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and stops trying to convert the path. 

Instead it needs to recheck for paths after a separator such as `:` or `=`.

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

Commit messages:
 - 8257905: Make fixpath.sh more liberal in accepting paths embedded in arguments

Changes: https://git.openjdk.java.net/jdk/pull/1698/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1698&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257905
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1698.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1698/head:pull/1698

PR: https://git.openjdk.java.net/jdk/pull/1698


From herrick at openjdk.java.net  Tue Dec  8 15:11:50 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 8 Dec 2020 15:11:50 GMT
Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618 [v2]
In-Reply-To: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
Message-ID: <UhKMC14CZoXTrgGQrC8iJJFVSzaTYCXD3whnca5s7Dw=.fd4c1d0f-822c-43c4-a27b-7cfa610d571d@github.com>

> increase retries and timeout increasing in runMsiexecWithRetries

Andy Herrick has updated the pull request incrementally with 18 additional commits since the last revision:

 - 8256149: Weird AST structure for incomplete member select
   
   Reviewed-by: vromero
 - 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary
   
   Reviewed-by: jvernee, shade
 - 8257848: -XX:CompileCommand=blackhole,* should be diagnostic
   
   Reviewed-by: vlivanov
 - 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input
   
   Reviewed-by: alanb
 - 8254733: HotSpot Style Guide should permit using range-based for loops
   
   Reviewed-by: dholmes, pliden, jrose, dcubed, iklam, eosterlund, tschatzl, kvn
 - 8253644: C2: assert(skeleton_predicate_has_opaque(iff)) failed: unexpected
   
   Reviewed-by: roland, kvn
 - 8256411: Based anonymous classes have a weird end position
   
   Reviewed-by: vromero
 - 8257813: [redo] C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops
   
   Reviewed-by: chagedorn, kvn
 - 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305
   
   Reviewed-by: mullan, valeriep
 - 8257855: Example SafeVarargsNotApplicableToRecordAccessors breaks test tools/javac/diags/CheckExamples.java
   
   Reviewed-by: jjg
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/7c4743c5...5d065497

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1676/files
  - new: https://git.openjdk.java.net/jdk/pull/1676/files/7c4743c5..5d065497

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1676&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1676&range=00-01

  Stats: 1938 lines in 49 files changed: 1465 ins; 276 del; 197 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1676.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1676/head:pull/1676

PR: https://git.openjdk.java.net/jdk/pull/1676


From weijun at openjdk.java.net  Tue Dec  8 15:28:11 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 8 Dec 2020 15:28:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec  8 16:20:21 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:20:21 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <XJDGP3MtiEMsfcKaybq1ZpasjInl_6TwEOxVCVKnPgU=.9c47e0ac-6c43-42f9-b2d6-22675351814a@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

@AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.

I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:

> As to charsetmapping and cldrconverter, I believe they can reside in 
java.base, as jdk.charsets and jdk.localedata modules depend on it.

Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.

Specifically for  make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From herrick at openjdk.java.net  Tue Dec  8 16:25:03 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 8 Dec 2020 16:25:03 GMT
Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618
In-Reply-To: <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
 <s8py0M4XMsD6CRz15ZUuN2ipQFB9T5lGttkbIwqh_Us=.2b5ec883-00fe-49ca-b36c-cbe419f9a5cf@github.com>
 <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com>
Message-ID: <KXhwC_QsPvLZbWxx0VOSHwM2T11LVIahL_eGfyzUTw8=.239cab51-45a1-468d-bc51-58aae763e853@github.com>

On Tue, 8 Dec 2020 14:56:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Looks like test failed due to:
>> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity.
>> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML?
>
>> 
>> 
>> Looks like test failed due to:
>> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity.
>> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML?
> 
> If you scroll down from that error - you can see that that is the expected error and the return code from jpackage is asserted to be 1, and it is asserted that the resulting WinL10NTest.msi does not exist.
> 
> the @Parameters for "data" cause instance of this test to be run 8 times with different args.  This instances is expected to fail since allWxlFilesValid is false.
> later in the log (https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-16+26-1740-tier2-20201124-1335-16116386-open_test_jdk_tier2_part2-windows-x64-125-1606226621-1556/log) you can see the timeout, where unpack.bat is run three times with 3 second delay and returns 1618 each time:
> **13:58:30.303] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:33.469] TRACE: exec: Done. Exit code: 1618
> [13:58:36.492] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:39.636] TRACE: exec: Done. Exit code: 1618
> [13:58:42.652] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:45.803] TRACE: exec: Done. Exit code: 1618
> [13:58:48.832] ERROR: Expected [0]. Actual [1618]: Check command [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3) exited with 0 code
> [13:58:48.832] [  FAILED  ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=fr](length=2), fr;en-us, null).test; checks=17
> [13:58:48.832] [ RUN      ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=it, name=c.wxl; culture=fr, name=d.wxl; culture=it](length=4), fr;it;en-us,**
> 
> running unpack.bat with msiexec command in it succeed for one test instance after the expected failure, then got 1618 return on the second test instance after the expected failure with the above timeout.

I converted to draft because somehow merging with master caused a mess - since is simple change in one test file I may create a new branch and new pull request cleanly again.

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

PR: https://git.openjdk.java.net/jdk/pull/1676


From ihse at openjdk.java.net  Tue Dec  8 16:25:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:25:06 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
Message-ID: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>

On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?
> 
> Update: I see all subdirs in tools are still there.

@wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.

I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec  8 16:43:14 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:43:14 GMT
Subject: RFR: 8257905: Make fixpath.sh more liberal in accepting paths
 embedded in arguments [v2]
In-Reply-To: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>
References: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>
Message-ID: <ANn3kytm5G53NKQ-EhqvoNQ6mxenmp5K-iPX4R3wUNc=.65b94424-af75-4741-9020-2d64268280f0@github.com>

> When calling a Windows tool that needs an argument on the form `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and stops trying to convert the path. 
> 
> Instead it needs to recheck for paths after a separator such as `:` or `=`.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  The same fix is also needed for the $DRIVEPREFIX regex

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1698/files
  - new: https://git.openjdk.java.net/jdk/pull/1698/files/ae993372..b678804e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1698&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1698&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1698.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1698/head:pull/1698

PR: https://git.openjdk.java.net/jdk/pull/1698


From erikj at openjdk.java.net  Tue Dec  8 16:43:32 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 8 Dec 2020 16:43:32 GMT
Subject: RFR: 8257905: Make fixpath.sh more liberal in accepting paths
 embedded in arguments [v2]
In-Reply-To: <ANn3kytm5G53NKQ-EhqvoNQ6mxenmp5K-iPX4R3wUNc=.65b94424-af75-4741-9020-2d64268280f0@github.com>
References: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>
 <ANn3kytm5G53NKQ-EhqvoNQ6mxenmp5K-iPX4R3wUNc=.65b94424-af75-4741-9020-2d64268280f0@github.com>
Message-ID: <JMdZox6MwQa6tT_iLlWgEhpN8t_hztfnKUkWjcAYlHE=.d38aaabb-7ed6-4df0-ad64-88715aa118b6@github.com>

On Tue, 8 Dec 2020 16:40:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When calling a Windows tool that needs an argument on the form `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and stops trying to convert the path. 
>> 
>> Instead it needs to recheck for paths after a separator such as `:` or `=`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The same fix is also needed for the $DRIVEPREFIX regex

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1698


From darcy at openjdk.java.net  Tue Dec  8 17:10:30 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 17:10:30 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v5]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e5462611...ff9b78ec

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/342c8650..ff9b78ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=03-04

  Stats: 1427 lines in 38 files changed: 1106 ins; 191 del; 130 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From erikj at openjdk.java.net  Tue Dec  8 17:35:10 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 8 Dec 2020 17:35:10 GMT
Subject: RFR: 8257905: Make fixpath.sh more liberal in accepting paths
 embedded in arguments [v2]
In-Reply-To: <ANn3kytm5G53NKQ-EhqvoNQ6mxenmp5K-iPX4R3wUNc=.65b94424-af75-4741-9020-2d64268280f0@github.com>
References: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>
 <ANn3kytm5G53NKQ-EhqvoNQ6mxenmp5K-iPX4R3wUNc=.65b94424-af75-4741-9020-2d64268280f0@github.com>
Message-ID: <do_qZHGSFirxufwwwyq_mDttIxMB_DnAxEXO2oecvP8=.a3cd946c-529c-4653-a588-fd86af52603c@github.com>

On Tue, 8 Dec 2020 16:43:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> When calling a Windows tool that needs an argument on the form `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and stops trying to convert the path. 
>> 
>> Instead it needs to recheck for paths after a separator such as `:` or `=`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The same fix is also needed for the $DRIVEPREFIX regex

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1698


From alanb at openjdk.java.net  Tue Dec  8 17:36:08 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 17:36:08 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.

This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec  8 18:03:10 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 18:03:10 GMT
Subject: Integrated: 8257905: Make fixpath.sh more liberal in accepting paths
 embedded in arguments
In-Reply-To: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>
References: <HKtMu4QEhtjMa-fYuGyNXVyj_gOnwcXSS65T8Mn55Mw=.c849266e-7388-44d5-b450-0bc16032fb4a@github.com>
Message-ID: <hsoqflOVqppZpTipfQA_soFflWM6l_Rp74rcsq3vLXI=.7d814136-8000-447c-b690-fb3e90d56018@github.com>

On Tue, 8 Dec 2020 14:43:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> When calling a Windows tool that needs an argument on the form `-option/a:/home/ihse/myjdk/...`, fixpath gets confused and thinks `/a:/home/ihse/myjdk` is a unix path, notices that it does not exists, and stops trying to convert the path. 
> 
> Instead it needs to recheck for paths after a separator such as `:` or `=`.

This pull request has now been integrated.

Changeset: 264feb35
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/264feb35
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8257905: Make fixpath.sh more liberal in accepting paths embedded in arguments

Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk/pull/1698


From mchung at openjdk.java.net  Tue Dec  8 18:20:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:20:07 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
 <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
Message-ID: <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>

On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?
>> 
>> Update: I see all subdirs in tools are still there.
>
> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
> 
> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.

@magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair.  You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure.

I reviewed this patch and this looks okay to me.   Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`?  There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up.   I agree that this should be cleaned up by the component teams and not part of this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From mchung at openjdk.java.net  Tue Dec  8 18:24:08 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:24:08 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
 <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
 <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>
Message-ID: <XbBJA_8zarG-F3qYYl0yXuS4ftw17t0gQbvE-o8mBOc=.2d1bb989-40d6-48c8-bc79-7f36580e000c@github.com>

On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
>> 
>> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.
>
> @magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair.  You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure.
> 
> I reviewed this patch and this looks okay to me.   Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`?  There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up.   I agree that this should be cleaned up by the component teams and not part of this PR.

With these new files showing up in under `src` directory, should `bin/idea.sh` be changed to exclude `data` to avoid incurring costs in loading JDK project from IDE that many of us use for development?

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From mchung at openjdk.java.net  Tue Dec  8 18:33:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:33:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v5]
In-Reply-To: <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
Message-ID: <-0FTWuV91_n7GwB4Om2qXb6LsQh7YxKq2ZCq4qSITGQ=.8955f873-e2ca-4eb1-a1d8-f295cdcab9c9@github.com>

On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update symbol files for JDK 16b27.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c3d62067...ff9b78ec

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From akozlov at openjdk.java.net  Tue Dec  8 18:34:09 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 8 Dec 2020 18:34:09 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <HQ_6ipJBnfR5D_0cyb0pvfyDZAFAZxU9ZZ6UN5bP3i0=.2acb269f-141a-4ae8-b022-e87b0fc6f75d@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
 <PY56Mfxu67jJWDI8LuWdmbF0z4boOW0jbSutObP-zWw=.66abad93-f4fb-415b-9060-c8a3d440bd09@github.com>
 <0soXrt4ZL1OWprS_NVh-tZAT3aqujHcHWnY42CZlarQ=.b937a2a9-ede3-4bd8-8d7a-660e5bd0f1d6@github.com>
 <eugS-Vx-dD5HglYOI25mnE2mSv2oT8245Yw4C_jV870=.5c1913c7-70ac-41c8-921f-17b8d4613950@github.com>
 <l5rkAkv1wM7b463AVNOT0e-oLaEU_xU2ASmb6x97-8E=.019d536f-8979-4208-8486-5447022d3c56@github.com>
 <afT-kCFb7JGW9uHnfugYFNyOITYVG5otQqIEzaD8O_E=.72ebd4ae-5913-41e2-8826-03bd514fcac9@github.com>
 <bwEdvPo6Qv7nuHC4tfp1IsHsDtYzRVPMb6FTVMXE-n8=.d95e3c74-4112-4e39-abff-60128e15fe22@github.com>
 <HQ_6ipJBnfR5D_0cyb0pvfyDZAFAZxU9ZZ6UN5bP3i0=.2acb269f-141a-4ae8-b022-e87b0fc6f75d@github.com>
Message-ID: <xswB4l-vlWxRvasGk3edOX2ZWsqSIyQhq80BBTz_ivA=.9d7ecfe0-58a6-47a5-a023-0451b002f4b9@github.com>

On Thu, 3 Dec 2020 06:50:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Filed https://bugs.openjdk.java.net/browse/JDK-8257633
>
> Thanks for taking care of those issues. To be clear, there is no real need to bump the version for this PR, 10.9 is fine. This PR just proposes another way to implement the workaround for 10.9.

Hi, could I get review of the patch?

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From naoto at openjdk.java.net  Tue Dec  8 18:44:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Dec 2020 18:44:10 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
Message-ID: <k9qXBPmHPOK7f3RlgFTgAwZ_xNkAHcCP2BMajiIcUHA=.05b9e889-3dd2-4e3f-b5a5-41c629077255@github.com>

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:
> 
> > As to charsetmapping and cldrconverter, I believe they can reside in
> > java.base, as jdk.charsets and jdk.localedata modules depend on it.
> 
> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.
> 
> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.

I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec  8 19:15:46 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 19:15:46 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
Message-ID: <NvyCKRMEPTJVNNstfqibDocrM3eRvRhp-oKn4RwS5JU=.25dc3794-c662-47ef-ac56-bed4e398cbbe@github.com>

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

@AlanBateman @mlchung @naotoj I can certainly anticipate follow-up cleanups on this patch. In fact, I think this patch has the potential to be a catalyst for such change, since the data that has been "hidden away" in `make` now becomes more visible to the teams that are capable of doing something about it. (With that said, of course the build team will assist in helping to clear up messy code structure, as we always do.) But I think we should be restrictive in trying too hard to make everything right in this single patch; it's better to get things approximately right and then go through the "warts" one by one and solve them properly.

@AlanBateman What I meant by Jigsaw was that when the monolithic source code were modularized, the separation of concern between java.base and jdk.charsets/jdk.localedata was not complete, compared to (more or less) all other modules. It might very well be the case that we will never be able to make such a separation; but, prior to Jigsaw, this was not a "wart". It only became a code hygiene issue when some of the charsets and localedata was extraced from java.base.

@mlchung My gut reaction is that we should not change idea.sh. First of all, kind of the purpose of this move is to make it clear to module developers the full set of materials their module consists of. That purpose would be sort of defeated, if we were to hide this in a popular IDE configuration. Secondly, I doubt this will add any performance difference. Listing additional files in the workspace is unlikely to do much, unless you actively open and/or interact with these files. But if you are worried, please fetch the PR (Skara adds instructions in the body) and try it out yourself!

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From jlahoda at openjdk.java.net  Tue Dec  8 19:35:03 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 19:35:03 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v12]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merging recent master changes into JDK-8250768
 - Fixing navigator for the PREVIEW page.
 - Fixing typo.
 - Removing obsolette @PreviewFeature.
 - Merging master into JDK-8250768
 - Removing unnecessary property keys.
 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - Reflecting review comments.
 - Removing trailing whitespace.
 - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=11
  Stats: 3711 lines in 132 files changed: 2726 ins; 692 del; 293 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

PR: https://git.openjdk.java.net/jdk/pull/703


From jjg at openjdk.java.net  Tue Dec  8 21:05:41 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 21:05:41 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v5]
In-Reply-To: <bG8PpoaqCnD_mWq0sKWSkOgOmiEyvsrpbn9v5hRTWuM=.a4206e56-1a5b-493e-9e47-7156166c74fa@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <bG8PpoaqCnD_mWq0sKWSkOgOmiEyvsrpbn9v5hRTWuM=.a4206e56-1a5b-493e-9e47-7156166c74fa@github.com>
Message-ID: <GdekdlOJbNpIYlK9w5R6xo7pWYlFAgUXK45IQxBvN-c=.c6c809b7-250b-4170-85e3-d8f4f60f1205@github.com>

On Thu, 3 Dec 2020 09:22:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
>> -updating and moving tests into test/langtools, so that it is easier to run them.
>> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
>> -fixing the -Xprint annotation processor to print record component annotations.
>> 
>> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Blank lines do not count for the text block indentation, removing them.

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From dholmes at openjdk.java.net  Tue Dec  8 22:38:37 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Dec 2020 22:38:37 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v5]
In-Reply-To: <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
Message-ID: <6zD-WD76gZaXzeOuaj0c1N75lPbLTxUOHoLu9M4ZbLc=.367ab8af-b105-4977-afe1-0a29bbe2d88a@github.com>

On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update symbol files for JDK 16b27.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/d1c29ce3...ff9b78ec

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From darcy at openjdk.java.net  Tue Dec  8 23:23:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 23:23:55 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v6]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Get in JEP 390 changes.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/823053e1...57ba7b64

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/ff9b78ec..57ba7b64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=04-05

  Stats: 1178 lines in 148 files changed: 571 ins; 195 del; 412 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From burban at openjdk.java.net  Wed Dec  9 07:22:51 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Wed, 9 Dec 2020 07:22:51 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v5]
In-Reply-To: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
Message-ID: <6w3ZPc_ZRK37SeuA9j1bLqojV8FjiafvLnaUrcWlt3Q=.8525cb22-e142-49e5-96e4-32edd7d1d4ad@github.com>

> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
> 
> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
> 
> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.

Bernhard Urban-Forster has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - remove gtest and jtreg
 - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
 - merge mistakes
 - change default target to hotspot and align with updated x64 bits
 - remove devkit usage on win-aarch64
 - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
 - todo note for caching devkit
 - remove release build
 - move windows_aarch64_build next to other builds
 - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/9ce3d806...c07f5d72

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

Changes: https://git.openjdk.java.net/jdk/pull/1379/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1379&range=04
  Stats: 92 lines in 1 file changed: 91 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1379.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1379/head:pull/1379

PR: https://git.openjdk.java.net/jdk/pull/1379


From burban at openjdk.java.net  Wed Dec  9 07:22:51 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Wed, 9 Dec 2020 07:22:51 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v4]
In-Reply-To: <8daExVszcK5qLhWmLys3tRdEKpoyyaSuEDLPSGLE4sc=.031c3e04-c404-4ad0-84a1-1bb3b25662a6@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <OoiPAIIu70YYjKwdyySZA-hGIK_EN7gWXssFH5Xj7uk=.a81ed5ad-1180-4155-beed-816b62366c44@github.com>
 <mdjmAEpxmagFq7e6N6y90XV8chqFADBAMX_faj78wSE=.87234f5b-a563-4304-b82e-d290a19d4e6f@github.com>
 <8daExVszcK5qLhWmLys3tRdEKpoyyaSuEDLPSGLE4sc=.031c3e04-c404-4ad0-84a1-1bb3b25662a6@github.com>
Message-ID: <j7fW2o8_dhooBAx1Ymgt5Ab5i7PfIAJ0cLx9LxqJR-I=.8c423b8b-72dc-4a5d-86f4-8deb64fa276e@github.com>

On Tue, 8 Dec 2020 06:59:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Minor nits.
>
> Also merge from master to get the clean workflow run everywhere?

Thank you @shipilev for your comments, I've updated the PR.

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

PR: https://git.openjdk.java.net/jdk/pull/1379


From shade at openjdk.java.net  Wed Dec  9 07:38:37 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 9 Dec 2020 07:38:37 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v5]
In-Reply-To: <6w3ZPc_ZRK37SeuA9j1bLqojV8FjiafvLnaUrcWlt3Q=.8525cb22-e142-49e5-96e4-32edd7d1d4ad@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <6w3ZPc_ZRK37SeuA9j1bLqojV8FjiafvLnaUrcWlt3Q=.8525cb22-e142-49e5-96e4-32edd7d1d4ad@github.com>
Message-ID: <AazElTQJda1mJXn2POu2aLu_d3PaZppoCtd9OgwZesw=.66f509d1-1090-4527-951c-11f607572d23@github.com>

On Wed, 9 Dec 2020 07:22:51 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
>> 
>> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
>> 
>> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.
>
> Bernhard Urban-Forster has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - remove gtest and jtreg
>  - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
>  - merge mistakes
>  - change default target to hotspot and align with updated x64 bits
>  - remove devkit usage on win-aarch64
>  - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
>  - todo note for caching devkit
>  - remove release build
>  - move windows_aarch64_build next to other builds
>  - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/9ce3d806...c07f5d72

Thanks, updates look fine to me.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1379


From ihse at openjdk.java.net  Wed Dec  9 08:01:37 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 08:01:37 GMT
Subject: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow [v5]
In-Reply-To: <6w3ZPc_ZRK37SeuA9j1bLqojV8FjiafvLnaUrcWlt3Q=.8525cb22-e142-49e5-96e4-32edd7d1d4ad@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
 <6w3ZPc_ZRK37SeuA9j1bLqojV8FjiafvLnaUrcWlt3Q=.8525cb22-e142-49e5-96e4-32edd7d1d4ad@github.com>
Message-ID: <OrjEFr2S9Dlp0wuN5kAlfo3qf5GjfEV-JpQkgkdpNPg=.04b13191-60d2-4c64-9fc3-8272dbfca58f@github.com>

On Wed, 9 Dec 2020 07:22:51 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

>> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
>> 
>> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
>> 
>> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.
>
> Bernhard Urban-Forster has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - remove gtest and jtreg
>  - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
>  - merge mistakes
>  - change default target to hotspot and align with updated x64 bits
>  - remove devkit usage on win-aarch64
>  - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
>  - todo note for caching devkit
>  - remove release build
>  - move windows_aarch64_build next to other builds
>  - Merge remote-tracking branch 'upstream/master' into 8256657-win-arm64-gh-submit-workflow
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/9ce3d806...c07f5d72

Marked as reviewed by ihse (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1379


From burban at openjdk.java.net  Wed Dec  9 11:24:33 2020
From: burban at openjdk.java.net (Bernhard Urban-Forster)
Date: Wed, 9 Dec 2020 11:24:33 GMT
Subject: Integrated: 8256657: Add cross-compiled build for Windows+Arm64 to
 submit workflow
In-Reply-To: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
References: <YJ0JKc3gR3QeZD52JHHXqVe6PomXcd5Aj-IVM3Fk2yQ=.9cc3e46d-7548-4e06-bd35-45451ba52ce9@github.com>
Message-ID: <gB77AMuo2oXTHa44acU8X5mV1NOAq4mRulS5YXjqSj8=.c07eecdb-cc76-4089-9a2c-84f263728349@github.com>

On Mon, 23 Nov 2020 09:35:40 GMT, Bernhard Urban-Forster <burban at openjdk.org> wrote:

> This adds the cross-compiled build only, as no Windows+Arm64 machines are available on GitHub Action that we could use to run the tests.
> 
> Due to cross-compilation a build JDK is required. Initially I added EA builds to be downloaded from https://jdk.java.net/16/ and used for that, but then I saw how @shipiliv attempted it for the linux cross-compilation builds in https://github.com/openjdk/jdk/pull/1147.  That is using the JDK image produced by the x64 variant. This however add more stress to the "critical path", as now two more jobs depend on the x64 build first.
> 
> Let's see how it works out in the long-run. A Windows+AArch64 build takes 40-50min.

This pull request has now been integrated.

Changeset: d3dddb6a
Author:    Bernhard Urban-Forster <burban at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d3dddb6a
Stats:     92 lines in 1 file changed: 91 ins; 0 del; 1 mod

8256657: Add cross-compiled build for Windows+Arm64 to submit workflow

Reviewed-by: shade, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/1379


From ihse at openjdk.java.net  Wed Dec  9 13:31:39 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 13:31:39 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
Message-ID: <lyKqlc3ngqk4NA7RgomL250cWvj64CymEwhWm-fytxg=.8d60a16f-d4e2-4245-8842-fc307683afa1@github.com>

On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available.

>From a build PoV this sounds like a reasonable fix, but you need a review from someone in core-libs as well.

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From ihse at openjdk.java.net  Wed Dec  9 13:32:43 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 13:32:43 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v12]
In-Reply-To: <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>
Message-ID: <k1SYjoM2awbCbJ9aK3_biTQRgLTIa62VlyOOqi1-IHQ=.c33493b3-4c7e-409e-b02d-13cdc467d71f@github.com>

On Tue, 8 Dec 2020 19:35:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:
> 
>  - Merging recent master changes into JDK-8250768
>  - Fixing navigator for the PREVIEW page.
>  - Fixing typo.
>  - Removing obsolette @PreviewFeature.
>  - Merging master into JDK-8250768
>  - Removing unnecessary property keys.
>  - Cleanup - removing unnecessary code.
>  - Merging master into JDK-8250768-dev4
>  - Reflecting review comments.
>  - Removing trailing whitespace.
>  - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57

Build changes still good.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/703


From ihse at openjdk.java.net  Wed Dec  9 13:46:39 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 13:46:39 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v6]
In-Reply-To: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com>
Message-ID: <4lA_pBO9zyK3YLajvxRTMaSpzXaTmeieeakdjmoRx_0=.1dbcf13e-809f-432b-ad71-8b9bd9afb9d7@github.com>

On Tue, 8 Dec 2020 23:23:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Get in JEP 390 changes.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update symbol files for JDK 16b27.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/5c27251d...57ba7b64

Build changes (or should I say "change"?) looks good!

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1531


From ihse at openjdk.java.net  Wed Dec  9 14:13:44 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 14:13:44 GMT
Subject: RFR: 8257973: UTIL_LOOKUP_PROGS should only find executable files
Message-ID: <SV1GD3s2ltbfT4nW3jcDPAOe_dBy5gy2KdOh2G1Qz5Q=.ccf4e497-9995-4f97-9a19-282ea873a038@github.com>

It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file in the PATH that matches the given tool name, it accept it straight away. Even if the file is a directory, or is not executable.

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

Commit messages:
 - 8257973: UTIL_LOOKUP_PROGS should only find executable files

Changes: https://git.openjdk.java.net/jdk/pull/1715/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1715&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257973
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1715.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1715/head:pull/1715

PR: https://git.openjdk.java.net/jdk/pull/1715


From rriggs at openjdk.java.net  Wed Dec  9 14:28:33 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 9 Dec 2020 14:28:33 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
Message-ID: <RBx-8nOu99FeLZ_RjPZ2YFRdtT2pOxFm0wbeQpbKZ-E=.4ae93e56-4168-4b76-b3d2-5688fb8fd03b@github.com>

On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available.

Looks ok to me.
But it would be good if @prrace can have a look.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1569


From erikj at openjdk.java.net  Wed Dec  9 14:34:35 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 9 Dec 2020 14:34:35 GMT
Subject: RFR: 8257973: UTIL_LOOKUP_PROGS should only find executable files
In-Reply-To: <SV1GD3s2ltbfT4nW3jcDPAOe_dBy5gy2KdOh2G1Qz5Q=.ccf4e497-9995-4f97-9a19-282ea873a038@github.com>
References: <SV1GD3s2ltbfT4nW3jcDPAOe_dBy5gy2KdOh2G1Qz5Q=.ccf4e497-9995-4f97-9a19-282ea873a038@github.com>
Message-ID: <NZAQB99cYaDs2mCKqD27zp5R0Vo32-6hmjBaVwmm3Fc=.c365daeb-0053-4fef-aa61-d7cb62a2f3ee@github.com>

On Wed, 9 Dec 2020 14:08:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file in the PATH that matches the given tool name, it accept it straight away. Even if the file is a directory, or is not executable.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1715


From jlahoda at openjdk.java.net  Wed Dec  9 15:10:07 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Dec 2020 15:10:07 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v6]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <0GbDxAutpYeJtWyAb4zDfywKH5y0Nur6zkOLqfCUTlA=.e522e1b8-cdda-4598-9129-a1935bccd276@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Need to open a few packages for the test.
 - Merge branch 'master' into JDK-8256950
 - Blank lines do not count for the text block indentation, removing them.
 - Reflecting review comments.
 - Fixing tests on Windows - normalizing line endings.
 - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950
 - Update CreateSymbolsTest.java
 - CreateSymbols should support records with no components.
 - Cleaning TODO.
 - Cleaning TODO.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/51dfede0...08d7a106

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/3aaaf28c..08d7a106

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=04-05

  Stats: 41234 lines in 1081 files changed: 28666 ins; 7705 del; 4863 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

PR: https://git.openjdk.java.net/jdk/pull/1480


From jlahoda at openjdk.java.net  Wed Dec  9 15:10:08 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Dec 2020 15:10:08 GMT
Subject: Integrated: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <dywHI85TUvu9EFIXRFiv1ptu1RbndCyrSosd5E1zkMU=.1dc8e16c-f1c8-4ff2-9097-4bfa3dc9664a@github.com>

On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

This pull request has now been integrated.

Changeset: 6eff9315
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6eff9315
Stats:     1961 lines in 12 files changed: 1198 ins; 745 del; 18 mod

8256950: Add record attribute support to symbol generator CreateSymbols

Reviewed-by: jjg, chegar

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

PR: https://git.openjdk.java.net/jdk/pull/1480


From ihse at openjdk.java.net  Wed Dec  9 15:44:35 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 15:44:35 GMT
Subject: Integrated: 8257973: UTIL_LOOKUP_PROGS should only find executable
 files
In-Reply-To: <SV1GD3s2ltbfT4nW3jcDPAOe_dBy5gy2KdOh2G1Qz5Q=.ccf4e497-9995-4f97-9a19-282ea873a038@github.com>
References: <SV1GD3s2ltbfT4nW3jcDPAOe_dBy5gy2KdOh2G1Qz5Q=.ccf4e497-9995-4f97-9a19-282ea873a038@github.com>
Message-ID: <DVjVbRfMlchjW-PJzJHpVHihW4Ry36p-Fv7KuNxeyq0=.e6bf02b4-f8cb-494e-80e8-1cdfe229a668@github.com>

On Wed, 9 Dec 2020 14:08:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It turns out that UTIL_LOOKUP_PROGS does not verify that when it find a file in the PATH that matches the given tool name, it accept it straight away. Even if the file is a directory, or is not executable.

This pull request has now been integrated.

Changeset: 6c69eca3
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6c69eca3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8257973: UTIL_LOOKUP_PROGS should only find executable files

Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk/pull/1715


From vdyakov at openjdk.java.net  Wed Dec  9 18:27:42 2020
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Wed, 9 Dec 2020 18:27:42 GMT
Subject: RFR: 8251854: [macosx] Java forces the use of discrete GPU
In-Reply-To: <YhYXy8tdT7E_dCSss6az0WIpnfL1dxw2eVsCTWUwDJI=.33246b1e-7e53-455f-87ea-cf94081759e2@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
 <YhYXy8tdT7E_dCSss6az0WIpnfL1dxw2eVsCTWUwDJI=.33246b1e-7e53-455f-87ea-cf94081759e2@github.com>
Message-ID: <SU_a7mV1C_lWYiRM61qkSbZwp49f9zq8eTLUtPYPzd8=.879ef998-b8ad-448d-a6c1-5155cc64646f@github.com>

On Tue, 17 Nov 2020 18:55:51 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU:
>> 
>> **attenuation.LightingSample: 500 large quads**
>> discrete GPU: 23.5 fps
>> integrated GPU: 2.34 fps
>> 
>> In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU:
>> 
>> **Vector charting test, oval clip**
>> discrete GPU: 41.1 fps
>> integrated GPU: 26.6 fps
>> 
>> I see similar results in the performance numbers you listed above.
>> 
>> An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit.
>
>> > @kevinrushforth @prrace could you please review?
>> 
>> As we discussed yesterday, it is reviewed but not ready to be approved.
>> We are waiting for a reply from Apple.
> 
> @prrace 
> We are waiting for it for three months already. If it is possible then not sure why other applications did not found any possible ways to force one specific GPU. What we are wating for?

@mrserb @prrace  what is a back up plan in case we will not have a reply from Apple? (as we do not have it for 4! months). Definitely we need a plan B

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

PR: https://git.openjdk.java.net/jdk/pull/1139


From mgronlun at openjdk.java.net  Wed Dec  9 21:02:23 2020
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Dec 2020 21:02:23 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default) [v4]
In-Reply-To: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
Message-ID: <3xq4tVLKVLdmZGawJ-rH6UPnGa756u0f3QK_YqdYwsc=.5928cc03-6c72-4b4d-8ec4-cc86a2f4f404@github.com>

> Greetings,
> 
> please help review this enhancement to let JFR sample object allocations by default.
> 
> A description is provided in the JIRA issue.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with 12 additional commits since the last revision:

 - initialization check
 - thread locals and detach and reattach
 - Tighter ThrottleUnit
 - JFC control elements
 - TLAB include
 - ThrottleUnit enum
 - remote tests
 - jfc control attributes
 - Sampling frequency adjustment for large objects
 - Treat large objects as tlabs for sampling purposes
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6918f0c8...4e986552

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1624/files
  - new: https://git.openjdk.java.net/jdk/pull/1624/files/6918f0c8..4e986552

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1624&range=02-03

  Stats: 530 lines in 13 files changed: 174 ins; 285 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1624/head:pull/1624

PR: https://git.openjdk.java.net/jdk/pull/1624


From github.com+26284057+mybloodtop at openjdk.java.net  Wed Dec  9 21:02:24 2020
From: github.com+26284057+mybloodtop at openjdk.java.net (Mukilesh Sethu)
Date: Wed, 9 Dec 2020 21:02:24 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default)
In-Reply-To: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
Message-ID: <qEj4oxwHjOzoHvLqXQChaMtuPOnp8rpQZ7oGLwx4XoE=.f6056380-0d0f-4771-98ad-4572b49c3f4b@github.com>

On Fri, 4 Dec 2020 15:25:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> please help review this enhancement to let JFR sample object allocations by default.
> 
> A description is provided in the JIRA issue.
> 
> Thanks
> Markus

This is great! It would be awesome to have this capability.

One query on the way you are throttling the events (please correct me if I'm wrong here as I am new to this codebase),

If I understood correctly, you are throttling the events at the time of committing, specifically part of `should_write` or `should_commit` in `jfrEvent.hpp`. If so, how would we be able to add throttling to events which might require it early on like `ObjectCountAfterGC` or `ObjectCount` events ? 

I think it makes perfect sense to have it part of commit for allocation events because most of the time consuming tasks like stack walking or storing stack trace in global table is done part of event commit and we will be able to throttle it. However, for events like `ObjectCountAfterGC` the time consuming task is iterating the heap which is unavoidable if we add throttling part of commit. So, I am just curious how can we extend this solution to such events ?

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

PR: https://git.openjdk.java.net/jdk/pull/1624


From egahlin at openjdk.java.net  Wed Dec  9 21:02:33 2020
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 9 Dec 2020 21:02:33 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default) [v4]
In-Reply-To: <3xq4tVLKVLdmZGawJ-rH6UPnGa756u0f3QK_YqdYwsc=.5928cc03-6c72-4b4d-8ec4-cc86a2f4f404@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
 <3xq4tVLKVLdmZGawJ-rH6UPnGa756u0f3QK_YqdYwsc=.5928cc03-6c72-4b4d-8ec4-cc86a2f4f404@github.com>
Message-ID: <uoFISdOPSilq13OLnJ1OcHfwvfSEm6-X0DpF9hSH1QQ=.28263371-32a0-4964-84f1-44fa35243edb@github.com>

On Wed, 9 Dec 2020 20:58:48 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> please help review this enhancement to let JFR sample object allocations by default.
>> 
>> A description is provided in the JIRA issue.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with 12 additional commits since the last revision:
> 
>  - initialization check
>  - thread locals and detach and reattach
>  - Tighter ThrottleUnit
>  - JFC control elements
>  - TLAB include
>  - ThrottleUnit enum
>  - remote tests
>  - jfc control attributes
>  - Sampling frequency adjustment for large objects
>  - Treat large objects as tlabs for sampling purposes
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6918f0c8...4e986552

src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 79:

> 77:     private final PlatformEventType type;
> 78:     private final String idName;
> 79: 

Why move Enabled to later?

src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 229:

> 227:     // Expected input format is "x/y" or "x\y" where x is a non-negative long
> 228:     // and y is a time unit. Split the string at the delimiter.
> 229:     private static String parseThrottleString(String s, boolean value) {

I think we should only support one type of slash "/".

src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 249:

> 247:     }
> 248: 
> 249:     private static TimeUnit timeUnit(String unit) {

This could be done with an enum with a constructor.

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line 65:

> 63:     @Override
> 64:     public String combine(Set<String> values) {
> 65:         double max = OFF;

Probably better to use a long (nanos) than floating number

src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line 88:

> 86:     @Override
> 87:     public void setValue(String s) {
> 88:         this.value = s;

If parsing fails, I think things should be kept as is. At least that is what the SettingControl interface say.s 

I looked at other setting control and the implementation seems wrong there as well.

src/jdk.jfr/share/conf/jfr/default.jfc line 618:

> 616: 
> 617:     <event name="jdk.ObjectAllocationSample">
> 618:       <setting name="enabled">true</setting>

I think enabled should have the "memory-profiling" control.

src/jdk.jfr/share/conf/jfr/profile.jfc line 608:

> 606: 
> 607:     <event name="jdk.ObjectAllocationInNewTLAB">
> 608:       <setting name="enabled" control="memory-profiling-enabled-medium">false</setting>

Need to sync this with <selection>. 

Perhaps a new choice are needed "Object Allocation"

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

PR: https://git.openjdk.java.net/jdk/pull/1624


From mgronlun at openjdk.java.net  Wed Dec  9 21:02:25 2020
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Dec 2020 21:02:25 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default)
In-Reply-To: <qEj4oxwHjOzoHvLqXQChaMtuPOnp8rpQZ7oGLwx4XoE=.f6056380-0d0f-4771-98ad-4572b49c3f4b@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
 <qEj4oxwHjOzoHvLqXQChaMtuPOnp8rpQZ7oGLwx4XoE=.f6056380-0d0f-4771-98ad-4572b49c3f4b@github.com>
Message-ID: <ae0tsQY5xMw2q_OESJbxrlt1j-4ABUnGWwwRDy5r0fY=.b51add2d-e63f-48af-9681-380439fb1b47@github.com>

On Mon, 7 Dec 2020 22:37:20 GMT, Mukilesh Sethu <github.com+26284057+myBloodTop at openjdk.org> wrote:

>> Greetings,
>> 
>> please help review this enhancement to let JFR sample object allocations by default.
>> 
>> A description is provided in the JIRA issue.
>> 
>> Thanks
>> Markus
>
> This is great! It would be awesome to have this capability.
> 
> One query on the way you are throttling the events (please correct me if I'm wrong here as I am new to this codebase),
> 
> If I understood correctly, you are throttling the events at the time of committing, specifically part of `should_write` or `should_commit` in `jfrEvent.hpp`. If so, how would we be able to add throttling to events which might require it early on like `ObjectCountAfterGC` or `ObjectCount` events ? 
> 
> I think it makes perfect sense to have it part of commit for allocation events because most of the time consuming tasks like stack walking or storing stack trace in global table is done part of event commit and we will be able to throttle it. However, for events like `ObjectCountAfterGC` the time consuming task is iterating the heap which is unavoidable if we add throttling part of commit. So, I am just curious how can we extend this solution to such events ?

Hi, @myBloodTop, thanks for your comment.

For more special events (for example periodic events), it will be possible, although not yet supported, to use the throttling mechanism directly. For example: 

TRACE_REQUEST_FUNC(ObjectCount) {  
       if (JfrEventThrottler::accept(JfrObjectCountEvent)) {  
     VM_GC_SendObjectCountEvent op;
     VMThread::execute(&op);
  }
}

Evaluating the throttle predicate as part of commit or should_commit() is an optimization to avoid having to take the clock twice, but for cases such as the above, if you don't pass a timestamp, a timestamp will be taken for you as part of the evaluation.

Now, ObjectCount and ObjectCountAfterGC are also special in another respect, in that they are UNTIMED, meaning the events are timestamped outside of JFR. For other, non-UNTIMED events, it would be sufficient to only use the should_commit() tester, since the throttler evaluation is incorporated (post enable and threshold checks evaluations). For example:

MyEvent event;
...
if (event.should_commit()) { <<-- throttle evaluation
   event.set_field(...);
   event.commit();
}

Thanks
Markus

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

PR: https://git.openjdk.java.net/jdk/pull/1624


From mgronlun at openjdk.java.net  Wed Dec  9 21:02:41 2020
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Dec 2020 21:02:41 GMT
Subject: RFR: 8257602: Introduce JFR Event Throttling and new
 jdk.ObjectAllocationSample event (enabled by default) [v4]
In-Reply-To: <uoFISdOPSilq13OLnJ1OcHfwvfSEm6-X0DpF9hSH1QQ=.28263371-32a0-4964-84f1-44fa35243edb@github.com>
References: <es5LivYOFnfekmPi-IqPC9QFP3dh1TLZ7aZ-vMAIXjs=.020af513-a0e2-4a32-ba88-82b30a945753@github.com>
 <3xq4tVLKVLdmZGawJ-rH6UPnGa756u0f3QK_YqdYwsc=.5928cc03-6c72-4b4d-8ec4-cc86a2f4f404@github.com>
 <uoFISdOPSilq13OLnJ1OcHfwvfSEm6-X0DpF9hSH1QQ=.28263371-32a0-4964-84f1-44fa35243edb@github.com>
Message-ID: <EWA1LbWXoXxCm_eltY2BZH12yXnJHE9h6sELnLn-kzY=.412b03af-515c-461d-92c7-55eb4e1159a3@github.com>

On Tue, 8 Dec 2020 16:31:37 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with 12 additional commits since the last revision:
>> 
>>  - initialization check
>>  - thread locals and detach and reattach
>>  - Tighter ThrottleUnit
>>  - JFC control elements
>>  - TLAB include
>>  - ThrottleUnit enum
>>  - remote tests
>>  - jfc control attributes
>>  - Sampling frequency adjustment for large objects
>>  - Treat large objects as tlabs for sampling purposes
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6918f0c8...4e986552
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java line 79:
> 
>> 77:     private final PlatformEventType type;
>> 78:     private final String idName;
>> 79: 
> 
> Why move Enabled to later?

Configuring the throttler implementation in native is a bit involved. With the existing order, with enabled first, events are enabled before subsequent conditions are set up. For the throttler, it means as soon as the enabled setting is flipped, the throttler gets traffic, but its not yet configured to accept it. It has a default, which is off, meaning it accepts all events until the subsequent call to configure the throttler which can take some time, because the setup is non-trivial. It was found that rates are not respected because of the throttler not having been setup yet when its starts to get traffic.

> src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 229:
> 
>> 227:     // Expected input format is "x/y" or "x\y" where x is a non-negative long
>> 228:     // and y is a time unit. Split the string at the delimiter.
>> 229:     private static String parseThrottleString(String s, boolean value) {
> 
> I think we should only support one type of slash "/".

Fixed.

> src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 249:
> 
>> 247:     }
>> 248: 
>> 249:     private static TimeUnit timeUnit(String unit) {
> 
> This could be done with an enum with a constructor.

Fixed.

> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line 65:
> 
>> 63:     @Override
>> 64:     public String combine(Set<String> values) {
>> 65:         double max = OFF;
> 
> Probably better to use a long (nanos) than floating number

Fixed.

> src/jdk.jfr/share/classes/jdk/jfr/internal/settings/ThrottleSetting.java line 88:
> 
>> 86:     @Override
>> 87:     public void setValue(String s) {
>> 88:         this.value = s;
> 
> If parsing fails, I think things should be kept as is. At least that is what the SettingControl interface say.s 
> 
> I looked at other setting control and the implementation seems wrong there as well.

Fixed.

> src/jdk.jfr/share/conf/jfr/default.jfc line 618:
> 
>> 616: 
>> 617:     <event name="jdk.ObjectAllocationSample">
>> 618:       <setting name="enabled">true</setting>
> 
> I think enabled should have the "memory-profiling" control.

Fixed.

> src/jdk.jfr/share/conf/jfr/profile.jfc line 608:
> 
>> 606: 
>> 607:     <event name="jdk.ObjectAllocationInNewTLAB">
>> 608:       <setting name="enabled" control="memory-profiling-enabled-medium">false</setting>
> 
> Need to sync this with <selection>. 
> 
> Perhaps a new choice are needed "Object Allocation"

New control elements and attributes introduced.

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

PR: https://git.openjdk.java.net/jdk/pull/1624


From weijun at openjdk.java.net  Thu Dec 10 00:46:35 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Dec 2020 00:46:35 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <Afb0e1sUCYbYLxrSDp5uPPHBTqhH7PY3tzrdP5JSB9w=.0a7838a0-71c3-4ac5-aa64-7af685f2373e@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

The security-related part (cacerts, blacklisted.certs, publicsuffxlist) looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From darcy at openjdk.java.net  Thu Dec 10 04:42:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 04:42:55 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v7]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <gyDm6VZGnylAP8jy5TSVCMa4ergsCp1q_upz-cnUH7w=.4f679fd0-39de-4964-ba9c-80a5a1983e86@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Get in JEP 390 changes.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/bbfda542...766c2c01

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/57ba7b64..766c2c01

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=05-06

  Stats: 4920 lines in 147 files changed: 3195 ins; 1060 del; 665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From darcy at openjdk.java.net  Thu Dec 10 08:24:56 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 08:24:56 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v8]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <rn9lVol-HjFN8IltKapVMsNV_2JDkmhYPFFcMORD5k0=.0dd4b179-70dd-4a18-a95b-740305095c0f@github.com>

> Start of JDK 17 updates.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Get in JEP 390 changes.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/61f30b72...553d134f

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/766c2c01..553d134f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=06-07

  Stats: 554 lines in 7 files changed: 324 ins; 220 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

PR: https://git.openjdk.java.net/jdk/pull/1531


From ihse at openjdk.java.net  Thu Dec 10 12:47:44 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Dec 2020 12:47:44 GMT
Subject: RFR: 8258005: JDK build fails with incorrect fixpath script
Message-ID: <vuhKBLrRr1El3lzmVvRj3d6gxBy_FWOX8Kv7H5qN6Cs=.cb78087d-4a3d-43bb-9ad7-6f0dd9b5ec1a@github.com>

The Leaning Toothpick Syndrome[1] strikes back!

In the fixpath shell script wrapper, we transform single `` to `\`, to make them correctly escaped. Unfortunately, the bas variable substitution pattern I used were missing a `/`, so it only replaced the first backslash, not all of them.

Thanks to @vidmik for analysis and fix!

[1] https://en.wikipedia.org/wiki/Leaning_toothpick_syndrome

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

Commit messages:
 - 8258005: JDK build fails with incorrect fixpath script

Changes: https://git.openjdk.java.net/jdk/pull/1731/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1731&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258005
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1731/head:pull/1731

PR: https://git.openjdk.java.net/jdk/pull/1731


From ihse at openjdk.java.net  Thu Dec 10 13:11:47 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Dec 2020 13:11:47 GMT
Subject: RFR: 8258005: JDK build fails with incorrect fixpath script [v2]
In-Reply-To: <vuhKBLrRr1El3lzmVvRj3d6gxBy_FWOX8Kv7H5qN6Cs=.cb78087d-4a3d-43bb-9ad7-6f0dd9b5ec1a@github.com>
References: <vuhKBLrRr1El3lzmVvRj3d6gxBy_FWOX8Kv7H5qN6Cs=.cb78087d-4a3d-43bb-9ad7-6f0dd9b5ec1a@github.com>
Message-ID: <qWjGWS3Tt1xNEa2sXGsUVsPylJDw7o_1Jpti4nJXDJA=.bb2a8943-6f78-4f5a-bb23-074ab477a6a9@github.com>

> The Leaning Toothpick Syndrome[1] strikes back!
> 
> In the fixpath shell script wrapper, we transform single `` to `\`, to make them correctly escaped. Unfortunately, the bas variable substitution pattern I used were missing a `/`, so it only replaced the first backslash, not all of them.
> 
> Thanks to @vidmik for analysis and fix!
> 
> [1] https://en.wikipedia.org/wiki/Leaning_toothpick_syndrome

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update second instance of WINENV_ROOT backslash rewrite

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1731/files
  - new: https://git.openjdk.java.net/jdk/pull/1731/files/bf0ca7ae..08eec16e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1731&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1731&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1731/head:pull/1731

PR: https://git.openjdk.java.net/jdk/pull/1731


From erikj at openjdk.java.net  Thu Dec 10 13:40:36 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 10 Dec 2020 13:40:36 GMT
Subject: RFR: 8258005: JDK build fails with incorrect fixpath script [v2]
In-Reply-To: <qWjGWS3Tt1xNEa2sXGsUVsPylJDw7o_1Jpti4nJXDJA=.bb2a8943-6f78-4f5a-bb23-074ab477a6a9@github.com>
References: <vuhKBLrRr1El3lzmVvRj3d6gxBy_FWOX8Kv7H5qN6Cs=.cb78087d-4a3d-43bb-9ad7-6f0dd9b5ec1a@github.com>
 <qWjGWS3Tt1xNEa2sXGsUVsPylJDw7o_1Jpti4nJXDJA=.bb2a8943-6f78-4f5a-bb23-074ab477a6a9@github.com>
Message-ID: <36LUf3kMhoKZQhY-Sv6qxOB212MBTzSNYNf31mTA-CI=.8cf47bac-e9af-4235-a7e5-33441ad6b114@github.com>

On Thu, 10 Dec 2020 13:11:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The Leaning Toothpick Syndrome[1] strikes back!
>> 
>> In the fixpath shell script wrapper, we transform single `` to `\`, to make them correctly escaped. Unfortunately, the bas variable substitution pattern I used were missing a `/`, so it only replaced the first backslash, not all of them.
>> 
>> Thanks to @vidmik for analysis and fix!
>> 
>> [1] https://en.wikipedia.org/wiki/Leaning_toothpick_syndrome
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update second instance of WINENV_ROOT backslash rewrite

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1731


From ihse at openjdk.java.net  Thu Dec 10 14:57:33 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Dec 2020 14:57:33 GMT
Subject: Integrated: 8258005: JDK build fails with incorrect fixpath script
In-Reply-To: <vuhKBLrRr1El3lzmVvRj3d6gxBy_FWOX8Kv7H5qN6Cs=.cb78087d-4a3d-43bb-9ad7-6f0dd9b5ec1a@github.com>
References: <vuhKBLrRr1El3lzmVvRj3d6gxBy_FWOX8Kv7H5qN6Cs=.cb78087d-4a3d-43bb-9ad7-6f0dd9b5ec1a@github.com>
Message-ID: <XMMuz1f9hZGZWs0dCHYtgAU3euMGMqxaqO4RtWu2Clw=.d996bc07-4778-469e-bf70-4a11c71ce44c@github.com>

On Thu, 10 Dec 2020 12:42:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The Leaning Toothpick Syndrome[1] strikes back!
> 
> In the fixpath shell script wrapper, we transform single `` to `\`, to make them correctly escaped. Unfortunately, the bas variable substitution pattern I used were missing a `/`, so it only replaced the first backslash, not all of them.
> 
> Thanks to @vidmik for analysis and fix!
> 
> [1] https://en.wikipedia.org/wiki/Leaning_toothpick_syndrome

This pull request has now been integrated.

Changeset: 0890620c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0890620c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8258005: JDK build fails with incorrect fixpath script

Co-authored-by: Mikael Vidstedt <mikael at openjdk.org>
Reviewed-by: erikj

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

PR: https://git.openjdk.java.net/jdk/pull/1731


From darcy at openjdk.java.net  Thu Dec 10 16:52:13 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 16:52:13 GMT
Subject: Integrated: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <wXD3dVj531OGGfdWHNznUhqYjItuoSG7JooTYstwUXs=.36d4a91d-be6d-4132-b815-99e152e9b386@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

This pull request has now been integrated.

Changeset: 6be1f567
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6be1f567
Stats:     7607 lines in 77 files changed: 7548 ins; 0 del; 59 mod

8257450: Start of release updates for JDK 17
8257451: Add SourceVersion.RELEASE_17
8257453: Add source 17 and target 17 to javac

Reviewed-by: dholmes, erikj, iris, mikael, jjg, jlahoda, jwilhelm, mchung, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/1531


From akozlov at openjdk.java.net  Thu Dec 10 20:14:57 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 10 Dec 2020 20:14:57 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
 <XQCEEv5XyfoQD6mAK5I5hccTlqmjfzKpkUjbW5ALYQg=.faa8a943-adc1-4471-bfb8-02fca76c6335@github.com>
Message-ID: <zgUSoOHyduX0pNGIPbIsf7yNhYHoFWrhJvatnZR-ywA=.6847c52c-317b-4158-addd-2ff02af3f127@github.com>

On Wed, 2 Dec 2020 19:27:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available.
>
> Surely these days you can just call [NSProcessInfo operatingSystemVersion] directly ?
> If I read the doc below it is in the 10.10 SDK and later.
> https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion?language=occ

@prrace could you look at this?

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From naoto at openjdk.java.net  Thu Dec 10 23:10:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Dec 2020 23:10:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

test/jdk/java/util/Locale/LSRDataTest.java line 57:

> 55:     // path to the lsr file from the make folder, this test relies on the
> 56:     // relative path to the file in the make folder, considering
> 57:     // test and make will always exist in the same jdk layout

The comment refers to the "make" folder. (line 55 as well).

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1611


From minqi at openjdk.java.net  Fri Dec 11 05:17:33 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 05:17:33 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <mBghLCvd_6OOPgNdUHyl6QGPV9V_C30p2ILwh4bwIac=.4c28be41-fc69-432a-aa39-5f2ccb9820fc@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Added test case; Fixed an nmt issue caused by bitmap region not released after archive loading failed; Unmap bitmap after archive failure. Fixed reserved region name for adding reserved region.
 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/29a09c89...0421943d

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

Changes: https://git.openjdk.java.net/jdk/pull/1657/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=04
  Stats: 8183 lines in 159 files changed: 4666 ins; 2763 del; 754 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

PR: https://git.openjdk.java.net/jdk/pull/1657


From minqi at openjdk.java.net  Fri Dec 11 06:20:56 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:56 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
 <vtqmULMCnP8KBSPw6V_NFKvYVQzd9nAT9Y4V-N3j9Zs=.3c935956-78ef-491f-b209-eca535b8ca40@github.com>
 <sAqnH0sEch5UPQIwaz0vgcwVE9P_8WS-FSBmH7VU4IQ=.d6161796-38fa-4267-a62d-4dbb82689af4@github.com>
 <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
Message-ID: <gxcE4bVzUGSQ_clecIjrse_78xNKil4-urgXqWbJmhU=.cadaa2df-7141-45a0-8d2e-e0d15d36f00c@github.com>

On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changes requested by iklam (Reviewer).
>
> Please check 03. 02 is generated when merge with most current and remote head not updated correctly. After set remote head correct, 03 is regenerated and is correct one for review. Thanks

This branch has many conflicts, something wrong since push-02, closed this PR and will send a single patch in new PR.

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

PR: https://git.openjdk.java.net/jdk/pull/1657


From minqi at openjdk.java.net  Fri Dec 11 06:20:57 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:57 GMT
Subject: Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region"
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <9Hu8Jqsqm4gG7-yV0AZIZvnOh72CmunbbQhdT-LnjBA=.da14a187-fb1b-4190-9e4b-d06896ad7202@github.com>

On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/1657


From magnus.ihse.bursie at oracle.com  Fri Dec 11 10:29:09 2020
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 11 Dec 2020 11:29:09 +0100
Subject: [patch] link libjvm with -latomic
In-Reply-To: <90671a28-0464-37e7-fc3d-1372a1bf8a77@ubuntu.com>
References: <90671a28-0464-37e7-fc3d-1372a1bf8a77@ubuntu.com>
Message-ID: <845e9d8c-d25c-b1d2-df62-e5130481d297@oracle.com>

If we need -latomic on certain platforms we should add it on those 
platforms, but I would prefer not to add it unconditionally. But then 
again, if you want to add it for a bunch of system which are only 
supported on zero, I will not argue hard against it.

(Also, build-dev is the proper list to discuss changes in the build system)

/Magnus

On 2020-12-09 16:19, Matthias Klose wrote:
> seen with 16+27, zero needs to be linked with -latomic for a few more
> architectures.  Instead of hard-coding these architectures, would it be possible
> to link with -latomic unconditionally? It's the last library on the link
> command, so linking with -Wl,--as-needed -latomic should be do no harm.  Even
> better link with
>
>    -Wl,--push-state,--as-needed -latomic -Wl,--pop-state
>
> --push-state/--pop-state are implemented in binutils 2.28, released in 2017.
>
> It also looks like zero also build on ARM32 again.
>
> Matthias
>
>
> --- a/make/autoconf/libraries.m4
> +++ b/make/autoconf/libraries.m4
> @@ -127,9 +127,13 @@ AC_DEFUN_ONCE([LIB_SETUP_LIBRARIES],
>     # Libatomic library
>     # 32-bit MIPS needs fallback library for 8-byte atomic ops
>     if test "x$OPENJDK_TARGET_OS" = xlinux &&
> -      (test "x$OPENJDK_TARGET_CPU" = xmips ||
> -       test "x$OPENJDK_TARGET_CPU" = xmipsel); then
> -    BASIC_JVM_LIBS="$BASIC_JVM_LIBS -latomic"
> +      (test "x$OPENJDK_TARGET_CPU" = xarm ||
> +       test "x$OPENJDK_TARGET_CPU" = xm68k ||
> +       test "x$OPENJDK_TARGET_CPU" = xmips ||
> +       test "x$OPENJDK_TARGET_CPU" = xmipsel ||
> +       test "x$OPENJDK_TARGET_CPU" = xppc ||
> +       test "x$OPENJDK_TARGET_CPU" = xsh); then
> +    BASIC_JVM_LIBS="$BASIC_JVM_LIBS -Wl,--push-state,--as-needed -latomic
> -Wl,--pop-state"
>     fi
>
>     # perfstat lib



From darcy at openjdk.java.net  Sat Dec 12 19:28:01 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 12 Dec 2020 19:28:01 GMT
Subject: RFR: 8257457: Update --release 16 symbol information for JDK 16 build
 28
Message-ID: <Elq62hhHZUULrEc2m4n0EmQdr1xaqEVFfB3EPntDVVA=.4e4f7517-af96-4f2e-ab40-cf0a7e6962da@github.com>

Update symbol information for --release 16 to JDK 16 b28, includes updates for JEP 390.

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

Commit messages:
 - 8257457

Changes: https://git.openjdk.java.net/jdk/pull/1754/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1754&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257457
  Stats: 235 lines in 4 files changed: 149 ins; 2 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1754.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1754/head:pull/1754

PR: https://git.openjdk.java.net/jdk/pull/1754


From jjg at openjdk.java.net  Sun Dec 13 00:25:07 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 13 Dec 2020 00:25:07 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
Message-ID: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>

This is for JDK16, as a precursor to fixing JDK-8258002.

While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.

The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

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

Commit messages:
 - JDK-8247994: Localize javadoc search

Changes: https://git.openjdk.java.net/jdk16/pull/16/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247994
  Stats: 122 lines in 9 files changed: 88 ins; 6 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16

PR: https://git.openjdk.java.net/jdk16/pull/16


From jjg at openjdk.java.net  Sun Dec 13 00:25:08 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 13 Dec 2020 00:25:08 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <Qw4H-xSPXjuND9jttEWDaJ3q_Fs3m0ckeMwtASd9KKQ=.3e47de4c-4090-4f8c-8f6b-5e15d8f4b077@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

make/CompileInterimLangtools.gmk line 77:

> 75:           Standard.java, \
> 76:       EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \
> 77:       COPY := .gif .png .xml .css .js .js.template .txt javax.tools.JavaCompilerTool, \

Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries.
(Future RFE?)

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From stuefe at openjdk.java.net  Sun Dec 13 15:56:02 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sun, 13 Dec 2020 15:56:02 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
Message-ID: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>

Hi,

May I have reviews please for the following patch.

At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file.

Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch.

Whether or not our SEH handler gets involved currently depends on arbitrary factors: 
- whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test
- Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH).

This patch consists of two parts

A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function.

B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. 

In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream.

The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. 

The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing.

Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch).

----

Notes:
- If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits.

- Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. 

[1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
[2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html
[3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions

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

Commit messages:
 - Make SEH work in gtests

Changes: https://git.openjdk.java.net/jdk/pull/1757/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1757&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8185734
  Stats: 17 lines in 5 files changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1757.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1757/head:pull/1757

PR: https://git.openjdk.java.net/jdk/pull/1757


From dholmes at openjdk.java.net  Mon Dec 14 04:54:55 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 14 Dec 2020 04:54:55 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
In-Reply-To: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
Message-ID: <TBUGGbQzFpATg5tlh3Q3VFunM8E2sx1l2It3xTlf4nw=.d611b065-7979-4e13-ba82-5cd46b40c314@github.com>

On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> May I have reviews please for the following patch.
> 
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file.
> 
> Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch.
> 
> Whether or not our SEH handler gets involved currently depends on arbitrary factors: 
> - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test
> - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH).
> 
> This patch consists of two parts
> 
> A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function.
> 
> B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. 
> 
> In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream.
> 
> The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. 
> 
> The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing.
> 
> Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch).
> 
> ----
> 
> Notes:
> - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits.
> 
> - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. 
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html
> [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions

Hi Thomas,
Not an expert but this all seems quite reasonable to me.
Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1757


From stuefe at openjdk.java.net  Mon Dec 14 05:54:55 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Dec 2020 05:54:55 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
In-Reply-To: <TBUGGbQzFpATg5tlh3Q3VFunM8E2sx1l2It3xTlf4nw=.d611b065-7979-4e13-ba82-5cd46b40c314@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
 <TBUGGbQzFpATg5tlh3Q3VFunM8E2sx1l2It3xTlf4nw=.d611b065-7979-4e13-ba82-5cd46b40c314@github.com>
Message-ID: <wpuwfr9G7dLS0KH1YvoKzkgMjR3jfK-UQvPsFfr9jF0=.d37a3371-2899-47d9-9a96-fc4112b3ffee@github.com>

On Mon, 14 Dec 2020 04:52:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> Not an expert but this all seems quite reasonable to me.
> Thanks,
> David

Thanks David!

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

PR: https://git.openjdk.java.net/jdk/pull/1757


From hannesw at openjdk.java.net  Mon Dec 14 09:52:59 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 14 Dec 2020 09:52:59 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Looks good in general. `<Unnamed>` shouldn't be localized as it is an internal tag (see inline comment).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40:

> 38: var MIN_RESULTS = 3;
> 39: var MAX_RESULTS = 500;
> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##";

`<Unnamed>` is not a string that is ever shown to the user, it is what is used by javadoc to denote the default package (see `toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't be localized as that would break behaviour for code in the default package (and show the localized string as package name, instead of no package name).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java line 256:

> 254:                 sb.append(resources.getText(m.group("key")));
> 255:             } catch (MissingResourceException e) {
> 256:                 sb.append(m.group());

Shouldn't we propagate an error here, or issue a warning? If a key is missing localized properties the value from default properties should be used, so this should never happen, right?

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

Changes requested by hannesw (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/16


From hannesw at openjdk.java.net  Mon Dec 14 09:58:56 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 14 Dec 2020 09:58:56 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
Message-ID: <KALg26trMSMSixmSapr3eujUWZE1bpeppZzzl6EzJF4=.0e009ea3-34b5-4730-a5e8-ddc99e9fb36b@github.com>

On Mon, 14 Dec 2020 09:34:31 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java line 256:
> 
>> 254:                 sb.append(resources.getText(m.group("key")));
>> 255:             } catch (MissingResourceException e) {
>> 256:                 sb.append(m.group());
> 
> Shouldn't we propagate an error here, or issue a warning? If a key is missing localized properties the value from default properties should be used, so this should never happen, right?

I see the added check for "##REPLACE:" in TestSearch.java will catch that case, so I guess it's ok.

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From bchristi at openjdk.java.net  Mon Dec 14 19:41:05 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 14 Dec 2020 19:41:05 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
Message-ID: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>

This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).

Here are the changes covering core libraries code and tests.  Terms were changed as follows:
1. grandfathered -> legacy
2. blacklist -> filter or reject
3. whitelist -> allow or accept
4. master -> coordinator
5. slave -> worker

Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

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

Commit messages:
 - Terminology Cleanup
 - corelibs terminology refresh - bchristi

Changes: https://git.openjdk.java.net/jdk/pull/1771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253497
  Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771


From naoto at openjdk.java.net  Mon Dec 14 20:29:56 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Dec 2020 20:29:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <6mGHyzJFxdntyaLG6CFPBw87a3I7caQuhWGz8hpLneY=.44f01fb2-a150-42e6-a3b0-853d72d24a1b@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Looks good to me.

test/jdk/java/lang/ClassLoader/Assert.java line 65:

> 63: 
> 64:         int switchSource = 0;
> 65:         if (args.length == 0) { // This is  the coordinator version

Extra space between "is" and "the."

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1771


From kcr at openjdk.java.net  Mon Dec 14 20:38:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 14 Dec 2020 20:38:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <ucR9bOGxWzSMGwDy9XYG_xjlDnob_wMLOoksGUE9Xu0=.328ad058-1764-48ca-93ae-9605de0e7aa6@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Marked as reviewed by kcr (Author).

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

PR: https://git.openjdk.java.net/jdk/pull/1771


From joehw at openjdk.java.net  Mon Dec 14 21:15:58 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 14 Dec 2020 21:15:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Marked as reviewed by joehw (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135:

> 133:      * The pattern must be in same format as used in
> 134:      * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135:      * It may define an accept-list of permitted classes, a reject-list of

should accept-list be allow-list to be consistent with the other two RMI classes and ObjectInputFilter.Status#ALLOWED?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:

> 150:      * <p>
> 151:      * Care must be taken when defining such a filter, as defining
> 152:      * an accept-list too restrictive or a too-wide reject-list may

would "an allow-list too restrictive or a reject-list too wide" read better?

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

PR: https://git.openjdk.java.net/jdk/pull/1771


From rriggs at openjdk.java.net  Mon Dec 14 21:15:56 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 14 Dec 2020 21:15:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <K0seMjLKhhmowZfX2kKeybGzSUvezMw5u96B2QtC-Us=.52ca831d-8036-4fc5-9fe0-f3ce0bf9160c@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Marked as reviewed by rriggs (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135:

> 133:      * The pattern must be in same format as used in
> 134:      * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135:      * It may define an accept-list of permitted classes, a reject-list of

accept -> allow for consistency

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:

> 150:      * <p>
> 151:      * Care must be taken when defining such a filter, as defining
> 152:      * an accept-list too restrictive or a too-wide reject-list may

accept -> allow for consistency

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

PR: https://git.openjdk.java.net/jdk/pull/1771


From bchristi at openjdk.java.net  Tue Dec 15 01:38:59 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 01:38:59 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
Message-ID: <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>

On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:
> 
>> 150:      * <p>
>> 151:      * Care must be taken when defining such a filter, as defining
>> 152:      * an accept-list too restrictive or a too-wide reject-list may
> 
> would "an allow-list too restrictive or a reject-list too wide" read better?

I agree that there is room for improvement here.  How about:
"...an allow-list too restrictively, or a reject-list too broadly, may..."
?

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

PR: https://git.openjdk.java.net/jdk/pull/1771


From bchristi at openjdk.java.net  Tue Dec 15 01:46:08 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 01:46:08 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  updates, per code review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1771/files
  - new: https://git.openjdk.java.net/jdk/pull/1771/files/4efa5d43..29525f05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771


From joehw at openjdk.java.net  Tue Dec 15 01:46:09 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 15 Dec 2020 01:46:09 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
 <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
Message-ID: <TZV1N7mk13QAb8casXllkVpuft3iExT_ISM3QYutRh8=.b168d39b-e786-4b14-b9dd-c742ad073b7a@github.com>

On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:
>> 
>>> 150:      * <p>
>>> 151:      * Care must be taken when defining such a filter, as defining
>>> 152:      * an accept-list too restrictive or a too-wide reject-list may
>> 
>> would "an allow-list too restrictive or a reject-list too wide" read better?
>
> I agree that there is room for improvement here.  How about:
> "...an allow-list too restrictively, or a reject-list too broadly, may..."
> ?

That sounds good to me

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

PR: https://git.openjdk.java.net/jdk/pull/1771


From ysatowse at openjdk.java.net  Tue Dec 15 07:26:15 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 15 Dec 2020 07:26:15 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  8257204 and 8256313
  8257204: Remove usage of -Xhtmlversion option from javac
  8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/4b733399..294b3cce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=00-01

  Stats: 182 lines in 9 files changed: 0 ins; 71 del; 111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Tue Dec 15 07:30:59 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 15 Dec 2020 07:30:59 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
Message-ID: <49zhTArZTN6JEApqmuxnSz-_9Jdiuvu8WKuSOTd6fRk=.0345e583-8e0a-4589-8c89-92df7b164013@github.com>

On Fri, 11 Dec 2020 06:44:57 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Please make the review non-draft as well
>
> Thanks for reviewing @jonathan-gibbons 
> This request should have got changed to "non-draft".
> 
> FYI. all tests in jdk-tier1 are still green with the latest changes.
> https://mach5.us.oracle.com/mdash/jobs/yoshiki-jdk-20201211-0555-16616611

This commit includes the changes for 
8257204: Remove usage of -Xhtmlversion option from javac
8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

The changes presume the changes made by a 8247957.   And there is no need to separate them from 8247957, so I would like to pull all changes into this.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From alanb at openjdk.java.net  Tue Dec 15 07:36:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Dec 2020 07:36:57 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
Message-ID: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com>

On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates, per code review

test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45:

> 43:         SocketChannel client = SocketChannel.open ();
> 44:         client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port));
> 45:         SocketChannel channel = server.accept ();

Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there).

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

PR: https://git.openjdk.java.net/jdk/pull/1771


From ihse at openjdk.java.net  Tue Dec 15 08:19:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 08:19:57 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
In-Reply-To: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
Message-ID: <oat5EPX-J-Uaq3iGAWuZaJfx-qOCMzDREfGCJ89eLec=.5b135979-69da-4eaa-8788-34a814b8a2b4@github.com>

On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> May I have reviews please for the following patch.
> 
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file.
> 
> Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch.
> 
> Whether or not our SEH handler gets involved currently depends on arbitrary factors: 
> - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test
> - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH).
> 
> This patch consists of two parts
> 
> A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function.
> 
> B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. 
> 
> In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream.
> 
> The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. 
> 
> The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing.
> 
> Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch).
> 
> ----
> 
> Notes:
> - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits.
> 
> - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. 
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html
> [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions

src/hotspot/os/windows/os_windows.cpp line 515:

> 513: }
> 514: 
> 515: JNIEXPORT

I understand if you do not want to start a code cleanup, but it looks like this should be in an external .hpp file, which could then have been included by all the .cpp files, instead of having the declaration repeated.

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

PR: https://git.openjdk.java.net/jdk/pull/1757


From ihse at openjdk.java.net  Tue Dec 15 08:23:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 08:23:55 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
In-Reply-To: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
Message-ID: <46N6M6v-qUGD1ifgu4lXDNf20hnb0fNTY8PNl432B30=.b5b95c40-3656-4d31-88b4-cad436c51c11@github.com>

On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> May I have reviews please for the following patch.
> 
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file.
> 
> Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch.
> 
> Whether or not our SEH handler gets involved currently depends on arbitrary factors: 
> - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test
> - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH).
> 
> This patch consists of two parts
> 
> A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function.
> 
> B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. 
> 
> In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream.
> 
> The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. 
> 
> The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing.
> 
> Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch).
> 
> ----
> 
> Notes:
> - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits.
> 
> - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. 
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html
> [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions

Build changes look good.

I left a note on the hotspot code; feel free to ignore it if  you want. :)

I agree with your assessment that restoring gtest to the code base would make life simpler. I'm not sure what needs to be done to do that; I suppose it needs someone to write and implement a JBS feature, and to publicly acknowledge that they intent to spend the time needed to keep it up to date with upstream going forward.

(I also agree with your assessment on VEH replacing SEH, as my recollection of working with the runtime system on JRockit was that VEH was superior for the needs of a VM, and much closer to the posix signal model.)

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1757


From stuefe at openjdk.java.net  Tue Dec 15 08:49:57 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Dec 2020 08:49:57 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
In-Reply-To: <oat5EPX-J-Uaq3iGAWuZaJfx-qOCMzDREfGCJ89eLec=.5b135979-69da-4eaa-8788-34a814b8a2b4@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
 <oat5EPX-J-Uaq3iGAWuZaJfx-qOCMzDREfGCJ89eLec=.5b135979-69da-4eaa-8788-34a814b8a2b4@github.com>
Message-ID: <iQ7S70MtRp0SDqYO4MkLtn2780dZhpfmOSBhtfUMPwU=.54f7772d-1086-4e20-a25e-b8c526d037d4@github.com>

On Tue, 15 Dec 2020 08:16:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi,
>> 
>> May I have reviews please for the following patch.
>> 
>> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file.
>> 
>> Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch.
>> 
>> Whether or not our SEH handler gets involved currently depends on arbitrary factors: 
>> - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test
>> - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH).
>> 
>> This patch consists of two parts
>> 
>> A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function.
>> 
>> B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. 
>> 
>> In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream.
>> 
>> The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. 
>> 
>> The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing.
>> 
>> Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch).
>> 
>> ----
>> 
>> Notes:
>> - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits.
>> 
>> - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. 
>> 
>> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
>> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html
>> [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions
>
> src/hotspot/os/windows/os_windows.cpp line 515:
> 
>> 513: }
>> 514: 
>> 515: JNIEXPORT
> 
> I understand if you do not want to start a code cleanup, but it looks like this should be in an external .hpp file, which could then have been included by all the .cpp files, instead of having the declaration repeated.

I agree, but I would like to leave this out for now. I think at some point we may switch to Vectored Exception Handling for all Windows architectures, then we can remove this hideous coding in the gtest launcher main function again. And remove the export.

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

PR: https://git.openjdk.java.net/jdk/pull/1757


From stuefe at openjdk.java.net  Tue Dec 15 09:00:56 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Dec 2020 09:00:56 GMT
Subject: RFR: JDK-8185734: [Windows] Structured Exception Catcher missing
 around gtest execution
In-Reply-To: <46N6M6v-qUGD1ifgu4lXDNf20hnb0fNTY8PNl432B30=.b5b95c40-3656-4d31-88b4-cad436c51c11@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
 <46N6M6v-qUGD1ifgu4lXDNf20hnb0fNTY8PNl432B30=.b5b95c40-3656-4d31-88b4-cad436c51c11@github.com>
Message-ID: <0Jkzd98oZ6ao67ytVmh96ivAEM6wmrCvnmrVFHfPtQI=.671a326a-46cd-4a04-9742-ae75c502d1b0@github.com>

On Tue, 15 Dec 2020 08:20:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Build changes look good.
> 
> I left a note on the hotspot code; feel free to ignore it if you want. :)
> 
> I agree with your assessment that restoring gtest to the code base would make life simpler. I'm not sure what needs to be done to do that; I suppose it needs someone to write and implement a JBS feature, and to publicly acknowledge that they intent to spend the time needed to keep it up to date with upstream going forward.

Yes, and unfortunately I cannot do this - I think this has to be driven from inside Oracle.

> 
> (I also agree with your assessment on VEH replacing SEH, as my recollection of working with the runtime system on JRockit was that VEH was superior for the needs of a VM, and much closer to the posix signal model.)

I also agree. @luhenry 's work convinced me, lets see when it bears fruit.

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/1757


From stuefe at openjdk.java.net  Tue Dec 15 09:05:58 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Dec 2020 09:05:58 GMT
Subject: Integrated: JDK-8185734: [Windows] Structured Exception Catcher
 missing around gtest execution
In-Reply-To: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
References: <jkAq_tJN927ZxMPzjGfDEGWd8heJggt4HOxV68jsWEw=.e2a5c0bf-22fd-4339-9790-4266a2e5e2c1@github.com>
Message-ID: <eHWusp5i_89wuZBtn-ruLZuFEgytV0-WmxHER0w03R0=.9d3c2ded-6031-4fb3-8ae3-4a12e7422c33@github.com>

On Sun, 13 Dec 2020 11:07:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> May I have reviews please for the following patch.
> 
> At the moment, if a crash happens on Windows in gtests, the gtest SEH handler may be invoked instead of our error handler, and we just see a one-line-warning "SEH happened blabala". No hs-err file.
> 
> Even worse, if a crash happens inside the VM as part of the gtests, if our SEH handler does not get involved, this may interfere with VM functionality - e.g. SafeFetch.
> 
> Whether or not our SEH handler gets involved currently depends on arbitrary factors: 
> - whether the fault happens in a VM or Java thread - which have a __try/__except around their start function - or whether the fault happens directly in the thread running the test
> - Faults in generated code are not handled on x86 but are okay x64 (where a SEH handler is registered for the code cache region) or on aarch64 (which uses VEH).
> 
> This patch consists of two parts
> 
> A) It surrounds the gtestlauncher main function with a SEH catcher. For that to work I also need to export the SEH handler from the hotspot. Note: It is difficult to place the SEH catcher: SEH is mutually exclusive with C++ exceptions, and since googletest uses C++ exceptions to communicate test conditions, the only place to put those __try/__except is really up here, at the entry of the gtestlauncher main() function.
> 
> B) This is unfortunately not sufficient since googletest uses its own SEH catcher to wrap each test (see gtest.cc). Since that catcher sits below our catcher on the stack, it superimposes ours. 
> 
> In JBS, @kimbarrett suggested to build gtests with GTEST_HAS_SEH switched off to prevent gtest from using SEH. Unfortunately that won't work since the use of death tests means we need SEH. If we switch GTEST_HAS_SEH off, the death tests don't build. I also do not like this suggestion since this configuration may have a higher chance of bitrotting upstream.
> 
> The solution I found is to switch off exception catching from user code as described in [3] using `--gtest_catch_exceptions=0` or the environment variable `GTEST_CATCH_EXCEPTIONS=0`. Since we do not use C++ exceptions in the hotspot, this is fine. 
> 
> The only drawback is that this cannot be done from within the gtestlauncher itself. Setting the environment variable in the main function - or even during dynamic initialization - does not work because the gtestlauncher itself parses all arguments as part of dynamic initialization. So I did the next best thing and specified `--gtest_catch_exceptions=0` at the places where we run the gtests. This is not perfect, but better than nothing.
> 
> Testing: manually on Windows x64, x86, GH actions (Linux errors seem unrelated to this patch).
> 
> ----
> 
> Notes:
> - If we owned the googletest code - forked it off like we did before - (B) would be very simple to solve by changing the default for `gtest_catch_exceptions` to 1. I still believe maintaining a fork of googletest would have many benefits.
> 
> - Using VEH would have saved us from using __try/__except here, so we would have not needed (A). ATM we use VEH on aarch, SEH on x64+x32. Uniformly switching to VEH has been discussed several times in the past, the last attempt has been by @luhenry (see [1], [2]), but this has not yet materialized. 
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-June/040228.html
> [2] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/040967.html
> [3] https://github.com/google/googletest/blob/master/googletest/docs/advanced.md#disabling-catching-test-thrown-exceptions

This pull request has now been integrated.

Changeset: 568dc29b
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/568dc29b
Stats:     17 lines in 5 files changed: 17 ins; 0 del; 0 mod

8185734: [Windows] Structured Exception Catcher missing around gtest execution

Reviewed-by: dholmes, ihse

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

PR: https://git.openjdk.java.net/jdk/pull/1757


From ihse at openjdk.java.net  Tue Dec 15 09:24:01 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:24:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>
Message-ID: <Yfps7QXZ65d-qGqLGp30xpflAFAwxOXt0FCSPJCBZy4=.27fbdd12-998a-4dbe-8007-9fa02281505c@github.com>

On Tue, 15 Dec 2020 07:26:15 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257204 and 8256313
>   8257204: Remove usage of -Xhtmlversion option from javac
>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

Build change look fine. I have not looked at the other changes.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/893


From ihse at openjdk.java.net  Tue Dec 15 09:27:59 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:27:59 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <Qw4H-xSPXjuND9jttEWDaJ3q_Fs3m0ckeMwtASd9KKQ=.3e47de4c-4090-4f8c-8f6b-5e15d8f4b077@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <Qw4H-xSPXjuND9jttEWDaJ3q_Fs3m0ckeMwtASd9KKQ=.3e47de4c-4090-4f8c-8f6b-5e15d8f4b077@github.com>
Message-ID: <Qa53ZO70gbtLBFhijs-2nPk-ZwMppxBjMZYBQiU4XGs=.54878d14-e980-43ea-8713-b0c27781f7a7@github.com>

On Sun, 13 Dec 2020 00:22:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> make/CompileInterimLangtools.gmk line 77:
> 
>> 75:           Standard.java, \
>> 76:       EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \
>> 77:       COPY := .gif .png .xml .css .js .js.template .txt javax.tools.JavaCompilerTool, \
> 
> Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries.
> (Future RFE?)

I agree. The entire design of CompileJavaModules.gmk needs to be updated. I've been procrastinating on cleaning this up, maybe it's time to get going on it...

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From ihse at openjdk.java.net  Tue Dec 15 09:27:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:27:57 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <EPayynUeJDI3wH52uEQvXuGsoroPkiJ8KkWEqlVo9N8=.dcb277f7-d889-4568-8157-b7f8d6214153@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/16


From ihse at openjdk.java.net  Tue Dec 15 13:20:25 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 13:20:25 GMT
Subject: RFR: 8258407: Split up CompileJavaModules.gmk into
 make/modules/$M/Java.gmk
Message-ID: <yI_I0Q9FK2YrMON0GnUlfsoqCoEcq0xPazOBKbuTAQE=.7c0be939-45f9-4155-ad76-4e9d5684ec78@github.com>

Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed.

The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`.

I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch).

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

Commit messages:
 - $($(MODULE)_COPY_EXTRA) target is not used anymore
 - Remove module prefix from java variables
 - Remove debug code mistakenly pushed
 - Move some more module-specific stuff to Java.gmk files
 - Only include the module Java.gmk file we need
 - First step: break out Java settings to separate files

Changes: https://git.openjdk.java.net/jdk/pull/1779/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1779&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258407
  Stats: 2118 lines in 47 files changed: 1556 ins; 548 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1779.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1779/head:pull/1779

PR: https://git.openjdk.java.net/jdk/pull/1779


From ihse at openjdk.java.net  Tue Dec 15 13:25:33 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 13:25:33 GMT
Subject: RFR: 8258407: Split up CompileJavaModules.gmk into
 make/modules/$M/Java.gmk [v2]
In-Reply-To: <yI_I0Q9FK2YrMON0GnUlfsoqCoEcq0xPazOBKbuTAQE=.7c0be939-45f9-4155-ad76-4e9d5684ec78@github.com>
References: <yI_I0Q9FK2YrMON0GnUlfsoqCoEcq0xPazOBKbuTAQE=.7c0be939-45f9-4155-ad76-4e9d5684ec78@github.com>
Message-ID: <Zex9PwP2zCaBMZ0uCYDz95RCZLEZtPe4xN5Dej77BtM=.6bd1e333-5b7f-4333-8f4e-172f336cd814@github.com>

> Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed.
> 
> The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`.
> 
> I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename DISABLED_WARNINGS to DISABLED_WARNINGS_java to avoid overwriting the global variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1779/files
  - new: https://git.openjdk.java.net/jdk/pull/1779/files/09b5bee7..1e1cb858

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1779&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1779&range=00-01

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1779.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1779/head:pull/1779

PR: https://git.openjdk.java.net/jdk/pull/1779


From ihse at openjdk.java.net  Tue Dec 15 14:40:34 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 14:40:34 GMT
Subject: RFR: 8258407: Split up CompileJavaModules.gmk into
 make/modules/$M/Java.gmk [v3]
In-Reply-To: <yI_I0Q9FK2YrMON0GnUlfsoqCoEcq0xPazOBKbuTAQE=.7c0be939-45f9-4155-ad76-4e9d5684ec78@github.com>
References: <yI_I0Q9FK2YrMON0GnUlfsoqCoEcq0xPazOBKbuTAQE=.7c0be939-45f9-4155-ad76-4e9d5684ec78@github.com>
Message-ID: <9xkNifNu1u9_edtzKO1GsygtwNwAM91k1o6iaw0KvS4=.c0c96c97-c13f-4f1b-97fe-a79abace039c@github.com>

> Right now `CompileJavaModules.gmk` contains two different part: one part with the functionality needed to compile a java module, and one part were all special requirements for all modules are listed.
> 
> The second part should be removed from `CompileJavaModules.gmk`, and instead listed directly for each individual module in `make/modules/$M/Java.gmk`.
> 
> I used a special-written shell script to automatically extract the module-specific part from CompileJavaModules.gmk into the respective Java.gmk files, to avoid risking any hard-to-detect copy/paste errors. After this I did a `sed -i` to remove the module-specific prefix. All this makes me confident that I have correctly moved the variables (I realize this is hard to verify from the patch).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Final bug fixes...

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1779/files
  - new: https://git.openjdk.java.net/jdk/pull/1779/files/1e1cb858..a869f4b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1779&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1779&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1779.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1779/head:pull/1779

PR: https://git.openjdk.java.net/jdk/pull/1779


From ihse at openjdk.java.net  Tue Dec 15 16:16:07 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 16:16:07 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to conf
 dir
Message-ID: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>

The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.

Thus the actual lists of module sets should move to the `make/conf` directory.

This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

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

Commit messages:
 - 8258411: Move module set configuration from Modules.gmk to conf dir

Changes: https://git.openjdk.java.net/jdk/pull/1781/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258411
  Stats: 348 lines in 2 files changed: 179 ins; 162 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1781/head:pull/1781

PR: https://git.openjdk.java.net/jdk/pull/1781


From alanb at openjdk.java.net  Tue Dec 15 16:56:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Dec 2020 16:56:57 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir
In-Reply-To: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
Message-ID: <rwiOXpfRt9ly8PIiv4pucHymkagxNhYAf5MsdddEkgE=.c33e46a5-1615-4504-9304-e5c5081374e3@github.com>

On Tue, 15 Dec 2020 16:11:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
> 
> Thus the actual lists of module sets should move to the `make/conf` directory.
> 
> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

I really dislike patch as it mixes up several things in module-sets.conf. If you really need to move configuration out of Modules.gmk (and I see no reason to do this) then please look at separating out the static mapping of modules to class loaders, the modules used for the interim builds, and the modules used to create API docs.

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

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 17:56:02 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 17:56:02 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir
In-Reply-To: <rwiOXpfRt9ly8PIiv4pucHymkagxNhYAf5MsdddEkgE=.c33e46a5-1615-4504-9304-e5c5081374e3@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <rwiOXpfRt9ly8PIiv4pucHymkagxNhYAf5MsdddEkgE=.c33e46a5-1615-4504-9304-e5c5081374e3@github.com>
Message-ID: <eVL3WyzNwG_6Hbz3wJC_Ok6Psm394DKYGUQPvsGzioc=.d4e77b42-54e9-44e1-896a-94493a9b29d3@github.com>

On Tue, 15 Dec 2020 16:53:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
>> 
>> Thus the actual lists of module sets should move to the `make/conf` directory.
>> 
>> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.
>
> I really dislike patch as it mixes up several things in module-sets.conf. If you really need to move configuration out of Modules.gmk (and I see no reason to do this) then please look at separating out the static mapping of modules to class loaders, the modules used for the interim builds, and the modules used to create API docs.

@AlanBateman It's not really more mixed-up than it was previously in Modules.gmk, since I lifted the code mostly unchanged from there. But sure, I can split it up further; I agree that it might make sense to do so.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 17:56:11 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 17:56:11 GMT
Subject: RFR: 8258420: Move URL configuration from Docs.gmk to conf dir
Message-ID: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>

In `Docs.gmk` there are some hard-coded links to online URL documentation and bug reporting locations. These should not reside in the make file per se, but instead move to the `make/conf` directory.

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

Commit messages:
 - 8258420: Move URL configuration from Docs.gmk to conf dir

Changes: https://git.openjdk.java.net/jdk/pull/1785/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1785&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258420
  Stats: 39 lines in 2 files changed: 33 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1785.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1785/head:pull/1785

PR: https://git.openjdk.java.net/jdk/pull/1785


From ihse at openjdk.java.net  Tue Dec 15 18:15:28 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 18:15:28 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
Message-ID: <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>

> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
> 
> Thus the actual lists of module sets should move to the `make/conf` directory.
> 
> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Split up module-sets.conf

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1781/files
  - new: https://git.openjdk.java.net/jdk/pull/1781/files/9d90330a..df445d6e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=00-01

  Stats: 417 lines in 5 files changed: 238 ins; 177 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1781/head:pull/1781

PR: https://git.openjdk.java.net/jdk/pull/1781


From alanb at openjdk.java.net  Tue Dec 15 19:22:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Dec 2020 19:22:00 GMT
Subject: RFR: 8258420: Move URL configuration from Docs.gmk to conf dir
In-Reply-To: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
References: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
Message-ID: <S5M1k-lHx9xwRSirPBBL2bFh-edWkOs8Avd4LzHjRT8=.e9ab3b4e-fa69-4490-a63d-479eb3a69d3c@github.com>

On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In `Docs.gmk` there are some hard-coded links to online URL documentation and bug reporting locations. These should not reside in the make file per se, but instead move to the `make/conf` directory.

This looks okay me to but I can't help thinking that javadoc.conf should also be the place to list the root modules for javadoc (PR 1781 puts them in oddly named module-sets-docs.conf).

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

PR: https://git.openjdk.java.net/jdk/pull/1785


From alanb at openjdk.java.net  Tue Dec 15 19:30:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Dec 2020 19:30:57 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
Message-ID: <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>

On Tue, 15 Dec 2020 18:15:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
>> 
>> Thus the actual lists of module sets should move to the `make/conf` directory.
>> 
>> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Split up module-sets.conf

This looks better but I think we need to find better names for the conf files. Prefixing them with "module-sets" looks really strange.
JRE_TOOL_MODULES in module-sets-classloaders.conf might also need to be re-examined because it is not used to generate ModuleLoaderMap. Instead it was defined in Modules.gmk for the legacy-jre-image build target.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 20:29:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 20:29:55 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
Message-ID: <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>

On Tue, 15 Dec 2020 19:28:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Split up module-sets.conf
>
> This looks better but I think we need to find better names for the conf files. Prefixing them with "module-sets" looks really strange.
> JRE_TOOL_MODULES in module-sets-classloaders.conf might also need to be re-examined because it is not used to generate ModuleLoaderMap. Instead it was defined in Modules.gmk for the legacy-jre-image build target.

I thought it was a consistent and clear naming scheme. :-) But I guess to each their own...

Would `classloader-modules.conf`, `docs-modules.conf` and `build-modules.con` be better? Otherwise you'll need to come up with any better solutions yourself, since I'm starting to run out of ideas.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 20:34:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 20:34:55 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
Message-ID: <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>

On Tue, 15 Dec 2020 20:27:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This looks better but I think we need to find better names for the conf files. Prefixing them with "module-sets" looks really strange.
>> JRE_TOOL_MODULES in module-sets-classloaders.conf might also need to be re-examined because it is not used to generate ModuleLoaderMap. Instead it was defined in Modules.gmk for the legacy-jre-image build target.
>
> I thought it was a consistent and clear naming scheme. :-) But I guess to each their own...
> 
> Would `classloader-modules.conf`, `docs-modules.conf` and `build-modules.con` be better? Otherwise you'll need to come up with any better solutions yourself, since I'm starting to run out of ideas.

As for `JRE_TOOL_MODULES`, I understand what you mean but it is at least kind of a "sibling" to the others. After all, we use these sets of modules together to form the set of modules for the JRE:

JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \
    $(PLATFORM_MODULES) $(JRE_TOOL_MODULES))

So given that `BOOT_MODULES` and `PLATFORM_MODULE` has a role to play here as well, I think it would be odd *not* to have `JRE_TOOL_MODULES` defined at the same place.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 20:37:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 20:37:55 GMT
Subject: RFR: 8258420: Move URL configuration from Docs.gmk to conf dir
In-Reply-To: <S5M1k-lHx9xwRSirPBBL2bFh-edWkOs8Avd4LzHjRT8=.e9ab3b4e-fa69-4490-a63d-479eb3a69d3c@github.com>
References: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
 <S5M1k-lHx9xwRSirPBBL2bFh-edWkOs8Avd4LzHjRT8=.e9ab3b4e-fa69-4490-a63d-479eb3a69d3c@github.com>
Message-ID: <ls5MzdlwrUDUVIsoX0DbNMzkNc-JcBvV8bweUB_OtRo=.16fec479-7aa8-48d6-8b31-654851ab755b@github.com>

On Tue, 15 Dec 2020 19:19:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In `Docs.gmk` there are some hard-coded links to online URL documentation and bug reporting locations. These should not reside in the make file per se, but instead move to the `make/conf` directory.
>
> This looks okay me to but I can't help thinking that javadoc.conf should also be the place to list the root modules for javadoc (PR 1781 puts them in oddly named module-sets-docs.conf).

Maybe, but if anything I think they should rather merge with the upcoming `conf/branding.conf` (see JDK-8258426). I think that once we got all configuration collected in one place, it's easier to see how and if we can unify them.

At this stage, I'd like to concentrate on just splitting out the configuration part from the makefiles.

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

PR: https://git.openjdk.java.net/jdk/pull/1785


From ihse at openjdk.java.net  Tue Dec 15 20:40:07 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 20:40:07 GMT
Subject: RFR: 8258426: Split up autoconf/version-numbers and move it to conf
 dir
Message-ID: <ERpH89pwEDW_zQ_JXznwBbICmKGgrRcgktmxHkWqbrs=.cb7e6f43-3031-4176-b72b-7e85ef15c9e2@github.com>

The file `make/autoconf/version-numbers` is plagued by a two-fold problem: first of all, it's a configuration file, not a part of autoconf, so it should reside in `make/conf` instead of `make/autoconf`.

Secondly, contrary to the name, it does not only contain version numbers, but also the branding properties (company name, product name, etc). This should be split out into a separate branding configuration file.

This is the last patch in the series of moving configuration into `make/conf`.

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

Commit messages:
 - 8258426: Split up autoconf/version-numbers and move it to conf dir

Changes: https://git.openjdk.java.net/jdk/pull/1786/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1786&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258426
  Stats: 151 lines in 7 files changed: 81 ins; 55 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1786/head:pull/1786

PR: https://git.openjdk.java.net/jdk/pull/1786


From ihse at openjdk.java.net  Tue Dec 15 20:50:54 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 20:50:54 GMT
Subject: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version
In-Reply-To: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
Message-ID: <OwNSHqBRBnB-KeuNrk71V4cwL6lddf0OIWbgjEL-jsY=.cfacc65a-4cfb-4bec-be25-b8c7b560bfba@github.com>

On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available.

Marked as reviewed by ihse (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From ihse at openjdk.java.net  Tue Dec 15 21:17:14 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 21:17:14 GMT
Subject: RFR: 8258426: Split up autoconf/version-numbers and move it to
 conf dir [v2]
In-Reply-To: <ERpH89pwEDW_zQ_JXznwBbICmKGgrRcgktmxHkWqbrs=.cb7e6f43-3031-4176-b72b-7e85ef15c9e2@github.com>
References: <ERpH89pwEDW_zQ_JXznwBbICmKGgrRcgktmxHkWqbrs=.cb7e6f43-3031-4176-b72b-7e85ef15c9e2@github.com>
Message-ID: <9O1KoB8zL6iGMcMbjmo_wM0bhV1AqNH4tHavRAt3FOQ=.d13a9d3d-e16c-4c2c-a51a-928b0070f064@github.com>

> The file `make/autoconf/version-numbers` is plagued by a two-fold problem: first of all, it's a configuration file, not a part of autoconf, so it should reside in `make/conf` instead of `make/autoconf`.
> 
> Secondly, contrary to the name, it does not only contain version numbers, but also the branding properties (company name, product name, etc). This should be split out into a separate branding configuration file.
> 
> This is the last patch in the series of moving configuration into `make/conf`.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update submit.yml

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1786/files
  - new: https://git.openjdk.java.net/jdk/pull/1786/files/b40db3af..bcd3b338

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1786&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1786&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1786/head:pull/1786

PR: https://git.openjdk.java.net/jdk/pull/1786


From ihse at openjdk.java.net  Tue Dec 15 22:40:53 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:40:53 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v3]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <ZQKkeZnC0DkuVXm10pUBOC7eHbUSXleDRyOTUHMrW5k=.07290ec9-fd83-46bc-81bb-3b6423327507@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [ ] java.base
> - [ ] java.desktop
> - [x] jdk.compiler
> - [ ] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move macosxicons from share to macosx

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/f0047704..00dc61c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=01-02

  Stats: 1 line in 2 files changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From mchung at openjdk.java.net  Tue Dec 15 22:49:57 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 15 Dec 2020 22:49:57 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
Message-ID: <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>

On Tue, 15 Dec 2020 20:32:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I thought it was a consistent and clear naming scheme. :-) But I guess to each their own...
>> 
>> Would `classloader-modules.conf`, `docs-modules.conf` and `build-modules.con` be better? Otherwise you'll need to come up with any better solutions yourself, since I'm starting to run out of ideas.
>
> As for `JRE_TOOL_MODULES`, I understand what you mean but it is at least kind of a "sibling" to the others. After all, we use these sets of modules together to form the set of modules for the JRE:
> 
> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \
>     $(PLATFORM_MODULES) $(JRE_TOOL_MODULES))
> 
> So given that `BOOT_MODULES` and `PLATFORM_MODULE` has a role to play here as well, I think it would be odd *not* to have `JRE_TOOL_MODULES` defined at the same place.

`JRE_TOOL_MODULES` started with more than one modules in JDK 9:

JRE_TOOL_MODULES += \
    jdk.jdwp.agent \
    jdk.pack \
    jdk.scripting.nashorn.shell \
    #

Since only `jdk.jdwp.agent` one module is left for `JRE_TOOL_MODULES`, as you are refactoring this file, I suggest to get rid of `JRE_TOOL_MODULES` and explicitly name `jdk.jdwp.agent` in `JRE_MODULES`.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 22:56:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:56:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [ ] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Update comment refering to "make" dir
 - Move new symbols to jdk.compiler
 - Merge branch 'master' into shuffle-data
 - Move macosxicons from share to macosx
 - Move to share/data, and move jdwp.spec to java.se
 - Update references in test
 - Step 2: Update references
 - First stage, move actual data files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/00dc61c1..68b252b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=02-03

  Stats: 38451 lines in 948 files changed: 28535 ins; 6611 del; 3305 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec 15 22:56:16 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:56:16 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
Message-ID: <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?

> test/jdk/java/util/Locale/LSRDataTest.java line 57:
> 
>> 55:     // path to the lsr file from the make folder, this test relies on the
>> 56:     // relative path to the file in the make folder, considering
>> 57:     // test and make will always exist in the same jdk layout
> 
> The comment refers to the "make" folder. (line 55 as well).

Fixed. Thank you for noticing!

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Tue Dec 15 23:03:21 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 23:03:21 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v3]
In-Reply-To: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
Message-ID: <z7as4PibNpq42qgcj0cQKOTcCTtEiVwGZ8yGvq7JzCw=.c0cffa62-e450-4799-8d75-d521be6e8d40@github.com>

> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
> 
> Thus the actual lists of module sets should move to the `make/conf` directory.
> 
> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove JRE_TOOL_MODULES and inline jdk.jdwp.agent in JRE definition

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1781/files
  - new: https://git.openjdk.java.net/jdk/pull/1781/files/df445d6e..ef9d53cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=01-02

  Stats: 7 lines in 3 files changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1781/head:pull/1781

PR: https://git.openjdk.java.net/jdk/pull/1781


From mchung at openjdk.java.net  Tue Dec 15 23:03:21 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 15 Dec 2020 23:03:21 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
Message-ID: <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>

On Tue, 15 Dec 2020 22:47:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> As for `JRE_TOOL_MODULES`, I understand what you mean but it is at least kind of a "sibling" to the others. After all, we use these sets of modules together to form the set of modules for the JRE:
>> 
>> JRE_MODULES += $(filter $(ALL_MODULES), $(BOOT_MODULES) \
>>     $(PLATFORM_MODULES) $(JRE_TOOL_MODULES))
>> 
>> So given that `BOOT_MODULES` and `PLATFORM_MODULE` has a role to play here as well, I think it would be odd *not* to have `JRE_TOOL_MODULES` defined at the same place.
>
> `JRE_TOOL_MODULES` started with more than one modules in JDK 9:
> 
> JRE_TOOL_MODULES += \
>     jdk.jdwp.agent \
>     jdk.pack \
>     jdk.scripting.nashorn.shell \
>     #
> 
> Since only `jdk.jdwp.agent` one module is left for `JRE_TOOL_MODULES`, as you are refactoring this file, I suggest to get rid of `JRE_TOOL_MODULES` and explicitly name `jdk.jdwp.agent` in `JRE_MODULES`.

Do you see a way to get rid of `DOCS_MODULES` but determine this set at build time?  IIRC it was added for expediency for [JDK-8172312](https://bugs.openjdk.java.net/browse/JDK-8172312).   This is the set of JDK (non-Java SE) modules (excluding `jdk.internal.*` modules and `jdk.unsupported` and also platform-specific modules). 

As for the conf file for module to class loader mapping, I actually like one single file `jdk-modules.conf` to enumerate all JDK modules.   Currently it only defines the list of modules defined to boot and platform class loader but excludes any modules defined to application class loaders.  I consider to enumerate all modules in this file and the build can verify if any module is missing.

`module-sets-build.conf` is a bit awkward and I will give more thought on naming ideas.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Tue Dec 15 23:20:03 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 23:20:03 GMT
Subject: RFR: 8258445: Move make/templates to make/data
Message-ID: <MdHgDFE-9b3PrS4_xprqfLCnvuGFSH8-3QIS-YdRr3E=.bda211d2-c08b-4dc1-8edc-542a63ca5a48@github.com>

The `templates` directory in `make` is an odd bird. It actually contains data files that the license checker needs, so it should move to `make/data`.

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

Commit messages:
 - 8258445: Move make/templates to make/data

Changes: https://git.openjdk.java.net/jdk/pull/1790/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1790&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258445
  Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1790.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1790/head:pull/1790

PR: https://git.openjdk.java.net/jdk/pull/1790


From ihse at openjdk.java.net  Tue Dec 15 23:33:04 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 23:33:04 GMT
Subject: RFR: 8258447: Move make/hotspot/hotspot.script to make/scripts
Message-ID: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>

The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension).

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

Commit messages:
 - 8258447: Move make/hotspot/hotspot.script to make/scripts

Changes: https://git.openjdk.java.net/jdk/pull/1791/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1791&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258447
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1791.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1791/head:pull/1791

PR: https://git.openjdk.java.net/jdk/pull/1791


From ihse at openjdk.java.net  Tue Dec 15 23:42:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 23:42:06 GMT
Subject: RFR: 8258449: Move make/hotspot/symbols to make/data
Message-ID: <5xNHtr0piHsmCR5c17c1zzwfeAdUK1YxzrrulIXcy5w=.88bfdc68-de83-41c7-9fc6-2e69ded5bfa2@github.com>

The "symbol" files in make/hotspot/symbols are a list of exported symbols from libjvm. As such, they are an essential data source for the build system, and they should reside in make/data, not mixed with the hotspot make source code.

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

Commit messages:
 - 8258449: Move make/hotspot/symbols to make/data

Changes: https://git.openjdk.java.net/jdk/pull/1793/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1793&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258449
  Stats: 6 lines in 7 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1793.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1793/head:pull/1793

PR: https://git.openjdk.java.net/jdk/pull/1793


From mchung at openjdk.java.net  Tue Dec 15 23:53:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 15 Dec 2020 23:53:56 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
 <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
Message-ID: <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>

On Tue, 15 Dec 2020 22:58:47 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `JRE_TOOL_MODULES` started with more than one modules in JDK 9:
>> 
>> JRE_TOOL_MODULES += \
>>     jdk.jdwp.agent \
>>     jdk.pack \
>>     jdk.scripting.nashorn.shell \
>>     #
>> 
>> Since only `jdk.jdwp.agent` one module is left for `JRE_TOOL_MODULES`, as you are refactoring this file, I suggest to get rid of `JRE_TOOL_MODULES` and explicitly name `jdk.jdwp.agent` in `JRE_MODULES`.
>
> Do you see a way to get rid of `DOCS_MODULES` but determine this set at build time?  IIRC it was added for expediency for [JDK-8172312](https://bugs.openjdk.java.net/browse/JDK-8172312).   This is the set of Java SE + JDK modules that excludes `jdk.internal.*` modules and `jdk.unsupported` and also platform-specific modules.   (History: the docs bundle generated prior to JDK 9 only included platform-neutral APIs.)
> 
> As for the conf file for module to class loader mapping, I actually like one single file `jdk-modules.conf` to enumerate all JDK modules.   Currently it only defines the list of modules defined to boot and platform class loader but excludes any modules defined to application class loaders.  I consider to enumerate all modules in this file and the build can verify if any module is missing.
> 
> `module-sets-build.conf` is a bit awkward and I will give more thought on naming ideas.

Can any of `INTERIM_IMAGE_MODULES` , `HOTSPOT_MODULES` and `LANGTOOLS_MODULES` be inlined in the appropriate .gmk file?

`INTERIM_IMAGE_MODULES` is for building interim image.  If it has to be defined in a conf file, I like its name be explicit and match the target or makefile, for example, `interim-images.conf` or `InterimImages.conf`.    This way I can tell what this conf file intends for.  What do you think?

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Wed Dec 16 00:17:02 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 00:17:02 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
 <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
 <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>
Message-ID: <x67oas0wEquTD4RV8SP-WRH7qzFD3MVRBc_6GH3-74E=.5d85502a-19fe-4400-844e-fc27a6a961dc@github.com>

On Tue, 15 Dec 2020 23:50:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Do you see a way to get rid of `DOCS_MODULES` but determine this set at build time?  IIRC it was added for expediency for [JDK-8172312](https://bugs.openjdk.java.net/browse/JDK-8172312).   This is the set of Java SE + JDK modules that excludes `jdk.internal.*` modules and `jdk.unsupported` and also platform-specific modules.   (History: the docs bundle generated prior to JDK 9 only included platform-neutral APIs.)
>> 
>> As for the conf file for module to class loader mapping, I actually like one single file `jdk-modules.conf` to enumerate all JDK modules.   Currently it only defines the list of modules defined to boot and platform class loader but excludes any modules defined to application class loaders.  I consider to enumerate all modules in this file and the build can verify if any module is missing.
>> 
>> `module-sets-build.conf` is a bit awkward and I will give more thought on naming ideas.
>
> Can any of `INTERIM_IMAGE_MODULES` , `HOTSPOT_MODULES` and `LANGTOOLS_MODULES` be inlined in the appropriate .gmk file?
> 
> `INTERIM_IMAGE_MODULES` is for building interim image.  If it has to be defined in a conf file, I like its name be explicit and match the target or makefile, for example, `interim-images.conf` or `InterimImages.conf`.    This way I can tell what this conf file intends for.  What do you think?

@mlchung The entire point of this exercise is to *not* have hard-coded lists of modules in make files... 

Having hard-coded lists have come back to bite us, time after time again. We try to auto-discover everything that is possible. For these sets of modules, however, auto-discovery is not possible since these lists *define* what we mean by e.g. platform modules or an interim image.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Wed Dec 16 00:17:02 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 00:17:02 GMT
Subject: RFR: 8258447: Move make/hotspot/hotspot.script to make/scripts
In-Reply-To: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>
References: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>
Message-ID: <5eItiU_W66u3rfiyNFuu18Oiq3Qu55gN7ZMQlmiU-gs=.8a98404d-12a2-4765-bd09-eacdb7fb8616@github.com>

On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension).

Can someone from hotspot please confirm if this script is still needed/used?

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

PR: https://git.openjdk.java.net/jdk/pull/1791


From ysatowse at openjdk.java.net  Wed Dec 16 02:09:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 16 Dec 2020 02:09:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <Yfps7QXZ65d-qGqLGp30xpflAFAwxOXt0FCSPJCBZy4=.27fbdd12-998a-4dbe-8007-9fa02281505c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>
 <Yfps7QXZ65d-qGqLGp30xpflAFAwxOXt0FCSPJCBZy4=.27fbdd12-998a-4dbe-8007-9fa02281505c@github.com>
Message-ID: <8zKt8T3B6UDl5dUP47zJZXAj9PDCuZkO3AsrK1qmfHg=.50d5af51-f1bd-42e8-9852-983ae52a2390@github.com>

On Tue, 15 Dec 2020 09:20:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> Build change look fine. I have not looked at the other changes.

I found an issue when called from javac, so will convert to draft until the issue resolved.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From alanb at openjdk.java.net  Wed Dec 16 10:15:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 10:15:56 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
Message-ID: <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>

On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.
>
> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?

I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives?

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From alanb at openjdk.java.net  Wed Dec 16 10:23:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 10:23:55 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <x67oas0wEquTD4RV8SP-WRH7qzFD3MVRBc_6GH3-74E=.5d85502a-19fe-4400-844e-fc27a6a961dc@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
 <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
 <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>
 <x67oas0wEquTD4RV8SP-WRH7qzFD3MVRBc_6GH3-74E=.5d85502a-19fe-4400-844e-fc27a6a961dc@github.com>
Message-ID: <lx-WvJ4UCgbzCv9uhKpuj-5p8wD0cw_M6qvGYUOAvfI=.ec4c6a90-f111-48d4-9246-6e6fcd0a9bd7@github.com>

On Wed, 16 Dec 2020 00:14:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Can any of `INTERIM_IMAGE_MODULES` , `HOTSPOT_MODULES` and `LANGTOOLS_MODULES` be inlined in the appropriate .gmk file?
>> 
>> `INTERIM_IMAGE_MODULES` is for building interim image.  If it has to be defined in a conf file, I like its name be explicit and match the target or makefile, for example, `interim-images.conf` or `InterimImages.conf`.    This way I can tell what this conf file intends for.  What do you think?
>
> @mlchung The entire point of this exercise is to *not* have hard-coded lists of modules in make files... 
> 
> Having hard-coded lists have come back to bite us, time after time again. We try to auto-discover everything that is possible. For these sets of modules, however, auto-discovery is not possible since these lists *define* what we mean by e.g. platform modules or an interim image.

The update to JRE_MODULES in Images.gmk resolves my comment above. However, the naming for the configuration is still a bit odd,  e.g. module-sets-classloaders.conf should be something like module-loader-map.conf as used to generate ModuleLoaderMap.java in the build.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From rwestberg at openjdk.java.net  Wed Dec 16 10:53:07 2020
From: rwestberg at openjdk.java.net (Robin Westberg)
Date: Wed, 16 Dec 2020 10:53:07 GMT
Subject: RFR: 8258477: Pre-submit testing using GitHub Actions should merge
 changes from target branch
Message-ID: <AjDSrcfDfZuNWrLpkfNXeFpsABj8bhvwZYNInSXKDyU=.9c36ae6c-eabc-4029-904f-c09e64814082@github.com>

Normally when running GitHub Actions on a pull request, what is checked out is the merge of the pull request with the latest changes on the target branch. This ensure that what is tested is as close as possible to what will actually be the result of integrating said pull request. 

In our use of GitHub Actions, we don't run directly on pull requests but instead allow contributors to run them in their own personal forks. In that context, there is no notion of a target branch. However, we can infer the target project and branch by encoding this in the workflow file. This allows us to perform the same merge manually, and achieve the same behaviour. 

The change also adds an option to disable this automated merge when launching the workflow manually, which could be useful when investigating unexpected test failures.

Note that downstream projects picking up this change will have to adapt the workflow file to keep using these actions for pre-submit testing. This has been a common request from downstream projects, but could also be done in a separate change (or not at all).

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

Commit messages:
 - Allow opting out of automated merge on manual runs
 - Initial implementation

Changes: https://git.openjdk.java.net/jdk/pull/1801/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1801&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258477
  Stats: 117 lines in 1 file changed: 116 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1801/head:pull/1801

PR: https://git.openjdk.java.net/jdk/pull/1801


From alanb at openjdk.java.net  Wed Dec 16 11:33:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 11:33:55 GMT
Subject: RFR: 8258420: Move URL configuration from Docs.gmk to conf dir
In-Reply-To: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
References: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
Message-ID: <2ZrNW23Z_MgR1Er_9DDVV_xxEjYx7nSRQxAKn1B0og0=.1cb14762-b657-4334-87a9-1898e6ed2c21@github.com>

On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In `Docs.gmk` there are some hard-coded links to online URL documentation and bug reporting locations. These should not reside in the make file per se, but instead move to the `make/conf` directory.

Okay.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1785


From ihse at openjdk.java.net  Wed Dec 16 13:40:58 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 13:40:58 GMT
Subject: Integrated: 8258420: Move URL configuration from Docs.gmk to conf dir
In-Reply-To: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
References: <WHKu2AMJ-9PZ-dRxnl_L1nUTmXsrkLekslfP5g3s6gI=.95b1392c-b440-41bc-9837-034f0beaedfb@github.com>
Message-ID: <nV8hJ59H7nOEWnMU2DbzvolXOpoe1KhHlIdNi3iVQp8=.01046366-894f-498c-949b-140053ca7dc6@github.com>

On Tue, 15 Dec 2020 17:50:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In `Docs.gmk` there are some hard-coded links to online URL documentation and bug reporting locations. These should not reside in the make file per se, but instead move to the `make/conf` directory.

This pull request has now been integrated.

Changeset: 6eca2960
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6eca2960
Stats:     39 lines in 2 files changed: 33 ins; 6 del; 0 mod

8258420: Move URL configuration from Docs.gmk to conf dir

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/1785


From ihse at openjdk.java.net  Wed Dec 16 13:52:22 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 13:52:22 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v4]
In-Reply-To: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
Message-ID: <emblyngWBHmY2lY25lW_Re4rxAQetFt0McGYkd4rbYg=.465baddc-0ad0-4f52-a6ac-1c7a75783336@github.com>

> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
> 
> Thus the actual lists of module sets should move to the `make/conf` directory.
> 
> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Rename configuration files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1781/files
  - new: https://git.openjdk.java.net/jdk/pull/1781/files/ef9d53cb..199832a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=02-03

  Stats: 3 lines in 4 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1781/head:pull/1781

PR: https://git.openjdk.java.net/jdk/pull/1781


From thomas.stuefe at gmail.com  Wed Dec 16 13:54:29 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 16 Dec 2020 14:54:29 +0100
Subject: RFR: 8258477: Pre-submit testing using GitHub Actions should
 merge changes from target branch
In-Reply-To: <AjDSrcfDfZuNWrLpkfNXeFpsABj8bhvwZYNInSXKDyU=.9c36ae6c-eabc-4029-904f-c09e64814082@github.com>
References: <AjDSrcfDfZuNWrLpkfNXeFpsABj8bhvwZYNInSXKDyU=.9c36ae6c-eabc-4029-904f-c09e64814082@github.com>
Message-ID: <CAA-vtUwGC=HfhEUeFrdUObWf7+rZahAUcGsNf09VF27p+HcqRA@mail.gmail.com>

Hi Robin,

does this mean tests won't run on branches which cannot be merged with the
assumed target branch?

Thanks, Thomas


On Wed, Dec 16, 2020 at 11:55 AM Robin Westberg <rwestberg at openjdk.java.net>
wrote:

> Normally when running GitHub Actions on a pull request, what is checked
> out is the merge of the pull request with the latest changes on the target
> branch. This ensure that what is tested is as close as possible to what
> will actually be the result of integrating said pull request.
>
> In our use of GitHub Actions, we don't run directly on pull requests but
> instead allow contributors to run them in their own personal forks. In that
> context, there is no notion of a target branch. However, we can infer the
> target project and branch by encoding this in the workflow file. This
> allows us to perform the same merge manually, and achieve the same
> behaviour.
>
> The change also adds an option to disable this automated merge when
> launching the workflow manually, which could be useful when investigating
> unexpected test failures.
>
> Note that downstream projects picking up this change will have to adapt
> the workflow file to keep using these actions for pre-submit testing. This
> has been a common request from downstream projects, but could also be done
> in a separate change (or not at all).
>
> -------------
>
> Commit messages:
>  - Allow opting out of automated merge on manual runs
>  - Initial implementation
>
> Changes: https://git.openjdk.java.net/jdk/pull/1801/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1801&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8258477
>   Stats: 117 lines in 1 file changed: 116 ins; 0 del; 1 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/1801.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/1801/head:pull/1801
>
> PR: https://git.openjdk.java.net/jdk/pull/1801
>


From ihse at openjdk.java.net  Wed Dec 16 13:54:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 13:54:56 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <lx-WvJ4UCgbzCv9uhKpuj-5p8wD0cw_M6qvGYUOAvfI=.ec4c6a90-f111-48d4-9246-6e6fcd0a9bd7@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
 <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
 <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>
 <x67oas0wEquTD4RV8SP-WRH7qzFD3MVRBc_6GH3-74E=.5d85502a-19fe-4400-844e-fc27a6a961dc@github.com>
 <lx-WvJ4UCgbzCv9uhKpuj-5p8wD0cw_M6qvGYUOAvfI=.ec4c6a90-f111-48d4-9246-6e6fcd0a9bd7@github.com>
Message-ID: <h2UO3lHrtp-_PiXTgpr1P-OZyqhI1-SOn7oOmY7h4YY=.194c40f3-935c-4544-98ce-809430dda35a@github.com>

On Wed, 16 Dec 2020 10:21:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @mlchung The entire point of this exercise is to *not* have hard-coded lists of modules in make files... 
>> 
>> Having hard-coded lists have come back to bite us, time after time again. We try to auto-discover everything that is possible. For these sets of modules, however, auto-discovery is not possible since these lists *define* what we mean by e.g. platform modules or an interim image.
>
> The update to JRE_MODULES in Images.gmk resolves my comment above. However, the naming for the configuration is still a bit odd,  e.g. module-sets-classloaders.conf should be something like module-loader-map.conf as used to generate ModuleLoaderMap.java in the build.

@AlanBateman I don't have a problem with renaming the conf files, I just did not know what you wanted them to be called. :-) I renamed `module-sets-classloaders.conf` to `module-loader-map.conf`. Based on this, I rename the other two files `javadoc-modules.conf` and `build-module-sets.conf`, respectively. I hope this is okay. Otherwise, please just let me know what you think they should be called.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Wed Dec 16 14:02:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 14:02:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
 <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>
Message-ID: <F1TBC8SJ4UagUp3gvVlBcWOmsIHsG6yqbF9-PUFI2mQ=.7ef21145-157f-4871-8045-979284284dce@github.com>

On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?
>
> I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives?

@AlanBateman Let me re-iterate: the data files are *not* "make" files. It is just as annoying to have team-specific data files in the make tree! So to keep things as they are is not an option. The fact that they currently reside there is just a continuation of the old view of make as a general dumping ground. I've requested this change since before Project Jigsaw. In fact, I opposed Erik's original Jigsaw patch on this ground, among other things. As a compromise, we agreed that it was to be fixed *after* Jigsaw, since that project had already dragged out in time for so long and was blocking the release. (See https://bugs.openjdk.java.net/browse/JDK-8055193 for details.)

So what do you propose for alternative? A new top-level data directory? I mean, sure, we could have like `data/java.base/share/charsetmapping` instead. I personally think that makes less sense. I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From robin.westberg at oracle.com  Wed Dec 16 14:20:19 2020
From: robin.westberg at oracle.com (Robin Westberg)
Date: Wed, 16 Dec 2020 15:20:19 +0100
Subject: RFR: 8258477: Pre-submit testing using GitHub Actions should
 merge changes from target branch
In-Reply-To: <CAA-vtUwGC=HfhEUeFrdUObWf7+rZahAUcGsNf09VF27p+HcqRA@mail.gmail.com>
References: <AjDSrcfDfZuNWrLpkfNXeFpsABj8bhvwZYNInSXKDyU=.9c36ae6c-eabc-4029-904f-c09e64814082@github.com>
 <CAA-vtUwGC=HfhEUeFrdUObWf7+rZahAUcGsNf09VF27p+HcqRA@mail.gmail.com>
Message-ID: <AA6D4DB0-5061-45CC-B4DF-A9F8466FAD0E@oracle.com>

Hi Thomas,

> On 16 Dec 2020, at 14:54, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi Robin,
> 
> does this mean tests won't run on branches which cannot be merged with the
> assumed target branch?

No, if there?s a problem with doing the merge the tests will simply continue without doing it, and just use the commit in the pull request as-is.

Best regards,
Robin
 
> 
> Thanks, Thomas
> 
> 
> On Wed, Dec 16, 2020 at 11:55 AM Robin Westberg <rwestberg at openjdk.java.net>
> wrote:
> 
>> Normally when running GitHub Actions on a pull request, what is checked
>> out is the merge of the pull request with the latest changes on the target
>> branch. This ensure that what is tested is as close as possible to what
>> will actually be the result of integrating said pull request.
>> 
>> In our use of GitHub Actions, we don't run directly on pull requests but
>> instead allow contributors to run them in their own personal forks. In that
>> context, there is no notion of a target branch. However, we can infer the
>> target project and branch by encoding this in the workflow file. This
>> allows us to perform the same merge manually, and achieve the same
>> behaviour.
>> 
>> The change also adds an option to disable this automated merge when
>> launching the workflow manually, which could be useful when investigating
>> unexpected test failures.
>> 
>> Note that downstream projects picking up this change will have to adapt
>> the workflow file to keep using these actions for pre-submit testing. This
>> has been a common request from downstream projects, but could also be done
>> in a separate change (or not at all).
>> 
>> -------------
>> 
>> Commit messages:
>> - Allow opting out of automated merge on manual runs
>> - Initial implementation
>> 
>> Changes: https://git.openjdk.java.net/jdk/pull/1801/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1801&range=00
>>  Issue: https://bugs.openjdk.java.net/browse/JDK-8258477
>>  Stats: 117 lines in 1 file changed: 116 ins; 0 del; 1 mod
>>  Patch: https://git.openjdk.java.net/jdk/pull/1801.diff
>>  Fetch: git fetch https://git.openjdk.java.net/jdk
>> pull/1801/head:pull/1801
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/1801
>> 



From thomas.stuefe at gmail.com  Wed Dec 16 14:22:11 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 16 Dec 2020 15:22:11 +0100
Subject: RFR: 8258477: Pre-submit testing using GitHub Actions should
 merge changes from target branch
In-Reply-To: <AA6D4DB0-5061-45CC-B4DF-A9F8466FAD0E@oracle.com>
References: <AjDSrcfDfZuNWrLpkfNXeFpsABj8bhvwZYNInSXKDyU=.9c36ae6c-eabc-4029-904f-c09e64814082@github.com>
 <CAA-vtUwGC=HfhEUeFrdUObWf7+rZahAUcGsNf09VF27p+HcqRA@mail.gmail.com>
 <AA6D4DB0-5061-45CC-B4DF-A9F8466FAD0E@oracle.com>
Message-ID: <CAA-vtUwFaqZbKrgMHPxvRcLWhTjErs2qBmEK=y1-wQJS=OJx6Q@mail.gmail.com>

On Wed, Dec 16, 2020 at 3:20 PM Robin Westberg <robin.westberg at oracle.com>
wrote:

> Hi Thomas,
>
> > On 16 Dec 2020, at 14:54, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> >
> > Hi Robin,
> >
> > does this mean tests won't run on branches which cannot be merged with
> the
> > assumed target branch?
>
> No, if there?s a problem with doing the merge the tests will simply
> continue without doing it, and just use the commit in the pull request
> as-is.
>
> Best regards,
> Robin


Yes, that makes sense. Thank you!

..Thomas


>
> >
> > Thanks, Thomas
> >
> >
> > On Wed, Dec 16, 2020 at 11:55 AM Robin Westberg <
> rwestberg at openjdk.java.net>
> > wrote:
> >
> >> Normally when running GitHub Actions on a pull request, what is checked
> >> out is the merge of the pull request with the latest changes on the
> target
> >> branch. This ensure that what is tested is as close as possible to what
> >> will actually be the result of integrating said pull request.
> >>
> >> In our use of GitHub Actions, we don't run directly on pull requests but
> >> instead allow contributors to run them in their own personal forks. In
> that
> >> context, there is no notion of a target branch. However, we can infer
> the
> >> target project and branch by encoding this in the workflow file. This
> >> allows us to perform the same merge manually, and achieve the same
> >> behaviour.
> >>
> >> The change also adds an option to disable this automated merge when
> >> launching the workflow manually, which could be useful when
> investigating
> >> unexpected test failures.
> >>
> >> Note that downstream projects picking up this change will have to adapt
> >> the workflow file to keep using these actions for pre-submit testing.
> This
> >> has been a common request from downstream projects, but could also be
> done
> >> in a separate change (or not at all).
> >>
> >> -------------
> >>
> >> Commit messages:
> >> - Allow opting out of automated merge on manual runs
> >> - Initial implementation
> >>
> >> Changes: https://git.openjdk.java.net/jdk/pull/1801/files
> >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1801&range=00
> >>  Issue: https://bugs.openjdk.java.net/browse/JDK-8258477
> >>  Stats: 117 lines in 1 file changed: 116 ins; 0 del; 1 mod
> >>  Patch: https://git.openjdk.java.net/jdk/pull/1801.diff
> >>  Fetch: git fetch https://git.openjdk.java.net/jdk
> >> pull/1801/head:pull/1801
> >>
> >> PR: https://git.openjdk.java.net/jdk/pull/1801
> >>
>
>


From alanb at openjdk.java.net  Wed Dec 16 14:43:02 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 14:43:02 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <h2UO3lHrtp-_PiXTgpr1P-OZyqhI1-SOn7oOmY7h4YY=.194c40f3-935c-4544-98ce-809430dda35a@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
 <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
 <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>
 <x67oas0wEquTD4RV8SP-WRH7qzFD3MVRBc_6GH3-74E=.5d85502a-19fe-4400-844e-fc27a6a961dc@github.com>
 <lx-WvJ4UCgbzCv9uhKpuj-5p8wD0cw_M6qvGYUOAvfI=.ec4c6a90-f111-48d4-9246-6e6fcd0a9bd7@github.com>
 <h2UO3lHrtp-_PiXTgpr1P-OZyqhI1-SOn7o
 OmY7h4YY=.194c40f3-935c-4544-98ce-809430dda35a@github.com>
Message-ID: <F8huLCVoSBK6p4i-iiJ_bR01vCatvE3KZ9EirmX_uiU=.55602431-3546-4a2a-b3da-4b94e5a8a4fc@github.com>

On Wed, 16 Dec 2020 13:51:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The update to JRE_MODULES in Images.gmk resolves my comment above. However, the naming for the configuration is still a bit odd,  e.g. module-sets-classloaders.conf should be something like module-loader-map.conf as used to generate ModuleLoaderMap.java in the build.
>
> @AlanBateman I don't have a problem with renaming the conf files, I just did not know what you wanted them to be called. :-) I renamed `module-sets-classloaders.conf` to `module-loader-map.conf`. Based on this, I rename the other two files `javadoc-modules.conf` and `build-module-sets.conf`, respectively. I hope this is okay. Otherwise, please just let me know what you think they should be called.

Thanks for the update.

javadoc-modules.conf is probably okay although someone finding this in the repo might initially think it's the configuration for the javadoc modules. That plus it sets DOCS_MODULES, so maybe it should be apidocs-modules.conf.

module-loader-map.conf works as the configuration file that defines BOOT_MODULES and PLATFORM_MODULES. I think AGGREGATOR_MODULES should be dropped and "java.se" added to PLATFORM_MODULES. If I remember correctly, this was separated out in JDK 9 and 10 because of the java.se.ee aggregator module (that one was removed in Java 11 by JEP 320).

We should probably look at UPGRADEABLE_MODULES while we are here. This is the modules that are overriddable by way of excluding from the hashes stored in java.base (CreateJmods.gmk). I think it's okay to leave it in module-loader-map.conf because these modules are mapped to the platform class loader. Could we just rename it to UPGRADEABLE_PLATFORM_MODULES so that its a bit clearer (in Modules.gmk) as to why they are append to PLATFORM_MODULES?

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From dcubed at openjdk.java.net  Wed Dec 16 15:07:56 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Dec 2020 15:07:56 GMT
Subject: RFR: 8258447: Move make/hotspot/hotspot.script to make/scripts
In-Reply-To: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>
References: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>
Message-ID: <Ol9Gh3BukYMXhN9daz9vIQUjDoGOGn2VJlzAgjPzPg0=.4cf972bc-7652-4fa4-9517-62c4c0cb818b@github.com>

On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension).

The rename and makefile changes look good.
I've used the script on occasion, but not recently (not in the last 6 months).

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1791


From mchung at openjdk.java.net  Wed Dec 16 17:10:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 16 Dec 2020 17:10:03 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v2]
In-Reply-To: <F8huLCVoSBK6p4i-iiJ_bR01vCatvE3KZ9EirmX_uiU=.55602431-3546-4a2a-b3da-4b94e5a8a4fc@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <b26J4pSiVYL8TCBSboh5sJ2u5Ir_VJU2nxwwhBwUbKo=.0c064b9c-1006-43cf-b1da-9f49d81176c4@github.com>
 <8vS8R-VHMI0bJa9SeLfWMFb_knahizPVQ8nvSrLK2n0=.a57b7415-90c3-4501-84ad-a4beb780316f@github.com>
 <EEi2A2Yzjxbe1HBtgTIqC_13Dv3UcJhwGJZTWzlKkJc=.df76d4ed-c8be-462b-bf62-690bdf4adb42@github.com>
 <3Aghqph8r8ulE5Yrevo1NQyM8c30MHpJ-3A7K32Xtqg=.212637ab-4d2b-4f13-9a88-2abfe77b6175@github.com>
 <S47jkcUUQs97OIAWRhx28J7-ftyGiVInSItuiXdD3gM=.841e2146-c77c-442b-81cd-7629024d54b7@github.com>
 <siKLNHIhlBLRlgou7tWAX-6Mvk1PxTaAd8s37uxmfvQ=.0d292c3d-2b90-443e-a9e2-77c1dec07380@github.com>
 <gpbrd8yVuz-YVwTjrsV-5o_UG23RgB-thDDq-TkEzrw=.1b0c6704-e22c-4753-9cef-5f2d2615d54f@github.com>
 <x67oas0wEquTD4RV8SP-WRH7qzFD3MVRBc_6GH3-74E=.5d85502a-19fe-4400-844e-fc27a6a961dc@github.com>
 <lx-WvJ4UCgbzCv9uhKpuj-5p8wD0cw_M6qvGYUOAvfI=.ec4c6a90-f111-48d4-9246-6e6fcd0a9bd7@github.com>
 <h2UO3lHrtp-_PiXTgpr1P-OZyqhI1-SOn7o
 OmY7h4YY=.194c40f3-935c-4544-98ce-809430dda35a@github.com>
 <F8huLCVoSBK6p4i-iiJ_bR01vCatvE3KZ9EirmX_uiU=.55602431-3546-4a2a-b3da-4b94e5a8a4fc@github.com>
Message-ID: <mhvdOm1QTJO09NPx53wTfbHgIptvG_WZ4NrerdSOuLk=.1b9534bc-6c50-4a61-aace-b2ed7fa1996d@github.com>

On Wed, 16 Dec 2020 14:40:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> javadoc-modules.conf is probably okay although someone finding this in the repo might initially think it's the configuration for the javadoc modules. That plus it sets DOCS_MODULES, so maybe it should be apidocs-modules.conf.

I'm okay with apidocs-modules.conf or docs-modules.conf.   It's good to match the make target name which makes it easier to understand what this configuration is for.

> module-loader-map.conf works as the configuration file that defines BOOT_MODULES and PLATFORM_MODULES. I think AGGREGATOR_MODULES should be dropped and "java.se" added to PLATFORM_MODULES. If I remember correctly, this was separated out in JDK 9 and 10 because of the java.se.ee aggregator module (that one was removed in Java 11 by JEP 320).

module-loader-map.conf works for me too.   We can drop AGGREGATOR_MODULES  since java.se is the sole aggregator module in JDK now.

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From jjg at openjdk.java.net  Wed Dec 16 18:29:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 18:29:00 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v2]
In-Reply-To: <GEwkDW5Hm6vl7P3oQXO80jukkmydlyx4v4rXba7-f3E=.36cc3952-8017-46dc-bfd3-177bcbabe960@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
 <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>
 <GEwkDW5Hm6vl7P3oQXO80jukkmydlyx4v4rXba7-f3E=.36cc3952-8017-46dc-bfd3-177bcbabe960@github.com>
Message-ID: <C1yKyssMIqT_8tC1_JlpF1hMlDBpONw1FjOmPJuY6YA=.9db2227d-fccb-4cc5-8fe8-4da49c1da40c@github.com>

On Thu, 5 Nov 2020 16:16:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Fix merge issues; review feedback
>>  - Merge with master
>>  - allow rich content in createAnchorAndSearchIndex
>>  - update Docs.gmk to stop disabling spec tag
>>  - fix TestSpecTag.testEncodedURI
>>  - fix tests
>>  - remove support to workaround legacy @spec tag
>>  - Merge remote-tracking branch 'upstream/master' into new-spec-tag
>>  - fix trailing whitespace in test
>>  - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9
>
> 1. Thanks for incorporating my previous offline feedback.
> 2. Since Hannes and Erik seem to have looked at everything else, I looked mostly at changes in `src/jdk.compiler/share/classes/com/sun/source/**`, which are good!
> 3. There should be a corresponding but separate change to "Documentation Comment Specification for the Standard Doclet".
> 4. Can we use this new `@since` tag to refer to the spec at `com/sun/tools/javac/parser/DocCommentParser.java:1116`?
> 5. Should we specify in `com.sun.source.doctree.SpecTree` that both `url` and `label` parts are mandatory?
> 6. `DCSpec extends DCEndPosTree`, sigh... Although that is not a public API, this design suggests we could improve that abstraction sometime later.

Closing pull request, until we better decide the contents of the spec page

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

PR: https://git.openjdk.java.net/jdk/pull/790


From jjg at openjdk.java.net  Wed Dec 16 18:29:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 18:29:02 GMT
Subject: Withdrawn: JDK-6251738: Want a top-level summary page that itemizes
 all spec documents referenced from javadocs (OEM spec)
In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
Message-ID: <_5FMfeDyMMGcBlb5BSM-cA0LsrrJYnIcvggWuUy-yf0=.3e55f9e7-ece2-4809-93bc-6afd433c49e7@github.com>

On Thu, 22 Oct 2020 02:40:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
> 
> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
> 
> As a block tag, the format is simply
> 
>     @spec url label
> 
> which is handled in a manner analogous to
> 
>     @see <a href="url">label</a>
> 
> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
> 
> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/790


From ihse at openjdk.java.net  Wed Dec 16 18:36:25 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 18:36:25 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v5]
In-Reply-To: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
Message-ID: <Z7dcAgaSSC6S9Z993K9nxlpRDNrMSBSzFTAPuQ1sj-s=.bcb2111e-94a0-4e41-b0ee-9db94515ae1c@github.com>

> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
> 
> Thus the actual lists of module sets should move to the `make/conf` directory.
> 
> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Changes as requested by reviewers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1781/files
  - new: https://git.openjdk.java.net/jdk/pull/1781/files/199832a1..b7d393f0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1781&range=03-04

  Stats: 14 lines in 3 files changed: 1 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1781/head:pull/1781

PR: https://git.openjdk.java.net/jdk/pull/1781


From naoto at openjdk.java.net  Wed Dec 16 18:37:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Dec 2020 18:37:00 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
Message-ID: <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.

Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this.

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

PR: https://git.openjdk.java.net/jdk/pull/1611


From ihse at openjdk.java.net  Wed Dec 16 18:51:58 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 18:51:58 GMT
Subject: Integrated: 8258447: Move make/hotspot/hotspot.script to make/scripts
In-Reply-To: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>
References: <TAN7mcJbd5Kw5a8x13PBXlwnsj8gVEYdhv_fAdPfsBU=.49bf33b6-7687-45c6-9bcc-f6ba3ceed322@github.com>
Message-ID: <DQunHYVQPQd0Z5qffe1FDvBvpLJs76oxNxvT8_gGkuQ=.91d4357d-1432-4ddb-a0f6-e77dc25c731a@github.com>

On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension).

This pull request has now been integrated.

Changeset: ab5d581b
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab5d581b
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8258447: Move make/hotspot/hotspot.script to make/scripts

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/1791


From mchung at openjdk.java.net  Wed Dec 16 18:59:58 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 16 Dec 2020 18:59:58 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v5]
In-Reply-To: <Z7dcAgaSSC6S9Z993K9nxlpRDNrMSBSzFTAPuQ1sj-s=.bcb2111e-94a0-4e41-b0ee-9db94515ae1c@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <Z7dcAgaSSC6S9Z993K9nxlpRDNrMSBSzFTAPuQ1sj-s=.bcb2111e-94a0-4e41-b0ee-9db94515ae1c@github.com>
Message-ID: <A8ylRUnjDTbiyLHal0OpN5rok88JSK-j6W255ESuYIE=.e058cbd9-c96d-4c0c-b20d-e115bfdded3a@github.com>

On Wed, 16 Dec 2020 18:36:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
>> 
>> Thus the actual lists of module sets should move to the `make/conf` directory.
>> 
>> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes as requested by reviewers

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From alanb at openjdk.java.net  Wed Dec 16 19:03:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 19:03:58 GMT
Subject: RFR: 8258411: Move module set configuration from Modules.gmk to
 conf dir [v5]
In-Reply-To: <Z7dcAgaSSC6S9Z993K9nxlpRDNrMSBSzFTAPuQ1sj-s=.bcb2111e-94a0-4e41-b0ee-9db94515ae1c@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
 <Z7dcAgaSSC6S9Z993K9nxlpRDNrMSBSzFTAPuQ1sj-s=.bcb2111e-94a0-4e41-b0ee-9db94515ae1c@github.com>
Message-ID: <gPHUcLTi064TZoJlNw7-1kme0HJetc5p2LfPdRkfXV0=.eac90279-05ac-4e93-91fa-0d94a6470109@github.com>

On Wed, 16 Dec 2020 18:36:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
>> 
>> Thus the actual lists of module sets should move to the `make/conf` directory.
>> 
>> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes as requested by reviewers

Thanks for the updates.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1781


From ihse at openjdk.java.net  Wed Dec 16 22:00:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 22:00:56 GMT
Subject: Integrated: 8258411: Move module set configuration from Modules.gmk
 to conf dir
In-Reply-To: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
References: <O0TVozStiJEuT2kI6CXOUYLWcX_1qnMIwRIn865JFuk=.5f307e0d-dcd1-4be3-aac9-e36f9cbd6aca@github.com>
Message-ID: <1N_tK5fcFvA30H-KWr8eyNtQtfm05WsWcLkn0v3-Pw4=.52e4dbfc-6168-400f-9120-684d941195ff@github.com>

On Tue, 15 Dec 2020 16:11:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The hard-coded list of modules in `make/common/Modules.gmk` has always been a wart in the build system. We pride ourself on using discovery instead of hard-coded list. In this case, it is not possible to do do auto-discovery, since the different module sets are configured, not determined.
> 
> Thus the actual lists of module sets should move to the `make/conf` directory.
> 
> This is the first patch in a series where I will move configuration values spread over the build system into the designated `make/conf` directory.

This pull request has now been integrated.

Changeset: a244b822
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a244b822
Stats:     393 lines in 5 files changed: 223 ins; 157 del; 13 mod

8258411: Move module set configuration from Modules.gmk to conf dir

Reviewed-by: alanb, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/1781


From jjg at openjdk.java.net  Wed Dec 16 22:30:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 22:30:56 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
Message-ID: <n4TZRZAE4icwhh4C0YbnPciLYpJRyUFF8TRu5B1OrDo=.7d5d8fa5-a681-4160-9d7e-5768a5a1efad@github.com>

On Mon, 14 Dec 2020 09:11:31 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40:
> 
>> 38: var MIN_RESULTS = 3;
>> 39: var MAX_RESULTS = 500;
>> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##";
> 
> `<Unnamed>` is not a string that is ever shown to the user, it is what is used by javadoc to denote the default package (see `toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't be localized as that would break behaviour for code in the default package (and show the localized string as package name, instead of no package name).

Noted, thanks

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From jjg at openjdk.java.net  Wed Dec 16 23:21:11 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 23:21:11 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v2]
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <1GIodXJQxB1mO27Of0bxkkihV_wRhbb3EoGTnCFWG3w=.f927c17d-3653-4d58-9210-dc5b692386b8@github.com>

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into localize.search.js
 - JDK-8247994: Localize javadoc search

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/16/files
  - new: https://git.openjdk.java.net/jdk16/pull/16/files/8eb7f27b..ec111185

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=00-01

  Stats: 1532 lines in 52 files changed: 1207 ins; 121 del; 204 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16

PR: https://git.openjdk.java.net/jdk16/pull/16


From ysatowse at openjdk.java.net  Thu Dec 17 01:40:14 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 17 Dec 2020 01:40:14 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8257204 and 8256313
  8257204: Remove usage of -Xhtmlversion option from javac
  8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/294b3cce..30db3882

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Thu Dec 17 05:01:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:01:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
Message-ID: <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>

On Thu, 17 Dec 2020 01:40:14 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8257204 and 8256313
>   8257204: Remove usage of -Xhtmlversion option from javac
>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

Mostly OK; some minor suggestions

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 36:

> 34: dc.attr.img.border.not.number = attribute "border" for img is not a number
> 35: dc.attr.table.border.not.valid = attribute "border" for table only accepts "" or "1", use CSS instead: {0}
> 36: dc.attr.table.border.not.number = attribute "border" for table is not a number

suggest dropping "use CSS instead"

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

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Thu Dec 17 05:01:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:01:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
Message-ID: <utC2G0Ga3tAOMc2s-SPwbfinJD5P8fyxUHnM23lJOp4=.6cf5de97-58c8-40a3-8265-3a52eff785df@github.com>

On Thu, 12 Nov 2020 03:10:01 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 410:
>> 
>>> 408:         OBSOLETE,
>>> 409:         UNSUPPORTED
>>> 410:     }
>> 
>> On one hand, I don't think we need this level of detail, but on the other, I see it closely matches `AttrKind`, so OK.
>> 
>> Is there are useful distinction between INVALID / OBSOLETE / UNSUPPORTED ?
>
> OK: valid
> OBSOLETE: obsolete, deprecated, but still supported (valid)
> UNSUPPORTED: ever supported but no longer supported (invalid)
> INVALID: the rest of others (invalid)
> 
> UNSUPPORTED can be used if we would like to choose a friendly message instead of saying "unknown tag" only.
> OBSOLETE is not used anywhere in this commit.  Although HTML5 has some obsolete features, [JDK-8215577](https://bugs.openjdk.java.net/browse/JDK-8215577) didn't define them as valid features if my understanding is correct.  So I chose not to allow obsolete features in order to avoid inconsistency.

For both `ElemKind` and `AttrKind` there only seem to be two kinds:
* valid
* previously valid

For these two cases, `OK` is obviously reasonable for `valid`, but `OBSOLETE` seems a better fit than `UNSUPPORTED`, but you could also use `HTML4` or `OLD_HTML4` or something like that to indicate why we're keeping the name around for better messages.  Or, stay with `UNSUPPORTED` but add a doc comment explaining that it was previously supported but no longer supported

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

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Thu Dec 17 05:01:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:01:04 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
 <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
Message-ID: <ct3G5aCjd2l1ULLxIeslbJeu_pdn7Y9XrUo3iALSTdM=.8ca1e3d4-6fc0-4929-ba6d-b9055b5f7093@github.com>

On Thu, 17 Dec 2020 04:50:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 36:
> 
>> 34: dc.attr.img.border.not.number = attribute "border" for img is not a number
>> 35: dc.attr.table.border.not.valid = attribute "border" for table only accepts "" or "1", use CSS instead: {0}
>> 36: dc.attr.table.border.not.number = attribute "border" for table is not a number
> 
> suggest dropping "use CSS instead"

The wording of `attribute "border" for img is not a number` seems strange.
Suggest something like `invalid value for attribute "border": {0}`

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

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Thu Dec 17 06:37:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 17 Dec 2020 06:37:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <ct3G5aCjd2l1ULLxIeslbJeu_pdn7Y9XrUo3iALSTdM=.8ca1e3d4-6fc0-4929-ba6d-b9055b5f7093@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
 <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
 <ct3G5aCjd2l1ULLxIeslbJeu_pdn7Y9XrUo3iALSTdM=.8ca1e3d4-6fc0-4929-ba6d-b9055b5f7093@github.com>
Message-ID: <LaPvn9zXOCuv3dabCWRzTvMc_Qmch_-YLBUnkrS1Njw=.6f56b3b4-1382-49b5-845c-3250c591143f@github.com>

On Thu, 17 Dec 2020 04:52:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 36:
>> 
>>> 34: dc.attr.img.border.not.number = attribute "border" for img is not a number
>>> 35: dc.attr.table.border.not.valid = attribute "border" for table only accepts "" or "1", use CSS instead: {0}
>>> 36: dc.attr.table.border.not.number = attribute "border" for table is not a number
>> 
>> suggest dropping "use CSS instead"
>
> The wording of `attribute "border" for img is not a number` seems strange.
> Suggest something like `invalid value for attribute "border": {0}`

Ok, I will fix that.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Thu Dec 17 06:42:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 17 Dec 2020 06:42:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <utC2G0Ga3tAOMc2s-SPwbfinJD5P8fyxUHnM23lJOp4=.6cf5de97-58c8-40a3-8265-3a52eff785df@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <utC2G0Ga3tAOMc2s-SPwbfinJD5P8fyxUHnM23lJOp4=.6cf5de97-58c8-40a3-8265-3a52eff785df@github.com>
Message-ID: <nIfzA3CWPNH4afTxI1eBE303Bsj6gINA4pYPe5dOpu8=.2d5bdda8-f220-4b47-ad76-44e83405bb35@github.com>

On Thu, 17 Dec 2020 04:48:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> OK: valid
>> OBSOLETE: obsolete, deprecated, but still supported (valid)
>> UNSUPPORTED: ever supported but no longer supported (invalid)
>> INVALID: the rest of others (invalid)
>> 
>> UNSUPPORTED can be used if we would like to choose a friendly message instead of saying "unknown tag" only.
>> OBSOLETE is not used anywhere in this commit.  Although HTML5 has some obsolete features, [JDK-8215577](https://bugs.openjdk.java.net/browse/JDK-8215577) didn't define them as valid features if my understanding is correct.  So I chose not to allow obsolete features in order to avoid inconsistency.
>
> For both `ElemKind` and `AttrKind` there only seem to be two kinds:
> * valid
> * previously valid
> 
> For these two cases, `OK` is obviously reasonable for `valid`, but `OBSOLETE` seems a better fit than `UNSUPPORTED`, but you could also use `HTML4` or `OLD_HTML4` or something like that to indicate why we're keeping the name around for better messages.  Or, stay with `UNSUPPORTED` but add a doc comment explaining that it was previously supported but no longer supported

Ok, I will use `HTML4`.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From drandynisbet at gmail.com  Thu Dec 17 16:13:20 2020
From: drandynisbet at gmail.com (Andy Nisbet)
Date: Thu, 17 Dec 2020 16:13:20 +0000
Subject: Cross-compilation of OpenJDK Zero with clang
Message-ID: <CALXRTw8zhGD2ixUnD6ufsw3wm-BZHXTgmnADyYpzvCnF6ZkypQ@mail.gmail.com>

Hi,
I am in the process of porting OpenJDK to a new architecture, at the
current moment in time we only have clang/LLVM cross compilation tools, and
GCC/binutils is still a year or so away. Could anyone offer any pointers to
documentation/hints, and/or outline what is necessary to get cross
compilation with clang working?  I have a sysroot and a bootable diskimage
for the virtual emulated platform.

Thanks,
Andy


From jjg at openjdk.java.net  Thu Dec 17 16:39:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 16:39:17 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v3]
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <yNCZp72SmLyGtISZOHf03lrmZWaObtajWmXyeNZITqc=.caba81f4-e70b-42a2-b92c-3d93bcf5b377@github.com>

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/16/files
  - new: https://git.openjdk.java.net/jdk16/pull/16/files/ec111185..1a406f35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16

PR: https://git.openjdk.java.net/jdk16/pull/16


From hannesw at openjdk.java.net  Thu Dec 17 17:06:00 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 17 Dec 2020 17:06:00 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v3]
In-Reply-To: <yNCZp72SmLyGtISZOHf03lrmZWaObtajWmXyeNZITqc=.caba81f4-e70b-42a2-b92c-3d93bcf5b377@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <yNCZp72SmLyGtISZOHf03lrmZWaObtajWmXyeNZITqc=.caba81f4-e70b-42a2-b92c-3d93bcf5b377@github.com>
Message-ID: <-H-OPr6wCQeLESYlsa7aQTVJjtzxeknaqJRpy0-s0L8=.af6de1b0-749d-4cf4-898b-2f4284db3ebd@github.com>

On Thu, 17 Dec 2020 16:39:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40:

> 38: var MIN_RESULTS = 3;
> 39: var MAX_RESULTS = 500;
> 40: var UNNAMED = "<Unnamed>>";

Oops, an additional closing angle bracket slipped there.

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From jjg at openjdk.java.net  Thu Dec 17 17:13:14 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 17:13:14 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v4]
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <z4c0UByrdXBXCUoBX41qx9nJJVh0XOUynSgF9mAFt4Q=.70d8db98-dc89-4883-96aa-eb1f8c8770fc@github.com>

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/16/files
  - new: https://git.openjdk.java.net/jdk16/pull/16/files/1a406f35..de6802c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16

PR: https://git.openjdk.java.net/jdk16/pull/16


From hannesw at openjdk.java.net  Thu Dec 17 17:13:15 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 17 Dec 2020 17:13:15 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v4]
In-Reply-To: <z4c0UByrdXBXCUoBX41qx9nJJVh0XOUynSgF9mAFt4Q=.70d8db98-dc89-4883-96aa-eb1f8c8770fc@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <z4c0UByrdXBXCUoBX41qx9nJJVh0XOUynSgF9mAFt4Q=.70d8db98-dc89-4883-96aa-eb1f8c8770fc@github.com>
Message-ID: <6teL5P5Sg13pNY0zUuTF-wQc5a_rr8zrq4xNAxoGJL0=.5d6444e0-66d4-43ee-aa80-5ac2bfa9fc75@github.com>

On Thu, 17 Dec 2020 17:10:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by hannesw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From jjg at openjdk.java.net  Thu Dec 17 18:36:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 18:36:58 GMT
Subject: [jdk16] Integrated: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <mLgRaQMV52_N_PKjfTsigoc0sYxYeecyxktxV7i98-A=.7f258a87-60b0-4a0d-a25e-b45d4ad3a3e1@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

This pull request has now been integrated.

Changeset: 30ca0a5d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/30ca0a5d
Stats:     120 lines in 9 files changed: 87 ins; 6 del; 27 mod

8247994: Localize javadoc search

Reviewed-by: hannesw, ihse

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

PR: https://git.openjdk.java.net/jdk16/pull/16


From jwilhelm at openjdk.java.net  Thu Dec 17 20:44:15 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 20:44:15 GMT
Subject: Integrated: Merge jdk16
Message-ID: <LD8ANDgogS-bx4izFlwhL_9-MwiCI2jNn6a4Ehb2wmA=.80d8ff3d-e60b-4634-bcce-943c96d6edbd@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8247994: Localize javadoc search
 - 8258515: javac should issue an error if an annotation is nested in a local class or interface
 - 8258225: compiler/c2/cr6340864/TestIntVect.java runs faster in interpreter
 - 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2
 - 8257621: JFR StringPool misses cached items across consecutive recordings
 - 8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
 - 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect
 - 8258505: [TESTBUG] TestDivZeroWithSplitIf.java fails due to missing UnlockDiagnosticVMOptions
 - 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1827&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1827&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/1827/files
  Stats: 773 lines in 63 files changed: 449 ins; 124 del; 200 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1827.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1827/head:pull/1827

PR: https://git.openjdk.java.net/jdk/pull/1827


From jwilhelm at openjdk.java.net  Thu Dec 17 20:44:15 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 20:44:15 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <LD8ANDgogS-bx4izFlwhL_9-MwiCI2jNn6a4Ehb2wmA=.80d8ff3d-e60b-4634-bcce-943c96d6edbd@github.com>
References: <LD8ANDgogS-bx4izFlwhL_9-MwiCI2jNn6a4Ehb2wmA=.80d8ff3d-e60b-4634-bcce-943c96d6edbd@github.com>
Message-ID: <Rb-Ei4T62YffDeV4VkDR96LjtERDt8U5cJKXE0Vk7kY=.67f13552-6ea7-4be4-a61d-d546c313b68f@github.com>

On Thu, 17 Dec 2020 20:38:45 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: f15528eb
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f15528eb
Stats:     773 lines in 63 files changed: 449 ins; 124 del; 200 mod

Merge

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

PR: https://git.openjdk.java.net/jdk/pull/1827


From ysatowse at openjdk.java.net  Fri Dec 18 01:34:15 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 18 Dec 2020 01:34:15 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v4]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  5th: 8257204 and 8256313
  8257204: Remove usage of -Xhtmlversion option from javac
  8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/30db3882..f9ae0c5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=02-03

  Stats: 50 lines in 5 files changed: 0 ins; 0 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Fri Dec 18 02:34:16 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 18 Dec 2020 02:34:16 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  5th: 8258460: Remove --doclint-format option from javac

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/f9ae0c5f..261f207a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=03-04

  Stats: 10 lines in 3 files changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Fri Dec 18 02:42:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 18 Dec 2020 02:42:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
 <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
Message-ID: <rY5rzSkeAG6Y5_HV9oA4UW_wY0957Dk7nvE6fSdY-ws=.02fe43aa-e5ae-425b-beb3-23d414423408@github.com>

On Thu, 17 Dec 2020 04:58:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> Mostly OK; some minor suggestions

Some related changes to 8258460 in closed repo is here.
https://orahub.oci.oraclecorp.com/yoshiki_sato/jdk/-/merge_requests/new?merge_request%5Bsource_branch%5D=JDK-8247957_2

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

PR: https://git.openjdk.java.net/jdk/pull/893


From akozlov at openjdk.java.net  Mon Dec 21 08:47:55 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 21 Dec 2020 08:47:55 GMT
Subject: Integrated: 8257620: Do not use objc_msgSend_stret to get macOS
 version
In-Reply-To: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
References: <ro31np4XeKoTu9UoTydiQnk9C9GjU6pqUg_gs5-JaWU=.2950dd3a-5c9f-4405-8eb9-80d0bb49b50b@github.com>
Message-ID: <RBdHyLYmGq664M4uin9cYQ8pRn-qNLkgesjQ6x1YKC8=.78dd707c-cefe-416b-a041-13dd5119e74e@github.com>

On Wed, 2 Dec 2020 17:34:00 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review a small change that replaces use of objc_msgSend_stret in macOS platform code with pure ObjC code. It's also a prerequisite for macOS/AArch64 support, where objc_msgSend_stret is not available.

This pull request has now been integrated.

Changeset: d4c7db50
Author:    Anton Kozlov <akozlov at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d4c7db50
Stats:     9 lines in 1 file changed: 5 ins; 0 del; 4 mod

8257620: Do not use objc_msgSend_stret to get macOS version

Reviewed-by: ihse, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/1569


From matthias.perktold at asaon.com  Mon Dec 21 10:01:43 2020
From: matthias.perktold at asaon.com (Matthias Perktold - ASA)
Date: Mon, 21 Dec 2020 10:01:43 +0000
Subject: Build and test problems on Windows with gtest
Message-ID: <VI1PR0202MB348732F590A6247A2C45F8F0E9C00@VI1PR0202MB3487.eurprd02.prod.outlook.com>

I wanted to create a pull request in OpenJDK, but I struggle to make the tests of tier 1 pass before making any changes.

At some point, I was able to run the tests of tier1, but got some failures (roughly about 60).

Then I noticed that the document says "Building of Hotspot Gtest suite requires the source code of Google Test framework".
So, I downloaded the source code and reconfigured the Toolchain, adding -with-gtest to the previously used config command, resulting in:
bash configure --with-boot-jdk=/cygdrive/c/jDev/java-x64/jdk-15.0.1+9/
  --with-jtreg=/cygdrive/c/jDev/jtreg/
  --with-gtest=/cygdrive/c/jDev/googletest-release-1.8.1/

But now I cannot run the tests anymore.
The test build exits with the message "ERROR: Build failed for target 'run-test-tier1' in configuration 'windows-x86_64-server-release' (exit code 2)".
Further up the logs, I found the following messages:

Creating support/test/lib-test/jtreg/native/bin/jvm-test-launcher.exe from 1 file(s)
make[3]: *** No rule to make target '/cygdrive/c/jdev/java-x64/jdk-15~2.1_9/bin//cygdrive/c/windows/system32/vcruntime140_1.dll', needed by '/cygdrive/c/users/matthiasp/git/jdk/build/windows-x86_64-server-release/images/test/hotspot/gtest/server/vcruntime140_1.dll'.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:675: test-image-hotspot-gtest] Error 2

Notice the double slash in the target path.
Also, it starts with the path to the boot JDK, but then it has "jdk-15~2.19" instead of "jdk-15.0.1+9".
Apparently, the paths got messed up here.

Do you have any idea what that could be, or what steps can help to solve this?
As you can see, I am on Windows with Cygwin.
Also, I installed Visual Studio 2019 Community Edition, adding "MSVC v142 - VS 2019 C++-ARM-Buildtools (v14.28)" to the core installation.

Thanks,
Matthias Perktold



From ihse at openjdk.java.net  Mon Dec 21 16:05:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Dec 2020 16:05:56 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <szc1adVdikwcXJce3l4OZFrtAssQqYb_vcTCuF5JX7o=.49900b63-9954-41cd-94a5-fcebb2bd5acb@github.com>
References: <91erxiMDb4ftvSomuJYHPi9SX-v8Z2VLD2qEwCbz5tk=.b9ed01b5-f0e0-4ed7-9c1a-b06bc0e64640@github.com>
 <FGicebGSC16JkFxwEcaznIGXx9Yji_YE5_SB9oNa9NU=.57eec7d9-f448-4b6f-8ee7-fa717b9ad3b0@github.com>
 <OGDUSwuVC42nasIh_IAxxyb9IL3EaCwLqoSNBL5Uams=.c0c8393d-6eb8-432e-8ff0-50c424eab9a8@github.com>
 <8Eqswd7tsVaGEXHdKDncXqKpW2tBsSeuY0PV6aTB9_c=.a6cf4957-9d31-4e89-bf44-e7b7852205d5@github.com>
 <ySKYIKsv5fE1GjJu0Wmd0nd8zfzCA2ckSuj9a1smNJ8=.88fa3e79-bf59-46a2-ab7a-b24a347dd7e0@github.com>
 <XIIxGudBaBPa33m9U9bLuwVigOOUCNoHxCAvg5r7jy8=.ede63b6e-f354-4b87-a3f2-b65c3c9f362b@github.com>
 <rdXhTxKu0lggWaU7JYW7LVvk_sirLQtkF3-7aqalDF4=.61ad7f3c-1954-4b56-935b-137965d996ad@github.com>
 <vADK2q5pDbUFlCMk0T4HXMCpCesFkwjJSnUOFyifFHA=.c534d7ae-3068-4a95-9c91-1bb722c3562f@github.com>
 <2S00ucaPGiAQLeLOejt1kfXeYEc7ctEPeRCIcq1N0N8=.dbf1ea7a-8de4-48a5-8759-03495e3e3c08@github.com>
 <MF0zpJDtYFB2xtM1C0MdccfCvu1xwLTGid-rfVrbaa4=.04763a1f-aaed-4c5e-afac-744686c23c41@github.com>
 <L6Y-UqXHQNQ7ZLxmxkhwwvB4hjuhNGt64_t
 _Y2qnTBU=.82107aad-c347-46db-b50a-7f7be4fb73e2@github.com>
 <9oXnHULCd76_J69CKMVVZl3FfDte1pnt38y06LVV4Sg=.26a4ab2c-5ff7-4e2f-9428-0d8cd931d243@github.com>
 <szc1adVdikwcXJce3l4OZFrtAssQqYb_vcTCuF5JX7o=.49900b63-9954-41cd-94a5-fcebb2bd5acb@github.com>
Message-ID: <re_7RZBHcdt8xcLI8gYUy4Oq_h0KwB55HSXOylU-icA=.a474d1b8-5007-459f-8bd2-17d068660799@github.com>

On Mon, 23 Nov 2020 15:55:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I think a proper solution to both this and the Capstone implementation is to provide a proper framework for selecting the hsdis backend as a first step, and refactor the existing bfd implementation as the first such backend. After that, we can add llvm and capstone as alternative hsdis backend implementations.
>
> FWIW, I started working on a framework which would add support for selectable backends for hsdis. Unfortunately it was not as simple as I initially thought, so I had to put it on hold while directing my time to working on the winenv patch instead.
> 
> I believe the proper way forward is to get the "selectable hsdis backend" framework in place, and then retrofit this patch to add LLVM support in that framework. If this means that this PR should be closed, or kept open until this is done, I don't know.

Nag nag bot...

I'm away for the holidays now, but I intend to pick up the work on the selectable hsdis backend when I return. So while this exact code is unlikely to be the one merged, it's good to have it open to allow me to double check the solutions picked here.

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

PR: https://git.openjdk.java.net/jdk/pull/392


From luhenry at openjdk.java.net  Mon Dec 21 23:21:55 2020
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Mon, 21 Dec 2020 23:21:55 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <re_7RZBHcdt8xcLI8gYUy4Oq_h0KwB55HSXOylU-icA=.a474d1b8-5007-459f-8bd2-17d068660799@github.com>
References: <91erxiMDb4ftvSomuJYHPi9SX-v8Z2VLD2qEwCbz5tk=.b9ed01b5-f0e0-4ed7-9c1a-b06bc0e64640@github.com>
 <FGicebGSC16JkFxwEcaznIGXx9Yji_YE5_SB9oNa9NU=.57eec7d9-f448-4b6f-8ee7-fa717b9ad3b0@github.com>
 <OGDUSwuVC42nasIh_IAxxyb9IL3EaCwLqoSNBL5Uams=.c0c8393d-6eb8-432e-8ff0-50c424eab9a8@github.com>
 <8Eqswd7tsVaGEXHdKDncXqKpW2tBsSeuY0PV6aTB9_c=.a6cf4957-9d31-4e89-bf44-e7b7852205d5@github.com>
 <ySKYIKsv5fE1GjJu0Wmd0nd8zfzCA2ckSuj9a1smNJ8=.88fa3e79-bf59-46a2-ab7a-b24a347dd7e0@github.com>
 <XIIxGudBaBPa33m9U9bLuwVigOOUCNoHxCAvg5r7jy8=.ede63b6e-f354-4b87-a3f2-b65c3c9f362b@github.com>
 <rdXhTxKu0lggWaU7JYW7LVvk_sirLQtkF3-7aqalDF4=.61ad7f3c-1954-4b56-935b-137965d996ad@github.com>
 <vADK2q5pDbUFlCMk0T4HXMCpCesFkwjJSnUOFyifFHA=.c534d7ae-3068-4a95-9c91-1bb722c3562f@github.com>
 <2S00ucaPGiAQLeLOejt1kfXeYEc7ctEPeRCIcq1N0N8=.dbf1ea7a-8de4-48a5-8759-03495e3e3c08@github.com>
 <MF0zpJDtYFB2xtM1C0MdccfCvu1xwLTGid-rfVrbaa4=.04763a1f-aaed-4c5e-afac-744686c23c41@github.com>
 <L6Y-UqXHQNQ7ZLxmxkhwwvB4hjuhNGt64_t
 _Y2qnTBU=.82107aad-c347-46db-b50a-7f7be4fb73e2@github.com>
 <9oXnHULCd76_J69CKMVVZl3FfDte1pnt38y06LVV4Sg=.26a4ab2c-5ff7-4e2f-9428-0d8cd931d243@github.com>
 <szc1adVdikwcXJce3l4OZFrtAssQqYb_vcTCuF5JX7o=.49900b63-9954-41cd-94a5-fcebb2bd5acb@github.com>
 <re_7RZBHcdt8xcLI8gYUy4Oq_h0KwB55HSXOylU-icA=.a474d1b8-5007-459f-8bd2-17d068660799@github.com>
Message-ID: <4Ek_anRMgDzvodg-QJQuJWZOnx8pr8ulnnUf47OQ_ak=.d761073f-860c-43d0-a359-6f32f8bc2e2f@github.com>

On Mon, 21 Dec 2020 16:03:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> FWIW, I started working on a framework which would add support for selectable backends for hsdis. Unfortunately it was not as simple as I initially thought, so I had to put it on hold while directing my time to working on the winenv patch instead.
>> 
>> I believe the proper way forward is to get the "selectable hsdis backend" framework in place, and then retrofit this patch to add LLVM support in that framework. If this means that this PR should be closed, or kept open until this is done, I don't know.
>
> Nag nag bot...
> 
> I'm away for the holidays now, but I intend to pick up the work on the selectable hsdis backend when I return. So while this exact code is unlikely to be the one merged, it's good to have it open to allow me to double check the solutions picked here.

@magicus that PR fell off my plate, but I'm happy to pick it up based on your "selectable hsdis backend" change.

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

PR: https://git.openjdk.java.net/jdk/pull/392


From amenkov at openjdk.java.net  Tue Dec 22 18:16:55 2020
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 22 Dec 2020 18:16:55 GMT
Subject: RFR: 8257928: Test image build failure with clang-10 due to
 -Wmisleading-indentation
In-Reply-To: <b-F3PhjqWssucURHd8wMGcsKEmSZf653mYa2OKO1D2s=.a460967e-3407-4548-b580-891b6d543198@github.com>
References: <b-F3PhjqWssucURHd8wMGcsKEmSZf653mYa2OKO1D2s=.a460967e-3407-4548-b580-891b6d543198@github.com>
Message-ID: <KpOPlw_HXIknjpHHxkUsJPLoz1OKrO-J88Y-dBTic2w=.18b867b3-3f59-4d35-ab19-1b6a4841fb33@github.com>

On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and
> gcc-6 [2]. Putting the code with proper indentations would suppress this
> warning.
> 
> The main reason why test image build with gcc succeeds is that, clang
> and gcc might behave differently for some corner cases under
> '-Wmisleading-indentation'.
> 
> The following code snippet is crafted based on this build failure, where
> each statement with improper indentation (line A and line B) follows an
> if-statement. The key difference between foo() and bar() lies in that
> there exists an extra comment, i.e. "/* comment 2 */", between statement
> at line A and the if-statement.
> 
>     int foo(int num) {
>       /* comment 1 */
>       if (num > 1)
>         return 0;
> 
>       /* comment 2 */
>         num = num + 1;  // line A
>       return num;
>     }
> 
>     int bar(int val) {
>       /* comment 3 */
>       if (val > 1)
>         return 0;
> 
>         val = val + 1;  // line B
>       return val;
>     }
> 
> It's worth noting that foo() is quite similar to the erroneous code in
> this build failure. Clang-10 would emit misleading indentation warnings
> for both foo() and bar(), whereas gcc-6 or higher considers foo() free
> of problems. [3]
> 
> This patch is a complement to JDK-8253892. In JDK-8253892, flag
> '-Wmisleading-indentation' is disabled for both clang and gcc when
> building JRE and JDK images. This patch does not disable the flag for
> test image building, but just fixes the code, becasue:
>   - only a small number of warnings are produced and it's easy to fix
>   them one by one.
>   - inconsistent warning behaviors between gcc and clang are triggered
>   by this case and simply disabling the flag does not work.
> 
> Note that AArch64 is NOT tested because test image build still fails
> after this bug is fixed due to another runtime error (See JDK-8257936),
> which is not related to this patch.
> 
> [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html
> [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options
> [3] https://godbolt.org/z/xs6xWv
> 
> ---------------------
> We have tested with this patch, the test image can be built successfully with clang-10 on Linux X86 machine.

Marked as reviewed by amenkov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1709


From cjplummer at openjdk.java.net  Tue Dec 22 19:19:55 2020
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 22 Dec 2020 19:19:55 GMT
Subject: RFR: 8257928: Test image build failure with clang-10 due to
 -Wmisleading-indentation
In-Reply-To: <b-F3PhjqWssucURHd8wMGcsKEmSZf653mYa2OKO1D2s=.a460967e-3407-4548-b580-891b6d543198@github.com>
References: <b-F3PhjqWssucURHd8wMGcsKEmSZf653mYa2OKO1D2s=.a460967e-3407-4548-b580-891b6d543198@github.com>
Message-ID: <7e-w6rdmO_JE0zmLCVAptzuLlL6nLZ55ULxpqJEYu9c=.700ab28a-7e4a-4093-9110-379159dd9112@github.com>

On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and
> gcc-6 [2]. Putting the code with proper indentations would suppress this
> warning.
> 
> The main reason why test image build with gcc succeeds is that, clang
> and gcc might behave differently for some corner cases under
> '-Wmisleading-indentation'.
> 
> The following code snippet is crafted based on this build failure, where
> each statement with improper indentation (line A and line B) follows an
> if-statement. The key difference between foo() and bar() lies in that
> there exists an extra comment, i.e. "/* comment 2 */", between statement
> at line A and the if-statement.
> 
>     int foo(int num) {
>       /* comment 1 */
>       if (num > 1)
>         return 0;
> 
>       /* comment 2 */
>         num = num + 1;  // line A
>       return num;
>     }
> 
>     int bar(int val) {
>       /* comment 3 */
>       if (val > 1)
>         return 0;
> 
>         val = val + 1;  // line B
>       return val;
>     }
> 
> It's worth noting that foo() is quite similar to the erroneous code in
> this build failure. Clang-10 would emit misleading indentation warnings
> for both foo() and bar(), whereas gcc-6 or higher considers foo() free
> of problems. [3]
> 
> This patch is a complement to JDK-8253892. In JDK-8253892, flag
> '-Wmisleading-indentation' is disabled for both clang and gcc when
> building JRE and JDK images. This patch does not disable the flag for
> test image building, but just fixes the code, becasue:
>   - only a small number of warnings are produced and it's easy to fix
>   them one by one.
>   - inconsistent warning behaviors between gcc and clang are triggered
>   by this case and simply disabling the flag does not work.
> 
> Note that AArch64 is NOT tested because test image build still fails
> after this bug is fixed due to another runtime error (See JDK-8257936),
> which is not related to this patch.
> 
> [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html
> [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options
> [3] https://godbolt.org/z/xs6xWv
> 
> ---------------------
> We have tested with this patch, the test image can be built successfully with clang-10 on Linux X86 machine.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1709


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 01:34:56 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 01:34:56 GMT
Subject: Integrated: 8257928: Test image build failure with clang-10 due to
 -Wmisleading-indentation
In-Reply-To: <b-F3PhjqWssucURHd8wMGcsKEmSZf653mYa2OKO1D2s=.a460967e-3407-4548-b580-891b6d543198@github.com>
References: <b-F3PhjqWssucURHd8wMGcsKEmSZf653mYa2OKO1D2s=.a460967e-3407-4548-b580-891b6d543198@github.com>
Message-ID: <7NtRFBxuoWO8Z18Xf59SnIZDZpDHAFgKZ9XVFlydVuo=.51a8cfac-dbde-4857-baf6-d99f37c52e66@github.com>

On Wed, 9 Dec 2020 07:11:53 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> Flag '-Wmisleading-indentation' was introduced since clang-10 [1] and
> gcc-6 [2]. Putting the code with proper indentations would suppress this
> warning.
> 
> The main reason why test image build with gcc succeeds is that, clang
> and gcc might behave differently for some corner cases under
> '-Wmisleading-indentation'.
> 
> The following code snippet is crafted based on this build failure, where
> each statement with improper indentation (line A and line B) follows an
> if-statement. The key difference between foo() and bar() lies in that
> there exists an extra comment, i.e. "/* comment 2 */", between statement
> at line A and the if-statement.
> 
>     int foo(int num) {
>       /* comment 1 */
>       if (num > 1)
>         return 0;
> 
>       /* comment 2 */
>         num = num + 1;  // line A
>       return num;
>     }
> 
>     int bar(int val) {
>       /* comment 3 */
>       if (val > 1)
>         return 0;
> 
>         val = val + 1;  // line B
>       return val;
>     }
> 
> It's worth noting that foo() is quite similar to the erroneous code in
> this build failure. Clang-10 would emit misleading indentation warnings
> for both foo() and bar(), whereas gcc-6 or higher considers foo() free
> of problems. [3]
> 
> This patch is a complement to JDK-8253892. In JDK-8253892, flag
> '-Wmisleading-indentation' is disabled for both clang and gcc when
> building JRE and JDK images. This patch does not disable the flag for
> test image building, but just fixes the code, becasue:
>   - only a small number of warnings are produced and it's easy to fix
>   them one by one.
>   - inconsistent warning behaviors between gcc and clang are triggered
>   by this case and simply disabling the flag does not work.
> 
> Note that AArch64 is NOT tested because test image build still fails
> after this bug is fixed due to another runtime error (See JDK-8257936),
> which is not related to this patch.
> 
> [1] https://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html
> [2] https://gcc.gnu.org/onlinedocs/gcc-6.5.0/gcc/Warning-Options.html#Warning-Options
> [3] https://godbolt.org/z/xs6xWv
> 
> ---------------------
> We have tested with this patch, the test image can be built successfully with clang-10 on Linux X86 machine.

This pull request has now been integrated.

Changeset: 4ea88512
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4ea88512
Stats:     8 lines in 4 files changed: 0 ins; 0 del; 8 mod

8257928: Test image build failure with clang-10 due to -Wmisleading-indentation

Reviewed-by: amenkov, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/1709


From jjg at openjdk.java.net  Wed Dec 23 01:35:07 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 01:35:07 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v4]
In-Reply-To: <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>
Message-ID: <XKTvz2-x2vrvW523LJlGWOkDOqJP27e2n5OiqmmVjZY=.abce90e3-4e29-4a89-aa99-1f74a8bf95ea@github.com>

On Fri, 18 Dec 2020 01:34:15 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5th: 8257204 and 8256313
>   8257204: Remove usage of -Xhtmlversion option from javac
>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

src/jdk.compiler/share/man/javac.1 line 638:

> 636: .RS
> 637: .RE
> 638: .TP

In general, you should not edit files like this; these files are generated from upstream Markdown files.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Wed Dec 23 01:35:05 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 01:35:05 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
Message-ID: <g106P5efLYq8H9ekh04enafDvGW0IRB4Z4NyFN6j_8E=.9399c3bb-bb9e-46a5-83f2-a5e7c68dcddf@github.com>

On Fri, 18 Dec 2020 02:34:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5th: 8258460: Remove --doclint-format option from javac

Looks good.
I'll pull down a copy, for review in an IDE and to build and run tests, and if that goes OK, I will approve it.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 01:52:01 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 01:52:01 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
Message-ID: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>

1. '-Wdeprecated-copy'
As specified in C++11 [1], "the generation of the implicitly-defined
copy constructor is deprecated if T has a user-defined destructor or
user-defined copy assignment operator". The rationale behind is the
well-known Rule of Three [2].

Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
warns about the C++11 deprecation of implicitly declared copy
constructor and assignment operator if one of them is user-provided.
Defining an explicit copy constructor would suppress this warning.

The main reason why debug build with gcc-9 or higher succeeds lies in
the inconsistent warning behaviors between gcc and clang. See the
reduced code example [5]. We suspect it might be return value
optimization/copy elision [6] that drives gcc not to declare implicit
copy constructor for this case.

Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise
warnings for deprecated defintions of copy constructors. However,
'-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8
and clang-9 are not affected.

2. '-Wimplicit-int-float-conversion'
Making the conversion explicit would fix it.

Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
Therefore clang-8 and clang-9 are not affected. The flag with similar
functionality in gcc is '-Wfloat-conversion', but it is not enabled by
'-Wall' or '-Wextra'. That's why this warning does not apprear when
building with gcc.

[1] https://en.cppreference.com/w/cpp/language/copy_constructor
[2] https://en.cppreference.com/w/cpp/language/rule_of_three
[3] https://www.gnu.org/software/gcc/gcc-9/changes.html
[4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
[5] https://godbolt.org/z/err4jM
[6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization


Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines.

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

Commit messages:
 - 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion

Changes: https://git.openjdk.java.net/jdk/pull/1874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258010
  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874

PR: https://git.openjdk.java.net/jdk/pull/1874


From ysatowse at openjdk.java.net  Wed Dec 23 02:25:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 02:25:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <g106P5efLYq8H9ekh04enafDvGW0IRB4Z4NyFN6j_8E=.9399c3bb-bb9e-46a5-83f2-a5e7c68dcddf@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <g106P5efLYq8H9ekh04enafDvGW0IRB4Z4NyFN6j_8E=.9399c3bb-bb9e-46a5-83f2-a5e7c68dcddf@github.com>
Message-ID: <6eJV9qXpBqWxbpH2x-RbDWpL9uOTjsCjIu5jhbQ-wSI=.c14cb5c3-266c-423f-924a-6159aa9dd502@github.com>

On Wed, 23 Dec 2020 01:32:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> Looks good.
> I'll pull down a copy, for review in an IDE and to build and run tests, and if that goes OK, I will approve it.

test comment

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

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Wed Dec 23 05:05:05 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 05:05:05 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v4]
In-Reply-To: <XKTvz2-x2vrvW523LJlGWOkDOqJP27e2n5OiqmmVjZY=.abce90e3-4e29-4a89-aa99-1f74a8bf95ea@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>
 <XKTvz2-x2vrvW523LJlGWOkDOqJP27e2n5OiqmmVjZY=.abce90e3-4e29-4a89-aa99-1f74a8bf95ea@github.com>
Message-ID: <7_wU3eWhv3jNcD6RLyg4Z9V0uM7PHklBQJqfeJmycZI=.e5251839-6fe9-4e79-9877-539af1098ad5@github.com>

On Wed, 23 Dec 2020 01:27:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> src/jdk.compiler/share/man/javac.1 line 638:
> 
>> 636: .RS
>> 637: .RE
>> 638: .TP
> 
> In general, you should not edit files like this; these files are generated from upstream Markdown files.

Ok.  I will revert this with the next commit.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Wed Dec 23 05:13:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 05:13:04 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
Message-ID: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>

On Fri, 18 Dec 2020 02:34:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5th: 8258460: Remove --doclint-format option from javac

One must-fix item (bad pattern constant.)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 736:

> 734: 
> 735:     // https://html.spec.whatwg.org/#the-id-attribute
> 736:     private static final Pattern validId = Pattern.compile("[^\s]+");

The regular expression is invalid and needs to be fixed. It should be `Pattern.compile("[^\\s]+")`
Note the extra `` character. This is because you need to escape the `` character in the string constant, so that the `` is seen in the pattern as part of `\s`.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 710:

> 708: 
> 709: 
> 710:     private boolean checkAnchor(String name) {

I was going to let it slide for this round of cleanup, but if you're editing this file again (see comment on line 736) it might be worth changing the use of `anchor` to `id`.  `anchor` is a term that was more appropriate in the days before the `id` attribute, when we used `<a name="...">`.  This is an optional suggestion.  It might equally be worth focussing on the must-fix items, and postpone this cleanup for later.

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

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Wed Dec 23 05:41:02 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 05:41:02 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
Message-ID: <K-lT5fBVeSNjXs6FNgsFaLRrhQWu-kclfX3TZf7FBXw=.55005f37-8658-4596-bb78-1b719af0f8e8@github.com>

On Wed, 23 Dec 2020 05:01:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 736:
> 
>> 734: 
>> 735:     // https://html.spec.whatwg.org/#the-id-attribute
>> 736:     private static final Pattern validId = Pattern.compile("[^\s]+");
> 
> The regular expression is invalid and needs to be fixed. It should be `Pattern.compile("[^\\s]+")`
> Note the extra `` character. This is because you need to escape the `` character in the string constant, so that the `` is seen in the pattern as part of `\s`.

Correct.  Thanks a lot for finding this error.  
Now that I have doubts why this line could have been compiled without error.  This line should cause a compiler error.

Let me review all anchor tests again because the logic should be checked there.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 05:53:04 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 05:53:04 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205
Message-ID: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>

The declaration sites for JVM flags were changed by JDK-8243205 and the
subsequent JDK-8258074. As a result, undeclared identifier errors
occurred while building VM without compiler1 or compiler2 feature.

Making the corresponding header files included would fix it.

Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.

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

Commit messages:
 - 8258856: VM build without C1/C2 fails after JDK-8243205

Changes: https://git.openjdk.java.net/jdk/pull/1876/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1876&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258856
  Stats: 4 lines in 3 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1876.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1876/head:pull/1876

PR: https://git.openjdk.java.net/jdk/pull/1876


From jiefu at openjdk.java.net  Wed Dec 23 06:34:56 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Dec 2020 06:34:56 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205
In-Reply-To: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
Message-ID: <RuGH-Vmeq3F5lBUPkW1cUNwhAsICwbFmOSX8IUs3d-E=.a845f7e9-2fe8-4a7b-bf29-b208f57cb52d@github.com>

On Wed, 23 Dec 2020 05:48:10 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> The declaration sites for JVM flags were changed by JDK-8243205 and the
> subsequent JDK-8258074. As a result, undeclared identifier errors
> occurred while building VM without compiler1 or compiler2 feature.
> 
> Making the corresponding header files included would fix it.
> 
> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.

Changes requested by jiefu (Committer).

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 33:

> 31: #include "gc/shared/barrierSetNMethod.hpp"
> 32: #include "interpreter/interpreter.hpp"
> 33: #include "jvmci/jvmci_globals.hpp"

I would suggest #if INCLUDE_JVMCI for the added header file.

src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 30:

> 28: #include "gc/shared/cardTable.hpp"
> 29: #include "gc/shared/collectedHeap.hpp"
> 30: #include "jvmci/jvmci_globals.hpp"

This line can be removed since compiler/compiler_globals.hpp already includes jvmci_globals.hpp, right?

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From ysatowse at openjdk.java.net  Wed Dec 23 06:45:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 06:45:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
Message-ID: <SaZ-FbYfWjRxEVFDxnDM8nP_ljpFw-nj4Pe-mzl759s=.cf773bed-11dc-4017-bf0c-8aefd0c9873b@github.com>

On Wed, 23 Dec 2020 05:08:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 710:
> 
>> 708: 
>> 709: 
>> 710:     private boolean checkAnchor(String name) {
> 
> I was going to let it slide for this round of cleanup, but if you're editing this file again (see comment on line 736) it might be worth changing the use of `anchor` to `id`.  `anchor` is a term that was more appropriate in the days before the `id` attribute, when we used `<a name="...">`.  This is an optional suggestion.  It might equally be worth focussing on the must-fix items, and postpone this cleanup for later.

I understand.  But is it really no problem to be done in part of the cleanup of doclint?  
Looking at the classes in jdk/javadoc/internal/doclint,  the term `(anchor|Anchor)` looks like only used in Checker.java and resource files.  But a lot of other files, for instance in jdk/javadoc/internal/doclets, use this term to refer to the `id` or `name` attribute.  I would be fine if it is supposed to be done in each cleanup in the future.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 07:00:57 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 07:00:57 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205
In-Reply-To: <RuGH-Vmeq3F5lBUPkW1cUNwhAsICwbFmOSX8IUs3d-E=.a845f7e9-2fe8-4a7b-bf29-b208f57cb52d@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <RuGH-Vmeq3F5lBUPkW1cUNwhAsICwbFmOSX8IUs3d-E=.a845f7e9-2fe8-4a7b-bf29-b208f57cb52d@github.com>
Message-ID: <INfZ1dD45jHgXMomTMjKDOAvZ--I3YcG0YIdemtoUt4=.fb8b47d7-a88b-4cdd-a5ea-d892344cdc6f@github.com>

On Wed, 23 Dec 2020 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>> 
>> Making the corresponding header files included would fix it.
>> 
>> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 33:
> 
>> 31: #include "gc/shared/barrierSetNMethod.hpp"
>> 32: #include "interpreter/interpreter.hpp"
>> 33: #include "jvmci/jvmci_globals.hpp"
> 
> I would suggest #if INCLUDE_JVMCI for the added header file.

Thanks for your comment. Agree. Will add it.

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 07:16:54 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 07:16:54 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205
In-Reply-To: <RuGH-Vmeq3F5lBUPkW1cUNwhAsICwbFmOSX8IUs3d-E=.a845f7e9-2fe8-4a7b-bf29-b208f57cb52d@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <RuGH-Vmeq3F5lBUPkW1cUNwhAsICwbFmOSX8IUs3d-E=.a845f7e9-2fe8-4a7b-bf29-b208f57cb52d@github.com>
Message-ID: <c0paYL0Db3IUMpSeVDVpwGo62UOEHWxFJTY6lR28aug=.4e97be6d-4585-4bd9-93c1-1261f4bbd8bb@github.com>

On Wed, 23 Dec 2020 06:31:08 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>> 
>> Making the corresponding header files included would fix it.
>> 
>> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.
>
> src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp line 30:
> 
>> 28: #include "gc/shared/cardTable.hpp"
>> 29: #include "gc/shared/collectedHeap.hpp"
>> 30: #include "jvmci/jvmci_globals.hpp"
> 
> This line can be removed since compiler/compiler_globals.hpp already includes jvmci_globals.hpp, right?

Yes, you are right. Will remove. Thanks a lot.

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From ysatowse at openjdk.java.net  Wed Dec 23 07:54:02 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 07:54:02 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <K-lT5fBVeSNjXs6FNgsFaLRrhQWu-kclfX3TZf7FBXw=.55005f37-8658-4596-bb78-1b719af0f8e8@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <K-lT5fBVeSNjXs6FNgsFaLRrhQWu-kclfX3TZf7FBXw=.55005f37-8658-4596-bb78-1b719af0f8e8@github.com>
Message-ID: <7A3J6XuVSinC1anOYqPp1FkPmq7D25z6Ed8x-dXUJsA=.3c9a56cd-cc38-4ab4-8f88-f991fd7709dd@github.com>

On Wed, 23 Dec 2020 05:38:36 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 736:
>> 
>>> 734: 
>>> 735:     // https://html.spec.whatwg.org/#the-id-attribute
>>> 736:     private static final Pattern validId = Pattern.compile("[^\s]+");
>> 
>> The regular expression is invalid and needs to be fixed. It should be `Pattern.compile("[^\\s]+")`
>> Note the extra `` character. This is because you need to escape the `` character in the string constant, so that the `` is seen in the pattern as part of `\s`.
>
> Correct.  Thanks a lot for finding this error.  
> Now that I have doubts why this line could have been compiled without error.  This line should cause a compiler error.
> 
> Let me review all anchor tests again because the logic should be checked there.

For some reason, `"[^\s]+"` might have been dealt with as a text block, thus `\s` was regarded as a whitespace...
I believe a text block is defined with triple double quotes, but javac seems to accept `"[^\s]+"` as a text block.

That aside, all anchor tests look fine.  This is because there is no specific test to use whitespace characters such as `\n`, `\t`, `\r` and `\f` in an anchor name.  Also I confirmed the discrepancy of the results for `"[^\s]+"` and `"[^\\s]+"`.  It shows that the former is not exactly what we want to do.

$ jshell -J-Duser.language=en -J--show-version
java 15 2020-09-15
Java(TM) SE Runtime Environment (build 15+36-1562)
Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)
|  Welcome to JShell -- Version 15
|  For an introduction type: /help intro

jshell> Pattern validId1 = Pattern.compile("[^\s]+")
validId1 ==> [^ ]+

jshell> Pattern validId2 = Pattern.compile("[^\\s]+")
validId2 ==> [^\s]+

jshell> validId1.matcher("aaa").matches()
$3 ==> true

jshell> validId1.matcher("aaa ").matches()
$4 ==> false

jshell> validId1.matcher("aaa\n").matches()
$5 ==> true

jshell> validId2.matcher("aaa").matches()
$6 ==> true

jshell> validId2.matcher("aaa ").matches()
$7 ==> false

jshell> validId2.matcher("aaa\n").matches()
$8 ==> false

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

PR: https://git.openjdk.java.net/jdk/pull/893


From ysatowse at openjdk.java.net  Wed Dec 23 08:18:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 08:18:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <SaZ-FbYfWjRxEVFDxnDM8nP_ljpFw-nj4Pe-mzl759s=.cf773bed-11dc-4017-bf0c-8aefd0c9873b@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <SaZ-FbYfWjRxEVFDxnDM8nP_ljpFw-nj4Pe-mzl759s=.cf773bed-11dc-4017-bf0c-8aefd0c9873b@github.com>
Message-ID: <hEsFMq6xyUUyDmTATPckbAPUprE9p2Ycqqzk2GXUlJM=.6308c33d-0ba2-4de7-9c63-b26b9783a138@github.com>

On Wed, 23 Dec 2020 06:42:21 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 710:
>> 
>>> 708: 
>>> 709: 
>>> 710:     private boolean checkAnchor(String name) {
>> 
>> I was going to let it slide for this round of cleanup, but if you're editing this file again (see comment on line 736) it might be worth changing the use of `anchor` to `id`.  `anchor` is a term that was more appropriate in the days before the `id` attribute, when we used `<a name="...">`.  This is an optional suggestion.  It might equally be worth focussing on the must-fix items, and postpone this cleanup for later.
>
> I understand.  But is it really no problem to be done in part of the cleanup of doclint?  
> Looking at the classes in jdk/javadoc/internal/doclint,  the term `(anchor|Anchor)` looks like only used in Checker.java and resource files.  But a lot of other files, for instance in jdk/javadoc/internal/doclets, use this term to refer to the `id` or `name` attribute.  I would be fine if it is supposed to be done in each cleanup in the future.

If we would apply similar changing to doclint.properties, what you are thinking is like below right?

-dc.anchor.already.defined = anchor already defined: "{0}"
-dc.anchor.value.missing = no value given for anchor
+dc.id.already.defined = attribute "id" already defined: "{0}"
+dc.id.value.missing = no value given for attribute "id"

-dc.invalid.anchor = invalid name for anchor: "{0}"
-dc.invalid.id = invalid name for attribute "id": "{0}"

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

PR: https://git.openjdk.java.net/jdk/pull/893


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 09:28:11 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 09:28:11 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v2]
In-Reply-To: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
Message-ID: <chL8izZOhCqofKueamhHzK-6pENarS8qr5wcxcfjX2c=.d812e7b6-50f2-441f-9d8c-772bfaddda6f@github.com>

> The declaration sites for JVM flags were changed by JDK-8243205 and the
> subsequent JDK-8258074. As a result, undeclared identifier errors
> occurred while building VM without compiler1 or compiler2 feature.
> 
> Making the corresponding header files included would fix it.
> 
> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.

Hao Sun has updated the pull request incrementally with one additional commit since the last revision:

  Use JVMCI compilation condition and remove redundant header
  
  Check the compilation condition INCLUDE_JVMCI before trying to include
  the header file, i.e. jvmci_globals.hpp, for stubGenerator_x86_64.cpp
  
  In jvmciCompilerToVMInit.cpp, remove the redundant header
  jvmci_globals.hpp since it is already included by compiler_globals.hpp
  
  Change-Id: I8858d4ca94b6d12396db6bbebf226b351b5f230a
  CustomizedGitHooks: yes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1876/files
  - new: https://git.openjdk.java.net/jdk/pull/1876/files/22cec1dd..b0bb2de2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1876&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1876&range=00-01

  Stats: 5 lines in 2 files changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1876.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1876/head:pull/1876

PR: https://git.openjdk.java.net/jdk/pull/1876


From jiefu at openjdk.java.net  Wed Dec 23 09:36:58 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Dec 2020 09:36:58 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v2]
In-Reply-To: <chL8izZOhCqofKueamhHzK-6pENarS8qr5wcxcfjX2c=.d812e7b6-50f2-441f-9d8c-772bfaddda6f@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <chL8izZOhCqofKueamhHzK-6pENarS8qr5wcxcfjX2c=.d812e7b6-50f2-441f-9d8c-772bfaddda6f@github.com>
Message-ID: <rGdzfm21pR6b9t9-B1PO-h75AMvAcptzBZ64KU2HGOM=.da4ee2ab-ab1d-4b7f-9756-f1a57df7f21f@github.com>

On Wed, 23 Dec 2020 09:28:11 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>> 
>> Making the corresponding header files included would fix it.
>> 
>> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.
>
> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use JVMCI compilation condition and remove redundant header
>   
>   Check the compilation condition INCLUDE_JVMCI before trying to include
>   the header file, i.e. jvmci_globals.hpp, for stubGenerator_x86_64.cpp
>   
>   In jvmciCompilerToVMInit.cpp, remove the redundant header
>   jvmci_globals.hpp since it is already included by compiler_globals.hpp
>   
>   Change-Id: I8858d4ca94b6d12396db6bbebf226b351b5f230a
>   CustomizedGitHooks: yes

src/hotspot/share/compiler/oopMap.cpp line 32:

> 30: #include "compiler/oopMap.hpp"
> 31: #include "gc/shared/collectedHeap.hpp"
> 32: #include "jvmci/jvmci_globals.hpp"

Also #if INCLUDE_JVMCI here?

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 10:00:58 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 10:00:58 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v2]
In-Reply-To: <rGdzfm21pR6b9t9-B1PO-h75AMvAcptzBZ64KU2HGOM=.da4ee2ab-ab1d-4b7f-9756-f1a57df7f21f@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <chL8izZOhCqofKueamhHzK-6pENarS8qr5wcxcfjX2c=.d812e7b6-50f2-441f-9d8c-772bfaddda6f@github.com>
 <rGdzfm21pR6b9t9-B1PO-h75AMvAcptzBZ64KU2HGOM=.da4ee2ab-ab1d-4b7f-9756-f1a57df7f21f@github.com>
Message-ID: <M2BKlTviA_6nftxbt8xvTQf_DWQe0kr0ab3oJBSoCec=.588c3758-c7ef-4051-8c3f-f8e62b751554@github.com>

On Wed, 23 Dec 2020 09:33:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use JVMCI compilation condition and remove redundant header
>>   
>>   Check the compilation condition INCLUDE_JVMCI before trying to include
>>   the header file, i.e. jvmci_globals.hpp, for stubGenerator_x86_64.cpp
>>   
>>   In jvmciCompilerToVMInit.cpp, remove the redundant header
>>   jvmci_globals.hpp since it is already included by compiler_globals.hpp
>>   
>>   Change-Id: I8858d4ca94b6d12396db6bbebf226b351b5f230a
>>   CustomizedGitHooks: yes
>
> src/hotspot/share/compiler/oopMap.cpp line 32:
> 
>> 30: #include "compiler/oopMap.hpp"
>> 31: #include "gc/shared/collectedHeap.hpp"
>> 32: #include "jvmci/jvmci_globals.hpp"
> 
> Also #if INCLUDE_JVMCI here?

Thanks for pointing this out. Agree. Will add soon.

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 10:09:08 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 10:09:08 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]
In-Reply-To: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
Message-ID: <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>

> The declaration sites for JVM flags were changed by JDK-8243205 and the
> subsequent JDK-8258074. As a result, undeclared identifier errors
> occurred while building VM without compiler1 or compiler2 feature.
> 
> Making the corresponding header files included would fix it.
> 
> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.

Hao Sun has updated the pull request incrementally with one additional commit since the last revision:

  Use JVMCI compilation condition for oopMap.cpp
  
  Check the compilation condition INCLUDE_JVMCI before trying to include
  the header file, i.e. jvmci_globals.hpp, for oopMap.cpp
  
  Change-Id: I9885291d9f971984d83942669a22ee030722a206
  CustomizedGitHooks: yes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1876/files
  - new: https://git.openjdk.java.net/jdk/pull/1876/files/b0bb2de2..1cb58212

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1876&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1876&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1876.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1876/head:pull/1876

PR: https://git.openjdk.java.net/jdk/pull/1876


From jiefu at openjdk.java.net  Wed Dec 23 11:05:56 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Dec 2020 11:05:56 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]
In-Reply-To: <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
Message-ID: <oRquE92csKsRjre5qxzJjdWRooJQwLdWtaHUqZzmUmA=.a5200d6b-b811-456f-b12a-57eb1dc039fa@github.com>

On Wed, 23 Dec 2020 10:09:08 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>> 
>> Making the corresponding header files included would fix it.
>> 
>> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.
>
> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use JVMCI compilation condition for oopMap.cpp
>   
>   Check the compilation condition INCLUDE_JVMCI before trying to include
>   the header file, i.e. jvmci_globals.hpp, for oopMap.cpp
>   
>   Change-Id: I9885291d9f971984d83942669a22ee030722a206
>   CustomizedGitHooks: yes

LGTM
Thanks for the update.

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

Marked as reviewed by jiefu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/1876


From jjg at openjdk.java.net  Wed Dec 23 15:56:01 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 15:56:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
Message-ID: <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>

On Wed, 23 Dec 2020 05:10:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> One must-fix item (bad pattern constant.)

\s was introduced as a valid escape character in JDK 15 as part of the 
support for Text Blocks.

https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence
https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7

FWIW, the escape sequence showed up with red squiggly lines in my IDE.

-- Jon

On 12/22/20 9:38 PM, Yoshiki SATO wrote:
>
> *@satoyoshiki* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>:
>
> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>           return e;
>       }
>   
> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZibVYnjqnQ$>
> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZib5vw0eRg$>
> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>
> Correct. Thanks a lot for finding this error.
> Now that I have doubts why this line could have been compiled without 
> error. This line should cause a compiler error.
>
> Let me review all anchor tests again because the logic should be 
> checked there.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRXCJBCNZR4ZUBZCEBTSWF66TANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZia6kQL08w$>.
>

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

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Wed Dec 23 17:12:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 17:12:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
Message-ID: <xZxi9rbJ9VUlAsG3ZJrHI8dfziWoH1Gt0ti6IKe4wwI=.c8f0f568-b94e-4ba3-9451-e2ef361a6f11@github.com>

On Wed, 23 Dec 2020 15:53:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> One must-fix item (bad pattern constant.)
>
> \s was introduced as a valid escape character in JDK 15 as part of the 
> support for Text Blocks.
> 
> https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence
> https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7
> 
> FWIW, the escape sequence showed up with red squiggly lines in my IDE.
> 
> -- Jon
> 
> On 12/22/20 9:38 PM, Yoshiki SATO wrote:
>>
>> *@satoyoshiki* commented on this pull request.
>>
>> ------------------------------------------------------------------------
>>
>> In 
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>:
>>
>> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>>           return e;
>>       }
>>   
>> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZibVYnjqnQ$>
>> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
>> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZib5vw0eRg$>
>> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>>
>> Correct. Thanks a lot for finding this error.
>> Now that I have doubts why this line could have been compiled without 
>> error. This line should cause a compiler error.
>>
>> Let me review all anchor tests again because the logic should be 
>> checked there.
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRXCJBCNZR4ZUBZCEBTSWF66TANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZia6kQL08w$>.
>>

On 12/22/20 10:42 PM, Yoshiki SATO wrote:
>
> *@satoyoshiki* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>:
>
> > -    }
> -
> -    private void validateHtml5Attrs(AttributeTree tree, Name name, AttrKind k) {
> -        switch (k) {
> -            case ALL:
> -            case HTML5:
> -                break;
> -
> -            case INVALID:
> -            case OBSOLETE:
> -            case USE_CSS:
> -            case HTML4:
> -                env.messages.error(HTML, tree, "dc.attr.not.supported.html5", name);
> -                break;
> -        }
> -    }
>   
>       private boolean checkAnchor(String name) {
>
> I understand. But is it really no problem to be done in part of the 
> cleanup of doclint?
> Looking at the classes in jdk/javadoc/internal/doclint, the term 
> |(anchor|Anchor)| looks like only used in Checker.java and resource 
> files. But a lot of other files, for instance in 
> jdk/javadoc/internal/doclets, use this term to refer to the |id| or 
> |name| attribute. I would be fine if it is supposed to be done in each 
> cleanup in the future.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRQS4FULCERHKMAZ5OLSWGGNVANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVYEkdTG2A$>.
>

If you were to cleanup the "anchor" terminology, it should only be done 
in doclint, meaning Checker.java and resource files. Cleaning up 
terminology in the rest of javadoc is another project for another day. 
But, it's OK to skip this terminology cleanup in doclint at this time, 
since it is only peripherally related to the primary goal to remove 
HTML4 support.

-- Jon

>

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

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Wed Dec 23 17:15:01 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 17:15:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <xZxi9rbJ9VUlAsG3ZJrHI8dfziWoH1Gt0ti6IKe4wwI=.c8f0f568-b94e-4ba3-9451-e2ef361a6f11@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
 <xZxi9rbJ9VUlAsG3ZJrHI8dfziWoH1Gt0ti6IKe4wwI=.c8f0f568-b94e-4ba3-9451-e2ef361a6f11@github.com>
Message-ID: <RnaZOYLCduGjwzYR_Kq6vul_nmOFpjFDXfuYZ4Dt0Zo=.a22a9652-2e6d-49ac-a4cb-cc0b7d945b11@github.com>

On Wed, 23 Dec 2020 17:08:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> \s was introduced as a valid escape character in JDK 15 as part of the 
>> support for Text Blocks.
>> 
>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence
>> https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7
>> 
>> FWIW, the escape sequence showed up with red squiggly lines in my IDE.
>> 
>> -- Jon
>> 
>> On 12/22/20 9:38 PM, Yoshiki SATO wrote:
>>>
>>> *@satoyoshiki* commented on this pull request.
>>>
>>> ------------------------------------------------------------------------
>>>
>>> In 
>>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>:
>>>
>>> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>>>           return e;
>>>       }
>>>   
>>> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZibVYnjqnQ$>
>>> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
>>> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZib5vw0eRg$>
>>> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>>>
>>> Correct. Thanks a lot for finding this error.
>>> Now that I have doubts why this line could have been compiled without 
>>> error. This line should cause a compiler error.
>>>
>>> Let me review all anchor tests again because the logic should be 
>>> checked there.
>>>
>>> ?
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>, 
>>> or unsubscribe 
>>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRXCJBCNZR4ZUBZCEBTSWF66TANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZia6kQL08w$>.
>>>
>
> On 12/22/20 10:42 PM, Yoshiki SATO wrote:
>>
>> *@satoyoshiki* commented on this pull request.
>>
>> ------------------------------------------------------------------------
>>
>> In 
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>:
>>
>> > -    }
>> -
>> -    private void validateHtml5Attrs(AttributeTree tree, Name name, AttrKind k) {
>> -        switch (k) {
>> -            case ALL:
>> -            case HTML5:
>> -                break;
>> -
>> -            case INVALID:
>> -            case OBSOLETE:
>> -            case USE_CSS:
>> -            case HTML4:
>> -                env.messages.error(HTML, tree, "dc.attr.not.supported.html5", name);
>> -                break;
>> -        }
>> -    }
>>   
>>       private boolean checkAnchor(String name) {
>>
>> I understand. But is it really no problem to be done in part of the 
>> cleanup of doclint?
>> Looking at the classes in jdk/javadoc/internal/doclint, the term 
>> |(anchor|Anchor)| looks like only used in Checker.java and resource 
>> files. But a lot of other files, for instance in 
>> jdk/javadoc/internal/doclets, use this term to refer to the |id| or 
>> |name| attribute. I would be fine if it is supposed to be done in each 
>> cleanup in the future.
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRQS4FULCERHKMAZ5OLSWGGNVANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVYEkdTG2A$>.
>>
> 
> If you were to cleanup the "anchor" terminology, it should only be done 
> in doclint, meaning Checker.java and resource files. Cleaning up 
> terminology in the rest of javadoc is another project for another day. 
> But, it's OK to skip this terminology cleanup in doclint at this time, 
> since it is only peripherally related to the primary goal to remove 
> HTML4 support.
> 
> -- Jon
> 
>>

Although `\s` was introduced as part of the work for text blocks, it was 
added to the set of escape characters accepted in string and character 
literals. So, no, that constant is not being treated as a text block, 
because text blocks only begin and end with triple-quotes: `"""`

See the JLS links I gave in my previous response.

-- Jon

On 12/22/20 11:50 PM, Yoshiki SATO wrote:
>
> *@satoyoshiki* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547768833__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpJdsJ1BgQ$>:
>
> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>           return e;
>       }
>   
> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpJRSKFcFA$>
> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpLwqIk5gQ$>
> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>
> For some reason, |"[^\s]+"| might have been dealt with as a text 
> block, thus |\s| was regarded as a whitespace...
> I believe a text block is defined with triple double quotes, but javac 
> seems to accept |"[^\s]+"| as a text block.
>
> That aside, all anchor tests look fine. This is because there is no 
> specific test to use whitespace characters such as |\n|, |\t|, |\r| 
> and |\f| in an anchor name. Also I confirmed the discrepancy of the 
> results for |"[^\s]+"| and |"[^\\s]+"|. It shows that the former is 
> not exactly what we want to do.
>
> /var/tmp/jib-yoshiki/install/jdk/15/36/bundles/osx-x64/jdk-15_osx-x64_bin.tar.gz/jdk-15.jdk/Contents/Home/bin/jshell 
> -J-Duser.language=en -J--show-version
> java 15 2020-09-15
> Java(TM) SE Runtime Environment (build 15+36-1562)
> Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)
> | Welcome to JShell -- Version 15
> | For an introduction type: /help intro
>
> jshell> Pattern validId1 = Pattern.compile("[^\s]+")
> validId1 ==> [^ ]+
>
> jshell> Pattern validId2 = Pattern.compile("[^\s]+")
> validId2 ==> [^\s]+
>
> jshell> validId1.matcher("aaa").matches()
> $3 ==> true
>
> jshell> validId1.matcher("aaa ").matches()
> $4 ==> false
>
> jshell> validId1.matcher("aaa\n").matches()
> $5 ==> true
>
> jshell> validId2.matcher("aaa").matches()
> $6 ==> true
>
> jshell> validId2.matcher("aaa ").matches()
> $7 ==> false
>
> jshell> validId2.matcher("aaa\n").matches()
> $8 ==> false
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547768833__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpJdsJ1BgQ$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRQZVY3MLTBJ7SZR7ETSWGONXANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpK72GWUdA$>.
>

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

PR: https://git.openjdk.java.net/jdk/pull/893


From kvn at openjdk.java.net  Wed Dec 23 18:39:55 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 23 Dec 2020 18:39:55 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]
In-Reply-To: <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
Message-ID: <-64t6euaJW59jMrj0HcsD8-tcZ1DNbRJKESvCZv9y2I=.46e7fd10-2a37-457e-bfa9-5080f6a40573@github.com>

On Wed, 23 Dec 2020 10:09:08 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>> 
>> Making the corresponding header files included would fix it.
>> 
>> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.
>
> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use JVMCI compilation condition for oopMap.cpp
>   
>   Check the compilation condition INCLUDE_JVMCI before trying to include
>   the header file, i.e. jvmci_globals.hpp, for oopMap.cpp
>   
>   Change-Id: I9885291d9f971984d83942669a22ee030722a206
>   CustomizedGitHooks: yes

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1876


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 23 23:17:57 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 23 Dec 2020 23:17:57 GMT
Subject: Integrated: 8258856: VM build without C1/C2 fails after JDK-8243205
In-Reply-To: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
Message-ID: <qCDilgBi-92aLg0GctiCEYrYdaVCv6ZbvhwsCYhix6w=.201e26fd-6041-463d-9aca-cc97662039f0@github.com>

On Wed, 23 Dec 2020 05:48:10 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> The declaration sites for JVM flags were changed by JDK-8243205 and the
> subsequent JDK-8258074. As a result, undeclared identifier errors
> occurred while building VM without compiler1 or compiler2 feature.
> 
> Making the corresponding header files included would fix it.
> 
> Note that we have tested locally with this patch, build without C1/C2 succeeded on Linux X86/AArch64 machines.

This pull request has now been integrated.

Changeset: cdb487a6
Author:    Hao Sun <hao.sun at arm.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cdb487a6
Stats:     7 lines in 3 files changed: 7 ins; 0 del; 0 mod

8258856: VM build without C1/C2 fails after JDK-8243205

Reviewed-by: jiefu, kvn

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From serb at openjdk.java.net  Thu Dec 24 01:04:57 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 24 Dec 2020 01:04:57 GMT
Subject: RFR: 8251854: [macosx] Java forces the use of discrete GPU
In-Reply-To: <SU_a7mV1C_lWYiRM61qkSbZwp49f9zq8eTLUtPYPzd8=.879ef998-b8ad-448d-a6c1-5155cc64646f@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
 <YhYXy8tdT7E_dCSss6az0WIpnfL1dxw2eVsCTWUwDJI=.33246b1e-7e53-455f-87ea-cf94081759e2@github.com>
 <SU_a7mV1C_lWYiRM61qkSbZwp49f9zq8eTLUtPYPzd8=.879ef998-b8ad-448d-a6c1-5155cc64646f@github.com>
Message-ID: <RE2kXuiglO457DJNjpWnXpvzUhRtspupNmgAr_77hWg=.e9a3a319-b269-499e-bdaf-6c3ce1a24699@github.com>

On Wed, 9 Dec 2020 17:40:34 GMT, Victor Dyakov <vdyakov at openjdk.org> wrote:

>>> > @kevinrushforth @prrace could you please review?
>>> 
>>> As we discussed yesterday, it is reviewed but not ready to be approved.
>>> We are waiting for a reply from Apple.
>> 
>> @prrace 
>> We are waiting for it for three months already. If it is possible then not sure why other applications did not found any possible ways to force one specific GPU. What we are wating for?
>
> @mrserb @prrace  what is a back up plan in case we will not have a reply from Apple? (as we do not have it for 4! months). Definitely we need a plan B

CSR is filed: https://bugs.openjdk.java.net/browse/JDK-8258918

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

PR: https://git.openjdk.java.net/jdk/pull/1139


From ysatowse at openjdk.java.net  Thu Dec 24 01:17:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 24 Dec 2020 01:17:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
Message-ID: <VDi3Ijs-MdtHTAXBk6LNoIDeCxdgIEuWWteMuyyeveI=.c1ac5846-7028-4247-92a6-be63a6ce935b@github.com>

On Wed, 23 Dec 2020 15:53:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> \s was introduced as a valid escape character in JDK 15 as part of the support for Text Blocks. https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7 FWIW, the escape sequence showed up with red squiggly lines in my IDE.
> [?](#)

Ok.  I didn't know that.  When I change my project SDK to 14, the escape sequence showed up with red squiggly.

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

PR: https://git.openjdk.java.net/jdk/pull/893


From philip.race at oracle.com  Thu Dec 24 01:56:13 2020
From: philip.race at oracle.com (Philip Race)
Date: Wed, 23 Dec 2020 17:56:13 -0800
Subject: <AWT Dev> RFR: 8251854: [macosx] Java forces the use of discrete
 GPU
In-Reply-To: <RE2kXuiglO457DJNjpWnXpvzUhRtspupNmgAr_77hWg=.e9a3a319-b269-499e-bdaf-6c3ce1a24699@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
 <epFJBT7ojxv5e7lJwX92LkMtHvFnWDTsiXg6SIcxFf8=.0b6d23db-89de-4521-89ef-5c0002968d90@github.com>
 <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com>
 <YhYXy8tdT7E_dCSss6az0WIpnfL1dxw2eVsCTWUwDJI=.33246b1e-7e53-455f-87ea-cf94081759e2@github.com>
 <SU_a7mV1C_lWYiRM61qkSbZwp49f9zq8eTLUtPYPzd8=.879ef998-b8ad-448d-a6c1-5155cc64646f@github.com>
 <RE2kXuiglO457DJNjpWnXpvzUhRtspupNmgAr_77hWg=.e9a3a319-b269-499e-bdaf-6c3ce1a24699@github.com>
Message-ID: <09c700c6-dc7f-0599-0a2d-9c8455532b59@oracle.com>


 From the CSR ;

 >This change also improves the startup performance, on my current new
 > laptop mbp 16 + BigSur 11.1 the switching discrete/integrated causes 
unexpected delays up to 10 seconds.

This also has to be a bug. I thought it had gone away. Have we reported 
that to Apple ?
If not we should do so ASAP.

-phil.

On 12/23/20 5:04 PM, Sergey Bylokhov wrote:
> On Wed, 9 Dec 2020 17:40:34 GMT, Victor Dyakov <vdyakov at openjdk.org> wrote:
>
>>>>> @kevinrushforth @prrace could you please review?
>>>> As we discussed yesterday, it is reviewed but not ready to be approved.
>>>> We are waiting for a reply from Apple.
>>> @prrace
>>> We are waiting for it for three months already. If it is possible then not sure why other applications did not found any possible ways to force one specific GPU. What we are wating for?
>> @mrserb @prrace  what is a back up plan in case we will not have a reply from Apple? (as we do not have it for 4! months). Definitely we need a plan B
> CSR is filed: https://bugs.openjdk.java.net/browse/JDK-8258918
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1139



From ysatowse at openjdk.java.net  Thu Dec 24 02:54:17 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 24 Dec 2020 02:54:17 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v6]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <iAxu3KnauDOTBgSQCyVQoI8PZXWJC96g-CTZQCD8dU8=.be3b7775-1a43-42ed-87cc-6471ff5baa13@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  7th: Some fixes and additional changes for 8247957

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/261f207a..8a0e1193

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=04-05

  Stats: 17 lines in 4 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Thu Dec 24 04:53:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 04:53:02 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v6]
In-Reply-To: <iAxu3KnauDOTBgSQCyVQoI8PZXWJC96g-CTZQCD8dU8=.be3b7775-1a43-42ed-87cc-6471ff5baa13@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <iAxu3KnauDOTBgSQCyVQoI8PZXWJC96g-CTZQCD8dU8=.be3b7775-1a43-42ed-87cc-6471ff5baa13@github.com>
Message-ID: <5hMtvUeQgEc5mk5_Fcb3vahTxPIviTG5pbDD_J0f1ec=.5fbd685c-606e-44e4-843d-449418c1a950@github.com>

On Thu, 24 Dec 2020 02:54:17 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7th: Some fixes and additional changes for 8247957

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/893


From dholmes at openjdk.java.net  Thu Dec 24 06:20:58 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 24 Dec 2020 06:20:58 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]
In-Reply-To: <-64t6euaJW59jMrj0HcsD8-tcZ1DNbRJKESvCZv9y2I=.46e7fd10-2a37-457e-bfa9-5080f6a40573@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
 <-64t6euaJW59jMrj0HcsD8-tcZ1DNbRJKESvCZv9y2I=.46e7fd10-2a37-457e-bfa9-5080f6a40573@github.com>
Message-ID: <o_NexFi-S3uRTDOPgbpEGrrygdgiza09XVyDPxRtxHU=.2e57f175-d50b-4a34-ba31-aba859ba5417@github.com>

On Wed, 23 Dec 2020 18:36:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use JVMCI compilation condition for oopMap.cpp
>>   
>>   Check the compilation condition INCLUDE_JVMCI before trying to include
>>   the header file, i.e. jvmci_globals.hpp, for oopMap.cpp
>>   
>>   Change-Id: I9885291d9f971984d83942669a22ee030722a206
>>   CustomizedGitHooks: yes
>
> Good.

Just an observation but it seems to me that if we are not including C1 or C2 in a build (ie interpreter-only) then really the build system should not be building the source files that had to be fixed.

David

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From github.com+16932759+shqking at openjdk.java.net  Thu Dec 24 06:56:56 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Thu, 24 Dec 2020 06:56:56 GMT
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]
In-Reply-To: <o_NexFi-S3uRTDOPgbpEGrrygdgiza09XVyDPxRtxHU=.2e57f175-d50b-4a34-ba31-aba859ba5417@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
 <-64t6euaJW59jMrj0HcsD8-tcZ1DNbRJKESvCZv9y2I=.46e7fd10-2a37-457e-bfa9-5080f6a40573@github.com>
 <o_NexFi-S3uRTDOPgbpEGrrygdgiza09XVyDPxRtxHU=.2e57f175-d50b-4a34-ba31-aba859ba5417@github.com>
Message-ID: <ip2KGU_b0FYrvUsqdug0OqjduW16Am3SGs-ndI9YWrc=.08c56712-6c71-40fd-b8d0-5e7427f3ccab@github.com>

On Thu, 24 Dec 2020 06:16:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Just an observation but it seems to me that if we are not including C1 or C2 in a build (ie interpreter-only) then really the build system should not be building the source files that had to be fixed.
> 
> David

Hi David, 
I guess "not including C1 or C2 in a build (ie interpreter-only)" refers to the zero build. 
Yes. Regarding zero build, these source files fixed in this patch would not be compiled.

However, the build failures this patch aimed to address are 'server build without C1 feature' and 'server build without C2 feature'.
'C1/C2' in the title of this PR means 'build without C1' or 'build without C2'.

As stated in JDK-8258856, the build failures can be reproduced by 
` ./configure --with-jvm-features=-compiler1 && make images`
and ` ./configure --with-jvm-features=-compiler2 && make images` respectively.

Hope that I made myself understood. Thanks.
Hao

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

PR: https://git.openjdk.java.net/jdk/pull/1876


From ysuenaga at openjdk.java.net  Thu Dec 24 09:35:02 2020
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 24 Dec 2020 09:35:02 GMT
Subject: RFR: 8258925: configure script failed on WSL
Message-ID: <oZD0e3fhaxVz7hjLzPAjKcwOcmpPy39uV2T8vw9PLXk=.faa7d235-23fb-4cb9-a99c-6ab07178ca88@github.com>

I ran configure script on WSL 1, but it failed as below:

$ bash configure --enable-debug --with-boot-jdk=/mnt/d/Java/jdk-15.0.1

    :

configure: Found potential Boot JDK using configure arguments
configure: The command for java_to_test, which resolves as "/mnt/d/Java/jdk-15.0.1/bin/java", can not be found.
configure: error: Cannot locate /mnt/d/Java/jdk-15.0.1/bin/java
configure exiting with result code 1

`fixpath.sh` attempts to run `$PATHTOOL` with `.exe` if it fails with original path, but `.exe` would not be added even if `$path.exe` exists.

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

Commit messages:
 - 8258925: configure script failed on WSL

Changes: https://git.openjdk.java.net/jdk/pull/1889/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1889&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258925
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1889.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1889/head:pull/1889

PR: https://git.openjdk.java.net/jdk/pull/1889


From kbarrett at openjdk.java.net  Thu Dec 24 13:29:53 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 24 Dec 2020 13:29:53 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
In-Reply-To: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
Message-ID: <lW9AALJDS7c0-iuXAWv7PJ5KRgGE09GVzC_SS_xHSus=.3e368f60-da21-423b-8579-7933ca000515@github.com>

On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> 1. '-Wdeprecated-copy'
> As specified in C++11 [1], "the generation of the implicitly-defined
> copy constructor is deprecated if T has a user-defined destructor or
> user-defined copy assignment operator". The rationale behind is the
> well-known Rule of Three [2].
> 
> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
> warns about the C++11 deprecation of implicitly declared copy
> constructor and assignment operator if one of them is user-provided.
> Defining an explicit copy constructor would suppress this warning.
> 
> The main reason why debug build with gcc-9 or higher succeeds lies in
> the inconsistent warning behaviors between gcc and clang. See the
> reduced code example [5]. We suspect it might be return value
> optimization/copy elision [6] that drives gcc not to declare implicit
> copy constructor for this case.
> 
> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise
> warnings for deprecated defintions of copy constructors. However,
> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8
> and clang-9 are not affected.
> 
> 2. '-Wimplicit-int-float-conversion'
> Making the conversion explicit would fix it.
> 
> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
> Therefore clang-8 and clang-9 are not affected. The flag with similar
> functionality in gcc is '-Wfloat-conversion', but it is not enabled by
> '-Wall' or '-Wextra'. That's why this warning does not apprear when
> building with gcc.
> 
> [1] https://en.cppreference.com/w/cpp/language/copy_constructor
> [2] https://en.cppreference.com/w/cpp/language/rule_of_three
> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html
> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
> [5] https://godbolt.org/z/err4jM
> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization
> 
> 
> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines.

I think the two issues described here are distinct and should be dealt
with in separate bugs and PRs.  Their only relation is that both arise
with using clang-10.  But they are very different problems, in very
different parts of the code, and probably ought to be reviewed by
folks from different teams.

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

PR: https://git.openjdk.java.net/jdk/pull/1874


From kbarrett at openjdk.java.net  Thu Dec 24 17:29:56 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 24 Dec 2020 17:29:56 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
In-Reply-To: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
Message-ID: <WhvBVqrbT7ar8EMzw2yFE83E4U0Zza-hGiRxqpVQigM=.8938cc9e-1790-401a-a1ad-156e367422f3@github.com>

On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> 1. '-Wdeprecated-copy'
> As specified in C++11 [1], "the generation of the implicitly-defined
> copy constructor is deprecated if T has a user-defined destructor or
> user-defined copy assignment operator". The rationale behind is the
> well-known Rule of Three [2].
> 
> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
> warns about the C++11 deprecation of implicitly declared copy
> constructor and assignment operator if one of them is user-provided.
> Defining an explicit copy constructor would suppress this warning.
> 
> The main reason why debug build with gcc-9 or higher succeeds lies in
> the inconsistent warning behaviors between gcc and clang. See the
> reduced code example [5]. We suspect it might be return value
> optimization/copy elision [6] that drives gcc not to declare implicit
> copy constructor for this case.
> 
> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise
> warnings for deprecated defintions of copy constructors. However,
> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8
> and clang-9 are not affected.
> 
> 2. '-Wimplicit-int-float-conversion'
> Making the conversion explicit would fix it.
> 
> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
> Therefore clang-8 and clang-9 are not affected. The flag with similar
> functionality in gcc is '-Wfloat-conversion', but it is not enabled by
> '-Wall' or '-Wextra'. That's why this warning does not apprear when
> building with gcc.
> 
> [1] https://en.cppreference.com/w/cpp/language/copy_constructor
> [2] https://en.cppreference.com/w/cpp/language/rule_of_three
> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html
> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
> [5] https://godbolt.org/z/err4jM
> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization
> 
> 
> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines.

src/hotspot/share/opto/node.hpp line 1458:

> 1456:   // initialize to garbage
> 1457: 
> 1458:   DUIterator_Last (const DUIterator_Last& that) : DUIterator_Fast(that) {}

Since DUIterator_Last is just delegating both the copy constructor and
assignment operator to the base class, their copy constructor and
assignment operator would be better as the default (either implicit or
explicit using `=default`) rather than explicit code.

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

PR: https://git.openjdk.java.net/jdk/pull/1874


From kim.barrett at oracle.com  Thu Dec 24 17:31:50 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 24 Dec 2020 12:31:50 -0500
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
In-Reply-To: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
Message-ID: <9E9D468D-5560-4F3B-8F45-4D3182F403D2@oracle.com>

> On Dec 22, 2020, at 8:52 PM, Hao Sun <github.com+16932759+shqking at openjdk.java.net> wrote:
> 
> 1. '-Wdeprecated-copy'
> As specified in C++11 [1], "the generation of the implicitly-defined
> copy constructor is deprecated if T has a user-defined destructor or
> user-defined copy assignment operator". The rationale behind is the
> well-known Rule of Three [2].
> 
> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
> warns about the C++11 deprecation of implicitly declared copy
> constructor and assignment operator if one of them is user-provided.
> Defining an explicit copy constructor would suppress this warning.
> 
> The main reason why debug build with gcc-9 or higher succeeds lies in
> the inconsistent warning behaviors between gcc and clang. See the
> reduced code example [5]. We suspect it might be return value
> optimization/copy elision [6] that drives gcc not to declare implicit
> copy constructor for this case.

C++17 "guaranteed copy elision" is implemented in gcc7.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html

Using -fno-elide-constructors makes it obvious that the deprecated
implicit copy constructors are indeed being elided, so no deprecation
warning.

Why doesn't this patch similarly define DUIterator copy constructor?
It seems to have the same issue, and I'm surprised clang-10 didn't
complain about it too. Certainly gcc with -fno-elide-constructors
complains about the defaulted implicit constructor.

But I discovered something alarming while experimenting.  Building
with gcc10.2 with -fno-elide-constructors doesn't seem to be possible.
I get different kinds of failures depending on how DUIterator is
defined:

- implict: deprecation warning (as expected)
- =delete: error, deleted function used
- =default: assert in os::free
- _idx and reset from that: assert in reset

Without -fno-elide-constructors, all of the variants seem to work
except =delete, which still fails because the deleted function is
used.  (I didn't test the "working" cases extensively though.)

So there's something problematic, though I don't understand the code
well enough to understand what.

Interestingly, some of the complexity and weirdness around copy/assign
for these classes may be an attempt at providing something like move
semantics in a C++98 code base. I've noticed a number of places in
HotSpot that are doing that.

Defining DUIterator_Fast and DUIterator_Last as movable but not
copyable (explicitly delete the copy constructor and copy assign
operator, and define the move constructor and move assign operator
with the reset) works, even with -fno-elide-constructors.




From xliu at openjdk.java.net  Thu Dec 24 20:44:56 2020
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 24 Dec 2020 20:44:56 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
In-Reply-To: <WhvBVqrbT7ar8EMzw2yFE83E4U0Zza-hGiRxqpVQigM=.8938cc9e-1790-401a-a1ad-156e367422f3@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
 <WhvBVqrbT7ar8EMzw2yFE83E4U0Zza-hGiRxqpVQigM=.8938cc9e-1790-401a-a1ad-156e367422f3@github.com>
Message-ID: <XhGsF7raCYs6PiefoFOC962KvGLRt21lVcJXhQnzm2w=.8f9cdf5f-d603-48a8-8d7e-938544635dad@github.com>

On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>> well-known Rule of Three [2].
>> 
>> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
>> warns about the C++11 deprecation of implicitly declared copy
>> constructor and assignment operator if one of them is user-provided.
>> Defining an explicit copy constructor would suppress this warning.
>> 
>> The main reason why debug build with gcc-9 or higher succeeds lies in
>> the inconsistent warning behaviors between gcc and clang. See the
>> reduced code example [5]. We suspect it might be return value
>> optimization/copy elision [6] that drives gcc not to declare implicit
>> copy constructor for this case.
>> 
>> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise
>> warnings for deprecated defintions of copy constructors. However,
>> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8
>> and clang-9 are not affected.
>> 
>> 2. '-Wimplicit-int-float-conversion'
>> Making the conversion explicit would fix it.
>> 
>> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
>> Therefore clang-8 and clang-9 are not affected. The flag with similar
>> functionality in gcc is '-Wfloat-conversion', but it is not enabled by
>> '-Wall' or '-Wextra'. That's why this warning does not apprear when
>> building with gcc.
>> 
>> [1] https://en.cppreference.com/w/cpp/language/copy_constructor
>> [2] https://en.cppreference.com/w/cpp/language/rule_of_three
>> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html
>> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
>> [5] https://godbolt.org/z/err4jM
>> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization
>> 
>> 
>> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines.
>
> src/hotspot/share/opto/node.hpp line 1458:
> 
>> 1456:   // initialize to garbage
>> 1457: 
>> 1458:   DUIterator_Last (const DUIterator_Last& that) : DUIterator_Fast(that) {}
> 
> Since DUIterator_Last is just delegating both the copy constructor and
> assignment operator to the base class, their copy constructor and
> assignment operator would be better as the default (either implicit or
> explicit using `=default`) rather than explicit code.

Agree.  c2 actually never uses the assignment operator of DUIterator_Last.  It needs the copy constructor in this line.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499

you can delete the following code or leave it =default.
-  void operator=(const DUIterator_Last& that)
-    { DUIterator_Fast::operator=(that); }

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

PR: https://git.openjdk.java.net/jdk/pull/1874


From ysatowse at openjdk.java.net  Fri Dec 25 02:17:16 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 25 Dec 2020 02:17:16 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v7]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <LzK41S5KU-_RAey_VEUY36M38mCNpTaUyTyAQGFyy_k=.bd57bd4b-edf0-465e-987a-bc8b96b5bf5f@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing -Xhtmlversion option from doclint and --doclint-format from javac.
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Updating makefile not to use removed option.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Fixing incorrect value checks for the id attribute.
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge master
 - 7th: Some fixes and additional changes for 8247957
 - 5th: 8258460: Remove --doclint-format option from javac
 - 5th: 8257204 and 8256313
   8257204: Remove usage of -Xhtmlversion option from javac
   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
 - 8257204 and 8256313
   8257204: Remove usage of -Xhtmlversion option from javac
   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
 - 3rd: 8247957 and 8256312
 - Merge branch 'master' into JDK-8247957_2
 - 8247957: remove doclint support for HTML 4
   8256312: Valid anchor 'id' value not allowed
 - 8247957: remove doclint support for HTML 4

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

Changes: https://git.openjdk.java.net/jdk/pull/893/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=06
  Stats: 1499 lines in 60 files changed: 411 ins; 808 del; 280 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893


From jjg at openjdk.java.net  Fri Dec 25 02:24:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 25 Dec 2020 02:24:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v7]
In-Reply-To: <LzK41S5KU-_RAey_VEUY36M38mCNpTaUyTyAQGFyy_k=.bd57bd4b-edf0-465e-987a-bc8b96b5bf5f@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <LzK41S5KU-_RAey_VEUY36M38mCNpTaUyTyAQGFyy_k=.bd57bd4b-edf0-465e-987a-bc8b96b5bf5f@github.com>
Message-ID: <qaq5n4TG873EONYE468-sVM_oq8AibEpWT1haNhmIOM=.cf3d7c3b-2510-4c67-8fbf-3d90031b54cc@github.com>

On Fri, 25 Dec 2020 02:17:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing -Xhtmlversion option from doclint and --doclint-format from javac.
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Updating makefile not to use removed option.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Fixing incorrect value checks for the id attribute.
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - 7th: Some fixes and additional changes for 8247957
>  - 5th: 8258460: Remove --doclint-format option from javac
>  - 5th: 8257204 and 8256313
>    8257204: Remove usage of -Xhtmlversion option from javac
>    8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>  - 8257204 and 8256313
>    8257204: Remove usage of -Xhtmlversion option from javac
>    8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>  - 3rd: 8247957 and 8256312
>  - Merge branch 'master' into JDK-8247957_2
>  - 8247957: remove doclint support for HTML 4
>    8256312: Valid anchor 'id' value not allowed
>  - 8247957: remove doclint support for HTML 4

Marked as reviewed by jjg (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/893


From github.com+16932759+shqking at openjdk.java.net  Fri Dec 25 06:02:55 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Fri, 25 Dec 2020 06:02:55 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
In-Reply-To: <XhGsF7raCYs6PiefoFOC962KvGLRt21lVcJXhQnzm2w=.8f9cdf5f-d603-48a8-8d7e-938544635dad@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
 <WhvBVqrbT7ar8EMzw2yFE83E4U0Zza-hGiRxqpVQigM=.8938cc9e-1790-401a-a1ad-156e367422f3@github.com>
 <XhGsF7raCYs6PiefoFOC962KvGLRt21lVcJXhQnzm2w=.8f9cdf5f-d603-48a8-8d7e-938544635dad@github.com>
Message-ID: <qWzxKhSPtkUv7sAUzNBUa4ejygb8ZDa4WOUMWOaoXr0=.698c73c6-57de-4347-b823-fbecd3e1e600@github.com>

On Thu, 24 Dec 2020 20:42:01 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> src/hotspot/share/opto/node.hpp line 1458:
>> 
>>> 1456:   // initialize to garbage
>>> 1457: 
>>> 1458:   DUIterator_Last (const DUIterator_Last& that) : DUIterator_Fast(that) {}
>> 
>> Since DUIterator_Last is just delegating both the copy constructor and
>> assignment operator to the base class, their copy constructor and
>> assignment operator would be better as the default (either implicit or
>> explicit using `=default`) rather than explicit code.
>
> Agree.  c2 actually never uses the assignment operator of DUIterator_Last.  It needs the copy constructor in this line.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499
> 
> you can delete the following code or leave it =default.
> -  void operator=(const DUIterator_Last& that)
> -    { DUIterator_Fast::operator=(that); }

Thanks for your comments.
Will remove the assignment operator of DUIterator_Last.

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

PR: https://git.openjdk.java.net/jdk/pull/1874


From github.com+16932759+shqking at openjdk.java.net  Fri Dec 25 06:16:55 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Fri, 25 Dec 2020 06:16:55 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion
In-Reply-To: <lW9AALJDS7c0-iuXAWv7PJ5KRgGE09GVzC_SS_xHSus=.3e368f60-da21-423b-8579-7933ca000515@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
 <lW9AALJDS7c0-iuXAWv7PJ5KRgGE09GVzC_SS_xHSus=.3e368f60-da21-423b-8579-7933ca000515@github.com>
Message-ID: <r3qLXOiNujhpo0s0H189PCzvVuWQajbDiAA9P8NErng=.84d25cd0-5440-4476-a83b-4d597eabe864@github.com>

On Thu, 24 Dec 2020 13:27:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I think the two issues described here are distinct and should be dealt
> with in separate bugs and PRs. Their only relation is that both arise
> with using clang-10. But they are very different problems, in very
> different parts of the code, and probably ought to be reviewed by
> folks from different teams.

Thanks for your comment.

Warning message of '-Wimplicit-int-float-conversion' was further encountered after we fixed the build failure caused by '-Wdeprecated-copy' first. That's why we put them in one PR initially.

Yes. Your way is much better. But we suppose the issue of '-Wimplicit-int-float-conversion' is trivial and putting them in separate PRs might raise another internal review process (for our side) by which extra time is needed. I was wondering could we continue in one single PR. :)

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

PR: https://git.openjdk.java.net/jdk/pull/1874


From github.com+16932759+shqking at openjdk.java.net  Fri Dec 25 10:19:02 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Fri, 25 Dec 2020 10:19:02 GMT
Subject: RFR: 8258857: Zero: non-PCH build fails after JDK-8258074
Message-ID: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>

>From the error log we can see the root cause is that, develop_pd flag
'pd_CICompileOSR' is undeclared in zero build.

Where this flag is used?
Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'.

Where this flag can be declared?
Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if
VM is built with compiler1 or compiler2. See lines 30 to 38 of
'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get
declared in the header files for specific arch, e.g.,
'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'.
However, regarding zero build (without compiler1 and compiler2 and
jvmci) , this flag is undelcared. Hence, this patch gets header file
'compiler/compiler_globals_pd.hpp' included where this flag is declared
for the case when neither COMPILER1 nor COMPILER2 are defined and
INCLUDE_JVMCI is inactive.

Note that 'compiler/compiler_globals_pd.hpp' already includes
'runtime/globals_shared.hpp'.

Note that zero build with PCH succeeds because 'runtime/globals.hpp' is
included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is
included in 'runtime/globals.hpp'.

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

Commit messages:
 - 8258857: Zero: non-PCH build fails after JDK-8258074

Changes: https://git.openjdk.java.net/jdk/pull/1894/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1894&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258857
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1894.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1894/head:pull/1894

PR: https://git.openjdk.java.net/jdk/pull/1894


From jiefu at openjdk.java.net  Fri Dec 25 11:46:55 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Dec 2020 11:46:55 GMT
Subject: RFR: 8258857: Zero: non-PCH build fails after JDK-8258074
In-Reply-To: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
Message-ID: <kqlZzLAjiUH-O2_KIFg6AlJ5C6Rt5JyyQU111T_Y0FY=.7dbd482a-7835-429e-84f8-71427f30ea6b@github.com>

On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
> 
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'.
> 
> Where this flag can be declared?
> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if
> VM is built with compiler1 or compiler2. See lines 30 to 38 of
> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get
> declared in the header files for specific arch, e.g.,
> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'.
> However, regarding zero build (without compiler1 and compiler2 and
> jvmci) , this flag is undelcared. Hence, this patch gets header file
> 'compiler/compiler_globals_pd.hpp' included where this flag is declared
> for the case when neither COMPILER1 nor COMPILER2 are defined and
> INCLUDE_JVMCI is inactive.
> 
> Note that 'compiler/compiler_globals_pd.hpp' already includes
> 'runtime/globals_shared.hpp'.
> 
> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is
> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is
> included in 'runtime/globals.hpp'.

Maybe, the title would be better with 'Zero: non-PCH release build fails after JDK-8258074'.

Just wondering why it gets passed with debug build?  
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/1894


From github.com+16932759+shqking at openjdk.java.net  Sat Dec 26 04:44:55 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Sat, 26 Dec 2020 04:44:55 GMT
Subject: RFR: 8258857: Zero: non-PCH build fails after JDK-8258074
In-Reply-To: <kqlZzLAjiUH-O2_KIFg6AlJ5C6Rt5JyyQU111T_Y0FY=.7dbd482a-7835-429e-84f8-71427f30ea6b@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <kqlZzLAjiUH-O2_KIFg6AlJ5C6Rt5JyyQU111T_Y0FY=.7dbd482a-7835-429e-84f8-71427f30ea6b@github.com>
Message-ID: <qzwM1UUK5Y3RcuV1sAa92I_ddSyMnkTZNdlvYGhp-0c=.0f99da7a-2a46-4d99-8d39-78a4c47d6597@github.com>

On Fri, 25 Dec 2020 11:44:11 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Maybe, the title would be better with 'Zero: non-PCH release build fails after JDK-8258074'.

Hi Jie, thanks for your comment.
Yes. Agree. It's much more accurate to describe this issue with 'release' added.
Will rename it next Monday as I need ask my colleague to help me rename the title of the corresponding JBS issue (since I'm not a JDK author currently).

> 
> Just wondering why it gets passed with debug build?
> Thanks.

Regarding the debug build, I guess it's because that flag 'pd_CICompileOSR' is not used for debug build.
Please refer to https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals_shared.hpp#L84

I suppose macro 'DECLARE_PD_DEVELOPER_FLAG' is defined at line 86 for release build where flags 'pd_XXX' would be used, while this macro is defined at line 90 for debug build where flags 'pd_XXX' are not used.

Please let me know if I misunderstand anything since I'm a beginner on OpenJDK.
Thanks. :)

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

PR: https://git.openjdk.java.net/jdk/pull/1894


From jiefu at openjdk.java.net  Sat Dec 26 06:42:54 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 26 Dec 2020 06:42:54 GMT
Subject: RFR: 8258857: Zero: non-PCH build fails after JDK-8258074
In-Reply-To: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
Message-ID: <ZL8v4pLXc1bwFzcLiiaVOBKipOsL3Y0DN-rIhmDGn_E=.932c66b3-f876-441e-b806-48832c1367f2@github.com>

On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
> 
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.hpp' and further line 86 of 'globals_shared.hpp'.
> 
> Where this flag can be declared?
> Header files 'c1_globals.hpp' or 'c2_globals.hpp' would be included if
> VM is built with compiler1 or compiler2. See lines 30 to 38 of
> 'complier_globals.hpp'. And further, flag 'pd_CICompileOSR' may get
> declared in the header files for specific arch, e.g.,
> 'c1_globals_aarch64.hpp', 'c2_globals_aarch64.hpp'.
> However, regarding zero build (without compiler1 and compiler2 and
> jvmci) , this flag is undelcared. Hence, this patch gets header file
> 'compiler/compiler_globals_pd.hpp' included where this flag is declared
> for the case when neither COMPILER1 nor COMPILER2 are defined and
> INCLUDE_JVMCI is inactive.
> 
> Note that 'compiler/compiler_globals_pd.hpp' already includes
> 'runtime/globals_shared.hpp'.
> 
> Note that zero build with PCH succeeds because 'runtime/globals.hpp' is
> included in 'precompiled.hpp', and further 'compiler_globals_pd.hpp' is
> included in 'runtime/globals.hpp'.

Marked as reviewed by jiefu (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/1894


From jiefu at openjdk.java.net  Sat Dec 26 06:42:55 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 26 Dec 2020 06:42:55 GMT
Subject: RFR: 8258857: Zero: non-PCH build fails after JDK-8258074
In-Reply-To: <qzwM1UUK5Y3RcuV1sAa92I_ddSyMnkTZNdlvYGhp-0c=.0f99da7a-2a46-4d99-8d39-78a4c47d6597@github.com>
References: <PRRJfSz53_hYtUnCe9Jxq-wY6NpbFxdsEm97xMl6804=.ac50a4ff-7929-4df7-a47b-e3c5c44545bf@github.com>
 <kqlZzLAjiUH-O2_KIFg6AlJ5C6Rt5JyyQU111T_Y0FY=.7dbd482a-7835-429e-84f8-71427f30ea6b@github.com>
 <qzwM1UUK5Y3RcuV1sAa92I_ddSyMnkTZNdlvYGhp-0c=.0f99da7a-2a46-4d99-8d39-78a4c47d6597@github.com>
Message-ID: <oCDMjAwKZTQbZlxbiWBQtW8Hm57-CaLiBuHgqACe9TQ=.05fbd143-8c4f-4155-a4a1-2d0e5ba99c08@github.com>

On Sat, 26 Dec 2020 04:42:34 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

> Regarding the debug build, I guess it's because that flag 'pd_CICompileOSR' is not used for debug build.
> Please refer to https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals_shared.hpp#L84
> 
> I suppose macro 'DECLARE_PD_DEVELOPER_FLAG' is defined at line 86 for release build where flags 'pd_XXX' would be used, while this macro is defined at line 90 for debug build where flags 'pd_XXX' are not used.
> 

Yes, you are right.
The change looks reasonable to me.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/1894


From david.holmes at oracle.com  Sat Dec 26 09:39:20 2020
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 26 Dec 2020 19:39:20 +1000
Subject: RFR: 8258856: VM build without C1/C2 fails after JDK-8243205 [v3]
In-Reply-To: <ip2KGU_b0FYrvUsqdug0OqjduW16Am3SGs-ndI9YWrc=.08c56712-6c71-40fd-b8d0-5e7427f3ccab@github.com>
References: <l27JDHmzHhMT8rNs5P0BwB_9rG0Ybpk9JrzOD9fewFI=.f8ac96bc-dd2b-466c-acd8-d38b04ee7c23@github.com>
 <NwBBd0AI_ulUYJ7q33npDtp52jGH2N_BBIANfTGyUng=.8290083b-f708-4c67-8c77-6083e3854239@github.com>
 <-64t6euaJW59jMrj0HcsD8-tcZ1DNbRJKESvCZv9y2I=.46e7fd10-2a37-457e-bfa9-5080f6a40573@github.com>
 <o_NexFi-S3uRTDOPgbpEGrrygdgiza09XVyDPxRtxHU=.2e57f175-d50b-4a34-ba31-aba859ba5417@github.com>
 <ip2KGU_b0FYrvUsqdug0OqjduW16Am3SGs-ndI9YWrc=.08c56712-6c71-40fd-b8d0-5e7427f3ccab@github.com>
Message-ID: <37ca1a04-810c-8fcb-dfbb-c5257b075e22@oracle.com>

Hi Hao,

On 24/12/2020 4:56 pm, Hao Sun wrote:
> On Thu, 24 Dec 2020 06:16:50 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Just an observation but it seems to me that if we are not including C1 or C2 in a build (ie interpreter-only) then really the build system should not be building the source files that had to be fixed.
>>
>> David
> 
> Hi David,
> I guess "not including C1 or C2 in a build (ie interpreter-only)" refers to the zero build.
> Yes. Regarding zero build, these source files fixed in this patch would not be compiled.
> 
> However, the build failures this patch aimed to address are 'server build without C1 feature' and 'server build without C2 feature'.
> 'C1/C2' in the title of this PR means 'build without C1' or 'build without C2'.

Sorry I did misunderstand the context of the problem. And my comment was 
wrong as JVMCI can be used to replace C1 and/or C2, so a build without 
both them need not be interpreter-only.

David

> As stated in JDK-8258856, the build failures can be reproduced by
> ` ./configure --with-jvm-features=-compiler1 && make images`
> and ` ./configure --with-jvm-features=-compiler2 && make images` respectively.
> 
> Hope that I made myself understood. Thanks.
> Hao
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1876
> 


From github.com+16932759+shqking at openjdk.java.net  Mon Dec 28 10:28:09 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Mon, 28 Dec 2020 10:28:09 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]
In-Reply-To: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
Message-ID: <O_KEiwxPWYuIcbUKLBm_hyFiblh6X0lqzuVEqTjPGec=.4e806038-0c38-4b51-b86b-f8fc6f7824b6@github.com>

> 1. '-Wdeprecated-copy'
> As specified in C++11 [1], "the generation of the implicitly-defined
> copy constructor is deprecated if T has a user-defined destructor or
> user-defined copy assignment operator". The rationale behind is the
> well-known Rule of Three [2].
> 
> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
> warns about the C++11 deprecation of implicitly declared copy
> constructor and assignment operator if one of them is user-provided.
> Defining an explicit copy constructor would suppress this warning.
> 
> The main reason why debug build with gcc-9 or higher succeeds lies in
> the inconsistent warning behaviors between gcc and clang. See the
> reduced code example [5]. We suspect it might be return value
> optimization/copy elision [6] that drives gcc not to declare implicit
> copy constructor for this case.
> 
> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise
> warnings for deprecated defintions of copy constructors. However,
> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8
> and clang-9 are not affected.
> 
> 2. '-Wimplicit-int-float-conversion'
> Making the conversion explicit would fix it.
> 
> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
> Therefore clang-8 and clang-9 are not affected. The flag with similar
> functionality in gcc is '-Wfloat-conversion', but it is not enabled by
> '-Wall' or '-Wextra'. That's why this warning does not apprear when
> building with gcc.
> 
> [1] https://en.cppreference.com/w/cpp/language/copy_constructor
> [2] https://en.cppreference.com/w/cpp/language/rule_of_three
> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html
> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
> [5] https://godbolt.org/z/err4jM
> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization
> 
> 
> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines.

Hao Sun has updated the pull request incrementally with one additional commit since the last revision:

  Remove the unused assignment operator for DUIterator_Last
  
  Instead of adding the copy constructor, remove the assignment operator
  of DUIterator_Last since it's never used.
  
  Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f
  CustomizedGitHooks: yes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1874/files
  - new: https://git.openjdk.java.net/jdk/pull/1874/files/124033f2..68679966

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874

PR: https://git.openjdk.java.net/jdk/pull/1874


From xliu at openjdk.java.net  Mon Dec 28 19:25:55 2020
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 28 Dec 2020 19:25:55 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]
In-Reply-To: <O_KEiwxPWYuIcbUKLBm_hyFiblh6X0lqzuVEqTjPGec=.4e806038-0c38-4b51-b86b-f8fc6f7824b6@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
 <O_KEiwxPWYuIcbUKLBm_hyFiblh6X0lqzuVEqTjPGec=.4e806038-0c38-4b51-b86b-f8fc6f7824b6@github.com>
Message-ID: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com>

On Mon, 28 Dec 2020 10:28:09 GMT, Hao Sun <github.com+16932759+shqking at openjdk.org> wrote:

>> 1. '-Wdeprecated-copy'
>> As specified in C++11 [1], "the generation of the implicitly-defined
>> copy constructor is deprecated if T has a user-defined destructor or
>> user-defined copy assignment operator". The rationale behind is the
>> well-known Rule of Three [2].
>> 
>> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
>> warns about the C++11 deprecation of implicitly declared copy
>> constructor and assignment operator if one of them is user-provided.
>> Defining an explicit copy constructor would suppress this warning.
>> 
>> The main reason why debug build with gcc-9 or higher succeeds lies in
>> the inconsistent warning behaviors between gcc and clang. See the
>> reduced code example [5]. We suspect it might be return value
>> optimization/copy elision [6] that drives gcc not to declare implicit
>> copy constructor for this case.
>> 
>> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise
>> warnings for deprecated defintions of copy constructors. However,
>> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8
>> and clang-9 are not affected.
>> 
>> 2. '-Wimplicit-int-float-conversion'
>> Making the conversion explicit would fix it.
>> 
>> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10.
>> Therefore clang-8 and clang-9 are not affected. The flag with similar
>> functionality in gcc is '-Wfloat-conversion', but it is not enabled by
>> '-Wall' or '-Wextra'. That's why this warning does not apprear when
>> building with gcc.
>> 
>> [1] https://en.cppreference.com/w/cpp/language/copy_constructor
>> [2] https://en.cppreference.com/w/cpp/language/rule_of_three
>> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html
>> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html
>> [5] https://godbolt.org/z/err4jM
>> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization
>> 
>> 
>> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines.
>
> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the unused assignment operator for DUIterator_Last
>   
>   Instead of adding the copy constructor, remove the assignment operator
>   of DUIterator_Last since it's never used.
>   
>   Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f
>   CustomizedGitHooks: yes

LGTM. It still needs other's approval.

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

Marked as reviewed by xliu (no project role).

PR: https://git.openjdk.java.net/jdk/pull/1874


From github.com+16932759+shqking at openjdk.java.net  Wed Dec 30 03:33:58 2020
From: github.com+16932759+shqking at openjdk.java.net (Hao Sun)
Date: Wed, 30 Dec 2020 03:33:58 GMT
Subject: RFR: 8258010: Debug build failure with clang-10 due to
 -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]
In-Reply-To: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com>
References: <DsL8dtjK0pQ1vmafGdlyPPznwQgLEr0cWikQlL3dELU=.78ea4878-200f-4caf-a815-e32dd4d554bb@github.com>
 <O_KEiwxPWYuIcbUKLBm_hyFiblh6X0lqzuVEqTjPGec=.4e806038-0c38-4b51-b86b-f8fc6f7824b6@github.com>
 <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com>
Message-ID: <RoMSURqpqV9Orgz3zpDFj3X6q75yQaMod3rLKa7EVOQ=.6f1f3b03-42a7-4375-bed8-3c040c5f1366@github.com>

On Mon, 28 Dec 2020 19:23:34 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Hao Sun has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the unused assignment operator for DUIterator_Last
>>   
>>   Instead of adding the copy constructor, remove the assignment operator
>>   of DUIterator_Last since it's never used.
>>   
>>   Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f
>>   CustomizedGitHooks: yes
>
> LGTM. It still needs other's approval.

> _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> > On Dec 22, 2020, at 8:52 PM, Hao Sun <github.com+16932759+shqking at openjdk.java.net> wrote:
> > 1. '-Wdeprecated-copy'
> > As specified in C++11 [1], "the generation of the implicitly-defined
> > copy constructor is deprecated if T has a user-defined destructor or
> > user-defined copy assignment operator". The rationale behind is the
> > well-known Rule of Three [2].
> > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy'
> > warns about the C++11 deprecation of implicitly declared copy
> > constructor and assignment operator if one of them is user-provided.
> > Defining an explicit copy constructor would suppress this warning.
> > The main reason why debug build with gcc-9 or higher succeeds lies in
> > the inconsistent warning behaviors between gcc and clang. See the
> > reduced code example [5]. We suspect it might be return value
> > optimization/copy elision [6] that drives gcc not to declare implicit
> > copy constructor for this case.
> 
> C++17 "guaranteed copy elision" is implemented in gcc7.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html
> 

Thanks for your comment.
Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. 
Thank you for pointing it out.

> Using -fno-elide-constructors makes it obvious that the deprecated
> implicit copy constructors are indeed being elided, so no deprecation
> warning.
> 

I suppose you want to express 'Using -**felide-constructors**' here.
gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does.

> Why doesn't this patch similarly define DUIterator copy constructor?
> It seems to have the same issue, and I'm surprised clang-10 didn't
> complain about it too. Certainly gcc with -fno-elide-constructors
> complains about the defaulted implicit constructor.
> 

I'm afraid we have noticed the same issue for 'DUIterator' before.
Yes. It's weird that clang-10 didn't raise warning here. ( verified it on my local machine.)

> But I discovered something alarming while experimenting. Building
> with gcc10.2 with -fno-elide-constructors doesn't seem to be possible.
> I get different kinds of failures depending on how DUIterator is
> defined:
> 
> - implict: deprecation warning (as expected)
> - =delete: error, deleted function used
> - =default: assert in os::free
> - _idx and reset from that: assert in reset
> 
> Without -fno-elide-constructors, all of the variants seem to work
> except =delete, which still fails because the deleted function is
> used. (I didn't test the "working" cases extensively though.)
> 
> So there's something problematic, though I don't understand the code
> well enough to understand what.

Thanks for your tests. 
But I have no idea how to fix it right now either.
Do you know anyone who is familiar with these code and maybe we can invite him/her to help take a look at this issue?
Thanks.

> 
> Interestingly, some of the complexity and weirdness around copy/assign
> for these classes may be an attempt at providing something like move
> semantics in a C++98 code base. I've noticed a number of places in
> HotSpot that are doing that.
> 
> Defining DUIterator_Fast and DUIterator_Last as movable but not
> copyable (explicitly delete the copy constructor and copy assign
> operator, and define the move constructor and move assign operator
> with the reset) works, even with -fno-elide-constructors.

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

PR: https://git.openjdk.java.net/jdk/pull/1874