Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" Marked as reviewed by asemenyuk (Committer). - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: 8223347: Integration of Vector API (Incubator) [v4]
On Wed, 14 Oct 2020 00:34:04 GMT, Sandhya Viswanathan wrote: >> There are several gc tests crashed in panama-vector tier3 testing which >> seems are not observed in openjdk repo. >> The crashes look like: >> # assert(oopDesc::is_oop(obj)) failed: not an oop: 0xfff1 >> # >> # JRE version: Java(TM) SE Runtime Environment (16.0+3) (fastdebug build >> 16-panama+3-216) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-panama+3-216, >> mixed mode, sharing, tiered, compressed oops, >> g1 gc, linux-amd64) # Problematic frame: >> # V [libjvm.so+0xd8ef94] HandleArea::allocate_handle(oop)+0x144 >> >> and the issue is actually tracked by JDK-8233199. >> >> This issue needs to be at least analyzed before integrating Vector API. > > @katyapav Is the failure observed on vector-unstable branch of panama-vector? > The code in this pull request is from vector-unstable branch. > The bug report https://bugs.openjdk.java.net/browse/JDK-8233199 refers to > repo-valhalla and not > panama-vector:vector-unstable. @PaulSandoz is doing final testing of the pull > request today before integration tomorrow > hopefully. @sviswa7 you are right, the failure is observed on vector-unstable branch of panama-vector. I referred to JDK-8233199 because it seems both panama-vector and valhalla-repo have the same issue/crash. @PaulSandoz also mentioned that panama-vector was not in sync with master and this is perhaps the issue is in vector-unstable. He said that he tested the PR separately and didn't observe this issue in the PR. - PR: https://git.openjdk.java.net/jdk/pull/367
Re: RFR: 8223347: Integration of Vector API (Incubator) [v4]
On Tue, 13 Oct 2020 21:29:52 GMT, Ekaterina Pavlova wrote: >> Build changes look good. > > There are several gc tests crashed in panama-vector tier3 testing which seems > are not observed in openjdk repo. > The crashes look like: > # assert(oopDesc::is_oop(obj)) failed: not an oop: 0xfff1 > # > # JRE version: Java(TM) SE Runtime Environment (16.0+3) (fastdebug build > 16-panama+3-216) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-panama+3-216, > mixed mode, sharing, tiered, compressed oops, > g1 gc, linux-amd64) # Problematic frame: > # V [libjvm.so+0xd8ef94] HandleArea::allocate_handle(oop)+0x144 > > and the issue is actually tracked by JDK-8233199. > > This issue needs to be at least analyzed before integrating Vector API. @katyapav Is the failure observed on vector-unstable branch of panama-vector? The code in this pull request is from vector-unstable branch. The bug report https://bugs.openjdk.java.net/browse/JDK-8233199 refers to repo-valhalla and not panama-vector:vector-unstable. @PaulSandoz is doing final testing of the pull request today before integration tomorrow hopefully. - PR: https://git.openjdk.java.net/jdk/pull/367
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 23:28:24 GMT, Alexander Matveev wrote: >> Andy Herrick has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JDK-8252870: Finalize (remove "incubator" from) jpackage >> - reverting two auto-generated files, and changing module-info to >> "@since 16" > > Marked as reviewed by almatvee (Committer). > src/jdk.jpackage/macosx/classes/module-info.java.extra > jdk.jpackage.internal.MacAppBundler, > jdk.jpackage.internal.MacAppStoreBundler, not related to this change directly, but even in 14 there was no MacAppStoreBundler - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 21:30:05 GMT, Alexander Matveev wrote: >> Andy Herrick has updated the pull request incrementally with one additional >> commit since the last revision: >> >> JDK-8252870: Finalize (remove "incubator" from) jpackage >> - reverting two auto-generated files, and changing module-info to >> "@since 16" > > src/jdk.jpackage/linux/classes/module-info.java.extra line 29: > >> 27: jdk.jpackage.internal.LinuxAppBundler, >> 28: jdk.jpackage.internal.LinuxDebBundler, >> 29: jdk.jpackage.internal.LinuxRpmBundler; > > Not sure why it was changed. Looks like git recorded file renaming > incorrectly. Yes, sometime GIt / Github get a bit confused about identifying rename/copy when generating a diff for a renamed file with changes. The result is correct, but the diff looks odd. > src/jdk.jpackage/macosx/classes/module-info.java.extra line 30: > >> 28: jdk.jpackage.internal.MacAppStoreBundler, >> 29: jdk.jpackage.internal.MacDmgBundler, >> 30: jdk.jpackage.internal.MacPkgBundler; > > Looks like another rename issue. Yes (or more precisely another issue displaying the diffs for a renamed file with changes). - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" Looks good. I double-checked all of the file renames and all are exactly as expected. The diffs got a bit confused in a couple cases, where it thought that a renamed and modified file was copied from somewhere else (see inline comments), but that can happen given that git doesn't actually track renames and copies). - Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: 8223347: Integration of Vector API (Incubator) [v4]
On Mon, 12 Oct 2020 12:56:10 GMT, Erik Joelsson wrote: >> Paul Sandoz 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 >> - Fix related to merge >> - HotspotIntrinsicCandidate to IntrinsicCandidate >> - Merge master >> - Fix permissions >> - Fix permissions >> - Merge master >> - Vector API new files >> - Integration of Vector API (Incubator) > > Build changes look good. There are several gc tests crashed in panama-vector tier3 testing which seems are not observed in openjdk repo. The crashes look like: # assert(oopDesc::is_oop(obj)) failed: not an oop: 0xfff1 # # JRE version: Java(TM) SE Runtime Environment (16.0+3) (fastdebug build 16-panama+3-216) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-panama+3-216, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xd8ef94] HandleArea::allocate_handle(oop)+0x144 and the issue is actually tracked by JDK-8233199. This issue needs to be at least analyzed before integrating Vector API. - PR: https://git.openjdk.java.net/jdk/pull/367
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" src/jdk.jpackage/linux/classes/module-info.java.extra line 29: > 27: jdk.jpackage.internal.LinuxAppBundler, > 28: jdk.jpackage.internal.LinuxDebBundler, > 29: jdk.jpackage.internal.LinuxRpmBundler; Not sure why it was changed. Looks like git recorded file renaming incorrectly. src/jdk.jpackage/macosx/classes/module-info.java.extra line 30: > 28: jdk.jpackage.internal.MacAppStoreBundler, > 29: jdk.jpackage.internal.MacDmgBundler, > 30: jdk.jpackage.internal.MacPkgBundler; Looks like another rename issue. src/jdk.jpackage/windows/classes/module-info.java.extra line 29: > 27: jdk.jpackage.internal.WinAppBundler, > 28: jdk.jpackage.internal.WinExeBundler, > 29: jdk.jpackage.internal.WinMsiBundler; Another rename issue. - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
On Tue, 13 Oct 2020 11:32:54 GMT, Kiran Sidhartha Ravikumar wrote: >> Looks good. I think we should release-note the removal of the >> "US/Pacific-New" Link on the off chance that some >> production/testing system is looking for such a zone. > > Thanks for the review everyone, I have added a release note to the bug. I > will integrate the changes Looks like we both reached the same patch for this one independently :) systemv was removed from tzdata some time ago and wasn't even being read by the JDK as far as I could see. Its contents are duplicated in jdk11_backward anyway. Good to see both it and pacificnew being removed. In the unlikely event the removal of Pacific_New is problematic, it could be added to jdk11_backward as well, but it seems very unlikely. - PR: https://git.openjdk.java.net/jdk/pull/602
Re: RFR: 8223347: Integration of Vector API (Incubator) [v4]
> This pull request is for integration of the Vector API. It was previously > reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here > (searching for issue number 8223347 in the > title): > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html > > If mercurial was still being used the code would be pushed directly, once the > CSR is approved. However, in this case a > pull request is required and needs explicit reviewer approval. Between the > final review and this pull request no code > has changed, except for that related to merging. Paul Sandoz 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 - Fix related to merge - HotspotIntrinsicCandidate to IntrinsicCandidate - Merge master - Fix permissions - Fix permissions - Merge master - Vector API new files - Integration of Vector API (Incubator) - Changes: https://git.openjdk.java.net/jdk/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=03 Stats: 295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod Patch: https://git.openjdk.java.net/jdk/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367 PR: https://git.openjdk.java.net/jdk/pull/367
Integrated: 8254311: Incorrect statements in createWindowsDevkit2017.sh
On Fri, 9 Oct 2020 15:39:18 GMT, Ludovic Henry wrote: > We made a typo in https://github.com/openjdk/jdk/pull/212 when updating > make/devkit/createWindowsDevkit2017.sh. This pull request has now been integrated. Changeset: 715e24af Author:Ludovic Henry Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/715e24af Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8254311: Incorrect statements in createWindowsDevkit2017.sh Reviewed-by: erikj, thartmann - PR: https://git.openjdk.java.net/jdk/pull/581
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage > - reverting two auto-generated files, and changing module-info to "@since > 16" Build changes look good. - Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: 8223347: Integration of Vector API (Incubator) [v3]
> This pull request is for integration of the Vector API. It was previously > reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here > (searching for issue number 8223347 in the > title): > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html > > If mercurial was still being used the code would be pushed directly, once the > CSR is approved. However, in this case a > pull request is required and needs explicit reviewer approval. Between the > final review and this pull request no code > has changed, except for that related to merging. Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision: Fix related to merge - Changes: - all: https://git.openjdk.java.net/jdk/pull/367/files - new: https://git.openjdk.java.net/jdk/pull/367/files/9cca17b8..d5acb4ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=01-02 Stats: 76 lines in 1 file changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.java.net/jdk/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367 PR: https://git.openjdk.java.net/jdk/pull/367
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
On Tue, 13 Oct 2020 13:44:22 GMT, Kevin Rushforth wrote:
>> Andy Herrick has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>> - reverting two auto-generated files, and changing module-info to
>> "@since 16"
>
> make/data/symbols/jdk.jpackage-E.sym.txt line 29:
>
>> 27: # ##
>> 28: #
>> 29: module name jdk.jpackage
>
> I think you need to revert this. Note this comment:
>
> # ### THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. ###
reverted
> make/data/symbols/symbols line 40:
>
>> 38: platform version C base B files
>> java.base-C.sym.txt:java.compiler-C.sym.txt:java.desktop-C.sym.txt:java.naming-C.sym.txt:java.rmi-C.sym.txt:java.xml-C.sym.txt:jdk.compiler-C.sym.txt:jdk.jfr-C.sym.txt:jdk.jsobject-C.sym.txt:jdk.unsupported-C.sym.txt
>> 39: platform version D base C files
>> java.base-D.sym.txt:java.compiler-D.sym.txt:java.desktop-D.sym.txt:java.management-D.sym.txt:java.management.rmi-D.sym.txt:java.net.http-D.sym.txt:java.security.jgss-D.sym.txt:java.xml-D.sym.txt:java.xml.crypto-D.sym.txt:jdk.compiler-D.sym.txt:jdk.httpserver-D.sym.txt:jdk.jartool-D.sym.txt:jdk.javadoc-D.sym.txt:jdk.jlink-D.sym.txt:jdk.jshell-D.sym.txt
>> 40: platform version E base D files
>> java.base-E.sym.txt:java.compiler-E.sym.txt:java.desktop-E.sym.txt:java.xml-E.sym.txt:jdk.compiler-E.sym.txt:jdk.httpserver-E.sym.txt:jdk.incubator.foreign-E.sym.txt:jdk.jpackage-E.sym.txt:jdk.jfr-E.sym.txt:jdk.jlink-E.sym.txt:jdk.jshell-E.sym.txt:jdk.jsobject-E.sym.txt:jdk.management-E.sym.txt:jdk.net-E.sym.txt:jdk.pack-E.sym.txt
>
> Similarly, I think you need to revert this.
reverted
> src/jdk.jpackage/share/classes/module-info.java line 49:
>
>> 47: */
>> 48:
>> 49: module jdk.jpackage {
>
> Change to `@since 16`
changed to @since16
-
PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
> JDK-8252870: Finalize (remove "incubator" from) jpackage Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8252870: Finalize (remove "incubator" from) jpackage - reverting two auto-generated files, and changing module-info to "@since 16" - Changes: - all: https://git.openjdk.java.net/jdk/pull/633/files - new: https://git.openjdk.java.net/jdk/pull/633/files/4b95b41c..4b1e6363 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=00-01 Stats: 64 lines in 4 files changed: 31 ins; 31 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633 PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
On Tue, 13 Oct 2020 13:51:27 GMT, Kevin Rushforth wrote: >> I spot checked it and left a couple comments. The rest looks good. I'll >> review it in more detail later this week. > > @andyherrick the "reviewer credit" command should not be used in this manner. > It is intended for the case where an > offline review of a PR has been done elsewhere and you wish to record that in > the commit. It is not how you ask someone > to do a review. You can't directly, so I usually just mention in a comment who I want to review it. If you use their GitHub username it will notify them (unless they have disabled all notifications). Something like this: @prrace @kevinrushforth @sashamatveev @alexeysemenyukoracle please review - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
On Tue, 13 Oct 2020 13:49:13 GMT, Kevin Rushforth wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > I spot checked it and left a couple comments. The rest looks good. I'll > review it in more detail later this week. @andyherrick the "reviewer credit" command should not be used in this manner. It is intended for the case where an offline review of a PR has been done elsewhere and you wish to record that in the commit. It is not how you ask someone to do a review. - PR: https://git.openjdk.java.net/jdk/pull/633
Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
On Tue, 13 Oct 2020 12:51:54 GMT, Andy Herrick wrote:
> JDK-8252870: Finalize (remove "incubator" from) jpackage
I spot checked it and left a couple comments. The rest looks good. I'll review
it in more detail later this week.
make/data/symbols/jdk.jpackage-E.sym.txt line 29:
> 27: # ##
> 28: #
> 29: module name jdk.jpackage
I think you need to revert this. Note this comment:
# ### THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. ###
make/data/symbols/symbols line 40:
> 38: platform version C base B files
> java.base-C.sym.txt:java.compiler-C.sym.txt:java.desktop-C.sym.txt:java.naming-C.sym.txt:java.rmi-C.sym.txt:java.xml-C.sym.txt:jdk.compiler-C.sym.txt:jdk.jfr-C.sym.txt:jdk.jsobject-C.sym.txt:jdk.unsupported-C.sym.txt
> 39: platform version D base C files
> java.base-D.sym.txt:java.compiler-D.sym.txt:java.desktop-D.sym.txt:java.management-D.sym.txt:java.management.rmi-D.sym.txt:java.net.http-D.sym.txt:java.security.jgss-D.sym.txt:java.xml-D.sym.txt:java.xml.crypto-D.sym.txt:jdk.compiler-D.sym.txt:jdk.httpserver-D.sym.txt:jdk.jartool-D.sym.txt:jdk.javadoc-D.sym.txt:jdk.jlink-D.sym.txt:jdk.jshell-D.sym.txt
> 40: platform version E base D files
> java.base-E.sym.txt:java.compiler-E.sym.txt:java.desktop-E.sym.txt:java.xml-E.sym.txt:jdk.compiler-E.sym.txt:jdk.httpserver-E.sym.txt:jdk.incubator.foreign-E.sym.txt:jdk.jpackage-E.sym.txt:jdk.jfr-E.sym.txt:jdk.jlink-E.sym.txt:jdk.jshell-E.sym.txt:jdk.jsobject-E.sym.txt:jdk.management-E.sym.txt:jdk.net-E.sym.txt:jdk.pack-E.sym.txt
Similarly, I think you need to revert this.
src/jdk.jpackage/share/classes/module-info.java line 49:
> 47: */
> 48:
> 49: module jdk.jpackage {
Change to `@since 16`
-
PR: https://git.openjdk.java.net/jdk/pull/633
RFR: 8254231: Implementation of Foreign Linker API (Incubator)
This patch contains the changes associated with the first incubation round of the foreign linker access API incubation (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]). The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients. Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible. A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand). Thanks Maurizio Webrev: http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev Javadoc: http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html Specdiff (relative to [3]): http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html CSR: https://bugs.openjdk.java.net/browse/JDK-8254232 ### API Changes The API changes are actually rather slim: * `LibraryLookup` * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library. * `FunctionDescriptor` * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function. * `CLinker` * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls. * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place. * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back. * `NativeScope` * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls. * `MemorySegment` * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope. ### Safety The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API). ### Implementation changes The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders). As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on t
RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
JDK-8252870: Finalize (remove "incubator" from) jpackage - Commit messages: - JDK-8252870: Finalize (remove "incubator" from) jpackage - 8252869 Finalize (remove incubator from) jpackage (implementation) Changes: https://git.openjdk.java.net/jdk/pull/633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252870 Stats: 1796 lines in 262 files changed: 723 ins; 732 del; 341 mod Patch: https://git.openjdk.java.net/jdk/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633 PR: https://git.openjdk.java.net/jdk/pull/633
Integrated: 8254177: (tz) Upgrade time-zone data to tzdata2020b
On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review the patch for tzdata2020b integration into JDK. > > Release details can be found here: > > https://mm.icann.org/pipermail/tz-announce/2020-October/59.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8254177 > > I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName > classes, make file and few test files > need to be updated to incorporate the change. > The patch has passed all the related testing including JCK. > > Thanks, > Kiran This pull request has now been integrated. Changeset: 9c934909 Author:Kiran Sidhartha Ravikumar Committer: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/9c934909 Stats: 480 lines in 27 files changed: 138 ins; 133 del; 209 mod 8254177: (tz) Upgrade time-zone data to tzdata2020b Reviewed-by: erikj, naoto, coffeys - PR: https://git.openjdk.java.net/jdk/pull/602
Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
On Tue, 13 Oct 2020 11:07:13 GMT, Sean Coffey wrote: >> Hi Guys, >> >> Please review the patch for tzdata2020b integration into JDK. >> >> Release details can be found here: >> >> https://mm.icann.org/pipermail/tz-announce/2020-October/59.html >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177 >> >> I had the pacificnew, systemv files removed from JDK repo and so >> TimeZoneName classes, make file and few test files >> need to be updated to incorporate the change. >> The patch has passed all the related testing including JCK. >> >> Thanks, >> Kiran > > Looks good. I think we should release-note the removal of the > "US/Pacific-New" Link on the off chance that some > production/testing system is looking for such a zone. Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes - PR: https://git.openjdk.java.net/jdk/pull/602
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v11]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation > (see JEP 393 [1]). This iteration focus on improving the usability of the API > in 3 main ways: > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from > multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee > that the memory will be deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class > has been added, which defines several useful dereference routines; these > are really just thin wrappers around memory > access var handles, but they make the barrier of entry for using this API > somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not > the same as it used to be; it used to be the case that a memory address could > (sometimes, not always) have a back link > to the memory segment which originated it; additionally, memory access var > handles used `MemoryAddress` as a basic unit > of dereference. This has all changed as per this API refresh; now a > `MemoryAddress` is just a dumb carrier which > wraps a pair of object/long addressing coordinates; `MemorySegment` has > become the star of the show, as far as > dereferencing memory is concerned. You cannot dereference memory if you don't > have a segment. This improves usability > in a number of ways - first, it is a lot easier to wrap native addresses > (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can > use that; otherwise, if the client only has an address, it will have to > create a segment *unsafely* (this can be done > by calling `MemoryAddress::asSegmentRestricted`). A list of the API, > implementation and test changes is provided > below. If you have any questions, or need more detailed explanations, I (and > the rest of the Panama team) will be > happy to point at existing discussions, and/or to provide the feedback > required. A big thank to Erik Osterlund, > Vladimir Ivanov and David Holmes, without whom the work on shared memory > segment would not have been possible; also I'd > like to thank Paul Sandoz, whose insights on API design have been very > helpful in this journey. Thanks Maurizio > Javadoc: > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative > to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a > carrier is one of the usual suspect (a Java primitive, minus `boolean`); > the access mode can be simple (e.g. access > base address of given segment), or indexed, in which case the accessor > takes a segment and either a low-level byte > offset,or a high level logical index. The classification is reflected in > the naming scheme (e.g. `getByte` vs. > `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which > it is easy to derive all the other handles using plain var handle > combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both > `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP > 389 [2] to add more implementations. Clients > can largely ignore this interface, which co
Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar wrote: > Hi Guys, > > Please review the patch for tzdata2020b integration into JDK. > > Release details can be found here: > > https://mm.icann.org/pipermail/tz-announce/2020-October/59.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8254177 > > I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName > classes, make file and few test files > need to be updated to incorporate the change. > The patch has passed all the related testing including JCK. > > Thanks, > Kiran Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some production/testing system is looking for such a zone. - Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/602
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v10]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation > (see JEP 393 [1]). This iteration focus on improving the usability of the API > in 3 main ways: > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from > multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee > that the memory will be deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class > has been added, which defines several useful dereference routines; these > are really just thin wrappers around memory > access var handles, but they make the barrier of entry for using this API > somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not > the same as it used to be; it used to be the case that a memory address could > (sometimes, not always) have a back link > to the memory segment which originated it; additionally, memory access var > handles used `MemoryAddress` as a basic unit > of dereference. This has all changed as per this API refresh; now a > `MemoryAddress` is just a dumb carrier which > wraps a pair of object/long addressing coordinates; `MemorySegment` has > become the star of the show, as far as > dereferencing memory is concerned. You cannot dereference memory if you don't > have a segment. This improves usability > in a number of ways - first, it is a lot easier to wrap native addresses > (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can > use that; otherwise, if the client only has an address, it will have to > create a segment *unsafely* (this can be done > by calling `MemoryAddress::asSegmentRestricted`). A list of the API, > implementation and test changes is provided > below. If you have any questions, or need more detailed explanations, I (and > the rest of the Panama team) will be > happy to point at existing discussions, and/or to provide the feedback > required. A big thank to Erik Osterlund, > Vladimir Ivanov and David Holmes, without whom the work on shared memory > segment would not have been possible; also I'd > like to thank Paul Sandoz, whose insights on API design have been very > helpful in this journey. Thanks Maurizio > Javadoc: > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative > to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a > carrier is one of the usual suspect (a Java primitive, minus `boolean`); > the access mode can be simple (e.g. access > base address of given segment), or indexed, in which case the accessor > takes a segment and either a low-level byte > offset,or a high level logical index. The classification is reflected in > the naming scheme (e.g. `getByte` vs. > `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which > it is easy to derive all the other handles using plain var handle > combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both > `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP > 389 [2] to add more implementations. Clients > can largely ignore this interface, which co
Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v9]
> This patch contains the changes associated with the third incubation round of > the foreign memory access API incubation > (see JEP 393 [1]). This iteration focus on improving the usability of the API > in 3 main ways: > * first, by providing a way to obtain truly *shared* segments, which can be > accessed and closed concurrently from > multiple threads > * second, by providing a way to register a memory segment against a > `Cleaner`, so as to have some (optional) guarantee > that the memory will be deallocated, eventually > * third, by not requiring users to dive deep into var handles when they first > pick up the API; a new `MemoryAccess` class > has been added, which defines several useful dereference routines; these > are really just thin wrappers around memory > access var handles, but they make the barrier of entry for using this API > somewhat lower. > > A big conceptual shift that comes with this API refresh is that the role of > `MemorySegment` and `MemoryAddress` is not > the same as it used to be; it used to be the case that a memory address could > (sometimes, not always) have a back link > to the memory segment which originated it; additionally, memory access var > handles used `MemoryAddress` as a basic unit > of dereference. This has all changed as per this API refresh; now a > `MemoryAddress` is just a dumb carrier which > wraps a pair of object/long addressing coordinates; `MemorySegment` has > become the star of the show, as far as > dereferencing memory is concerned. You cannot dereference memory if you don't > have a segment. This improves usability > in a number of ways - first, it is a lot easier to wrap native addresses > (`long`, essentially) into a `MemoryAddress`; > secondly, it is crystal clear what a client has to do in order to dereference > memory: if a client has a segment, it can > use that; otherwise, if the client only has an address, it will have to > create a segment *unsafely* (this can be done > by calling `MemoryAddress::asSegmentRestricted`). A list of the API, > implementation and test changes is provided > below. If you have any questions, or need more detailed explanations, I (and > the rest of the Panama team) will be > happy to point at existing discussions, and/or to provide the feedback > required. A big thank to Erik Osterlund, > Vladimir Ivanov and David Holmes, without whom the work on shared memory > segment would not have been possible; also I'd > like to thank Paul Sandoz, whose insights on API design have been very > helpful in this journey. Thanks Maurizio > Javadoc: > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254163 > > > > ### API Changes > > * `MemorySegment` > * drop factory for restricted segment (this has been moved to > `MemoryAddress`, see below) > * added a no-arg factory for a native restricted segment representing > entire native heap > * rename `withOwnerThread` to `handoff` > * add new `share` method, to create shared segments > * add new `registerCleaner` method, to register a segment against a cleaner > * add more helpers to create arrays from a segment e.g. `toIntArray` > * add some `asSlice` overloads (to make up for the fact that now segments > are more frequently used as cursors) > * rename `baseAddress` to `address` (so that `MemorySegment` can implement > `Addressable`) > * `MemoryAddress` > * drop `segment` accessor > * drop `rebase` method and replace it with `segmentOffset` which returns > the offset (a `long`) of this address relative > to a given segment > * `MemoryAccess` > * New class supporting several static dereference helpers; the helpers are > organized by carrier and access mode, where a > carrier is one of the usual suspect (a Java primitive, minus `boolean`); > the access mode can be simple (e.g. access > base address of given segment), or indexed, in which case the accessor > takes a segment and either a low-level byte > offset,or a high level logical index. The classification is reflected in > the naming scheme (e.g. `getByte` vs. > `getByteAtOffset` vs `getByteAtIndex`). > * `MemoryHandles` > * drop `withOffset` combinator > * drop `withStride` combinator > * the basic memory access handle factory now returns a var handle which > takes a `MemorySegment` and a `long` - from which > it is easy to derive all the other handles using plain var handle > combinators. > * `Addressable` > * This is a new interface which is attached to entities which can be > projected to a `MemoryAddress`. For now, both > `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP > 389 [2] to add more implementations. Clients > can largely ignore this interface, which co
Re: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6]
On Fri, 9 Oct 2020 06:02:04 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now >> contains three commits: >> - Merge branch 'master' into JDK-8247589 >> - JDK-8247589: Implementation of Alpine Linux/x64 Port >> - JDK-8247589: Implementation of Alpine Linux/x64 Port > > Marked as reviewed by dholmes (Reviewer). Thanks everyone! - PR: https://git.openjdk.java.net/jdk/pull/49
Integrated: 8247591: Document Alpine Linux build steps in OpenJDK build guide
On Mon, 5 Oct 2020 18:13:49 GMT, Aleksei Voitylov wrote: > Please review the build guide update for Alpine Linux. > > building.html was generated by "make update-build-docs". However, this > command produced a slightly different > building.html, with some other sections modified as well. This is probably > due to another version of the tooling > installed. I have manually removed the modifications to other, not relevant > sections of the building.html change > introduced by the tool, and kept only the changes relevant to the md file > change. This pull request has now been integrated. Changeset: 508c8a95 Author:Aleksei Voitylov Committer: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/508c8a95 Stats: 51 lines in 2 files changed: 51 ins; 0 del; 0 mod 8247591: Document Alpine Linux build steps in OpenJDK build guide Co-authored-by: Aleksei Voitylov Reviewed-by: erikj - PR: https://git.openjdk.java.net/jdk/pull/512
Integrated: JDK-8247589: Implementation of Alpine Linux/x64 Port
On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the > integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a > comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on > that to re-confirm the review here. This pull request has now been integrated. Changeset: 63009f90 Author:Aleksei Voitylov Committer: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/63009f90 Stats: 403 lines in 30 files changed: 348 ins; 17 del; 38 mod 8247589: Implementation of Alpine Linux/x64 Port Co-authored-by: Mikael Vidstedt Co-authored-by: Alexander Scherbatiy Co-authored-by: Axel Siebenborn Co-authored-by: Aleksei Voitylov Reviewed-by: alanb, erikj, dholmes - PR: https://git.openjdk.java.net/jdk/pull/49
