Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v16]

On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8276025: Hotspot's libsvml.so may conflict with user dependency [v2]

On Thu, 4 Nov 2021 19:49:08 GMT, Sandhya Viswanathan wrote: >> This patch removes conflicts with libsvml.so distributed with Intel's MKL >> library: >> Renames exported symbols from __svml to __jsvml. >> Renames library from libsvml.so to libjsvml.so. >> Updates the

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12]

On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line >> 111: >> >>> 109: class VarHandleCache { >>> 110: private static final Map handleMap >>> = new ConcurrentHashMap<>(); >>> 111:

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v2]

On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8268768: idea.sh has been updated in surprising and incompatible ways

On Tue, 15 Jun 2021 14:04:56 GMT, Maurizio Cimadamore wrote: > As the title says (please also refer to the JBS issue which describes all the > issues in more details), the IDE support for IntelliJ has been updated with > many enhancements as part of a seemingly innocuous "path handling" fix.

Re: RFR: 8262891: Compiler implementation for Pattern Matching for switch (Preview) [v12]

On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote: >> This is a preview of a patch implementing JEP 406: Pattern Matching for >> switch (Preview): >> https://bugs.openjdk.java.net/browse/JDK-8213076 >> >> The current draft of the specification is here: >>

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v11]

On Wed, 19 May 2021 22:16:18 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for >> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), >> in preparation for when targeted. >> >> Intel Short Vector Math Library

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2]

On Mon, 3 May 2021 21:41:26 GMT, Paul Sandoz wrote: >> Sandhya Viswanathan has updated the pull request with a new target base due >> to a merge or a rebase. The pull request now contains six commits: >> >> - Merge master >> - remove whitespace >

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v9]

On Wed, 19 May 2021 03:37:11 GMT, Sandhya Viswanathan wrote: >> This PR contains Short Vector Math Library support related changes for >> [JEP-414 Vector API (Second Incubator)](https://openjdk.java.net/jeps/414), >> in preparation for when targeted. >> >> Intel Short Vector Math Library

Re: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2]

On Wed, 28 Apr 2021 21:11:26 GMT, Sandhya Viswanathan wrote: >> Intel Short Vector Math Library (SVML) based intrinsics in native x86 >> assembly provide optimized implementation for Vector API transcendental and >> trigonometric methods. >> These methods are built into a separate library

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

On Tue, 17 Nov 2020 22:21:18 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . > > Jim Laskey has

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v9]

On Thu, 22 Oct 2020 14:26:37 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java >> line 120: >> >>> 118: } >>> 119: } >>> 120: throw new AssertionError("Cannot get here!"); >> >>

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

On Thu, 22 Oct 2020 14:31:12 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 36: >> >>> 34: import static java.lang.invoke.MethodHandleStatics.newInternalError; >>> 35: >>> 36: /** TODO */ >> >> Is the TODO to make this class public later

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

On Thu, 22 Oct 2020 13:30:13 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java >> line 126: >> >>> 124: * >>> 125: * @param symbol downcall symbol. >>> 126: * @param type the method type. >> >> s/method

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

gt;> 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

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v9]

gt;> 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

Integrated: 8255020: Minor updates to docs jdk.incubator.vector

On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz wrote: > Minor updates, with no specification changes, to the documentation of Vector > API. > > The compilation of the Vector module was updated to turn on doclint errors > for >= protected documentation. This pull re

RFR: 8255020: Minor updates to docs jdk.incubator.vector

Minor updates, with no specification changes, to the documentation of Vector API. The compilation of the Vector module was updated to turn on doclint errors for >= protected documentation. - Commit messages: - 8255020:Minor updates to docs jdk.incubator.vector Changes:

Integrated: 8223347: Integration of Vector API (Incubator)

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote: > 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 nu

Re: RFR: 8223347: Integration of Vector API (Incubator) [v6]

shed 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 n

Re: RFR: 8223347: Integration of Vector API (Incubator) [v5]

shed 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 n

Re: RFR: 8223347: Integration of Vector API (Incubator) [v4]

shed 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 n

Re: RFR: 8223347: Integration of Vector API (Incubator) [v3]

shed 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

Re: RFR: 8223347: Integration of Vector API (Incubator) [v2]

shed 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 n

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v5]

entation 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 Os

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v3]

entation 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 Os

Re: RFR: 8223347: Integration of Vector API (Incubator)

On Thu, 1 Oct 2020 00:25:46 GMT, Jie Fu wrote: >> @DamonFool we can follow up later for that fix (and others in >> `vectorIntrinsics`), after this PR integrates. I don't >> want to perturb the code that has already been reviewed, which requires yet >> more additional review. > > Hi @PaulSandoz

RFR: 8223347: Integration of Vector API (Incubator)

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):

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I >> believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change

Re: JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 / JDK-8205621: Increment JDK version for JDK 12

This generally looks good. Having it all consolidated helps a lot, and we are slowly chipping away at reducing this for each release. src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java — 118 V55(55, 0), // JDK 11: constant dynamic 119 V56(56, 0); // JDK

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Mar 1, 2018, at 4:41 PM, Lance Andersen wrote: > > While running the JDK regression tests, I found a test that needed to be > updated, test/langtools/tools/jdeps/modules/DotFileTest.java, due to the > update to the java.sql module > > The updated webrev is at

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

+1 > On Mar 1, 2018, at 8:59 AM, Lance Andersen wrote: >> >> +1, i second Joe’s request to update package-info.java while we are >> opportunistically cleaning this area up. > > Per your and Joe’s request, please see > cr.openjdk.java.net/~lancea/8197533/webrev.02

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

> On Feb 28, 2018, at 1:22 PM, Lance Andersen <lance.ander...@oracle.com> wrote: > >> >> On Feb 28, 2018, at 2:20 PM, Lance Andersen <lance.ander...@oracle.com >> <mailto:lance.ander...@oracle.com>> wrote: >> >> Hi Paul, >> >&g

Re: RFR JDK-8197533 move javax.transaction.xa into its own module

Compatible module refactoring in action! Looks good, one comment: test/jdk/javax/transaction/xa/testng/JavaSqlModuleDriver.java This is not a valid Java source file can you merge the jtreg meta data into XAExceptionTests instead? Paul. > On Feb 28, 2018, at 10:25 AM, Lance Andersen

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 18 Dec 2017, at 17:52, David Holmes <david.hol...@oracle.com> wrote: > > On 19/12/2017 11:42 AM, Paul Sandoz wrote: >> Looks good to me. >> I am including HS dev for the class file version changes: >> http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Looks good to me. I am including HS dev for the class file version changes: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Here are two webrevs (in order that can be merged with the other): the class file version changes; and the build changes related to that. http://cr.openjdk.java.net/~psandoz/jdk/JDK-8173382-classfile-version/webrev/

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Hi Iris, Erik We should be able to automate all the following by referring to the latest release variable, yes? Nashorn build targets version 9 source https://bugs.openjdk.java.net/browse/JDK-8188012 http://hg.openjdk.java.net/jdk10/master/rev/0e67ab18b511 symbolgenerator targets jdk 9

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 13 Dec 2017, at 19:51, mark.reinh...@oracle.com wrote: > > 2017/12/13 15:49:53 -0800, paul.san...@oracle.com: >> On 13 Dec 2017, at 14:36, mark.reinh...@oracle.com wrote: >>> I understand that other incoming changes are waiting for the 11 version >>> bump, but can't we at least do the

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 14 Dec 2017, at 03:58, Erik Joelsson wrote: > > And here it is: http://cr.openjdk.java.net/~erikj/8173382/webrev.01/ > > Feel free to incorporate this into whichever changeset you want, or I can > push this separately. > Thanks! that is exactly what i was

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 13 Dec 2017, at 14:36, mark.reinh...@oracle.com wrote: > > 2017/12/13 14:09:44 -0800, paul.san...@oracle.com: >>> On 13 Dec 2017, at 13:18, mark.reinh...@oracle.com wrote: >>> How much of this can we parameterize and/or automate? >> >> I suspect quite a bit, as you present below, and i

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 13 Dec 2017, at 13:18, mark.reinh...@oracle.com wrote: > > 2017/12/13 8:44:33 -0800, paul.san...@oracle.com: >>> On 12 Dec 2017, at 20:56, david.hol...@oracle.com wrote: >>> >>> Anyway, none of the proposed changes have any impact on hotspot >>> AFAICT. It is only when the actual version

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

On 13 Dec 2017, at 08:44, Paul Sandoz <paul.san...@oracle.com> wrote: > > > >> On 12 Dec 2017, at 20:56, David Holmes <david.hol...@oracle.com> wrote: >> >> Anyway, none of the proposed changes have any impact on hotspot AFAICT. It >> is only

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 12 Dec 2017, at 20:56, David Holmes wrote: > > Anyway, none of the proposed changes have any impact on hotspot AFAICT. It is > only when the actual version is updated to 11 that hotspot, and other > entities will have to be updated. I'm still unclear if someone

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

> On 12 Dec 2017, at 10:03, Paul Sandoz <paul.san...@oracle.com> wrote: > > > >> On 12 Dec 2017, at 09:52, joe darcy <joe.da...@oracle.com> wrote: >> >> Hi Paul, >> >> There is sense in working in including the class file version updat

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

e we don’t currently use ASM process or generate constant dynamic entries. Paul. > Thanks, > > -Joe > > > On 12/12/2017 9:31 AM, Paul Sandoz wrote: >> Hi Joe, >> >> I would like to see the class file version increment [*] in the same patch >> (the unifie

Re: Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

Hi Joe, I would like to see the class file version increment [*] in the same patch (the unified repo makes this easier now). Then we have everything in one changeset (except for any ctsym changes?) that can be easily templated when the next increment is required, since we will be doing this

Re: RFR: JDK-8192771: Boot JDK jar tool used to construct the modular JAR for java.jnlp

+1 I tested this out with the class file version change patch and the build no longer fails. Thanks, Paul. > On 4 Dec 2017, at 15:21, Erik Joelsson wrote: > > To be able to bump the classfile version in JDK 10, we need to be able to > build certain jar files using

Re: RFR: 8160000: Runtime.version() cause startup regressions in 9+119

> On 26 Jun 2016, at 21:55, Claes Redestad wrote: > > Hi, > > 9+119 changed java.util.regex to initialize java.lang.invoke early, causing a > number of easily reproducible startup regressions. > > This patch uses the fact that we already maintain the version string

Re: RFR (L) JEP 280: Indify String Concatenation (integration)

I think it quite reasonable to push everything to jdk9/dev. Paul. > On 27 Jan 2016, at 14:55, Aleksey Shipilev > wrote: > > Hi again, > > This is a formal pre-integration review thread for JEP 280 ("Indify > String Concatenation") integration: >