Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"

2020-12-10 Thread Yumin Qi
On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi  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


Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]

2020-12-10 Thread Yumin Qi
On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi  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


Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]

2020-12-10 Thread Yumin Qi
> 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=1657=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


Re: RFR: 8257733: Move module-specific data from make to respective module [v2]

2020-12-10 Thread Naoto Sato
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie  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


Re: RFR: 8257620: Do not use objc_msgSend_stret to get macOS version

2020-12-10 Thread Anton Kozlov
On Wed, 2 Dec 2020 19:27:25 GMT, Phil Race  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


Integrated: 8257450: Start of release updates for JDK 17

2020-12-10 Thread Joe Darcy
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy  wrote:

> Start of JDK 17 updates.

This pull request has now been integrated.

Changeset: 6be1f567
Author:Joe Darcy 
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


Integrated: 8258005: JDK build fails with incorrect fixpath script

2020-12-10 Thread Magnus Ihse Bursie
On Thu, 10 Dec 2020 12:42:48 GMT, Magnus Ihse Bursie  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 
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 
Reviewed-by: erikj

-

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


Re: RFR: 8258005: JDK build fails with incorrect fixpath script [v2]

2020-12-10 Thread Erik Joelsson
On Thu, 10 Dec 2020 13:11:47 GMT, Magnus Ihse Bursie  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


Re: RFR: 8258005: JDK build fails with incorrect fixpath script [v2]

2020-12-10 Thread Magnus Ihse Bursie
> 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=1731=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1731=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


RFR: 8258005: JDK build fails with incorrect fixpath script

2020-12-10 Thread Magnus Ihse Bursie
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=1731=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


Re: RFR: 8257450: Start of release updates for JDK 17 [v8]

2020-12-10 Thread Joe Darcy
> 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=1531=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1531=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