Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v4]

2022-12-05 Thread Sergey Tsypanov
> I found out that this code > > public class Main { > public static void main(String[] args) { > String s = "Hello world!"; > char[] chars = s.toCharArray(); > int point = Character.codePointAt(chars, -1, 1); > } > } > > throws `ArrayIndexOutOfBoundsException`

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Alan Bateman
On Tue, 6 Dec 2022 07:08:55 GMT, Jaikiran Pai wrote: > Furthermore, I think in its current form it means that this will > load/instantiate any `JdkConsoleProvider` implementations that are accessible > to the thread context classloader but may not have been from the module > configured

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jaikiran Pai
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v4]

2022-12-05 Thread David Holmes
On Mon, 5 Dec 2022 17:45:25 GMT, Doug Simon wrote: >> Libgraal is compiled ahead of time and should not need any JVMCI Java code >> to be dynamically loaded at runtime. Prior to this PR, this is not the case >> due to: >> >> * Code to copy system properties from the HotSpot heap into the

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Joe Darcy
On Mon, 5 Dec 2022 23:33:14 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 519: >> >>> 517: * @param cffv the class file format version >>> 518: */ >>> 519: public static Set maskToAccessFlags(int mask, Location >>> location, >> >>

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Joe Darcy
On Mon, 5 Dec 2022 23:10:20 GMT, Roger Riggs wrote: >> src/java.base/share/classes/java/lang/Class.java line 1345: >> >>> 1343: * its {@code INTERFACE} flag is absent, even when the >>> 1344: * component type is an interface >>> 1345: * its class file format version is

Re: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]

2022-12-05 Thread Andrew John Hughes
On Mon, 5 Dec 2022 20:37:31 GMT, Naoto Sato wrote: > Have you run tests under `sun.util.calendar`? Tests like > `TestZoneInfo310.java` sometimes fail with tzdata updates. Yes ~~~ Passed: sun/util/calendar/zi/Beyond2037.java Passed: sun/util/calendar/zi/TestZoneInfo310.java Passed:

Integrated: 8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout

2022-12-05 Thread Alexey Semenyuk
On Mon, 5 Dec 2022 22:20:19 GMT, Alexey Semenyuk wrote: > Simply increase timeout limit to make test pass on slower/loaded hosts This pull request has now been integrated. Changeset: 8d8a28ff Author:Alexey Semenyuk URL:

Integrated: 8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels [1024] of [1024] is < [0.100000] threshold"

2022-12-05 Thread Alexey Semenyuk
On Mon, 5 Dec 2022 22:14:50 GMT, Alexey Semenyuk wrote: > - throw an exception if icon swap fails with the corresponding l10n message; > - add retries to the jpackage test routine that extracts an icon from a > launcher This pull request has now been integrated. Changeset: 884b9ade Author:

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Roger Riggs
On Mon, 5 Dec 2022 21:47:29 GMT, Joe Darcy wrote: >> Roger Riggs has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Updated the descriptions of AccessFlags being dependent on the class file >> version number. >>Removed unnecessary

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Roger Riggs
On Mon, 5 Dec 2022 21:43:03 GMT, Joe Darcy wrote: >> Roger Riggs has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Updated the descriptions of AccessFlags being dependent on the class file >> version number. >>Removed unnecessary

Re: RFR: 8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels [1024] of [1024] is < [0.100000] threshold"

2022-12-05 Thread Alexander Matveev
On Mon, 5 Dec 2022 22:14:50 GMT, Alexey Semenyuk wrote: > - throw an exception if icon swap fails with the corresponding l10n message; > - add retries to the jpackage test routine that extracts an icon from a > launcher Marked as reviewed by almatvee (Reviewer). - PR:

Re: RFR: 8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout

2022-12-05 Thread Alexander Matveev
On Mon, 5 Dec 2022 22:20:19 GMT, Alexey Semenyuk wrote: > Simply increase timeout limit to make test pass on slower/loaded hosts Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.org/jdk/pull/11522

RFR: 8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels [1024] of [1024] is < [0.100000] threshold"

2022-12-05 Thread Alexey Semenyuk
- throw an exception if icon swap fails with the corresponding l10n message; - add retries to the jpackage test routine that extracts an icon from a launcher - Commit messages: - 8293453: tools/jpackage/share/AddLShortcutTest.java "Failed: Check the number of mismatched pixels

RFR: 8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout

2022-12-05 Thread Alexey Semenyuk
Simply increase timeout limit to make test pass on slower/loaded hosts - Commit messages: - 8296489: tools/jpackage/windows/WinL10nTest.java fails with timeout Changes: https://git.openjdk.org/jdk/pull/11522/files Webrev: https://webrevs.openjdk.org/?repo=jdk=11522=00 Issue:

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Joe Darcy
On Mon, 5 Dec 2022 19:52:20 GMT, Roger Riggs wrote: >> The accessFlags() methods added (in JDK 20, the current release) to >> java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field >> implicitly uses the access flags from the current/most recent class file >> format

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Joe Darcy
On Mon, 5 Dec 2022 19:52:20 GMT, Roger Riggs wrote: >> The accessFlags() methods added (in JDK 20, the current release) to >> java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field >> implicitly uses the access flags from the current/most recent class file >> format

Re: RFR: 8240567: MethodTooLargeException thrown while creating a jlink image [v6]

2022-12-05 Thread Oliver Kopp
> Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): > "MethodTooLargeException thrown while creating a jlink image". > > Java still has a 64kb limit: A method may not be longer than 64kb. The idea > of the fix is to split up the generated methods in several smaller methods

Re: RFR: JDK-8295859: Update Manual Test Groups [v3]

2022-12-05 Thread Bill Huang
> This task is created to add manual tests to the manual test groups. > > In addition, fix is provided for TestMatrix.java#Downcall-F and > TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java > ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)). Bill Huang

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v3]

2022-12-05 Thread Roger Riggs
On Mon, 5 Dec 2022 13:22:36 GMT, Sergey Tsypanov wrote: >> Yeah, this AIOOBE is exactly the reason why I added this. So should we >> modify `codePointBefore` in the same way as `codePointAt`? > > I'm asking because counter-intuitively `codePointBefore ` doesn't specify > IOOBE for negative

Re: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v7]

2022-12-05 Thread Bill Huang
> The current non local registry tests require a manual process that runs > rmiregitrty on a different machine and changes the -Dregistry.host property > in the source before running the tests on the local machine. This task is > created to improve this manual process and provide a clearer

Re: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]

2022-12-05 Thread Naoto Sato
On Mon, 5 Dec 2022 14:38:51 GMT, Andrew John Hughes wrote: >> Update to the latest tzdata, 2022g. >> >> Primary changes: >> * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` >> (MST/MDT) >> * `America/Pangnirtung` becomes a link to `America/Iqaluit` >> * `America/Ojinaga`

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Jim Laskey
On Mon, 5 Dec 2022 19:52:59 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v7]

2022-12-05 Thread Naoto Sato
> This is to allow Console to be used even when it is not attached to the > platform provided terminal, such as the case when the standard input is > redirected. `System.console()` now returns a Console implementation based on > `jdk.internal.le` terminal by default, or jshell implementation if

Re: RFR: 8295803: Console should be usable in jshell and other environments [v4]

2022-12-05 Thread Naoto Sato
On Sun, 4 Dec 2022 17:09:15 GMT, Alan Bateman wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Changed the expected behavior when the SecurityManager is enabled > > src/java.base/share/classes/java/io/Console.java

Re: RFR: 8297271: AccessFlags should be specific to class file version [v2]

2022-12-05 Thread Roger Riggs
> The accessFlags() methods added (in JDK 20, the current release) to > java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field > implicitly uses the access flags from the current/most recent class file > format version. For current and past class file format versions there

Re: RFR: JDK-8295087: Manual Test to Automated Test Conversion [v5]

2022-12-05 Thread Bill Huang
> This task converts 5 manual tests to automated tests. > > sun/security/provider/PolicyParser/ExtDirsDefaultPolicy.java > sun/security/provider/PolicyParser/ExtDirsChange.java > sun/security/provider/PolicyParser/ExtDirs.java >

Re: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2]

2022-12-05 Thread Brian Burkhalter
On Sun, 20 Nov 2022 09:41:47 GMT, Markus KARG wrote: >> Since JDK 18 some implementations of InputStream.transferTo, namely >> FileInputStream and ChannelInputStream, offload work to lower layers using >> NIO channels. This provides shorter execution time and reduced resource >> consumption.

Re: RFR: 8298045: Fix hidden but significant trailing whitespace in properties files for core-libs code

2022-12-05 Thread Justin Lu
On Fri, 2 Dec 2022 16:40:51 GMT, Magnus Ihse Bursie wrote: > According to [the > specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) > trailing whitespaces in the values of properties files are (somewhat > surprisingly)

Re: RFR: JDK-8295859: Update Manual Test Groups [v2]

2022-12-05 Thread Bill Huang
> This task is created to add manual tests to the manual test groups. > > In addition, fix is provided for TestMatrix.java#Downcall-F and > TestMatrix.java#Downcall-T which are failing due to missing TestDowncall.java > ([JDK-8287158](https://bugs.openjdk.org/browse/JDK-8287158)). Bill Huang

Re: RFR: 8295803: Console should be usable in jshell and other environments [v6]

2022-12-05 Thread Jim Laskey
On Mon, 5 Dec 2022 18:33:10 GMT, Naoto Sato wrote: >> This is to allow Console to be used even when it is not attached to the >> platform provided terminal, such as the case when the standard input is >> redirected. `System.console()` now returns a Console implementation based on >>

Re: RFR: 8295803: Console should be usable in jshell and other environments [v6]

2022-12-05 Thread Naoto Sato
> This is to allow Console to be used even when it is not attached to the > platform provided terminal, such as the case when the standard input is > redirected. `System.console()` now returns a Console implementation based on > `jdk.internal.le` terminal by default, or jshell implementation if

Re: RFR: 8295803: Console should be usable in jshell and other environments [v5]

2022-12-05 Thread Naoto Sato
> This is to allow Console to be used even when it is not attached to the > platform provided terminal, such as the case when the standard input is > redirected. `System.console()` now returns a Console implementation based on > `jdk.internal.le` terminal by default, or jshell implementation if

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v4]

2022-12-05 Thread Doug Simon
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to > be dynamically loaded at runtime. Prior to this PR, this is not the case due > to: > > * Code to copy system properties from the HotSpot heap into the libgraal > heap. This is in >

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v2]

2022-12-05 Thread Doug Simon
On Mon, 5 Dec 2022 17:17:16 GMT, Doug Simon wrote: >> Assuming --limit-modules isn't used, it is testing if the module is >> "observable". > > I assume this function should therefore be named `is_module_observable`? How about this: // Determines if the named module is present in the //

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v2]

2022-12-05 Thread Doug Simon
On Mon, 5 Dec 2022 15:58:19 GMT, Alan Bateman wrote: >> src/hotspot/share/classfile/classLoader.hpp line 378: >> >>> 376: >>> 377: // Determines if the `module_name` module is resolvable. >>> 378: static bool is_module_resolvable(const char* module_name); >> >> Is "resolvable" the right

Re: CachedRowSet findColumn(string), getObject(string), ... should use label, not name

2022-12-05 Thread Ernie Rael
And to make the noise worse, I posted from the wrong account. On 22/12/05 9:09 AM, Ernie Rael wrote: Apologies, accidentally hit send. Those links are notes. The stackoverflow link is the best summary I've seen and references a bug that can't be seen from the outside. I'm hoping to find a

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v2]

2022-12-05 Thread Alan Bateman
On Mon, 5 Dec 2022 13:53:07 GMT, Doug Simon wrote: >> Doug Simon has updated the pull request incrementally with one additional >> commit since the last revision: >> >> generalized ClassLoader::has_jvmci_module to is_module_resolvable > > src/hotspot/share/classfile/classLoader.hpp line 378:

Integrated: 8297733: Refactor Cast binding to enum

2022-12-05 Thread Jorn Vernee
On Mon, 28 Nov 2022 20:13:35 GMT, Jorn Vernee wrote: > Refactor the cast binding to an enum, which clearly enumerates all supported > conversions. > > This also fixes a bug where `java/foreign/normalize/TestNormalize` was > failing when running in interpreted mode >

Integrated: 8297495: j.u.concurrent updates for JDK 20

2022-12-05 Thread Alan Bateman
On Wed, 23 Nov 2022 12:40:05 GMT, Alan Bateman wrote: > The proposed updates for JDK 20 are: > > - ForkJoinPool.externalSubmit > - ForkJoinWorkerThread.getQueuedTaskCount > > These methods will be used to improve the Thread.yield implementation for > virtual threads. The range of

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v3]

2022-12-05 Thread Doug Simon
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to > be dynamically loaded at runtime. Prior to this PR, this is not the case due > to: > > * Code to copy system properties from the HotSpot heap into the libgraal > heap. This is in >

Re: RFR: 8297733: Refactor Cast binding to enum [v2]

2022-12-05 Thread Jorn Vernee
> Refactor the cast binding to an enum, which clearly enumerates all supported > conversions. > > This also fixes a bug where `java/foreign/normalize/TestNormalize` was > failing when running in interpreted mode > (`-Djdk.internal.foreign.DowncallLinker.USE_SPEC=false`), for conversions >

Integrated: 8296477: Foreign linker implementation update following JEP 434

2022-12-05 Thread Jorn Vernee
On Mon, 7 Nov 2022 14:34:45 GMT, Jorn Vernee wrote: > Pull in linker implementation changes, that include non-trivial changes to VM > code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the

Re: RFR: 8296477: Foreign linker implementation update following JEP 434 [v13]

2022-12-05 Thread Jorn Vernee
> Pull in linker implementation changes, that include non-trivial changes to VM > code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1.

Re: RFR: 8297804: (tz) Update Timezone Data to 2022g

2022-12-05 Thread Andrew John Hughes
On Sat, 3 Dec 2022 00:21:21 GMT, Naoto Sato wrote: > Hi Andrew, Thanks for taking on this. I think you can cherry-pick the > relevant [CLDR > changes](https://github.com/unicode-org/cldr/commit/0bd22412b35b6e7037a39c3ad6a4dc49c699439b) > (under `common` directory) into this PR so that

Re: RFR: 8297804: (tz) Update Timezone Data to 2022g

2022-12-05 Thread Andrew John Hughes
On Fri, 2 Dec 2022 01:15:49 GMT, Yoshiki Sato wrote: > The following files need to be updated with the timezone data version. > src/java.base/share/data/tzdata/VERSION > test/jdk/java/util/TimeZone/TimeZoneData/VERSION Good catch. I copied over the files from the tzdb bundle, but it seems

Re: RFR: 8296477: Foreign linker implementation update following JEP 434 [v12]

2022-12-05 Thread Jorn Vernee
> Pull in linker implementation changes, that include non-trivial changes to VM > code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1.

Re: RFR: 8297804: (tz) Update Timezone Data to 2022g [v2]

2022-12-05 Thread Andrew John Hughes
> Update to the latest tzdata, 2022g. > > Primary changes: > * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT) > * `America/Pangnirtung` becomes a link to `America/Iqaluit` > * `America/Ojinaga` gains DST (CDT) > > See bug for the full details. > > There will likely

Re: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes [v3]

2022-12-05 Thread Daniel Jeliński
> Please review this patch that removes progress monitoring classes used by > UrlConnection. > Since Java 9 these classes are not used in the JDK, and are not exported from > java.base. If anyone was still using them, reimplementing them in user code > should be pretty straightforward. > >

Re: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes [v2]

2022-12-05 Thread Daniel Jeliński
On Mon, 5 Dec 2022 14:06:10 GMT, Daniel Jeliński wrote: >> Please review this patch that removes progress monitoring classes used by >> UrlConnection. >> Since Java 9 these classes are not used in the JDK, and are not exported >> from java.base. If anyone was still using them, reimplementing

Re: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes [v2]

2022-12-05 Thread Daniel Jeliński
> Please review this patch that removes progress monitoring classes used by > UrlConnection. > Since Java 9 these classes are not used in the JDK, and are not exported from > java.base. If anyone was still using them, reimplementing them in user code > should be pretty straightforward. > >

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v2]

2022-12-05 Thread Doug Simon
On Mon, 5 Dec 2022 13:49:28 GMT, Doug Simon wrote: >> Libgraal is compiled ahead of time and should not need any JVMCI Java code >> to be dynamically loaded at runtime. Prior to this PR, this is not the case >> due to: >> >> * Code to copy system properties from the HotSpot heap into the

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v2]

2022-12-05 Thread Doug Simon
On Mon, 5 Dec 2022 13:32:38 GMT, Alan Bateman wrote: >> Doug Simon has updated the pull request incrementally with one additional >> commit since the last revision: >> >> generalized ClassLoader::has_jvmci_module to is_module_resolvable > > src/hotspot/share/classfile/classLoader.cpp line

Integrated: 8295044: Implementation of Foreign Function and Memory API (Second Preview)

2022-12-05 Thread Maurizio Cimadamore
On Wed, 26 Oct 2022 13:11:50 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-434 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: RFR: 8296477: Foreign linker implementation update following JEP 434 [v11]

2022-12-05 Thread Jorn Vernee
> Pull in linker implementation changes, that include non-trivial changes to VM > code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1.

Re: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39]

2022-12-05 Thread Maurizio Cimadamore
On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime [v2]

2022-12-05 Thread Doug Simon
> Libgraal is compiled ahead of time and should not need any JVMCI Java code to > be dynamically loaded at runtime. Prior to this PR, this is not the case due > to: > > * Code to copy system properties from the HotSpot heap into the libgraal > heap. This is in >

Re: RFR: 8298099: [JVMCI] decouple libgraal from JVMCI module at runtime

2022-12-05 Thread Alan Bateman
On Mon, 5 Dec 2022 13:16:25 GMT, Doug Simon wrote: > Libgraal is compiled ahead of time and should not need any JVMCI Java code to > be dynamically loaded at runtime. Prior to this PR, this is not the case due > to: > > * Code to copy system properties from the HotSpot heap into the libgraal

Re: RFR: 8298033: Character.codePointAt(char[], int, int) doesn't do JavaDoc-specified check [v3]

2022-12-05 Thread Sergey Tsypanov
On Sat, 3 Dec 2022 18:40:59 GMT, Sergey Tsypanov wrote: >> test/jdk/java/lang/Character/Supplementary.java line 808: >> >>> 806: return; >>> 807: } >>> 808: if (expectedException.isInstance(e)) { // >>> Character.codePointBefore() throws >> >> The test

Re: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT)

2022-12-05 Thread Kennke, Roman
Hi Thomas, I very much like the idea and also your proposals how to do it. Insights in JDK's native memory usage is sorely lacking and would be very useful! I don't have all that much to add about the details beyond what you already covered, though :-) Cheers, Roman Are there any

Re: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT)

2022-12-05 Thread Thomas Stüfe
Thank you for the positive encouragement, Roman :-) Cheers, Thomas On Mon, Dec 5, 2022 at 12:03 PM Kennke, Roman wrote: > Hi Thomas, > > I very much like the idea and also your proposals how to do it. Insights > in JDK's native memory usage is sorely lacking and would be very useful! > I don't

Re: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v37]

2022-12-05 Thread Andrew Haley
> JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Add comment - Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new:

Re: RFR: JDK-8296149: Start of release updates for JDK 21 [v3]

2022-12-05 Thread Jan Lahoda
On Sat, 3 Dec 2022 23:10:48 GMT, Joe Darcy wrote: >> Usual start-of-release updates. Symbol updates in initial version reflect >> JDK 20 build 21. > > 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

Re: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v36]

2022-12-05 Thread Andrew Haley
> JEP 429 implementation. Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits: - Merge https://github.com/openjdk/jdk into JDK-828 - Feedback from reviewers - Feedback from reviewers - Unused variable -

Re: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]

2022-12-05 Thread Viktor Klang
On Mon, 5 Dec 2022 10:33:38 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2920: >> >>> 2918: * @since 20 >>> 2919: */ >>> 2920: public ForkJoinTask externalSubmit(ForkJoinTask task) { >> >> @AlanBateman Does it make sense to

Re: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39]

2022-12-05 Thread Athijegannathan Sundararajan
On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]

2022-12-05 Thread Alan Bateman
On Mon, 5 Dec 2022 10:16:22 GMT, Viktor Klang wrote: >> Alan Bateman 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 six additional >> commits

Re: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39]

2022-12-05 Thread Maurizio Cimadamore
> This PR contains the API and implementation changes for JEP-434 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request

Re: RFR: JDK-8296360: Track native memory used by zlib via NMT

2022-12-05 Thread Alan Bateman
On Fri, 4 Nov 2022 14:35:00 GMT, Thomas Stuefe wrote: > This patch adds NMT tracking to the zlib. > > *Please note: we currently discuss whether NMT can be expanded across the JDK > in this ML discussion [1]. This PR depends on the outcome of that discussion > and won't proceed unless

Re: RFR: 8297495: j.u.concurrent updates for JDK 20 [v2]

2022-12-05 Thread Viktor Klang
On Thu, 1 Dec 2022 14:46:48 GMT, Alan Bateman wrote: >> The proposed updates for JDK 20 are: >> >> - ForkJoinPool.externalSubmit >> - ForkJoinWorkerThread.getQueuedTaskCount >> >> These methods will be used to improve the Thread.yield implementation for >> virtual threads. The range of

RFR: JDK-8296360: Track native memory used by zlib via NMT

2022-12-05 Thread Thomas Stuefe
This patch adds NMT tracking to the zlib. *Please note: we currently discuss whether NMT can be expanded across the JDK in this ML discussion [1]. This PR depends on the outcome of that discussion and won't proceed unless greenlighted. But since [1] is stalled, I post the PR for RFR to get

Re: RFR: 8297976: Remove sun.net.ProgressMonitor and related classes

2022-12-05 Thread Jaikiran Pai
On Fri, 2 Dec 2022 08:31:25 GMT, Daniel Jeliński wrote: > Please review this patch that removes progress monitoring classes used by > UrlConnection. > Since Java 9 these classes are not used in the JDK, and are not exported from > java.base. If anyone was still using them, reimplementing them