Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 21:14:55 GMT, Joe Darcy 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
Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]
On Tue, 8 Dec 2020 06:58:49 GMT, Aleksey Shipilev 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
Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]
On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster
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
Re: RFR: 8257450: Start of release updates for JDK 17 [v4]
> 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=1531=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1531=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
Re: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]
> 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=1657=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1657=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
Re: RFR: 8257450: Start of release updates for JDK 17 [v3]
> 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=1531=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1531=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
Re: RFR: 8257733: Move module-specific data from make to respective module [v2]
On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons 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
Re: RFR: JDK-8257789: Fix incremental build of test-image and bundles
On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson 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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 20:20:58 GMT, Jesper Wilhelmsson 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
Integrated: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes 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 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
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 20:08:59 GMT, Jonathan Gibbons 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
Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]
On Mon, 7 Dec 2020 19:34:26 GMT, Bernhard Urban-Forster 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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy 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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy 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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy 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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
On Mon, 7 Dec 2020 16:10:42 GMT, Jan Lahoda 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
Re: RFR: 8257450: Start of release updates for JDK 17 [v2]
> 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=1531=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1531=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
Re: RFR: 8257733: Move module-specific data from make to respective module [v2]
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. > > 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
Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v4]
> 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=1379=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1379=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
Re: RFR: 8256657: Add cross-compiled build for Windows+Arm64 to submit workflow [v3]
> 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=1379=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
Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal
On Mon, 7 Dec 2020 15:50:55 GMT, Harold Seigel 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
Re: RFR: 8257450: Start of release updates for JDK 17
On Sat, 5 Dec 2020 03:17:56 GMT, Mikael Vidstedt 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
Integrated: 8257679: Improved unix compatibility layer in Windows build (winenv)
On Thu, 3 Dec 2020 14:19:13 GMT, Magnus Ihse Bursie 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 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
Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith 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
Re: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for removal
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith 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
Re: RFR: JDK-8257789: Fix incremental build of test-image and bundles
On Fri, 4 Dec 2020 23:01:26 GMT, Erik Joelsson 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
Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v7]
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie 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
Re: RFR: 8257733: Move module-specific data from make to respective module
On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie 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
Re: RFR: 8257733: Move module-specific data from make to respective module
On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie wrote:
>> Regarding the chosen layout. Did you consider following the existing pattern
>> of src//{share,}/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
Re: RFR: 8257733: Move module-specific data from make to respective module [v2]
> 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=1611=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1611=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
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes 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
Re: RFR: 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
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
Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v7]
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie 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
Re: RFR: 8257679: Improved unix compatibility layer in Windows build (winenv) [v7]
On Sat, 5 Dec 2020 01:13:34 GMT, Magnus Ihse Bursie 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
