From iris at openjdk.org  Tue Aug  1 01:48:54 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 1 Aug 2023 01:48:54 GMT
Subject: [jdk21] RFR: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
In-Reply-To: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
References: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
Message-ID: <l2UIAj5y2x61M3-zD9-l52BAroBZF-GM7HNDq8K4UWo=.30d62916-fbdc-47b6-a774-13c2ee9101b8@github.com>

On Mon, 31 Jul 2023 21:13:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which contains a backport of commit [c6396dce](https://github.com/openjdk/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This PR is a java.text doc/test-only change.
> 
> The commit being backported was authored by Justin Lu on 25 Jul 2023 and was reviewed by Naoto Sato.
> 
> Thanks!

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/154#pullrequestreview-1556044570

From duke at openjdk.org  Tue Aug  1 06:29:28 2023
From: duke at openjdk.org (sid8606)
Date: Tue, 1 Aug 2023 06:29:28 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v10]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/b81d5bb7..924b45bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Tue Aug  1 06:29:32 2023
From: duke at openjdk.org (sid8606)
Date: Tue, 1 Aug 2023 06:29:32 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v3]
In-Reply-To: <UA7ZGFLTwJgbWQkZXrlWIjos5f9d9bcZt8-cqJlBpm8=.7da2a900-d87b-4ce5-b70f-6b88d7923ff4@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <k4zjNV-UZ6-Jk1_mohDeZ9u69tOh9WR2w5Avd164j2E=.6dd0bc9f-f2c0-4bb6-a420-0e3105add602@github.com>
 <ePA2Co3SuIIkJZd1Ox5AvEr8bJIv8lOBEuV9CGiCQng=.977566d9-770a-4540-9cd5-4df752d63ac2@github.com>
 <UA7ZGFLTwJgbWQkZXrlWIjos5f9d9bcZt8-cqJlBpm8=.7da2a900-d87b-4ce5-b70f-6b88d7923ff4@github.com>
Message-ID: <kbMKD8_IasD4yeM1LCS_na5E7O-_v1cC_kzxHFnfwQo=.71e42d44-4b53-4401-ab25-bcc35f028756@github.com>

On Mon, 31 Jul 2023 14:27:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> src/hotspot/cpu/s390/frame_s390.cpp line 228:
>> 
>>> 226: 
>>> 227: bool frame::upcall_stub_frame_is_first() const {
>>> 228:   assert(is_upcall_stub_frame(), "must be optimzed entry frame");
>> 
>> typo: s/optimzed/optimized
>
> @sid8606 you left this one.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1280157849

From jpai at openjdk.org  Tue Aug  1 09:11:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Aug 2023 09:11:49 GMT
Subject: RFR: 8313274: Failure building java.base-jmod target
In-Reply-To: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
Message-ID: <rr0mXroamJdaj3b7-nSlF4LRm9vuxSiil2dGcIhAAto=.753fbff7-a182-4026-a95c-732706e13807@github.com>

On Tue, 1 Aug 2023 09:01:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the build failure noted in https://bugs.openjdk.org/browse/JDK-8313274?
> 
> The build failure is consistently reproducible with `--with-jobs=1`. Martin, in that JBS issue, has narrowed down the commit to the change in https://github.com/openjdk/jdk/pull/14561, starting which this failure is reproducible. The change in that PR, from what I understand, was meant to not require upgradable modules be a prerequisite for the `java.base-jmod` make target:
> 
>> ... upgradeable modules, those shouldn't be on the prerequisites list for java.base-jmod.
> 
> The implementation of that change uses the `FindAllUpgradeableModules` function which as commented in the make files does:
> 
>> #Upgradeable modules are those that are either defined as upgradeable or that
>> #require an upradeable module.
> 
> The implementation of `FindAllUpgradeableModules` uses the `UPGRADEABLE_PLATFORM_MODULES` make variable which similarly comments:
> 
>> #Modules that directly or indirectly requiring upgradeable modules
>> #should carefully be considered if it should be upgradeable or not.
> 
> However, that set currently doesn't include the "indirectly requiring upgradable modules" and thus appears to be missing some of the modules that are considered upgradable.
> 
> As a result, what seems to be happening is that the `java.base-jmod` make target now can (and does) end up requiring a particular target as a prerequisite, say `jdk.jdeps` (which uses `java.compiler` upgradable module), but doesn't add the `java.compiler-jmod` target as a prerequisite and thus ends up with that build failure:
> 
> 
> Creating java.base.jmod
> Error: Resolution failed: Module java.compiler not found, required by jdk.jdeps
> 
> 
> The commit in this PR proposes to fix this by updating the static set of `UPGRADEABLE_PLATFORM_MODULES` to include the indirect modules that require the upgradable modules. How these additional modules were derived is explained as a separate comment in this PR.
> 
> The build succeeds with this change, both with `--with-jobs=1` and without the `--with-jobs` option (in which case on my setup it uses 8 jobs).
> 
> I have triggered tier testing in the CI to make sure this doesn't cause any unexpected regressions.
> 
> This change will require reviews from both the build team as well as the Java modules team - my knowledge of these areas is limited and I'm unsure if there are any additional considerations to take into account.

The additional set of modules included in the `UPGRADEABLE_PLATFORM_MODULES` was determined programatically using the following code, which starts with the "well known" upgradable modules (defined in JEP 261 https://openjdk.org/jeps/261) and then finds the dependents of these upgradable modules:


import java.lang.module.ModuleDescriptor;
import java.util.HashSet;
import java.util.Set;
import java.lang.module.ModuleFinder;
import java.lang.module.ModuleReference;
import java.util.Collections;
import java.util.TreeSet;
import java.util.stream.Collectors;

public class UpgradableModules {
    public static void main(final String[] args) throws Exception {
        // upgradable as specified by the JEP https://openjdk.org/jeps/261
        final Set<String> specedUpgradable = new TreeSet<>(Set.of(
                // "java.activation", // no longer present in mainline
                "java.compiler",
                // "java.corba", // no longer present in mainline
                // "java.transaction", // no longer present in mainline
                // "java.xml.bind", // no longer present in mainline
                // "java.xml.ws" // no longer present in mainline
                //"java.xml.ws.annotation", // no longer present in mainline
                "jdk.internal.vm.compiler"
                // "jdk.xml.bind" // no longer present in mainline
                // "jdk.xml.ws" // no longer present in mainline
        ));
        // all other modules that "require" these JEP specified upgradable modules
        final Set<String> dependentUpgradable = new TreeSet<>();
        final ModuleFinder sysModuleFinder = ModuleFinder.ofSystem();
        final Set<ModuleReference> allModules = sysModuleFinder.findAll();
        System.out.println("Using following modules as universe for finding upgradable modules: "
                + allModules.stream()
                .map((mr) -> mr.descriptor().name())
                .collect(Collectors.toList()));
        for (final String upgradableModName : specedUpgradable) {
            final ModuleReference dependency = sysModuleFinder.find(upgradableModName)
                    .orElseThrow(() -> new AssertionError("Missing module " + upgradableModName));
            dependentUpgradable.addAll(findDependents(upgradableModName, allModules));
        }
        System.out.println("JEP upgradable modules: " + specedUpgradable);
        System.out.println("Dependent upgradable modules: " + dependentUpgradable);
    }

    private static Set<String> findDependents(final String dependencyModName,
                                              final Set<ModuleReference> allModules) {
        System.out.println("finding dependents of " + dependencyModName);
        final Set<String> dependents = new TreeSet<>();
        for (final ModuleReference sysModRef : allModules) {
            for (final ModuleDescriptor.Requires req : sysModRef.descriptor().requires()) {
                final String reqModName = req.name();
                if (dependencyModName.equals(reqModName)) {
                    // found a dependent
                    final String dependent = sysModRef.descriptor().name();
                    System.out.println(dependencyModName + " is required by " + dependent);
                    dependents.add(dependent);
                    // if requirement is transitive find dependencies of this dependent
                    if (req.modifiers().contains(ModuleDescriptor.Requires.Modifier.TRANSITIVE)) {
                        final Set<String> transitive = findDependents(dependent, allModules);
                        System.out.println(dependent + " is required by " + transitive);
                        dependents.addAll(transitive);
                    }
                }
            }
        }
        return dependents;
    }
}

When this code is run against the current mainline, it generates:


Using following modules as universe for finding upgradable modules: [java.sql, java.sql.rowset, jdk.internal.le, jdk.jsobject, jdk.sctp, jdk.incubator.vector, jdk.compiler, java.xml, jdk.random, jdk.internal.vm.ci, jdk.crypto.cryptoki, java.scripting, jdk.security.auth, jdk.jdi, jdk.jpackage, jdk.httpserver, jdk.nio.mapmode, jdk.security.jgss, jdk.jshell, java.security.sasl, jdk.internal.opt, jdk.jfr, jdk.naming.dns, java.naming, jdk.javadoc, jdk.net, java.rmi, java.compiler, jdk.accessibility, java.security.jgss, java.prefs, jdk.editpad, java.smartcardio, jdk.internal.jvmstat, jdk.jconsole, jdk.jdeps, jdk.dynalink, jdk.crypto.ec, jdk.jlink, jdk.management.jfr, jdk.jcmd, jdk.internal.vm.compiler, jdk.jdwp.agent, jdk.unsupported.desktop, jdk.zipfs, jdk.management, java.base, jdk.hotspot.agent, java.desktop, java.management.rmi, jdk.attach, jdk.localedata, jdk.naming.rmi, java.datatransfer, jdk.jstatd, java.management, jdk.jartool, java.xml.crypto, jdk.internal.ed, java.logging, jdk.ch
 arsets, java.instrument, java.net.http, java.se, jdk.unsupported, jdk.internal.vm.compiler.management, java.transaction.xa, jdk.xml.dom, jdk.management.agent]
finding dependents of java.compiler
java.compiler is required by jdk.compiler
finding dependents of jdk.compiler
jdk.compiler is required by jdk.jshell
jdk.compiler is required by jdk.javadoc
finding dependents of jdk.javadoc
jdk.javadoc is required by []
jdk.compiler is required by jdk.jdeps
jdk.compiler is required by [jdk.javadoc, jdk.jdeps, jdk.jshell]
java.compiler is required by jdk.jshell
finding dependents of jdk.jshell
jdk.jshell is required by []
java.compiler is required by jdk.javadoc
finding dependents of jdk.javadoc
jdk.javadoc is required by []
java.compiler is required by jdk.jdeps
java.compiler is required by java.se
finding dependents of java.se
java.se is required by []
finding dependents of jdk.internal.vm.compiler
JEP upgradable modules: [java.compiler, jdk.internal.vm.compiler]
Dependent upgradable modules: [java.se, jdk.compiler, jdk.javadoc, jdk.jdeps, jdk.jshell]

So `java.se, jdk.compiler, jdk.javadoc, jdk.jdeps, jdk.jshell` are the additional modules that this commit adds to the `UPGRADEABLE_PLATFORM_MODULES` set.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15102#issuecomment-1659898091

From alanb at openjdk.org  Tue Aug  1 10:33:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Aug 2023 10:33:51 GMT
Subject: RFR: 8313274: Failure building java.base-jmod target
In-Reply-To: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
Message-ID: <5OpVY0eAtv4ik4GX7Q-WNrMpN-050dEnva_V9Sw6CXk=.7f68f6f0-3553-4797-a1ef-c364b2c2ddf8@github.com>

On Tue, 1 Aug 2023 09:01:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the build failure noted in https://bugs.openjdk.org/browse/JDK-8313274?
> 
> The build failure is consistently reproducible with `--with-jobs=1`. Martin, in that JBS issue, has narrowed down the commit to the change in https://github.com/openjdk/jdk/pull/14561, starting which this failure is reproducible. The change in that PR, from what I understand, was meant to not require upgradable modules be a prerequisite for the `java.base-jmod` make target:
> 
>> ... upgradeable modules, those shouldn't be on the prerequisites list for java.base-jmod.
> 
> The implementation of that change uses the `FindAllUpgradeableModules` function which as commented in the make files does:
> 
>> #Upgradeable modules are those that are either defined as upgradeable or that
>> #require an upradeable module.
> 
> The implementation of `FindAllUpgradeableModules` uses the `UPGRADEABLE_PLATFORM_MODULES` make variable which similarly comments:
> 
>> #Modules that directly or indirectly requiring upgradeable modules
>> #should carefully be considered if it should be upgradeable or not.
> 
> However, that set currently doesn't include the "indirectly requiring upgradable modules" and thus appears to be missing some of the modules that are considered upgradable.
> 
> As a result, what seems to be happening is that the `java.base-jmod` make target now can (and does) end up requiring a particular target as a prerequisite, say `jdk.jdeps` (which uses `java.compiler` upgradable module), but doesn't add the `java.compiler-jmod` target as a prerequisite and thus ends up with that build failure:
> 
> 
> Creating java.base.jmod
> Error: Resolution failed: Module java.compiler not found, required by jdk.jdeps
> 
> 
> The commit in this PR proposes to fix this by updating the static set of `UPGRADEABLE_PLATFORM_MODULES` to include the indirect modules that require the upgradable modules. How these additional modules were derived is explained as a separate comment in this PR.
> 
> The build succeeds with this change, both with `--with-jobs=1` and without the `--with-jobs` option (in which case on my setup it uses 8 jobs).
> 
> I have triggered tier testing in the CI to make sure this doesn't cause any unexpected regressions.
> 
> This change will require reviews from both the build team as well as the Java modules team - my knowledge of these areas is limited and I'm unsure if there are any additional considerations to take into account.

Changes to UPGRADEABLE_PLATFORM_MODULES require discussion as adding or removing a java.* modules impacts the Java SE specification. It also opens the door to accidental mix 'n match of modules from different JDK modules. So I don't think this the right change for this issue.

-------------

Changes requested by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15102#pullrequestreview-1556678796

From jpai at openjdk.org  Tue Aug  1 10:33:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Aug 2023 10:33:51 GMT
Subject: RFR: 8313274: Failure building java.base-jmod target
In-Reply-To: <5OpVY0eAtv4ik4GX7Q-WNrMpN-050dEnva_V9Sw6CXk=.7f68f6f0-3553-4797-a1ef-c364b2c2ddf8@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
 <5OpVY0eAtv4ik4GX7Q-WNrMpN-050dEnva_V9Sw6CXk=.7f68f6f0-3553-4797-a1ef-c364b2c2ddf8@github.com>
Message-ID: <VZKRaNSD2GrqwDdtx5mltMixOslqAg3jnU6wW7eT79M=.ab0e7075-3830-4e25-bc81-6ed8f4b5ce51@github.com>

On Tue, 1 Aug 2023 10:30:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It also opens the door to accidental mix 'n match of modules from different JDK modules. So I don't think this the right change for this issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15102#issuecomment-1660035694

From jpai at openjdk.org  Tue Aug  1 10:37:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 1 Aug 2023 10:37:56 GMT
Subject: Withdrawn: 8313274: Failure building java.base-jmod target
In-Reply-To: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
Message-ID: <vKWk0WIJf8ZtpanJtN8fZo_0Cisb6xfd9GKAMliUkAM=.4f9e0d83-af39-4a38-a291-c9318b120ead@github.com>

On Tue, 1 Aug 2023 09:01:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the build failure noted in https://bugs.openjdk.org/browse/JDK-8313274?
> 
> The build failure is consistently reproducible with `--with-jobs=1`. Martin, in that JBS issue, has narrowed down the commit to the change in https://github.com/openjdk/jdk/pull/14561, starting which this failure is reproducible. The change in that PR, from what I understand, was meant to not require upgradable modules be a prerequisite for the `java.base-jmod` make target:
> 
>> ... upgradeable modules, those shouldn't be on the prerequisites list for java.base-jmod.
> 
> The implementation of that change uses the `FindAllUpgradeableModules` function which as commented in the make files does:
> 
>> #Upgradeable modules are those that are either defined as upgradeable or that
>> #require an upradeable module.
> 
> The implementation of `FindAllUpgradeableModules` uses the `UPGRADEABLE_PLATFORM_MODULES` make variable which similarly comments:
> 
>> #Modules that directly or indirectly requiring upgradeable modules
>> #should carefully be considered if it should be upgradeable or not.
> 
> However, that set currently doesn't include the "indirectly requiring upgradable modules" and thus appears to be missing some of the modules that are considered upgradable.
> 
> As a result, what seems to be happening is that the `java.base-jmod` make target now can (and does) end up requiring a particular target as a prerequisite, say `jdk.jdeps` (which uses `java.compiler` upgradable module), but doesn't add the `java.compiler-jmod` target as a prerequisite and thus ends up with that build failure:
> 
> 
> Creating java.base.jmod
> Error: Resolution failed: Module java.compiler not found, required by jdk.jdeps
> 
> 
> The commit in this PR proposes to fix this by updating the static set of `UPGRADEABLE_PLATFORM_MODULES` to include the indirect modules that require the upgradable modules. How these additional modules were derived is explained as a separate comment in this PR.
> 
> The build succeeds with this change, both with `--with-jobs=1` and without the `--with-jobs` option (in which case on my setup it uses 8 jobs).
> 
> I have triggered tier testing in the CI to make sure this doesn't cause any unexpected regressions.
> 
> This change will require reviews from both the build team as well as the Java modules team - my knowledge of these areas is limited and I'm unsure if there are any additional considerations to take into account.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15102

From jvernee at openjdk.org  Tue Aug  1 13:04:40 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Aug 2023 13:04:40 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <8o90m_870sJwVWPZBRch9CR-aPOnaZzGP6DxjBexXcI=.294edec1-2355-465a-91d1-b384e9ff104f@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

All green

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15089#pullrequestreview-1556945814

From rriggs at openjdk.org  Tue Aug  1 14:38:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Aug 2023 14:38:57 GMT
Subject: [jdk21] Integrated: 8310033: Clarify return value of Java Time
 compareTo methods
In-Reply-To: <ADJwWmHwN83osnGnw5-abEHQVIXAxAGpE1R2gBbCCbQ=.97f06961-5231-430c-a545-d75821ab2f19@github.com>
References: <ADJwWmHwN83osnGnw5-abEHQVIXAxAGpE1R2gBbCCbQ=.97f06961-5231-430c-a545-d75821ab2f19@github.com>
Message-ID: <vhFhszeOffkmerQV9tIpOOq2K1YlyLsxtSy3jTwU5Dw=.29cc3aae-678e-4b46-814e-7493b06ee128@github.com>

On Mon, 31 Jul 2023 19:48:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A doc-only change to improve javadoc in java.time.

This pull request has now been integrated.

Changeset: a228185e
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/a228185ebbda9b2004262b494f648ab62078fcde
Stats:     84 lines in 17 files changed: 49 ins; 0 del; 35 mod

8310033: Clarify return value of Java Time compareTo methods

Reviewed-by: naoto
Backport-of: 8650026ff16e5c5eff897f9fd39c0c35fd8b7367

-------------

PR: https://git.openjdk.org/jdk21/pull/153

From jvernee at openjdk.org  Tue Aug  1 15:46:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Aug 2023 15:46:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
Message-ID: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>

This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:

1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on unsupported platforms. All tests are turned on by default, instead of being skipped when the linker is not present.
10. https://github.com/openjdk/panama-foreign/pull/851 Minor code tweaks to ensure the JIT can constant fold through native access checks if the accessing class is statically known (see commit/original PR for changes).
11. https://github.com/openjdk/panama-foreign/pull/853 Remove all the `@PreviewFeature` annotations from the API. Update all `@since` tags in the Javadoc to `@since 22` (per [JEP 12](https://bugs.openjdk.org/browse/JDK-8195734)). Update tests and benchmarks to no longer build and run using `--enable-preview` (or the `@enablePreview` jtreg tag).

I want to call out in particular that this patch finalizes the FFM API (by moving it out of preview), and requires all JDK implementations to implement it. Most ports already have full FFM API support. The ones that are missing are: s390 ([currently under review](https://github.com/openjdk/jdk/pull/14801)), windows-x86 (deprecated for removal), and linux-86 & arm32 (which can both be implemented using the fallback linker [1](https://github.com/openjdk/panama-foreign/pull/770) [2](https://mail.openjdk.org/pipermail/porters-dev/2023-March/000753.html)).

-------------

Commit messages:
 - use immutable map for fallback linker canonical layouts
 - 8313265: Move the FFM API out of preview
 - 8313005: Ensure native access check can fold away
 - 8312981: Make the linker API required
 - 8312615: Ensure jdk_foreign tests pass on linux-x86
 - 8312186: TestStringEncodingFails for UTF-32
 - 8312059: Clarify the documention for variadic functions
 - 8311533: SegmentAllocator::allocateArray call can be ambiguous
 - 8310893: VarHandleTestExact fails
 - 8310820: Remove MemorySegment::segmentOffset
 - ... and 4 more: https://git.openjdk.org/jdk/compare/6fca2898...b0a1abaf

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312522
  Stats: 2444 lines in 224 files changed: 1084 ins; 721 del; 639 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From jvernee at openjdk.org  Tue Aug  1 15:46:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Aug 2023 15:46:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <WRs9SDShhlJ04SnlJru3YqOjf_6jcEyR6rKFyzkDs-A=.336c32d8-dc73-462c-a37d-044ed5ac1b1f@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Open build question: the `jdk_foreign` tests will fail if a JDK does not have a full linker port, and is not built with `--enable-fallback-linker`. If the API is to become required, as proposed by this PR, then should the build also require the fallback linker by default on platforms that do not have a full linker port?

FWIW, GHA linux-x86 currently fail tests, since it is not being built with `--enable-fallback-linker`. I think this could be easily [resolved](https://github.com/JornVernee/jdk/commit/6577c3725f79375c1df8c4af70925d8ac8dec9a2), but attempting this currently [fails](https://github.com/JornVernee/jdk/actions/runs/5726155097/job/15516044665) when trying to install GCC:


Package gcc-10-multilib is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source


This error occurs even on a plain master branch, so it doesn't seem to be caused by this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1660052156
PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1660353141

From duke at openjdk.org  Tue Aug  1 15:46:21 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 1 Aug 2023 15:46:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <EOzojng1c9Ha2eaFXFlKVoMq5H8SmyJpYtY3O988vaI=.448a94e2-afdc-471a-9390-a94b8d524b9d@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 299:

> 297:     @Override
> 298:     public Map<String, MemoryLayout> canonicalLayouts() {
> 299:         return CANONICAL_LAYOUTS;

`CANONICAL_LAYOUTS` is?set to?a?`HashMap`, which?is?not?unmodifiable.
Suggestion:

        return Collections.unmodifiableMap(CANONICAL_LAYOUTS);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1280480570

From jvernee at openjdk.org  Tue Aug  1 15:46:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 1 Aug 2023 15:46:21 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <EOzojng1c9Ha2eaFXFlKVoMq5H8SmyJpYtY3O988vaI=.448a94e2-afdc-471a-9390-a94b8d524b9d@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <EOzojng1c9Ha2eaFXFlKVoMq5H8SmyJpYtY3O988vaI=.448a94e2-afdc-471a-9390-a94b8d524b9d@github.com>
Message-ID: <j-aHGxHEExz5EsR9m6GiSLcJJ5gHr-952acI_9n2BYQ=.8ccdcc45-070e-4caa-bb31-f4324ab42287@github.com>

On Tue, 1 Aug 2023 11:17:57 GMT, ExE Boss <duke at openjdk.org> wrote:

>> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
>> 
>> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
>> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
>> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
>> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
>> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
>> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
>> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
>> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
>> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO...
>
> src/java.base/share/classes/jdk/internal/foreign/abi/fallback/FallbackLinker.java line 299:
> 
>> 297:     @Override
>> 298:     public Map<String, MemoryLayout> canonicalLayouts() {
>> 299:         return CANONICAL_LAYOUTS;
> 
> `CANONICAL_LAYOUTS` is?set to?a?`HashMap`, which?is?not?unmodifiable.
> Suggestion:
> 
>         return Collections.unmodifiableMap(CANONICAL_LAYOUTS);

Good catch. I think the right fix is to update FallbackLinker though. The other ports already use `Map.of`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15103#discussion_r1280665030

From ccheung at openjdk.org  Tue Aug  1 17:05:43 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Aug 2023 17:05:43 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v4]
In-Reply-To: <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
Message-ID: <V7nmCQZlthPSc2XaYBeNbJKteBcmotWQeXmQ0HUjDNI=.e003b59a-f536-4f51-9d78-a5bb7bd8cad3@github.com>

On Thu, 27 Jul 2023 19:09:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>> 
>> Verified with tier 1-9 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ioi comments

Looks good overall. I have one question.

src/hotspot/share/oops/constantPool.cpp line 308:

> 306:           assert(java_lang_String::is_instance(obj), "must be");
> 307:           if (!ArchiveHeapWriter::is_string_too_large_to_archive(obj)) {
> 308:             scratch_rr->obj_at_put(i, nullptr);

Should the above be the following?
`scratch_rr->obj_at_put(i, obj);`

-------------

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1557454731
PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1280919862

From joehw at openjdk.org  Tue Aug  1 19:39:49 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 1 Aug 2023 19:39:49 GMT
Subject: RFR: 8310991: missing @since tags in java.xml
Message-ID: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>

Please review a patch that adds the @since tag to DOM package.

-------------

Commit messages:
 - 8310991: missing @since tags in java.xml

Changes: https://git.openjdk.org/jdk/pull/15109/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310991
  Stats: 36 lines in 18 files changed: 36 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15109.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15109/head:pull/15109

PR: https://git.openjdk.org/jdk/pull/15109

From iris at openjdk.org  Tue Aug  1 20:04:47 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 1 Aug 2023 20:04:47 GMT
Subject: RFR: 8310991: missing @since tags in java.xml
In-Reply-To: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
References: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
Message-ID: <AkfzStMamc4SP-TXX20Jp_oVRsvT_ArX9UJP2QWEpKo=.19a56ac0-3701-461c-80cd-b089295c935c@github.com>

On Tue, 1 Aug 2023 19:32:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that adds the @since tag to DOM package.

Added @since tags follow existing convention for XML APIs in java.xml and jdk.xml.dom modules.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15109#pullrequestreview-1557740390

From naoto at openjdk.org  Tue Aug  1 20:04:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 1 Aug 2023 20:04:48 GMT
Subject: RFR: 8310991: missing @since tags in java.xml
In-Reply-To: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
References: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
Message-ID: <MRgeVYbVxpdg5XqFO3YFhWBwsPonNsssSyMddiqQI1I=.c315e1d3-dddf-4660-a169-7ef20e0261ef@github.com>

On Tue, 1 Aug 2023 19:32:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that adds the @since tag to DOM package.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15109#pullrequestreview-1557745601

From lancea at openjdk.org  Tue Aug  1 20:09:49 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 1 Aug 2023 20:09:49 GMT
Subject: RFR: 8310991: missing @since tags in java.xml
In-Reply-To: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
References: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
Message-ID: <rPkcbGwiGvdldYbyBD5ILRrXCm6EuyvfGlELrpv_uFk=.d1c14d1e-e7f3-4bb8-8f7d-94e3871802cd@github.com>

On Tue, 1 Aug 2023 19:32:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that adds the @since tag to DOM package.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15109#pullrequestreview-1557752047

From duke at openjdk.org  Tue Aug  1 20:11:50 2023
From: duke at openjdk.org (phuchau1989)
Date: Tue, 1 Aug 2023 20:11:50 GMT
Subject: RFR: 8313274: Failure building java.base-jmod target
In-Reply-To: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
Message-ID: <kscYJe_Y8R4E55ox_Vpfra-MahsxCHSUWLf5X0h838I=.4cf5476c-b6b5-4c24-bd0d-89c4ca41c462@github.com>

On Tue, 1 Aug 2023 09:01:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address the build failure noted in https://bugs.openjdk.org/browse/JDK-8313274?
> 
> The build failure is consistently reproducible with `--with-jobs=1`. Martin, in that JBS issue, has narrowed down the commit to the change in https://github.com/openjdk/jdk/pull/14561, starting which this failure is reproducible. The change in that PR, from what I understand, was meant to not require upgradable modules be a prerequisite for the `java.base-jmod` make target:
> 
>> ... upgradeable modules, those shouldn't be on the prerequisites list for java.base-jmod.
> 
> The implementation of that change uses the `FindAllUpgradeableModules` function which as commented in the make files does:
> 
>> #Upgradeable modules are those that are either defined as upgradeable or that
>> #require an upradeable module.
> 
> The implementation of `FindAllUpgradeableModules` uses the `UPGRADEABLE_PLATFORM_MODULES` make variable which similarly comments:
> 
>> #Modules that directly or indirectly requiring upgradeable modules
>> #should carefully be considered if it should be upgradeable or not.
> 
> However, that set currently doesn't include the "indirectly requiring upgradable modules" and thus appears to be missing some of the modules that are considered upgradable.
> 
> As a result, what seems to be happening is that the `java.base-jmod` make target now can (and does) end up requiring a particular target as a prerequisite, say `jdk.jdeps` (which uses `java.compiler` upgradable module), but doesn't add the `java.compiler-jmod` target as a prerequisite and thus ends up with that build failure:
> 
> 
> Creating java.base.jmod
> Error: Resolution failed: Module java.compiler not found, required by jdk.jdeps
> 
> 
> The commit in this PR proposes to fix this by updating the static set of `UPGRADEABLE_PLATFORM_MODULES` to include the indirect modules that require the upgradable modules. How these additional modules were derived is explained as a separate comment in this PR.
> 
> The build succeeds with this change, both with `--with-jobs=1` and without the `--with-jobs` option (in which case on my setup it uses 8 jobs).
> 
> I have triggered tier testing in the CI to make sure this doesn't cause any unexpected regressions.
> 
> This change will require reviews from both the build team as well as the Java modules team - my knowledge of these areas is limited and I'm unsure if there are any additional considerations to take into account.

Marked as reviewed by phuchau1989 at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15102#pullrequestreview-1557755385

From naoto at openjdk.org  Tue Aug  1 20:21:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 1 Aug 2023 20:21:11 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v5]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <KsHPJN-4NOFaU1Tu8qSVJdkO__GHD0J07cZNiHrBkJc=.0d58d5ce-2bfc-4dbc-b17e-c3756e887b35@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
 - small cleanup
 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Update ReferencedKeyTest.java
 - Simple versions of create
 - Add flag for reference queue type
 - Merge branch 'master' into 8310913
 - Update to use VirtualThread friendly stale queue.
 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Remove warning tied to String Templates
 - ... and 19 more: https://git.openjdk.org/jdk/compare/7ba8c69a...0e435898

-------------

Changes: https://git.openjdk.org/jdk/pull/14404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=04
  Stats: 697 lines in 7 files changed: 129 ins; 441 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From matsaave at openjdk.org  Tue Aug  1 21:08:05 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 1 Aug 2023 21:08:05 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v5]
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <KE_D8oQEFXSeyDO_2mAjQWRpRUsv138dUEcF1UZX-k0=.40896a1f-c3c2-4c0c-80cf-9ad286eb7070@github.com>

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
> 
> Verified with tier 1-9 tests.

Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into remove_exit_after_dump_8306582
 - Calvin comment
 - Ioi comments
 - Refactored KlassToOopHandleTable, Ioi and Alan comments
 - Merge fix
 - Restores java loaders
 - Ioi and David comments
 - Windows fix
 - 8306582: Remove MetaspaceShared::exit_after_static_dump()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14879/files
  - new: https://git.openjdk.org/jdk/pull/14879/files/64d8c638..f4f9091a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14879&range=03-04

  Stats: 9132 lines in 289 files changed: 4715 ins; 2001 del; 2416 mod
  Patch: https://git.openjdk.org/jdk/pull/14879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14879/head:pull/14879

PR: https://git.openjdk.org/jdk/pull/14879

From matsaave at openjdk.org  Tue Aug  1 21:08:05 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 1 Aug 2023 21:08:05 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v4]
In-Reply-To: <V7nmCQZlthPSc2XaYBeNbJKteBcmotWQeXmQ0HUjDNI=.e003b59a-f536-4f51-9d78-a5bb7bd8cad3@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
 <V7nmCQZlthPSc2XaYBeNbJKteBcmotWQeXmQ0HUjDNI=.e003b59a-f536-4f51-9d78-a5bb7bd8cad3@github.com>
Message-ID: <JrV73ojqGgNcU9a6MiX5S1gSFjsTjI3o5Gb0c_1S7tE=.0cf3f3f1-c58a-4348-a76a-df167a305307@github.com>

On Tue, 1 Aug 2023 17:02:46 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ioi comments
>
> src/hotspot/share/oops/constantPool.cpp line 308:
> 
>> 306:           assert(java_lang_String::is_instance(obj), "must be");
>> 307:           if (!ArchiveHeapWriter::is_string_too_large_to_archive(obj)) {
>> 308:             scratch_rr->obj_at_put(i, nullptr);
> 
> Should the above be the following?
> `scratch_rr->obj_at_put(i, obj);`

Yes it should! Thank you for catching this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1281150300

From ccheung at openjdk.org  Tue Aug  1 21:54:52 2023
From: ccheung at openjdk.org (Calvin Cheung)
Date: Tue, 1 Aug 2023 21:54:52 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v5]
In-Reply-To: <KE_D8oQEFXSeyDO_2mAjQWRpRUsv138dUEcF1UZX-k0=.40896a1f-c3c2-4c0c-80cf-9ad286eb7070@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <KE_D8oQEFXSeyDO_2mAjQWRpRUsv138dUEcF1UZX-k0=.40896a1f-c3c2-4c0c-80cf-9ad286eb7070@github.com>
Message-ID: <aeAT0eDTfERCtdHmv2Tyt5RoZ4qmD8rBqndTrba5Wuw=.97d88e60-adc0-4b47-ae80-2bb7c22d436d@github.com>

On Tue, 1 Aug 2023 21:08:05 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
>> 
>> 
>>  // We have finished dumping the static archive. At this point, there may be pending VM
>>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>>  // may cause these VM operations to fail. For safety, forget these operations and
>>  // exit the VM directly.
>>  void MetaspaceShared::exit_after_static_dump() {
>>    os::_exit(0);
>>  } 
>> 
>> 
>> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
>> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
>> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
>> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
>> 
>> Verified with tier 1-9 tests.
>
> Matias Saavedra Silva has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_exit_after_dump_8306582
>  - Calvin comment
>  - Ioi comments
>  - Refactored KlassToOopHandleTable, Ioi and Alan comments
>  - Merge fix
>  - Restores java loaders
>  - Ioi and David comments
>  - Windows fix
>  - 8306582: Remove MetaspaceShared::exit_after_static_dump()

Marked as reviewed by ccheung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14879#pullrequestreview-1557891129

From clanger at openjdk.org  Tue Aug  1 22:03:56 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 1 Aug 2023 22:03:56 GMT
Subject: [jdk21] RFR: 8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
Message-ID: <9Iij8Jc0pCJjBh5gufESH2b8GpkLWH3NotFYaLdLvJk=.4a4a2bfe-3681-4134-8ce7-adee0f794714@github.com>

Hi all,

This pull request contains a backport of [JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit [d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851edd4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Per Minborg on 24 Jul 2023 and was reviewed by Jorn Vernee.


Test fix, so qualifying for jdk21 under RDP2 rules.

Thanks!

-------------

Commit messages:
 - Backport d1cc2782606e8a3cfead9055aa845e48e851edd4

Changes: https://git.openjdk.org/jdk21/pull/157/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=157&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311822
  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk21/pull/157.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/157/head:pull/157

PR: https://git.openjdk.org/jdk21/pull/157

From jlu at openjdk.org  Tue Aug  1 23:04:04 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Aug 2023 23:04:04 GMT
Subject: [jdk21] Integrated: 8039165: [Doc] MessageFormat null locale generates
 NullPointerException
In-Reply-To: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
References: <JEUry7Jy_iEpNIjBbBKwX6M6K93nKGnSxPd0AiaJryk=.b394e6cf-9791-4279-931d-02507dbf9fa8@github.com>
Message-ID: <iBEZ6CtTX_1aoI_0fgJni_i1S70ttM27tqGkbBTwb3Y=.81941f8b-baa7-40e8-9dd9-2b5e64a93a65@github.com>

On Mon, 31 Jul 2023 21:13:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this change which contains a backport of commit [c6396dce](https://github.com/openjdk/jdk/commit/c6396dceb9a64578d5b335af27ad1d968190a1fa) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This PR is a java.text doc/test-only change.
> 
> The commit being backported was authored by Justin Lu on 25 Jul 2023 and was reviewed by Naoto Sato.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f34ac12a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/f34ac12aa7c2b932bf2f4c7a58e4dfdf228edfd2
Stats:     164 lines in 3 files changed: 97 ins; 64 del; 3 mod

8039165: [Doc] MessageFormat null locale generates NullPointerException

Reviewed-by: naoto, iris
Backport-of: c6396dceb9a64578d5b335af27ad1d968190a1fa

-------------

PR: https://git.openjdk.org/jdk21/pull/154

From jlu at openjdk.org  Tue Aug  1 23:19:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 1 Aug 2023 23:19:58 GMT
Subject: Integrated: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
References: <vXCU3IuIfquN7Fg7NzHZpC388vtyF_sbqgRWQrmKqVU=.2aef82f2-f476-4d9e-9f6e-68c13f1e151a@github.com>
Message-ID: <J-7QWUZ9dqBcFUe2nYIM8YKFKqgzot9vDiiIAzuwmoo=.08144cb7-7a84-4b68-9d66-e89b87682b88@github.com>

On Wed, 26 Jul 2023 20:41:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which contains the translations for updates to localized resources in the JDK since RDP1.
> 
> Included in this change are improved translations for certain values, which also includes global updates for translations of the words 'annotation' and 'file' for zh_CN.
> 
> The following files contain key/value resources that were added, updated, or removed in the original file. (This means that the localized versions of these files contain changes to translations that are a reflection of the original key/value changing, and are not just improved translations).
> 
> - src/java.base/share/classes/sun/launcher/resources/launcher.properties
> - src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
> - src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties
> - src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties
> 
> It is recommended to view the changes in UTF-8 native at https://cr.openjdk.org/~jlu/RDP2_Diffs/.

This pull request has now been integrated.

Changeset: 9b55e9a7
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18
Stats:     223 lines in 32 files changed: 36 ins; 15 del; 172 mod

8312572: JDK 21 RDP2 L10n resource files update

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15047

From joehw at openjdk.org  Wed Aug  2 01:41:08 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 2 Aug 2023 01:41:08 GMT
Subject: RFR: 8310991: missing @since tags in java.xml
In-Reply-To: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
References: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
Message-ID: <i-DbYWsLwR_IpFfFtwXktFabUs50tt4WgWNJwdWYPbo=.df2fb3f1-8cb6-4d91-8667-f9bf62debed6@github.com>

On Tue, 1 Aug 2023 19:32:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that adds the @since tag to DOM package.

Thanks all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15109#issuecomment-1661344704

From joehw at openjdk.org  Wed Aug  2 01:41:08 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 2 Aug 2023 01:41:08 GMT
Subject: Integrated: 8310991: missing @since tags in java.xml
In-Reply-To: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
References: <P-FQJCOHqnY01zVv2cXROG1yNJ5ujYje2VG6D3iXofY=.6fd0e88c-2bf0-4585-85c3-204375793a56@github.com>
Message-ID: <yO9IfMkcFvTGajCFneaHnkydUIf4KSWFHCzzM6gRXj0=.d392230d-79b4-4a7f-890d-b345445c2b43@github.com>

On Tue, 1 Aug 2023 19:32:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that adds the @since tag to DOM package.

This pull request has now been integrated.

Changeset: 528596fa
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/528596fa937f8589f71fa06929fbb75f62142a4f
Stats:     36 lines in 18 files changed: 36 ins; 0 del; 0 mod

8310991: missing @since tags in java.xml

Reviewed-by: iris, naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/15109

From jvernee at openjdk.org  Wed Aug  2 02:18:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Aug 2023 02:18:00 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <SKjWOpsfZIJPsTc8vyFL3kxAYzSQqL8W1hYv6En5BjU=.c18b7042-a07e-461b-8b09-6be7ae7a739f@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

FWIW, if you want to look into reducing the generated code further, I think we can potentially reduce the amount of shuffling between registers that's needed by reordering the arguments on the Java side so that each VMStorage corresponding to an argument of the leaf method handle is the same as the register for that argument in the Java calling convention.

I think the right place to do this is in DowncallLinker where we are creating the NativeEntryPoint. The way I think it should work: 
1. compute the Java calling convention's argument registers for the leaf method type.
2. compute a re-ordered VMStorage[] for the arguments, and a re-ordered method type, such that the VMStorage/type for a particular argument index matches the register for the same index used in the Java calling convention as much as possible.
3. use these 2 to create the native entry point + native method handle
4. apply the same reordering to the created native method handle (using MethodHandles::permuteArguments) so that the resulting method handle has the original argument order/method type.

Pushing this shuffling to the Java side will allow the JIT to reduce data motion, and this should result in reduced shuffling being needed overall I think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1661382669

From dholmes at openjdk.org  Wed Aug  2 04:04:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Aug 2023 04:04:58 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v4]
In-Reply-To: <JrV73ojqGgNcU9a6MiX5S1gSFjsTjI3o5Gb0c_1S7tE=.0cf3f3f1-c58a-4348-a76a-df167a305307@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
 <V7nmCQZlthPSc2XaYBeNbJKteBcmotWQeXmQ0HUjDNI=.e003b59a-f536-4f51-9d78-a5bb7bd8cad3@github.com>
 <JrV73ojqGgNcU9a6MiX5S1gSFjsTjI3o5Gb0c_1S7tE=.0cf3f3f1-c58a-4348-a76a-df167a305307@github.com>
Message-ID: <92hduxZ6vbxgkiYkbGWtKw9E_EezThT-5VeVo9vFACg=.ecdddcbc-5a0d-4fec-bdcb-44252a35957f@github.com>

On Tue, 1 Aug 2023 21:02:36 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.cpp line 308:
>> 
>>> 306:           assert(java_lang_String::is_instance(obj), "must be");
>>> 307:           if (!ArchiveHeapWriter::is_string_too_large_to_archive(obj)) {
>>> 308:             scratch_rr->obj_at_put(i, nullptr);
>> 
>> Should the above be the following?
>> `scratch_rr->obj_at_put(i, obj);`
>
> Yes it should! Thank you for catching this.

This suggests we don't have test coverage for this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1281362007

From thartmann at openjdk.org  Wed Aug  2 05:19:57 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 2 Aug 2023 05:19:57 GMT
Subject: [jdk21] RFR: 8313023: Return value corrupted when using CCS +
 isTrivial (mainline)
In-Reply-To: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>
References: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>
Message-ID: <JJYV8kBQGBBIC4-HDkBxZV7-Y8t9okBrSElccTtW67o=.f572d2c8-d3f2-417c-8209-c75eb1b80b8b@github.com>

On Mon, 31 Jul 2023 08:13:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [6fca2898](https://github.com/openjdk/jdk/commit/6fca28988794b52a6aa974bed1ed6f4f07e0994b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 31 Jul 2023 and was reviewed by Maurizio Cimadamore and Vladimir Ivanov.
> 
> Thanks!

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/150#pullrequestreview-1558210925

From dholmes at openjdk.org  Wed Aug  2 05:28:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Aug 2023 05:28:07 GMT
Subject: RFR: 8313274: Failure building java.base-jmod target
In-Reply-To: <VZKRaNSD2GrqwDdtx5mltMixOslqAg3jnU6wW7eT79M=.ab0e7075-3830-4e25-bc81-6ed8f4b5ce51@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
 <5OpVY0eAtv4ik4GX7Q-WNrMpN-050dEnva_V9Sw6CXk=.7f68f6f0-3553-4797-a1ef-c364b2c2ddf8@github.com>
 <VZKRaNSD2GrqwDdtx5mltMixOslqAg3jnU6wW7eT79M=.ab0e7075-3830-4e25-bc81-6ed8f4b5ce51@github.com>
Message-ID: <w6r1EZEPM5AQLUhXHEKP2LrUhKXNx1zUs3i4oRcIxic=.6f05e47c-5e7c-4197-ae9e-20f1577505cf@github.com>

On Tue, 1 Aug 2023 10:31:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the build failure noted in https://bugs.openjdk.org/browse/JDK-8313274?
>> 
>> The build failure is consistently reproducible with `--with-jobs=1`. Martin, in that JBS issue, has narrowed down the commit to the change in https://github.com/openjdk/jdk/pull/14561, starting which this failure is reproducible. The change in that PR, from what I understand, was meant to not require upgradable modules be a prerequisite for the `java.base-jmod` make target:
>> 
>>> ... upgradeable modules, those shouldn't be on the prerequisites list for java.base-jmod.
>> 
>> The implementation of that change uses the `FindAllUpgradeableModules` function which as commented in the make files does:
>> 
>>> #Upgradeable modules are those that are either defined as upgradeable or that
>>> #require an upradeable module.
>> 
>> The implementation of `FindAllUpgradeableModules` uses the `UPGRADEABLE_PLATFORM_MODULES` make variable which similarly comments:
>> 
>>> #Modules that directly or indirectly requiring upgradeable modules
>>> #should carefully be considered if it should be upgradeable or not.
>> 
>> However, that set currently doesn't include the "indirectly requiring upgradable modules" and thus appears to be missing some of the modules that are considered upgradable.
>> 
>> As a result, what seems to be happening is that the `java.base-jmod` make target now can (and does) end up requiring a particular target as a prerequisite, say `jdk.jdeps` (which uses `java.compiler` upgradable module), but doesn't add the `java.compiler-jmod` target as a prerequisite and thus ends up with that build failure:
>> 
>> 
>> Creating java.base.jmod
>> Error: Resolution failed: Module java.compiler not found, required by jdk.jdeps
>> 
>> 
>> The commit in this PR proposes to fix this by updating the static set of `UPGRADEABLE_PLATFORM_MODULES` to include the indirect modules that require the upgradable modules. How these additional modules were derived is explained as a separate comment in this PR.
>> 
>> The build succeeds with this change, both with `--with-jobs=1` and without the `--with-jobs` option (in which case on my setup it uses 8 jobs).
>> 
>> I have triggered tier testing in the CI to make sure this doesn't cause any unexpected regressions.
>> 
>> This change will require reviews from both the build team as well as the Java modules team - my knowledge of these areas is limited and I'm unsure if there are any additional considerations to take into...
>
>> It also opens the door to accidental mix 'n match of modules from different JDK modules. So I don't think this the right change for this issue.
> 
> Thank you Alan for that input. I'll close this PR then. I think in the PR that introduced the original change, there was a mention that the change isn't too helpful for the build but is mostly a good to have:
> 
>> Fixing this won't impact the build much, but certainly won't hurt either.
> 
> So for now I suspect we could revert that change since it currently does adversely impact the build.

@jaikiran I would concur - back out the change that caused the problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15102#issuecomment-1661514395

From amitkumar at openjdk.org  Wed Aug  2 06:45:53 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 2 Aug 2023 06:45:53 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <XEXOHZdjoQoCXitVeXIB06u99fCl-1eN7tNGdnpAHVc=.b185f379-564c-45bc-b58a-4eae8832cc23@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
 <XEXOHZdjoQoCXitVeXIB06u99fCl-1eN7tNGdnpAHVc=.b185f379-564c-45bc-b58a-4eae8832cc23@github.com>
Message-ID: <_oHcy74my4Zx6CFVDqlKfp9C0tcpNnrsi09EE9GZ9kM=.19c654f8-f5f5-4f2b-9743-8dab0411ec08@github.com>

On Mon, 31 Jul 2023 18:13:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>Please change the bug priority to P2; that is needed to be considered.

> Add a comment as described headlined with "Fix Request" and the described rationale and information.

Added comment and set priority to P2. This is low risk code change, So would you please review it Or ping someone who can review it ?

Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1661590642

From jpai at openjdk.org  Wed Aug  2 06:58:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Aug 2023 06:58:58 GMT
Subject: RFR: 8313274: Failure building java.base-jmod target
In-Reply-To: <w6r1EZEPM5AQLUhXHEKP2LrUhKXNx1zUs3i4oRcIxic=.6f05e47c-5e7c-4197-ae9e-20f1577505cf@github.com>
References: <_FoIsLXrXhMMqiOmX9fVEdMn-2EW2hCEFbngWTfa9xY=.2a3a45a7-3803-4387-b76f-ae399aa8f69c@github.com>
 <5OpVY0eAtv4ik4GX7Q-WNrMpN-050dEnva_V9Sw6CXk=.7f68f6f0-3553-4797-a1ef-c364b2c2ddf8@github.com>
 <VZKRaNSD2GrqwDdtx5mltMixOslqAg3jnU6wW7eT79M=.ab0e7075-3830-4e25-bc81-6ed8f4b5ce51@github.com>
 <w6r1EZEPM5AQLUhXHEKP2LrUhKXNx1zUs3i4oRcIxic=.6f05e47c-5e7c-4197-ae9e-20f1577505cf@github.com>
Message-ID: <177YtzIvr-vcCRvbvoipFLhm2OUk1wkNJS6QSQVZsmc=.1de5647d-ffc9-4351-8b12-00d31fb78020@github.com>

On Wed, 2 Aug 2023 05:24:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @jaikiran I would concur - back out the change that caused the problem.

Hello David, I have now opened a PR to revert that change https://github.com/openjdk/jdk/pull/15118

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15102#issuecomment-1661607103

From mbaesken at openjdk.org  Wed Aug  2 07:18:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 2 Aug 2023 07:18:58 GMT
Subject: [jdk21] RFR: 8311822: AIX : test/jdk/java/foreign/TestLayouts.java
 fails because of different output - expected [[i4](struct)] but found
 [[I4](struct)]
In-Reply-To: <9Iij8Jc0pCJjBh5gufESH2b8GpkLWH3NotFYaLdLvJk=.4a4a2bfe-3681-4134-8ce7-adee0f794714@github.com>
References: <9Iij8Jc0pCJjBh5gufESH2b8GpkLWH3NotFYaLdLvJk=.4a4a2bfe-3681-4134-8ce7-adee0f794714@github.com>
Message-ID: <X1MUwYcyQaon2vHErRuBGEaP9sEEPT0RX4sYKwS96tM=.6464bf21-aa89-4e8f-b29a-6fe567641dd3@github.com>

On Tue, 1 Aug 2023 21:57:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit [d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851edd4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 24 Jul 2023 and was reviewed by Jorn Vernee.
> 
> 
> Test fix, so qualifying for jdk21 under RDP2 rules.
> 
> Thanks!

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/157#pullrequestreview-1558355190

From duke at openjdk.org  Wed Aug  2 09:05:56 2023
From: duke at openjdk.org (dan1st)
Date: Wed, 2 Aug 2023 09:05:56 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
In-Reply-To: <hLcXeITOhEvzQQVy_KjZSay2oq4EzL8ZyNOB4uLuS8U=.1eb99aa7-f93f-4a72-be6c-2c4ae1584365@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <hLcXeITOhEvzQQVy_KjZSay2oq4EzL8ZyNOB4uLuS8U=.1eb99aa7-f93f-4a72-be6c-2c4ae1584365@github.com>
Message-ID: <H4GOhzIleW-M6h6GxAHYjNXzmjbtx4oh-goKYak27zc=.6965bfc1-5df7-41f3-beeb-f66789508dae@github.com>

On Wed, 26 Jul 2023 23:01:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add addFirst(), removeFirst() and reversed() methods to lists.
>> However, the Javadoc of List mentions:
>>  > The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
>> 
>> This PR updates that Javadoc to factor in the new methods introduced by JEP 431.
>> 
>> https://bugs.openjdk.org/browse/JDK-8311517
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
>> 
>> This PR only affects documentation.
>
> Yes, that's correct. I'll create a CSR for this when the change settles down.

@stuart-marks Can you please create the CSR request as mentioned above or are there further changes I should do?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1661820508

From mcimadamore at openjdk.org  Wed Aug  2 10:42:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 2 Aug 2023 10:42:50 GMT
Subject: [jdk21] RFR: 8313023: Return value corrupted when using CCS +
 isTrivial (mainline)
In-Reply-To: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>
References: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>
Message-ID: <hix4Y9ZHv_4VSF2CxiQlFnCFrUb29tZ_P6V2Bu3lXZo=.71539e10-bd37-465a-84db-6eb4a3fa08b7@github.com>

On Mon, 31 Jul 2023 08:13:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [6fca2898](https://github.com/openjdk/jdk/commit/6fca28988794b52a6aa974bed1ed6f4f07e0994b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 31 Jul 2023 and was reviewed by Maurizio Cimadamore and Vladimir Ivanov.
> 
> Thanks!

Looks good (already approved in jdk22 and panama repo)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/150#pullrequestreview-1558722084

From alanb at openjdk.org  Wed Aug  2 10:43:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Aug 2023 10:43:49 GMT
Subject: Integrated: 8311989: Test java/lang/Thread/virtual/Reflection.java
 timed out
In-Reply-To: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>
References: <d9lk2VG2kmsjDzSqc5AGPemSjpTF5uorW9NUNe9qCXo=.d607f40f-6e31-4b36-994c-21e7f26c7ad8@github.com>
Message-ID: <eMDIwnkNa7hNLkyZCCqTHATKvHBUtv7Ivoa3LL2mPZ0=.94ce6ee8-11ef-4690-b4fb-b66d6e6d40f8@github.com>

On Fri, 28 Jul 2023 15:44:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to a test that exercises core reflection from virtual threads. One of the tests (testNewInstance6) uses a custom scheduler in setup to check that calling a constructor reflectively, where the constructor parks, doesn't pin the underlying carrier. The test schedules an unpark from a virtual thread but the test is missing a call to Thread::join, thus creating a race between shutdown of the scheduler and the unpark. Two sightings of the test failing so far, both -Xcomp and ZGC.
> 
> While in the area, two usages of Thread.sleep in the test have been replaced with latches.

This pull request has now been integrated.

Changeset: 6faf05c6
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6faf05c6ddb3a0bcf4dce9516b8fca15d25cd80f
Stats:     20 lines in 1 file changed: 15 ins; 0 del; 5 mod

8311989: Test java/lang/Thread/virtual/Reflection.java timed out

Reviewed-by: jpai, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/15073

From jvernee at openjdk.org  Wed Aug  2 11:02:00 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Aug 2023 11:02:00 GMT
Subject: [jdk21] Integrated: 8313023: Return value corrupted when using CCS +
 isTrivial (mainline)
In-Reply-To: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>
References: <dkqtEtTUgG8zHoU3EJYBpV09trLBjRen2fHiKfRcMas=.04ac1c72-1e83-44b7-8e75-b460acd6eb39@github.com>
Message-ID: <TDNhS3dlewzXokcVfM4d_cJKZtMc4GtzdUQWJA0Gje8=.b7f69f27-031a-4a74-9750-4bd66c92c299@github.com>

On Mon, 31 Jul 2023 08:13:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [6fca2898](https://github.com/openjdk/jdk/commit/6fca28988794b52a6aa974bed1ed6f4f07e0994b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Jorn Vernee on 31 Jul 2023 and was reviewed by Maurizio Cimadamore and Vladimir Ivanov.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 20ca0465
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/20ca0465b59b601d669ff17f19eec5df782f1d27
Stats:     39 lines in 5 files changed: 12 ins; 0 del; 27 mod

8313023: Return value corrupted when using CCS + isTrivial (mainline)

Reviewed-by: thartmann, mcimadamore
Backport-of: 6fca28988794b52a6aa974bed1ed6f4f07e0994b

-------------

PR: https://git.openjdk.org/jdk21/pull/150

From yzheng at openjdk.org  Wed Aug  2 11:05:12 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Aug 2023 11:05:12 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
In-Reply-To: <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
Message-ID: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com>

On Wed, 21 Oct 2020 23:42:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
>> 
>> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
>> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
>> 
>> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
>> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
>> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
>> 
>> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
>> Patch passed jtreg tier1-3 tests with QEMU system emulator.
>> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression.
>> 
>> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
>> We measured the performance benefit with an aarch64 cycle-accurate simulator.
>> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
>> 
>> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected.
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473:

> 3471:     __ bcax(v24, __ T16B, v24, v8,  v31);
> 3472: 
> 3473:     __ ld1r(v31, __ T2D, __ post(rscratch1, 8));

is it intentional to load 16 bytes and post-increment by 8?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281749663

From duke at openjdk.org  Wed Aug  2 12:37:13 2023
From: duke at openjdk.org (Ferenc Rakoczi)
Date: Wed, 2 Aug 2023 12:37:13 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
In-Reply-To: <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
 <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com>
Message-ID: <kpcUwbvzUXBxFJowtv0Gg681Fm4oXVx1D20KXTVHphM=.98729cea-8116-442f-8e6f-697e95c634a7@github.com>

On Wed, 2 Aug 2023 11:02:07 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473:
> 
>> 3471:     __ bcax(v24, __ T16B, v24, v8,  v31);
>> 3472: 
>> 3473:     __ ld1r(v31, __ T2D, __ post(rscratch1, 8));
> 
> is it intentional to load 16 bytes and post-increment by 8?

Actually, with the ld1r instruction the post increment should be the same as the size of the memory accessed. So T2D requires 8 as it reads 8 bytes(and duplicates it into both halves of the SIMD register).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281840355

From ysuenaga at openjdk.org  Wed Aug  2 12:38:51 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 2 Aug 2023 12:38:51 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <SKjWOpsfZIJPsTc8vyFL3kxAYzSQqL8W1hYv6En5BjU=.c18b7042-a07e-461b-8b09-6be7ae7a739f@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
 <SKjWOpsfZIJPsTc8vyFL3kxAYzSQqL8W1hYv6En5BjU=.c18b7042-a07e-461b-8b09-6be7ae7a739f@github.com>
Message-ID: <lCcvxxGjJxyyeDto-3S0f5ICUmvcW9XD_1wfWMVOgCk=.65b1183e-4249-4c4a-aa54-999627a39ff1@github.com>

On Wed, 2 Aug 2023 02:12:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
>> 
>> 
>> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
>> --------------------------------------------------------------------------------
>>   0x00007fcae394cd80: pushq %rbp
>>   0x00007fcae394cd81: movq %rsp, %rbp
>>   0x00007fcae394cd84: subq $0, %rsp
>>  ;; { argument shuffle
>>   0x00007fcae394cd88: movq %r8, %rax
>>   0x00007fcae394cd8b: movq %rsi, %r10
>>   0x00007fcae394cd8e: movq %rcx, %rsi
>>   0x00007fcae394cd91: movq %rdx, %rdi
>>  ;; } argument shuffle
>>   0x00007fcae394cd94: callq *%r10
>>   0x00007fcae394cd97: leave
>>   0x00007fcae394cd98: retq
>> 
>> 
>> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
>> 
>> 
>> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
>> --------------------------------------------------------------------------------
>>   0x00007fd8778e2880: pushq %rbp
>>   0x00007fd8778e2881: movq %rsp, %rbp
>>  ;; { argument shuffle
>>   0x00007fd8778e2884: movq %rsi, %r10
>>   0x00007fd8778e2887: movq %rcx, %rsi
>>   0x00007fd8778e288a: movq %rdx, %rdi
>>  ;; } argument shuffle
>>   0x00007fd8778e288d: callq *%r10
>>   0x00007fd8778e2890: leave
>>   0x00007fd8778e2891: retq
>> 
>> 
>> All java/foreign jtreg tests are passed.
>> 
>> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
>> 
>> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
>> 
>> before:
>> 
>> Benchmark                           Mode  Cnt          Score          Error  Units
>> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
>> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
>> 
>> 
>> after:
>> 
>> Benchmark                           Mode  Cnt          Score          Error  Units
>> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
>> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
>> 
>> 
>> Environment:
>> * CPU: AMD Ry...
>
> FWIW, if you want to look into reducing the generated code further, I think we can potentially reduce the amount of shuffling between registers that's needed by reordering the arguments on the Java side so that each VMStorage corresponding to an argument of the leaf method handle is the same as the register for that argument in the Java calling convention.
> 
> I think the right place to do this is in DowncallLinker where we are creating the NativeEntryPoint. The way I think it should work: 
> 1. compute the Java calling convention's argument registers for the leaf method type.
> 2. compute a re-ordered VMStorage[] for the arguments, and a re-ordered method type, such that the VMStorage/type for a particular argument index matches the register for the same index used in the Java calling convention as much as possible.
> 3. use the re-ordered VMStorage[] + MethodType to create the native entry point + native method handle
> 4. apply the same reordering in reverse to the arguments of the created native method handle (using MethodHandles::permuteArguments) so that the resulting method handle has the original argument order/method type.
> 
> Pushing this shuffling to the Java side will allow the JIT to reduce data motion, and this should result in reduced shuffling being needed overall I think.

@JornVernee Thanks for your review! I will integrate this when I get second reviewer.

> I think we can potentially reduce the amount of shuffling between registers that's needed by reordering the arguments on the Java side so that each VMStorage corresponding to an argument of the leaf method handle is the same as the register for that argument in the Java calling convention.

It would be great! I guess you suggested that `ArgumentShuffle` in HotSpot moves into `DowncallLinker`, right? To be honest, I haven't yet understood well about this, and also I do not have other testbed excepting Linux x64. So it is difficult to work for this now.

Again, this idea is great. I'd like to call native function via FFM with less overhead. So I'm happy to help if I can.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1662132113

From yzheng at openjdk.org  Wed Aug  2 14:10:13 2023
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 2 Aug 2023 14:10:13 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
In-Reply-To: <kpcUwbvzUXBxFJowtv0Gg681Fm4oXVx1D20KXTVHphM=.98729cea-8116-442f-8e6f-697e95c634a7@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
 <_xhY05iLfIuABX0G_7UkyrAz6iCnJzZPzWNe09_ryjI=.372ae759-fc49-496d-b1c1-c10ad065987b@github.com>
 <kpcUwbvzUXBxFJowtv0Gg681Fm4oXVx1D20KXTVHphM=.98729cea-8116-442f-8e6f-697e95c634a7@github.com>
Message-ID: <qWnaYqMXG3knnqyHWKjxsfTlu5mgmJmO_rrwpXuDtW0=.a2a80003-65af-4f75-be55-ee1ad48dcd1a@github.com>

On Wed, 2 Aug 2023 12:33:43 GMT, Ferenc Rakoczi <duke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 3473:
>> 
>>> 3471:     __ bcax(v24, __ T16B, v24, v8,  v31);
>>> 3472: 
>>> 3473:     __ ld1r(v31, __ T2D, __ post(rscratch1, 8));
>> 
>> is it intentional to load 16 bytes and post-increment by 8?
>
> Actually, with the ld1r instruction the post increment should be the same as the size of the memory accessed. So T2D requires 8 as it reads 8 bytes(and duplicates it into both halves of the SIMD register).

Thanks for the clarification!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/207#discussion_r1281961206

From jvernee at openjdk.org  Wed Aug  2 14:23:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 2 Aug 2023 14:23:56 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <lCcvxxGjJxyyeDto-3S0f5ICUmvcW9XD_1wfWMVOgCk=.65b1183e-4249-4c4a-aa54-999627a39ff1@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
 <SKjWOpsfZIJPsTc8vyFL3kxAYzSQqL8W1hYv6En5BjU=.c18b7042-a07e-461b-8b09-6be7ae7a739f@github.com>
 <lCcvxxGjJxyyeDto-3S0f5ICUmvcW9XD_1wfWMVOgCk=.65b1183e-4249-4c4a-aa54-999627a39ff1@github.com>
Message-ID: <SKanNJXXQFiwz_gEmmJmT2yqOuR11YJeZ91OaV-9LY4=.66d6bb4e-dcd5-4b30-954b-e38e91e7c291@github.com>

On Wed, 2 Aug 2023 12:35:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I guess you suggested that ArgumentShuffle in HotSpot moves into DowncallLinker, right?

No, ArgumentShuffle should stay inside HotSpot. We can not do all the shuffling on the Java side. We can only eliminate some of the register moves that are needed by re-ordering the arguments on the Java side.

For instance, if you look at the comment in `assembler_x86.hpp`, where we define `j_rarg*` Register constants, you'll see this:


//        |-------------------------------------------------------|
//        | c_rarg0   c_rarg1  c_rarg2 c_rarg3 c_rarg4 c_rarg5    |
//        |-------------------------------------------------------|
//        | rcx       rdx      r8      r9      rdi*    rsi*       | windows (* not a c_rarg)
//        | rdi       rsi      rdx     rcx     r8      r9         | solaris/linux
//        |-------------------------------------------------------|
//        | j_rarg5   j_rarg0  j_rarg1 j_rarg2 j_rarg3 j_rarg4    |
//        |-------------------------------------------------------|


i.e. all the registers in the Java calling convention are 'off by one' compared to the native calling convention. This makes sense for JNI since we need to prepend the JNIEnv* to the start of the argument list, but it doesn't make sense for Panama.

Let's say we have a native function taking five `long`s. On Linux/x64 the VMStorage[] for the arguments (the one we use when creating the NativeEntryPoint inside DowncallLinker) would be:

    [rdi, rsi, rdx, rcx, r8, r9]

i.e. the first argument we pass on the Java side gets moved (by the downcall stub) into `rdi`, the second into `rsi`, etc. This doesn't match the incoming registers of the Java calling convention, where the first argument is passed passing in `rsi`, the second is passed in `rdx`, etc. (i.e. off-by-one).

We can simply re-arrange the entries in the `VMStorage[]` to match the order of registers in the Java calling convention:

    [rsi, rdx, rcx, r8, r9, rdi]
    
i.e. the argument that should go into `rdi` is passed in the fifth position instead. Since now the registers for each argument match the Java calling convention, the downcall stub doesn't need to do any shuffling! (I'm being very hand-wavey here. Figuring out how to correctly do the re-ordering is the hard part of this).

Ok, but now the arguments we pass to the downcall stub are going to go in the wrong registers as well :( So, to compensate for that, we have to also re-order the incoming argument values on the Java side so that each argument will correspond to it's original register again. To do that, we just need to pass the first argument in the fifth position as well, and shift arguments 1-4 forward by one spot.

Make sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1662302891

From rriggs at openjdk.org  Wed Aug  2 15:34:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Aug 2023 15:34:44 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <c0PQjZV46p2HH9w8tVN2Hux-4uB8RWPLawvcXkcSDqk=.2466e008-f29e-408d-bf5c-8f03d8d3ce1d@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

The changes in jdk.internal.util classes look ok.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15070#pullrequestreview-1559281414

From rriggs at openjdk.org  Wed Aug  2 15:39:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Aug 2023 15:39:49 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <Q1aLmRqWGb7rSWmctWK_8zE-_KOp9kBmlHx2IRjUHVI=.d36e8f69-7da1-4285-a404-64e803cf38ce@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

/Reviewers 2

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1662435901

From asotona at openjdk.org  Wed Aug  2 15:53:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 2 Aug 2023 15:53:52 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <qgqgDKlLAUL-88aqmuMxISORxjYnv6q3rfKryKz_7fY=.777c9fc9-7073-409d-b7ed-e2866b5cc561@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

Marked as reviewed by asotona (Reviewer).

The Classfile API part looks fine, thanks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15070#pullrequestreview-1559316760
PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1662470466

From rriggs at openjdk.org  Wed Aug  2 15:59:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Aug 2023 15:59:49 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <N479m0EpSWd4giKyi2dehPzcSJGI4ywU_YXaWwXcgQ0=.f9a4a60c-8441-4b30-937c-6e0f04dfc208@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

Marked as reviewed by rriggs (Reviewer).

These changes are fine to go into the mainline.  When the fix request is approved; they can be backported to JDK 21.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15070#pullrequestreview-1559328130
PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1662478927

From iklam at openjdk.org  Wed Aug  2 16:03:50 2023
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 2 Aug 2023 16:03:50 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v4]
In-Reply-To: <92hduxZ6vbxgkiYkbGWtKw9E_EezThT-5VeVo9vFACg=.ecdddcbc-5a0d-4fec-bdcb-44252a35957f@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <JNmxvM9LYO3qt1Eccce9fX3f2_9s7FzDEGNZHlaVQ88=.05986efe-f203-4b64-bb33-7f4db762773b@github.com>
 <V7nmCQZlthPSc2XaYBeNbJKteBcmotWQeXmQ0HUjDNI=.e003b59a-f536-4f51-9d78-a5bb7bd8cad3@github.com>
 <JrV73ojqGgNcU9a6MiX5S1gSFjsTjI3o5Gb0c_1S7tE=.0cf3f3f1-c58a-4348-a76a-df167a305307@github.com>
 <92hduxZ6vbxgkiYkbGWtKw9E_EezThT-5VeVo9vFACg=.ecdddcbc-5a0d-4fec-bdcb-44252a35957f@github.com>
Message-ID: <Q1fW8I2aSZvbEvXSPMFE1CWoNZw9xO4ajPl-2JV5hLs=.1a3f701d-7844-4e18-ac16-7f5b7cdc4db9@github.com>

On Wed, 2 Aug 2023 04:01:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes it should! Thank you for catching this.
>
> This suggests we don't have test coverage for this case.

If we want to add a test case, I would suggest adding a WhiteBox method like:


public native Object[] getResolvedReferences(Class<?> c);


This would return the `resolved_references` array for this class.

The test class would look like this:


class TestApp {
    static String foo = "fooString";
    static String bar = "barString";

    public void main(String args[]) {
        Object[] resolvedReferences = wb.getResolvedReferences(TestApp.class);

        ... resolvedReferences must be non null for classes in the static archive
        ... the test needs to have @requires vm.cds.write.archived.java.heap

        bool foundFoo = false;
        bool foundBar = false;
        for (Object o : resolvedReferences) {
            foundFoo |= (o == foo);
            foundBar |= (o == bar);
        }

        ... foo and bar must have been found
        ... CDS resolves all of the string literals used by the TestApp and stores
        ... them inside the resolvedReferences array.
}


The new test can live under test/hotspot/jtreg/runtime/cds/appcds/sharedStrings

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14879#discussion_r1282115165

From jlu at openjdk.org  Wed Aug  2 17:11:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Aug 2023 17:11:07 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
Message-ID: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>

Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This change is required to keep the localized translations up to date with the English source resource files.

-------------

Commit messages:
 - Backport 9b55e9a706de9893b1a71c7a6a4e23c4b8842f18

Changes: https://git.openjdk.org/jdk21/pull/160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312572
  Stats: 223 lines in 32 files changed: 36 ins; 15 del; 172 mod
  Patch: https://git.openjdk.org/jdk21/pull/160.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/160/head:pull/160

PR: https://git.openjdk.org/jdk21/pull/160

From matsaave at openjdk.org  Wed Aug  2 17:14:01 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Aug 2023 17:14:01 GMT
Subject: RFR: 8306582: Remove MetaspaceShared::exit_after_static_dump()
 [v3]
In-Reply-To: <Uiisv3lkGh_SjPcTWzkagSLARIjBpZ4tjweNOBL_hWk=.3d87a2d3-fc6a-4128-b299-6201573a1394@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
 <ICAzw_PZum9JfcJ5yHmCjYhr_pDG_gS-XITGKHQLI1E=.a9aa5900-39c5-413b-8187-63cea2731fdf@github.com>
 <Uiisv3lkGh_SjPcTWzkagSLARIjBpZ4tjweNOBL_hWk=.3d87a2d3-fc6a-4128-b299-6201573a1394@github.com>
Message-ID: <GdqPWqdCVvXJU42CuVMzirlDHpmQSmdK1cZoGeyH--0=.0f6a378c-803c-46c1-8ba8-ddbb36f80ed4@github.com>

On Thu, 27 Jul 2023 18:07:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactored KlassToOopHandleTable, Ioi and Alan comments
>
> Looks good. Just a couple of nits.

Thank you for the reviews @iklam, @calvinccheung, @dholmes-ora, and @AlanBateman!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14879#issuecomment-1662624259

From matsaave at openjdk.org  Wed Aug  2 17:14:02 2023
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 2 Aug 2023 17:14:02 GMT
Subject: Integrated: 8306582: Remove MetaspaceShared::exit_after_static_dump()
In-Reply-To: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
References: <nbB3JhovLqSHYyc9nFtbLoA-FS_fCFHQPTkde5w_v1c=.8dd5b791-16ab-4ade-8e0e-7baebf73f1bd@github.com>
Message-ID: <u5uGs7u6hbN5Ke4J0x_vwAXbFIVeeGh6_nG-SPPX1S8=.2cb1dcc8-b3ff-4746-a974-37e4a418fa66@github.com>

On Thu, 13 Jul 2023 21:25:17 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> Currently we exit the VM after static dumping with `MetaspaceShared::exit_after_static_dump()`. 
> 
> 
>  // We have finished dumping the static archive. At this point, there may be pending VM
>  // operations. We have changed some global states (such as vmClasses::_klasses) that
>  // may cause these VM operations to fail. For safety, forget these operations and
>  // exit the VM directly.
>  void MetaspaceShared::exit_after_static_dump() {
>    os::_exit(0);
>  } 
> 
> 
> As the comment suggests, the VM state is altered when preparing and performing the static dump, so this change aims to prevent these state changes so the VM can exit normally after the static dump completes. There are three major aspects to this change:
> 1. Since the resolved references array in the Constant Pool is altered when preparing for a static dump, a "scratch copy" is created and archived instead 
> 2. Symbols are sorted by address and have their hash recalculated. Similarly to point 1, the copies of the symbols that are to be archived have their hashes updated as opposed to the originals.
> 3. The handling of -Xshare:dump during argument parsing such that the VM can continue and exit normally with an exit code of 0.
> 
> Verified with tier 1-9 tests.

This pull request has now been integrated.

Changeset: cff25dd5
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cff25dd574203d0840d11ce083a5b825fb26d61d
Stats:     121 lines in 9 files changed: 77 ins; 27 del; 17 mod

8306582: Remove MetaspaceShared::exit_after_static_dump()

Reviewed-by: iklam, alanb, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/14879

From naoto at openjdk.org  Wed Aug  2 17:46:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Aug 2023 17:46:53 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <0qmatseGr9WvMxmSIZhofWEmd4usRDuDVJqqsKl2pI0=.56d1c812-a9ab-4b22-88cf-9183fca693ba@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/160#pullrequestreview-1559541428

From tprinzing at openjdk.org  Wed Aug  2 18:22:53 2023
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 2 Aug 2023 18:22:53 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

I believe this has all requested changes or has separate bug reports to address changes yet needing to be made.
https://bugs.openjdk.org/browse/JDK-8310979  - better exception handling
https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation
https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops

This request has been patiently waiting for approval for a long time!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1662726848

From iris at openjdk.org  Wed Aug  2 18:23:57 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 2 Aug 2023 18:23:57 GMT
Subject: [jdk21] RFR: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <O9s7CY1Q5EhtKtkkRGQVZWjNzLIBmk9Qh0k-4AS9BC0=.90c29ca1-8fdf-4501-846a-3c24a5b3cd83@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/160#pullrequestreview-1559601318

From alanb at openjdk.org  Wed Aug  2 20:12:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Aug 2023 20:12:51 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
Message-ID: <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>

On Wed, 2 Aug 2023 18:19:27 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> I believe this has all requested changes or has separate bug reports to address changes yet needing to be made. https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops
> 
> This request has been patiently waiting for approval for a long time!

I plan to come back to this soon, been busy with other things.  It's good to have JBS issues created for the next steps. I assume you can start to prepare the changes for the next steps so that all the pieces can go into the same release.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1662903292

From alanb at openjdk.org  Wed Aug  2 20:20:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Aug 2023 20:20:53 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match [v4]
In-Reply-To: <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
 <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>
Message-ID: <-pm6uSXgQmfGhfm-6hE_PHxlsTm0D7JSj6Mjx2ewj8Y=.9d7bfcfc-b0bc-44c5-a56b-982b5322bc43@github.com>

On Mon, 31 Jul 2023 18:38:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.
>
> Raffaello Giulietti 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 since the last revision:
> 
>  - Merged with mainline.
>  - Merge branch 'master' into 8312976
>  - Refactored recent tests as JUnit parametrized test.
>  - Added a test with negatvie lookbehind.
>  - Added test with a lookahead containing a back reference.
>  - 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match

This looks okay. I think its would be useful to get another reviewer to also look over this in case there is any other issues.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15053#pullrequestreview-1559778227

From egahlin at openjdk.org  Wed Aug  2 21:12:44 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 2 Aug 2023 21:12:44 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <IbeWAyReO6cvEgMinyffb6vRGkTlw73TotYrwulG7Nw=.11f9df4e-a3b7-4de5-b31d-12ad704a16dc@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

Looks good as far as I can tell. I would perhaps name the checkForCommit(...) method commitEvent(...) to make it more clear that it writes the event, but it's not a big thing.

-------------

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1559847776

From joehw at openjdk.org  Wed Aug  2 22:33:00 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 2 Aug 2023 22:33:00 GMT
Subject: RFR: 8311006: missing @since info in jdk.xml.dom
Message-ID: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>

Please review a patch that add `@since` tags following existing convention for XML APIs in java.xml and jdk.xml.dom modules.

-------------

Commit messages:
 - 8311006: missing @since info in jdk.xml.dom

Changes: https://git.openjdk.org/jdk/pull/15129/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311006
  Stats: 12 lines in 6 files changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15129/head:pull/15129

PR: https://git.openjdk.org/jdk/pull/15129

From bpb at openjdk.org  Wed Aug  2 22:51:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Aug 2023 22:51:36 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <5k4VFVI74A2cbypxW01WHS1-jRPs0LCCmnT8sfQEomM=.1f19c199-0531-46f4-9b44-3ddccb053d69@github.com>
References: <DUj8_VN1IxFoiWA2mczjyVjlQ4YsbWKXOCB-EhNTGJw=.878bd08c-060b-4cd9-af79-8e1977516125@github.com>
 <c3ma_hgY3P7iCJwEVzVvrFKXBykVZnZQwnuKMva_LCY=.dd5cbce8-b761-4de8-a49e-ccf42874f22e@github.com>
 <5k4VFVI74A2cbypxW01WHS1-jRPs0LCCmnT8sfQEomM=.1f19c199-0531-46f4-9b44-3ddccb053d69@github.com>
Message-ID: <6KOz3IGCWd19RLyu521tmQ-W7yf1i_ReEI6hpmCzCDw=.ff8b20e5-a602-44fc-bde3-713f41428556@github.com>

On Sun, 30 Jul 2023 13:06:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6478546: Move buffer clamping up to Java layer; correct read behavior to match legacy
>
> src/java.base/share/classes/java/io/FileOutputStream.java line 347:
> 
>> 345:                 pos += n;
>> 346:                 remaining -= n;
>> 347:             } while (remaining > 0);
> 
> Long standing behavior is that write is a no-op with len is 0, meaning you can do while here (no need to change it to do-while). Same thing in RAF.

So changed in cdb8455ccbd1db49d272e867b16a14eb72b41a7b.

> src/java.base/share/native/libjava/io_util.c line 160:
> 
>> 158:     }
>> 159: 
>> 160:     if (outOfBounds(env, off, len, bytes)) {
> 
> I assume the IS_NULL and outOfBounds checking in both readBytes and writeBytes are redundant now.

Right. Removed in cdb8455ccbd1db49d272e867b16a14eb72b41a7b.

> src/java.base/share/native/libjava/io_util.c line 183:
> 
>> 181:         if (fd == -1) {
>> 182:             JNU_ThrowIOException(env, "Stream Closed");
>> 183:             nwritten = -1;
> 
> nwritten is initialized to -1.

Removed in cdb8455ccbd1db49d272e867b16a14eb72b41a7b.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1279618127
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1279617787
PR Review Comment: https://git.openjdk.org/jdk/pull/14981#discussion_r1279618406

From smarks at openjdk.org  Wed Aug  2 23:24:33 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 2 Aug 2023 23:24:33 GMT
Subject: RFR: 8159527: Collections mutator methods should all be marked as
 optional operations
Message-ID: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>

Adjust the leading javadoc sentence of several collections mutator methods to include "(optional operation)" as appropriate. Also adjust doc for UnsupportedOperationException on those methods as necessary.

-------------

Commit messages:
 - Adjust wording of various UnsupportedOperationException docs.
 - Note (optional operation) and UOE in appropriate places.

Changes: https://git.openjdk.org/jdk/pull/15127/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8159527
  Stats: 70 lines in 5 files changed: 17 ins; 8 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/15127.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15127/head:pull/15127

PR: https://git.openjdk.org/jdk/pull/15127

From naoto at openjdk.org  Wed Aug  2 23:29:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Aug 2023 23:29:52 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns
Message-ID: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>

Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15130/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8041488
  Stats: 679 lines in 6 files changed: 671 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From jlu at openjdk.org  Wed Aug  2 23:32:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 2 Aug 2023 23:32:23 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case [v3]
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <IkW3sSRT6fCf92zlgj-WcIZwZGHk69hQCDMZNw70940=.6165f14b-ceb2-4df8-8e21-5463b6b6bef4@github.com>

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and input decimal String.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when input decimal String values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Refactor underflowToZero

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14110/files
  - new: https://git.openjdk.org/jdk/pull/14110/files/a8e1a81b..ed889741

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14110&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14110&range=01-02

  Stats: 39 lines in 1 file changed: 2 ins; 22 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/14110.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14110/head:pull/14110

PR: https://git.openjdk.org/jdk/pull/14110

From naoto at openjdk.org  Wed Aug  2 23:40:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 2 Aug 2023 23:40:31 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v2]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <IDIH53zHiRcvktSFv7a-q-tWkTqWoR36HUeK2s5Zg_A=.1c0d7e00-03bb-4e1a-842f-966791d15da1@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/7340a0f7..8e7181f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=00-01

  Stats: 207 lines in 1 file changed: 207 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From iris at openjdk.org  Thu Aug  3 00:04:53 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 3 Aug 2023 00:04:53 GMT
Subject: RFR: 8311006: missing @since info in jdk.xml.dom
In-Reply-To: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
References: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
Message-ID: <OFWmDcgWgwCgR7sZ6SabW4bGG4KuqbWllkJKgzXg4Ow=.7402f038-ccf7-483d-a2b5-e4f1a7586b17@github.com>

On Wed, 2 Aug 2023 22:26:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that add `@since` tags following existing convention for XML APIs in java.xml and jdk.xml.dom modules.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15129#pullrequestreview-1559985912

From ysuenaga at openjdk.org  Thu Aug  3 04:10:29 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 3 Aug 2023 04:10:29 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <q_FsRRUvFS-xgfUMMObKiC8CJCOArytG-Z2WXeY0a8c=.b2b590cb-41ba-4a2a-a53b-ed9736791d52@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

Ideally it is the best if we eliminate all of the shuffling completely, but it is impossible I think. We have to use `MethodHandles::permuteArguments` to apply reordering to `NativeMethodHandle` as you said, then shuffling would remain somewhare even if we could eliminate them from NEP stub.

Thus this topic would be lower priority if my guessing is correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1663260805

From jvernee at openjdk.org  Thu Aug  3 05:12:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 3 Aug 2023 05:12:29 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <q_FsRRUvFS-xgfUMMObKiC8CJCOArytG-Z2WXeY0a8c=.b2b590cb-41ba-4a2a-a53b-ed9736791d52@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
 <q_FsRRUvFS-xgfUMMObKiC8CJCOArytG-Z2WXeY0a8c=.b2b590cb-41ba-4a2a-a53b-ed9736791d52@github.com>
Message-ID: <6T79GckPQ7lIgiaw0wYNjhLWMnI0NyAQJysLBOT4yX0=.c97c8155-de39-440a-9ae7-7ca706fd4830@github.com>

On Thu, 3 Aug 2023 04:07:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> then shuffling would remain somewhare even if we could eliminate them from NEP stub.

Since things on the Java side are visible to the JIT, it should be able to avoid the extra data motion.

> Thus this topic would be lower priority if my guessing is correct.

Yes, it is lower priority. It's relatively complex to solve, and also CPUs, in my experience, don't generally care that much about the shuffling. They probably just change their internal register allocation table instead of doing the actual moves.

Also, it will ultimately help more to implement C2 intrinsics for native calls, as that avoids going through the downcall stub altogether. I have an old POC for that which I will dust off.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1663298793

From amitkumar at openjdk.org  Thu Aug  3 05:49:38 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 3 Aug 2023 05:49:38 GMT
Subject: RFR: 8313312: Add missing classpath exception copyright header
 [v2]
In-Reply-To: <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
 <cwVvcKK4X92FDntRJg9Iv3NuPvUAaybTDLrp6G1L6To=.0f1c62ab-b8cc-4df2-8157-4445fb1aa49c@github.com>
Message-ID: <xXt0iNdPB_urJYX4e7j8sqrHX44StWjqARcbxMxo3VE=.d974f912-8936-4f99-aa0c-2e10eaebc118@github.com>

On Fri, 28 Jul 2023 17:39:18 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Adds `classpath exception` in multiple files, affects copyright header only.
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert java.lang.foreign changes

Thanks for the reviews!!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15070#issuecomment-1663327067

From amitkumar at openjdk.org  Thu Aug  3 05:49:39 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 3 Aug 2023 05:49:39 GMT
Subject: Integrated: 8313312: Add missing classpath exception copyright header
In-Reply-To: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
References: <9ZKXDEMzNF_XPzgzsXYskRSuM4pLj1zBVQUU8YONVqE=.e14017a2-cd82-4abd-8b72-d096a3fce69f@github.com>
Message-ID: <J0q31UzV90tpPqn1VNNP-PaK9UIGAGemS2wvaLAqUoY=.77384644-40d3-4c66-9b53-b79cfd375efb@github.com>

On Fri, 28 Jul 2023 13:02:20 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Adds `classpath exception` in multiple files, affects copyright header only.

This pull request has now been integrated.

Changeset: 53ca75b1
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53ca75b18ea419d469758475fac8352bf915b484
Stats:     48 lines in 16 files changed: 32 ins; 0 del; 16 mod

8313312: Add missing classpath exception copyright header

Reviewed-by: rriggs, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/15070

From clanger at openjdk.org  Thu Aug  3 07:42:42 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 3 Aug 2023 07:42:42 GMT
Subject: [jdk21] Integrated: 8311822: AIX :
 test/jdk/java/foreign/TestLayouts.java fails because of different output -
 expected [[i4](struct)] but found [[I4](struct)]
In-Reply-To: <9Iij8Jc0pCJjBh5gufESH2b8GpkLWH3NotFYaLdLvJk=.4a4a2bfe-3681-4134-8ce7-adee0f794714@github.com>
References: <9Iij8Jc0pCJjBh5gufESH2b8GpkLWH3NotFYaLdLvJk=.4a4a2bfe-3681-4134-8ce7-adee0f794714@github.com>
Message-ID: <fx4oVZHpJNrL37njQ9-WrcghKSw75X_HfyOuqo-P9Jc=.342c021d-a053-4c2d-9de3-73b4c25a7589@github.com>

On Tue, 1 Aug 2023 21:57:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit [d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851edd4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Per Minborg on 24 Jul 2023 and was reviewed by Jorn Vernee.
> 
> 
> Test fix, so qualifying for jdk21 under RDP2 rules.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 610812d4
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/610812d4743d9ef9f6e92f7f2eea179fbdf81387
Stats:     7 lines in 1 file changed: 3 ins; 0 del; 4 mod

8311822: AIX : test/jdk/java/foreign/TestLayouts.java fails because of different output - expected [[i4](struct)] but found [[I4](struct)]

Reviewed-by: mbaesken
Backport-of: d1cc2782606e8a3cfead9055aa845e48e851edd4

-------------

PR: https://git.openjdk.org/jdk21/pull/157

From rgiulietti at openjdk.org  Thu Aug  3 12:37:35 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 3 Aug 2023 12:37:35 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v4]
In-Reply-To: <-4FNO-SDSVY6y13UHp8ws0rMPmfU7I4U_lGwUSZ_Qs0=.bef74326-cd0a-4f2c-a41a-6fa84b1dc0fb@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <-4FNO-SDSVY6y13UHp8ws0rMPmfU7I4U_lGwUSZ_Qs0=.bef74326-cd0a-4f2c-a41a-6fa84b1dc0fb@github.com>
Message-ID: <UV0coAExeBZRp8i4ZbEor3boTp-JtIioJZr_ysr_DNc=.6350d38d-566c-430d-9e9f-f8a9f920e519@github.com>

On Fri, 28 Jul 2023 12:15:21 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes and test for CIBackRef

The change looks good.
However, I'm not a Reviewer.

src/java.base/share/classes/java/util/regex/Pattern.java line 5192:

> 5190:             // reference to not existing group must never match
> 5191:             // group does not exist if matcher didn't allocate space for it
> 5192:             if (groupIndex + 1 > matcher.groups.length) {

Suggestion:

            if (groupIndex >= matcher.groups.length) {

src/java.base/share/classes/java/util/regex/Pattern.java line 5234:

> 5232:             // reference to not existing group must never match
> 5233:             // group does not exist if matcher didn't allocate space for it
> 5234:             if (groupIndex + 1 > matcher.groups.length) {

Suggestion:

            if (groupIndex >= matcher.groups.length) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/14894#pullrequestreview-1560992171
PR Review Comment: https://git.openjdk.org/jdk/pull/14894#discussion_r1283135433
PR Review Comment: https://git.openjdk.org/jdk/pull/14894#discussion_r1283135831

From duke at openjdk.org  Thu Aug  3 14:42:45 2023
From: duke at openjdk.org (Cristian Vat)
Date: Thu, 3 Aug 2023 14:42:45 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v5]
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <NNYVWvjz92L0gfFpu2gamLl_07vT3AWSsjycpzHjEZg=.9c354204-7ede-413d-9eac-41a2bf657cb1@github.com>

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:

  review condition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/b591b2ba..37b18e0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From naoto at openjdk.org  Thu Aug  3 16:05:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 3 Aug 2023 16:05:32 GMT
Subject: RFR: 8311006: missing @since info in jdk.xml.dom
In-Reply-To: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
References: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
Message-ID: <Iuf_5jn2CBK5zBQjt1CgvGeS3s14XI78SC89VWN8V8Y=.7b87df78-1f63-491e-b806-8bdb17d59c68@github.com>

On Wed, 2 Aug 2023 22:26:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that add `@since` tags following existing convention for XML APIs in java.xml and jdk.xml.dom modules.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15129#pullrequestreview-1561422707

From lancea at openjdk.org  Thu Aug  3 16:10:33 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 3 Aug 2023 16:10:33 GMT
Subject: RFR: 8311006: missing @since info in jdk.xml.dom
In-Reply-To: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
References: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
Message-ID: <epx3Ue4M2PWH-OtEU0RurT2xc4W_UDZpbeQ-BoFrx-w=.6a4b419b-46d2-43fe-ada4-36ce1cb9873f@github.com>

On Wed, 2 Aug 2023 22:26:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that add `@since` tags following existing convention for XML APIs in java.xml and jdk.xml.dom modules.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15129#pullrequestreview-1561431824

From jlu at openjdk.org  Thu Aug  3 16:38:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Aug 2023 16:38:36 GMT
Subject: RFR: 8313702: Update IANA Language Subtag Registry to Version
 2023-08-02
Message-ID: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>

Please review this PR which updates the IANA data from version 05-11-2023 to version [08-02-2023](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-August/000088.html).

The contents of the update added variant subtag ?blasl? to the language subtag registry.

-------------

Commit messages:
 - Support 08-02-23

Changes: https://git.openjdk.org/jdk/pull/15142/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313702
  Stats: 12 lines in 2 files changed: 9 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15142/head:pull/15142

PR: https://git.openjdk.org/jdk/pull/15142

From naoto at openjdk.org  Thu Aug  3 18:48:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 3 Aug 2023 18:48:30 GMT
Subject: RFR: 8313702: Update IANA Language Subtag Registry to Version
 2023-08-02
In-Reply-To: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>
References: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>
Message-ID: <LeuONUIT7d7maSBn9DGdbJVtQBxUS5fJ0aRdytL1y4k=.7ade07bd-deec-413e-8ce8-0e2fc163891f@github.com>

On Thu, 3 Aug 2023 16:31:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the IANA data from version 05-11-2023 to version [08-02-2023](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-August/000088.html).
> 
> The contents of the update added variant subtag ?blasl? to the language subtag registry.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15142#pullrequestreview-1561671988

From smarks at openjdk.org  Thu Aug  3 20:26:35 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 3 Aug 2023 20:26:35 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match [v4]
In-Reply-To: <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
 <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>
Message-ID: <sSiZBbvi1X3yGCrGwx-KefIr_JBoMBr_vbnFy1wFG1k=.5eede7d2-5eb2-4772-bf11-e5f37e4a74e8@github.com>

On Mon, 31 Jul 2023 18:38:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.
>
> Raffaello Giulietti 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 since the last revision:
> 
>  - Merged with mainline.
>  - Merge branch 'master' into 8312976
>  - Refactored recent tests as JUnit parametrized test.
>  - Added a test with negatvie lookbehind.
>  - Added test with a lookahead containing a back reference.
>  - 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match

Marked as reviewed by smarks (Reviewer).

OK, changes and tests look good. Who knew, a capturing group could have bounds outside the matched string!

I did notice something that we might want to look at in the future. `MatchResult` has `first` and `last` fields; these seem redundant with the `group[0]` and `group[1]` entries. Indeed, `Matcher` also has `first` and `last` and the `group[]` array; `start()` returns `first` and `end()` returns `last`; while `start(0)` returns `group[0]` and `end(0)` returns `group[1]`. But the javadocs say that `start()` and `start(0)` are equivalent and that `end()` and `end(0)` are also equivalent. So `Matcher` also appears to have this redundancy. Since these values are all set by the matching engine in `Pattern` it seems like the redundancy is spread throughout the code.

Conceptually it might be possible for `MatchResult` to omit `first` and `last` and just use the first two `group` array entries, but it's really hard to verify this. Unclear whether this is worthwhile (and it's certainly not worth trying to include in this  bugfix).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15053#pullrequestreview-1561805692
PR Comment: https://git.openjdk.org/jdk/pull/15053#issuecomment-1664600847

From iris at openjdk.org  Thu Aug  3 20:27:29 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 3 Aug 2023 20:27:29 GMT
Subject: RFR: 8313702: Update IANA Language Subtag Registry to Version
 2023-08-02
In-Reply-To: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>
References: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>
Message-ID: <cLRhfqfsYcqXpv3PXk2bJ6JEJPzUI3E_px00pLGNj0Q=.9c9f7ed4-948c-4fbc-bc5c-1d657c8a4be5@github.com>

On Thu, 3 Aug 2023 16:31:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the IANA data from version 05-11-2023 to version [08-02-2023](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-August/000088.html).
> 
> The contents of the update added variant subtag ?blasl? to the language subtag registry.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15142#pullrequestreview-1561806378

From jlu at openjdk.org  Thu Aug  3 20:52:41 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 3 Aug 2023 20:52:41 GMT
Subject: [jdk21] Integrated: 8312572: JDK 21 RDP2 L10n resource files update
In-Reply-To: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
References: <QoeSI73Ezz7c6hyj_yxB9Te4ac6W0kdngtMkFOW_Jmw=.eba06a60-637a-43dd-a04d-dd4cd372478d@github.com>
Message-ID: <xtjzSrMie_mGi87AdfSi6ZDaEzsx4XmfSJLA3JoMTJc=.ee4f76c2-305f-4e0c-91fd-155583f69915@github.com>

On Wed, 2 Aug 2023 17:03:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR (L10N translation update), which is a backport of commit [9b55e9a7](https://github.com/openjdk/jdk/commit/9b55e9a706de9893b1a71c7a6a4e23c4b8842f18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This change is required to keep the localized translations up to date with the English source resource files.

This pull request has now been integrated.

Changeset: fd789db5
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/fd789db510181886ffd3aa36ab06389a76d53e0b
Stats:     223 lines in 32 files changed: 36 ins; 15 del; 172 mod

8312572: JDK 21 RDP2 L10n resource files update

Reviewed-by: naoto, iris
Backport-of: 9b55e9a706de9893b1a71c7a6a4e23c4b8842f18

-------------

PR: https://git.openjdk.org/jdk21/pull/160

From naoto at openjdk.org  Thu Aug  3 21:25:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 3 Aug 2023 21:25:45 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v3]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <ao3zmdGCpfQYNZACJk2XdbQ_q3_DOTqjhvEe_mZyGnw=.e06de2bd-2347-4a7a-a4e0-e217309a8b39@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Wording fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/8e7181f2..cf3dddba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From rgiulietti at openjdk.org  Thu Aug  3 21:41:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 3 Aug 2023 21:41:31 GMT
Subject: RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException
 for groups outside match [v4]
In-Reply-To: <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
 <dAlKckz0TgbCEaRYNsXhCMiAKpneG6SfYqQ3Zvfb1AQ=.ad6300a0-f3ca-4ac4-af6d-7b0e72e37b07@github.com>
Message-ID: <fIVYKuVrR8j6NI4DHW6tp4XpwkxafPnUxY5ZtF1_Ej8=.8d9e83ef-f522-41ee-b59c-0f45ff6ba03d@github.com>

On Mon, 31 Jul 2023 18:38:30 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.
>
> Raffaello Giulietti 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 since the last revision:
> 
>  - Merged with mainline.
>  - Merge branch 'master' into 8312976
>  - Refactored recent tests as JUnit parametrized test.
>  - Added a test with negatvie lookbehind.
>  - Added test with a lookahead containing a back reference.
>  - 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match

Yes, I noticed that as well.

There's another [PR](https://git.openjdk.org/jdk/pull/14894) aimed to reduce the length of the `groups` array when possible (currently, it is always sized for at least 10 pairs of (`start`, `end`) entries, even when only one pair is needed for group 0). That one is slated for >= 22, so I might be coordinated the future PR for the removal of the redundant `first` and `last` fields with that PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15053#issuecomment-1664678223

From joehw at openjdk.org  Thu Aug  3 21:52:38 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 3 Aug 2023 21:52:38 GMT
Subject: RFR: 8311006: missing @since info in jdk.xml.dom
In-Reply-To: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
References: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
Message-ID: <0vj6gZS2BW8CtjBe8i6ajaXLVyUOhCJb0e3j--lPIsg=.8ce31a24-6449-47d9-a103-da7ffa81c745@github.com>

On Wed, 2 Aug 2023 22:26:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that add `@since` tags following existing convention for XML APIs in java.xml and jdk.xml.dom modules.

Thanks all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15129#issuecomment-1664686325

From joehw at openjdk.org  Thu Aug  3 21:52:39 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 3 Aug 2023 21:52:39 GMT
Subject: Integrated: 8311006: missing @since info in jdk.xml.dom
In-Reply-To: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
References: <gemIDsMRPOteyOSbhNEXLYXvUjrw9aC8Qm98YGCOfyw=.b8b1d5b8-d978-46d6-9aa9-2a161311b308@github.com>
Message-ID: <ISnEzAcdymXfAXmkpN_apMb_4JuDO9xXZedKS8jERc0=.f414b3a2-2f31-4f58-838d-57a3d163d2fe@github.com>

On Wed, 2 Aug 2023 22:26:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Please review a patch that add `@since` tags following existing convention for XML APIs in java.xml and jdk.xml.dom modules.

This pull request has now been integrated.

Changeset: d60352e2
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d60352e26fd8b7e51eeaf299e3f88783b739b02a
Stats:     12 lines in 6 files changed: 12 ins; 0 del; 0 mod

8311006: missing @since info in jdk.xml.dom

Reviewed-by: iris, naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/15129

From duke at openjdk.org  Thu Aug  3 21:55:30 2023
From: duke at openjdk.org (Cristian Vat)
Date: Thu, 3 Aug 2023 21:55:30 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v5]
In-Reply-To: <NNYVWvjz92L0gfFpu2gamLl_07vT3AWSsjycpzHjEZg=.9c354204-7ede-413d-9eac-41a2bf657cb1@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <NNYVWvjz92L0gfFpu2gamLl_07vT3AWSsjycpzHjEZg=.9c354204-7ede-413d-9eac-41a2bf657cb1@github.com>
Message-ID: <6vjrDRfVuI7Cokml8w3x7n_VgfqC-otdNEiZXoBhcJk=.25972b22-d5dc-4452-a9e7-4eb2080b1642@github.com>

On Thu, 3 Aug 2023 14:42:45 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review condition

Thanks. I committed changes suggested for if conditions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1664690418

From naoto at openjdk.org  Thu Aug  3 22:25:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 3 Aug 2023 22:25:29 GMT
Subject: RFR: 8159527: Collections mutator methods should all be marked as
 optional operations
In-Reply-To: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>
References: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>
Message-ID: <kRCngvM1JNeKcYKP7zzdj478YjVDXVeX5-BbFJAtQ3o=.f012f819-daa3-4f33-b42b-9f1156cd29b1@github.com>

On Wed, 2 Aug 2023 20:11:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the leading javadoc sentence of several collections mutator methods to include "(optional operation)" as appropriate. Also adjust doc for UnsupportedOperationException on those methods as necessary.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15127#pullrequestreview-1561935117

From bpb at openjdk.org  Thu Aug  3 22:53:32 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Aug 2023 22:53:32 GMT
Subject: RFR: 8159527: Collections mutator methods should all be marked as
 optional operations
In-Reply-To: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>
References: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>
Message-ID: <-LbvT5PS0gm0hp9IuHIzY-w0Bz2fuwbGtoNWsVeyejw=.87030d26-0d68-4a5e-b83a-4ba98cccabfa@github.com>

On Wed, 2 Aug 2023 20:11:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the leading javadoc sentence of several collections mutator methods to include "(optional operation)" as appropriate. Also adjust doc for UnsupportedOperationException on those methods as necessary.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15127#pullrequestreview-1561955359

From smarks at openjdk.org  Fri Aug  4 03:11:33 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 4 Aug 2023 03:11:33 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
Message-ID: <qVezMBdQeoqpE6BAnClb8MQQ8W47NfMCe6OvfHWppxA=.5b53c558-db95-4090-aca6-370e326dd6bc@github.com>

On Thu, 27 Jul 2023 06:31:06 GMT, dan1st <duke at openjdk.org> wrote:

>> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add addFirst(), removeFirst() and reversed() methods to lists.
>> However, the Javadoc of List mentions:
>>  > The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
>> 
>> This PR updates that Javadoc to factor in the new methods introduced by JEP 431.
>> 
>> https://bugs.openjdk.org/browse/JDK-8311517
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
>> 
>> This PR only affects documentation.
>
> dan1st has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>   
>   as requested by https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426

Thanks for the updates. I've drafted a CSR; see link in header. Please take a look.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15040#pullrequestreview-1562111046

From duke at openjdk.org  Fri Aug  4 05:16:40 2023
From: duke at openjdk.org (Qing Xiao)
Date: Fri, 4 Aug 2023 05:16:40 GMT
Subject: Integrated: 8294979: test/jdk/tools/jlink 3 test classes use ASM
 library
In-Reply-To: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
References: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
Message-ID: <Bzbgol03pDkjvIt3lPbQYmRgDj3GbA9Hrhi9O0bS5iE=.56aa4fce-46fc-46a3-8387-ec99d535a9ad@github.com>

On Thu, 13 Jul 2023 18:35:42 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 3 of 3 test/jdk/tools/jlink test classes to replace com.sun.tools.classfile library.

This pull request has now been integrated.

Changeset: 10a26058
Author:    Qing Xiao <qing.xiao at oracle.com>
Committer: Koichi Sakata <ksakata at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10a260588497eafa6c6c1caae4a15f354f7e2402
Stats:     11 lines in 3 files changed: 0 ins; 10 del; 1 mod

8294979: test/jdk/tools/jlink 3 test classes use ASM library

Reviewed-by: mchung, ksakata

-------------

PR: https://git.openjdk.org/jdk/pull/14877

From ksakata at openjdk.org  Fri Aug  4 05:16:39 2023
From: ksakata at openjdk.org (Koichi Sakata)
Date: Fri, 4 Aug 2023 05:16:39 GMT
Subject: RFR: 8294979: test/jdk/tools/jlink 3 test classes use ASM library
In-Reply-To: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
References: <TJWelTKjz_OMRNneuSFsHM5Uu-aoJQtis3eEwDiM88k=.0af87a97-78d2-48d4-ab17-3f1efba4033f@github.com>
Message-ID: <EuTPuGh46AYPMEdPi9rYa603AD9onnay1lw8jqd80ck=.6595f9ca-a9b5-47f3-bdfb-41eae8b92c6a@github.com>

On Thu, 13 Jul 2023 18:35:42 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified 3 of 3 test/jdk/tools/jlink test classes to replace com.sun.tools.classfile library.

Marked as reviewed by ksakata (Committer).

I'll sponsor you. I've checked those tests passed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14877#pullrequestreview-1562182593
PR Comment: https://git.openjdk.org/jdk/pull/14877#issuecomment-1665002336

From duke at openjdk.org  Fri Aug  4 07:14:31 2023
From: duke at openjdk.org (dan1st)
Date: Fri, 4 Aug 2023 07:14:31 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <qVezMBdQeoqpE6BAnClb8MQQ8W47NfMCe6OvfHWppxA=.5b53c558-db95-4090-aca6-370e326dd6bc@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
 <qVezMBdQeoqpE6BAnClb8MQQ8W47NfMCe6OvfHWppxA=.5b53c558-db95-4090-aca6-370e326dd6bc@github.com>
Message-ID: <KCi621OWGOVx_8OWymkRV7FQC6VngBj5QjpIxgcRx34=.886b63cd-7d0b-452c-9c9b-1189d0fd8221@github.com>

On Fri, 4 Aug 2023 03:08:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Thanks for the updates. I've drafted a CSR; see link in header. Please take a look.

@stuart-marks Thanks, the CSR looks good to me. I guess the `Fix versions` field will be added when the CSR is reviewed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1665120343

From rgiulietti at openjdk.org  Fri Aug  4 07:14:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Aug 2023 07:14:45 GMT
Subject: Integrated: 8312976: MatchResult produces
 StringIndexOutOfBoundsException for groups outside match
In-Reply-To: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
References: <x8ghNv-MsXGwtDhqgBCPbXQFGLTr3x0cWa4qUapadhY=.fa9e7f4f-744f-44aa-85c6-495a76eb2388@github.com>
Message-ID: <ey7gqzwd9BdQ5QGfXNw-A6yJzFtJdqX9vbKp5t0cyVQ=.140aa1ac-e293-4e22-852e-1f8bd7a48730@github.com>

On Thu, 27 Jul 2023 11:25:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Fixes a bug showing up after [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are capturing groups outside the match.

This pull request has now been integrated.

Changeset: 61c58fdd
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61c58fdd00727da2841a052477e4f4ecfa7094d6
Stats:     88 lines in 2 files changed: 80 ins; 0 del; 8 mod

8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match

Reviewed-by: alanb, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/15053

From rgiulietti at openjdk.org  Fri Aug  4 09:07:43 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Aug 2023 09:07:43 GMT
Subject: [jdk21] RFR: 8312976: MatchResult produces
 StringIndexOutOfBoundsException for groups outside match
Message-ID: <n_6xrk0yM0WbwKctAqa3jkaWHw6wq1Q0MZkM1fQxupo=.13e98d0e-b919-40a7-8bf7-0deac064a239@github.com>

Hi all,

This pull request contains a backport of commit [61c58fdd](https://github.com/openjdk/jdk/commit/61c58fdd00727da2841a052477e4f4ecfa7094d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Raffaello Giulietti on 4 Aug 2023 and was reviewed by Alan Bateman and Stuart Marks.

Thanks!

-------------

Commit messages:
 - Backport 61c58fdd00727da2841a052477e4f4ecfa7094d6

Changes: https://git.openjdk.org/jdk21/pull/164/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=164&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312976
  Stats: 88 lines in 2 files changed: 80 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk21/pull/164.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/164/head:pull/164

PR: https://git.openjdk.org/jdk21/pull/164

From rgiulietti at openjdk.org  Fri Aug  4 09:28:40 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Aug 2023 09:28:40 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
Message-ID: <6mHvyhxZXOsRotqEpoLsko8AJEp8TNbi2hMbJONXOT4=.279c3620-ea42-48d1-bb29-3efed2d1ada5@github.com>

On Thu, 27 Jul 2023 06:31:06 GMT, dan1st <duke at openjdk.org> wrote:

>> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add addFirst(), removeFirst() and reversed() methods to lists.
>> However, the Javadoc of List mentions:
>>  > The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
>> 
>> This PR updates that Javadoc to factor in the new methods introduced by JEP 431.
>> 
>> https://bugs.openjdk.org/browse/JDK-8311517
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
>> 
>> This PR only affects documentation.
>
> dan1st has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>   
>   as requested by https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426

LGTM (not a Reviewer)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1665309184

From mbaesken at openjdk.org  Fri Aug  4 10:06:43 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 4 Aug 2023 10:06:43 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some tests
Message-ID: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>

There is coding e.g. in
https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
that deals with shared lib naming on different OS.
This code should be simplified.

-------------

Commit messages:
 - JDK-8313670

Changes: https://git.openjdk.org/jdk/pull/15151/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313670
  Stats: 77 lines in 6 files changed: 13 ins; 59 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151

PR: https://git.openjdk.org/jdk/pull/15151

From duke at openjdk.org  Fri Aug  4 13:07:02 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 4 Aug 2023 13:07:02 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors
Message-ID: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>

com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.

Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

-------------

Commit messages:
 - reformat the code
 - remove unreachable code and reformatting the code
 - 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors

Changes: https://git.openjdk.org/jdk/pull/15143/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313657
  Stats: 197 lines in 2 files changed: 196 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143

PR: https://git.openjdk.org/jdk/pull/15143

From alanb at openjdk.org  Fri Aug  4 13:07:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 4 Aug 2023 13:07:02 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <MtIQgEWMX_t5e9jWJ8McwbjPsT9Vel1l3Trzbg3cvHQ=.06514aaf-46b4-487a-b71e-c7d04d738172@github.com>

On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 658:

> 656:                             unpauseReader();
> 657:                             if (debug) {
> 658:                                 if (sock.isClosed()) {

How is it possible for sock.close() to succeed but isClosed to return false?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1283542206

From duke at openjdk.org  Fri Aug  4 13:07:03 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 4 Aug 2023 13:07:03 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors
In-Reply-To: <MtIQgEWMX_t5e9jWJ8McwbjPsT9Vel1l3Trzbg3cvHQ=.06514aaf-46b4-487a-b71e-c7d04d738172@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <MtIQgEWMX_t5e9jWJ8McwbjPsT9Vel1l3Trzbg3cvHQ=.06514aaf-46b4-487a-b71e-c7d04d738172@github.com>
Message-ID: <Cq89OPAwzdd7f7SEciKH81eIpkFoH4vujToHqqO7szY=.fc0d46dc-3cdc-4b25-9789-16fbd1437f16@github.com>

On Thu, 3 Aug 2023 17:59:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 658:
> 
>> 656:                             unpauseReader();
>> 657:                             if (debug) {
>> 658:                                 if (sock.isClosed()) {
> 
> How is it possible for sock.close() to succeed but isClosed to return false?

It is an unreachable code and got removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1283640395

From stsypanov at openjdk.org  Fri Aug  4 14:57:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 4 Aug 2023 14:57:49 GMT
Subject: RFR: 8313768: Reduce interaction with volatile field in
 j.u.l.StreamHandler
Message-ID: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>

In `publish0()`, `flush0()` and `flushAndClose()`methods of `StreamHandler` we read multiple times from volatile writer. The access number can be reduced by reading the field into local variable once.

-------------

Commit messages:
 - 8313768: Reduce interaction with volatile field in j.u.l.StreamHandler

Changes: https://git.openjdk.org/jdk/pull/15161/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15161&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313768
  Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15161.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15161/head:pull/15161

PR: https://git.openjdk.org/jdk/pull/15161

From msheppar at openjdk.org  Fri Aug  4 15:23:33 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 4 Aug 2023 15:23:33 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <BFSZkuRjVCX3CXBa2GpFpMrqEEKZ6xnZh8IlslIV8lk=.354e8276-8b60-4fa8-a734-98c1efd43c8b@github.com>

On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

why not restructure the finally block a little ... refactor extract methods
flushOutputStream, 
closeConnectionSocket 
... should the outputStream be closed in this finally block, also?

                } finally {
                    flushOutputStream(outStream);
                    closeConnectionSocket(sock);
                    try {
                        unpauseReader();
                    } catch (IOException ie) {
                        if (debug)
                            System.err.println("Connection.cleanup: problem with unpuaseReader " + ie);
                    }
  ...


    private void flushOutputStream (OutputStream outputStream) {
        try {
            outStream.flush();
            outStream.close();
        } catch (IOException ioEx) {
            if (debug)
                System.err.println("Connection.flushOutputStream: OutputStream flush or close problem " + ioEx);
        }
    }
    
    private void closeConnectionSocket (Socket sock) {
        //bug 8313657, socket not closed util GC running
        try {
            sock.close();
        } catch (IOException ioEx) {
            if (debug)
                System.err.println("ConnectioncloseConnectioSocket: problem closing socket: " + ioEx);
        }
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1665777500

From bpb at openjdk.org  Fri Aug  4 15:34:32 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Aug 2023 15:34:32 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
Message-ID: <4Kp7qns7WsF3CvSh3NuKObJvG-hz006Alt1TujF8CjU=.e0d7a9e8-5368-44ba-aa0c-afc19b415dda@github.com>

On Thu, 27 Jul 2023 06:31:06 GMT, dan1st <duke at openjdk.org> wrote:

>> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add addFirst(), removeFirst() and reversed() methods to lists.
>> However, the Javadoc of List mentions:
>>  > The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
>> 
>> This PR updates that Javadoc to factor in the new methods introduced by JEP 431.
>> 
>> https://bugs.openjdk.org/browse/JDK-8311517
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
>> 
>> This PR only affects documentation.
>
> dan1st has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>   
>   as requested by https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426

src/java.base/share/classes/java/util/ArrayList.java line 46:

> 44:  * {@code listIterator}, and {@code reversed} operations run in constant time.
> 45:  * The {@code add}, and {@code addLast} operations runs in <i>amortized
> 46:  * constant time</i>, that is, adding n elements requires O(n) time.  All of

Should `n` and `O(n)` here be in italics or code font?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15040#discussion_r1284569426

From duke at openjdk.org  Fri Aug  4 15:41:33 2023
From: duke at openjdk.org (dan1st)
Date: Fri, 4 Aug 2023 15:41:33 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <4Kp7qns7WsF3CvSh3NuKObJvG-hz006Alt1TujF8CjU=.e0d7a9e8-5368-44ba-aa0c-afc19b415dda@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
 <4Kp7qns7WsF3CvSh3NuKObJvG-hz006Alt1TujF8CjU=.e0d7a9e8-5368-44ba-aa0c-afc19b415dda@github.com>
Message-ID: <hWlDB5Mkk1RrvmseZk16mHpKGGZUGjn2y2LQLkfaDrs=.0bae4408-3690-49fd-aa1c-6702c7331f8f@github.com>

On Fri, 4 Aug 2023 15:31:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> dan1st has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>>   
>>   as requested by https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426
>
> src/java.base/share/classes/java/util/ArrayList.java line 46:
> 
>> 44:  * {@code listIterator}, and {@code reversed} operations run in constant time.
>> 45:  * The {@code add}, and {@code addLast} operations runs in <i>amortized
>> 46:  * constant time</i>, that is, adding n elements requires O(n) time.  All of
> 
> Should `n` and `O(n)` here be in italics or code font?

It wasn't in italic or code font before so I didn't change that. However, I am open to changing that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15040#discussion_r1284573107

From bpb at openjdk.org  Fri Aug  4 16:02:33 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Aug 2023 16:02:33 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <hWlDB5Mkk1RrvmseZk16mHpKGGZUGjn2y2LQLkfaDrs=.0bae4408-3690-49fd-aa1c-6702c7331f8f@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
 <4Kp7qns7WsF3CvSh3NuKObJvG-hz006Alt1TujF8CjU=.e0d7a9e8-5368-44ba-aa0c-afc19b415dda@github.com>
 <hWlDB5Mkk1RrvmseZk16mHpKGGZUGjn2y2LQLkfaDrs=.0bae4408-3690-49fd-aa1c-6702c7331f8f@github.com>
Message-ID: <pBshqMYk8tzBdwlh1awzTTp511KkZn0HLY22yIqs5j0=.f7ca8d39-f422-4e7f-8326-a33fd9b656d9@github.com>

On Fri, 4 Aug 2023 15:36:05 GMT, dan1st <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ArrayList.java line 46:
>> 
>>> 44:  * {@code listIterator}, and {@code reversed} operations run in constant time.
>>> 45:  * The {@code add}, and {@code addLast} operations runs in <i>amortized
>>> 46:  * constant time</i>, that is, adding n elements requires O(n) time.  All of
>> 
>> Should `n` and `O(n)` here be in italics or code font?
>
> It wasn't in italic or code font before so I didn't change that. However, I am open to changing that.

Fine to leave it as is in that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15040#discussion_r1284596785

From bpb at openjdk.org  Fri Aug  4 16:06:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 4 Aug 2023 16:06:37 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
Message-ID: <jYIpPHdWg0KotViwoen0lxi1lpKzJBtIG6Fd_beEH44=.9a63a820-5c08-4276-a5d8-f8cb3b97d67d@github.com>

On Thu, 27 Jul 2023 06:31:06 GMT, dan1st <duke at openjdk.org> wrote:

>> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add addFirst(), removeFirst() and reversed() methods to lists.
>> However, the Javadoc of List mentions:
>>  > The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
>> 
>> This PR updates that Javadoc to factor in the new methods introduced by JEP 431.
>> 
>> https://bugs.openjdk.org/browse/JDK-8311517
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
>> 
>> This PR only affects documentation.
>
> dan1st has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>   
>   as requested by https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15040#pullrequestreview-1563165924

From smarks at openjdk.org  Fri Aug  4 16:31:31 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 4 Aug 2023 16:31:31 GMT
Subject: RFR: 8311517: Add performance information to ArrayList javadoc
 [v2]
In-Reply-To: <KCi621OWGOVx_8OWymkRV7FQC6VngBj5QjpIxgcRx34=.886b63cd-7d0b-452c-9c9b-1189d0fd8221@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
 <pamKySAQGsJyiCtY4CBrXBv_lzJzM-BjF_NGyjVSlWc=.eda95e0d-d496-40c1-a9d6-b6724269cce4@github.com>
 <qVezMBdQeoqpE6BAnClb8MQQ8W47NfMCe6OvfHWppxA=.5b53c558-db95-4090-aca6-370e326dd6bc@github.com>
 <KCi621OWGOVx_8OWymkRV7FQC6VngBj5QjpIxgcRx34=.886b63cd-7d0b-452c-9c9b-1189d0fd8221@github.com>
Message-ID: <_zIpiA3Y2Jzn5xBO1r8z36rMIqKLf_P7O08bfry1Kms=.5efffbb3-37f5-4097-a9aa-b5ad0e25db3b@github.com>

On Fri, 4 Aug 2023 07:11:58 GMT, dan1st <duke at openjdk.org> wrote:

>> Thanks for the updates. I've drafted a CSR; see link in header. Please take a look.
>
>> Thanks for the updates. I've drafted a CSR; see link in header. Please take a look.
> 
> @stuart-marks Thanks, the CSR looks good to me. I guess the `Fix versions` field will be added when the CSR is reviewed?
> Also, I guess this change will not be backported to 21 as it requires a CSR and we are approaching the initial release candidate?

@danthe1st 

>Thanks, the CSR looks good to me. I guess the Fix versions field will be added when the CSR is reviewed?
Also, I guess this change will not be backported to 21 as it requires a CSR and we are approaching the initial release candidate?

I've marked the CSR with Fix-Version 22. The bug itself should have its Fix-Version stay at "tbd" because it gets filled in automatically when the change is integrated. That doesn't happen for CSRs. (Admittedly this is kind of confusing and there's been some discussion about the best way to handle this.)

Right, it's too late to get this into JDK 21, and there's no compelling reason to do so. For stuff like this we just fix it in the "latest" release and move forward.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1665885792

From aefimov at openjdk.org  Fri Aug  4 16:36:33 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 4 Aug 2023 16:36:33 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <FO0NicWoYktKf_ONdliMqH-rYwCAvm9jgLst-ircNcs=.21506470-fc5e-41a0-b80b-9d51bf5467c3@github.com>

On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 652:

> 650:                     } catch (IOException ie) {
> 651:                         if (debug)
> 652:                             System.err.println("Connection: problem closing socket: " + ie);

How about combining the debug statement here with the one below and just print the socket isClosed state, something like

if (debug) {
    System.err.println("Connection: problem cleaning-up the connection: " + ie);
    System.err.println("Socket isClosed: " + sock.isClosed());
}

The text was changed here since the exception can also be thrown by `unpauseReader`

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 664:

> 662:                         } catch (IOException ioe) {
> 663:                             if (debug)
> 664:                                 System.err.println("Connection::cleanup problem: " + ioe);

Maybe change the message here to highlight the fact that it's the 2nd attemp to clean-up the connection

test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 28:

> 26: import javax.naming.directory.InitialDirContext;
> 27: import javax.net.SocketFactory;
> 28: import java.io.*;

Can we please use a set of class imports instead of package import here:

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 44:

> 42:  */
> 43: 
> 44: public class SocketCloseTest {

Can we change the test location from `test/javax/naming/InitialContext` to an LDAP-implementation specific folder - `test/jdk/com/sun/jndi/ldap`

test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 53:

> 51:     };
> 52:     private static final int SEARCH_SIZE = 87;
> 53:     private static final byte[] SEARCH_RESPONSE = new byte[]{

`SEARCH_RESPONSE`, `SEARCH_SIZE` and `BIND_SIZE` are not used in the test. If they're not needed they can be removed.

test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 71:

> 69: 
> 70:         props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
> 71:         props.put(Context.PROVIDER_URL, "ldap://localhost:1389/o=example");

For future test maintainers - can we please clarify that the hostname and port do not matter here because the provided custom socket factory doesn't establish a connection to the specified provider URL

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284631833
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284633364
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284569423
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284579620
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284582686
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284587752

From daniel at wwwmaster.at  Fri Aug  4 16:55:19 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Fri, 4 Aug 2023 18:55:19 +0200
Subject: Wrong exception in ComputedConstant#orElse Javadoc
Message-ID: <b7b155b9-b97c-902d-090b-555435eb97ea@wwwmaster.at>

When viewing the propsed Javadoc of ComputedConstant#orElse 
(https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#orElse(V)),it 
mentions throwing an NoSuchElementException in case the element cannot 
be bound.
However, the Javadoc also mentions returning the passed value in that case.

If we take a look at the code for that in the Leyden repository 
(https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L127 
and 
https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L161C27-L161C27), 
we can see that "rethrow" is false and no NoSuchElementException is 
thrown 
(https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L183-L186).

I think the "@throws NoSuchElementException" should be removed from 
ComputedConstant#orElse 
(https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/java/lang/ComputedConstant.java#L294C19-L294C19)

Yours,
Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230804/5ee4b746/smime.p7s>

From duke at openjdk.org  Fri Aug  4 18:24:04 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 4 Aug 2023 18:24:04 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v2]
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <CjtFmXqKTt27gH_24yLfLFLeyPK7upUHOuq6K-4XGIQ=.bb21764d-6f27-4110-a99a-2c80fa36c5f7@github.com>

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  updated the code according the review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15143/files
  - new: https://git.openjdk.org/jdk/pull/15143/files/c7feb93f..abf8126c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=00-01

  Stats: 409 lines in 3 files changed: 205 ins; 198 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143

PR: https://git.openjdk.org/jdk/pull/15143

From cjplummer at openjdk.org  Fri Aug  4 18:39:32 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 4 Aug 2023 18:39:32 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests
In-Reply-To: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
Message-ID: <kZ6zEPZ5N1plvXdvAdGXyabEVGIOyJqN0dpgw-uuGZI=.4082b25c-98cf-4829-9745-170f344394b6@github.com>

On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.

Changes requested by cjplummer (Reviewer).

test/lib/jdk/test/lib/Platform.java line 376:

> 374:         }
> 375:     }
> 376: 

The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`:

test/hotspot/jtreg/runtime/signal/SigTestDriver.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java
test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java

Perhaps a `Platform.buildSharedLibraryName()` API is worth considering.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1563375724
PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1284731606

From duke at openjdk.org  Fri Aug  4 19:09:58 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 4 Aug 2023 19:09:58 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v3]
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update error message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15143/files
  - new: https://git.openjdk.org/jdk/pull/15143/files/abf8126c..f33a565c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143

PR: https://git.openjdk.org/jdk/pull/15143

From duke at openjdk.org  Fri Aug  4 19:09:58 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 4 Aug 2023 19:09:58 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v2]
In-Reply-To: <CjtFmXqKTt27gH_24yLfLFLeyPK7upUHOuq6K-4XGIQ=.bb21764d-6f27-4110-a99a-2c80fa36c5f7@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <CjtFmXqKTt27gH_24yLfLFLeyPK7upUHOuq6K-4XGIQ=.bb21764d-6f27-4110-a99a-2c80fa36c5f7@github.com>
Message-ID: <ZUqyvDAGUyXiNjaSUCTiLaQUav51FdCzKkkcsTJosI0=.127001c1-d6fe-462d-bed2-c246d7f4125b@github.com>

On Fri, 4 Aug 2023 18:24:04 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according the review comments

1) Extracted the methods for finally black of Connection::cleanUP
2) Move the test class to LDAP test folder and updated the test comments.
3) Removed the redundant code and update the import statement.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1666054865

From smarks at openjdk.org  Fri Aug  4 19:30:39 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 4 Aug 2023 19:30:39 GMT
Subject: Integrated: 8159527: Collections mutator methods should all be marked
 as optional operations
In-Reply-To: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>
References: <VYmZlIBjLz74hHd3j1axU9JuCr76iO4pycKH6ezlk-w=.1306a8e0-34d1-4f7d-84ec-c38c8f01efb7@github.com>
Message-ID: <cvKgGORlF_fCBFeg_Kyao0-JZsrJkRMUqgtGO_nmLgY=.20b86aff-b005-414b-b306-e44c3aeacee4@github.com>

On Wed, 2 Aug 2023 20:11:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Adjust the leading javadoc sentence of several collections mutator methods to include "(optional operation)" as appropriate. Also adjust doc for UnsupportedOperationException on those methods as necessary.

This pull request has now been integrated.

Changeset: b2add96c
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2add96c353f15b91524e10207e49841298bed01
Stats:     70 lines in 5 files changed: 17 ins; 8 del; 45 mod

8159527: Collections mutator methods should all be marked as optional operations

Reviewed-by: naoto, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/15127

From duke at openjdk.org  Fri Aug  4 20:24:40 2023
From: duke at openjdk.org (dan1st)
Date: Fri, 4 Aug 2023 20:24:40 GMT
Subject: Integrated: 8311517: Add performance information to ArrayList javadoc
In-Reply-To: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
References: <W__ZJFyW8rEfrc6oxheeaO55f2YRc4ree7tsGNpYtQM=.4ce5a2fa-6943-42d0-93d9-f8fe87da8cf3@github.com>
Message-ID: <LTLZZUo-GsUUl8Qe3tE8u_QsfHoG7DVHhRewD563PEA=.e7cd9484-bb29-4d17-b5df-e73a30f0901a@github.com>

On Wed, 26 Jul 2023 11:02:20 GMT, dan1st <duke at openjdk.org> wrote:

> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add addFirst(), removeFirst() and reversed() methods to lists.
> However, the Javadoc of List mentions:
>  > The size, isEmpty, get, set, iterator, and listIterator operations run in constant time. The add operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList implementation.
> 
> This PR updates that Javadoc to factor in the new methods introduced by JEP 431.
> 
> https://bugs.openjdk.org/browse/JDK-8311517
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
> 
> This PR only affects documentation.

This pull request has now been integrated.

Changeset: b463c6d3
Author:    danthe1st <daniel at wwwmaster.at>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b463c6d3b0f27c8f124b5733cb9e7677542abe37
Stats:     6 lines in 1 file changed: 1 ins; 0 del; 5 mod

8311517: Add performance information to ArrayList javadoc

Reviewed-by: smarks, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/15040

From sspitsyn at openjdk.org  Fri Aug  4 20:59:27 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 4 Aug 2023 20:59:27 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests
In-Reply-To: <kZ6zEPZ5N1plvXdvAdGXyabEVGIOyJqN0dpgw-uuGZI=.4082b25c-98cf-4829-9745-170f344394b6@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <kZ6zEPZ5N1plvXdvAdGXyabEVGIOyJqN0dpgw-uuGZI=.4082b25c-98cf-4829-9745-170f344394b6@github.com>
Message-ID: <mq4i61AYQW5l6Q2SPOIFXBk14fIb8h-hp_ojf3c_qMM=.32372f4e-b0a5-4aee-a19e-fba74c00164e@github.com>

On Fri, 4 Aug 2023 18:34:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> test/lib/jdk/test/lib/Platform.java line 376:
> 
>> 374:         }
>> 375:     }
>> 376: 
> 
> The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`:
> 
> test/hotspot/jtreg/runtime/signal/SigTestDriver.java
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java
> test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
> 
> Perhaps a `Platform.buildSharedLibraryName()` API is worth considering.

The fix looks good in general.
But I like the suggestion from Chris above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1284840135

From naoto at openjdk.org  Fri Aug  4 21:09:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 4 Aug 2023 21:09:13 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v4]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <YJkDk23Otno9IzNwIVSeytv2MIjdHPBHp1iEdpej0nk=.45763b7a-ebc0-464e-a3c6-2ae326ae54d2@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  parsePosition update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/cf3dddba..50ba267c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=02-03

  Stats: 42 lines in 2 files changed: 40 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From cjplummer at openjdk.org  Fri Aug  4 22:49:44 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 4 Aug 2023 22:49:44 GMT
Subject: RFR: 8307408: Some jdk/sun/tools/jhsdb tests don't pass test JVM args
 to the debuggee JVM
Message-ID: <h17O6yCl-kR4vEWiOi0kV_MpTFlWxmY86p-HLn9SiNo=.d72a77f2-3a2b-4466-86dd-a701c202576f@github.com>

Normally we want the test args passed to the SA debuggee. In fact for proper SA test coverage, it is more important for the test args to be passed to the debuggee than to be passed to the test or the the SA tool that the test launches. For a couple of jhsdb tests that launch jshell as the debuggee, this wasn't happening, and jshell was always launched with no extra args.

Fixing this was very simple. Dealing with the unexpected fallout wasn't.  I filed a number of bugs that turned up (or where otherwise exposed) once I fixed this CR. The main onces were:

[JDK-8313798](https://bugs.openjdk.org/browse/JDK-8313798) [aarch64] sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java sometimes times out on aarch64
[JDK-8313655](https://bugs.openjdk.org/browse/JDK-8313655) sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java frequently fails with SerialGC

For the first one I'm problem listing the test for now, but have a fix and will get it out for review shortly. For the second one I'm just having the test avoid the issue by not allowing jshell to be launched with SerialGC.

Note also that this change caused some failures with ZGC due to an already filed CR.

-------------

Commit messages:
 - Pass test args to debuggee

Changes: https://git.openjdk.org/jdk/pull/15168/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15168&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307408
  Stats: 17 lines in 4 files changed: 13 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15168/head:pull/15168

PR: https://git.openjdk.org/jdk/pull/15168

From duke at openjdk.org  Sun Aug  6 00:51:33 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sun, 6 Aug 2023 00:51:33 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3]
In-Reply-To: <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
Message-ID: <nM4tqYyURffMFCsZiR_13K6Sg6kMCBxO6K10zX46F0U=.006c1bd0-71e4-412b-8ad7-f6d52016f704@github.com>

On Thu, 6 Jul 2023 05:20:14 GMT, ??? <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add method CharacterDataLatin1#isLowerCaseEx

Is anyone working on this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1666659089

From ysuenaga at openjdk.org  Sun Aug  6 09:14:28 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 6 Aug 2023 09:14:28 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <UNkZ9B-oirgBZdwn-BMFledS6Au_kqNCIhdz9P-clFs=.5b395a31-5d86-4d67-b58b-9db68080581a@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

Can I get second reviewer?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1666785232

From aturbanov at openjdk.org  Sun Aug  6 09:34:38 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 6 Aug 2023 09:34:38 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v10]
In-Reply-To: <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
Message-ID: <AiCDx8xvZbR9GQinau_ChZmcNpy0kBfqYaGORSBPd-s=.e34e0f50-034e-4548-a657-ec915b4cf69a@github.com>

On Tue, 1 Aug 2023 06:29:28 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 112:

> 110:     }
> 111: 
> 112:     public static  MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) {

Suggestion:

    public static MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285183843

From duke at openjdk.org  Sun Aug  6 12:30:44 2023
From: duke at openjdk.org (Wouter Born)
Date: Sun, 6 Aug 2023 12:30:44 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v10]
In-Reply-To: <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com>
Message-ID: <cWkgNekRMQfUx6ygAOSoZ_IROM-tnck1kMyCv5YCodA=.284d88a6-5e89-456a-ad63-cf48f6587653@github.com>

On Fri, 21 Jul 2023 16:42:25 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This update addresses performance issues across both LinkedTransferQueue and SynchronousQueue by creating a common basis for implementation across them (mainly in LinkedTransferQueue).  Pasting from internal doc summary of changes:
>>      * * Class DualNode replaces Qnode, with fields and methods
>>      *   that apply to any match-based dual data structure, and now
>>      *   usable in other j.u.c classes. in particular, SynchronousQueue.
>>      * * Blocking control (in class DualNode) accommodates
>>      *   VirtualThreads and (perhaps virtualized) uniprocessors.
>>      * * All fields of this class (LinkedTransferQueue) are
>>      *   default-initializable (to null), allowing further extension
>>      *   (in particular, SynchronousQueue.Transferer)
>>      * * Head and tail fields are lazily initialized rather than set
>>      *   to a dummy node, while also reducing retries under heavy
>>      *   contention and misorderings, and relaxing some accesses,
>>      *   requiring accommodation in many places (as well as
>>      *   adjustments in WhiteBox tests).
>
> Doug Lea 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 13 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8301341
>  - Address more review comments
>  - Address review comments
>  - nitpicks
>  - Merge branch 'openjdk:master' into JDK-8301341
>  - Accommodate white-box tests; use consistent constructions; minor improvements
>  - Merge branch 'openjdk:master' into JDK-8301341
>  - Simplify contention handling; fix test
>  - Fix inverted test assert; improve internal documentation; simplify code
>  - Merge branch 'openjdk:master' into JDK-8301341
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c456c802...f53cee67

Thanks for making the fixes Doug!
Would it also be possible to backport these fixes to Java 17?

It seems to be a very common issue for openHAB users now that they upgrade to openHAB 4 which requires Java 17.
See: https://community.openhab.org/t/consistent-100-cpu-use-of-safecall-queue-thread/143792

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-1666841611

From duke at openjdk.org  Mon Aug  7 00:07:37 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Mon, 7 Aug 2023 00:07:37 GMT
Subject: RFR: 8311207: Cleanup for Optimization for UUID.toString [v7]
In-Reply-To: <f6vmtp22GlgZ8loB_lH46hy5224Hpx7-zGdP_0G_wEk=.55e9cf5d-be28-4582-bda4-c585835343de@github.com>
References: <4_wGZz_VRmVnlHkDyvFBypBnvDaMxS9ToFb34RFVbJE=.6dd3ea8c-13d3-4b38-97c8-b7e2f99262fc@github.com>
 <f6vmtp22GlgZ8loB_lH46hy5224Hpx7-zGdP_0G_wEk=.55e9cf5d-be28-4582-bda4-c585835343de@github.com>
Message-ID: <O72gvZYqA9CDDlWFQh3mtHNmcLVN24pmPBl-MGN3kVE=.b71eaad2-dcba-478f-a1e0-0f9bc8cc4be8@github.com>

On Sat, 8 Jul 2023 00:20:20 GMT, ??? <duke at openjdk.org> wrote:

>> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved discussions, continue to make improvements.
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.util.UUIDBench.toString"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  62.019 ? 0.622  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  82.998 ? 0.739  ops/us (+33.82%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  88.668 ? 0.672  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  89.229 ? 0.271  ops/us (+0.63%)
>> 
>> 
>> 
>> ## 3. [aliyun_ecs_c8y.xlarge](https://help.aliyun.com/document_detail/25378.html#c8y)
>> * cpu : aliyun yitian 710 (aarch64)
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  49.382 ? 2.160  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  49.636 ? 1.974  ops/us (+0.51%)
>> 
>> 
>> ## 4. MacBookPro M1 Pro
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt    Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  103.543 ? 0.963  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt    Score   Error   Units
>> +UUIDBench.toString   20000  thrpt   15  110.976 ? 0.685  ops/us (+7.17%)
>> 
>> 
>> ## 5. Orange Pi 5 Plus
>> 
>> ``` diff
>> -Benchmark           (size)   Mode  Cnt   Score   Error   Units (baseline)
>> -UUIDBench.toString   20000  thrpt   15  33.532 ? 0.396  ops/us
>> 
>> +Benchmark           (size)   Mode  Cnt   Score   Error   Units (PR)
>> +UUIDBench.toString   20000  thrpt   15  33.054 ? 0.190  ops/us (-4.42%)
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Is anyone working on this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14745#issuecomment-1667012359

From duke at openjdk.org  Mon Aug  7 02:44:36 2023
From: duke at openjdk.org (Kimura Yukihiro)
Date: Mon, 7 Aug 2023 02:44:36 GMT
Subject: RFR: 8313854: Some tests in serviceability area fail on localized
 Windows platform
Message-ID: <dUmFyqjkNveLh3utuad5hI9fZtIyqfzeU9JbSAtL-oE=.4b3ba932-b3da-4f4b-8bbb-e34615208830@github.com>

I would like to fix this issue 
because the svc jtreg test does not pass on localized Windows platform.
Testing:
  all serviceability area tests (jdk_svc group).

Could anyone review the fix please?

Thanks,
Kimura Yukihiro

-------------

Commit messages:
 - 8313854: Some tests in serviceability area fail on localized Windows platform

Changes: https://git.openjdk.org/jdk/pull/15172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313854
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15172.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15172/head:pull/15172

PR: https://git.openjdk.org/jdk/pull/15172

From dholmes at openjdk.org  Mon Aug  7 06:45:32 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Aug 2023 06:45:32 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests
In-Reply-To: <mq4i61AYQW5l6Q2SPOIFXBk14fIb8h-hp_ojf3c_qMM=.32372f4e-b0a5-4aee-a19e-fba74c00164e@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <kZ6zEPZ5N1plvXdvAdGXyabEVGIOyJqN0dpgw-uuGZI=.4082b25c-98cf-4829-9745-170f344394b6@github.com>
 <mq4i61AYQW5l6Q2SPOIFXBk14fIb8h-hp_ojf3c_qMM=.32372f4e-b0a5-4aee-a19e-fba74c00164e@github.com>
Message-ID: <iiH7kcpQmIyhRwTzmPae-l2tUiVPEqX42HBZfWTmOuU=.6675819f-cf50-4cbb-ab23-a610cab6de54@github.com>

On Fri, 4 Aug 2023 20:55:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/lib/jdk/test/lib/Platform.java line 376:
>> 
>>> 374:         }
>>> 375:     }
>>> 376: 
>> 
>> The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`:
>> 
>> test/hotspot/jtreg/runtime/signal/SigTestDriver.java
>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java
>> test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java
>> 
>> Perhaps a `Platform.buildSharedLibraryName()` API is worth considering.
>
> The fix looks good in general.
> But I like the suggestion from Chris above

Agreed, I'd like to see `Platform.buildSharedLibraryName()` in addition to the other methods (the latter are needed if you want to decompose a filename to get the library name (though we could also provide a function just to do that).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1285438334

From vtewari at openjdk.org  Mon Aug  7 06:45:34 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 7 Aug 2023 06:45:34 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v3]
In-Reply-To: <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
Message-ID: <txNoS_N_MJ2zuVQdNHNseyYjkMHH-tmImLBy7QJFGn4=.84ffd9fb-66d6-4941-9fa0-7a9a1013b654@github.com>

On Fri, 4 Aug 2023 19:09:58 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update error message

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 686:

> 684: 
> 685:     // flush and close output stream
> 686:     private void flushCloseOutputStream() {

'flushAndCloseOutputStream' will be more meaningful name.

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 702:

> 700: 
> 701:     // close socket
> 702:     private void closeConnectionSocket() {

'closeSocketConnection' will be more meaningful.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1285437029
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1285438547

From pminborg at openjdk.org  Mon Aug  7 08:40:32 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Aug 2023 08:40:32 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM
In-Reply-To: <CKKSbqKgvZ3lhPRtCqJ0iM-Ko5ZQ6Rbuh38tIO4Nbrw=.a3d2cb06-dece-4a0a-a380-68ad2ac2b8c6@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
 <CKKSbqKgvZ3lhPRtCqJ0iM-Ko5ZQ6Rbuh38tIO4Nbrw=.a3d2cb06-dece-4a0a-a380-68ad2ac2b8c6@github.com>
Message-ID: <POsVVgCrJQe3wkThIsvcUjOMqYOxXgvhaDVx3Q7lBsA=.c6130369-68f2-4f0d-9916-164a858b2643@github.com>

On Sat, 29 Jul 2023 12:29:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
>> 
>> Some of the test files will have now the "classpath" exception. Is this correct?
>
> src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 25:
> 
>> 23:  * questions.
>> 24:  */
>> 25: 
> 
> Is there some style guideline that says there needs to be a blank line here?

This is common for many JDK files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15042#discussion_r1285558048

From msheppar at openjdk.org  Mon Aug  7 08:57:32 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 7 Aug 2023 08:57:32 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v3]
In-Reply-To: <txNoS_N_MJ2zuVQdNHNseyYjkMHH-tmImLBy7QJFGn4=.84ffd9fb-66d6-4941-9fa0-7a9a1013b654@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
 <txNoS_N_MJ2zuVQdNHNseyYjkMHH-tmImLBy7QJFGn4=.84ffd9fb-66d6-4941-9fa0-7a9a1013b654@github.com>
Message-ID: <JAMkfqYK5P3l5iXHt8bORmAUp8tOdr6FFn2-eL1pLiM=.edd4453e-c561-4e3f-ae81-99dc60c036f2@github.com>

On Mon, 7 Aug 2023 06:42:54 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update error message
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 702:
> 
>> 700: 
>> 701:     // close socket
>> 702:     private void closeConnectionSocket() {
> 
> 'closeSocketConnection' will be more meaningful.

the suggested name was to convey the closing of the  Connection's socket, not a socket connection per se.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1285577687

From pminborg at openjdk.org  Mon Aug  7 08:57:56 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Aug 2023 08:57:56 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM [v2]
In-Reply-To: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
Message-ID: <XtVA64aWRtO5oQzlBxnOaTRywbso1zQUs5M6y7nuiFI=.7a57a057-a618-43c9-b696-84395265a780@github.com>

> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
> 
> Some of the test files will have now the "classpath" exception. Is this correct?

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Remove classpath exception from test files
 - Add classpath exception to some internal files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15042/files
  - new: https://git.openjdk.org/jdk/pull/15042/files/3389537c..d81d0c4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15042&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15042&range=00-01

  Stats: 135 lines in 45 files changed: 8 ins; 82 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/15042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15042/head:pull/15042

PR: https://git.openjdk.org/jdk/pull/15042

From jvernee at openjdk.org  Mon Aug  7 09:15:37 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Aug 2023 09:15:37 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM [v2]
In-Reply-To: <XtVA64aWRtO5oQzlBxnOaTRywbso1zQUs5M6y7nuiFI=.7a57a057-a618-43c9-b696-84395265a780@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
 <XtVA64aWRtO5oQzlBxnOaTRywbso1zQUs5M6y7nuiFI=.7a57a057-a618-43c9-b696-84395265a780@github.com>
Message-ID: <0S6HC4W8mcjsb20oS3qxregP-uwFJDiEsnEJxmb680A=.d12018ed-5067-4ce0-9b7c-d4d01bc42e60@github.com>

On Mon, 7 Aug 2023 08:57:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
>> 
>> Some of the test files will have now the "classpath" exception. Is this correct?
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove classpath exception from test files
>  - Add classpath exception to some internal files

test/jdk/java/foreign/TestIllegalLink.java line 30:

> 28:  * @requires jdk.foreign.linker != "UNSUPPORTED"
> 29:  * @modules java.base/jdk.internal.foreign
> 30:  * @run testng/othervm --enable-native-access=ALL-UNNAMED TestIllegalLink

This is removing the jtreg test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15042#discussion_r1285595093

From msheppar at openjdk.org  Mon Aug  7 09:55:31 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 7 Aug 2023 09:55:31 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v3]
In-Reply-To: <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
Message-ID: <HjQh8ZHcL1oTUEp6AqpXnYUaMzwukLcPcE7_L5AZPWc=.1e1661b3-db42-4bfd-9d83-665f2bc83313@github.com>

On Fri, 4 Aug 2023 19:09:58 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update error message

I ran the test multiple times in mach5 and it executes fine. However, while examining the log output I noticed the "The socket was not closed. " output. This is a little confusing. While looking at the test and exploring the origins of this outout, we see that the test is essentially an othervm execution. As such, I restructured the test to othervm and it executes with some informative output and eliminates the discombobulating output.

I have left a comment in the JBS bug item with some further details and changes for othervm. This gives some imformative output as the test executes.

The origins of the output is the main try block executing in the agentvm and the throwing of a ClassNotFoundException.

If you don't wish to do otherrvm and to avoid the  "The socket was not closed. " output, and if wish to retain the same structure, then consider adding a run command to the test with an arg, and then a conditional on the core test logic e.g.

* @run main SocketCloseTest launcher

and in the main method

    public static void main(String[] args) throws Exception {
        Hashtable<String, Object> props = new Hashtable<>();

if (args.length == 0)  { // only executed in the launched JVM
        props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
        props.put(Context.PROVIDER_URL, "ldap://localhost:1389/o=example");
        props.put("java.naming.ldap.factory.socket", CustomSocketFactory.class.getName());
        try {
            final DirContext ctx = new InitialDirContext(props);
        } catch (Exception e) {
            if (CustomSocketFactory.customSocket.closeMethodCalledCount() > 0) {
                System.out.println(SOCKET_CLOSED_MSG);
            } else {
                System.out.println(SOCKET_NOT_CLOSED_MSG);
            }
        }
}

        OutputAnalyzer outputAnalyzer = ProcessTools.executeTestJvm("SocketCloseTest_II");
        outputAnalyzer.stdoutShouldContain(SOCKET_CLOSED_MSG);
        outputAnalyzer.stdoutShouldNotContain(SOCKET_NOT_CLOSED_MSG);
        outputAnalyzer.stdoutShouldContain(BAD_FLUSH);
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1667550730

From msheppar at openjdk.org  Mon Aug  7 10:21:32 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 7 Aug 2023 10:21:32 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v3]
In-Reply-To: <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
Message-ID: <qT5rzBQFVAlybbLhehHQuoZ1g-5tQw7EeybihV2wCzA=.478dfaae-ef65-466a-a04f-a63a3a7d0588@github.com>

On Fri, 4 Aug 2023 19:09:58 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update error message

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 62:

> 60:         props.put(Context.PROVIDER_URL, "ldap://localhost:1389/o=example");
> 61:         props.put("java.naming.ldap.factory.socket", CustomSocketFactory.class.getName());
> 62:         try {

this will execute twice: once in the agentvm main and also, as desired, in the test JVM main.
The agentvm main sees a ClassNotFoundException being thrown and then the output of "The socket was not closed. " in the log c.f. other comments and bug comments for further details to avoid execution in agentvm or use of othervm test mode execution

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1285675453

From aturbanov at openjdk.org  Mon Aug  7 10:53:37 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 7 Aug 2023 10:53:37 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
Message-ID: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>

Couple of static fields in Math could be declared `final`.

-------------

Commit messages:
 - [PATCH] Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown

Changes: https://git.openjdk.org/jdk/pull/14875/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14875&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313875
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14875.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14875/head:pull/14875

PR: https://git.openjdk.org/jdk/pull/14875

From jvernee at openjdk.org  Mon Aug  7 10:57:53 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Aug 2023 10:57:53 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM [v3]
In-Reply-To: <b_ZfJfYxVaG3bSOcuJiB64Etn43ctlTzihcn9GE0wUM=.424e7672-7fe3-4d53-a63f-e297ec7f62cf@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
 <b_ZfJfYxVaG3bSOcuJiB64Etn43ctlTzihcn9GE0wUM=.424e7672-7fe3-4d53-a63f-e297ec7f62cf@github.com>
Message-ID: <GKxeq6bCUkf5tfJTlY2ntWwjWv79kmYlXGQkW4oq4YA=.a92651fb-cc19-466f-b55f-b24e6e00246d@github.com>

On Mon, 7 Aug 2023 10:53:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
>> 
>> Some of the test files will have now the "classpath" exception. Is this correct?
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore removed test definition

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15042#pullrequestreview-1565069902

From pminborg at openjdk.org  Mon Aug  7 10:57:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Aug 2023 10:57:52 GMT
Subject: RFR: 8310643: Misformatted copyright messages in FFM [v3]
In-Reply-To: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
Message-ID: <b_ZfJfYxVaG3bSOcuJiB64Etn43ctlTzihcn9GE0wUM=.424e7672-7fe3-4d53-a63f-e297ec7f62cf@github.com>

> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
> 
> Some of the test files will have now the "classpath" exception. Is this correct?

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Restore removed test definition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15042/files
  - new: https://git.openjdk.org/jdk/pull/15042/files/d81d0c4e..c0a50714

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15042&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15042&range=01-02

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15042/head:pull/15042

PR: https://git.openjdk.org/jdk/pull/15042

From pminborg at openjdk.org  Mon Aug  7 11:01:41 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Aug 2023 11:01:41 GMT
Subject: Integrated: 8310643: Misformatted copyright messages in FFM
In-Reply-To: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
References: <4FbnzcAJbfC-pko1pw-VJuIwcoAaexsShS5ptUms91I=.74aa6b0f-9bed-43e7-a940-fcc9bb561883@github.com>
Message-ID: <g-vkWYBSeZzwCip4YYrwswotGDOT1hvQARwfncq550Y=.3f2de35d-6a9f-4914-b6c8-b4ecb4b3990b@github.com>

On Wed, 26 Jul 2023 15:43:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests updating some of the ill-formed copyright headers in the FFM API and the implementation and test thereof.
> 
> Some of the test files will have now the "classpath" exception. Is this correct?

This pull request has now been integrated.

Changeset: 0b4387e3
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b4387e3a33dd360efc5856126394739256505f8
Stats:     1012 lines in 58 files changed: 102 ins; 113 del; 797 mod

8310643: Misformatted copyright messages in FFM

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/15042

From redestad at openjdk.org  Mon Aug  7 12:00:29 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 7 Aug 2023 12:00:29 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
Message-ID: <LCxzgbRbu4rQwy8rNqe8gSAfBsAtUyUl64zBnjXD5TE=.1ffa3615-670f-44e7-9c83-d0b23094991f@github.com>

On Thu, 13 Jul 2023 17:57:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of static fields in Math could be declared `final`.

Looks good and trivial.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14875#pullrequestreview-1565168404

From dl at openjdk.org  Mon Aug  7 12:12:28 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 7 Aug 2023 12:12:28 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v2]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <v1P9UqGHhB0EQyq592LQzr7SGxjEJZXYpWOwT2k2ou0=.f59faebf-eae8-43f2-9ae9-4469b7b8ce81@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 40 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Rework versioning
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Reduce contention
 - minor improvements and renamings
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 30 more: https://git.openjdk.org/jdk/compare/8891d660...e29bbca3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/6a116f50..e29bbca3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=00-01

  Stats: 207739 lines in 3515 files changed: 99360 ins; 90418 del; 17961 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From thartmann at openjdk.org  Mon Aug  7 12:38:54 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 7 Aug 2023 12:38:54 GMT
Subject: Integrated: 8313880: Incorrect copyright header in
 jdk/java/foreign/TestFree.java after JDK-8310643
In-Reply-To: <ye8ejEgOdEbbnxbadSp-ScpYgwvsCQBsCSfnYRpG19A=.38d21d05-87f1-4cec-ab5c-543238ce3c8c@github.com>
References: <ye8ejEgOdEbbnxbadSp-ScpYgwvsCQBsCSfnYRpG19A=.38d21d05-87f1-4cec-ab5c-543238ce3c8c@github.com>
Message-ID: <AYj5fCrkEYKahCSrRrDtDTTZzK35M9ZecTsBRI5O-tY=.508b0c2c-4673-4b1c-a573-54fd1abdb5d0@github.com>

On Mon, 7 Aug 2023 12:27:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a formatting error in a copyright header.

Looks good and trivial to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15175#pullrequestreview-1565217211

From pminborg at openjdk.org  Mon Aug  7 12:38:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Aug 2023 12:38:54 GMT
Subject: Integrated: 8313880: Incorrect copyright header in
 jdk/java/foreign/TestFree.java after JDK-8310643
Message-ID: <ye8ejEgOdEbbnxbadSp-ScpYgwvsCQBsCSfnYRpG19A=.38d21d05-87f1-4cec-ab5c-543238ce3c8c@github.com>

This PR fixes a formatting error in a copyright header.

-------------

Commit messages:
 - Restore enablePreview
 - Fix copyright formatting in TestFree

Changes: https://git.openjdk.org/jdk/pull/15175/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15175&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313880
  Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15175.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15175/head:pull/15175

PR: https://git.openjdk.org/jdk/pull/15175

From pminborg at openjdk.org  Mon Aug  7 12:38:54 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 7 Aug 2023 12:38:54 GMT
Subject: Integrated: 8313880: Incorrect copyright header in
 jdk/java/foreign/TestFree.java after JDK-8310643
In-Reply-To: <ye8ejEgOdEbbnxbadSp-ScpYgwvsCQBsCSfnYRpG19A=.38d21d05-87f1-4cec-ab5c-543238ce3c8c@github.com>
References: <ye8ejEgOdEbbnxbadSp-ScpYgwvsCQBsCSfnYRpG19A=.38d21d05-87f1-4cec-ab5c-543238ce3c8c@github.com>
Message-ID: <7LRTdOfjjSQDlFfkaUqyundBIWD8V53wom3CPSEvmsc=.84aaa812-834c-4b0b-8b0e-e617b74f8955@github.com>

On Mon, 7 Aug 2023 12:27:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes a formatting error in a copyright header.

This pull request has now been integrated.

Changeset: bbbfa217
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bbbfa217a030e90e41c036203f85b764927f4848
Stats:     6 lines in 1 file changed: 2 ins; 2 del; 2 mod

8313880: Incorrect copyright header in jdk/java/foreign/TestFree.java after JDK-8310643

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/15175

From mdoerr at openjdk.org  Mon Aug  7 13:40:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 7 Aug 2023 13:40:39 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v10]
In-Reply-To: <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
Message-ID: <Bl41kBtdYb_u4u_TBPWMwCGVxTZomk1iLH5GbdCB_TA=.0fc0bec9-38e7-4b64-bd9a-930e35179080@github.com>

On Tue, 1 Aug 2023 06:29:28 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 154:

> 152:       } else {
> 153:         assert(to_reg.stack_size() == 4, "size should match");
> 154:         // s390 needs 4 Byte offset

Seems like this comment should get removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285880721

From mdoerr at openjdk.org  Mon Aug  7 13:45:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 7 Aug 2023 13:45:40 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v10]
In-Reply-To: <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
Message-ID: <Y-3KQsHS8gDVc9o8nhX0Ium1iVRsRObETEaqN3X_K8c=.08137a38-8f10-4c0b-9d02-ea81791509a3@github.com>

On Tue, 1 Aug 2023 06:29:28 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 221:

> 219:                     Class<?> type = SharedUtils.primitiveCarrierForSize(layout.byteSize(), false);
> 220:                     bindings.bufferLoad(0, type)
> 221:                         .vmStore(storage, type);

Maybe improve indentation?

src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 44:

> 42:     FLOAT;
> 43: 
> 44:     private static final int MAX_AGGREGATE_REGS_SIZE = 1;

Unused.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285885012
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1285886685

From sgehwolf at openjdk.org  Mon Aug  7 14:06:32 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 7 Aug 2023 14:06:32 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <DPP6Zfw8p1JJDnUqVRHe4plGJsMyg1PCz9U-sFlzarQ=.7e77bdb7-58c9-44d1-bf11-4974033f5aa8@github.com>

On Thu, 6 Jul 2023 17:34:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

Please keep open, bot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1667923083

From darcy at openjdk.org  Mon Aug  7 14:37:29 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Aug 2023 14:37:29 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
Message-ID: <ONJHwZtdnDN0ms0ZA-Ml3udMqbZNoi5p3SrJy1Y7SR8=.0b48b6b2-756a-48b5-91e5-b939ba6ef365@github.com>

On Thu, 13 Jul 2023 17:57:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of static fields in Math could be declared `final`.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14875#pullrequestreview-1565476822

From jvernee at openjdk.org  Mon Aug  7 15:13:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 7 Aug 2023 15:13:34 GMT
Subject: RFR: 8313889: Fix -Wconversion warnings in foreign benchmarks
Message-ID: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>

Fix these -Wconversion warnings in the foreign benchmarks:


./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1optimized?:
./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:59:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
   59 |     qsort(ints, length, sizeof(jint), &comparator);
      |                 ^~~~~~
./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1naive?:
./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:87:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
   87 |     qsort(carr, length, sizeof(jint), java_cmp);
      |


In this case the issue is that we're converting from a signed type to an unsigned type. So, if the source value is negative, it will be positive after conversion.

Since the source value is a Java array length in both cases, the value can not be negative, so we simply fix this by casting to `size_t` explicitly.

-------------

Commit messages:
 - fix -Wconversion warnings in foreign benchmarks

Changes: https://git.openjdk.org/jdk/pull/15179/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15179&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313889
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15179/head:pull/15179

PR: https://git.openjdk.org/jdk/pull/15179

From bpb at openjdk.org  Mon Aug  7 16:03:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 7 Aug 2023 16:03:31 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
Message-ID: <Ox3punw5ki2D002KA9IoRPVEgRr3P95cghltJqJndGw=.f24b5203-6860-433a-ad1c-61b437d48988@github.com>

On Thu, 13 Jul 2023 17:57:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of static fields in Math could be declared `final`.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14875#pullrequestreview-1565684801

From rgiulietti at openjdk.org  Mon Aug  7 16:46:32 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 7 Aug 2023 16:46:32 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
Message-ID: <TOcU3FY_olx0RXLIB0YP2GMHJnezD5hy-n0rgVTeVnU=.67da4375-869c-465b-9043-b3b2751b4d9b@github.com>

On Thu, 13 Jul 2023 17:57:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of static fields in Math could be declared `final`.

src/java.base/share/classes/java/lang/Math.java line 3425:

> 3423:     // Constants used in scalb
> 3424:     private static final double twoToTheDoubleScaleUp = powerOfTwoD(512);
> 3425:     private static final double twoToTheDoubleScaleDown = powerOfTwoD(-512);

Aren't these the _literals_ `0x1p512` and `0x1p-512`, respectively?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14875#discussion_r1286144980

From jlu at openjdk.org  Mon Aug  7 17:13:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 7 Aug 2023 17:13:39 GMT
Subject: Integrated: 8313702: Update IANA Language Subtag Registry to Version
 2023-08-02
In-Reply-To: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>
References: <mmq4TR1-8QiXsEOu-Wr_Hg-U5qDxFLTkkHygG0MKhXs=.d75beca0-6bd2-4d4e-9ce6-b765c51cef17@github.com>
Message-ID: <OgCId1VYECt71T8fR28VNOMQYS5wir9RwHr-X_1uuM0=.510aac52-5e12-4ccf-905c-d35b616e2b0c@github.com>

On Thu, 3 Aug 2023 16:31:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the IANA data from version 05-11-2023 to version [08-02-2023](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-August/000088.html).
> 
> The contents of the update added variant subtag ?blasl? to the language subtag registry.

This pull request has now been integrated.

Changeset: 1da82a34
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1da82a34b14189814e45a93c68620ccb51427111
Stats:     12 lines in 2 files changed: 9 ins; 0 del; 3 mod

8313702: Update IANA Language Subtag Registry to Version 2023-08-02

Reviewed-by: naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/15142

From aturbanov at openjdk.org  Mon Aug  7 17:38:30 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 7 Aug 2023 17:38:30 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <TOcU3FY_olx0RXLIB0YP2GMHJnezD5hy-n0rgVTeVnU=.67da4375-869c-465b-9043-b3b2751b4d9b@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <TOcU3FY_olx0RXLIB0YP2GMHJnezD5hy-n0rgVTeVnU=.67da4375-869c-465b-9043-b3b2751b4d9b@github.com>
Message-ID: <xdt8iFHYHm9tCtLWXDlD6oh5tjKadB-dxFeuIIuPrAw=.9f1349a8-689a-4293-9a6d-8c07a3494fde@github.com>

On Mon, 7 Aug 2023 16:43:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Couple of static fields in Math could be declared `final`.
>
> src/java.base/share/classes/java/lang/Math.java line 3425:
> 
>> 3423:     // Constants used in scalb
>> 3424:     private static final double twoToTheDoubleScaleUp = powerOfTwoD(512);
>> 3425:     private static final double twoToTheDoubleScaleDown = powerOfTwoD(-512);
> 
> Aren't these the _literals_ `0x1p512` and `0x1p-512`, respectively?

Whoa. You are right.

    public static void main(String[] args) {
        System.out.println(twoToTheDoubleScaleUp);
        System.out.println(twoToTheDoubleScaleDown);
        System.out.println(0x1p512);
        System.out.println(0x1p-512);

        System.out.println(twoToTheDoubleScaleUp == 0x1p512);
        System.out.println(twoToTheDoubleScaleDown == 0x1p-512);
    }



1.3407807929942597E154
7.458340731200207E-155
1.3407807929942597E154
7.458340731200207E-155
true
true

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14875#discussion_r1286196598

From rgiulietti at openjdk.org  Mon Aug  7 18:02:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 7 Aug 2023 18:02:31 GMT
Subject: RFR: 8313875: Make fields final in java.util.Math:
 twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <xdt8iFHYHm9tCtLWXDlD6oh5tjKadB-dxFeuIIuPrAw=.9f1349a8-689a-4293-9a6d-8c07a3494fde@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <TOcU3FY_olx0RXLIB0YP2GMHJnezD5hy-n0rgVTeVnU=.67da4375-869c-465b-9043-b3b2751b4d9b@github.com>
 <xdt8iFHYHm9tCtLWXDlD6oh5tjKadB-dxFeuIIuPrAw=.9f1349a8-689a-4293-9a6d-8c07a3494fde@github.com>
Message-ID: <SZCD8VTlvNP7et0_HTOz3RYdA--bQS6D_Utjg1x94Qw=.69d94019-367b-4c7a-bf17-cfd003860cd4@github.com>

On Mon, 7 Aug 2023 17:35:34 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 3425:
>> 
>>> 3423:     // Constants used in scalb
>>> 3424:     private static final double twoToTheDoubleScaleUp = powerOfTwoD(512);
>>> 3425:     private static final double twoToTheDoubleScaleDown = powerOfTwoD(-512);
>> 
>> Aren't these the _literals_ `0x1p512` and `0x1p-512`, respectively?
>
> Whoa. You are right.
> 
>     public static void main(String[] args) {
>         System.out.println(twoToTheDoubleScaleUp);
>         System.out.println(twoToTheDoubleScaleDown);
>         System.out.println(0x1p512);
>         System.out.println(0x1p-512);
> 
>         System.out.println(twoToTheDoubleScaleUp == 0x1p512);
>         System.out.println(twoToTheDoubleScaleDown == 0x1p-512);
>     }
> 
> 
> 
> 1.3407807929942597E154
> 7.458340731200207E-155
> 1.3407807929942597E154
> 7.458340731200207E-155
> true
> true

These static fields seem to be used just once each, so we might as well just replace the usages with the literals and get rid of the fields.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14875#discussion_r1286221538

From aturbanov at openjdk.org  Mon Aug  7 19:44:48 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 7 Aug 2023 19:44:48 GMT
Subject: RFR: 8313875: Use literals instead of static fields final in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
Message-ID: <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>

> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
  
  completely remove the fields. Use literals instead.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14875/files
  - new: https://git.openjdk.org/jdk/pull/14875/files/759180e3..4e154831

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14875&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14875&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14875.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14875/head:pull/14875

PR: https://git.openjdk.org/jdk/pull/14875

From bpb at openjdk.org  Mon Aug  7 19:46:40 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 7 Aug 2023 19:46:40 GMT
Subject: RFR: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
Message-ID: <OOlUZZY_aGrBpef7yeMTLhtnnNPhfOYrtLY3q9kY1HU=.1e78f061-4101-4356-a3f0-60ba1644f05f@github.com>

On Mon, 7 Aug 2023 19:44:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
>   
>   completely remove the fields. Use literals instead.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14875#pullrequestreview-1566050946

From duke at openjdk.org  Tue Aug  8 05:39:04 2023
From: duke at openjdk.org (sid8606)
Date: Tue, 8 Aug 2023 05:39:04 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v11]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation
  
  Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/924b45bc..a28c92d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=09-10

  Stats: 16 lines in 3 files changed: 0 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Tue Aug  8 05:39:05 2023
From: duke at openjdk.org (sid8606)
Date: Tue, 8 Aug 2023 05:39:05 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v10]
In-Reply-To: <AiCDx8xvZbR9GQinau_ChZmcNpy0kBfqYaGORSBPd-s=.e34e0f50-034e-4548-a657-ec915b4cf69a@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
 <AiCDx8xvZbR9GQinau_ChZmcNpy0kBfqYaGORSBPd-s=.e34e0f50-034e-4548-a657-ec915b4cf69a@github.com>
Message-ID: <LmohQjJD06ox3ziqnu279rOYmrFG7dhEG4TU5mP_7-o=.0641315b-952e-44f3-8e46-14c933f09af9@github.com>

On Sun, 6 Aug 2023 09:32:08 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>>   
>>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>
>
> src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 112:
> 
>> 110:     }
>> 111: 
>> 112:     public static  MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) {
> 
> Suggestion:
> 
>     public static MethodHandle arrangeDowncall(MethodType mt, FunctionDescriptor cDesc, LinkerOptions options) {

Thank you @turbanoff for the review comment. I have Fixed this in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613222

From duke at openjdk.org  Tue Aug  8 05:39:05 2023
From: duke at openjdk.org (sid8606)
Date: Tue, 8 Aug 2023 05:39:05 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v10]
In-Reply-To: <Bl41kBtdYb_u4u_TBPWMwCGVxTZomk1iLH5GbdCB_TA=.0fc0bec9-38e7-4b64-bd9a-930e35179080@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <eqQ6Xuilxh9retBuc_65RlMFW5dv-vsyPpD0uSDrEjA=.57f9f7f2-612f-454f-adcb-7e95928f2026@github.com>
 <Bl41kBtdYb_u4u_TBPWMwCGVxTZomk1iLH5GbdCB_TA=.0fc0bec9-38e7-4b64-bd9a-930e35179080@github.com>
Message-ID: <FTzNCpL2qR4AXg2b4_qKBOJRytpYcZSOwPVoHpVAFZY=.743b776a-8bae-43c1-b50e-48ffa6f74c3a@github.com>

On Mon, 7 Aug 2023 13:37:57 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>>   
>>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>
>
> src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 154:
> 
>> 152:       } else {
>> 153:         assert(to_reg.stack_size() == 4, "size should match");
>> 154:         // s390 needs 4 Byte offset
> 
> Seems like this comment should get removed.

Fixed

> src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/LinuxS390CallArranger.java line 221:
> 
>> 219:                     Class<?> type = SharedUtils.primitiveCarrierForSize(layout.byteSize(), false);
>> 220:                     bindings.bufferLoad(0, type)
>> 221:                         .vmStore(storage, type);
> 
> Maybe improve indentation?

Thank you @TheRealMDoerr. Fixed in new commit.

> src/java.base/share/classes/jdk/internal/foreign/abi/s390/linux/TypeClass.java line 44:
> 
>> 42:     FLOAT;
>> 43: 
>> 44:     private static final int MAX_AGGREGATE_REGS_SIZE = 1;
> 
> Unused.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613915
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613616
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286613721

From pminborg at openjdk.org  Tue Aug  8 08:35:51 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Aug 2023 08:35:51 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v4]
In-Reply-To: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
Message-ID: <qW_vDSWY9ZytLSINBu7CGh2Bt8tQx-ndaoZNf9jEQ7A=.5374490f-0991-49c7-8208-2ccbe4d7cf70@github.com>

> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.

Per Minborg 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 seven additional commits since the last revision:

 - Add snippet for MS::allocateArray methods
 - Merge branch 'master' into segallocjavadoc
 - Simplify snippets
 - Update after comments
 - Update array methods
 - Improve javadocs
 - Update javadocs for SegmentAllocator::allocate methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14997/files
  - new: https://git.openjdk.org/jdk/pull/14997/files/66b1c8e5..c7544307

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=02-03

  Stats: 19765 lines in 753 files changed: 9812 ins; 4053 del; 5900 mod
  Patch: https://git.openjdk.org/jdk/pull/14997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14997/head:pull/14997

PR: https://git.openjdk.org/jdk/pull/14997

From rgiulietti at openjdk.org  Tue Aug  8 08:44:45 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 8 Aug 2023 08:44:45 GMT
Subject: RFR: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
Message-ID: <X6tQsiHym6-rHASSrUv_zdoffqRXw2ue9yj0yfmAE4U=.d913badc-4d0f-48d6-9b32-6122171b1b4d@github.com>

On Mon, 7 Aug 2023 19:44:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
>   
>   completely remove the fields. Use literals instead.

LGTM (not a Reviewer)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14875#issuecomment-1669180764

From aturbanov at openjdk.org  Tue Aug  8 09:53:36 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Aug 2023 09:53:36 GMT
Subject: RFR: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <X6tQsiHym6-rHASSrUv_zdoffqRXw2ue9yj0yfmAE4U=.d913badc-4d0f-48d6-9b32-6122171b1b4d@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
 <X6tQsiHym6-rHASSrUv_zdoffqRXw2ue9yj0yfmAE4U=.d913badc-4d0f-48d6-9b32-6122171b1b4d@github.com>
Message-ID: <Wcls8QGOni3ei8tpqsd1rc5H4NK_4XnG5EFiGTGsSrY=.5f346144-662e-4adb-817e-46bd45203753@github.com>

On Tue, 8 Aug 2023 08:42:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
>>   
>>   completely remove the fields. Use literals instead.
>
> LGTM (not a Reviewer)

@rgiulietti you still can approve it _officially_, even if you are not a reviewer.
![???????????](https://github.com/openjdk/jdk/assets/741251/de391a20-c01c-490d-b943-a395e5c0e431)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14875#issuecomment-1669294085

From rgiulietti at openjdk.org  Tue Aug  8 10:03:34 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 8 Aug 2023 10:03:34 GMT
Subject: RFR: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
Message-ID: <pLHkqn0vjl44FXDAnchf1QRtKxhF7AB_qBcOj6apLeQ=.79479611-9278-47b0-a0ca-ba3b9450bf94@github.com>

On Mon, 7 Aug 2023 19:44:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
>   
>   completely remove the fields. Use literals instead.

I know, but that's not an _official_ review from the perspective of the OpenJDK, it's only a GitHub approval.
I find GitHub "reviews" confusing in the context of OpenJDK.
How would my GitHub approval help you in closing this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14875#issuecomment-1669310813

From mdoerr at openjdk.org  Tue Aug  8 10:04:42 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Aug 2023 10:04:42 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v11]
In-Reply-To: <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
Message-ID: <5j-qoK4YcY7h8xUGAGnrumzLQ3pWplhlGesEEhV6MFA=.987f91c3-e920-4b3a-b961-b54baadb758e@github.com>

On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 95:

> 93: 
> 94: static const int native_invoker_code_base_size = 384;
> 95: static const int native_invoker_size_per_args = 8;

Sizes were taken from PPC64. Are they correct for s390?

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 156:

> 154: #endif
> 155: 
> 156:   int allocated_frame_size = 0;

Line not needed.

src/hotspot/cpu/s390/downcallLinker_s390.cpp line 163:

> 161:   assert(!_needs_return_buffer, "unexpected needs_return_buffer");
> 162:   RegSpiller out_reg_spiller(_output_registers);
> 163:   int spill_offset = -1;

Line not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286895276
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286897339
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286897502

From mdoerr at openjdk.org  Tue Aug  8 10:30:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Aug 2023 10:30:41 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v11]
In-Reply-To: <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
Message-ID: <qdJfQbz8FQcIgm9TFSjBF4e9er1qoO7-rpE-7LFX2Ew=.6f682978-226b-4a19-9b11-d95c8510465e@github.com>

On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 130:

> 128:       }
> 129:       switch (to_reg.stack_size()) {
> 130:         case 8: __ reg2mem_opt(as_Register(from_reg), Address(Z_SP, reg2offset(to_reg, out_bias)), true);break;

Coding style: Spaces missing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286924775

From aturbanov at openjdk.org  Tue Aug  8 10:34:30 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Aug 2023 10:34:30 GMT
Subject: RFR: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
Message-ID: <2_WS2WdhIWKLDnHGlWMQXgQiySkrdg9LhKEPofGiZlo=.214168ec-4947-4120-8154-9ce4536c773c@github.com>

On Mon, 7 Aug 2023 19:44:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
>   
>   completely remove the fields. Use literals instead.

>I know, but that's not an official review from the perspective of the OpenJDK, it's only a GitHub approval.

Actually OpenJDK bot use Github approvals as a source. For example see this PR - #13213
Even I'm not a reviewer, my review is still listed in PR description and in the final commit message 30a140b5a2cedc7f69158ce398f148
`Reviewed-by: bpb, prr, aturbanov `

>How would my GitHub approval help you in closing this PR?

It's not directly related. You are right.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14875#issuecomment-1669356191

From mdoerr at openjdk.org  Tue Aug  8 10:35:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Aug 2023 10:35:39 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v11]
In-Reply-To: <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
Message-ID: <o0hYg0skuHs4rNJHNL6XBuHF_H6d2ZD2vquCJwouEQY=.13c793f0-57fe-49a1-be7c-1348203a56ee@github.com>

On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

src/hotspot/cpu/s390/upcallLinker_s390.cpp line 118:

> 116: 
> 117: static const int upcall_stub_code_base_size = 1536; // depends on GC (resolve_jobject)
> 118: static const int upcall_stub_size_per_arg = 16; // arg save & restore + move

Again sizes from PPC64. Should be checked!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1286929336

From rgiulietti at openjdk.org  Tue Aug  8 10:41:33 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 8 Aug 2023 10:41:33 GMT
Subject: RFR: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown [v2]
In-Reply-To: <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
 <V_H-UYoBQQ8A40dUiFbryndRRQrPhKFhqKBGpxlx-wk=.18722a0d-296b-4726-acfd-05241216aa5a@github.com>
Message-ID: <DR1i-ngUS4xsIF3Y5Pa07OvzoBw4qhGksG-BrIcBuAg=.4838fa5f-871d-4a62-804e-b82dc1d7591b@github.com>

On Mon, 7 Aug 2023 19:44:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8313875: Make fields final in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
>   
>   completely remove the fields. Use literals instead.

Marked as reviewed by rgiulietti (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14875#pullrequestreview-1567008351

From mdoerr at openjdk.org  Tue Aug  8 10:48:40 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 8 Aug 2023 10:48:40 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v11]
In-Reply-To: <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
Message-ID: <v57ukMKaR6CCRP04R7n3dbLgr83FPTXOfR_r5SoHFxo=.9bd5bee6-924d-450e-a612-64c175d01ce7@github.com>

On Tue, 8 Aug 2023 05:39:04 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation
>   
>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>

I couldn't spot real bugs, but sizes should get determined. (+ Possibly a bit more cleanup.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1567019061

From aturbanov at openjdk.org  Tue Aug  8 11:41:41 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 8 Aug 2023 11:41:41 GMT
Subject: Integrated: 8313875: Use literals instead of static fields in
 java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown
In-Reply-To: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
References: <Uwq_1UKEn_gRlVrt28TSPvyGXjI3p38p9uD_BhVW4cM=.ca6d1b07-eb9c-4167-8170-b2ce87273cc6@github.com>
Message-ID: <z5nj1EwgIQuwBWzVABUtjRy52f5GyJ5WUiGRlsT6_IA=.33dfc977-d4fa-4ae0-bf6d-90ec025e492e@github.com>

On Thu, 13 Jul 2023 17:57:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of static fields in Math are used only once and can be replaced with literals `0x1p512`/`0x1p-512 `

This pull request has now been integrated.

Changeset: 41bdcded
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41bdcded65eefd1b82a1f18dd49a61473d7072be
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8313875: Use literals instead of static fields in java.util.Math: twoToTheDoubleScaleUp, twoToTheDoubleScaleDown

Reviewed-by: redestad, darcy, bpb, rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/14875

From dfuchs at openjdk.org  Tue Aug  8 13:30:31 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 8 Aug 2023 13:30:31 GMT
Subject: RFR: 8313768: Reduce interaction with volatile field in
 j.u.l.StreamHandler
In-Reply-To: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>
References: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>
Message-ID: <_xZWz8dz4xRHi-bOH1hN3_o66deM10hgN8pIfBDV9Kw=.662848d6-2908-438e-80b1-7f37ff814082@github.com>

On Fri, 4 Aug 2023 14:51:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> In `publish0()`, `flush0()` and `flushAndClose()`methods of `StreamHandler` we read multiple times from volatile writer. The access number can be reduced by reading the field into local variable once.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15161#pullrequestreview-1567302875

From pminborg at openjdk.org  Tue Aug  8 13:49:30 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 8 Aug 2023 13:49:30 GMT
Subject: RFR: 8313889: Fix -Wconversion warnings in foreign benchmarks
In-Reply-To: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>
References: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>
Message-ID: <GV5pMG-ezJTM2nk8L32r0DszCsJk0lZnqEdriXpxN_Y=.13c85033-4e1f-46a2-8950-c5787f004623@github.com>

On Mon, 7 Aug 2023 14:40:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Fix these -Wconversion warnings in the foreign benchmarks:
> 
> 
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1optimized?:
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:59:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
>    59 |     qsort(ints, length, sizeof(jint), &comparator);
>       |                 ^~~~~~
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1naive?:
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:87:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
>    87 |     qsort(carr, length, sizeof(jint), java_cmp);
>       |
> 
> 
> In this case the issue is that we're converting from a signed type to an unsigned type. So, if the source value is negative, it will be positive after conversion.
> 
> Since the source value is a Java array length in both cases, the value can not be negative, so we simply fix this by casting to `size_t` explicitly.

LGTM.

-------------

Marked as reviewed by pminborg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15179#pullrequestreview-1567352237

From mcimadamore at openjdk.org  Tue Aug  8 13:54:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 8 Aug 2023 13:54:31 GMT
Subject: RFR: 8313889: Fix -Wconversion warnings in foreign benchmarks
In-Reply-To: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>
References: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>
Message-ID: <lBk_ei-U4ulTXxCCuWOk-LV22MSlxZ2bUWaP4UGtDcc=.10f034bb-8720-4e38-8d23-f1591b71e383@github.com>

On Mon, 7 Aug 2023 14:40:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Fix these -Wconversion warnings in the foreign benchmarks:
> 
> 
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1optimized?:
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:59:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
>    59 |     qsort(ints, length, sizeof(jint), &comparator);
>       |                 ^~~~~~
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1naive?:
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:87:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
>    87 |     qsort(carr, length, sizeof(jint), java_cmp);
>       |
> 
> 
> In this case the issue is that we're converting from a signed type to an unsigned type. So, if the source value is negative, it will be positive after conversion.
> 
> Since the source value is a Java array length in both cases, the value can not be negative, so we simply fix this by casting to `size_t` explicitly.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15179#pullrequestreview-1567365160

From jvernee at openjdk.org  Tue Aug  8 14:02:42 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 8 Aug 2023 14:02:42 GMT
Subject: Integrated: 8313889: Fix -Wconversion warnings in foreign benchmarks
In-Reply-To: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>
References: <3FLSQ1267KeHB4x2wSCynPs3wmbA5vsyhgMvogBVJyw=.4d2b8244-e9e5-44bf-8f2f-ce899627f578@github.com>
Message-ID: <oGjilZYm83PDtq_cSoq_oXLiARAlKNuR2w0oyUK-HpU=.3fb3129c-5145-475e-aaef-42a533d76ed1@github.com>

On Mon, 7 Aug 2023 14:40:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Fix these -Wconversion warnings in the foreign benchmarks:
> 
> 
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1optimized?:
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:59:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
>    59 |     qsort(ints, length, sizeof(jint), &comparator);
>       |                 ^~~~~~
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c: In function ?Java_org_openjdk_bench_java_lang_foreign_QSort_jni_1qsort_1naive?:
> ./test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c:87:17: warning: conversion to ?size_t? {aka ?long unsigned int?} from ?jsize? {aka ?int?} may change the sign of the result [-Wsign-conversion]
>    87 |     qsort(carr, length, sizeof(jint), java_cmp);
>       |
> 
> 
> In this case the issue is that we're converting from a signed type to an unsigned type. So, if the source value is negative, it will be positive after conversion.
> 
> Since the source value is a Java array length in both cases, the value can not be negative, so we simply fix this by casting to `size_t` explicitly.

This pull request has now been integrated.

Changeset: 509f80bb
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/509f80bb047beb49fb8ecb62bffb0d0fd4fe75cb
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8313889: Fix -Wconversion warnings in foreign benchmarks

Reviewed-by: pminborg, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/15179

From asotona at openjdk.org  Tue Aug  8 15:06:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 8 Aug 2023 15:06:02 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v7]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <Ys37hdH6Lgm8JF6w0R6BMYWBFccEFtYEbphDG_E6e8k=.9fee0f8c-6a67-4ca2-bbfe-a9f06550fc01@github.com>

> This pull request updates Classfile API snippets and examples and adds missing javadoc.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed extra lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/a2b4e858..cd182173

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=05-06

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From rriggs at openjdk.org  Tue Aug  8 16:03:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Aug 2023 16:03:36 GMT
Subject: [jdk21] RFR: 8313312: Add missing classpath exception copyright header
Message-ID: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>

The same copyright updates are needed in JDK21.

-------------

Commit messages:
 - Backport 53ca75b18ea419d469758475fac8352bf915b484

Changes: https://git.openjdk.org/jdk21/pull/166/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=166&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313312
  Stats: 48 lines in 16 files changed: 32 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk21/pull/166.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/166/head:pull/166

PR: https://git.openjdk.org/jdk21/pull/166

From bpb at openjdk.org  Tue Aug  8 16:16:36 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 8 Aug 2023 16:16:36 GMT
Subject: [jdk21] RFR: 8313312: Add missing classpath exception copyright
 header
In-Reply-To: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
References: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
Message-ID: <KVVYCL3_PVFN8HoZ1EgqKjeTHFm7IBYBTZC9DkZspDU=.7a4c7b38-c3a6-4fe5-8972-c3335712ed1b@github.com>

On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The same copyright updates are needed in JDK21.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk21/pull/166#pullrequestreview-1567674852

From sgehwolf at openjdk.org  Tue Aug  8 16:34:09 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 8 Aug 2023 16:34:09 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v2]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <vOKwbbLeJM-azXc8xhgFG9sJWqraG-q8aQ2bgWSnaWA=.da834e20-40dc-47c7-a398-c3650109df48@github.com>

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Use 'run-image' as the term shown with --verbose
 - 8311302: Allow for jlinking a custom runtime without packaged modules being present

-------------

Changes: https://git.openjdk.org/jdk/pull/14787/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=01
  Stats: 2080 lines in 23 files changed: 2015 ins; 32 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From naoto at openjdk.org  Tue Aug  8 17:19:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Aug 2023 17:19:55 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v5]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <9S5QinT9cgHGGL26AXkWN8ENRVxL1Le1fwZ_rdTz-F4=.684308dc-e1b8-4dee-9eff-3690b327e29b@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato 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 five additional commits since the last revision:

 - Merge branch 'master' into JDK-8041488-ListPatterns-PR
 - parsePosition update
 - Wording fixes
 - Added test
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/50ba267c..a98e1e1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=03-04

  Stats: 8981 lines in 435 files changed: 3504 ins; 2284 del; 3193 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From naoto at openjdk.org  Tue Aug  8 17:20:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Aug 2023 17:20:31 GMT
Subject: [jdk21] RFR: 8313312: Add missing classpath exception copyright
 header
In-Reply-To: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
References: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
Message-ID: <X0BS3LDDPEhgblGl0qafsXGUPmseXNHA68kYv_iOgLw=.f6759af0-095f-4d7a-914e-7ce886b392b7@github.com>

On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The same copyright updates are needed in JDK21.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/166#pullrequestreview-1567795009

From jlaskey at openjdk.org  Tue Aug  8 18:38:40 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 8 Aug 2023 18:38:40 GMT
Subject: RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
Message-ID: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>

The last fragment of a string template does not get it's coder added to the mix.

-------------

Commit messages:
 - 8313809: String template fails with java.lang.StringIndexOutOfBoundsException

Changes: https://git.openjdk.org/jdk/pull/15195/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313809
  Stats: 45 lines in 2 files changed: 44 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15195/head:pull/15195

PR: https://git.openjdk.org/jdk/pull/15195

From erikj at openjdk.org  Tue Aug  8 18:41:34 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 8 Aug 2023 18:41:34 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <22KaxTbA_XWZS28f7xM5oEXoZhlNttZvNNNnc66Mi-c=.0e98ec5f-7a47-41f1-b65b-37c0ac81d308@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Build change looks ok.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1567918097

From redestad at openjdk.org  Tue Aug  8 19:08:36 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Aug 2023 19:08:36 GMT
Subject: RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
In-Reply-To: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
References: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
Message-ID: <8Qg6JLfCuNqFDN9DEqsDbnOE4kTCKWsh8h3WCl_1Up0=.b3319221-882c-442e-b25a-0c8a068e5096@github.com>

On Tue, 8 Aug 2023 18:31:04 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The last fragment of a string template does not get it's coder added to the mix.

LGTM. This also adds an implicit null check on the last fragment.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1129:

> 1127:         }
> 1128: 
> 1129:         initialLengthCoder -= lastFragment.length();

Nit: Could leverage the fact that the last fragment will always be at `fragments.get(ttypes.length)` here and simplify above (remove `lastFragment`, move `initialLengthCoder` back to L1122)

test/jdk/java/lang/template/T8313809.java line 27:

> 25:  * @test
> 26:  * @bug 8313809
> 27:  * @summary String template fails with java.lang.StringIndexOutOfBoundsException if the string contains euro symbol.

Perhaps could use the same phrasing as the bug summary?

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15195#pullrequestreview-1567922299
PR Review Comment: https://git.openjdk.org/jdk/pull/15195#discussion_r1287529542
PR Review Comment: https://git.openjdk.org/jdk/pull/15195#discussion_r1287515955

From jlaskey at openjdk.org  Tue Aug  8 19:20:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 8 Aug 2023 19:20:34 GMT
Subject: RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
In-Reply-To: <8Qg6JLfCuNqFDN9DEqsDbnOE4kTCKWsh8h3WCl_1Up0=.b3319221-882c-442e-b25a-0c8a068e5096@github.com>
References: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
 <8Qg6JLfCuNqFDN9DEqsDbnOE4kTCKWsh8h3WCl_1Up0=.b3319221-882c-442e-b25a-0c8a068e5096@github.com>
Message-ID: <8FIsgCPtg3Ahh3CMqM0Nv8gagflxtg9meD65OrA8aCE=.92da7c61-7649-48ce-92c0-36973b863ee2@github.com>

On Tue, 8 Aug 2023 18:56:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The last fragment of a string template does not get it's coder added to the mix.
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1129:
> 
>> 1127:         }
>> 1128: 
>> 1129:         initialLengthCoder -= lastFragment.length();
> 
> Nit: Could leverage the fact that the last fragment will always be at `fragments.get(ttypes.length)` here and simplify above (remove `lastFragment`, move `initialLengthCoder` back to L1122)

Changing

> test/jdk/java/lang/template/T8313809.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8313809
>> 27:  * @summary String template fails with java.lang.StringIndexOutOfBoundsException if the string contains euro symbol.
> 
> Perhaps could use the same phrasing as the bug summary?

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15195#discussion_r1287548392
PR Review Comment: https://git.openjdk.org/jdk/pull/15195#discussion_r1287548475

From jlaskey at openjdk.org  Tue Aug  8 19:38:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 8 Aug 2023 19:38:41 GMT
Subject: RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16 [v2]
In-Reply-To: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
References: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
Message-ID: <DJpadIRCTgz55qZcUv_cc7RdijVANPDPFTqV5jXxXzI=.8a4e715e-b121-483e-a553-7e097910a0c8@github.com>

> The last fragment of a string template does not get it's coder added to the mix.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested by @cl4es

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15195/files
  - new: https://git.openjdk.org/jdk/pull/15195/files/ae6bc58c..3dba5187

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15195&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15195&range=00-01

  Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15195/head:pull/15195

PR: https://git.openjdk.org/jdk/pull/15195

From redestad at openjdk.org  Tue Aug  8 19:38:42 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 8 Aug 2023 19:38:42 GMT
Subject: RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16 [v2]
In-Reply-To: <DJpadIRCTgz55qZcUv_cc7RdijVANPDPFTqV5jXxXzI=.8a4e715e-b121-483e-a553-7e097910a0c8@github.com>
References: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
 <DJpadIRCTgz55qZcUv_cc7RdijVANPDPFTqV5jXxXzI=.8a4e715e-b121-483e-a553-7e097910a0c8@github.com>
Message-ID: <ZQatikSD28wtJWHeYOPUOwzfS39A9aBKOShh-QETUTE=.91d41322-af5d-46a1-9b7d-f85a083bb49d@github.com>

On Tue, 8 Aug 2023 19:34:05 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> The last fragment of a string template does not get it's coder added to the mix.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Requested by @cl4es

This works. Thanks!

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15195#pullrequestreview-1568020270

From jlaskey at openjdk.org  Tue Aug  8 19:38:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 8 Aug 2023 19:38:44 GMT
Subject: Integrated: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
In-Reply-To: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
References: <CHH5IGGwy6uU2NfcplQ_og3PYrCyL93tmg2WZk-yNHU=.a696cc55-9254-4ff6-9ff6-44ba9aef6944@github.com>
Message-ID: <Zx5inDXN7ACptWv33KPSOIE0C6Y6EaIX5QvpnmlqhJ0=.4815898a-a41d-4e5f-95e8-802e0552522f@github.com>

On Tue, 8 Aug 2023 18:31:04 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The last fragment of a string template does not get it's coder added to the mix.

This pull request has now been integrated.

Changeset: 68644411
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6864441163f946d0bec7380a2a120e31b812a6dc
Stats:     49 lines in 2 files changed: 45 ins; 2 del; 2 mod

8313809: String template fails with java.lang.StringIndexOutOfBoundsException if last fragment is UTF16

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/15195

From rriggs at openjdk.org  Tue Aug  8 20:01:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Aug 2023 20:01:41 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v5]
In-Reply-To: <9S5QinT9cgHGGL26AXkWN8ENRVxL1Le1fwZ_rdTz-F4=.684308dc-e1b8-4dee-9eff-3690b327e29b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <9S5QinT9cgHGGL26AXkWN8ENRVxL1Le1fwZ_rdTz-F4=.684308dc-e1b8-4dee-9eff-3690b327e29b@github.com>
Message-ID: <CfrDYtQM-opiAKfNnTDmXUV4OFDEipogC69s82AvORE=.7fc8273b-36e5-4151-9a43-1a2f72de5376@github.com>

On Tue, 8 Aug 2023 17:19:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html
>
> Naoto Sato 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 five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8041488-ListPatterns-PR
>  - parsePosition update
>  - Wording fixes
>  - Added test
>  - Initial commit

src/java.base/share/classes/java/text/ListFormat.java line 199:

> 197:      * @param locale Locale to be used, not null
> 198:      * @param type type of the list format. One of STANDARD/OR/UNIT, not null
> 199:      * @param style style of the list format. One of FULL/SHORT/NARROW, not null

It would be ease navigation in the javadoc if there was a link to the ListFormat.Type and ListFormat.Style classes, perhaps Locale also.
Use the normal prose form STANDARD, OR, or UNIT, instead of the "/" shorthand. Here and throughout the javadoc.  Ditto FULL, SHORT, or NARROW.
Also use Locale, Type, and Style instead of the shorthand.

src/java.base/share/classes/java/text/ListFormat.java line 213:

> 211:     /**
> 212:      * {@return the list format for the specified patterns}
> 213:      * <p>

LDML includes a section on the "Gender of Lists";  If later support was desired, is this API extensible to include that?  https://www.unicode.org/reports/tr35/tr35-general.html#List_Gender

src/java.base/share/classes/java/text/ListFormat.java line 234:

> 232:      * If parsing of the pattern string for start/middle/end fails, it throws an
> 233:      * {@code IllegalArgumentException}. If two/three pattern string is empty, or
> 234:      * fails on parsing, it falls back to

I don't see code to try to parse the TWO or THREE patterns, where it could detect incorrectly formatted (user supplied) patterns.
If I understand correctly, a bad TWO or THREE pattern would not be detected until it is used in format or parse.

src/java.base/share/classes/java/text/ListFormat.java line 350:

> 348:      * {@code "a", "b", "c"}.
> 349:      *
> 350:      * @param source the String to parse, not null.

String does not need to be capitalized.

src/java.base/share/classes/java/text/ListFormat.java line 365:

> 363: 
> 364:     /**
> 365:      * Parses text from a string to produce a list of {@code String}s.

No need to capitalize String if list is not capitalized. (or be consistent)

src/java.base/share/classes/java/text/ListFormat.java line 428:

> 426:             return Arrays.asList(objs);
> 427:         }
> 428:         throw new InternalError("MessageFormat.parseObject() should return Object[]");

The error message is inconsistent with line 426, returning a List<String>.

src/java.base/share/classes/java/text/ListFormat.java line 442:

> 440: 
> 441:     /**
> 442:      * {@inheritDoc}

The javadoc from Object.equals doesn't give any information about what constituted equals for a ListFormat.
Namely, that the locale and patterns are equal.

src/java.base/share/classes/java/text/ListFormat.java line 480:

> 478:         var len = input.length;
> 479:         return switch (len) {
> 480:             case 0 -> throw new IllegalArgumentException("There should at least be one input string");

It is unfortunate that LDML did not consider the case of an empty list. For example, to supply "NONE" or "n/a" or similar.  The developer will need to deal with that separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287548046
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287623678
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287564928
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287624574
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287626211
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287627985
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287630232
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287622614

From naoto at openjdk.org  Tue Aug  8 21:45:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Aug 2023 21:45:33 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v5]
In-Reply-To: <CfrDYtQM-opiAKfNnTDmXUV4OFDEipogC69s82AvORE=.7fc8273b-36e5-4151-9a43-1a2f72de5376@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <9S5QinT9cgHGGL26AXkWN8ENRVxL1Le1fwZ_rdTz-F4=.684308dc-e1b8-4dee-9eff-3690b327e29b@github.com>
 <CfrDYtQM-opiAKfNnTDmXUV4OFDEipogC69s82AvORE=.7fc8273b-36e5-4151-9a43-1a2f72de5376@github.com>
Message-ID: <-DjQ2TurFbzd3vc0Iz2AHv0EfjCvLJRsU2c5XC8acPo=.c79bef39-07f5-4bef-b4c7-44bfbbdb82f7@github.com>

On Tue, 8 Aug 2023 19:49:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato 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 five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8041488-ListPatterns-PR
>>  - parsePosition update
>>  - Wording fixes
>>  - Added test
>>  - Initial commit
>
> src/java.base/share/classes/java/text/ListFormat.java line 213:
> 
>> 211:     /**
>> 212:      * {@return the list format for the specified patterns}
>> 213:      * <p>
> 
> LDML includes a section on the "Gender of Lists";  If later support was desired, is this API extensible to include that?  https://www.unicode.org/reports/tr35/tr35-general.html#List_Gender

IIUC, although it is described within "list patterns" in LDML, it is orthogonal to "list patterns." The purpose of the "Gender of Lists" seems to me the resulting gender of the whole list of names, e.g., "Tom and Mary" is "other" in English, but it is "male" in Arabic (I just used the sample XML in the spec). So I believe it is not an extension of the class.

> src/java.base/share/classes/java/text/ListFormat.java line 234:
> 
>> 232:      * If parsing of the pattern string for start/middle/end fails, it throws an
>> 233:      * {@code IllegalArgumentException}. If two/three pattern string is empty, or
>> 234:      * fails on parsing, it falls back to
> 
> I don't see code to try to parse the TWO or THREE patterns, where it could detect incorrectly formatted (user supplied) patterns.
> If I understand correctly, a bad TWO or THREE pattern would not be detected until it is used in format or parse.

Right. Will provide validation for them

> src/java.base/share/classes/java/text/ListFormat.java line 442:
> 
>> 440: 
>> 441:     /**
>> 442:      * {@inheritDoc}
> 
> The javadoc from Object.equals doesn't give any information about what constituted equals for a ListFormat.
> Namely, that the locale and patterns are equal.

Will add those ListFormat specific considerations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287716917
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287716871
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1287717003

From naoto at openjdk.org  Tue Aug  8 22:21:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 8 Aug 2023 22:21:04 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v6]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <HIJCX1Q4oNubs6WcLlmAp0UkIC2IjqQZNzjNkSmSrtQ=.16f9edeb-799d-4bea-b453-13080a1e4c8f@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflects review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/a98e1e1f..516c00c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=04-05

  Stats: 59 lines in 2 files changed: 40 ins; 1 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From duke at openjdk.org  Wed Aug  9 00:21:55 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 9 Aug 2023 00:21:55 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v4]
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update method name and test case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15143/files
  - new: https://git.openjdk.org/jdk/pull/15143/files/f33a565c..b46537be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=02-03

  Stats: 16 lines in 2 files changed: 7 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143

PR: https://git.openjdk.org/jdk/pull/15143

From duke at openjdk.org  Wed Aug  9 00:21:56 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 9 Aug 2023 00:21:56 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v3]
In-Reply-To: <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <5Wn_3WxejUtaqO99qbq9P2ffWVodUzVZapw_tfdcqb8=.f2901dfd-0ac3-4449-974f-38be43242a68@github.com>
Message-ID: <MvYsLnFjHLgiawe15aaU_YUGEJRKXjOuc8Yw68-iS6Q=.51865203-c3f5-4c82-9d27-aa8fbe5bb1da@github.com>

On Fri, 4 Aug 2023 19:09:58 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update error message

1) Update the name of the methods
2) Update the test file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1670475452

From naoto at openjdk.org  Wed Aug  9 00:46:58 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 9 Aug 2023 00:46:58 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v7]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <1rFouxpbzGLybnxXGslNTnoMIZC7MjrEU1zvDCKaqi0=.d3566682-582f-4a26-81c2-76f35f6fed5c@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Small cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/516c00c7..7760656a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From erdong.me at gmail.com  Wed Aug  9 01:00:00 2023
From: erdong.me at gmail.com (Erdong Ren)
Date: Wed, 9 Aug 2023 09:00:00 +0800
Subject: A Discussion on Wrapper Class Source Code
Message-ID: <CAPHV=GAhNvESEtxmYby4KxOq36y6F9cp068hW69UZrVVX0YZvw@mail.gmail.com>

Hello everyone,

My name is Ren Erdong, and I am a Java developer from China. It's a
pleasure to meet all of you, and I'm excited to join this community.

While reading the source code of the wrapper classes, I have identified
some areas that could potentially be optimized. However, I acknowledge that
my considerations may not be comprehensive. Therefore, I would like to
initiate a discussion with all of you to gather different perspectives and
collectively explore possible optimizations.

Actually, prior to this, I sent an email to the community, but it was held,
stating that the message body was too large.

*If this type of email shouldn't have been sent to this community, then I
sincerely apologize. Please forgive me as a newcomer. I would appreciate
your guidance on how to handle this matter correctly. Thank you very much!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230809/2a82b3e1/attachment-0001.htm>

From liangchenblue at gmail.com  Wed Aug  9 01:04:30 2023
From: liangchenblue at gmail.com (-)
Date: Wed, 9 Aug 2023 09:04:30 +0800
Subject: A Discussion on Wrapper Class Source Code
In-Reply-To: <CAPHV=GAhNvESEtxmYby4KxOq36y6F9cp068hW69UZrVVX0YZvw@mail.gmail.com>
References: <CAPHV=GAhNvESEtxmYby4KxOq36y6F9cp068hW69UZrVVX0YZvw@mail.gmail.com>
Message-ID: <CABe8uE3kfNxWYx8BXOrEoYurebBk3F+JEPBz6=YU89NY4q-uLw@mail.gmail.com>

If your email was withheld for having a too large body, I recommend you to
send a summary to this core-libs-dev mailing list instead. Your current
topic lists no RFEs for optimization and thus is not helpful, so I wish to
see your summaries (as bullet points). You can talk about the details in
follow-up reply emails to the original message in the list.

Chen Liang

On Wed, Aug 9, 2023 at 9:01?AM Erdong Ren <erdong.me at gmail.com> wrote:

> Hello everyone,
>
> My name is Ren Erdong, and I am a Java developer from China. It's a
> pleasure to meet all of you, and I'm excited to join this community.
>
> While reading the source code of the wrapper classes, I have identified
> some areas that could potentially be optimized. However, I acknowledge that
> my considerations may not be comprehensive. Therefore, I would like to
> initiate a discussion with all of you to gather different perspectives and
> collectively explore possible optimizations.
>
> Actually, prior to this, I sent an email to the community, but it was
> held, stating that the message body was too large.
>
> *If this type of email shouldn't have been sent to this community, then I
> sincerely apologize. Please forgive me as a newcomer. I would appreciate
> your guidance on how to handle this matter correctly. Thank you very much!*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230809/7b9dfafe/attachment.htm>

From vtewari at openjdk.org  Wed Aug  9 04:11:32 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 9 Aug 2023 04:11:32 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v4]
In-Reply-To: <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>
Message-ID: <vYNrWS_OJ7GemuabUtSgHMQlA6xkG8wAbgfHWZzcxmA=.853b7fd9-e464-4122-8c6c-481d73a7d3f7@github.com>

On Wed, 9 Aug 2023 00:21:55 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update method name and test case

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 118:

> 116:         private LdapOutputStream los;
> 117:         private ByteArrayInputStream bos;
> 118:         int pos = 0;

variable 'pos' is not used can be removed.

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 127:

> 125:         public int read() throws IOException {
> 126:             bos = new ByteArrayInputStream(BIND_RESPONSE);
> 127:             int next = bos.read();

can be simplified as follows return bos.read();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1287907584
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1287908154

From vtewari at openjdk.org  Wed Aug  9 05:02:36 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 9 Aug 2023 05:02:36 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v4]
In-Reply-To: <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>
Message-ID: <NIuaU4Bv8N87N80efEGL3H8CsXmAt54pAfy6iPMo3zA=.87d45fe0-442d-4625-944b-32bf6b7abe03@github.com>

On Wed, 9 Aug 2023 00:21:55 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update method name and test case

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 81:

> 79: 
> 80:     public static class CustomSocketFactory extends SocketFactory {
> 81:         public static CustomSocket customSocket = new CustomSocket();

you can make 'customSocket' to private.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1287937502

From jpai at openjdk.org  Wed Aug  9 06:41:35 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 9 Aug 2023 06:41:35 GMT
Subject: RFR: 8313768: Reduce interaction with volatile field in
 j.u.l.StreamHandler
In-Reply-To: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>
References: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>
Message-ID: <Pg97nK6TBmvd4TMtBJpKeie0fXFtvXpQhXkyZWFxBUI=.f4d334a4-7375-434d-bbd4-9a44703fe2c6@github.com>

On Fri, 4 Aug 2023 14:51:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> In `publish0()`, `flush0()` and `flushAndClose()`methods of `StreamHandler` we read multiple times from volatile writer. The access number can be reduced by reading the field into local variable once.

The change looks fine to me. 

I have triggered a CI run and will sponsor once that completes (I don't expect any regressions here given the nature of this change).

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15161#pullrequestreview-1568845719

From mbaesken at openjdk.org  Wed Aug  9 08:42:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Aug 2023 08:42:35 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v2]
In-Reply-To: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
Message-ID: <FlgB8jg8E8b7CVfcoSAhzlev1iwDhgJIhSCG4XLhJEM=.f96e82b2-a5c6-4c77-bc9e-e7e389d325ae@github.com>

> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use Platform.sharedLibraryPrefix in more tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15151/files
  - new: https://git.openjdk.org/jdk/pull/15151/files/c99d984d..e708bb68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=00-01

  Stats: 9 lines in 3 files changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151

PR: https://git.openjdk.org/jdk/pull/15151

From asotona at openjdk.org  Wed Aug  9 09:07:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 9 Aug 2023 09:07:59 GMT
Subject: [jdk21] RFR: 8313312: Add missing classpath exception copyright
 header
In-Reply-To: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
References: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
Message-ID: <GYqwunWvACUeAabIhu7738whV_twgus2P2p9zFkzayY=.6489c6e3-f47c-4f94-95ab-9bd6b74b8456@github.com>

On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The same copyright updates are needed in JDK21.

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/166#pullrequestreview-1569051344

From dnsimon at openjdk.org  Wed Aug  9 09:56:29 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 9 Aug 2023 09:56:29 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
Message-ID: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>

In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:

java.lang.OutOfMemoryError: Metaspace
        at jdk.internal.vm.TranslatedException.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:176)
        at jdk.internal.vm.TranslatedException.<clinit>([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:61)
        at jdk.internal.vm.VMSupport.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/VMSupport.java:171)

This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.

The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

-------------

Commit messages:
 - handle exception in TranslatedException.<clinit> (JDK-8313899)

Changes: https://git.openjdk.org/jdk/pull/15198/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15198&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313899
  Stats: 43 lines in 3 files changed: 41 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15198/head:pull/15198

PR: https://git.openjdk.org/jdk/pull/15198

From never at openjdk.org  Wed Aug  9 09:56:29 2023
From: never at openjdk.org (Tom Rodriguez)
Date: Wed, 9 Aug 2023 09:56:29 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <yOZ1jB0NNvOw3IaiayZqMYBqDd3prXTbA6sjPmQy1Ck=.50e4ceb8-9578-43bd-830a-dd3aa09cc88d@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable([java.base at 21-galahadeestaging](mailto:java.base at 21-galahadeestaging)/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

Looks good.

-------------

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1568664065

From mbaesken at openjdk.org  Wed Aug  9 11:06:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Aug 2023 11:06:04 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v3]
In-Reply-To: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
Message-ID: <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>

> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Introduce buildSharedLibraryName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15151/files
  - new: https://git.openjdk.org/jdk/pull/15151/files/e708bb68..9f9c5b25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=01-02

  Stats: 50 lines in 9 files changed: 10 ins; 25 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/15151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151

PR: https://git.openjdk.org/jdk/pull/15151

From mbaesken at openjdk.org  Wed Aug  9 11:06:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Aug 2023 11:06:28 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v2]
In-Reply-To: <FlgB8jg8E8b7CVfcoSAhzlev1iwDhgJIhSCG4XLhJEM=.f96e82b2-a5c6-4c77-bc9e-e7e389d325ae@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <FlgB8jg8E8b7CVfcoSAhzlev1iwDhgJIhSCG4XLhJEM=.f96e82b2-a5c6-4c77-bc9e-e7e389d325ae@github.com>
Message-ID: <quk8ZcJNGSKzaNpYcF0_4OmYe4CtaNpM3yTNCCikgrc=.1ae227a9-8d68-4beb-abfc-8c7cd1f4245d@github.com>

On Wed, 9 Aug 2023 08:42:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Platform.sharedLibraryPrefix in more tests

Hello, as suggested I introduced a Platform.buildSharedLibraryName; this can be used to simplify a lot of code in the mentioned tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15151#issuecomment-1671099342

From duke at openjdk.org  Wed Aug  9 12:52:35 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 9 Aug 2023 12:52:35 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v5]
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  class access modifier

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15143/files
  - new: https://git.openjdk.org/jdk/pull/15143/files/b46537be..e3e98226

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143

PR: https://git.openjdk.org/jdk/pull/15143

From duke at openjdk.org  Wed Aug  9 12:52:37 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 9 Aug 2023 12:52:37 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v4]
In-Reply-To: <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <NlN7yjCWkoT90_ofsoBGTt22eS29sJGTQy2GkyxGJII=.926e56b9-f5ee-4254-989a-3dc2a3357462@github.com>
Message-ID: <Xdad44t-n2hoqp9NRYpJRtor5jEk7btNQYniE9BYYgg=.078dced1-7d35-4b5a-822c-8faacb9afc27@github.com>

On Wed, 9 Aug 2023 00:21:55 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update method name and test case

1) Cannot make CustomSocket be private. The test failed. I believe JDK is using the reflection to load the class.
2) The rest of the changes are based on the comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1671228915

From jlaskey at openjdk.org  Wed Aug  9 15:09:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Aug 2023 15:09:28 GMT
Subject: [jdk21] RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
Message-ID: <50kfXNimeZWhteKRG-BN4vk1PJK069jzuXT7enZ_X18=.e1a488c4-67d1-4bf9-9153-4e423c4075e5@github.com>

8313809: String template fails with java.lang.StringIndexOutOfBoundsException if last fragment is UTF16

-------------

Commit messages:
 - Backport 6864441163f946d0bec7380a2a120e31b812a6dc

Changes: https://git.openjdk.org/jdk21/pull/170/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313809
  Stats: 49 lines in 2 files changed: 45 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk21/pull/170.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/170/head:pull/170

PR: https://git.openjdk.org/jdk21/pull/170

From redestad at openjdk.org  Wed Aug  9 15:20:30 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 9 Aug 2023 15:20:30 GMT
Subject: [jdk21] RFR: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
In-Reply-To: <50kfXNimeZWhteKRG-BN4vk1PJK069jzuXT7enZ_X18=.e1a488c4-67d1-4bf9-9153-4e423c4075e5@github.com>
References: <50kfXNimeZWhteKRG-BN4vk1PJK069jzuXT7enZ_X18=.e1a488c4-67d1-4bf9-9153-4e423c4075e5@github.com>
Message-ID: <yFmKT0jozw8EhzNSgcDh-3QuKKzeYLvh8S8kw5lP2iQ=.5ee5c1dd-153f-4f9e-a923-5214c55d3508@github.com>

On Wed, 9 Aug 2023 14:41:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> 8313809: String template fails with java.lang.StringIndexOutOfBoundsException if last fragment is UTF16

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk21/pull/170#pullrequestreview-1569868331

From jlaskey at openjdk.org  Wed Aug  9 15:35:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 9 Aug 2023 15:35:58 GMT
Subject: [jdk21] Integrated: 8313809: String template fails with
 java.lang.StringIndexOutOfBoundsException if last fragment is UTF16
In-Reply-To: <50kfXNimeZWhteKRG-BN4vk1PJK069jzuXT7enZ_X18=.e1a488c4-67d1-4bf9-9153-4e423c4075e5@github.com>
References: <50kfXNimeZWhteKRG-BN4vk1PJK069jzuXT7enZ_X18=.e1a488c4-67d1-4bf9-9153-4e423c4075e5@github.com>
Message-ID: <7fL60P7OD8ejrzzHrRecH6Mvs8Ly9yfo5AvOhAyLo6o=.9fb2bebd-f1f0-4bb5-bc2c-512a00c1ce8c@github.com>

On Wed, 9 Aug 2023 14:41:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> 8313809: String template fails with java.lang.StringIndexOutOfBoundsException if last fragment is UTF16

This pull request has now been integrated.

Changeset: c746fc01
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk21/commit/c746fc013cb9a765b374e77d1af24b1557e3691b
Stats:     49 lines in 2 files changed: 45 ins; 2 del; 2 mod

8313809: String template fails with java.lang.StringIndexOutOfBoundsException if last fragment is UTF16

Reviewed-by: redestad
Backport-of: 6864441163f946d0bec7380a2a120e31b812a6dc

-------------

PR: https://git.openjdk.org/jdk21/pull/170

From mcimadamore at openjdk.org  Wed Aug  9 17:38:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 9 Aug 2023 17:38:59 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v4]
In-Reply-To: <qW_vDSWY9ZytLSINBu7CGh2Bt8tQx-ndaoZNf9jEQ7A=.5374490f-0991-49c7-8208-2ccbe4d7cf70@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
 <qW_vDSWY9ZytLSINBu7CGh2Bt8tQx-ndaoZNf9jEQ7A=.5374490f-0991-49c7-8208-2ccbe4d7cf70@github.com>
Message-ID: <MQDlewvf8W9eHRza2ndASb9nwvLp6WAr9FsW4ARkduE=.372a57ed-1457-43e9-baf4-3d338083bd6c@github.com>

On Tue, 8 Aug 2023 08:35:51 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.
>
> Per Minborg 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 seven additional commits since the last revision:
> 
>  - Add snippet for MS::allocateArray methods
>  - Merge branch 'master' into segallocjavadoc
>  - Simplify snippets
>  - Update after comments
>  - Update array methods
>  - Improve javadocs
>  - Update javadocs for SegmentAllocator::allocate methods

Looks good.

src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java line 352:

> 350:      *  int size = Objects.requireNonNull(elements).length;
> 351:      *  MemorySegment seg = allocateArray(Objects.requireNonNull(elementLayout), size);
> 352:      *  MemorySegment.copy(MemorySegment.ofArray(elements), elementLayout, 0,

there's overloads for copy which accepts the array directly too - so no need to wrap the array into an heap segments - that should simplify the snippet some more

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14997#pullrequestreview-1570211102
PR Review Comment: https://git.openjdk.org/jdk/pull/14997#discussion_r1288945094

From vtewari at openjdk.org  Wed Aug  9 18:08:29 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 9 Aug 2023 18:08:29 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v5]
In-Reply-To: <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>
Message-ID: <0S2Wq4UxWU010uZqPwjo5nxV0X0xs24VMuB5Nxl0l1M=.2a4f197c-f06a-478c-bbe9-81db66e4b4f4@github.com>

On Wed, 9 Aug 2023 12:52:35 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class access modifier

Latest code looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15143#pullrequestreview-1570238198

From cjplummer at openjdk.org  Wed Aug  9 18:21:31 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Aug 2023 18:21:31 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v3]
In-Reply-To: <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>
Message-ID: <R8D_QIVUcaJGnaq7VsahvB-f2mX2SZeCrcRU4cfGLo8=.a8eee31e-ed3f-47aa-94e9-9845e36f856c@github.com>

On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce buildSharedLibraryName

Needs copyright updates, but otherwise looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1570274636

From dl at openjdk.org  Wed Aug  9 18:47:31 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 9 Aug 2023 18:47:31 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v3]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <fhGXnFG1Qn7l26xCRkINyJZQItAWleIrbKpnXJOh_YY=.3e164146-e1cd-4c1d-8423-e5248871402c@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 43 additional commits since the last revision:

 - resync
 - Merge branch 'openjdk:master' into JDK-8288899
 - ExecutorService tests
 - Merge branch 'openjdk:master' into JDK-8288899
 - Rework versioning
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 33 more: https://git.openjdk.org/jdk/compare/718dd22f...bec6e207

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/e29bbca3..bec6e207

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=01-02

  Stats: 9657 lines in 433 files changed: 4091 ins; 2892 del; 2674 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From prappo at openjdk.org  Wed Aug  9 20:59:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 9 Aug 2023 20:59:58 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v5]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <kIeR-CBy6fzgTGETqEDb3bdbgCmRmr_rrKA8whgqIxw=.3e03b3e2-f033-45e6-9fbd-9904069fb39e@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Group params coarser (suggested by @cl4es)
   
   - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
     Every testXYZ method invokes M operations, where M is the maximum
     number of elements in a group. Shorter groups are cyclically padded.
   - Uses the org.openjdk.jmh.infra.Blackhole API and increases
     benchmark time.
   - Fixes a bug in Shared that precluded 0 from being in a pair.
 - Use better overloads (suggested by @cl4es)
   
   - Uses simpler, more suitable overloads for the subrange
     starting from 0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/eb4b9775..5af2d5dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=03-04

  Stats: 189 lines in 5 files changed: 75 ins; 86 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

PR: https://git.openjdk.org/jdk/pull/14630

From sspitsyn at openjdk.org  Wed Aug  9 22:46:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Aug 2023 22:46:28 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v3]
In-Reply-To: <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>
Message-ID: <oFMMRBNkQB-hZMYSidOFm6VfqsmlhMiHvRfZME-hz0Y=.c2fe1be6-1142-4757-854e-06f70aa80511@github.com>

On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce buildSharedLibraryName

Thank you for the update.
Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1570707364

From prappo at openjdk.org  Wed Aug  9 22:54:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 9 Aug 2023 22:54:28 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
Message-ID: <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>

> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
> 
> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.

Pavel Rappo 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 13 additional commits since the last revision:

 - Fix bugs in Shared.createSingle
 - Merge branch 'master' into 8310813
 - Group params coarser (suggested by @cl4es)
   
   - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
     Every testXYZ method invokes M operations, where M is the maximum
     number of elements in a group. Shorter groups are cyclically padded.
   - Uses the org.openjdk.jmh.infra.Blackhole API and increases
     benchmark time.
   - Fixes a bug in Shared that precluded 0 from being in a pair.
 - Use better overloads (suggested by @cl4es)
   
   - Uses simpler, more suitable overloads for the subrange
     starting from 0
 - Improve benchmarks
 - Merge branch 'master' into 8310813
 - Restore hash code values
   
   BigInteger is old and ubiquitous enough so that there might be
   inadvertent dependencies on its hash code.
   
   This commit also includes a test, to make sure hash code is
   unchanged.
 - Merge branch 'master' into 8310813
 - Add a benchmark
 - Merge branch 'master' into 8310813
 - ... and 3 more: https://git.openjdk.org/jdk/compare/5907d416...6fa3f694

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14630/files
  - new: https://git.openjdk.org/jdk/pull/14630/files/5af2d5dc..6fa3f694

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=04-05

  Stats: 23666 lines in 977 files changed: 10910 ins; 6105 del; 6651 mod
  Patch: https://git.openjdk.org/jdk/pull/14630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630

PR: https://git.openjdk.org/jdk/pull/14630

From redestad at openjdk.org  Wed Aug  9 23:02:59 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 9 Aug 2023 23:02:59 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
Message-ID: <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>

On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo 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 13 additional commits since the last revision:
> 
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - Add a benchmark
>  - Merge branch 'master' into 8310813
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d5d285cb...6fa3f694

This looks good, thanks for the microbenchmark updates.

Your work on this PR was what prompted me to look at `ArraysSupport.mismatch` performance. The patch in #15197 should mitigate at least some of the overhead we've seen on small `BigInteger` objects on `equals` and `compareTo` micros

test/micro/org/openjdk/bench/java/math/Shared.java line 82:

> 80:         }
> 81:         int nBytes = (nBits + 7) / 8;
> 82:         var r = new Random();

Some have a preference for providing a seed for `Random` instances in micros. Either hard-coded or through a `@Param` (I find this a bit excessive). Doing so might reduce run-to-run noise.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14630#pullrequestreview-1570712845
PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289313113

From joehw at openjdk.org  Thu Aug 10 00:03:58 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 10 Aug 2023 00:03:58 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v7]
In-Reply-To: <1rFouxpbzGLybnxXGslNTnoMIZC7MjrEU1zvDCKaqi0=.d3566682-582f-4a26-81c2-76f35f6fed5c@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <1rFouxpbzGLybnxXGslNTnoMIZC7MjrEU1zvDCKaqi0=.d3566682-582f-4a26-81c2-76f35f6fed5c@github.com>
Message-ID: <sO7CsYC2Jkv4KjsNvditGur9EjGSrzwYeXezvds3VKc=.1d2c193d-67eb-4be9-a0b7-5d262038f874@github.com>

On Wed, 9 Aug 2023 00:46:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small cleanup

src/java.base/share/classes/java/text/ListFormat.java line 58:

> 56:  *     .format(List.of("Foo", "Bar", "Baz"))
> 57:  * }
> 58:  * This will produce the concatenated list string, "Foo, Bar, and Baz" as seen in

With this sample code, if the Style is changed to SHORT, it would produce the same string. Would it be better to use the weekdays instead of Foo, Bar and Baz (as in the Unicode spec)? Esp. with the UNIT type, those examples explained it better, e.g. NARROW produces 3? 7?.

Also, if the instance is of STANDARD/SHORT, does it format List.of("January", "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches to 3 ft, 7 in? The format method states simply "Returns the string that consists of the input strings, concatenated with the patterns of this ListFormat."  I wonder if it'd be helpful to explain a bit more or add one more sample.

src/java.base/share/classes/java/text/ListFormat.java line 71:

> 69:  * <tr><th scope="row" style="text-align:left">STANDARD</th>
> 70:  *     <td>Foo, Bar, and Baz</td>
> 71:  *     <td>Foo, Bar, &amp; Baz</td>

Is "&amp;" a typo?  It's still "and" in the Unicode spec's "standard-short" format, e.g. "Jan., Feb., and Mar."

src/java.base/share/classes/java/text/ListFormat.java line 408:

> 406:         var em = endPattern.matcher(source);
> 407:         Object parsed = null;
> 408:         if (sm.find(parsePos.index) && em.find(parsePos.index)) {

Would it be better to call getIndex() instead? (same below)

test/jdk/java/text/Format/ListFormat/TestListFormat.java line 157:

> 155:                         "foo, bar, baz", true),
> 156:                 arguments(Locale.US, ListFormat.Type.OR, ListFormat.Style.NARROW,
> 157:                         "foo, bar, or baz", true),

Same as in the ListFormat class, the expected results are the same "foo, bar, or baz" when different Styles are specified.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1289362909
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1289364452
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1289352495
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1289365866

From dholmes at openjdk.org  Thu Aug 10 05:36:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 05:36:58 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <K_ggA4vD7lnYTQUW2Q7mjOFF_Jo_nL_Frmf-Bth9c04=.ee51d623-5549-40ef-82b4-d12b02820a4c@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Hotspot test changes look fine. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15103#pullrequestreview-1571033557

From stsypanov at openjdk.org  Thu Aug 10 06:07:29 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 10 Aug 2023 06:07:29 GMT
Subject: Integrated: 8313768: Reduce interaction with volatile field in
 j.u.l.StreamHandler
In-Reply-To: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>
References: <eW_mOT-ny339wTvp9MbLsNhTgOay87DI9Ic3KXFkVtk=.3797aba3-f959-48ce-b217-c543ca2cf236@github.com>
Message-ID: <EMwZnvhzq5YEGjrJU4z35p3-wB-D81wrxNFiHnIY0vM=.93262194-09b2-411b-856d-13ee6ed8829f@github.com>

On Fri, 4 Aug 2023 14:51:35 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> In `publish0()`, `flush0()` and `flushAndClose()`methods of `StreamHandler` we read multiple times from volatile writer. The access number can be reduced by reading the field into local variable once.

This pull request has now been integrated.

Changeset: c822183e
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c822183e98aa26f005338464f3946dcbf34802aa
Stats:     7 lines in 1 file changed: 6 ins; 1 del; 0 mod

8313768: Reduce interaction with volatile field in j.u.l.StreamHandler

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15161

From mbaesken at openjdk.org  Thu Aug 10 07:44:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Aug 2023 07:44:58 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v4]
In-Reply-To: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
Message-ID: <Xt7aewdTt1LFFT_IlR83eFv3b3mob8Cq5V5Dshb0-jQ=.65765f6d-dfb2-4c17-b7df-20b9cd487c29@github.com>

> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust COPYRIGHT headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15151/files
  - new: https://git.openjdk.org/jdk/pull/15151/files/9f9c5b25..5e8dfa79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15151&range=02-03

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151

PR: https://git.openjdk.org/jdk/pull/15151

From mbaesken at openjdk.org  Thu Aug 10 07:48:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Aug 2023 07:48:02 GMT
Subject: Integrated: JDK-8313670: Simplify shared lib name handling code in
 some tests
In-Reply-To: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
Message-ID: <cvZe-vyhsVGli9Qga8r6F38-_0HcqbHOS_Pr4bWDYos=.661e3cef-d3ae-4b62-b422-d949fb62c200@github.com>

On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is coding e.g. in
> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
> that deals with shared lib naming on different OS.
> This code should be simplified.

This pull request has now been integrated.

Changeset: 6dba2026
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6dba2026d72de6a67aa0209749ded8174b088904
Stats:     130 lines in 9 files changed: 22 ins; 87 del; 21 mod

8313670: Simplify shared lib name handling code in some tests

Reviewed-by: cjplummer, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/15151

From mbaesken at openjdk.org  Thu Aug 10 07:47:58 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Aug 2023 07:47:58 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v3]
In-Reply-To: <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <jUqYTEbMDvF4CO0g-7mmkN5sFjaJFMCyv6Db9CKlotQ=.73143c16-c9ed-409d-b2fb-0eebe7d143d2@github.com>
Message-ID: <8CSDWiLaG1Ny0Z81n2R_qsVUbF-URNetXDfoCclLXUU=.5c6d9e7a-de4f-41bf-9ed8-2c2fb48f8f31@github.com>

On Wed, 9 Aug 2023 11:06:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce buildSharedLibraryName

Hi Chris and Serguei, thanks for the reviews !  I adjusted the COPYRIGHT years.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15151#issuecomment-1672693986

From dholmes at openjdk.org  Thu Aug 10 08:06:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 08:06:58 GMT
Subject: RFR: JDK-8313670: Simplify shared lib name handling code in some
 tests [v4]
In-Reply-To: <Xt7aewdTt1LFFT_IlR83eFv3b3mob8Cq5V5Dshb0-jQ=.65765f6d-dfb2-4c17-b7df-20b9cd487c29@github.com>
References: <rc5S_IIBaSZEYuHCsp-XC2KFSQ1IYDxzWJ3Cvm6qW2U=.65b41d89-9f1f-4d93-a740-4392cfe11e0f@github.com>
 <Xt7aewdTt1LFFT_IlR83eFv3b3mob8Cq5V5Dshb0-jQ=.65765f6d-dfb2-4c17-b7df-20b9cd487c29@github.com>
Message-ID: <-ozXnVe5STjD6ltTvUVIxOzTbAs0YN8dD9rq0iBCKQA=.e2e1a087-47ad-4103-811d-4b693eec23ab@github.com>

On Thu, 10 Aug 2023 07:44:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is coding e.g. in
>> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72
>> that deals with shared lib naming on different OS.
>> This code should be simplified.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust COPYRIGHT headers

A belated thumbs up from me too. Thanks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1571269550

From pminborg at openjdk.org  Thu Aug 10 08:31:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Aug 2023 08:31:59 GMT
Subject: Integrated: 8298095: Refine implSpec for SegmentAllocator
In-Reply-To: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
Message-ID: <gazpxr1ua8CXMqCQs8wyi45EKNHwDsOoaYHi-TICm84=.b6220c60-a3aa-4bad-9a8f-4d8f9b642b4c@github.com>

On Mon, 24 Jul 2023 12:32:59 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.

This pull request has now been integrated.

Changeset: 35b60f92
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35b60f925a4e7e2e3f1ec7c5c1eee60206e7508a
Stats:     249 lines in 1 file changed: 147 ins; 21 del; 81 mod

8298095: Refine implSpec for SegmentAllocator

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14997

From pminborg at openjdk.org  Thu Aug 10 08:31:29 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 10 Aug 2023 08:31:29 GMT
Subject: RFR: 8298095: Refine implSpec for SegmentAllocator [v5]
In-Reply-To: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
References: <MYKIf86teO-EoEjeqII6aRsex4ZBxS9bOAQHRS5c59o=.39a950db-d4e6-40a8-bd40-80822fea06da@github.com>
Message-ID: <DoYmJLO12WggU9BFzj-3LFgD9vQReqV10iVOTjnewGM=.e019d3db-b749-4293-97d7-03c10f1e8b8b@github.com>

> This PR suggests refining the `@implSpec` for the SegmentAllocator::allocate methods as well as clarifying the docs a bit more. Also, a local variable is renamed.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Simplify java snippets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14997/files
  - new: https://git.openjdk.org/jdk/pull/14997/files/c7544307..f0f80b85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14997&range=03-04

  Stats: 14 lines in 1 file changed: 0 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14997/head:pull/14997

PR: https://git.openjdk.org/jdk/pull/14997

From clanger at openjdk.org  Thu Aug 10 10:24:31 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 10 Aug 2023 10:24:31 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on Windows
 when run as user with Administrator privileges
Message-ID: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>

On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible.

-------------

Commit messages:
 - JDK-8314094

Changes: https://git.openjdk.org/jdk/pull/15222/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15222&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314094
  Stats: 21 lines in 1 file changed: 14 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15222.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15222/head:pull/15222

PR: https://git.openjdk.org/jdk/pull/15222

From cstein at openjdk.org  Thu Aug 10 11:10:58 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 10 Aug 2023 11:10:58 GMT
Subject: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from problem
 list
Message-ID: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>

Please review this change to remove Unit-based tests in `java/lang/invoke` from `jdk`'s problem list. The underlying race condition in jtreg was fixed in release 7.3; which is now the default version used in JDK mainline development.

-------------

Commit messages:
 - Update ProblemList.txt

Changes: https://git.openjdk.org/jdk/pull/15206/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15206&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314025
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15206/head:pull/15206

PR: https://git.openjdk.org/jdk/pull/15206

From jpai at openjdk.org  Thu Aug 10 11:10:59 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Aug 2023 11:10:59 GMT
Subject: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from
 problem list
In-Reply-To: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
References: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
Message-ID: <3cl4LQGh4jrJpgoamw41d7mjrpq0pgVAAXI5TdNm6pE=.8e733cee-6b03-482b-a5f1-9d86c720e9df@github.com>

On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove Unit-based tests in `java/lang/invoke` from `jdk`'s problem list. The underlying race condition in jtreg was fixed in release 7.3; which is now the default version used in JDK mainline development.

Hello Christian, I think this PR should also be linked against the problem listed JBS issue https://bugs.openjdk.org/browse/JDK-8312482 so that when this is integrated that issue gets resolved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15206#issuecomment-1672989075

From prappo at openjdk.org  Thu Aug 10 11:37:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 10 Aug 2023 11:37:58 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <c9GuApl0qzJFK49dRu5w1xD4DPAxeiU7pz59PdG3RhY=.e8c94627-d90e-44d6-af66-44b7533c379d@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
 <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>
 <c9GuApl0qzJFK49dRu5w1xD4DPAxeiU7pz59PdG3RhY=.e8c94627-d90e-44d6-af66-44b7533c379d@github.com>
Message-ID: <Q7rlwlCsQy1AW8wU_AFnwHraRGgcFwqSFh8YNshjj_8=.4354103f-3c45-4f13-99e2-66c8946332d3@github.com>

On Thu, 10 Aug 2023 11:13:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> AFAIK, if you need reproducible randoms in tests, you should add the tags:
> 
> ```
>  * @key randomness
>  * @library /test/lib
> ```
> 
> and initialize your random generator with
> 
> ```
> import jdk.test.lib.RandomFactory;
> ...
> Random rnd = RandomFactory.getRandom();
> ```
> 
> This prints the seed to STDOUT.

It'd be applicable for tests, but not for benchmarks. Also, the point that @cl4es seems to make is that randomness is captured and set up to reduce noise, not to be able to reproduce "benchmark failures".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289976177

From rgiulietti at openjdk.org  Thu Aug 10 11:36:58 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Aug 2023 11:36:58 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
 <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>
Message-ID: <c9GuApl0qzJFK49dRu5w1xD4DPAxeiU7pz59PdG3RhY=.e8c94627-d90e-44d6-af66-44b7533c379d@github.com>

On Wed, 9 Aug 2023 22:36:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Pavel Rappo 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 13 additional commits since the last revision:
>> 
>>  - Fix bugs in Shared.createSingle
>>  - Merge branch 'master' into 8310813
>>  - Group params coarser (suggested by @cl4es)
>>    
>>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>>      Every testXYZ method invokes M operations, where M is the maximum
>>      number of elements in a group. Shorter groups are cyclically padded.
>>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>>      benchmark time.
>>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>>  - Use better overloads (suggested by @cl4es)
>>    
>>    - Uses simpler, more suitable overloads for the subrange
>>      starting from 0
>>  - Improve benchmarks
>>  - Merge branch 'master' into 8310813
>>  - Restore hash code values
>>    
>>    BigInteger is old and ubiquitous enough so that there might be
>>    inadvertent dependencies on its hash code.
>>    
>>    This commit also includes a test, to make sure hash code is
>>    unchanged.
>>  - Merge branch 'master' into 8310813
>>  - Add a benchmark
>>  - Merge branch 'master' into 8310813
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3425a24d...6fa3f694
>
> test/micro/org/openjdk/bench/java/math/Shared.java line 82:
> 
>> 80:         }
>> 81:         int nBytes = (nBits + 7) / 8;
>> 82:         var r = new Random();
> 
> Some have a preference for providing a seed for `Random` instances in micros. Either hard-coded or through a `@Param` (I find this a bit excessive). Doing so might reduce run-to-run noise.

AFAIK, if you need reproducible randoms in tests, you should add the tags:

 * @key randomness
 * @library /test/lib

and initialize your random generator with

import jdk.test.lib.RandomFactory;
...
Random rnd = RandomFactory.getRandom();

This prints the seed to STDOUT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289966641

From rgiulietti at openjdk.org  Thu Aug 10 11:38:28 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 10 Aug 2023 11:38:28 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <Q7rlwlCsQy1AW8wU_AFnwHraRGgcFwqSFh8YNshjj_8=.4354103f-3c45-4f13-99e2-66c8946332d3@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
 <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>
 <c9GuApl0qzJFK49dRu5w1xD4DPAxeiU7pz59PdG3RhY=.e8c94627-d90e-44d6-af66-44b7533c379d@github.com>
 <Q7rlwlCsQy1AW8wU_AFnwHraRGgcFwqSFh8YNshjj_8=.4354103f-3c45-4f13-99e2-66c8946332d3@github.com>
Message-ID: <JDcrO1nerQuSDvqTzWaSCfcyHGPehTWceoDp0TOIzec=.90eec047-7021-4873-ae53-996403c0959f@github.com>

On Thu, 10 Aug 2023 11:23:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> AFAIK, if you need reproducible randoms in tests, you should add the tags:
>> 
>>  * @key randomness
>>  * @library /test/lib
>> 
>> and initialize your random generator with
>> 
>> import jdk.test.lib.RandomFactory;
>> ...
>> Random rnd = RandomFactory.getRandom();
>> 
>> This prints the seed to STDOUT.
>
>> AFAIK, if you need reproducible randoms in tests, you should add the tags:
>> 
>> ```
>>  * @key randomness
>>  * @library /test/lib
>> ```
>> 
>> and initialize your random generator with
>> 
>> ```
>> import jdk.test.lib.RandomFactory;
>> ...
>> Random rnd = RandomFactory.getRandom();
>> ```
>> 
>> This prints the seed to STDOUT.
> 
> It'd be applicable for tests, but not for benchmarks. Also, the point that @cl4es seems to make is that randomness is captured and set up to reduce noise, not to be able to reproduce "benchmark failures".

My bad. Forget my note

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289981733

From prappo at openjdk.org  Thu Aug 10 11:52:00 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 10 Aug 2023 11:52:00 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
Message-ID: <PtaGzKPth_wow6m60jFepz2MwqBMH376o9bugDmQrVI=.5c60b2c8-24be-43bb-a4e3-9455aa70bbb2@github.com>

On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo 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 13 additional commits since the last revision:
> 
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - Add a benchmark
>  - Merge branch 'master' into 8310813
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/16b32b66...6fa3f694

Here's a status update for this PR. I'm currently benchmarking baseline against this PR and this PR plus changes in https://github.com/openjdk/jdk/pull/15197. It's a 3-way benchmark, so to speak. Its purpose is to see whether performance degradation brought by this PR to `equals` and `compareTo` can be sufficiently offset by the improved `ArraysSupport.mismatch` mechanics.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1673056244

From prappo at openjdk.org  Thu Aug 10 11:52:58 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 10 Aug 2023 11:52:58 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <JDcrO1nerQuSDvqTzWaSCfcyHGPehTWceoDp0TOIzec=.90eec047-7021-4873-ae53-996403c0959f@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
 <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>
 <c9GuApl0qzJFK49dRu5w1xD4DPAxeiU7pz59PdG3RhY=.e8c94627-d90e-44d6-af66-44b7533c379d@github.com>
 <Q7rlwlCsQy1AW8wU_AFnwHraRGgcFwqSFh8YNshjj_8=.4354103f-3c45-4f13-99e2-66c8946332d3@github.com>
 <JDcrO1nerQuSDvqTzWaSCfcyHGPehTWceoDp0TOIzec=.90eec047-7021-4873-ae53-996403c0959f@github.com>
Message-ID: <ltY1m2hnILSeJpp-PvmLcLneR55xiQ1jKKZDKVO_pP8=.4fb048f3-bb41-4c3a-9096-22326c36a134@github.com>

On Thu, 10 Aug 2023 11:28:39 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> AFAIK, if you need reproducible randoms in tests, you should add the tags:
>>> 
>>> ```
>>>  * @key randomness
>>>  * @library /test/lib
>>> ```
>>> 
>>> and initialize your random generator with
>>> 
>>> ```
>>> import jdk.test.lib.RandomFactory;
>>> ...
>>> Random rnd = RandomFactory.getRandom();
>>> ```
>>> 
>>> This prints the seed to STDOUT.
>> 
>> It'd be applicable for tests, but not for benchmarks. Also, the point that @cl4es seems to make is that randomness is captured and set up to reduce noise, not to be able to reproduce "benchmark failures".
>
> My bad. Forget my note

> Some have a preference for providing a seed for `Random` instances in micros. Either hard-coded or through a `@Param` (I find this a bit excessive). Doing so might reduce run-to-run noise.

I hear you, but unless your opinion is strong, I'll leave it as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289994437

From redestad at openjdk.org  Thu Aug 10 11:53:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 10 Aug 2023 11:53:58 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <ltY1m2hnILSeJpp-PvmLcLneR55xiQ1jKKZDKVO_pP8=.4fb048f3-bb41-4c3a-9096-22326c36a134@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
 <hZbiYFmVRcvWf4aZraMA5czSM5QgoyhrUqib2aHPd_Y=.7a792a76-9f69-40d5-9f1f-803ea96e7d52@github.com>
 <c9GuApl0qzJFK49dRu5w1xD4DPAxeiU7pz59PdG3RhY=.e8c94627-d90e-44d6-af66-44b7533c379d@github.com>
 <Q7rlwlCsQy1AW8wU_AFnwHraRGgcFwqSFh8YNshjj_8=.4354103f-3c45-4f13-99e2-66c8946332d3@github.com>
 <JDcrO1nerQuSDvqTzWaSCfcyHGPehTWceoDp0TOIzec=.90eec047-7021-4873-ae53-996403c0959f@github.com>
 <ltY1m2hnILSeJpp-PvmLcLneR55xiQ1jKKZDKVO_pP8=.4fb048f3-bb41-4c3a-9096-22326c36a134@github.com>
Message-ID: <dLvAIbsR6XwxuZPUsvcW0AWKyKPC5-S9iAQGdAj-_QQ=.c649adb1-5b15-435e-b2e8-c37fb08dfcf9@github.com>

On Thu, 10 Aug 2023 11:40:52 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> My bad. Forget my note
>
>> Some have a preference for providing a seed for `Random` instances in micros. Either hard-coded or through a `@Param` (I find this a bit excessive). Doing so might reduce run-to-run noise.
> 
> I hear you, but unless your opinion is strong, I'll leave it as is.

Hard-coding a seed would remove the run-to-run randomness, too, so would remove the need the `randomness` tag if this utility were to be used from a functional test. But yes, the reason to not do true randomness when setting up data for micros is to ensure we don't get multimodal results from arbitrary differences in the data setup. There are other ways around that, e.g. randomize data continually between iterations, run more forks to get more samples about flicker etc. A lot of work with an end result which is unlikely to add little more quality than a "random" set of data that we keep static from run-to-run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1289995785

From duke at openjdk.org  Thu Aug 10 12:06:29 2023
From: duke at openjdk.org (Cristian Vat)
Date: Thu, 10 Aug 2023 12:06:29 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
 <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
Message-ID: <2-FWP032phjwmiT6vOUN5ds83XjWEjfXOjVedDdgk4g=.656b80f4-c8e7-4935-904f-1b07bb8a3ddc@github.com>

On Fri, 28 Jul 2023 08:40:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce allocations also for Matcher.usePattern
>
> Shouldn't the similar change be in `CIBackRef.match` too? The fact current tests do not catch it makes me uneasy: the test coverage seems to be rather low there. 
> 
> We need a regex expert to look at it. @rgiulietti @igraves might help us out here?

@shipilev anything I should do to continue here?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1673076902

From shade at openjdk.org  Thu Aug 10 12:22:00 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Aug 2023 12:22:00 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
 <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
Message-ID: <5QUjAqngrIjpYEB7awYR2LWwZoEaWExfBQldqy6pYGM=.1540b1c9-f250-41c4-ad87-7759d03d2bbf@github.com>

On Fri, 28 Jul 2023 08:40:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduce allocations also for Matcher.usePattern
>
> Shouldn't the similar change be in `CIBackRef.match` too? The fact current tests do not catch it makes me uneasy: the test coverage seems to be rather low there. 
> 
> We need a regex expert to look at it. @rgiulietti @igraves might help us out here?

> @shipilev anything I should do to continue here?

Not really, we need more reviewers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1673080377

From thartmann at openjdk.org  Thu Aug 10 12:21:10 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Aug 2023 12:21:10 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <SeKm9x0yMf7J7bX2dvS0IPgoAeGo0dIV9kGAGiyY-4M=.053e3dda-6af6-452a-a825-ed864b34ca62@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

Looks good to me too.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1571741510

From dnsimon at openjdk.org  Thu Aug 10 12:22:00 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 12:22:00 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <CwhUQ6_eWDj6wN7hiyDGM8bVNcS0wdvPykO5kwgxBzI=.55852b16-2fce-4d88-98dc-31ad270d0230@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

src/hotspot/share/jvmci/jvmciEnv.cpp line 472:

> 470:                             vmSymbols::encodeThrowable_name(),
> 471:                             vmSymbols::encodeThrowable_signature(), &jargs, THREAD);
> 472:     if (handle_pending_exception(THREAD, buffer, buffer_size)) {

This is the actual bug fix: handle any exception occurring in the Java upcall.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15198#discussion_r1290014253

From dholmes at openjdk.org  Thu Aug 10 13:21:59 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Aug 2023 13:21:59 GMT
Subject: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from
 problem list
In-Reply-To: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
References: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
Message-ID: <KB2KnemwfIH63KzYS5iWxikDKUXVj25eu66inY2uqGs=.134fe7d6-c87e-4a3a-a70d-3b1b86e72a63@github.com>

On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove Unit-based tests in `java/lang/invoke` from `jdk`'s problem list. The underlying race condition in jtreg was fixed in release 7.3; which is now the default version used in JDK mainline development.

The bug management is a bit awkward here. I would suggest closing [JDK-8312482](https://bugs.openjdk.org/browse/JDK-8312482) as a dup of the codetools issue if allowed, else close it as "external" and link to the codetools issue.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15206#pullrequestreview-1571839507

From jpai at openjdk.org  Thu Aug 10 13:35:32 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 10 Aug 2023 13:35:32 GMT
Subject: RFR: 8314025: Remove JUnit-based test in java/lang/invoke from
 problem list
In-Reply-To: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
References: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
Message-ID: <RBJHJqZ_02fkiXasLl-j6A54BIwSvnsDSvYkl7DyaiI=.f88389a1-bb7e-4fd1-acc0-5fd7cb9b87df@github.com>

On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove Unit-based tests in `java/lang/invoke` from `jdk`'s problem list. The underlying race condition in jtreg was fixed in release 7.3; which is now the default version used in JDK mainline development.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15206#pullrequestreview-1571889773

From dnsimon at openjdk.org  Thu Aug 10 13:56:37 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 13:56:37 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit> [v2]
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

Doug Simon has updated the pull request incrementally with two additional commits since the last revision:

 - guard test-only code with ASSERT instead of !PRODUCT
 - omit test-only code in product build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15198/files
  - new: https://git.openjdk.org/jdk/pull/15198/files/529258a8..f160cb80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15198&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15198&range=00-01

  Stats: 17 lines in 4 files changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15198/head:pull/15198

PR: https://git.openjdk.org/jdk/pull/15198

From thartmann at openjdk.org  Thu Aug 10 13:56:38 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Aug 2023 13:56:38 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit> [v2]
In-Reply-To: <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
 <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
Message-ID: <de-iz_yAckG9RKnGOKM2KSFYgdPiqorOi6E07x3eonw=.c4889c70-8c16-4c61-b10c-92d39324f998@github.com>

On Thu, 10 Aug 2023 13:41:05 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
>> 
>> java.lang.OutOfMemoryError: Metaspace
>>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
>> 
>> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
>> 
>> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - guard test-only code with ASSERT instead of !PRODUCT
>  - omit test-only code in product build

Still looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15198#pullrequestreview-1571929038

From jvernee at openjdk.org  Thu Aug 10 15:05:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Aug 2023 15:05:58 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <7K7n7ahPfknWU6q5Wu9upiPKhMmXzwA5jthvvJmt7A4=.3072efdc-e2cc-4250-a5b1-feabe104ae30@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Thanks for the reviews so far.

That also reminds me to mention: while there are a lot of files touched, most of the updates a simple 1 line changes to test files removing the `@enablePreview` tag from the jtreg test information. So, probably most of this is easy to review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673384016

From dl at openjdk.org  Thu Aug 10 15:25:58 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 10 Aug 2023 15:25:58 GMT
Subject: RFR: 8301341: LinkedTransferQueue does not respect timeout for
 poll() [v10]
In-Reply-To: <cWkgNekRMQfUx6ygAOSoZ_IROM-tnck1kMyCv5YCodA=.284d88a6-5e89-456a-ad63-cf48f6587653@github.com>
References: <KD1ZOArvTEYT1j2KmkOJm-bNmDf0xViz8hXsT7LUh5w=.3c54f435-83fd-41dc-a52e-4759c9092607@github.com>
 <-6vf_XiZtv-LeQuln9iCrvwr1bZDWgaseqjfUENOpwE=.21f2d872-8b75-4f5b-be2a-1e27f8c109e2@github.com>
 <cWkgNekRMQfUx6ygAOSoZ_IROM-tnck1kMyCv5YCodA=.284d88a6-5e89-456a-ad63-cf48f6587653@github.com>
Message-ID: <lWgU6gXj1CMphtoyBCXbJ3BY6ukx_XMo_JCRAHG7MQM=.c7e05f75-5330-40c8-bb73-21967d2c55a0@github.com>

On Sun, 6 Aug 2023 12:23:54 GMT, Wouter Born <duke at openjdk.org> wrote:

>> Doug Lea 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 13 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8301341
>>  - Address more review comments
>>  - Address review comments
>>  - nitpicks
>>  - Merge branch 'openjdk:master' into JDK-8301341
>>  - Accommodate white-box tests; use consistent constructions; minor improvements
>>  - Merge branch 'openjdk:master' into JDK-8301341
>>  - Simplify contention handling; fix test
>>  - Fix inverted test assert; improve internal documentation; simplify code
>>  - Merge branch 'openjdk:master' into JDK-8301341
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c067d356...f53cee67
>
> Thanks for making the fixes Doug!
> Would it also be possible to backport these fixes to Java 17?
> 
> It seems to be a very common issue for openHAB users now that they upgrade to openHAB 4 which requires Java 17.
> 
> See:
> 
> * https://community.openhab.org/t/consistent-100-cpu-use-of-safecall-queue-thread/143792
> * https://community.openhab.org/t/high-cpu-usage-after-migration-to-oh4/148200

@wborn I think 17 should also be OK modulo deleting 2 lines for pre-21 mentioned above. I only checked with 19 though..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14317#issuecomment-1673399971

From duke at openjdk.org  Thu Aug 10 15:55:29 2023
From: duke at openjdk.org (Swati Sharma)
Date: Thu, 10 Aug 2023 15:55:29 GMT
Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests
 having shared state
Message-ID: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>

In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.

org/openjdk/bench/java/io/DataInputStreamTest.java
org/openjdk/bench/java/lang/ArrayClone.java
org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
org/openjdk/bench/java/lang/StringComparisons.java
org/openjdk/bench/java/lang/StringEquals.java
org/openjdk/bench/java/lang/StringFormat.java
org/openjdk/bench/java/lang/StringReplace.java
org/openjdk/bench/java/lang/StringSubstring.java
org/openjdk/bench/java/lang/StringTemplateFMT.java
org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
org/openjdk/bench/java/security/CipherSuiteBench.java
org/openjdk/bench/java/time/GetYearBench.java
org/openjdk/bench/java/time/InstantBench.java
org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
org/openjdk/bench/java/util/ListArgs.java
org/openjdk/bench/java/util/LocaleDefaults.java
org/openjdk/bench/java/util/TestAdler32.java
org/openjdk/bench/java/util/TestCRC32.java
org/openjdk/bench/java/util/TestCRC32C.java
org/openjdk/bench/java/util/regex/Exponential.java
org/openjdk/bench/java/util/regex/Primality.java
org/openjdk/bench/java/util/regex/Trim.java
org/openjdk/bench/javax/crypto/AESReinit.java
org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
org/openjdk/bench/vm/compiler/Rotation.java
org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
org/openjdk/bench/vm/compiler/x86/BasicRules.java

Please review and provide your feedback.

Thanks,
Swati

-------------

Commit messages:
 - 8314085: Fixing scope from benchmark to thread for JMH tests having shared state

Changes: https://git.openjdk.org/jdk/pull/15230/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314085
  Stats: 46 lines in 38 files changed: 0 ins; 0 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/15230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15230/head:pull/15230

PR: https://git.openjdk.org/jdk/pull/15230

From shade at openjdk.org  Thu Aug 10 16:10:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Aug 2023 16:10:59 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync
Message-ID: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>

When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for FileDescriptor.sync that can be used to qualify the changes in that area. 

Additionally, we use FD.sync for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK.

It will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself.


Benchmark                Mode  Cnt    Score   Error  Units

# Before JDK-8312127
FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op

# After JDK-8312127
FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op


The new regression test completes in <0.5s on my Mac.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/15231/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314120
  Stats: 155 lines in 2 files changed: 155 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15231/head:pull/15231

PR: https://git.openjdk.org/jdk/pull/15231

From sgehwolf at openjdk.org  Thu Aug 10 17:21:31 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Aug 2023 17:21:31 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <nQlctZ3ctF4Wsn8cKLir4kn51OAqKChwyQ5Z-tPI-CM=.72a25210-016a-43a6-acca-5f3065e2bbba@github.com>

> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.jmod        jdk.unsupported...

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Implementation for run-image link and single-hop
   
   This uses a stamp file in 'lib/modules' jimage in order to recognize
   multi-hop links. However, this has the caveat of no longer producing
   reproducible builds as compared to a packaged module-based link.
   
   Add an option to allow for multi-hop, which disables the stamp file
   addition and makes it reproducible again.
 - Exit the jlink on modified files by default
   
   This is configurable so add tests for both scenarios.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/baeaaf5d..738b8a31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=01-02

  Stats: 529 lines in 15 files changed: 450 ins; 45 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From mcimadamore at openjdk.org  Thu Aug 10 17:24:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Aug 2023 17:24:28 GMT
Subject: [jdk21] RFR: 8298095: Refine implSpec for SegmentAllocator
Message-ID: <y3KX22_gSdBoURVmqi7H-SlfK_KfCticXD5mMnlbwho=.78b4c7b3-5dc8-44a1-a408-58050fc18c6a@github.com>

8298095: Refine implSpec for SegmentAllocator

-------------

Commit messages:
 - Backport 35b60f925a4e7e2e3f1ec7c5c1eee60206e7508a

Changes: https://git.openjdk.org/jdk21/pull/172/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298095
  Stats: 249 lines in 1 file changed: 147 ins; 21 del; 81 mod
  Patch: https://git.openjdk.org/jdk21/pull/172.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/172/head:pull/172

PR: https://git.openjdk.org/jdk21/pull/172

From sgehwolf at openjdk.org  Thu Aug 10 17:25:36 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Aug 2023 17:25:36 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v2]
In-Reply-To: <vOKwbbLeJM-azXc8xhgFG9sJWqraG-q8aQ2bgWSnaWA=.da834e20-40dc-47c7-a398-c3650109df48@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <vOKwbbLeJM-azXc8xhgFG9sJWqraG-q8aQ2bgWSnaWA=.da834e20-40dc-47c7-a398-c3650109df48@github.com>
Message-ID: <LYOG8qQU2uZDzMbUhCdixSmF0_aSnioLQajpbtJBA7M=.30be5f5e-8b08-4a65-8e04-8ec3a4ad2726@github.com>

On Tue, 8 Aug 2023 16:34:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.j...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Use 'run-image' as the term shown with --verbose
>  - 8311302: Allow for jlinking a custom runtime without packaged modules being present

@AlanBateman Hi! Moving the [discusion](https://mail.openjdk.org/pipermail/leyden-dev/2023-July/000173.html) to this PR now. I've updated this patch to do single-hops only by default now. Looks like this:


$ bin/jlink --add-modules java.base --output ../testme-java-base/ --verbose
java.base jrt:/java.base (run-image)

Providers:
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
Error: Run image links only allow single-hop.


I'm not particularly fond of that, though, as there is a need to know what is single hop is and what not. My approach is adding a 0-sized stamp file to the `lib/modules` jimage, but that has the issue of now breaking comparison between a packaged module jlink vs. a runtime image using one. The same would be true for adding a file or appending the `jmod_resources` file with some info to know it's multi-hop. Some state needs to be there unless I'm missing something for this. For now an option suppresses creating that file so as to be able to keep asserting packaged vs run-image link and other properties in tests. I'd argue most of the time multi-hop would be OK, but default off and a switch to turn it on seems reasonable to me. Up for discussion...

Also, if a file is modified the link fails unless it's turned off with an option. Looks like this:


$ ./bin/jlink --add-modules java.base --output ../abort-on-mod --verbose
java.base jrt:/java.base (run-image)

Providers:
  java.base provides java.nio.file.spi.FileSystemProvider used by java.base
  java.base provides java.util.random.RandomGenerator used by java.base
Error: java.lang.IllegalArgumentException: /disk/openjdk/upstream-sources/git/jdk-jdk/build/jmodless-copy-jmods-removed/conf/net.properties has been modified. Please double check!
$ echo $?
1


Both things will have CLI options to a) make the exit on mod a warning only and b) allow multi-hop - some tests needed that. Hence, I've marked this PR as needing a CSR for now.

More thoughts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1673592876

From naoto at openjdk.org  Thu Aug 10 17:34:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Aug 2023 17:34:59 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v7]
In-Reply-To: <sO7CsYC2Jkv4KjsNvditGur9EjGSrzwYeXezvds3VKc=.1d2c193d-67eb-4be9-a0b7-5d262038f874@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <1rFouxpbzGLybnxXGslNTnoMIZC7MjrEU1zvDCKaqi0=.d3566682-582f-4a26-81c2-76f35f6fed5c@github.com>
 <sO7CsYC2Jkv4KjsNvditGur9EjGSrzwYeXezvds3VKc=.1d2c193d-67eb-4be9-a0b7-5d262038f874@github.com>
Message-ID: <67BVzHBTdGjXFSXWq06oYJ_RcWGNc0E01jQO2RvWp1w=.c66ffd69-25a5-484c-8aa8-c6d548363857@github.com>

On Wed, 9 Aug 2023 23:39:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Small cleanup
>
> src/java.base/share/classes/java/text/ListFormat.java line 58:
> 
>> 56:  *     .format(List.of("Foo", "Bar", "Baz"))
>> 57:  * }
>> 58:  * This will produce the concatenated list string, "Foo, Bar, and Baz" as seen in
> 
> With this sample code, if the Style is changed to SHORT, it would produce the same string. Would it be better to use the weekdays instead of Foo, Bar and Baz (as in the Unicode spec)? Esp. with the UNIT type, those examples explained it better, e.g. NARROW produces 3? 7?.
> 
> Also, if the instance is of STANDARD/SHORT, does it format List.of("January", "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches to 3 ft, 7 in? The format method states simply "Returns the string that consists of the input strings, concatenated with the patterns of this ListFormat."  I wonder if it'd be helpful to explain a bit more or add one more sample.

In fact, the sample in LDML's page seems to be incorrect. `standard-short` in English is defined as:

		<listPattern type="standard-short">
			<listPatternPart type="start">{0}, {1}</listPatternPart>
			<listPatternPart type="middle">{0}, {1}</listPatternPart>
			<listPatternPart type="end">{0}, &amp; {1}</listPatternPart>
			<listPatternPart type="2">{0} &amp; {1}</listPatternPart>
		</listPattern>

in `en.xml` file. So `&` is expected rather than `and`.

> Also, if the instance is of STANDARD/SHORT, does it format List.of("January", "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches to 3 ft, 7 in?

No it does not. The `format()` method does not alter the passed input strings, so it would not convert "January" to "Jan." even if `SHORT` Style is specified. I have added some extra explanations, that those patterns vary depending on the locale providers.

> src/java.base/share/classes/java/text/ListFormat.java line 71:
> 
>> 69:  * <tr><th scope="row" style="text-align:left">STANDARD</th>
>> 70:  *     <td>Foo, Bar, and Baz</td>
>> 71:  *     <td>Foo, Bar, &amp; Baz</td>
> 
> Is "&amp;" a typo?  It's still "and" in the Unicode spec's "standard-short" format, e.g. "Jan., Feb., and Mar."

Again `ampersand` is the correct pattern for `SHORT` in English.

> src/java.base/share/classes/java/text/ListFormat.java line 408:
> 
>> 406:         var em = endPattern.matcher(source);
>> 407:         Object parsed = null;
>> 408:         if (sm.find(parsePos.index) && em.find(parsePos.index)) {
> 
> Would it be better to call getIndex() instead? (same below)

Fixed.

> test/jdk/java/text/Format/ListFormat/TestListFormat.java line 157:
> 
>> 155:                         "foo, bar, baz", true),
>> 156:                 arguments(Locale.US, ListFormat.Type.OR, ListFormat.Style.NARROW,
>> 157:                         "foo, bar, or baz", true),
> 
> Same as in the ListFormat class, the expected results are the same "foo, bar, or baz" when different Styles are specified.

Yes, those are exactly what are defined in CLDR. (They could have chosen `|` for SHORT style, but that would be not so common in plain English I guess)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428317
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428359
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428267
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290428459

From naoto at openjdk.org  Thu Aug 10 17:31:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 10 Aug 2023 17:31:28 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v8]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <AVfJ8UE6_AT-iTUKEmZjreZLyOCvhnqCN86RVlr14Pk=.0044c604-bcd6-437e-9ba4-a7265c1a14f3@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/7760656a..5b536fab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=06-07

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From jvernee at openjdk.org  Thu Aug 10 17:57:01 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Aug 2023 17:57:01 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v2]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <JqkBKqDF9cI50Sr7h7OPNw2n6IVYry4-zMVZ5iVp1QM=.c9a18b34-fd8e-4cce-97b8-7afb61c0a2e2@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - 8313894: Rename isTrivial linker option to critical
   
   Reviewed-by: pminborg, mcimadamore
 - 8313680: Disallow combining caputreCallState with isTrivial
   
   Reviewed-by: mcimadamore
 - Merge branch 'master' into JEP22
 - use immutable map for fallback linker canonical layouts
 - 8313265: Move the FFM API out of preview
   
   Reviewed-by: mcimadamore
 - 8313005: Ensure native access check can fold away
   
   Reviewed-by: mcimadamore
 - 8312981: Make the linker API required
   
   Reviewed-by: mcimadamore
 - 8312615: Ensure jdk_foreign tests pass on linux-x86
   
   Reviewed-by: mcimadamore
 - 8312186: TestStringEncodingFails for UTF-32
   
   Reviewed-by: mcimadamore
 - 8312059: Clarify the documention for variadic functions
   8310646: Javadoc around prototype-less functions might be incorrect
   
   Reviewed-by: mcimadamore
 - ... and 7 more: https://git.openjdk.org/jdk/compare/23fe2ece...74bbe721

-------------

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=01
  Stats: 2817 lines in 230 files changed: 1239 ins; 894 del; 684 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From jvernee at openjdk.org  Thu Aug 10 17:57:03 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Aug 2023 17:57:03 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <xbpM41JARFgR3qUVQh-YXCHVGDTW2jhwIShCxE-vc4k=.4c5a073a-3713-4a23-b991-ce69966b7022@github.com>

On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Addressing some offline review comments. Two more (small) changes have been added:
- Disallow combining the `captureCallState` and `isTrivial` (see https://github.com/openjdk/panama-foreign/pull/856)
- Rename `isTrivial` to `critical` (see https://github.com/openjdk/panama-foreign/pull/859)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673627002

From mcimadamore at openjdk.org  Thu Aug 10 18:21:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 10 Aug 2023 18:21:59 GMT
Subject: [jdk21] Withdrawn: 8298095: Refine implSpec for SegmentAllocator
In-Reply-To: <y3KX22_gSdBoURVmqi7H-SlfK_KfCticXD5mMnlbwho=.78b4c7b3-5dc8-44a1-a408-58050fc18c6a@github.com>
References: <y3KX22_gSdBoURVmqi7H-SlfK_KfCticXD5mMnlbwho=.78b4c7b3-5dc8-44a1-a408-58050fc18c6a@github.com>
Message-ID: <FVfGCIW6Mvl7CAwTSH4VPXkYyKsYiRhXLmgz870rCLU=.538548c0-dda4-4ada-a9a9-d8f9a0507957@github.com>

On Thu, 10 Aug 2023 16:54:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> 8298095: Refine implSpec for SegmentAllocator

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk21/pull/172

From dnsimon at openjdk.org  Thu Aug 10 19:10:29 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 19:10:29 GMT
Subject: Integrated: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit>
In-Reply-To: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
Message-ID: <PIp8kU5nQNbvEdSKGRqiv0U-qEePi206figumm-bqQU=.405ebd4b-16b1-4841-bd72-68b005a49e19@github.com>

On Tue, 8 Aug 2023 20:52:29 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
> 
> java.lang.OutOfMemoryError: Metaspace
>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
> 
> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
> 
> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.

This pull request has now been integrated.

Changeset: 6f5c903d
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f5c903d10aa5f7ff979a79f121609c167f88eff
Stats:     60 lines in 6 files changed: 58 ins; 1 del; 1 mod

8313899: JVMCI exception Translation can fail in TranslatedException.<clinit>

Reviewed-by: never, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/15198

From dnsimon at openjdk.org  Thu Aug 10 19:10:28 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Thu, 10 Aug 2023 19:10:28 GMT
Subject: RFR: 8313899: JVMCI exception Translation can fail in
 TranslatedException.<clinit> [v2]
In-Reply-To: <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
References: <wjbzbrHU-TexTsReFbO-7MyEWmf86UNd5wdCobL_2Ag=.44866942-430e-40c4-b119-1b49ed186f8a@github.com>
 <hspU29wwRzlaNdkHmmKAE3oAk_rNxe5L6Ys4fAK9l3g=.eaed4289-ea46-4ebb-ac12-2865bda51bae@github.com>
Message-ID: <smBcTsOKOTRQRtg482AUmk9IMj0uRQuMVA-bpTqQ1ac=.d61e1fcf-35a1-4707-b7d1-23a0ad07d467@github.com>

On Thu, 10 Aug 2023 13:56:37 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> In a test that stresses metaspace (such as `vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java`) that also uses `-Xcomp -XX:-TieredCompilation`, we've seen a failure in `TranslatedException.<clinit>` due to exhausted metaspace:
>> 
>> java.lang.OutOfMemoryError: Metaspace
>>         at jdk.internal.vm.TranslatedException.encodeThrowable(java.base at 21/TranslatedException.java:176)
>>         at jdk.internal.vm.TranslatedException.<clinit>(java.base at 21/TranslatedException.java:61)
>>         at jdk.internal.vm.VMSupport.encodeThrowable(java.base at 21/VMSupport.java:171)
>> 
>> This PR pushes a fix such that this exception is properly handled in the VM (i.e. causing a compilation bailout) instead of leading to a VM crash.
>> 
>> The PR includes 2 bits of debug code guarded by system properties that enable the handling to be tested in libgraal. The test itself is not included as libgraal is not part of OpenJDK.
>
> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - guard test-only code with ASSERT instead of !PRODUCT
>  - omit test-only code in product build

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15198#issuecomment-1673739930

From jvernee at openjdk.org  Thu Aug 10 20:43:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 10 Aug 2023 20:43:28 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <BstFOkZK_4kKuP3J9jRNpDYMUtjA7r0-ZEOt53wTGio=.4edf93be-8194-4d49-865c-fccbcd62709c@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - enable fallback linker on linux x86 in GHA
 - make Arena::allocate abstract

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/74bbe721..147e79d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=01-02

  Stats: 20 lines in 4 files changed: 9 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From aturbanov at openjdk.org  Thu Aug 10 21:23:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 10 Aug 2023 21:23:00 GMT
Subject: RFR: 8314129: Make fields final in java.util.Scanner
Message-ID: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>

Made a few fields `final` in java.util.Scanner.
Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.`

-------------

Commit messages:
 - [PATHC] Make fields final in java.util.Scanner

Changes: https://git.openjdk.org/jdk/pull/14863/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314129
  Stats: 34 lines in 1 file changed: 17 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14863/head:pull/14863

PR: https://git.openjdk.org/jdk/pull/14863

From stsypanov at openjdk.org  Thu Aug 10 21:23:28 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 10 Aug 2023 21:23:28 GMT
Subject: RFR: 8314129: Make fields final in java.util.Scanner
In-Reply-To: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
References: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
Message-ID: <E4kcYR-oBcmjsftugffow5caHZG6lAYUWPT09bim6PM=.6f1f22ec-dcae-42a4-9444-f29a2a7aacf8@github.com>

On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Made a few fields `final` in java.util.Scanner.
> Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.`

Marked as reviewed by stsypanov (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14863#pullrequestreview-1528793589

From bpb at openjdk.org  Thu Aug 10 21:49:58 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 10 Aug 2023 21:49:58 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
In-Reply-To: <BstFOkZK_4kKuP3J9jRNpDYMUtjA7r0-ZEOt53wTGio=.4edf93be-8194-4d49-865c-fccbcd62709c@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <BstFOkZK_4kKuP3J9jRNpDYMUtjA7r0-ZEOt53wTGio=.4edf93be-8194-4d49-865c-fccbcd62709c@github.com>
Message-ID: <e_s6nibUiAJbQRF5nzvIkYhI5wBlWrzG8rpKj8ObHok=.63e47d6c-f4ed-4295-8b24-78d984063982@github.com>

On Thu, 10 Aug 2023 20:43:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
>> 
>> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
>> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
>> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
>> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
>> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
>> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
>> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
>> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
>> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - enable fallback linker on linux x86 in GHA
>  - make Arena::allocate abstract

The few, simple NIO changes are fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1673943826

From joehw at openjdk.org  Thu Aug 10 22:02:58 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 10 Aug 2023 22:02:58 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v7]
In-Reply-To: <67BVzHBTdGjXFSXWq06oYJ_RcWGNc0E01jQO2RvWp1w=.c66ffd69-25a5-484c-8aa8-c6d548363857@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <1rFouxpbzGLybnxXGslNTnoMIZC7MjrEU1zvDCKaqi0=.d3566682-582f-4a26-81c2-76f35f6fed5c@github.com>
 <sO7CsYC2Jkv4KjsNvditGur9EjGSrzwYeXezvds3VKc=.1d2c193d-67eb-4be9-a0b7-5d262038f874@github.com>
 <67BVzHBTdGjXFSXWq06oYJ_RcWGNc0E01jQO2RvWp1w=.c66ffd69-25a5-484c-8aa8-c6d548363857@github.com>
Message-ID: <hvg2BqiO8SoZigaKOTSJTSDVFYFx5OoIQo-VS69Nz5E=.ccc18667-137a-43a6-b0ab-335b51e1b52c@github.com>

On Thu, 10 Aug 2023 16:59:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/ListFormat.java line 58:
>> 
>>> 56:  *     .format(List.of("Foo", "Bar", "Baz"))
>>> 57:  * }
>>> 58:  * This will produce the concatenated list string, "Foo, Bar, and Baz" as seen in
>> 
>> With this sample code, if the Style is changed to SHORT, it would produce the same string. Would it be better to use the weekdays instead of Foo, Bar and Baz (as in the Unicode spec)? Esp. with the UNIT type, those examples explained it better, e.g. NARROW produces 3? 7?.
>> 
>> Also, if the instance is of STANDARD/SHORT, does it format List.of("January", "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches to 3 ft, 7 in? The format method states simply "Returns the string that consists of the input strings, concatenated with the patterns of this ListFormat."  I wonder if it'd be helpful to explain a bit more or add one more sample.
>
> In fact, the sample in LDML's page seems to be incorrect. `standard-short` in English is defined as:
> 
> 		<listPattern type="standard-short">
> 			<listPatternPart type="start">{0}, {1}</listPatternPart>
> 			<listPatternPart type="middle">{0}, {1}</listPatternPart>
> 			<listPatternPart type="end">{0}, &amp; {1}</listPatternPart>
> 			<listPatternPart type="2">{0} &amp; {1}</listPatternPart>
> 		</listPattern>
> 
> in `en.xml` file. So `&` is expected rather than `and`.
> 
>> Also, if the instance is of STANDARD/SHORT, does it format List.of("January", "February", "March") and return "Jan., Feb., and Mar.", or 3 feet, 7 inches to 3 ft, 7 in?
> 
> No it does not. The `format()` method does not alter the passed input strings, so it would not convert "January" to "Jan." even if `SHORT` Style is specified. I have added some extra explanations, that those patterns vary depending on the locale providers.

Ah, I see. Those samples did give an impression that the format does more than concatenation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1290711203

From duke at openjdk.org  Thu Aug 10 22:06:59 2023
From: duke at openjdk.org (Christoph)
Date: Thu, 10 Aug 2023 22:06:59 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder
Message-ID: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>

Add new test case with sample modules that contains some requires/exports/uses/provides.

We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.

Follow up task from https://github.com/openjdk/jdk/pull/14408

-------------

Commit messages:
 - cleanup
 - rename and cleanup
 - revert back to default size of 75 for module desriptors
 - add decompilation via javap
 - extract jimage
 - add some more opens and exports
 - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591
 - Set module split size to 1
 - fix test
 - test
 - ... and 2 more: https://git.openjdk.org/jdk/compare/509f80bb...9577e7e8

Changes: https://git.openjdk.org/jdk/pull/15234/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311591
  Stats: 240 lines in 10 files changed: 240 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From duke at openjdk.org  Thu Aug 10 22:07:32 2023
From: duke at openjdk.org (Christoph)
Date: Thu, 10 Aug 2023 22:07:32 GMT
Subject: RFR: 8240567: MethodTooLargeException thrown while creating a
 jlink image [v19]
In-Reply-To: <LKX6erLY9wXZSuf11pHt6R-PkqDt-NHeY3VA8p4dyVQ=.f477a6a1-fb00-427b-85b0-fd2affa68259@github.com>
References: <I79DcNOlfxaVJei-aqMxFiQTOwnWg56C9m4UnQ4QoGc=.29692e7c-dc4d-4197-a22c-d1482d520572@github.com>
 <fp9PEVNZNpBwh0yHwPC9-HhI8vbH6pjDxUd29ogWEmw=.796ded42-ba4b-4a02-86a9-08b680110168@github.com>
 <CJuqpdWdrQpn8QNiocm6EuUzVNwYmoNqX8F3ryTIZ7U=.3dbd8f38-7a5f-4001-a6c9-641d25695081@github.com>
 <nJtaOmnevHioGemQCIfp25ldjI0ZV_BD2ksZp3CJKmk=.a4f1a323-aab6-4c61-bba4-3aee348648c9@github.com>
 <LKX6erLY9wXZSuf11pHt6R-PkqDt-NHeY3VA8p4dyVQ=.f477a6a1-fb00-427b-85b0-fd2affa68259@github.com>
Message-ID: <q_6iZ4jZHr1eOqQmwvd7aR6O84S1LoXfpCG1tLF0yao=.0a7e433a-89b9-4f38-b461-8c41ca5c58a5@github.com>

On Fri, 14 Jul 2023 16:08:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> It's looking pretty good.
>> 
>> Thank you!
>> 
>>> About the test, I don't see `ArrayList::add` in the generated bytecode of `sub2-13`. The dedup string set is used for the targets of qualified exports and opens and uses. The modifiers set of `requires` is deduplicated but not the required module names.
>> 
>> Thank you for the hint.
>> 
>>> I assume you want this be backported. If so, we should give it some baked time after it's integrated to the main line.
>> 
>> Sounds great!
>> 
>>> I'm okay if you want to extend the test in a follow up. 
>> 
>> That would be great. Will take time to craft a proper setting.
>
> @koppor do you have any update on a new test for [JDK-8311591](https://bugs.openjdk.org/browse/JDK-8311591)?

@mlchung Pardon for the delay, we now created a PR with a test case https://github.com/openjdk/jdk/pull/15234

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14408#issuecomment-1673959119

From duke at openjdk.org  Thu Aug 10 22:22:35 2023
From: duke at openjdk.org (Christoph)
Date: Thu, 10 Aug 2023 22:22:35 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v2]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <iz7hlaqOjMb_QbPRIxbCtSJi0XecucWu4MWy8L8LPS0=.556337e1-8db3-4c56-90b1-9136ebe76e64@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
  
  Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>

-------------

Changes: https://git.openjdk.org/jdk/pull/15234/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=01
  Stats: 239 lines in 9 files changed: 239 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From duke at openjdk.org  Thu Aug 10 22:30:58 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 10 Aug 2023 22:30:58 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <sgnoUrYJrk1_EJo8Ftp3tL_r49H0y6eh2b_hVws55g0=.47a6dcc2-a6ea-41b6-b357-d44df12801a6@github.com>

On Thu, 10 Aug 2023 21:42:41 GMT, Christoph <duke at openjdk.org> wrote:

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

We accidently pushed the full internal history - and "immediatly" squashed into one commit. From now on, we will update the branch "as usual"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15234#issuecomment-1673981735

From almatvee at openjdk.org  Thu Aug 10 23:21:59 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 10 Aug 2023 23:21:59 GMT
Subject: RFR: 8313904: [macos] All signing tests which verifies unsigned app
 images are failing
Message-ID: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>

- This is regression from [JDK-8298488](https://bugs.openjdk.org/browse/JDK-8298488).
- Since JDK-8298488 unsigned app bundles are ad-hoc signed and `codesign` will report that app bundle is signed and thus our tests failed.
- Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate.
- Unsigned post process image will be ad-hoc re-sign when generating DMG or PKG, since we adding `.package` file which makes ad-hoc signature invalid. This is similar to [JDK-8293462](https://bugs.openjdk.org/browse/JDK-8293462).

-------------

Commit messages:
 - 8313904: [macos] All signing tests which verifies unsigned app images are failing

Changes: https://git.openjdk.org/jdk/pull/15235/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313904
  Stats: 94 lines in 8 files changed: 58 ins; 0 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/15235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15235/head:pull/15235

PR: https://git.openjdk.org/jdk/pull/15235

From mik3hall at gmail.com  Thu Aug 10 23:35:56 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 10 Aug 2023 18:35:56 -0500
Subject: RFR: 8313904: [macos] All signing tests which verifies unsigned
 app images are failing
In-Reply-To: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
Message-ID: <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>



> On Aug 10, 2023, at 6:21 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
> - Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate.

How is ad-hoc signing done?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230810/2a04751b/attachment-0001.htm>

From liach at openjdk.org  Thu Aug 10 23:46:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Aug 2023 23:46:01 GMT
Subject: RFR: 8314129: Make fields final in java.util.Scanner
In-Reply-To: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
References: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
Message-ID: <0kEHqtrx0KvoLF66x6Qmn2Ut8wM-mcVQtuEaUA712Fs=.14993cb2-e59d-425e-849c-633284744849@github.com>

On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Made a few fields `final` in java.util.Scanner.
> Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.`

Marked as reviewed by liach (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14863#pullrequestreview-1572853738

From liach at openjdk.org  Thu Aug 10 23:46:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Aug 2023 23:46:58 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
In-Reply-To: <BstFOkZK_4kKuP3J9jRNpDYMUtjA7r0-ZEOt53wTGio=.4edf93be-8194-4d49-865c-fccbcd62709c@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <BstFOkZK_4kKuP3J9jRNpDYMUtjA7r0-ZEOt53wTGio=.4edf93be-8194-4d49-865c-fccbcd62709c@github.com>
Message-ID: <J5LbOHrt9jhamepRscFbCGaF0XT3cvUDPPe4vNTtiAU=.d2409ee8-7c0e-449a-9014-1a5ce426b521@github.com>

On Thu, 10 Aug 2023 20:43:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
>> 
>> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
>> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
>> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
>> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
>> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
>> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
>> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
>> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
>> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO...
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - enable fallback linker on linux x86 in GHA
>  - make Arena::allocate abstract

Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1674051619

From mik3hall at gmail.com  Fri Aug 11 01:11:00 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 10 Aug 2023 20:11:00 -0500
Subject: RFR: 8313904: [macos] All signing tests which verifies unsigned
 app images are failing
In-Reply-To: <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
 <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>
Message-ID: <7601285F-853F-40C3-888C-DD411DBBFB55@gmail.com>



> On Aug 10, 2023, at 6:35 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Aug 10, 2023, at 6:21 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
>> 
>> - Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate.
> 
> How is ad-hoc signing done?
> 
> 

If it?s this, I guess I got it
https://developer.apple.com/documentation/security/seccodesignatureflags/1397793-adhoc

I assume done with jpackage by indicating something like ?mac-sign only? If wrong feel free to correct.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230810/fc80dfef/attachment-0001.htm>

From alexander.matveev at oracle.com  Fri Aug 11 03:02:35 2023
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 11 Aug 2023 03:02:35 +0000
Subject: RFR: 8313904: [macos] All signing tests which verifies unsigned
 app images are failing
In-Reply-To: <7601285F-853F-40C3-888C-DD411DBBFB55@gmail.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
 <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>
 <7601285F-853F-40C3-888C-DD411DBBFB55@gmail.com>
Message-ID: <36F7D47D-0E2B-489E-838B-470FDF1234D0@oracle.com>

Hi Michael,

On Aug 10, 2023, at 6:11 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Aug 10, 2023, at 6:35 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Aug 10, 2023, at 6:21 PM, Alexander Matveev <almatvee at openjdk.org<mailto:almatvee at openjdk.org>> wrote:

- Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate.

How is ad-hoc signing done?



If it?s this, I guess I got it
https://developer.apple.com/documentation/security/seccodesignatureflags/1397793-adhoc

Yes, this is how it is done.


I assume done with jpackage by indicating something like ?mac-sign only? If wrong feel free to correct.

No, it is always done if ?mac-sign is NOT specified and we doing ad-hoc signing on app bundle only. PKG will not be ad-hoc signed.
If ?mac-sign is provided we will use certificate provided with ?mac-sign to sign app image and PKG as before.

Thanks,
Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230811/aadaae6b/attachment-0001.htm>

From duke at openjdk.org  Fri Aug 11 04:28:29 2023
From: duke at openjdk.org (duke)
Date: Fri, 11 Aug 2023 04:28:29 GMT
Subject: Withdrawn: JDK-8077371: Binary files in JAXP test should be removed
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <7Gul11f2gxwfw_HX5Fr27zj2nJhJEMF0-DbVJAQTC6M=.41941956-6f0b-4626-97f9-de7827e7c0eb@github.com>

On Wed, 19 Apr 2023 15:51:01 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Test is updated to create the binary files during test execution.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13537

From mik3hall at gmail.com  Fri Aug 11 05:48:35 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 11 Aug 2023 00:48:35 -0500
Subject: RFR: 8313904: [macos] All signing tests which verifies unsigned
 app images are failing
In-Reply-To: <36F7D47D-0E2B-489E-838B-470FDF1234D0@oracle.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
 <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>
 <7601285F-853F-40C3-888C-DD411DBBFB55@gmail.com>
 <36F7D47D-0E2B-489E-838B-470FDF1234D0@oracle.com>
Message-ID: <3D79C30A-0BF6-4812-9D19-4F5BADEDDC90@gmail.com>


>> 
>> I assume done with jpackage by indicating something like ?mac-sign only? If wrong feel free to correct.
> 
> No, it is always done if ?mac-sign is NOT specified and we doing ad-hoc signing on app bundle only. PKG will not be ad-hoc signed.
> If ?mac-sign is provided we will use certificate provided with ?mac-sign to sign app image and PKG as before.
> 
> Thanks,
> Alexander

I always do dmg or app-image for quick testing. I haven?t done any pkg yet. 

So if I understand correctly now for app bundle types - dmg or app-image, some signing is always done. Certificate if signing is indicated and it is provided or adhoc if it isn?t indicated as a default. I didn?t know this.

Thanks

Mike 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230811/9cfc25f6/attachment-0001.htm>

From redestad at openjdk.org  Fri Aug 11 11:16:29 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 11 Aug 2023 11:16:29 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
Message-ID: <rvuPA35pTfhDpnb1bvjQ_QbVs_84XkTXD4-wsEEFcv4=.4ad97f77-beea-4f5d-81c3-7c59ee0058c0@github.com>

On Wed, 9 Aug 2023 22:54:28 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them.
>> 
>> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon.
>
> Pavel Rappo 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 13 additional commits since the last revision:
> 
>  - Fix bugs in Shared.createSingle
>  - Merge branch 'master' into 8310813
>  - Group params coarser (suggested by @cl4es)
>    
>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>      Every testXYZ method invokes M operations, where M is the maximum
>      number of elements in a group. Shorter groups are cyclically padded.
>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>      benchmark time.
>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>  - Use better overloads (suggested by @cl4es)
>    
>    - Uses simpler, more suitable overloads for the subrange
>      starting from 0
>  - Improve benchmarks
>  - Merge branch 'master' into 8310813
>  - Restore hash code values
>    
>    BigInteger is old and ubiquitous enough so that there might be
>    inadvertent dependencies on its hash code.
>    
>    This commit also includes a test, to make sure hash code is
>    unchanged.
>  - Merge branch 'master' into 8310813
>  - Add a benchmark
>  - Merge branch 'master' into 8310813
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/983eb997...6fa3f694

> Here's a status update for this PR. I'm currently benchmarking baseline against this PR and this PR plus changes in #15197. It's a 3-way benchmark, so to speak. Its purpose is to see whether performance degradation brought by this PR to `equals` and `compareTo` can be sufficiently offset by the improved `ArraysSupport.mismatch` mechanics.

Sadly #15197 doesn't pan out as well as I'd hoped: the win on some array sizes is cancelled out by losses on others. I'll be shifting the focus of that PR over to simplifying in ways that will be performance neutral and enhancing the targeted `ArraysMismatch` microbenchmarks so that they work on tiny array sizes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1674563442

From redestad at openjdk.org  Fri Aug 11 11:29:28 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 11 Aug 2023 11:29:28 GMT
Subject: RFR: 8310813: Simplify and modernize equals, hashCode,
 and compareTo for BigInteger [v6]
In-Reply-To: <PtaGzKPth_wow6m60jFepz2MwqBMH376o9bugDmQrVI=.5c60b2c8-24be-43bb-a4e3-9455aa70bbb2@github.com>
References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com>
 <PuxOkuvAitHz3-lhAmJnjagYsr6Hh-uls8xZRwsmP-w=.75b53d35-4429-40d2-a32e-d162f0458964@github.com>
 <PtaGzKPth_wow6m60jFepz2MwqBMH376o9bugDmQrVI=.5c60b2c8-24be-43bb-a4e3-9455aa70bbb2@github.com>
Message-ID: <Q-AgYAEv0Ke3Mhi6bB-QHP-nMs2pvn4OmrhntjM0HFw=.73737d6a-1c76-4ad1-85a1-ef7daa6996e1@github.com>

On Thu, 10 Aug 2023 11:38:08 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Pavel Rappo 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 13 additional commits since the last revision:
>> 
>>  - Fix bugs in Shared.createSingle
>>  - Merge branch 'master' into 8310813
>>  - Group params coarser (suggested by @cl4es)
>>    
>>    - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge.
>>      Every testXYZ method invokes M operations, where M is the maximum
>>      number of elements in a group. Shorter groups are cyclically padded.
>>    - Uses the org.openjdk.jmh.infra.Blackhole API and increases
>>      benchmark time.
>>    - Fixes a bug in Shared that precluded 0 from being in a pair.
>>  - Use better overloads (suggested by @cl4es)
>>    
>>    - Uses simpler, more suitable overloads for the subrange
>>      starting from 0
>>  - Improve benchmarks
>>  - Merge branch 'master' into 8310813
>>  - Restore hash code values
>>    
>>    BigInteger is old and ubiquitous enough so that there might be
>>    inadvertent dependencies on its hash code.
>>    
>>    This commit also includes a test, to make sure hash code is
>>    unchanged.
>>  - Merge branch 'master' into 8310813
>>  - Add a benchmark
>>  - Merge branch 'master' into 8310813
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3619ef21...6fa3f694
>
> Here's a status update for this PR. I'm currently benchmarking baseline against this PR and this PR plus changes in https://github.com/openjdk/jdk/pull/15197. It's a 3-way benchmark, so to speak. Its purpose is to see whether performance degradation brought by this PR to `equals` and `compareTo` can be sufficiently offset by the improved `ArraysSupport.mismatch` mechanics.

Some context: On the `equals` and `compareTo` microbenchmarks @pavelrappo is adding in this PR there's a tiny regression from using `ArraysSupport.mismatch` when the `value` array has just a single element. Since such small `BigInteger`s appears to be exceedingly common (huh) it's been deemed hard to brush aside. Still this regression comes from the code having some extra branch, and is less than 2ns/op. All the while the speedup on huge `BigInteger`s is substantial. 

I think it's reasonable to move forward with this patch and accept the tiny regression on `equals/hashCode` with a magnitude of 1 (like we've done in other places such as `String.startsWith`) and separately continue investigating if `ArraysSupport.mismatch` can be improved to remove this deficiency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1674582483

From jvernee at openjdk.org  Fri Aug 11 12:37:59 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 11 Aug 2023 12:37:59 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v4]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <2oLXen9Xs8SSrIgV9q_2KV0CA0ioUIdUZDqtsSkQ-BI=.b30a8a5b-1f03-480e-8d53-9f107ab35d64@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  remove spurious imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15103/files
  - new: https://git.openjdk.org/jdk/pull/15103/files/147e79d3..141096b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From alanb at openjdk.org  Fri Aug 11 14:55:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 11 Aug 2023 14:55:59 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync
In-Reply-To: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
Message-ID: <1wwMOJIIp63YoHWMoD-dhTCm80gpN1TyMQ3z50q7hIU=.b75c6eb1-502f-480b-94ce-9ee719ff02b8@github.com>

On Thu, 10 Aug 2023 15:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
> 
> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
> 
> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
> 
> 
> Benchmark                Mode  Cnt    Score   Error  Units
> 
> # Before JDK-8312127
> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
> 
> # After JDK-8312127
> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
> 
> 
> The new regression test completes in <0.5s on my Mac.

It's a historical issue that the tests for this are elsewhere so it's good to add some sanity test for this legacy method.

test/jdk/java/io/FileDescriptor/Sync.java line 36:

> 34:  * @requires vm.continuations
> 35:  * @library /test/lib
> 36:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-VMContinuations Sync

Running it with -XX:-VMContinuations is probably overkill here as it will be the same as the default case.

test/jdk/java/io/FileDescriptor/Sync.java line 83:

> 81: 
> 82:         File tmpFile = File.createTempFile("FileDescriptorSync2", "tmp");
> 83:         testWith(tmpFile);

This will leave the file on the tmp file system. A try-finally to delete it might be best as we've had issues with temp file accumulating in long test runs.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15231#pullrequestreview-1573793329
PR Review Comment: https://git.openjdk.org/jdk/pull/15231#discussion_r1291415629
PR Review Comment: https://git.openjdk.org/jdk/pull/15231#discussion_r1291417472

From shade at openjdk.org  Fri Aug 11 15:32:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Aug 2023 15:32:58 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
Message-ID: <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>

> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
> 
> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
> 
> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
> 
> 
> Benchmark                Mode  Cnt    Score   Error  Units
> 
> # Before JDK-8312127
> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
> 
> # After JDK-8312127
> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
> 
> 
> The new regression test completes in <0.5s on my Mac.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15231/files
  - new: https://git.openjdk.org/jdk/pull/15231/files/19f8c6fb..e66c244a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15231&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15231&range=00-01

  Stats: 32 lines in 1 file changed: 18 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15231/head:pull/15231

PR: https://git.openjdk.org/jdk/pull/15231

From shade at openjdk.org  Fri Aug 11 15:35:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Aug 2023 15:35:28 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <1wwMOJIIp63YoHWMoD-dhTCm80gpN1TyMQ3z50q7hIU=.b75c6eb1-502f-480b-94ce-9ee719ff02b8@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
 <1wwMOJIIp63YoHWMoD-dhTCm80gpN1TyMQ3z50q7hIU=.b75c6eb1-502f-480b-94ce-9ee719ff02b8@github.com>
Message-ID: <iqR0Iw7zgPlDPV6lmM96cUC_b-g6nL8Emd8JsPaIbbE=.48cd9077-4140-4d63-838d-31e2184719de@github.com>

On Fri, 11 Aug 2023 14:32:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/io/FileDescriptor/Sync.java line 36:
> 
>> 34:  * @requires vm.continuations
>> 35:  * @library /test/lib
>> 36:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-VMContinuations Sync
> 
> Running it with -XX:-VMContinuations is probably overkill here as it will be the same as the default case.

Agreed, removed.

> test/jdk/java/io/FileDescriptor/Sync.java line 83:
> 
>> 81: 
>> 82:         File tmpFile = File.createTempFile("FileDescriptorSync2", "tmp");
>> 83:         testWith(tmpFile);
> 
> This will leave the file on the tmp file system. A try-finally to delete it might be best as we've had issues with temp file accumulating in long test runs.

Agreed. I think `try-with-resources` wrapper is cleaner here. See new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15231#discussion_r1291452045
PR Review Comment: https://git.openjdk.org/jdk/pull/15231#discussion_r1291457992

From asemenyuk at openjdk.org  Fri Aug 11 16:10:58 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 11 Aug 2023 16:10:58 GMT
Subject: RFR: 8313904: [macos] All signing tests which verifies unsigned
 app images are failing
In-Reply-To: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
Message-ID: <Sc-HONpDbgVn01nSbGGdvcH4K9kMf4o1cXC54B44lVY=.5623b5e8-33dd-4645-984d-db542e9ffae6@github.com>

On Thu, 10 Aug 2023 22:58:18 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - This is regression from [JDK-8298488](https://bugs.openjdk.org/browse/JDK-8298488).
> - Since JDK-8298488 unsigned app bundles are ad-hoc signed and `codesign` will report that app bundle is signed and thus our tests failed.
> - Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate.
> - Unsigned post process image will be ad-hoc re-sign when generating DMG or PKG, since we adding `.package` file which makes ad-hoc signature invalid. This is similar to [JDK-8293462](https://bugs.openjdk.org/browse/JDK-8293462).

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15235#pullrequestreview-1573979900

From jvernee at openjdk.org  Fri Aug 11 16:53:58 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 11 Aug 2023 16:53:58 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v3]
In-Reply-To: <J5LbOHrt9jhamepRscFbCGaF0XT3cvUDPPe4vNTtiAU=.d2409ee8-7c0e-449a-9014-1a5ce426b521@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <BstFOkZK_4kKuP3J9jRNpDYMUtjA7r0-ZEOt53wTGio=.4edf93be-8194-4d49-865c-fccbcd62709c@github.com>
 <J5LbOHrt9jhamepRscFbCGaF0XT3cvUDPPe4vNTtiAU=.d2409ee8-7c0e-449a-9014-1a5ce426b521@github.com>
Message-ID: <Rw1cqiuD_GLvd3fMpwk4w_aM6iNgkmqPeRSi0KoAUmU=.14e99038-3933-462e-ad34-ed136d4e8250@github.com>

On Thu, 10 Aug 2023 23:31:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview?

A preview API is finalized when it is ready. The preview process, as outlined by [JEP 12](https://bugs.openjdk.org/browse/JDK-8195734), does not place a mandate on the amount of changes that a JEP that finalizes a preview API should or should not contain. It only requires that the changes since the last preview iteration are noted (which we have done). Though, the amount of changes can be used to inform the decision to finalize. We feel that the FFM API is ready for finalization, and does not require another round of preview.

In this case in particular: previous iterations contained significant changes to the API, including re-shuffling of some of the core APIs. (See e.g. https://github.com/openjdk/jdk/pull/13079#issuecomment-1476648707) In contrast this JEP contains mostly superficial changes to the API, that are not likely to impact how a client would write a program using the FFM API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1675057357

From uschindler at openjdk.org  Fri Aug 11 17:23:28 2023
From: uschindler at openjdk.org (Uwe Schindler)
Date: Fri, 11 Aug 2023 17:23:28 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v4]
In-Reply-To: <2oLXen9Xs8SSrIgV9q_2KV0CA0ioUIdUZDqtsSkQ-BI=.b30a8a5b-1f03-480e-8d53-9f107ab35d64@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
 <2oLXen9Xs8SSrIgV9q_2KV0CA0ioUIdUZDqtsSkQ-BI=.b30a8a5b-1f03-480e-8d53-9f107ab35d64@github.com>
Message-ID: <yH6HkeuC0t1p_iHbQU0Ac5QtuD8TD5-vQqeh-PO69h4=.ca7050a0-799e-47d5-becc-3caad5bbb7b1@github.com>

On Fri, 11 Aug 2023 12:37:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
>> 
>> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
>> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
>> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
>> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
>> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
>> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
>> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
>> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
>> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedO...
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove spurious imports

> > Just curious, what's the rationale for finalizing the API when there are significant changes from the last preview?
> 
> A preview API is finalized when it is ready. The preview process, as outlined by [JEP 12](https://bugs.openjdk.org/browse/JDK-8195734), does not place a mandate on the amount of changes that a JEP that finalizes a preview API should or should not contain. It only requires that the changes since the last preview iteration are noted (which we have done). Though, the amount of changes can be used to inform the decision to finalize. We feel that the FFM API is ready for finalization, and does not require another round of preview.
> 
> In this case in particular: previous iterations contained significant changes to the API, including re-shuffling of some of the core APIs. (See e.g. [#13079 (comment)](https://github.com/openjdk/jdk/pull/13079#issuecomment-1476648707)) In contrast this JEP contains mostly superficial changes to the API, that are not likely to impact how a client would write a program using the FFM API.

In addition if somebody wrote code against the preview API, heshe needs to update it anyways because the class files are marked by preview flag. So all is fine. We just make API ready to use for everybody and therefor all early adopters need to adapt. t won't affect anybox else.

To me it would be strange if code goes out of preview without changes, because if there are no changes why was it in preview then in the last JDK feature version?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15103#issuecomment-1675101701

From jlu at openjdk.org  Fri Aug 11 18:55:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 11 Aug 2023 18:55:29 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in j.text.DigitList
Message-ID: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>

Please review this PR which is a broad clean up of the DigitList class (used by Format classes in j.text).

This PR is intended to be a portion of a bigger change (split up to make reviewing easier). 

The main change combines related Rounding Mode logic in `shouldRoundUp()` - (_CEILING/FLOOR_, _HALF_UP/DOWN/EVEN_)

Other changes include
- Certain for loops can be replaced with cleaner syntax (E.g. for(;;), empty for loops)
- Introduce overloaded `round(int)` - For use by Integer representations of DigitList
- Introduce `non0AfterIndex(int)` - To reduce code duplication

-------------

Commit messages:
 - Init

Changes: https://git.openjdk.org/jdk/pull/15252/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314169
  Stats: 166 lines in 1 file changed: 59 ins; 68 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/15252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15252/head:pull/15252

PR: https://git.openjdk.org/jdk/pull/15252

From aefimov at openjdk.org  Fri Aug 11 19:08:30 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 11 Aug 2023 19:08:30 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v5]
In-Reply-To: <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>
Message-ID: <PQNYZGNqO2P8mylhrT24ZH6G7BzOWQ66gJxVEfhKYjI=.44e0d435-64b1-4646-b409-e9eaf705c173@github.com>

On Wed, 9 Aug 2023 12:52:35 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class access modifier

test/jdk/com/sun/jndi/ldap/SocketCloseTest.java line 116:

> 114: 
> 115:     private static class LdapInputStream extends InputStream {
> 116:         private LdapOutputStream los;

The `LdapOutputStream` reference is not used by `LdapInputStream`, therefore the `los` field can be removed:

private static class LdapInputStream extends InputStream {
-        private LdapOutputStream los;
         private ByteArrayInputStream bos;
 
-        public LdapInputStream(LdapOutputStream los) {
-            this.los = los;
+        public LdapInputStream() {
         }
 
         @Override
@@ -144,7 +142,7 @@ public class SocketCloseTest {
     private static class CustomSocket extends Socket {
         private int closeMethodCalled = 0;
         private LdapOutputStream output = new LdapOutputStream();
-        private LdapInputStream input = new LdapInputStream(output);
+        private LdapInputStream input = new LdapInputStream();
 
         public void connect(SocketAddress address, int timeout) {
         }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1291679154

From alexander.matveev at oracle.com  Fri Aug 11 20:55:03 2023
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Fri, 11 Aug 2023 20:55:03 +0000
Subject: [External] : Re: RFR: 8313904: [macos] All signing tests which
 verifies unsigned app images are failing
In-Reply-To: <3D79C30A-0BF6-4812-9D19-4F5BADEDDC90@gmail.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
 <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>
 <7601285F-853F-40C3-888C-DD411DBBFB55@gmail.com>
 <36F7D47D-0E2B-489E-838B-470FDF1234D0@oracle.com>
 <3D79C30A-0BF6-4812-9D19-4F5BADEDDC90@gmail.com>
Message-ID: <5521ED4D-23CF-4E95-AB96-4148FA50465C@oracle.com>

Hi Michael,

On Aug 10, 2023, at 10:48 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



I assume done with jpackage by indicating something like ?mac-sign only? If wrong feel free to correct.

No, it is always done if ?mac-sign is NOT specified and we doing ad-hoc signing on app bundle only. PKG will not be ad-hoc signed.
If ?mac-sign is provided we will use certificate provided with ?mac-sign to sign app image and PKG as before.

Thanks,
Alexander

I always do dmg or app-image for quick testing. I haven?t done any pkg yet.

So if I understand correctly now for app bundle types - dmg or app-image, some signing is always done. Certificate if signing is indicated and it is provided or adhoc if it isn?t indicated as a default. I didn?t know this.

Yes, but ad-hoc signing was introduced back in JDK 20 with https://bugs.openjdk.org/browse/JDK-8298488 for macOS x64 and in JDK 19 with https://bugs.openjdk.org/browse/JDK-8277493 for macOS aarch64. We do ad-hoc signing for app images when generating PKG as well, so it is for all targets and not only for app-image or dmg.

Thanks,
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230811/a19de894/attachment-0001.htm>

From mik3hall at gmail.com  Fri Aug 11 20:56:35 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 11 Aug 2023 15:56:35 -0500
Subject: [External] : Re: RFR: 8313904: [macos] All signing tests which
 verifies unsigned app images are failing
In-Reply-To: <5521ED4D-23CF-4E95-AB96-4148FA50465C@oracle.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
 <8681CBDC-40EB-403D-90FD-EDA0EE8B5F72@gmail.com>
 <7601285F-853F-40C3-888C-DD411DBBFB55@gmail.com>
 <36F7D47D-0E2B-489E-838B-470FDF1234D0@oracle.com>
 <3D79C30A-0BF6-4812-9D19-4F5BADEDDC90@gmail.com>
 <5521ED4D-23CF-4E95-AB96-4148FA50465C@oracle.com>
Message-ID: <C8B73928-8985-4F78-AF97-E0459F5B8D09@gmail.com>



> On Aug 11, 2023, at 3:55 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
>> On Aug 10, 2023, at 10:48 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>>>> 
>>>> I assume done with jpackage by indicating something like ?mac-sign only? If wrong feel free to correct.
>>> 
>>> No, it is always done if ?mac-sign is NOT specified and we doing ad-hoc signing on app bundle only. PKG will not be ad-hoc signed.
>>> If ?mac-sign is provided we will use certificate provided with ?mac-sign to sign app image and PKG as before.
>>> 
>>> Thanks,
>>> Alexander
>> 
>> I always do dmg or app-image for quick testing. I haven?t done any pkg yet. 
>> 
>> So if I understand correctly now for app bundle types - dmg or app-image, some signing is always done. Certificate if signing is indicated and it is provided or adhoc if it isn?t indicated as a default. I didn?t know this.
> 
> Yes, but ad-hoc signing was introduced back in JDK 20 with https://bugs.openjdk.org/browse/JDK-8298488 for macOS x64 and in JDK 19 with https://bugs.openjdk.org/browse/JDK-8277493 for macOS aarch64. We do ad-hoc signing for app images when generating PKG as well, so it is for all targets and not only for app-image or dmg.
> 
> Thanks,
> Alexander

Ok, thanks again

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230811/9b4a9239/attachment-0001.htm>

From almatvee at openjdk.org  Fri Aug 11 21:22:58 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 11 Aug 2023 21:22:58 GMT
Subject: Integrated: 8313904: [macos] All signing tests which verifies unsigned
 app images are failing
In-Reply-To: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
References: <1cONCjct7zJ8615SHQHqfvC8cCT-m1twI6zx_1F2e1A=.1cea2919-ade4-4c99-bc46-36d2e147fd89@github.com>
Message-ID: <iMKvnsyjp1s6QFY39pyr-JJwigMkAvupkLF5NHa9c1A=.215851f4-4776-42b8-95df-2a1589e0b893@github.com>

On Thu, 10 Aug 2023 22:58:18 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - This is regression from [JDK-8298488](https://bugs.openjdk.org/browse/JDK-8298488).
> - Since JDK-8298488 unsigned app bundles are ad-hoc signed and `codesign` will report that app bundle is signed and thus our tests failed.
> - Fixed tests by checking that all app bundles are signed and by checking how they signed ad-hoc vs actual certificate.
> - Unsigned post process image will be ad-hoc re-sign when generating DMG or PKG, since we adding `.package` file which makes ad-hoc signature invalid. This is similar to [JDK-8293462](https://bugs.openjdk.org/browse/JDK-8293462).

This pull request has now been integrated.

Changeset: ec0cc630
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec0cc6300a02dd92b25d9072b8b3859dab583bbd
Stats:     94 lines in 8 files changed: 58 ins; 0 del; 36 mod

8313904: [macos] All signing tests which verifies unsigned app images are failing

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/15235

From duke at openjdk.org  Fri Aug 11 22:32:59 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 11 Aug 2023 22:32:59 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
Message-ID: <Yf3uh-MSpkLRbKZFseL0nJQ7lLiPi4LMl4UPOnkIQOI=.215416db-939c-4da9-a528-1312b8023060@github.com>

On Thu, 15 Jun 2023 09:21:13 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'dpqs23' of github.com:bourgesl/jdk-official into dpqs23
>  - simplified test to enable radix sort (improved sorting on period and shuffle data) + updated version to 22

Hello, please see an implementation of x86 SIMD sort for Java here: https://github.com/openjdk/jdk/pull/14227

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1675464124

From naoto at openjdk.org  Fri Aug 11 23:03:58 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 11 Aug 2023 23:03:58 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in
 j.text.DigitList
In-Reply-To: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
Message-ID: <jPVnRQANAEVYiyo-ILGgFKAsIv9JNpNcCRT_W5etMmo=.fc249269-1ee2-482e-ab89-e525beace3f2@github.com>

On Fri, 11 Aug 2023 18:27:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a broad clean up of the DigitList class (used by Format classes in j.text).
> 
> This PR is intended to be a portion of a bigger change (split up to make reviewing easier). 
> 
> The main change combines related Rounding Mode logic in `shouldRoundUp()` - (_CEILING/FLOOR_, _HALF_UP/DOWN/EVEN_)
> 
> Other changes include
> - Certain for loops can be replaced with cleaner syntax (E.g. for(;;), empty for loops)
> - Introduce overloaded `round(int)` - For use by Integer representations of DigitList
> - Introduce `non0AfterIndex(int)` - To reduce code duplication

src/java.base/share/classes/java/text/DigitList.java line 123:

> 121:      * from the given index until the end.
> 122:      */
> 123:     private boolean non0AfterIndex(int index) {

I'd prefer spelling out `0` to `Zero`.

src/java.base/share/classes/java/text/DigitList.java line 409:

> 407:      * Upon return, count will be less than or equal to maximumDigits.
> 408:      */
> 409:     private void round(int maximumDigits) {

If the method is only used for `Long` and `BigInteger`, probably use the specific name instead of explaining it in the description and overloading would be more clear to me.

src/java.base/share/classes/java/text/DigitList.java line 521:

> 519:                 if (non0AfterIndex(maximumDigits)) {
> 520:                     return (isNegative && roundingMode == RoundingMode.FLOOR)
> 521:                             || (!isNegative && roundingMode == RoundingMode.CEILING);

`roundingMode` is checked against `FLOOR`/`CEILING` twice. I don't see the need of bundling them up.

src/java.base/share/classes/java/text/DigitList.java line 526:

> 524:             case HALF_UP:
> 525:             case HALF_DOWN:
> 526:                 case HALF_EVEN:

Fix the indentation

src/java.base/share/classes/java/text/DigitList.java line 543:

> 541:                                                 && (maximumDigits > 0) && (digits[maximumDigits - 1] % 2 != 0));
> 542:                                 // Not already rounded, and not exact, round up
> 543:                             } else {

Are you sure this logic is equivalent to the previous one? Previously, `HALF_UP/DOWN` checks `valueExactAsDecimal` before `alreadyRounded`, but the new one checks `alreadyRounded` first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1291822984
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1291829499
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1291833892
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1291834906
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1291843188

From duke at openjdk.org  Sat Aug 12 22:03:28 2023
From: duke at openjdk.org (iaroslavski)
Date: Sat, 12 Aug 2023 22:03:28 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v19]
In-Reply-To: <ptbz4GUKNgTgItey6ipARJZDOM-rim2EMakqRvxVNVo=.aaa9c0f0-5f12-4804-8027-ba88ab34e9e4@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <ptbz4GUKNgTgItey6ipARJZDOM-rim2EMakqRvxVNVo=.aaa9c0f0-5f12-4804-8027-ba88ab34e9e4@github.com>
Message-ID: <dtOb-fGRa51t3r6OERX0v2mo1uqOJlNgtLiSg3rfPDE=.66573ddc-2e73-4386-97ad-4ad9eb424283@github.com>

On Sun, 12 Mar 2023 21:28:59 GMT, iaroslavski <duke at openjdk.org> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Use uninitialized array for buffers

Keeping alive for a while

-------------

PR Comment: https://git.openjdk.org/jdk/pull/3938#issuecomment-1676112600

From alanb at openjdk.org  Sun Aug 13 07:32:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 13 Aug 2023 07:32:58 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
 <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
Message-ID: <9qCigGZ01hcaCHzo7VidGW4aF_g3WBYJGgbBpPEuTaU=.df4b11bd-193d-4a21-adf7-eb1586c61fd2@github.com>

On Fri, 11 Aug 2023 15:32:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
>> 
>> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
>> 
>> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
>> 
>> 
>> Benchmark                Mode  Cnt    Score   Error  Units
>> 
>> # Before JDK-8312127
>> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
>> 
>> # After JDK-8312127
>> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
>> 
>> 
>> The new regression test completes in <0.5s on my Mac.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

AutoDelete is probably a bit overkill but okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15231#pullrequestreview-1575704528

From duke at openjdk.org  Sun Aug 13 16:43:58 2023
From: duke at openjdk.org (Christoph)
Date: Sun, 13 Aug 2023 16:43:58 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v3]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <GqXA1aWxkl9mFUjuV4AlvyqLZlkkTDLkN86DbTM7MZ4=.ad4868df-9b09-4151-81dc-8302a17b2229@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph 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 15 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591
   
   * origin/fix-8311591:
     8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
 - 8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
   
   Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>
 - Merge remote-tracking branch 'upstream/master' into fix-8311591
   
   * upstream/master: (49 commits)
     8313904: [macos] All signing tests which verifies unsigned app images are failing
     8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores
     8313798: [aarch64] sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java sometimes times out on aarch64
     8313244: NM flags handling in configure process
     8314113: G1: Remove unused G1CardSetInlinePtr::card_at
     8311648: Refactor the Arena/Chunk/ChunkPool interface
     8313224: Avoid calling JavaThread::current() in MemAllocator::Allocation constructor
     8312461: JNI warnings in SunMSCApi provider
     8312882: Update the CONTRIBUTING.md with pointers to lifecycle of a PR
     8304292: Memory leak related to ClassLoader::update_class_path_entry_list
     8313899: JVMCI exception Translation can fail in TranslatedException.<clinit>
     8313633: [macOS] java/awt/dnd/NextDropActionTest/NextDropActionTest.java fails with java.lang.RuntimeException: wrong next drop action!
     8312259: StatusResponseManager unused code clean up
     8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred barriers
     8313905: Checked_cast assert in CDS compare_by_loader
     8313654: Test WaitNotifySuspendedVThreadTest.java timed out
     8312194: test/hotspot/jtreg/applications/ctw/modules/jdk_crypto_ec.java cannot handle empty modules
     8313616: support loading library members on AIX in os::dll_load
     8313882: Fix -Wconversion warnings in runtime code
     8313239: InetAddress.getCanonicalHostName may return ip address if reverse lookup fails
     ...
 - cleanup
 - rename and cleanup
 - revert back to default size of 75 for module desriptors
   use parameter for jlink
 - add decompilation via javap
 - extract jimage
 - add some more opens and exports
   
   prepare methods for verifying
 - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591
   
   * origin/fix-8311591:
     Set module split size to 1
 - ... and 5 more: https://git.openjdk.org/jdk/compare/406ae9ec...996c187c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/9b9b0bb2..996c187c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=01-02

  Stats: 334 lines in 30 files changed: 137 ins; 78 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From ysuenaga at openjdk.org  Mon Aug 14 01:52:28 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 14 Aug 2023 01:52:28 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <Ysrw6i0IsmK8rQ4qL8uT4uwM17hUlu9Gbr7tUB6PjP4=.918c1c35-4ebb-4cfd-89e8-a32c0c6f4994@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

PING: could you review this PR? I need one more reviewer to push.

This PR has passed java/foreign jtreg tests and CI in Oracle.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15089#issuecomment-1676545828

From mbaesken at openjdk.org  Mon Aug 14 08:10:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Aug 2023 08:10:59 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
Message-ID: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>

Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
Some examples :
Events::log_dll_message for hs-err files reporting
JFR event NativeLibraryLoad
There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information

Offer an interface (e.g. jvm.cpp) to support this.

-------------

Commit messages:
 - JDK-8313764

Changes: https://git.openjdk.org/jdk/pull/15264/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313764
  Stats: 150 lines in 7 files changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264

PR: https://git.openjdk.org/jdk/pull/15264

From alanb at openjdk.org  Mon Aug 14 09:06:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Aug 2023 09:06:33 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <J70jXfotDv8W6TlxAcOvaeFbqWQZApDdqVcNd1oOuUg=.d2d3334f-0eeb-4e04-af73-05e00f47cf7a@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Having dlopen usages in non-core native libraries such as such as libsctp, libawt_xawt, ... have their dlopen usages compiled to use dlopen_ext in libjvm introduces questionable coupling that I think requires broader discussion. For the JFR NativeLibraryLoad event then I suppose there is a discussion on whether events for statically or dynamically loaded libs is interesting or not as there isn't a corresponding System.loadLibrary or SymbolLookup.libraryLookup. JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1676938047

From mbaesken at openjdk.org  Mon Aug 14 10:21:00 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 14 Aug 2023 10:21:00 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <X453xaUIPaOuRuCqTo9o-q0yI2Hdk3ujtmd0umpgkco=.be63945d-6506-43b6-9f4c-d980492b303e@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Hi Alan,

> JDK-8314152 seems to very AIX specific with shared lib caching that I would hope complicate interfaces for other ports.

yes this is of course AIX specific.  However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in  os::dll_load   calls to  SymbolEngine::recalc_search_path();
However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1677045118

From dl at openjdk.org  Mon Aug 14 11:52:00 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 14 Aug 2023 11:52:00 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 45 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Update @since tags
 - resync
 - Merge branch 'openjdk:master' into JDK-8288899
 - ExecutorService tests
 - Merge branch 'openjdk:master' into JDK-8288899
 - Rework versioning
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - Merge branch 'openjdk:master' into JDK-8288899
 - ... and 35 more: https://git.openjdk.org/jdk/compare/74dbe5b0...585769c9

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/bec6e207..585769c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=02-03

  Stats: 2087 lines in 132 files changed: 1029 ins; 543 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From dcherepanov at openjdk.org  Mon Aug 14 13:10:59 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Mon, 14 Aug 2023 13:10:59 GMT
Subject: RFR: 8313949: Missing word in GPLv2 license text in
 StackMapTableAttribute.java
Message-ID: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>

The PR suggests updating copyright headers in two files so that they are the same as in other files.

-------------

Commit messages:
 - update copyright headers

Changes: https://git.openjdk.org/jdk/pull/15269/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313949
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15269/head:pull/15269

PR: https://git.openjdk.org/jdk/pull/15269

From duke at openjdk.org  Mon Aug 14 13:27:05 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 14 Aug 2023 13:27:05 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v6]
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <vWUCEdOpInPQIwlBI2ZSm1lNpKAt9-a30EMLfkOQajA=.f77e0168-f3a8-4ccd-839d-fcb06b2d7720@github.com>

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  removed the unused variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15143/files
  - new: https://git.openjdk.org/jdk/pull/15143/files/e3e98226..b7d0c257

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15143&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143

PR: https://git.openjdk.org/jdk/pull/15143

From duke at openjdk.org  Mon Aug 14 13:27:30 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 14 Aug 2023 13:27:30 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v5]
In-Reply-To: <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <A5j8j3ljJpHuUBC9rn4E-Nv4iTbVZqws6lA3lSi8Xg4=.9fc7fc6f-ceae-4075-811b-411433838591@github.com>
Message-ID: <5qEaIA3IPBJnDIXejrhDAZm0Od8nDRjXbhv08-mavmo=.e037f36d-d568-4912-8339-117117d97502@github.com>

On Wed, 9 Aug 2023 12:52:35 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   class access modifier

Updated LdapInputStream.java and remove the unused variable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1677275894

From cstein at openjdk.org  Mon Aug 14 13:56:59 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 14 Aug 2023 13:56:59 GMT
Subject: Integrated: 8314025: Remove JUnit-based test in java/lang/invoke from
 problem list
In-Reply-To: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
References: <0taY8SdC3pnEbfwRiCkqOPWxWyrsDWDNhklFoYdpmro=.dc569ed7-99f1-4938-bcb7-16b645ea34ce@github.com>
Message-ID: <t9LIyhb8zjphAqa8owFjozJzeBwPVx1Jq4WbuISKdZA=.c187a77e-84db-4096-9a60-9c1f3716a572@github.com>

On Wed, 9 Aug 2023 10:45:56 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to remove Unit-based tests in `java/lang/invoke` from `jdk`'s problem list. The underlying race condition in jtreg was fixed in release 7.3; which is now the default version used in JDK mainline development.

This pull request has now been integrated.

Changeset: 6574dd79
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6574dd796dbb23645c87dddad427ed8f26d18323
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8314025: Remove JUnit-based test in java/lang/invoke from problem list

Reviewed-by: dholmes, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15206

From shade at openjdk.org  Mon Aug 14 14:07:30 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Aug 2023 14:07:30 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <9qCigGZ01hcaCHzo7VidGW4aF_g3WBYJGgbBpPEuTaU=.df4b11bd-193d-4a21-adf7-eb1586c61fd2@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
 <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
 <9qCigGZ01hcaCHzo7VidGW4aF_g3WBYJGgbBpPEuTaU=.df4b11bd-193d-4a21-adf7-eb1586c61fd2@github.com>
Message-ID: <JSsUZDYSbbvlkKUzXu1TGUzivhq2YIcgvgnEsUg9mo4=.c1f24c0d-2346-401b-9fbf-b164e59c065e@github.com>

On Sun, 13 Aug 2023 07:15:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> AutoDelete is probably a bit overkill but okay.

Thanks! Any more takers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15231#issuecomment-1677361679

From iris at openjdk.org  Mon Aug 14 16:05:59 2023
From: iris at openjdk.org (Iris Clark)
Date: Mon, 14 Aug 2023 16:05:59 GMT
Subject: RFR: 8313949: Missing word in GPLv2 license text in
 StackMapTableAttribute.java
In-Reply-To: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
References: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
Message-ID: <G3WJ-I1b9sXqktNuhDQeKZyaXSfz0miFrbVM_in1-NQ=.dce6a826-734e-44ad-983e-78df6dcdd08d@github.com>

On Mon, 14 Aug 2023 12:47:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The PR suggests updating copyright headers in two files so that they are the same as in other files.

The updated license appears to match the expected license:

https://github.com/openjdk/jdk/blob/master/make/data/license-templates/gpl-cp-header

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15269#pullrequestreview-1577155280

From lancea at openjdk.org  Mon Aug 14 16:11:01 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 16:11:01 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field size)
Message-ID: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>

This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::

> ZipException: Invalid CEN header (invalid zip64 extra data field size)

1. Extra field includes padding :


----------------#1--------------------
[Central Directory Header]
  0x3374: Signature    : 0x02014b50
  0x3378: Created Zip Spec :    0xa [1.0]
  0x3379: Created OS   :    0x0 [MS-DOS]
  0x337a: VerMadeby    :    0xa [0, 1.0]
  0x337b: VerExtract   :    0xa [1.0]
  0x337c: Flag      :   0x800
  0x337e: Method     :    0x0 [STORED]
  0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
  0x3384: CRC       : 0x694c6952
  0x3388: Compressed Size :   0x624
  0x338c: Uncompressed Size:   0x624
  0x3390: Name Length   :   0x1b
 0x3392: Extra Length  :    0x7
		[tag=0xcafe, sz=0, data= ]
				->[tag=cafe, size=0]
  0x3394: Comment Length :    0x0
  0x3396: Disk Start   :    0x0
  0x3398: Attrs      :    0x0
  0x339a: AttrsEx     :    0x0
  0x339e: Loc Header Offset:    0x0
  0x33a2: File Name    : res/drawable/size_48x48.jpg


The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.


2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):


----------------#359--------------------
[Central Directory Header]
   0x600b4: Signature        : 0x02014b50
   0x600b8: Created Zip Spec :       0x14 [2.0]
   0x600b9: Created OS       :        0x0 [MS-DOS]
   0x600ba: VerMadeby        :       0x14 [0, 2.0]
   0x600bb: VerExtract       :       0x14 [2.0]
   0x600bc: Flag             :      0x808
   0x600be: Method           :        0x8 [DEFLATED]
   0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
   0x600c4: CRC              : 0xd8f689cb
   0x600c8: Compressed Size  :      0x23e
   0x600cc: Uncompressed Size:      0x392
   0x600d0: Name Length      :       0x20
   0x600d2: Extra Length     :        0x8
		[tag=0xbfef, sz=61373, data=        
  0x600d4: Comment Length   :        0x0
   0x600d6: Disk Start       :        0x0
   0x600d8: Attrs            :        0x0
   0x600da: AttrsEx          :        0x0
   0x600de: Loc Header Offset:    0x4f2fe
   0x600e2: File Name        : net/n3/nanoxml/CDATAReader.class

In the above example, the extra length is `0x8` and the tag size is `61373` which exceeds the extra length.

zip -T would also report an error:

>  zip -T foo.jar 
> net/n3/nanoxml/CDATAReader.class bad extra-field entry:
>       EF block length (61373 bytes) exceeds remaining EF data (4 bytes)
> test of foo.jar FAILED


3. Some releases of Ant and commons-compress create CEN Zip64  extra headers with  a size of 0 when Zip64 mode is required :


----------------#63--------------------
[Central Directory Header]
  0x2fded9: Signature        : 0x02014b50
  0x2fdedd: Created Zip Spec :       0x2d [4.5]
  0x2fdede: Created OS       :        0x3 [UNIX]
  0x2fdedf: VerMadeby        :      0x32d [3, 4.5]
  0x2fdee0: VerExtract       :       0x2d [4.5]
  0x2fdee1: Flag             :      0x800
  0x2fdee3: Method           :        0x8 [DEFLATED]
  0x2fdee5: Last Mod Time    : 0x43516617 [Thu Oct 17 12:48:46 EDT 2013]
  0x2fdee9: CRC              :        0x0
  0x2fdeed: Compressed Size  :        0x2
  0x2fdef1: Uncompressed Size:        0x0
  0x2fdef5: Name Length      :       0x22
  0x2fdef7: Extra Length     :        0x4
       [tag=0x0001, sz=0, data= ]
         ->ZIP64: 
  0x2fdef9: Comment Length   :        0x0
  0x2fdefb: Disk Start       :        0x0
  0x2fdefd: Attrs            :        0x0
  0x2fdeff: AttrsEx          : 0x81a40000
  0x2fdf03: Loc Header Offset:     0x1440
  0x2fdf07: File Name        : .xdk_version_12.1.0.2.0_production

[Local File Header]
    0x1440: Signature   :   0x04034b50
    0x1444: Version     :         0x2d    [4.5]
    0x1446: Flag        :        0x800
    0x1448: Method      :          0x8    [DEFLATED]
    0x144a: LastMTime   :   0x43516617    [Thu Oct 17 12:48:46 EDT 2013]
    0x144e: CRC         :          0x0
    0x1452: CSize       :   0xffffffff
    0x1456: Size        :   0xffffffff
    0x145a: Name Length :         0x22    [.xdk_version_12.1.0.2.0_production]
    0x145c: ExtraLength :         0x14
       [tag=0x0001, sz=16, data= 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 ]
           ->ZIP64: size *0x0 csize *0x2 *0x2d04034b500003 
    0x145e: File Name  : [.xdk_version_12.1.0.2.0_production]

Notice the CEN Extra length differs for the same tag in the LOC. 

As we are validating the  Zip64 extra fields, we are not expecting the data size to be 0. 

Mach5 tiers 1-6 and the relevant JCK tests continue to pass with the above changes.

The following 3rd party tools have (or have pending) fixes to address  the issues highlighted above:

- Apache Commons-compress fix for [Empty CEN Zip64 Extra Headers](https://github.com/apache/commons-compress/pull/10) fixed in [Commons-compress ](https://commons.apache.org/proper/commons-compress/changes-report.html#a1.11)[1.11](https://commons.apache.org/proper/commons-compress/changes-report.html#a1.11) (2016)
- Ant fix for Empty [CEN Zip64 Extra Headers in process ](https://bz.apache.org/bugzilla/show_bug.cgi?id=66873)  will be available in  Ant 1.10.14 once it goes GA.

- BND issue with writing invalid [Extra Headers](https://issues.apache.org/jira/browse/FELIX-6622)  and is fixed in[ BND 5.3](https://github.com/bndtools/bnd/issues/4507) (2021)
- The [maven-bundle-plugin 5.1.5](https://felix.apache.org/documentation/_attachments/components/bundle-plugin/index.html) includes the BND 5.3 patch.

-------------

Commit messages:
 - Minor comment word smithing
 - Fix for JDK-8313765

Changes: https://git.openjdk.org/jdk/pull/15273/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313765
  Stats: 696 lines in 4 files changed: 676 ins; 4 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From shade at openjdk.org  Mon Aug 14 16:38:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Aug 2023 16:38:58 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size)
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <O9wbKX3y1DSTa8zqfTapKgwXQ4RWK5h43-tTAmLrF_Y=.6f680954-43d6-4cfe-87c8-715da2640148@github.com>

On Mon, 14 Aug 2023 14:52:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Please merge from master to get clean GHA runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677656274

From msheppar at openjdk.org  Mon Aug 14 17:09:29 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Mon, 14 Aug 2023 17:09:29 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v6]
In-Reply-To: <vWUCEdOpInPQIwlBI2ZSm1lNpKAt9-a30EMLfkOQajA=.f77e0168-f3a8-4ccd-839d-fcb06b2d7720@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <vWUCEdOpInPQIwlBI2ZSm1lNpKAt9-a30EMLfkOQajA=.f77e0168-f3a8-4ccd-839d-fcb06b2d7720@github.com>
Message-ID: <tHMvvhowLTl_LEuhA37Qg4yqEBXuxLtp2QiwP0BjPxc=.f9bd0d67-edee-49ac-bb1f-70871dea7a14@github.com>

On Mon, 14 Aug 2023 13:27:05 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed the unused variable

thanks for incorporating the feedback
LGTM

-------------

Marked as reviewed by msheppar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15143#pullrequestreview-1577263299

From lancea at openjdk.org  Mon Aug 14 17:33:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 17:33:30 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen 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 three additional commits since the last revision:

 - Merge branch 'master' into extraHeaders-JDK-8313765
 - Minor comment word smithing
 - Fix for JDK-8313765

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/0420ab16..6ab557c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=00-01

  Stats: 51852 lines in 1409 files changed: 24540 ins; 18833 del; 8479 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From simonis at openjdk.org  Mon Aug 14 17:41:31 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 14 Aug 2023 17:41:31 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
Message-ID: <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>

On Mon, 14 Aug 2023 17:33:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into extraHeaders-JDK-8313765
>  - Minor comment word smithing
>  - Fix for JDK-8313765

Hi Lance,
In general it looks good, but I have some suggestion that I think could slightly improve the patch.

src/java.base/share/classes/java/util/zip/ZipFile.java line 1320:

> 1318:                 zerror("Invalid CEN header (invalid zip64 extra data field size)");
> 1319:             }
> 1320:             // if ZIP64_EXTID blocksize == 0, validate csize and size

If you put this block in front of the call to `isZip64ExtBlockSizeValid()` we don't have to handle the `blockSize == 0` case in `isZip64ExtBlockSizeValid()`.

This will also make the following comment true again:

            // Note we do not need to check blockSize is >= 8 as
            // we know its length is at least 8 from the call to
            // isZip64ExtBlockSizeValid()

src/java.base/share/classes/java/util/zip/ZipFile.java line 1364:

> 1362:              * As the fields must appear in order, the block size indicates which
> 1363:              * fields to expect:
> 1364:              *  0 - May be written out by Ant and Apache Commons Compress Library

I don't like that `isZip64ExtBlockSizeValid()` still accepts `0` as *valid* input. I think we should fully handle the zero case in `checkZip64ExtraFieldValues()` (also see my comments there).

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3099:

> 3097:                         throw new ZipException("Invalid CEN header (invalid zip64 extra data field size)");
> 3098:                     }
> 3099:                     // if ZIP64_EXTID blocksize == 0, validate csize, size and

Same here. Just put this block before the call to isZip64ExtBlockSizeValid() than you don't have to handle the `sz == 0` case there.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3216:

> 3214:              */
> 3215:             return switch(blockSize) {
> 3216:                 case 0, 8, 16, 24, 28 -> true;

Don't need to handle the zero case here if you rearrange the code in `readExtra()` as suggested above.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15273#pullrequestreview-1577293869
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293755895
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293751880
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293761720
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293762891

From alanb at openjdk.org  Mon Aug 14 17:41:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 14 Aug 2023 17:41:32 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size)
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <-2eJle8BIV3yzsDywZQO5MvUcfH6FS3I7YRzVfBXqmw=.c668c1dc-3d0e-4ba7-af7a-59feff40a53a@github.com>

On Mon, 14 Aug 2023 14:52:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

It's unfortunate that there are tools and plugins in the eco system that have these issues. I think you've got the right balance here, meaning tolerating a zip64 extra block with a block size of 0 and rejecting corrupted extra blocks added by older versions of the BND plugin.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677739309

From lancea at openjdk.org  Mon Aug 14 17:55:31 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 17:55:31 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>
Message-ID: <LAdxqNAaxtraDHSs2V0bhK2ScO8XgvHBX1Bgp36bOms=.be319357-0d4d-45e5-8431-ba2a973739ed@github.com>

On Mon, 14 Aug 2023 17:15:21 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Lance Andersen 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into extraHeaders-JDK-8313765
>>  - Minor comment word smithing
>>  - Fix for JDK-8313765
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 1364:
> 
>> 1362:              * As the fields must appear in order, the block size indicates which
>> 1363:              * fields to expect:
>> 1364:              *  0 - May be written out by Ant and Apache Commons Compress Library
> 
> I don't like that `isZip64ExtBlockSizeValid()` still accepts `0` as *valid* input. I think we should fully handle the zero case in `checkZip64ExtraFieldValues()` (also see my comments there).

Hi Volker,

I understand your point and I had done that  previously  but decided I  did not like the flow of the code that way which is why I moved the check.  I prefer to leave it as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293782309

From duke at openjdk.org  Mon Aug 14 17:56:04 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 14 Aug 2023 17:56:04 GMT
Subject: Integrated: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not
 close connections on SocketTimeoutErrors
In-Reply-To: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
Message-ID: <r7vCoc_O-5jjna3Nil4_yIzsXae_Ue2gLeVao4yoHWg=.740f7592-f5ea-4b54-a523-64754c8c92e4@github.com>

On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
> 
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.

This pull request has now been integrated.

Changeset: e56d3bc2
Author:    Weibing Xiao <weibing.xiao at oracle.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e56d3bc2dab3d32453b6eda66e8434953c436084
Stats:     214 lines in 2 files changed: 205 ins; 2 del; 7 mod

8313657: com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors

Reviewed-by: vtewari, msheppar, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/15143

From aefimov at openjdk.org  Mon Aug 14 17:56:02 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 14 Aug 2023 17:56:02 GMT
Subject: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close
 connections on SocketTimeoutErrors [v6]
In-Reply-To: <vWUCEdOpInPQIwlBI2ZSm1lNpKAt9-a30EMLfkOQajA=.f77e0168-f3a8-4ccd-839d-fcb06b2d7720@github.com>
References: <O-6m3su0-pNnfQj0JOhf3pEdTAlQDCimZ9Oimt2r8Og=.995221b1-63b3-49d8-b3b2-e95d5d3f93e6@github.com>
 <vWUCEdOpInPQIwlBI2ZSm1lNpKAt9-a30EMLfkOQajA=.f77e0168-f3a8-4ccd-839d-fcb06b2d7720@github.com>
Message-ID: <4UDIOaagMme6l3RZy09zO07cRiQza63YKfPsjv1WFjQ=.dcbdad55-bba1-46e8-947f-6f61e038a60f@github.com>

On Mon, 14 Aug 2023 13:27:05 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer.
>> 
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed the unused variable

Marked as reviewed by aefimov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15143#pullrequestreview-1577326005

From serb at openjdk.org  Mon Aug 14 18:02:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 14 Aug 2023 18:02:56 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size)
In-Reply-To: <-2eJle8BIV3yzsDywZQO5MvUcfH6FS3I7YRzVfBXqmw=.c668c1dc-3d0e-4ba7-af7a-59feff40a53a@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <-2eJle8BIV3yzsDywZQO5MvUcfH6FS3I7YRzVfBXqmw=.c668c1dc-3d0e-4ba7-af7a-59feff40a53a@github.com>
Message-ID: <X-a3o8eRaBTnkeicTioFrbVfJJhLJ2fCdnYoTUSuiO8=.fc4e21b9-9a50-4bf7-8a96-6121f1c0a53b@github.com>

On Mon, 14 Aug 2023 17:16:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's unfortunate that there are tools and plugins in the eco system that have these issues. I think you've got the right balance here, meaning tolerating a zip64 extra block with a block size of 0 and rejecting corrupted extra blocks added by older versions of the BND plugin.

I think I already asked this question, but it disappeared in the latest PR: Why our code has an assumption that the extended block has some kind of limitation of the size, like 9,16,24,28, there are no such limitations in the zip specification:
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

     4.5.3 -Zip64 Extended Information Extra Field (0x0001):

      The following is the layout of the zip64 extended 
      information "extra" block. If one of the size or
      offset fields in the Local or Central directory
      record is too small to hold the required data,
      a Zip64 extended information record is created.
      The order of the fields in the zip64 extended 
      information record is fixed, but the fields MUST
      only appear if the corresponding Local or Central
      directory record field is set to 0xFFFF or 0xFFFFFFFF.

      Note: all fields stored in Intel low-byte/high-byte order.

        Value      Size       Description
        -----      ----       -----------
(ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
        Size       2 bytes    Size of this "extra" block
        Original 
        Size       8 bytes    Original uncompressed file size
        Compressed
        Size       8 bytes    Size of compressed data
        Relative Header
        Offset     8 bytes    Offset of local header record
        Disk Start
        Number     4 bytes    Number of the disk on which
                              this file starts 

      This entry in the Local header MUST include BOTH original
      and compressed file size fields. If encrypting the 


It probably comes from the Wiki page: https://en.wikipedia.org/wiki/ZIP_(file_format) but it is not a spec.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677821187

From jlu at openjdk.org  Mon Aug 14 18:05:05 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Aug 2023 18:05:05 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in
 j.text.DigitList [v2]
In-Reply-To: <jPVnRQANAEVYiyo-ILGgFKAsIv9JNpNcCRT_W5etMmo=.fc249269-1ee2-482e-ab89-e525beace3f2@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
 <jPVnRQANAEVYiyo-ILGgFKAsIv9JNpNcCRT_W5etMmo=.fc249269-1ee2-482e-ab89-e525beace3f2@github.com>
Message-ID: <_owPkhWCPS4l3-wXSSbtY3WOFbEKqAJ5_cMH2UBW1zk=.e6eb9895-aedc-4218-8e11-2a9099b83aa1@github.com>

On Fri, 11 Aug 2023 22:33:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments (8/11/23)
>
> src/java.base/share/classes/java/text/DigitList.java line 521:
> 
>> 519:                 if (non0AfterIndex(maximumDigits)) {
>> 520:                     return (isNegative && roundingMode == RoundingMode.FLOOR)
>> 521:                             || (!isNegative && roundingMode == RoundingMode.CEILING);
> 
> `roundingMode` is checked against `FLOOR`/`CEILING` twice. I don't see the need of bundling them up.

Thank you for the review. Addressed this, and your other comments that I did not explicitly respond to.

> src/java.base/share/classes/java/text/DigitList.java line 526:
> 
>> 524:             case HALF_UP:
>> 525:             case HALF_DOWN:
>> 526:                 case HALF_EVEN:
> 
> Fix the indentation

Thanks for catching (copy paste error)

> src/java.base/share/classes/java/text/DigitList.java line 543:
> 
>> 541:                                                 && (maximumDigits > 0) && (digits[maximumDigits - 1] % 2 != 0));
>> 542:                                 // Not already rounded, and not exact, round up
>> 543:                             } else {
> 
> Are you sure this logic is equivalent to the previous one? Previously, `HALF_UP/DOWN` checks `valueExactAsDecimal` before `alreadyRounded`, but the new one checks `alreadyRounded` first.

Yes, since `alreadyRounded` and `valueExactAsDecimal` are never both `true` and when either of them are `true`, it warrants a return without considering other logic. 

However, I have adjusted the code so that this is more apparent (and appears more similar to the original `HALF_DOWN/UP`, which was written more concisely).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1293781469
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1293781511
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1293781546

From jlu at openjdk.org  Mon Aug 14 18:04:44 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 14 Aug 2023 18:04:44 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in
 j.text.DigitList [v2]
In-Reply-To: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
Message-ID: <aaRnkMQplPQawqzSlpdmrkGhn4ZQ1rz4_Yy6G306MdM=.88f7c76a-ced5-4ff4-b345-82b35c9ba87a@github.com>

> Please review this PR which is a broad clean up of the DigitList class (used by Format classes in j.text).
> 
> This PR is intended to be a portion of a bigger change (split up to make reviewing easier). 
> 
> The main change combines related Rounding Mode logic in `shouldRoundUp()` - (_CEILING/FLOOR_, _HALF_UP/DOWN/EVEN_)
> 
> Other changes include
> - Certain for loops can be replaced with cleaner syntax (E.g. for(;;), empty for loops)
> - Introduce `roundInt(int)` - For use by Integer representations of DigitList
> - Introduce `nonZeroAfterIndex(int)` - To reduce code duplication

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Reflect review comments (8/11/23)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15252/files
  - new: https://git.openjdk.org/jdk/pull/15252/files/207db250..c9782b77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15252&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15252&range=00-01

  Stats: 46 lines in 1 file changed: 8 ins; 10 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/15252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15252/head:pull/15252

PR: https://git.openjdk.org/jdk/pull/15252

From serb at openjdk.org  Mon Aug 14 18:21:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 14 Aug 2023 18:21:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
Message-ID: <yRXT0D9umtaLnqylmeXi94rfsXzCxip53NI9b9OAGQw=.28004fb7-c8bd-43a3-baae-e883a1ed8d27@github.com>

On Mon, 14 Aug 2023 17:33:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into extraHeaders-JDK-8313765
>  - Minor comment word smithing
>  - Fix for JDK-8313765

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3108:

> 3106:                         break;
> 3107:                     }
> 3108:                     if (size == ZIP64_MINVAL) {

Note that we always increase "pos" only in case of "_MINVAL". If the values of size and csize are correct/valid in the "body" of the zip file and only locoff is negative then we should skip two fields in the extra block and read the third one. Otherwise, we may read some random values and throw an exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293801754

From simonis at openjdk.org  Mon Aug 14 18:21:41 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 14 Aug 2023 18:21:41 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
Message-ID: <4nbAf1njjZapxljUQj4AMqPXH4kvpd8PWUB3XveecwU=.2efe30bc-d725-49ed-b0a6-0a759294f41d@github.com>

On Mon, 14 Aug 2023 17:33:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into extraHeaders-JDK-8313765
>  - Minor comment word smithing
>  - Fix for JDK-8313765

test/jdk/java/util/zip/ZipFile/ReadNonStandardExtraHeadersTest.java line 637:

> 635:         return sb.toString();
> 636:     }
> 637: }

No newline at end of the file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293817256

From lancea at openjdk.org  Mon Aug 14 18:25:22 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 18:25:22 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <yRXT0D9umtaLnqylmeXi94rfsXzCxip53NI9b9OAGQw=.28004fb7-c8bd-43a3-baae-e883a1ed8d27@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <yRXT0D9umtaLnqylmeXi94rfsXzCxip53NI9b9OAGQw=.28004fb7-c8bd-43a3-baae-e883a1ed8d27@github.com>
Message-ID: <I5nyy956dOGec5ZxgQ8JwTYPL3du1nwerhhPiz8MEkk=.6b3c86e9-dfd8-4788-931c-fb1ff4635477@github.com>

On Mon, 14 Aug 2023 18:03:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Lance Andersen 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 three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into extraHeaders-JDK-8313765
>>  - Minor comment word smithing
>>  - Fix for JDK-8313765
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3108:
> 
>> 3106:                         break;
>> 3107:                     }
>> 3108:                     if (size == ZIP64_MINVAL) {
> 
> Note that we always increase "pos" only in case of "_MINVAL". If the values of size and csize are correct/valid in the "body" of the zip file and only locoff is negative then we should skip two fields in the extra block and read the third one. Otherwise, we may read some random values and throw an exception.

I am not sure I (quite) understand your question completely..

How ZIpFS::readExtra  has navigated these fields has not changed

 If you have a tool that creates a zip/jar that demonstrates an issue that might need further examination, please provide a test case, the tool that created the zip/jar in question and open a new bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293821603

From lancea at openjdk.org  Mon Aug 14 18:35:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 18:35:17 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size)
In-Reply-To: <X-a3o8eRaBTnkeicTioFrbVfJJhLJ2fCdnYoTUSuiO8=.fc4e21b9-9a50-4bf7-8a96-6121f1c0a53b@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <-2eJle8BIV3yzsDywZQO5MvUcfH6FS3I7YRzVfBXqmw=.c668c1dc-3d0e-4ba7-af7a-59feff40a53a@github.com>
 <X-a3o8eRaBTnkeicTioFrbVfJJhLJ2fCdnYoTUSuiO8=.fc4e21b9-9a50-4bf7-8a96-6121f1c0a53b@github.com>
Message-ID: <o8ypyQoxFOTaDPZH3RnYPARbdHyHjcfVUpmg7iD14eU=.87328227-fc51-4b18-9205-74dcee213a9d@github.com>

On Mon, 14 Aug 2023 17:59:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > It's unfortunate that there are tools and plugins in the eco system that have these issues. I think you've got the right balance here, meaning tolerating a zip64 extra block with a block size of 0 and rejecting corrupted extra blocks added by older versions of the BND plugin.
> 
> I think I already asked this question, but it disappeared in the latest PR: Why our code has an assumption that the extended block has some kind of limitation of the size, like 9,16,24,28, there are no such limitations in the zip specification: https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
> 
> ```
>      4.5.3 -Zip64 Extended Information Extra Field (0x0001):
> 
>       The following is the layout of the zip64 extended 
>       information "extra" block. If one of the size or
>       offset fields in the Local or Central directory
>       record is too small to hold the required data,
>       a Zip64 extended information record is created.
>       The order of the fields in the zip64 extended 
>       information record is fixed, but the fields MUST
>       only appear if the corresponding Local or Central
>       directory record field is set to 0xFFFF or 0xFFFFFFFF.
> 
>       Note: all fields stored in Intel low-byte/high-byte order.
> 
>         Value      Size       Description
>         -----      ----       -----------
> (ZIP64) 0x0001     2 bytes    Tag for this "extra" block type
>         Size       2 bytes    Size of this "extra" block
>         Original 
>         Size       8 bytes    Original uncompressed file size
>         Compressed
>         Size       8 bytes    Size of compressed data
>         Relative Header
>         Offset     8 bytes    Offset of local header record
>         Disk Start
>         Number     4 bytes    Number of the disk on which
>                               this file starts 
> 
>       This entry in the Local header MUST include BOTH original
>       and compressed file size fields. If encrypting the 
> ```
> 
> It probably comes from the Wiki page: https://en.wikipedia.org/wiki/ZIP_(file_format) but it is not a spec.
> 
> Note the spec also says that an extended block should be created **at least** in this case
> 
> ```
>      " size or
>       offset fields in the Local or Central directory
>       record is too small to hold the required data,
>       a Zip64 extended information record is created."
> ```
> 
> It does not say that the block cannot be empty or have any other size if all fields in the body of the zip file are correct/valid.

I am not understanding your point.  There is a specific order  for the Zip64 fields  based on which fields have the Magic value.   the spec does also not suggest that an empty Zip64  extra field can be written to the CEN when there is a Zip64 with data written to the LOC.

If you have a zip which demonstrates an issue not addressed, Please provide an a test case, with the tool created the  zip and it be can looked at.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677865727

From vlivanov at openjdk.org  Mon Aug 14 18:41:47 2023
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 14 Aug 2023 18:41:47 GMT
Subject: RFR: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <rq7dTGtvbjAJMR8Ob4yuGEEDDlRVZFlrsiL5yTyiasM=.3d177382-3c08-4969-9707-d931f0f691b2@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15089#pullrequestreview-1577434056

From serb at openjdk.org  Mon Aug 14 18:44:03 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 14 Aug 2023 18:44:03 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size)
In-Reply-To: <o8ypyQoxFOTaDPZH3RnYPARbdHyHjcfVUpmg7iD14eU=.87328227-fc51-4b18-9205-74dcee213a9d@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <-2eJle8BIV3yzsDywZQO5MvUcfH6FS3I7YRzVfBXqmw=.c668c1dc-3d0e-4ba7-af7a-59feff40a53a@github.com>
 <X-a3o8eRaBTnkeicTioFrbVfJJhLJ2fCdnYoTUSuiO8=.fc4e21b9-9a50-4bf7-8a96-6121f1c0a53b@github.com>
 <o8ypyQoxFOTaDPZH3RnYPARbdHyHjcfVUpmg7iD14eU=.87328227-fc51-4b18-9205-74dcee213a9d@github.com>
Message-ID: <idL482f_4_9lW334_Ovf7iHlCqB6OPoal4aowPBuilo=.5238d906-7486-4c66-9f23-777875dde7df@github.com>

On Mon, 14 Aug 2023 18:32:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>I am not understanding your point. There is a specific order for the Zip64 fields based on which fields have the Magic value. the spec does also not suggest that an empty Zip64 extra field can be written to the CEN when there is a Zip64 with data written to the LOC.

Yes, there is a specific order of fields that should be stored in the extended block if some of the data in the "body" is negative. But as you pointed out in this case the empty block or block bigger than necessary to store the size/csize/locoff is not prohibited by the spec. For example, take a look at the code in the [ZipEntry](https://github.com/openjdk/jdk/blob/c132176b932dd136d5c4314e08ac97d0fee7ba4d/src/java.base/share/classes/java/util/zip/ZipEntry.java#L553) where we accept any size of that block and just checked that it has required data in it.

If you disagree then point to the part of the spec which blocks such sizes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677878124

From lancea at openjdk.org  Mon Aug 14 18:49:25 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 18:49:25 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v3]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <5eqgU76m_EwkMAVsHy_eTgFN5LKurpuTKhny4MnrNEE=.3c575254-8a4f-4839-88c7-294a7bc3d5ef@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/6ab557c3..e6bae321

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From serb at openjdk.org  Mon Aug 14 18:49:45 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 14 Aug 2023 18:49:45 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <I5nyy956dOGec5ZxgQ8JwTYPL3du1nwerhhPiz8MEkk=.6b3c86e9-dfd8-4788-931c-fb1ff4635477@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <yRXT0D9umtaLnqylmeXi94rfsXzCxip53NI9b9OAGQw=.28004fb7-c8bd-43a3-baae-e883a1ed8d27@github.com>
 <I5nyy956dOGec5ZxgQ8JwTYPL3du1nwerhhPiz8MEkk=.6b3c86e9-dfd8-4788-931c-fb1ff4635477@github.com>
Message-ID: <s2VOYe5l9I-2djPcPCZKc8AHz3IB511E7ApOFKm8ewk=.df1253ac-065a-4d1e-8ef3-ab00f1b676a4@github.com>

On Mon, 14 Aug 2023 18:22:27 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3108:
>> 
>>> 3106:                         break;
>>> 3107:                     }
>>> 3108:                     if (size == ZIP64_MINVAL) {
>> 
>> Note that we always increase "pos" only in case of "_MINVAL". If the values of size and csize are correct/valid in the "body" of the zip file and only locoff is negative then we should skip two fields in the extra block and read the third one. Otherwise, we may read some random values and throw an exception.
>
> I am not sure I (quite) understand your question completely..
> 
> How ZIpFS::readExtra  has navigated these fields has not changed
> 
>  If you have a tool that creates a zip/jar that demonstrates an issue that might need further examination, please provide a test case, the tool that created the zip/jar in question and open a new bug.

The 8302483 changed this code to throw an exception, this is why I am looking into it.
You can compare the code in this file and the same code in the ZipFile in the checkZip64ExtraFieldValues method or the code in the ZipEntry#setExtra0, where we do not increase the "off" but instead checks for "off+8" or "off + 16". So if we need to read only the third field we should read "pos+16" but for the current implementation we will read it at "pos+0" since the pos was not bumped by the code for two other fields.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293844319

From serb at openjdk.org  Mon Aug 14 19:08:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 14 Aug 2023 19:08:07 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size)
In-Reply-To: <idL482f_4_9lW334_Ovf7iHlCqB6OPoal4aowPBuilo=.5238d906-7486-4c66-9f23-777875dde7df@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <-2eJle8BIV3yzsDywZQO5MvUcfH6FS3I7YRzVfBXqmw=.c668c1dc-3d0e-4ba7-af7a-59feff40a53a@github.com>
 <X-a3o8eRaBTnkeicTioFrbVfJJhLJ2fCdnYoTUSuiO8=.fc4e21b9-9a50-4bf7-8a96-6121f1c0a53b@github.com>
 <o8ypyQoxFOTaDPZH3RnYPARbdHyHjcfVUpmg7iD14eU=.87328227-fc51-4b18-9205-74dcee213a9d@github.com>
 <idL482f_4_9lW334_Ovf7iHlCqB6OPoal4aowPBuilo=.5238d906-7486-4c66-9f23-777875dde7df@github.com>
Message-ID: <nz-_363q8Ghq0OL3uwsr3QbiS7NTzJURSfSdOzTBm3s=.b08a94f8-f1c4-4dfd-aabf-a8e58e643e98@github.com>

On Mon, 14 Aug 2023 18:41:26 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > I am not understanding your point. There is a specific order for the Zip64 fields based on which fields have the Magic value. the spec does also not suggest that an empty Zip64 extra field can be written to the CEN when there is a Zip64 with data written to the LOC.
> 
> Yes, there is a specific order of fields that should be stored in the extended block if some of the data in the "body" is negative. But as you pointed out in this case the empty block or block bigger than necessary to store the size/csize/locoff is not prohibited by the spec. For example, take a look at the code in the [ZipEntry](https://github.com/openjdk/jdk/blob/c132176b932dd136d5c4314e08ac97d0fee7ba4d/src/java.base/share/classes/java/util/zip/ZipEntry.java#L553) where we accept any size of that block and just checked that it has required data in it.
> 
> If you disagree then point to the part of the spec which blocks such sizes.

This is how it is implemented by the "unzip"
https://github.com/madler/zlib/blob/04f42ceca40f73e2978b50e93806c2a18c1281fc/contrib/minizip/unzip.c#L1035C68-L1035C76 , the dataSize is accepted as is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677908114

From simonis at openjdk.org  Mon Aug 14 19:12:07 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 14 Aug 2023 19:12:07 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v3]
In-Reply-To: <5eqgU76m_EwkMAVsHy_eTgFN5LKurpuTKhny4MnrNEE=.3c575254-8a4f-4839-88c7-294a7bc3d5ef@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <5eqgU76m_EwkMAVsHy_eTgFN5LKurpuTKhny4MnrNEE=.3c575254-8a4f-4839-88c7-294a7bc3d5ef@github.com>
Message-ID: <YngwrMNWlM05df2IYahULzntYEnEndCHLH2svUJWGn8=.e135f1b7-9626-4107-b8d7-207655e95e57@github.com>

On Mon, 14 Aug 2023 18:49:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add newline

There's one final thing I want to mention. Your current test cases (i.e. the corrupted zip-files in `ReadNonStandardExtraHeadersTest.`) only reproduce the problem with `ZipFile` but not with `ZipFileSystem`. That's because of a slightly different logic in [`ZipFileSystem$Entry::readExtra()`](https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java#L3081) because of which the error will only be triggered if the `ZIP64_EXTID` Extra Block will be followed by another Extra Block. So we need a Zip file with a 0-length ZIP64_EXTID Extra Block followed by another Extra Block in order to trigger the issue. 

I've therefore attached a zip file (`ZeroLengthZIP64EXTID.zip`) which was created by ANT 1.10.7 from a directory containing a single, zero-length file and the following `build.xml` file:

<project name="ZipFiles" default="zip">
    <target name="zip">
        <zip destfile="/tmp/output.zip" zip64Mode="always" createUnicodeExtraFields="always">
            <fileset dir="/tmp/testfiles" includes="**/*" />
        </zip>
    </target>
</project>

- `zip64Mode="always"` is required in order to produce a `ZIP64_EXTID` Extra Field with zero length (which triggers the problem).
- `createUnicodeExtraFields="always"`  is required in order to produce a second Extra Field after `ZIP64_EXTID`.

I think it would be good if you could add that as test case as well.
[ZeroLengthZIP64EXTID.zip](https://github.com/openjdk/jdk/files/12338707/ZeroLengthZIP64EXTID.zip)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677913675

From lancea at openjdk.org  Mon Aug 14 20:31:08 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 20:31:08 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v3]
In-Reply-To: <5eqgU76m_EwkMAVsHy_eTgFN5LKurpuTKhny4MnrNEE=.3c575254-8a4f-4839-88c7-294a7bc3d5ef@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <5eqgU76m_EwkMAVsHy_eTgFN5LKurpuTKhny4MnrNEE=.3c575254-8a4f-4839-88c7-294a7bc3d5ef@github.com>
Message-ID: <4e5dspDcLAJUMJ_T8BvMGZLR8EB8HJZS68D-mwuT210=.425d38e4-2e28-4015-ab18-fbc1d286a8c8@github.com>

On Mon, 14 Aug 2023 18:49:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add newline

> > > I am not understanding your point. There is a specific order for the Zip64 fields based on which fields have the Magic value. the spec does also not suggest that an empty Zip64 extra field can be written to the CEN when there is a Zip64 with data written to the LOC.
> > 
> > 
> > Yes, there is a specific order of fields that should be stored in the extended block if some of the data in the "body" is negative. But as you pointed out in this case the empty block or block bigger than necessary to store the size/csize/locoff is not prohibited by the spec. For example, take a look at the code in the [ZipEntry](https://github.com/openjdk/jdk/blob/c132176b932dd136d5c4314e08ac97d0fee7ba4d/src/java.base/share/classes/java/util/zip/ZipEntry.java#L553) where we accept any size of that block and just checked that it has required data in it.
> > If you disagree then point to the part of the spec which blocks such sizes.
> 
> This is how it is implemented by the "unzip" https://github.com/madler/zlib/blob/04f42ceca40f73e2978b50e93806c2a18c1281fc/contrib/minizip/unzip.c#L1035C68-L1035C76 , the dataSize is accepted as is.

> 4.6.2 Third-party Extra Fields MUST include a Header ID using
>    the format defined in the section of this document 
>    titled Extensible Data Fields (section 4.5).
> 
>    The Data Size field indicates the size of the following
>    data block. Programs can use this value to skip to the
>    next header block, passing over any data blocks that are
>    not of interest.

Zip -T would also report errors with a BND modified jar:

 zip -T bad.jar

>  net/n3/nanoxml/CDATAReader.class bad extra-field entry:
>        EF block length (61373 bytes) exceeds remaining EF data (4 bytes)
>  test of bad.jar FAILED
> 
> zip error: Zip file invalid, could not spawn unzip, or wrong unzip (original files unmodified)
> 

zipdetails would also fail with the above jar

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1678012762

From prr at openjdk.org  Mon Aug 14 20:42:07 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 14 Aug 2023 20:42:07 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <IJSqm24JaP77kYP_UgPL7Kvf8wPLDn3NqM8k52FkEnI=.0d121538-024a-46f0-9bc1-9ba05a4549f7@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

I don't see why we need this .. 
The desktop module has a LOT of calls to dlopen() .. I wasn't sure why you were only interested in two of them.
I suspect because there's #ifdef AIX blocks in both of these files that do AIX-specific things for the dlopen .. but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ? 

And I'd prefer that if anything is done that whatever you need to do be entirely within that #ifdef AIX block and so not affect anything else.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678026889

From lancea at openjdk.org  Mon Aug 14 20:51:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 20:51:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v4]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <c8FUbMeku6uIxrgxMppz__Fag8NCQy6rrEzVGoTDow8=.8b72d97a-2034-4692-829e-38db259687da@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added an additional test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/e6bae321..5f27087b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=02-03

  Stats: 230 lines in 1 file changed: 229 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From duke at openjdk.org  Mon Aug 14 21:07:43 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Mon, 14 Aug 2023 21:07:43 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate
Message-ID: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>

`Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:

final int size = (1 << 30) + 1;
final List<Byte> list = new ArrayList<>(size);
for (int i = 0; i < size; ++i)
    list.add((byte) 0);
Collections.rotate(list, size - 1);

Output:
```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```

In that case private method `Collections.rotate1` will be called. And the line:
`i += distance;`
will cause overflow. I fixed this method and wrote a test for it.

I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.

Kindly ask you to raise a bug.

-------------

Commit messages:
 - 83141345: fix overflow in Collections.rotate

Changes: https://git.openjdk.org/jdk/pull/15270/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314236
  Stats: 52 lines in 2 files changed: 45 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From shade at openjdk.org  Mon Aug 14 21:07:43 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Aug 2023 21:07:43 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <nL2GHQrXWUoaggM6Z7EbJ24lUiBq8vRYuQS3w7DcGew=.a53b3bef-cedb-4151-8132-a51a5518a394@github.com>

On Mon, 14 Aug 2023 12:56:46 GMT, Nikita Sakharin <duke at openjdk.org> wrote:

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Submitted: [JDK-8314236](https://bugs.openjdk.org/browse/JDK-8314236)

Please change the PR synopsis to: "8314236: Overflow in Collections.rotate".

Also go to https://github.com/nikita-sakharin/jdk/actions, and enable testing workflows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1678006190

From lancea at openjdk.org  Mon Aug 14 21:08:54 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 21:08:54 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v5]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <tZDdHohVTvGkL1-PBxfKOKzjl40RsmhTX6G3cfRgd64=.cd5bef2f-e7e5-4d55-a84b-6d37838d73cb@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Added an additional test with with 0 extra header followed by an extra header with a data size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/5f27087b..eee210a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=03-04

  Stats: 68 lines in 1 file changed: 68 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From serb at openjdk.org  Mon Aug 14 21:16:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 14 Aug 2023 21:16:07 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v3]
In-Reply-To: <4e5dspDcLAJUMJ_T8BvMGZLR8EB8HJZS68D-mwuT210=.425d38e4-2e28-4015-ab18-fbc1d286a8c8@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <5eqgU76m_EwkMAVsHy_eTgFN5LKurpuTKhny4MnrNEE=.3c575254-8a4f-4839-88c7-294a7bc3d5ef@github.com>
 <4e5dspDcLAJUMJ_T8BvMGZLR8EB8HJZS68D-mwuT210=.425d38e4-2e28-4015-ab18-fbc1d286a8c8@github.com>
Message-ID: <D9DAhgr3Q6a-eNa3_0jT4Zn55mlua29oI1sWmIHcSOc=.6cc0221e-dff9-4443-931f-c8359de54951@github.com>

On Mon, 14 Aug 2023 20:28:08 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > net/n3/nanoxml/CDATAReader.class bad extra-field entry:
> > EF block length (61373 bytes) exceeds remaining EF data (4 bytes)
> > test of bad.jar FAILED
> > zip error: Zip file invalid, could not spawn unzip, or wrong unzip (original files unmodified)
> 
> zipdetails would also fail with the above jar

It seems that error " EF block length (30837 bytes) exceeds remaining EF data" caused by the fact the size was too big for the actual zipfile, which I think is a different issue, but you can try to unzip that file, and you will get a result w/o errors. unzip implementation is linked above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1678071099

From lancea at openjdk.org  Mon Aug 14 21:21:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 21:21:30 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add additional zip to the DataProvider so it is exercised

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/eee210a1..8b0d2363

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From simonis at openjdk.org  Mon Aug 14 21:24:15 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 14 Aug 2023 21:24:15 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v5]
In-Reply-To: <tZDdHohVTvGkL1-PBxfKOKzjl40RsmhTX6G3cfRgd64=.cd5bef2f-e7e5-4d55-a84b-6d37838d73cb@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <tZDdHohVTvGkL1-PBxfKOKzjl40RsmhTX6G3cfRgd64=.cd5bef2f-e7e5-4d55-a84b-6d37838d73cb@github.com>
Message-ID: <j3WvliWdbbSPfIxzRglNbmYtZKE6KjFsuG66TKE1YWg=.b1d8df40-5804-4f54-b148-039203060eb5@github.com>

On Mon, 14 Aug 2023 21:08:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added an additional test with with 0 extra header followed by an extra header with a data size

Changes requested by simonis (Reviewer).

test/jdk/java/util/zip/ZipFile/ReadNonStandardExtraHeadersTest.java line 863:

> 861:         Files.write(VALID_APACHE_COMPRESS_JAR, COMMONS_COMPRESS_JAR);
> 862:         Files.write(VALID_ANT_JAR, ANT_ZIP64_UNICODE_EXTRA_JAR);
> 863:         Files.write(VALID_ANT_JAR, ANT_ZIP64_UNICODE_EXTRA_ZIP);

This should probably read `VALID_ANT_ZIP` instead of `VALID_ANT_JAR`.

test/jdk/java/util/zip/ZipFile/ReadNonStandardExtraHeadersTest.java line 871:

> 869:      */
> 870:     private static Stream<Path> zipFilesToTest() {
> 871:         return Stream.of(VALID_APK, VALID_APACHE_COMPRESS_JAR, VALID_ANT_JAR);

And here you probably want to add `VALID_ANT_ZIP` in addition to `VALID_ANT_JAR`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15273#pullrequestreview-1577662528
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293977435
PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293978132

From lancea at openjdk.org  Mon Aug 14 21:29:15 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 14 Aug 2023 21:29:15 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v5]
In-Reply-To: <j3WvliWdbbSPfIxzRglNbmYtZKE6KjFsuG66TKE1YWg=.b1d8df40-5804-4f54-b148-039203060eb5@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <tZDdHohVTvGkL1-PBxfKOKzjl40RsmhTX6G3cfRgd64=.cd5bef2f-e7e5-4d55-a84b-6d37838d73cb@github.com>
 <j3WvliWdbbSPfIxzRglNbmYtZKE6KjFsuG66TKE1YWg=.b1d8df40-5804-4f54-b148-039203060eb5@github.com>
Message-ID: <QjqGt1UebUbn1_vQ3goiZSjE2WO3aZxuHStnRbN4LSk=.bee72a0a-f3b5-4eea-acf9-31e865516973@github.com>

On Mon, 14 Aug 2023 21:16:27 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added an additional test with with 0 extra header followed by an extra header with a data size
>
> test/jdk/java/util/zip/ZipFile/ReadNonStandardExtraHeadersTest.java line 871:
> 
>> 869:      */
>> 870:     private static Stream<Path> zipFilesToTest() {
>> 871:         return Stream.of(VALID_APK, VALID_APACHE_COMPRESS_JAR, VALID_ANT_JAR);
> 
> And here you probably want to add `VALID_ANT_ZIP` in addition to `VALID_ANT_JAR`.

Yep, already caught that typo, forgot to save before I committed :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293984884

From simonis at openjdk.org  Mon Aug 14 21:41:08 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 14 Aug 2023 21:41:08 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <LAdxqNAaxtraDHSs2V0bhK2ScO8XgvHBX1Bgp36bOms=.be319357-0d4d-45e5-8431-ba2a973739ed@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>
 <LAdxqNAaxtraDHSs2V0bhK2ScO8XgvHBX1Bgp36bOms=.be319357-0d4d-45e5-8431-ba2a973739ed@github.com>
Message-ID: <7JehWv6SeJmo_06epcO8t3hWRrRlfWUDRhubjOqERqA=.70420e94-fb5d-4b2b-943d-4f19922d9899@github.com>

On Mon, 14 Aug 2023 17:44:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1364:
>> 
>>> 1362:              * As the fields must appear in order, the block size indicates which
>>> 1363:              * fields to expect:
>>> 1364:              *  0 - May be written out by Ant and Apache Commons Compress Library
>> 
>> I don't like that `isZip64ExtBlockSizeValid()` still accepts `0` as *valid* input. I think we should fully handle the zero case in `checkZip64ExtraFieldValues()` (also see my comments there).
>
> Hi Volker,
> 
> I understand your point and I had done that  previously  but decided I  did not like the flow of the code that way which is why I moved the check.  I prefer to leave it as is.

I don't think this is a question of "taste" because `isZip64ExtBlockSizeValid()` suggests that the method will check for *valid* sizes and to my understanding `0` is not a valid input. This method might also be called from other places in the future which do not handle the zero case appropriately.

In any case, I'm ready to accept this as a case of "Disagree and Commit"  :) but in that case please update at least the comment below to something like "*..Note we do not need to check blockSize is >= 8 as we know its length is at least 8 by now*" because "*..from the call to isZip64ExtBlockSizeValid()*" isn't true any more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1293994175

From mchung at openjdk.org  Mon Aug 14 22:10:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 14 Aug 2023 22:10:10 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v3]
In-Reply-To: <GqXA1aWxkl9mFUjuV4AlvyqLZlkkTDLkN86DbTM7MZ4=.ad4868df-9b09-4151-81dc-8302a17b2229@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <GqXA1aWxkl9mFUjuV4AlvyqLZlkkTDLkN86DbTM7MZ4=.ad4868df-9b09-4151-81dc-8302a17b2229@github.com>
Message-ID: <AvyLRgpr8hcSQScz1asIb8DX5xXUi6jeOu19TkV004U=.d8a2bebc-9156-4c79-b2ed-b92805bfb666@github.com>

On Sun, 13 Aug 2023 16:43:58 GMT, Christoph <duke at openjdk.org> wrote:

>> Add new test case with sample modules that contains some requires/exports/uses/provides.
>> 
>> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
>> 
>> Follow up task from https://github.com/openjdk/jdk/pull/14408
>
> Christoph 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 15 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591
>    
>    * origin/fix-8311591:
>      8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
>  - 8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder
>    
>    Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>
>  - Merge remote-tracking branch 'upstream/master' into fix-8311591
>    
>    * upstream/master: (49 commits)
>      8313904: [macos] All signing tests which verifies unsigned app images are failing
>      8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores
>      8313798: [aarch64] sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java sometimes times out on aarch64
>      8313244: NM flags handling in configure process
>      8314113: G1: Remove unused G1CardSetInlinePtr::card_at
>      8311648: Refactor the Arena/Chunk/ChunkPool interface
>      8313224: Avoid calling JavaThread::current() in MemAllocator::Allocation constructor
>      8312461: JNI warnings in SunMSCApi provider
>      8312882: Update the CONTRIBUTING.md with pointers to lifecycle of a PR
>      8304292: Memory leak related to ClassLoader::update_class_path_entry_list
>      8313899: JVMCI exception Translation can fail in TranslatedException.<clinit>
>      8313633: [macOS] java/awt/dnd/NextDropActionTest/NextDropActionTest.java fails with java.lang.RuntimeException: wrong next drop action!
>      8312259: StatusResponseManager unused code clean up
>      8314061: [JVMCI] DeoptimizeALot stress logic breaks deferred barriers
>      8313905: Checked_cast assert in CDS compare_by_loader
>      8313654: Test WaitNotifySuspendedVThreadTest.java timed out
>      8312194: test/hotspot/jtreg/applications/ctw/modules/jdk_crypto_ec.java cannot handle empty modules
>      8313616: support loading library members on AIX in os::dll_load
>      8313882: Fix -Wconversion warnings in runtime code
>      8313239: InetAddress.getCanonicalHostName may return ip address if reverse lookup fails
>      ...
>  - cleanup
>  - rename and cleanup
>  - revert back to default size of 75 for module desriptors
>    use parameter for jlink
>  - add decompilati...

Thanks for adding this case.   The steps to extract from jimage and inspect the generated bytecode of `SystemModules$all` is for us to manually verify if the test does the work, i.e. each `subX` method adds more local variables due to deduplication.   It's not needed in the test itself.

Since the batch size is 1, I would suggest that `p4.Main` can also load `jdk.internal.module.SystemModules$all` and verify the expected numbers of `subX` methods (one per each module).   To find all modules in the image, you can simply do `ModuleFinder.ofSystem().findAll()`.

BTW, `dedup/src/*` files should also have the copyright header.

test/jdk/tools/jlink/JLink100Modules.java line 46:

> 44:  *          jdk.compiler
> 45:  * @build tests.*
> 46:  *        jdk.test.lib.compiler.CompilerUtils

This change is not needed, right?

test/jdk/tools/jlink/JLinkDedupTestBatchSizeOne.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

copyright header start year is 2023.

test/jdk/tools/jlink/JLinkDedupTestBatchSizeOne.java line 87:

> 85:     public static void main(String[] args) throws Throwable {
> 86:         compileAll();
> 87:         Path src = Paths.get("bug8311591");

suggest to rename `src` to `image` to make it clear that it's the resulting image.

test/jdk/tools/jlink/JLinkDedupTestBatchSizeOne.java line 94:

> 92:                 .addMods("m1")
> 93:                 .addMods("m2")
> 94:                 .addMods("m2")

I think it's not needed.

test/jdk/tools/jlink/dedup/src/m1/module-info.java line 13:

> 11: 
> 12:     provides ServiceInterface
> 13:             with AInterface;

Nit: this can be in 1 line.  No line break needed.  Same for other module-info file.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15234#pullrequestreview-1577366289
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1294001939
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1294002211
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1294005310
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1293799917
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1293795648

From ysuenaga at openjdk.org  Mon Aug 14 23:17:17 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 14 Aug 2023 23:17:17 GMT
Subject: Integrated: 8313406: nep_invoker_blob can be simplified more
In-Reply-To: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
References: <ca-iKkSeH8MjkMpLcCIhAbLmSn9idhIeJOuREuyIEu8=.00516ac0-5191-48db-99bc-ca3ecd0362a2@github.com>
Message-ID: <lKCXby-vLzuR3wq2n6ohI1mpo4k75UoWBvT-OCwy9KE=.083d8c75-3024-4d0f-8ea2-9e2a83066a38@github.com>

On Mon, 31 Jul 2023 12:22:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> In FFM, native function would be called via `nep_invoker_blob`. If the function has two arguments, it would be following:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fcae394cd10
> --------------------------------------------------------------------------------
>   0x00007fcae394cd80: pushq %rbp
>   0x00007fcae394cd81: movq %rsp, %rbp
>   0x00007fcae394cd84: subq $0, %rsp
>  ;; { argument shuffle
>   0x00007fcae394cd88: movq %r8, %rax
>   0x00007fcae394cd8b: movq %rsi, %r10
>   0x00007fcae394cd8e: movq %rcx, %rsi
>   0x00007fcae394cd91: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fcae394cd94: callq *%r10
>   0x00007fcae394cd97: leave
>   0x00007fcae394cd98: retq
> 
> 
> `subq $0, %rsp` is for shadow space on stack, and `movq %r8, %rax` is number of args for variadic function. So they are not necessary in some case. They should be remove following if they are not needed:
> 
> 
> Decoding RuntimeStub - nep_invoker_blob 0x00007fd8778e2810
> --------------------------------------------------------------------------------
>   0x00007fd8778e2880: pushq %rbp
>   0x00007fd8778e2881: movq %rsp, %rbp
>  ;; { argument shuffle
>   0x00007fd8778e2884: movq %rsi, %r10
>   0x00007fd8778e2887: movq %rcx, %rsi
>   0x00007fd8778e288a: movq %rdx, %rdi
>  ;; } argument shuffle
>   0x00007fd8778e288d: callq *%r10
>   0x00007fd8778e2890: leave
>   0x00007fd8778e2891: retq
> 
> 
> All java/foreign jtreg tests are passed.
> 
> We can see these stub code on [ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/examples/cpumodel) with `-XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode` and hsdis library. This testcase linked the code with `Linker.Option.isTrivial()`.
> 
> After this change, FFM performance on [another ffmasm testcase](https://github.com/YaSuenag/ffmasm/tree/ef7a466ca9607164dbe7be7e68ea509d4bdac998/benchmarks/funccall) was improved:
> 
> before:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  106664071.816 ? 14396524.718  ops/s
> FuncCallComparison.rdtsc           thrpt    3  108024079.738 ? 13223921.011  ops/s
> 
> 
> after:
> 
> Benchmark                           Mode  Cnt          Score          Error  Units
> FuncCallComparison.invokeFFMRDTSC  thrpt    3  107622971.525 ? 12249767.134  ops/s
> FuncCallComparison.rdtsc           thrpt    3  107695741.608 ? 23983281.346  ops/s
> 
> 
> Environment:
> * CPU: AMD Ryzen 3 3300X
> * OS: Fedora 38 x86_64 (Kernel 6.3.8-200.fc38.x86_64)
> * Hyper-V 4vCPU, 8GB mem

This pull request has now been integrated.

Changeset: 583cb754
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/583cb754f38f5d32144e302ce5e82a3b36a2cb78
Stats:     41 lines in 3 files changed: 4 ins; 11 del; 26 mod

8313406: nep_invoker_blob can be simplified more

Reviewed-by: jvernee, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/15089

From serb at openjdk.org  Tue Aug 15 00:10:09 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Aug 2023 00:10:09 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
Message-ID: <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>

On Mon, 14 Aug 2023 21:21:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional zip to the DataProvider so it is exercised

[TEST.zip](https://github.com/openjdk/jdk/files/12340301/TEST.zip)

try this example, zip -T passed, unzip works fine, but openjdk rejects it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1678251452

From dholmes at openjdk.org  Tue Aug 15 04:30:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Aug 2023 04:30:06 GMT
Subject: RFR: 8313949: Missing word in GPLv2 license text in
 StackMapTableAttribute.java
In-Reply-To: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
References: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
Message-ID: <QrnoBNGNGjBsjkpSqJsAtID7m4NJNKR9vGUssneyG_A=.e9d1ac6d-062e-4f2f-854f-e43acab89f9e@github.com>

On Mon, 14 Aug 2023 12:47:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The PR suggests updating copyright headers in two files so that they are the same as in other files.

Looks good.

I'm very surprised our header validation process did not pick this up.

Thanks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15269#pullrequestreview-1577949854

From duke at openjdk.org  Tue Aug 15 07:32:30 2023
From: duke at openjdk.org (Qing Xiao)
Date: Tue, 15 Aug 2023 07:32:30 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
Message-ID: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>

Modified all tests under lib-test/jdk to use JUnit

-------------

Commit messages:
 - Corrected the testSecondArrayIsNull() in ArrayDiffTest and modified format.
 - Modified all tests under lib-test/jdk to use JUnit

Changes: https://git.openjdk.org/jdk/pull/15131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313612
  Stats: 288 lines in 5 files changed: 45 ins; 26 del; 217 mod
  Patch: https://git.openjdk.org/jdk/pull/15131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15131/head:pull/15131

PR: https://git.openjdk.org/jdk/pull/15131

From cstein at openjdk.org  Tue Aug 15 07:32:30 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Aug 2023 07:32:30 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
Message-ID: <o9-J0iT4vYxP-YpfuP-T1rJ8XCoR6Wnvv06Z-3l_yMg=.3e3bb8c5-7be0-44c0-9db6-0b0874ff5f3a@github.com>

On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified all tests under lib-test/jdk to use JUnit

Marked as reviewed by cstein (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15131#pullrequestreview-1578082673

From mbaesken at openjdk.org  Tue Aug 15 07:43:23 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 15 Aug 2023 07:43:23 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <AEryJxVLekumt8z5_vuefEui0ItIi2cGZE3uA-Kh-_I=.23057281-1e7c-47b1-b769-adef5ff57958@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Hi Phil, yes there are of course more call sites of dlopen in the JDK C codebase.
I could cover them too, if this is wished.

> . but I'm still not sure I understand .. why is what you are doing only wanted for the AIX cases ?

The lib cache update ` LoadedLibraries::reload();`   is  AIX specific;  the UL and JFR events are cross platform.

( Btw. in our proprietary JVM we have this approach for many years )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1678538226

From alanb at openjdk.org  Tue Aug 15 08:06:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 08:06:08 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v2]
In-Reply-To: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com>
Message-ID: <vOnYiqdjTcH05Nt-yjqWux_XAiU7RcFBB3--e1W5dTo=.cabbf243-2b21-414b-92c9-5ad9882daea3@github.com>

On Wed, 12 Jul 2023 15:06:36 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert StreamTokenizer.java

Now that the incompatible change to StreamTokenizer is dropped from this change then I assume the rest can be reviewed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1678560892

From jjiang at openjdk.org  Tue Aug 15 08:07:08 2023
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 15 Aug 2023 08:07:08 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
Message-ID: <BDzzIhVCz0rVMuInnhmdPRnsRU1u0LCiUgZMiR5u2dI=.210d14df-ffc0-4659-8192-93e61c30b967@github.com>

On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified all tests under lib-test/jdk to use JUnit

test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, 2023, Oracle and/or its affiliates. All rights reserved.

Should it just modify the second year, here is `2021`, to `2023`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1294304121

From cstein at openjdk.org  Tue Aug 15 08:10:12 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Aug 2023 08:10:12 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: <BDzzIhVCz0rVMuInnhmdPRnsRU1u0LCiUgZMiR5u2dI=.210d14df-ffc0-4659-8192-93e61c30b967@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
 <BDzzIhVCz0rVMuInnhmdPRnsRU1u0LCiUgZMiR5u2dI=.210d14df-ffc0-4659-8192-93e61c30b967@github.com>
Message-ID: <aPbLjZv3oURnWlE5ShO7psHLmpg-iCKEXITaKQyHUKU=.fc6e021e-e18f-4e9c-8531-38e9fd698a4e@github.com>

On Tue, 15 Aug 2023 08:03:59 GMT, John Jiang <jjiang at openjdk.org> wrote:

>> Modified all tests under lib-test/jdk to use JUnit
>
> test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2021, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Should it just modify the second year, here is `2021`, to `2023`?

Yes, good catch!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1294306627

From cstein at openjdk.org  Tue Aug 15 08:13:12 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 15 Aug 2023 08:13:12 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
Message-ID: <Yc772eoTWy4mILS7QARSZLR7FV2b8CEKkat1PKOkg5o=.3efb3731-0886-4a41-96d9-4456fd13d0bb@github.com>

On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified all tests under lib-test/jdk to use JUnit

Please only keep first and last/latest year of changes.

test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2020, 2023, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2019, 2023, Oracle and/or its affiliates. All rights reserved.

test/lib-test/jdk/test/lib/hexdump/ObjectStreamPrinterTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2021, 2023, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2019, 2023, Oracle and/or its affiliates. All rights reserved.

-------------

Changes requested by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15131#pullrequestreview-1578134852
PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1294308211
PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1294308602

From alanb at openjdk.org  Tue Aug 15 08:14:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 08:14:12 GMT
Subject: [jdk21] RFR: 8313312: Add missing classpath exception copyright
 header
In-Reply-To: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
References: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
Message-ID: <dro8y8UaF4NXNbssisd5coKIb50FREiYP1WeTieBL2w=.a38469e9-635b-4842-b96a-efe34d024c74@github.com>

On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The same copyright updates are needed in JDK21.

JDK 21 is in the RC phase so I assume this should re-targeted to jdk21u.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/166#issuecomment-1678567910

From dcherepanov at openjdk.org  Tue Aug 15 08:46:14 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 15 Aug 2023 08:46:14 GMT
Subject: RFR: 8313949: Missing word in GPLv2 license text in
 StackMapTableAttribute.java
In-Reply-To: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
References: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
Message-ID: <Tq4Sxc2iCAqwnHEp6y13KE1YSWq9XbVC8_WzJWwNhbA=.a53c4fe6-90b4-4b0d-8b51-7be8be7407ab@github.com>

On Mon, 14 Aug 2023 12:47:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The PR suggests updating copyright headers in two files so that they are the same as in other files.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15269#issuecomment-1678603082

From dcherepanov at openjdk.org  Tue Aug 15 08:46:15 2023
From: dcherepanov at openjdk.org (Dmitry Cherepanov)
Date: Tue, 15 Aug 2023 08:46:15 GMT
Subject: Integrated: 8313949: Missing word in GPLv2 license text in
 StackMapTableAttribute.java
In-Reply-To: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
References: <j7Srl3BxYJJdZ_Wr5YGFtOmPPvSplGmLmbLa_8TfGN4=.3620eb47-bbcd-4b16-bfbe-56fe41a5b972@github.com>
Message-ID: <k-zcdmV8OwFyaABYVvvtCUEDw7TYGalbXV_ehMK41JM=.a3209ac7-2c8a-4b27-9d02-0b7b1c87d5d3@github.com>

On Mon, 14 Aug 2023 12:47:46 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> The PR suggests updating copyright headers in two files so that they are the same as in other files.

This pull request has now been integrated.

Changeset: f4e72c58
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4e72c58d7b188563a0413161419f91e024ec472
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8313949: Missing word in GPLv2 license text in StackMapTableAttribute.java

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/15269

From shade at openjdk.org  Tue Aug 15 08:49:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Aug 2023 08:49:07 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
 <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
Message-ID: <q1hypx3ZrELrmn3qr6yaP5Jp1HWcFzTQBhjtqP1L9b0=.5dc95dea-b076-4c1b-9bfb-1f3180f364b5@github.com>

On Fri, 11 Aug 2023 15:32:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
>> 
>> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
>> 
>> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
>> 
>> 
>> Benchmark                Mode  Cnt    Score   Error  Units
>> 
>> # Before JDK-8312127
>> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
>> 
>> # After JDK-8312127
>> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
>> 
>> 
>> The new regression test completes in <0.5s on my Mac.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

One more reviewer, please? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15231#issuecomment-1678606581

From duke at openjdk.org  Tue Aug 15 09:45:43 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Tue, 15 Aug 2023 09:45:43 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v2]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:

  8314236: change bug number and summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/e7f9fd84..10bddbb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From shade at openjdk.org  Tue Aug 15 10:15:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Aug 2023 10:15:11 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v2]
In-Reply-To: <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>
Message-ID: <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>

On Tue, 15 Aug 2023 09:45:43 GMT, Nikita Sakharin <duke at openjdk.org> wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List<Byte> list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314236: change bug number and summary

Superficially, this looks okay. Some OpenJDK code/test style trivia:

src/java.base/share/classes/java/util/Collections.java line 810:

> 808: 
> 809:     private static <T> void rotate1(final List<T> list, int distance) {
> 810:         final int size = list.size();

Let's keep the style, and do a focused fix: skip adding `final` here. (`final` mostly matters for fields).

src/java.base/share/classes/java/util/Collections.java line 813:

> 811:         if (size == 0)
> 812:             return;
> 813:         distance %= size;

Same, let's keep the original style.

test/jdk/java/util/Collections/RotateHuge.java line 27:

> 25:  * @test
> 26:  * @bug 8314236
> 27:  * @summary Overflow in Collections.rotate

Since this test takes >4G of heap to hold the list with compressed oops, and >8G of heap without compressed oops, we need to run it in a separate VM with enough headroom, something like this:


 * @test
 * @bug 8314236
 * @summary Overflow in Collections.rotate
 * @requires (sun.arch.data.model == "64" & os.maxMemory >= 16g)
 * @run main/othervm -Xmx12g RotateHuge

test/jdk/java/util/Collections/RotateHuge.java line 40:

> 38:         final List<Byte> list = new ArrayList<>(size);
> 39:         for (int i = 0; i < size; ++i)
> 40:             list.add((byte) 0);

We don't actually need to rely on auto-boxing here, right?

Suggestion:

        final Object o = new Object();
        final List<Object> list = new ArrayList<>(size);
        for (int i = 0; i < size; i++) {
            list.add(o);
        }

-------------

PR Review: https://git.openjdk.org/jdk/pull/15270#pullrequestreview-1578268533
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294404136
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294404599
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294399882
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294395844

From aturbanov at openjdk.org  Tue Aug 15 10:36:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Aug 2023 10:36:06 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
Message-ID: <ZC7P6OroWccvJR26Av0978M83ihk9jEAUFz0cv6-al0=.eb0d39d2-97dd-42f0-b232-60b796b91199@github.com>

On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified all tests under lib-test/jdk to use JUnit

test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java line 84:

> 82:                 Arguments.of("canonical", "%08x  ", "%02x ", 16, "|", 31, HexPrinter.Formatters.PRINTABLE, "|" + System.lineSeparator()),
> 83:                 Arguments.of("simple", "%04x: ", "%02x ", 16, " // ", 64, HexPrinter.Formatters.ASCII, System.lineSeparator()),
> 84:                 Arguments.of("source", "    ", "(byte)%3d, ", 8, " // ", 64, HexPrinter.Formatters.PRINTABLE,  System.lineSeparator())

Suggestion:

                Arguments.of("source", "    ", "(byte)%3d, ", 8, " // ", 64, HexPrinter.Formatters.PRINTABLE, System.lineSeparator())

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15131#discussion_r1294433943

From alanb at openjdk.org  Tue Aug 15 10:40:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 10:40:11 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
Message-ID: <PMQovAuWLJZ51lFNW8vX1mtQeofkgHm8b-eY_qHBz_I=.83e3cac1-bc10-441e-aa3f-e8164f5ae91c@github.com>

On Mon, 14 Aug 2023 21:21:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional zip to the DataProvider so it is exercised

src/java.base/share/classes/java/util/zip/ZipFile.java line 132:

> 130:             GetPropertyAction.privilegedGetProperty(
> 131:                     "jdk.util.zip.disableZip64ExtraFieldValidation", "false")
> 132:                     .equalsIgnoreCase("true");

This doesn't quite work for -Djdk.util.zip.disableZip64ExtraFieldValidation, this is closer to what you want here:

    private static final boolean DISABLE_ZIP64_EXTRA_VALIDATION;
    static {
        String value = GetPropertyAction.privilegedGetProperty(
                "jdk.util.zip.disableZip64ExtraFieldValidation");
        if (value == null) {
            DISABLE_ZIP64_EXTRA_VALIDATION = false;
        } else {
            DISABLE_ZIP64_EXTRA_VALIDATION = value.isEmpty() || value.equalsIgnoreCase("true");
        }
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294426292

From alanb at openjdk.org  Tue Aug 15 10:40:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 10:40:12 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <7JehWv6SeJmo_06epcO8t3hWRrRlfWUDRhubjOqERqA=.70420e94-fb5d-4b2b-943d-4f19922d9899@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>
 <LAdxqNAaxtraDHSs2V0bhK2ScO8XgvHBX1Bgp36bOms=.be319357-0d4d-45e5-8431-ba2a973739ed@github.com>
 <7JehWv6SeJmo_06epcO8t3hWRrRlfWUDRhubjOqERqA=.70420e94-fb5d-4b2b-943d-4f19922d9899@github.com>
Message-ID: <4elD_x3ZX81525PUarpyPMLcc6W9lZlTT0bKHiXBQlw=.7189caca-5f04-45f8-910e-82d35220c1b4@github.com>

On Mon, 14 Aug 2023 21:38:02 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Hi Volker,
>> 
>> I understand your point and I had done that  previously  but decided I  did not like the flow of the code that way which is why I moved the check.  I prefer to leave it as is.
>
> I don't think this is a question of "taste" because `isZip64ExtBlockSizeValid()` suggests that the method will check for *valid* sizes and to my understanding `0` is not a valid input. This method might also be called from other places in the future which do not handle the zero case appropriately.
> 
> In any case, I'm ready to accept this as a case of "Disagree and Commit"  :) but in that case please update at least the comment below to something like "*..Note we do not need to check blockSize is >= 8 as we know its length is at least 8 by now*" because "*..from the call to isZip64ExtBlockSizeValid()*" isn't true any more.

I think I agree with Volker that it would be better if isZip64ExtBlockSizeValid continued to return false for block size 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294436616

From duke at openjdk.org  Tue Aug 15 10:48:29 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 15 Aug 2023 10:48:29 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
 - Revert StreamTokenizer.java
 - Update DateTimeFormatterBuilder
 - Avoid locale-sensitive case conversions in java.base

-------------

Changes: https://git.openjdk.org/jdk/pull/14763/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=02
  Stats: 44 lines in 11 files changed: 6 ins; 0 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/14763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14763/head:pull/14763

PR: https://git.openjdk.org/jdk/pull/14763

From alanb at openjdk.org  Tue Aug 15 10:52:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 10:52:09 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
Message-ID: <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>

On Tue, 15 Aug 2023 00:07:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> try this example, zip -T passed, unzip works fine, but openjdk rejects it.

Are you arguing to drop all checking of the extra fields? It's not clear to me that this PR should be do that as it has a lot of implications.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1678744410

From duke at openjdk.org  Tue Aug 15 10:52:12 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 15 Aug 2023 10:52:12 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
Message-ID: <zczFY6mqas1UTn5bALJo_1UcszkBCFjVOIkTA03UV80=.6e7cd119-1354-4683-852e-1dcabd8fff39@github.com>

On Tue, 15 Aug 2023 10:48:29 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
>  - Revert StreamTokenizer.java
>  - Update DateTimeFormatterBuilder
>  - Avoid locale-sensitive case conversions in java.base

I updated this PR to resolve the merge conflict. Now it is waiting to be reviewed again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1678743922

From duke at openjdk.org  Tue Aug 15 11:25:46 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Tue, 15 Aug 2023 11:25:46 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v3]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <MMa1Z6RNaCSk3PGyvddtRyQIbeTZWsINy5lthi0jjlI=.e3283eff-7273-4ab4-8405-46414f62c966@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:

  8314236: fix style, add test requirements

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/10bddbb9..dda1c3b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=01-02

  Stats: 11 lines in 2 files changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From duke at openjdk.org  Tue Aug 15 14:23:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 15 Aug 2023 14:23:14 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
Message-ID: <dGCJ_heaOQaSdOOFr_RuaU4avoCYqsB5KEGcixEtgtM=.9b2d5719-0744-4a8e-851a-31f0ce60ea0c@github.com>

On Mon, 14 Aug 2023 11:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea 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 45 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Update @since tags
>  - resync
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ExecutorService tests
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Rework versioning
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/c52f3bd1...585769c9

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 442:

> 440:      * queues are at odd indices. Worker phase ids masked with SMASK
> 441:      * match their index. Shared (submission) queues are at even
> 442:      * indices. Grouping them together in this way simplifies and

@DougLea Interesting?so by having the worker queues at odd indices increases the likelihood of the then adjacent submission queues already having been prefetched?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1294661447

From duke at openjdk.org  Tue Aug 15 14:37:37 2023
From: duke at openjdk.org (Qing Xiao)
Date: Tue, 15 Aug 2023 14:37:37 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests [v2]
In-Reply-To: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
Message-ID: <BGHpmGjwjscvO-2T2wxuGUDbyy-JuVM4YpChqXZ_urs=.9702d73d-f35f-4e07-920f-ff09bf1b5b44@github.com>

> Modified all tests under lib-test/jdk to use JUnit

Qing Xiao has updated the pull request incrementally with three additional commits since the last revision:

 - Delete extra space
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Update years in comments in test/lib-test/jdk/test/lib/hexdump
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Update years in comments in test/lib-test/jdk/test/lib/hexdump
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15131/files
  - new: https://git.openjdk.org/jdk/pull/15131/files/1ab34e8d..0e15e752

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15131&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15131/head:pull/15131

PR: https://git.openjdk.org/jdk/pull/15131

From liach at openjdk.org  Tue Aug 15 14:37:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Aug 2023 14:37:59 GMT
Subject: RFR: 8313612: Use JUnit in lib-test/jdk tests
In-Reply-To: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
References: <RBRvQpmaOFDiN2dDH65wR7w_ruRbSJbKDpLMRgzAz6M=.321c39ed-6890-4963-95d9-e13b3a8ee30a@github.com>
Message-ID: <2_VTt8u5x-AnZheEBHCM-VMbwHKzWlpV1JbH4T7VZxA=.4e6e3ccb-c5d9-4289-ac3d-238c0e071e5c@github.com>

On Wed, 2 Aug 2023 23:25:13 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Modified all tests under lib-test/jdk to use JUnit

Should all static `@Test` methods be converted to instance methods, as recommended by JUnit? See https://junit.org/junit5/docs/snapshot/user-guide/#writing-tests-definitions

> Test Method
any **instance** method that is directly annotated or meta-annotated with `@Test`, ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15131#issuecomment-1679037063

From bpb at openjdk.org  Tue Aug 15 15:31:11 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 15 Aug 2023 15:31:11 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
 <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
Message-ID: <aaOhnvK1TTZtdLw-b-zD_-TyxZ2uKcZtFUV5N8tm8Z4=.0a5ed6d7-7df4-47cd-946b-321b8803fbc7@github.com>

On Fri, 11 Aug 2023 15:32:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
>> 
>> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
>> 
>> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
>> 
>> 
>> Benchmark                Mode  Cnt    Score   Error  Units
>> 
>> # Before JDK-8312127
>> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
>> 
>> # After JDK-8312127
>> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
>> 
>> 
>> The new regression test completes in <0.5s on my Mac.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15231#pullrequestreview-1578847268

From lancea at openjdk.org  Tue Aug 15 15:34:12 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 15:34:12 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
Message-ID: <_gKOgI8Mn4z85-3yh_SqxR5_quJBSzX4rVQhQb-qXqU=.1ee1a197-b14d-41a6-907e-52decad16580@github.com>

On Tue, 15 Aug 2023 00:07:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> [TEST.zip](https://github.com/openjdk/jdk/files/12340301/TEST.zip)
> 
> try this example, zip -T passed, unzip works fine, but openjdk rejects it.

Yes, the Zip64 header in the CEN has a field size of 2 and as we are validating the Zip64 header size, you get the ZipException:

`Invalid CEN header (invalid zip64 extra data field  size)
`
> ----------------#1--------------------
> [Central Directory Header]
>      0x369: Signature        : 0x02014b50
>      0x36d: Created Zip Spec :       0x2d [4.5]
>      0x36e: Created OS       :        0x3 [UNIX]
>      0x36f: VerMadeby        :      0x32d [3, 4.5]
>      0x370: VerExtract       :       0x2d [4.5]
>      0x371: Flag             :      0x800
>      0x373: Method           :        0x8 [DEFLATED]
>      0x375: Last Mod Time    : 0x5703021b [Thu Aug 03 00:16:54 EDT 2023]
>      0x379: CRC              : 0x279590b5
>      0x37d: Compressed Size  :        0xa
>      0x381: Uncompressed Size:        0xb
>      0x385: Name Length      :        0x5
>      0x387: Extra Length     :        0x6
> 			Extra data:[01, 00, 02, 00, 00, 00]
> 		[tag=0x0001, sz=2]
> 			->ZIP64: 
> 			[data= 00 00 ]
>      0x389: Comment Length   :        0x0
>      0x38b: Disk Start       :        0x0
>      0x38d: Attrs            :        0x0
>      0x38f: AttrsEx          : 0x81a40000
>      0x393: Loc Header Offset:        0x0
>      0x397: File Name        : b.txt
> 
> [Local File Header]
>        0x0: Signature   :   0x04034b50
>        0x4: Version     :         0x2d    [4.5]
>        0x6: Flag        :        0x800
>        0x8: Method      :          0x8    [DEFLATED]
>        0xa: LastMTime   :   0x5703021b    [Thu Aug 03 00:16:54 EDT 2023]
>        0xe: CRC         :   0x279590b5
>       0x12: CSize       :          0xa
>       0x16: Size        :          0xb
>       0x1a: Name Length :          0x5    [b.txt]
>       0x1c: ExtraLength :         0x14
> 			Extra data:[01, 00, 10, 00, 0b, 00, 00, 00, 00, 00, 00, 00, 0a, 00, 00, 00, 00, 00, 00, 00]
> 		[tag=0x0001, sz=16]
> 			->ZIP64: *0xb *0xa 
> 			[data= 0b 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 ]
>       0x1e: File Name  : [b.txt]

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679134441

From lancea at openjdk.org  Tue Aug 15 15:44:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 15:44:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v7]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <sVN67kLLkmw_-bfgB2mCCvmjWHc61EoEgMg25ZVNOH0=.a414d8f6-95d0-428c-9218-4ff70c7dee91@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Reorder the Zip64 blocksize==0 check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/8b0d2363..912903f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=05-06

  Stats: 25 lines in 2 files changed: 9 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From lancea at openjdk.org  Tue Aug 15 15:44:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 15:44:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <4elD_x3ZX81525PUarpyPMLcc6W9lZlTT0bKHiXBQlw=.7189caca-5f04-45f8-910e-82d35220c1b4@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>
 <LAdxqNAaxtraDHSs2V0bhK2ScO8XgvHBX1Bgp36bOms=.be319357-0d4d-45e5-8431-ba2a973739ed@github.com>
 <7JehWv6SeJmo_06epcO8t3hWRrRlfWUDRhubjOqERqA=.70420e94-fb5d-4b2b-943d-4f19922d9899@github.com>
 <4elD_x3ZX81525PUarpyPMLcc6W9lZlTT0bKHiXBQlw=.7189caca-5f04-45f8-910e-82d35220c1b4@github.com>
Message-ID: <Oeu-4uabxvLr7cQlsRjxJQG7vKChc4mKz8dq0NNErlk=.5560a629-4734-415c-802f-27ff518ed10b@github.com>

On Tue, 15 Aug 2023 10:36:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think this is a question of "taste" because `isZip64ExtBlockSizeValid()` suggests that the method will check for *valid* sizes and to my understanding `0` is not a valid input. This method might also be called from other places in the future which do not handle the zero case appropriately.
>> 
>> In any case, I'm ready to accept this as a case of "Disagree and Commit"  :) but in that case please update at least the comment below to something like "*..Note we do not need to check blockSize is >= 8 as we know its length is at least 8 by now*" because "*..from the call to isZip64ExtBlockSizeValid()*" isn't true any more.
>
> I think I agree with Volker that it would be better if isZip64ExtBlockSizeValid continued to return false for block size 0.

OK, I have made the suggest change that you both prefer.

Thank you for your input

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294792855

From serb at openjdk.org  Tue Aug 15 16:04:09 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Aug 2023 16:04:09 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
 <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>
Message-ID: <H7j-6T9Js9u8c2ehXTFu_ZXtbXd5UHyBHkXhmMU_0Vo=.b101c354-2e74-48ce-bc9d-0417e53f11ca@github.com>

On Tue, 15 Aug 2023 10:49:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are you arguing to drop all checking of the extra fields? It's not clear to me that this PR should be do that as it has a lot of implications.

Not all, but do it in a different way. The only thing which is MUST be implemented according to specifications is: if the data in the body of the zip file for size/csize/locoff is negative then the correct value for these fields should be stored in the extended block. So for example if the size is negative in the body of the zip file, then the extended block should be at least 8 bytes. If the locoff is negative then the extended block should be at least 24 bytes(two fillers at the beginning).

Other than that there are no limitation on the size of extended block, it could be 0, 20, 100 , etc. But it should contain correct data if necessary and should not be larger than the surrounding "chunk".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679198173

From shade at openjdk.org  Tue Aug 15 16:14:25 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Aug 2023 16:14:25 GMT
Subject: RFR: 8314120: Add tests for FileDescriptor.sync [v2]
In-Reply-To: <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
 <5XPJW0Ya-HJEq1kAHbYwW3LAnpDAQzUgopmhwVDqD8M=.879695df-39f9-486b-a9e6-92522be5ddc7@github.com>
Message-ID: <6PjkPTIiB6ok-8CMfENjd4yy-KWGF7qCzbag-dzSJCY=.c724362a-a237-4214-9ec1-ba227a105888@github.com>

On Fri, 11 Aug 2023 15:32:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
>> 
>> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
>> 
>> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
>> 
>> 
>> Benchmark                Mode  Cnt    Score   Error  Units
>> 
>> # Before JDK-8312127
>> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
>> 
>> # After JDK-8312127
>> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
>> 
>> 
>> The new regression test completes in <0.5s on my Mac.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15231#issuecomment-1679218022

From shade at openjdk.org  Tue Aug 15 16:14:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Aug 2023 16:14:28 GMT
Subject: Integrated: 8314120: Add tests for FileDescriptor.sync
In-Reply-To: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
References: <nJXBjaIH206l6SjhDru3YV0qKMzBC83Fg2oYi6SD4Zo=.881c9e4f-5ae3-4423-9b8f-7d6f7200e9ed@github.com>
Message-ID: <-6q5zaXRxpJWxBBCe1KzVP2K4Ku8XPzJ02VFOIS2Ok8=.ad4705a5-9f94-4843-b304-deab3d72d6e9@github.com>

On Thu, 10 Aug 2023 15:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When backporting [JDK-8312127](https://bugs.openjdk.org/browse/JDK-8312127), I realized there are no targeted tests for `FileDescriptor.sync` that can be used to qualify the changes in that area. 
> 
> Additionally, we use `FD.sync` for durability in Java databases, and we want to make sure at least some smoke tests are available in OpenJDK. Asserting durability would be hard, but let's at least test the Java code does not throw unexpected exceptions and native code does not crash the VM.
> 
> The benchmark will show, among other things, that the recent change to `FileDescriptor.sync` does not affect the performance much, compared to the cost of the `fsync` itself. It deliberately targets tmpfs to provide the lowest actual FS overhead.
> 
> 
> Benchmark                Mode  Cnt    Score   Error  Units
> 
> # Before JDK-8312127
> FileDescriptorSync.sync  avgt   15  351,688 ? 2,477  ns/op
> 
> # After JDK-8312127
> FileDescriptorSync.sync  avgt   15  353,331 ? 2,116  ns/op
> 
> 
> The new regression test completes in <0.5s on my Mac.

This pull request has now been integrated.

Changeset: 2e8a0ab2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e8a0ab27227b2e06e2ece3776f66ff0932ef353
Stats:     165 lines in 2 files changed: 165 ins; 0 del; 0 mod

8314120: Add tests for FileDescriptor.sync

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/15231

From naoto at openjdk.org  Tue Aug 15 16:26:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Aug 2023 16:26:12 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in
 j.text.DigitList [v2]
In-Reply-To: <_owPkhWCPS4l3-wXSSbtY3WOFbEKqAJ5_cMH2UBW1zk=.e6eb9895-aedc-4218-8e11-2a9099b83aa1@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
 <jPVnRQANAEVYiyo-ILGgFKAsIv9JNpNcCRT_W5etMmo=.fc249269-1ee2-482e-ab89-e525beace3f2@github.com>
 <_owPkhWCPS4l3-wXSSbtY3WOFbEKqAJ5_cMH2UBW1zk=.e6eb9895-aedc-4218-8e11-2a9099b83aa1@github.com>
Message-ID: <xVZqtmZdpjoTOqOlltotZVLEdHkImMV_Kg1u5xvEiXs=.9974637c-e8b5-4d90-b34e-4a55b4c1dd36@github.com>

On Mon, 14 Aug 2023 17:43:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DigitList.java line 521:
>> 
>>> 519:                 if (non0AfterIndex(maximumDigits)) {
>>> 520:                     return (isNegative && roundingMode == RoundingMode.FLOOR)
>>> 521:                             || (!isNegative && roundingMode == RoundingMode.CEILING);
>> 
>> `roundingMode` is checked against `FLOOR`/`CEILING` twice. I don't see the need of bundling them up.
>
> Thank you for the review. Addressed this, and your other comments that I did not explicitly respond to.

I'd think this separate one-liner for each case would be simpler and more readable:

    case CEILING:
        return nonZeroAfterIndex(maximumDigits) && !isNegative;
    case FLOOR:
        return nonZeroAfterIndex(maximumDigits) && isNegative;

>> src/java.base/share/classes/java/text/DigitList.java line 543:
>> 
>>> 541:                                                 && (maximumDigits > 0) && (digits[maximumDigits - 1] % 2 != 0));
>>> 542:                                 // Not already rounded, and not exact, round up
>>> 543:                             } else {
>> 
>> Are you sure this logic is equivalent to the previous one? Previously, `HALF_UP/DOWN` checks `valueExactAsDecimal` before `alreadyRounded`, but the new one checks `alreadyRounded` first.
>
> Yes, since `alreadyRounded` and `valueExactAsDecimal` are never both `true` and when either of them are `true`, it warrants a return without considering other logic. 
> 
> However, I have adjusted the code so that this is more apparent (and appears more similar to the original `HALF_DOWN/UP`, which was written more concisely).

OK, thanks for confirming

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1294841815
PR Review Comment: https://git.openjdk.org/jdk/pull/15252#discussion_r1294841883

From jlu at openjdk.org  Tue Aug 15 16:38:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 15 Aug 2023 16:38:42 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in
 j.text.DigitList [v3]
In-Reply-To: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
Message-ID: <fLj3KQBGU0Q5zgNn17OKkKeCLwMPU9MSG73TmE7PVyQ=.c7537063-cf57-4d07-838d-6f62fcd7e628@github.com>

> Please review this PR which is a broad clean up of the DigitList class (used by Format classes in j.text).
> 
> This PR is intended to be a portion of a bigger change (split up to make reviewing easier). 
> 
> The main change simplifying related Rounding Mode logic in `shouldRoundUp()` - (_CEILING/FLOOR_, _HALF_UP/DOWN/EVEN_)
> 
> Other changes include
> - Certain for loops can be replaced with cleaner syntax (E.g. for(;;), empty for loops)
> - Introduce `roundInt(int)` - For use by Integer representations of DigitList
> - Introduce `nonZeroAfterIndex(int)` - To reduce code duplication

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Reflect review comment: uncombine CEILING/FLOOR (8/15/23)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15252/files
  - new: https://git.openjdk.org/jdk/pull/15252/files/c9782b77..dc9dcf33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15252&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15252&range=01-02

  Stats: 9 lines in 1 file changed: 1 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15252/head:pull/15252

PR: https://git.openjdk.org/jdk/pull/15252

From lancea at openjdk.org  Tue Aug 15 16:41:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 16:41:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <PMQovAuWLJZ51lFNW8vX1mtQeofkgHm8b-eY_qHBz_I=.83e3cac1-bc10-441e-aa3f-e8164f5ae91c@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <PMQovAuWLJZ51lFNW8vX1mtQeofkgHm8b-eY_qHBz_I=.83e3cac1-bc10-441e-aa3f-e8164f5ae91c@github.com>
Message-ID: <5WywljavUC_xHowcaMhybdbF7JTJK7L0DN5KRKPA5LM=.a3630045-2467-4989-8965-dbc2a056a50e@github.com>

On Tue, 15 Aug 2023 10:21:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add additional zip to the DataProvider so it is exercised
>
> src/java.base/share/classes/java/util/zip/ZipFile.java line 132:
> 
>> 130:             GetPropertyAction.privilegedGetProperty(
>> 131:                     "jdk.util.zip.disableZip64ExtraFieldValidation", "false")
>> 132:                     .equalsIgnoreCase("true");
> 
> This doesn't quite work for -Djdk.util.zip.disableZip64ExtraFieldValidation, this is closer to what you want here:
> 
>     private static final boolean DISABLE_ZIP64_EXTRA_VALIDATION;
>     static {
>         String value = GetPropertyAction.privilegedGetProperty(
>                 "jdk.util.zip.disableZip64ExtraFieldValidation");
>         if (value == null) {
>             DISABLE_ZIP64_EXTRA_VALIDATION = false;
>         } else {
>             DISABLE_ZIP64_EXTRA_VALIDATION = value.isEmpty() || value.equalsIgnoreCase("true");
>         }
>     }

Reworked similar to above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294857154

From lancea at openjdk.org  Tue Aug 15 16:41:35 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 16:41:35 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v8]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <GjhSUSDSoKMzrP8rj4UmsRmYr2R5hCdlctsnSZWcCC0=.fcbfdb05-eef3-49e7-864b-69404f43e72f@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Revise retrieval of jdk.util.zip.disableZip64ExtraFieldValidation and tweak a comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/912903f0..68a1bd3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=06-07

  Stats: 20 lines in 2 files changed: 16 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From naoto at openjdk.org  Tue Aug 15 17:24:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Aug 2023 17:24:08 GMT
Subject: RFR: 8314169: Combine related RoundingMode logic in
 j.text.DigitList [v3]
In-Reply-To: <fLj3KQBGU0Q5zgNn17OKkKeCLwMPU9MSG73TmE7PVyQ=.c7537063-cf57-4d07-838d-6f62fcd7e628@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
 <fLj3KQBGU0Q5zgNn17OKkKeCLwMPU9MSG73TmE7PVyQ=.c7537063-cf57-4d07-838d-6f62fcd7e628@github.com>
Message-ID: <pE2eOB3-OzCPC4YFcVr7XACQy7qpiyj8u3SskuB4vYU=.1d0a43d0-9652-4807-826c-2b5d15e12049@github.com>

On Tue, 15 Aug 2023 16:38:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which is a broad clean up of the DigitList class (used by Format classes in j.text).
>> 
>> This PR is intended to be a portion of a bigger change (split up to make reviewing easier). 
>> 
>> The main change simplifying related Rounding Mode logic in `shouldRoundUp()` - (_CEILING/FLOOR_, _HALF_UP/DOWN/EVEN_)
>> 
>> Other changes include
>> - Certain for loops can be replaced with cleaner syntax (E.g. for(;;), empty for loops)
>> - Introduce `roundInt(int)` - For use by Integer representations of DigitList
>> - Introduce `nonZeroAfterIndex(int)` - To reduce code duplication
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comment: uncombine CEILING/FLOOR (8/15/23)

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15252#pullrequestreview-1579050154

From duke at openjdk.org  Tue Aug 15 17:25:21 2023
From: duke at openjdk.org (duke)
Date: Tue, 15 Aug 2023 17:25:21 GMT
Subject: Withdrawn: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <Fsz_fOJw7_NvsHHb5u3NYz9a3yx1FOlLWbvhnC2_pJk=.3307ea56-6351-48e0-bc7b-8acf1403b210@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14216

From duke at openjdk.org  Tue Aug 15 17:37:29 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 15 Aug 2023 17:37:29 GMT
Subject: RFR: 8314063 : The socket is not closed in Connection::createSocket
 when =?UTF-8?B?dOKApg==?=
Message-ID: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>

Please refer to JDK-8314063.

The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.

The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

-------------

Commit messages:
 - remove the unused import
 - 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection

Changes: https://git.openjdk.org/jdk/pull/15294/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314063
  Stats: 286 lines in 3 files changed: 229 ins; 15 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From simonis at openjdk.org  Tue Aug 15 17:52:10 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Aug 2023 17:52:10 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v8]
In-Reply-To: <GjhSUSDSoKMzrP8rj4UmsRmYr2R5hCdlctsnSZWcCC0=.fcbfdb05-eef3-49e7-864b-69404f43e72f@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <GjhSUSDSoKMzrP8rj4UmsRmYr2R5hCdlctsnSZWcCC0=.fcbfdb05-eef3-49e7-864b-69404f43e72f@github.com>
Message-ID: <I4VKgZQ7caNK4cdhOjr1POeP2eT-ARuZkfxFUUInMfY=.d734c07f-99f8-407e-b6b7-0fceef33086e@github.com>

On Tue, 15 Aug 2023 16:41:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise retrieval of jdk.util.zip.disableZip64ExtraFieldValidation and tweak a comment

Thanks for doing the additional changes. This looks good to me now.

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15273#pullrequestreview-1579091533

From simonis at openjdk.org  Tue Aug 15 17:59:10 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Aug 2023 17:59:10 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <H7j-6T9Js9u8c2ehXTFu_ZXtbXd5UHyBHkXhmMU_0Vo=.b101c354-2e74-48ce-bc9d-0417e53f11ca@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
 <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>
 <H7j-6T9Js9u8c2ehXTFu_ZXtbXd5UHyBHkXhmMU_0Vo=.b101c354-2e74-48ce-bc9d-0417e53f11ca@github.com>
Message-ID: <a2SDpVWXfEySGrUu8U9E2w30RcrDeKOj0PL__ZUbsSw=.68f9c4d2-d0a5-4b72-b0c6-ea13aaf89534@github.com>

On Tue, 15 Aug 2023 16:01:37 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Other than that there are no limitation on the size of extended block, it could be 0, 20, 100 , etc. But it should contain correct data if necessary and should not be larger than the surrounding "chunk".

This seems to be a very "free" interpretation of the specification to me. According to my understanding, the valid sizes of 8, 16, 24 or 28 as described in the Wikipedia article are a direct consequence of the specification which only allows for a fixed set of entries in the ZIP64 Extra Field. Already the zero-length case is questionable because a ZIP64 Extra Field should only be created if required, however we have to handle it here for backward compatibility reasons.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679363319

From alanb at openjdk.org  Tue Aug 15 18:16:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 18:16:11 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <5WywljavUC_xHowcaMhybdbF7JTJK7L0DN5KRKPA5LM=.a3630045-2467-4989-8965-dbc2a056a50e@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <PMQovAuWLJZ51lFNW8vX1mtQeofkgHm8b-eY_qHBz_I=.83e3cac1-bc10-441e-aa3f-e8164f5ae91c@github.com>
 <5WywljavUC_xHowcaMhybdbF7JTJK7L0DN5KRKPA5LM=.a3630045-2467-4989-8965-dbc2a056a50e@github.com>
Message-ID: <aDUhVuR-fEh2qwO-mikQ3v2Dcc3fFQD8UIKbRwNhMcM=.47b2c170-a17a-4437-b63b-84ba3a6235ee@github.com>

On Tue, 15 Aug 2023 16:36:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Reworked similar to above.

Thanks. Related is that there aren't tests in this PR that run with -Djdk.util.zip.disableZip64ExtraFieldValidation and -D"jdk.util.zip.disableZip64ExtraFieldValidation=true to check that zip implementations won't reject the zip/JAR files with wonky extra fields. Is this something for another PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294949030

From lancea at openjdk.org  Tue Aug 15 18:25:08 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 18:25:08 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <aDUhVuR-fEh2qwO-mikQ3v2Dcc3fFQD8UIKbRwNhMcM=.47b2c170-a17a-4437-b63b-84ba3a6235ee@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <PMQovAuWLJZ51lFNW8vX1mtQeofkgHm8b-eY_qHBz_I=.83e3cac1-bc10-441e-aa3f-e8164f5ae91c@github.com>
 <5WywljavUC_xHowcaMhybdbF7JTJK7L0DN5KRKPA5LM=.a3630045-2467-4989-8965-dbc2a056a50e@github.com>
 <aDUhVuR-fEh2qwO-mikQ3v2Dcc3fFQD8UIKbRwNhMcM=.47b2c170-a17a-4437-b63b-84ba3a6235ee@github.com>
Message-ID: <jIjXOTpP676bchQgBj0BSPPo3bFC2Ka8ynflcupcWQk=.acd81426-bda8-482f-bd4d-43802ddb22e0@github.com>

On Tue, 15 Aug 2023 18:13:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Reworked similar to above.
>
>> Reworked similar to above.
> 
> Thanks. Related is that there aren't tests in this PR that run with -Djdk.util.zip.disableZip64ExtraFieldValidation and -D"jdk.util.zip.disableZip64ExtraFieldValidation=true to check that zip implementations won't reject the zip/JAR files with wonky extra fields. Is this something for another PR?

I can look to add the additional proposed test separately under an additional PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294955538

From alanb at openjdk.org  Tue Aug 15 18:25:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Aug 2023 18:25:11 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v8]
In-Reply-To: <GjhSUSDSoKMzrP8rj4UmsRmYr2R5hCdlctsnSZWcCC0=.fcbfdb05-eef3-49e7-864b-69404f43e72f@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <GjhSUSDSoKMzrP8rj4UmsRmYr2R5hCdlctsnSZWcCC0=.fcbfdb05-eef3-49e7-864b-69404f43e72f@github.com>
Message-ID: <K8UzV68Y_FXObbUwcNzgWJFtJNeMctMRc8pTSz_hzRo=.f88ccf5b-f04d-4816-a2a8-01ef24816d8f@github.com>

On Tue, 15 Aug 2023 16:41:35 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise retrieval of jdk.util.zip.disableZip64ExtraFieldValidation and tweak a comment

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3100:

> 3098:                     if (sz == 0) {
> 3099:                         if ( csize == ZIP64_MINVAL || size == ZIP64_MINVAL ||
> 3100:                                 locoff == ZIP64_MINVAL) {

Minor nit but you can drop the space in "( csize)" and put the third condition on L3099 to make it easier to read.

For the comment, it looks like it is missing a comma after "== 0". Either that or change it to start with "Some older version of Apache Ant and Apache Commons ...".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294956354

From igraves at openjdk.org  Tue Aug 15 18:39:12 2023
From: igraves at openjdk.org (Ian Graves)
Date: Tue, 15 Aug 2023 18:39:12 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v4]
In-Reply-To: <UV0coAExeBZRp8i4ZbEor3boTp-JtIioJZr_ysr_DNc=.6350d38d-566c-430d-9e9f-f8a9f920e519@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <-4FNO-SDSVY6y13UHp8ws0rMPmfU7I4U_lGwUSZ_Qs0=.bef74326-cd0a-4f2c-a41a-6fa84b1dc0fb@github.com>
 <UV0coAExeBZRp8i4ZbEor3boTp-JtIioJZr_ysr_DNc=.6350d38d-566c-430d-9e9f-f8a9f920e519@github.com>
Message-ID: <G1kUqPHP0iHBtZB_4KS1N0BIgGhm5-YBWRTmKqiTKEI=.83218ea0-cbd2-47e8-95d8-b39f923a0c54@github.com>

On Thu, 3 Aug 2023 12:34:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Cristian Vat has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes and test for CIBackRef
>
> The change looks good.
> However, I'm not a Reviewer.

This looks good to me, too. Like @rgiulietti I'm also not a reviewer.

Tagging in @stuart-marks and @RogerRiggs for reviewer status.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1679414674

From lancea at openjdk.org  Tue Aug 15 18:43:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 18:43:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Cleaned up spacing and added missing comma

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15273/files
  - new: https://git.openjdk.org/jdk/pull/15273/files/68a1bd3e..27bb0ecc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15273&range=07-08

  Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15273/head:pull/15273

PR: https://git.openjdk.org/jdk/pull/15273

From lancea at openjdk.org  Tue Aug 15 18:43:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 15 Aug 2023 18:43:36 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v8]
In-Reply-To: <K8UzV68Y_FXObbUwcNzgWJFtJNeMctMRc8pTSz_hzRo=.f88ccf5b-f04d-4816-a2a8-01ef24816d8f@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <GjhSUSDSoKMzrP8rj4UmsRmYr2R5hCdlctsnSZWcCC0=.fcbfdb05-eef3-49e7-864b-69404f43e72f@github.com>
 <K8UzV68Y_FXObbUwcNzgWJFtJNeMctMRc8pTSz_hzRo=.f88ccf5b-f04d-4816-a2a8-01ef24816d8f@github.com>
Message-ID: <42ZIQVaL-m0xEA8L31-HuI-7Etvpk8fFhm7XQZq4HH0=.fd47cc79-e8e3-4afa-a709-a5ae92c3671c@github.com>

On Tue, 15 Aug 2023 18:22:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise retrieval of jdk.util.zip.disableZip64ExtraFieldValidation and tweak a comment
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3100:
> 
>> 3098:                     if (sz == 0) {
>> 3099:                         if ( csize == ZIP64_MINVAL || size == ZIP64_MINVAL ||
>> 3100:                                 locoff == ZIP64_MINVAL) {
> 
> Minor nit but you can drop the space in "( csize)" and put the third condition on L3099 to make it easier to read.
> 
> For the comment, it looks like it is missing a comma after "== 0". Either that or change it to start with "Some older version of Apache Ant and Apache Commons ...".

Addressed in the latest update.  Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1294975044

From duke at openjdk.org  Tue Aug 15 19:13:31 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 19:13:31 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v4]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <OfYpkuBBINWUrmv3fLFSfu__YEytTlT88aMh7alsuIs=.b848e6e8-7b48-426c-bb15-b596dcfc32a6@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request incrementally with two additional commits since the last revision:

 - Add another required transitive desktop
   
   Assert number of module description generated sub modules
   
   Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>
 - Add copyright header and apply some formatting
   Revert unnecesary CompilerUtil

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/996c187c..1a2e463e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=02-03

  Stats: 189 lines in 9 files changed: 171 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From shade at openjdk.org  Tue Aug 15 19:14:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Aug 2023 19:14:12 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v2]
In-Reply-To: <2-FWP032phjwmiT6vOUN5ds83XjWEjfXOjVedDdgk4g=.656b80f4-c8e7-4935-904f-1b07bb8a3ddc@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <PsTu5E6ACWA3qBtfWidauo_1uCFAQ7S7xZPjeVMxTwU=.0e76e9ae-2ea7-4b5d-820d-a6b5d1eb46f1@github.com>
 <EQXyOHqtSlA0c7UIhuAuwy5yHWYbOHLmPPVgDp7a9Ns=.50771041-f734-4674-9b55-6df4ea582f9b@github.com>
 <2-FWP032phjwmiT6vOUN5ds83XjWEjfXOjVedDdgk4g=.656b80f4-c8e7-4935-904f-1b07bb8a3ddc@github.com>
Message-ID: <LCAI-EUNx-DmJfC8wfdgfVraEt6lJWMvjQR2plAEFFk=.c9b9dec6-dd54-4ab3-bb18-8a8481cba34d@github.com>

On Thu, 10 Aug 2023 11:54:05 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Shouldn't the similar change be in `CIBackRef.match` too? The fact current tests do not catch it makes me uneasy: the test coverage seems to be rather low there. 
>> 
>> We need a regex expert to look at it. @rgiulietti @igraves might help us out here?
>
> @shipilev anything I should do to continue here?

@deathy, please merge from master to get the clean testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1679457602

From duke at openjdk.org  Tue Aug 15 19:14:12 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 19:14:12 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v3]
In-Reply-To: <AvyLRgpr8hcSQScz1asIb8DX5xXUi6jeOu19TkV004U=.d8a2bebc-9156-4c79-b2ed-b92805bfb666@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <GqXA1aWxkl9mFUjuV4AlvyqLZlkkTDLkN86DbTM7MZ4=.ad4868df-9b09-4151-81dc-8302a17b2229@github.com>
 <AvyLRgpr8hcSQScz1asIb8DX5xXUi6jeOu19TkV004U=.d8a2bebc-9156-4c79-b2ed-b92805bfb666@github.com>
Message-ID: <iJxcmB4fGq1aXUDyejRCx10I0pFa2HWd7Oxzj7vxVjc=.e3d011c8-747e-4bfe-90d4-feba63ff1f84@github.com>

On Mon, 14 Aug 2023 22:07:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Since the batch size is 1, I would suggest that `p4.Main` can also load `jdk.internal.module.SystemModules$all` and verify the expected numbers of `subX` methods (one per each module). To find all modules in the image, you can simply do `ModuleFinder.ofSystem().findAll()`.

Thanks for the suggestion. We added now a check in the main class for the number of generated sub methods. We put a fixed number, as we did not get the relation between the number of "require modules" statements and the total number of modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15234#issuecomment-1679458565

From duke at openjdk.org  Tue Aug 15 19:26:38 2023
From: duke at openjdk.org (Cristian Vat)
Date: Tue, 15 Aug 2023 19:26:38 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v6]
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <ULrsOrSnucxfAz1B_gDzoLn4qZHZSGimp1FTDPbq_GU=.a02e43e8-2dc2-46bd-8302-c169de3ac2f7@github.com>

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat 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 since the last revision:

 - Merge branch 'openjdk:master' into JDK-8311939
 - review condition
 - changes and test for CIBackRef
 - remove new line
 - reduce allocations also for Matcher.usePattern
 - 8311939: Excessive allocation of Matcher.groups array

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/37b18e0c..0538e25e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=04-05

  Stats: 64874 lines in 1702 files changed: 33516 ins; 19812 del; 11546 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From mchung at openjdk.org  Tue Aug 15 19:40:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Aug 2023 19:40:13 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v4]
In-Reply-To: <OfYpkuBBINWUrmv3fLFSfu__YEytTlT88aMh7alsuIs=.b848e6e8-7b48-426c-bb15-b596dcfc32a6@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <OfYpkuBBINWUrmv3fLFSfu__YEytTlT88aMh7alsuIs=.b848e6e8-7b48-426c-bb15-b596dcfc32a6@github.com>
Message-ID: <0NzbGq8_rVrGUZtj9N-7t2dBwYxg8qW-isl-Os3uVvw=.02c0cb02-066e-4684-ba8f-e2fe5a118b18@github.com>

On Tue, 15 Aug 2023 19:13:31 GMT, Christoph <duke at openjdk.org> wrote:

>> Add new test case with sample modules that contains some requires/exports/uses/provides.
>> 
>> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
>> 
>> Follow up task from https://github.com/openjdk/jdk/pull/14408
>
> Christoph has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add another required transitive desktop
>    
>    Assert number of module description generated sub modules
>    
>    Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>
>  - Add copyright header and apply some formatting
>    Revert unnecesary CompilerUtil

Looks good.   Since the image is created with batchSize = 1, it means that one `subX` method is created for each module linked in the image.  So the test can count the number of modules in the image and the number of `subX` methods should match the module count.  I include the suggested code to check that.

test/jdk/tools/jlink/JLinkDedupTestBatchSizeOne.java line 38:

> 36: /*
> 37:  * @test
> 38:  * @summary Make sure that modules can be linked using jlink and deduplication works correctly when creating sub methods

please wrap this long line.

test/jdk/tools/jlink/JLinkDedupTestBatchSizeOne.java line 94:

> 92:                 .addMods("m1")
> 93:                 .addMods("m2")
> 94:                 .addMods("m2")

`m2` is added twice.  The duplicated line should be removed.

test/jdk/tools/jlink/JLinkDedupTestBatchSizeOne.java line 116:

> 114: 
> 115:         extractJImage(image);
> 116:         decompileWitJavap(image);

No needed.   These 2 lines along with the methods can be deleted.

test/jdk/tools/jlink/dedup/src/m1/p1/AInterface.java line 1:

> 1: package p1;

missing copyright header.

test/jdk/tools/jlink/dedup/src/m4/p4/Main.java line 43:

> 41:         }
> 42:         var moduleClass = Class.forName("jdk.internal.module.SystemModules$all");
> 43:         long subMethodCount = Arrays.stream(moduleClass.getDeclaredMethods()).filter(method -> method.getName().startsWith("sub")).count();

nit: wrap long line

Suggestion:

        long subMethodCount = Arrays.stream(moduleClass.getDeclaredMethods())
                                    .filter(method -> method.getName().startsWith("sub"))
                                    .count();

test/jdk/tools/jlink/dedup/src/m4/p4/Main.java line 47:

> 45:         if (subMethodCount != MODULE_SUB_METHOD_COUNT) {
> 46:             throw new AssertionError("Difference in generated sub module methods count! Expected: " + MODULE_SUB_METHOD_COUNT + " but was " + subMethodCount);
> 47:         }

Suggestion:

        // one subX method per each module is generated as the image is linked with
        // --system-modules=batchSize=1
        var moduleCount = ModuleFinder.ofSystem().findAll().stream().count();
        if (subMethodCount != moduleCount) {
            throw new AssertionError("Difference in generated sub module methods count! Expected: " +
                    moduleCount + " but was " + subMethodCount);
        }

-------------

PR Review: https://git.openjdk.org/jdk/pull/15234#pullrequestreview-1579273111
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295023900
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295023665
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295022781
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295024085
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295029909
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295025060

From duke at openjdk.org  Tue Aug 15 19:51:44 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 19:51:44 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v5]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <s1j95tpNUgqhinyfwCiEVQxfdnAZrLnWovrxc_U-rT0=.f5a5694a-1061-4e0f-8ee1-17bc8ce2dfb3@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request incrementally with four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591
   
   * origin/fix-8311591:
     Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
     Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
 - Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Reformat, add missing copyright header
   
   Remove duplicated module in add mods call
   
   Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/1a2e463e..015a3c2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=03-04

  Stats: 35 lines in 3 files changed: 30 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From duke at openjdk.org  Tue Aug 15 19:54:41 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 19:54:41 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v6]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <P9DYdIMSmi0KVaZmqnBdpiaJ8c9yppG7CKqrYAQhfTI=.0c452706-8bb6-44f7-8f64-bf5cc4472b54@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing import, use size instead of count

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/015a3c2e..2ebc0592

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From mchung at openjdk.org  Tue Aug 15 19:58:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Aug 2023 19:58:12 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v6]
In-Reply-To: <P9DYdIMSmi0KVaZmqnBdpiaJ8c9yppG7CKqrYAQhfTI=.0c452706-8bb6-44f7-8f64-bf5cc4472b54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <P9DYdIMSmi0KVaZmqnBdpiaJ8c9yppG7CKqrYAQhfTI=.0c452706-8bb6-44f7-8f64-bf5cc4472b54@github.com>
Message-ID: <C4MAm2UZR0hhB8tJ5DBdZhRaOTjhkF7XNRYfNtdCNts=.5409e840-8701-47a7-a7c3-5cf8a519eccc@github.com>

On Tue, 15 Aug 2023 19:54:41 GMT, Christoph <duke at openjdk.org> wrote:

>> Add new test case with sample modules that contains some requires/exports/uses/provides.
>> 
>> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
>> 
>> Follow up task from https://github.com/openjdk/jdk/pull/14408
>
> Christoph has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing import, use size instead of count

JLinkDedupTestBatchSizeOne.java line 115-144 can be deleted; otherwise, looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15234#pullrequestreview-1579317868

From duke at openjdk.org  Tue Aug 15 19:58:15 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 19:58:15 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v5]
In-Reply-To: <s1j95tpNUgqhinyfwCiEVQxfdnAZrLnWovrxc_U-rT0=.f5a5694a-1061-4e0f-8ee1-17bc8ce2dfb3@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <s1j95tpNUgqhinyfwCiEVQxfdnAZrLnWovrxc_U-rT0=.f5a5694a-1061-4e0f-8ee1-17bc8ce2dfb3@github.com>
Message-ID: <FAHtLlP90GDpZ44mKrm3TTQ6P6i5M0NG0roVCWMCxrA=.40d0d84d-1a8b-489e-8a5c-e88e1663537c@github.com>

On Tue, 15 Aug 2023 19:51:44 GMT, Christoph <duke at openjdk.org> wrote:

>> Add new test case with sample modules that contains some requires/exports/uses/provides.
>> 
>> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
>> 
>> Follow up task from https://github.com/openjdk/jdk/pull/14408
>
> Christoph has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/fix-8311591' into fix-8311591
>    
>    * origin/fix-8311591:
>      Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
>      Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
>  - Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Update test/jdk/tools/jlink/dedup/src/m4/p4/Main.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Reformat, add missing copyright header
>    
>    Remove duplicated module in add mods call
>    
>    Co-authored-by: Oliver Kopp <kopp.dev at gmail.com>

Thanks a lot for your explanation and suggestions! Now we understood this :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15234#issuecomment-1679515563

From duke at openjdk.org  Tue Aug 15 20:03:46 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 20:03:46 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v7]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <KG43OpUZa_mFeJtOmRdLcElR_ffsL98CeTvpBVeREgQ=.67fc498c-9fa5-4c07-998e-18d35c81e43d@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request incrementally with one additional commit since the last revision:

  remove obsolete jimage and decompile methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/2ebc0592..2bcdd2fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=05-06

  Stats: 30 lines in 1 file changed: 0 ins; 30 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From aturbanov at openjdk.org  Tue Aug 15 20:21:31 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 15 Aug 2023 20:21:31 GMT
Subject: RFR: 8314321: Remove unused field
 jdk.internal.util.xml.impl.Attrs.mAttrIdx
Message-ID: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>

A field `char mAttrIdx` in the `jdk.internal.util.xml.impl.Attrs` class is unused and can be removed.

-------------

Commit messages:
 - [PATCH] Remove unused field jdk.internal.util.xml.impl.Attrs.mAttrIdx

Changes: https://git.openjdk.org/jdk/pull/15298/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15298&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314321
  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15298.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15298/head:pull/15298

PR: https://git.openjdk.org/jdk/pull/15298

From duke at openjdk.org  Tue Aug 15 20:49:33 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 20:49:33 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v8]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <BagTRsERBn4WuD9pvOJSaVTYpR1T9SuLKpqaBZf-H_4=.3c862e98-9d72-4d51-905a-76ac079b98a1@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request incrementally with one additional commit since the last revision:

  remove obsolete constant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/2bcdd2fc..94fcd8d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From mchung at openjdk.org  Tue Aug 15 20:49:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Aug 2023 20:49:33 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v7]
In-Reply-To: <KG43OpUZa_mFeJtOmRdLcElR_ffsL98CeTvpBVeREgQ=.67fc498c-9fa5-4c07-998e-18d35c81e43d@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <KG43OpUZa_mFeJtOmRdLcElR_ffsL98CeTvpBVeREgQ=.67fc498c-9fa5-4c07-998e-18d35c81e43d@github.com>
Message-ID: <8UxLRpATLE95LueJ6bjK5OOjr-ldLJ_om-WyoOkv5JA=.13d6650f-f74e-4973-aa94-bb97a5c17871@github.com>

On Tue, 15 Aug 2023 20:03:46 GMT, Christoph <duke at openjdk.org> wrote:

>> Add new test case with sample modules that contains some requires/exports/uses/provides.
>> 
>> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
>> 
>> Follow up task from https://github.com/openjdk/jdk/pull/14408
>
> Christoph has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove obsolete jimage and decompile methods

Marked as reviewed by mchung (Reviewer).

test/jdk/tools/jlink/dedup/src/m4/p4/Main.java line 35:

> 33: 
> 34: public class Main {
> 35:     private final static int MODULE_SUB_METHOD_COUNT = 9;

This is leftover and should be deleted

-------------

PR Review: https://git.openjdk.org/jdk/pull/15234#pullrequestreview-1579396751
PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295090298

From duke at openjdk.org  Tue Aug 15 20:49:33 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 20:49:33 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v7]
In-Reply-To: <8UxLRpATLE95LueJ6bjK5OOjr-ldLJ_om-WyoOkv5JA=.13d6650f-f74e-4973-aa94-bb97a5c17871@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <KG43OpUZa_mFeJtOmRdLcElR_ffsL98CeTvpBVeREgQ=.67fc498c-9fa5-4c07-998e-18d35c81e43d@github.com>
 <8UxLRpATLE95LueJ6bjK5OOjr-ldLJ_om-WyoOkv5JA=.13d6650f-f74e-4973-aa94-bb97a5c17871@github.com>
Message-ID: <P84LYF-m7vNfbOTfg5HVFR2MjDCaIIXOSHiDdV5YE-8=.1f81924b-87f0-4348-8b55-d9ad961dba3c@github.com>

On Tue, 15 Aug 2023 20:41:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Christoph has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove obsolete jimage and decompile methods
>
> test/jdk/tools/jlink/dedup/src/m4/p4/Main.java line 35:
> 
>> 33: 
>> 34: public class Main {
>> 35:     private final static int MODULE_SUB_METHOD_COUNT = 9;
> 
> This is leftover and should be deleted

Ah yeah overlooked that!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15234#discussion_r1295092962

From duke at openjdk.org  Tue Aug 15 20:56:43 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 20:56:43 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v9]
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <fKJRdOb31Bew20AGubIdJdDqC0YYqOFV1Y2Vh5UE2T0=.f5f6270a-f075-48a2-a8ad-cab26c7e5024@github.com>

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

Christoph has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15234/files
  - new: https://git.openjdk.org/jdk/pull/15234/files/94fcd8d1..42df3f5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15234&range=07-08

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15234/head:pull/15234

PR: https://git.openjdk.org/jdk/pull/15234

From serb at openjdk.org  Tue Aug 15 21:08:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Aug 2023 21:08:10 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <a2SDpVWXfEySGrUu8U9E2w30RcrDeKOj0PL__ZUbsSw=.68f9c4d2-d0a5-4b72-b0c6-ea13aaf89534@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
 <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>
 <H7j-6T9Js9u8c2ehXTFu_ZXtbXd5UHyBHkXhmMU_0Vo=.b101c354-2e74-48ce-bc9d-0417e53f11ca@github.com>
 <a2SDpVWXfEySGrUu8U9E2w30RcrDeKOj0PL__ZUbsSw=.68f9c4d2-d0a5-4b72-b0c6-ea13aaf89534@github.com>
Message-ID: <nq-fINDtliP5pixXJicIdNN-gI3jLczPry5QGm0VJFw=.aaf3d470-6a5b-4637-a2a6-e072db95ef26@github.com>

On Tue, 15 Aug 2023 17:56:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>This seems to be a very "free" interpretation of the specification to me. According to my understanding, the valid sizes of 8, 16, 24 or 28 as described in the Wikipedia article are a direct consequence of the specification.

I have provided a test.zip file above which passed the zip integrity test via "zip -T" and can be unzip w/o errors, but rejected by the openjdk. That zip was created based on the actual specification, and not on the wiki.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679613530

From simonis at openjdk.org  Tue Aug 15 21:42:11 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Aug 2023 21:42:11 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
Message-ID: <1aVCVPhBgbggmGoKUiQBmRoYoVGm78R6JHxJkZeFc84=.efd5d14c-c80d-4087-b68d-3e1f6c2cb4ca@github.com>

On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up spacing and added missing comma

Marked as reviewed by simonis (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15273#pullrequestreview-1579474217

From simonis at openjdk.org  Tue Aug 15 21:42:13 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Aug 2023 21:42:13 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <nq-fINDtliP5pixXJicIdNN-gI3jLczPry5QGm0VJFw=.aaf3d470-6a5b-4637-a2a6-e072db95ef26@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
 <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>
 <H7j-6T9Js9u8c2ehXTFu_ZXtbXd5UHyBHkXhmMU_0Vo=.b101c354-2e74-48ce-bc9d-0417e53f11ca@github.com>
 <a2SDpVWXfEySGrUu8U9E2w30RcrDeKOj0PL__ZUbsSw=.68f9c4d2-d0a5-4b72-b0c6-ea13aaf89534@github.com>
 <nq-fINDtliP5pixXJicIdNN-gI3jLczPry5QGm0VJFw=.aaf3d470-6a5b-4637-a2a6-e072db95ef26@github.com>
Message-ID: <ieQr5Kd_kHdEyiPDUCuy2hHfljsYkL-bfA0dHji6Icc=.ea6bb3e0-f4dc-4bc8-9f49-792f6dc0ee14@github.com>

On Tue, 15 Aug 2023 21:05:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I have provided a test.zip file above which passed the zip integrity test via "zip -T" and can be unzip w/o errors, but rejected by the openjdk. That zip was created based on the actual specification, and not on the wiki.

Did you create that zip file manually or was it created by a tool and if by a tool than which one? I think we must differentiate here between functional compatibility with a tool like "zip", compatibility with a specification and the compatibility with existing zip files and zip files created by common tools.

The latter is important and required in order to avoid regressions (and I think that's exactly what we're fixing with this PR). Compatibility with a specification is great as long as it doesn't collide with the previous point. Behavioral compatibility with a tool like "zip" is the least important in this list and I think as long as the file in question is not an artifact commonly created by popular tools it is fine to behave different for edge cases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679652919

From serb at openjdk.org  Tue Aug 15 22:22:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 15 Aug 2023 22:22:10 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v6]
In-Reply-To: <ieQr5Kd_kHdEyiPDUCuy2hHfljsYkL-bfA0dHji6Icc=.ea6bb3e0-f4dc-4bc8-9f49-792f6dc0ee14@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <8EuC3QwueyMoc-aiwP9VfsWUZriaeSI1F_CgyvXxL68=.22397489-4d7e-49e0-ad0e-ef9cd1cac993@github.com>
 <o82LM00-odWvKsi5xTUM71oNOCe5hpEigdCoB1KyCbQ=.154ee559-f32f-4a6a-a11d-dca42fc351e3@github.com>
 <GKmFJZGH8xQLFd763dLhwSrKSsAL8Tn-CCsXWI7uAy8=.56b47d52-fc01-4499-8b77-a31b0a85cb80@github.com>
 <H7j-6T9Js9u8c2ehXTFu_ZXtbXd5UHyBHkXhmMU_0Vo=.b101c354-2e74-48ce-bc9d-0417e53f11ca@github.com>
 <a2SDpVWXfEySGrUu8U9E2w30RcrDeKOj0PL__ZUbsSw=.68f9c4d2-d0a5-4b72-b0c6-ea13aaf89534@github.com>
 <nq-fINDtliP5pixXJicIdNN-gI3jLczPry5QGm0VJFw=.aaf3d470-6a5b-4637-a2a6-e072db95ef26@github.com>
 <ieQr5Kd_kHdEyiPDUCuy2hHfljsYkL-bfA0dHji6Icc=.ea6bb3e0-f4dc-4bc8-9f49-792f6dc0ee14@github.com>
Message-ID: <yuZUo30hP7Wzskck61e9WrEFk4guo82GQC_yBsegKxM=.d2860413-4ab2-464b-a1b6-820800a59036@github.com>

On Tue, 15 Aug 2023 21:38:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Did you create that zip file manually or was it created by a tool and if by a tool than which one? I think we must differentiate here between functional compatibility with a tool like "zip", compatibility with a specification and the compatibility with existing zip files and zip files created by common tools.

That was created manually and then repacked by the zip.

> The latter is important and required in order to avoid regressions (and I think that's exactly what we're fixing with this PR). Compatibility with a specification is great as long as it doesn't collide with the previous point. Behavioral compatibility with a tool like "zip" is the least important in this list and I think as long as the file in question is not an artifact commonly created by popular tools it is fine to behave different for edge cases.

That file is accepted by zip, by the latest JDK8u382, by the JDK20 GA, and rejected by the 20.0.2. That is a regression in the latest update of JDK11+ which we trying to solve here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679696095

From duke at openjdk.org  Tue Aug 15 22:37:21 2023
From: duke at openjdk.org (Christoph)
Date: Tue, 15 Aug 2023 22:37:21 GMT
Subject: Integrated: 8311591: Add SystemModulesPlugin test case that splits
 module descriptors with new local variables defined by DedupSetBuilder
In-Reply-To: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
Message-ID: <C5fUxZpspKcZLviOKxXRIQC1IQ-aM1vnEyOvYh9w_wc=.cb15fbe8-e594-40ef-9cb5-c242bdf51cc5@github.com>

On Thu, 10 Aug 2023 21:42:41 GMT, Christoph <duke at openjdk.org> wrote:

> Add new test case with sample modules that contains some requires/exports/uses/provides.
> 
> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
> 
> Follow up task from https://github.com/openjdk/jdk/pull/14408

This pull request has now been integrated.

Changeset: bc8e9f44
Author:    Christoph Schwentker <siedlerkiller at gmail.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc8e9f44a39ff59b59b2d1d5d546a148be75a2f2
Stats:     355 lines in 9 files changed: 351 ins; 0 del; 4 mod

8311591: Add SystemModulesPlugin test case that splits module descriptors with new local variables defined by DedupSetBuilder

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/15234

From simonis at openjdk.org  Tue Aug 15 23:16:10 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 15 Aug 2023 23:16:10 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
Message-ID: <FGiugtg9L9pNduibuMSWy_vrsbZOov1OCirx_ueygJU=.64505da1-bd07-478d-8148-b05430d86697@github.com>

On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up spacing and added missing comma

> That was created manually and then repacked by the zip.

> That file is accepted by zip, by the latest JDK8u382, by the JDK20 GA, and rejected by the 20.0.2. That is a regression in the latest update of JDK11+ which we trying to solve here.

In my opinion we should resolve the regression for existing zip files and zip files which are commonly created by popular tools.

As far as I understand you can manually create "artificial" zip files which can be processed by the zip tool and previous versions of the JDK but not by new ones. As long as these kind of files aren't automatically generated by common tools, I don't see that as a *real* regression. I'm not even sure if we should fix that at all because hardly anybody is manually creating such zip files except maybe for attackers who intend to break the JDK.

I recommend we should instead fix the real problem as quickly as possible and create a new issue for potential additional improvements if you think that's necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679745984

From lmesnik at openjdk.org  Wed Aug 16 00:21:23 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Aug 2023 00:21:23 GMT
Subject: RFR: 8314330: java/foreign tests should respect vm flags when start
 new processes
Message-ID: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>

The test helper which spawn new jvms is updated to start them using VM flags for testing.

-------------

Commit messages:
 - 8314330: java/foreign tests should respect vm flags when start new processes

Changes: https://git.openjdk.org/jdk/pull/15302/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314330
  Stats: 10 lines in 1 file changed: 1 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15302/head:pull/15302

PR: https://git.openjdk.org/jdk/pull/15302

From serb at openjdk.org  Wed Aug 16 02:25:26 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Aug 2023 02:25:26 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <FGiugtg9L9pNduibuMSWy_vrsbZOov1OCirx_ueygJU=.64505da1-bd07-478d-8148-b05430d86697@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
 <FGiugtg9L9pNduibuMSWy_vrsbZOov1OCirx_ueygJU=.64505da1-bd07-478d-8148-b05430d86697@github.com>
Message-ID: <KLEqHRwJyDou51RSXoa3tTWXMa075BmZdgyRFuXmu5Q=.dd82df6d-471b-4353-b351-5cf4ea979300@github.com>

On Tue, 15 Aug 2023 23:13:00 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>As far as I understand you can manually create "artificial" zip files which can be processed by the zip tool and previous versions of the JDK but not by new ones.

It can be processed by the new/latest version of JDK8.

> As long as these kind of files aren't automatically generated by common tools, I don't see that as a real regression.

It is clearly a regression. All that new checks should be proved to be based on some statement from the specification otherwise - such checks should be changed or deleted. As of now the strict check of the size does not based on the spec nor the behavior of the zip cmd.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679869021

From serb at openjdk.org  Wed Aug 16 04:20:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Aug 2023 04:20:08 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
Message-ID: <lJoCjbUzKygVvbr32sITI8Tn1PX0H2lxQXvruUv6DYU=.b73e8136-475d-49ef-8dc2-1770dc87ae5d@github.com>

On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up spacing and added missing comma

My overall point is that it will be unfortunate if users will be able to open some files on Linux/macOS/Windows using default programs but will not be able to do that using Java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1679933388

From alanb at openjdk.org  Wed Aug 16 06:52:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 06:52:30 GMT
Subject: RFR: 8314280: StructuredTaskScope.shutdown should document that the
 state of completing subtasks is not defined
Message-ID: <LeoqedNfFK6IIupqWVYC3SXlVC45GaiN36zP4E_8B-k=.50ac351b-bbcf-4905-b97a-baeb5f9fa317@github.com>

This is a docs only change. The specification for StructuredTaskScope.shutdown should make it clear that the state of subtasks that are completing (with a result or exception) at around the time of shutdown is not defined. The state of a completing subtask may transition to a terminal state, it may not, as it is racing with the shutdown.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15293/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15293&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314280
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15293/head:pull/15293

PR: https://git.openjdk.org/jdk/pull/15293

From alanb at openjdk.org  Wed Aug 16 06:52:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 06:52:35 GMT
Subject: RFR: 8313290: Misleading exception message from STS.Subtask::get when
 task forked after shutdown
Message-ID: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>

This is a small issue with StructuredTaskScope. If the owner attempts to fork a subtask and the task scope is shutdown then the implementation doesn't currently force the owner to join when it's the first fork in a new round of forking. The result is that broken code calling Subtask::get throws ISE with the wrong exception message.

The existing test for this API is updated to remove a duplicate test and also fix two tasks that didn't call join.

-------------

Commit messages:
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15076/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15076&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313290
  Stats: 23 lines in 2 files changed: 2 ins; 19 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15076/head:pull/15076

PR: https://git.openjdk.org/jdk/pull/15076

From alanb at openjdk.org  Wed Aug 16 07:01:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 07:01:14 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
Message-ID: <u8fVtweweRcNEvFWSkLuxvN5AC20XRLyhp1MyrFVfkQ=.043b2cc3-6904-4cbf-9e96-dcc577005c3f@github.com>

On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up spacing and added missing comma

Latest changes looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15273#pullrequestreview-1579921176

From alanb at openjdk.org  Wed Aug 16 07:05:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 07:05:11 GMT
Subject: RFR: 8314321: Remove unused field
 jdk.internal.util.xml.impl.Attrs.mAttrIdx
In-Reply-To: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
References: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
Message-ID: <xxhNXkX8-o0wzdaTInUb5JuPa_pYpOmPgHleZY28C_A=.eba018a2-06bf-4ac7-b3a3-88113bbcfc2d@github.com>

On Tue, 15 Aug 2023 20:13:18 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A field `char mAttrIdx` in the `jdk.internal.util.xml.impl.Attrs` class is unused and can be removed.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15298#pullrequestreview-1579926617

From vtewari at openjdk.org  Wed Aug 16 07:26:07 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 16 Aug 2023 07:26:07 GMT
Subject: RFR: 8314321: Remove unused field
 jdk.internal.util.xml.impl.Attrs.mAttrIdx
In-Reply-To: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
References: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
Message-ID: <sM_4RG80sY_l0k1nR74k43VGemG44SAEny7op1G6rZk=.dea2bf9d-a233-4775-b5aa-f9fa50dd4d85@github.com>

On Tue, 15 Aug 2023 20:13:18 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A field `char mAttrIdx` in the `jdk.internal.util.xml.impl.Attrs` class is unused and can be removed.

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15298#pullrequestreview-1579959938

From alanb at openjdk.org  Wed Aug 16 07:32:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 07:32:10 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <FGiugtg9L9pNduibuMSWy_vrsbZOov1OCirx_ueygJU=.64505da1-bd07-478d-8148-b05430d86697@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
 <FGiugtg9L9pNduibuMSWy_vrsbZOov1OCirx_ueygJU=.64505da1-bd07-478d-8148-b05430d86697@github.com>
Message-ID: <gaYf9GStyt4QVdAKmcgLuC-HP_zW2TfwE_9-iSFKmlQ=.782ccb7e-9a52-4f5b-a6b1-88c2553c3830@github.com>

On Tue, 15 Aug 2023 23:13:00 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> That file is accepted by zip, by the latest JDK8u382, by the JDK20 GA, and rejected by the 20.0.2. That is a regression in the latest update of JDK11+ which we trying to solve here.

Have you tested your ZIP file with -Djdk.util.zip.disableZip64ExtraFieldValidation=true? That's the system property to disable the additional checking and is the "get out of jail card" for anyone running into issues. As always with changes like this, or other changes that tighten up checking, there is a risk that it will break something, hence the system property to give existing deployments a workaround to continue. In this case, the original change exposed an issue with a number of Apache projects (see the linked bugs in their issue trackers) and a bad bug in the BND tool that was fixed a few years ago. The system property is the temporary workaround until the deployment has versions of the libraries produced with updated versions of these tools, or a JDK update that tolerates a 0 block size.

I think the main lesson with all this is that the JDK doesn't have enough "interop" tests in this area. There are dozens of tools and plugins that generate their own ZIP or JAR files. The addition of the ZIP64 extensions a few number of years ago ushered in a lot of interop issues due to different interpretations of the spec. The changes in PR expands the tests a bit but I think a follow on work will be required to massively expand the number of sample ZIP and JAR files that the JDK is tested with.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1680103189

From rgiulietti at openjdk.org  Wed Aug 16 08:14:31 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 16 Aug 2023 08:14:31 GMT
Subject: RFR: 8314209: Wrong @since tag for RandomGenerator::equiDoubles
Message-ID: <QVqzeE73VKKSazII3P2SS4a6eYO8xcsJQABeBhq-KZ0=.bfa8d3bb-615c-481c-90eb-d76de5a3ec92@github.com>

Please review this trivial typo.
TIA

-------------

Commit messages:
 - 8314209: Wrong @since tag for RandomGenerator::equiDoubles

Changes: https://git.openjdk.org/jdk/pull/15303/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314209
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15303.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15303/head:pull/15303

PR: https://git.openjdk.org/jdk/pull/15303

From alanb at openjdk.org  Wed Aug 16 08:17:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 08:17:05 GMT
Subject: RFR: 8314209: Wrong @since tag for RandomGenerator::equiDoubles
In-Reply-To: <QVqzeE73VKKSazII3P2SS4a6eYO8xcsJQABeBhq-KZ0=.bfa8d3bb-615c-481c-90eb-d76de5a3ec92@github.com>
References: <QVqzeE73VKKSazII3P2SS4a6eYO8xcsJQABeBhq-KZ0=.bfa8d3bb-615c-481c-90eb-d76de5a3ec92@github.com>
Message-ID: <gSSFvbOCe-Lfng0UpwOzfbqfa5xii7w36ZXxOI7-1_I=.cd29a330-360d-44b9-af59-ed7ed43938a3@github.com>

On Wed, 16 Aug 2023 08:07:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Please review this trivial typo.
> TIA

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15303#pullrequestreview-1580051924

From rgiulietti at openjdk.org  Wed Aug 16 08:24:14 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 16 Aug 2023 08:24:14 GMT
Subject: Integrated: 8314209: Wrong @since tag for RandomGenerator::equiDoubles
In-Reply-To: <QVqzeE73VKKSazII3P2SS4a6eYO8xcsJQABeBhq-KZ0=.bfa8d3bb-615c-481c-90eb-d76de5a3ec92@github.com>
References: <QVqzeE73VKKSazII3P2SS4a6eYO8xcsJQABeBhq-KZ0=.bfa8d3bb-615c-481c-90eb-d76de5a3ec92@github.com>
Message-ID: <y6yYTa_Eyomi3BvDEsAYyGifu3enzvzYWm-Gv2tAFR0=.9b96f690-e959-4354-955b-4477dee73426@github.com>

On Wed, 16 Aug 2023 08:07:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Please review this trivial typo.
> TIA

This pull request has now been integrated.

Changeset: b80001de
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b80001de0c0aeedeb412430660a4727fc26be98b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8314209: Wrong @since tag for RandomGenerator::equiDoubles

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15303

From duke at openjdk.org  Wed Aug 16 09:11:34 2023
From: duke at openjdk.org (Cristian Vat)
Date: Wed, 16 Aug 2023 09:11:34 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v7]
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <31xjj3_jPZWzrPuhU7DgeQglMiluV2MSKlP4h2DUfNE=.e626cc53-3fde-4f3a-92fe-23f1421ecd2d@github.com>

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

Cristian Vat 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 seven additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8311939
 - Merge branch 'openjdk:master' into JDK-8311939
 - review condition
 - changes and test for CIBackRef
 - remove new line
 - reduce allocations also for Matcher.usePattern
 - 8311939: Excessive allocation of Matcher.groups array

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14894/files
  - new: https://git.openjdk.org/jdk/pull/14894/files/0538e25e..9e33c2e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14894&range=05-06

  Stats: 932 lines in 52 files changed: 832 ins; 14 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/14894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14894/head:pull/14894

PR: https://git.openjdk.org/jdk/pull/14894

From alanb at openjdk.org  Wed Aug 16 09:57:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 09:57:08 GMT
Subject: RFR: 8314129: Make fields final in java.util.Scanner
In-Reply-To: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
References: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
Message-ID: <g9Ui7xs3a2VIzbo5p6fdJgtxBos2e-kixBicqD5ifOw=.614b1632-f949-4c74-afae-ae08f4bb164c@github.com>

On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Made a few fields `final` in java.util.Scanner.
> Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.`

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14863#pullrequestreview-1580230627

From aph at openjdk.org  Wed Aug 16 10:12:10 2023
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 16 Aug 2023 10:12:10 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
Message-ID: <NnaAUjqrHuaELbw_x1AQNNyDwuQ_hBgE-lAjNAxEC28=.536bd163-60e8-41b6-950d-0f8bfae636e6@github.com>

On Thu, 15 Jun 2023 09:21:13 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'dpqs23' of github.com:bourgesl/jdk-official into dpqs23
>  - simplified test to enable radix sort (improved sorting on period and shuffle data) + updated version to 22

These benchmarks are all small arrays. We need to check for possible regressions here.
Also, I'm rather concerned that we might lose the data from this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1680329201

From dl at openjdk.org  Wed Aug 16 10:37:13 2023
From: dl at openjdk.org (Doug Lea)
Date: Wed, 16 Aug 2023 10:37:13 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <dGCJ_heaOQaSdOOFr_RuaU4avoCYqsB5KEGcixEtgtM=.9b2d5719-0744-4a8e-851a-31f0ce60ea0c@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
 <dGCJ_heaOQaSdOOFr_RuaU4avoCYqsB5KEGcixEtgtM=.9b2d5719-0744-4a8e-851a-31f0ce60ea0c@github.com>
Message-ID: <NihW42UsTHECmRmdgxZUlelVnlvVA9EQnqVNgK6Yf-E=.19c8a8b8-e5bc-4e52-81d8-f3d8599958b5@github.com>

On Tue, 15 Aug 2023 14:19:29 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea 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 45 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Update @since tags
>>  - resync
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - ExecutorService tests
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Rework versioning
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/3258dc09...585769c9
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 442:
> 
>> 440:      * queues are at odd indices. Worker phase ids masked with SMASK
>> 441:      * match their index. Shared (submission) queues are at even
>> 442:      * indices. Grouping them together in this way simplifies and
> 
> @DougLea Interesting?so by having the worker queues at odd indices increases the likelihood of the then adjacent submission queues already having been prefetched?

More-or-less. At top-level, both kinds of queues should be sampled with approx the same probability, which is simpler if they are all in the same array. But we also need to identify what kind they are without looking at them, leading to odd/even scheme. One disadvantage is that there are usually many fewer submission queues, so there can be a lot of wasted probes (null slots). But still cheaper than alternatives because of cache locality etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1295702036

From lbourges at openjdk.org  Wed Aug 16 10:38:10 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 16 Aug 2023 10:38:10 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
Message-ID: <2vDI94_wNPzNIkKH9f9vQQ3aImva3XqSrNdXxsQXqy8=.2328f44a-3c59-4487-b4c4-7a2d3b3546e1@github.com>

On Thu, 15 Jun 2023 09:21:13 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'dpqs23' of github.com:bourgesl/jdk-official into dpqs23
>  - simplified test to enable radix sort (improved sorting on period and shuffle data) + updated version to 22

Keeping this PR alive

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1680360074

From lbourges at openjdk.org  Wed Aug 16 10:38:11 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 16 Aug 2023 10:38:11 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <NnaAUjqrHuaELbw_x1AQNNyDwuQ_hBgE-lAjNAxEC28=.536bd163-60e8-41b6-950d-0f8bfae636e6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
 <NnaAUjqrHuaELbw_x1AQNNyDwuQ_hBgE-lAjNAxEC28=.536bd163-60e8-41b6-950d-0f8bfae636e6@github.com>
Message-ID: <ifDiEU0yMbpwUeYsLJG0c92plKQ539xsAmC9pGCd7J0=.d2dda212-6cb8-48bf-863a-12e9991018dc@github.com>

On Wed, 16 Aug 2023 10:09:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

> These benchmarks are all small arrays. We need to check for possible regressions here.
The JMH ArraysSort tests arrays of length 800 to 2 million elements.
Is it not enough for smaller or larger arrays ?

> Also, I'm rather concerned that we might lose the data from this PR.
Keep alive done!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1680363342

From dnsimon at openjdk.org  Wed Aug 16 11:10:21 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Aug 2023 11:10:21 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <yQ0uOrANg_4-bwcHX9hg9UQPwKe0I2bI3u81a2f4lMQ=.92c05cad-52ec-429a-ab87-c1743dadd545@github.com>
Message-ID: <YAY_CUUlaMdP_MTmnUGeXH2rFpExXn_GT1cWr2aEoPw=.0e4f2773-ae75-47e5-8f3d-6baa3eaba7d3@github.com>

On Thu, 1 Jun 2023 10:25:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I'm concerned about the hard-coding of delimiter values and the added accidential complexity in order to avoid the Regex engine. Note that this test fails due to the delimiter hard-coding:
> 
> ```
> jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java
> ```
> 
> This change seems hard to maintain. How would you ensure this won't regress?

There's seems to be a lot of usage of `sscanf` in https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/cgroupSubsystem_linux.cpp. Maybe I'm misreading that code, but doesn't it also hard code assumptions about the file format(s)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1680403327

From sergei.tsypanov at yandex.ru  Wed Aug 16 11:37:42 2023
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 16 Aug 2023 13:37:42 +0200
Subject: Different costs of accessing volatile reference and array
Message-ID: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>

Hello,

I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references.

Here's the benchmark for array:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(time = 2, iterations = 5)
@Measurement(time = 2, iterations = 5)
@Fork(value = 4, jvmArgs = "-Xmx1g")
public class VolatileArrayInLoopBenchmark {

@Benchmark
public int accessVolatileInLoop(Data data) {
int sum = 0;
for (int i = 0; i < data.count; i++) {
sum += data.ints[i];
}
return sum;
}

@Benchmark
public int hoistVolatileFromLoop(Data data) {
int sum = 0;
int[] ints = data.ints;
for (int i = 0; i < data.count; i++) {
sum += ints[i];
}
return sum;
}

@State(Scope.Benchmark)
public static class Data {
@Param({"1", "10", "100"})
private int count;
private volatile int[] ints;

@Setup
public void setUp() {
int[] ints = new int[count];
for (int i = 0; i < ints.length; i++) {
ints[i] = ThreadLocalRandom.current().nextInt();
}
this.ints = ints;
}
}
}

and this one is for reference:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(time = 2, iterations = 5)
@Measurement(time = 2, iterations = 5)
@Fork(value = 4, jvmArgs = "-Xmx1g")
public class VolatileFieldInLoopBenchmark {

@Benchmark
public int accessVolatileInLoop(Data data) {
int sum = 0;
for (int i = 0; i < data.count; i++) {
sum += data.value;
}
return sum;
}

@Benchmark
public int hoistVolatileFromLoop(Data data) {
int sum = 0;
int value = data.value;
for (int i = 0; i < data.count; i++) {
sum += value;
}
return sum;
}

@State(Scope.Benchmark)
public static class Data {
private final ThreadLocalRandom random = ThreadLocalRandom.current();

private volatile int value = random.nextInt();

@Param({"1", "10", "100"})
private int count;
}
}

>From measurement results it looks like volatile array access is cheaper than "plain" reference access:

Java 19

Benchmark (count) Mode Cnt Score Error Units
VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 2.110 ? 0.404 ns/op
VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 14.836 ? 2.825 ns/op
VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 146.497 ? 25.786 ns/op
VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 3.006 ? 0.686 ns/op
VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 6.222 ? 1.215 ns/op
VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 33.262 ? 6.579 ns/op

VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.823 ? 0.382 ns/op
VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.259 ? 2.874 ns/op
VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 98.648 ? 18.500 ns/op
VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.189 ? 0.412 ns/op
VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.734 ? 0.891 ns/op
VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 7.126 ? 1.309 ns/op

Java 20

Benchmark (count) Mode Cnt Score Error Units
VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.714 ? 0.066 ns/op
VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.703 ? 0.148 ns/op
VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 109.001 ? 1.866 ns/op
VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.408 ? 0.224 ns/op
VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.678 ? 0.060 ns/op
VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 24.711 ? 1.091 ns/op

VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.366 ? 0.105 ns/op
VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 7.388 ? 0.119 ns/op
VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 74.630 ? 1.163 ns/op
VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 1.653 ? 0.035 ns/op
VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 3.138 ? 0.040 ns/op
VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 4.945 ? 0.177 ns/op

So my question is why is volatile reference access is relatively more expensive than volatile array access?

From coffeys at openjdk.org  Wed Aug 16 12:10:20 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 16 Aug 2023 12:10:20 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
Message-ID: <G5TTvSlfocf0-O1uSNw4m616BYyBWi8lVtDmOePUVMg=.27d693fc-8188-4fa4-8d50-c21be4b95523@github.com>

On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
>> 
>>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
>> 
>> 1. Extra field includes padding :
>> 
>> 
>> ----------------#1--------------------
>> [Central Directory Header]
>>   0x3374: Signature    : 0x02014b50
>>   0x3378: Created Zip Spec :    0xa [1.0]
>>   0x3379: Created OS   :    0x0 [MS-DOS]
>>   0x337a: VerMadeby    :    0xa [0, 1.0]
>>   0x337b: VerExtract   :    0xa [1.0]
>>   0x337c: Flag      :   0x800
>>   0x337e: Method     :    0x0 [STORED]
>>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>>   0x3384: CRC       : 0x694c6952
>>   0x3388: Compressed Size :   0x624
>>   0x338c: Uncompressed Size:   0x624
>>   0x3390: Name Length   :   0x1b
>>  0x3392: Extra Length  :    0x7
>> 		[tag=0xcafe, sz=0, data= ]
>> 				->[tag=cafe, size=0]
>>   0x3394: Comment Length :    0x0
>>   0x3396: Disk Start   :    0x0
>>   0x3398: Attrs      :    0x0
>>   0x339a: AttrsEx     :    0x0
>>   0x339e: Loc Header Offset:    0x0
>>   0x33a2: File Name    : res/drawable/size_48x48.jpg
>> 
>> 
>> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
>> 
>> 
>> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
>> 
>> 
>> ----------------#359--------------------
>> [Central Directory Header]
>>    0x600b4: Signature        : 0x02014b50
>>    0x600b8: Created Zip Spec :       0x14 [2.0]
>>    0x600b9: Created OS       :        0x0 [MS-DOS]
>>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>>    0x600bb: VerExtract       :       0x14 [2.0]
>>    0x600bc: Flag             :      0x808
>>    0x600be: Method           :        0x8 [DEFLATED]
>>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>>    0x600c4: CRC              : 0xd8f689cb
>>    0x600c8: Compressed Size  :      0x23e
>>    0x600cc: Uncompressed Size:      0x392
>>    0x600d0: Name Length      :       0x20
>>    0x600d2: Extra Length     :        0x8
>> 		[tag=0xbfef, sz=61373, data=        
>>   0x600d4: Comment Length   ...
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleaned up spacing and added missing comma

Marked as reviewed by coffeys (Reviewer).

nice work Lance, thanks for the comprehensive write up also.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15273#pullrequestreview-1580446503
PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1680483945

From sgehwolf at openjdk.org  Wed Aug 16 12:32:32 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 16 Aug 2023 12:32:32 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <D_H1BNeBhE3zDr0BDMm2REgSrhojL5VJGIxXTg_3mZk=.24ca8be1-9bb7-4b41-b602-30161865b7d4@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

Not as far as I'm aware (it can deal with tabs vs. spaces differences as well as multiple spaces).

FWIW, I've done [this change](https://github.com/openjdk/jdk/compare/master...jerboaa:jdk:jdk-21+25-cgroups-change) as a PoC a while ago and it seems sufficient to use the JDK's metrics impl in native-image (barring some perf numbers; If somebody provides me with pointers, happy to provide those too).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1680514999

From jvernee at openjdk.org  Wed Aug 16 12:36:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 16 Aug 2023 12:36:21 GMT
Subject: RFR: 8314330: java/foreign tests should respect vm flags when
 start new processes
In-Reply-To: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>
References: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>
Message-ID: <7wNiPUMnZLBeIB8Xixc2mbAWcULuxPj0aKAFtxETgkA=.addc5624-3793-4e1a-86aa-1607de958b1d@github.com>

On Wed, 16 Aug 2023 00:14:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test helper which spawn new jvms is updated to start them using VM flags for testing.

Marked as reviewed by jvernee (Reviewer).

test/jdk/java/foreign/UpcallTestHelper.java line 25:

> 23: 
> 24: import jdk.test.lib.process.ProcessTools;
> 25: import jdk.test.lib.Utils;

Looks like the `Utils` and `Paths` imports are no longer needed now.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15302#pullrequestreview-1580468855
PR Review Comment: https://git.openjdk.org/jdk/pull/15302#discussion_r1295812282

From raffaello.giulietti at oracle.com  Wed Aug 16 13:40:33 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 16 Aug 2023 15:40:33 +0200
Subject: Different costs of accessing volatile reference and array
In-Reply-To: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
References: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
Message-ID: <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>

If I read the data correctly, for the count=100 case in jdk 20 it takes 
109 ns/op for the array and 74 ns/op for the field.

To me this looks like a field access is _less_ expensive.

Am I missing something?



On 2023-08-16 13:37, ?????? ??????? wrote:
> Hello,
> 
> I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references.
> 
> Here's the benchmark for array:
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(time = 2, iterations = 5)
> @Measurement(time = 2, iterations = 5)
> @Fork(value = 4, jvmArgs = "-Xmx1g")
> public class VolatileArrayInLoopBenchmark {
> 
> @Benchmark
> public int accessVolatileInLoop(Data data) {
> int sum = 0;
> for (int i = 0; i < data.count; i++) {
> sum += data.ints[i];
> }
> return sum;
> }
> 
> @Benchmark
> public int hoistVolatileFromLoop(Data data) {
> int sum = 0;
> int[] ints = data.ints;
> for (int i = 0; i < data.count; i++) {
> sum += ints[i];
> }
> return sum;
> }
> 
> @State(Scope.Benchmark)
> public static class Data {
> @Param({"1", "10", "100"})
> private int count;
> private volatile int[] ints;
> 
> @Setup
> public void setUp() {
> int[] ints = new int[count];
> for (int i = 0; i < ints.length; i++) {
> ints[i] = ThreadLocalRandom.current().nextInt();
> }
> this.ints = ints;
> }
> }
> }
> 
> and this one is for reference:
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(time = 2, iterations = 5)
> @Measurement(time = 2, iterations = 5)
> @Fork(value = 4, jvmArgs = "-Xmx1g")
> public class VolatileFieldInLoopBenchmark {
> 
> @Benchmark
> public int accessVolatileInLoop(Data data) {
> int sum = 0;
> for (int i = 0; i < data.count; i++) {
> sum += data.value;
> }
> return sum;
> }
> 
> @Benchmark
> public int hoistVolatileFromLoop(Data data) {
> int sum = 0;
> int value = data.value;
> for (int i = 0; i < data.count; i++) {
> sum += value;
> }
> return sum;
> }
> 
> @State(Scope.Benchmark)
> public static class Data {
> private final ThreadLocalRandom random = ThreadLocalRandom.current();
> 
> private volatile int value = random.nextInt();
> 
> @Param({"1", "10", "100"})
> private int count;
> }
> }
> 
>  From measurement results it looks like volatile array access is cheaper than "plain" reference access:
> 
> Java 19
> 
> Benchmark (count) Mode Cnt Score Error Units
> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 2.110 ? 0.404 ns/op
> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 14.836 ? 2.825 ns/op
> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 146.497 ? 25.786 ns/op
> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 3.006 ? 0.686 ns/op
> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 6.222 ? 1.215 ns/op
> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 33.262 ? 6.579 ns/op
> 
> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.823 ? 0.382 ns/op
> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.259 ? 2.874 ns/op
> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 98.648 ? 18.500 ns/op
> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.189 ? 0.412 ns/op
> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.734 ? 0.891 ns/op
> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 7.126 ? 1.309 ns/op
> 
> Java 20
> 
> Benchmark (count) Mode Cnt Score Error Units
> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.714 ? 0.066 ns/op
> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.703 ? 0.148 ns/op
> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 109.001 ? 1.866 ns/op
> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.408 ? 0.224 ns/op
> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.678 ? 0.060 ns/op
> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 24.711 ? 1.091 ns/op
> 
> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.366 ? 0.105 ns/op
> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 7.388 ? 0.119 ns/op
> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 74.630 ? 1.163 ns/op
> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 1.653 ? 0.035 ns/op
> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 3.138 ? 0.040 ns/op
> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 4.945 ? 0.177 ns/op
> 
> So my question is why is volatile reference access is relatively more expensive than volatile array access?

From mbaesken at openjdk.org  Wed Aug 16 13:43:18 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Aug 2023 13:43:18 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
Message-ID: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>

We run into some BackingStoreException: Couldn't get file lock. e.g. here :

[JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
[JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
[JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
[JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
[JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
[JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
[JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
[JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
[JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
[JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
[JShell] ... 4 more

The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

-------------

Commit messages:
 - JDK-8314272

Changes: https://git.openjdk.org/jdk/pull/15308/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15308&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314272
  Stats: 15 lines in 1 file changed: 5 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15308.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15308/head:pull/15308

PR: https://git.openjdk.org/jdk/pull/15308

From dnsimon at openjdk.org  Wed Aug 16 13:52:27 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 16 Aug 2023 13:52:27 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <sGvK_yipxzLlPR9YrziLX7nsb1GidYh_bu5jaxRL8WI=.1019a046-4452-4290-9912-e8e9b4e828d9@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

Ok, thanks. It's obviously been too long since I used `sscanf` ;-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1680648653

From sergei.tsypanov at yandex.ru  Wed Aug 16 14:02:24 2023
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 16 Aug 2023 16:02:24 +0200
Subject: Different costs of accessing volatile reference and array
In-Reply-To: <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
References: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
 <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
Message-ID: <242691692194146@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230816/cd32b3c4/attachment.htm>

From sergei.tsypanov at yandex.ru  Wed Aug 16 14:06:05 2023
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 16 Aug 2023 16:06:05 +0200
Subject: Different costs of accessing volatile reference and array
In-Reply-To: <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
References: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
 <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
Message-ID: <624071692194765@s6wxws2fajj4foga.iva.yp-c.yandex.net>

I meant relation between in-loop and hoisted access.
 
In Java 19 when we take count = 100 for volatile array and hoist it from the loop then the average time decreases from 146 to 33 ns.
 
And if we take the same count for "plain" field and hoist it from the loop then the average time decreases from 98 to 7 ns.


> If I read the data correctly, for the count=100 case in jdk 20 it takes
> 109 ns/op for the array and 74 ns/op for the field.
> 
> To me this looks like a field access is _less_ expensive.
> 
> Am I missing something?
> 
> On 2023-08-16 13:37, ?????? ??????? wrote:
> 
>> Hello,
>>
>> I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references.
>>
>> Here's the benchmark for array:
>>
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Warmup(time = 2, iterations = 5)
>> @Measurement(time = 2, iterations = 5)
>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>> public class VolatileArrayInLoopBenchmark {
>>
>> @Benchmark
>> public int accessVolatileInLoop(Data data) {
>> int sum = 0;
>> for (int i = 0; i < data.count; i++) {
>> sum += data.ints[i];
>> }
>> return sum;
>> }
>>
>> @Benchmark
>> public int hoistVolatileFromLoop(Data data) {
>> int sum = 0;
>> int[] ints = data.ints;
>> for (int i = 0; i < data.count; i++) {
>> sum += ints[i];
>> }
>> return sum;
>> }
>>
>> @State(Scope.Benchmark)
>> public static class Data {
>> @Param({"1", "10", "100"})
>> private int count;
>> private volatile int[] ints;
>>
>> @Setup
>> public void setUp() {
>> int[] ints = new int[count];
>> for (int i = 0; i < ints.length; i++) {
>> ints[i] = ThreadLocalRandom.current().nextInt();
>> }
>> this.ints = ints;
>> }
>> }
>> }
>>
>> and this one is for reference:
>>
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Warmup(time = 2, iterations = 5)
>> @Measurement(time = 2, iterations = 5)
>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>> public class VolatileFieldInLoopBenchmark {
>>
>> @Benchmark
>> public int accessVolatileInLoop(Data data) {
>> int sum = 0;
>> for (int i = 0; i < data.count; i++) {
>> sum += data.value;
>> }
>> return sum;
>> }
>>
>> @Benchmark
>> public int hoistVolatileFromLoop(Data data) {
>> int sum = 0;
>> int value = data.value;
>> for (int i = 0; i < data.count; i++) {
>> sum += value;
>> }
>> return sum;
>> }
>>
>> @State(Scope.Benchmark)
>> public static class Data {
>> private final ThreadLocalRandom random = ThreadLocalRandom.current();
>>
>> private volatile int value = random.nextInt();
>>
>> @Param({"1", "10", "100"})
>> private int count;
>> }
>> }
>>
>> From measurement results it looks like volatile array access is cheaper than "plain" reference access:
>>
>> Java 19
>>
>> Benchmark (count) Mode Cnt Score Error Units
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 2.110 ? 0.404 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 14.836 ? 2.825 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 146.497 ? 25.786 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 3.006 ? 0.686 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 6.222 ? 1.215 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 33.262 ? 6.579 ns/op
>>
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.823 ? 0.382 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.259 ? 2.874 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 98.648 ? 18.500 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.189 ? 0.412 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.734 ? 0.891 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 7.126 ? 1.309 ns/op
>>
>> Java 20
>>
>> Benchmark (count) Mode Cnt Score Error Units
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.714 ? 0.066 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.703 ? 0.148 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 109.001 ? 1.866 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.408 ? 0.224 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.678 ? 0.060 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 24.711 ? 1.091 ns/op
>>
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.366 ? 0.105 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 7.388 ? 0.119 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 74.630 ? 1.163 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 1.653 ? 0.035 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 3.138 ? 0.040 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 4.945 ? 0.177 ns/op
>>
>> So my question is why is volatile reference access is relatively more expensive than volatile array access?

From sergei.tsypanov at yandex.ru  Wed Aug 16 14:06:05 2023
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Wed, 16 Aug 2023 16:06:05 +0200
Subject: Different costs of accessing volatile reference and array
In-Reply-To: <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
References: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
 <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
Message-ID: <624071692194765@s6wxws2fajj4foga.iva.yp-c.yandex.net>

I meant relation between in-loop and hoisted access.
 
In Java 19 when we take count = 100 for volatile array and hoist it from the loop then the average time decreases from 146 to 33 ns.
 
And if we take the same count for "plain" field and hoist it from the loop then the average time decreases from 98 to 7 ns.


> If I read the data correctly, for the count=100 case in jdk 20 it takes
> 109 ns/op for the array and 74 ns/op for the field.
> 
> To me this looks like a field access is _less_ expensive.
> 
> Am I missing something?
> 
> On 2023-08-16 13:37, ?????? ??????? wrote:
> 
>> Hello,
>>
>> I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references.
>>
>> Here's the benchmark for array:
>>
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Warmup(time = 2, iterations = 5)
>> @Measurement(time = 2, iterations = 5)
>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>> public class VolatileArrayInLoopBenchmark {
>>
>> @Benchmark
>> public int accessVolatileInLoop(Data data) {
>> int sum = 0;
>> for (int i = 0; i < data.count; i++) {
>> sum += data.ints[i];
>> }
>> return sum;
>> }
>>
>> @Benchmark
>> public int hoistVolatileFromLoop(Data data) {
>> int sum = 0;
>> int[] ints = data.ints;
>> for (int i = 0; i < data.count; i++) {
>> sum += ints[i];
>> }
>> return sum;
>> }
>>
>> @State(Scope.Benchmark)
>> public static class Data {
>> @Param({"1", "10", "100"})
>> private int count;
>> private volatile int[] ints;
>>
>> @Setup
>> public void setUp() {
>> int[] ints = new int[count];
>> for (int i = 0; i < ints.length; i++) {
>> ints[i] = ThreadLocalRandom.current().nextInt();
>> }
>> this.ints = ints;
>> }
>> }
>> }
>>
>> and this one is for reference:
>>
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Warmup(time = 2, iterations = 5)
>> @Measurement(time = 2, iterations = 5)
>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>> public class VolatileFieldInLoopBenchmark {
>>
>> @Benchmark
>> public int accessVolatileInLoop(Data data) {
>> int sum = 0;
>> for (int i = 0; i < data.count; i++) {
>> sum += data.value;
>> }
>> return sum;
>> }
>>
>> @Benchmark
>> public int hoistVolatileFromLoop(Data data) {
>> int sum = 0;
>> int value = data.value;
>> for (int i = 0; i < data.count; i++) {
>> sum += value;
>> }
>> return sum;
>> }
>>
>> @State(Scope.Benchmark)
>> public static class Data {
>> private final ThreadLocalRandom random = ThreadLocalRandom.current();
>>
>> private volatile int value = random.nextInt();
>>
>> @Param({"1", "10", "100"})
>> private int count;
>> }
>> }
>>
>> From measurement results it looks like volatile array access is cheaper than "plain" reference access:
>>
>> Java 19
>>
>> Benchmark (count) Mode Cnt Score Error Units
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 2.110 ? 0.404 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 14.836 ? 2.825 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 146.497 ? 25.786 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 3.006 ? 0.686 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 6.222 ? 1.215 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 33.262 ? 6.579 ns/op
>>
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.823 ? 0.382 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.259 ? 2.874 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 98.648 ? 18.500 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.189 ? 0.412 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.734 ? 0.891 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 7.126 ? 1.309 ns/op
>>
>> Java 20
>>
>> Benchmark (count) Mode Cnt Score Error Units
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.714 ? 0.066 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.703 ? 0.148 ns/op
>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 109.001 ? 1.866 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.408 ? 0.224 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.678 ? 0.060 ns/op
>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 24.711 ? 1.091 ns/op
>>
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.366 ? 0.105 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 7.388 ? 0.119 ns/op
>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 74.630 ? 1.163 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 1.653 ? 0.035 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 3.138 ? 0.040 ns/op
>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 4.945 ? 0.177 ns/op
>>
>> So my question is why is volatile reference access is relatively more expensive than volatile array access?

From raffaello.giulietti at oracle.com  Wed Aug 16 14:33:31 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 16 Aug 2023 16:33:31 +0200
Subject: [External] : Re: Different costs of accessing volatile reference
 and array
In-Reply-To: <624071692194765@s6wxws2fajj4foga.iva.yp-c.yandex.net>
References: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
 <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
 <624071692194765@s6wxws2fajj4foga.iva.yp-c.yandex.net>
Message-ID: <b1729187-f1ad-ee6b-1cb7-067d3f9f2907@oracle.com>

I guess that the cost for an array element access is more expensive than 
accessing a field, regardless of volatile. The offset is computed at 
runtime for an array element and might need to be checked to be in the 
range of valid indices, while the offset of a field is known and can be 
a constant in the instruction stream.

Different access costs probably prevent a direct comparison of the 
ratios non-hoisted/hoisted.

Also, you would probably have to look at the generated code.

For example, in the hoisted field case the loop for the sum could be 
replaced by a multiplication value * count.




On 2023-08-16 16:06, ?????? ??????? wrote:
> I meant relation between in-loop and hoisted access.
>   
> In Java 19 when we take count = 100 for volatile array and hoist it from the loop then the average time decreases from 146 to 33 ns.
>   
> And if we take the same count for "plain" field and hoist it from the loop then the average time decreases from 98 to 7 ns.
> 
> 
>> If I read the data correctly, for the count=100 case in jdk 20 it takes
>> 109 ns/op for the array and 74 ns/op for the field.
>>
>> To me this looks like a field access is _less_ expensive.
>>
>> Am I missing something?
>>
>> On 2023-08-16 13:37, ?????? ??????? wrote:
>>
>>> Hello,
>>>
>>> I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references.
>>>
>>> Here's the benchmark for array:
>>>
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @Warmup(time = 2, iterations = 5)
>>> @Measurement(time = 2, iterations = 5)
>>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>>> public class VolatileArrayInLoopBenchmark {
>>>
>>> @Benchmark
>>> public int accessVolatileInLoop(Data data) {
>>> int sum = 0;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += data.ints[i];
>>> }
>>> return sum;
>>> }
>>>
>>> @Benchmark
>>> public int hoistVolatileFromLoop(Data data) {
>>> int sum = 0;
>>> int[] ints = data.ints;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += ints[i];
>>> }
>>> return sum;
>>> }
>>>
>>> @State(Scope.Benchmark)
>>> public static class Data {
>>> @Param({"1", "10", "100"})
>>> private int count;
>>> private volatile int[] ints;
>>>
>>> @Setup
>>> public void setUp() {
>>> int[] ints = new int[count];
>>> for (int i = 0; i < ints.length; i++) {
>>> ints[i] = ThreadLocalRandom.current().nextInt();
>>> }
>>> this.ints = ints;
>>> }
>>> }
>>> }
>>>
>>> and this one is for reference:
>>>
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @Warmup(time = 2, iterations = 5)
>>> @Measurement(time = 2, iterations = 5)
>>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>>> public class VolatileFieldInLoopBenchmark {
>>>
>>> @Benchmark
>>> public int accessVolatileInLoop(Data data) {
>>> int sum = 0;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += data.value;
>>> }
>>> return sum;
>>> }
>>>
>>> @Benchmark
>>> public int hoistVolatileFromLoop(Data data) {
>>> int sum = 0;
>>> int value = data.value;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += value;
>>> }
>>> return sum;
>>> }
>>>
>>> @State(Scope.Benchmark)
>>> public static class Data {
>>> private final ThreadLocalRandom random = ThreadLocalRandom.current();
>>>
>>> private volatile int value = random.nextInt();
>>>
>>> @Param({"1", "10", "100"})
>>> private int count;
>>> }
>>> }
>>>
>>>  From measurement results it looks like volatile array access is cheaper than "plain" reference access:
>>>
>>> Java 19
>>>
>>> Benchmark (count) Mode Cnt Score Error Units
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 2.110 ? 0.404 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 14.836 ? 2.825 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 146.497 ? 25.786 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 3.006 ? 0.686 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 6.222 ? 1.215 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 33.262 ? 6.579 ns/op
>>>
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.823 ? 0.382 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.259 ? 2.874 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 98.648 ? 18.500 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.189 ? 0.412 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.734 ? 0.891 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 7.126 ? 1.309 ns/op
>>>
>>> Java 20
>>>
>>> Benchmark (count) Mode Cnt Score Error Units
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.714 ? 0.066 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.703 ? 0.148 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 109.001 ? 1.866 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.408 ? 0.224 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.678 ? 0.060 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 24.711 ? 1.091 ns/op
>>>
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.366 ? 0.105 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 7.388 ? 0.119 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 74.630 ? 1.163 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 1.653 ? 0.035 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 3.138 ? 0.040 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 4.945 ? 0.177 ns/op
>>>
>>> So my question is why is volatile reference access is relatively more expensive than volatile array access?

From raffaello.giulietti at oracle.com  Wed Aug 16 14:33:31 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 16 Aug 2023 16:33:31 +0200
Subject: [External] : Re: Different costs of accessing volatile reference
 and array
In-Reply-To: <624071692194765@s6wxws2fajj4foga.iva.yp-c.yandex.net>
References: <3156321692179340@2y2i6g6snfcuakol.iva.yp-c.yandex.net>
 <1c6c39d3-0889-601e-1f5f-593bed709040@oracle.com>
 <624071692194765@s6wxws2fajj4foga.iva.yp-c.yandex.net>
Message-ID: <b1729187-f1ad-ee6b-1cb7-067d3f9f2907@oracle.com>

I guess that the cost for an array element access is more expensive than 
accessing a field, regardless of volatile. The offset is computed at 
runtime for an array element and might need to be checked to be in the 
range of valid indices, while the offset of a field is known and can be 
a constant in the instruction stream.

Different access costs probably prevent a direct comparison of the 
ratios non-hoisted/hoisted.

Also, you would probably have to look at the generated code.

For example, in the hoisted field case the loop for the sum could be 
replaced by a multiplication value * count.




On 2023-08-16 16:06, ?????? ??????? wrote:
> I meant relation between in-loop and hoisted access.
>   
> In Java 19 when we take count = 100 for volatile array and hoist it from the loop then the average time decreases from 146 to 33 ns.
>   
> And if we take the same count for "plain" field and hoist it from the loop then the average time decreases from 98 to 7 ns.
> 
> 
>> If I read the data correctly, for the count=100 case in jdk 20 it takes
>> 109 ns/op for the array and 74 ns/op for the field.
>>
>> To me this looks like a field access is _less_ expensive.
>>
>> Am I missing something?
>>
>> On 2023-08-16 13:37, ?????? ??????? wrote:
>>
>>> Hello,
>>>
>>> I was measuring costs of hoisting volatile access out of the loop and found out, that there's a difference in numbers for arrays and "plain" references.
>>>
>>> Here's the benchmark for array:
>>>
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @Warmup(time = 2, iterations = 5)
>>> @Measurement(time = 2, iterations = 5)
>>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>>> public class VolatileArrayInLoopBenchmark {
>>>
>>> @Benchmark
>>> public int accessVolatileInLoop(Data data) {
>>> int sum = 0;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += data.ints[i];
>>> }
>>> return sum;
>>> }
>>>
>>> @Benchmark
>>> public int hoistVolatileFromLoop(Data data) {
>>> int sum = 0;
>>> int[] ints = data.ints;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += ints[i];
>>> }
>>> return sum;
>>> }
>>>
>>> @State(Scope.Benchmark)
>>> public static class Data {
>>> @Param({"1", "10", "100"})
>>> private int count;
>>> private volatile int[] ints;
>>>
>>> @Setup
>>> public void setUp() {
>>> int[] ints = new int[count];
>>> for (int i = 0; i < ints.length; i++) {
>>> ints[i] = ThreadLocalRandom.current().nextInt();
>>> }
>>> this.ints = ints;
>>> }
>>> }
>>> }
>>>
>>> and this one is for reference:
>>>
>>> @BenchmarkMode(Mode.AverageTime)
>>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>> @Warmup(time = 2, iterations = 5)
>>> @Measurement(time = 2, iterations = 5)
>>> @Fork(value = 4, jvmArgs = "-Xmx1g")
>>> public class VolatileFieldInLoopBenchmark {
>>>
>>> @Benchmark
>>> public int accessVolatileInLoop(Data data) {
>>> int sum = 0;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += data.value;
>>> }
>>> return sum;
>>> }
>>>
>>> @Benchmark
>>> public int hoistVolatileFromLoop(Data data) {
>>> int sum = 0;
>>> int value = data.value;
>>> for (int i = 0; i < data.count; i++) {
>>> sum += value;
>>> }
>>> return sum;
>>> }
>>>
>>> @State(Scope.Benchmark)
>>> public static class Data {
>>> private final ThreadLocalRandom random = ThreadLocalRandom.current();
>>>
>>> private volatile int value = random.nextInt();
>>>
>>> @Param({"1", "10", "100"})
>>> private int count;
>>> }
>>> }
>>>
>>>  From measurement results it looks like volatile array access is cheaper than "plain" reference access:
>>>
>>> Java 19
>>>
>>> Benchmark (count) Mode Cnt Score Error Units
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 2.110 ? 0.404 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 14.836 ? 2.825 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 146.497 ? 25.786 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 3.006 ? 0.686 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 6.222 ? 1.215 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 33.262 ? 6.579 ns/op
>>>
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.823 ? 0.382 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.259 ? 2.874 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 98.648 ? 18.500 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.189 ? 0.412 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.734 ? 0.891 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 7.126 ? 1.309 ns/op
>>>
>>> Java 20
>>>
>>> Benchmark (count) Mode Cnt Score Error Units
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.714 ? 0.066 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 10 avgt 20 10.703 ? 0.148 ns/op
>>> VolatileArrayInLoopBenchmark.accessVolatileInLoop 100 avgt 20 109.001 ? 1.866 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 2.408 ? 0.224 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 4.678 ? 0.060 ns/op
>>> VolatileArrayInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 24.711 ? 1.091 ns/op
>>>
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 1 avgt 20 1.366 ? 0.105 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 10 avgt 20 7.388 ? 0.119 ns/op
>>> VolatileFieldInLoopBenchmark.accessVolatileInLoop 100 avgt 20 74.630 ? 1.163 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 1 avgt 20 1.653 ? 0.035 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 10 avgt 20 3.138 ? 0.040 ns/op
>>> VolatileFieldInLoopBenchmark.hoistVolatileFromLoop 100 avgt 20 4.945 ? 0.177 ns/op
>>>
>>> So my question is why is volatile reference access is relatively more expensive than volatile array access?

From alanb at openjdk.org  Wed Aug 16 14:44:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 14:44:09 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <M-oW7QqMhE-bgzpfxABZH4Bq4AAEGPxX54J6k_hKqXU=.22f475cd-4e63-4e1f-887b-008f159bc878@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

I don't object to improving  exception message but please try to keep the code consistent style if you can.

I think the main question with this change is whether it's okay from a security point of view as to whether an interesting file path might leak into a stack trace served up by a HTTP server. In other words, this one probably needs security input on whether it should be opt-in with jdk.includeInExceptions security config. It's somewhat awkward here as it's the java.prefs module, a faraway (and little used) module that java.base would rather not export anything to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1680742906

From mbaesken at openjdk.org  Wed Aug 16 14:47:10 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 16 Aug 2023 14:47:10 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <NidiHGBtL-YNzCO_-wAhJOWDpfVvcg8-sNsTeYtphXg=.1bda28e5-c07d-4363-81a2-c8dc79229d15@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

Hi Alan,  I am not sure what 'interesting file path' you are referring to.  I only added an integer (errno/errcode)  and at one place fix strings shared/nonshared to the exception message.
Or do you mean something that is already present without my patch ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1680752247

From serb at openjdk.org  Wed Aug 16 14:48:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Aug 2023 14:48:14 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <lJoCjbUzKygVvbr32sITI8Tn1PX0H2lxQXvruUv6DYU=.b73e8136-475d-49ef-8dc2-1770dc87ae5d@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
 <lJoCjbUzKygVvbr32sITI8Tn1PX0H2lxQXvruUv6DYU=.b73e8136-475d-49ef-8dc2-1770dc87ae5d@github.com>
Message-ID: <duttTcOuu369rPOrCX75C-Ng7BPlsf21K09UVBo19Ig=.9515c8a4-a0d7-4764-8daa-c795a6ef9907@github.com>

On Wed, 16 Aug 2023 04:16:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleaned up spacing and added missing comma
>
> My overall point is that it will be unfortunate if users will be able to open some files on Linux/macOS/Windows using default programs but will not be able to do that using Java.

>@mrserb Have you tested your ZIP file with -Djdk.util.zip.disableZip64ExtraFieldValidation=true? That's the system property to disable the additional checking and is the "get out of jail card" for anyone running into issues. As always with changes like this, or other changes that tighten up checking, there is a risk that it will break something, hence the system property to give existing deployments a workaround to continue. In this case, the original change exposed an issue with a number of Apache projects (see the linked bugs in their issue trackers) and a bad bug in the BND tool that was fixed a few years ago. The system property is the temporary workaround until the deployment has versions of the libraries produced with updated versions of these tools, or a JDK update that tolerates a 0 block size.

I disagree for a few reasons, using that property will completely disable the appropriate patch for a fix in the CPU, and it will be possible to have/accept some malicious zip files which may trigger some unfortunate behavior. That is not what we would like to recommend doing. Validation of the negative values is much more important.
 - The bug fixed by the BND was clearly a bug when some "random" value was used as the size of the component which was unrelated to the size of the chunk not the size of the zip file.
 - The bug we discussed here related to the size of the block which is properly set, for some reason an additional validation was added for it, and it is still not mentioned from where that validation has come, there is no such thing in the spec nor in the behavior of the common tools such as zip/unzip, Windows Explorer, macOS Archive Utility.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1680754080

From alanb at openjdk.org  Wed Aug 16 14:54:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 14:54:21 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <NidiHGBtL-YNzCO_-wAhJOWDpfVvcg8-sNsTeYtphXg=.1bda28e5-c07d-4363-81a2-c8dc79229d15@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <NidiHGBtL-YNzCO_-wAhJOWDpfVvcg8-sNsTeYtphXg=.1bda28e5-c07d-4363-81a2-c8dc79229d15@github.com>
Message-ID: <6KYNYgBO088rkC3oNj9tjwBnK-7oUyVhcDHtxC4azMc=.2509248a-c318-4f07-9e48-e901a6a29b18@github.com>

On Wed, 16 Aug 2023 14:44:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, I am not sure what 'interesting file path' you are referring to. I only added an integer (errno/errcode) and at one place fix strings shared/nonshared to the exception message.

Oh I see, I thought you wanted to include the file lock on Unix, which would have issues. The error code might be okay, just very different to other places.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1680764222

From alanb at openjdk.org  Wed Aug 16 15:40:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Aug 2023 15:40:11 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <duttTcOuu369rPOrCX75C-Ng7BPlsf21K09UVBo19Ig=.9515c8a4-a0d7-4764-8daa-c795a6ef9907@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
 <lJoCjbUzKygVvbr32sITI8Tn1PX0H2lxQXvruUv6DYU=.b73e8136-475d-49ef-8dc2-1770dc87ae5d@github.com>
 <duttTcOuu369rPOrCX75C-Ng7BPlsf21K09UVBo19Ig=.9515c8a4-a0d7-4764-8daa-c795a6ef9907@github.com>
Message-ID: <QTqNnOS3d_34WLR_dnJn5IHhqkO8Krktqn39CI8Ma7s=.f29c6a0a-657e-4964-9df8-82663c216246@github.com>

On Wed, 16 Aug 2023 14:45:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I disagree for a few reasons, using that property will completely disable the appropriate patch for a fix in the CPU, and it will be possible to have/accept some malicious zip files which may trigger some unfortunate behavior. That is not what we would like to recommend doing. Validation of the negative values is much more important.

Changes that introduce new checks or dial up validation are often risky changes. The JDK has a long history of introducing such changes with a system property or some means to temporarily disable the stricter checking, at least when the spec allows it. You may disagree with this long standing practice but it is a necessary evil to give a temporary workaround for environments that might need a bit of time to fix something after a JDK upgrade. There is of course risk in that but I don't think we can get into that discussion here.

As I think has already been said, we can't engage with you in this PR on the reasons why additional checking was added in a security update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1680842611

From lancea at openjdk.org  Wed Aug 16 15:45:25 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 16 Aug 2023 15:45:25 GMT
Subject: Integrated: 8313765: Invalid CEN header (invalid zip64 extra data
 field size)
In-Reply-To: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
Message-ID: <Rhh-ZH1OCY5Imzcegqf3beDVQci568hZtFm-18gRd7E=.bf49cbe9-7d05-4898-8270-3b54344bd72b@github.com>

On Mon, 14 Aug 2023 14:52:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> This PR  updates the extra field validation added as part of [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483)  to deal with issues seen with 3rd party tools/libraries where a ZipException may be encountered when opening select APK, ZIP or JAR files.  Please see refer to the links provided at the end the description for the more information ::
> 
>> ZipException: Invalid CEN header (invalid zip64 extra data field size)
> 
> 1. Extra field includes padding :
> 
> 
> ----------------#1--------------------
> [Central Directory Header]
>   0x3374: Signature    : 0x02014b50
>   0x3378: Created Zip Spec :    0xa [1.0]
>   0x3379: Created OS   :    0x0 [MS-DOS]
>   0x337a: VerMadeby    :    0xa [0, 1.0]
>   0x337b: VerExtract   :    0xa [1.0]
>   0x337c: Flag      :   0x800
>   0x337e: Method     :    0x0 [STORED]
>   0x3380: Last Mod Time  : 0x385ca437 [Thu Feb 28 20:33:46 EST 2008]
>   0x3384: CRC       : 0x694c6952
>   0x3388: Compressed Size :   0x624
>   0x338c: Uncompressed Size:   0x624
>   0x3390: Name Length   :   0x1b
>  0x3392: Extra Length  :    0x7
> 		[tag=0xcafe, sz=0, data= ]
> 				->[tag=cafe, size=0]
>   0x3394: Comment Length :    0x0
>   0x3396: Disk Start   :    0x0
>   0x3398: Attrs      :    0x0
>   0x339a: AttrsEx     :    0x0
>   0x339e: Loc Header Offset:    0x0
>   0x33a2: File Name    : res/drawable/size_48x48.jpg
> 
> 
> The extra field tag of `0xcafe` has its data size set to `0`.  and the extra length is `7`.   It is expected that you can use the  tag's data size to traverse the extra fields.
> 
> 
> 2. The [BND tool](https://github.com/bndtools/bnd) added [problematic data to the extra field](https://issues.apache.org/jira/browse/FELIX-6622):
> 
> 
> ----------------#359--------------------
> [Central Directory Header]
>    0x600b4: Signature        : 0x02014b50
>    0x600b8: Created Zip Spec :       0x14 [2.0]
>    0x600b9: Created OS       :        0x0 [MS-DOS]
>    0x600ba: VerMadeby        :       0x14 [0, 2.0]
>    0x600bb: VerExtract       :       0x14 [2.0]
>    0x600bc: Flag             :      0x808
>    0x600be: Method           :        0x8 [DEFLATED]
>    0x600c0: Last Mod Time    : 0x2e418983 [Sat Feb 01 17:12:06 EST 2003]
>    0x600c4: CRC              : 0xd8f689cb
>    0x600c8: Compressed Size  :      0x23e
>    0x600cc: Uncompressed Size:      0x392
>    0x600d0: Name Length      :       0x20
>    0x600d2: Extra Length     :        0x8
> 		[tag=0xbfef, sz=61373, data=        
>   0x600d4: Comment Length   :        0x0
>    0x600d6: Disk Start       :        0x0
>    0x600d8: Attrs            :        0x0
>    0x600da: ...

This pull request has now been integrated.

Changeset: 13f6450e
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13f6450e2e70df4df8bd882def837fbd5bef1524
Stats:     1004 lines in 4 files changed: 986 ins; 4 del; 14 mod

8313765: Invalid CEN header (invalid zip64 extra data field size)

Reviewed-by: simonis, alanb, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/15273

From duke at openjdk.org  Wed Aug 16 15:52:28 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Wed, 16 Aug 2023 15:52:28 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v2]
In-Reply-To: <Oeu-4uabxvLr7cQlsRjxJQG7vKChc4mKz8dq0NNErlk=.5560a629-4734-415c-802f-27ff518ed10b@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <41l60dbMJhFRHO7PGqAkkEEXL911zJsPcEFl6SgiM3o=.ea2a7528-17c1-42ef-a28f-56e6d87a4b48@github.com>
 <XhOturKrMWqiMkQj2dKoFWZ1X0s8qmg0KHtKobVnhcE=.2e9bdb70-5e4b-49a4-b87d-f759be0c4223@github.com>
 <LAdxqNAaxtraDHSs2V0bhK2ScO8XgvHBX1Bgp36bOms=.be319357-0d4d-45e5-8431-ba2a973739ed@github.com>
 <7JehWv6SeJmo_06epcO8t3hWRrRlfWUDRhubjOqERqA=.70420e94-fb5d-4b2b-943d-4f19922d9899@github.com>
 <4elD_x3ZX81525PUarpyPMLcc6W9lZlTT0bKHiXBQlw=.7189caca-5f04-45f8-910e-82d35220c1b4@github.com>
 <Oeu-4uabxvLr7cQlsRjxJQG7vKChc4mKz8dq0NNErlk=.5560a629-4734-415c-802f-27ff518ed10b@github.com>
Message-ID: <7EFvQ_qV7_h8TDokSiSgIssWbtSZWz1oOQ_YjLxyVYk=.96a9a291-5826-4c0c-b251-bb74cf3f0731@github.com>

On Tue, 15 Aug 2023 15:39:37 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I think I agree with Volker that it would be better if isZip64ExtBlockSizeValid continued to return false for block size 0.
>
> OK, I have made the suggest change that you both prefer.
> 
> Thank you for your input

I'm also happy to see `isZip64ExtBlockSizeValid` rejecting 0. This logic could be useful when implementing support for valid Zip64 fields for small entries in ZipInputStream, like #12524 attempted to do.  (The PR was closed by the bots in the end). 

I guess this method could be moved to ZipUtils if JDK-8303866 is ever implemented.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15273#discussion_r1296113648

From bpb at openjdk.org  Wed Aug 16 15:54:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 16 Aug 2023 15:54:09 GMT
Subject: RFR: 8314321: Remove unused field
 jdk.internal.util.xml.impl.Attrs.mAttrIdx
In-Reply-To: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
References: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
Message-ID: <iT79LoEuxdTit-b1CBeUh8FUGo4UvRLivdCPscnbHDg=.d0cb9f28-3bae-421a-8744-d97dd21e554e@github.com>

On Tue, 15 Aug 2023 20:13:18 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A field `char mAttrIdx` in the `jdk.internal.util.xml.impl.Attrs` class is unused and can be removed.

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15298#pullrequestreview-1580942072

From psandoz at openjdk.org  Wed Aug 16 15:58:07 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Aug 2023 15:58:07 GMT
Subject: RFR: 8314280: StructuredTaskScope.shutdown should document that
 the state of completing subtasks is not defined
In-Reply-To: <LeoqedNfFK6IIupqWVYC3SXlVC45GaiN36zP4E_8B-k=.50ac351b-bbcf-4905-b97a-baeb5f9fa317@github.com>
References: <LeoqedNfFK6IIupqWVYC3SXlVC45GaiN36zP4E_8B-k=.50ac351b-bbcf-4905-b97a-baeb5f9fa317@github.com>
Message-ID: <o9YKoTkZxr4XdS_n5d1kb1w7sXaiYi0BBsOtjQ7sSI8=.c4010058-e101-4fb1-8a51-5ebcd2cf5994@github.com>

On Tue, 15 Aug 2023 16:21:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a docs only change. The specification for StructuredTaskScope.shutdown should make it clear that the state of subtasks that are completing (with a result or exception) at around the time of shutdown is not defined. The state of a completing subtask may transition to a terminal state, it may not, as it is racing with the shutdown.

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15293#pullrequestreview-1580950038

From psandoz at openjdk.org  Wed Aug 16 16:19:06 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 16 Aug 2023 16:19:06 GMT
Subject: RFR: 8313290: Misleading exception message from STS.Subtask::get
 when task forked after shutdown
In-Reply-To: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
References: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
Message-ID: <z-3TaZciA4WWzfx2yFiv7wEz_8hiTnO6kNEQryPiTGU=.0883d54f-74b6-4d03-9704-0c81829dd7be@github.com>

On Fri, 28 Jul 2023 20:33:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a small issue with StructuredTaskScope. If the owner attempts to fork a subtask and the task scope is shutdown then the implementation doesn't currently force the owner to join when it's the first fork in a new round of forking. The result is that broken code calling Subtask::get throws ISE with the wrong exception message.
> 
> The existing test for this API is updated to remove a duplicate test and also fix two tasks that didn't call join.

Very minor suggestion, up to you. We could change the exception message thrown by `SubtaskImpl::get` to:

> Subtask result is unavailable or did not complete successfully

(Similar change for `SubtaskImpl::exception`.)
That leans into the terminology more.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15076#pullrequestreview-1580992012

From duke at openjdk.org  Wed Aug 16 16:37:11 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 16 Aug 2023 16:37:11 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
Message-ID: <jvAsRly2wVraXzyVSLNxGjo6kU8ufm3_thqsNSF95rw=.263b32a3-bb35-4fa1-b396-bbf9ea607a9a@github.com>

On Tue, 15 Aug 2023 10:48:29 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
>  - Revert StreamTokenizer.java
>  - Update DateTimeFormatterBuilder
>  - Avoid locale-sensitive case conversions in java.base

Can someone review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1680928752

From duke at openjdk.org  Wed Aug 16 16:38:21 2023
From: duke at openjdk.org (Christoph)
Date: Wed, 16 Aug 2023 16:38:21 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v7]
In-Reply-To: <8UxLRpATLE95LueJ6bjK5OOjr-ldLJ_om-WyoOkv5JA=.13d6650f-f74e-4973-aa94-bb97a5c17871@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <KG43OpUZa_mFeJtOmRdLcElR_ffsL98CeTvpBVeREgQ=.67fc498c-9fa5-4c07-998e-18d35c81e43d@github.com>
 <8UxLRpATLE95LueJ6bjK5OOjr-ldLJ_om-WyoOkv5JA=.13d6650f-f74e-4973-aa94-bb97a5c17871@github.com>
Message-ID: <XGOZxqMRZ4aOntWv50-E4QL4a10SPPUx7phSP0Pwfus=.1b9f347c-42c8-44cb-a64d-e4554cc3a158@github.com>

On Tue, 15 Aug 2023 20:41:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Christoph has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove obsolete jimage and decompile methods
>
> Marked as reviewed by mchung (Reviewer).

@mlchung Thanks again for your help. What would be needed to get the at https://github.com/openjdk/jdk/commit/ec7da91bd83803b7d91a4de3a01caf0ba256c037 back ported to JDK21? I guess for the initial release it's too late but maybe for one of the jdk21u releases? That would be really a huge step forward for us at JabRef. (Currently we rely on a custom build)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15234#issuecomment-1680929166

From serb at openjdk.org  Wed Aug 16 17:19:21 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 16 Aug 2023 17:19:21 GMT
Subject: RFR: 8313765: Invalid CEN header (invalid zip64 extra data field
 size) [v9]
In-Reply-To: <QTqNnOS3d_34WLR_dnJn5IHhqkO8Krktqn39CI8Ma7s=.f29c6a0a-657e-4964-9df8-82663c216246@github.com>
References: <7fmhwSwi-tHGXUChSAoQEomMNnY3UJy84RyKxDZYrOQ=.339958c5-6c27-408b-853c-98ab678becbf@github.com>
 <RPoh2C8IQted6lAHGSSXMLE286yWNwENkubY8yqDB9k=.1418a01d-b2e9-41b8-9c0f-123a4a248496@github.com>
 <lJoCjbUzKygVvbr32sITI8Tn1PX0H2lxQXvruUv6DYU=.b73e8136-475d-49ef-8dc2-1770dc87ae5d@github.com>
 <duttTcOuu369rPOrCX75C-Ng7BPlsf21K09UVBo19Ig=.9515c8a4-a0d7-4764-8daa-c795a6ef9907@github.com>
 <QTqNnOS3d_34WLR_dnJn5IHhqkO8Krktqn39CI8Ma7s=.f29c6a0a-657e-4964-9df8-82663c216246@github.com>
Message-ID: <JFx1KtQtG0Q4t8yJeMpXMqJY2SAR7ZQeGEoeu93KExE=.af9c91e4-17ff-4acd-8500-3dd4e273efbb@github.com>

On Wed, 16 Aug 2023 15:36:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>As I think has already been said, we can't engage with you in this PR on the reasons why additional checking was added in a security update.

I think you have an assumption that this check for exact size(8/16/24) bytes are related to the change fixed by the security update, I am pretty sure that's the wrong assumption.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1680987371

From naoto at openjdk.org  Wed Aug 16 17:20:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 16 Aug 2023 17:20:11 GMT
Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in
 java.base [v3]
In-Reply-To: <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <k3byHD2GiJRdwDSHe5mh4sRYq5enoc2QjSA7y4aPuAc=.347ba1cf-04b1-437d-9b5b-1ba93cf01310@github.com>
Message-ID: <wQ4x9r4AcBEtbfKQaDxJULNtVaveGaYeVpm4S4nw3VA=.47707fbf-7814-4fde-bb87-838b4c15442a@github.com>

On Tue, 15 Aug 2023 10:48:29 GMT, Glavo <duke at openjdk.org> wrote:

>> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.
>
> Glavo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge remote-tracking branch 'origin/master' into case-conversion-java-base
>  - Revert StreamTokenizer.java
>  - Update DateTimeFormatterBuilder
>  - Avoid locale-sensitive case conversions in java.base

LGTM. Thanks for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14763#pullrequestreview-1581093609

From duke at openjdk.org  Wed Aug 16 17:40:15 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 16 Aug 2023 17:40:15 GMT
Subject: Integrated: 8311943: Cleanup usages of toLowerCase() and toUpperCase()
 in java.base
In-Reply-To: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <Q0AnhgkR0kliEpGrfWEeGi0qnr7-pmRd743_VPnS7H0=.dff23974-4a71-43af-bd6a-5228562b24ca@github.com>

On Mon, 3 Jul 2023 20:53:34 GMT, Glavo <duke at openjdk.org> wrote:

> Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base.

This pull request has now been integrated.

Changeset: b32d6411
Author:    Glavo <zjx001202 at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b32d6411c406608ba5f7d60bfb8d935adb876564
Stats:     44 lines in 11 files changed: 6 ins; 0 del; 38 mod

8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14763

From lmesnik at openjdk.org  Wed Aug 16 17:54:55 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Aug 2023 17:54:55 GMT
Subject: RFR: 8314330: java/foreign tests should respect vm flags when
 start new processes [v2]
In-Reply-To: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>
References: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>
Message-ID: <Mvg19qdE5xPxhypwRpDRRR4J3KSy7z9CHij2c5cAilk=.a62a15fb-5332-4979-8aa8-c5e05bb502c5@github.com>

> The test helper which spawn new jvms is updated to start them using VM flags for testing.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed imports.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15302/files
  - new: https://git.openjdk.org/jdk/pull/15302/files/27f5eb83..23184fc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15302&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15302&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15302/head:pull/15302

PR: https://git.openjdk.org/jdk/pull/15302

From lmesnik at openjdk.org  Wed Aug 16 17:54:57 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Aug 2023 17:54:57 GMT
Subject: Integrated: 8314330: java/foreign tests should respect vm flags when
 start new processes
In-Reply-To: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>
References: <kzhhm5KgJuP47k4gSWMVw3bLKhGQWRJqRsZlF3h3Bdg=.e74666dc-8e2f-42b2-9495-7fed4ef9b5bf@github.com>
Message-ID: <aVbb5ayXicw-He270FYYXpjvUUp_kze2c8jZRc2gZnM=.1a6fdd12-fec0-4568-bc5f-86df4f4b5e84@github.com>

On Wed, 16 Aug 2023 00:14:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test helper which spawn new jvms is updated to start them using VM flags for testing.

This pull request has now been integrated.

Changeset: 7b28d360
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b28d3608a10b26af376c8f6d142d97c708c9f11
Stats:     11 lines in 1 file changed: 0 ins; 8 del; 3 mod

8314330: java/foreign tests should respect vm flags when start new processes

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/15302

From aefimov at openjdk.org  Wed Aug 16 18:15:17 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 16 Aug 2023 18:15:17 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <U3BKpPGTLgqLAC8j3n-E9uM3B-6WQT1nB801uO3qtNY=.8b9d0f2a-9a8b-4e76-a349-ad3097d29c47@github.com>

On Tue, 15 Aug 2023 17:30:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Hello Weibing,
The approach taken here seems resonable to me. Please find my comments on the fix and the test below:

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 284:

> 282: 
> 283:         Socket socket = null;
> 284:         try {

This method is hard to read. Readability could be improved by adding/splitting it into two new methods:
 - one for creating a socket with a use of specified socket factory
 - another one for creating a socket with `new Socket`

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 369:

> 367:                 }
> 368:             }
> 369:         } catch (Exception e) {

The code wrapped in this try-catch block can throw unchecked exceptions, for example `SecurityException` thrown by `Socket.connect`. For such cases the newly created socket remain open.

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 372:

> 370:             // 8314063 the socket is not closed after the failure of handshake
> 371:             if (socket != null && !socket.isClosed()) {
> 372:                 socket.close();

The original exception can be lost if `socket.close()` fails with `IOException` here

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 64:

> 62:         setKeyStore();
> 63:         // start the test server first.
> 64:         TestServer server = new TestServer();

Since the `TestServer` implements `AutoClosable`, can we take advantage of that and of try-with-resources to close the server socket. One possibility is to move test server, url and environment table creation into try-catch block, and convert it to try-with-resources (`TestServer`).

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 66:

> 64:         TestServer server = new TestServer();
> 65:         server.start();
> 66:         url = "ldaps://localhost:" + server.getPortNumber();

The `URIBuilder` utility class from a test library  can be used to construct a test server url here:

URI uri = URIBuilder.newBuilder()
.scheme("ldaps")
.loopback()
.port(server.getPortNumber())
.build();

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 78:

> 76:         try {
> 77:             LdapContext ctx = new InitialLdapContext(env, null);
> 78:             ctx.close();

The context can be closed in finally block

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 151:

> 149:         private volatile boolean exceptionThrown;
> 150: 
> 151:         TestServer() throws IOException {

`IOException` is not thrown by this constructor - can be removed

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 154:

> 152:             try {
> 153:                 SSLServerSocketFactory socketFactory = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
> 154:                 serverSocket = socketFactory.createServerSocket(0);

The test server can be bound to the loopback address here and `URIBuilder` test library class can be used to construct the `URL` as mentioned above:
`socketFactory.createServerSocket(0, 0, InetAddress.getLoopbackAddress());`

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 166:

> 164:         }
> 165: 
> 166:         public boolean isExceptionThrown() {

`isExceptionThrown` method is not used by the test

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 172:

> 170:         @Override
> 171:         public void run() {
> 172:             try (Socket socket = serverSocket.accept()) {

Can be beautified a bit by putting socket, IS and OS into one try-with-resources statement. Something like:

            try (Socket socket = serverSocket.accept();
                 InputStream in = socket.getInputStream();
                 OutputStream out = socket.getOutputStream()) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/15294#pullrequestreview-1581104126
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296223224
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296269582
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296224057
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296226004
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296228008
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296229176
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296230459
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296232557
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296235296
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296236949

From jvernee at openjdk.org  Wed Aug 16 18:18:46 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 16 Aug 2023 18:18:46 GMT
Subject: RFR: 8312522: Implementation of Foreign Function & Memory API [v5]
In-Reply-To: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
References: <g8z3qUFbvagEFeS4Ady229FndhwEGKIivngu4c3RwMo=.4492929f-1ba2-4b48-b6b3-2f3b7f56a382@github.com>
Message-ID: <y6W2v5wutXNrteQlYovNeBQM7d8nQf_P0ooQ-cFK7_I=.a5d5cdd6-7780-4795-8562-260e19cc69f2@github.com>

> This patch contains the implementation of the foreign linker & memory API JEP for Java 22. The initial patch is composed of commits brought over directly from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). The main changes found in this patch come from the following PRs:
> 
> 1. https://github.com/openjdk/panama-foreign/pull/836 Where previous iterations supported converting Java strings to and from native strings in the UTF-8 encoding, we've extended the supported encoding to all the encodings found in the `java.nio.charset.StandardCharsets` class.
> 2. https://github.com/openjdk/panama-foreign/pull/838 We dropped the `MemoryLayout::sequenceLayout` factory method which inferred the size of the sequence to be `Long.MAX_VALUE`, as this led to confusion among clients. A client is now required to explicitly specify the sequence size.
> 3. https://github.com/openjdk/panama-foreign/pull/839 A new API was added: `Linker::canonicalLayouts`, which exposes a map containing the platform-specific mappings of common C type names to memory layouts.
> 4. https://github.com/openjdk/panama-foreign/pull/840 Memory access varhandles, as well as byte offset and slice handles derived from memory layouts, now feature an additional 'base offset' coordinate that is added to the offset computed by the handle. This allows composing these handles with other offset computation strategies that may not be based on the same memory layout. This addresses use-cases where clients are working with 'dynamic' layouts, whose size might not be known statically, such as variable length arrays, or variable size matrices.
> 5. https://github.com/openjdk/panama-foreign/pull/841 Remove this now redundant API. Clients can simply use the difference between the base address of two memory segments.
> 6. https://github.com/openjdk/panama-foreign/pull/845 Disambiguate uses of `SegmentAllocator::allocateArray`, by renaming methods that both allocate + initialize memory segments to `allocateFrom`. (see the original PR for the problematic case)
> 7. https://github.com/openjdk/panama-foreign/pull/846 Improve the documentation for variadic functions.
> 8. https://github.com/openjdk/panama-foreign/pull/849 Several test fixes to make sure the `jdk_foreign` tests can pass on 32-bit machines, taking linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API required. The `Linker::nativeLinker` method is not longer allowed to throw an `UnsupportedOperationException` on ...

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into JEP22
 - remove spurious imports
 - enable fallback linker on linux x86 in GHA
 - make Arena::allocate abstract
 - 8313894: Rename isTrivial linker option to critical
   
   Reviewed-by: pminborg, mcimadamore
 - 8313680: Disallow combining caputreCallState with isTrivial
   
   Reviewed-by: mcimadamore
 - Merge branch 'master' into JEP22
 - use immutable map for fallback linker canonical layouts
 - 8313265: Move the FFM API out of preview
   
   Reviewed-by: mcimadamore
 - 8313005: Ensure native access check can fold away
   
   Reviewed-by: mcimadamore
 - ... and 11 more: https://git.openjdk.org/jdk/compare/6b396da2...5352dc0f

-------------

Changes: https://git.openjdk.org/jdk/pull/15103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15103&range=04
  Stats: 2834 lines in 232 files changed: 1245 ins; 901 del; 688 mod
  Patch: https://git.openjdk.org/jdk/pull/15103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15103/head:pull/15103

PR: https://git.openjdk.org/jdk/pull/15103

From mchung at openjdk.org  Wed Aug 16 18:34:23 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 16 Aug 2023 18:34:23 GMT
Subject: RFR: 8311591: Add SystemModulesPlugin test case that splits module
 descriptors with new local variables defined by DedupSetBuilder [v9]
In-Reply-To: <fKJRdOb31Bew20AGubIdJdDqC0YYqOFV1Y2Vh5UE2T0=.f5f6270a-f075-48a2-a8ad-cab26c7e5024@github.com>
References: <BulG-w-umZtqROujKTnSmnsznbmGILfgmTNVTE6pJ5o=.8c79a502-ebfa-45e7-8cb4-79106db48c54@github.com>
 <fKJRdOb31Bew20AGubIdJdDqC0YYqOFV1Y2Vh5UE2T0=.f5f6270a-f075-48a2-a8ad-cab26c7e5024@github.com>
Message-ID: <NwJf6OLUe-G8OQswsiyGCLWJNKK4FJ8zaVaS1fn7THM=.838b802d-ed6c-4dc5-a085-3cc04f946eb5@github.com>

On Tue, 15 Aug 2023 20:56:43 GMT, Christoph <duke at openjdk.org> wrote:

>> Add new test case with sample modules that contains some requires/exports/uses/provides.
>> 
>> We are just unsure if and how we should add some last step of verificaiton with the extracted and decompiled class.
>> 
>> Follow up task from https://github.com/openjdk/jdk/pull/14408
>
> Christoph has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update full name

I created the backport PRs for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567) and [JDK-8311591](https://bugs.openjdk.org/browse/JDK-8311591).

https://github.com/openjdk/jdk21u/pull/65
https://github.com/openjdk/jdk21u/pull/66

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15234#issuecomment-1681091848

From rriggs at openjdk.org  Wed Aug 16 18:36:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Aug 2023 18:36:06 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
Message-ID: <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>

On Thu, 10 Aug 2023 09:54:43 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible.

test/jdk/java/lang/ProcessHandle/InfoTest.java line 304:

> 302:                     if (Platform.isWindows() && "BUILTIN\\Administrators".equals(whoami)) {
> 303:                         System.out.println("Test seems to be run as Administrator. " +
> 304:                                 "Check for user correctness is not possible.");

Is there an alternative way to determine the expected username? 
Perhaps by running a windows command or extracting it from the environment (System.getEnv("XX"))?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1296289845

From rriggs at openjdk.org  Wed Aug 16 18:47:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Aug 2023 18:47:08 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v7]
In-Reply-To: <31xjj3_jPZWzrPuhU7DgeQglMiluV2MSKlP4h2DUfNE=.e626cc53-3fde-4f3a-92fe-23f1421ecd2d@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <31xjj3_jPZWzrPuhU7DgeQglMiluV2MSKlP4h2DUfNE=.e626cc53-3fde-4f3a-92fe-23f1421ecd2d@github.com>
Message-ID: <OzvI6XdhEv5AJg9m2iSsLMrJCu94zEKtABLfbiLG-_o=.f31bd421-4e0c-4b41-8c95-3d35caf75375@github.com>

On Wed, 16 Aug 2023 09:11:34 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat 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 seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8311939
>  - Merge branch 'openjdk:master' into JDK-8311939
>  - review condition
>  - changes and test for CIBackRef
>  - remove new line
>  - reduce allocations also for Matcher.usePattern
>  - 8311939: Excessive allocation of Matcher.groups array

LGTM

Looks good.
Non-"R"-reviewers can review and approve (and get recognition for reviewing).

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14894#pullrequestreview-1581222155
PR Comment: https://git.openjdk.org/jdk/pull/14894#issuecomment-1681106661

From mchung at openjdk.org  Wed Aug 16 18:49:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 16 Aug 2023 18:49:28 GMT
Subject: RFR: 8310815: Clarify the name of the main class,
 services and provider classes in module descriptor
Message-ID: <sFl8a99xmRocPxZCyqP1bF4wy2chKMbimkWrrzycJmw=.ac327770-7242-4b9d-9c4c-9e0d805b7a4b@github.com>

Clarify the spec of `ModuleDescriptor::mainClass`, `ModuleDescriptor::uses`, `ModuleDescriptor.Provides::service` and `ModuleDescriptor.Provides::providers` to return a binary name. 

This PR also fixes JDK-8314449 to update the spec of `StackTraceElement::getClassName` and the `declaringClass` parameter of the constructor.

-------------

Commit messages:
 - 8314449: Clarify the name of the declaring class of StackTraceElement
 - 8310815: Clarify the name of the main class, services and provider classes in module descriptor

Changes: https://git.openjdk.org/jdk/pull/15317/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8310815
  Stats: 25 lines in 2 files changed: 3 ins; 4 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15317/head:pull/15317

PR: https://git.openjdk.org/jdk/pull/15317

From rriggs at openjdk.org  Wed Aug 16 19:06:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 16 Aug 2023 19:06:07 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <FlrRm94KmjHEavB26YVcGVRzhT8920ftdHCJXWX5plY=.4e56fa80-eb5e-4dc4-a366-b37d26508bd8@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 773:

> 771:                String sharingMode = "shared";
> 772:                if (!shared) sharingMode = "nonshared";
> 773:                throw(new BackingStoreException("Couldn't get file lock. errno is " + errCode + " mode is " + sharingMode));

A raw errno is pretty uninformative, except for experts. Can the errno be translated to a string as well as supplying the errno?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1296318043

From duke at openjdk.org  Wed Aug 16 19:12:54 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 16 Aug 2023 19:12:54 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v2]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <F9wKdhFD8av9i0W8xQHUNyfM6j0iCOKJRWsV5csvMsY=.01602f00-63ee-46e8-975c-936a175a85a3@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the test code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/e5d981ea..5e83e6ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From mdonovan at openjdk.org  Wed Aug 16 19:13:09 2023
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 16 Aug 2023 19:13:09 GMT
Subject: RFR: 8303525: Refactor/cleanup
 open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
In-Reply-To: <By-JilEJV4FYBvjxQ15aJnjQpzsuAaBsnk7rVnwZfaY=.dffb004a-5159-4b54-aef1-98dc9b9ce0cf@github.com>
References: <By-JilEJV4FYBvjxQ15aJnjQpzsuAaBsnk7rVnwZfaY=.dffb004a-5159-4b54-aef1-98dc9b9ce0cf@github.com>
Message-ID: <i7sbUdYBYSCxB5oVwJADMi5oEtddKFwySQM2UjumMCw=.79a654d1-8d4d-4810-aede-0b8000166469@github.com>

On Wed, 19 Jul 2023 12:03:40 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR refactors the SSLSocketParametersTest by removing redundant/unnecessary classes and cleans up the logic around expected exceptions.

I'm still looking for a reviewer for this PR. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14932#issuecomment-1681138364

From igraves at openjdk.org  Wed Aug 16 20:09:12 2023
From: igraves at openjdk.org (Ian Graves)
Date: Wed, 16 Aug 2023 20:09:12 GMT
Subject: RFR: 8311939: Excessive allocation of Matcher.groups array [v7]
In-Reply-To: <31xjj3_jPZWzrPuhU7DgeQglMiluV2MSKlP4h2DUfNE=.e626cc53-3fde-4f3a-92fe-23f1421ecd2d@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
 <31xjj3_jPZWzrPuhU7DgeQglMiluV2MSKlP4h2DUfNE=.e626cc53-3fde-4f3a-92fe-23f1421ecd2d@github.com>
Message-ID: <UdWvOAS0q_McOg3ThsqTKPkLtHZlNWngg4LyK95mlto=.021038c4-6213-452d-8b10-0890dcf0bef9@github.com>

On Wed, 16 Aug 2023 09:11:34 GMT, Cristian Vat <duke at openjdk.org> wrote:

>> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
>> 
>> Original clamping to 10 possibly due to documented behavior from javadoc: 
>> "In this class, \1 through \9 are always interpreted as back references, "
>> 
>> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
>> Added a match failure condition in Pattern that fixes failing tests.
>> 
>> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
>> 
>> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
>> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
>> So a group index outside groups array length must never match.
>
> Cristian Vat 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 seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8311939
>  - Merge branch 'openjdk:master' into JDK-8311939
>  - review condition
>  - changes and test for CIBackRef
>  - remove new line
>  - reduce allocations also for Matcher.usePattern
>  - 8311939: Excessive allocation of Matcher.groups array

Marked as reviewed by igraves (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14894#pullrequestreview-1581336661

From smarks at openjdk.org  Wed Aug 16 21:40:42 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 16 Aug 2023 21:40:42 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v2]
In-Reply-To: <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>
 <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>
Message-ID: <fQnqt8E12cTShqzhOIZAwvvKjv1fiQeCBZfhHUNEv3Q=.c59f5048-9872-4e8c-a4b9-39cfe87d0db3@github.com>

On Tue, 15 Aug 2023 09:51:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8314236: change bug number and summary
>
> test/jdk/java/util/Collections/RotateHuge.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8314236
>> 27:  * @summary Overflow in Collections.rotate
> 
> Since this test takes >4G of heap to hold the list with compressed oops, and >8G of heap without compressed oops, we need to run it in a separate VM with enough headroom, something like this:
> 
> 
>  * @test
>  * @bug 8314236
>  * @summary Overflow in Collections.rotate
>  * @requires (sun.arch.data.model == "64" & os.maxMemory >= 16g)
>  * @run main/othervm -Xmx12g RotateHuge

@nikita-sakharin

Thanks for finding this bug and offering to fix it! (And @shipilev thanks for your assistance on this.)

Putting the test into a separate JVM will work, but I don't think it's necessary to actually allocate the space. The test is only testing the indexes sent to `get` and `set` on the list, and it doesn't actually verify the contents of the list. (Presumably that's done by other tests.) Therefore it should be possible to create a "virtual" list of a given size that checks that the indexes are all in bounds but that doesn't actually store any elements. It should be fairly straightforward to do this by subclassing AbstractList and overriding a few methods.

The advantage of not actually allocating 4G of memory is that it makes it easier to run a bunch of cases that test the boundary conditions. In fact I'd like to see that in the test, as opposed to testing this one case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1296455894

From msheppar at openjdk.org  Wed Aug 16 22:52:45 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 22:52:45 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v2]
In-Reply-To: <F9wKdhFD8av9i0W8xQHUNyfM6j0iCOKJRWsV5csvMsY=.01602f00-63ee-46e8-975c-936a175a85a3@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <F9wKdhFD8av9i0W8xQHUNyfM6j0iCOKJRWsV5csvMsY=.01602f00-63ee-46e8-975c-936a175a85a3@github.com>
Message-ID: <G-no1mb7QkxWZa6wqLsriEwT0qxP8lk1L68OVhVbXyY=.2352e031-ad64-4483-b85e-a9d2023e39d8@github.com>

On Wed, 16 Aug 2023 19:12:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the test code

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 173:

> 171:         public void run() {
> 172:             try (Socket socket = serverSocket.accept()) {
> 173:                 Thread.sleep(10000);

What's the purpose of the sleep ? 
Regardless, based on the test semantics alluded in the test name, the server should never enter the read block. So is this code redundant? Or is it there just in case the accept and the handshake succeeds?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296511511

From msheppar at openjdk.org  Wed Aug 16 23:00:27 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 23:00:27 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v2]
In-Reply-To: <U3BKpPGTLgqLAC8j3n-E9uM3B-6WQT1nB801uO3qtNY=.8b9d0f2a-9a8b-4e76-a349-ad3097d29c47@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <U3BKpPGTLgqLAC8j3n-E9uM3B-6WQT1nB801uO3qtNY=.8b9d0f2a-9a8b-4e76-a349-ad3097d29c47@github.com>
Message-ID: <ahjfsQYpBoiouufV43ZPA_J6zsLostJCA_McU6sEqgY=.ab76f9d4-7d12-40d9-9beb-6b83616e2f37@github.com>

On Wed, 16 Aug 2023 18:10:04 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the test code
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 369:
> 
>> 367:                 }
>> 368:             }
>> 369:         } catch (Exception e) {
> 
> The code wrapped in this try-catch block can throw unchecked exceptions, for example `SecurityException` thrown by `Socket.connect`. For such cases the newly created socket remain open.

But the catch is on generalized Exception, and SecutityException is a subclass, so it is covered, n'est-ce pas?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296515618

From duke at openjdk.org  Wed Aug 16 23:11:11 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 16 Aug 2023 23:11:11 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  updated the code according to the review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/5e83e6ff..0cae2343

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=01-02

  Stats: 195 lines in 2 files changed: 83 ins; 62 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From msheppar at openjdk.org  Wed Aug 16 23:11:14 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 23:11:14 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <U3BKpPGTLgqLAC8j3n-E9uM3B-6WQT1nB801uO3qtNY=.8b9d0f2a-9a8b-4e76-a349-ad3097d29c47@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <U3BKpPGTLgqLAC8j3n-E9uM3B-6WQT1nB801uO3qtNY=.8b9d0f2a-9a8b-4e76-a349-ad3097d29c47@github.com>
Message-ID: <D78afBXHS60zMokWa4j3kDdzrFOG5ZzzrEo-dcGtjNk=.ddc927c4-04dc-4cc5-ab02-a3df4d944e30@github.com>

On Wed, 16 Aug 2023 17:24:57 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated the code according to the review
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 372:
> 
>> 370:             // 8314063 the socket is not closed after the failure of handshake
>> 371:             if (socket != null && !socket.isClosed()) {
>> 372:                 socket.close();
> 
> The original exception can be lost if `socket.close()` fails with `IOException` here

a closeConnectionSocket (IIRC) was introduced in previous change which handled any IOExceptions on the close. This could be used here.
But some how that seems to have been renamed !!

709     private void closeOpenedSocket() {
 710         try {
 711             sock.close();
 712         } catch (IOException ioEx) {
 713             if (debug) {
 714                 System.err.println("Connection.closeConnectionSocket: Socket close problem: " + ioEx);
 715                 System.err.println("Socket isClosed: " + sock.isClosed());
 716             }
 717         }
 718     }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296519158

From duke at openjdk.org  Wed Aug 16 23:14:39 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 16 Aug 2023 23:14:39 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
Message-ID: <l17H66lYvSlpecdnkUBepJ4c3SfWOFr2cwMAPjQVPhk=.b83c28af-8773-4be9-a791-c9fb6b868637@github.com>

On Wed, 16 Aug 2023 23:11:11 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according to the review

1) Refactor Connection::createSocket
2) Update the test code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1681383275

From duke at openjdk.org  Wed Aug 16 23:14:41 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Wed, 16 Aug 2023 23:14:41 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v2]
In-Reply-To: <G-no1mb7QkxWZa6wqLsriEwT0qxP8lk1L68OVhVbXyY=.2352e031-ad64-4483-b85e-a9d2023e39d8@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <F9wKdhFD8av9i0W8xQHUNyfM6j0iCOKJRWsV5csvMsY=.01602f00-63ee-46e8-975c-936a175a85a3@github.com>
 <G-no1mb7QkxWZa6wqLsriEwT0qxP8lk1L68OVhVbXyY=.2352e031-ad64-4483-b85e-a9d2023e39d8@github.com>
Message-ID: <vg2Mjc85ZNi2MUmFI5WMdVopnFamSKMnXdQzF_ZJC1M=.e7894138-82cc-49c2-8391-f091587a7b29@github.com>

On Wed, 16 Aug 2023 22:49:24 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the test code
>
> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 173:
> 
>> 171:         public void run() {
>> 172:             try (Socket socket = serverSocket.accept()) {
>> 173:                 Thread.sleep(10000);
> 
> What's the purpose of the sleep ? 
> Regardless, based on the test semantics alluded in the test name, the server should never enter the read block. So is this code redundant? Or is it there just in case the accept and the handshake succeeds?

It will slow down the handshake process after the socket is created and connected with the server. The bug is showing the handshake failure and the socket is not closed properly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296522377

From msheppar at openjdk.org  Wed Aug 16 23:29:26 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 23:29:26 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v2]
In-Reply-To: <vg2Mjc85ZNi2MUmFI5WMdVopnFamSKMnXdQzF_ZJC1M=.e7894138-82cc-49c2-8391-f091587a7b29@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <F9wKdhFD8av9i0W8xQHUNyfM6j0iCOKJRWsV5csvMsY=.01602f00-63ee-46e8-975c-936a175a85a3@github.com>
 <G-no1mb7QkxWZa6wqLsriEwT0qxP8lk1L68OVhVbXyY=.2352e031-ad64-4483-b85e-a9d2023e39d8@github.com>
 <vg2Mjc85ZNi2MUmFI5WMdVopnFamSKMnXdQzF_ZJC1M=.e7894138-82cc-49c2-8391-f091587a7b29@github.com>
Message-ID: <r5lweaAGSxfG36B-wEna017LLaeN8HYGWMPzmFaaa-w=.0bffb5ec-d354-4f08-82d7-c38643585b04@github.com>

On Wed, 16 Aug 2023 23:10:02 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 173:
>> 
>>> 171:         public void run() {
>>> 172:             try (Socket socket = serverSocket.accept()) {
>>> 173:                 Thread.sleep(10000);
>> 
>> What's the purpose of the sleep ? 
>> Regardless, based on the test semantics alluded in the test name, the server should never enter the read block. So is this code redundant? Or is it there just in case the accept and the handshake succeeds?
>
> It will slow down the handshake process after the socket is created and connected with the server. The bug is showing the handshake failure and the socket is not closed properly.

OK, So the SSL handshake must take place within the getInputStream call rather than the accept, as such you are triggering a timeout on the SSL handshake.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296530516

From msheppar at openjdk.org  Wed Aug 16 23:47:27 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 23:47:27 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
Message-ID: <ddxKzVYg74pTG16d_vvCno1pVCrid2uOIDaIL8A2-6k=.f4059d16-1afc-42ce-bc18-2ac85957b0a0@github.com>

On Wed, 16 Aug 2023 23:11:11 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according to the review

together with a refactor extact methods on the createSocket method, the existing logic could be simplified something like as follows:


            InetSocketAddress endpoint =
               createInetSocketAddress(ldapServerHost, ldapServerPort);

            if (socketFactory != null) {
                 // further refine with refactor extract method createConnectionSocket(InetSocketAddress serverEndpoint, String factoryClassName, int timeout)

                // create the factory

                @SuppressWarnings("unchecked")
                Class<? extends SocketFactory> socketFactoryClass =
                        (Class<? extends SocketFactory>) Obj.helper.loadClass(socketFactory);
                Method getDefault =
                        socketFactoryClass.getMethod("getDefault", new Class<?>[]{});
                SocketFactory factory = (SocketFactory) getDefault.invoke(null, new Object[]{});
 
                // create unconnected socket
                socket = factory.createSocket();

               if (connectTimeout > 0) {                 
                  if (debug) {
                        System.err.println("Connection.createSocket: creating socket with " +
                                "a timeout using supplied socket factory");
                    }

                    // connect socket
                    socket.connect(endpoint, connectTimeout);
               } else {
                   if (debug) {
                        System.err.println("Connection.createSocket: creating socket using " +
                                "supplied socket factory");
                    }
                    // connect socket
                    socket.connect(endpoint);
               }
             } else { // NO SocketFactory
                // further refine with refactor extract method createConnectionSocket(InetSocketAddress serverEndpoint,  int timeout)
                socket = new Socket();
                if (connectTimeout > 0) {
                    if (debug) {
                        System.err.println("Connection.createSocket: creating socket with " +
                                "a timeout");
                    }
                    socket.connect(endpoint, connectTimeout);
                } else {
                   if (debug) {
                        System.err.println("Connection.createSocket: creating socket");
                   }
                   socket.connect(endpoint);
              }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1681403755

From msheppar at openjdk.org  Wed Aug 16 23:51:28 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 23:51:28 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
Message-ID: <wqDuSYnrz8LNHH89M0GYqJR9SYjo3kpnCMizMgYpwEA=.a33ae856-a3ee-4045-984b-2ea249edd68d@github.com>

On Wed, 16 Aug 2023 23:11:11 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according to the review

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 287:

> 285:             // create the socket with factory
> 286:             if (socketFactory != null) {
> 287:                 socket = createSocketWithFactory (host, port, socketFactory, connectTimeout) ;

you could use method overloading :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296540658

From msheppar at openjdk.org  Wed Aug 16 23:59:27 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 16 Aug 2023 23:59:27 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
Message-ID: <JqByG0rqPYykFiuC92w7iUx56oKarAU-IAruhrazLnM=.28002022-04a4-4435-8c89-d10b48f2aae3@github.com>

On Wed, 16 Aug 2023 23:11:11 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according to the review

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 340:

> 338: 
> 339:     // create the socket without the factory
> 340:     private Socket createSocketWithoutFactory (String host, int port, int connectTimeout) throws Exception {

i think the logic can be streamlined as per comment in main conversation

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 381:

> 379:                     createInetSocketAddress(host, port);
> 380:             // unconnected socket
> 381:             socket = factory.createSocket();

i think the logic can be streamlined as per comment in main conversation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296543226
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296543879

From duke at openjdk.org  Thu Aug 17 02:03:51 2023
From: duke at openjdk.org (duke)
Date: Thu, 17 Aug 2023 02:03:51 GMT
Subject: Withdrawn: 8294961: Convert java.base/java.lang.reflect.ProxyGenerator
 to use the Classfile API to generate proxy classes
In-Reply-To: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
References: <rqqi61cKbJ8TjDVSzsjh6BVXjF1ZxL2ZFHheuXzL5E8=.bd1f1a2c-6f35-4180-a0a5-8a6e3cb93e75@github.com>
Message-ID: <QLA20lvTmGvo0opJ3zxhC09yA4vRFzYq8rDqmWW3jjk=.2f963934-ac40-49b7-ae32-6bc273d44aa0@github.com>

On Fri, 4 Nov 2022 15:21:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10991

From darcy at openjdk.org  Thu Aug 17 04:59:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 04:59:47 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math terms
Message-ID: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>

Use of javadoc search index feature; I'll re-flow paragraphs before pushing once the wording is agreed to.

-------------

Commit messages:
 - JDK-8314489: Add javadoc index entries for java.lang.Math terms

Changes: https://git.openjdk.org/jdk/pull/15322/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15322&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314489
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15322.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15322/head:pull/15322

PR: https://git.openjdk.org/jdk/pull/15322

From aturbanov at openjdk.org  Thu Aug 17 07:16:35 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 17 Aug 2023 07:16:35 GMT
Subject: Integrated: 8314321: Remove unused field
 jdk.internal.util.xml.impl.Attrs.mAttrIdx
In-Reply-To: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
References: <Psxx7O0TYOOFYH1kX5ni_4kS3o5ixKhPMUJF6STZ7pI=.e281721d-7fae-46d0-936e-76987b6609ed@github.com>
Message-ID: <Jok-wftuG3Oy-XkSyy2CvB9DFgOJoLCdWy8DAsTX4gM=.9f6c9216-d150-4eae-8f3b-18e3f0cddf26@github.com>

On Tue, 15 Aug 2023 20:13:18 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A field `char mAttrIdx` in the `jdk.internal.util.xml.impl.Attrs` class is unused and can be removed.

This pull request has now been integrated.

Changeset: 249dc374
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/249dc37426d6eb5b70a387317b6780b643ce4c06
Stats:     7 lines in 1 file changed: 0 ins; 4 del; 3 mod

8314321: Remove unused field jdk.internal.util.xml.impl.Attrs.mAttrIdx

Reviewed-by: alanb, vtewari, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/15298

From mbaesken at openjdk.org  Thu Aug 17 07:57:37 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 17 Aug 2023 07:57:37 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <FlrRm94KmjHEavB26YVcGVRzhT8920ftdHCJXWX5plY=.4e56fa80-eb5e-4dc4-a366-b37d26508bd8@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <FlrRm94KmjHEavB26YVcGVRzhT8920ftdHCJXWX5plY=.4e56fa80-eb5e-4dc4-a366-b37d26508bd8@github.com>
Message-ID: <nCmpCRcYhVyK_AvhEAnV36abG59d0MH3u8rJbHq5-BU=.07c0a471-f625-43de-a5d3-06afc1943b48@github.com>

On Wed, 16 Aug 2023 19:02:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
>> 
>> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
>> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
>> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
>> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
>> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
>> [JShell] ... 4 more
>> 
>> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding
>
> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 773:
> 
>> 771:                String sharingMode = "shared";
>> 772:                if (!shared) sharingMode = "nonshared";
>> 773:                throw(new BackingStoreException("Couldn't get file lock. errno is " + errCode + " mode is " + sharingMode));
> 
> A raw errno is pretty uninformative, except for experts. Can the errno be translated to a string as well as supplying the errno?

Hi Roger,  sounds like a good idea  to translate it to a more informative string.
Do you have an  utility function in mind that does this ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1296822489

From alanb at openjdk.org  Thu Aug 17 08:05:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Aug 2023 08:05:34 GMT
Subject: Integrated: 8314280: StructuredTaskScope.shutdown should document that
 the state of completing subtasks is not defined
In-Reply-To: <LeoqedNfFK6IIupqWVYC3SXlVC45GaiN36zP4E_8B-k=.50ac351b-bbcf-4905-b97a-baeb5f9fa317@github.com>
References: <LeoqedNfFK6IIupqWVYC3SXlVC45GaiN36zP4E_8B-k=.50ac351b-bbcf-4905-b97a-baeb5f9fa317@github.com>
Message-ID: <vr3MrlW9L_8uhSi-gJyVelObfoCHgirkEkafrJSMZ9o=.09ee3746-eafe-4af2-b485-c62b55463804@github.com>

On Tue, 15 Aug 2023 16:21:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a docs only change. The specification for StructuredTaskScope.shutdown should make it clear that the state of subtasks that are completing (with a result or exception) at around the time of shutdown is not defined. The state of a completing subtask may transition to a terminal state, it may not, as it is racing with the shutdown.

This pull request has now been integrated.

Changeset: ed585d16
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed585d16b9069a678bb8633239ca87f64c956fdd
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8314280: StructuredTaskScope.shutdown should document that the state of completing subtasks is not defined

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/15293

From alanb at openjdk.org  Thu Aug 17 08:35:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Aug 2023 08:35:30 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms
In-Reply-To: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
Message-ID: <STiCPBqiWjZrrBFNqxZqk-c4SNA0MX-URL21idCP3CY=.7c446516-a93f-4413-9020-53ef8cb16256@github.com>

On Thu, 17 Aug 2023 04:52:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use of javadoc search index feature; I'll re-flow paragraphs before pushing once the wording is agreed to.

This looks okay to me. You might want to move the "For a" on L58 to the next line to avoid L58 stick out too much, up to you.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15322#pullrequestreview-1582073746

From aph at openjdk.org  Thu Aug 17 08:51:30 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 17 Aug 2023 08:51:30 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <ifDiEU0yMbpwUeYsLJG0c92plKQ539xsAmC9pGCd7J0=.d2dda212-6cb8-48bf-863a-12e9991018dc@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
 <NnaAUjqrHuaELbw_x1AQNNyDwuQ_hBgE-lAjNAxEC28=.536bd163-60e8-41b6-950d-0f8bfae636e6@github.com>
 <ifDiEU0yMbpwUeYsLJG0c92plKQ539xsAmC9pGCd7J0=.d2dda212-6cb8-48bf-863a-12e9991018dc@github.com>
Message-ID: <I0K6AVV0tSnA-1MKFwp5xU6cRqJtSLcd2e1F7TGXn_4=.45141fae-a297-412c-a511-dec6b2a0bf36@github.com>

On Wed, 16 Aug 2023 10:35:32 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> These benchmarks are all small arrays. We need to check for possible regressions here. 

Sorry, all large arrays. I suspect that the average-length sort is not represented.

> Also, I'm rather concerned that we might lose the data from this PR.

How does keep alive work? Will the data from that external web site still be here for the reader in 15 years' time?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1681885607

From vtewari at openjdk.org  Thu Aug 17 09:00:30 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 17 Aug 2023 09:00:30 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
Message-ID: <43kZqSP9JDVTb_AQSfat0RQnPoiY2LdFi9fKwsjlung=.d7d5146a-dadf-4f4d-ac67-cbe0ed27a16d@github.com>

On Wed, 16 Aug 2023 23:11:11 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according to the review

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 143:

> 141:     }
> 142: 
> 143:     private static void setKeyStore() {

Overall code changes looks OK to me,  did you consider creating the self signed certificates programmatically and use them in  your test ?. Please  look into the existing javax.net.ssl tests how to do this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1296897982

From prappo at openjdk.org  Thu Aug 17 09:26:29 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 17 Aug 2023 09:26:29 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v7]
In-Reply-To: <I0K6AVV0tSnA-1MKFwp5xU6cRqJtSLcd2e1F7TGXn_4=.45141fae-a297-412c-a511-dec6b2a0bf36@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <LLW8WZYmQGyRSJWZlQxdEF9hgdowA2zENlTrdvemUXE=.fa7740c5-f020-46ab-8bd1-3dd6c6c38f17@github.com>
 <NnaAUjqrHuaELbw_x1AQNNyDwuQ_hBgE-lAjNAxEC28=.536bd163-60e8-41b6-950d-0f8bfae636e6@github.com>
 <ifDiEU0yMbpwUeYsLJG0c92plKQ539xsAmC9pGCd7J0=.d2dda212-6cb8-48bf-863a-12e9991018dc@github.com>
 <I0K6AVV0tSnA-1MKFwp5xU6cRqJtSLcd2e1F7TGXn_4=.45141fae-a297-412c-a511-dec6b2a0bf36@github.com>
Message-ID: <HaLbxEZwFr80fdVAtkxcOfbr0v2IysbKMc5aHvlXMr8=.4bd3d1a6-db86-4af6-8156-ffec503612c6@github.com>

On Thu, 17 Aug 2023 08:48:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

> How does keep alive work? Will the data from that external web site still be here for the reader in 15 years' time?

Hm... I thought that at least full webrevs are stored somewhere on https://cr.openjdk.org/. Turns out they aren't. They are stored on https://openjdk.github.io/cr/.

Okay, a cheap thing to do *now* is to ask the Web Archive to store it, which I just did:

  * https://web.archive.org/web/20230817091712/https://openjdk.github.io/cr/?repo=jdk&pr=13568&range=06
  * https://web.archive.org/web/20230817091943/https://github.com/openjdk/jdk/compare/0f51e6326373ff7d4a4d9a0e3a2788401f73405d...f7f7e11adf9984ee1ce316e3e36f5e351b49bb97.diff
  * https://web.archive.org/web/20230817092146/https://github.com/openjdk/jdk/pull/13568

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1681937116

From pminborg at openjdk.org  Thu Aug 17 09:42:37 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 17 Aug 2023 09:42:37 GMT
Subject: RFR: 8314071: Test java/foreign/TestByteBuffer.java timed out
Message-ID: <34VlCruMgC16DgQwR7bn2GMWh1TtECwaNEr38grRrVk=.9afb35f2-c820-4cad-b2f9-f49236d1222a@github.com>

This PR proposes improving performance for two `VarHandle` objects and increasing the timeout for the tests. The size of a mapped file is also reduced from 3 GiB to 2.5 GiB. This still crosses the 2<sup> 31</sup> boundary.

-------------

Commit messages:
 - Improve performance and increase timeout

Changes: https://git.openjdk.org/jdk/pull/15326/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15326&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314071
  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/15326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15326/head:pull/15326

PR: https://git.openjdk.org/jdk/pull/15326

From msheppar at openjdk.org  Thu Aug 17 09:50:31 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 17 Aug 2023 09:50:31 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <svMuHNs68wt3ih5x0yRtlmEmRSj4renmwX500rcyMs0=.50890d71-7fec-4aa7-b016-1be2c3de1f96@github.com>
Message-ID: <Osuybd6DkDFc0bu2u4Bg4wrQDg22v5t3TtOwRXGOVKY=.af178273-1a26-4702-ad55-805b62bd218c@github.com>

On Wed, 16 Aug 2023 23:11:11 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated the code according to the review

you now have two methods closing a socket. Can these be refactored and a single closeSocket method used in both cases ?

method overloading could have been used for the new create socket method

you might consider some restructuring of the call flow in each:

   private Socket createSocketWithoutFactory (String host, int port, int connectTimeout) throws Exception {
        Socket socket = null;
        InetSocketAddress endpoint = createInetSocketAddress(host, port);
        socket = new Socket();

        if (connectTimeout > 0) {
            if (debug) {
                System.err.println("Connection: creating socket with " +
                        "a timeout");
            }
            socket.connect(endpoint, connectTimeout);
        } else {
            if (debug) {
                System.err.println("Connection: creating socket");
            }
            // connected socket
            socket.connect(endpoint);
        }
        return socket;
    }


    // create the socket with the provided factory
    private Socket createSocketWithFactory(String host, int port, String socketFactory,
                                           int connectTimeout) throws Exception {
        Socket socket = null;
        @SuppressWarnings("unchecked")
        Class<? extends SocketFactory> socketFactoryClass = (Class<? extends SocketFactory>)
                Obj.helper.loadClass(socketFactory);
        Method getDefault =
                socketFactoryClass.getMethod("getDefault", new Class<?>[]{});
        SocketFactory factory = (SocketFactory) getDefault.invoke(null, new Object[]{});
        InetSocketAddress endpoint =
                  createInetSocketAddress(host, port);
        // create unconnected socket
        socket = factory.createSocket();

        // create the socket
        if (connectTimeout > 0) {
            if (debug) {
                System.err.println("Connection: creating socket with " +
                        "a timeout using supplied socket factory");
            }
            // connected socket
            socket.connect(endpoint, connectTimeout);
        } else {
            if (debug) {
                System.err.println("Connection: creating socket using " +
                        "supplied socket factory");
            }
            // connected socket
            socket.connect(endpoint);
        }
        return socket;
    }

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1681979781

From mcimadamore at openjdk.org  Thu Aug 17 09:51:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 17 Aug 2023 09:51:28 GMT
Subject: RFR: 8314071: Test java/foreign/TestByteBuffer.java timed out
In-Reply-To: <34VlCruMgC16DgQwR7bn2GMWh1TtECwaNEr38grRrVk=.9afb35f2-c820-4cad-b2f9-f49236d1222a@github.com>
References: <34VlCruMgC16DgQwR7bn2GMWh1TtECwaNEr38grRrVk=.9afb35f2-c820-4cad-b2f9-f49236d1222a@github.com>
Message-ID: <PAH5Us9lHS7Mp-FNdVU9V7udxnzYrGmxAAQnJkkc5sw=.b8c43835-3e3b-43d9-b5ed-637dd173cc10@github.com>

On Thu, 17 Aug 2023 09:36:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes improving performance for two `VarHandle` objects and increasing the timeout for the tests. The size of a mapped file is also reduced from 3 GiB to 2.5 GiB. This still crosses the 2<sup> 31</sup> boundary.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15326#pullrequestreview-1582244048

From duke at openjdk.org  Thu Aug 17 09:53:33 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 17 Aug 2023 09:53:33 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
Message-ID: <fNReI-KPagLhxGUjWrw09DlLx2SRrMhctTq2qDMXJ_4=.a1aa8ab5-fcc0-46fe-ae7b-0c7d99b88b0c@github.com>

On Mon, 14 Aug 2023 11:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea 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 45 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Update @since tags
>  - resync
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ExecutorService tests
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Rework versioning
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/c4e74122...585769c9

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 456:

> 454:      * mechanism. In particular, the stack top subfield of ctl stores
> 455:      * indices, not references. Operations on queues obtained from
> 456:      * these indices remain OK (with at most some unnecessary extra

Suggestion:

     * these indices remain valid (with at most some unnecessary extra

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1296983889

From duke at openjdk.org  Thu Aug 17 10:05:35 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 17 Aug 2023 10:05:35 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
Message-ID: <qkzCeIZ6enfc9YyAfy7KpasQ-KqH2gzVfhgnKXSpIk8=.7f1f251d-e9a8-481f-83de-79190767f32e@github.com>

On Mon, 14 Aug 2023 11:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea 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 45 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Update @since tags
>  - resync
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ExecutorService tests
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Rework versioning
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/a26bcff0...585769c9

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 721:

> 719:      * they are ignored, and 0 is an OK default.) The scan in method
> 720:      * helpJoin uses these markers to try to find a worker to help
> 721:      * (i.e., steal back a task from and execute it) that could makje

Suggestion:

     * (i.e., steal back a task from and execute it) that could make

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1296996791

From shade at openjdk.org  Thu Aug 17 10:33:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 17 Aug 2023 10:33:28 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v2]
In-Reply-To: <fQnqt8E12cTShqzhOIZAwvvKjv1fiQeCBZfhHUNEv3Q=.c59f5048-9872-4e8c-a4b9-39cfe87d0db3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>
 <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>
 <fQnqt8E12cTShqzhOIZAwvvKjv1fiQeCBZfhHUNEv3Q=.c59f5048-9872-4e8c-a4b9-39cfe87d0db3@github.com>
Message-ID: <jC0eGraFg1Mf48V8-aueLKbUK9ixvN3ZImtQ_Py_G5o=.b6b4793f-22a9-41e1-9ce3-3ba654ad0e20@github.com>

On Wed, 16 Aug 2023 21:38:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/java/util/Collections/RotateHuge.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8314236
>>> 27:  * @summary Overflow in Collections.rotate
>> 
>> Since this test takes >4G of heap to hold the list with compressed oops, and >8G of heap without compressed oops, we need to run it in a separate VM with enough headroom, something like this:
>> 
>> 
>>  * @test
>>  * @bug 8314236
>>  * @summary Overflow in Collections.rotate
>>  * @requires (sun.arch.data.model == "64" & os.maxMemory >= 16g)
>>  * @run main/othervm -Xmx12g RotateHuge
>
> @nikita-sakharin
> 
> Thanks for finding this bug and offering to fix it! (And @shipilev thanks for your assistance on this.)
> 
> Putting the test into a separate JVM will work, but I don't think it's necessary to actually allocate the space. The test is only testing the indexes sent to `get` and `set` on the list, and it doesn't actually verify the contents of the list. (Presumably that's done by other tests.) Therefore it should be possible to create a "virtual" list of a given size that checks that the indexes are all in bounds but that doesn't actually store any elements. It should be fairly straightforward to do this by subclassing AbstractList and overriding a few methods.
> 
> The advantage of not actually allocating 4G of memory is that it makes it easier to run a bunch of cases that test the boundary conditions. In fact I'd like to see that in the test, as opposed to testing this one case.

Oh yes, let's do the synthetic `AbstractList` (?) subclass, instead of allocating lots of memory.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1297030276

From duke at openjdk.org  Thu Aug 17 10:54:07 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Thu, 17 Aug 2023 10:54:07 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v4]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <Goz9mnlBOSmYHnfKTNK-XbBr3_P_NiupjiTO7DURbEU=.c05cb614-af85-4dd9-89b2-b44a6112217c@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:

  8314236: rewrite test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/dda1c3b0..3ea1c1a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=02-03

  Stats: 38 lines in 1 file changed: 30 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From aefimov at openjdk.org  Thu Aug 17 10:56:28 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 17 Aug 2023 10:56:28 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v3]
In-Reply-To: <ahjfsQYpBoiouufV43ZPA_J6zsLostJCA_McU6sEqgY=.ab76f9d4-7d12-40d9-9beb-6b83616e2f37@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <U3BKpPGTLgqLAC8j3n-E9uM3B-6WQT1nB801uO3qtNY=.8b9d0f2a-9a8b-4e76-a349-ad3097d29c47@github.com>
 <ahjfsQYpBoiouufV43ZPA_J6zsLostJCA_McU6sEqgY=.ab76f9d4-7d12-40d9-9beb-6b83616e2f37@github.com>
Message-ID: <QcIi8KYI5ErxAfI4H_slGsxzAEtkKRB88BHLGe2Z0pU=.2bbd1775-3836-4473-b7f8-d9171f525fbc@github.com>

On Wed, 16 Aug 2023 22:57:55 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 369:
>> 
>>> 367:                 }
>>> 368:             }
>>> 369:         } catch (Exception e) {
>> 
>> The code wrapped in this try-catch block can throw unchecked exceptions, for example `SecurityException` thrown by `Socket.connect`. For such cases the newly created socket remain open.
>
> But the catch is on generalized Exception, and SecutityException is a subclass, so it is covered, n'est-ce pas?

Thanks Mark. Correct - SecurityException is a subclass of Exception, scratch my previous comment. We just need to double check `catch Exception` covers all thrown exception types in this code block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1297053493

From duke at openjdk.org  Thu Aug 17 11:30:37 2023
From: duke at openjdk.org (Cristian Vat)
Date: Thu, 17 Aug 2023 11:30:37 GMT
Subject: Integrated: 8311939: Excessive allocation of Matcher.groups array
In-Reply-To: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
References: <-rGxVaelERJzU0k6NH_N-1VG30LBEEPRVitTZWW8YVQ=.3d51e97a-95b7-4dbc-b36b-15dbc6802825@github.com>
Message-ID: <FgUG7CsqKkc2qMHhpvROHnIFAsUHI6jaoJv2ko88lIA=.f725c94a-1749-45a9-bbd1-c89692c7d879@github.com>

On Sat, 15 Jul 2023 18:24:59 GMT, Cristian Vat <duke at openjdk.org> wrote:

> Reduces excessive allocation of Matcher.groups array when the original Pattern has no groups or less than 9 groups.
> 
> Original clamping to 10 possibly due to documented behavior from javadoc: 
> "In this class, \1 through \9 are always interpreted as back references, "
> 
> Only with Matcher changes RegExTest.backRefTest fails when backreferences to non-existing groups are present.
> Added a match failure condition in Pattern that fixes failing tests.
> 
> As per existing `java.util.regex.Pattern.BackRef#match`: "// If the referenced group didn't match, neither can this"
> 
> A group that does not exist in the original Pattern can never match so neither can a backref to that group.
> If the group existed in the original Pattern then it would have had space allocated in Matcher.groups for that group index.
> So a group index outside groups array length must never match.

This pull request has now been integrated.

Changeset: 32efd23c
Author:    Cristian Vat <cristian.vat at gmail.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32efd23c5d59c03a6376c92c63f5947e961ee24e
Stats:     68 lines in 3 files changed: 64 ins; 2 del; 2 mod

8311939: Excessive allocation of Matcher.groups array

Reviewed-by: rriggs, igraves

-------------

PR: https://git.openjdk.org/jdk/pull/14894

From pminborg at openjdk.org  Thu Aug 17 11:34:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 17 Aug 2023 11:34:33 GMT
Subject: Integrated: 8314071: Test java/foreign/TestByteBuffer.java timed out
In-Reply-To: <34VlCruMgC16DgQwR7bn2GMWh1TtECwaNEr38grRrVk=.9afb35f2-c820-4cad-b2f9-f49236d1222a@github.com>
References: <34VlCruMgC16DgQwR7bn2GMWh1TtECwaNEr38grRrVk=.9afb35f2-c820-4cad-b2f9-f49236d1222a@github.com>
Message-ID: <f6hurIbtK_jEqOzxDziDOLHuBBUHVY9SXyzVrynHY5Y=.f34a9645-d2f2-40a6-8f5a-00700ec5bb73@github.com>

On Thu, 17 Aug 2023 09:36:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes improving performance for two `VarHandle` objects and increasing the timeout for the tests. The size of a mapped file is also reduced from 3 GiB to 2.5 GiB. This still crosses the 2<sup> 31</sup> boundary.

This pull request has now been integrated.

Changeset: 2b81885f
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b81885f787d6cf97de556d1774420e2fb7d56f5
Stats:     12 lines in 1 file changed: 0 ins; 0 del; 12 mod

8314071: Test java/foreign/TestByteBuffer.java timed out

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/15326

From alanb at openjdk.org  Thu Aug 17 12:51:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Aug 2023 12:51:29 GMT
Subject: RFR: 8310815: Clarify the name of the main class,
 services and provider classes in module descriptor
In-Reply-To: <sFl8a99xmRocPxZCyqP1bF4wy2chKMbimkWrrzycJmw=.ac327770-7242-4b9d-9c4c-9e0d805b7a4b@github.com>
References: <sFl8a99xmRocPxZCyqP1bF4wy2chKMbimkWrrzycJmw=.ac327770-7242-4b9d-9c4c-9e0d805b7a4b@github.com>
Message-ID: <-0r60yJkelpFitobg0POTkI2ZGfGGFlms_1zBxBm5k0=.be65e16c-3210-432b-9783-ded63459e42e@github.com>

On Wed, 16 Aug 2023 18:42:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Clarify the spec of `ModuleDescriptor::mainClass`, `ModuleDescriptor::uses`, `ModuleDescriptor.Provides::service` and `ModuleDescriptor.Provides::providers` to return a binary name. 
> 
> This PR also fixes JDK-8314449 to update the spec of `StackTraceElement::getClassName` and the `declaringClass` parameter of the constructor.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15317#pullrequestreview-1582546834

From rgiulietti at openjdk.org  Thu Aug 17 13:03:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Aug 2023 13:03:27 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms
In-Reply-To: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
Message-ID: <3lEvfPG45vx_la0HeAWOW7hallZwoJFQY9AWl-D5-fs=.f4ccb090-7ecd-47ca-9484-61815fddb648@github.com>

On Thu, 17 Aug 2023 04:52:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use of javadoc search index feature; I'll re-flow paragraphs before pushing once the wording is agreed to.

What about `<i>semi-monotonic</i>` on L.80?
Does it deserve to be tagged as `<dfn>` and indexed?

-------------

PR Review: https://git.openjdk.org/jdk/pull/15322#pullrequestreview-1582570065

From rgiulietti at openjdk.org  Thu Aug 17 13:16:36 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 17 Aug 2023 13:16:36 GMT
Subject: [jdk21] Withdrawn: 8312976: MatchResult produces
 StringIndexOutOfBoundsException for groups outside match
In-Reply-To: <n_6xrk0yM0WbwKctAqa3jkaWHw6wq1Q0MZkM1fQxupo=.13e98d0e-b919-40a7-8bf7-0deac064a239@github.com>
References: <n_6xrk0yM0WbwKctAqa3jkaWHw6wq1Q0MZkM1fQxupo=.13e98d0e-b919-40a7-8bf7-0deac064a239@github.com>
Message-ID: <TsfNBJ6r43ztXDbIqwVnzrxaSyy13qegFZkpVTorFDc=.a91682a6-1a93-4180-b784-5483affea846@github.com>

On Fri, 4 Aug 2023 08:58:46 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [61c58fdd](https://github.com/openjdk/jdk/commit/61c58fdd00727da2841a052477e4f4ecfa7094d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Raffaello Giulietti on 4 Aug 2023 and was reviewed by Alan Bateman and Stuart Marks.
> 
> Thanks!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk21/pull/164

From dl at openjdk.org  Thu Aug 17 13:37:55 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 17 Aug 2023 13:37:55 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v5]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <4-QLtSTaFZNyy0xb0YFQWOMCaKLs5GtmzxFLfxO-ZzA=.672e7be5-77d8-4adb-9585-b79791c74f72@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Avoid false-alarm failures on shutdown

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/585769c9..901f5bdd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=03-04

  Stats: 72 lines in 6 files changed: 28 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From dl at openjdk.org  Thu Aug 17 13:37:55 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 17 Aug 2023 13:37:55 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <NihW42UsTHECmRmdgxZUlelVnlvVA9EQnqVNgK6Yf-E=.19c8a8b8-e5bc-4e52-81d8-f3d8599958b5@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
 <dGCJ_heaOQaSdOOFr_RuaU4avoCYqsB5KEGcixEtgtM=.9b2d5719-0744-4a8e-851a-31f0ce60ea0c@github.com>
 <NihW42UsTHECmRmdgxZUlelVnlvVA9EQnqVNgK6Yf-E=.19c8a8b8-e5bc-4e52-81d8-f3d8599958b5@github.com>
Message-ID: <vXPosVAUuidI01ZtZNk-zUcKA7w500uvv2elGdDAazQ=.4f8cfdeb-dc59-4ece-b010-1a9b5d7a4489@github.com>

On Wed, 16 Aug 2023 10:33:58 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 442:
>> 
>>> 440:      * queues are at odd indices. Worker phase ids masked with SMASK
>>> 441:      * match their index. Shared (submission) queues are at even
>>> 442:      * indices. Grouping them together in this way simplifies and
>> 
>> @DougLea Interesting?so by having the worker queues at odd indices increases the likelihood of the then adjacent submission queues already having been prefetched?
>
> More-or-less. At top-level, both kinds of queues should be sampled with approx the same probability, which is simpler if they are all in the same array. But we also need to identify what kind they are without looking at them, leading to odd/even scheme. One disadvantage is that there are usually many fewer submission queues, so there can be a lot of wasted probes (null slots). But still cheaper than alternatives because of cache locality etc.

(I also added some similar wording to the internal docs.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1297226372

From dl at openjdk.org  Thu Aug 17 13:37:58 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 17 Aug 2023 13:37:58 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <fNReI-KPagLhxGUjWrw09DlLx2SRrMhctTq2qDMXJ_4=.a1aa8ab5-fcc0-46fe-ae7b-0c7d99b88b0c@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
 <fNReI-KPagLhxGUjWrw09DlLx2SRrMhctTq2qDMXJ_4=.a1aa8ab5-fcc0-46fe-ae7b-0c7d99b88b0c@github.com>
Message-ID: <NwMbnAcWfOEkUzHqe_IbfA0DldLnAOAPEhSAQ3k8ero=.29b9de7c-0402-41ad-9bbe-73445658fcc8@github.com>

On Thu, 17 Aug 2023 09:50:49 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea 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 45 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Update @since tags
>>  - resync
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - ExecutorService tests
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Rework versioning
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/31d0f5ed...585769c9
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 456:
> 
>> 454:      * mechanism. In particular, the stack top subfield of ctl stores
>> 455:      * indices, not references. Operations on queues obtained from
>> 456:      * these indices remain OK (with at most some unnecessary extra
> 
> Suggestion:
> 
>      * these indices remain valid (with at most some unnecessary extra

Thanks. Done

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 721:
> 
>> 719:      * they are ignored, and 0 is an OK default.) The scan in method
>> 720:      * helpJoin uses these markers to try to find a worker to help
>> 721:      * (i.e., steal back a task from and execute it) that could makje
> 
> Suggestion:
> 
>      * (i.e., steal back a task from and execute it) that could make

Thanks. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1297228886
PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1297229368

From rriggs at openjdk.org  Thu Aug 17 14:02:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Aug 2023 14:02:37 GMT
Subject: [jdk21] Withdrawn: 8313312: Add missing classpath exception copyright
 header
In-Reply-To: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
References: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
Message-ID: <S-dCWa7d6ryfiPd8cVt8tGOqjFbLUUomEV5dujY0sII=.d7455871-3526-4f7e-bc29-93eb79dad2c0@github.com>

On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The same copyright updates are needed in JDK21.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk21/pull/166

From rriggs at openjdk.org  Thu Aug 17 14:02:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Aug 2023 14:02:36 GMT
Subject: [jdk21] RFR: 8313312: Add missing classpath exception copyright
 header
In-Reply-To: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
References: <W4t8hVY7iPg8yN4mwewuiPzREyzMZB7N_a8zL2IxZYc=.b6eb6b8b-ba1f-4a20-99fc-48d03292b720@github.com>
Message-ID: <AXqv-kwYPpuFe10-sWCVcKv6nG1jAfyvenfMfLmo_cw=.fd0b80fd-b0aa-423b-81b9-23d175fa011a@github.com>

On Tue, 8 Aug 2023 15:55:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The same copyright updates are needed in JDK21.

Too late for jdk21 RC.
Will backport to jdk21u.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/166#issuecomment-1682340185

From roger.riggs at oracle.com  Thu Aug 17 15:04:44 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 17 Aug 2023 11:04:44 -0400
Subject: Result: New Core Libraries Group Member: Brian Burkhalter
Message-ID: <0261146b-cab2-d8ea-13c6-7a1c473c038a@oracle.com>

The vote for Brian Burkhalter [1] is now closed.

Yes: 8
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109898.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230817/a24f5154/attachment.htm>

From roger.riggs at oracle.com  Thu Aug 17 15:04:56 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 17 Aug 2023 11:04:56 -0400
Subject: Result: New Core Libraries Group Member: Brent Christian
Message-ID: <a9f24c9c-2f5e-dc0e-7860-d11042cf201f@oracle.com>

The vote for Brent Christian [1] is now closed.

Yes: 8
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109899.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230817/58d42d83/attachment-0001.htm>

From roger.riggs at oracle.com  Thu Aug 17 15:05:07 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 17 Aug 2023 11:05:07 -0400
Subject: Result: New Core Libraries Group Member: Joe Wang
Message-ID: <feafa651-d70a-c5ba-e8bd-7f04c3509c68@oracle.com>

The vote for Joe Wang [1] is now closed.

Yes: 8
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109900.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230817/9f04f6cf/attachment.htm>

From roger.riggs at oracle.com  Thu Aug 17 15:05:22 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 17 Aug 2023 11:05:22 -0400
Subject: Result: New Core Libraries Group Member: Brian Burkhalter
Message-ID: <90551da4-7adb-24d2-ea38-ceb308bb2edc@oracle.com>

The vote for Brian Burkhalter [1] is now closed.

Yes: 8
Veto: 0
Abstain: 0

|According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. Roger Riggs [1] 
https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109898.html |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230817/10566ba8/attachment.htm>

From duke at openjdk.org  Thu Aug 17 15:28:35 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 17 Aug 2023 15:28:35 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
Message-ID: <2VxtUHQOQdretKTrqlk4zPFZux1Bng6l3MbkkYWYbYg=.022ef204-c37b-4459-b7e1-0946251c2df8@github.com>

On Mon, 14 Aug 2023 11:52:00 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
>> 
>> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.
>
> Doug Lea 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 45 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Update @since tags
>  - resync
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ExecutorService tests
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Rework versioning
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - Merge branch 'openjdk:master' into JDK-8288899
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/211154b9...585769c9

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1823:

> 1821:                 WorkQueue[] qs; int n;
> 1822:                 if ((qs = queues) != null && (n = qs.length) > 0) {
> 1823:                     for (int k = n, m = n - 1;  ; id += 2) {

@DougLea Might make sense to create a constant each for worker-queue stride and submission-queue stride so it becomes easier to reason about the `2` here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1297385745

From alanb at openjdk.org  Thu Aug 17 15:56:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Aug 2023 15:56:14 GMT
Subject: RFR: 8313290: Misleading exception message from STS.Subtask::get
 when task forked after shutdown [v2]
In-Reply-To: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
References: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
Message-ID: <_ekcvkKlglzauw_j4inERa5iygVPPRunEp2Xe15I7XI=.f9018ea9-0a61-4822-9fd0-a148bbc0be44@github.com>

> This is a small issue with StructuredTaskScope. If the owner attempts to fork a subtask and the task scope is shutdown then the implementation doesn't currently force the owner to join when it's the first fork in a new round of forking. The result is that broken code calling Subtask::get throws ISE with the wrong exception message.
> 
> The existing test for this API is updated to remove a duplicate test and also fix two tasks that didn't call join.

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 five additional commits since the last revision:

 - Adjust exception messages
 - Merge
 - Merge
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15076/files
  - new: https://git.openjdk.org/jdk/pull/15076/files/f88590bf..c2e9024c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15076&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15076&range=00-01

  Stats: 2789 lines in 110 files changed: 2488 ins; 65 del; 236 mod
  Patch: https://git.openjdk.org/jdk/pull/15076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15076/head:pull/15076

PR: https://git.openjdk.org/jdk/pull/15076

From alanb at openjdk.org  Thu Aug 17 15:56:17 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Aug 2023 15:56:17 GMT
Subject: RFR: 8313290: Misleading exception message from STS.Subtask::get
 when task forked after shutdown [v2]
In-Reply-To: <z-3TaZciA4WWzfx2yFiv7wEz_8hiTnO6kNEQryPiTGU=.0883d54f-74b6-4d03-9704-0c81829dd7be@github.com>
References: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
 <z-3TaZciA4WWzfx2yFiv7wEz_8hiTnO6kNEQryPiTGU=.0883d54f-74b6-4d03-9704-0c81829dd7be@github.com>
Message-ID: <SFlRYCQNZ1Kg5bo6klUO0kTPkgpAowlDqhTWwYmRe9Y=.bdf905e9-d09c-4e39-953a-8b2ef32b1be1@github.com>

On Wed, 16 Aug 2023 16:16:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Very minor suggestion, up to you. We could change the exception message thrown by `SubtaskImpl::get` to:
> 
> > Subtask result is unavailable or did not complete successfully
> 
> (Similar change for `SubtaskImpl::exception`.) That leans into the terminology more.

Okay, it's probably a good time to do that. It's also tempting to change the description of the ISE thrown by get and exception but I'll sit that on for a while.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15076#issuecomment-1682518112

From darcy at openjdk.org  Thu Aug 17 17:22:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 17:22:09 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms [v2]
In-Reply-To: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
Message-ID: <i-2iUu0xJ9Pic0S-4mk7zsP9HA1wDNvOCUOwNyVKrm4=.87bef89f-159e-46fc-a26d-20097229f69f@github.com>

> Use of javadoc search index feature; I'll re-flow paragraphs before pushing once the wording is agreed to.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15322/files
  - new: https://git.openjdk.org/jdk/pull/15322/files/0bf30783..26438061

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15322&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15322&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15322.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15322/head:pull/15322

PR: https://git.openjdk.org/jdk/pull/15322

From darcy at openjdk.org  Thu Aug 17 17:22:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 17:22:11 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms [v2]
In-Reply-To: <3lEvfPG45vx_la0HeAWOW7hallZwoJFQY9AWl-D5-fs=.f4ccb090-7ecd-47ca-9484-61815fddb648@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
 <3lEvfPG45vx_la0HeAWOW7hallZwoJFQY9AWl-D5-fs=.f4ccb090-7ecd-47ca-9484-61815fddb648@github.com>
Message-ID: <eF9ByXiXbgFc_D4RsZ8ON09SCDcIaLFjlV4uKY29ZIM=.47a29130-b128-498f-a6ce-e27de5dccfdc@github.com>

On Thu, 17 Aug 2023 13:00:40 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What about `<i>semi-monotonic</i>` on L.80? Does it deserve to be tagged as `<dfn>` and indexed?

Good idea; added. The term "IEEE 754" is already index from various section titles so I didn't add an index item for that explicitly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15322#issuecomment-1682670512

From darcy at openjdk.org  Thu Aug 17 17:22:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 17:22:13 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms [v2]
In-Reply-To: <STiCPBqiWjZrrBFNqxZqk-c4SNA0MX-URL21idCP3CY=.7c446516-a93f-4413-9020-53ef8cb16256@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
 <STiCPBqiWjZrrBFNqxZqk-c4SNA0MX-URL21idCP3CY=.7c446516-a93f-4413-9020-53ef8cb16256@github.com>
Message-ID: <RUoP_WsB7qH9P5WPY-4FV60NOu8CC7mVJghmpyREx7w=.0b6bd5e0-e016-4e0e-aa6d-bb4f9ddb0940@github.com>

On Thu, 17 Aug 2023 08:32:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay to me. You might want to move the "For a" on L58 to the next line to avoid L58 stick out too much, up to you.

Sure; I usually prefer to re-flow the paragraphs after the text changes are agreed to so the difference is easier to see along the way.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15322#issuecomment-1682671784

From darcy at openjdk.org  Thu Aug 17 17:31:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 17:31:32 GMT
Subject: RFR: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms [v3]
In-Reply-To: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
Message-ID: <cJOHFwERHye1Y4Cgauu0nNsZrHynV217EP8GvJc0a58=.abe04613-b2ff-45bb-9d58-c947ad04aa9d@github.com>

> Use of javadoc search index feature; I'll re-flow paragraphs before pushing once the wording is agreed to.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Reflow-paragraphs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15322/files
  - new: https://git.openjdk.org/jdk/pull/15322/files/26438061..73dfc7f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15322&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15322&range=01-02

  Stats: 37 lines in 1 file changed: 2 ins; 0 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/15322.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15322/head:pull/15322

PR: https://git.openjdk.org/jdk/pull/15322

From darcy at openjdk.org  Thu Aug 17 17:35:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 17 Aug 2023 17:35:39 GMT
Subject: Integrated: JDK-8314489: Add javadoc index entries for java.lang.Math
 terms
In-Reply-To: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
References: <QbmERHZZFVj-9g9RWwUFib9YP0OgvvN6EV1bEjYB_o4=.68e7692b-ca6d-4ae1-aae5-070f0a1cb93f@github.com>
Message-ID: <TJ1lzGPY5ky-CYsQ1iPo-nerFg5d5-2E0LQwgXBkGSI=.fa2a9b5b-da41-4d15-9358-2213279befbc@github.com>

On Thu, 17 Aug 2023 04:52:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Use of javadoc search index feature; I'll re-flow paragraphs before pushing once the wording is agreed to.

This pull request has now been integrated.

Changeset: 3bb8afba
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bb8afba691965e9036b04b9c7e4727b4c29e776
Stats:     38 lines in 1 file changed: 2 ins; 1 del; 35 mod

8314489: Add javadoc index entries for java.lang.Math terms

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15322

From aturbanov at openjdk.org  Thu Aug 17 18:35:38 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 17 Aug 2023 18:35:38 GMT
Subject: Integrated: 8314129: Make fields final in java.util.Scanner
In-Reply-To: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
References: <8OKKfxrAhjzpV3owlxFFDGev29Fb2mF3odMwWXIlkxE=.2cbdad9d-6e09-4865-8b3c-fd74bffb9eae@github.com>
Message-ID: <cApIb77dYOvv-StM_E3nMfhoxEoXEMwfUerX7u03mH8=.d89f3a5b-3aa0-4349-88db-c49cab3f597e@github.com>

On Thu, 13 Jul 2023 08:57:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Made a few fields `final` in java.util.Scanner.
> Also made `digits`, `non0Digit`, `SIMPLE_GROUP_INDEX` as `static.`

This pull request has now been integrated.

Changeset: d27daf01
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d27daf01d6361513a815e78327961f9367887163
Stats:     34 lines in 1 file changed: 17 ins; 0 del; 17 mod

8314129: Make fields final in java.util.Scanner

Reviewed-by: stsypanov, liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14863

From dl at openjdk.org  Thu Aug 17 19:06:33 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 17 Aug 2023 19:06:33 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v6]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <dWz4jkqFkpDm9F3p8JvGzuBMJCS-O-ptql9w15U335s=.f534f429-7fd3-44f5-8448-83cbae709636@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 48 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Pass through cancellations in FJ tests
 - Avoid false-alarm failures on shutdown
 - Merge branch 'openjdk:master' into JDK-8288899
 - Update @since tags
 - resync
 - Merge branch 'openjdk:master' into JDK-8288899
 - ExecutorService tests
 - Merge branch 'openjdk:master' into JDK-8288899
 - Rework versioning
 - ... and 38 more: https://git.openjdk.org/jdk/compare/c7aafe3e...11b9d732

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/901f5bdd..11b9d732

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=04-05

  Stats: 8160 lines in 274 files changed: 5118 ins; 313 del; 2729 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From dl at openjdk.org  Thu Aug 17 19:13:16 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 17 Aug 2023 19:13:16 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v7]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <i3y2UdqnEMnzLBs_Phf6WEM4MJRegYVgEXDQv5clyF4=.0c787737-10d1-4b6b-ad97-79044013d292@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Allow cancel in checkCompletedAbnormally

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/11b9d732..7ad962d4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=05-06

  Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From rriggs at openjdk.org  Thu Aug 17 19:53:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 17 Aug 2023 19:53:30 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <nCmpCRcYhVyK_AvhEAnV36abG59d0MH3u8rJbHq5-BU=.07c0a471-f625-43de-a5d3-06afc1943b48@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <FlrRm94KmjHEavB26YVcGVRzhT8920ftdHCJXWX5plY=.4e56fa80-eb5e-4dc4-a366-b37d26508bd8@github.com>
 <nCmpCRcYhVyK_AvhEAnV36abG59d0MH3u8rJbHq5-BU=.07c0a471-f625-43de-a5d3-06afc1943b48@github.com>
Message-ID: <u6eIEMrZAv_uBWroDTgqwCUV_mHep0H4pS9BFu9XYbM=.d756a536-cda1-4619-b0a8-ee6f0afd2bcd@github.com>

On Thu, 17 Aug 2023 07:54:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 773:
>> 
>>> 771:                String sharingMode = "shared";
>>> 772:                if (!shared) sharingMode = "nonshared";
>>> 773:                throw(new BackingStoreException("Couldn't get file lock. errno is " + errCode + " mode is " + sharingMode));
>> 
>> A raw errno is pretty uninformative, except for experts. Can the errno be translated to a string as well as supplying the errno?
>
> Hi Roger,  sounds like a good idea  to translate it to a more informative string.
> Do you have an  utility function in mind that does this ?

Not trivial in java, there are platform specific native functions to get the string for the current errno.
The function definition for `getLastErrorString` is in jni_uti.h, returning a java String.

If there are only a couple of errno's that occur for these cases, it might be easier to hardwire the translation.
Otherwise, an appropriate native method call and implementation could be added to FileSystemPreferences.c for both unix and windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1297672699

From duke at openjdk.org  Thu Aug 17 21:20:04 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 17 Aug 2023 21:20:04 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v4]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <JZw_zlwJPX6eVcPSQqGJAE50_tO4A_Zf9rlshS0vcy0=.ad7cd802-7244-42bc-9e3c-027c73fd54f8@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  refactor the code and remove pre-created keystore

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/0cae2343..e4898a54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=02-03

  Stats: 131 lines in 3 files changed: 46 ins; 54 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Thu Aug 17 21:24:29 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 17 Aug 2023 21:24:29 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v4]
In-Reply-To: <JZw_zlwJPX6eVcPSQqGJAE50_tO4A_Zf9rlshS0vcy0=.ad7cd802-7244-42bc-9e3c-027c73fd54f8@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <JZw_zlwJPX6eVcPSQqGJAE50_tO4A_Zf9rlshS0vcy0=.ad7cd802-7244-42bc-9e3c-027c73fd54f8@github.com>
Message-ID: <IEOoSB4eLG9BxvLKGYV36pFjdDIonHA7BHgAfKBPyqw=.6ff43c6f-84ca-4ed5-929d-a7b92893e443@github.com>

On Thu, 17 Aug 2023 21:20:04 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the code and remove pre-created keystore

1) Refactor the code according to the suggestion
2) Removed the pre-created key store and re-create it at the runtime.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1682997687

From martin at openjdk.org  Thu Aug 17 22:42:55 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Thu, 17 Aug 2023 22:42:55 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
Message-ID: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>

The usual tiny improvements, with no guarantee that the intermittent test failure is actually fixed.

-------------

Commit messages:
 - JDK-8314515

Changes: https://git.openjdk.org/jdk/pull/15337/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15337&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314515
  Stats: 29 lines in 1 file changed: 7 ins; 3 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15337.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15337/head:pull/15337

PR: https://git.openjdk.org/jdk/pull/15337

From jlu at openjdk.org  Thu Aug 17 22:44:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 17 Aug 2023 22:44:33 GMT
Subject: Integrated: 8314169: Combine related RoundingMode logic in
 j.text.DigitList
In-Reply-To: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
References: <RxJh9O3owsF0yR7QBp5I0UNHt6YBgi4SBWtVxXHgDJI=.8b177e57-60aa-4ead-ae15-ae8683e2d957@github.com>
Message-ID: <weaZvJKRk-o3Qit4eFxvbKuyl771D2QObvRWmMsQIsg=.34d08f3b-b268-4159-9d01-b0c15bfd86b5@github.com>

On Fri, 11 Aug 2023 18:27:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a broad clean up of the DigitList class (used by Format classes in j.text).
> 
> This PR is intended to be a portion of a bigger change (split up to make reviewing easier). 
> 
> The main change simplifying related Rounding Mode logic in `shouldRoundUp()` - (_CEILING/FLOOR_, _HALF_UP/DOWN/EVEN_)
> 
> Other changes include
> - Certain for loops can be replaced with cleaner syntax (E.g. for(;;), empty for loops)
> - Introduce `roundInt(int)` - For use by Integer representations of DigitList
> - Introduce `nonZeroAfterIndex(int)` - To reduce code duplication

This pull request has now been integrated.

Changeset: 96778dd5
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96778dd549b596d8884376b19a49aa152efb377b
Stats:     159 lines in 1 file changed: 57 ins; 74 del; 28 mod

8314169: Combine related RoundingMode logic in j.text.DigitList

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15252

From dl at openjdk.org  Thu Aug 17 22:55:06 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 17 Aug 2023 22:55:06 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v8]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <8Mf1F7v9PhK3fko1WgUyjznoGNht5tZJpHEriPOogFE=.9fd29e1b-b75d-4b8d-bd09-5e68fef080d0@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/7ad962d4..27f7357b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From duke at openjdk.org  Fri Aug 18 04:03:49 2023
From: duke at openjdk.org (Martin Stypinski)
Date: Fri, 18 Aug 2023 04:03:49 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API
Message-ID: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>

Added a bunch of different implementations for Vector API Matrix Multiplications:

- Baseline
- Blocked (Cache Local)
- FMA
- Vector API Simple Implementation
- Vector API Blocked Implementation

Commit was discussed with @PaulSandoz

-------------

Commit messages:
 - fixed some style issues
 - added MatrixMultiplicationBenchmark
 - Merge pull request #1 from openjdk/master

Changes: https://git.openjdk.org/jdk/pull/15338/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15338&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314544
  Stats: 185 lines in 1 file changed: 185 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15338/head:pull/15338

PR: https://git.openjdk.org/jdk/pull/15338

From duke at openjdk.org  Fri Aug 18 04:41:25 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 18 Aug 2023 04:41:25 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v12]
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <qACUze-oBrGVYz2Y_VncUpItwg-pfrtkDVwyOgASmtw=.a7acdd61-56af-40c1-9480-921a3e9041d8@github.com>

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

sid8606 has updated the pull request incrementally with two additional commits since the last revision:

 - Calculate the code size.
 - Fix missing spcaces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14801/files
  - new: https://git.openjdk.org/jdk/pull/14801/files/a28c92d6..dad186f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14801&range=10-11

  Stats: 11 lines in 3 files changed: 0 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14801/head:pull/14801

PR: https://git.openjdk.org/jdk/pull/14801

From duke at openjdk.org  Fri Aug 18 04:41:30 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 18 Aug 2023 04:41:30 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v11]
In-Reply-To: <5j-qoK4YcY7h8xUGAGnrumzLQ3pWplhlGesEEhV6MFA=.987f91c3-e920-4b3a-b961-b54baadb758e@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <hL5ZOeYFzAQqNogQG5Z6TF7NTN7IpNeTrn73eMWSY3U=.410d952f-5d9d-463d-9635-a544a35034f9@github.com>
 <5j-qoK4YcY7h8xUGAGnrumzLQ3pWplhlGesEEhV6MFA=.987f91c3-e920-4b3a-b961-b54baadb758e@github.com>
Message-ID: <IfDGYIEI24U0f26mgR9NVJ9k_LR53X3AO4apOZrKxZI=.754bfead-5284-4a5b-96ea-cb1377139479@github.com>

On Tue, 8 Aug 2023 09:59:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> sid8606 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>>   
>>   Signed-off-by: Sidraya <sidraya.jayagond at ibm.com>
>
> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 95:
> 
>> 93: 
>> 94: static const int native_invoker_code_base_size = 384;
>> 95: static const int native_invoker_size_per_args = 8;
> 
> Sizes were taken from PPC64. Are they correct for s390?

Calculated code size and rounded off as per the s390x cache line size. Thank you

> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 156:
> 
>> 154: #endif
>> 155: 
>> 156:   int allocated_frame_size = 0;
> 
> Line not needed.

Fixed. Thank you

> src/hotspot/cpu/s390/downcallLinker_s390.cpp line 163:
> 
>> 161:   assert(!_needs_return_buffer, "unexpected needs_return_buffer");
>> 162:   RegSpiller out_reg_spiller(_output_registers);
>> 163:   int spill_offset = -1;
> 
> Line not needed.

Fixed. Thank you

> src/hotspot/cpu/s390/foreignGlobals_s390.cpp line 130:
> 
>> 128:       }
>> 129:       switch (to_reg.stack_size()) {
>> 130:         case 8: __ reg2mem_opt(as_Register(from_reg), Address(Z_SP, reg2offset(to_reg, out_bias)), true);break;
> 
> Coding style: Spaces missing.

Fixed. Thank you

> src/hotspot/cpu/s390/upcallLinker_s390.cpp line 118:
> 
>> 116: 
>> 117: static const int upcall_stub_code_base_size = 1536; // depends on GC (resolve_jobject)
>> 118: static const int upcall_stub_size_per_arg = 16; // arg save & restore + move
> 
> Again sizes from PPC64. Should be checked!

Calculated code size and rounded off as per the s390x cache line size. Thank you

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994858
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994949
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994309
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994258
PR Review Comment: https://git.openjdk.org/jdk/pull/14801#discussion_r1297994768

From mbaesken at openjdk.org  Fri Aug 18 07:59:26 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Aug 2023 07:59:26 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <u6eIEMrZAv_uBWroDTgqwCUV_mHep0H4pS9BFu9XYbM=.d756a536-cda1-4619-b0a8-ee6f0afd2bcd@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <FlrRm94KmjHEavB26YVcGVRzhT8920ftdHCJXWX5plY=.4e56fa80-eb5e-4dc4-a366-b37d26508bd8@github.com>
 <nCmpCRcYhVyK_AvhEAnV36abG59d0MH3u8rJbHq5-BU=.07c0a471-f625-43de-a5d3-06afc1943b48@github.com>
 <u6eIEMrZAv_uBWroDTgqwCUV_mHep0H4pS9BFu9XYbM=.d756a536-cda1-4619-b0a8-ee6f0afd2bcd@github.com>
Message-ID: <Lg-GJaDd4fPPJOwLg8PvxptJgZLPIPZohw-ku_WWhAQ=.5746bf8f-2361-41d2-8290-738e5ad34b54@github.com>

On Thu, 17 Aug 2023 19:50:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi Roger,  sounds like a good idea  to translate it to a more informative string.
>> Do you have an  utility function in mind that does this ?
>
> Not trivial in java, there are platform specific native functions to get the string for the current errno.
> The function definition for `getLastErrorString` is in jni_uti.h, returning a java String.
> 
> If there are only a couple of errno's that occur for these cases, it might be easier to hardwire the translation.
> Otherwise, an appropriate native method call and implementation could be added to FileSystemPreferences.c for both unix and windows.

Hi Roger , seems we can get errno numbers at least from open and fcntl , see
Java_java_util_prefs_FileSystemPreferences_lockFile0
https://github.com/openjdk/jdk/blob/master/src/java.prefs/unix/native/libprefs/FileSystemPreferences.c#L70

Those functions have quite a few potential errnos, from the Linux manpages at least those
https://man7.org/linux/man-pages/man2/open.2.html
https://man7.org/linux/man-pages/man2/fcntl.2.html
EACCES 
EAGAIN 
EBADF  
EBUSY
EDEADLK
EDQUOT
EEXIST 
EFAULT 
EFBIG  See EOVERFLOW.
EINTR  
EINVAL 
EISDIR 
ELOOP  
EMFILE 
ENAMETOOLONG
ENFILE 
ENODEV 
ENOENT 
ENOLCK 
ENOMEM
ENOSPC 
ENOTDIR
ENXIO  
EOPNOTSUPP
EOVERFLOW
EPERM  
EROFS  
ETXTBSY
EWOULDBLOCK

I noticed src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template contains some of them, should I add the missing ones there and reference from there ?

Btw. when looking at Java_java_util_prefs_FileSystemPreferences_lockFile0  should we better initialize
`int result[2]`
https://github.com/openjdk/jdk/blob/master/src/java.prefs/unix/native/libprefs/FileSystemPreferences.c#L74
There seems to be a codepath where  result[1] is never written but at the end used to fill javeResult
https://github.com/openjdk/jdk/blob/master/src/java.prefs/unix/native/libprefs/FileSystemPreferences.c#L117

 this looks a bit problematic ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15308#discussion_r1298136160

From duke at openjdk.org  Fri Aug 18 08:20:31 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 18 Aug 2023 08:20:31 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>
References: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>
Message-ID: <QfOWynwrzQcWOBK_OFckRXbbAiJM3F1h7yfZDurX4Dw=.6af94d21-35a9-4bf7-8c42-890c636b3610@github.com>

On Thu, 17 Aug 2023 22:35:39 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> The usual tiny improvements, with no guarantee that the intermittent test failure is actually fixed.

test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 41:

> 39:         throws Throwable
> 40:     {
> 41:         int threadCount = ThreadLocalRandom.current().nextInt(2, 8);

@Martin-Buchholz I'm a bit weary about making the number of threads random?might make it tricky to get to reproduce if the test fails?

test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 55:

> 53:             Thread t = new Thread(put);
> 54:             t.start();
> 55:             ts.add(t);

@Martin-Buchholz Any specific reason to add the thread *after* it has been started?

test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 70:

> 68:                                               fair, i, threadCount, j));
> 69:         }
> 70:         for (Thread t : ts) t.join();

@Martin-Buchholz Makes a lot of sense to make sure that all threads have terminated before exiting the test ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15337#discussion_r1298155867
PR Review Comment: https://git.openjdk.org/jdk/pull/15337#discussion_r1298157572
PR Review Comment: https://git.openjdk.org/jdk/pull/15337#discussion_r1298158247

From mdoerr at openjdk.org  Fri Aug 18 08:22:41 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 18 Aug 2023 08:22:41 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v12]
In-Reply-To: <qACUze-oBrGVYz2Y_VncUpItwg-pfrtkDVwyOgASmtw=.a7acdd61-56af-40c1-9480-921a3e9041d8@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <qACUze-oBrGVYz2Y_VncUpItwg-pfrtkDVwyOgASmtw=.a7acdd61-56af-40c1-9480-921a3e9041d8@github.com>
Message-ID: <30UqWPs530NugPVkGESGKTIwoqUlXLh4BYZsRgLkajQ=.16105e12-3aca-4ec4-bc35-472aff07f988@github.com>

On Fri, 18 Aug 2023 04:41:25 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Calculate the code size.
>  - Fix missing spcaces

Thanks for cleaning it up. LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14801#pullrequestreview-1584089670

From duke at openjdk.org  Fri Aug 18 09:08:31 2023
From: duke at openjdk.org (sid8606)
Date: Fri, 18 Aug 2023 09:08:31 GMT
Subject: RFR: 8311630: [s390] Implementation of Foreign Function & Memory
 API (Preview) [v12]
In-Reply-To: <qACUze-oBrGVYz2Y_VncUpItwg-pfrtkDVwyOgASmtw=.a7acdd61-56af-40c1-9480-921a3e9041d8@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
 <qACUze-oBrGVYz2Y_VncUpItwg-pfrtkDVwyOgASmtw=.a7acdd61-56af-40c1-9480-921a3e9041d8@github.com>
Message-ID: <NYdZnIZ4rtAeK8PEDR_fPYsIhiwjpbza0eohBvPlBR0=.0389dfe6-f5e2-4e52-a873-6f5bbbfcc73b@github.com>

On Fri, 18 Aug 2023 04:41:25 GMT, sid8606 <duke at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).
>
> sid8606 has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Calculate the code size.
>  - Fix missing spcaces

Thanks a lot for all discussions, feedback and the reviews! This was really helpful! I'm planning to integrate tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14801#issuecomment-1683601556

From cstein at openjdk.org  Fri Aug 18 09:53:48 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 18 Aug 2023 09:53:48 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
Message-ID: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>

Please review the change to update to using jtreg 7.3,1.

The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.

This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda

This change set also fixes:
- https://bugs.openjdk.org/browse/JDK-8313902
- https://bugs.openjdk.org/browse/JDK-8313903

Testing: _tier1-tier5 pending..._

-------------

Commit messages:
 - Un-problem-list tests failing with jtreg 7.3
 - 8314495: Update to use jtreg 7.3.1

Changes: https://git.openjdk.org/jdk/pull/15323/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15323&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314495
  Stats: 12 lines in 9 files changed: 0 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15323.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15323/head:pull/15323

PR: https://git.openjdk.org/jdk/pull/15323

From dholmes at openjdk.org  Fri Aug 18 09:53:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Aug 2023 09:53:48 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <4iFRb_Qh7PqBCUiY84xDyDOK7GzCXKDCKyz6eBwIBZI=.387bf6ce-d2f2-481f-9a38-74f97629828d@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: _tier1-tier5 pending..._

Looks good to me!

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1582016262

From mbaesken at openjdk.org  Fri Aug 18 12:04:30 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Aug 2023 12:04:30 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

I checked the usage of sun/nio/fs/UnixConstants.java and seems we would need to make the class public and an additional export for this like

     exports sun.nio.fs to
+        java.prefs,
         jdk.net;

would this be acceptable ? I could image there are more places in the JDK codebase where this might be interesting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1683817599

From erikj at openjdk.org  Fri Aug 18 12:16:28 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 18 Aug 2023 12:16:28 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <ve4sUGJ7RG5ZnxRBh7da6nx-MSdPm59lUj5R9RRk4PM=.2568d8c8-c125-4d0f-8a78-bf598f707728@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: _tier1-tier5 pending..._

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1584457571

From jpai at openjdk.org  Fri Aug 18 12:17:27 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 18 Aug 2023 12:17:27 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <SvMObwRjzrMi_pwCj6bexMu4i0TkleitBcuhmN0AXhw=.dd561d80-f118-47c2-b3fb-73a4bab5a8fe@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

Hello Matthias, I think adding some diagnostics in this class would be a good thing. Like in the JBS issue that this PR links to, there's another JBS issue https://bugs.openjdk.org/browse/JDK-8304938 where we run into intermittent failures because of this exception.

However, before doing the changes being proposed in this PR, would it be better to do those (minimal) changes in a private build and run those tests and see if these proposed error number or error message diagnostics do provide the needed detail to narrow down this issue? That might provide insight on what else (if anything) would need to be included in that diagnostic message.

In the meantime, I'll run your proposed change which shows the error number, just to see if that tells us what's going on with these tests, when they fail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1683831684

From mbaesken at openjdk.org  Fri Aug 18 12:33:30 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 18 Aug 2023 12:33:30 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <SvMObwRjzrMi_pwCj6bexMu4i0TkleitBcuhmN0AXhw=.dd561d80-f118-47c2-b3fb-73a4bab5a8fe@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <SvMObwRjzrMi_pwCj6bexMu4i0TkleitBcuhmN0AXhw=.dd561d80-f118-47c2-b3fb-73a4bab5a8fe@github.com>
Message-ID: <kb_0ho4zYNDkj78Z7RGY5T_3GP4hXAdQOO4YqCFSFUQ=.175c64f3-b393-4e69-b525-1b0475de2b07@github.com>

On Fri, 18 Aug 2023 12:14:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Matthias, I think adding some diagnostics in this class would be a good thing. Like in the JBS issue that this PR links to, there's another JBS issue https://bugs.openjdk.org/browse/JDK-8304938 where we run into intermittent failures because of this exception.
> 
> However, before doing the changes being proposed in this PR, would it be better to do those (minimal) changes in a private build and run those tests and see if these proposed error number or error message diagnostics do provide the needed detail to narrow down this issue? That might provide insight on what else (if anything) would need to be included in that diagnostic message.
> 
> In the meantime, I'll run your proposed change which shows the error number, just to see if that tells us what's going on with these tests, when they fail.

the enhanced output in a failing sun/tools/jhsdb/JStackStressTest.java  is 

java.util.prefs.BackingStoreException: Couldn't get file lock. errno is 11 mode is nonshared

errno  11 seems to be EAGAIN. Unfortunately  even the enhanced message does not tell me if it is a failure of open or fcntl in the native layer , that would be good to know.  
We see this issue mostly on a particular Linux machine, probably I should ask the admins what's 'special' about this machine ....

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1683850190

From alanb at openjdk.org  Fri Aug 18 12:38:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Aug 2023 12:38:27 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>
Message-ID: <8aZ1XXA5YT0_OrCRIiLwgqvJej8B14ywflAtXS7M264=.9f655668-9bf4-41af-9e6e-b5ee32da13d0@github.com>

On Fri, 18 Aug 2023 12:02:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> I checked the usage of sun/nio/fs/UnixConstants.java and seems we would need to make the class public and an additional export for this like
> 
> ```
>      exports sun.nio.fs to
> +        java.prefs,
>          jdk.net;
> ```
> 
> would this be acceptable ?

No, I don't think the legacy prefs API being coupled to internals like this. Instead I think this is case where the prefs natives will need to use strerror.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1683856641

From duke at openjdk.org  Fri Aug 18 13:20:50 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 18 Aug 2023 13:20:50 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v5]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <8ffB5tlUHiMqPbOjIa4NRFYC0ao8knC3J-eXUEntswg=.70a82464-0295-4994-a6b5-780d0e7fc064@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the Connection code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/e4898a54..3df1b6cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=03-04

  Stats: 58 lines in 1 file changed: 21 ins; 11 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Fri Aug 18 13:30:54 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 18 Aug 2023 13:30:54 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v6]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <swyQgQ1mHIRiOLcbv81XUiBauusoCsnY09Y6DjFtUD4=.299db019-aabc-47fc-adee-c49845df5c9e@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  re-write close method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/3df1b6cc..ac72c3d8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=04-05

  Stats: 18 lines in 1 file changed: 1 ins; 13 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Fri Aug 18 13:30:55 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 18 Aug 2023 13:30:55 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v5]
In-Reply-To: <8ffB5tlUHiMqPbOjIa4NRFYC0ao8knC3J-eXUEntswg=.70a82464-0295-4994-a6b5-780d0e7fc064@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <8ffB5tlUHiMqPbOjIa4NRFYC0ao8knC3J-eXUEntswg=.70a82464-0295-4994-a6b5-780d0e7fc064@github.com>
Message-ID: <8eSzAhvZw2v4VZ303lBNF9SNKw3pYnUCVOrH74zzvNs=.83673f19-9dd2-4d93-93d7-160870b3fe4c@github.com>

On Fri, 18 Aug 2023 13:20:50 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the Connection code

1) Please ignore the previous change for Connection.java
2) Refactor the method of createSocket
3) Re-write closedOpenedSocket, and remove closeSocket method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1683918936

From erikj at openjdk.org  Fri Aug 18 14:30:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 18 Aug 2023 14:30:54 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated source
Message-ID: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>

In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.

-------------

Commit messages:
 - JDK-8314483

Changes: https://git.openjdk.org/jdk/pull/15346/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15346&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314483
  Stats: 43 lines in 4 files changed: 34 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15346/head:pull/15346

PR: https://git.openjdk.org/jdk/pull/15346

From mchung at openjdk.org  Fri Aug 18 17:13:37 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 18 Aug 2023 17:13:37 GMT
Subject: Integrated: 8310815: Clarify the name of the main class,
 services and provider classes in module descriptor
In-Reply-To: <sFl8a99xmRocPxZCyqP1bF4wy2chKMbimkWrrzycJmw=.ac327770-7242-4b9d-9c4c-9e0d805b7a4b@github.com>
References: <sFl8a99xmRocPxZCyqP1bF4wy2chKMbimkWrrzycJmw=.ac327770-7242-4b9d-9c4c-9e0d805b7a4b@github.com>
Message-ID: <4xKEU2dMNiSwz3osINDFhScIRBwyXuuuGCUqsN5pj1c=.700799a0-39bf-44d6-9407-0b3bea66e2c2@github.com>

On Wed, 16 Aug 2023 18:42:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Clarify the spec of `ModuleDescriptor::mainClass`, `ModuleDescriptor::uses`, `ModuleDescriptor.Provides::service` and `ModuleDescriptor.Provides::providers` to return a binary name. 
> 
> This PR also fixes JDK-8314449 to update the spec of `StackTraceElement::getClassName` and the `declaringClass` parameter of the constructor.

This pull request has now been integrated.

Changeset: 50a2ce01
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/50a2ce01f4d1d42d7a537b48a669b5a75a583df5
Stats:     25 lines in 2 files changed: 3 ins; 4 del; 18 mod

8310815: Clarify the name of the main class, services and provider classes in module descriptor
8314449: Clarify the name of the declaring class of StackTraceElement

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15317

From btaylor at openjdk.org  Fri Aug 18 17:33:02 2023
From: btaylor at openjdk.org (Ben Taylor)
Date: Fri, 18 Aug 2023 17:33:02 GMT
Subject: [jdk21] RFR: 8313765: Invalid CEN header (invalid zip64 extra data
 field size)
Message-ID: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>

Backport is clean, all tests in test/jdk/java/util/zip pass.

-------------

Commit messages:
 - Backport 13f6450e2e70df4df8bd882def837fbd5bef1524

Changes: https://git.openjdk.org/jdk21/pull/173/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=173&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313765
  Stats: 1004 lines in 4 files changed: 986 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/jdk21/pull/173.diff
  Fetch: git fetch https://git.openjdk.org/jdk21.git pull/173/head:pull/173

PR: https://git.openjdk.org/jdk21/pull/173

From alanb at openjdk.org  Fri Aug 18 17:51:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Aug 2023 17:51:36 GMT
Subject: [jdk21] RFR: 8313765: Invalid CEN header (invalid zip64 extra data
 field size)
In-Reply-To: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
References: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
Message-ID: <ytWR0v0lsKFEXAM6LcoNuDlIu2as1E7Pe4ArYmX5i5U=.d071cfb7-f9b7-48bf-b89d-fbaf5a3f74fd@github.com>

On Fri, 18 Aug 2023 17:25:10 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Backport is clean, all tests in test/jdk/java/util/zip pass.

JDK 21 is at RC, only P1 issues with approval. There is already a fix request for jdk21u. The 21.0.1 release is only a few weeks after JDK 21.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/173#issuecomment-1684240722

From serb at openjdk.org  Fri Aug 18 18:01:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 18 Aug 2023 18:01:35 GMT
Subject: [jdk21] RFR: 8313765: Invalid CEN header (invalid zip64 extra data
 field size)
In-Reply-To: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
References: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
Message-ID: <_KmNbozlo14Q4je93-Ck2-lM4KQ79qX8OO_86JqLCY4=.94ad7054-e4cf-4072-bba7-e4e3ef4bf8a7@github.com>

On Fri, 18 Aug 2023 17:25:10 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Backport is clean, all tests in test/jdk/java/util/zip pass.

It is strange that there is a request for jdk21u but there is no PR for that repo.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/173#issuecomment-1684250803

From btaylor at openjdk.org  Fri Aug 18 18:05:38 2023
From: btaylor at openjdk.org (Ben Taylor)
Date: Fri, 18 Aug 2023 18:05:38 GMT
Subject: [jdk21] RFR: 8313765: Invalid CEN header (invalid zip64 extra data
 field size)
In-Reply-To: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
References: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
Message-ID: <zPiVwfYu89Ku3xlewzBPep2_Smyam3aflKEO_uwXar0=.8fadbbf4-f1b8-49f3-b678-ebfd265e4225@github.com>

On Fri, 18 Aug 2023 17:25:10 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Backport is clean, all tests in test/jdk/java/util/zip pass.

My mistake, will create the PR against 21u.

-------------

PR Comment: https://git.openjdk.org/jdk21/pull/173#issuecomment-1684255033

From btaylor at openjdk.org  Fri Aug 18 18:05:39 2023
From: btaylor at openjdk.org (Ben Taylor)
Date: Fri, 18 Aug 2023 18:05:39 GMT
Subject: [jdk21] Withdrawn: 8313765: Invalid CEN header (invalid zip64 extra
 data field size)
In-Reply-To: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
References: <uGdsSouxXWPMZ2ERN8grviQbv2LNYtNzsGhN-X6h7oI=.e2831aa8-cca0-43a4-b142-fc265ec89798@github.com>
Message-ID: <H1pREmkU1HYGFqWmnLwhluY7kB-IP2t-gSuxdEj2ZUI=.cdef74a6-6c49-42d7-9de6-50c8b754bdc0@github.com>

On Fri, 18 Aug 2023 17:25:10 GMT, Ben Taylor <btaylor at openjdk.org> wrote:

> Backport is clean, all tests in test/jdk/java/util/zip pass.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk21/pull/173

From aefimov at openjdk.org  Fri Aug 18 18:19:37 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 18 Aug 2023 18:19:37 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v6]
In-Reply-To: <swyQgQ1mHIRiOLcbv81XUiBauusoCsnY09Y6DjFtUD4=.299db019-aabc-47fc-adee-c49845df5c9e@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <swyQgQ1mHIRiOLcbv81XUiBauusoCsnY09Y6DjFtUD4=.299db019-aabc-47fc-adee-c49845df5c9e@github.com>
Message-ID: <CodQTFFjxnwcEhmOWMuCiXSNRv2UyQmAu9tb9ZlzwxI=.04f1480c-23f8-4a40-970d-58d0f26e02a5@github.com>

On Fri, 18 Aug 2023 13:30:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-write close method

Changes requested by aefimov (Reviewer).

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 293:

> 291:             } else { // NO SocketFactory
> 292:                 // create a connected socket without factory
> 293:                 createConnectionSocket(endpoint, connectTimeout);

A socket returned by `createConnectionSocket` here needs to be saved to the `socket` variable - currently almost all of the tests that are not using a custom socket factory - fails with:

Caused by: java.lang.NullPointerException: Cannot invoke "java.net.Socket.getInputStream()" because "this.sock" is null
	at java.naming/com.sun.jndi.ldap.Connection.<init>(Connection.java:238)

-------------

PR Review: https://git.openjdk.org/jdk/pull/15294#pullrequestreview-1585010623
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1298730216

From iris at openjdk.org  Fri Aug 18 18:39:25 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 18 Aug 2023 18:39:25 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <3efOFjO6mEklYsdbGon5OWAsK7ffNDSd-lpSzMHnjCk=.264978af-605d-4943-ad17-e50dcb9b1416@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: tier1-tier5 OK

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1585041001

From rriggs at openjdk.org  Fri Aug 18 20:06:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Aug 2023 20:06:38 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v8]
In-Reply-To: <AVfJ8UE6_AT-iTUKEmZjreZLyOCvhnqCN86RVlr14Pk=.0044c604-bcd6-437e-9ba4-a7265c1a14f3@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <AVfJ8UE6_AT-iTUKEmZjreZLyOCvhnqCN86RVlr14Pk=.0044c604-bcd6-437e-9ba4-a7265c1a14f3@github.com>
Message-ID: <cjqkI-zHdskQxfJKMZRKA9X18JFlm6P6Ku5CXnmBWE8=.5669c6f4-0f1a-4535-a400-17e70cf7dec6@github.com>

On Thu, 10 Aug 2023 17:31:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

src/java.base/share/classes/java/text/ListFormat.java line 96:

> 94:  * round-trip with the corresponding formatting. For example, a String list
> 95:  * "a, b,", "c" will be formatted as "a, b, and c", but may be parsed as
> 96:  * "a", "b", "c".

Suggestion:

  * round-trip with the corresponding formatting. For example, a two element String list
 * "a, b,", "c" will be formatted as "a, b, and c", but may be parsed as three elements
 * "a", "b", "c".

src/java.base/share/classes/java/text/ListFormat.java line 240:

> 238:      * is thrown.
> 239:      * <p>
> 240:      * Each pattern string is first parsed as follows. Patterns in parentheses are optional:

The characters in parentheses are arbitrary and literal strings; not really "patterns" in the regex sense.

src/java.base/share/classes/java/text/ListFormat.java line 246:

> 244:      * end := {0}end_between{1}(end_after)
> 245:      * two := (two_before){0}two_between{1}(two_after)
> 246:      * three := (three_before){0}three_between{1}three_between{2}(three_after)

The use of "three_between" in 2 positions may mislead the developer to think they need to be the same string.
Perhaps "three_between1" and "three_between2"? or something to differentiate them.

src/java.base/share/classes/java/text/ListFormat.java line 250:

> 248:      * If parsing of the pattern string for start/middle/end fails, it throws an
> 249:      * {@code IllegalArgumentException}. If two/three pattern string is empty, or
> 250:      * fails on parsing, it falls back to

The IllegalArgumentException is thrown for a parse failure on any of the start, middle, end, two, or three patterns.
The fallback is only if they are null or empty.
A more readable form of "start/middle/end" would be "start, middle, or end".  Here and elsewhere in the javadoc.

src/java.base/share/classes/java/text/ListFormat.java line 262:

> 260:      * n > 3: (start_before){0}start_between{1}middle_between{2} ... middle_between{m}end_between{n}(end_after)
> 261:      * </pre></blockquote>
> 262:      * As an example, the following table shows patterns array which is equivalent to

Suggestion:

     * As an example, the following table shows a pattern array which is equivalent to

src/java.base/share/classes/java/text/ListFormat.java line 279:

> 277:      * <tr><th scope="row" style="text-align:left">2</th>
> 278:      *     <td>"{0} and {1}"</td>
> 279:      * <tr><th scope="row" style="text-align:left">3</th>

The use of different terms to identify pattern kinds of 2/two and 3/three may be confusing.
Unless it is referring to LDML, use "two" and "three" be used consistently.

src/java.base/share/classes/java/text/ListFormat.java line 304:

> 302:      * @param patterns array of patterns, not null
> 303:      * @throws IllegalArgumentException if the length {@code patterns} array is not 5, or
> 304:      *          any of {@code start}, {@code middle}, {@code end} patterns cannot be parsed.

Also throws if two and three patterns can not be parsed.

src/java.base/share/classes/java/text/ListFormat.java line 353:

> 351:             return generateMessageFormat(a).format(a, toAppendTo, DontCareFieldPosition.INSTANCE);
> 352:         } else {
> 353:             throw new IllegalArgumentException("The object to format should be an Object list");

Suggestion:

            throw new IllegalArgumentException("The object to format should be a List<Object> or List[] array");

src/java.base/share/classes/java/text/ListFormat.java line 364:

> 362:      * delimiters. For example, a String list {@code "a, b,", "c"} will be
> 363:      * formatted as {@code "a, b, and c"}, but may be parsed as
> 364:      * {@code "a", "b", "c"}.

Suggestion:

     * delimiters. For example, a two element String list {@code "a, b,", "c"} will be
     * formatted as {@code "a, b, and c"}, but may be parsed as three elements
     * {@code "a", "b", "c"}.

src/java.base/share/classes/java/text/ListFormat.java line 389:

> 387:      * use all characters up to the end of the string), and the parsed
> 388:      * object is returned. The updated {@code parsePos} can be used to
> 389:      * indicate the starting point for the next call to this method.

The "this method" seems too specific to ListFormat.
Suggestion:

     * indicate the starting point for the next call to parse additional text.

src/java.base/share/classes/java/text/ListFormat.java line 429:

> 427:             // now try exact number patterns
> 428:             parsed = new MessageFormat(patterns[TWO], locale).parseObject(source, parsePos);
> 429:             if (parsed == null && !patterns[THREE].isEmpty()) {

patterns[THREE] should never be null/empty.

src/java.base/share/classes/java/text/ListFormat.java line 451:

> 449:     @Override
> 450:     public AttributedCharacterIterator formatToCharacterIterator(Object arguments) {
> 451:         if (arguments instanceof List<?> objs) {

Should this method also support Object[].
And update the exception message below.

src/java.base/share/classes/java/text/ListFormat.java line 510:

> 508:                 } else {
> 509:                     yield new MessageFormat(createMessageFormatString(len), locale);
> 510:                 }

TWO and THREE patterns are always generated, so this if/else switch should not be needed.

src/java.base/share/classes/java/text/ListFormat.java line 591:

> 589:          * Suitable for elements, such as, "M", "T", "W", etc.
> 590:          */
> 591:         NARROW

The examples here are misleading (without explaining the source of the values).
The ListFormat does NOT change the strings supplied, it can only affect the text and punctuation literals that appear before, between, or after the elements of the list.

Suggestion:

         * The {@code FULL} list format style. This is the default style, which typically is the 
         * full description of the text and punctuation that appear between the list elements.
         * Suitable for elements, such as, "Monday", "Tuesday",  "Wednesday", etc.
         */
        FULL,

        /**
         * The {@code SHORT} list format style. This style is typically an abbreviation 
         * of the text and punctuation that appear between the list elements.
         * Suitable for elements, such as, "Mon", "Tue", "Wed", etc.
         */
        SHORT,

        /**
         * The {@code NARROW} list format style. This style is typically the shortest description 
         * of the text and punctuation that appear between the list elements.
         * Suitable for elements, such as, "M", "T", "W", etc.
         */
        NARROW

test/jdk/java/text/Format/ListFormat/TestListFormat.java line 261:

> 259:             assertEquals(input, f.parse(result));
> 260:         }
> 261:     }

There should be a test of `formatToCharacterIterator` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298790942
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298783724
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298781795
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298628165
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298784506
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298787272
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298791762
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298793675
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298794252
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298673908
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298798096
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298813568
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298642614
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298821495
PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298824618

From psandoz at openjdk.org  Fri Aug 18 20:12:30 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 18 Aug 2023 20:12:30 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API
In-Reply-To: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
References: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
Message-ID: <hO8hVOIstMcFXZnSwIo7RNtE38nlt1BAL_ojkorUsbU=.7d859b65-909e-4dcc-a7de-e1424bb47a58@github.com>

On Fri, 18 Aug 2023 03:57:24 GMT, Martin Stypinski <duke at openjdk.org> wrote:

> Added a bunch of different implementations for Vector API Matrix Multiplications:
> 
> - Baseline
> - Blocked (Cache Local)
> - FMA
> - Vector API Simple Implementation
> - Vector API Blocked Implementation
> 
> Commit was discussed with @PaulSandoz

test/micro/org/openjdk/bench/jdk/incubator/vector/MatrixMultiplicationBenchmark.java line 33:

> 31: 
> 32: import org.openjdk.jmh.annotations.*;
> 33: import org.openjdk.jmh.infra.Blackhole;

Unused import.

test/micro/org/openjdk/bench/jdk/incubator/vector/MatrixMultiplicationBenchmark.java line 176:

> 174: 
> 175:     private static float[] newFloatRowMatrix(int size) {
> 176:         Random rand = new Random();

Instead we can use the new random generator API e.g,:

var rand = RandomGenerator.getDefault();

This is not super important, but its good practice to try and use more preferred APIs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15338#discussion_r1298830226
PR Review Comment: https://git.openjdk.org/jdk/pull/15338#discussion_r1298830156

From rriggs at openjdk.org  Fri Aug 18 20:13:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 18 Aug 2023 20:13:27 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v8]
In-Reply-To: <AVfJ8UE6_AT-iTUKEmZjreZLyOCvhnqCN86RVlr14Pk=.0044c604-bcd6-437e-9ba4-a7265c1a14f3@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <AVfJ8UE6_AT-iTUKEmZjreZLyOCvhnqCN86RVlr14Pk=.0044c604-bcd6-437e-9ba4-a7265c1a14f3@github.com>
Message-ID: <DGKkiNntPBWexFUnkjakAMH0WEcj3wUeo9lbmzTF3yE=.57f951eb-4e7c-4742-a33f-852d675a0a7e@github.com>

On Thu, 10 Aug 2023 17:31:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

src/java.base/share/classes/java/text/ListFormat.java line 199:

> 197: 
> 198:     /**
> 199:      * {@return the list format object for the default

"list format" will read better using the class name `ListFormat`. Here an in other `getInstance` methods.
As is, in prose it looks like it returns some kind of list.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15130#discussion_r1298831450

From duke at openjdk.org  Fri Aug 18 21:31:31 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Fri, 18 Aug 2023 21:31:31 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v2]
In-Reply-To: <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>
 <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>
Message-ID: <Mh2N7mr2j-8gpRh1f9igAA5rPMFq6v-MrE8TPiTrzpc=.824b273a-5026-4f49-bd02-9c52ac2b3872@github.com>

On Tue, 15 Aug 2023 09:54:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8314236: change bug number and summary
>
> src/java.base/share/classes/java/util/Collections.java line 810:
> 
>> 808: 
>> 809:     private static <T> void rotate1(final List<T> list, int distance) {
>> 810:         final int size = list.size();
> 
> Let's keep the style, and do a focused fix: skip adding `final` here. (`final` mostly matters for fields).

Done. In order to be consistent I also removed `final` for `bound` variable.

> src/java.base/share/classes/java/util/Collections.java line 813:
> 
>> 811:         if (size == 0)
>> 812:             return;
>> 813:         distance %= size;
> 
> Same, let's keep the original style.

Done

> test/jdk/java/util/Collections/RotateHuge.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8314236
>> 27:  * @summary Overflow in Collections.rotate
> 
> Since this test takes >4G of heap to hold the list with compressed oops, and >8G of heap without compressed oops, we need to run it in a separate VM with enough headroom, something like this:
> 
> 
>  * @test
>  * @bug 8314236
>  * @summary Overflow in Collections.rotate
>  * @requires (sun.arch.data.model == "64" & os.maxMemory >= 16g)
>  * @run main/othervm -Xmx12g RotateHuge

Thanks! Done

> test/jdk/java/util/Collections/RotateHuge.java line 40:
> 
>> 38:         final List<Byte> list = new ArrayList<>(size);
>> 39:         for (int i = 0; i < size; ++i)
>> 40:             list.add((byte) 0);
> 
> We don't actually need to rely on auto-boxing here, right?
> 
> Suggestion:
> 
>         final Object o = new Object();
>         final List<Object> list = new ArrayList<>(size);
>         for (int i = 0; i < size; i++) {
>             list.add(o);
>         }

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294467547
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294466664
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294466347
PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1294467775

From duke at openjdk.org  Fri Aug 18 21:31:32 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Fri, 18 Aug 2023 21:31:32 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v2]
In-Reply-To: <fQnqt8E12cTShqzhOIZAwvvKjv1fiQeCBZfhHUNEv3Q=.c59f5048-9872-4e8c-a4b9-39cfe87d0db3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <N8_9aQ1u-evblRal6gdOjc9X0cUjpoSVIYDf3WrUCPs=.ab70604a-24c6-4c60-bb96-2e5f2018e3e3@github.com>
 <Uj21o3kVzMWaoCEWD9Wm_6FXx-Y3CLoVuBBgg1iMjMY=.3cccff73-d25c-4e33-9ed0-22cebd015735@github.com>
 <fQnqt8E12cTShqzhOIZAwvvKjv1fiQeCBZfhHUNEv3Q=.c59f5048-9872-4e8c-a4b9-39cfe87d0db3@github.com>
Message-ID: <ygwKMlBHaWdrLvC0TjPUeNYm4-Ihy1XdcDQ9MpXeY3I=.a13ccb65-e932-4f48-bbd5-f3fb19adb4b1@github.com>

On Wed, 16 Aug 2023 21:38:09 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Thanks! Done
>
> @nikita-sakharin
> 
> Thanks for finding this bug and offering to fix it! (And @shipilev thanks for your assistance on this.)
> 
> Putting the test into a separate JVM will work, but I don't think it's necessary to actually allocate the space. The test is only testing the indexes sent to `get` and `set` on the list, and it doesn't actually verify the contents of the list. (Presumably that's done by other tests.) Therefore it should be possible to create a "virtual" list of a given size that checks that the indexes are all in bounds but that doesn't actually store any elements. It should be fairly straightforward to do this by subclassing AbstractList and overriding a few methods.
> 
> The advantage of not actually allocating 4G of memory is that it makes it easier to run a bunch of cases that test the boundary conditions. In fact I'd like to see that in the test, as opposed to testing this one case.

@stuart-marks
Thanks for your review! I rewrote the test according with your advise. All checks passed successfully.

Could you review the changes, please?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1297105328

From jlu at openjdk.org  Fri Aug 18 21:34:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 18 Aug 2023 21:34:45 GMT
Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is not
 clear
Message-ID: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns  in regards to the max integer digits in j.text.DecimalFormat.

The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`.

See below,

DecimalFormat df = new DecimalFormat();
df.applyPattern("000.000E0");
df.getMaximumIntegerDigits(); //  ==> 3
df.applyPattern("000.000");
df.getMaximumIntegerDigits(); // ==> 2147483647

DecimalFormat df = new DecimalFormat("000.000");
df.getMaximumIntegerDigits(); // ==> 2147483647
DecimalFormat df = new DecimalFormat("000.000E0");
df.getMaximumIntegerDigits(); // ==> 3


Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well.

-------------

Commit messages:
 - Include constructors
 - Re-clarify spec
 - Init

Changes: https://git.openjdk.org/jdk/pull/15349/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15349&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314604
  Stats: 28 lines in 1 file changed: 22 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15349/head:pull/15349

PR: https://git.openjdk.org/jdk/pull/15349

From bpb at openjdk.org  Fri Aug 18 23:22:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 18 Aug 2023 23:22:08 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent
Message-ID: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>

Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.

-------------

Commit messages:
 - 8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent

Changes: https://git.openjdk.org/jdk/pull/15351/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15351&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8219567
  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/15351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15351/head:pull/15351

PR: https://git.openjdk.org/jdk/pull/15351

From jlu at openjdk.org  Sat Aug 19 00:18:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 19 Aug 2023 00:18:29 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent
In-Reply-To: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
Message-ID: <YIPSL9WFiXxE1fEka_lWR3yqzN2mqfRQe2LLMWyLcFE=.f61dd4c1-d230-4005-bf96-9b234fdcc1ca@github.com>

On Fri, 18 Aug 2023 23:14:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15351#pullrequestreview-1585330641

From duke at openjdk.org  Sat Aug 19 02:15:06 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Sat, 19 Aug 2023 02:15:06 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v7]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  refactor the code and test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/ac72c3d8..e9e0497f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=05-06

  Stats: 121 lines in 3 files changed: 48 ins; 36 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Sat Aug 19 02:15:37 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Sat, 19 Aug 2023 02:15:37 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v6]
In-Reply-To: <swyQgQ1mHIRiOLcbv81XUiBauusoCsnY09Y6DjFtUD4=.299db019-aabc-47fc-adee-c49845df5c9e@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <swyQgQ1mHIRiOLcbv81XUiBauusoCsnY09Y6DjFtUD4=.299db019-aabc-47fc-adee-c49845df5c9e@github.com>
Message-ID: <xo1iQs42sKc79oIbZeJyNBU3Q5FfbaXJKe966JKVU3M=.236062e3-d08b-424f-8111-aa70598bb2a3@github.com>

On Fri, 18 Aug 2023 13:30:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-write close method

1) Refactor the code again, and simplify the code to handle the setting of connection time
2) Add more test cases
3) Bring back the pre-created keystore. I could not find a good example to create the key store at runtime.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1684688234

From martin at openjdk.org  Sat Aug 19 02:44:40 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Sat, 19 Aug 2023 02:44:40 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <QfOWynwrzQcWOBK_OFckRXbbAiJM3F1h7yfZDurX4Dw=.6af94d21-35a9-4bf7-8c42-890c636b3610@github.com>
References: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>
 <QfOWynwrzQcWOBK_OFckRXbbAiJM3F1h7yfZDurX4Dw=.6af94d21-35a9-4bf7-8c42-890c636b3610@github.com>
Message-ID: <AYf8ZhnePNaePfn2cSar7db_XHGnScW5Qesxy9mCmxc=.0527951e-81ac-4dba-a02d-510c2d30da67@github.com>

On Fri, 18 Aug 2023 08:15:58 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> The usual tiny improvements, with no guarantee that the intermittent test failure is actually fixed.
>
> test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 41:
> 
>> 39:         throws Throwable
>> 40:     {
>> 41:         int threadCount = ThreadLocalRandom.current().nextInt(2, 8);
> 
> @Martin-Buchholz I'm a bit weary about making the number of threads random?might make it tricky to get to reproduce if the test fails?

Suppose the test fails only with a specific number of threads.  I would want to know that!  At least once in the past a j.u.c. bug has been found due to randomization of concurrency level in a test.  I can't understand the current industry obsession with deterministic tests, except that too many  organizations don't commit to hunting down flakes.

Here the error detail has been changed to report the threadcount, in case of failure.

> test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 55:
> 
>> 53:             Thread t = new Thread(put);
>> 54:             t.start();
>> 55:             ts.add(t);
> 
> @Martin-Buchholz Any specific reason to add the thread *after* it has been started?

I've never considered that the order would matter - so, no reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15337#discussion_r1299024335
PR Review Comment: https://git.openjdk.org/jdk/pull/15337#discussion_r1299027961

From martin at openjdk.org  Sat Aug 19 02:51:44 2023
From: martin at openjdk.org (Martin Buchholz)
Date: Sat, 19 Aug 2023 02:51:44 GMT
Subject: RFR: 8314515: java/util/concurrent/SynchronousQueue/Fairness.java
 failed with "Error: fair=false i=8 j=0"
In-Reply-To: <QfOWynwrzQcWOBK_OFckRXbbAiJM3F1h7yfZDurX4Dw=.6af94d21-35a9-4bf7-8c42-890c636b3610@github.com>
References: <6yvA_1UW9arwLh-HQqllCe04KtMlpNc_pRwV5fjpnP0=.01b1313c-0dc8-4f45-84e2-07ee3fdcf63f@github.com>
 <QfOWynwrzQcWOBK_OFckRXbbAiJM3F1h7yfZDurX4Dw=.6af94d21-35a9-4bf7-8c42-890c636b3610@github.com>
Message-ID: <89bDsQDcA9Y-n89mwO9svCQN_4dPMn6PaOn-ZY9GNiY=.727850f2-9ee7-4643-a14a-08003b4c8bbb@github.com>

On Fri, 18 Aug 2023 08:18:24 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> The usual tiny improvements, with no guarantee that the intermittent test failure is actually fixed.
>
> test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 70:
> 
>> 68:                                               fair, i, threadCount, j));
>> 69:         }
>> 70:         for (Thread t : ts) t.join();
> 
> @Martin-Buchholz Makes a lot of sense to make sure that all threads have terminated before exiting the test ?

There's a lot of infrastructure in JSR166TestCase.java to address this.  Some of it could be librarified for use by other openjdk tests.


 * <li>All code not running in the main test thread (manually spawned threads
 * or the common fork join pool) must be checked for failure (and completion!).
 * Mechanisms that can be used to ensure this are:
 *   <ol>
 *   <li>Signalling via a synchronizer like AtomicInteger or CountDownLatch
 *    that the task completed normally, which is checked before returning from
 *    the test method in the main thread.
 *   <li>Using the forms {@link #threadFail}, {@link #threadAssertTrue},
 *    or {@link #threadAssertNull}, (not {@code fail}, {@code assertTrue}, etc.)
 *    Only the most typically used JUnit assertion methods are defined
 *    this way, but enough to live with.
 *   <li>Recording failure explicitly using {@link #threadUnexpectedException}
 *    or {@link #threadRecordFailure}.
 *   <li>Using a wrapper like CheckedRunnable that uses one the mechanisms above.
 *   </ol>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15337#discussion_r1299029889

From vtewari at openjdk.org  Sat Aug 19 03:24:25 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Sat, 19 Aug 2023 03:24:25 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent
In-Reply-To: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
Message-ID: <iKp9162dgsRUaikc8nxAk-iCIj59b-sIvk62pLh5yBA=.4a129571-dbe5-4aed-a60e-79fa003c0288@github.com>

On Fri, 18 Aug 2023 23:14:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.

Looks OK to me

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15351#pullrequestreview-1585469761

From aturbanov at openjdk.org  Sat Aug 19 09:11:37 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 19 Aug 2023 09:11:37 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v7]
In-Reply-To: <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
Message-ID: <hbrpI8o5bT0-6iPluFeZVmU0oFwS01Tkl2h187O5nns=.bf7de73a-dc6d-43ea-97b7-c5efd025ee59@github.com>

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the code and test cases

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 77:

> 75:         // start the test server first.
> 76:         boolean serverSlowDown = false;
> 77:         if(args.length ==2 ) {

Suggestion:

        if (args.length ==2 ) {

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 80:

> 78:             serverSlowDown = Boolean.valueOf(args[1]);
> 79:         } else {
> 80:             if(args.length ==1 ) {

Suggestion:

            if (args.length ==1) {

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 98:

> 96:         }
> 97:         env.put("java.naming.ldap.version", "3");
> 98:         if (args.length == 2 ) {

Suggestion:

        if (args.length == 2) {

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 99:

> 97:         env.put("java.naming.ldap.version", "3");
> 98:         if (args.length == 2 ) {
> 99:             if( args[0].contains("LdapSSLHandshakeFailureTest")) {

Suggestion:

            if (args[0].contains("LdapSSLHandshakeFailureTest")) {

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 122:

> 120:             }
> 121:         } finally {
> 122:             if(ctx != null)

Suggestion:

            if (ctx != null)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1299160346
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1299160377
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1299160495
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1299160402
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1299160439

From dl at openjdk.org  Sat Aug 19 12:54:33 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 19 Aug 2023 12:54:33 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v4]
In-Reply-To: <2VxtUHQOQdretKTrqlk4zPFZux1Bng6l3MbkkYWYbYg=.022ef204-c37b-4459-b7e1-0946251c2df8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
 <xdlyQEPp_J5PBqJKHp4trJUhD2tDGDwX4WFFxyjf5u0=.73dcc7d4-6f80-498d-9210-f25628b92b29@github.com>
 <2VxtUHQOQdretKTrqlk4zPFZux1Bng6l3MbkkYWYbYg=.022ef204-c37b-4459-b7e1-0946251c2df8@github.com>
Message-ID: <w_u_cg5GcC3fcaK5lfNpLKhEyPjHYv4CEQgkTLbQjIE=.d9880c4e-9811-4084-9df0-ea0a88901127@github.com>

On Thu, 17 Aug 2023 15:25:49 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doug Lea 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 45 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Update @since tags
>>  - resync
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - ExecutorService tests
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Rework versioning
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - Merge branch 'openjdk:master' into JDK-8288899
>>  - ... and 35 more: https://git.openjdk.org/jdk/compare/cdcc657e...585769c9
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1823:
> 
>> 1821:                 WorkQueue[] qs; int n;
>> 1822:                 if ((qs = queues) != null && (n = qs.length) > 0) {
>> 1823:                     for (int k = n, m = n - 1;  ; id += 2) {
> 
> @DougLea Might make sense to create a constant each for worker-queue stride and submission-queue stride so it becomes easier to reason about the `2` here.

There seem to be too many variants of queues array traversal loops to do this uniformly, but I did add some explanation:

     * alternatives. Other loops over the queues array vary in origin
     * and stride depending on whether they cover only submission
     * (even) or worker (odd) queues or both, and whether they require
     * randomness (in which case cyclically exhaustive strides may be
     * used).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1299183118

From dl at openjdk.org  Sat Aug 19 13:00:01 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 19 Aug 2023 13:00:01 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v9]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <yqejsGtyy7zdVnOJ9RIBF_iWCDWc-XxXQ05nGAE2VV0=.7849a312-9a1e-48c9-b54f-4feb4c533f04@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Use signalWork in isQuiescent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/27f7357b..1a7466d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=07-08

  Stats: 25 lines in 1 file changed: 4 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From alanb at openjdk.org  Sat Aug 19 18:45:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Aug 2023 18:45:35 GMT
Subject: Integrated: 8313290: Misleading exception message from
 STS.Subtask::get when task forked after shutdown
In-Reply-To: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
References: <StiyEh_IiWnag2ZoNMDvxTbenG1CMMa_s-wTnvYq12M=.22f024a6-4ee6-4ce1-8360-01a6dcdb13c2@github.com>
Message-ID: <40pVE5L7tFaXtfKIvlz4LTda_ryuZlhTKQiLHAUEaYU=.b030836e-6948-480a-ae0d-f085c6201a3c@github.com>

On Fri, 28 Jul 2023 20:33:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a small issue with StructuredTaskScope. If the owner attempts to fork a subtask and the task scope is shutdown then the implementation doesn't currently force the owner to join when it's the first fork in a new round of forking. The result is that broken code calling Subtask::get throws ISE with the wrong exception message.
> 
> The existing test for this API is updated to remove a duplicate test and also fix two tasks that didn't call join.

This pull request has now been integrated.

Changeset: ed0f75f2
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed0f75f2666f61ec3d8ccb78594a21db9f1be50a
Stats:     27 lines in 2 files changed: 4 ins; 19 del; 4 mod

8313290: Misleading exception message from STS.Subtask::get when task forked after shutdown

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/15076

From jpai at openjdk.org  Sun Aug 20 06:31:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 20 Aug 2023 06:31:37 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent
In-Reply-To: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
Message-ID: <aDs1bcK6HLiFCjto5gfxxe4qpaf1HxWnDzYkGy-23ag=.fa8da5d5-0a03-4535-a5ae-21175c83fc8b@github.com>

On Fri, 18 Aug 2023 23:14:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.

src/java.base/share/classes/java/io/RandomAccessFile.java line 213:

> 211:      * @throws      SecurityException  if a security manager exists and its
> 212:      *             {@code checkRead} method denies read access to the file
> 213:      *             or the mode is {@code "rw"} and the security manager's

GitHub UI isn't allowing me to add a review comment on line 195, so adding it here. Should line 195 be changed to say:


also called with the pathname of the {@code file} argument to see if write access to the file...

to match what it says a few lines above for the `checkRead` security check?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15351#discussion_r1299313238

From jpai at openjdk.org  Sun Aug 20 06:58:36 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 20 Aug 2023 06:58:36 GMT
Subject: RFR: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <nqvto-2duB9RBZ1r8JUgReinh6Ackgqmm5H8ocgb424=.d309d8d6-ff29-4979-a1ab-2e1a10ec51f1@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: tier1-tier5 OK

Looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15323#pullrequestreview-1585812406

From dl at openjdk.org  Sun Aug 20 13:03:56 2023
From: dl at openjdk.org (Doug Lea)
Date: Sun, 20 Aug 2023 13:03:56 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v10]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <HDJQi01JfpRqGfu6-faOeQTC3NelL5W9KycZVq-5fJ8=.8fe2dedb-dc09-4dbb-add7-7894d899c7f3@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Ensure thread not interrupted when testing close

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/1a7466d3..50fe9a4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=08-09

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From vpetko at openjdk.org  Sun Aug 20 20:33:39 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sun, 20 Aug 2023 20:33:39 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
Message-ID: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>

8314491: Linux: jexec launched via PATH fails to find java

-------------

Commit messages:
 - Use /proc/self/exec to identify path to the executable.
 - Create failing test for jexec in PATH issue

Changes: https://git.openjdk.org/jdk/pull/15343/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314491
  Stats: 46 lines in 2 files changed: 29 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From vpetko at openjdk.org  Sun Aug 20 20:33:40 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sun, 20 Aug 2023 20:33:40 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <Ma-MjNPVqk0B5q1O7N6pg8Ay_6u3dH-AYxdWr10D0Mw=.0a83dd0d-ae22-4e0e-a6ce-be0e1928b813@github.com>

On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> 8314491: Linux: jexec launched via PATH fails to find java

When jexec is found in the PATH, e.g. we run ``$jexec myjar.jar``, the `argv[0]` contains `jexec` and Java can not be found.

Running updated test without fix in jexec.c:


$make test CONF=linux-x86_64-server-slowdebug TEST=test/jdk/tools/launcher/Jexec.java 
.....

++++Test Output++++
  can't locate java: No such file or directory
++++Test Stack Trace++++
....
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/jdk/tools/launcher/Jexec.java              1     0     1     0 <<
==============================
TEST FAILURE


Running test after fixing jexec.c:


$ make test CONF=linux-x86_64-server-slowdebug TEST=test/jdk/tools/launcher/Jexec.java 
....
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/tools/launcher/Jexec.java              1     1     0     0   
==============================
TEST SUCCESS


Rerun jdk_launcher tests:

$ make test CONF=linux-x86_64-server-slowdebug TEST=jdk_launcher
...
==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk:jdk_launcher                         124   124     0     0   
==============================
TEST SUCCESS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1683680600

From duke at openjdk.org  Mon Aug 21 03:55:42 2023
From: duke at openjdk.org (Martin Stypinski)
Date: Mon, 21 Aug 2023 03:55:42 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API [v2]
In-Reply-To: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
References: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
Message-ID: <QHvth827QpJkt4bY9KEpcOs6xV9_Vfa4qT8y_LeMrm8=.684fe64b-dae2-4404-9247-de4cd8eec522@github.com>

> Added a bunch of different implementations for Vector API Matrix Multiplications:
> 
> - Baseline
> - Blocked (Cache Local)
> - FMA
> - Vector API Simple Implementation
> - Vector API Blocked Implementation
> 
> Commit was discussed with @PaulSandoz

Martin Stypinski has updated the pull request incrementally with two additional commits since the last revision:

 - changed for consistency
 - improved some RandomGenerator & unuseed Imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15338/files
  - new: https://git.openjdk.org/jdk/pull/15338/files/c5289fdc..5bda0c2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15338&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15338&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15338.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15338/head:pull/15338

PR: https://git.openjdk.org/jdk/pull/15338

From duke at openjdk.org  Mon Aug 21 03:55:43 2023
From: duke at openjdk.org (Martin Stypinski)
Date: Mon, 21 Aug 2023 03:55:43 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API
In-Reply-To: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
References: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
Message-ID: <8BXkyGnNgMS6iktaExy65qSluRvYoS1ww-1ZS6ekMxY=.ffab5a85-17da-41b6-8056-ae7bb721bd2a@github.com>

On Fri, 18 Aug 2023 03:57:24 GMT, Martin Stypinski <duke at openjdk.org> wrote:

> Added a bunch of different implementations for Vector API Matrix Multiplications:
> 
> - Baseline
> - Blocked (Cache Local)
> - FMA
> - Vector API Simple Implementation
> - Vector API Blocked Implementation
> 
> Commit was discussed with @PaulSandoz

Changed according to comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15338#issuecomment-1685597390

From dholmes at openjdk.org  Mon Aug 21 04:41:25 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Aug 2023 04:41:25 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <wKSjxN1Wst-WaKWvpEI8GZD4Xvm2R7B_jXjaUg0DAi4=.b5c0166c-7612-4abe-ba1f-b26c93de4387@github.com>

On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> 8314491: Linux: jexec launched via PATH fails to find java

I get the sense from the comment in jexec.c that it is only intended to be launched via a full path, so having it in the $PATH seems like a usage error to me.

That said this change seems relatively harmless, though I confess I do not understand how `/proc/self/exe` works and under what conditions reading it returns the actual binary path rather than "/proc/self/exe". ??

src/java.base/unix/native/launcher/jexec.c line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2017, 2023, Oracle and/or its affiliates. All rights reserved.

Copyright format is incorrect, please just replace 2017 with 2023.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15343#pullrequestreview-1586161358
PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1299581188

From dholmes at openjdk.org  Mon Aug 21 05:16:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Aug 2023 05:16:27 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <kb_0ho4zYNDkj78Z7RGY5T_3GP4hXAdQOO4YqCFSFUQ=.175c64f3-b393-4e69-b525-1b0475de2b07@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <SvMObwRjzrMi_pwCj6bexMu4i0TkleitBcuhmN0AXhw=.dd561d80-f118-47c2-b3fb-73a4bab5a8fe@github.com>
 <kb_0ho4zYNDkj78Z7RGY5T_3GP4hXAdQOO4YqCFSFUQ=.175c64f3-b393-4e69-b525-1b0475de2b07@github.com>
Message-ID: <s-l9GiU0I8x33m_0dsZdN2XbJCwU0gdKGwHFGQwcBgs=.be05ab51-bfbb-4d34-ace8-7abcb41fc5e2@github.com>

On Fri, 18 Aug 2023 12:30:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> errno 11 seems to be EAGAIN.

Sounds like the native code should be retrying in this case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1685653886

From jpai at openjdk.org  Mon Aug 21 06:17:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 21 Aug 2023 06:17:25 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

Hello David,

> > errno 11 seems to be EAGAIN.
> 
> Sounds like the native code should be retrying in this case.

The Java side of this code does have retry logic which will end up reattempting it for a few times (with sleep() in between) https://github.com/openjdk/jdk/blob/master/src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java#L939. It's possible that if multiple tests are running and try to acquire this file lock, then they might end up interfering with each other, but it's surprising that in some cases even after multiple attempts the file lock doesn't become available.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1685713819

From vpetko at openjdk.org  Mon Aug 21 06:26:52 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 06:26:52 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v2]
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <eb_eeEMhfeyZIlK9tvGf5DAkRPsRxU-XYCluf8qanN8=.f93e90a3-4698-48b6-9de2-8cdc48944f42@github.com>

> 8314491: Linux: jexec launched via PATH fails to find java

Vladimir Petko 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 four additional commits since the last revision:

 - Merge branch 'master' into 8314491-jexec-resolve-symlink
 - correct copyright statement
 - Use /proc/self/exec to identify path to the executable.
 - Create failing test for jexec in PATH issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15343/files
  - new: https://git.openjdk.org/jdk/pull/15343/files/958ee563..7bd4e677

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=00-01

  Stats: 1162 lines in 126 files changed: 658 ins; 189 del; 315 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From vpetko at openjdk.org  Mon Aug 21 06:26:52 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 06:26:52 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v2]
In-Reply-To: <wKSjxN1Wst-WaKWvpEI8GZD4Xvm2R7B_jXjaUg0DAi4=.b5c0166c-7612-4abe-ba1f-b26c93de4387@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <wKSjxN1Wst-WaKWvpEI8GZD4Xvm2R7B_jXjaUg0DAi4=.b5c0166c-7612-4abe-ba1f-b26c93de4387@github.com>
Message-ID: <a4EWfp4ELPnMRv30ddyubqCr1d11YIouzkJsQxk03L4=.ef936f81-d6d3-4fe7-a892-b208324bc153@github.com>

On Mon, 21 Aug 2023 04:38:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I get the sense from the comment in jexec.c that it is only intended to be launched via a full path, so having it in the $PATH seems like a usage error to me.

Unfortunately this executable is linked in /usr/bin and is assumed to work perfectly when run as just `jexec` .

> That said this change seems relatively harmless, though I confess I do not understand how `/proc/self/exe` works and under what conditions reading it returns the actual binary path rather than "/proc/self/exe". ??

The '/proc/' filesystem contains a 'self' entry for the current process and 'exe' entry is expected to contain the symbolic link to the actual binary[1] . `realpath` call in getJavaPath() function translates the symbolic link into the binary path. 

I do not have much expertise in the kernel development, but as far as I know the value of `/proc/self/exe` it is being set in Memory Descriptor structure whenever a process is created from a file[2].
Reading the symlink may return ENOENT (broken symlink) if there was no file[3].

[1] https://docs.kernel.org/filesystems/proc.html
[2] https://github.com/torvalds/linux/blob/f7757129e3dea336c407551c98f50057c22bb266/fs/exec.c#L1282
[3] https://github.com/torvalds/linux/blob/f7757129e3dea336c407551c98f50057c22bb266/fs/proc/base.c#L1730

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1685716770

From cstein at openjdk.org  Mon Aug 21 06:33:35 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 21 Aug 2023 06:33:35 GMT
Subject: Integrated: 8314495: Update to use jtreg 7.3.1
In-Reply-To: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
References: <p10Ls7dRZtpGBoZHjRETUdFlwRIYROP4oxMdh2D9sN4=.0ae06e04-39e2-45ea-92e0-6cc46efdf1ff@github.com>
Message-ID: <lpRwAzlEmkhq3uQVzIjyagG37nc9PZ67TI9xgeXUHdc=.29a625f6-e22b-4f1f-8c05-a31c4a1f9d97@github.com>

On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review the change to update to using jtreg 7.3,1.
> 
> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files.
> 
> This change set also un-problem-lists tests from https://github.com/openjdk/jdk/commit/360f65d7b15b327e2f160c42f318945cc6548bda
> 
> This change set also fixes:
> - https://bugs.openjdk.org/browse/JDK-8313902
> - https://bugs.openjdk.org/browse/JDK-8313903
> 
> Testing: tier1-tier5 OK

This pull request has now been integrated.

Changeset: c50315de
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c50315de8f13d316a7de08be53716cd88fa801c4
Stats:     12 lines in 9 files changed: 0 ins; 3 del; 9 mod

8314495: Update to use jtreg 7.3.1

Reviewed-by: dholmes, erikj, iris, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15323

From dholmes at openjdk.org  Mon Aug 21 06:36:31 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Aug 2023 06:36:31 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v2]
In-Reply-To: <a4EWfp4ELPnMRv30ddyubqCr1d11YIouzkJsQxk03L4=.ef936f81-d6d3-4fe7-a892-b208324bc153@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <wKSjxN1Wst-WaKWvpEI8GZD4Xvm2R7B_jXjaUg0DAi4=.b5c0166c-7612-4abe-ba1f-b26c93de4387@github.com>
 <a4EWfp4ELPnMRv30ddyubqCr1d11YIouzkJsQxk03L4=.ef936f81-d6d3-4fe7-a892-b208324bc153@github.com>
Message-ID: <FiAwkmTuLNEFL6xfKwwoLTpkDPHETBSx_BcE7xMSB-A=.3b52f5a7-bb15-4c7e-827c-eaa966eaae4e@github.com>

On Mon, 21 Aug 2023 06:18:15 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> realpath call in getJavaPath() function translates the symbolic link into the binary path.

Okay so a specific API makes this work as intended.

What I can't determine is whether this may have an adverse effect on anyone using an "unusual" path to jexec, that `/proc/self/exe` will report differently. To minimise the impact on existing users can this be implemented as a fallback if the initial attempt to locate `java` fails?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1685732281

From dholmes at openjdk.org  Mon Aug 21 06:51:33 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Aug 2023 06:51:33 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
Message-ID: <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>

On Mon, 21 Aug 2023 06:15:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> if multiple tests are running and try to acquire this file lock, then they might end up interfering with each other, but it's surprising that in some cases even after multiple attempts the file lock doesn't become available.

How long is the file-lock typically held? How many such tests can run concurrently? And how long do we retry for?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1685748176

From vpetko at openjdk.org  Mon Aug 21 07:14:44 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 07:14:44 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <FiAwkmTuLNEFL6xfKwwoLTpkDPHETBSx_BcE7xMSB-A=.3b52f5a7-bb15-4c7e-827c-eaa966eaae4e@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <wKSjxN1Wst-WaKWvpEI8GZD4Xvm2R7B_jXjaUg0DAi4=.b5c0166c-7612-4abe-ba1f-b26c93de4387@github.com>
 <a4EWfp4ELPnMRv30ddyubqCr1d11YIouzkJsQxk03L4=.ef936f81-d6d3-4fe7-a892-b208324bc153@github.com>
 <FiAwkmTuLNEFL6xfKwwoLTpkDPHETBSx_BcE7xMSB-A=.3b52f5a7-bb15-4c7e-827c-eaa966eaae4e@github.com>
Message-ID: <eMHZiWr7sRzRHXb3X6aatAmIHJZdahERHLnNJdE_fM8=.85bab3e8-272a-4e3b-a1b1-1e2b0a28080f@github.com>

On Mon, 21 Aug 2023 06:33:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> To minimise the impact on existing users can this be implemented as a fallback if the initial attempt to locate `java` fails?

Updated and re-run the affected test:

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/tools/launcher/Jexec.java              1     1     0     0   
==============================
TEST SUCCESS

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1685772596

From vpetko at openjdk.org  Mon Aug 21 07:14:44 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 07:14:44 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>

> 8314491: Linux: jexec launched via PATH fails to find java

Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:

  Review comment: use /proc/self/exe as the backup option

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15343/files
  - new: https://git.openjdk.org/jdk/pull/15343/files/7bd4e677..3f832c40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=01-02

  Stats: 18 lines in 1 file changed: 9 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From alanb at openjdk.org  Mon Aug 21 07:17:30 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Aug 2023 07:17:30 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
 <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>
Message-ID: <kl1nZKcKJ50pznWkSgmJ1FMgwyI3QsCWCeJaraoJjS8=.40ab384b-b91e-45a1-9bf5-fbdd19e54552@github.com>

On Mon, 21 Aug 2023 06:48:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> How long is the file-lock typically held? How many such tests can run concurrently? And how long do we retry for?

It's typically the sync method when writing back the cached changes. I suspect the Unix implementation could be easily re-written to use FileChannel and Files.setPosixFilePermissions and that would eliminate the native code and give better exception messages when there are errors.

For the tests, I'm surprised the TEST.properties in this directory doesn't have exclusiveAccess.dirs=. as there has been historical issues with interference between tests in this area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1685778195

From duke at openjdk.org  Mon Aug 21 07:18:51 2023
From: duke at openjdk.org (sid8606)
Date: Mon, 21 Aug 2023 07:18:51 GMT
Subject: Integrated: 8311630: [s390] Implementation of Foreign Function &
 Memory API (Preview)
In-Reply-To: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
References: <c9vqL__vJ_ErZj5TgE6H6cTkpmDVssrHfUWNs5JsguE=.f06aad0b-d0d6-46b6-aa5b-cf24303989c7@github.com>
Message-ID: <OBbfAwBqv5HepYy7ULBtgbrrwNFVpk0vhOl1IAViWjk=.e0e172db-0f5a-42a2-8333-751dfb5635cd@github.com>

On Fri, 7 Jul 2023 07:55:03 GMT, sid8606 <duke at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for s390x (Big Endian).

This pull request has now been integrated.

Changeset: ec1f7a84
Author:    Sidraya <sidraya.jayagond at ibm.com>
Committer: Andrew Dinn <adinn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec1f7a8480db025a6f405817a106af8e92b69c44
Stats:     1523 lines in 19 files changed: 1469 ins; 4 del; 50 mod

8311630: [s390] Implementation of Foreign Function & Memory API (Preview)

Reviewed-by: amitkumar, jvernee, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/14801

From dholmes at openjdk.org  Mon Aug 21 08:03:27 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Aug 2023 08:03:27 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
Message-ID: <KdtDoYNOqiy135qcyi46qBnFpXb4ZmNdOKekcX56fhs=.b125ad1e-e901-4301-be36-7deb2f751eb0@github.com>

On Mon, 21 Aug 2023 07:14:44 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: use /proc/self/exe as the backup option

Thanks for the update, I feel much more comfortable with this change now.

Please wait for a second review however.

Thanks

src/java.base/unix/native/launcher/jexec.c line 162:

> 160:     int           argi  = 0;             /* index into old array */
> 161:     size_t        alen  = 0;             /* length of new array */
> 162:     int           error = 0;             /* getJavaPath error */

Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15343#pullrequestreview-1586415445
PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1299744492

From pavel.rappo at oracle.com  Mon Aug 21 09:57:44 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 21 Aug 2023 09:57:44 +0000
Subject: @Incubating
Message-ID: <D9DE42BE-02E6-4501-9CAB-C6C98C6EFCCD@oracle.com>

Does anybody remember why {@Incubating}, a JDK-specific tag introduced in JDK-8173354, starts with an uppercase letter? Put differently, are there any reasons why we should not make it conform to implicit convention of camelCase, like all other standard and JDK tags do?

From albertattard at gmail.com  Mon Aug 21 12:18:22 2023
From: albertattard at gmail.com (Albert Attard)
Date: Mon, 21 Aug 2023 14:18:22 +0200
Subject: Enrich the Lock interface
Message-ID: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>

Hello.

I hope all is well.

Do you believe it is a bad idea to enrich the Lock interface with a set of
default methods that safely release the lock once ready?

Consider the following (dangerous) example.

final Lock lock = new ReentrantLock ();
lock.lock();
/* Code that may throw an exception */
lock.unlock();

This example will never release the lock if an exception is thrown, as the
programmer didn?t wrap this up in a try/finally.

Adding a default method within the Lock interface, called withLock(Runnable)
for example or any better name, would streamline this, as shown next.

default void withLock(final Runnable runnable) {
    requireNonNull(runnable, "Cannot run a null");
    lock();
    try {
        runnable.run();
    } finally {
        unlock();
    }
}

The caller can now simply change the above example into the following,
without having to worry about this.

final Lock lock = new ReentrantLock ();
lock.withLock(() -> {
  /* Code that may throw an exception */
});

We can have more variants of these default methods, as shown next.

default <T> T getWithLock(final Supplier<T> supplier) {
    requireNonNull(supplier, "The supplier cannot be null");
    lock();
    try {
        return supplier.get();
    } finally {
        unlock();
    }
}

Any thoughts?

With kind regards,
Albert Attard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230821/245aac5f/attachment-0001.htm>

From pavel.rappo at oracle.com  Mon Aug 21 12:37:39 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 21 Aug 2023 12:37:39 +0000
Subject: Enrich the Lock interface
In-Reply-To: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>
References: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>
Message-ID: <554805B7-C415-4051-A16A-EBAE9A16BE2D@oracle.com>

This is suggested every once in a while. I appreciate that openjdk mailing lists are not easily searchable, but with a bit of skill, you could find a few previous discussions on the topic.

This has also been discussed on concurrency-interest (at cs.oswego.edu <http://cs.oswego.edu/>), a dedicated mailing list for concurrency in Java. Sadly, that list has been defunct for quite some time now.

-Pavel

> On 21 Aug 2023, at 13:18, Albert Attard <albertattard at gmail.com> wrote:
> 
> Hello.
> 
> I hope all is well.
> 
> Do you believe it is a bad idea to enrich the Lock interface with a set of default methods that safely release the lock once ready?
> 
> Consider the following (dangerous) example.
> 
> final Lock lock = new ReentrantLock ();
> lock.lock();
> /* Code that may throw an exception */
> lock.unlock();
> 
> This example will never release the lock if an exception is thrown, as the programmer didn?t wrap this up in a try/finally.
> 
> Adding a default method within the Lock interface, called withLock(Runnable) for example or any better name, would streamline this, as shown next.
> 
> default void withLock(final Runnable runnable) {
>     requireNonNull(runnable, "Cannot run a null");
>     lock();
>     try {
>         runnable.run();
>     } finally {
>         unlock();
>     }
> }
> 
> The caller can now simply change the above example into the following, without having to worry about this.
> 
> final Lock lock = new ReentrantLock ();
> lock.withLock(() -> {
>   /* Code that may throw an exception */
> });
> 
> We can have more variants of these default methods, as shown next.
> 
> default <T> T getWithLock(final Supplier<T> supplier) {
>     requireNonNull(supplier, "The supplier cannot be null");
>     lock();
>     try {
>         return supplier.get();
>     } finally {
>         unlock();
>     }
> }
> 
> Any thoughts?
> 
> With kind regards,
> Albert Attard


From aefimov at openjdk.org  Mon Aug 21 13:10:31 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 21 Aug 2023 13:10:31 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v7]
In-Reply-To: <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
Message-ID: <wQvT0GZUXYGgAmkcfUbyGha1PPjNMb0u349PFiOatmY=.9ea659aa-de70-4141-875f-c141518d5931@github.com>

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the code and test cases

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 84:

> 82:             }
> 83:         }
> 84:         TestServer server = new TestServer( serverSlowDown );

The server instance can be used in try-with-resouces:

        try (TestServer server = new TestServer(serverSlowDown)) {
            server.start();
            env.put(Context.PROVIDER_URL, URIBuilder.newBuilder()
                    .scheme("ldaps")
                    .loopback()
                    .port(server.getPortNumber())
                    .buildUnchecked().toString());

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 94:

> 92:                 .buildUnchecked().toString());
> 93:         if (args.length == 2 &&
> 94:                 args[0].contains("LdapSSLHandshakeFailureTest")) {

This `arg[0]` check is done twice in the test - it can be save to a boolean variable:

boolean hasCustomSocketFactory = args[0]
        .equals("LdapSSLHandshakeFailureTest$CustomSocketFactory");

and then used to the checks

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300088395
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300086412

From aefimov at openjdk.org  Mon Aug 21 13:23:34 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 21 Aug 2023 13:23:34 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v7]
In-Reply-To: <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
Message-ID: <zcMfXEsiIoLgf8xaUyI3tX5aCvZ9t6ALjNnTyKWVRBQ=.92232bf7-c8de-4bdb-8d43-2ee57c5f3e14@github.com>

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the code and test cases

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 69:

> 67: public class LdapSSLHandshakeFailureTest {
> 68:     private static String SOCKET_CLOSED_MSG = "The socket has been closed.";
> 69:     private static String SOCKET_NOT_CLOSED_MSG = "The socket was not closed.";

`SOCKET_NOT_CLOSED_MSG` - not used and can be removed

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 76:

> 74:         setKeyStore();
> 75:         // start the test server first.
> 76:         boolean serverSlowDown = false;

`false` initializer is redundant here

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 178:

> 176:     }
> 177: 
> 178:     private static void setKeyStore() throws Exception {

`Exception` is not thrown by this method and can be removed

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 211:

> 209:         @Override
> 210:         public void run() {
> 211:             try (Socket socket = serverSocket.accept(); InputStream in = socket.getInputStream();

formatting: this can be made shorter by putting `InputStream in = socket.getInputStream();`  on a separate line

test/jdk/com/sun/jndi/ldap/LdapSSLHandshakeFailureTest.java line 216:

> 214:                     Thread.sleep(5000);
> 215:                 }
> 216:                 byte[] bindResponse = {0x30, 0x0C, 0x02, 0x01, 0x01, 0x61, 0x07, 0x0A, 0x01, 0x00, 0x04, 0x00, 0x04, 0x00};

formatting: can be splitted in two lines to make it shorter

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300093748
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300092781
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300095645
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300099068
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1300100447

From john.hendrikx at gmail.com  Mon Aug 21 13:24:27 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Mon, 21 Aug 2023 15:24:27 +0200
Subject: Enrich the Lock interface
In-Reply-To: <554805B7-C415-4051-A16A-EBAE9A16BE2D@oracle.com>
References: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>
 <554805B7-C415-4051-A16A-EBAE9A16BE2D@oracle.com>
Message-ID: <9b53bb5f-383a-d8b7-8acd-2c8d3f9d340c@gmail.com>

I couldn't find a discussion on openjdk, but for those interested (and 
to save others some searching) there is a JBS ticket:

https://bugs.openjdk.org/browse/JDK-8025597

--John

On 21/08/2023 14:37, Pavel Rappo wrote:
> This is suggested every once in a while. I appreciate that openjdk mailing lists are not easily searchable, but with a bit of skill, you could find a few previous discussions on the topic.
>
> This has also been discussed on concurrency-interest (at cs.oswego.edu <http://cs.oswego.edu/>), a dedicated mailing list for concurrency in Java. Sadly, that list has been defunct for quite some time now.
>
> -Pavel
>
>> On 21 Aug 2023, at 13:18, Albert Attard <albertattard at gmail.com> wrote:
>>
>> Hello.
>>
>> I hope all is well.
>>
>> Do you believe it is a bad idea to enrich the Lock interface with a set of default methods that safely release the lock once ready?
>>
>> Consider the following (dangerous) example.
>>
>> final Lock lock = new ReentrantLock ();
>> lock.lock();
>> /* Code that may throw an exception */
>> lock.unlock();
>>
>> This example will never release the lock if an exception is thrown, as the programmer didn?t wrap this up in a try/finally.
>>
>> Adding a default method within the Lock interface, called withLock(Runnable) for example or any better name, would streamline this, as shown next.
>>
>> default void withLock(final Runnable runnable) {
>>      requireNonNull(runnable, "Cannot run a null");
>>      lock();
>>      try {
>>          runnable.run();
>>      } finally {
>>          unlock();
>>      }
>> }
>>
>> The caller can now simply change the above example into the following, without having to worry about this.
>>
>> final Lock lock = new ReentrantLock ();
>> lock.withLock(() -> {
>>    /* Code that may throw an exception */
>> });
>>
>> We can have more variants of these default methods, as shown next.
>>
>> default <T> T getWithLock(final Supplier<T> supplier) {
>>      requireNonNull(supplier, "The supplier cannot be null");
>>      lock();
>>      try {
>>          return supplier.get();
>>      } finally {
>>          unlock();
>>      }
>> }
>>
>> Any thoughts?
>>
>> With kind regards,
>> Albert Attard

From pavel.rappo at oracle.com  Mon Aug 21 13:41:35 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 21 Aug 2023 13:41:35 +0000
Subject: Enrich the Lock interface
In-Reply-To: <9b53bb5f-383a-d8b7-8acd-2c8d3f9d340c@gmail.com>
References: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>
 <554805B7-C415-4051-A16A-EBAE9A16BE2D@oracle.com>
 <9b53bb5f-383a-d8b7-8acd-2c8d3f9d340c@gmail.com>
Message-ID: <CCADA3FE-FF31-4F74-BBCC-CC61DFC76064@oracle.com>

Okay. Here are some relevant messages/threads I've been able to find within 5 minutes, using google.com:

 * https://mail.openjdk.org/pipermail/coin-dev/2009-March/000267.html
 * https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043303.html
 * https://mail.openjdk.org/pipermail/discuss/2021-June/005819.html
 * https://mail.openjdk.org/pipermail/amber-spec-experts/2022-October/003596.html

There are more of those. Sadly, some reside on concurrency-interest, whose archives are inaccessible at the moment, either directly or through markmail.org <http://markmail.org/>.

-Pavel

> On 21 Aug 2023, at 14:24, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> I couldn't find a discussion on openjdk, but for those interested (and to save others some searching) there is a JBS ticket:
> 
> https://bugs.openjdk.org/browse/JDK-8025597
> 
> --John
> 
> On 21/08/2023 14:37, Pavel Rappo wrote:
>> This is suggested every once in a while. I appreciate that openjdk mailing lists are not easily searchable, but with a bit of skill, you could find a few previous discussions on the topic.
>> 
>> This has also been discussed on concurrency-interest (at cs.oswego.edu <http://cs.oswego.edu/>), a dedicated mailing list for concurrency in Java. Sadly, that list has been defunct for quite some time now.
>> 
>> -Pavel
>> 
>>> On 21 Aug 2023, at 13:18, Albert Attard <albertattard at gmail.com> wrote:
>>> 
>>> Hello.
>>> 
>>> I hope all is well.
>>> 
>>> Do you believe it is a bad idea to enrich the Lock interface with a set of default methods that safely release the lock once ready?
>>> 
>>> Consider the following (dangerous) example.
>>> 
>>> final Lock lock = new ReentrantLock ();
>>> lock.lock();
>>> /* Code that may throw an exception */
>>> lock.unlock();
>>> 
>>> This example will never release the lock if an exception is thrown, as the programmer didn?t wrap this up in a try/finally.
>>> 
>>> Adding a default method within the Lock interface, called withLock(Runnable) for example or any better name, would streamline this, as shown next.
>>> 
>>> default void withLock(final Runnable runnable) {
>>>     requireNonNull(runnable, "Cannot run a null");
>>>     lock();
>>>     try {
>>>         runnable.run();
>>>     } finally {
>>>         unlock();
>>>     }
>>> }
>>> 
>>> The caller can now simply change the above example into the following, without having to worry about this.
>>> 
>>> final Lock lock = new ReentrantLock ();
>>> lock.withLock(() -> {
>>>   /* Code that may throw an exception */
>>> });
>>> 
>>> We can have more variants of these default methods, as shown next.
>>> 
>>> default <T> T getWithLock(final Supplier<T> supplier) {
>>>     requireNonNull(supplier, "The supplier cannot be null");
>>>     lock();
>>>     try {
>>>         return supplier.get();
>>>     } finally {
>>>         unlock();
>>>     }
>>> }
>>> 
>>> Any thoughts?
>>> 
>>> With kind regards,
>>> Albert Attard


From sreyan32 at gmail.com  Mon Aug 21 13:43:48 2023
From: sreyan32 at gmail.com (Sreyan Chakravarty)
Date: Mon, 21 Aug 2023 19:13:48 +0530
Subject: ConcurrentHashMap - Removal for unnecessary bounds check i >= n || i
 + n >= nextn from transfer()
Message-ID: <CAMaziXtqLFbO-BAdWd4E5mXEAvN4m36RRXU3jUO+3CDBFotN6w@mail.gmail.com>

Hi,

I am trying to get my head around to why you need

 i >= n || i + n >= nextn

https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2465


in the transfer method of the CHM.

https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2426

The reasons why I think that this is not required is because :

1) At a time there can be only 1 active transfer. Since there is only one
table variable and only one newTable variable.

2) transferIndex is always set to oldTable.length before a transfer() takes
place

https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2440

3) transferIndex is always set to nextIndex - stride, nextIndex is always
set to transferIndex which in turn is always set to n (oldTable.length)

https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2456

https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2452

4) All threads that modifies the CHM must help with the transfer() before
finalizing the newTable

https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2467

Please let me know if I am going wrong anywhere

or if there are any code paths which can make i >=n when advance = false

Any help would be great.
-- 
Regards,
Sreyan Chakravarty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230821/45754fd3/attachment-0001.htm>

From albertattard at gmail.com  Mon Aug 21 13:56:40 2023
From: albertattard at gmail.com (Albert Attard)
Date: Mon, 21 Aug 2023 15:56:40 +0200
Subject: Enrich the Lock interface
In-Reply-To: <9b53bb5f-383a-d8b7-8acd-2c8d3f9d340c@gmail.com>
References: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>
 <554805B7-C415-4051-A16A-EBAE9A16BE2D@oracle.com>
 <9b53bb5f-383a-d8b7-8acd-2c8d3f9d340c@gmail.com>
Message-ID: <CABfnnZN+1yrZBr+qM-odwn9naAOwKrJ8NSY=gR9iiuj5fo60sg@mail.gmail.com>

Hello.

Thank you very much Pavel for helping me find more information about this.

After some research (mainly by Pavel) we found a thread, with subject "*Default
Functions for Lock Interface*", from October 2013 that discussed this exact
thing.  I don't believe that this thread is available on the internet, but
I may be wrong.

In this thread, two approaches were discussed.

   1. Add support for the try-with-resources
   2. Add default methods to the Lock interface


The second approach makes use of lambda functions which incur performance
cost when data is modified within the lambda function, as described by
Brian Goetz in the same thread (on the 8th of October 2013).

---















*When you write a method likevoid withLock(Runnable)the Runnable is going
to have side-effects. So its going to be a capturing lambda -- one that
captures variables from its scope:withLock( () -> { counter++; } ); //
counter is capturedWith the current implementation of lambda, evaluating
(not invoking) a capturing lambda expression will cause an allocation.
Whereas the hand-unrolled version:lock.lock();try { counter++; } finally {
lock.unlock(); }does not. The sort of things people do with locks are
generally pretty performance-sensitive, so such an API was deemed, at the
current time, to be an "attractive nuisance."*---

Almost 10 years have passed since this was originally suggested.  Have
enough things changed since then, that would make this approach feasible?

With kind regards,
Albert Attard


On Mon, 21 Aug 2023 at 15:33, John Hendrikx <john.hendrikx at gmail.com> wrote:

> I couldn't find a discussion on openjdk, but for those interested (and
> to save others some searching) there is a JBS ticket:
>
> https://bugs.openjdk.org/browse/JDK-8025597
>
> --John
>
> On 21/08/2023 14:37, Pavel Rappo wrote:
> > This is suggested every once in a while. I appreciate that openjdk
> mailing lists are not easily searchable, but with a bit of skill, you could
> find a few previous discussions on the topic.
> >
> > This has also been discussed on concurrency-interest (at cs.oswego.edu <
> http://cs.oswego.edu/>), a dedicated mailing list for concurrency in
> Java. Sadly, that list has been defunct for quite some time now.
> >
> > -Pavel
> >
> >> On 21 Aug 2023, at 13:18, Albert Attard <albertattard at gmail.com> wrote:
> >>
> >> Hello.
> >>
> >> I hope all is well.
> >>
> >> Do you believe it is a bad idea to enrich the Lock interface with a set
> of default methods that safely release the lock once ready?
> >>
> >> Consider the following (dangerous) example.
> >>
> >> final Lock lock = new ReentrantLock ();
> >> lock.lock();
> >> /* Code that may throw an exception */
> >> lock.unlock();
> >>
> >> This example will never release the lock if an exception is thrown, as
> the programmer didn?t wrap this up in a try/finally.
> >>
> >> Adding a default method within the Lock interface, called
> withLock(Runnable) for example or any better name, would streamline this,
> as shown next.
> >>
> >> default void withLock(final Runnable runnable) {
> >>      requireNonNull(runnable, "Cannot run a null");
> >>      lock();
> >>      try {
> >>          runnable.run();
> >>      } finally {
> >>          unlock();
> >>      }
> >> }
> >>
> >> The caller can now simply change the above example into the following,
> without having to worry about this.
> >>
> >> final Lock lock = new ReentrantLock ();
> >> lock.withLock(() -> {
> >>    /* Code that may throw an exception */
> >> });
> >>
> >> We can have more variants of these default methods, as shown next.
> >>
> >> default <T> T getWithLock(final Supplier<T> supplier) {
> >>      requireNonNull(supplier, "The supplier cannot be null");
> >>      lock();
> >>      try {
> >>          return supplier.get();
> >>      } finally {
> >>          unlock();
> >>      }
> >> }
> >>
> >> Any thoughts?
> >>
> >> With kind regards,
> >> Albert Attard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230821/c6235a36/attachment.htm>

From vtewari at openjdk.org  Mon Aug 21 14:34:02 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 21 Aug 2023 14:34:02 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
Message-ID: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>

With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.

-------------

Commit messages:
 - 4799358: BufferOutputStream.write() should immediately throw IOException on closed stream

Changes: https://git.openjdk.org/jdk/pull/15361/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15361&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4799358
  Stats: 75 lines in 3 files changed: 75 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15361/head:pull/15361

PR: https://git.openjdk.org/jdk/pull/15361

From alanb at openjdk.org  Mon Aug 21 14:42:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Aug 2023 14:42:28 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
In-Reply-To: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
Message-ID: <R-urK5nyGCYdJxYHTc4lGuXiZlGiTvIoeWprpWv0SP8=.be4bae87-540c-4f04-b54f-d4d0d908de83@github.com>

On Mon, 21 Aug 2023 14:26:39 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.

src/java.base/share/classes/java/io/FilterOutputStream.java line 209:

> 207:      * @return {@code true} if, and only if, this stream is open
> 208:      */
> 209:     protected boolean isOpen(){

Adding a protected method to a public class in an exported packages means this is a new  API, it will require discussion, I don't know if you meant to do this or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1300205399

From vtewari at openjdk.org  Mon Aug 21 14:53:28 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Mon, 21 Aug 2023 14:53:28 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
In-Reply-To: <R-urK5nyGCYdJxYHTc4lGuXiZlGiTvIoeWprpWv0SP8=.be4bae87-540c-4f04-b54f-d4d0d908de83@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <R-urK5nyGCYdJxYHTc4lGuXiZlGiTvIoeWprpWv0SP8=.be4bae87-540c-4f04-b54f-d4d0d908de83@github.com>
Message-ID: <zYIesyOnuBshWBv0O-LOADiPsTnnfEmOEPDFFWjNQYE=.12e73978-12c6-4dfc-8acb-0b7ebc4751cb@github.com>

On Mon, 21 Aug 2023 14:37:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.
>
> src/java.base/share/classes/java/io/FilterOutputStream.java line 209:
> 
>> 207:      * @return {@code true} if, and only if, this stream is open
>> 208:      */
>> 209:     protected boolean isOpen(){
> 
> Adding a protected method to a public class in an exported packages means this is a new  API, it will require discussion, I don't know if you meant to do this or not.

I thought of this ,but i was not 100% sure. I will create CSR first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1300222044

From duke at openjdk.org  Mon Aug 21 15:01:14 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 21 Aug 2023 15:01:14 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v8]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <CucQtP9pea04ylRXVZJN-_Uem1K2pS3wJOMnxPWyf0A=.84306f69-28bf-4b27-bf05-26207c531c41@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the code based on the review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/e9e0497f..8c23a747

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=06-07

  Stats: 70 lines in 2 files changed: 22 ins; 23 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Mon Aug 21 15:01:17 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 21 Aug 2023 15:01:17 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v7]
In-Reply-To: <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <qYc-Ps6rjnncuFjlCycSOEMjfSW133v4XpZ7lrTZfiU=.3aaa2a0d-5f7e-4494-bd57-b4b1afbab270@github.com>
Message-ID: <uet8rBke_4N5U5CAcIRGJQ0Wz2BzTg2114r_OqoT23I=.e1941243-2a31-407b-90d8-ed8a5015daee@github.com>

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the code and test cases

1) Reformat the test code
2) Add one more comment in Connection.java
3) Updated the test code base on the review comment

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1686489715

From liach at openjdk.org  Mon Aug 21 15:03:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Aug 2023 15:03:37 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
In-Reply-To: <zYIesyOnuBshWBv0O-LOADiPsTnnfEmOEPDFFWjNQYE=.12e73978-12c6-4dfc-8acb-0b7ebc4751cb@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <R-urK5nyGCYdJxYHTc4lGuXiZlGiTvIoeWprpWv0SP8=.be4bae87-540c-4f04-b54f-d4d0d908de83@github.com>
 <zYIesyOnuBshWBv0O-LOADiPsTnnfEmOEPDFFWjNQYE=.12e73978-12c6-4dfc-8acb-0b7ebc4751cb@github.com>
Message-ID: <rgOHMFnChaA9Odfup_IsCACCppgg_3gVDi62_zwqy-o=.d99b495f-26f2-4b00-b70f-b75c6223fbb4@github.com>

On Mon, 21 Aug 2023 14:50:12 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FilterOutputStream.java line 209:
>> 
>>> 207:      * @return {@code true} if, and only if, this stream is open
>>> 208:      */
>>> 209:     protected boolean isOpen(){
>> 
>> Adding a protected method to a public class in an exported packages means this is a new  API, it will require discussion, I don't know if you meant to do this or not.
>
> I thought of this ,but i was not 100% sure. I will create CSR first.

You can convert this method, or the `closed` field, to be package-private (default access) instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1300236089

From liach at openjdk.org  Mon Aug 21 15:03:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 21 Aug 2023 15:03:34 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
In-Reply-To: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
Message-ID: <4php3yqAcMsaPT8T2JcpIWHXS1sm0G41mdF2C1No_qY=.49794260-23af-4447-98b7-408f646d6a94@github.com>

On Mon, 21 Aug 2023 14:26:39 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.

`write(int)` should have an `ensureOpen` check too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15361#issuecomment-1686499580

From alanb at openjdk.org  Mon Aug 21 15:08:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 21 Aug 2023 15:08:37 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
In-Reply-To: <rgOHMFnChaA9Odfup_IsCACCppgg_3gVDi62_zwqy-o=.d99b495f-26f2-4b00-b70f-b75c6223fbb4@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <R-urK5nyGCYdJxYHTc4lGuXiZlGiTvIoeWprpWv0SP8=.be4bae87-540c-4f04-b54f-d4d0d908de83@github.com>
 <zYIesyOnuBshWBv0O-LOADiPsTnnfEmOEPDFFWjNQYE=.12e73978-12c6-4dfc-8acb-0b7ebc4751cb@github.com>
 <rgOHMFnChaA9Odfup_IsCACCppgg_3gVDi62_zwqy-o=.d99b495f-26f2-4b00-b70f-b75c6223fbb4@github.com>
Message-ID: <Z8_44bkT__wwbcn52kb6G5tLhieEUOuVxhyaFLpQMQU=.c48a4c73-a908-4ecd-bf11-b75a4c7911cf@github.com>

On Mon, 21 Aug 2023 15:00:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I thought of this ,but i was not 100% sure. I will create CSR first.
>
> You can convert this method, or the `closed` field, to be package-private (default access) instead.

> I thought of this ,but i was not 100% sure. I will create CSR first.

The current patch changes long standing behavior so that will be the focus of the CSR if this change goes away. I think get agreement on that part first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1300242064

From dl at openjdk.org  Mon Aug 21 15:38:59 2023
From: dl at openjdk.org (Doug Lea)
Date: Mon, 21 Aug 2023 15:38:59 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v11]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <1oSL4nJyQgqt2JdB6dREfN1YtHh6JeoHhMKhBrb7LCY=.07f4d17f-0a8a-447d-85fd-b24134d020b8@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Run close tests in seperate threads

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/50fe9a4a..76abc1fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=09-10

  Stats: 40 lines in 1 file changed: 16 ins; 11 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From bpb at openjdk.org  Mon Aug 21 15:44:56 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Aug 2023 15:44:56 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent [v2]
In-Reply-To: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
Message-ID: <wHIFYIPu0RimnLnY130np17uRKVpfyVX8jlUB-CzU0c=.8283c235-9153-40cd-87df-104ebbef0994@github.com>

> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8219567: Align checkWrite() verbiage with that of checkRead()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15351/files
  - new: https://git.openjdk.org/jdk/pull/15351/files/d8e43b53..ef91651b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15351&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15351&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15351/head:pull/15351

PR: https://git.openjdk.org/jdk/pull/15351

From bpb at openjdk.org  Mon Aug 21 15:44:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 21 Aug 2023 15:44:57 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent [v2]
In-Reply-To: <aDs1bcK6HLiFCjto5gfxxe4qpaf1HxWnDzYkGy-23ag=.fa8da5d5-0a03-4535-a5ae-21175c83fc8b@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
 <aDs1bcK6HLiFCjto5gfxxe4qpaf1HxWnDzYkGy-23ag=.fa8da5d5-0a03-4535-a5ae-21175c83fc8b@github.com>
Message-ID: <9OXQhDTMuzgP1zRCzuoTcJfe7SCvNDq7vEFMuA7p6_k=.6ac423f6-4a2d-40c9-86aa-8146259417e7@github.com>

On Sun, 20 Aug 2023 06:28:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8219567: Align checkWrite() verbiage with that of checkRead()
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 213:
> 
>> 211:      * @throws      SecurityException  if a security manager exists and its
>> 212:      *             {@code checkRead} method denies read access to the file
>> 213:      *             or the mode is {@code "rw"} and the security manager's
> 
> GitHub UI isn't allowing me to add a review comment on line 195, so adding it here. Should line 195 be changed to say:
> 
> 
> also called with the pathname of the {@code file} argument to see if write access to the file...
> 
> to match what it says a few lines above for the `checkRead` security check?

You are correct - thanks. So changed in ef91651b35cd30a7a11ac75ebbdc03a9c29c59e3.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15351#discussion_r1300295699

From rgiulietti at openjdk.org  Mon Aug 21 15:54:03 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Aug 2023 15:54:03 GMT
Subject: RFR: 8313961: Enhance identification of special serialization methods
Message-ID: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>

This improves the identification of the serialization magic fields and methods.

-------------

Commit messages:
 - 8313961: Enhance identification of special serialization methods
 - 8313961: Enhance identification of special serialization methods
 - Merge branch 'master' into 8313961
 - 8313961: Enhance identification of special serialization methods
 - Merge branch 'master' into 8313961
 - Using getDeclaredMethod() in getInheritableMethod().
 - Using getDeclaredMethod() in getPrivateMethod().

Changes: https://git.openjdk.org/jdk/pull/15364/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15364&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313961
  Stats: 349 lines in 4 files changed: 322 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15364/head:pull/15364

PR: https://git.openjdk.org/jdk/pull/15364

From davidalayachew at gmail.com  Mon Aug 21 15:59:24 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 21 Aug 2023 11:59:24 -0400
Subject: @Incubating
In-Reply-To: <D9DE42BE-02E6-4501-9CAB-C6C98C6EFCCD@oracle.com>
References: <D9DE42BE-02E6-4501-9CAB-C6C98C6EFCCD@oracle.com>
Message-ID: <CAA9v-_MuGTEYJWVnQO463YWOgLedx=H7BNHrmp07nAB_+o200Q@mail.gmail.com>

Hello Pavel,

I am not on the teams of any of the mailing lists you responded to, but I
feel confident that I can answer this.


Most, if not all annotations provided by Java (@Override,
@SuppressWarnings, @FunctionalInterface) actually start with uppercase.
This is, in fact, maintaining the status quo.

It may help to remember that annotations are written much like how you
write a class or an interface. Therefore, their naming conventions follow
those of classes and interfaces, which is to say, they start with an upper
case letter.

Thank you for reaching out!
David Alayachew

On Mon, Aug 21, 2023 at 5:57?AM Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Does anybody remember why {@Incubating}, a JDK-specific tag introduced in
> JDK-8173354, starts with an uppercase letter? Put differently, are there
> any reasons why we should not make it conform to implicit convention of
> camelCase, like all other standard and JDK tags do?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230821/3911a11c/attachment.htm>

From davidalayachew at gmail.com  Mon Aug 21 16:02:55 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 21 Aug 2023 12:02:55 -0400
Subject: @Incubating
In-Reply-To: <CAA9v-_MuGTEYJWVnQO463YWOgLedx=H7BNHrmp07nAB_+o200Q@mail.gmail.com>
References: <D9DE42BE-02E6-4501-9CAB-C6C98C6EFCCD@oracle.com>
 <CAA9v-_MuGTEYJWVnQO463YWOgLedx=H7BNHrmp07nAB_+o200Q@mail.gmail.com>
Message-ID: <CAA9v-_PzoGEVT+Yx92RgyRzNJpHymGoAe-yDzqAVH79kDoL3QQ@mail.gmail.com>

Oh, I see that you are referring to JavaDoc tags as opposed to Java
Annotations. In that case, nevermind.

On Mon, Aug 21, 2023 at 11:59?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Pavel,
>
> I am not on the teams of any of the mailing lists you responded to, but I
> feel confident that I can answer this.
>
>
> Most, if not all annotations provided by Java (@Override,
> @SuppressWarnings, @FunctionalInterface) actually start with uppercase.
> This is, in fact, maintaining the status quo.
>
> It may help to remember that annotations are written much like how you
> write a class or an interface. Therefore, their naming conventions follow
> those of classes and interfaces, which is to say, they start with an upper
> case letter.
>
> Thank you for reaching out!
> David Alayachew
>
> On Mon, Aug 21, 2023 at 5:57?AM Pavel Rappo <pavel.rappo at oracle.com>
> wrote:
>
>> Does anybody remember why {@Incubating}, a JDK-specific tag introduced in
>> JDK-8173354, starts with an uppercase letter? Put differently, are there
>> any reasons why we should not make it conform to implicit convention of
>> camelCase, like all other standard and JDK tags do?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230821/55bd3967/attachment-0001.htm>

From rgiulietti at openjdk.org  Mon Aug 21 16:04:49 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Aug 2023 16:04:49 GMT
Subject: RFR: 8313961: Enhance identification of special serialization
 methods [v2]
In-Reply-To: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
References: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
Message-ID: <DD6tD2pGlKlADXTxKWJxxUbivRktIdobutSGhqDr1jE=.c5ce640a-cc33-4725-91f7-abd490af12b7@github.com>

> This improves the identification of the serialization magic fields and methods.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Removed a spurious, unintended file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15364/files
  - new: https://git.openjdk.org/jdk/pull/15364/files/bc93873f..b74bc7a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15364&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15364&range=00-01

  Stats: 33 lines in 1 file changed: 0 ins; 33 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15364/head:pull/15364

PR: https://git.openjdk.org/jdk/pull/15364

From rgiulietti at openjdk.org  Mon Aug 21 16:06:28 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Aug 2023 16:06:28 GMT
Subject: RFR: 8313961: Enhance identification of special serialization
 methods
In-Reply-To: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
References: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
Message-ID: <AUb85OlE0KpVkqWkjoiUwqHK-Xc0skiGiCWzsjpZ74A=.71b39561-20f6-4367-b9d5-5bb47f7d3c0b@github.com>

On Mon, 21 Aug 2023 15:46:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This improves the identification of the serialization magic fields and methods.

The test is a bit unusual, in that it uses the [Classfile API](https://openjdk.org/jeps/8280389). It is used to generate two classes that cannot be expressed in the Java language, as they contain multiple fields with the same name but different types, and mulitple methods with the same name and parameter types but different return types.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15364#issuecomment-1686607139

From duke at openjdk.org  Mon Aug 21 16:22:31 2023
From: duke at openjdk.org (ExE Boss)
Date: Mon, 21 Aug 2023 16:22:31 GMT
Subject: RFR: 8313961: Enhance identification of special serialization
 methods [v2]
In-Reply-To: <DD6tD2pGlKlADXTxKWJxxUbivRktIdobutSGhqDr1jE=.c5ce640a-cc33-4725-91f7-abd490af12b7@github.com>
References: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
 <DD6tD2pGlKlADXTxKWJxxUbivRktIdobutSGhqDr1jE=.c5ce640a-cc33-4725-91f7-abd490af12b7@github.com>
Message-ID: <OiOBUf9nD97CXZWaL5ZGmQn8_S1cYd8RgLaYnFemXW4=.81537c69-5caf-420e-a92a-93da16e08e8a@github.com>

On Mon, 21 Aug 2023 16:04:49 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This improves the identification of the serialization magic fields and methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed a spurious, unintended file.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 1670:

> 1668:         ObjectStreamField[] serialPersistentFields = null;
> 1669:         try {
> 1670:             Field f = getDeclaredField(cl, ObjectStreamField[].class, "serialPersistentFields");

This?can?technically be?a?breaking?change, as?it?was?supported for?the?field to?have a?declared?type that?is?assignable from?`ObjectStreamField[]`, as?long?as it?held an?`ObjectStreamField[]`?instance at?runtime, even?if it?wasn?t officially?supported.


class Example implements Serializable {
	// This used to work before this patch in OpenJDK
	private static final Object serialPersistentFields = new ObjectStreamField[] {
		// ...
	};

	// ...
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15364#discussion_r1300341941

From rriggs at openjdk.org  Mon Aug 21 16:41:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 21 Aug 2023 16:41:27 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent [v2]
In-Reply-To: <wHIFYIPu0RimnLnY130np17uRKVpfyVX8jlUB-CzU0c=.8283c235-9153-40cd-87df-104ebbef0994@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
 <wHIFYIPu0RimnLnY130np17uRKVpfyVX8jlUB-CzU0c=.8283c235-9153-40cd-87df-104ebbef0994@github.com>
Message-ID: <S_shIP1Y7p-Lv-iF5m--2WFrjP6hwKLGG63v79hClqw=.60608a69-6af8-41a0-8c03-aa366218bfdd@github.com>

On Mon, 21 Aug 2023 15:44:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8219567: Align checkWrite() verbiage with that of checkRead()

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15351#pullrequestreview-1587434253

From rgiulietti at openjdk.org  Mon Aug 21 17:00:28 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 21 Aug 2023 17:00:28 GMT
Subject: RFR: 8313961: Enhance identification of special serialization
 methods [v2]
In-Reply-To: <OiOBUf9nD97CXZWaL5ZGmQn8_S1cYd8RgLaYnFemXW4=.81537c69-5caf-420e-a92a-93da16e08e8a@github.com>
References: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
 <DD6tD2pGlKlADXTxKWJxxUbivRktIdobutSGhqDr1jE=.c5ce640a-cc33-4725-91f7-abd490af12b7@github.com>
 <OiOBUf9nD97CXZWaL5ZGmQn8_S1cYd8RgLaYnFemXW4=.81537c69-5caf-420e-a92a-93da16e08e8a@github.com>
Message-ID: <7T9BconZt9CyoJvaMiS2p-vmtavPiuJvQ1DpHQszrTA=.ce2e0961-edf6-426b-be0f-7b556c885678@github.com>

On Mon, 21 Aug 2023 16:13:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed a spurious, unintended file.
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 1670:
> 
>> 1668:         ObjectStreamField[] serialPersistentFields = null;
>> 1669:         try {
>> 1670:             Field f = getDeclaredField(cl, ObjectStreamField[].class, "serialPersistentFields");
> 
> This?can?technically be?a?breaking?change, as?it?was?supported for?the?field to?have a?declared?type that?is?assignable from?`ObjectStreamField[]`, as?long?as it?held an?`ObjectStreamField[]`?instance at?runtime, even?if it?wasn?t officially?supported.
> 
> 
> class Example implements Serializable {
> 	// This used to work before this patch in OpenJDK
> 	private static final Object serialPersistentFields = new ObjectStreamField[] {
> 		// ...
> 	};
> 
> 	// ...
> }

True.

On the other hand, what about a .class file that includes all of (pseudo-Java)


    private static final Object              serialPersistentFields = new ObjectStreamField[0];
    private static final Cloneable           serialPersistentFields = new ObjectStreamField[0];
    private static final Serializable        serialPersistentFields = new ObjectStreamField[0];
    private static final ObjectStreamField[] serialPersistentFields = new SubclassOfObjectStreamField[0];


Which one is the "preferred" field?

Perhaps the Java Object Serialization Specification should simply prohibit multiple `serialPersistentFields`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15364#discussion_r1300400056

From rriggs at openjdk.org  Mon Aug 21 20:10:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 21 Aug 2023 20:10:30 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
Message-ID: <M0CEqxl6xhHXOlH5rhPp_I3Xni70vc8mxDh0YmxYV40=.bb4c588d-6624-4f22-adab-e045ab688c32@github.com>

On Mon, 21 Aug 2023 07:14:44 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: use /proc/self/exe as the backup option

test/jdk/tools/launcher/Jexec.java line 44:

> 42: import java.util.Map;
> 43: import java.util.UUID;
> 44: import java.util.HashMap;

Check if the imports are really used.  I can't imagine why java.beans.Transient would be needed, ditto UUID, etc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1300594902

From mchung at openjdk.org  Mon Aug 21 20:15:30 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 21 Aug 2023 20:15:30 GMT
Subject: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked
 reflectively [v3]
In-Reply-To: <cH3L7Wp-PX2ojZ0feZSJ_jWaOfrm5CoJRXEuDUbe0Ic=.15381ede-df75-41a6-9d36-abad98618acd@github.com>
References: <sJ_D_T_gW8UL-00VXYTVHDe0i-A4q3w-7x0yh5Igis4=.08b80d5a-e9a2-4e67-95c6-23e53bb33072@github.com>
 <BhLE3dfNH4BcJr1wdYplaRLON1PAABl_Kxw9bE0S36k=.388595b3-0094-41af-ad7c-ce8183fb72b2@github.com>
 <cH3L7Wp-PX2ojZ0feZSJ_jWaOfrm5CoJRXEuDUbe0Ic=.15381ede-df75-41a6-9d36-abad98618acd@github.com>
Message-ID: <rfyTlb2Olj2qKWsHFhAqJX3zNwnd8Ah0TPOn7i0ShJM=.5b3d3610-a3fc-4343-96e5-b89de39d581d@github.com>

On Mon, 17 Jul 2023 11:02:38 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed case when calling getCallerClass() from a @CallerSensitive method reflectively
>
> We actually have two problems here:
> 1. If called refelctively, `getCallerClass()` can throw an UOE even if it was **not** called from a `@CallerSensitive` method (see inital test case).
> 2. If called reflectively from a  `@CallerSensitive` method, `getCallerClass()` will currently not throw a UOE as expected (see extended test in this PR).
> 
> `getCallerClass()` **is** performance sensitive and we want to improve its performance rather than slow it down (see [JDK-8285447](https://bugs.openjdk.org/browse/JDK-8285447)). I think performance-wise it would be better to do all the filtering in the VM, where we have all the required information at hand and minimize the amount of data that needs to be passed between Java and the VM.
> 
> Before starting to implement a new version of the fix which moves all the checks to Java, I'd like to hear some more opinions about whether we agree to move all the filtering and checks from the VM to Java (even at the cost of performance regressions) or if we better want to go the other way and do all the filtering/checks in the JVM. @shipilev, @dholmes-ora, @dfuch, @AlanBateman - what do you think?

@simonis  please see #15370 to show the alternative fix for this issue and do the filtering in Java.  The benchmark shows about 30-60 ns slowdown.  I think it's acceptable with the benefit of keeping the filtering in the libraries rather than in VM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14773#issuecomment-1686977577

From vpetko at openjdk.org  Mon Aug 21 20:35:46 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 20:35:46 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v4]
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <nZIVLPQiVm1CWbdr-l1t_NY3c5rHTNulPboaUPGPxsk=.57f6aa25-5f54-4402-942b-271f9342ccde@github.com>

> 8314491: Linux: jexec launched via PATH fails to find java

Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:

  remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15343/files
  - new: https://git.openjdk.org/jdk/pull/15343/files/3f832c40..a2e8a045

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=02-03

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From vpetko at openjdk.org  Mon Aug 21 20:35:48 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 20:35:48 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <KdtDoYNOqiy135qcyi46qBnFpXb4ZmNdOKekcX56fhs=.b125ad1e-e901-4301-be36-7deb2f751eb0@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
 <KdtDoYNOqiy135qcyi46qBnFpXb4ZmNdOKekcX56fhs=.b125ad1e-e901-4301-be36-7deb2f751eb0@github.com>
Message-ID: <8FTt19ZCKrMBbwQ5lXy648Lk9atsQhya8KHkWPbWsP4=.cf28bf4e-bbf8-4f41-9c9b-17f0403c4fa7@github.com>

On Mon, 21 Aug 2023 07:59:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`

This one was intentional to keep the style consistent =)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1300614894

From mchung at openjdk.org  Mon Aug 21 20:37:47 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 21 Aug 2023 20:37:47 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with Class
 object only
Message-ID: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>

8268829: Provide an optimized way to walk the stack with Class object only

`StackWalker::walk` creates one `StackFrame` per frame and the current implementation
allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
like logging may only interest in the Class object but not the method name nor the BCI,
for example, filters out its implementation classes to find the caller class.  It's
similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.

This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option.
If no method information is needed, this option can be used such that the
stack walker will save the overhead (1) to extract the method information
and (2) the memory used for the stack walking.   In addition, this can also fix

- [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively

Adding `NO_METHOD_TIME` option provides a simple way for existing code,
for example logging frameworks, to take advantage of this enhancement with
the least change as it can keep the existing implementation in traversing
`StackFrame`s.

For example: to find the first caller filtering a known list of implementation class,
existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance`
to create a stack walker instance:


     StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO);
     Optional<Class<?>> callerClass = walker.walk(s ->
             s.map(StackFrame::getDeclaringClass)
              .filter(interestingClasses::contains)
              .findFirst());


If method information is accessed on the `StackFrame`s produced by this stack walker such as
`StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.

The alternative considered is to provide a new API:
`<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`

In this case, the caller would need to pass a function that takes a stream
of `Class` object instead of `StackFrame`.  Existing code would have to
modify calls to the `walk` method to `walkClass` and the function body.

### Implementation Details

If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]`
buffer that is filled by the VM during stack walking.   `ClassFrameInfo` holds the 
Class instance plus `flags`  which indicate if it's caller sensitive or hidden.  
With this change, `StackWalker::getCallerClass` can also use `ClassFrameInfo[]` buffer
to replace the special `Class` buffer and remove the special check in the VM. 
JDK-8311500 can be fixed in Java.

If `NO_METHOD_NAME` is not set, the implementation creates `StackFrameInfo[]` buffer. 
`StackFrameInfo` is a subclass of `ClassFrameInfo`.  It keeps `ResolvedMethodName` and all other method information.

### Performance

The memory usage of the data structure (shown by -XX:PrintFieldLayout):

| Type | Instance size |
| ---- | ------------ |
| `ClassFrameInfo` | 24 bytes |
| `StackFrameInfo` | 48 bytes |
| `ResolvedMethodName` | 24 bytes |
| `MemberName` | 48 bytes |
| `StackFrameInfo` (old) | 32 bytes |

The existing implementation allocates a total of 104 bytes for each frame
 (`StackFrameInfo` + `MemberName` + `ResolvedMethodName`).
The new implementation, without `NO_METHOD_INFO` option, allocates a total of 72 bytes
for each frame (`StackFrameInfo` + `ResolvedMethodName`) which saves 30% of the
buffer memory.
With `NO_METHOD_INFO`, 24 bytes is allocated for each frame (only `ClassFrameInfo` is needed).
In addition, it saves the overhead in creating `ResolvedMethodName` object in the VM.

The microbenchmark shows that the runtime performance of stack walking with method information
is 15-31% faster than the old implementation.   Using `NO_METHOD_INFO` option, it
is about 21-43% faster compared to traversing the frames without `NO_METHOD_INFO`
in the new implementation.

#### `StackWalker::getCallerClass`

`StackWalkBench::getCallerClass` shows about 30-60 ns degradation.    The old implementation creates
a `Class` array of size 8 whereas the new implementation which creates a `ClassFrameInfo` array
of size 8 initialized with 6 `ClassFrameInfo` elements.    The new implementation of `getCallerClass`
adds 144 bytes more, which is insignificant.   The benefit of this is to do the filtering in Java rather 
than doing in VM.

`StackWalkBench::getCallerClass` includes the cost of setting up the call stack.  There is no good way
to write a JMH benchmark just to measure the performance of `getCallerClass`.   If I measured `getCallerClass`
with a standalone benchmark, it shows `getCallerClass` takes roughly about 8500-10000 ns range on
my macos-aarch64 machine.  The 30-60 ns degradation is negligible.

-------------

Commit messages:
 - fix trailing whitespace
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Update LocalLongHelper.java
 - clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Add StackWalker.Option.NO_METHOD_INFO
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - ... and 3 more: https://git.openjdk.org/jdk/compare/78f74bc8...e9e2b390

Changes: https://git.openjdk.org/jdk/pull/15370/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8268829
  Stats: 1026 lines in 30 files changed: 628 ins; 178 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From mchung at openjdk.org  Mon Aug 21 21:10:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 21 Aug 2023 21:10:36 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v2]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <xLaThups-UlR8gEZnCY6prtOw-aty7_Y7xSCWHEIFYw=.5bf80110-707a-4855-9931-624a7a07ec96@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option.
> If no method information is needed, this option can be used such that the
> stack walker will save the overhead (1) to extract the method information
> and (2) the memory used for the stack walking.   In addition, this can also fix
> 
> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
> 
> Adding `NO_METHOD_TIME` option provides a simple way for existing code,
> for example logging frameworks, to take advantage of this enhancement with
> the least change as it can keep the existing implementation in traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance`
> to create a stack walker instance:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(interestingClasses::contains)
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> The alternative considered is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> ### Implementation Details
> 
> If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]`
> buffer that is filled by the VM during stack walking.   `ClassFrameInfo` holds the 
> Class instance plus `flags`  which indicate if it's caller sensitive or hidden.  
> With this change, `StackWalker::getCa...

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15370/files
  - new: https://git.openjdk.org/jdk/pull/15370/files/e9e2b390..87775552

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=00-01

  Stats: 6 lines in 4 files changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From dholmes at openjdk.org  Mon Aug 21 21:39:29 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 21 Aug 2023 21:39:29 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <8FTt19ZCKrMBbwQ5lXy648Lk9atsQhya8KHkWPbWsP4=.cf28bf4e-bbf8-4f41-9c9b-17f0403c4fa7@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
 <KdtDoYNOqiy135qcyi46qBnFpXb4ZmNdOKekcX56fhs=.b125ad1e-e901-4301-be36-7deb2f751eb0@github.com>
 <8FTt19ZCKrMBbwQ5lXy648Lk9atsQhya8KHkWPbWsP4=.cf28bf4e-bbf8-4f41-9c9b-17f0403c4fa7@github.com>
Message-ID: <oiC9RebNymDh9_t2ZWMOTBrZgiHfJcUAa1YxB1b0cV4=.75521752-965d-45ac-8a12-e4562c33376e@github.com>

On Mon, 21 Aug 2023 20:30:54 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> src/java.base/unix/native/launcher/jexec.c line 162:
>> 
>>> 160:     int           argi  = 0;             /* index into old array */
>>> 161:     size_t        alen  = 0;             /* length of new array */
>>> 162:     int           error = 0;             /* getJavaPath error */
>> 
>> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`
>
>> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`
> 
> This one was intentional to keep the style consistent =)

The others are more widely used and there is a desire to document their meaning. That isn't necessary for this case, but as I said, just a nit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1300672926

From duke at openjdk.org  Mon Aug 21 22:10:06 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 21 Aug 2023 22:10:06 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v9]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  use original logic to create socket to avoid the compatibility issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/8c23a747..212ee7fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=07-08

  Stats: 43 lines in 1 file changed: 24 ins; 0 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Mon Aug 21 22:33:31 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Mon, 21 Aug 2023 22:33:31 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v9]
In-Reply-To: <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>
Message-ID: <4lul4nHhdJo7ynIQOqRCmYOysoMx4aNDJKpZNwQbxeI=.2bebb4bd-deb8-429c-bef7-35e238389f4b@github.com>

On Mon, 21 Aug 2023 22:10:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use original logic to create socket to avoid the compatibility issue

Brought back the original logic. The modified logic created the compatibility issue.
Please check the change again. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1687137973

From mchung at openjdk.org  Mon Aug 21 22:35:27 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 21 Aug 2023 22:35:27 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v2]
In-Reply-To: <xLaThups-UlR8gEZnCY6prtOw-aty7_Y7xSCWHEIFYw=.5bf80110-707a-4855-9931-624a7a07ec96@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <xLaThups-UlR8gEZnCY6prtOw-aty7_Y7xSCWHEIFYw=.5bf80110-707a-4855-9931-624a7a07ec96@github.com>
Message-ID: <nsg-YlihQzCOT7MD0J1pq7K_nrIMd4etIJTWgpGvpZs=.ce177a54-8612-413e-b960-63667f3f8fe2@github.com>

On Mon, 21 Aug 2023 21:10:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option.
>> If no method information is needed, this option can be used such that the
>> stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> Adding `NO_METHOD_TIME` option provides a simple way for existing code,
>> for example logging frameworks, to take advantage of this enhancement with
>> the least change as it can keep the existing implementation in traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance`
>> to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> The alternative considered is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]`
>> buffer that is filled by the VM during stack walking.   `ClassFrameInfo` holds the 
>> Class instance plus `flag...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

@vidmik gave the feedback about the name of the option `NO_METHOD_INFO`, generally preferred a positive word.   I do agree.   One option is to introduce  `enum Kind { CLASS_INFO, METHOD_INFO}` instead of `NO_METHOD_INFO` and new factory methods `getInstance(Kind kind, Option... option)`.  
`getInstance()` is equivalent to `getInstance(METHOD_INFO)`.   To collect class only, do

getInstance(CLASS_INFO);
getInstance(CLASS_INFO, RETAIN_CLASS_REFERENCE);


I think a new enum is a cleaner way to specify what information to collect.    Any feedback/thought before I update this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1687140453

From vpetko at openjdk.org  Mon Aug 21 22:52:53 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 22:52:53 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v5]
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <eNtOh9Q7Q2IiCMUVNnfyylYot0aXaIDhALHLlgXb_g8=.f5dc446b-bb31-4d41-9547-b0056592e02e@github.com>

> 8314491: Linux: jexec launched via PATH fails to find java

Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:

  declare error in-place

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15343/files
  - new: https://git.openjdk.org/jdk/pull/15343/files/a2e8a045..c974e011

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From vpetko at openjdk.org  Mon Aug 21 22:52:53 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 21 Aug 2023 22:52:53 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v3]
In-Reply-To: <oiC9RebNymDh9_t2ZWMOTBrZgiHfJcUAa1YxB1b0cV4=.75521752-965d-45ac-8a12-e4562c33376e@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <XoPhRaYqjZSg5-ZaMfEIYnmJioOcyQMrBCmQm1ExDpk=.804650f0-6b4b-46ee-a14d-663b0e66e09a@github.com>
 <KdtDoYNOqiy135qcyi46qBnFpXb4ZmNdOKekcX56fhs=.b125ad1e-e901-4301-be36-7deb2f751eb0@github.com>
 <8FTt19ZCKrMBbwQ5lXy648Lk9atsQhya8KHkWPbWsP4=.cf28bf4e-bbf8-4f41-9c9b-17f0403c4fa7@github.com>
 <oiC9RebNymDh9_t2ZWMOTBrZgiHfJcUAa1YxB1b0cV4=.75521752-965d-45ac-8a12-e4562c33376e@github.com>
Message-ID: <7DdtbWW84e3LDqQmXzFP9utxNmyM2lOVFsltz6LjPvo=.68b2ec9c-5e56-4994-973e-ceeaac6865c1@github.com>

On Mon, 21 Aug 2023 21:36:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)`
>> 
>> This one was intentional to keep the style consistent =)
>
> The others are more widely used and there is a desire to document their meaning. That isn't necessary for this case, but as I said, just a nit.

Updated and re-run Jexec test. 


==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/tools/launcher/Jexec.java              1     1     0     0   
==============================
TEST SUCCESS

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1300725435

From duke at openjdk.org  Tue Aug 22 01:18:48 2023
From: duke at openjdk.org (duke)
Date: Tue, 22 Aug 2023 01:18:48 GMT
Subject: Withdrawn: 8307575: Migrate the serialization constructor accessors to
 Method Handles
In-Reply-To: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
References: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
Message-ID: <SKOfVKNz14XVf6KQYA57qExBQdxhv_2REHbupad3S6Q=.6a25131a-3fa6-4b74-8021-1ebfd41898c7@github.com>

On Sat, 6 May 2023 16:55:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation.
> 
> Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects.
> 
> #1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13853

From jpai at openjdk.org  Tue Aug 22 05:01:30 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Aug 2023 05:01:30 GMT
Subject: RFR: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent [v2]
In-Reply-To: <wHIFYIPu0RimnLnY130np17uRKVpfyVX8jlUB-CzU0c=.8283c235-9153-40cd-87df-104ebbef0994@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
 <wHIFYIPu0RimnLnY130np17uRKVpfyVX8jlUB-CzU0c=.8283c235-9153-40cd-87df-104ebbef0994@github.com>
Message-ID: <c1VboxJrZlJ2Yvs-_wgfo3fPOifNrDVJEGcFa6ZlKeM=.c228f308-f43c-4c46-a0e8-14860e2f9c3e@github.com>

On Mon, 21 Aug 2023 15:44:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8219567: Align checkWrite() verbiage with that of checkRead()

Thank you Brian, looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15351#pullrequestreview-1588288160

From david.holmes at oracle.com  Tue Aug 22 05:21:51 2023
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Aug 2023 15:21:51 +1000
Subject: Enrich the Lock interface
In-Reply-To: <CABfnnZN+1yrZBr+qM-odwn9naAOwKrJ8NSY=gR9iiuj5fo60sg@mail.gmail.com>
References: <CABfnnZMfTEyRWCJVKX-9nMfUDG-iGPwyWxFXyK0ko0YDPpdALw@mail.gmail.com>
 <554805B7-C415-4051-A16A-EBAE9A16BE2D@oracle.com>
 <9b53bb5f-383a-d8b7-8acd-2c8d3f9d340c@gmail.com>
 <CABfnnZN+1yrZBr+qM-odwn9naAOwKrJ8NSY=gR9iiuj5fo60sg@mail.gmail.com>
Message-ID: <06ed3fa3-6213-47cb-ae77-e4f64165a6b7@oracle.com>

On 21/08/2023 11:56 pm, Albert Attard wrote:
> Hello.
> 
> Thank you very much Pavel for helping me find more information about this.
> 
> After some research (mainly by Pavel) we found a thread, with subject 
> "/Default Functions for Lock Interface/", from October 2013 that 
> discussed this exact thing.? I don't believe that this thread is 
> available on the internet, but I may be wrong.
> 
> In this thread, two approaches were discussed.
> 
>  1. Add support for the try-with-resources
>  2. Add default methods to the Lock interface
> 
> 
> The second approach makes use of lambda functions which incur 
> performance cost when data is modified within the lambda function, as 
> described by Brian Goetz in the same thread (on the 8th of October 2013).
> 
> ---
> /When you write a method like
> 
> void withLock(Runnable)
> 
> the Runnable is going to have side-effects. So its going to be a 
> capturing lambda -- one that captures variables from its scope:
> 
> withLock( () -> { counter++; } ); // counter is captured
> 
> With the current implementation of lambda, evaluating (not invoking) a 
> capturing lambda expression will cause an allocation. Whereas the 
> hand-unrolled version:
> 
> lock.lock();
> try { counter++; }
> finally { lock.unlock(); }
> 
> does not. The sort of things people do with locks are generally pretty 
> performance-sensitive, so such an API was deemed, at the current time, 
> to be an "attractive nuisance."
> /---
> 
> Almost 10 years have passed since this was originally suggested.? Have 
> enough things changed since then, that would make this approach feasible?

Long before lambda's Doug Lea originally had this in the form of 
LockedExecutor:

https://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/LockedExecutor.html

but it never made the cut into java.util.concurrent (JSR-166).

A "withLock" style of programming does have some appeal to some people 
but it was never considered worthy of a place in the core API. The basic 
thing is trivial but then there are issues about returning values, or 
specialized exception handling - all of which are best handled, and 
easily handled, by application logic.

Cheers,
David
-----

> With kind regards,
> Albert Attard
> 
> 
> On Mon, 21 Aug 2023 at 15:33, John Hendrikx <john.hendrikx at gmail.com 
> <mailto:john.hendrikx at gmail.com>> wrote:
> 
>     I couldn't find a discussion on openjdk, but for those interested (and
>     to save others some searching) there is a JBS ticket:
> 
>     https://bugs.openjdk.org/browse/JDK-8025597
>     <https://bugs.openjdk.org/browse/JDK-8025597>
> 
>     --John
> 
>     On 21/08/2023 14:37, Pavel Rappo wrote:
>      > This is suggested every once in a while. I appreciate that
>     openjdk mailing lists are not easily searchable, but with a bit of
>     skill, you could find a few previous discussions on the topic.
>      >
>      > This has also been discussed on concurrency-interest (at
>     cs.oswego.edu <http://cs.oswego.edu> <http://cs.oswego.edu/
>     <http://cs.oswego.edu/>>), a dedicated mailing list for concurrency
>     in Java. Sadly, that list has been defunct for quite some time now.
>      >
>      > -Pavel
>      >
>      >> On 21 Aug 2023, at 13:18, Albert Attard <albertattard at gmail.com
>     <mailto:albertattard at gmail.com>> wrote:
>      >>
>      >> Hello.
>      >>
>      >> I hope all is well.
>      >>
>      >> Do you believe it is a bad idea to enrich the Lock interface
>     with a set of default methods that safely release the lock once ready?
>      >>
>      >> Consider the following (dangerous) example.
>      >>
>      >> final Lock lock = new ReentrantLock ();
>      >> lock.lock();
>      >> /* Code that may throw an exception */
>      >> lock.unlock();
>      >>
>      >> This example will never release the lock if an exception is
>     thrown, as the programmer didn?t wrap this up in a try/finally.
>      >>
>      >> Adding a default method within the Lock interface, called
>     withLock(Runnable) for example or any better name, would streamline
>     this, as shown next.
>      >>
>      >> default void withLock(final Runnable runnable) {
>      >>? ? ? requireNonNull(runnable, "Cannot run a null");
>      >>? ? ? lock();
>      >>? ? ? try {
>      >>? ? ? ? ? runnable.run();
>      >>? ? ? } finally {
>      >>? ? ? ? ? unlock();
>      >>? ? ? }
>      >> }
>      >>
>      >> The caller can now simply change the above example into the
>     following, without having to worry about this.
>      >>
>      >> final Lock lock = new ReentrantLock ();
>      >> lock.withLock(() -> {
>      >>? ? /* Code that may throw an exception */
>      >> });
>      >>
>      >> We can have more variants of these default methods, as shown next.
>      >>
>      >> default <T> T getWithLock(final Supplier<T> supplier) {
>      >>? ? ? requireNonNull(supplier, "The supplier cannot be null");
>      >>? ? ? lock();
>      >>? ? ? try {
>      >>? ? ? ? ? return supplier.get();
>      >>? ? ? } finally {
>      >>? ? ? ? ? unlock();
>      >>? ? ? }
>      >> }
>      >>
>      >> Any thoughts?
>      >>
>      >> With kind regards,
>      >> Albert Attard
> 

From aturbanov at openjdk.org  Tue Aug 22 07:13:47 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 22 Aug 2023 07:13:47 GMT
Subject: RFR: 8314734: Remove unused field
 TypeVariableImpl.EMPTY_ANNOTATION_ARRAY
Message-ID: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>

Field is unused since [JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) - https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e

-------------

Commit messages:
 - [PATCH] Remove unused field TypeVariableImpl.EMPTY_ANNOTATION_ARRAY

Changes: https://git.openjdk.org/jdk/pull/15379/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15379&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314734
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15379.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15379/head:pull/15379

PR: https://git.openjdk.org/jdk/pull/15379

From alanb at openjdk.org  Tue Aug 22 07:34:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:34:28 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
 <AGy_gfkz2APlFotN4lFGenyJCo2eWzmkCDlQS12mdl4=.deb96cbe-0610-4e45-9e0e-9b72d7ed9b9d@github.com>
 <gCZjF7g24gCFdmyfnSwb6MZq14SiROivv3jfxzkD81I=.b4ef9b4c-3d7f-44bf-8668-29fad1d11bc3@github.com>
Message-ID: <iSZjmtstOLnRKJVOgiHuPS9vkQ644LbZ3T3LvGGekQw=.56dde62e-6ada-4cf7-86c8-dbb62bc6636e@github.com>

On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event for select ops

Do you have a sense yet on events when the channel is configured non-blocking? I realise the threshold is 20ms so they are probably not recorded today but I wonder if these code paths will eventually include `|| !blocking` or if it useful to record data on all socket read/write ops.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687630491

From alanb at openjdk.org  Tue Aug 22 07:41:32 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:32 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <FSLy1lu91T20fxp7TbB9D7WMcdHJMK_wAn12SIT7k4U=.e300f883-4749-451f-a0f2-c6f4df25801f@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

Overall, it's good to move away from the "faraway instrumentation". Looks forward to the next steps to get to a more complete solution.

src/java.base/share/classes/java/net/Socket.java line 44:

> 42: import java.util.Collections;
> 43: 
> 44: 

Minor nit, I assume this additional blank line is left over from a previous iteration.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 465:

> 463:     public long read(ByteBuffer[] dsts, int offset, int length)
> 464:         throws IOException
> 465:     {

The supporting methods for read (beginRead, endRead, throwConnectionReset, ...) are declared before the read methods. It's probably best to put the implRead before the read too so that all the supporting methods are together. Same thing with the write methods.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14342#pullrequestreview-1588627786
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301134829
PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301144638

From alanb at openjdk.org  Tue Aug 22 07:41:34 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:34 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events
In-Reply-To: <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <EAJkf3t-7yNk3CRvC2oRsjW5dJ1-ZX-hODYy2ShdQHE=.51608e32-7dff-4c92-aaf3-5d25c62943a5@github.com>
 <hxX-hkQ13MG0i2y8-WY_K-4QdJ1JxCwKQoBQstW9Po8=.f7228526-123d-4c5f-a101-628e7e900351@github.com>
Message-ID: <Kc9gmGZY4EW0-j0vaYgOjQTS1lqJ5cgIBJ5XerGgrJA=.4e571964-e702-43ee-a1ab-5d76d7726c7d@github.com>

On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> An exception event will be emitted. The event is disabled by default, but there is ongoing work on a throttling mechanism, so it can be always-on.

Good, I think the exception cases are probably the most interesting for this area when it comes to troubleshooting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687636801

From alanb at openjdk.org  Tue Aug 22 07:41:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:38 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v3]
In-Reply-To: <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <PuE4ck4Mwvgotvnm6v75S5Itte2FIf675hYWzi56dgY=.1ea23d9c-102f-4d22-ae83-306a67c67ba4@github.com>
 <Fn3DgMw8AH9icFXJbp2fWkVFVqdOmOvE1I2BmbPJg0M=.7de4d1a5-5856-436c-9ee8-fa9a8f8b9176@github.com>
Message-ID: <dHY_YlyH_mN3TaYO-ZzBtyqTEAs7vSlc8_L8_MsGXgU=.e071811b-a84d-4c31-89b6-3cadc4048ef3@github.com>

On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>>  - Merge branch 'master' into JDK-8308995
>>    
>>    # Conflicts:
>>    #	src/jdk.jfr/share/classes/jdk/jfr/events/EventConfigurations.java
>>  - Avoid exceptions getting address/timeout for jfr event. Remove unused
>>    EventConiguration fields SOCKET_READ and SOCKET_WRITE.  Remove spurious
>>    whitespace.
>>  - some changes from review.
>>    
>>    read0() to implRead()
>>    write0() to implWrite()
>>    trailing whitespace
>>  - fix copyright date
>>  - Added micro benchmark to measure socket event overhead.
>>  - Some changes from review.
>>    
>>    Append a 0 to method names being wrapped.  Use getHostString to avoid
>>    a reverse lookup when fetching the hostname of the remote address.
>>  - remove unnecessary cast
>>  - 8308995: Update Network IO JFR events to be static mirror events
>
> src/java.base/share/classes/java/net/Socket.java line 1133:
> 
>> 1131:                 return parent.getSoTimeout();
>> 1132:             } catch (Throwable t) {
>> 1133:                 // ignored - avoiding exceptions in jfr event data gathering
> 
> This should be SocketException, not Throwable. That said, I think it would be useful to know why the SocketReadEvent includes the timeout. Is this used to see If read durations are close to the timeout? I assume once this code is fixed to deal with the exceptional case that the need to include the timeout for the success case will mostly go away.

Were you able to find out what the timeout is used for?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301136108

From alanb at openjdk.org  Tue Aug 22 07:41:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 07:41:40 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <Oo5AYrlXuEwsLMkgfJbQFu9H7g9_1-ng1CfncdLAHeg=.e763b44c-a1b8-4fef-acda-828f24004726@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <-joCOXm52wMG9vCbBdDUHnZCqNCYoUj-ruNjZgv4mwY=.70571acf-a859-4c88-972f-49af60bfed64@github.com>
 <Oo5AYrlXuEwsLMkgfJbQFu9H7g9_1-ng1CfncdLAHeg=.e763b44c-a1b8-4fef-acda-828f24004726@github.com>
Message-ID: <gl6QI9nlAksm-F9VUnBVKfaBFhVF8bIXfM_ICUEFe5o=.812ee61d-6aa0-4846-8bdf-1a74ea1fa467@github.com>

On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>> 
>>> 406:     @Override
>>> 407:     public int read(ByteBuffer buf) throws IOException {
>>> 408:         if (!SocketReadEvent.enabled()) {
>> 
>> The read/write with sun.nio.ch.SocketInputStream and SocketOutputStream does not go through SC.read/write so I think SocketAdaptor read/write will need attention, maybe a future PR as there are other code paths that aren't covered in this PR.
>
> I've created https://bugs.openjdk.org/browse/JDK-8310978 to drive the future PR to support the missing code paths

Thanks, it's a reminder that the existing SocketXXX events are incomplete and/or not much I/O done with the socket adaptors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14342#discussion_r1301143720

From mbaesken at openjdk.org  Tue Aug 22 07:51:29 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 22 Aug 2023 07:51:29 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <kl1nZKcKJ50pznWkSgmJ1FMgwyI3QsCWCeJaraoJjS8=.40ab384b-b91e-45a1-9bf5-fbdd19e54552@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
 <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>
 <kl1nZKcKJ50pznWkSgmJ1FMgwyI3QsCWCeJaraoJjS8=.40ab384b-b91e-45a1-9bf5-fbdd19e54552@github.com>
Message-ID: <dz875Wg1UGzws9xBWcSHUM6nlPWwP2z1AdXyY-deyRs=.f0a9093e-2313-4693-b64f-3cc0497a0335@github.com>

On Mon, 21 Aug 2023 07:14:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > How long is the file-lock typically held? How many such tests can run concurrently? And how long do we retry for?
> 
> It's typically the sync method when writing back the cached changes. I suspect the Unix implementation could be easily re-written to use FileChannel and Files.setPosixFilePermissions and that would eliminate the native code and give better exception messages when there are errors.
> 
> For the tests, I'm surprised the TEST.properties in this directory doesn't have exclusiveAccess.dirs=. as there has been historical issues with interference between tests in this area.

Hi Alan, should we maybe add this ?  If so in this change on in another one ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1687654412

From egahlin at openjdk.org  Tue Aug 22 08:49:32 2023
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 22 Aug 2023 08:49:32 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <Trwkx7ogqkLlKpCq8w-t7er1ZMlGpfJrQcnMzaLtnsA=.961a8a75-a60a-438b-bb27-6455b7907b09@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

The stack trace will start in the incorrect method, i.e checkForCommit, when a utility method is used. This is probably something we will have to fix anyway. I filed an issue for that: https://bugs.openjdk.org/browse/JDK-8314745

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687749717

From prappo at openjdk.org  Tue Aug 22 08:50:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 08:50:07 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
Message-ID: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>

Please review this simple PR.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15382/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15382&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314738
  Stats: 124 lines in 28 files changed: 0 ins; 116 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/15382.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15382/head:pull/15382

PR: https://git.openjdk.org/jdk/pull/15382

From alanb at openjdk.org  Tue Aug 22 08:59:33 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Aug 2023 08:59:33 GMT
Subject: RFR: 8308995: Update Network IO JFR events to be static mirror
 events [v4]
In-Reply-To: <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
References: <pRe6wiG2JsBa7JG7aFm8H2f41EetT83lEyY9K8zIUcc=.60c41c2b-33b8-4442-80d6-729d161cebc0@github.com>
 <uUxluubquQBnTajSZknVjiobTmhBskIvKKH2pKqBMMo=.f9a9e863-fb77-423c-8f17-86caa99804b7@github.com>
Message-ID: <Ncr3pmGdmtjDBiLKzwriKKDymN4IBVjq38jt1xdlFOA=.c51d2e8e-c653-455e-bef9-7d54c5beb13f@github.com>

On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> The socket read/write JFR events currently use instrumentation of java.base code using templates in the jdk.jfr modules. This results in some java.base code residing in the jdk.jfr module which is undesirable.
>> 
>> JDK19 added static support for event classes. The old instrumentor classes should be replaced with mirror events using the static support.
>> 
>> In the java.base module:
>> Added two new events, jdk.internal.event.SocketReadEvent and jdk.internal.event.SocketWriteEvent.
>> java.net.Socket and sun.nio.ch.SocketChannelImpl were changed to make use of the new events.
>> 
>> In the jdk.jfr module:
>> jdk.jfr.events.SocketReadEvent and jdk.jfr.events.SocketWriteEvent were changed to be mirror events.
>> In the package jdk.jfr.internal.instrument, the classes SocketChannelImplInstrumentor, SocketInputStreamInstrumentor, and SocketOutputStreamInstrumentor were removed. The JDKEvents class was updated to reflect all of those changes.
>> 
>> The existing tests in test/jdk/jdk/jfr/event/io continue to pass with the new implementation:
>> Passed: jdk/jfr/event/io/TestSocketChannelEvents.java
>> Passed: jdk/jfr/event/io/TestSocketEvents.java
>> 
>> I added a micro benchmark which measures the overhead of handling the jfr socket events.
>> test/micro/org/openjdk/bench/java/net/SocketEventOverhead.java.
>> It needs access the jdk.internal.event package, which is done at runtime with annotations that add the extra arguments.
>> At compile time the build arguments had to be augmented in make/test/BuildMicrobenchmark.gmk
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   less exception filtering when fetching socket read timeout

One other thing is that the comments in Socket.SocketInputStream and Socket.SocketOutputStream where it has "This class is instrumented by Java Flight Recorder (JFR) to get socket I/O events" can be removed now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14342#issuecomment-1687765868

From prappo at openjdk.org  Tue Aug 22 11:23:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 11:23:37 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note
In-Reply-To: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
Message-ID: <_WU_U9hmxS7p0fB5eJ5Be_7ioQdloTNGrYxDpZwER9I=.de1bb247-c819-4cb2-81cb-ca7853192541@github.com>

On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR.

CC'ing core-libs-dev whose members might also have some recollection on tags in question.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1687995105

From prappo at openjdk.org  Tue Aug 22 11:30:25 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 11:30:25 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note
In-Reply-To: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
Message-ID: <VxxQyH0btkF79RZa-2swdPpELePMfPuaTPEsU_WsN_Q=.c5b55b9d-3e5d-46f7-b19c-193281234c6c@github.com>

On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR.

CC'ing client-libs-dev because @beaninfo and @Note and jmx-dev because of @since.unbundled, which might've been used for JMX before 2007.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1688004264

From pavel.rappo at oracle.com  Tue Aug 22 12:21:23 2023
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 22 Aug 2023 12:21:23 +0000
Subject: @Incubating
In-Reply-To: <D9DE42BE-02E6-4501-9CAB-C6C98C6EFCCD@oracle.com>
References: <D9DE42BE-02E6-4501-9CAB-C6C98C6EFCCD@oracle.com>
Message-ID: <9FF8E218-241A-40AB-9DEF-5D89333F2FF3@oracle.com>

I've published a PR to change the name of that tag:

    https://github.com/openjdk/jdk/pull/15387

> On 21 Aug 2023, at 10:57, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Does anybody remember why {@Incubating}, a JDK-specific tag introduced in JDK-8173354, starts with an uppercase letter? Put differently, are there any reasons why we should not make it conform to implicit convention of camelCase, like all other standard and JDK tags do?



From mr at openjdk.org  Tue Aug 22 12:28:29 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 22 Aug 2023 12:28:29 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

Removing `@revised` tags is not a substantive change, so I wouldn?t update the copyright year as you have in some of these files.

Otherwise, this looks fine.

-------------

Marked as reviewed by mr (Lead).

PR Review: https://git.openjdk.org/jdk/pull/15382#pullrequestreview-1589309922

From prappo at openjdk.org  Tue Aug 22 12:28:30 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 12:28:30 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
 <H90O8Ih9l4rVA0KmykHseV_vGt-zDRRynIWLDWuzR24=.dedadaa6-1c53-44f0-82a0-0cf03e125354@github.com>
Message-ID: <SDiBPiBgNy7goDvyA_QproyjabPlsLoKDVaK_LUXfME=.05456201-40e8-4e38-b544-c81f9491d21a@github.com>

On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> I wouldn?t update the copyright year as you have in some of these files.

I was taught to do it every time when I change a file. Would you like me to revert those changes to copyright years in this case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688086627

From aturbanov at openjdk.org  Tue Aug 22 12:31:04 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 22 Aug 2023 12:31:04 GMT
Subject: RFR: 8312521: Unused field
 LocaleProviderAdapter#defaultLocaleProviderAdapter could be removed
Message-ID: <V8wbOFhzUYfyrMj6Q7UUvyb88QxfwxPgkY0J0T6-wxo=.18ed1683-f57c-4bcc-8037-88d1e1e558b4@github.com>

After [JDK-8245241](https://bugs.openjdk.org/browse/JDK-8245241), the field `sun.util.locale.provider.LocaleProviderAdapter#defaultLocaleProviderAdapter` is only written in `<clinit>` and then is not used after.
We can remove it.

-------------

Commit messages:
 - 8312521: Unused field LocaleProviderAdapter#defaultLocaleProviderAdapter could be removed

Changes: https://git.openjdk.org/jdk/pull/15388/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15388&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312521
  Stats: 11 lines in 1 file changed: 0 ins; 8 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15388.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15388/head:pull/15388

PR: https://git.openjdk.org/jdk/pull/15388

From mr at openjdk.org  Tue Aug 22 12:40:27 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 22 Aug 2023 12:40:27 GMT
Subject: RFR: 8314738: Remove all occurrences of and support for @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <zt4wRlDz8gCkuOvuI-b_2CJ29LVQgsD4tUm7QhBNoHM=.e4306c1b-4a54-46ff-a76c-91418bdca95c@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

You can leave the copyright years as-is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688104170

From prappo at openjdk.org  Tue Aug 22 13:05:38 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 13:05:38 GMT
Subject: Integrated: 8314738: Remove all occurrences of and support for
 @revised
In-Reply-To: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
References: <z_dEhfjavo5zZz4BifE0E-V72Uou3kTEZpt9KZRMrzw=.31b44ba0-89f0-471a-b9ce-eb9ddcc45e7d@github.com>
Message-ID: <DoB0QHugB2TSmS92E-93jBcsldiwg0_Bhsiusb6oMwo=.4e630be5-9b9a-4d1f-9434-62dffa8900e7@github.com>

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple PR.

This pull request has now been integrated.

Changeset: f39fc0aa
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a
Stats:     124 lines in 28 files changed: 0 ins; 116 del; 8 mod

8314738: Remove all occurrences of and support for @revised

Reviewed-by: mr

-------------

PR: https://git.openjdk.org/jdk/pull/15382

From prappo at openjdk.org  Tue Aug 22 14:55:18 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 14:55:18 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note [v2]
In-Reply-To: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
Message-ID: <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>

> Please review this trivial PR.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into 8314753
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/15385/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15385&range=01
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15385/head:pull/15385

PR: https://git.openjdk.org/jdk/pull/15385

From duke at openjdk.org  Tue Aug 22 14:57:17 2023
From: duke at openjdk.org (duke)
Date: Tue, 22 Aug 2023 14:57:17 GMT
Subject: Withdrawn: 8310837: Use ByteArrayLittleEndian in java.util.zip
In-Reply-To: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
References: <MAhOKHlG0LsSo86kCDoaRwJvCF0bHDEElqRNrrY4lbE=.da7de5af-4660-4c3d-96fc-59abbb8398d8@github.com>
Message-ID: <1vvNI4VHv6wWOly8mGeZfXzsVrdVX__i9jGn3AJPl0w=.7f20f4af-2851-4974-96ce-f1fe5e299522@github.com>

On Fri, 23 Jun 2023 20:00:12 GMT, Glavo <duke at openjdk.org> wrote:

> Using `ByteArrayLittleEndian` is simpler and faster.
> 
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
> 
> 
>   Benchmark                     (size)  Mode  Cnt      Score      Error  Units
> - ZipFileOpen.openCloseZipFile     512  avgt   15  39052.832 ?  107.496  ns/op
> + ZipFileOpen.openCloseZipFile     512  avgt   15  36275.539 ?  663.193  ns/op
> - ZipFileOpen.openCloseZipFile    1024  avgt   15  77106.494 ? 4159.300  ns/op
> + ZipFileOpen.openCloseZipFile    1024  avgt   15  71955.013 ? 2296.050  ns/op

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14632

From rriggs at openjdk.org  Tue Aug 22 15:08:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Aug 2023 15:08:47 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note [v2]
In-Reply-To: <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
 <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
Message-ID: <p2i3ZqGT5RCchLQxbjLRsGLDe2J-sy23oQLTod7MY2Q=.18b6a17f-3f4b-468c-b00a-8ae61679fda4@github.com>

On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this trivial PR.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8314753
>  - Initial commit

Looks trivial only after reviewing the issue and knowing the background.
The PR description could be a bit more complete and save a bunch of clicking around.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15385#pullrequestreview-1589653044

From aefimov at openjdk.org  Tue Aug 22 15:08:47 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 22 Aug 2023 15:08:47 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v9]
In-Reply-To: <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>
Message-ID: <ioAKSpQpANRDwh7bYtad3aqk2932uZbYu9LwMqmKNIc=.31ed77ee-7071-45f9-99ac-0bacbc0ac303@github.com>

On Mon, 21 Aug 2023 22:10:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use original logic to create socket to avoid the compatibility issue

The latest version looks fine to me:
New `createConnectionSocket` methods make code more readable while 
maintaining the same codeflow in respect of connection timeout and
socket factory method calls.
Existing LDAP tests show no problems with the proposed fix.
 
Few minor formatting suggestions:
 
Remove unused imports in the test:

 import java.io.File;
-import java.io.FileInputStream;
-import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.OutputStream;
@@ -36,7 +34,6 @@ import javax.naming.ldap.InitialLdapContext;
 import javax.naming.ldap.LdapContext;
 import javax.naming.Context;
 import java.net.SocketException;
-import java.security.KeyStore;


Remove extra space:

-        public CustomSocket () {
+        public CustomSocket() {


Remove redundant default value:

-        private boolean isForceToSleep = false;
+        private boolean isForceToSleep;

-------------

PR Review: https://git.openjdk.org/jdk/pull/15294#pullrequestreview-1589632056

From prappo at openjdk.org  Tue Aug 22 15:23:47 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 22 Aug 2023 15:23:47 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note [v2]
In-Reply-To: <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
 <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
Message-ID: <DD9h-0WJv6OXdU1rzHCbJ2XghtuiaRLqRdzUvaZOAcc=.3aeb4b23-2613-4362-85ba-655167730b9a@github.com>

On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this trivial PR.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8314753
>  - Initial commit

Thanks for reviewing it.

> Looks trivial only after reviewing the issue and knowing the background.
> The PR description could be a bit more complete and save a bunch of clicking around.

Fair enough. For the benefit of other reviewers, I'll copy the JBS description here and additionally note that tags in question are absent in the mainline doc comments and are also disabled during `make docs`. JBS:

Those tags seem to have been effectively decommissioned, but their remnants are still there and when seen, raise needless questions. 

- `@beaninfo` seems to relate to UI: 

   - [JDK-7179078](https://bugs.openjdk.org/browse/JDK-7179078) 
   - [JDK-4763438](https://bugs.openjdk.org/browse/JDK-4763438) 
   - [JDK-8051548](https://bugs.openjdk.org/browse/JDK-8051548) 

- `@ToDo` and `@since.unbundled` hasn't been used since the initial load (2007). 

- `@Note` seems to relate to UI: 

   - [JDK-8285686](https://bugs.openjdk.org/browse/JDK-8285686) 
   - [JDK-8227324](https://bugs.openjdk.org/browse/JDK-8227324) 
   - [JDK-8222362](https://bugs.openjdk.org/browse/JDK-8222362)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1688367797

From bpb at openjdk.org  Tue Aug 22 15:50:17 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 22 Aug 2023 15:50:17 GMT
Subject: RFR: 8314734: Remove unused field
 TypeVariableImpl.EMPTY_ANNOTATION_ARRAY
In-Reply-To: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>
References: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>
Message-ID: <Ob1-IPSqcVvUEUOEjuY_smcs-b1KYJucGL8pQKmsUkg=.f4c5dbaa-814d-4563-b73d-250e428aed26@github.com>

On Tue, 22 Aug 2023 06:57:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field is unused since [JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) - https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15379#pullrequestreview-1589745297

From pminborg at openjdk.org  Tue Aug 22 16:41:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 22 Aug 2023 16:41:18 GMT
Subject: RFR: 8310843: Reimplement ByteArray and ByteArrayLittleEndian with
 Unsafe [v10]
In-Reply-To: <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
References: <afK-to5bedxbOmemGZqmSs1E-rka_2SuQwMxNegW8Hk=.d83ae0dc-9b7c-4996-856b-62a646cab8f4@github.com>
 <md3iQ4UuTlYJU3YYhxY3hhPrKlDL0FlW-28QdjZ6DSE=.64b71c32-f17d-428f-8476-a54d6334bbef@github.com>
Message-ID: <FPb2AzFFDlCmhvgX8-EseAg-CK3OaHkhoIpVyrYlp9A=.e9f9e879-00ff-4bfd-b3f4-1837c0c00b10@github.com>

On Thu, 13 Jul 2023 23:05:48 GMT, Glavo <duke at openjdk.org> wrote:

>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can be used in many places to performance tuning.
>> 
>> Currently they are implemented by `VarHandle`, so using them may have some impact on startup time.
>> 
>> This PR reimplements them using `Unsafe`, which reduces the impact on startup time.
>
> Glavo 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 15 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unsafe
>  - add 8310843 to @bug
>  - Merge branch 'openjdk:master' into unsafe
>  - Merge branch 'openjdk:master' into unsafe
>  - delete incorrect comments
>  - delete extraneous whitespace
>  - add javadoc
>  - delete extraneous whitespace
>  - fix test
>  - update tests
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/5c910d60...cb56e736

In my opinion, reducing startup time can be achieved in other ways, both short-term (sharing VHs) and long-term (pre-generate VHs at build time using condensers). I think having a supported API carries some advantages rather than using Unsafe directly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14636#issuecomment-1688537509

From dl at openjdk.org  Tue Aug 22 17:05:20 2023
From: dl at openjdk.org (Doug Lea)
Date: Tue, 22 Aug 2023 17:05:20 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v12]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <j6CByVLv56T_Gb87lh_Suj4uB866aQ9xKAdoPjnSYKc=.f935b160-4366-4495-b1ff-87d9495a3e26@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 55 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Ensure each CloseTest test runs in a new thread
 - Run close tests in seperate threads
 - Ensure thread not interrupted when testing close
 - Use signalWork in isQuiescent
 - Typo
 - Allow cancel in checkCompletedAbnormally
 - Merge branch 'openjdk:master' into JDK-8288899
 - Pass through cancellations in FJ tests
 - Avoid false-alarm failures on shutdown
 - ... and 45 more: https://git.openjdk.org/jdk/compare/c2721e87...d1515cdf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/76abc1fd..d1515cdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=10-11

  Stats: 3690 lines in 231 files changed: 2477 ins; 511 del; 702 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From duke at openjdk.org  Tue Aug 22 17:24:24 2023
From: duke at openjdk.org (Swati Sharma)
Date: Tue, 22 Aug 2023 17:24:24 GMT
Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests
 having shared state
In-Reply-To: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
References: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
Message-ID: <5K5iYGm0ryQwxnOj-e0NlMsCPYMpzZtAiVXYubl7pLM=.65ae1221-e573-4666-911a-ef4e3a271927@github.com>

On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma <duke at openjdk.org> wrote:

> In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.
> 
> org/openjdk/bench/java/io/DataInputStreamTest.java
> org/openjdk/bench/java/lang/ArrayClone.java
> org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
> org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
> org/openjdk/bench/java/lang/StringComparisons.java
> org/openjdk/bench/java/lang/StringEquals.java
> org/openjdk/bench/java/lang/StringFormat.java
> org/openjdk/bench/java/lang/StringReplace.java
> org/openjdk/bench/java/lang/StringSubstring.java
> org/openjdk/bench/java/lang/StringTemplateFMT.java
> org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
> org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
> org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
> org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
> org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
> org/openjdk/bench/java/security/CipherSuiteBench.java
> org/openjdk/bench/java/time/GetYearBench.java
> org/openjdk/bench/java/time/InstantBench.java
> org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
> org/openjdk/bench/java/util/ListArgs.java
> org/openjdk/bench/java/util/LocaleDefaults.java
> org/openjdk/bench/java/util/TestAdler32.java
> org/openjdk/bench/java/util/TestCRC32.java
> org/openjdk/bench/java/util/TestCRC32C.java
> org/openjdk/bench/java/util/regex/Exponential.java
> org/openjdk/bench/java/util/regex/Primality.java
> org/openjdk/bench/java/util/regex/Trim.java
> org/openjdk/bench/javax/crypto/AESReinit.java
> org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
> org/openjdk/bench/vm/compiler/Rotation.java
> org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
> org/openjdk/bench/vm/compiler/x86/BasicRules.java
> 
> Please review and provide your feedback.
> 
> Thanks,
> Swati

Could you please review this ?  @ericcaspole

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15230#issuecomment-1688597226

From duke at openjdk.org  Tue Aug 22 18:25:17 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 22 Aug 2023 18:25:17 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v9]
In-Reply-To: <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <uyjI9q8fcQuuZfTyJOatIdLq1J2IzZYy1PzX6Jrx84E=.9e05739f-7f56-4b44-ba9e-274945999cc6@github.com>
Message-ID: <UI9IiZCdUGXcJ5EIwmJUV3j-0tU64dnrYpumbZm8yMg=.fdc42324-89f8-4ef9-8041-146013babee2@github.com>

On Mon, 21 Aug 2023 22:10:06 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use original logic to create socket to avoid the compatibility issue

Formatted the code according to the comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1688652418

From duke at openjdk.org  Tue Aug 22 18:21:17 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 22 Aug 2023 18:21:17 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  format the code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/212ee7fa..2e0e80fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=08-09

  Stats: 22 lines in 1 file changed: 10 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From darcy at openjdk.org  Tue Aug 22 18:25:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Aug 2023 18:25:21 GMT
Subject: RFR: 8314734: Remove unused field
 TypeVariableImpl.EMPTY_ANNOTATION_ARRAY
In-Reply-To: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>
References: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>
Message-ID: <TA5V9o-iUiFI-L6kMaTK3A3TiFAm7G3tLQBAWnTpwGU=.94aefe99-1048-403f-8037-6eeddc0def13@github.com>

On Tue, 22 Aug 2023 06:57:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field is unused since [JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) - https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15379#pullrequestreview-1590032591

From mchung at openjdk.org  Tue Aug 22 19:01:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Aug 2023 19:01:53 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v3]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <mePBmmBWJw9beXJUqj1oStOj3dh2ZhHOEpJKi-wykJE=.dbdca860-1674-4936-b2f7-2e787c39bc0e@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `Option.NO_METHOD_INFO` new stack walking option.
> If no method information is needed, this option can be used such that the
> stack walker will save the overhead (1) to extract the method information
> and (2) the memory used for the stack walking.   In addition, this can also fix
> 
> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
> 
> Adding `NO_METHOD_TIME` option provides a simple way for existing code,
> for example logging frameworks, to take advantage of this enhancement with
> the least change as it can keep the existing implementation in traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can just add `NO_METHOD_INFO` in the call to `StackWalker::getInstance`
> to create a stack walker instance:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE, NO_METHOD_INFO);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(interestingClasses::contains)
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> The alternative considered is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> ### Implementation Details
> 
> If `NO_METHOD_NAME` is set, the implementation creates `ClassFrameInfo[]`
> buffer that is filled by the VM during stack walking.   `ClassFrameInfo` holds the 
> Class instance plus `flags`  which indicate if it's caller sensitive or hidden.  
> With this change, `StackWalker::getCa...

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Replace NO_METHOD_INFO option with StackWalker.Kind enums
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - clean up
 - fix trailing whitespace
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Update LocalLongHelper.java
 - clean up
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - Add StackWalker.Option.NO_METHOD_INFO
 - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
 - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb

-------------

Changes: https://git.openjdk.org/jdk/pull/15370/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=02
  Stats: 1195 lines in 33 files changed: 694 ins; 204 del; 297 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From darcy at openjdk.org  Tue Aug 22 19:14:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 22 Aug 2023 19:14:18 GMT
Subject: RFR: 8313961: Enhance identification of special serialization
 methods [v2]
In-Reply-To: <7T9BconZt9CyoJvaMiS2p-vmtavPiuJvQ1DpHQszrTA=.ce2e0961-edf6-426b-be0f-7b556c885678@github.com>
References: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
 <DD6tD2pGlKlADXTxKWJxxUbivRktIdobutSGhqDr1jE=.c5ce640a-cc33-4725-91f7-abd490af12b7@github.com>
 <OiOBUf9nD97CXZWaL5ZGmQn8_S1cYd8RgLaYnFemXW4=.81537c69-5caf-420e-a92a-93da16e08e8a@github.com>
 <7T9BconZt9CyoJvaMiS2p-vmtavPiuJvQ1DpHQszrTA=.ce2e0961-edf6-426b-be0f-7b556c885678@github.com>
Message-ID: <0rToYN0aPP5XMLEFTChtkAsHpn5Vh-RB08Jwovktb_8=.b3d6cbaf-d34c-4ea6-94b9-39879de1c8d7@github.com>

On Mon, 21 Aug 2023 16:57:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 1670:
>> 
>>> 1668:         ObjectStreamField[] serialPersistentFields = null;
>>> 1669:         try {
>>> 1670:             Field f = getDeclaredField(cl, ObjectStreamField[].class, "serialPersistentFields");
>> 
>> This?can?technically be?a?breaking?change, as?it?was?supported for?the?field to?have a?declared?type that?is?assignable from?`ObjectStreamField[]`, as?long?as it?held an?`ObjectStreamField[]`?instance at?runtime, even?if it?wasn?t officially?supported.
>> 
>> 
>> class Example implements Serializable {
>> 	// This used to work before this patch in OpenJDK
>> 	private static final Object serialPersistentFields = new ObjectStreamField[] {
>> 		// ...
>> 	};
>> 
>> 	// ...
>> }
>
> True.
> 
> On the other hand, what about a .class file that includes all of (pseudo-Java)
> 
> 
>     private static final Object              serialPersistentFields = new ObjectStreamField[0];
>     private static final Cloneable           serialPersistentFields = new ObjectStreamField[0];
>     private static final Serializable        serialPersistentFields = new ObjectStreamField[0];
>     private static final ObjectStreamField[] serialPersistentFields = new SubclassOfObjectStreamField[0];
> 
> 
> Which one is the "preferred" field?
> 
> Perhaps the Java Object Serialization Specification should simply prohibit multiple `serialPersistentFields`.

> This can technically be a breaking change, as it was supported for the field to have a declared type that is assignable from `ObjectStreamField[]`, as long as it held an `ObjectStreamField[]` instance at runtime, even if it wasn?t officially supported.
> 
> ```java
> class Example implements Serializable {
> 	// This used to work before this patch in OpenJDK
> 	private static final Object serialPersistentFields = new ObjectStreamField[] {
> 		// ...
> 	};
> 
> 	// ...
> }
> ```

That sort of behavior change would require a CSR; marking the PR accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15364#discussion_r1302070033

From mchung at openjdk.org  Tue Aug 22 19:14:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Aug 2023 19:14:18 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v2]
In-Reply-To: <xLaThups-UlR8gEZnCY6prtOw-aty7_Y7xSCWHEIFYw=.5bf80110-707a-4855-9931-624a7a07ec96@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <xLaThups-UlR8gEZnCY6prtOw-aty7_Y7xSCWHEIFYw=.5bf80110-707a-4855-9931-624a7a07ec96@github.com>
Message-ID: <HdJNkdtep2Bt5sUHWcLSNt6ax9zyQ38HCtYlB8oAqqQ=.228d234c-faf6-4fe5-a05e-6e40259655c1@github.com>

On Mon, 21 Aug 2023 21:10:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> The alternative considered is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` of `CLASS_INFO` kind creates `ClassFrameInfo[]` buffer that
>> is...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up

I revised the patch to introduce new enums `CLASS_INFO` and `METHOD_INFO` to specify the kind of information a stack walker collects. The PR's description has been updated to reflect the revised API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1688761021

From dl at openjdk.org  Tue Aug 22 19:33:18 2023
From: dl at openjdk.org (Doug Lea)
Date: Tue, 22 Aug 2023 19:33:18 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v13]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <wYVnt-53XrWSkpVM5KFYd2c_6hc6SGGWyl6F0BxX2BQ=.540fc996-e583-4759-bf9e-3380b939812e@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Resync CloseTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/d1515cdf..61381dbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=11-12

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From jlu at openjdk.org  Tue Aug 22 19:46:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 22 Aug 2023 19:46:17 GMT
Subject: RFR: 6228794: [Fmt-Ch] Doc: java.text.ChoiceFormat behavior is not
 well documented.
Message-ID: <WE8FcTn6N1VLTDl6-G_izVPIfj_HJEKlrddh9HsrGgI=.b65be6ea-40f3-49d0-a94b-c3fcdc0a1cff@github.com>

Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the `java.text.ChoiceFormat` specification regarding its pattern.

`j.text.ChoiceFormat` provides an example pattern in the class description, but beyond that it does not specify any well-defined syntax for creating a pattern. In addition, methods related to the pattern String are under-specified and there are undocumented exceptions.

The wording for `getLimits()` and `getFormats()` was also adjusted, as there are other ways to set the limits and formats beyond the constructor.

The changes may be easier to view -> https://cr.openjdk.org/~jlu/api/java.base/java/text/ChoiceFormat.html

-------------

Commit messages:
 - Clarify ?
 - Adjust pattern definition
 - Remove leftover comments
 - Revert the example changes to focus on the more important changes
 - Adjust wording of getter methods
 - Init

Changes: https://git.openjdk.org/jdk/pull/15392/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15392&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6228794
  Stats: 69 lines in 1 file changed: 46 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/15392.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15392/head:pull/15392

PR: https://git.openjdk.org/jdk/pull/15392

From almatvee at openjdk.org  Tue Aug 22 22:15:17 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 22 Aug 2023 22:15:17 GMT
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not picked
 up by jpackage if it contains UNICODE characters
Message-ID: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>

- Added support for certificates with UNICODE characters.
- Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
- New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
- Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.

-------------

Commit messages:
 - 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters

Changes: https://git.openjdk.org/jdk/pull/15394/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308042
  Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/15394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394

PR: https://git.openjdk.org/jdk/pull/15394

From javalists at cbfiddle.com  Tue Aug 22 22:35:31 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 22 Aug 2023 15:35:31 -0700
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
Message-ID: <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>

I?m confused by this.

The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.

Surely codesign can handle certificates with unicode names, can?t it?

> On Aug 22, 2023, at 3:15 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
> - Added support for certificates with UNICODE characters.
> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.
> 
> -------------
> 
> Commit messages:
> - 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters
> 
> Changes: https://git.openjdk.org/jdk/pull/15394/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8308042
>  Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
>  Patch: https://git.openjdk.org/jdk/pull/15394.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394
> 
> PR: https://git.openjdk.org/jdk/pull/15394
> 


From msheppar at openjdk.org  Tue Aug 22 22:45:17 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 22 Aug 2023 22:45:17 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
Message-ID: <wdP5Wle_3KejLMdH6cKAdv_YEAvVgiywh76Z2yatI6A=.5a341a83-b867-4113-ab39-d177c6c4b8d9@github.com>

On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

Resuggesting restructure to createConnectionSocket methods -- to instantiate Socket explicitly in one place and to explicitly use connect in all cases

`
   ```
private Socket createConnectionSocket (String host, int port, int connectTimeout) throws Exception {
        InetSocketAddress endpoint = createInetSocketAddress(host, port);
        Socket socket = new Socket();

        if (connectTimeout > 0) {
            if (debug) {
                System.err.println("Connection: creating socket with " +
                        "a timeout");
            }
            socket.connect(endpoint, connectTimeout);
        } else {
            if (debug) {
                System.err.println("Connection: creating socket");
            }
            // connected socket
            socket.connect(endpoint);
        }
        return socket;
    }


    // create the socket with the provided factory
    private Socket createConnectionSocket(String host, int port, String socketFactory,
                                           int connectTimeout) throws Exception {
        @SuppressWarnings("unchecked")
        Class<? extends SocketFactory> socketFactoryClass = (Class<? extends SocketFactory>)
                Obj.helper.loadClass(socketFactory);
        Method getDefault =
                socketFactoryClass.getMethod("getDefault", new Class<?>[]{});
        SocketFactory factory = (SocketFactory) getDefault.invoke(null, new Object[]{});
        InetSocketAddress endpoint =
                  createInetSocketAddress(host, port);
        // create unconnected socket
        Socket socket = factory.createSocket();

        // create the socket
        if (connectTimeout > 0) {
            if (debug) {
                System.err.println("Connection: creating socket with " +
                        "a timeout using supplied socket factory");
            }
            // connected socket
            socket.connect(endpoint, connectTimeout);
        } else {
            if (debug) {
                System.err.println("Connection: creating socket using " +
                        "supplied socket factory");
            }
            // connected socket
            socket.connect(endpoint);
        }
        return socket;
    }


`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1689007121

From duke at openjdk.org  Tue Aug 22 23:14:47 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Tue, 22 Aug 2023 23:14:47 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
Message-ID: <lY2p5bIaNgM5c_uelXjkYR9hBXiuge9zYhTAfHEWrG0=.03e98f6a-0865-4d20-9ec4-65698021c730@github.com>

On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

If the custom factory does not implement the method creatSocket (no method parameters), it will fail for creating the socket. The SocketFactory::createSocket is not defined as an abstract method, instead, it throws UnsupportedOperationException. The subclass is not required to implement it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1689033617

From alexander.matveev at oracle.com  Tue Aug 22 23:42:24 2023
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 22 Aug 2023 23:42:24 +0000
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
Message-ID: <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>

Hi Alan,

> On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> I?m confused by this.
> 
> The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.

This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.

Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message. 

> 
> Surely codesign can handle certificates with unicode names, can?t it?

Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.

Thanks,
Alexander

> 
>> On Aug 22, 2023, at 3:15 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
>> 
>> - Added support for certificates with UNICODE characters.
>> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
>> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
>> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.
>> 
>> -------------
>> 
>> Commit messages:
>> - 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters
>> 
>> Changes: https://git.openjdk.org/jdk/pull/15394/files
>> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
>> Issue: https://bugs.openjdk.org/browse/JDK-8308042
>> Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
>> Patch: https://git.openjdk.org/jdk/pull/15394.diff
>> Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394
>> 
>> PR: https://git.openjdk.org/jdk/pull/15394
>> 
> 


From msheppar at openjdk.org  Wed Aug 23 00:25:17 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 23 Aug 2023 00:25:17 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
Message-ID: <KXgGTvy8Fkswf3JL8ANXN5bR-IElC97B63a_OT3xL-0=.e9eefbdd-bf99-4e14-9990-be6de349e579@github.com>

On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

Such a restriction appears to be a flaw in the design of SocketFactory and its use in jndi ldap.
Consider the existing updated code  and the inference of your assertion:
 ```
       // create the socket
        if (connectTimeout > 0) {
            InetSocketAddress endpoint =
                    createInetSocketAddress(host, port);
            // unconnected socket
            socket = factory.createSocket();
            // connected socket
            socket.connect(endpoint, connectTimeout);
            if (debug) {
                System.err.println("Connection: creating socket with " +
                        "a timeout using supplied socket factory");
            }
        } else {
            // continue (but ignore connectTimeout)
            if (socket == null) {
                // connected socket
                socket = factory.createSocket(host, port);
                if (debug) {
                    System.err.println("Connection: creating socket using " +
                            "supplied socket factory");
                }
            }
        }``

Your assertion is, "If the custom factory does not implement the method creatSocket (no method parameters), it will fail for creating the socket."
Thus, the first block of the, if (connectTimeout > 0) condition, is problematic. This assumes that if the timeout is > 0, then the factory will implement the no args factory method createSocket(). BUT that means that an implementor  of a customer factory would need to have knowledge of the internal implemntation of this class, and ensure no args factory method createSocket is implemented. If an implementor has knowledge to implement the no args factory method when timeout > 0, then they can also have knowldge to implement the no args factory method when the timeout is 0 or < 0, as suggested by the restructure.

Additionally, this would not prohibit a restructure of the non factory createConnectionSocket.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1689079814

From javalists at cbfiddle.com  Wed Aug 23 02:40:49 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 22 Aug 2023 19:40:49 -0700
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
 <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
Message-ID: <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>



> On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Alan,
> 
>> On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
>> 
>> I?m confused by this.
>> 
>> The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.
> 
> This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.
> 

The problem with this solution is that it introduces bugs. This bug and JDK-8311877 both result from jpackage trying to perform its own certificate search instead of letting codesign do the search.

The claimed advantage of failing ?faster" is negligible (it is a small difference and only happens when the user has made a mistake) and not worth the (proven) risk of introducing bugs.

If you think you can do a better job of diagnosing the failure to find a certificate than codesign, then you should post-process the failure of codesign. But I don?t see this as a worthwhile investment.


> Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message. 
> 
>> 
>> Surely codesign can handle certificates with unicode names, can?t it?
> 
> Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.
> 

Exactly my point. By doing your own certificate validation you risk doing it wrong.


> Thanks,
> Alexander
> 
>> 
>>> On Aug 22, 2023, at 3:15 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
>>> 
>>> - Added support for certificates with UNICODE characters.
>>> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
>>> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
>>> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.
>>> 
>>> -------------
>>> 
>>> Commit messages:
>>> - 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters
>>> 
>>> Changes: https://git.openjdk.org/jdk/pull/15394/files
>>> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
>>> Issue: https://bugs.openjdk.org/browse/JDK-8308042
>>> Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
>>> Patch: https://git.openjdk.org/jdk/pull/15394.diff
>>> Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394
>>> 
>>> PR: https://git.openjdk.org/jdk/pull/15394
>>> 
>> 
> 


From mik3hall at gmail.com  Wed Aug 23 06:33:44 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 23 Aug 2023 01:33:44 -0500
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
 <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
 <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
Message-ID: <E5DEC203-05B2-4B89-8451-14E099CFEC98@gmail.com>



> On Aug 22, 2023, at 9:40 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> 
> 
>> On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Alan,
>> 
>>> On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com> wrote:
>>> 
>>> I?m confused by this.
>>> 
>>> The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.
>> 
>> This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.
>> 
> 
> The problem with this solution is that it introduces bugs. This bug and JDK-8311877 both result from jpackage trying to perform its own certificate search instead of letting codesign do the search.
> 
> The claimed advantage of failing ?faster" is negligible (it is a small difference and only happens when the user has made a mistake) and not worth the (proven) risk of introducing bugs.
> 
> If you think you can do a better job of diagnosing the failure to find a certificate than codesign, then you should post-process the failure of codesign. But I don?t see this as a worthwhile investment.
> 
> 
>> Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message. 
>> 
>>> 
>>> Surely codesign can handle certificates with unicode names, can?t it?
>> 
>> Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.
>> 
> 
> Exactly my point. By doing your own certificate validation you risk doing it wrong.
> 

Assuming code sign will catch the errors discussed or even not.

Would it make sense to do post validation of the entire app after completion?

echo '*******************'
echo 'verifying signature'
echo '*******************'
codesign -v --verbose=4 outputdir/HalfPipe.app
echo '********************'
echo 'spctl assess install'
echo '********************'
#spctl --assess --type install --verbose=4 outputdir/HalfPipe.app
echo '********************'
echo 'spctl assess execute'
echo '********************'
#spctl --assess --type execute --verbose=4 outputdir/HalfPipe.app

I don?t remember why I killed the spctl checks. Maybe they were flagging errors that weren?t?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/5d2b7562/attachment.htm>

From alanb at openjdk.org  Wed Aug 23 10:15:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Aug 2023 10:15:27 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream
In-Reply-To: <Z8_44bkT__wwbcn52kb6G5tLhieEUOuVxhyaFLpQMQU=.c48a4c73-a908-4ecd-bf11-b75a4c7911cf@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <R-urK5nyGCYdJxYHTc4lGuXiZlGiTvIoeWprpWv0SP8=.be4bae87-540c-4f04-b54f-d4d0d908de83@github.com>
 <zYIesyOnuBshWBv0O-LOADiPsTnnfEmOEPDFFWjNQYE=.12e73978-12c6-4dfc-8acb-0b7ebc4751cb@github.com>
 <rgOHMFnChaA9Odfup_IsCACCppgg_3gVDi62_zwqy-o=.d99b495f-26f2-4b00-b70f-b75c6223fbb4@github.com>
 <Z8_44bkT__wwbcn52kb6G5tLhieEUOuVxhyaFLpQMQU=.c48a4c73-a908-4ecd-bf11-b75a4c7911cf@github.com>
Message-ID: <SleV2y4Rgi2FUz5jemlEQ2nNsd8VX1DBOODnPJdsPLM=.50bf7b75-eca1-4f24-b22d-2b4d65ad8a83@github.com>

On Mon, 21 Aug 2023 15:05:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I thought of this ,but i was not 100% sure. I will create CSR first.

It's probably a bit premature to create the CSR as there is no agreement here on the API change. I think it would be better to drop this part and focus on the behavior change. As I said, this is a change to long standing behavior that will likely be observed so need to proceed with caution.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1302800335

From raffaello.giulietti at oracle.com  Wed Aug 23 10:23:43 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 23 Aug 2023 12:23:43 +0200
Subject: RFR: 8313961: Enhance identification of special serialization
 methods
In-Reply-To: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
References: <ez32Avbsd2oL5ccVGBpv9KTBmXDBXFLSDMJYCLpTMNQ=.a6e82cb5-e76a-4646-b5e7-1b95de84e26f@github.com>
Message-ID: <1bd92a66-2746-f0a1-3a90-86b0d65a58f3@oracle.com>

Here's some more context about the issues that the PR attempts to fix.

Currently, serialization identifies special "magic" methods by querying 
classical reflection. It does so by invoking `getDeclaredMethod(name, 
parametertypes)`. This works correctly under the assumption that a 
serializable class contains at most one method with that name and those 
parameter types. While the assumption is valid in the Java language, it 
is not necessarily valid for JVM classes.

The specification of `Class::getDeclaredMethod` makes it clear that in 
case there are multiple methods with the same name and parameter types, 
the one with the most specific return type is chosen, or an arbitrary 
one is returned if there's no most specific one. This non-determinism 
means that serialization might fail to identify the relevant method. 
Even more, it might identify the relevant method on some implementations 
of the JDK, or during some runs, and fail to find it in other 
implementations or in other runs.

For example, suppose a serializable class (in the JVMS sense) contains 
the following methods (pseudo-Java)
```
     private int writeObject(ObjectOutputStream oos) {...}
     private void writeObject(ObjectOutputStream oos) {...}
```
Neither method has a most specific return type. Depending on how the 
methods appear in the class, the current implementation of 
`Class::getDeclaredMethod` returns the first or the second method. Only 
the second is relevant for serialization. When the first is returned, 
the relevant method is ignored by serialization, despite being present 
in the class.

The solution proposed by the PR identifies the relevant method even in 
such cases. However, this might break behavioral compatibility for 
classes which, for example, have multiple 
`writeObject(ObjectOutputStream)` methods.



A similar problem exists for special "magic" fields, which are currently 
identified by invoking `getDeclaredField(name)`. Here, however, there 
are a couple of additional issues.

Firstly, the specification of `Class::getDeclaredField` completely 
ignores the possible presence of multiple fields with the same name. It 
says nothing about, and returns an arbitrary one of the homonymous 
fields if there are more.

Secondly, even if the choice is made deterministic, it is unclear which 
field to choose when there are multiple ones.
Consider a class with 4 `serialPersistentFields` fields (pseudo-Java)
```
     private static final Object              serialPersistentFields = 
new ObjectStreamField[0];
     private static final Cloneable           serialPersistentFields = 
new ObjectStreamField[0];
     private static final Serializable        serialPersistentFields = 
new ObjectStreamField[0];
     private static final ObjectStreamField[] serialPersistentFields = 
new SubclassOfObjectStreamField[0];
```
Which one to choose? Which one is preferable?



We thus face a dilemma: the current behavior is potentially 
non-deterministic, which is uncomfortable, although it does not seem a 
problem in practice.
On the other hand, any solution to non-determinism can potentially break 
existing classes at run-time.

Which one is less evil?
Before progressing with the PR, I'd like to hear more opinions.


Greetings
Raffaello

From mdoerr at openjdk.org  Wed Aug 23 12:29:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 23 Aug 2023 12:29:20 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <kbn_Q8G0vVnfxfa-aWmiA7DQ72AFzcH3yrdmOtq7mjg=.24439595-7f1c-46ba-b297-e473e8fe7c20@github.com>

On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Please check windows-aarch64 build error: unresolved external symbol dlopen_ext

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1689871700

From mbaesken at openjdk.org  Wed Aug 23 12:49:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 12:49:21 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <8aZ1XXA5YT0_OrCRIiLwgqvJej8B14ywflAtXS7M264=.9f655668-9bf4-41af-9e6e-b5ee32da13d0@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>
 <8aZ1XXA5YT0_OrCRIiLwgqvJej8B14ywflAtXS7M264=.9f655668-9bf4-41af-9e6e-b5ee32da13d0@github.com>
Message-ID: <lwzKDW6bBqDRHNQJAhVuwy_ZS4Yr1Fkp__dxtJtgtxw=.858d0f1b-31f9-41bc-8864-f30d6e7fa6dd@github.com>

On Fri, 18 Aug 2023 12:35:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>No, I don't think the legacy prefs API being coupled to internals like this. Instead I think this is case where the prefs natives >will need to use strerror.

Hi Alan, should this be done similar to what is done here ,  using strerror + strdup and throwing an exception with the generated error message ?
https://github.com/openjdk/jdk/blob/master/src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c#L105
Does not look very nice to me, but would probably work.

It is really a bit frustrating that we have already in the OpenJDK codebase 2 solutions  (HS runtime/os.cpp and nio UnixConstants ) but none are really usable in other parts of the coding. Looks like a bad duplication (or worse) of efforts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1689900122

From alanb at openjdk.org  Wed Aug 23 12:56:27 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Aug 2023 12:56:27 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <lwzKDW6bBqDRHNQJAhVuwy_ZS4Yr1Fkp__dxtJtgtxw=.858d0f1b-31f9-41bc-8864-f30d6e7fa6dd@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>
 <8aZ1XXA5YT0_OrCRIiLwgqvJej8B14ywflAtXS7M264=.9f655668-9bf4-41af-9e6e-b5ee32da13d0@github.com>
 <lwzKDW6bBqDRHNQJAhVuwy_ZS4Yr1Fkp__dxtJtgtxw=.858d0f1b-31f9-41bc-8864-f30d6e7fa6dd@github.com>
Message-ID: <lk9wB7HHvPVqgPZQ7iz5ooGBMkq7jxuXaGM5OtopFhc=.9dd929c4-347c-460a-aa1e-1c0c327808cc@github.com>

On Wed, 23 Aug 2023 12:46:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, should this be done similar to what is done here , using strerror + strdup and throwing an exception with the generated error message ? https://github.com/openjdk/jdk/blob/master/src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c#L105 Does not look very nice to me, but would probably work.

I suspect the Unix implementation of prefs can easily be replaced with code that uses FileChannel. I think it would be good to try this and would allow the old native code to be removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1689907432

From alanb at openjdk.org  Wed Aug 23 13:05:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Aug 2023 13:05:20 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <dz875Wg1UGzws9xBWcSHUM6nlPWwP2z1AdXyY-deyRs=.f0a9093e-2313-4693-b64f-3cc0497a0335@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
 <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>
 <kl1nZKcKJ50pznWkSgmJ1FMgwyI3QsCWCeJaraoJjS8=.40ab384b-b91e-45a1-9bf5-fbdd19e54552@github.com>
 <dz875Wg1UGzws9xBWcSHUM6nlPWwP2z1AdXyY-deyRs=.f0a9093e-2313-4693-b64f-3cc0497a0335@github.com>
Message-ID: <de5CLrOVqincmTeTjSHmUYWY7tZWMRP_aGC1so_TlsY=.40b6821e-d75c-4a33-bbed-c7c2b08b146f@github.com>

On Tue, 22 Aug 2023 07:48:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan, should we maybe add this ? If so in this change on in another one ?

I don't have a strong opinion on this, I was just surprised to see these tests run concurrently given the history of issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1689922379

From mbaesken at openjdk.org  Wed Aug 23 13:05:22 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 13:05:22 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <lk9wB7HHvPVqgPZQ7iz5ooGBMkq7jxuXaGM5OtopFhc=.9dd929c4-347c-460a-aa1e-1c0c327808cc@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>
 <8aZ1XXA5YT0_OrCRIiLwgqvJej8B14ywflAtXS7M264=.9f655668-9bf4-41af-9e6e-b5ee32da13d0@github.com>
 <lwzKDW6bBqDRHNQJAhVuwy_ZS4Yr1Fkp__dxtJtgtxw=.858d0f1b-31f9-41bc-8864-f30d6e7fa6dd@github.com>
 <lk9wB7HHvPVqgPZQ7iz5ooGBMkq7jxuXaGM5OtopFhc=.9dd929c4-347c-460a-aa1e-1c0c327808cc@github.com>
Message-ID: <piJ3wffuDJGIQiqQaGExucycRpTh_BR8hODLCzxy7VA=.616d3a12-9189-487d-94a7-442be76f4900@github.com>

On Wed, 23 Aug 2023 12:51:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>I suspect the Unix implementation of prefs can easily be replaced with code that uses FileChannel. I think it would be good to try > this and would allow the old native code to be removed.

This might be the case, but it is a separate issue.  This issue is about  improving the BackingStoreException .
Normally I would not even touch the prefs C code, but converting the errno int  into something more 'nice'  has to be done somewhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1689924983

From duke at openjdk.org  Wed Aug 23 13:19:30 2023
From: duke at openjdk.org (duke)
Date: Wed, 23 Aug 2023 13:19:30 GMT
Subject: Withdrawn: JDK-8311009: Long.toUnsignedString(long,
 int) doesn't have to create a BigInteger
In-Reply-To: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
References: <Z_k_zxsuiNiiI9DqGZVPXALlqcXxOJ2VFrK9UQf3Ugw=.a8687de6-4cb4-4560-b830-0e74b12c012e@github.com>
Message-ID: <QYIvov6YL6jfsHnQ8obVwfB6RA6PeLUyHoCgnoJmBfY=.68c0e639-b7e1-410f-ab5c-e6ddf278899f@github.com>

On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan <duke at openjdk.org> wrote:

> This PR changes the implementation of `Long.toUnsignedString(long, int)` for "default" radices, which avoids creating a `BigInteger` and makes use of `Long.divideUnsigned` and `Long.remainderUnsigned`.
> 
> I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works correctly. I believe that there is no need to add more test cases.
> 
> I've added a benchmark case to `test/micro/org/openjdk/bench/java/lang/Longs.java` for this method. Here is the benchmark result tested on my machine:
> 
> Before (JDK 20.0.1):
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score    Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  6428.711 ? 63.142  us/op
> 
> 
> After:
> 
> 
> Benchmark                       (size)  Mode  Cnt     Score     Error  Units
> Longs.toUnsignedStringNegative     500  avgt   15  3823.655 ? 146.171  us/op
> 
> 
> No CSR needed since the behavior is not changed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14654

From alanb at openjdk.org  Wed Aug 23 13:27:20 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Aug 2023 13:27:20 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <piJ3wffuDJGIQiqQaGExucycRpTh_BR8hODLCzxy7VA=.616d3a12-9189-487d-94a7-442be76f4900@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <bsyoyBMJgvgwkw0LX6lHy8v41egPnVgOAfeOkbBHkAA=.74e01096-80e3-43ff-858c-d51389b671fc@github.com>
 <8aZ1XXA5YT0_OrCRIiLwgqvJej8B14ywflAtXS7M264=.9f655668-9bf4-41af-9e6e-b5ee32da13d0@github.com>
 <lwzKDW6bBqDRHNQJAhVuwy_ZS4Yr1Fkp__dxtJtgtxw=.858d0f1b-31f9-41bc-8864-f30d6e7fa6dd@github.com>
 <lk9wB7HHvPVqgPZQ7iz5ooGBMkq7jxuXaGM5OtopFhc=.9dd929c4-347c-460a-aa1e-1c0c327808cc@github.com>
 <piJ3wffuDJGIQiqQaGExucycRpTh_BR8hODLCzxy7VA=.616d3a12-9189-487d-94a7-442be76f4900@github.com>
Message-ID: <BYdSmQDy4vITGulMwxp4BmQESyY6s8mmgd8yo_O91Eo=.f08f6300-2d14-48da-9fb4-642ec3827c54@github.com>

On Wed, 23 Aug 2023 13:02:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> This might be the case, but it is a separate issue. This issue is about improving the BackingStoreException . Normally I would not even touch the prefs C code, but converting the errno int into something more 'nice' has to be done somewhere.

The file operations already do this. All I'm saying is that an option here is to change FileSystemPreferences to use FileChannel as that gets rid of the problematic native code that you are wrestling with. The result should be a BackingStoreException with a better exception message if there is an error creating the file lock or the lock op fails.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1689961219

From mbaesken at openjdk.org  Wed Aug 23 13:53:32 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 13:53:32 GMT
Subject: RFR: JDK-8314883: Java_java_util_prefs_FileSystemPreferences_lockFile0
 write result errno in missing case
Message-ID: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>

There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

-------------

Commit messages:
 - JDK-8314883

Changes: https://git.openjdk.org/jdk/pull/15402/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15402&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314883
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15402.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15402/head:pull/15402

PR: https://git.openjdk.org/jdk/pull/15402

From iselo+openjdk at raccoons.co  Wed Aug 23 14:43:17 2023
From: iselo+openjdk at raccoons.co (Oleksii Kucheruk)
Date: Wed, 23 Aug 2023 17:43:17 +0300
Subject: RFE: Refactor java.util.Optional and add NonNull checks
Message-ID: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>

Hi there.
I have found that `java.util.Optional` is written procedural style and has
`ifnonnull`  checks in each method. I propose to refactor `Optional` in
accordance to OOP-style. This will eliminates all unnecessary
`if`-statements, removes duplications and reduces bytecode size more then
twice.

I have two solutions:
1. Completely dynamic that avoids single static `EMPTY` instance and
unchecked casting of each `Optional.empty()`
2. Preserving original single static `EMPTY` per VM.

Also there are couple methods that throws NPE due to calling methods on
null-objects and requires to add `Objects.requireNonNull(...)`.

OptionalInt, OptionalDouble, OptionalLong could be refactored same way even
with remove of additional boolean variable `isPresent`.

Since I'm new here any guidance will be helpful.
Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/192a6868/attachment.htm>

From duke at openjdk.org  Wed Aug 23 14:58:36 2023
From: duke at openjdk.org (duke)
Date: Wed, 23 Aug 2023 14:58:36 GMT
Subject: Withdrawn: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API
In-Reply-To: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
Message-ID: <-Bw6OdxydH7QxlV2ZgQPWSOjnTniwbzvO2hspukXUX4=.19a0c8c9-4fb1-4c25-9bfa-db76e8ff2f4b@github.com>

On Tue, 14 Mar 2023 02:43:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13009

From vtewari at openjdk.org  Wed Aug 23 15:01:06 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 23 Aug 2023 15:01:06 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
Message-ID: <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>

> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.

Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:

  make the isOpen method to package private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15361/files
  - new: https://git.openjdk.org/jdk/pull/15361/files/5a12a6af..ffc93a71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15361&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15361&range=00-01

  Stats: 11 lines in 3 files changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15361.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15361/head:pull/15361

PR: https://git.openjdk.org/jdk/pull/15361

From mbaesken at openjdk.org  Wed Aug 23 15:18:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 23 Aug 2023 15:18:03 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
Message-ID: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>

> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
> 
> Offer an interface (e.g. jvm.cpp) to support this.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  windows aarch64 build issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15264/files
  - new: https://git.openjdk.org/jdk/pull/15264/files/94e25ad7..9ceec5e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15264&range=00-01

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15264/head:pull/15264

PR: https://git.openjdk.org/jdk/pull/15264

From bchristi at openjdk.org  Wed Aug 23 15:40:24 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 23 Aug 2023 15:40:24 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v3]
In-Reply-To: <mePBmmBWJw9beXJUqj1oStOj3dh2ZhHOEpJKi-wykJE=.dbdca860-1674-4936-b2f7-2e787c39bc0e@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <mePBmmBWJw9beXJUqj1oStOj3dh2ZhHOEpJKi-wykJE=.dbdca860-1674-4936-b2f7-2e787c39bc0e@github.com>
Message-ID: <2I1tRJQUo2wc1SK2L6Ah3ru77BIIucxnUSbFe5wiIBY=.bebde1f8-1803-4ad4-9602-949aaa644840@github.com>

On Tue, 22 Aug 2023 19:01:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Replace NO_METHOD_INFO option with StackWalker.Kind enums
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - clean up
>  - fix trailing whitespace
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - Update LocalLongHelper.java
>  - clean up
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - Add StackWalker.Option.NO_METHOD_INFO
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb

Sorry for not getting a look at this earlier.

I don't think adding a new `Kind` enum is the best way to do this.

StackWalkers would be configured along two different axes (`Kind` _and_ `Options`). It changes the mental model, in that all StackWalkers would now be divided into two `Kind`s. I feel like this bleeds the implementation into the API a bit.

The existing `Option` enum already provides a way to configure which frames are walked, and what information to include in those frames.  I think adding a new `Option` value fits better.

It's true that compatibility dictates that the default behavior be to _include_ method info, so the new option must _omit_ method info. If the `NO_METHOD_INFO` is disliked, perhaps a better name can be found - `SKIP_METHOD_INFO` or `OMIT_METHOD_INFO`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1690187998

From coffeys at openjdk.org  Wed Aug 23 15:47:42 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 23 Aug 2023 15:47:42 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError
Message-ID: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>

Recursive initialization calls possible during loading of LoggerFinder service.  

This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

-------------

Commit messages:
 - more cleanup
 - Copyright year
 - Edits to orig patch
 - Initial design

Changes: https://git.openjdk.org/jdk/pull/15404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314263
  Stats: 406 lines in 7 files changed: 396 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From forax at univ-mlv.fr  Wed Aug 23 15:56:42 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 23 Aug 2023 17:56:42 +0200 (CEST)
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
Message-ID: <2142535309.16863634.1692806202964.JavaMail.zimbra@univ-eiffel.fr>

Sorry, you can not do that. 
Optional is a value based class [1] (see the javadoc) so the class has to be final. 

And more generally, the API of a classes of OpenJDK will not change based on some stylistic issue, OOP or not. 

regards, 
R?mi Forax 

[1] https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/doc-files/ValueBased.html 

> From: "Oleksii Kucheruk" <iselo+openjdk at raccoons.co>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, August 23, 2023 4:43:17 PM
> Subject: RFE: Refactor java.util.Optional and add NonNull checks

> Hi there.
> I have found that `java.util.Optional` is written procedural style and has
> `ifnonnull` checks in each method. I propose to refactor `Optional` in
> accordance to OOP-style. This will eliminates all unnecessary `if`-statements,
> removes duplications and reduces bytecode size more then twice.

> I have two solutions:
> 1. Completely dynamic that avoids single static `EMPTY` instance and unchecked
> casting of each `Optional.empty()`
> 2. Preserving original single static `EMPTY` per VM.

> Also there are couple methods that throws NPE due to calling methods on
> null-objects and requires to add `Objects.requireNonNull(...)`.

> OptionalInt, OptionalDouble, OptionalLong could be refactored same way even with
> remove of additional boolean variable `isPresent`.

> Since I'm new here any guidance will be helpful.
> Thank you in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/e9f01acd/attachment-0001.htm>

From aefimov at openjdk.org  Wed Aug 23 16:36:25 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 23 Aug 2023 16:36:25 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
Message-ID: <KNsxF2zmS5kYtLhBI1KFxdHC8W3ao-CvyrhG5NkekmE=.966b58ed-7e92-4485-9cbb-a1a2ab7bb1ec@github.com>

On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

May I suggest a slightly different approach for refactoring of the Connection class code here:
Instead of having two methods for creating a `Socket` with OR without socket factory the method to select a socket factory can be introduced: 
If a socket factory class name is not set - the factory returned by `SocketFactory.getDefault()` will be used (which is identical to `s = new Socket()` for calls with timeout set; and `s = new Socket(host, port)` for calls with no timeout set):

```    private SocketFactory getSocketFactory(String socketFactoryName) throws Exception {
    if (socketFactoryName == null) {
        if (debug) {
            System.err.println("Connection: using default SocketFactory");
        }
        return SocketFactory.getDefault();
    } else {
        if (debug) {
            System.err.println("Connection: loading supplied SocketFactory: " + socketFactoryName);
        }
        @SuppressWarnings("unchecked")
        Class<? extends SocketFactory> socketFactoryClass =
                (Class<? extends SocketFactory>) Obj.helper.loadClass(socketFactoryName);
        Method getDefault =
                socketFactoryClass.getMethod("getDefault");
        SocketFactory factory = (SocketFactory) getDefault.invoke(null, new Object[]{});
        return factory;
    }
}


It then can be used to create a connection socket:

    private Socket createConnectionSocket(String host, int port, SocketFactory factory, int connectTimeout) throws Exception {
        Socket socket = null;

        if (connectTimeout > 0) {
            // create unconnected socket and then connect it if timeout
            // is supplied
            InetSocketAddress endpoint =
                    createInetSocketAddress(host, port);
            // unconnected socket
            socket = factory.createSocket();
            // connect socket with a timeout
            socket.connect(endpoint, connectTimeout);
            if (debug) {
                System.err.println("Connection: creating socket with " +
                        "a connect timeout");
            }
        }
        if (socket == null) {
            // create connected socket
            socket = factory.createSocket(host, port);
            if (debug) {
                System.err.println("Connection: creating connected socket with" +
                        " no connect timeout");
            }
        }
        return socket;
    }


And then `createSocket` can be changed to:

    private Socket createSocket(String host, int port, String socketFactory,
                                int connectTimeout) throws Exception {

        SocketFactory factory = getSocketFactory(socketFactory);
        assert factory != null;
        Socket socket = createConnectionSocket(host, port, factory, connectTimeout);

        // the handshake for SSL connection with server and reset timeout for the socket
        try {
            initialSSLHandshake(socket, connectTimeout);
        } catch (Exception e) {
            // 8314063 the socket is not closed after the failure of handshake
            // close the socket while the error happened
            closeOpenedSocket(socket);
            throw e;
        }
        return socket;
    }


Also, the new try catch block can be put around initialSSLHandshake method only - it is the only case when socket can be set to a non-null value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1690278791

From dfuchs at openjdk.org  Wed Aug 23 17:41:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 17:41:29 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>

On Wed, 23 Aug 2023 15:41:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java line 230:

> 228:     // The accessor in which this logger is temporarily set.
> 229:     final LazyLoggerAccessor holder;
> 230:     final BooleanSupplier isLoadingThread;

Suggestion:

    // tests whether the logger is invoked by the loading thread before
    // the LoggerFinder is loaded; can be null;
    final BooleanSupplier isLoadingThread;

src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java line 234:

> 232:     boolean isLoadingThread() {
> 233:         return isLoadingThread != null && isLoadingThread.getAsBoolean();
> 234:     }

Suggestion:

    // returns true if the logger is invoked by the loading thread before the
    // LoggerFinder service is loaded
    boolean isLoadingThread() {
        return isLoadingThread != null && isLoadingThread.getAsBoolean();
    }

src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java line 948:

> 946:     //      and the LogManager has not been initialized yet.
> 947:     public static boolean useLazyLoggers() {
> 948:         if (!BootstrapLogger.isBooted() ||

Suggestion:

        // Note: avoid triggering the initialization of the DetectBackend class
        //   while holding the BotstrapLogger class monitor
        if (!BootstrapLogger.isBooted() ||

src/java.base/share/classes/jdk/internal/logger/LazyLoggers.java line 425:

> 423:      */
> 424:     public static final Logger getLogger(String name, Module module) {
> 425:         BootstrapLogger.detectBackend();

Suggestion:

        // triggers detection of the backend
        BootstrapLogger.detectBackend();

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 76:

> 74: 
> 75:     // Return the loaded LoggerFinder, or load it if not already loaded.
> 76:     static volatile Thread loadingThread;

Suggestion:

    // record the loadingThread while loading the backend
    static volatile Thread loadingThread;
    // Return the loaded LoggerFinder, or load it if not already loaded.

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 83:

> 81:             Thread currentThread = Thread.currentThread();
> 82:             if (loadingThread == currentThread) {
> 83:                 return new TemporaryLoggerFinder();

Suggestion:

                // recursive ttempt to load the backend while loading the backend
                // use a temporary logger finder that returns special BootsrtapLoggers
                // which will wait until loading is finished
                return new TemporaryLoggerFinder();

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 98:

> 96:     }
> 97: 
> 98:     static boolean isLoadingThread() {

Suggestion:

    // returns true if called by the thread that loads the LoggerFinder, while
    // loading the LoggerFinder. 
    static boolean isLoadingThread() {

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 140:

> 138:     }
> 139: 
> 140:     static class TemporaryLoggerFinder extends LoggerFinder {

Suggestion:

    private static final class TemporaryLoggerFinder extends LoggerFinder {

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 145:

> 143:                     @Override
> 144:                     public Logger apply(String name, Module module) {
> 145:                         return LazyLoggers.getLoggerFromFinder(name, module);

A better idea might be to:
Suggestion:

                        return LazyLoggers.getLogger(name, module);

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 154:

> 152:             }
> 153:         };
> 154: 

Suggestion:

        private static final TemporaryLoggerFinder INSTANCE = new TemporaryLoggerFinder();

test/jdk/java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.java line 161:

> 159:             Logger testLogger = Logger.getLogger("jdk.event.security");
> 160:             assertEquals(testLogger.getClass().getName(), "java.util.logging.Logger");
> 161:             testComplete = true;

I believe these lines should be after `Security.setProperty("test_2", "test");`, to make sure the logger is loaded by the module that uses it. Also I was expecting some kind of checks to verify that the expected messages are indeed logged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303306422
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303310327
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303314153
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303315890
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303317596
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303320330
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303323768
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303327924
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303324768
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303326813
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303342480

From dfuchs at openjdk.org  Wed Aug 23 17:41:31 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 17:41:31 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError
In-Reply-To: <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>
Message-ID: <Esrm0V7Jh_MWD6Lc1qwryYlVTmayVEqgDft0uq-xpA0=.6bf03845-a911-46d0-86b0-ef7375775143@github.com>

On Wed, 23 Aug 2023 17:15:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 83:
> 
>> 81:             Thread currentThread = Thread.currentThread();
>> 82:             if (loadingThread == currentThread) {
>> 83:                 return new TemporaryLoggerFinder();
> 
> Suggestion:
> 
>                 // recursive ttempt to load the backend while loading the backend
>                 // use a temporary logger finder that returns special BootsrtapLoggers
>                 // which will wait until loading is finished
>                 return new TemporaryLoggerFinder();

We could create a singleton instance of TemporaryLoggerFinder in the TemporaryLoggerFinder class and return that.
Suggestion:

                return new TemporaryLoggerFinder.INSTANCE;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1303321618

From asemenyuk at openjdk.org  Wed Aug 23 17:46:21 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 23 Aug 2023 17:46:21 GMT
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
Message-ID: <HeS9OGXEh1DFpE12a4tQvBk2dRJG_XHJHPbA_U_LjHA=.810d738b-bc4f-4536-8d2e-999bfd373916@github.com>

On Tue, 22 Aug 2023 21:59:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for certificates with UNICODE characters.
> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15394#pullrequestreview-1592110218

From msheppar at openjdk.org  Wed Aug 23 17:55:25 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 23 Aug 2023 17:55:25 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
Message-ID: <jaLf8lTb0EDzU7lpqkSWCslVaA8XL6W4CooqtRWgIcg=.48b827c5-bda2-4395-906d-b328655583ca@github.com>

On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

looks like a good approach ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1690389811

From dfuchs at openjdk.org  Wed Aug 23 18:23:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Aug 2023 18:23:27 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v3]
In-Reply-To: <mePBmmBWJw9beXJUqj1oStOj3dh2ZhHOEpJKi-wykJE=.dbdca860-1674-4936-b2f7-2e787c39bc0e@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <mePBmmBWJw9beXJUqj1oStOj3dh2ZhHOEpJKi-wykJE=.dbdca860-1674-4936-b2f7-2e787c39bc0e@github.com>
Message-ID: <9NLO5FAeCdO7hf3exlczvF2zvCVfw6i-p2Ai7r_qkS8=.3040e411-c79b-4f4b-b2cf-71087f84333a@github.com>

On Tue, 22 Aug 2023 19:01:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Replace NO_METHOD_INFO option with StackWalker.Kind enums
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - clean up
>  - fix trailing whitespace
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - Update LocalLongHelper.java
>  - clean up
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - Add StackWalker.Option.NO_METHOD_INFO
>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb

src/java.base/share/classes/java/lang/StackFrameInfo.java line 38:

> 36:         SharedSecrets.getJavaLangInvokeAccess();
> 37: 
> 38:     private final boolean retainClassRef;

Shouldn't `private final boolean retainClassRef` move to ClassFrameInfo? Isn't it strange that CLASS_INFO still implies RETAIN_CLASS_REFERENCE?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1303378176

From roger.riggs at oracle.com  Wed Aug 23 18:41:01 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 23 Aug 2023 14:41:01 -0400
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <2142535309.16863634.1692806202964.JavaMail.zimbra@univ-eiffel.fr>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <2142535309.16863634.1692806202964.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <66b65ab0-99e8-5e16-b324-87176bf8b694@oracle.com>

Hi,

Also, Null checks in the VM are very cheap, likely cheaper than a 
virtual dispatch.
Adding calls to requireNonNull is almost always a no-op, except for 
adding a variable name to the exception it still throws NPE. A 
frequently used class like Optional will be compiled to machine code and 
the number of byte codes is not an important metric.

Regardless, Project Valhalla will be converting and optimizing Optional 
to a value class as the project matures.

Thanks, Roger


On 8/23/23 11:56 AM, Remi Forax wrote:
> Sorry, you can not do that.
> Optional is a value based class [1] (see the javadoc) so the class has 
> to be final.
>
> And more generally, the API of a classes of OpenJDK will not change 
> based on some stylistic issue, OOP or not.
>
> regards,
> R?mi Forax
>
> [1] 
> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Oleksii Kucheruk" <iselo+openjdk at raccoons.co>
>     *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
>     *Sent: *Wednesday, August 23, 2023 4:43:17 PM
>     *Subject: *RFE: Refactor java.util.Optional and add NonNull checks
>
>     Hi there.
>     I have found that?`java.util.Optional` is written procedural style
>     and has `ifnonnull`? checks in each method. I propose to refactor
>     `Optional` in accordance to OOP-style. This will eliminates all
>     unnecessary `if`-statements, removes duplications and reduces
>     bytecode size more then twice.
>
>     I have two solutions:
>     1. Completely dynamic that avoids single static `EMPTY` instance
>     and unchecked casting of each `Optional.empty()`
>     2. Preserving original single static `EMPTY` per VM.
>
>     Also there are couple methods that throws NPE due to?calling
>     methods on null-objects and requires to add
>     `Objects.requireNonNull(...)`.
>
>     OptionalInt, OptionalDouble, OptionalLong could be refactored same
>     way even with remove of additional boolean variable `isPresent`.
>
>     Since I'm new here any guidance will be helpful.
>     Thank you in advance.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/5d797fa4/attachment-0001.htm>

From almatvee at openjdk.org  Wed Aug 23 20:25:33 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 23 Aug 2023 20:25:33 GMT
Subject: Integrated: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
Message-ID: <stjAt1wTXGYehTNRLnAX88opBoPS4UZbHCsB4aUoBKk=.db9f4ef2-8b35-4a1a-8a77-bacd8f1082ad@github.com>

On Tue, 22 Aug 2023 21:59:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for certificates with UNICODE characters.
> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.

This pull request has now been integrated.

Changeset: 57a322da
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57a322da9bf6aac98e834516728fb6da1c18e7aa
Stats:     444 lines in 11 files changed: 248 ins; 60 del; 136 mod

8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/15394

From mchung at openjdk.org  Wed Aug 23 20:27:38 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 23 Aug 2023 20:27:38 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v4]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
> instead and such stack walker will save the overhead (1) to extract the method information
> and (2) the memory used for the stack walking.   In addition, this can also fix
> 
> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
> 
> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
> This provides a simple way for existing code, for example logging frameworks, to take advantage of
> this enhancement with the least change as it can keep the existing function for traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(interestingClasses::contains)
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> #### Alternatives Considered
> One alternative is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
> it only needs a small change in calling `getInstance` method to request class only info...

Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:

 - fix whitespace
 - move retainClassRef to ClassFrameInfo as a bit set in the flags field
 - fixup the factory methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15370/files
  - new: https://git.openjdk.org/jdk/pull/15370/files/434d90cb..30984253

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=02-03

  Stats: 109 lines in 10 files changed: 44 ins; 28 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From mchung at openjdk.org  Wed Aug 23 20:27:41 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 23 Aug 2023 20:27:41 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v3]
In-Reply-To: <9NLO5FAeCdO7hf3exlczvF2zvCVfw6i-p2Ai7r_qkS8=.3040e411-c79b-4f4b-b2cf-71087f84333a@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <mePBmmBWJw9beXJUqj1oStOj3dh2ZhHOEpJKi-wykJE=.dbdca860-1674-4936-b2f7-2e787c39bc0e@github.com>
 <9NLO5FAeCdO7hf3exlczvF2zvCVfw6i-p2Ai7r_qkS8=.3040e411-c79b-4f4b-b2cf-71087f84333a@github.com>
Message-ID: <Buwbt5q3yEK3QyNOQc6cs6WNfralKeuHN6qBocUvScU=.ecb8a69e-9460-4189-a6d0-65c061125ebb@github.com>

On Wed, 23 Aug 2023 18:12:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Replace NO_METHOD_INFO option with StackWalker.Kind enums
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>>  - clean up
>>  - fix trailing whitespace
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>>  - Update LocalLongHelper.java
>>  - clean up
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>>  - Add StackWalker.Option.NO_METHOD_INFO
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into stackwalker-class
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/ce1ded1a...434d90cb
>
> src/java.base/share/classes/java/lang/StackFrameInfo.java line 38:
> 
>> 36:         SharedSecrets.getJavaLangInvokeAccess();
>> 37: 
>> 38:     private final boolean retainClassRef;
> 
> Shouldn't `private final boolean retainClassRef` move to ClassFrameInfo? Isn't it strange that CLASS_INFO still implies RETAIN_CLASS_REFERENCE?

I was planning to move `retainClassRef` to `ClassFrameInfo` as a bit set in the `flags` field.   Thanks for catching this and reminding me to do that.  Now updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1303501735

From aturbanov at openjdk.org  Wed Aug 23 20:44:31 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 23 Aug 2023 20:44:31 GMT
Subject: Integrated: 8314734: Remove unused field
 TypeVariableImpl.EMPTY_ANNOTATION_ARRAY
In-Reply-To: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>
References: <7ePBWHjjcW5-qgde1XY9vgJi3WbbVb92Htm9LdH4caE=.7b583766-5368-467b-aab2-15c1127be44f@github.com>
Message-ID: <Hq-I0AFdBWFBxDoAlGf7pDfpt7ZWyXPcv-eUhm5N3J0=.f787cc52-874f-4d72-a68e-83355d29a3dd@github.com>

On Tue, 22 Aug 2023 06:57:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field is unused since [JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) - https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e

This pull request has now been integrated.

Changeset: 68815d54
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68815d54c199d39b14034c926777b492fa453a22
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8314734: Remove unused field TypeVariableImpl.EMPTY_ANNOTATION_ARRAY

Reviewed-by: bpb, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/15379

From javalists at cbfiddle.com  Wed Aug 23 20:54:45 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 23 Aug 2023 13:54:45 -0700
Subject: Integrated: 8308042: [macos] Developer ID Application Certificate
 not picked up by jpackage if it contains UNICODE characters
In-Reply-To: <stjAt1wTXGYehTNRLnAX88opBoPS4UZbHCsB4aUoBKk=.db9f4ef2-8b35-4a1a-8a77-bacd8f1082ad@github.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <stjAt1wTXGYehTNRLnAX88opBoPS4UZbHCsB4aUoBKk=.db9f4ef2-8b35-4a1a-8a77-bacd8f1082ad@github.com>
Message-ID: <584EE3A7-A5D3-47CA-B507-BFF025D52203@cbfiddle.com>

What?s the point of reviewing if the reviews are ignored?



> On Aug 23, 2023, at 1:25 PM, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
> On Tue, 22 Aug 2023 21:59:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
>> - Added support for certificates with UNICODE characters.
>> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
>> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
>> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.
> 
> This pull request has now been integrated.
> 
> Changeset: 57a322da
> Author:    Alexander Matveev <almatvee at openjdk.org>
> URL:       https://git.openjdk.org/jdk/commit/57a322da9bf6aac98e834516728fb6da1c18e7aa
> Stats:     444 lines in 11 files changed: 248 ins; 60 del; 136 mod
> 
> 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters
> 
> Reviewed-by: asemenyuk
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/15394
> 


From coleenp at openjdk.org  Wed Aug 23 21:34:22 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Aug 2023 21:34:22 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v4]
In-Reply-To: <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
Message-ID: <JrzeIOTYkSohmWSXHcyTKIdklmX-VQnvdtxKiY1FB1k=.12177d13-f072-415b-90c6-5a0fbb6c6fce@github.com>

On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fix whitespace
>  - move retainClassRef to ClassFrameInfo as a bit set in the flags field
>  - fixup the factory methods

The VM changes look good.  Promoting ResolvedMethodName seems more efficient in terms of space than MemberName.  Is there anything to prevent Java code from calling
ResolvedMethodName rm = new ResolvedMethodName(); since the Method* needs to be registered in the JVMs Hashtable?  (for redefinition)

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1592445140

From bpb at openjdk.org  Wed Aug 23 21:45:23 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Aug 2023 21:45:23 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
Message-ID: <uhyLuKi0_gBol9wAcln19it1l1QLvZVsHQi1mVYQODM=.19d5c1d5-2f31-4087-8c5b-d933092424ec@github.com>

On Wed, 23 Aug 2023 15:01:06 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make the isOpen method to package private

src/java.base/share/classes/java/io/FilterOutputStream.java line 210:

> 208:      */
> 209:     boolean isOpen(){
> 210:         return !closed;

Wouldn't you want `synchronized (closeLock)` here?

test/jdk/java/io/BufferedOutputStream/WriteAfterClose.java line 36:

> 34: import java.io.OutputStream;
> 35: import java.io.File;
> 36: import java.io.FileOutputStream;

The imports should be in alphabetical order per convention.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1303571619
PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1303572211

From bpb at openjdk.org  Wed Aug 23 21:51:09 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Aug 2023 21:51:09 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
Message-ID: <lqq-1sFoNnAFJjtc-scccGcjV07tcWcnvvDoHW68kpg=.41fba613-f37c-470a-8a78-ee6bdfbfa57c@github.com>

On Wed, 23 Aug 2023 15:01:06 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make the isOpen method to package private

test/jdk/java/io/BufferedOutputStream/WriteAfterClose.java line 61:

> 59:     public static void main(String argv[]) throws IOException {
> 60:         var file = new File(System.getProperty("test.dir", "."), "test.txt");
> 61:         file.createNewFile();

Why not instead do something like?:

var dir = new File(System.getProperty("test.dir", "."));
File file = File.createTempFile("x", "y", dir);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1303575171

From bpb at openjdk.org  Wed Aug 23 22:06:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Aug 2023 22:06:53 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
Message-ID: <dzDwU7C_-HGwUPeU8Lir5J5DO_tckwPN4Mdg-vNqxxs=.f295639f-93e2-409e-81da-c4db3921f823@github.com>

On Wed, 23 Aug 2023 15:01:06 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> With the current  implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private  "ensureOpen" function to BufferedOutputStream which will check if the underline stream is open. If the underline stream is closed "ensureOpen" will throw the IOException.
>
> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make the isOpen method to package private

The proposed change does not appear to add a great deal of value and breaks longstanding behavior. In such cases, the preferred approach is usually to modify the specification to match the current, albeit incorrect, behavior rather than to change the code itself. Given that this issue was filed more than two decades ago suggests that changing the implementation would be likely to break code which unwittingly depends on the longstanding behavior.

The PR title should be changed to match the JBS issue summary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15361#issuecomment-1690696492
PR Comment: https://git.openjdk.org/jdk/pull/15361#issuecomment-1690702429

From psandoz at openjdk.org  Wed Aug 23 22:08:17 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 23 Aug 2023 22:08:17 GMT
Subject: RFR: 8314544: Matrix multiple benchmark using Vector API [v2]
In-Reply-To: <QHvth827QpJkt4bY9KEpcOs6xV9_Vfa4qT8y_LeMrm8=.684fe64b-dae2-4404-9247-de4cd8eec522@github.com>
References: <Yyk-7KRqQeGk8UMVi3r8BSPDJbZX_5R7N3nEqHEAjgk=.64868189-07c5-46ca-8ea7-75d650008d02@github.com>
 <QHvth827QpJkt4bY9KEpcOs6xV9_Vfa4qT8y_LeMrm8=.684fe64b-dae2-4404-9247-de4cd8eec522@github.com>
Message-ID: <NE1xJdc-_o9zdnPp-3hai1meAQLWcEvJ5lvBrioOwiI=.4efa2333-08c9-4e46-8507-a895fa3e1b5d@github.com>

On Mon, 21 Aug 2023 03:55:42 GMT, Martin Stypinski <duke at openjdk.org> wrote:

>> Added a bunch of different implementations for Vector API Matrix Multiplications:
>> 
>> - Baseline
>> - Blocked (Cache Local)
>> - FMA
>> - Vector API Simple Implementation
>> - Vector API Blocked Implementation
>> 
>> Commit was discussed with @PaulSandoz
>
> Martin Stypinski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - changed for consistency
>  - improved some RandomGenerator & unuseed Imports

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15338#pullrequestreview-1592478060

From lancea at openjdk.org  Wed Aug 23 22:13:39 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 23 Aug 2023 22:13:39 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <lqq-1sFoNnAFJjtc-scccGcjV07tcWcnvvDoHW68kpg=.41fba613-f37c-470a-8a78-ee6bdfbfa57c@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
 <lqq-1sFoNnAFJjtc-scccGcjV07tcWcnvvDoHW68kpg=.41fba613-f37c-470a-8a78-ee6bdfbfa57c@github.com>
Message-ID: <y2gMtDOQJojHQFnmMGvdF2F75DHurPLKuVLK8948tTM=.d9a1afd8-049c-4e03-9021-660ab332f6bf@github.com>

On Wed, 23 Aug 2023 21:46:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make the isOpen method to package private
>
> test/jdk/java/io/BufferedOutputStream/WriteAfterClose.java line 61:
> 
>> 59:     public static void main(String argv[]) throws IOException {
>> 60:         var file = new File(System.getProperty("test.dir", "."), "test.txt");
>> 61:         file.createNewFile();
> 
> Why not instead do something like?:
> 
> var dir = new File(System.getProperty("test.dir", "."));
> File file = File.createTempFile("x", "y", dir);

I don't think you need to specify `test.dir`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1303590880

From bpb at openjdk.org  Wed Aug 23 22:39:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 23 Aug 2023 22:39:37 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <y2gMtDOQJojHQFnmMGvdF2F75DHurPLKuVLK8948tTM=.d9a1afd8-049c-4e03-9021-660ab332f6bf@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
 <lqq-1sFoNnAFJjtc-scccGcjV07tcWcnvvDoHW68kpg=.41fba613-f37c-470a-8a78-ee6bdfbfa57c@github.com>
 <y2gMtDOQJojHQFnmMGvdF2F75DHurPLKuVLK8948tTM=.d9a1afd8-049c-4e03-9021-660ab332f6bf@github.com>
Message-ID: <oTJzZRIZbYaLG6TyR1IaVfML-hXJ77ehFj4VF-5AaYI=.ffc49751-a0c0-4ea3-9f1b-4ded8e6b1b62@github.com>

On Wed, 23 Aug 2023 22:11:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/io/BufferedOutputStream/WriteAfterClose.java line 61:
>> 
>>> 59:     public static void main(String argv[]) throws IOException {
>>> 60:         var file = new File(System.getProperty("test.dir", "."), "test.txt");
>>> 61:         file.createNewFile();
>> 
>> Why not instead do something like?:
>> 
>> var dir = new File(System.getProperty("test.dir", "."));
>> File file = File.createTempFile("x", "y", dir);
>
> I don't think you need to specify `test.dir`

'test.dir' is not necessary, but it's a convention currently used in more than 50 IO and NIO tests. Probably not so useful here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1303604853

From alexander.matveev at oracle.com  Wed Aug 23 23:14:02 2023
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 23 Aug 2023 23:14:02 +0000
Subject: [External] : Re: RFR: 8308042: [macos] Developer ID Application
 Certificate not picked up by jpackage if it contains UNICODE characters
In-Reply-To: <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
 <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
 <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
Message-ID: <9E1881C8-5B84-4FC7-98D0-F4628AE0077C@oracle.com>

Hi Alan,

On Aug 22, 2023, at 7:40 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:



On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Alan,

On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:

I?m confused by this.

The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.

This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.


The problem with this solution is that it introduces bugs. This bug and JDK-8311877 both result from jpackage trying to perform its own certificate search instead of letting codesign do the search.

The claimed advantage of failing ?faster" is negligible (it is a small difference and only happens when the user has made a mistake) and not worth the (proven) risk of introducing bugs.

If you think you can do a better job of diagnosing the failure to find a certificate than codesign, then you should post-process the failure of codesign. But I don?t see this as a worthwhile investment.

JDK-8308042 is about fixing bug in current approach used by jpackage. You suggestion is to passthrough value from ?--mac-signing-key-user-name? to codesign and use it as value for "--sign? argument in codesign will change behavior of ?--mac-signing-key-user-name? and I do not think that we should be doing this as part of this bug fix.

From documentation:
https://docs.oracle.com/en/java/javase/20/jpackage/support-application-features.html#GUID-8D9F0607-91F4-4070-8823-02FCAB12238D

If you want to distribute your application outside the Mac App Store, then you'll need the certificates "Developer ID Application: <user or team name>" and "Developer ID Installer: <user or team name>".

If you want to deploy your application through the Mac App Store, then you'll need the certificates "3rd Party Mac Developer Application: <user or team name>" and "3rd Party Mac Developer Installer: <user or team name>?.

If --mac-app-store is set we will look for "3rd Party Mac Developer Application: <user or team name>? and if we cannot find it we will fallback to "Developer ID Application: <user or team name>? and if it is not found we will fail. If --mac-app-store is not set we will look for "Developer ID Application: <user or team name>?. <user or team name> is value provided via ?--mac-signing-key-user-name?.

I think you suggestion is to add additional argument to jpackage which will be used as passthrough value for "--sign? argument in codesign. I am still not sure if we should be doing this, but I am currently considering it as a solution for https://bugs.openjdk.org/browse/JDK-8311877 instead of adding "Apple Development? as fallback if we cannot find "Developer ID Application?.

Thanks,
Alexander



Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message.


Surely codesign can handle certificates with unicode names, can?t it?

Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.


Exactly my point. By doing your own certificate validation you risk doing it wrong.


Thanks,
Alexander


On Aug 22, 2023, at 3:15 PM, Alexander Matveev <almatvee at openjdk.org<mailto:almatvee at openjdk.org>> wrote:

- Added support for certificates with UNICODE characters.
- Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
- New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
- Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.

-------------

Commit messages:
- 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters

Changes: https://git.openjdk.org/jdk/pull/15394/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8308042
Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
Patch: https://git.openjdk.org/jdk/pull/15394.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394

PR: https://git.openjdk.org/jdk/pull/15394





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/20942884/attachment.htm>

From alexander.matveev at oracle.com  Wed Aug 23 23:24:52 2023
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Wed, 23 Aug 2023 23:24:52 +0000
Subject: [External] : Re: RFR: 8308042: [macos] Developer ID Application
 Certificate not picked up by jpackage if it contains UNICODE characters
In-Reply-To: <E5DEC203-05B2-4B89-8451-14E099CFEC98@gmail.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
 <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
 <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
 <E5DEC203-05B2-4B89-8451-14E099CFEC98@gmail.com>
Message-ID: <A156BE68-982E-407B-93CE-8E3E9E4AD19A@oracle.com>

Hi Michael,

On Aug 22, 2023, at 11:33 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Aug 22, 2023, at 9:40 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:



On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Alan,

On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:

I?m confused by this.

The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.

This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.


The problem with this solution is that it introduces bugs. This bug and JDK-8311877 both result from jpackage trying to perform its own certificate search instead of letting codesign do the search.

The claimed advantage of failing ?faster" is negligible (it is a small difference and only happens when the user has made a mistake) and not worth the (proven) risk of introducing bugs.

If you think you can do a better job of diagnosing the failure to find a certificate than codesign, then you should post-process the failure of codesign. But I don?t see this as a worthwhile investment.


Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message.


Surely codesign can handle certificates with unicode names, can?t it?

Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.


Exactly my point. By doing your own certificate validation you risk doing it wrong.


Assuming code sign will catch the errors discussed or even not.

Would it make sense to do post validation of the entire app after completion?

Good point, but I am not sure if we should be doing this.

Thanks,
Alexander


echo '*******************'
echo 'verifying signature'
echo '*******************'
codesign -v --verbose=4 outputdir/HalfPipe.app
echo '********************'
echo 'spctl assess install'
echo '********************'
#spctl --assess --type install --verbose=4 outputdir/HalfPipe.app
echo '********************'
echo 'spctl assess execute'
echo '********************'
#spctl --assess --type execute --verbose=4 outputdir/HalfPipe.app

I don?t remember why I killed the spctl checks. Maybe they were flagging errors that weren?t?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/c6c56307/attachment-0001.htm>

From mchung at openjdk.org  Wed Aug 23 23:29:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 23 Aug 2023 23:29:25 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v4]
In-Reply-To: <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
Message-ID: <uJ3IsKEBHB7sDyxDJUaKfrk79F2_xBHy_2MSfdi5YK0=.fa321719-16c3-456e-a500-288fcefa854b@github.com>

On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fix whitespace
>  - move retainClassRef to ClassFrameInfo as a bit set in the flags field
>  - fixup the factory methods

We can create `ResolvedMethodName` object and VM can fill in `Method*` and the java mirror without the object allocation.   The question is whether we need to store it in the `ResolvedMethodTable`.  One scenario is: if the user caches `StackFrame` objects for later us,  when the frame is being accessed, the method is already redefined.   Can it find the method information  the old Method* vmentry?   Maybe we can do something like the backtrace?

Another question is: if RMN is not registered in the JVM hashtable, is it possible for the class of the method being unloaded?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1690770829

From mik3hall at gmail.com  Wed Aug 23 23:37:01 2023
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 23 Aug 2023 18:37:01 -0500
Subject: [External] : Re: RFR: 8308042: [macos] Developer ID Application
 Certificate not picked up by jpackage if it contains UNICODE characters
In-Reply-To: <A156BE68-982E-407B-93CE-8E3E9E4AD19A@oracle.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
 <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
 <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
 <E5DEC203-05B2-4B89-8451-14E099CFEC98@gmail.com>
 <A156BE68-982E-407B-93CE-8E3E9E4AD19A@oracle.com>
Message-ID: <14FA3C33-D8D9-4087-8785-EF6246C2DCE1@gmail.com>



>>> 
>> 
>> Assuming code sign will catch the errors discussed or even not.
>> 
>> Would it make sense to do post validation of the entire app after completion?
> 
> Good point, but I am not sure if we should be doing this.
> 
> Thanks,
> Alexander


I?m not quite following that. 

The spctl maybe not, again I?m not remembering details but that might be related to notarizing. I figured it out once and it?s been broken for my builds ever since. I think you have to do some connection with Apple servers and wait until you get a response? Not an easy process to automate.

The codesign verify I?m not sure what would be the harm.  If there are any application signing issues this should catch them. You would be assured in your testing that you hadn?t accidentally broken signing. In support it might tell you if the user has somehow done something to accidentally break signing. 

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/592cb05e/attachment.htm>

From duke at openjdk.org  Thu Aug 24 00:10:54 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 24 Aug 2023 00:10:54 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v11]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <MY3dZoPXYO5wcnb-qPGp7PohEsV5X6BwxrWE9iXu6QU=.02d5a643-f1a9-4246-955b-3331d66f8fe7@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  refactoring the code according to the comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/2e0e80fa..cdb70069

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=09-10

  Stats: 205 lines in 1 file changed: 33 ins; 52 del; 120 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Thu Aug 24 00:10:54 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 24 Aug 2023 00:10:54 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v10]
In-Reply-To: <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <PcaNBam-GrLCxwVFPpYMFe9zBebwXS6gtkQSP1H9eiA=.0d505d50-b418-4117-94bd-d6eb78cbf4f5@github.com>
Message-ID: <e9-8k7hyeDvMb5PpWG3625w7HooGo3DbfUfkcDz2cQI=.95d862e6-2ccb-4a16-8172-5a5f8f806c2a@github.com>

On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

Please see the updated code. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1690796916

From smarks at openjdk.org  Thu Aug 24 02:39:24 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 24 Aug 2023 02:39:24 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v4]
In-Reply-To: <Goz9mnlBOSmYHnfKTNK-XbBr3_P_NiupjiTO7DURbEU=.c05cb614-af85-4dd9-89b2-b44a6112217c@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <Goz9mnlBOSmYHnfKTNK-XbBr3_P_NiupjiTO7DURbEU=.c05cb614-af85-4dd9-89b2-b44a6112217c@github.com>
Message-ID: <IDM6F6g7qrBB5DWLTPwLdg2U3CrzCUAwxyUt2KxE6Fs=.3380339f-fc2b-4a21-b03a-e1dadd1ac0d1@github.com>

On Thu, 17 Aug 2023 10:54:07 GMT, Nikita Sakharin <duke at openjdk.org> wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List<Byte> list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314236: rewrite test

@nikita-sakharin

Thanks for the updates. With the "Mock List" implementation we can run the test in-JVM and we can avoid allocating several GB of memory. Great!

The implementation logic in the `rotate1` method looks correct.

Now that an individual test case is much less expensive, it becomes feasible to add multiple test cases. In particular, for this kind of testing of arithmetic errors, I like to test a variety of edge cases. The one test case you have is for size=`(1 << 30) - 1` and distance=`(1 << 30)`. It would be good to have a few other cases where the existing code fails and where the modified code should pass. I was able to come up with a few examples quickly:

    size                 distance
    Integer.MAX_VALUE    2
    Integer.MAX_VALUE    Integer.MIN_VALUE
    Integer.MAX_VALUE    Integer.MAX_VALUE - 1

Please add these cases, and any others that you think might be interesting.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1690901246

From vtewari at openjdk.org  Thu Aug 24 04:27:24 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 24 Aug 2023 04:27:24 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <dzDwU7C_-HGwUPeU8Lir5J5DO_tckwPN4Mdg-vNqxxs=.f295639f-93e2-409e-81da-c4db3921f823@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
 <dzDwU7C_-HGwUPeU8Lir5J5DO_tckwPN4Mdg-vNqxxs=.f295639f-93e2-409e-81da-c4db3921f823@github.com>
Message-ID: <WIMzKcROxzzTk3LvmKW74nFwSnr6KVgfAmtzX8M-6P4=.f0b8bb72-1ba8-4a3c-9796-ba2aab12ca7c@github.com>

On Wed, 23 Aug 2023 21:54:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The proposed change does not appear to add a great deal of value and breaks longstanding behavior. In such cases, the preferred approach is usually to modify the specification to match the current, albeit incorrect, behavior rather than to change the code itself. Given that this issue was filed more than two decades ago suggests that changing the implementation would be likely to break code which unwittingly depends on the longstanding behavior.

I  am unable to understand how proposed change breaks longstanding behavior(what behavior). With current implementation if the underline stream is closed  ?BufferedOutputStream.write? will throw IOException when the internal buffer is full. With the proposed change BufferedOutputStream will throw IOException  immediately . I don?t see any reason in not throwing exception and waiting till internal buffer fills.

All other OutputStream  implementations internally checks  and throw IOException immediately if the stream is close. So with the proposed change 'BufferedOutputStream' will behave the same.

Do you really think there is code outside which do ?write? after closing the stream, and proposed change will break it ?.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15361#issuecomment-1690976782

From duke at openjdk.org  Thu Aug 24 04:36:27 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 24 Aug 2023 04:36:27 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3]
In-Reply-To: <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
Message-ID: <hzgWsESEzTvaqBbtUN9IjVz_f-n2jlstwuS0itvapMQ=.439937c3-3bf4-4519-945b-76663139f825@github.com>

On Thu, 6 Jul 2023 05:20:14 GMT, ??? <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add method CharacterDataLatin1#isLowerCaseEx

@AlanBateman It has been more than 1 month, can you help me to review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1690984875

From dholmes at openjdk.org  Thu Aug 24 04:50:26 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Aug 2023 04:50:26 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source
In-Reply-To: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
Message-ID: <qah2V3ZevJZm02mUrFlO2W7Nj_kyxP4QflaIkESU00Q=.1dda0ee8-e756-44e4-8df2-5c27ab88bbdc@github.com>

On Fri, 18 Aug 2023 14:22:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.

Seems reasonable.

One suggested change to make the tool command-line processing more robust, but up to you whether to take it or not.

Thanks.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 62:

> 60:                     StandardCharsets.UTF_8);
> 61:             i++;
> 62:         } else if (args.length != 3) {

This is not very robust for detecting malformed invocations. It won't even detect a simple typo in the argument name. I would suggest something more elaborate e.g.

int i  0;
boolean valid = true;
if (args.length != 5 && args.length !=3) {
  valid = false;
} else if (args.length == 5) {
  if ( ! "-jdk-header-template".equals(args[i])) {
    valid = false;
  } else {
    jdkHeaderTemplate = new String(Files.readAllBytes(Paths.get(args[++i])),
                    StandardCharsets.UTF_8);
     i++;
  }
}
if (!valid) {
  System.err.println(...);
   System.exit(1);
}
String lsrFile = args[i++];
...

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15346#pullrequestreview-1592770524
PR Review Comment: https://git.openjdk.org/jdk/pull/15346#discussion_r1303797947

From jpai at openjdk.org  Thu Aug 24 05:37:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Aug 2023 05:37:25 GMT
Subject: RFR: JDK-8314883:
 Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in
 missing case
In-Reply-To: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
References: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
Message-ID: <GKDspUf3SLM0TAawSNVk-S_jCex4tqZpNExwzQPgeaI=.05fbb428-5f3c-4675-805f-46f72b267203@github.com>

On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

The change looks OK to me.

Please wait for another review from someone more familiar with this code.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15402#pullrequestreview-1592808417

From alanb at openjdk.org  Thu Aug 24 06:39:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Aug 2023 06:39:28 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOExcept on closed stream [v2]
In-Reply-To: <WIMzKcROxzzTk3LvmKW74nFwSnr6KVgfAmtzX8M-6P4=.f0b8bb72-1ba8-4a3c-9796-ba2aab12ca7c@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
 <dzDwU7C_-HGwUPeU8Lir5J5DO_tckwPN4Mdg-vNqxxs=.f295639f-93e2-409e-81da-c4db3921f823@github.com>
 <WIMzKcROxzzTk3LvmKW74nFwSnr6KVgfAmtzX8M-6P4=.f0b8bb72-1ba8-4a3c-9796-ba2aab12ca7c@github.com>
Message-ID: <CIgEu93oHv44cSbnqzQzuSj286M39mMq01TKMDQqI74=.c9f3a07a-807d-4e16-844e-1fd37cd07815@github.com>

On Thu, 24 Aug 2023 04:24:21 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> I am unable to understand how proposed change breaks longstanding behavior(what behavior). With current implementation if the underline stream is closed ?BufferedOutputStream.write? will throw IOException when the internal buffer is full. With the proposed change BufferedOutputStream will throw IOException immediately.

The change means that IOException will be thrown for cases where it isn't currently thrown. It also means that IOException may be thrown at different use-sites that it is now. I don't think anyone is disagreeing that there is a long standing bug, the issue is that changing the behavior will likely be observed. In cases like this, we will often decide to just specify long standing behavior as the compatibility impact of fixing something is too high.

In this case, I don't object to fixing it early in JDK 22 but the change will need to be widely tested so as to shake out any bugs in code in the eco system as early as possible. It might be that after a few weeks/months that we get some confidence that it is okay, or it might be that we decide to introduce a system property to restore long standing behavior, or decide to just back it out. The question is whether we can get enough testing of JDK 22 builds to help decide on this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15361#issuecomment-1691087377

From alanb at openjdk.org  Thu Aug 24 06:42:42 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Aug 2023 06:42:42 GMT
Subject: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when pinned
 should be replaced
Message-ID: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>

If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't correct for cases where System.nanoTimes return a negative value or when parking for durations close to Long.MAX_VALUE (292 years). The change isn't really testable so there aren't any test changes included.

-------------

Commit messages:
 - .swp checked in accidently
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15405/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15405&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314759
  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15405/head:pull/15405

PR: https://git.openjdk.org/jdk/pull/15405

From aturbanov at openjdk.org  Thu Aug 24 06:55:26 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 24 Aug 2023 06:55:26 GMT
Subject: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when
 pinned should be replaced
In-Reply-To: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
References: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
Message-ID: <sFv_bY_vrIC9ji_tf4pXcf7273uHpD8mSvOWMXRXd9Y=.67952726-4b26-49cd-9ded-60367a9ce56f@github.com>

On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't correct for cases where System.nanoTimes return a negative value or when parking for durations close to Long.MAX_VALUE (292 years). The change isn't really testable so there aren't any test changes included.

Marked as reviewed by aturbanov (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15405#pullrequestreview-1592895422

From mbaesken at openjdk.org  Thu Aug 24 07:08:26 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 07:08:26 GMT
Subject: RFR: JDK-8314883:
 Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in
 missing case
In-Reply-To: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
References: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
Message-ID: <iUmLd42A1VeL8ZpSXxtv2HELHArLKOS35X8nxa82fSs=.b1bf444b-c095-4da8-b276-0738323e30bb@github.com>

On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

Hi jaikiran, thanks for the review !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15402#issuecomment-1691123447

From mbaesken at openjdk.org  Thu Aug 24 07:29:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 07:29:25 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <kbn_Q8G0vVnfxfa-aWmiA7DQ72AFzcH3yrdmOtq7mjg=.24439595-7f1c-46ba-b297-e473e8fe7c20@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <kbn_Q8G0vVnfxfa-aWmiA7DQ72AFzcH3yrdmOtq7mjg=.24439595-7f1c-46ba-b297-e473e8fe7c20@github.com>
Message-ID: <3Z3DhL13S8nSO7g4EaiOmCxTAZERbtP-GlDzlHW-d34=.3a8a9c47-b3e6-4b7c-afac-567ab81f47c8@github.com>

On Wed, 23 Aug 2023 12:26:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Please check windows-aarch64 build error: unresolved external symbol dlopen_ext

Hi Martin, thanks !  I did a small adjustment, now the windows aarch64 build works.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1691148432

From jwaters at openjdk.org  Thu Aug 24 07:32:51 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Aug 2023 07:32:51 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are not
 pointers
In-Reply-To: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
Message-ID: <MgULJ-0r9zZPHvQrAxEY49K39egabfFFtgPwRz3dHqc=.f7399f3c-b5b6-4af5-94a4-4d1cecb9ffe9@github.com>

On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
>         with
>         [
>             _Other=nullptr
>         ]
>         and
>         [
>             _Ty=unsigned long
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
>         with
>         [
>             _Ty=unsigned long,
>             _Ty2=unsigned long,
>             _Other=nullptr
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????
> 
> 
> `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
> I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

I'm wondering how MSVC is compiling without the <memory> header, when there are several other unique_ptr declarations inside MsiUtils.h. Sorry for bringing up an old commit, but this is now causing issues for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293), and I'm a little curious to know why MSVC still strangely accepts this as valid

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2858#issuecomment-1691153609

From iselo+openjdk at raccoons.co  Thu Aug 24 08:11:37 2023
From: iselo+openjdk at raccoons.co (Oleksii Kucheruk)
Date: Thu, 24 Aug 2023 11:11:37 +0300
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <66b65ab0-99e8-5e16-b324-87176bf8b694@oracle.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <2142535309.16863634.1692806202964.JavaMail.zimbra@univ-eiffel.fr>
 <66b65ab0-99e8-5e16-b324-87176bf8b694@oracle.com>
Message-ID: <CACg0bd0bbsB94DaSoX0Dq7P-joBM2C4Y9EHeL-LeitndsY1SSw@mail.gmail.com>

Thanks Roger, Remi.

Just want to understand full picture.

For both solutions, private static final nested class and dynamic anonymous
overloading, based on dipole/boolean pattern where all methods has opposite
charge, JVM produces separate code for classes that in total has:
- >10% less commands,
- less or same amount of `invokevirtual` related to code duplication in JDK
Optional as well,
- same `invokevirtual` of Optional methods by client code,
- same value based `hashCode()` and `equals()`,
- twice shorter code execution passthrough without `ifnull`, additional `
getfield` and `goto`.

The difference is absence of final class of Optional that actually not
declare accessible constructors. The one property of value-based classes
from javadoc is potentially violated.

Is final only reason? What I missed and where to look under the hood?

I believe that an empty optional does not require `getfield`, a present
optional does not require `ifnull` checks. The decision is already made by
`Optional.of()` or `Optional.ofNullable()`.

regards, Oleksii

On Wed, Aug 23, 2023 at 9:44?PM Roger Riggs <roger.riggs at oracle.com> wrote:

> Hi,
>
> Also, Null checks in the VM are very cheap, likely cheaper than a virtual
> dispatch.
> Adding calls to requireNonNull is almost always a no-op, except for adding
> a variable name to the exception it still throws NPE. A frequently used
> class like Optional will be compiled to machine code and the number of byte
> codes is not an important metric.
>
> Regardless, Project Valhalla will be converting and optimizing Optional to
> a value class as the project matures.
>
> Thanks, Roger
>
>
> On 8/23/23 11:56 AM, Remi Forax wrote:
>
> Sorry, you can not do that.
> Optional is a value based class [1] (see the javadoc) so the class has to
> be final.
>
> And more generally, the API of a classes of OpenJDK will not change based
> on some stylistic issue, OOP or not.
>
> regards,
> R?mi Forax
>
> [1]
> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
>
> ------------------------------
>
> *From: *"Oleksii Kucheruk" <iselo+openjdk at raccoons.co>
> <iselo+openjdk at raccoons.co>
> *To: *"core-libs-dev" <core-libs-dev at openjdk.org>
> <core-libs-dev at openjdk.org>
> *Sent: *Wednesday, August 23, 2023 4:43:17 PM
> *Subject: *RFE: Refactor java.util.Optional and add NonNull checks
>
> Hi there.
> I have found that `java.util.Optional` is written procedural style and has
> `ifnonnull`  checks in each method. I propose to refactor `Optional` in
> accordance to OOP-style. This will eliminates all unnecessary
> `if`-statements, removes duplications and reduces bytecode size more then
> twice.
>
> I have two solutions:
> 1. Completely dynamic that avoids single static `EMPTY` instance and
> unchecked casting of each `Optional.empty()`
> 2. Preserving original single static `EMPTY` per VM.
>
> Also there are couple methods that throws NPE due to calling methods on
> null-objects and requires to add `Objects.requireNonNull(...)`.
>
> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
> even with remove of additional boolean variable `isPresent`.
>
> Since I'm new here any guidance will be helpful.
> Thank you in advance.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230824/27cc702a/attachment-0001.htm>

From vtewari at openjdk.org  Thu Aug 24 08:15:29 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 24 Aug 2023 08:15:29 GMT
Subject: RFR: 4799358: BufferOutputStream.write() should immediately throw
 IOException on closed stream [v2]
In-Reply-To: <uhyLuKi0_gBol9wAcln19it1l1QLvZVsHQi1mVYQODM=.19d5c1d5-2f31-4087-8c5b-d933092424ec@github.com>
References: <FvGmHUalBXCQAyUw4mRFH1sjNtcXUhvnJgt3ZVTlsN0=.883960d3-cdfe-4790-8fa3-44a6812a84d3@github.com>
 <kxpfzYN3AkVw1hq_LAEtaKZf4vXUOdQml3NlFCCX_2M=.b5bea729-80ff-4d2d-a8b6-bcdd094afd1c@github.com>
 <uhyLuKi0_gBol9wAcln19it1l1QLvZVsHQi1mVYQODM=.19d5c1d5-2f31-4087-8c5b-d933092424ec@github.com>
Message-ID: <y2W_KwvsvXD2KboXuvgN18iaRAoaLAnHfPi61TWqg4A=.e0776ec9-c892-4497-924a-2790bb1a1d9f@github.com>

On Wed, 23 Aug 2023 21:41:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Vyom Tewari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make the isOpen method to package private
>
> src/java.base/share/classes/java/io/FilterOutputStream.java line 210:
> 
>> 208:      */
>> 209:     boolean isOpen(){
>> 210:         return !closed;
> 
> Wouldn't you want `synchronized (closeLock)` here?

'closed' is volatile, we don't need synchronized (closeLock) here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15361#discussion_r1303968655

From shade at openjdk.org  Thu Aug 24 09:14:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Aug 2023 09:14:28 GMT
Subject: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when
 pinned should be replaced
In-Reply-To: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
References: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
Message-ID: <cT0cYQEUrvFJyc7N_uxIVrNmS1tTbes3GjrpCfcuIZo=.c13dc14d-1c77-4e27-ae67-1b6bea540d94@github.com>

On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't correct for cases where System.nanoTimes return a negative value or when parking for durations close to Long.MAX_VALUE (292 years). The change isn't really testable so there aren't any test changes included.

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15405#pullrequestreview-1593141786

From shade at openjdk.org  Thu Aug 24 09:16:27 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Aug 2023 09:16:27 GMT
Subject: RFR: JDK-8314883:
 Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in
 missing case
In-Reply-To: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
References: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
Message-ID: <6oXIpB6tf-tyDTQxcitibGdQGLoPcHD0EjDfASrObEY=.11cb734e-a09e-4b84-8cd5-afde8d5c49d8@github.com>

On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

Looks reasonable.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15402#pullrequestreview-1593144405

From vtewari at openjdk.org  Thu Aug 24 10:02:24 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 24 Aug 2023 10:02:24 GMT
Subject: RFR: JDK-8314883:
 Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in
 missing case
In-Reply-To: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
References: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
Message-ID: <IGVzshYbr-BPwJZUsUL7xQwnjf3brW3LKV4JOvQ8CrI=.85ddd48c-23bf-4472-9be4-d048fb75a501@github.com>

On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15402#pullrequestreview-1593225692

From mbaesken at openjdk.org  Thu Aug 24 10:47:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 10:47:35 GMT
Subject: RFR: JDK-8314883:
 Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in
 missing case
In-Reply-To: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
References: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
Message-ID: <BERL-ghe2lsax85QXsrrGOMNkOKO2I86fO8rkEgbBRA=.561eff20-06d3-4352-8577-57fe58729051@github.com>

On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

Thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15402#issuecomment-1691441396

From mbaesken at openjdk.org  Thu Aug 24 10:47:36 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 10:47:36 GMT
Subject: Integrated: JDK-8314883:
 Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in
 missing case
In-Reply-To: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
References: <pAD9orp2AXPUhCqRbB3lgi1zTRISMGfwjITMG-QYQ1Q=.f2804cd0-1b43-42dd-a6bd-fc8ed57d7840@github.com>
Message-ID: <ej1TAyarQxoFESxPNTKAn9sxpxPKLxU0IZ_BRa8DgQA=.a6d0630c-e8bb-4640-991c-a5cc1b893dd3@github.com>

On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There seems to be a codepath in Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not stored but potentially accessed in the calling Java code.

This pull request has now been integrated.

Changeset: 97b94cb1
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/97b94cb1cdeba00f4bba7326a300c0336950f3ec
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8314883: Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in missing case

Reviewed-by: jpai, shade, vtewari

-------------

PR: https://git.openjdk.org/jdk/pull/15402

From coffeys at openjdk.org  Thu Aug 24 10:54:19 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 24 Aug 2023 10:54:19 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - Improve test coverage
 - Incorporate review comments from Daniel

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15404/files
  - new: https://git.openjdk.org/jdk/pull/15404/files/b7cf2947..976fdb27

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=00-01

  Stats: 168 lines in 4 files changed: 110 ins; 38 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From coffeys at openjdk.org  Thu Aug 24 10:56:28 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 24 Aug 2023 10:56:28 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <UWx9D3yRdnzpW4ITpZF2hMGPe9Uv-OIjKcy_q5g6f0g=.57972717-4b2a-42f2-adc3-6d038a10deca@github.com>

On Wed, 23 Aug 2023 15:41:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Thanks for the feedback @dfuch - good to have decent comments in such code. Good call on using `LazyLoggers.getLogger` in place of `LazyLoggers.getLoggerFromFinder` also. Changes implemented.

the Security.setProperty("test_2", "test") call is made after loading of the LoggerFinder framework should be complete. It's there for a sanity check. I also have Logger class type checks in the test. I've increased coverage in this area with run test in multi-thread/non multi-thread and customer logger finder versus default logger finder mode.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15404#issuecomment-1691455879

From mbaesken at openjdk.org  Thu Aug 24 11:07:24 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 11:07:24 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
Message-ID: <1HDQtIDaBTMmMn2kFrzCJx8Imkbvvbxl6XeqW73Kb58=.5de46e23-874e-4e21-942b-9f0c200db41a@github.com>

On Thu, 10 Aug 2023 09:54:43 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible.

Looks simple and solves our issue.

-------------

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15222#pullrequestreview-1593335232

From kevinw at openjdk.org  Thu Aug 24 11:41:44 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Aug 2023 11:41:44 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table"
Message-ID: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>

Port clashes happening when several tests from test/jdk/sun/tools/jstatd run at the same time on the same machine.

There is logic in here for detecting this, but it's not working.

We recently saw this fail with a port in use, and the failure is:

[Jstatd-Thread] Could not bind //:33859/TestJstatdServer to RMI Registry
[Jstatd-Thread] java.rmi.NoSuchObjectException: no such object in table

In JstatdTest.java, the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
But that is not what we see in this failure.
Should update its test to check for "Could not bind".
Should limit the retries also.

-------------

Commit messages:
 - 8314476: TestJstatdPortAndServer.java failed with "java.rmi.NoSuchObjectException: no such object in table"

Changes: https://git.openjdk.org/jdk/pull/15414/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15414&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314476
  Stats: 9 lines in 1 file changed: 3 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15414/head:pull/15414

PR: https://git.openjdk.org/jdk/pull/15414

From dl at openjdk.org  Thu Aug 24 11:42:57 2023
From: dl at openjdk.org (Doug Lea)
Date: Thu, 24 Aug 2023 11:42:57 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v14]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <0dgHHCBO3HXjv--M4Nule396r9KqZGh_t9_ymnTB08Y=.1f748b8b-8f43-4ca2-b3c2-403203625378@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Ordering for termination triggering

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/61381dbd..9d1b55a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=12-13

  Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From mbaesken at openjdk.org  Thu Aug 24 11:46:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 24 Aug 2023 11:46:25 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
Message-ID: <s88HPEqywtAEwQHhHpfZa1I1Gg2y71K99JY1LxWwoqs=.41dbffc3-2025-4227-98a1-3305efec1ffa@github.com>

On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
> 
> [JShell] Exception in thread "main" java.lang.IllegalStateException: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:313)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool$ReplayableHistory.storeHistory(JShellTool.java:692)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:1008)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.start(JShellToolBuilder.java:261)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider.main(JShellToolProvider.java:120)
> [JShell] Caused by: java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:769)
> [JShell] at java.prefs/java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:864)
> [JShell] at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder$PreferencesStorage.flush(JShellToolBuilder.java:311)
> [JShell] ... 4 more
> 
> The BackingStoreException should be enhanced e.g. by adding the errno/errorCode that is already available in the coding

Btw  printing just the errno - integer code looks not so nice first but on a lot of distros there are already OS tools that convert it for you so it is easy to get the string from the int value.


:~$ apt install moreutils

:~$ errno 11
EAGAIN 11 Resource temporarily unavailable

Having said that ,   I could still  hardwire a couple of  important errnos on Java level like Roger suggested 
> If there are only a couple of errno's that occur for these cases, it might be easier to hardwire the translation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1691522291

From dfuchs at openjdk.org  Thu Aug 24 11:55:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Aug 2023 11:55:26 GMT
Subject: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when
 pinned should be replaced
In-Reply-To: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
References: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
Message-ID: <ooGgZQb37MfLmd_G60Tzg0YKpG5AWhHWfTS1Bx9s07A=.4a7bfc06-d3c4-42d6-9f5c-5f4fc6fa051a@github.com>

On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't correct for cases where System.nanoTimes return a negative value or when parking for durations close to Long.MAX_VALUE (292 years). The change isn't really testable so there aren't any test changes included.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15405#pullrequestreview-1593413969

From dfuchs at openjdk.org  Thu Aug 24 11:58:27 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Aug 2023 11:58:27 GMT
Subject: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when
 pinned should be replaced
In-Reply-To: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
References: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
Message-ID: <HFafGYbjuGWQPxitg98VqjRy4gyexaPepZg2ZmYKj3M=.c2204f5d-3c39-4ff6-95c6-b079cc05e50a@github.com>

On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't correct for cases where System.nanoTimes return a negative value or when parking for durations close to Long.MAX_VALUE (292 years). The change isn't really testable so there aren't any test changes included.

Although... what happens if parkOnCarrierThread is called with a negative value (as that could happen here)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15405#issuecomment-1691537547

From kevinw at openjdk.org  Thu Aug 24 12:20:26 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Aug 2023 12:20:26 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table"
In-Reply-To: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
Message-ID: <_cHCXDWNOpjqu8kj_MlQuF-ORTjPLcaqZBIRv0wF72Q=.4014e949-d930-4dd9-a5cc-8b576ac1ec9e@github.com>

On Thu, 24 Aug 2023 11:34:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Port clashes happening when several tests from test/jdk/sun/tools/jstatd run at the same time on the same machine.
> 
> There is logic in here for detecting this, but it's not working.
> 
> We recently saw this fail with a port in use, and the failure is:
> 
> [Jstatd-Thread] Could not bind //:33859/TestJstatdServer to RMI Registry
> [Jstatd-Thread] java.rmi.NoSuchObjectException: no such object in table
> 
> In JstatdTest.java, the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
> But that is not what we see in this failure.
> Should update its test to check for "Could not bind".
> Should limit the retries also.

"Cannot start jstatd.  No free port found." might be too-specific an error to add here, it could be left as "Cannot start jstatd."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15414#issuecomment-1691568067

From alanb at openjdk.org  Thu Aug 24 12:21:25 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Aug 2023 12:21:25 GMT
Subject: RFR: 8314759: VirtualThread.parkNanos timeout adjustment when
 pinned should be replaced
In-Reply-To: <HFafGYbjuGWQPxitg98VqjRy4gyexaPepZg2ZmYKj3M=.c2204f5d-3c39-4ff6-95c6-b079cc05e50a@github.com>
References: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
 <HFafGYbjuGWQPxitg98VqjRy4gyexaPepZg2ZmYKj3M=.c2204f5d-3c39-4ff6-95c6-b079cc05e50a@github.com>
Message-ID: <kybJkY34sTU0oL-4BCQP8owrb084y9tSBxc9Y3Zn3VQ=.77cd5cee-4f5f-41bf-9c46-55b05d6b8821@github.com>

On Thu, 24 Aug 2023 11:55:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Although... what happens if parkOnCarrierThread is called with a negative value (as that could happen here)?

Not an issue, nothing has changed there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15405#issuecomment-1691569181

From sgehwolf at openjdk.org  Thu Aug 24 13:27:41 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 24 Aug 2023 13:27:41 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes issues
 in GraalVM
Message-ID: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>

Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part of the
JDK's Metrics API. The primary motivating factor is that it allows one to use the
JDK's version of `Metrics` in GraalVM. See the bug for details as to why this is
needed.

Testing:
- [x] GraalVM builds with/without the fix and the reproducer (fails before/works after)
- [x] `jdk/internal/platform` jtreg tests on Linux x86_64 (cgv1).
- [ ] GHA - still running

-------------

Commit messages:
 - 8314940: Use of NIO in JDKs Metrics implementation causes issues in GraalVM

Changes: https://git.openjdk.org/jdk/pull/15416/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314940
  Stats: 29 lines in 1 file changed: 11 ins; 14 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15416/head:pull/15416

PR: https://git.openjdk.org/jdk/pull/15416

From alanb at openjdk.org  Thu Aug 24 13:40:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Aug 2023 13:40:28 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
Message-ID: <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>

On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use the
> JDK's version of `Metrics` in GraalVM. See the bug for details as to why this is
> needed.
> 
> Testing:
> - [x] GraalVM builds with/without the fix and the reproducer (fails before/works after)
> - [x] `jdk/internal/platform` jtreg tests on Linux x86_64 (cgv1).
> - [ ] GHA - still running

Something fishy here, is this working around a bug in GraaVM native image or why does this change need to be in JDK?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1691694592

From aefimov at openjdk.org  Thu Aug 24 13:41:39 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 24 Aug 2023 13:41:39 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v11]
In-Reply-To: <MY3dZoPXYO5wcnb-qPGp7PohEsV5X6BwxrWE9iXu6QU=.02d5a643-f1a9-4246-955b-3331d66f8fe7@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <MY3dZoPXYO5wcnb-qPGp7PohEsV5X6BwxrWE9iXu6QU=.02d5a643-f1a9-4246-955b-3331d66f8fe7@github.com>
Message-ID: <85DVZxwXiURcrY5S1Ov7oxWWbnPY8Qn8cLxc1P4LQrY=.e460254e-82ba-4921-a535-d43979426ee1@github.com>

On Thu, 24 Aug 2023 00:10:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactoring the code according to the comment

The last change reformatted several lines unrelated to this change - I've commented on a few occurrences. Could you please keep only changes related to the scope of this PR?

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 62:

> 60: 
> 61: /**
> 62:   * A thread that creates a connection to an LDAP server.

The formatting changes here is not related to the code changes under review in this PR. Could you please revert them?

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 128:

> 126: 
> 127:     public final String host;  // used by LdapClient for generating exception messages
> 128:     // used by StartTlsResponse when creating an SSL socket

Same - reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 133:

> 131:                          // used by StartTlsResponse when creating an SSL socket
> 132:     public final int port;     // used by LdapClient for generating exception messages
> 133:                          // used by StartTlsResponse when creating an SSL socket

Same - reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 246:

> 244: 
> 245:             CommunicationException ce =
> 246:                 new CommunicationException(host + ":" + port);

Same - reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 254:

> 252:             // Also catches all IO errors generated by socket creation.
> 253:             CommunicationException ce =
> 254:                 new CommunicationException(host + ":" + port);

Same - reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 354:

> 352:     private void initialSSLHandshake(Socket socket, int connectTimeout) throws Exception {
> 353: 
> 354:         if (socket instanceof SSLSocket) {

instanceof pattern matching can be used here:

        if (socket instanceof SSLSocket sslSocket) {

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 387:

> 385: 
> 386:     LdapRequest writeRequest(BerEncoder ber, int msgId,
> 387:         boolean pauseAfterReceipt) throws IOException {

Reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 391:

> 389: 
> 390:     LdapRequest writeRequest(BerEncoder ber, int msgId,
> 391:                              boolean pauseAfterReceipt, int replyQueueCapacity) throws IOException {

Reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 394:

> 392: 
> 393:         LdapRequest req =
> 394:                 new LdapRequest(msgId, pauseAfterReceipt, replyQueueCapacity);

Reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 435:

> 433:             if (sock == null) {
> 434:                 throw new ServiceUnavailableException(host + ":" + port +
> 435:                     "; socket closed");

Reformatting of unrelated code

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 619:

> 617: 
> 618:     /**
> 619:      * @param reqCtls Possibly null request controls that accompanies the

Reformatting of unrelated code

-------------

PR Review: https://git.openjdk.org/jdk/pull/15294#pullrequestreview-1593589706
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304321768
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304322767
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304322965
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304324031
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304324165
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304326820
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304329352
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304330163
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304330374
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304330800
PR Review Comment: https://git.openjdk.org/jdk/pull/15294#discussion_r1304331645

From mdoerr at openjdk.org  Thu Aug 24 14:05:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 24 Aug 2023 14:05:43 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
Message-ID: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>

I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.

Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:

Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/foreign                          88    88     0     0   


Note: This PR should be considered as preparation work for AIX which also uses ABIv1.

-------------

Commit messages:
 - 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API

Changes: https://git.openjdk.org/jdk/pull/15417/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314949
  Stats: 235 lines in 10 files changed: 225 ins; 5 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417

PR: https://git.openjdk.org/jdk/pull/15417

From sgehwolf at openjdk.org  Thu Aug 24 14:42:28 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 24 Aug 2023 14:42:28 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
 <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
Message-ID: <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>

On Thu, 24 Aug 2023 13:37:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Something fishy here, is this working around a bug in GraaVM native image or why does this change need to be in JDK?

I've now realized that the bug had an incorrect statement in the description. The cycle happens due to the `Runtime.getRuntime().maxMemory()` implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code relies on the `Runtime.getRuntime().maxMemory()` API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no?

With that said, it's seems a rather uncontroversial change with very limited scope. Do you see anything problematic in this patch? Happy to revise if you think there are some no-no's :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1691812632

From dfuchs at openjdk.org  Thu Aug 24 14:44:33 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 24 Aug 2023 14:44:33 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v4]
In-Reply-To: <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
Message-ID: <ZxvL8_P6FsUdv2R1fkHsCGmNGfxeKjwyRCwcxapHaBc=.3ff134b3-c8c9-47c0-87d3-8789770cc969@github.com>

On Wed, 23 Aug 2023 20:27:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fix whitespace
>  - move retainClassRef to ClassFrameInfo as a bit set in the flags field
>  - fixup the factory methods

src/java.base/share/classes/java/lang/ClassFrameInfo.java line 32:

> 30: class ClassFrameInfo implements StackFrame {
> 31:     protected Object classOrMemberName;    // Class or ResolvedMemberName initialized by VM
> 32:     protected int flags;

I see only one place where flags is written to and that's at line 35 below. I guess the reason it's not final is that it can be mutated by the VM. Maybe that would deserve a comment here:
 ```suggestion
     protected int flags; // flags can be mutated by the VM to indicate hidden frame

src/java.base/share/classes/java/lang/StackStreamFactory.java line 1083:

> 1081:     private static boolean filterStackWalkImpl(Class<?> c) {
> 1082:         return stackWalkImplClasses.contains(c) ||
> 1083:                 c.getPackageName().equals("java.util.stream");

There is a small semantic difference here and in the change below compared to the original code: the original code would have also included sub-packages, where the new code will not. Since neither `java.util.stream` nor `java.lang.invoke` have sub-package I guess it's of no concern for now.

src/java.base/share/classes/java/lang/StackStreamFactory.java line 1096:

> 1094:                c == Constructor.class ||
> 1095:                MethodAccessor.class.isAssignableFrom(c) ||
> 1096:                ConstructorAccessor.class.isAssignableFrom(c);

I guess LambdaForm have the hidden flag on, which is why there's no need to include them here now?

src/java.base/share/classes/java/lang/StackWalker.java line 333:

> 331:          * {@linkplain StackFrame#getMethodType() method type},
> 332:          * {@linkplain StackFrame#getLineNumber() line number} and
> 333:          * {@linkplain StackFrame#getByteCodeIndex() bytecode index}.

Maybe you should include `getFileName` (and possibly `isNativeMethod`) here?

src/java.base/share/classes/java/lang/StackWalker.java line 338:

> 336:     }
> 337: 
> 338:     enum ExtendedOption {

Should `ExtendedOption` now be renamed into `ExtendedKind`?

test/jdk/java/lang/StackWalker/SanityTest.java line 120:

> 118:                 sw.forEach(StackWalker.StackFrame::isNativeMethod));
> 119:         assertThrows(UnsupportedOperationException.class, () ->
> 120:                 sw.forEach(StackWalker.StackFrame::toStackTraceElement));

Should we check that the exception is thrown by each frame? This code will hit the exception at the first frame and not check the others.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304261309
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304358574
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304362430
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304380080
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304424800
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304440971

From kevinw at openjdk.org  Thu Aug 24 14:57:47 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Aug 2023 14:57:47 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v2]
In-Reply-To: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
Message-ID: <d7mDsKDMthGz3-OA2m1JcT2kX8pHuBaP2MFf6BMz1GQ=.a8ee1e6d-dd3a-409d-ae3e-fc9d591bbd3a@github.com>

> Port clashes happening when several tests from test/jdk/sun/tools/jstatd run at the same time on the same machine.
> 
> There is logic in here for detecting this, but it's not working.
> 
> We recently saw this fail with a port in use, and the failure is:
> 
> [Jstatd-Thread] Could not bind //:33859/TestJstatdServer to RMI Registry
> [Jstatd-Thread] java.rmi.NoSuchObjectException: no such object in table
> 
> In JstatdTest.java, the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
> But that is not what we see in this failure.
> Should update its test to check for "Could not bind".
> Should limit the retries also.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Less specific error message, could be ports or other failure..

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15414/files
  - new: https://git.openjdk.org/jdk/pull/15414/files/f5bdf903..67fd896d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15414&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15414&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15414/head:pull/15414

PR: https://git.openjdk.org/jdk/pull/15414

From ecki at zusammenkunft.net  Thu Aug 24 15:02:07 2023
From: ecki at zusammenkunft.net (Bernd)
Date: Thu, 24 Aug 2023 17:02:07 +0200
Subject: RFR: JDK-8314272: Improve
 java.util.prefs.BackingStoreException: Couldn't get file lock.
In-Reply-To: <s88HPEqywtAEwQHhHpfZa1I1Gg2y71K99JY1LxWwoqs=.41dbffc3-2025-4227-98a1-3305efec1ffa@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>,
 <s88HPEqywtAEwQHhHpfZa1I1Gg2y71K99JY1LxWwoqs=.41dbffc3-2025-4227-98a1-3305efec1ffa@github.com>
Message-ID: <0CE5EE2F-D910-1E45-AE10-3F6A5C9E6327@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230824/b89cd590/attachment-0001.htm>

From sgehwolf at openjdk.org  Thu Aug 24 15:13:40 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 24 Aug 2023 15:13:40 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <VsxMKA-Kwba9WEoVDHaw0U0WD6XHke717bUjdQgnYb0=.7c6698f6-81b1-4cbb-a688-386048f7436a@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic <apejovic at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

https://github.com/openjdk/jdk/pull/15416 alternative PR with a more limited scope.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1691869346

From mchung at openjdk.org  Thu Aug 24 16:39:33 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 24 Aug 2023 16:39:33 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v4]
In-Reply-To: <ZxvL8_P6FsUdv2R1fkHsCGmNGfxeKjwyRCwcxapHaBc=.3ff134b3-c8c9-47c0-87d3-8789770cc969@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
 <ZxvL8_P6FsUdv2R1fkHsCGmNGfxeKjwyRCwcxapHaBc=.3ff134b3-c8c9-47c0-87d3-8789770cc969@github.com>
Message-ID: <kToQWKLpVlFgHg_pn-eJzckoZowy7OsiTLQehWSdt8s=.0a54d864-8dbc-432c-bca2-7a72f0492c3f@github.com>

On Thu, 24 Aug 2023 13:47:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - fix whitespace
>>  - move retainClassRef to ClassFrameInfo as a bit set in the flags field
>>  - fixup the factory methods
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 1083:
> 
>> 1081:     private static boolean filterStackWalkImpl(Class<?> c) {
>> 1082:         return stackWalkImplClasses.contains(c) ||
>> 1083:                 c.getPackageName().equals("java.util.stream");
> 
> There is a small semantic difference here and in the change below compared to the original code: the original code would have also included sub-packages, where the new code will not. Since neither `java.util.stream` nor `java.lang.invoke` have sub-package I guess it's of no concern for now.

Right, that's the reason for this change.  Subpackages if added in the future may not need to be filtered as it may not the implementation of streams and method handles.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304599669

From mchung at openjdk.org  Thu Aug 24 16:45:28 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 24 Aug 2023 16:45:28 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v4]
In-Reply-To: <ZxvL8_P6FsUdv2R1fkHsCGmNGfxeKjwyRCwcxapHaBc=.3ff134b3-c8c9-47c0-87d3-8789770cc969@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <uxANZ2Mzycug4NROOCiFnwHfZok5j0rPHzOfLsjTK1w=.754c2a64-b511-4354-9297-598c35fb7f5f@github.com>
 <ZxvL8_P6FsUdv2R1fkHsCGmNGfxeKjwyRCwcxapHaBc=.3ff134b3-c8c9-47c0-87d3-8789770cc969@github.com>
Message-ID: <MohzGHtjMsm856ar7AGS8og_OYKJLrcCjsMYbS2l7Os=.48d2fe1c-1497-4a46-9539-46f402976c2f@github.com>

On Thu, 24 Aug 2023 13:49:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - fix whitespace
>>  - move retainClassRef to ClassFrameInfo as a bit set in the flags field
>>  - fixup the factory methods
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 1096:
> 
>> 1094:                c == Constructor.class ||
>> 1095:                MethodAccessor.class.isAssignableFrom(c) ||
>> 1096:                ConstructorAccessor.class.isAssignableFrom(c);
> 
> I guess LambdaForm have the hidden flag on, which is why there's no need to include them here now?

`LambdaForm` are method handle frames which are filtered by `isMethodHandleFrame`

> test/jdk/java/lang/StackWalker/SanityTest.java line 120:
> 
>> 118:                 sw.forEach(StackWalker.StackFrame::isNativeMethod));
>> 119:         assertThrows(UnsupportedOperationException.class, () ->
>> 120:                 sw.forEach(StackWalker.StackFrame::toStackTraceElement));
> 
> Should we check that the exception is thrown by each frame? This code will hit the exception at the first frame and not check the others.

I think not necessary since the walker returns the `ClassFrameInfo` for all frames.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304603999
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304606664

From alanb at openjdk.org  Thu Aug 24 16:54:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Aug 2023 16:54:36 GMT
Subject: Integrated: 8314759: VirtualThread.parkNanos timeout adjustment when
 pinned should be replaced
In-Reply-To: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
References: <j_MLs2hARWPGJe2sYdsR5unCiLE7O_VkiRk9t33AL_A=.eabc83e5-85be-483f-86e0-f1192beede01@github.com>
Message-ID: <jwuJUk8P0R9ydoZN5CMNf1WXxDJHP_UU2c7wtMGwcZw=.fb4855a0-4653-473b-8c2c-16e7d187a472@github.com>

On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If yielding fails due to the pinning then VirtualThread.parkNanos parks on the carrier thread with the remaining time. The calculation of the remaining time needs to be replaced so that it obviously uses the difference between the start and end time in the calculation. The current code isn't correct for cases where System.nanoTimes return a negative value or when parking for durations close to Long.MAX_VALUE (292 years). The change isn't really testable so there aren't any test changes included.

This pull request has now been integrated.

Changeset: d9fc6b69
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9fc6b6933ad733d1b2a4d2bd91ecb3824970ea8
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced

Reviewed-by: aturbanov, shade, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/15405

From erikj at openjdk.org  Thu Aug 24 17:36:46 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 24 Aug 2023 17:36:46 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v2]
In-Reply-To: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
Message-ID: <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>

> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Suggestion from dholmes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15346/files
  - new: https://git.openjdk.org/jdk/pull/15346/files/64bce083..a53cf2f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15346&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15346&range=00-01

  Stats: 13 lines in 1 file changed: 8 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15346/head:pull/15346

PR: https://git.openjdk.org/jdk/pull/15346

From erikj at openjdk.org  Thu Aug 24 17:40:28 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 24 Aug 2023 17:40:28 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v2]
In-Reply-To: <qah2V3ZevJZm02mUrFlO2W7Nj_kyxP4QflaIkESU00Q=.1dda0ee8-e756-44e4-8df2-5c27ab88bbdc@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
 <qah2V3ZevJZm02mUrFlO2W7Nj_kyxP4QflaIkESU00Q=.1dda0ee8-e756-44e4-8df2-5c27ab88bbdc@github.com>
Message-ID: <yD15ECSO7xtUrQQu4NygWeCOwLtKm22F0bbXwKMH6aQ=.c7610651-1ff5-42ad-97f3-8afff2102fba@github.com>

On Thu, 24 Aug 2023 04:46:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggestion from dholmes
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 62:
> 
>> 60:                     StandardCharsets.UTF_8);
>> 61:             i++;
>> 62:         } else if (args.length != 3) {
> 
> This is not very robust for detecting malformed invocations. It won't even detect a simple typo in the argument name. I would suggest something more elaborate e.g.
> 
> int i  0;
> boolean valid = true;
> if (args.length != 5 && args.length !=3) {
>   valid = false;
> } else if (args.length == 5) {
>   if ( ! "-jdk-header-template".equals(args[i])) {
>     valid = false;
>   } else {
>     jdkHeaderTemplate = new String(Files.readAllBytes(Paths.get(args[++i])),
>                     StandardCharsets.UTF_8);
>      i++;
>   }
> }
> if (!valid) {
>   System.err.println(...);
>    System.exit(1);
> }
> String lsrFile = args[i++];
> ...

I think it actually will, but your suggestion is clearer to read, so I have applied it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15346#discussion_r1304664443

From iris at openjdk.org  Thu Aug 24 17:47:26 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 24 Aug 2023 17:47:26 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v2]
In-Reply-To: <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
 <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
Message-ID: <LVKW1ETCUr1ZM3Ks2dl4s5JQFGdkJeT-XAq8NtN1MuQ=.e6880dc6-b2d2-4325-b680-0597b6b6fa02@github.com>

On Thu, 24 Aug 2023 17:36:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion from dholmes

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15346#pullrequestreview-1594143141

From msheppar at openjdk.org  Thu Aug 24 18:11:31 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 24 Aug 2023 18:11:31 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v2]
In-Reply-To: <d7mDsKDMthGz3-OA2m1JcT2kX8pHuBaP2MFf6BMz1GQ=.a8ee1e6d-dd3a-409d-ae3e-fc9d591bbd3a@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
 <d7mDsKDMthGz3-OA2m1JcT2kX8pHuBaP2MFf6BMz1GQ=.a8ee1e6d-dd3a-409d-ae3e-fc9d591bbd3a@github.com>
Message-ID: <05Iaw2JWs3CZ14wa8CCyi6kAeInPUvLHYv7Q3Jp_F58=.fe01303f-99f0-4989-b917-2f75a135bbd2@github.com>

On Thu, 24 Aug 2023 14:57:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>> 
>> Port clashes when run at the same time on the same machine have been a problem.
>> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
>> Either way, jstatd fails to startup and and the test fails.
>> 
>> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
>> 
>> Should update its test to check for "Could not bind".
>> Should limit the retries also.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Less specific error message, could be ports or other failure..

test/jdk/sun/tools/jstatd/JstatdTest.java line 327:

> 325:         int tries = 0;
> 326:         try {
> 327:             while (jstatdThread == null && ++tries <= 10) {

maybe use a ubiquitous constant MAX_RETRY (private static final in MAX_RETRY = 10)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15414#discussion_r1304694460

From javalists at cbfiddle.com  Thu Aug 24 18:11:33 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 24 Aug 2023 11:11:33 -0700
Subject: RFR: 8308042: [macos] Developer ID Application Certificate not
 picked up by jpackage if it contains UNICODE characters
In-Reply-To: <9E1881C8-5B84-4FC7-98D0-F4628AE0077C@oracle.com>
References: <LPACoJ0P-sdlZ2lN5vSkNjpD7XeNVedcWdI6D-l9Tj4=.ebea9cc6-26be-43f0-944f-d1a19205f424@github.com>
 <98A07DBE-FA6D-422C-8829-FECD6F3A5012@cbfiddle.com>
 <47D4AEA8-E3C7-43B2-B55B-E7E61352639A@oracle.com>
 <8AD4DB63-E82E-464B-AB13-76594EE7ED29@cbfiddle.com>
 <9E1881C8-5B84-4FC7-98D0-F4628AE0077C@oracle.com>
Message-ID: <9BABE3D8-8A54-4EBD-B037-6D33289C5DF2@cbfiddle.com>

Hi Alex,

Yes, I understand that this issue is about fixing a bug in the current approach.

Although it is a moot point, my opinion is that the current approach is ill-conceived and should be scrapped,
so improving it is a wasted effort.

The problems with the current approach:

1. An attempt is made to emulate the behavior of codesign for the purpose of predicting when it will fail.

The problem here is that if the emulation is not perfect, it can cause the packaging operation to abort needlessly.
This is basically a lost cause. You?ll never know when you have discovered the last bug.
In my opinion, the value of predicting when codesign will fail is very small, not even close to justifying
the risk of incorrectly aborting the packaging process.

If you are determined to try to predict when codesign will fail, it seems to me that a better approach is
to run codesign on a test file. But I still think it would be a mistake.

2. An attempt is made to enforce Apple?s policies and naming conventions.

There are two problems with this attempt. One is that Apple can change its policies and naming
conventions at any time, so you are signing up for maintaining consistency for an indefinite period of time,
and when they do make a change, there will necessarily be a delay before an updated jpackage
can be released.

The other problem is that you are assuming how the packaged application is going to be used.
As a developer using jpackage, I should be able to sign the application using any certificate that I choose.
I can see that you are trying to be helpful by finding the ?right? certificate, but jpackage should not
block my ability to choose a specific certificate.

A bit of design philosophy: As far as I know, the issues faced by Java application developers regarding
the creation and selection of signing certificates are no different than the issues faced by other
Apple application developers. So it is not clear to me why jpackage should get involved in these
issues. Developers need to understand how to create and use certificates for applications distributed
using the two approaches recommended by Apple, and for that they need to read the Apple
documentation.

The focus of jpackage should be on JDK related issues. For code signing, that means identifying
the JDK files that need to be signed and the correct order of signing.

  Alan


> On Aug 23, 2023, at 4:14 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Alan,
> 
>> On Aug 22, 2023, at 7:40 PM, Alan Snyder <javalists at cbfiddle.com <mailto:javalists at cbfiddle.com>> wrote:
>> 
>> 
>> 
>>> On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com <mailto:alexander.matveev at oracle.com>> wrote:
>>> 
>>> Hi Alan,
>>> 
>>>> On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com <mailto:javalists at cbfiddle.com>> wrote:
>>>> 
>>>> I?m confused by this.
>>>> 
>>>> The issue is marked as macOS, but on macOS you don?t need to ?find? the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.
>>> 
>>> This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.
>>> 
>> 
>> The problem with this solution is that it introduces bugs. This bug and JDK-8311877 both result from jpackage trying to perform its own certificate search instead of letting codesign do the search.
>> 
>> The claimed advantage of failing ?faster" is negligible (it is a small difference and only happens when the user has made a mistake) and not worth the (proven) risk of introducing bugs.
>> 
>> If you think you can do a better job of diagnosing the failure to find a certificate than codesign, then you should post-process the failure of codesign. But I don?t see this as a worthwhile investment.
> 
> JDK-8308042 is about fixing bug in current approach used by jpackage. You suggestion is to passthrough value from ?--mac-signing-key-user-name? to codesign and use it as value for "--sign? argument in codesign will change behavior of ?--mac-signing-key-user-name? and I do not think that we should be doing this as part of this bug fix.
> 
> From documentation:
> https://docs.oracle.com/en/java/javase/20/jpackage/support-application-features.html#GUID-8D9F0607-91F4-4070-8823-02FCAB12238D
> 
> If you want to distribute your application outside the Mac App Store, then you'll need the certificates "Developer ID Application: <user or team name>" and "Developer ID Installer: <user or team name>".
> 
> If you want to deploy your application through the Mac App Store, then you'll need the certificates "3rd Party Mac Developer Application: <user or team name>" and "3rd Party Mac Developer Installer: <user or team name>?.
> 
> If --mac-app-store is set we will look for "3rd Party Mac Developer Application: <user or team name>? and if we cannot find it we will fallback to "Developer ID Application: <user or team name>? and if it is not found we will fail. If --mac-app-store is not set we will look for "Developer ID Application: <user or team name>?. <user or team name> is value provided via ?--mac-signing-key-user-name?.
> 
> I think you suggestion is to add additional argument to jpackage which will be used as passthrough value for "--sign? argument in codesign. I am still not sure if we should be doing this, but I am currently considering it as a solution for https://bugs.openjdk.org/browse/JDK-8311877 instead of adding "Apple Development? as fallback if we cannot find "Developer ID Application?.
> 
> Thanks,
> Alexander
> 
>> 
>> 
>>> Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message. 
>>> 
>>>> 
>>>> Surely codesign can handle certificates with unicode names, can?t it?
>>> 
>>> Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.
>>> 
>> 
>> Exactly my point. By doing your own certificate validation you risk doing it wrong.
>> 
>> 
>>> Thanks,
>>> Alexander
>>> 
>>>> 
>>>>> On Aug 22, 2023, at 3:15 PM, Alexander Matveev <almatvee at openjdk.org <mailto:almatvee at openjdk.org>> wrote:
>>>>> 
>>>>> - Added support for certificates with UNICODE characters.
>>>>> - Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
>>>>> - New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
>>>>> - Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.
>>>>> 
>>>>> -------------
>>>>> 
>>>>> Commit messages:
>>>>> - 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters
>>>>> 
>>>>> Changes: https://git.openjdk.org/jdk/pull/15394/files
>>>>> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
>>>>> Issue: https://bugs.openjdk.org/browse/JDK-8308042
>>>>> Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
>>>>> Patch: https://git.openjdk.org/jdk/pull/15394.diff
>>>>> Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394
>>>>> 
>>>>> PR: https://git.openjdk.org/jdk/pull/15394
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230824/eea5c8db/attachment.htm>

From msheppar at openjdk.org  Thu Aug 24 18:15:28 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 24 Aug 2023 18:15:28 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v2]
In-Reply-To: <d7mDsKDMthGz3-OA2m1JcT2kX8pHuBaP2MFf6BMz1GQ=.a8ee1e6d-dd3a-409d-ae3e-fc9d591bbd3a@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
 <d7mDsKDMthGz3-OA2m1JcT2kX8pHuBaP2MFf6BMz1GQ=.a8ee1e6d-dd3a-409d-ae3e-fc9d591bbd3a@github.com>
Message-ID: <EkbGX5xDS2HHp8mplLqfhXN2lvbOHxYUSt0c6mFs2f8=.e91b37a0-2efc-44f8-b10e-61f856eb33c8@github.com>

On Thu, 24 Aug 2023 14:57:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>> 
>> Port clashes when run at the same time on the same machine have been a problem.
>> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
>> Either way, jstatd fails to startup and and the test fails.
>> 
>> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
>> 
>> Should update its test to check for "Could not bind".
>> Should limit the retries also.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Less specific error message, could be ports or other failure..

Observations from other "rmi" test scenarios suggest there might be some issue in the Registry, requiring some "deep dive" analysis. In any case, for the jstatd test, checking for a "name binding condition" and executing a retry seems reasonable

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15414#issuecomment-1692189768

From bpb at openjdk.org  Thu Aug 24 18:30:16 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 24 Aug 2023 18:30:16 GMT
Subject: Integrated: 8219567: Name of first parameter of
 RandomAccessFile(String,String) is inconsistent
In-Reply-To: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
References: <aYmiFTFs8RpK7x0K5ect85sg1CPggmmPIs3ykkajUtc=.18cae900-dc9b-4c07-ba21-8049ea7e274c@github.com>
Message-ID: <aQUwNQDVw8-KdpesB4yWKkahHy4GAyNP02Larcl3PXo=.8f0f6c72-fb2d-474f-82cf-83c61b2e0e6a@github.com>

On Fri, 18 Aug 2023 23:14:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revise some verbiage about the `RandomAccessFile(String,String)` constructor so that the string name of a file is referred to as _pathname string_ for consistency with `java.io.File`.

This pull request has now been integrated.

Changeset: 2624324a
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2624324ac216aadc938a870075f6fad287fedf05
Stats:     15 lines in 1 file changed: 0 ins; 0 del; 15 mod

8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent

Reviewed-by: jlu, vtewari, rriggs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/15351

From mchung at openjdk.org  Thu Aug 24 18:44:14 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 24 Aug 2023 18:44:14 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
> instead and such stack walker will save the overhead (1) to extract the method information
> and (2) the memory used for the stack walking.   In addition, this can also fix
> 
> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
> 
> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
> This provides a simple way for existing code, for example logging frameworks, to take advantage of
> this enhancement with the least change as it can keep the existing function for traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(interestingClasses::contains)
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> #### Alternatives Considered
> One alternative is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
> it only needs a small change in calling `getInstance` method to request class only info...

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  review feedback and javadoc clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15370/files
  - new: https://git.openjdk.org/jdk/pull/15370/files/30984253..a3a44575

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=03-04

  Stats: 52 lines in 2 files changed: 11 ins; 7 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From duke at openjdk.org  Thu Aug 24 18:45:01 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 24 Aug 2023 18:45:01 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v12]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <ojN5Ny3bup8_qz5dogZpDmCJS9eQ5xCyEthMckGv-jo=.189a231c-2e96-4653-bbb2-5bc1179e8e2c@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the code according to code review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/cdb70069..be3bd44f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=10-11

  Stats: 106 lines in 2 files changed: 30 ins; 22 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Thu Aug 24 19:42:24 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 24 Aug 2023 19:42:24 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v12]
In-Reply-To: <ojN5Ny3bup8_qz5dogZpDmCJS9eQ5xCyEthMckGv-jo=.189a231c-2e96-4653-bbb2-5bc1179e8e2c@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <ojN5Ny3bup8_qz5dogZpDmCJS9eQ5xCyEthMckGv-jo=.189a231c-2e96-4653-bbb2-5bc1179e8e2c@github.com>
Message-ID: <blNrTYMC6eC9IG3Ry_Cmy0GODhTJiMYYU8JDuJPo8dw=.34f4996d-1bf4-489f-85df-bebe893f2282@github.com>

On Thu, 24 Aug 2023 18:45:01 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the code according to code review

1) Add server sleeping time through the command line
2) Move out instanceof pattern out of the defined method
3)Extra testings were done.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15294#issuecomment-1692301763

From asemenyuk at openjdk.org  Thu Aug 24 20:05:39 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 24 Aug 2023 20:05:39 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are not
 pointers
In-Reply-To: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
Message-ID: <T6swRa6J2th6vcce4dqMSsW7F97FR1Tikl-rbvLNVxY=.c73a7408-f56f-4374-9f46-dfeddbc0adfa@github.com>

On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
>         with
>         [
>             _Other=nullptr
>         ]
>         and
>         [
>             _Ty=unsigned long
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
>         with
>         [
>             _Ty=unsigned long,
>             _Ty2=unsigned long,
>             _Other=nullptr
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????
> 
> 
> `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
> I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

> I'm wondering how MSVC is compiling without the header

For older MSVC it picks unique_ptr from 
https://github.com/openjdk/jdk/blob/2624324ac216aadc938a870075f6fad287fedf05/src/jdk.jpackage/share/native/common/kludge_c%2B%2B11.h

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2858#issuecomment-1692331015

From duke at openjdk.org  Thu Aug 24 20:48:01 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 24 Aug 2023 20:48:01 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v13]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <gYGCNw9IEECG_Hr6YspZqivlKLcYAcCFZtHz0IWg_80=.8245653c-f14c-4cdb-8f65-92bbe80213f4@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  format the code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/be3bd44f..71bca08c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=11-12

  Stats: 94 lines in 1 file changed: 1 ins; 1 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From kevinw at openjdk.org  Thu Aug 24 21:38:41 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Aug 2023 21:38:41 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v3]
In-Reply-To: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
Message-ID: <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>

> Several tests from test/jdk/sun/tools/jstatd are intermittent.
> 
> Port clashes when run at the same time on the same machine have been a problem.
> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
> Either way, jstatd fails to startup and and the test fails.
> 
> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
> 
> Should update its test to check for "Could not bind".
> Should limit the retries also.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  Modernisation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15414/files
  - new: https://git.openjdk.org/jdk/pull/15414/files/67fd896d..35199a6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15414&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15414&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15414/head:pull/15414

PR: https://git.openjdk.org/jdk/pull/15414

From kevinw at openjdk.org  Thu Aug 24 21:38:42 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Aug 2023 21:38:42 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v2]
In-Reply-To: <05Iaw2JWs3CZ14wa8CCyi6kAeInPUvLHYv7Q3Jp_F58=.fe01303f-99f0-4989-b917-2f75a135bbd2@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
 <d7mDsKDMthGz3-OA2m1JcT2kX8pHuBaP2MFf6BMz1GQ=.a8ee1e6d-dd3a-409d-ae3e-fc9d591bbd3a@github.com>
 <05Iaw2JWs3CZ14wa8CCyi6kAeInPUvLHYv7Q3Jp_F58=.fe01303f-99f0-4989-b917-2f75a135bbd2@github.com>
Message-ID: <tOUWkKLydbaYCdcRqGzHdZ1WQ6oUpoms8LMNdKxwMjo=.84cbf46b-dc6a-409f-abb8-86fbd2b7a152@github.com>

On Thu, 24 Aug 2023 18:08:13 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Less specific error message, could be ports or other failure..
>
> test/jdk/sun/tools/jstatd/JstatdTest.java line 327:
> 
>> 325:         int tries = 0;
>> 326:         try {
>> 327:             while (jstatdThread == null && ++tries <= 10) {
> 
> maybe use a ubiquitous constant MAX_RETRY (private static final in MAX_RETRY = 10)

Yes, agreed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15414#discussion_r1304892510

From jlu at openjdk.org  Thu Aug 24 21:48:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 24 Aug 2023 21:48:24 GMT
Subject: RFR: 6333341: [BI] Doc: java.text.BreakIterator class specification is
 unclear
Message-ID: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>

Please review this PR and [CSR ](https://bugs.openjdk.org/browse/JDK-8314974)which clarifies behavior for BreakIterator instances when text has not been set.

For example,  calling `BreakIterator.getWordInstance().next();` has an ambiguous result.
A boundary searching operation was called but no text was supplied. Is the result an exception, 0, -1 (BreakIterator.DONE), or something else? In reality, the operation will be performed on any empty string.


This change makes it apparent that failing to set the text will cause the BreakIterator instance to default to a `StringCharacterIterator` with an empty string (equivalent to calling setText("")).

-------------

Commit messages:
 - Use setText() instead
 - Clarify wording
 - Init

Changes: https://git.openjdk.org/jdk/pull/15422/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15422&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6333341
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15422/head:pull/15422

PR: https://git.openjdk.org/jdk/pull/15422

From msheppar at openjdk.org  Thu Aug 24 21:55:19 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 24 Aug 2023 21:55:19 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v13]
In-Reply-To: <gYGCNw9IEECG_Hr6YspZqivlKLcYAcCFZtHz0IWg_80=.8245653c-f14c-4cdb-8f65-92bbe80213f4@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <gYGCNw9IEECG_Hr6YspZqivlKLcYAcCFZtHz0IWg_80=.8245653c-f14c-4cdb-8f65-92bbe80213f4@github.com>
Message-ID: <CjHjQm10FkwTPsSIsrPvhp9xSbMbuMwjZMSgDhn2OW0=.0a103c69-ab88-4e5e-85ad-6f1368fead82@github.com>

On Thu, 24 Aug 2023 20:48:01 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format the code

Marked as reviewed by msheppar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15294#pullrequestreview-1594517760

From msheppar at openjdk.org  Thu Aug 24 21:56:14 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 24 Aug 2023 21:56:14 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v3]
In-Reply-To: <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
 <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>
Message-ID: <cahp8QjrNcciOURzK0Iyj_wyoRKBustooTN5sKpAsV0=.89cdb0cd-520a-468c-84bf-0cb23a3cc74b@github.com>

On Thu, 24 Aug 2023 21:38:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>> 
>> Port clashes when run at the same time on the same machine have been a problem.
>> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
>> Either way, jstatd fails to startup and and the test fails.
>> 
>> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
>> 
>> Should update its test to check for "Could not bind".
>> Should limit the retries also.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modernisation

Marked as reviewed by msheppar (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15414#pullrequestreview-1594519549

From duke at openjdk.org  Thu Aug 24 22:06:50 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Thu, 24 Aug 2023 22:06:50 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v5]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <qmE9tYCUYrGUAOZwEgF6-s2K6Nxf6Fswks1TgxRmn6o=.391e8c2b-5821-4b7e-a896-014ff8e9aafc@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:

  8314236: add more tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/3ea1c1a7..aba42b5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=03-04

  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From mchung at openjdk.org  Thu Aug 24 22:07:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 24 Aug 2023 22:07:12 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
Message-ID: <fo_8O8wm8XlBVyv_TXz_Fn_Prh3lwFXXf1Z5zra34KM=.45620058-b912-488c-9fe5-7556811dc53f@github.com>

On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and javadoc clean up

> StackWalkers would be configured along two different axes (Kind and Options). 

This is intentional.   `Kind` is not the best name but it describes what information a stack walker collects from each stack frame.  

> It changes the mental model, in that all StackWalkers would now be divided into two Kinds. I feel like this bleeds the implementation into the API a bit.

Although this RFE is motivated by an optimized way to walk the stack, each method has a declaring class.

In the current implementation, it has an internal way to collect the live locals and operands on the stack (`LOCALS_AND_OPERANDS`).   That fits into the third type to be collected from each frame.   If that were supported, it would belong to the new enum type. 

> The existing Option enum already provides a way to configure which frames are walked, and what information to include in those frames. I think adding a new Option value fits better.
> 
> It's true that compatibility dictates that the default behavior be to include method info, so the new option must omit method info. If the NO_METHOD_INFO is disliked, perhaps a better name can be found - SKIP_METHOD_INFO or OMIT_METHOD_INFO?

In fact it's not so much constrained by the default behavior.  I wasn't completely happy with adding `NO_METHOD_INFO` to the options but could live with it.   When I reconsidered, I like separating this from `Option` as it specifies what information to be collected from each frame whereas `Option` controls everything else such as what frames to be filtered for better categorization.

I updated the javadoc.  Maybe it helps?

https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1692474762

From duke at openjdk.org  Thu Aug 24 22:21:42 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Thu, 24 Aug 2023 22:21:42 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v6]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <yiKJTEY9MnQ76tidx09uhlvgrAkf_9odUFyJ1-ClURA=.8bcfbb2c-3961-4d9f-b531-060076158303@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:

  8314236: add more tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/aba42b5f..69672701

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From bchristi at openjdk.org  Thu Aug 24 22:24:13 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 24 Aug 2023 22:24:13 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
Message-ID: <y0gEMpbBPdmP8fbm5v9YbNBrslcAT-NgETmAkcVkRbQ=.42f322ca-d729-4a70-b99f-a2d1477b44df@github.com>

On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and javadoc clean up

src/java.base/share/classes/java/lang/StackWalker.java line 47:

> 45:  * from the stack frames by default.  If the method information is not needed,
> 46:  * a {@code StackWalker} collecting {@linkplain Kind#CLASS_INFO class only information}
> 47:  * can be used instead via the {@link #getInstance(Kind, Option...)} method.

The description of `Kind` should come after the basics of what StackWalker does:

 * <p> The {@link StackWalker#walk walk} method opens a sequential stream
 * of {@link StackFrame StackFrame}s for the current thread and then applies
 * the given function to walk the {@code StackFrame} stream.


It should be clarified that `METHOD_INFO` returns method information _as well as_ class information.

Overall I would still prefer adding an `Option.OMIT_METHOD_INFO` over a new `Kind` enum.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1304929416

From duke at openjdk.org  Thu Aug 24 23:08:43 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Thu, 24 Aug 2023 23:08:43 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v14]
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <poCcoILL2XADwz8lJg59A2aAvcqo6TEWgXv64jI46EE=.2c5f0b7b-c71e-407c-aa5f-c407d7687acc@github.com>

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  update the code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15294/files
  - new: https://git.openjdk.org/jdk/pull/15294/files/71bca08c..f03bb797

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15294&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15294.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15294/head:pull/15294

PR: https://git.openjdk.org/jdk/pull/15294

From bchristi at openjdk.org  Thu Aug 24 23:26:11 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 24 Aug 2023 23:26:11 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <fo_8O8wm8XlBVyv_TXz_Fn_Prh3lwFXXf1Z5zra34KM=.45620058-b912-488c-9fe5-7556811dc53f@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
 <fo_8O8wm8XlBVyv_TXz_Fn_Prh3lwFXXf1Z5zra34KM=.45620058-b912-488c-9fe5-7556811dc53f@github.com>
Message-ID: <yfU7eTg6XIIoqGzTOGOFmj0gC14Xz_tDbnqwy5vj_xI=.4e1488f0-f4cf-498f-b6e2-ac0646c3fdf3@github.com>

On Thu, 24 Aug 2023 22:03:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I like separating this from `Option` as it specifies what information to be collected from each frame whereas `Option` controls everything else such as what frames to be filtered

In my mind, `Option` _already_ can control what information is to be collected:
`RETAIN_CLASS_REFERENCE`

as well as what frames to filter:
`SHOW_HIDDEN_FRAMES`
`SHOW_REFLECT_FRAMES`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1692537575

From mcimadamore at openjdk.org  Thu Aug 24 23:36:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Aug 2023 23:36:10 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
Message-ID: <4zrTfeu8tY86-yVJXBoqQ-gsWxGvdogZLTxfScBR7wU=.4f27a1f5-8334-497b-8a7d-756c95ad33ea@github.com>

On Thu, 24 Aug 2023 13:56:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
> 
> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/foreign                          88    88     0     0   
> 
> 
> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/ABIv1CallArranger.java line 33:

> 31:  * PPC64 CallArranger specialized for ABI v1.
> 32:  */
> 33: public class ABIv1CallArranger extends CallArranger {

Wouldn't it be more natural for CallArranger to have an abstract method (or even a kind() accessor for the different kinds of ABI supported) and then have these specialized subclasses return the correct kind? It seems to me that setting the `useXYZAbi` flag using an instanceof test is a little dirty.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304966196

From mcimadamore at openjdk.org  Thu Aug 24 23:41:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Aug 2023 23:41:10 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
Message-ID: <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>

On Thu, 24 Aug 2023 13:56:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
> 
> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/foreign                          88    88     0     0   
> 
> 
> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.

Overall these changes look good - as commented I'd like to learn a bit more of the underlying ABI, to get a sense of whether adding a new binding is ok. But overall it's great to see support for a big-endian ABI - apart from the linker, I am pleased to see that you did not encounter too many issues in the memory-side of the FFM API.

src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695:

> 693:      *   Negative [shiftAmount] shifts right and converts to int if needed.
> 694:      */
> 695:     record ShiftLeft(int shiftAmount, Class<?> type) implements Binding {

Given the situation you are facing, perhaps adding the new binding here is unavoidable. Let's wait to hear from @JornVernee. In the meantime, can you point me to a document which explains this behavior? I'm curious and I'd like to know more :-)

-------------

PR Review: https://git.openjdk.org/jdk/pull/15417#pullrequestreview-1594603192
PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304967438

From mcimadamore at openjdk.org  Thu Aug 24 23:58:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 24 Aug 2023 23:58:08 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
Message-ID: <kMh2eH6HfkAhSNFkKD35MqhEZyvE2ZWdH8N_mOReKzc=.a5c26ca0-8676-47f0-be26-989975c6ef6c@github.com>

On Thu, 24 Aug 2023 23:36:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
>> 
>> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/foreign                          88    88     0     0   
>> 
>> 
>> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695:
> 
>> 693:      *   Negative [shiftAmount] shifts right and converts to int if needed.
>> 694:      */
>> 695:     record ShiftLeft(int shiftAmount, Class<?> type) implements Binding {
> 
> Given the situation you are facing, perhaps adding the new binding here is unavoidable. Let's wait to hear from @JornVernee. In the meantime, can you point me to a document which explains this behavior? I'm curious and I'd like to know more :-)

Maybe I'm starting to see it - it's not a special rule, as much as it is a consequence of the endianness. E.g. if you have a struct that is 64 + 32 bytes, you can store the first 64 bytes as a long. Then, there's an issue as we have to fill another long, but we have only 32 bits of value. Is it the problem that if we just copy the value into the long word "as is" it will be stored in the "wrong" 32 bits? So the shift takes care of that, I guess?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304981242

From mcimadamore at openjdk.org  Fri Aug 25 00:01:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Aug 2023 00:01:10 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <kMh2eH6HfkAhSNFkKD35MqhEZyvE2ZWdH8N_mOReKzc=.a5c26ca0-8676-47f0-be26-989975c6ef6c@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
 <kMh2eH6HfkAhSNFkKD35MqhEZyvE2ZWdH8N_mOReKzc=.a5c26ca0-8676-47f0-be26-989975c6ef6c@github.com>
Message-ID: <gH6S2fsCi4kZPhOZSpCZrMRZQUQQF2Mei1o59HZTeqI=.032acbb2-f242-4f6c-b3d7-246b2e231096@github.com>

On Thu, 24 Aug 2023 23:55:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 695:
>> 
>>> 693:      *   Negative [shiftAmount] shifts right and converts to int if needed.
>>> 694:      */
>>> 695:     record ShiftLeft(int shiftAmount, Class<?> type) implements Binding {
>> 
>> Given the situation you are facing, perhaps adding the new binding here is unavoidable. Let's wait to hear from @JornVernee. In the meantime, can you point me to a document which explains this behavior? I'm curious and I'd like to know more :-)
>
> Maybe I'm starting to see it - it's not a special rule, as much as it is a consequence of the endianness. E.g. if you have a struct that is 64 + 32 bytes, you can store the first 64 bytes as a long. Then, there's an issue as we have to fill another long, but we have only 32 bits of value. Is it the problem that if we just copy the value into the long word "as is" it will be stored in the "wrong" 32 bits? So the shift takes care of that, I guess?

If my assumption above is correct, then maybe another way to solve the problem, would be to, instead of adding a new shift binding, to generalize the VM store binding we have to allow writing a smaller value into a bigger storage, with an offset. Correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304982593

From mcimadamore at openjdk.org  Fri Aug 25 00:13:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Aug 2023 00:13:09 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
Message-ID: <aIoYGs3Y5CqhchCtkjVlQnwn9HhXemEp1Dpzx56mlmk=.adba1add-b871-4657-b5fb-1bccff6a4b44@github.com>

On Thu, 24 Aug 2023 13:56:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
> 
> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/foreign                          88    88     0     0   
> 
> 
> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.

src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 717:

> 715:         public void interpret(Deque<Object> stack, StoreFunc storeFunc,
> 716:                               LoadFunc loadFunc, SegmentAllocator allocator) {
> 717:             if (shiftAmount > 0) {

Why do we assume we can only deal with ints or longs?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1304987417

From jwaters at openjdk.org  Fri Aug 25 01:47:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 25 Aug 2023 01:47:38 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are not
 pointers
In-Reply-To: <T6swRa6J2th6vcce4dqMSsW7F97FR1Tikl-rbvLNVxY=.c73a7408-f56f-4374-9f46-dfeddbc0adfa@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
 <T6swRa6J2th6vcce4dqMSsW7F97FR1Tikl-rbvLNVxY=.c73a7408-f56f-4374-9f46-dfeddbc0adfa@github.com>
Message-ID: <NZ24Npr51s1BDtnU-yHFeWxN4cOLZZkoKmTDFdCut_w=.0aff0eec-1f9e-4ab8-afed-85a9f6334550@github.com>

On Thu, 24 Aug 2023 20:02:23 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > I'm wondering how MSVC is compiling without the header
> 
> For older MSVC it picks unique_ptr from https://github.com/openjdk/jdk/blob/2624324ac216aadc938a870075f6fad287fedf05/src/jdk.jpackage/share/native/common/kludge_c%2B%2B11.h

Hmm, I just checked in that file, and it seems like the kludge unique_ptr is only defined for gcc, with no case that enables it for MSVC? (On top of that the gcc conditional is also not spelled correctly)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2858#issuecomment-1692634683

From kvn at openjdk.org  Fri Aug 25 02:00:18 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Aug 2023 02:00:18 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v22]
In-Reply-To: <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <PkSyELVYJ0ZUO3udhmW-V30AYoa5XYA9jZ-IzoogSJI=.31dcc4f0-2738-4979-ac29-5679f6297143@github.com>
 <q1BS6xbmCwurWxTfiGuWXwk921hQapX1vdOACcEx0H4=.1ea9f870-f9ca-4dd1-88ef-e76bba9bc38f@github.com>
 <WaE_HqgYyTUc_e1VVT4I3j_QnV8uvRa2nd62igBf-ME=.32799d89-f74b-4b14-ac7c-ed6d8a777fa6@github.com>
 <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
Message-ID: <xjfJhCpbaxLE2WRX8RQvNF7XMPZkqiheCpAd-NUfjes=.65c42725-c6c8-488c-b2a1-2950e01f610d@github.com>

On Thu, 24 Aug 2023 06:23:29 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
>> 
>> Hi Vladimir,
>> 
>> Thank you for the suggestion! 
>> Currently, AVX512sort is doing well for Random, Repeated and Shuffle patterns of input data. The regressions are observed for Staggered (Wave) pattern of input data. 
>> Will investigate the regressions and adjust the implementations to address them.
>> 
>> Thanks,
>> Vamsi
>
>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
> 
> Hello Vladimir (@vnkozlov) ,
> 
> As per your suggestion, the implementation was adjusted to address the regressions caused for STAGGER and REPEATED type of input data patterns. 
> Please see below the new JMH performance data using the adjusted implementation.
> 
> In the new implementation, we don't call the AVX512 sort intrinsic at the top level (`Arrays.sort()`) . Instead, we take a decomposed or a 'building blocks' approach where we only intrinsify  (using AVX512 instructions) the partitioning and small array sort functions used in the current baseline ( `DualPivotQuickSort.sort()` ). Since the current baseline has logic to detect and sort special input patterns like STAGGER, we fallback to the current baseline instead of using AVX512 partitioning and sorting (which works best for RANDOM, REPEATED and SHUFFLE patterns).
> 
> Data below shows `Arrays.sort()` performance comparison between the current **Java baseline (DPQS)** vs. **AVX512 sort** (this PR)  using the `ArraysSort.java` JMH [benchmark](https://github.com/openjdk/jdk/pull/13568/files#diff-dee51b13bd1872ff455cec2f29255cfd25014a5dd33dda55a2fc68638c3dd4b2) provided in the PR for [JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)](https://github.com/openjdk/jdk/pull/13568/files#top) ( #13568)
> 
> - The following command line was used to run the benchmarks: ` java -jar $JDK_HOME/build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -jvmArgs "-XX:CompileThreshold=1 -XX:-TieredCompilation" ArraysSort`
> - The scores shown are the average time (us/op),  thus lower is better. The last column towards the right shows the speedup. 
> 
> 
> |	Benchmark	|	Mode	|	Size	|	Baseline DPQS (us/op)	|	AVX512 partitioning & sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	800	|	6.7	|	4.8	|	1.39x	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	7000	|	234.1	|	51.5	|	**4.55x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	50000	|	2155.9	|	470.0	|	**4.59x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	300000	|	15076.3	|	3391.3	|	**4.45x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	2000000	|	116445.5	|	27491.7	|	**4.24x**	|
> |	ArraysSort.Double.testSort	|	REPEATED	|	800	|	2.3	|	1.7	|	1.35x	|
> |	ArraysSort.Double.testSort	|	REPEATED	|	7000	|	23.3	|	12.1	|	**1.92x**	|
> |	ArraysSort.Double.testSort	|...

@vamsi-parasa Thank you for addressing performance issues I asked about.

First, since you add new public Java API to Arrays class this have to be reviewed by Core Libs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1692644591

From kvn at openjdk.org  Fri Aug 25 02:00:20 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Aug 2023 02:00:20 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v28]
In-Reply-To: <CxpbB91DvoxsA_7HkuEGamoL7HbM5N0T-sg_6bIa5u4=.4db8b64c-fc9d-4cd6-834f-30235bbccd48@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <CxpbB91DvoxsA_7HkuEGamoL7HbM5N0T-sg_6bIa5u4=.4db8b64c-fc9d-4cd6-834f-30235bbccd48@github.com>
Message-ID: <x0tmqlXlfNMZjWrV6Tqo0-UeYcJ04cD5tl1G5EWhhK0=.a94e18f4-f270-4300-add2-f31948a22f4a@github.com>

On Fri, 25 Aug 2023 01:51:12 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move sort and partition intrinsics from Arrays.java to DPQS.java

Also by build group.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1692645418

From sviswanathan at openjdk.org  Fri Aug 25 02:11:24 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 25 Aug 2023 02:11:24 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v23]
In-Reply-To: <1yCo55YXhhweh_3xXTORwBCZNnQjYneqD3xMxV_SbQE=.b1e286fa-a5fd-4236-84d8-255b62f1b627@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <1yCo55YXhhweh_3xXTORwBCZNnQjYneqD3xMxV_SbQE=.b1e286fa-a5fd-4236-84d8-255b62f1b627@github.com>
Message-ID: <r9GvmK2xLW753XKHkxZm2KBR7dbwNkIR5h9qRm6qbxY=.e38d8f05-d1ff-4949-9f26-53a69fd96ed8@github.com>

On Tue, 22 Aug 2023 23:38:47 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Decomposed DPQS using AVX512 partitioning and AVX512 sort (for small arrays). Works for serial and parallel sort.

src/java.base/linux/native/libx86_64/avx512-common-qsort.h line 29:

> 27: 
> 28: // This implementation is based on x86-simd-sort(https://github.com/intel/x86-simd-sort)
> 29: #include <iostream>

Is the include iostream needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1305047404

From dholmes at openjdk.org  Fri Aug 25 02:32:09 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Aug 2023 02:32:09 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v2]
In-Reply-To: <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
 <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
Message-ID: <VxVhGbpY7bV_2Kxc_uQTeM0XMICqWDnbNZREFTST2Zc=.5371e859-7033-460f-9f9e-f4fb94f09586@github.com>

On Thu, 24 Aug 2023 17:36:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion from dholmes

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15346#pullrequestreview-1594728150

From kvn at openjdk.org  Fri Aug 25 02:53:17 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Aug 2023 02:53:17 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
Message-ID: <aYU82eujuKEvdU95wd2WEyv1g4s718eaLoDglpr4FYM=.a3555f5e-6b38-4869-bc6a-60ad482e6d75@github.com>

On Fri, 25 Aug 2023 01:57:41 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import in Arrays.java

Second.  We do have already the precedent to generate separate dynamic library (and load it into JVM) for intrinsics : [8265783](https://bugs.openjdk.org/browse/JDK-8265783). But I consider that as an exception.

To have second such library gives me concerns. Especially C++ code - we can't control what vectors code particular version of C++ produces. Are `_mm512_set1_*` part of C++ standard or it is dependancies on another tool?
In 8265783 case we had assembler code  which is why we accepted it after some discussions.

And I don't see (may be missing it somewhere) any checks in JVM that a CPU on which you use this library code actually supports AVX512.

Is it possible to identify the hottest code in Java implementation and look why C2 does not produce good vectorized code of it? Even then you may find that performance is coming from some core code which you can then implement in VM in stub generator.

We had similar issue back with CRC32.  What we ended with: we looked on generated by C assembler code and duplicated it in stub generator.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1692680714

From duke at openjdk.org  Fri Aug 25 03:09:29 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 25 Aug 2023 03:09:29 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v23]
In-Reply-To: <r9GvmK2xLW753XKHkxZm2KBR7dbwNkIR5h9qRm6qbxY=.e38d8f05-d1ff-4949-9f26-53a69fd96ed8@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <1yCo55YXhhweh_3xXTORwBCZNnQjYneqD3xMxV_SbQE=.b1e286fa-a5fd-4236-84d8-255b62f1b627@github.com>
 <r9GvmK2xLW753XKHkxZm2KBR7dbwNkIR5h9qRm6qbxY=.e38d8f05-d1ff-4949-9f26-53a69fd96ed8@github.com>
Message-ID: <mjR9HzoD-qXWvlIFHGEKQ3oRs-dULC6g1BSdGt21IPo=.d4ea8ff2-02df-4f75-8249-01de1e64fd20@github.com>

On Fri, 25 Aug 2023 02:07:54 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Decomposed DPQS using AVX512 partitioning and AVX512 sort (for small arrays). Works for serial and parallel sort.
>
> src/java.base/linux/native/libx86_64/avx512-common-qsort.h line 29:
> 
>> 27: 
>> 28: // This implementation is based on x86-simd-sort(https://github.com/intel/x86-simd-sort)
>> 29: #include <iostream>
> 
> Is the include iostream needed?

That was from an earlier commit and was removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1305080141

From asemenyuk at openjdk.org  Fri Aug 25 06:33:28 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 25 Aug 2023 06:33:28 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are not
 pointers
In-Reply-To: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
Message-ID: <16lOg3eS8TshymRpWv5GbXbmnfbrTznaKeoIcyMKVPA=.c75e0b75-85f1-4776-aa41-bf3904c23c11@github.com>

On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
>         with
>         [
>             _Other=nullptr
>         ]
>         and
>         [
>             _Ty=unsigned long
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
>         with
>         [
>             _Ty=unsigned long,
>             _Ty2=unsigned long,
>             _Other=nullptr
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????
> 
> 
> `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
> I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

The intention was to make jpackage native code work with compilers without native std::unique_ptr.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2858#issuecomment-1692837310

From aturbanov at openjdk.org  Fri Aug 25 06:49:10 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 25 Aug 2023 06:49:10 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v2]
In-Reply-To: <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
 <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
Message-ID: <cM99Xs-9r_viB9aAnSddJQlD6rrZyz_-ZR6-bygjKqg=.18f63699-8a90-4b5b-a98b-fa5d2be0bd70@github.com>

On Thu, 24 Aug 2023 17:36:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestion from dholmes

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 236:

> 234:                     case "-jdk-header-template":
> 235:                         jdkHeaderTemplate = new String(
> 236:                             Files.readAllBytes(Paths.get(args[++i])),

Can `java.nio.file.Files#readString(java.nio.file.Path)` be used instead?

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 63:

> 61:         } else if (args.length == 5) {
> 62:             if ("-jdk-header-template".equals(args[i])) {
> 63:                 jdkHeaderTemplate = new String(Files.readAllBytes(Paths.get(args[++i])),

Can be simplified with `Files.readString(java.nio.file.Path)`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15346#discussion_r1305246836
PR Review Comment: https://git.openjdk.org/jdk/pull/15346#discussion_r1305247477

From vpetko at openjdk.org  Fri Aug 25 07:04:50 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 25 Aug 2023 07:04:50 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v6]
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>

> 8314491: Linux: jexec launched via PATH fails to find java

Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into 8314491-jexec-resolve-symlink
 - declare error in-place
 - remove unused imports
 - Review comment: use /proc/self/exe as the backup option
 - Merge branch 'master' into 8314491-jexec-resolve-symlink
 - correct copyright statement
 - Use /proc/self/exec to identify path to the executable.
 - Create failing test for jexec in PATH issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15343/files
  - new: https://git.openjdk.org/jdk/pull/15343/files/c974e011..5354ceba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=04-05

  Stats: 4629 lines in 273 files changed: 3398 ins; 519 del; 712 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From mdoerr at openjdk.org  Fri Aug 25 07:39:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 07:39:09 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <4zrTfeu8tY86-yVJXBoqQ-gsWxGvdogZLTxfScBR7wU=.4f27a1f5-8334-497b-8a7d-756c95ad33ea@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <4zrTfeu8tY86-yVJXBoqQ-gsWxGvdogZLTxfScBR7wU=.4f27a1f5-8334-497b-8a7d-756c95ad33ea@github.com>
Message-ID: <3TcrDO2J1wAFDG5UaHKeh6tSKSKrR4ZSDC6n5-7pT20=.a53854a3-835d-4738-b6d3-54fdf13f70e9@github.com>

On Thu, 24 Aug 2023 23:33:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
>> 
>> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/foreign                          88    88     0     0   
>> 
>> 
>> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/ABIv1CallArranger.java line 33:
> 
>> 31:  * PPC64 CallArranger specialized for ABI v1.
>> 32:  */
>> 33: public class ABIv1CallArranger extends CallArranger {
> 
> Wouldn't it be more natural for CallArranger to have an abstract method (or even a kind() accessor for the different kinds of ABI supported) and then have these specialized subclasses return the correct kind? It seems to me that setting the `useXYZAbi` flag using an instanceof test is a little dirty.

I had something like that, but another reviewer didn't like it, either. Originally, I had thought that the v1 and v2 CallArrangers would get more content, but they're still empty. Would it be better to remove these special CallArrangers and distinguish in the base class?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305300539

From azeller at openjdk.org  Fri Aug 25 07:50:09 2023
From: azeller at openjdk.org (Arno Zeller)
Date: Fri, 25 Aug 2023 07:50:09 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
 <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
Message-ID: <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>

On Wed, 16 Aug 2023 18:33:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as user that is member of the Administrators group. In that case new files are not owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the assumptions of the test's whoami check. My suggestion is to cater for this case and don't fail the test but write a warning message to stdout that a whoami check is not correctly possible.
>
> test/jdk/java/lang/ProcessHandle/InfoTest.java line 304:
> 
>> 302:                     if (Platform.isWindows() && "BUILTIN\\Administrators".equals(whoami)) {
>> 303:                         System.out.println("Test seems to be run as Administrator. " +
>> 304:                                 "Check for user correctness is not possible.");
> 
> Is there an alternative way to determine the expected username? 
> Perhaps by running a windows command or extracting it from the environment (System.getEnv("XX"))?

I think you might use System.getProperty("user.name"). But I am not sure about domain names of users on Windows.
I am also not sure why the user name is currently determined by creating a file - there might be a reason for this that is not obvious to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1305312497

From mdoerr at openjdk.org  Fri Aug 25 07:51:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 07:51:09 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <gH6S2fsCi4kZPhOZSpCZrMRZQUQQF2Mei1o59HZTeqI=.032acbb2-f242-4f6c-b3d7-246b2e231096@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
 <kMh2eH6HfkAhSNFkKD35MqhEZyvE2ZWdH8N_mOReKzc=.a5c26ca0-8676-47f0-be26-989975c6ef6c@github.com>
 <gH6S2fsCi4kZPhOZSpCZrMRZQUQQF2Mei1o59HZTeqI=.032acbb2-f242-4f6c-b3d7-246b2e231096@github.com>
Message-ID: <9eDbDxSzdUMYrRDZh8XMiSd2Np4JrwAy2l6jSyykEVA=.1d009a67-a8e9-4868-8244-d244b8653729@github.com>

On Thu, 24 Aug 2023 23:58:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maybe I'm starting to see it - it's not a special rule, as much as it is a consequence of the endianness. E.g. if you have a struct that is 64 + 32 bytes, you can store the first 64 bytes as a long. Then, there's an issue as we have to fill another long, but we have only 32 bits of value. Is it the problem that if we just copy the value into the long word "as is" it will be stored in the "wrong" 32 bits? So the shift takes care of that, I guess?
>
> If my assumption above is correct, then maybe another way to solve the problem, would be to, instead of adding a new shift binding, to generalize the VM store binding we have to allow writing a smaller value into a bigger storage, with an offset. Correct?

The ABI says: "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." [https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#PARAM-PASS].
I have written examples which pass 9 and 15 Bytes.
In the first case, we need to get 0x0001020304050607 in the first argument and 0x08XXXXXXXXXXXXXX into the second argument (X is "don't care"). Shift amount is 7.
In the second case, we need to get 0x0001020304050607 in the first argument and 0x08090a0b0c0d0eXX into the second argument. Shift amount is 1.
In other words, we need shift amounts between 1 and 7. Stack slots and registers are always 64 bit on PPC64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305313810

From mdoerr at openjdk.org  Fri Aug 25 07:57:09 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 07:57:09 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <aIoYGs3Y5CqhchCtkjVlQnwn9HhXemEp1Dpzx56mlmk=.adba1add-b871-4657-b5fb-1bccff6a4b44@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <aIoYGs3Y5CqhchCtkjVlQnwn9HhXemEp1Dpzx56mlmk=.adba1add-b871-4657-b5fb-1bccff6a4b44@github.com>
Message-ID: <IPlzsSlz3TAd-qEW6NEGm7raG_YOoZ2JHV3JHLK4IKM=.25a343ac-0ec9-4b2b-b88d-1eae4b094db4@github.com>

On Fri, 25 Aug 2023 00:10:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
>> 
>> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/foreign                          88    88     0     0   
>> 
>> 
>> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 717:
> 
>> 715:         public void interpret(Deque<Object> stack, StoreFunc storeFunc,
>> 716:                               LoadFunc loadFunc, SegmentAllocator allocator) {
>> 717:             if (shiftAmount > 0) {
> 
> Why do we assume we can only deal with ints or longs?

I have inserted casts into `public Binding.Builder shiftLeft(int shiftAmount, Class<?> type)` (similar to other bindings). The VM handles integral types smaller than `int` like `int` and uses 4 Bytes for arithmetic operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305321446

From mdoerr at openjdk.org  Fri Aug 25 08:04:10 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 08:04:10 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
Message-ID: <UPFLCECluTnFfvwItHCzHZzMbXQPyFsw9jNwUmVQgQI=.2734809e-3cf1-4ed7-b376-616e1e2588f0@github.com>

On Thu, 24 Aug 2023 23:38:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
>> 
>> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
>> 
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/java/foreign                          88    88     0     0   
>> 
>> 
>> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.
>
> Overall these changes look good - as commented I'd like to learn a bit more of the underlying ABI, to get a sense of whether adding a new binding is ok. But overall it's great to see support for a big-endian ABI - apart from the linker, I am pleased to see that you did not encounter too many issues in the memory-side of the FFM API.

@mcimadamore: Thanks for your feedback! Jorn and I had resolved the other issues already when we have worked on the linux little endian part. It already contains some ABIv1 code. Note that we already have one big endian platform: s390. But that one doesn't pass structs >8 Bytes in registers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15417#issuecomment-1692938709

From jwaters at openjdk.org  Fri Aug 25 08:28:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 25 Aug 2023 08:28:28 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are not
 pointers
In-Reply-To: <16lOg3eS8TshymRpWv5GbXbmnfbrTznaKeoIcyMKVPA=.c75e0b75-85f1-4776-aa41-bf3904c23c11@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
 <16lOg3eS8TshymRpWv5GbXbmnfbrTznaKeoIcyMKVPA=.c75e0b75-85f1-4776-aa41-bf3904c23c11@github.com>
Message-ID: <fvmrjwP-05Vb7wVsdXFas6XJ8guReEQXTpiiiT3mtUI=.e995b93f-2407-4b63-ad93-7a4dea8f6ca3@github.com>

On Fri, 25 Aug 2023 06:30:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The intention was to make jpackage native code work with compilers without native std::unique_ptr.

I understand, however it appears MSVC does not use the code inside that file

-------------

PR Comment: https://git.openjdk.org/jdk/pull/2858#issuecomment-1692968268

From mcimadamore at openjdk.org  Fri Aug 25 09:04:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Aug 2023 09:04:10 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <3TcrDO2J1wAFDG5UaHKeh6tSKSKrR4ZSDC6n5-7pT20=.a53854a3-835d-4738-b6d3-54fdf13f70e9@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <4zrTfeu8tY86-yVJXBoqQ-gsWxGvdogZLTxfScBR7wU=.4f27a1f5-8334-497b-8a7d-756c95ad33ea@github.com>
 <3TcrDO2J1wAFDG5UaHKeh6tSKSKrR4ZSDC6n5-7pT20=.a53854a3-835d-4738-b6d3-54fdf13f70e9@github.com>
Message-ID: <TwX-AHJl6gDtSM7XyeDU0tz9kepyczpJXUvK-JqHtKc=.31d8f44d-cac8-4634-9a51-6761015d573e@github.com>

On Fri, 25 Aug 2023 07:36:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/ABIv1CallArranger.java line 33:
>> 
>>> 31:  * PPC64 CallArranger specialized for ABI v1.
>>> 32:  */
>>> 33: public class ABIv1CallArranger extends CallArranger {
>> 
>> Wouldn't it be more natural for CallArranger to have an abstract method (or even a kind() accessor for the different kinds of ABI supported) and then have these specialized subclasses return the correct kind? It seems to me that setting the `useXYZAbi` flag using an instanceof test is a little dirty.
>
> I had something like that, but another reviewer didn't like it, either. Originally, I had thought that the v1 and v2 CallArrangers would get more content, but they're still empty. Would it be better to remove these special CallArrangers and distinguish in the base class?

It seems to me that what you are doing is similar to what was done for aarch64, which was dealt with using very simple subclasses:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64CallArranger.java
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64CallArranger.java
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64CallArranger.java

In your case there's less difference, but I think we should follow the same idiom for both.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305396592

From mcimadamore at openjdk.org  Fri Aug 25 09:27:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Aug 2023 09:27:09 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <9eDbDxSzdUMYrRDZh8XMiSd2Np4JrwAy2l6jSyykEVA=.1d009a67-a8e9-4868-8244-d244b8653729@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <-H8TLXCvHxTIMGSl0vfnuPByyVX1olhlQzNtKut6aa8=.1094aa6b-60c9-430c-99f2-9af72f994191@github.com>
 <kMh2eH6HfkAhSNFkKD35MqhEZyvE2ZWdH8N_mOReKzc=.a5c26ca0-8676-47f0-be26-989975c6ef6c@github.com>
 <gH6S2fsCi4kZPhOZSpCZrMRZQUQQF2Mei1o59HZTeqI=.032acbb2-f242-4f6c-b3d7-246b2e231096@github.com>
 <9eDbDxSzdUMYrRDZh8XMiSd2Np4JrwAy2l6jSyykEVA=.1d009a67-a8e9-4868-8244-d244b8653729@github.com>
Message-ID: <NCHFvtLFljxxUIOFWFdxR-8M2RDWlSez4dsyDS-V3Jo=.30590cf1-5918-4c9c-856b-56d0e77edb49@github.com>

On Fri, 25 Aug 2023 07:48:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> If my assumption above is correct, then maybe another way to solve the problem, would be to, instead of adding a new shift binding, to generalize the VM store binding we have to allow writing a smaller value into a bigger storage, with an offset. Correct?
>
> The ABI says: "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." [https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#PARAM-PASS].
> I have written examples which pass 9 and 15 Bytes.
> In the first case, we need to get 0x0001020304050607 in the first argument and 0x08XXXXXXXXXXXXXX into the second argument (X is "don't care"). Shift amount is 7.
> In the second case, we need to get 0x0001020304050607 in the first argument and 0x08090a0b0c0d0eXX into the second argument. Shift amount is 1.
> In other words, we need shift amounts between 1 and 7. Stack slots and registers are always 64 bit on PPC64.

Got it - I found these representations:

https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.7.html#BYTEORDER

Very helpful. So you have e.g. a `short` value (loaded from somewhere) and you have to store it on a double-word. Now, if you just stored it at offset 0, you will write the bits 0-15, which are the "most" significant bits in big-endian representation. So, it's backwards. I believe FFM will take care of endianness, so that the bytes 0-7 and 8-15 will be "swapped" when writing into the double-word (right?) but their base offset (0) is still off, as they should really start at offset 48. Hence the shift.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305420316

From duke at openjdk.org  Fri Aug 25 09:27:10 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Fri, 25 Aug 2023 09:27:10 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3]
In-Reply-To: <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
Message-ID: <lQB3pUh9XPILfxBEyYfpxo3ug_E96eBAGCbxUPKk128=.bd7d4130-49e8-403a-bc3e-cd658dd5e08a@github.com>

On Thu, 6 Jul 2023 05:20:14 GMT, ??? <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add method CharacterDataLatin1#isLowerCaseEx

@AlanBateman can you help me to review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1693056828

From aefimov at openjdk.org  Fri Aug 25 09:32:22 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 25 Aug 2023 09:32:22 GMT
Subject: RFR: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection [v14]
In-Reply-To: <poCcoILL2XADwz8lJg59A2aAvcqo6TEWgXv64jI46EE=.2c5f0b7b-c71e-407c-aa5f-c407d7687acc@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
 <poCcoILL2XADwz8lJg59A2aAvcqo6TEWgXv64jI46EE=.2c5f0b7b-c71e-407c-aa5f-c407d7687acc@github.com>
Message-ID: <bzPzEHZLXFW2KYA0cLceUkC0PHnu5qSUblDDEC7hQUA=.998bf859-8e68-4411-b907-a541d009efb1@github.com>

On Thu, 24 Aug 2023 23:08:43 GMT, Weibing Xiao <duke at openjdk.org> wrote:

>> Please refer to JDK-8314063.
>> 
>> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
>> 
>> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.
>
> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the code

Thanks for addressing all comments, Weibing. The changes look good to me. I will sponsor this change.

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15294#pullrequestreview-1595318497

From mcimadamore at openjdk.org  Fri Aug 25 09:33:09 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 25 Aug 2023 09:33:09 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API
In-Reply-To: <IPlzsSlz3TAd-qEW6NEGm7raG_YOoZ2JHV3JHLK4IKM=.25a343ac-0ec9-4b2b-b88d-1eae4b094db4@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <aIoYGs3Y5CqhchCtkjVlQnwn9HhXemEp1Dpzx56mlmk=.adba1add-b871-4657-b5fb-1bccff6a4b44@github.com>
 <IPlzsSlz3TAd-qEW6NEGm7raG_YOoZ2JHV3JHLK4IKM=.25a343ac-0ec9-4b2b-b88d-1eae4b094db4@github.com>
Message-ID: <Jkn9vVZs4ZEHkuBDq0F6X6TTh1FZsIiJjwiTiwzZ1KU=.5d192c71-e9ea-4a76-b08a-8ef9597db85c@github.com>

On Fri, 25 Aug 2023 07:54:51 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 717:
>> 
>>> 715:         public void interpret(Deque<Object> stack, StoreFunc storeFunc,
>>> 716:                               LoadFunc loadFunc, SegmentAllocator allocator) {
>>> 717:             if (shiftAmount > 0) {
>> 
>> Why do we assume we can only deal with ints or longs?
>
> I have inserted casts into `public Binding.Builder shiftLeft(int shiftAmount, Class<?> type)` (similar to other bindings). The VM handles integral types smaller than `int` like `int` and uses 4 Bytes for arithmetic operations.

Ah I see that now - it's done the binding "builder".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305426640

From myano at openjdk.org  Fri Aug 25 09:44:25 2023
From: myano at openjdk.org (Masanori Yano)
Date: Fri, 25 Aug 2023 09:44:25 GMT
Subject: RFR: 8315004: Runtime.halt() debug logging
Message-ID: <rK1UbMwvq7pLAgQRAe9O8c5-FUXflM2FcNpvR9vfye0=.acbc1359-8b45-43d4-b5c8-15c249f038da@github.com>

I want to add a log output similar to JDK-8301627 to Runtime.halt().
To avoid double logging of Runtime.exit(), add a flag to indicate whether logging was done, and fix it so that logging is done only once.
Could someone please review this fix?

-------------

Commit messages:
 - Merge branch 'openjdk:master' into LogRuntimeHalt
 - Merge branch 'openjdk:master' into LogRuntimeHalt
 - Add log output on Runtime.halt()
 - Add log output on Runtime.halt()

Changes: https://git.openjdk.org/jdk/pull/15426/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15426&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315004
  Stats: 21 lines in 2 files changed: 7 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15426.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15426/head:pull/15426

PR: https://git.openjdk.org/jdk/pull/15426

From alanb at openjdk.org  Fri Aug 25 09:52:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Aug 2023 09:52:11 GMT
Subject: RFR: 8315004: Runtime.halt() debug logging
In-Reply-To: <rK1UbMwvq7pLAgQRAe9O8c5-FUXflM2FcNpvR9vfye0=.acbc1359-8b45-43d4-b5c8-15c249f038da@github.com>
References: <rK1UbMwvq7pLAgQRAe9O8c5-FUXflM2FcNpvR9vfye0=.acbc1359-8b45-43d4-b5c8-15c249f038da@github.com>
Message-ID: <ftMu57QxruK7fUs9705PW57R4UmWnAk1zS2qBAlbbCY=.bcc5ab4b-96d9-4613-aac7-4b0978b7f5fb@github.com>

On Fri, 25 Aug 2023 09:37:47 GMT, Masanori Yano <myano at openjdk.org> wrote:

> I want to add a log output similar to JDK-8301627 to Runtime.halt().
> To avoid double logging of Runtime.exit(), add a flag to indicate whether logging was done, and fix it so that logging is done only once.
> Could someone please review this fix?

I think you may have missed the comment in the JBS issue. Logging means running potentially arbitrary code, doing this at Runtime.halt time is problematic. I thought the conclusion from the work on Runtime.exit was not to log in Runtime.halt?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15426#issuecomment-1693095419

From alanb at openjdk.org  Fri Aug 25 10:07:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Aug 2023 10:07:09 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
 <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
 <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>
Message-ID: <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>

On Thu, 24 Aug 2023 14:39:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I've now realized that the bug had an incorrect statement in the description. The cycle happens due to the `Runtime.getRuntime().maxMemory()` implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code relies on the `Runtime.getRuntime().maxMemory()` API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no?
> 
> With that said, it's seems a rather uncontroversial change with very limited scope. Do you see anything problematic in this patch? Happy to revise if you think there are some no-no's :)

Recursive initialization issues can tricky and often it comes down to deciding where to break the cycle. In this case, it seems a bit fragile to do it in CgroupUtil as it should be allowed to use any of the file system APIs to access cgroups or proc files. Part of me wonders if this would be better handled in their implementation of jdk.internal.misc.VM or Runtime.maxMemory but maybe you've been there already?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1693114562

From jpai at openjdk.org  Fri Aug 25 10:27:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Aug 2023 10:27:10 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
Message-ID: <UoY481q88LjxvLidm6IkUqeKcjEc02n7j2Crj1zZHpo=.f5d6ceda-5fb3-4a1d-a459-6d9b89d93f77@github.com>

On Thu, 24 Aug 2023 10:54:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test coverage
>  - Incorporate review comments from Daniel

src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java line 988:

> 986:     private static void ensureClassInitialized(Class<?> c) {
> 987:         try {
> 988:             MethodHandles.lookup().ensureInitialized(c);

Hello Sean, should we check if there are any implications, like on startup performance, of using `MethodHandles` in this `BootstrapLogger`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305485295

From jpai at openjdk.org  Fri Aug 25 10:36:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Aug 2023 10:36:10 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>
Message-ID: <WQoLVQ_yB-ZK5Vdt5xefP-lNlbxqzmIySDt-kGdJWdw=.7a016328-e73b-4318-afef-07a45f8cabcc@github.com>

On Wed, 23 Aug 2023 17:10:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Improve test coverage
>>  - Incorporate review comments from Daniel
>
> src/java.base/share/classes/jdk/internal/logger/LazyLoggers.java line 425:
> 
>> 423:      */
>> 424:     public static final Logger getLogger(String name, Module module) {
>> 425:         BootstrapLogger.detectBackend();
> 
> Suggestion:
> 
>         // triggers detection of the backend
>         BootstrapLogger.detectBackend();

Hello Daniel, Sean, I couldn't understand the need for this method. The changes to `BootstrapLogger` in this PR removes the initialization of `DetectBackend` class while holding a lock on `BootstrapLogger` class in the `BootstrapLogger.useLazyLoggers` method. Wouldn't that be enough?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305493743

From mdoerr at openjdk.org  Fri Aug 25 10:41:04 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 10:41:04 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API [v2]
In-Reply-To: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
Message-ID: <RFVJWhUjbkCZ2zM5p7MbHGuJDy0UTTpFMT2Q34KC82A=.2e30b2c5-0eb6-46aa-9a11-12bd0f18bd0e@github.com>

> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
> 
> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/foreign                          88    88     0     0   
> 
> 
> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Implement ABI version selection by virtual method instead of instanceof check.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15417/files
  - new: https://git.openjdk.org/jdk/pull/15417/files/5d7b0e1d..50144b14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=00-01

  Stats: 16 lines in 3 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417

PR: https://git.openjdk.org/jdk/pull/15417

From mdoerr at openjdk.org  Fri Aug 25 10:41:05 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 10:41:05 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API [v2]
In-Reply-To: <TwX-AHJl6gDtSM7XyeDU0tz9kepyczpJXUvK-JqHtKc=.31d8f44d-cac8-4634-9a51-6761015d573e@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
 <4zrTfeu8tY86-yVJXBoqQ-gsWxGvdogZLTxfScBR7wU=.4f27a1f5-8334-497b-8a7d-756c95ad33ea@github.com>
 <3TcrDO2J1wAFDG5UaHKeh6tSKSKrR4ZSDC6n5-7pT20=.a53854a3-835d-4738-b6d3-54fdf13f70e9@github.com>
 <TwX-AHJl6gDtSM7XyeDU0tz9kepyczpJXUvK-JqHtKc=.31d8f44d-cac8-4634-9a51-6761015d573e@github.com>
Message-ID: <UhQ8kVZDdE42anIPfDzl1Wa5f1_7KFCwFOU-ENj-Hv0=.e248e956-5fe0-4d73-8931-671b02dc89b4@github.com>

On Fri, 25 Aug 2023 09:01:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I had something like that, but another reviewer didn't like it, either. Originally, I had thought that the v1 and v2 CallArrangers would get more content, but they're still empty. Would it be better to remove these special CallArrangers and distinguish in the base class?
>
> It seems to me that what you are doing is similar to what was done for aarch64, which was dealt with using very simple subclasses:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64CallArranger.java
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64CallArranger.java
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64CallArranger.java
> 
> In your case there's less difference, but I think we should follow the same idiom for both.

Makes sense. I've changed it with the 2nd commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305495063

From duke at openjdk.org  Fri Aug 25 10:48:37 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Fri, 25 Aug 2023 10:48:37 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v7]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <E4K0z5Kom5a-_vl2dmGNtHS1dBibbsqo-68xrwbId24=.b244c5f1-5739-4fa3-997d-5f53b321fee4@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with 141 additional commits since the last revision:

 - 8314990: Generational ZGC: Strong OopStorage stats reported as weak roots
   
   Reviewed-by: stefank, eosterlund
 - 8312749: Generational ZGC: Tests crash with assert(index == 0 || is_power_of_2(index))
   
   Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
   Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
   Reviewed-by: thartmann, ayang, kvn
 - 8314951: VM build without C2 still fails after JDK-8313530
   
   Reviewed-by: dnsimon, kvn
 - 8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent
   
   Reviewed-by: jlu, vtewari, rriggs, jpai
 - 8314850: SharedRuntime::handle_wrong_method() gets called too often when resolving Continuation.enter
   
   Reviewed-by: rpressler, aph
 - 8314759: VirtualThread.parkNanos timeout adjustment when pinned should be replaced
   
   Reviewed-by: aturbanov, shade, dfuchs
 - 8306040: HttpResponseInputStream.available() returns 1 on empty stream
   
   Reviewed-by: dfuchs
 - 8314656: GHA: No need for Debian ports keyring installation after JDK-8313701
   
   Reviewed-by: fyang
 - 8314554: Debian/Ubuntu should not link OpenJDK with --as-needed link option
   
   Reviewed-by: erikj
 - 8314883: Java_java_util_prefs_FileSystemPreferences_lockFile0 write result errno in missing case
   
   Reviewed-by: jpai, shade, vtewari
 - ... and 131 more: https://git.openjdk.org/jdk/compare/69672701...b49bf280

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/69672701..b49bf280

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=05-06

  Stats: 14502 lines in 618 files changed: 9508 ins; 1142 del; 3852 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From jpai at openjdk.org  Fri Aug 25 10:59:08 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Aug 2023 10:59:08 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <Esrm0V7Jh_MWD6Lc1qwryYlVTmayVEqgDft0uq-xpA0=.6bf03845-a911-46d0-86b0-ef7375775143@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>
 <Esrm0V7Jh_MWD6Lc1qwryYlVTmayVEqgDft0uq-xpA0=.6bf03845-a911-46d0-86b0-ef7375775143@github.com>
Message-ID: <h56zuS7WoRjhc7VQDbncq_xmQtfmBzGy08z4kgV7jdc=.f0905e6c-89e6-4096-904c-a020d307ac40@github.com>

On Wed, 23 Aug 2023 17:16:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> We could create a singleton instance of TemporaryLoggerFinder in the TemporaryLoggerFinder class and return that.

I think the disadvantage is that this singleton instance will never be GCed (till `LoggerFinderLoader` class itself is unloaded) unlike just using a new instance at the call site. Having said that, not being GCed doesn't make a huge difference given what this singleton instance does or holds on to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305512530

From mdoerr at openjdk.org  Fri Aug 25 10:59:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Aug 2023 10:59:45 GMT
Subject: RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign
 Function & Memory API [v3]
In-Reply-To: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
References: <JtIQHDBw0yptHgCKWJ12FxIEY4BHrAcHBzsKG4YbCTQ=.0782acf6-9f4f-49d4-86cf-59c8f4371f50@github.com>
Message-ID: <9Kiu1jOvcK84xyXL6IlXsgHZSBWyWe35HQU9ZdG0bZ8=.20665eea-7e0b-4ec8-94d1-f926a9f0f38b@github.com>

> I've found a way to solve the remaining FFI problem on linux PPC64 Big Endian. Large structs (>8 Bytes) which are passed in registers or on stack require shifting the Bytes in the last slot if the size is not a multiple of 8. This PR adds the required functionality to the Java code.
> 
> Please review and provide feedback. There may be better ways to implement it. I just found one which works and makes the tests pass:
> 
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/java/foreign                          88    88     0     0   
> 
> 
> Note: This PR should be considered as preparation work for AIX which also uses ABIv1.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary imports.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15417/files
  - new: https://git.openjdk.org/jdk/pull/15417/files/50144b14..430fa018

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15417&range=01-02

  Stats: 5 lines in 3 files changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15417/head:pull/15417

PR: https://git.openjdk.org/jdk/pull/15417

From jpai at openjdk.org  Fri Aug 25 11:14:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Aug 2023 11:14:11 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
Message-ID: <giANpSdk-WbvgecOJ-mOg5FS8Uad6zMggCyB1xwQxR0=.4931eede-c2fe-4ba7-860b-3c8c7c3a1e17@github.com>

On Thu, 24 Aug 2023 10:54:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test coverage
>  - Incorporate review comments from Daniel

test/jdk/java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.java line 109:

> 107:                 Boolean.parseBoolean(System.getProperty("mutliThreadLoad", "false"));
> 108:             boolean withCustomLoggerFinder =
> 109:                 Boolean.parseBoolean(System.getProperty("withCustomLoggerFinder", "false"));

Nit - these two calls can be replaced with `Boolean.getBoolean("<syspropname>")`. If you however want to use this current form, that's fine too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305525527

From jpai at openjdk.org  Fri Aug 25 11:26:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 25 Aug 2023 11:26:10 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
Message-ID: <wl3ojMxbIFk6b-ULxVeHkWK94OQyTvHkbkmkY8_r_Jg=.8d347357-15d4-4832-ace0-4ad8c579674f@github.com>

On Thu, 24 Aug 2023 10:54:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test coverage
>  - Incorporate review comments from Daniel

test/jdk/java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.java line 122:

> 120:                             Thread.sleep(sleep);
> 121:                         } catch (InterruptedException e) {
> 122:                             throw new RuntimeException(e);

Given that this will end up being thrown from a `Thread`, this will end up being an uncaught exception and handled by a `UncaughtExceptionHandler` (I don't remember if/what jtreg sets it to). The default `ThreadGroup` UncaughtExceptionHandler, just logs to System.err such exceptions https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadGroup.java#L697. Just noting it here, in case you want to do this differently if you want this exception to fail the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305534996

From dl at openjdk.org  Fri Aug 25 11:53:42 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 25 Aug 2023 11:53:42 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v15]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <WbfLZFXCHZdNfpsimYFH8xN6AF-BD9Eb6-821B__VY8=.431b04b1-4e22-4489-94ca-f5e91b372e7b@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Isolate unexpected interrupt status issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/9d1b55a7..9a329b6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=13-14

  Stats: 119 lines in 3 files changed: 112 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From duke at openjdk.org  Fri Aug 25 12:03:21 2023
From: duke at openjdk.org (duke)
Date: Fri, 25 Aug 2023 12:03:21 GMT
Subject: Withdrawn: 8311084: Add typeSymbol() API for applicable constant pool
 entries
In-Reply-To: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
References: <Q7rrUTUHdj0ltS1PNbgVEI9X3X8MS6P4zR1piWw5d7g=.0855af33-9dd3-4853-baa6-5a0d3d704d93@github.com>
Message-ID: <78-pThCT1PQ3S_VpulDky1sJntT64y89IBn0MtVMaxw=.e15a5672-e692-41e4-b289-e51acdadbb07@github.com>

On Thu, 29 Jun 2023 09:59:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> 5 Constant Pool entries, namely ConstantDynamicEntry, InvokeDynamicEntry, FieldRefEntry, MethodRefEntry, and InterfaceMethodRefEntry should have a typeSymbol() API to return the nominal/symbolic descriptor (ClassDesc or MethodTypeDesc).
> 
> This API is not added to NameAndTypeEntry itself, for a NameAndTypeEntry only knows if its type should be a field or method type from the other entries that refer to it.
> 
> This is one of the issues discussed in this mailing list thread: https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14706

From duke at openjdk.org  Fri Aug 25 12:23:36 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 25 Aug 2023 12:23:36 GMT
Subject: Integrated: 8314063 : The socket is not closed in
 Connection::createSocket when the handshake failed for LDAP connection
In-Reply-To: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
References: <H8vP6HB9sYyYm4QXuLVZNdyUQ4A8EHPS2GeWItJr39E=.fdb56f65-5fc7-40ce-bebf-bd0d9dad4899@github.com>
Message-ID: <BCXUc8oB8EentKWGZx193YV4NmUifHibdkoFRUXcdTI=.4ac77b35-191d-49aa-9428-b926f42721e4@github.com>

On Tue, 15 Aug 2023 17:30:54 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Please refer to JDK-8314063.
> 
> The failure scenario is due to the setting of connection timeout. It is either too small or not an optimal value for the system. When the client tries to connect to the server with LDAPs protocol. It requires the handshake after the socket is created and connected, but it fails due to connection timeout and leaves the socket open. It is not closed properly due to the exception handling in the JDK code.
> 
> The change is adding a try/catch block and closing the socket in the catch block,  and the format of the code got changed consequently.

This pull request has now been integrated.

Changeset: f2383b3c
Author:    Weibing Xiao <weibing.xiao at oracle.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f2383b3cbd1096f0b38e89a3d876da2217511f11
Stats:     357 lines in 3 files changed: 290 ins; 42 del; 25 mod

8314063: The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection

Reviewed-by: aefimov, msheppar

-------------

PR: https://git.openjdk.org/jdk/pull/15294

From duke at openjdk.org  Fri Aug 25 12:56:21 2023
From: duke at openjdk.org (duke)
Date: Fri, 25 Aug 2023 12:56:21 GMT
Subject: Withdrawn: 8307149: MethodHandles.arrayConstructor can be cached
In-Reply-To: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>
References: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>
Message-ID: <4BJoMvcN1EdljX70aUefBWcFzLviCxW8uAkqmI0feMc=.ee45b35f-1b61-4232-86eb-386c5314d516@github.com>

On Thu, 4 May 2023 23:29:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch migrates `MethodHandles::arrayConstructor`, added in Java 9 as a hotfix to the incorrect constructor found on arrays via Lookup, to share the array access caching features. The result is that calling `MethodHandles.arrayConstructor` to create method handles is much faster.
> 
> Oracle JDK 20:
> 
> Benchmark                                             Mode  Cnt   Score   Error  Units
> MethodHandlesArrayConstructor.createWithAnewarray     avgt   15   2.739 ? 0.058  ns/op
> MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15   3.313 ? 0.041  ns/op
> MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  61.874 ? 0.397  ns/op
> 
> 
> This patch:
> 
> Benchmark                                             Mode  Cnt  Score   Error  Units
> MethodHandlesArrayConstructor.createWithAnewarray     avgt   15  3.067 ? 0.026  ns/op
> MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15  3.699 ? 0.042  ns/op
> MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  1.447 ? 0.004  ns/op

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/13819

From erikj at openjdk.org  Fri Aug 25 13:12:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 25 Aug 2023 13:12:44 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v3]
In-Reply-To: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
Message-ID: <IhaPxHpXx4vAiamZhTfe0B0aFqI5BwazqvnqGLW2oag=.9885e8ea-d5ad-44ef-933d-dd8865475bf2@github.com>

> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Use Files.readString

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15346/files
  - new: https://git.openjdk.org/jdk/pull/15346/files/a53cf2f2..8ab213a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15346&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15346&range=01-02

  Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15346.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15346/head:pull/15346

PR: https://git.openjdk.org/jdk/pull/15346

From erikj at openjdk.org  Fri Aug 25 13:12:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 25 Aug 2023 13:12:44 GMT
Subject: RFR: 8314483: Optionally override copyright header in generated
 source [v2]
In-Reply-To: <cM99Xs-9r_viB9aAnSddJQlD6rrZyz_-ZR6-bygjKqg=.18f63699-8a90-4b5b-a98b-fa5d2be0bd70@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
 <ngEqh5ssZfwVV8sPc6p7wlDuIbrQJboaYVo5rAR7uso=.5229104a-99b0-458c-bd22-cd38a298c783@github.com>
 <cM99Xs-9r_viB9aAnSddJQlD6rrZyz_-ZR6-bygjKqg=.18f63699-8a90-4b5b-a98b-fa5d2be0bd70@github.com>
Message-ID: <E0Wrsv7BDhrJFSkV7Ruc1nA8fIZQBb5y136FLfpkoZg=.1085431d-13b1-4f73-a83a-9c3222d99832@github.com>

On Fri, 25 Aug 2023 06:45:25 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggestion from dholmes
>
> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 236:
> 
>> 234:                     case "-jdk-header-template":
>> 235:                         jdkHeaderTemplate = new String(
>> 236:                             Files.readAllBytes(Paths.get(args[++i])),
> 
> Can `java.nio.file.Files#readString(java.nio.file.Path)` be used instead?

Ah yes, I was looking for that method and didn't find it, but I now realize I was looking in the jdk 8 api. Punished for not setting up an IDE for editing these files. Fixed now, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15346#discussion_r1305638090

From duke at openjdk.org  Fri Aug 25 13:20:54 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Fri, 25 Aug 2023 13:20:54 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v8]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <hm8v3HONdRkzGDXcRcyeTpFyBLm4Hc2drvVWOFCPlg0=.91eaa5be-a90c-4139-86c7-161dae94ee5f@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin 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 one additional commit since the last revision:

  fix overflow in Collections.rotate and write tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/b49bf280..a7d7722b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=06-07

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From erikj at openjdk.org  Fri Aug 25 13:23:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 25 Aug 2023 13:23:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
Message-ID: <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>

On Fri, 25 Aug 2023 01:57:41 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import in Arrays.java

make/modules/java.base/Lib.gmk line 239:

> 237: ################################################################################
> 238: 
> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)

Is there a reason for this to only be supported on Linux?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1305652232

From sgehwolf at openjdk.org  Fri Aug 25 13:32:11 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 25 Aug 2023 13:32:11 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
 <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
 <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>
 <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
Message-ID: <AkEDp4aBr9HnZtTHbdzGTdkT0OCBFRfl8_HZorvmKzY=.c3e34866-bf54-4a29-984a-3bf0620ebab5@github.com>

On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In this case, it seems a bit fragile to do it in CgroupUtil as it should be allowed to use any of the file system APIs to access cgroups or proc files.

In theory, yes. It should be able to use any file system APIs. Practically, it doesn't make a whole lot of difference :-) Going by the last few years this area of the code hasn't had many updates.

> Part of me wonders if this would be better handled in their implementation of jdk.internal.misc.VM or Runtime.maxMemory but maybe you've been there already?

Implementing `Runtime.maxMemory` (determine the configured max heap size), usually needs some notion of 'Physical Memory', since the heap size is being based on 'Physical Memory' if not explicitly set. As with HotSpot, that notion of 'Physical Memory' might depend on whether or not you're running in a container (usually with a single process in that container) or not. The GraalVM implementation uses the JDK cgroups code to figure out the 'Physical Memory' in the container case. I don't think there is a way to implement `Runtime.maxMemory` without knowing `Physical Memory'.

This isn't a problem in OpenJDK (yet), since HotSpot has its own implementation in its runtime written in C. That has its own set of problems, since we need to update both implementations when bugs come in.

In a way, this boils down to ByteBuffers using max heap size for it's default direct memory size determination. I'm not sure doing something else in GraalVM for determining the default direct memory size would be any better.

All things considered, breaking the cycle in OpenJDK seems reasonable to me. Would this convince you to accept this patch?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1693364297

From duke at openjdk.org  Fri Aug 25 13:48:09 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Fri, 25 Aug 2023 13:48:09 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v4]
In-Reply-To: <IDM6F6g7qrBB5DWLTPwLdg2U3CrzCUAwxyUt2KxE6Fs=.3380339f-fc2b-4a21-b03a-e1dadd1ac0d1@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <Goz9mnlBOSmYHnfKTNK-XbBr3_P_NiupjiTO7DURbEU=.c05cb614-af85-4dd9-89b2-b44a6112217c@github.com>
 <IDM6F6g7qrBB5DWLTPwLdg2U3CrzCUAwxyUt2KxE6Fs=.3380339f-fc2b-4a21-b03a-e1dadd1ac0d1@github.com>
Message-ID: <gBECVINDR64q52H_S3m5zl4pCug9vzvyZWnR5LrIPJc=.d63b2bbe-79e5-4b70-bf1d-605ce8ad4a8b@github.com>

On Thu, 24 Aug 2023 02:36:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8314236: rewrite test
>
> @nikita-sakharin
> 
> Thanks for the updates. With the "Mock List" implementation we can run the test in-JVM and we can avoid allocating several GB of memory. Great!
> 
> The implementation logic in the `rotate1` method looks correct.
> 
> Now that an individual test case is much less expensive, it becomes feasible to add multiple test cases. In particular, for this kind of testing of arithmetic errors, I like to test a variety of edge cases. The one test case you have is for size=`(1 << 30) - 1` and distance=`(1 << 30)`. It would be good to have a few other cases where the existing code fails and where the modified code should pass. I was able to come up with a few examples quickly:
> 
>     size                 distance
>     Integer.MAX_VALUE    2
>     Integer.MAX_VALUE    Integer.MIN_VALUE
>     Integer.MAX_VALUE    Integer.MAX_VALUE - 1
> 
> Please add these cases, and any others that you think might be interesting.

@stuart-marks
Thank you for your review.

Test was failing due to [JDK-8313701](https://bugs.openjdk.org/browse/JDK-8313701). So, I pulled changes from the `master` and squash my commits.

I increased test coverage with respect to your advice. All tests passed successfully.

Awaiting the next step of your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1693385541

From heidinga at openjdk.org  Fri Aug 25 13:56:13 2023
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 25 Aug 2023 13:56:13 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
Message-ID: <_gf28X1okZyVfbHhRjDSB3ehFyuytHFyxF4f5Z5qb4E=.6f77ccf6-5f84-485b-ad26-4bc79874e6de@github.com>

On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> Another alternative is to add a new `NO_METHOD_INFO` option.  Similar to the proposed API,
>>...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and javadoc clean up

src/hotspot/share/classfile/javaClasses.cpp line 2990:

> 2988:     // direct calls for private and/or final non-static methods.
> 2989:     flags |= java_lang_invoke_MemberName::MN_IS_METHOD;
> 2990:   }

Both the is_static and the else block set java_lang_invoke_MemberName::MN_IS_METHOD.  Do we need to differentiate between the two cases or can they be collapsed?

src/java.base/share/classes/java/lang/ClassFrameInfo.java line 48:

> 46:     }
> 47:     boolean isHidden() {
> 48:         return SharedSecrets.getJavaLangInvokeAccess().isHiddenMember(flags & MEMBER_INFO_FLAGS);

Is it better to cache the JLIA in a static final similar to what StackFrameInfo does?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305670313
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305670016

From dl at openjdk.org  Fri Aug 25 14:08:51 2023
From: dl at openjdk.org (Doug Lea)
Date: Fri, 25 Aug 2023 14:08:51 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v16]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <WtT0dn14O9j0CVIHFisbS-SXdrOwo0opDoB5ucUrCs4=.dcd5656b-d377-4200-baa1-78219c6401ae@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Conditionalize new tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/9a329b6c..5a4131f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=14-15

  Stats: 38 lines in 1 file changed: 4 ins; 0 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From roger.riggs at oracle.com  Fri Aug 25 15:23:22 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Aug 2023 11:23:22 -0400
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
Message-ID: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>

I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group

Daniel has been contributing to the OpenJDK Core Libraries at Oracle 
since 2012. He is leading the networking team and has made nearly 400 
contributions to OpenJDK since JDK 6.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to 
vote on this nomination. Votes must be cast in the open by replying to 
this mailing list.

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote

From roger.riggs at oracle.com  Fri Aug 25 15:23:35 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Aug 2023 11:23:35 -0400
Subject: CFV: New Core Libraries Group Member: Lance Andersen
Message-ID: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>

I hereby nominate Lance Andersen to Membership in the Core Libraries Group

Lance has been contributing to the OpenJDK at Oracle since 2007. He has 
been the JDBC spec lead since 2005 and an OpenJDK committer since day 1. 
He has extensive experience with Java EE, Databases and SQL and is 
improving the integrity and performance of Zip and JAR implementations.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to 
vote on this nomination. Votes must be cast in the open by replying to 
this mailing list.

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote||
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230825/7a2ff3ad/attachment-0001.htm>

From roger.riggs at oracle.com  Fri Aug 25 15:24:44 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Aug 2023 11:24:44 -0400
Subject: CFV: New Core Libraries Group Member: Michael McMahon
Message-ID: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>

I hereby nominate Michael McMahon to Membership in the Core Libraries Group

Michael has been contributing to the OpenJDK Core Libraries since 2008, 
originally at Sun Microsystems, now Oracle. He has deep networking 
experience and has made more than 260 contributions to OpenJDK.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to 
vote on this nomination. Votes must be cast in the open by replying to 
this mailing list For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote


From brian.burkhalter at oracle.com  Fri Aug 25 15:25:32 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 25 Aug 2023 15:25:32 +0000
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <C0F92AF5-9F7A-4CE5-8F25-90327711FA45@oracle.com>

Vote: yes

From brian.burkhalter at oracle.com  Fri Aug 25 15:25:43 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 25 Aug 2023 15:25:43 +0000
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <2C88BF0C-B644-4F4D-A1FE-C5603FE1A589@oracle.com>

Vote: yes

From brian.burkhalter at oracle.com  Fri Aug 25 15:25:56 2023
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 25 Aug 2023 15:25:56 +0000
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <700785D5-33ED-429E-8048-CDF1F2D8917A@oracle.com>

Vote: yes

From huizhe.wang at oracle.com  Fri Aug 25 15:44:25 2023
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 25 Aug 2023 08:44:25 -0700
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <4d073dcc-0d41-4e3f-7eb2-451da1149e45@oracle.com>

Vote: yes

-Joe

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group 


From huizhe.wang at oracle.com  Fri Aug 25 15:44:39 2023
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 25 Aug 2023 08:44:39 -0700
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <7f746607-6121-b80e-5418-9ecb1192f500@oracle.com>

Vote: yes

-Joe

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Lance Andersen to Membership in the Core Libraries 
> Group 


From huizhe.wang at oracle.com  Fri Aug 25 15:44:57 2023
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 25 Aug 2023 08:44:57 -0700
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <83e0c17f-a7d8-8c5f-b4d0-a8c61256e94e@oracle.com>

Vote: yes

-Joe

On 8/25/23 8:24 AM, Roger Riggs wrote:
> I hereby nominate Michael McMahon to Membership in the Core Libraries 
> Group 


From coffeys at openjdk.org  Fri Aug 25 16:13:53 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 25 Aug 2023 16:13:53 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v3]
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <wPmTR1XAD7IFxisSrdwUXf3z3C6bGVH9f6_l_IdtCus=.b91c4d23-89f7-4203-bf34-5962959a9a8a@github.com>

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  fix up bootstrap loggers, patch contribution from Daniel

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15404/files
  - new: https://git.openjdk.org/jdk/pull/15404/files/976fdb27..3b35c440

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=01-02

  Stats: 70 lines in 3 files changed: 23 ins; 32 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From coffeys at openjdk.org  Fri Aug 25 16:13:55 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 25 Aug 2023 16:13:55 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
Message-ID: <veAaojPfQWbsT27BgrVYQE4uVBemFH0FYAbjm1xB7jk=.32146d61-19a7-4730-90e1-589351e139e3@github.com>

On Thu, 24 Aug 2023 10:54:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Improve test coverage
>  - Incorporate review comments from Daniel

Thanks for your comments @jai - I'll incorporate your test comments soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15404#issuecomment-1693595951

From coffeys at openjdk.org  Fri Aug 25 16:13:58 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 25 Aug 2023 16:13:58 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v2]
In-Reply-To: <UoY481q88LjxvLidm6IkUqeKcjEc02n7j2Crj1zZHpo=.f5d6ceda-5fb3-4a1d-a459-6d9b89d93f77@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <d6b7vYWOgx01RENzXN3alvOFRQHWiYo7L-bwEn-q630=.4c1c9621-8a38-44f2-968b-78ea7f8aad38@github.com>
 <UoY481q88LjxvLidm6IkUqeKcjEc02n7j2Crj1zZHpo=.f5d6ceda-5fb3-4a1d-a459-6d9b89d93f77@github.com>
Message-ID: <mne2M19XILALlrU8EhBeYTg0xBGe77PvbM1Yzgkf4r8=.dc06b872-d736-4ffe-bd4f-a3d4b1541014@github.com>

On Fri, 25 Aug 2023 10:24:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Improve test coverage
>>  - Incorporate review comments from Daniel
>
> src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java line 988:
> 
>> 986:     private static void ensureClassInitialized(Class<?> c) {
>> 987:         try {
>> 988:             MethodHandles.lookup().ensureInitialized(c);
> 
> Hello Sean, should we check if there are any implications, like on startup performance, of using `MethodHandles` in this `BootstrapLogger`?

Thanks for the comments Jai. Latest patch just pushed resolved this -  in any case, it looks like the MethodHandles class is loaded very early in the module system  (even before the application code)


[0.026s][info][class,load] java.util.HexFormat source: shared objects file
[0.026s][info][class,load] java.util.concurrent.atomic.AtomicInteger source: shared objects file
[0.026s][info][class,load] jdk.internal.module.ModuleBootstrap source: shared objects file
[0.026s][info][class,load] java.lang.invoke.MethodHandles source: shared objects file
[0.026s][info][class,load] java.lang.invoke.MemberName$Factory source: shared objects file
[0.026s][info][class,load] java.lang.invoke.MethodHandles$Lookup source: shared objects file
[0.027s][info][class,load] java.lang.StrictMath source: shared objects file


[0.032s][info][class,load] java.security.SecureClassLoader$DebugHolder source: shared objects file
[0.032s][info][class,load] sun.security.util.Debug source: shared objects file
[0.033s][info][class,load] SignedLoggerFinderTest source: file:/MYREPO/jdk/open/test/jdk/JTwork/classes/0/java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.d/
[0.033s][info][class,load] java.lang.NamedPackage source: shared objects file
[0.033s][info][class,load] jdk.internal.misc.MainMethodFinder source: shared objects file
[0.033s][info][class,load] jdk.internal.misc.PreviewFeatures source: shared objects file

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305854273

From coffeys at openjdk.org  Fri Aug 25 16:14:01 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 25 Aug 2023 16:14:01 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v3]
In-Reply-To: <WQoLVQ_yB-ZK5Vdt5xefP-lNlbxqzmIySDt-kGdJWdw=.7a016328-e73b-4318-afef-07a45f8cabcc@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <ioc3HaWAtrg_Jvp3uqiSwiEGMKSvKb7foyGRi7PRy6w=.b1b38d11-f80c-4619-8348-81abd1a330bc@github.com>
 <WQoLVQ_yB-ZK5Vdt5xefP-lNlbxqzmIySDt-kGdJWdw=.7a016328-e73b-4318-afef-07a45f8cabcc@github.com>
Message-ID: <C4t8KsQo0cU_yThQiBIaAO0J06Dg6l32jOVNQq_bjzI=.c6cba87d-388b-49fd-a613-c0312dc367e5@github.com>

On Fri, 25 Aug 2023 10:33:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/logger/LazyLoggers.java line 425:
>> 
>>> 423:      */
>>> 424:     public static final Logger getLogger(String name, Module module) {
>>> 425:         BootstrapLogger.detectBackend();
>> 
>> Suggestion:
>> 
>>         // triggers detection of the backend
>>         BootstrapLogger.detectBackend();
>
> Hello Daniel, Sean, I couldn't understand the need for this method. The changes to `BootstrapLogger` in this PR removes the initialization of `DetectBackend` class while holding a lock on `BootstrapLogger` class in the `BootstrapLogger.useLazyLoggers` method. Wouldn't that be enough?

a deadlock is still possible Jai with forcing class initialization here. The new auto test confirms.

here's the interesting calling stack :

"Thread-0" #31 [2241170] prio=5 os_prio=0 cpu=32.77ms elapsed=13.69s tid=0x00007fb0b019bf10 nid=2241170 waiting on condition  [0x00007fb01ac29000]
   java.lang.Thread.State: RUNNABLE
	at jdk.internal.logger.BootstrapLogger.useLazyLoggers(java.base at 22-internal/BootstrapLogger.java:952)
	- waiting on the Class initialization monitor for jdk.internal.logger.BootstrapLogger$DetectBackend
	at jdk.internal.logger.LazyLoggers.getLazyLogger(java.base at 22-internal/LazyLoggers.java:462)
	at jdk.internal.logger.LazyLoggers.getLogger(java.base at 22-internal/LazyLoggers.java:437)
	at java.lang.System.getLogger(java.base at 22-internal/System.java:1822)
	at jdk.internal.event.EventHelper.isLoggingSecurity(java.base at 22-internal/EventHelper.java:148)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1305856639

From iselo+openjdk at raccoons.co  Fri Aug 25 16:38:29 2023
From: iselo+openjdk at raccoons.co (Oleksii Kucheruk)
Date: Fri, 25 Aug 2023 19:38:29 +0300
Subject: Thanks for re-play
Message-ID: <CACg0bd1Qf=Q0GHhtBVFp-GQ8=vVRDxicetwAHRBPAeTddHu=yg@mail.gmail.com>

Hi there!

I?ve e nominate my self to be a change provoker of this community!

I?ve propose to stop kissing everyones butts only because of the history,
go this evening to your favorite bar get drunk, talk to people about your
beliefs and in the morning or next day assemble all your craziest hidden
thoughts that you have documented inGoogle Keep about OOP in Java in form
of proposal to discuss  and share it soon with the community. Because the
people in Core who do not believe in OOP will not improve it. All the tries
interpreting of ?_fast_invokevfinal? approaches will not make significant
change between Java 10 and 30 ambitions.

You free to remove me from here, I appreciate you read it. Reboot your self.

I?ve already have learned from you something. I appreciate it.

ISelo means in Ukrainian - I?m village man who can ask stupid questions but
sometimes they could be essential.

Please vote, for your self!

Kind regards and sorry for disturbing your.
Young and stupid, but I believe ;)
iselo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230825/f088c6d0/attachment.htm>

From mandy.chung at oracle.com  Fri Aug 25 16:43:09 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 25 Aug 2023 09:43:09 -0700
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <bf8f0ba8-25d2-bf2f-5eab-6e2191bbe69a@oracle.com>

Vote: yes

Mandy


From mandy.chung at oracle.com  Fri Aug 25 16:43:25 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 25 Aug 2023 09:43:25 -0700
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <7be3876c-0282-1a46-50ef-7806d0178d34@oracle.com>

Vote: Yes

Mandy


From mandy.chung at oracle.com  Fri Aug 25 16:43:26 2023
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Fri, 25 Aug 2023 09:43:26 -0700
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <0f268d44-437d-6dbe-664b-2ae2ffb86045@oracle.com>

Vote: yes

Mandy


From roger.riggs at oracle.com  Fri Aug 25 16:57:04 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Aug 2023 12:57:04 -0400
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <c07d1d9b-cc09-7b70-67e6-fa3cd27f913f@oracle.com>

Vote: Yes

On 8/25/23 11:24 AM, Roger Riggs wrote:
> I hereby nominate Michael McMahon to Membership in the Core Libraries 
> Group 


From roger.riggs at oracle.com  Fri Aug 25 16:57:21 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Aug 2023 12:57:21 -0400
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <116b47a6-fe44-bede-171c-d975624ead78@oracle.com>

Vote: Yes

On 8/25/23 11:23 AM, Roger Riggs wrote:
>
> I hereby nominate Lance Andersen to Membership in the Core Libraries 
> Group
>


From roger.riggs at oracle.com  Fri Aug 25 16:57:38 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Aug 2023 12:57:38 -0400
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <89cfcb0c-696d-4cb6-8426-ee0e63d8e6db@oracle.com>

Vote: Yes

On 8/25/23 11:23 AM, Roger Riggs wrote:
> I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group 


From mchung at openjdk.org  Fri Aug 25 17:26:13 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 25 Aug 2023 17:26:13 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <_gf28X1okZyVfbHhRjDSB3ehFyuytHFyxF4f5Z5qb4E=.6f77ccf6-5f84-485b-ad26-4bc79874e6de@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
 <_gf28X1okZyVfbHhRjDSB3ehFyuytHFyxF4f5Z5qb4E=.6f77ccf6-5f84-485b-ad26-4bc79874e6de@github.com>
Message-ID: <iNJ76CKeRN4XiNlhhfRKul7mjEzZYdai66z_EtjxC9o=.e4e9419a-a539-4a95-ad13-024eac075539@github.com>

On Fri, 25 Aug 2023 13:35:04 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review feedback and javadoc clean up
>
> src/hotspot/share/classfile/javaClasses.cpp line 2990:
> 
>> 2988:     // direct calls for private and/or final non-static methods.
>> 2989:     flags |= java_lang_invoke_MemberName::MN_IS_METHOD;
>> 2990:   }
> 
> Both the is_static and the else block set java_lang_invoke_MemberName::MN_IS_METHOD.  Do we need to differentiate between the two cases or can they be collapsed?

yes they can be collapsed.  I will update it.

> src/java.base/share/classes/java/lang/ClassFrameInfo.java line 48:
> 
>> 46:     }
>> 47:     boolean isHidden() {
>> 48:         return SharedSecrets.getJavaLangInvokeAccess().isHiddenMember(flags & MEMBER_INFO_FLAGS);
> 
> Is it better to cache the JLIA in a static final similar to what StackFrameInfo does?

either way is fine.  I can add a static field.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305941281
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1305942726

From kvn at openjdk.org  Fri Aug 25 18:50:19 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Aug 2023 18:50:19 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v22]
In-Reply-To: <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <PkSyELVYJ0ZUO3udhmW-V30AYoa5XYA9jZ-IzoogSJI=.31dcc4f0-2738-4979-ac29-5679f6297143@github.com>
 <q1BS6xbmCwurWxTfiGuWXwk921hQapX1vdOACcEx0H4=.1ea9f870-f9ca-4dd1-88ef-e76bba9bc38f@github.com>
 <WaE_HqgYyTUc_e1VVT4I3j_QnV8uvRa2nd62igBf-ME=.32799d89-f74b-4b14-ac7c-ed6d8a777fa6@github.com>
 <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
Message-ID: <wUGHDMCZZSDKLiZk3klDq8qBNueAcbbmbN-qCj5kwJw=.7ee68cdf-8d31-4c8f-8405-e5ebe82af2ca@github.com>

On Thu, 24 Aug 2023 06:23:29 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
>> 
>> Hi Vladimir,
>> 
>> Thank you for the suggestion! 
>> Currently, AVX512sort is doing well for Random, Repeated and Shuffle patterns of input data. The regressions are observed for Staggered (Wave) pattern of input data. 
>> Will investigate the regressions and adjust the implementations to address them.
>> 
>> Thanks,
>> Vamsi
>
>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
> 
> Hello Vladimir (@vnkozlov) ,
> 
> As per your suggestion, the implementation was adjusted to address the regressions caused for STAGGER and REPEATED type of input data patterns. 
> Please see below the new JMH performance data using the adjusted implementation.
> 
> In the new implementation, we don't call the AVX512 sort intrinsic at the top level (`Arrays.sort()`) . Instead, we take a decomposed or a 'building blocks' approach where we only intrinsify  (using AVX512 instructions) the partitioning and small array sort functions used in the current baseline ( `DualPivotQuickSort.sort()` ). Since the current baseline has logic to detect and sort special input patterns like STAGGER, we fallback to the current baseline instead of using AVX512 partitioning and sorting (which works best for RANDOM, REPEATED and SHUFFLE patterns).
> 
> Data below shows `Arrays.sort()` performance comparison between the current **Java baseline (DPQS)** vs. **AVX512 sort** (this PR)  using the `ArraysSort.java` JMH [benchmark](https://github.com/openjdk/jdk/pull/13568/files#diff-dee51b13bd1872ff455cec2f29255cfd25014a5dd33dda55a2fc68638c3dd4b2) provided in the PR for [JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)](https://github.com/openjdk/jdk/pull/13568/files#top) ( #13568)
> 
> - The following command line was used to run the benchmarks: ` java -jar $JDK_HOME/build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -jvmArgs "-XX:CompileThreshold=1 -XX:-TieredCompilation" ArraysSort`
> - The scores shown are the average time (us/op),  thus lower is better. The last column towards the right shows the speedup. 
> 
> 
> |	Benchmark	|	Mode	|	Size	|	Baseline DPQS (us/op)	|	AVX512 partitioning & sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	800	|	6.7	|	4.8	|	1.39x	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	7000	|	234.1	|	51.5	|	**4.55x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	50000	|	2155.9	|	470.0	|	**4.59x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	300000	|	15076.3	|	3391.3	|	**4.45x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	2000000	|	116445.5	|	27491.7	|	**4.24x**	|
> |	ArraysSort.Double.testSort	|	REPEATED	|	800	|	2.3	|	1.7	|	1.35x	|
> |	ArraysSort.Double.testSort	|	REPEATED	|	7000	|	23.3	|	12.1	|	**1.92x**	|
> |	ArraysSort.Double.testSort	|...

@vamsi-parasa I submitted our testing of latest v28 version. It found issue in `ArraysSort.java` new benchmark file. You missed `,`after year in copyright line:

 * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1693790589

From kvn at openjdk.org  Fri Aug 25 18:50:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Aug 2023 18:50:21 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
Message-ID: <vo3Hui5umBf0wpTOInuzWI52aD3AQ_-Y9f0xkEwLA4c=.0b543fee-c809-43d8-a825-b84f2b6c63d7@github.com>

On Fri, 25 Aug 2023 01:57:41 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import in Arrays.java

After I fixed it Tier1 passed and I submitted other tiers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1693791251

From prappo at openjdk.org  Fri Aug 25 19:00:22 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 25 Aug 2023 19:00:22 GMT
Subject: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex,
 length, initialValue)
In-Reply-To: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
References: <xh6T_mvwyT2yxFZoK-6yg3eudfeRmTt3D_AxR_eScqE=.2c66d4d6-f0f0-4f24-8892-ea2aa5b56c2d@github.com>
Message-ID: <nUfIroQEyoEmWv4QbLtrs3WDLpIrkKvxW_Vxk7W1QYg=.1d42ec34-5c9f-4e85-869e-e5e3fa3ee9f0@github.com>

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR adds an internal method to calculate hash code from the provided integer array, offset and length into that array, and the initial hash code value.
> 
> Current options for calculating a hash code for int[] are inflexible. It's either ArraysSupport.vectorizedHashCode with an offset, length and initial value, or Arrays.hashCode with just an array.
> 
> For an arbitrary int[], unconditional vectorization might be unwarranted or puzzling. Unfortunately, it's the only hash code method that operates on an array subrange or accepts the initial hash code value.
> 
> A more convenient method could be added and then used, for example, here:
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680
> 
> * https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362
> 
> This PR adds such a method and provides tests for it. Additionally, this PR adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, behaviour which was specified but untested.

To Skara bots: keep this PR alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1693802282

From duke at openjdk.org  Fri Aug 25 19:02:19 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Fri, 25 Aug 2023 19:02:19 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v22]
In-Reply-To: <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <PkSyELVYJ0ZUO3udhmW-V30AYoa5XYA9jZ-IzoogSJI=.31dcc4f0-2738-4979-ac29-5679f6297143@github.com>
 <q1BS6xbmCwurWxTfiGuWXwk921hQapX1vdOACcEx0H4=.1ea9f870-f9ca-4dd1-88ef-e76bba9bc38f@github.com>
 <WaE_HqgYyTUc_e1VVT4I3j_QnV8uvRa2nd62igBf-ME=.32799d89-f74b-4b14-ac7c-ed6d8a777fa6@github.com>
 <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
Message-ID: <pjjbfHZkqTQxGyFkgQ-U6wFNgJo7a4D7jsicpcVQA_4=.56c8bf27-ae2d-441a-b034-542c35eb8203@github.com>

On Thu, 24 Aug 2023 06:23:29 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
>> 
>> Hi Vladimir,
>> 
>> Thank you for the suggestion! 
>> Currently, AVX512sort is doing well for Random, Repeated and Shuffle patterns of input data. The regressions are observed for Staggered (Wave) pattern of input data. 
>> Will investigate the regressions and adjust the implementations to address them.
>> 
>> Thanks,
>> Vamsi
>
>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
> 
> Hello Vladimir (@vnkozlov) ,
> 
> As per your suggestion, the implementation was adjusted to address the regressions caused for STAGGER and REPEATED type of input data patterns. 
> Please see below the new JMH performance data using the adjusted implementation.
> 
> In the new implementation, we don't call the AVX512 sort intrinsic at the top level (`Arrays.sort()`) . Instead, we take a decomposed or a 'building blocks' approach where we only intrinsify  (using AVX512 instructions) the partitioning and small array sort functions used in the current baseline ( `DualPivotQuickSort.sort()` ). Since the current baseline has logic to detect and sort special input patterns like STAGGER, we fallback to the current baseline instead of using AVX512 partitioning and sorting (which works best for RANDOM, REPEATED and SHUFFLE patterns).
> 
> Data below shows `Arrays.sort()` performance comparison between the current **Java baseline (DPQS)** vs. **AVX512 sort** (this PR)  using the `ArraysSort.java` JMH [benchmark](https://github.com/openjdk/jdk/pull/13568/files#diff-dee51b13bd1872ff455cec2f29255cfd25014a5dd33dda55a2fc68638c3dd4b2) provided in the PR for [JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)](https://github.com/openjdk/jdk/pull/13568/files#top) ( #13568)
> 
> - The following command line was used to run the benchmarks: ` java -jar $JDK_HOME/build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -jvmArgs "-XX:CompileThreshold=1 -XX:-TieredCompilation" ArraysSort`
> - The scores shown are the average time (us/op),  thus lower is better. The last column towards the right shows the speedup. 
> 
> 
> |	Benchmark	|	Mode	|	Size	|	Baseline DPQS (us/op)	|	AVX512 partitioning & sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	800	|	6.7	|	4.8	|	1.39x	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	7000	|	234.1	|	51.5	|	**4.55x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	50000	|	2155.9	|	470.0	|	**4.59x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	300000	|	15076.3	|	3391.3	|	**4.45x**	|
> |	ArraysSort.Double.testSort	|	RANDOM	|	2000000	|	116445.5	|	27491.7	|	**4.24x**	|
> |	ArraysSort.Double.testSort	|	REPEATED	|	800	|	2.3	|	1.7	|	1.35x	|
> |	ArraysSort.Double.testSort	|	REPEATED	|	7000	|	23.3	|	12.1	|	**1.92x**	|
> |	ArraysSort.Double.testSort	|...

> @vamsi-parasa I submitted our testing of latest v28 version. It found issue in `ArraysSort.java` new benchmark file. You missed `,`after year in copyright line:
> 
> ```
>  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> ```

Thank you, Vladimir!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1693804429

From erikj at openjdk.org  Fri Aug 25 20:45:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 25 Aug 2023 20:45:17 GMT
Subject: Integrated: 8314483: Optionally override copyright header in generated
 source
In-Reply-To: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
References: <BVKLQouGtIOWvP1Pgh1WvCJdivajkJE7UdVd4Y0qpuY=.a5b6507e-ee2f-4bc9-85fa-61d9b5ed1f90@github.com>
Message-ID: <3x10O7FEG3JRiRXn4LmT3cST7JY7Hv5tJaa1alv5m04=.07ca1039-3c93-4d88-bb8e-ba043b504818@github.com>

On Fri, 18 Aug 2023 14:22:49 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> In the JDK build we have various build tools that generate source code from data files. For most of these tools, the source files are based on template files, which already have copyright headers, but for some, the complete source file is generated by the tool, which is providing the copyright header programatically. For the latter, we would like to implement an override mechanism in each tool so that we can change the copyright header from a custom makefile.

This pull request has now been integrated.

Changeset: 837d2e1c
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/837d2e1cac7e006506cd4cff03862d7fbcd42140
Stats:     46 lines in 4 files changed: 37 ins; 1 del; 8 mod

8314483: Optionally override copyright header in generated source

Reviewed-by: dholmes, iris

-------------

PR: https://git.openjdk.org/jdk/pull/15346

From rriggs at openjdk.org  Fri Aug 25 21:05:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Aug 2023 21:05:20 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v5]
In-Reply-To: <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BxhfHqiwa57t2RIWDzsq5wX28R1HqmURdv-y1naX0xs=.e069302b-64cb-404d-9a95-73860fcc9051@github.com>
Message-ID: <r246jjnAwk3YoX00tOaWQ6pxI4khaOobR1fJ4VrN-1U=.cbed0d58-30b1-423f-8293-99260a973a63@github.com>

On Thu, 24 Aug 2023 18:44:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review feedback and javadoc clean up

src/java.base/share/classes/java/lang/StackWalker.java line 55:

> 53:  * available but not the {@link StackFrame#getDeclaringClass() Class reference}.
> 54:  * The {@code Class} reference can be accessed if {@link Option#RETAIN_CLASS_REFERENCE}
> 55:  * RETAIN_CLASS_REFERENCE} option is set.

Double `}` in the link.

src/java.base/share/classes/java/lang/StackWalker.java line 249:

> 247:          *
> 248:          * @throws UnsupportedOperationException if the {@code StackWalker} is of
> 249:          *         {@link Kind#CLASS_INFO CLASS_INFO} kind

Other CLASS_INFO methods use the javadoc:

if the StackWalker collects class only information

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306129921
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306143327

From kvn at openjdk.org  Fri Aug 25 22:07:22 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 25 Aug 2023 22:07:22 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
Message-ID: <oFL692TCzBpuGQWhrLUupjz3MsUYTh5UVMrYPB1sbY8=.761dc8e8-6b82-440d-b934-9a8bfc33a2ed@github.com>

On Fri, 25 Aug 2023 01:57:41 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary import in Arrays.java

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4143:

> 4141:     log_info(library)("Loaded library %s, handle " INTPTR_FORMAT, JNI_LIB_PREFIX "x86_64" JNI_LIB_SUFFIX, p2i(libx86_64));
> 4142: 
> 4143:     if (UseAVX > 2 && VM_Version::supports_avx512dq()) {

This check should be done before you locate and load library

src/hotspot/share/opto/library_call.cpp line 5218:

> 5216:   BasicType bt = elem_type->basic_type();
> 5217:   stubAddr = StubRoutines::select_array_partition_function(bt);
> 5218:   if (stubAddr == nullptr) return false;

I see now how you check for AVX512 support.

You bailout here if address for stubs is not set and I see that you have `if (UseAVX > 2 && VM_Version::supports_avx512dq())` check in stubGenerator.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1306180258
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1306179926

From mchung at openjdk.org  Fri Aug 25 22:22:43 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 25 Aug 2023 22:22:43 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
> instead and such stack walker will save the overhead (1) to extract the method information
> and (2) the memory used for the stack walking.   In addition, this can also fix
> 
> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
> 
> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
> This provides a simple way for existing code, for example logging frameworks, to take advantage of
> this enhancement with the least change as it can keep the existing function for traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(interestingClasses::contains)
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> #### Javadoc & specdiff
> 
> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
> 
> #### Alternatives Considered
> One alternative is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> Another alte...

Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:

 - fixup javadoc
 - Review feedback: move JLIA to ClassFrameInfo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15370/files
  - new: https://git.openjdk.org/jdk/pull/15370/files/a3a44575..4c5c5d79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=04-05

  Stats: 19 lines in 4 files changed: 3 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From sviswanathan at openjdk.org  Fri Aug 25 23:20:15 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 25 Aug 2023 23:20:15 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <vo3Hui5umBf0wpTOInuzWI52aD3AQ_-Y9f0xkEwLA4c=.0b543fee-c809-43d8-a825-b84f2b6c63d7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <vo3Hui5umBf0wpTOInuzWI52aD3AQ_-Y9f0xkEwLA4c=.0b543fee-c809-43d8-a825-b84f2b6c63d7@github.com>
Message-ID: <GX14R2E1qRFIfvwaECYAMO8BmsGGf7wZNY6uI4MqNrs=.4161af27-4ae9-4add-a2b1-5f3aae41fa69@github.com>

On Fri, 25 Aug 2023 18:46:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary import in Arrays.java
>
> After I fixed it Tier1 passed and I submitted other tiers.

@vnkozlov The  _mm512_set1_*  are all C/C++ intrinsics for Intel instructions documented at https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html. Both GCC and Microsoft C implements them.
https://learn.microsoft.com/en-us/cpp/intrinsics/x64-amd64-intrinsics-list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1694025189

From duke at openjdk.org  Sat Aug 26 01:43:26 2023
From: duke at openjdk.org (duke)
Date: Sat, 26 Aug 2023 01:43:26 GMT
Subject: Withdrawn: 8311175: Move BufWriter::asByteBuffer to BufWriterImpl
In-Reply-To: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
References: <sEKITMKa0yBPrV7RTKYa0_GGSOss8a9T7GaOQpLaEYk=.f7ad0b39-bc77-4589-a8de-ef5132387e6c@github.com>
Message-ID: <4_WbJVshGnf4y4WIa0Mkl-bKFHAJALk_iO5BwFQkdZw=.2f629d75-242b-4648-ae6c-148c90c43b2c@github.com>

On Fri, 30 Jun 2023 14:43:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> As discussed on the mailing list https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html, BufWriter::asByteBuffer has a behavior not suitable for API and is only used by internal StackMapGenerator/StackCounter, so it will be converted to an internal API.
> 
> Somehow the ByteBuffer needs to be sliced, or StackMapGenerator encounters IOOBE. Not sure what the exact cause was.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14736

From duke at openjdk.org  Sat Aug 26 03:15:22 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Sat, 26 Aug 2023 03:15:22 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
Message-ID: <zyrheDt3GjENT9qWqOWQRBVg_jzLIfTobEgETpB1jkY=.5d0c9663-2653-44a8-af88-fb13dc8bb0c2@github.com>

On Tue, 18 Jul 2023 01:49:17 GMT, ??? <duke at openjdk.org> wrote:

>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*" 
>> make test TEST="micro:java.lang.Longs.toString*" 
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
>> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
>> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
>> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
>> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
>> 
>> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
>> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
>> 
>> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
>> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
>> 
>> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
>> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
>> 
>> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
>> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
>> 
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
>> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
>> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  5.036 ? 0.005  us/op (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert bounds check

@AlanBateman can you help me to review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1694137748

From Alan.Bateman at oracle.com  Sat Aug 26 07:12:13 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 26 Aug 2023 08:12:13 +0100
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <c209638e-2578-790c-7085-014ad2bdead9@oracle.com>

Vote: yes


From Alan.Bateman at oracle.com  Sat Aug 26 07:12:24 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 26 Aug 2023 08:12:24 +0100
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <5b6c4e69-ee10-abb2-da68-f113234139fa@oracle.com>

Vote: yes

From Alan.Bateman at oracle.com  Sat Aug 26 07:12:34 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 26 Aug 2023 08:12:34 +0100
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <6e475053-ebfc-5068-828d-779acad3ed7a@oracle.com>

Vote: yes

From forax at openjdk.org  Sat Aug 26 09:28:24 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 26 Aug 2023 09:28:24 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
Message-ID: <nqdJruPxZVRGPZyDFilBVEa9rZ7s8uKT3NSEyPwPPe0=.419a5ab2-b5cf-4c0f-b343-a7c2bece095e@github.com>

On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixup javadoc
>  - Review feedback: move JLIA to ClassFrameInfo

src/java.base/share/classes/java/lang/ClassFrameInfo.java line 34:

> 32:     static final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();
> 33: 
> 34:     protected Object classOrMemberName;    // Class or ResolvedMemberName initialized by VM

I believe that the package-private access is enough here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306387977

From forax at openjdk.org  Sat Aug 26 09:35:20 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 26 Aug 2023 09:35:20 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
Message-ID: <hP9emfo32qIeqeOLqC5I2aEbhkEOOf2L03zC2wZLxdk=.430739af-ea30-4cbc-bfaa-541a84c4c4eb@github.com>

On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixup javadoc
>  - Review feedback: move JLIA to ClassFrameInfo

src/java.base/share/classes/java/lang/StackFrameInfo.java line 82:

> 80: 
> 81:         {
> 82:             // Get a snapshot of type which doesn't get changed by racing threads.

Also the constructed MethodType is non mutable

src/java.base/share/classes/java/lang/StackFrameInfo.java line 94:

> 92:                 type = JLIA.getMethodType(sig, declaringClass().getClassLoader());
> 93:             }
> 94:             assert type instanceof MethodType : "bad method type " + type;

Not sure this assert is useful given the next instruction is a cast to MethodType

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306389071
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306389160

From forax at openjdk.org  Sat Aug 26 09:45:23 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 26 Aug 2023 09:45:23 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
Message-ID: <QQCudsmzEEs57rdJx1nTst_DHDXLVkvst8wCiAeN7Xw=.8c4c25d1-babe-4481-a931-456669cf423c@github.com>

On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixup javadoc
>  - Review feedback: move JLIA to ClassFrameInfo

src/java.base/share/classes/java/lang/StackWalker.java line 81:

> 79:  *     Optional<Class<?>> callerClass = walker.walk(s ->
> 80:  *             s.map(StackFrame::getDeclaringClass)
> 81:  *              .filter(interestingClasses::contains)

Usually it's more `.filter(Predicate.not(implClasses::contains))`

src/java.base/share/classes/java/lang/StackWalker.java line 88:

> 86:  * {@snippet lang="java" :
> 87:  *     List<StackFrame> stack = StackWalker.getInstance().walk(s ->
> 88:  *             s.limit(10).collect(Collectors.toList()));

`s.limit(10).toList()`

src/java.base/share/classes/java/lang/StackWalker.java line 505:

> 503:      */
> 504:     public static StackWalker getInstance(Kind kind, Option... options) {
> 505:         return getInstance(Objects.requireNonNull(kind), Set.of(Objects.requireNonNull(options)));

Set.of() already does a NPE check

src/java.base/share/classes/java/lang/StackWalker.java line 649:

> 647:      *         s.dropWhile(f -> f.getClassName().startsWith("com.foo."))
> 648:      *          .limit(10)
> 649:      *          .collect(Collectors.toList()));

`.toList())`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390180
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390266
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390553
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1306390713

From dl at openjdk.org  Sat Aug 26 13:04:57 2023
From: dl at openjdk.org (Doug Lea)
Date: Sat, 26 Aug 2023 13:04:57 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v17]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <lEICe3NsZgYx71vfutgPTleI0kWgiF7A7W5RkQrydws=.2d01638a-9011-44e1-b669-a0e6ede3ea88@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea 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 61 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8288899
 - Clear interrupts at top level
 - Conditionalize new tests
 - Isolate unexpected interrupt status issues
 - Ordering for termination triggering
 - Resync CloseTest
 - Merge branch 'openjdk:master' into JDK-8288899
 - Ensure each CloseTest test runs in a new thread
 - Run close tests in seperate threads
 - Ensure thread not interrupted when testing close
 - ... and 51 more: https://git.openjdk.org/jdk/compare/4c8c4ab2...6bc1b607

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/5a4131f7..6bc1b607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=15-16

  Stats: 3857 lines in 208 files changed: 2655 ins; 614 del; 588 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From alanb at openjdk.org  Sat Aug 26 13:44:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Aug 2023 13:44:08 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase
In-Reply-To: <X453xaUIPaOuRuCqTo9o-q0yI2Hdk3ujtmd0umpgkco=.be63945d-6506-43b6-9f4c-d980492b303e@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <X453xaUIPaOuRuCqTo9o-q0yI2Hdk3ujtmd0umpgkco=.be63945d-6506-43b6-9f4c-d980492b303e@github.com>
Message-ID: <yzYVji84WvFQd7ZyxtZam5pnTN2GRHYcqR5vG72aedc=.e9195274-1bea-4823-ac1b-bd897eae4020@github.com>

On Mon, 14 Aug 2023 10:06:57 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> yes this is of course AIX specific. However I found something that might be similar on Windows, there we have in case of successful LoadLibrary in os::dll_load calls to SymbolEngine::recalc_search_path(); However I did not check the details on this; but for AIX we have a real problem with outdated/incomplete stacks in hs_err files.

Right now, you've got concerns/objections from two potential reviewers so it would be better to see if there are other options to help the error logs on AIX.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694344116

From chegar999 at gmail.com  Sun Aug 27 11:58:56 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Sun, 27 Aug 2023 12:58:56 +0100
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <6e475053-ebfc-5068-828d-779acad3ed7a@oracle.com>
References: <6e475053-ebfc-5068-828d-779acad3ed7a@oracle.com>
Message-ID: <C9636157-B6D5-4E5A-BC79-485201307240@gmail.com>

Vote: yes

-Chris


> On 26 Aug 2023, at 08:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> ?Vote: yes

From chegar999 at gmail.com  Sun Aug 27 11:59:20 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Sun, 27 Aug 2023 12:59:20 +0100
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <c209638e-2578-790c-7085-014ad2bdead9@oracle.com>
References: <c209638e-2578-790c-7085-014ad2bdead9@oracle.com>
Message-ID: <C1882DC9-D369-47B0-8465-542B2F395191@gmail.com>

Vote: yes

-Chris

> On 26 Aug 2023, at 08:13, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> ?Vote: yes
> 

From chegar999 at gmail.com  Sun Aug 27 11:59:43 2023
From: chegar999 at gmail.com (Chris Hegarty)
Date: Sun, 27 Aug 2023 12:59:43 +0100
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <7f746607-6121-b80e-5418-9ecb1192f500@oracle.com>
References: <7f746607-6121-b80e-5418-9ecb1192f500@oracle.com>
Message-ID: <11DDC549-D6CF-4231-9A41-E5AA14FB9D92@gmail.com>

Vote: yes

-Chris

> On 25 Aug 2023, at 16:45, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> ?Vote: yes
> 
> -Joe
> 
>> On 8/25/23 8:23 AM, Roger Riggs wrote:
>> I hereby nominate Lance Andersen to Membership in the Core Libraries Group 
> 

From dl at openjdk.org  Sun Aug 27 12:37:53 2023
From: dl at openjdk.org (Doug Lea)
Date: Sun, 27 Aug 2023 12:37:53 GMT
Subject: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java
 failed with "InterruptedException: sleep interrupted" [v18]
In-Reply-To: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
References: <rOtHpQFUXMSjR-R1iagDcpk4oHsdKIQ_m0tZDsypCO8=.3a4e31e6-2acd-4021-b765-27c26855bef8@github.com>
Message-ID: <Dcab2qE2q5P8crR4KHQjaA5IUNO9VvspT-xPRI_OTRI=.b9087c7f-b78a-4516-badf-2e544cad301b@github.com>

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" and related issues.
> 
> This is a major ForkJoin update (and hard to review -- sorry) that finally addresses incompatibilities between ExecutorService and ForkJoinPool (which claims to implement it), with the goal of avoiding continuing bug reports and incompatibilities. Doing this required reworking internal control to use phaser/seqlock-style versioning schemes (affecting nearly every method) that ensure consistent data structures and actions without requiring global synchronization or locking on every task execution that would massively degrade performance. The previous lack of a solution to this was the main reason for these incompatibilities.

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Avoid unwanted jtreg interrupts; undo unnecessary changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14301/files
  - new: https://git.openjdk.org/jdk/pull/14301/files/6bc1b607..4b12ddc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14301&range=16-17

  Stats: 86 lines in 4 files changed: 13 ins; 21 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/14301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14301/head:pull/14301

PR: https://git.openjdk.org/jdk/pull/14301

From dholmes at openjdk.org  Mon Aug 28 02:29:18 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Aug 2023 02:29:18 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <VdNeGwdmluvTB-MxwQz5UAUGXhw6NoN3YkuKQp5yqLU=.d208acdc-4441-4ba8-beb8-560d7f535311@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is  far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues.

I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1694907802

From dholmes at openjdk.org  Mon Aug 28 03:02:13 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Aug 2023 03:02:13 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v6]
In-Reply-To: <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>
Message-ID: <6WFNbWZR3EbbwLcduBU7cgKqSmbNlgwSIB4icfoWU5Q=.fe30362b-69aa-4ab1-ac58-d7b3372201f1@github.com>

On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8314491-jexec-resolve-symlink
>  - declare error in-place
>  - remove unused imports
>  - Review comment: use /proc/self/exe as the backup option
>  - Merge branch 'master' into 8314491-jexec-resolve-symlink
>  - correct copyright statement
>  - Use /proc/self/exec to identify path to the executable.
>  - Create failing test for jexec in PATH issue

Still good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15343#pullrequestreview-1597392639

From azeller at openjdk.org  Mon Aug 28 05:27:11 2023
From: azeller at openjdk.org (Arno Zeller)
Date: Mon, 28 Aug 2023 05:27:11 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
 <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
 <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>
Message-ID: <PAAwyDFEoXNEw3LDkKa6CqSJxpcfks7qfx4f-0T0oE0=.b60e7d57-0170-4b85-ba50-028b2cc45190@github.com>

On Fri, 25 Aug 2023 07:47:19 GMT, Arno Zeller <azeller at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessHandle/InfoTest.java line 304:
>> 
>>> 302:                     if (Platform.isWindows() && "BUILTIN\\Administrators".equals(whoami)) {
>>> 303:                         System.out.println("Test seems to be run as Administrator. " +
>>> 304:                                 "Check for user correctness is not possible.");
>> 
>> Is there an alternative way to determine the expected username? 
>> Perhaps by running a windows command or extracting it from the environment (System.getEnv("XX"))?
>
> I think you might use System.getProperty("user.name"). But I am not sure about domain names of users on Windows.
> I am also not sure why the user name is currently determined by creating a file - there might be a reason for this that is not obvious to me.

It seems that ProcessHandle.info()  returns **DOMAIN/USERNAME** on Windows but System.getProperty("user.name") only the **USERNAME**.
You can get **DOMAIN** and **USERNAME** on **Windows** by calling:
com.sun.security.auth.module.NTSystem NTSystem = new com.sun.security.auth.module.NTSystem();
String user = NTSystem.getName();
String domain = NTSystem.getDomain();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1306920852

From per-ake.minborg at oracle.com  Mon Aug 28 06:59:24 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 28 Aug 2023 06:59:24 +0000
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <DM6PR10MB4283763D0A294D71CAAFE836DAE0A@DM6PR10MB4283.namprd10.prod.outlook.com>

Vote: yes

-Per
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Sent: Friday, August 25, 2023 5:23 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: CFV: New Core Libraries Group Member: Lance Andersen


I hereby nominate Lance Andersen to Membership in the Core Libraries Group

Lance has been contributing to the OpenJDK at Oracle since 2007. He has been the JDBC spec lead since 2005 and an OpenJDK committer since day 1. He has extensive experience with Java EE, Databases and SQL and is improving the integrity and performance of Zip and JAR implementations.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/46c629cb/attachment-0001.htm>

From per-ake.minborg at oracle.com  Mon Aug 28 07:00:12 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 28 Aug 2023 07:00:12 +0000
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <DM6PR10MB42835C03E9E83785273DF676DAE0A@DM6PR10MB4283.namprd10.prod.outlook.com>

Vote: yes


  *   Per

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Sent: Friday, August 25, 2023 5:23 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs

I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group

Daniel has been contributing to the OpenJDK Core Libraries at Oracle
since 2012. He is leading the networking team and has made nearly 400
contributions to OpenJDK since JDK 6.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to
vote on this nomination. Votes must be cast in the open by replying to
this mailing list.

For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/a54d3ae4/attachment.htm>

From per-ake.minborg at oracle.com  Mon Aug 28 07:00:46 2023
From: per-ake.minborg at oracle.com (Per-Ake Minborg)
Date: Mon, 28 Aug 2023 07:00:46 +0000
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <DM6PR10MB42838D3C34DD111969B08014DAE0A@DM6PR10MB4283.namprd10.prod.outlook.com>

Vote: yes

-Per
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Sent: Friday, August 25, 2023 5:24 PM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: CFV: New Core Libraries Group Member: Michael McMahon

I hereby nominate Michael McMahon to Membership in the Core Libraries Group

Michael has been contributing to the OpenJDK Core Libraries since 2008,
originally at Sun Microsystems, now Oracle. He has deep networking
experience and has made more than 260 contributions to OpenJDK.

Votes are due by September 8th, 2023.

Only current Members of the Core Libraries Group [1] are eligible to
vote on this nomination. Votes must be cast in the open by replying to
this mailing list For Lazy Consensus voting instructions, see [2].

Roger Riggs

[1] https://openjdk.org/census#core-libs

[2] https://openjdk.org/groups/#member-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/0bddc31c/attachment.htm>

From mbaesken at openjdk.org  Mon Aug 28 07:05:13 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Aug 2023 07:05:13 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <VdNeGwdmluvTB-MxwQz5UAUGXhw6NoN3YkuKQp5yqLU=.d208acdc-4441-4ba8-beb8-560d7f535311@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
 <VdNeGwdmluvTB-MxwQz5UAUGXhw6NoN3YkuKQp5yqLU=.d208acdc-4441-4ba8-beb8-560d7f535311@github.com>
Message-ID: <SnM2uIIiFvqw2u72KsdhluvTYNXmqdETub-k1DQvmVc=.e0aa1c9d-acf6-4b71-bd6e-f291c54942c6@github.com>

On Mon, 28 Aug 2023 02:26:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but looking at the hotspot part of this I do not like the code in jvm.cpp at all - it is far too messy. I expected to see a simple interface to os::dlopen which then handles all the platform specific issues.
> 
> I'm also somewhat dubious about having all the JDK code use a VM interface for this, The usual coupling to the VM is to just provide native implementations of core library methods, not to have the VM provide a general purpose utility interface like dynamic library loading.


Hi David, so would you prefer to call into 'os::dll_load' (probably you meant that) instead ?  That would indeed make the coding smaller and less 'messy' .
However 'os::dll_load' has no flags parameter but uses a default, have to check if this might be a problem ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1695142975

From mbaesken at openjdk.org  Mon Aug 28 07:31:12 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Aug 2023 07:31:12 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <dz875Wg1UGzws9xBWcSHUM6nlPWwP2z1AdXyY-deyRs=.f0a9093e-2313-4693-b64f-3cc0497a0335@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
 <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>
 <kl1nZKcKJ50pznWkSgmJ1FMgwyI3QsCWCeJaraoJjS8=.40ab384b-b91e-45a1-9bf5-fbdd19e54552@github.com>
 <dz875Wg1UGzws9xBWcSHUM6nlPWwP2z1AdXyY-deyRs=.f0a9093e-2313-4693-b64f-3cc0497a0335@github.com>
Message-ID: <mT0AsjSWcNxDslmoyi71h9H3-oKMV2hfncsSitCRtqM=.9cbd90dd-4b3d-42ea-9521-89131c1796df@github.com>

On Tue, 22 Aug 2023 07:48:46 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> For the tests, I'm surprised the TEST.properties in this directory doesn't have exclusiveAccess.dirs=. as there has been historical issues with interference between tests in this area.

Hi Alan ,  when adding the test group  sun/tools/jhsdb in TEST.root to the exclusiveAccess.dirs , I cannot see the error any more. So it seems your suggestions is correct .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1695175709

From anhmdq at gmail.com  Mon Aug 28 08:13:04 2023
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Mon, 28 Aug 2023 16:13:04 +0800
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
Message-ID: <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>

Hi,

Polymorphism is a performance killer. Normally this does not matter much,
but for thin wrappers such as Optional, this is one of the most important
factor.

Behaviour polymorphism requires virtual dispatch and prevents inlining.
This is really detrimental, as simple operations such as a getter which is
previously only consisted of a memory load, in the presence of polymorphism
would have to go through a 10-time more expensive virtual dispatch.
Function calls, especially virtual ones, are also opaque and prohibit
compiler optimisations.

Layout polymorphism prevents direct accesses and requires indirection. This
means that for every instance of Optional created a memory allocation is
required. Optional is expected to be a near zero-cost abstraction in the
presence of Value classes, so making it polymorphic is unacceptable.

Thanks.

On Wed, 23 Aug 2023 at 22:43, Oleksii Kucheruk <iselo+openjdk at raccoons.co>
wrote:

> Hi there.
> I have found that `java.util.Optional` is written procedural style and has
> `ifnonnull`  checks in each method. I propose to refactor `Optional` in
> accordance to OOP-style. This will eliminates all unnecessary
> `if`-statements, removes duplications and reduces bytecode size more then
> twice.
>
> I have two solutions:
> 1. Completely dynamic that avoids single static `EMPTY` instance and
> unchecked casting of each `Optional.empty()`
> 2. Preserving original single static `EMPTY` per VM.
>
> Also there are couple methods that throws NPE due to calling methods on
> null-objects and requires to add `Objects.requireNonNull(...)`.
>
> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
> even with remove of additional boolean variable `isPresent`.
>
> Since I'm new here any guidance will be helpful.
> Thank you in advance.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/39623dac/attachment.htm>

From asotona at openjdk.org  Mon Aug 28 08:29:18 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Aug 2023 08:29:18 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v11]
In-Reply-To: <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
 <8uaJpVaqZSOwhp38MchtAvlA3e57Ewl6GSTFV45rcBo=.cd9bc59b-586f-48ea-be24-23c3eb342cd9@github.com>
Message-ID: <81Lr7VBflCF9wpwW7lBp5rHbtxE-MC0EQyme_e2BkKA=.bd9a00b3-0dc4-4498-8843-67e20c8e6db9@github.com>

On Thu, 20 Jul 2023 09:11:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> javap uses proprietary com.sun.tools.classfile library to parse class files.
>> 
>> This patch converts javap to use Classfile API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed code printing and ConstantPoolException reporting indoex
>  - added DydnamicConstantPoolEntry::bootstrapMethodIndex
>    fix of javap ConstantWriter to print DynamicConstantPoolEntry without accessing BSM attribute
>  - extended ClassReader about specific entry-reading methods to avoid class cast and throw ConstantPoolException instead
>  - throwing ConstantPoolException for invalid BSM entry index
>  - Merge branch 'master' into JDK-8294969-javap
>  - fixed JavapTask
>  - Merge branch 'master' into JDK-8294969-javap
>  - Merge branch 'master' into JDK-8294969-javap
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/constantpool/ConstantPoolException.java
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/37c756a7...4960751b

keep open

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11411#issuecomment-1695260560

From daniel at wwwmaster.at  Mon Aug 28 08:43:01 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Mon, 28 Aug 2023 10:43:01 +0200
Subject: yield return based on Coroutines
Message-ID: <c2f518b5-6ab9-5741-3d2c-a3d7951dc00d@wwwmaster.at>

Hi,

After seeing the JVM Language Summit talk on Continuations 
(https://www.youtube.com/watch?v=6nRS6UiN7X0), I thought about it being 
possible to implement something like "yield return" in languages like C# 
(or "yield" in Python) based on Continuations.
Kotlin has implemented a similar feature as well: 
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/-sequence-scope/yield.html
Now that Continuations are in the JDK, I feel like it can be used as a 
good primitive and now is a good time to start about thinking about 
adding something like this as a Java feature or the libraries.

After my experiments and some discussion with another developer named 
Peter Eastham (https://github.com/Crain-32), I was able to come up with 
an implementation/proof-of-concept allowing something like the following:

public static void main(String[] args) {
 ?? ?System.out.println("main thread: " + Thread.currentThread());

 ?? ?for (String s : Yielder.create(YieldReturnTest::someMethod)) {
 ?? ???? System.out.println("Text: " + s);
 ?? ?}
}

private static void someMethod(Yielder<String> y) {
 ?? ?y.yield("Hello - " + Thread.currentThread());
 ?? ?System.out.println("between yields");
 ?? ?y.yield("World - " + Thread.currentThread());

 ?? ?for (String s : Yielder.create(YieldReturnTest::otherMethod)) {
 ?? ???? y.yield("nested: " + s);
 ?? ?}

 ?? ?y.yield("bye - " + Thread.currentThread());
}

private static void otherMethod(Yielder<String> y) {
 ?? ?y.yield("it can");
 ?? ?y.yield("also be");
 ?? ?y.yield("nested");
}

output:

main thread: Thread[#1,main,5,main]
Text: Hello - Thread[#1,main,5,main]
between yields
Text: World - Thread[#1,main,5,main]
Text: nested: it can
Text: nested: also be
Text: nested: nested
Text: bye - Thread[#1,main,5,main]

In this example, the method reference passed to the Yielder.create 
method would be run in a Continuation while y.yield would yield the 
Continuation and make the value available to the iterator (next() calls 
Continuation#run).

You can find a simple proof-of-concept of that here: 
https://github.com/danthe1st/ContinuationYieldReturn

Would it be possible to add something like this to the JDK libraries?
I feel like it might be a useful addition to the JDK libraries as it 
simplifies creating sequences a lot.

Originally, I thought about whether it might be a good idea to add 
syntax for this but after building that proof-of-concept, it looks like 
it would be sufficient to add this to the libraries and using methods 
like this seems pretty natural.
One thing I am concerned with this approach (opposed to an approach that 
involves changing syntax) is that it would be possible that the method 
suddenly runs in a different thread if the hasNext()/next()-calls of the 
Iterator chang the thread they are used in at some point. While 
Continuations allow this behaviour, it might seem a weird to developers 
who don't know how Continuations work.
But aside from that issue with iterations switching threads, this 
approach seems pretty natural to me.

Yours,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/3b438572/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/3b438572/smime-0001.p7s>

From Alan.Bateman at oracle.com  Mon Aug 28 09:12:51 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Aug 2023 10:12:51 +0100
Subject: yield return based on Coroutines
In-Reply-To: <c2f518b5-6ab9-5741-3d2c-a3d7951dc00d@wwwmaster.at>
References: <c2f518b5-6ab9-5741-3d2c-a3d7951dc00d@wwwmaster.at>
Message-ID: <109a08a9-98ca-2ff7-8075-7f39c8b45eb5@oracle.com>


This looks fun! It's probably best to bring this to loom-dev. In its 
archives you'll find several discussions about generators as several 
people have been interested in that topic. Even when thread confined, 
the main concern has been that exotic control flow yields leads to 
surprising behavior with many of the existing constructs, e.g. in your 
example think about behavior with finally blocks, try-with-resources, 
locks, ... when the iterator is not fully consumed.

-Alan

On 28/08/2023 09:43, Daniel Schmid wrote:
>
> Hi,
>
> After seeing the JVM Language Summit talk on Continuations 
> (https://www.youtube.com/watch?v=6nRS6UiN7X0), I thought about it 
> being possible to implement something like "yield return" in languages 
> like C# (or "yield" in Python) based on Continuations.
> Kotlin has implemented a similar feature as well: 
> https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/-sequence-scope/yield.html
> Now that Continuations are in the JDK, I feel like it can be used as a 
> good primitive and now is a good time to start about thinking about 
> adding something like this as a Java feature or the libraries.
>
> After my experiments and some discussion with another developer named 
> Peter Eastham (https://github.com/Crain-32), I was able to come up 
> with an implementation/proof-of-concept allowing something like the 
> following:
>
> public static void main(String[] args) {
>  ?? ?System.out.println("main thread: " + Thread.currentThread());
>
>  ?? ?for (String s : Yielder.create(YieldReturnTest::someMethod)) {
>  ?? ???? System.out.println("Text: " + s);
>  ?? ?}
> }
>
> private static void someMethod(Yielder<String> y) {
>  ?? ?y.yield("Hello - " + Thread.currentThread());
>  ?? ?System.out.println("between yields");
>  ?? ?y.yield("World - " + Thread.currentThread());
>
>  ?? ?for (String s : Yielder.create(YieldReturnTest::otherMethod)) {
>  ?? ???? y.yield("nested: " + s);
>  ?? ?}
>
>  ?? ?y.yield("bye - " + Thread.currentThread());
> }
>
> private static void otherMethod(Yielder<String> y) {
>  ?? ?y.yield("it can");
>  ?? ?y.yield("also be");
>  ?? ?y.yield("nested");
> }
>
> output:
>
> main thread: Thread[#1,main,5,main]
> Text: Hello - Thread[#1,main,5,main]
> between yields
> Text: World - Thread[#1,main,5,main]
> Text: nested: it can
> Text: nested: also be
> Text: nested: nested
> Text: bye - Thread[#1,main,5,main]
>
> In this example, the method reference passed to the Yielder.create 
> method would be run in a Continuation while y.yield would yield the 
> Continuation and make the value available to the iterator (next() 
> calls Continuation#run).
>
> You can find a simple proof-of-concept of that here: 
> https://github.com/danthe1st/ContinuationYieldReturn
>
> Would it be possible to add something like this to the JDK libraries?
> I feel like it might be a useful addition to the JDK libraries as it 
> simplifies creating sequences a lot.
>
> Originally, I thought about whether it might be a good idea to add 
> syntax for this but after building that proof-of-concept, it looks 
> like it would be sufficient to add this to the libraries and using 
> methods like this seems pretty natural.
> One thing I am concerned with this approach (opposed to an approach 
> that involves changing syntax) is that it would be possible that the 
> method suddenly runs in a different thread if the 
> hasNext()/next()-calls of the Iterator chang the thread they are used 
> in at some point. While Continuations allow this behaviour, it might 
> seem a weird to developers who don't know how Continuations work.
> But aside from that issue with iterations switching threads, this 
> approach seems pretty natural to me.
>
> Yours,
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/1e20a050/attachment.htm>

From alanb at openjdk.org  Mon Aug 28 09:18:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Aug 2023 09:18:15 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v6]
In-Reply-To: <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>
Message-ID: <VI6ij-zKYMcD0fzrYASJ8DEZe-nVlBERSEDr_J0eb_I=.a49fc217-36e3-4880-82fa-4e8c08226950@github.com>

On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8314491-jexec-resolve-symlink
>  - declare error in-place
>  - remove unused imports
>  - Review comment: use /proc/self/exe as the backup option
>  - Merge branch 'master' into 8314491-jexec-resolve-symlink
>  - correct copyright statement
>  - Use /proc/self/exec to identify path to the executable.
>  - Create failing test for jexec in PATH issue

I think looks okay. I'm just surprised that it has been found/used on Linux as this was originally went with a Solaris feature for doing JRE version selection, and I actually thought had been removed a long time ago.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1695334327

From daniel at wwwmaster.at  Mon Aug 28 09:23:39 2023
From: daniel at wwwmaster.at (Daniel Schmid)
Date: Mon, 28 Aug 2023 11:23:39 +0200
Subject: yield return based on Continuations
In-Reply-To: <109a08a9-98ca-2ff7-8075-7f39c8b45eb5@oracle.com>
References: <c2f518b5-6ab9-5741-3d2c-a3d7951dc00d@wwwmaster.at>
 <109a08a9-98ca-2ff7-8075-7f39c8b45eb5@oracle.com>
Message-ID: <7ca1506f-e184-03f4-54e0-22f2383517d9@wwwmaster.at>

Thank you for your interest,

I'll also include loom-dev with this mail.

Yours,
Daniel

Am 28.08.2023 um 11:12 schrieb Alan Bateman:
>
> This looks fun! It's probably best to bring this to loom-dev. In its 
> archives you'll find several discussions about generators as several 
> people have been interested in that topic. Even when thread confined, 
> the main concern has been that exotic control flow yields leads to 
> surprising behavior with many of the existing constructs, e.g. in your 
> example think about behavior with finally blocks, try-with-resources, 
> locks, ... when the iterator is not fully consumed.
>
> -Alan
>
> On 28/08/2023 09:43, Daniel Schmid wrote:
>>
>> Hi,
>>
>> After seeing the JVM Language Summit talk on Continuations 
>> (https://www.youtube.com/watch?v=6nRS6UiN7X0), I thought about it 
>> being possible to implement something like "yield return" in 
>> languages like C# (or "yield" in Python) based on Continuations.
>> Kotlin has implemented a similar feature as well: 
>> https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.sequences/-sequence-scope/yield.html
>> Now that Continuations are in the JDK, I feel like it can be used as 
>> a good primitive and now is a good time to start about thinking about 
>> adding something like this as a Java feature or the libraries.
>>
>> After my experiments and some discussion with another developer named 
>> Peter Eastham (https://github.com/Crain-32), I was able to come up 
>> with an implementation/proof-of-concept allowing something like the 
>> following:
>>
>> public static void main(String[] args) {
>>  ?? ?System.out.println("main thread: " + Thread.currentThread());
>>
>>  ?? ?for (String s : Yielder.create(YieldReturnTest::someMethod)) {
>>  ?? ???? System.out.println("Text: " + s);
>>  ?? ?}
>> }
>>
>> private static void someMethod(Yielder<String> y) {
>>  ?? ?y.yield("Hello - " + Thread.currentThread());
>>  ?? ?System.out.println("between yields");
>>  ?? ?y.yield("World - " + Thread.currentThread());
>>
>>  ?? ?for (String s : Yielder.create(YieldReturnTest::otherMethod)) {
>>  ?? ???? y.yield("nested: " + s);
>>  ?? ?}
>>
>>  ?? ?y.yield("bye - " + Thread.currentThread());
>> }
>>
>> private static void otherMethod(Yielder<String> y) {
>>  ?? ?y.yield("it can");
>>  ?? ?y.yield("also be");
>>  ?? ?y.yield("nested");
>> }
>>
>> output:
>>
>> main thread: Thread[#1,main,5,main]
>> Text: Hello - Thread[#1,main,5,main]
>> between yields
>> Text: World - Thread[#1,main,5,main]
>> Text: nested: it can
>> Text: nested: also be
>> Text: nested: nested
>> Text: bye - Thread[#1,main,5,main]
>>
>> In this example, the method reference passed to the Yielder.create 
>> method would be run in a Continuation while y.yield would yield the 
>> Continuation and make the value available to the iterator (next() 
>> calls Continuation#run).
>>
>> You can find a simple proof-of-concept of that here: 
>> https://github.com/danthe1st/ContinuationYieldReturn
>>
>> Would it be possible to add something like this to the JDK libraries?
>> I feel like it might be a useful addition to the JDK libraries as it 
>> simplifies creating sequences a lot.
>>
>> Originally, I thought about whether it might be a good idea to add 
>> syntax for this but after building that proof-of-concept, it looks 
>> like it would be sufficient to add this to the libraries and using 
>> methods like this seems pretty natural.
>> One thing I am concerned with this approach (opposed to an approach 
>> that involves changing syntax) is that it would be possible that the 
>> method suddenly runs in a different thread if the 
>> hasNext()/next()-calls of the Iterator chang the thread they are used 
>> in at some point. While Continuations allow this behaviour, it might 
>> seem a weird to developers who don't know how Continuations work.
>> But aside from that issue with iterations switching threads, this 
>> approach seems pretty natural to me.
>>
>> Yours,
>> Daniel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/02e0bc98/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4490 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/02e0bc98/smime-0001.p7s>

From iselo+openjdk at raccoons.co  Mon Aug 28 10:27:21 2023
From: iselo+openjdk at raccoons.co (Oleksii Kucheruk)
Date: Mon, 28 Aug 2023 13:27:21 +0300
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>
Message-ID: <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>

Thank you Qu?n.

All  you saying guys make sense.
Yes there is a difference calling methods by pointer and involving vtable.
But one thing didn't came out of my head:
If virtual dispatch dispatch is 10-time more expensive and polymorphism is
a performance killer so how combinations of "return optional - isPresent-
get" or "return empty - isEmpty" with virtual dispatch and memory
allocation for every empty or sole but polymorph empty could perform
equally or even beat the near zero-cost abstraction of Value classes
according to JMH?

Maybe private final static nested EmptyOptional invokevirtual bytecode refers
a final methods and it need not have a vtable slot allocated. This means
that, after linking, an invokevirtual bytecode might in fact collapse into
the equivalent of an invokestatic bytecode.
The question of full dynamic with anonymous overloading is still unclear to
me.

Benchmark                                               Mode  Cnt
     Score
          Error  Units

*OptionalComboIsPresentGet.opDynamicAnonymous           thrpt   30
1059868995.937 ?  51273067.116  ops/s*

OptionalComboIsPresentGet.opJdk                        thrpt   30
1017505800.567
?  16007847.872  ops/s

OptionalComboIsPresentGet.opNestedStatic               thrpt   30
951493332.957
?  12167812.398  ops/s


OptionalComboOfIsPresentGetTest.opDynamicAnonymous     thrpt   30
1426348334.485
?  20889455.433  ops/s

*OptionalComboOfIsPresentGetTest.opJdk                  thrpt   30
1435570789.822 ?  16587538.659  ops/s*

OptionalComboOfIsPresentGetTest.opNestedStatic         thrpt   30
1418853644.215
?  27755398.645  ops/s


*OptionalComboOfNullableIsEmptyTest.opDynamicAnonymous  thrpt   30
1434399595.592 ?  14749443.903  ops/s*

OptionalComboOfNullableIsEmptyTest.opJdk               thrpt   30
1255375023.531
? 107403119.573  ops/s

OptionalComboOfNullableIsEmptyTest.opNestedStatic      thrpt   30
1415705702.964
?  26328318.672  ops/s


OptionalEmptyTest.opDynamicAnonymous                   thrpt   30
1417895521.763
?  26311640.557  ops/s

*OptionalEmptyTest.opJdk                                thrpt   30
1423940087.962 ?  18515297.860  ops/s*

OptionalEmptyTest.opNestedStatic                       thrpt   30
1424779162.084
?  20288793.337  ops/s


OptionalGetTest.emDynamicAnonymous                     thrpt   30
569132.235
?     11089.903  ops/s

*OptionalGetTest.emJdk                                  thrpt   30
549764.038 ?     14768.566  ops/s*

OptionalGetTest.emNestedStatic                         thrpt   30
568308.722
?      6075.671  ops/s


OptionalGetTest.opDynamicAnonymous                     thrpt   30
953788065.414
?   7043419.784  ops/s

*OptionalGetTest.opJdk                                  thrpt   30
1015679232.049 ?  11726562.032  ops/s*

OptionalGetTest.opNestedStatic                         thrpt   30
944209513.151
?  17718342.519  ops/s


OptionalIsPresentTest.emDynamicAnonymous               thrpt   30
869086292.481
?  11668636.886  ops/s

*OptionalIsPresentTest.emJdk                            thrpt   30
977042244.447 ?  44558020.220  ops/s*

OptionalIsPresentTest.emNestedStatic                   thrpt   30
953424664.631
?   8448564.963  ops/s


OptionalIsPresentTest.opDynamicAnonymous               thrpt   30
953285872.799
?   6562894.941  ops/s

*OptionalIsPresentTest.opJdk                            thrpt   30
1006926903.885 ?  18055487.689  ops/s*

OptionalIsPresentTest.opNestedStatic                   thrpt   30
954121471.431
?   6829528.708  ops/s


OptionalOfNullableTest.emDynamicAnonymous              thrpt   30
1422939780.266
?  21693247.354  ops/s

*OptionalOfNullableTest.emJdk                           thrpt   30
1423340184.237 ?  21296444.017  ops/s*

OptionalOfNullableTest.emNestedStatic                  thrpt   30
1414965236.385
?  26021734.344  ops/s


OptionalOfNullableTest.opDynamicAnonymous              thrpt   30
1412594454.538
?  28123612.298  ops/s

*OptionalOfNullableTest.opJdk                           thrpt   30
1427924599.589 ?  23469517.835  ops/s*

OptionalOfNullableTest.opNestedStatic                  thrpt   30
1420053175.637
?  21170929.571  ops/s


OptionalOfTest.emDynamicAnonymous                      thrpt   30
549907.559
?     14560.954  ops/s

OptionalOfTest.emJdk                                   thrpt   30
557858.903
?      2851.076  ops/s

*OptionalOfTest.emNestedStatic                          thrpt   30
548655.854 ?     10875.674  ops/s*


OptionalOfTest.opDynamicAnonymous                      thrpt   30
1411307270.435
?  19832207.408  ops/s

OptionalOfTest.opJdk                                   thrpt   30
1400651442.726
?  23641065.234  ops/s

*OptionalOfTest.opNestedStatic                          thrpt   30
1433953744.298 ?  21414147.936  ops/s*


On Mon, Aug 28, 2023 at 11:13?AM Qu?n Anh Mai <anhmdq at gmail.com> wrote:

> Hi,
>
> Polymorphism is a performance killer. Normally this does not matter much,
> but for thin wrappers such as Optional, this is one of the most important
> factor.
>
> Behaviour polymorphism requires virtual dispatch and prevents inlining.
> This is really detrimental, as simple operations such as a getter which is
> previously only consisted of a memory load, in the presence of polymorphism
> would have to go through a 10-time more expensive virtual dispatch.
> Function calls, especially virtual ones, are also opaque and prohibit
> compiler optimisations.
>
> Layout polymorphism prevents direct accesses and requires indirection.
> This means that for every instance of Optional created a memory allocation
> is required. Optional is expected to be a near zero-cost abstraction in the
> presence of Value classes, so making it polymorphic is unacceptable.
>
> Thanks.
>
> On Wed, 23 Aug 2023 at 22:43, Oleksii Kucheruk <iselo+openjdk at raccoons.co>
> wrote:
>
>> Hi there.
>> I have found that `java.util.Optional` is written procedural style and
>> has `ifnonnull`  checks in each method. I propose to refactor `Optional` in
>> accordance to OOP-style. This will eliminates all unnecessary
>> `if`-statements, removes duplications and reduces bytecode size more then
>> twice.
>>
>> I have two solutions:
>> 1. Completely dynamic that avoids single static `EMPTY` instance and
>> unchecked casting of each `Optional.empty()`
>> 2. Preserving original single static `EMPTY` per VM.
>>
>> Also there are couple methods that throws NPE due to calling methods on
>> null-objects and requires to add `Objects.requireNonNull(...)`.
>>
>> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
>> even with remove of additional boolean variable `isPresent`.
>>
>> Since I'm new here any guidance will be helpful.
>> Thank you in advance.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/a96c7add/attachment-0001.htm>

From anhmdq at gmail.com  Mon Aug 28 11:03:24 2023
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Mon, 28 Aug 2023 19:03:24 +0800
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>
 <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>
Message-ID: <CAPvyiyLfnEoC2ahVhG8kOw9_3-qKDR8ppxO5WS=41nsFxu7A1Q@mail.gmail.com>

Tbh I have a hard time understand what you are trying to convey. Please
write grammatically correct sentences with clear structure.

I notice you attach benchmark results but I don't see what was benchmarked
to produce those results.

Another point is that Value classes has not been delivered yet, so there
are potential performance uplifts of Optional in the future. This may not
be possible if Optional is polymorphic.

Thanks

On Mon, 28 Aug 2023 at 18:27, Oleksii Kucheruk <iselo+openjdk at raccoons.co>
wrote:

> Thank you Qu?n.
>
> All  you saying guys make sense.
> Yes there is a difference calling methods by pointer and involving vtable.
> But one thing didn't came out of my head:
> If virtual dispatch dispatch is 10-time more expensive and polymorphism is
> a performance killer so how combinations of "return optional - isPresent-
> get" or "return empty - isEmpty" with virtual dispatch and memory
> allocation for every empty or sole but polymorph empty could perform
> equally or even beat the near zero-cost abstraction of Value classes
> according to JMH?
>
> Maybe private final static nested EmptyOptional invokevirtual bytecode refers
> a final methods and it need not have a vtable slot allocated. This means
> that, after linking, an invokevirtual bytecode might in fact collapse into
> the equivalent of an invokestatic bytecode.
> The question of full dynamic with anonymous overloading is still unclear
> to me.
>
> Benchmark                                               Mode  Cnt
>   Score           Error  Units
>
> *OptionalComboIsPresentGet.opDynamicAnonymous           thrpt   30
> 1059868995.937 ?  51273067.116  ops/s*
>
> OptionalComboIsPresentGet.opJdk                        thrpt   30  1017505800.567
> ?  16007847.872  ops/s
>
> OptionalComboIsPresentGet.opNestedStatic               thrpt   30   951493332.957
> ?  12167812.398  ops/s
>
>
> OptionalComboOfIsPresentGetTest.opDynamicAnonymous     thrpt   30  1426348334.485
> ?  20889455.433  ops/s
>
> *OptionalComboOfIsPresentGetTest.opJdk                  thrpt   30
> 1435570789.822 ?  16587538.659  ops/s*
>
> OptionalComboOfIsPresentGetTest.opNestedStatic         thrpt   30  1418853644.215
> ?  27755398.645  ops/s
>
>
> *OptionalComboOfNullableIsEmptyTest.opDynamicAnonymous  thrpt   30
> 1434399595.592 ?  14749443.903  ops/s*
>
> OptionalComboOfNullableIsEmptyTest.opJdk               thrpt   30  1255375023.531
> ? 107403119.573  ops/s
>
> OptionalComboOfNullableIsEmptyTest.opNestedStatic      thrpt   30  1415705702.964
> ?  26328318.672  ops/s
>
>
> OptionalEmptyTest.opDynamicAnonymous                   thrpt   30  1417895521.763
> ?  26311640.557  ops/s
>
> *OptionalEmptyTest.opJdk                                thrpt   30
> 1423940087.962 ?  18515297.860  ops/s*
>
> OptionalEmptyTest.opNestedStatic                       thrpt   30  1424779162.084
> ?  20288793.337  ops/s
>
>
> OptionalGetTest.emDynamicAnonymous                     thrpt   30      569132.235
> ?     11089.903  ops/s
>
> *OptionalGetTest.emJdk                                  thrpt   30
> 549764.038 ?     14768.566  ops/s*
>
> OptionalGetTest.emNestedStatic                         thrpt   30      568308.722
> ?      6075.671  ops/s
>
>
> OptionalGetTest.opDynamicAnonymous                     thrpt   30   953788065.414
> ?   7043419.784  ops/s
>
> *OptionalGetTest.opJdk                                  thrpt   30
> 1015679232.049 ?  11726562.032  ops/s*
>
> OptionalGetTest.opNestedStatic                         thrpt   30   944209513.151
> ?  17718342.519  ops/s
>
>
> OptionalIsPresentTest.emDynamicAnonymous               thrpt   30   869086292.481
> ?  11668636.886  ops/s
>
> *OptionalIsPresentTest.emJdk                            thrpt   30
> 977042244.447 ?  44558020.220  ops/s*
>
> OptionalIsPresentTest.emNestedStatic                   thrpt   30   953424664.631
> ?   8448564.963  ops/s
>
>
> OptionalIsPresentTest.opDynamicAnonymous               thrpt   30   953285872.799
> ?   6562894.941  ops/s
>
> *OptionalIsPresentTest.opJdk                            thrpt   30
> 1006926903.885 ?  18055487.689  ops/s*
>
> OptionalIsPresentTest.opNestedStatic                   thrpt   30   954121471.431
> ?   6829528.708  ops/s
>
>
> OptionalOfNullableTest.emDynamicAnonymous              thrpt   30  1422939780.266
> ?  21693247.354  ops/s
>
> *OptionalOfNullableTest.emJdk                           thrpt   30
> 1423340184.237 ?  21296444.017  ops/s*
>
> OptionalOfNullableTest.emNestedStatic                  thrpt   30  1414965236.385
> ?  26021734.344  ops/s
>
>
> OptionalOfNullableTest.opDynamicAnonymous              thrpt   30  1412594454.538
> ?  28123612.298  ops/s
>
> *OptionalOfNullableTest.opJdk                           thrpt   30
> 1427924599.589 ?  23469517.835  ops/s*
>
> OptionalOfNullableTest.opNestedStatic                  thrpt   30  1420053175.637
> ?  21170929.571  ops/s
>
>
> OptionalOfTest.emDynamicAnonymous                      thrpt   30      549907.559
> ?     14560.954  ops/s
>
> OptionalOfTest.emJdk                                   thrpt   30      557858.903
> ?      2851.076  ops/s
>
> *OptionalOfTest.emNestedStatic                          thrpt   30
> 548655.854 ?     10875.674  ops/s*
>
>
> OptionalOfTest.opDynamicAnonymous                      thrpt   30  1411307270.435
> ?  19832207.408  ops/s
>
> OptionalOfTest.opJdk                                   thrpt   30  1400651442.726
> ?  23641065.234  ops/s
>
> *OptionalOfTest.opNestedStatic                          thrpt   30
> 1433953744.298 ?  21414147.936  ops/s*
>
>
> On Mon, Aug 28, 2023 at 11:13?AM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>
>> Hi,
>>
>> Polymorphism is a performance killer. Normally this does not matter much,
>> but for thin wrappers such as Optional, this is one of the most important
>> factor.
>>
>> Behaviour polymorphism requires virtual dispatch and prevents inlining.
>> This is really detrimental, as simple operations such as a getter which is
>> previously only consisted of a memory load, in the presence of polymorphism
>> would have to go through a 10-time more expensive virtual dispatch.
>> Function calls, especially virtual ones, are also opaque and prohibit
>> compiler optimisations.
>>
>> Layout polymorphism prevents direct accesses and requires indirection.
>> This means that for every instance of Optional created a memory allocation
>> is required. Optional is expected to be a near zero-cost abstraction in the
>> presence of Value classes, so making it polymorphic is unacceptable.
>>
>> Thanks.
>>
>> On Wed, 23 Aug 2023 at 22:43, Oleksii Kucheruk <iselo+openjdk at raccoons.co>
>> wrote:
>>
>>> Hi there.
>>> I have found that `java.util.Optional` is written procedural style and
>>> has `ifnonnull`  checks in each method. I propose to refactor `Optional` in
>>> accordance to OOP-style. This will eliminates all unnecessary
>>> `if`-statements, removes duplications and reduces bytecode size more then
>>> twice.
>>>
>>> I have two solutions:
>>> 1. Completely dynamic that avoids single static `EMPTY` instance and
>>> unchecked casting of each `Optional.empty()`
>>> 2. Preserving original single static `EMPTY` per VM.
>>>
>>> Also there are couple methods that throws NPE due to calling methods on
>>> null-objects and requires to add `Objects.requireNonNull(...)`.
>>>
>>> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
>>> even with remove of additional boolean variable `isPresent`.
>>>
>>> Since I'm new here any guidance will be helpful.
>>> Thank you in advance.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/79daa4d5/attachment-0001.htm>

From iselo+openjdk at raccoons.co  Mon Aug 28 12:17:23 2023
From: iselo+openjdk at raccoons.co (Oleksii Kucheruk)
Date: Mon, 28 Aug 2023 15:17:23 +0300
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CAPvyiyLfnEoC2ahVhG8kOw9_3-qKDR8ppxO5WS=41nsFxu7A1Q@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>
 <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>
 <CAPvyiyLfnEoC2ahVhG8kOw9_3-qKDR8ppxO5WS=41nsFxu7A1Q@mail.gmail.com>
Message-ID: <CACg0bd2o3+9wVWLVzgHmnKEPUnk=1rcQ7kOJ0bfM4X9dBZeRtA@mail.gmail.com>

Now it is clear. Sorry for the inconvenience. Thank you for your time. I
appreciate.

On Mon, 28 Aug 2023 at 2:03 PM Qu?n Anh Mai <anhmdq at gmail.com> wrote:

> Tbh I have a hard time understand what you are trying to convey. Please
> write grammatically correct sentences with clear structure.
>
> I notice you attach benchmark results but I don't see what was benchmarked
> to produce those results.
>
> Another point is that Value classes has not been delivered yet, so there
> are potential performance uplifts of Optional in the future. This may not
> be possible if Optional is polymorphic.
>
> Thanks
>
> On Mon, 28 Aug 2023 at 18:27, Oleksii Kucheruk <iselo+openjdk at raccoons.co>
> wrote:
>
>> Thank you Qu?n.
>>
>> All  you saying guys make sense.
>> Yes there is a difference calling methods by pointer and involving
>> vtable. But one thing didn't came out of my head:
>> If virtual dispatch dispatch is 10-time more expensive and polymorphism
>> is a performance killer so how combinations of "return optional -
>> isPresent- get" or "return empty - isEmpty" with virtual dispatch and
>> memory allocation for every empty or sole but polymorph empty could perform
>> equally or even beat the near zero-cost abstraction of Value classes
>> according to JMH?
>>
>> Maybe private final static nested EmptyOptional invokevirtual bytecode refers
>> a final methods and it need not have a vtable slot allocated. This means
>> that, after linking, an invokevirtual bytecode might in fact collapse into
>> the equivalent of an invokestatic bytecode.
>> The question of full dynamic with anonymous overloading is still unclear
>> to me.
>>
>> Benchmark                                               Mode  Cnt
>>     Score           Error  Units
>>
>> *OptionalComboIsPresentGet.opDynamicAnonymous           thrpt   30
>> 1059868995.937 ?  51273067.116  ops/s*
>>
>> OptionalComboIsPresentGet.opJdk                        thrpt   30  1017505800.567
>> ?  16007847.872  ops/s
>>
>> OptionalComboIsPresentGet.opNestedStatic               thrpt   30   951493332.957
>> ?  12167812.398  ops/s
>>
>>
>> OptionalComboOfIsPresentGetTest.opDynamicAnonymous     thrpt   30  1426348334.485
>> ?  20889455.433  ops/s
>>
>> *OptionalComboOfIsPresentGetTest.opJdk                  thrpt   30
>> 1435570789.822 ?  16587538.659  ops/s*
>>
>> OptionalComboOfIsPresentGetTest.opNestedStatic         thrpt   30  1418853644.215
>> ?  27755398.645  ops/s
>>
>>
>> *OptionalComboOfNullableIsEmptyTest.opDynamicAnonymous  thrpt   30
>> 1434399595.592 ?  14749443.903  ops/s*
>>
>> OptionalComboOfNullableIsEmptyTest.opJdk               thrpt   30  1255375023.531
>> ? 107403119.573  ops/s
>>
>> OptionalComboOfNullableIsEmptyTest.opNestedStatic      thrpt   30  1415705702.964
>> ?  26328318.672  ops/s
>>
>>
>> OptionalEmptyTest.opDynamicAnonymous                   thrpt   30  1417895521.763
>> ?  26311640.557  ops/s
>>
>> *OptionalEmptyTest.opJdk                                thrpt   30
>> 1423940087.962 ?  18515297.860  ops/s*
>>
>> OptionalEmptyTest.opNestedStatic                       thrpt   30  1424779162.084
>> ?  20288793.337  ops/s
>>
>>
>> OptionalGetTest.emDynamicAnonymous                     thrpt   30      569132.235
>> ?     11089.903  ops/s
>>
>> *OptionalGetTest.emJdk                                  thrpt   30
>> 549764.038 ?     14768.566  ops/s*
>>
>> OptionalGetTest.emNestedStatic                         thrpt   30      568308.722
>> ?      6075.671  ops/s
>>
>>
>> OptionalGetTest.opDynamicAnonymous                     thrpt   30   953788065.414
>> ?   7043419.784  ops/s
>>
>> *OptionalGetTest.opJdk                                  thrpt   30
>> 1015679232.049 ?  11726562.032  ops/s*
>>
>> OptionalGetTest.opNestedStatic                         thrpt   30   944209513.151
>> ?  17718342.519  ops/s
>>
>>
>> OptionalIsPresentTest.emDynamicAnonymous               thrpt   30   869086292.481
>> ?  11668636.886  ops/s
>>
>> *OptionalIsPresentTest.emJdk                            thrpt   30
>> 977042244.447 ?  44558020.220  ops/s*
>>
>> OptionalIsPresentTest.emNestedStatic                   thrpt   30   953424664.631
>> ?   8448564.963  ops/s
>>
>>
>> OptionalIsPresentTest.opDynamicAnonymous               thrpt   30   953285872.799
>> ?   6562894.941  ops/s
>>
>> *OptionalIsPresentTest.opJdk                            thrpt   30
>> 1006926903.885 ?  18055487.689  ops/s*
>>
>> OptionalIsPresentTest.opNestedStatic                   thrpt   30   954121471.431
>> ?   6829528.708  ops/s
>>
>>
>> OptionalOfNullableTest.emDynamicAnonymous              thrpt   30  1422939780.266
>> ?  21693247.354  ops/s
>>
>> *OptionalOfNullableTest.emJdk                           thrpt   30
>> 1423340184.237 ?  21296444.017  ops/s*
>>
>> OptionalOfNullableTest.emNestedStatic                  thrpt   30  1414965236.385
>> ?  26021734.344  ops/s
>>
>>
>> OptionalOfNullableTest.opDynamicAnonymous              thrpt   30  1412594454.538
>> ?  28123612.298  ops/s
>>
>> *OptionalOfNullableTest.opJdk                           thrpt   30
>> 1427924599.589 ?  23469517.835  ops/s*
>>
>> OptionalOfNullableTest.opNestedStatic                  thrpt   30  1420053175.637
>> ?  21170929.571  ops/s
>>
>>
>> OptionalOfTest.emDynamicAnonymous                      thrpt   30      549907.559
>> ?     14560.954  ops/s
>>
>> OptionalOfTest.emJdk                                   thrpt   30      557858.903
>> ?      2851.076  ops/s
>>
>> *OptionalOfTest.emNestedStatic                          thrpt   30
>> 548655.854 ?     10875.674  ops/s*
>>
>>
>> OptionalOfTest.opDynamicAnonymous                      thrpt   30  1411307270.435
>> ?  19832207.408  ops/s
>>
>> OptionalOfTest.opJdk                                   thrpt   30  1400651442.726
>> ?  23641065.234  ops/s
>>
>> *OptionalOfTest.opNestedStatic                          thrpt   30
>> 1433953744.298 ?  21414147.936  ops/s*
>>
>>
>> On Mon, Aug 28, 2023 at 11:13?AM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Polymorphism is a performance killer. Normally this does not matter
>>> much, but for thin wrappers such as Optional, this is one of the most
>>> important factor.
>>>
>>> Behaviour polymorphism requires virtual dispatch and prevents inlining.
>>> This is really detrimental, as simple operations such as a getter which is
>>> previously only consisted of a memory load, in the presence of polymorphism
>>> would have to go through a 10-time more expensive virtual dispatch.
>>> Function calls, especially virtual ones, are also opaque and prohibit
>>> compiler optimisations.
>>>
>>> Layout polymorphism prevents direct accesses and requires indirection.
>>> This means that for every instance of Optional created a memory allocation
>>> is required. Optional is expected to be a near zero-cost abstraction in the
>>> presence of Value classes, so making it polymorphic is unacceptable.
>>>
>>> Thanks.
>>>
>>> On Wed, 23 Aug 2023 at 22:43, Oleksii Kucheruk <
>>> iselo+openjdk at raccoons.co> wrote:
>>>
>>>> Hi there.
>>>> I have found that `java.util.Optional` is written procedural style and
>>>> has `ifnonnull`  checks in each method. I propose to refactor `Optional` in
>>>> accordance to OOP-style. This will eliminates all unnecessary
>>>> `if`-statements, removes duplications and reduces bytecode size more then
>>>> twice.
>>>>
>>>> I have two solutions:
>>>> 1. Completely dynamic that avoids single static `EMPTY` instance and
>>>> unchecked casting of each `Optional.empty()`
>>>> 2. Preserving original single static `EMPTY` per VM.
>>>>
>>>> Also there are couple methods that throws NPE due to calling methods on
>>>> null-objects and requires to add `Objects.requireNonNull(...)`.
>>>>
>>>> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
>>>> even with remove of additional boolean variable `isPresent`.
>>>>
>>>> Since I'm new here any guidance will be helpful.
>>>> Thank you in advance.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/832e3d98/attachment-0001.htm>

From liangchenblue at gmail.com  Mon Aug 28 13:04:00 2023
From: liangchenblue at gmail.com (-)
Date: Mon, 28 Aug 2023 21:04:00 +0800
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>
 <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>
Message-ID: <CABe8uE3DAQrz9vm-N1wM9uDfU+hR6++d=9eMALKJoDY231Bnkw@mail.gmail.com>

Can you share the benchmark code? Maybe C2 profiled class hierarchy,
determined your optional only has 2 subclasses and can thus generate
optimized machine code. Or maybe your benchmark is wrong that the result is
not consumed by blackhole so the whole benchmark is moot. We need the code
to make a verdict.

Chen

On Mon, Aug 28, 2023 at 6:27?PM Oleksii Kucheruk <iselo+openjdk at raccoons.co>
wrote:

> Thank you Qu?n.
>
> All  you saying guys make sense.
> Yes there is a difference calling methods by pointer and involving vtable.
> But one thing didn't came out of my head:
> If virtual dispatch dispatch is 10-time more expensive and polymorphism is
> a performance killer so how combinations of "return optional - isPresent-
> get" or "return empty - isEmpty" with virtual dispatch and memory
> allocation for every empty or sole but polymorph empty could perform
> equally or even beat the near zero-cost abstraction of Value classes
> according to JMH?
>
> Maybe private final static nested EmptyOptional invokevirtual bytecode refers
> a final methods and it need not have a vtable slot allocated. This means
> that, after linking, an invokevirtual bytecode might in fact collapse into
> the equivalent of an invokestatic bytecode.
> The question of full dynamic with anonymous overloading is still unclear
> to me.
>
> Benchmark                                               Mode  Cnt
>   Score           Error  Units
>
> *OptionalComboIsPresentGet.opDynamicAnonymous           thrpt   30
> 1059868995.937 ?  51273067.116  ops/s*
>
> OptionalComboIsPresentGet.opJdk                        thrpt   30  1017505800.567
> ?  16007847.872  ops/s
>
> OptionalComboIsPresentGet.opNestedStatic               thrpt   30   951493332.957
> ?  12167812.398  ops/s
>
>
> OptionalComboOfIsPresentGetTest.opDynamicAnonymous     thrpt   30  1426348334.485
> ?  20889455.433  ops/s
>
> *OptionalComboOfIsPresentGetTest.opJdk                  thrpt   30
> 1435570789.822 ?  16587538.659  ops/s*
>
> OptionalComboOfIsPresentGetTest.opNestedStatic         thrpt   30  1418853644.215
> ?  27755398.645  ops/s
>
>
> *OptionalComboOfNullableIsEmptyTest.opDynamicAnonymous  thrpt   30
> 1434399595.592 ?  14749443.903  ops/s*
>
> OptionalComboOfNullableIsEmptyTest.opJdk               thrpt   30  1255375023.531
> ? 107403119.573  ops/s
>
> OptionalComboOfNullableIsEmptyTest.opNestedStatic      thrpt   30  1415705702.964
> ?  26328318.672  ops/s
>
>
> OptionalEmptyTest.opDynamicAnonymous                   thrpt   30  1417895521.763
> ?  26311640.557  ops/s
>
> *OptionalEmptyTest.opJdk                                thrpt   30
> 1423940087.962 ?  18515297.860  ops/s*
>
> OptionalEmptyTest.opNestedStatic                       thrpt   30  1424779162.084
> ?  20288793.337  ops/s
>
>
> OptionalGetTest.emDynamicAnonymous                     thrpt   30      569132.235
> ?     11089.903  ops/s
>
> *OptionalGetTest.emJdk                                  thrpt   30
> 549764.038 ?     14768.566  ops/s*
>
> OptionalGetTest.emNestedStatic                         thrpt   30      568308.722
> ?      6075.671  ops/s
>
>
> OptionalGetTest.opDynamicAnonymous                     thrpt   30   953788065.414
> ?   7043419.784  ops/s
>
> *OptionalGetTest.opJdk                                  thrpt   30
> 1015679232.049 ?  11726562.032  ops/s*
>
> OptionalGetTest.opNestedStatic                         thrpt   30   944209513.151
> ?  17718342.519  ops/s
>
>
> OptionalIsPresentTest.emDynamicAnonymous               thrpt   30   869086292.481
> ?  11668636.886  ops/s
>
> *OptionalIsPresentTest.emJdk                            thrpt   30
> 977042244.447 ?  44558020.220  ops/s*
>
> OptionalIsPresentTest.emNestedStatic                   thrpt   30   953424664.631
> ?   8448564.963  ops/s
>
>
> OptionalIsPresentTest.opDynamicAnonymous               thrpt   30   953285872.799
> ?   6562894.941  ops/s
>
> *OptionalIsPresentTest.opJdk                            thrpt   30
> 1006926903.885 ?  18055487.689  ops/s*
>
> OptionalIsPresentTest.opNestedStatic                   thrpt   30   954121471.431
> ?   6829528.708  ops/s
>
>
> OptionalOfNullableTest.emDynamicAnonymous              thrpt   30  1422939780.266
> ?  21693247.354  ops/s
>
> *OptionalOfNullableTest.emJdk                           thrpt   30
> 1423340184.237 ?  21296444.017  ops/s*
>
> OptionalOfNullableTest.emNestedStatic                  thrpt   30  1414965236.385
> ?  26021734.344  ops/s
>
>
> OptionalOfNullableTest.opDynamicAnonymous              thrpt   30  1412594454.538
> ?  28123612.298  ops/s
>
> *OptionalOfNullableTest.opJdk                           thrpt   30
> 1427924599.589 ?  23469517.835  ops/s*
>
> OptionalOfNullableTest.opNestedStatic                  thrpt   30  1420053175.637
> ?  21170929.571  ops/s
>
>
> OptionalOfTest.emDynamicAnonymous                      thrpt   30      549907.559
> ?     14560.954  ops/s
>
> OptionalOfTest.emJdk                                   thrpt   30      557858.903
> ?      2851.076  ops/s
>
> *OptionalOfTest.emNestedStatic                          thrpt   30
> 548655.854 ?     10875.674  ops/s*
>
>
> OptionalOfTest.opDynamicAnonymous                      thrpt   30  1411307270.435
> ?  19832207.408  ops/s
>
> OptionalOfTest.opJdk                                   thrpt   30  1400651442.726
> ?  23641065.234  ops/s
>
> *OptionalOfTest.opNestedStatic                          thrpt   30
> 1433953744.298 ?  21414147.936  ops/s*
>
>
> On Mon, Aug 28, 2023 at 11:13?AM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>
>> Hi,
>>
>> Polymorphism is a performance killer. Normally this does not matter much,
>> but for thin wrappers such as Optional, this is one of the most important
>> factor.
>>
>> Behaviour polymorphism requires virtual dispatch and prevents inlining.
>> This is really detrimental, as simple operations such as a getter which is
>> previously only consisted of a memory load, in the presence of polymorphism
>> would have to go through a 10-time more expensive virtual dispatch.
>> Function calls, especially virtual ones, are also opaque and prohibit
>> compiler optimisations.
>>
>> Layout polymorphism prevents direct accesses and requires indirection.
>> This means that for every instance of Optional created a memory allocation
>> is required. Optional is expected to be a near zero-cost abstraction in the
>> presence of Value classes, so making it polymorphic is unacceptable.
>>
>> Thanks.
>>
>> On Wed, 23 Aug 2023 at 22:43, Oleksii Kucheruk <iselo+openjdk at raccoons.co>
>> wrote:
>>
>>> Hi there.
>>> I have found that `java.util.Optional` is written procedural style and
>>> has `ifnonnull`  checks in each method. I propose to refactor `Optional` in
>>> accordance to OOP-style. This will eliminates all unnecessary
>>> `if`-statements, removes duplications and reduces bytecode size more then
>>> twice.
>>>
>>> I have two solutions:
>>> 1. Completely dynamic that avoids single static `EMPTY` instance and
>>> unchecked casting of each `Optional.empty()`
>>> 2. Preserving original single static `EMPTY` per VM.
>>>
>>> Also there are couple methods that throws NPE due to calling methods on
>>> null-objects and requires to add `Objects.requireNonNull(...)`.
>>>
>>> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
>>> even with remove of additional boolean variable `isPresent`.
>>>
>>> Since I'm new here any guidance will be helpful.
>>> Thank you in advance.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/ff4fc2e6/attachment-0001.htm>

From azvegint at openjdk.org  Mon Aug 28 14:11:12 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 28 Aug 2023 14:11:12 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note [v2]
In-Reply-To: <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
 <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
Message-ID: <eoOaLBXooZ9uqNTM2WcGbiK_Bct3PA2ti-x-Tk3PbQQ=.6a7eea57-cfa1-4850-8473-11d706be4699@github.com>

On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this trivial PR.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8314753
>  - Initial commit

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15385#pullrequestreview-1598378564

From iselo+openjdk at raccoons.co  Mon Aug 28 14:21:32 2023
From: iselo+openjdk at raccoons.co (Oleksii Kucheruk)
Date: Mon, 28 Aug 2023 17:21:32 +0300
Subject: RFE: Refactor java.util.Optional and add NonNull checks
In-Reply-To: <CABe8uE3DAQrz9vm-N1wM9uDfU+hR6++d=9eMALKJoDY231Bnkw@mail.gmail.com>
References: <CACg0bd0v8e+sZih1UjM57FqBbGpkDP8CtH1FF3REaHOG9XB_7A@mail.gmail.com>
 <CAPvyiyJ5K4Dr27gUtX-Vr02wXG=RjiqR0VeVcdORNqwF6x4xiA@mail.gmail.com>
 <CACg0bd3xZLELxCJrrB6jG1DnvpaGFKtFYoeMAeNRscFZ-cG8HA@mail.gmail.com>
 <CABe8uE3DAQrz9vm-N1wM9uDfU+hR6++d=9eMALKJoDY231Bnkw@mail.gmail.com>
Message-ID: <CACg0bd02bLsEtgGiNdxwqtE+bd1334bmyT4Bbsic7Ms6G5jVRA@mail.gmail.com>

Yes, it's 2 subclasses hierarchy.
https://github.com/iselo/jdk-optional/tree/master/lib/src
I'm open to learning about my pitfalls.

# JMH version: 1.36

# VM version: JDK 20.0.2, Java HotSpot(TM) 64-Bit Server VM, 20.0.2+9-78

# VM invoker:
/Library/Java/JavaVirtualMachines/jdk-20.jdk/Contents/Home/bin/java

# VM options: -Dfile.encoding=UTF-8
-Djava.io.tmpdir=/Users/iselo/IdeaProjects/jmh/lib/build/tmp/jmh
-Duser.country=GB -Duser.language=en -Duser.variant

# Blackhole mode: compiler (auto-detected, use
-Djmh.blackhole.autoDetect=false to disable)

# Warmup: 2 iterations, 10 s each

# Measurement: 10 iterations, 10 s each

# Timeout: 10 min per iteration

# Threads: 1 thread, will synchronize iterations

# Benchmark mode: Throughput, ops/time

On Mon, Aug 28, 2023 at 4:04?PM - <liangchenblue at gmail.com> wrote:

> Can you share the benchmark code? Maybe C2 profiled class hierarchy,
> determined your optional only has 2 subclasses and can thus generate
> optimized machine code. Or maybe your benchmark is wrong that the result is
> not consumed by blackhole so the whole benchmark is moot. We need the code
> to make a verdict.
>
> Chen
>
> On Mon, Aug 28, 2023 at 6:27?PM Oleksii Kucheruk <
> iselo+openjdk at raccoons.co> wrote:
>
>> Thank you Qu?n.
>>
>> All  you saying guys make sense.
>> Yes there is a difference calling methods by pointer and involving
>> vtable. But one thing didn't came out of my head:
>> If virtual dispatch dispatch is 10-time more expensive and polymorphism
>> is a performance killer so how combinations of "return optional -
>> isPresent- get" or "return empty - isEmpty" with virtual dispatch and
>> memory allocation for every empty or sole but polymorph empty could perform
>> equally or even beat the near zero-cost abstraction of Value classes
>> according to JMH?
>>
>> Maybe private final static nested EmptyOptional invokevirtual bytecode refers
>> a final methods and it need not have a vtable slot allocated. This means
>> that, after linking, an invokevirtual bytecode might in fact collapse into
>> the equivalent of an invokestatic bytecode.
>> The question of full dynamic with anonymous overloading is still unclear
>> to me.
>>
>> Benchmark                                               Mode  Cnt
>>     Score           Error  Units
>>
>> *OptionalComboIsPresentGet.opDynamicAnonymous           thrpt   30
>> 1059868995.937 ?  51273067.116  ops/s*
>>
>> OptionalComboIsPresentGet.opJdk                        thrpt   30  1017505800.567
>> ?  16007847.872  ops/s
>>
>> OptionalComboIsPresentGet.opNestedStatic               thrpt   30   951493332.957
>> ?  12167812.398  ops/s
>>
>>
>> OptionalComboOfIsPresentGetTest.opDynamicAnonymous     thrpt   30  1426348334.485
>> ?  20889455.433  ops/s
>>
>> *OptionalComboOfIsPresentGetTest.opJdk                  thrpt   30
>> 1435570789.822 ?  16587538.659  ops/s*
>>
>> OptionalComboOfIsPresentGetTest.opNestedStatic         thrpt   30  1418853644.215
>> ?  27755398.645  ops/s
>>
>>
>> *OptionalComboOfNullableIsEmptyTest.opDynamicAnonymous  thrpt   30
>> 1434399595.592 ?  14749443.903  ops/s*
>>
>> OptionalComboOfNullableIsEmptyTest.opJdk               thrpt   30  1255375023.531
>> ? 107403119.573  ops/s
>>
>> OptionalComboOfNullableIsEmptyTest.opNestedStatic      thrpt   30  1415705702.964
>> ?  26328318.672  ops/s
>>
>>
>> OptionalEmptyTest.opDynamicAnonymous                   thrpt   30  1417895521.763
>> ?  26311640.557  ops/s
>>
>> *OptionalEmptyTest.opJdk                                thrpt   30
>> 1423940087.962 ?  18515297.860  ops/s*
>>
>> OptionalEmptyTest.opNestedStatic                       thrpt   30  1424779162.084
>> ?  20288793.337  ops/s
>>
>>
>> OptionalGetTest.emDynamicAnonymous                     thrpt   30      569132.235
>> ?     11089.903  ops/s
>>
>> *OptionalGetTest.emJdk                                  thrpt   30
>> 549764.038 ?     14768.566  ops/s*
>>
>> OptionalGetTest.emNestedStatic                         thrpt   30      568308.722
>> ?      6075.671  ops/s
>>
>>
>> OptionalGetTest.opDynamicAnonymous                     thrpt   30   953788065.414
>> ?   7043419.784  ops/s
>>
>> *OptionalGetTest.opJdk                                  thrpt   30
>> 1015679232.049 ?  11726562.032  ops/s*
>>
>> OptionalGetTest.opNestedStatic                         thrpt   30   944209513.151
>> ?  17718342.519  ops/s
>>
>>
>> OptionalIsPresentTest.emDynamicAnonymous               thrpt   30   869086292.481
>> ?  11668636.886  ops/s
>>
>> *OptionalIsPresentTest.emJdk                            thrpt   30
>> 977042244.447 ?  44558020.220  ops/s*
>>
>> OptionalIsPresentTest.emNestedStatic                   thrpt   30   953424664.631
>> ?   8448564.963  ops/s
>>
>>
>> OptionalIsPresentTest.opDynamicAnonymous               thrpt   30   953285872.799
>> ?   6562894.941  ops/s
>>
>> *OptionalIsPresentTest.opJdk                            thrpt   30
>> 1006926903.885 ?  18055487.689  ops/s*
>>
>> OptionalIsPresentTest.opNestedStatic                   thrpt   30   954121471.431
>> ?   6829528.708  ops/s
>>
>>
>> OptionalOfNullableTest.emDynamicAnonymous              thrpt   30  1422939780.266
>> ?  21693247.354  ops/s
>>
>> *OptionalOfNullableTest.emJdk                           thrpt   30
>> 1423340184.237 ?  21296444.017  ops/s*
>>
>> OptionalOfNullableTest.emNestedStatic                  thrpt   30  1414965236.385
>> ?  26021734.344  ops/s
>>
>>
>> OptionalOfNullableTest.opDynamicAnonymous              thrpt   30  1412594454.538
>> ?  28123612.298  ops/s
>>
>> *OptionalOfNullableTest.opJdk                           thrpt   30
>> 1427924599.589 ?  23469517.835  ops/s*
>>
>> OptionalOfNullableTest.opNestedStatic                  thrpt   30  1420053175.637
>> ?  21170929.571  ops/s
>>
>>
>> OptionalOfTest.emDynamicAnonymous                      thrpt   30      549907.559
>> ?     14560.954  ops/s
>>
>> OptionalOfTest.emJdk                                   thrpt   30      557858.903
>> ?      2851.076  ops/s
>>
>> *OptionalOfTest.emNestedStatic                          thrpt   30
>> 548655.854 ?     10875.674  ops/s*
>>
>>
>> OptionalOfTest.opDynamicAnonymous                      thrpt   30  1411307270.435
>> ?  19832207.408  ops/s
>>
>> OptionalOfTest.opJdk                                   thrpt   30  1400651442.726
>> ?  23641065.234  ops/s
>>
>> *OptionalOfTest.opNestedStatic                          thrpt   30
>> 1433953744.298 ?  21414147.936  ops/s*
>>
>>
>> On Mon, Aug 28, 2023 at 11:13?AM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Polymorphism is a performance killer. Normally this does not matter
>>> much, but for thin wrappers such as Optional, this is one of the most
>>> important factor.
>>>
>>> Behaviour polymorphism requires virtual dispatch and prevents inlining.
>>> This is really detrimental, as simple operations such as a getter which is
>>> previously only consisted of a memory load, in the presence of polymorphism
>>> would have to go through a 10-time more expensive virtual dispatch.
>>> Function calls, especially virtual ones, are also opaque and prohibit
>>> compiler optimisations.
>>>
>>> Layout polymorphism prevents direct accesses and requires indirection.
>>> This means that for every instance of Optional created a memory allocation
>>> is required. Optional is expected to be a near zero-cost abstraction in the
>>> presence of Value classes, so making it polymorphic is unacceptable.
>>>
>>> Thanks.
>>>
>>> On Wed, 23 Aug 2023 at 22:43, Oleksii Kucheruk <
>>> iselo+openjdk at raccoons.co> wrote:
>>>
>>>> Hi there.
>>>> I have found that `java.util.Optional` is written procedural style and
>>>> has `ifnonnull`  checks in each method. I propose to refactor `Optional` in
>>>> accordance to OOP-style. This will eliminates all unnecessary
>>>> `if`-statements, removes duplications and reduces bytecode size more then
>>>> twice.
>>>>
>>>> I have two solutions:
>>>> 1. Completely dynamic that avoids single static `EMPTY` instance and
>>>> unchecked casting of each `Optional.empty()`
>>>> 2. Preserving original single static `EMPTY` per VM.
>>>>
>>>> Also there are couple methods that throws NPE due to calling methods on
>>>> null-objects and requires to add `Objects.requireNonNull(...)`.
>>>>
>>>> OptionalInt, OptionalDouble, OptionalLong could be refactored same way
>>>> even with remove of additional boolean variable `isPresent`.
>>>>
>>>> Since I'm new here any guidance will be helpful.
>>>> Thank you in advance.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230828/220275b1/attachment-0001.htm>

From sgehwolf at openjdk.org  Mon Aug 28 14:44:11 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 28 Aug 2023 14:44:11 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
 <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
 <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>
 <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
Message-ID: <YUQYZyYbPMcuEI9CBHQPuFbr8GlVDSK6xz7h5f7FRGE=.7fe0d7cf-da54-4d20-8556-17d7b45af8c6@github.com>

On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Something fishy here, is this working around a bug in GraaVM native image or why does this change need to be in JDK?
>> 
>> I've now realized that the bug had an incorrect statement in the description. The cycle happens due to the `Runtime.getRuntime().maxMemory()` implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code relies on the `Runtime.getRuntime().maxMemory()` API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no?
>> 
>> With that said, it's seems a rather uncontroversial change with very limited scope. Do you see anything problematic in this patch? Happy to revise if you think there are some no-no's :)
>
>> I've now realized that the bug had an incorrect statement in the description. The cycle happens due to the `Runtime.getRuntime().maxMemory()` implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code relies on the `Runtime.getRuntime().maxMemory()` API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no?
>> 
>> With that said, it's seems a rather uncontroversial change with very limited scope. Do you see anything problematic in this patch? Happy to revise if you think there are some no-no's :)
> 
> Recursive initialization issues can tricky and often it comes down to deciding where to break the cycle. In this case, it seems a bit fragile to do it in CgroupUtil as it should be allowed to use any of the file system APIs to access cgroups or proc files. Part of me wonders if this would be better handled in their implementation of jdk.internal.misc.VM or Runtime.maxMemory but maybe you've been there already?

@AlanBateman Is there anything else you need me to do? If so, please let me know. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1695824275

From simonis at openjdk.org  Mon Aug 28 14:50:14 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 28 Aug 2023 14:50:14 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
Message-ID: <ldrH2mwEODKrt0-3OnNWrtrQWzYpZh9xw1spuQ1_Bqg=.d877db9f-5107-4f46-91e8-355cc2cede35@github.com>

On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixup javadoc
>  - Review feedback: move JLIA to ClassFrameInfo

Hi Mandy,

thanks for doing this experiment. I've looked at your proposal, but I can't see how it can help to fix [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500). Your change proposes to add a bunch of new Java SE specific changes which can't be downported to any previous JDK version but [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500) affects JDK 11, 17 and 21. I'd therefore still appreciate if we could fix [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500) first before we start to redesign the public StackWalker API.

In case you do redesign the `StackWalker` API, I fully agree with @bchristi-git that the current version is overkill. As your [specdiff](https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html) shows, it introduces 34 API changes (9 additions and 18 changes) with no clear benefit. I second @bchristi-git that an addtional `StackWalker.Option` would be simpler and much cleaner (I'd vote for `SKIP_METHOD_INFO`) if we decide to change the API at all..

Another point that should be taken into account when we start to redesign the StackWalker API is its interaction with the `-XX:+ShowHiddenFrames` command line parameter. This is currently not specified and can lead to surprising results (see e.g. [this remark about failing JTreg tests with `-XX:+ShowHiddenFrames`](https://github.com/openjdk/jdk/pull/14773#issuecomment-1631065562)).

I'm also not convinced that doing frame filtering in Java is the right thing to do. If we have to call into the JVM anyway, I think it would be more natural to let the JVM do as much of the work as possible. To me it seems as if your change is mostly about improving the performance of stack walks and I think this could be achieved to an even greater extent without the need to change the public API, simply by improving the implementation. Such improvements could than also be downported to JDK 17 & 21 which isn't possible with your approach.

If it turns out that API changes are required in order to achieve superior performance, we should try to keep them to a minimum and weight them against the performance benefits. E.g. we could add a single `getCallerClass(int depth)` method which would provide all the benefits of `Kind.CLASS_INFO` but with considerably less API changes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1598457114

From stuefe at openjdk.org  Mon Aug 28 15:21:12 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Aug 2023 15:21:12 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
Message-ID: <2dODX4TG2azYQvw_e3DirrVeZlHcTY1YStP6eGPoEB8=.5d469862-c347-49f8-940b-4cbbc27fe33c@github.com>

On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use the
> JDK's version of `Metrics` in GraalVM. See the bug for details as to why this is
> needed.
> 
> Testing:
> - [x] GraalVM builds with/without the fix and the reproducer (fails before/works after)
> - [x] `jdk/internal/platform` jtreg tests on Linux x86_64 (cgv1).
> - [x] GHA - passed (Failed GHA cross compile on RISCV is unrelated)

Looks good to me. A comment would be nice, possibly above the imports, warning about using nio.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15416#pullrequestreview-1598518803

From dfuchs at openjdk.org  Mon Aug 28 15:30:23 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Aug 2023 15:30:23 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
Message-ID: <B--8AtK82CNqIUdwf5mK8yEjJei6m9l__6PspBNreWs=.ed4c6e36-d11c-41b7-81c7-adb4c3f75988@github.com>

On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixup javadoc
>  - Review feedback: move JLIA to ClassFrameInfo

As far as I understand the point of this change is to provide a new API that will allow a caller to request class information only, thus improving performance when only class information is required. Whether we use a new enum or a new option constant, we will need changes to the API documentation. If we use a new option constant we won't need any new static factory methods though.
Whether filtering is performed in java or in native is orthogonal to that. The trend these days is to do as much as possible in java, and the patch goes in that direction. There is a small price to pay if the frame to be filtered is a continuation, as this will cause the member name to be resolved. Is that significant enough to push back towards doing the filtering in native: I don't know. It may be worth investigating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1695899325

From alanb at openjdk.org  Mon Aug 28 15:32:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Aug 2023 15:32:22 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
 <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
 <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>
 <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
Message-ID: <t2e8X8EBE2XOIbISiHzOQSVkN3j0rNxJ7MAVywKCY-E=.1b136148-ab16-4948-97d0-9e8bf5f1311a@github.com>

On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Something fishy here, is this working around a bug in GraaVM native image or why does this change need to be in JDK?
>> 
>> I've now realized that the bug had an incorrect statement in the description. The cycle happens due to the `Runtime.getRuntime().maxMemory()` implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code relies on the `Runtime.getRuntime().maxMemory()` API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no?
>> 
>> With that said, it's seems a rather uncontroversial change with very limited scope. Do you see anything problematic in this patch? Happy to revise if you think there are some no-no's :)
>
>> I've now realized that the bug had an incorrect statement in the description. The cycle happens due to the `Runtime.getRuntime().maxMemory()` implementation in GraalVM to use JDK `Metrics`, since the `ByteBuffer` [code relies on the `Runtime.getRuntime().maxMemory()` API](https://github.com/openjdk/jdk/blob/76b9011c9ecb8c0c713a58d034f281ba70d65d4e/src/java.base/share/classes/jdk/internal/misc/VM.java#L261). The GraalVM impl to use the JDK Metrics seems a reasonable thing to do, no?
>> 
>> With that said, it's seems a rather uncontroversial change with very limited scope. Do you see anything problematic in this patch? Happy to revise if you think there are some no-no's :)
> 
> Recursive initialization issues can tricky and often it comes down to deciding where to break the cycle. In this case, it seems a bit fragile to do it in CgroupUtil as it should be allowed to use any of the file system APIs to access cgroups or proc files. Part of me wonders if this would be better handled in their implementation of jdk.internal.misc.VM or Runtime.maxMemory but maybe you've been there already?

> @AlanBateman Is there anything else you need me to do? If so, please let me know. Thanks!

I don't think the JDK is the right place to workaround this issue. Also, we really need to get back re-implementing FileInputStream and friends on the new API, in which case the original issue will come back again. So I think it would be better to see how this can be fixed in the native image code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1695902738

From lkorinth at openjdk.org  Mon Aug 28 16:01:53 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 28 Aug 2023 16:01:53 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder
Message-ID: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>

Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.

I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`

Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:

   /**
     * Create ProcessBuilder using the java launcher from the jdk to
     * be tested.
     *
     * <p><b> Please observe that you likely should use
     * createTestJvm() instead of this method because createTestJvm()
     * will add JVM options from "test.vm.opts" and "test.java.opts"
     * </b> and this method will not do that.
     *
     * @param command Arguments to pass to the java command.
     * @return The ProcessBuilder instance representing the java command.
     */


I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...

I have run tier 1 testing, and I have started more exhaustive testing.

-------------

Commit messages:
 - 8315097: Rename createJavaProcessBuilder

Changes: https://git.openjdk.org/jdk/pull/15452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315097
  Stats: 756 lines in 462 files changed: 22 ins; 10 del; 724 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From lancea at openjdk.org  Mon Aug 28 16:44:24 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Aug 2023 16:44:24 GMT
Subject: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3
Message-ID: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>

Hi all,

Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK

The [Zlib Data Compression Library](https://github.com/madler/zlib ) has released Zlib 1.3 on August 18, 2023.

There are a [small number of updates](https://github.com/madler/zlib/compare/v1.2.13...master ) between 1.2.13 and 1.3 

Mach5 tiers1-6 have run clean as do the JCK tests

-------------

Commit messages:
 - Update zlib to zlib 1.3

Changes: https://git.openjdk.org/jdk/pull/15453/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15453&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315117
  Stats: 2075 lines in 25 files changed: 532 ins; 1006 del; 537 mod
  Patch: https://git.openjdk.org/jdk/pull/15453.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15453/head:pull/15453

PR: https://git.openjdk.org/jdk/pull/15453

From sgehwolf at openjdk.org  Mon Aug 28 16:45:20 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 28 Aug 2023 16:45:20 GMT
Subject: RFR: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <t2e8X8EBE2XOIbISiHzOQSVkN3j0rNxJ7MAVywKCY-E=.1b136148-ab16-4948-97d0-9e8bf5f1311a@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
 <O62JrL3Lmvti1FfRSxJK7tYFlipmSnIrWOWp_-tHHMU=.d208ae31-c30a-4fd8-a72e-191090915c59@github.com>
 <RcR-usng6NlreDJgjFmA5akggx7T210LWIp06unPTbk=.bda4f68f-c685-4f97-9578-233de80d091f@github.com>
 <wuDdg2N_73aiytStGzESW_2qxx0Lj_-jYckyBZXm9hU=.04f32da8-5296-4dd1-962b-4cc580b61cf2@github.com>
 <t2e8X8EBE2XOIbISiHzOQSVkN3j0rNxJ7MAVywKCY-E=.1b136148-ab16-4948-97d0-9e8bf5f1311a@github.com>
Message-ID: <-qSWaTWsYKTDSbDV125k8y4gOXNNVrc08BEVQXZ3euQ=.00694bcd-6d49-4166-9eae-49d849686191@github.com>

On Mon, 28 Aug 2023 15:29:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman Is there anything else you need me to do? If so, please let me know. Thanks!
> 
> I don't think the JDK is the right place to workaround this issue. Also, we really need to get back re-implementing FileInputStream and friends on the new API, in which case the original issue will come back again. So I think it would be better to see how this can be fixed in the native image code.

OK. I understand. Withdrawing this PR then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15416#issuecomment-1696011153

From sgehwolf at openjdk.org  Mon Aug 28 16:45:22 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 28 Aug 2023 16:45:22 GMT
Subject: Withdrawn: 8314940: Use of NIO in JDKs Metrics implementation causes
 issues in GraalVM
In-Reply-To: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
References: <VBM8e0sqEr7UBszNuWrhmIZwkY9ugnH2yy33jvbocp8=.a13235f8-9f0e-43d6-a83f-a73764ec166d@github.com>
Message-ID: <N0dDjLNJKtcmJaum2vBwat_8MREkfRV8I0MfiCWcDYs=.10ee752b-f3c1-438e-b9f1-667e4305744e@github.com>

On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use the
> JDK's version of `Metrics` in GraalVM. See the bug for details as to why this is
> needed.
> 
> Testing:
> - [x] GraalVM builds with/without the fix and the reproducer (fails before/works after)
> - [x] `jdk/internal/platform` jtreg tests on Linux x86_64 (cgv1).
> - [x] GHA - passed (Failed GHA cross compile on RISCV is unrelated)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15416

From alanb at openjdk.org  Mon Aug 28 17:13:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Aug 2023 17:13:10 GMT
Subject: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3
In-Reply-To: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
References: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
Message-ID: <D9eLHGAJediL7GaMubxF3lgXYKAfGuKE6_dOA0IGlMM=.6650b8fe-d165-47d6-a12b-6a3466e7d7c0@github.com>

On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib ) has released Zlib 1.3 on August 18, 2023.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.2.13...master ) between 1.2.13 and 1.3 
> 
> Mach5 tiers1-6 have run clean as do the JCK tests

Are there any changes from the upstream zlib 1.3 code that should be called out or is zlib 1.3 copied in without any changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15453#issuecomment-1696048680

From lancea at openjdk.org  Mon Aug 28 17:18:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 28 Aug 2023 17:18:07 GMT
Subject: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3
In-Reply-To: <D9eLHGAJediL7GaMubxF3lgXYKAfGuKE6_dOA0IGlMM=.6650b8fe-d165-47d6-a12b-6a3466e7d7c0@github.com>
References: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
 <D9eLHGAJediL7GaMubxF3lgXYKAfGuKE6_dOA0IGlMM=.6650b8fe-d165-47d6-a12b-6a3466e7d7c0@github.com>
Message-ID: <_KVQLcikiE-xGuOXrsTuLbFH4c_omw4_lnSIbMFe5Xw=.ebe1ec1a-7c65-4670-91ff-c9a910586b03@github.com>

On Mon, 28 Aug 2023 17:10:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Are there any changes from the upstream zlib 1.3 code that should be called out or is zlib 1.3 copied in without any changes?

It was a clean copy(which I have been able to do as of zlib 1.2.13).  Sorry I should have mentioned this in the PR request

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15453#issuecomment-1696055842

From coffeys at openjdk.org  Mon Aug 28 17:29:16 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 28 Aug 2023 17:29:16 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v4]
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <-X44ANr8Q71q0RvuGXwDdYb6wCrimUtR3P_VhavFKDM=.50726b11-0bdd-4e7e-a273-4eec435787b6@github.com>

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:

 - Tidy up SignedLoggerFinderTest.java
 - Code contribution from Daniel included. New tests. Fix up extra service call issues

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15404/files
  - new: https://git.openjdk.org/jdk/pull/15404/files/3b35c440..83fcfae8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=02-03

  Stats: 389 lines in 9 files changed: 366 ins; 10 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From naoto.sato at oracle.com  Mon Aug 28 17:59:13 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 28 Aug 2023 10:59:13 -0700
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <0fcec564-d896-b020-fd10-b419ea617e4d@oracle.com>

Vote: yes

Naoto

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Lance Andersen to Membership in the Core Libraries Group
> 
> Lance has been contributing to the OpenJDK at Oracle since 2007. He has 
> been the JDBC spec lead since 2005 and an OpenJDK committer since day 1. 
> He has extensive experience with Java EE, Databases and SQL and is 
> improving the integrity and performance of Zip and JAR implementations.
> 
> Votes are due by September 8th, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Roger Riggs
> 
> [1] https://openjdk.org/census#core-libs
> 
> [2] https://openjdk.org/groups/#member-vote||
> 

From naoto.sato at oracle.com  Mon Aug 28 18:00:08 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 28 Aug 2023 11:00:08 -0700
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <0da8b311-6051-e325-ec45-b5ef3b4490fe@oracle.com>

Vote: yes

Naoto

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group
> 
> Daniel has been contributing to the OpenJDK Core Libraries at Oracle 
> since 2012. He is leading the networking team and has made nearly 400 
> contributions to OpenJDK since JDK 6.
> 
> Votes are due by September 8th, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Roger Riggs
> 
> [1] https://openjdk.org/census#core-libs
> 
> [2] https://openjdk.org/groups/#member-vote

From naoto.sato at oracle.com  Mon Aug 28 18:00:44 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 28 Aug 2023 11:00:44 -0700
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <c2f6c779-1f58-6df1-3810-281c9f34e517@oracle.com>

Vote: yes

Naoto

On 8/25/23 8:24 AM, Roger Riggs wrote:
> I hereby nominate Michael McMahon to Membership in the Core Libraries Group
> 
> Michael has been contributing to the OpenJDK Core Libraries since 2008, 
> originally at Sun Microsystems, now Oracle. He has deep networking 
> experience and has made more than 260 contributions to OpenJDK.
> 
> Votes are due by September 8th, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible to 
> vote on this nomination. Votes must be cast in the open by replying to 
> this mailing list For Lazy Consensus voting instructions, see [2].
> 
> Roger Riggs
> 
> [1] https://openjdk.org/census#core-libs
> 
> [2] https://openjdk.org/groups/#member-vote
> 

From mchung at openjdk.org  Mon Aug 28 18:19:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 28 Aug 2023 18:19:12 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <ldrH2mwEODKrt0-3OnNWrtrQWzYpZh9xw1spuQ1_Bqg=.d877db9f-5107-4f46-91e8-355cc2cede35@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
 <ldrH2mwEODKrt0-3OnNWrtrQWzYpZh9xw1spuQ1_Bqg=.d877db9f-5107-4f46-91e8-355cc2cede35@github.com>
Message-ID: <8oljuTbN4vzVwFxUy0fqWeYOiLRK6A3klSx-UAvQ-is=.04a40a0f-1178-4348-a4b7-9f1e173197e1@github.com>

On Mon, 28 Aug 2023 14:47:20 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> thanks for doing this experiment. I've looked at your proposal, but I can't see how it can help to fix [JDK-8311500](https://bugs.openjdk.org/browse/JDK-8311500).....

I think you may be confused.   This PR can be viewed as follows:

1. introduce a new API to allow walking the stack with no method information and the implementation will use `ClassFrameInfo` buffer
2. reduce the memory footprint of `StackFrameInfo` buffer
3. change `getCallerClass` to use the `ClassFrameInfo` buffer
4. fix JDK-8311500 by checking if a method is caller-sensitive in Java.   Note that the filtering of reflection frames has been done in Java.

#2-4 can be backport to older releases.   #2 improve the StackWalker performance.    Backporting the PR should be straight-forward by excluding the API and javadoc change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1696134958

From mchung at openjdk.org  Mon Aug 28 18:33:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 28 Aug 2023 18:33:12 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v6]
In-Reply-To: <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <BMADPPRuc_qihgiCWiWsw7RsJt2y844mTZHQiW2EA6M=.91a9a9e6-19bd-422a-a390-e81ba92b5417@github.com>
Message-ID: <LQwcYWqePIUxmuOue3_NRCrZkTkLpZ2yeoWUGJqJNMg=.f47a277b-076a-4cdd-9533-26ef329b6fb8@github.com>

On Fri, 25 Aug 2023 22:22:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
>> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
>> instead and such stack walker will save the overhead (1) to extract the method information
>> and (2) the memory used for the stack walking.   In addition, this can also fix
>> 
>> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(interestingClasses::contains)
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would hav...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixup javadoc
>  - Review feedback: move JLIA to ClassFrameInfo

Thank you all for the feedback on the API.   I discussed with @AlanBateman and @RogerRiggs offline.  Alan suggests an option to drop that would work well (`Lookup::dropLookupMode` is a precedent).  I like the suggested name `DROP_METHOD_INFO`.

| Option | getDeclaringClass | class name | method info |
| ------- | ------------------ | ----------- | ------------ |
| | N | Y | Y |
| `RETAIN_CLASS_REFERENCE` | Y | Y | Y |
| `DROP_METHOD_INFO` | N | Y | N |
| `RETAIN_CLASS_REFERENCE, DROP_METHOD_INFO` | Y | Y | N |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1696152180

From alanb at openjdk.org  Mon Aug 28 18:41:07 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Aug 2023 18:41:07 GMT
Subject: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3
In-Reply-To: <_KVQLcikiE-xGuOXrsTuLbFH4c_omw4_lnSIbMFe5Xw=.ebe1ec1a-7c65-4670-91ff-c9a910586b03@github.com>
References: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
 <D9eLHGAJediL7GaMubxF3lgXYKAfGuKE6_dOA0IGlMM=.6650b8fe-d165-47d6-a12b-6a3466e7d7c0@github.com>
 <_KVQLcikiE-xGuOXrsTuLbFH4c_omw4_lnSIbMFe5Xw=.ebe1ec1a-7c65-4670-91ff-c9a910586b03@github.com>
Message-ID: <BbgkXVaD-WR6RheNuua7TTZDP4saGJ5jVXFb5lebWQA=.c3ffbd4c-41bc-4794-a9e3-53b32ec3b66f@github.com>

On Mon, 28 Aug 2023 17:15:36 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> It was a clean copy(which I have been able to do as of zlib 1.2.13). Sorry I should have mentioned this in the PR request

That's okay, I just wanted to check to be sure that the ChangeLog_java (renamed adler32.c -> zadler32.c, crc32c -> zcrc32.c) is everything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15453#issuecomment-1696163199

From coffeys at openjdk.org  Mon Aug 28 18:45:03 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 28 Aug 2023 18:45:03 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v5]
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <yymNHSguBFUdANfiYohZnRvBrjV9teC-sqNQkCVOlQI=.768ca0ec-c710-4ed3-8939-672c1b884192@github.com>

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Fix up test cases

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15404/files
  - new: https://git.openjdk.org/jdk/pull/15404/files/83fcfae8..ca4cd4f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=03-04

  Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From dfuchs at openjdk.org  Mon Aug 28 18:47:21 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Aug 2023 18:47:21 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v4]
In-Reply-To: <-X44ANr8Q71q0RvuGXwDdYb6wCrimUtR3P_VhavFKDM=.50726b11-0bdd-4e7e-a273-4eec435787b6@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <-X44ANr8Q71q0RvuGXwDdYb6wCrimUtR3P_VhavFKDM=.50726b11-0bdd-4e7e-a273-4eec435787b6@github.com>
Message-ID: <HvrBmbQOutdCA4MOZF5h9a2wHlTbyK-mWlOwyt04QLY=.9b0ab1fe-ae0c-41b9-8083-b259baac89e9@github.com>

On Mon, 28 Aug 2023 17:29:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy up SignedLoggerFinderTest.java
>  - Code contribution from Daniel included. New tests. Fix up extra service call issues

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRecursiveLoadingTest.java line 58:

> 56:      * of this run). Running test in signed and unsigned jar mode for sanity coverage.
> 57:      * The current bug only manifests when jars are signed.
> 58:      */

Suggestion:

    /**
     * This test triggers recursion by calling `System.getLogger` in the class init
     * of a custom LoggerFinder. Without the fix, this is expected to throw 
     * java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.logger.LoggerFinderLoader$ErrorPolicy
     * caused by: java.lang.StackOverflowError
     *
     */

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRecursiveLoadingTest.java line 65:

> 63:         logs.stream().map(SimpleLogRecord::of).forEach(System.out::println);
> 64:         logs.stream().map(SimpleLogRecord::of).forEach(SimpleLogRecord::check);
> 65:         assertEquals(String.valueOf(logs.size()), String.valueOf(2));*/

Why is this code commented? Is it an oversight?

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/RecursiveLoadingTest.java line 55:

> 53:      * of this run). Running test in signed and unsigned jar mode for sanity coverage.
> 54:      * The current bug only manifests when jars are signed.
> 55:      */

Suggestion:

    /**
     * This test triggers recursion by calling `System.getLogger` in the class init
     * of a custom LoggerFinder. Without the fix, this is expected to throw 
     * java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.logger.LoggerFinderLoader$ErrorPolicy
     * caused by: java.lang.StackOverflowError
     *
     */

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/RecursiveLoadingTest.java line 61:

> 59:         logs.stream().map(SimpleLogRecord::of).forEach(System.out::println);
> 60:         logs.stream().map(SimpleLogRecord::of).forEach(SimpleLogRecord::check);
> 61:         assertEquals(String.valueOf(logs.size()), String.valueOf(2));

See suggested changes to SimpleLoggerFinder
Suggestion:

        assertEquals(String.valueOf(logs.size()), String.valueOf(3));

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/SimpleLoggerFinder.java line 28:

> 26: import java.lang.*;
> 27: import java.util.*;
> 28: import java.util.concurrent.CopyOnWriteArrayList;

Suggestion:

import java.util.concurrent.CopyOnWriteArrayList;
import java.util.concurrent.ConcurrentHashMap;

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/SimpleLoggerFinder.java line 49:

> 47:     }
> 48: 
> 49:     public static final CopyOnWriteArrayList<Object> LOGS = new CopyOnWriteArrayList<>();

Suggest to move the declaration before the static block above.

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/SimpleLoggerFinder.java line 50:

> 48: 
> 49:     public static final CopyOnWriteArrayList<Object> LOGS = new CopyOnWriteArrayList<>();
> 50: 

Suggestion:


    private final Map<String, SimpleLogger> loggers = new ConcurrentHashMap<>();

    public SimpleLoggerFinder() {
        System.getLogger("dummy")
                .log(System.Logger.Level.INFO,
                        "Logger finder service created");
    }

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/SimpleLoggerFinder.java line 53:

> 51:     @Override
> 52:     public System.Logger getLogger(String name, Module module) {
> 53:         return new SimpleLogger(name);

Suggestion:

        return loggers.computeIfAbsent(name, SimpleLogger::new);

We're now getting the "dummy" logger twice, and since its constructor has side effects on its underlying jul logger implementation, we don't want to create two loggers for the same name - as that would cause two identical SimpleHandler instances to be added to the same underlying logger, making the log message appear twice in the LOGS list.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307771237
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307725024
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307773997
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307773194
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307776466
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307774748
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307775886
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307777399

From dfuchs at openjdk.org  Mon Aug 28 18:47:22 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Aug 2023 18:47:22 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v4]
In-Reply-To: <HvrBmbQOutdCA4MOZF5h9a2wHlTbyK-mWlOwyt04QLY=.9b0ab1fe-ae0c-41b9-8083-b259baac89e9@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <-X44ANr8Q71q0RvuGXwDdYb6wCrimUtR3P_VhavFKDM=.50726b11-0bdd-4e7e-a273-4eec435787b6@github.com>
 <HvrBmbQOutdCA4MOZF5h9a2wHlTbyK-mWlOwyt04QLY=.9b0ab1fe-ae0c-41b9-8083-b259baac89e9@github.com>
Message-ID: <YfhNbwD1hfbbH7nBtFqYJoWpjQJM-ZHwm3EdlpnHckw=.66ad99f8-3db5-484e-b980-f2c9e0b8a310@github.com>

On Mon, 28 Aug 2023 17:42:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy up SignedLoggerFinderTest.java
>>  - Code contribution from Daniel included. New tests. Fix up extra service call issues
>
> test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRecursiveLoadingTest.java line 65:
> 
>> 63:         logs.stream().map(SimpleLogRecord::of).forEach(System.out::println);
>> 64:         logs.stream().map(SimpleLogRecord::of).forEach(SimpleLogRecord::check);
>> 65:         assertEquals(String.valueOf(logs.size()), String.valueOf(2));*/
> 
> Why is this code commented? Is it an oversight?

BTW: With the modification suggested below in SimpleLoggerFinder, note that the expected number of messages should be 3 (not 2).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307772571

From dfuchs at openjdk.org  Mon Aug 28 18:52:14 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Aug 2023 18:52:14 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v5]
In-Reply-To: <yymNHSguBFUdANfiYohZnRvBrjV9teC-sqNQkCVOlQI=.768ca0ec-c710-4ed3-8939-672c1b884192@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <yymNHSguBFUdANfiYohZnRvBrjV9teC-sqNQkCVOlQI=.768ca0ec-c710-4ed3-8939-672c1b884192@github.com>
Message-ID: <XGLP17y0oTVvSQoDACtgpWQiIH6WzaS6ZZI-AA7oFVc=.505cae58-0220-4cb4-a350-d034f7085963@github.com>

On Mon, 28 Aug 2023 18:45:03 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix up test cases

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRecursiveLoadingTest.java line 64:

> 62:         logs.stream().map(SimpleLogRecord::of).forEach(System.out::println);
> 63:         logs.stream().map(SimpleLogRecord::of).forEach(SimpleLogRecord::check);
> 64:         assertEquals(String.valueOf(logs.size()), String.valueOf(2));

Suggestion:

        assertEquals(String.valueOf(logs.size()), String.valueOf(3));

See suggestions to SimpleLoggerFinder below...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307785939

From jbhateja at openjdk.org  Mon Aug 28 18:59:20 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Aug 2023 18:59:20 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v22]
In-Reply-To: <pjjbfHZkqTQxGyFkgQ-U6wFNgJo7a4D7jsicpcVQA_4=.56c8bf27-ae2d-441a-b034-542c35eb8203@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <PkSyELVYJ0ZUO3udhmW-V30AYoa5XYA9jZ-IzoogSJI=.31dcc4f0-2738-4979-ac29-5679f6297143@github.com>
 <q1BS6xbmCwurWxTfiGuWXwk921hQapX1vdOACcEx0H4=.1ea9f870-f9ca-4dd1-88ef-e76bba9bc38f@github.com>
 <WaE_HqgYyTUc_e1VVT4I3j_QnV8uvRa2nd62igBf-ME=.32799d89-f74b-4b14-ac7c-ed6d8a777fa6@github.com>
 <qEnZUMO8WSp3SlauW9y9hXxAy2yPF4dt88uOjQ35hls=.4560b634-fadf-4ab8-89c1-3d488b052d21@github.com>
 <pjjbfHZkqTQxGyFkgQ-U6wFNgJo7a4D7jsicpcVQA_4=.56c8bf27-ae2d-441a-b034-542c35eb8203@github.com>
Message-ID: <2NFjfo8C9unam7w-JOyVthNbkmTlAJH8tt56THmx6o8=.6858a6c3-dc83-46fa-adda-8ea1be6e02a0@github.com>

On Fri, 25 Aug 2023 18:59:47 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> Improvements are nice but it would not pay off if you have big regressions. I can accept 0.9x but 0.4x - 0.8x regressions should be investigated and implementation adjusted to avoid them.
>> 
>> Hello Vladimir (@vnkozlov) ,
>> 
>> As per your suggestion, the implementation was adjusted to address the regressions caused for STAGGER and REPEATED type of input data patterns. 
>> Please see below the new JMH performance data using the adjusted implementation.
>> 
>> In the new implementation, we don't call the AVX512 sort intrinsic at the top level (`Arrays.sort()`) . Instead, we take a decomposed or a 'building blocks' approach where we only intrinsify  (using AVX512 instructions) the partitioning and small array sort functions used in the current baseline ( `DualPivotQuickSort.sort()` ). Since the current baseline has logic to detect and sort special input patterns like STAGGER, we fallback to the current baseline instead of using AVX512 partitioning and sorting (which works best for RANDOM, REPEATED and SHUFFLE patterns).
>> 
>> Data below shows `Arrays.sort()` performance comparison between the current **Java baseline (DPQS)** vs. **AVX512 sort** (this PR)  using the `ArraysSort.java` JMH [benchmark](https://github.com/openjdk/jdk/pull/13568/files#diff-dee51b13bd1872ff455cec2f29255cfd25014a5dd33dda55a2fc68638c3dd4b2) provided in the PR for [JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)](https://github.com/openjdk/jdk/pull/13568/files#top) ( #13568)
>> 
>> - The following command line was used to run the benchmarks: ` java -jar $JDK_HOME/build/linux-x86_64-server-release/images/test/micro/benchmarks.jar -jvmArgs "-XX:CompileThreshold=1 -XX:-TieredCompilation" ArraysSort`
>> - The scores shown are the average time (us/op),  thus lower is better. The last column towards the right shows the speedup. 
>> 
>> 
>> |	Benchmark	|	Mode	|	Size	|	Baseline DPQS (us/op)	|	AVX512 partitioning & sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.Double.testSort	|	RANDOM	|	800	|	6.7	|	4.8	|	1.39x	|
>> |	ArraysSort.Double.testSort	|	RANDOM	|	7000	|	234.1	|	51.5	|	**4.55x**	|
>> |	ArraysSort.Double.testSort	|	RANDOM	|	50000	|	2155.9	|	470.0	|	**4.59x**	|
>> |	ArraysSort.Double.testSort	|	RANDOM	|	300000	|	15076.3	|	3391.3	|	**4.45x**	|
>> |	ArraysSort.Double.testSort	|	RANDOM	|	2000000	|	116445.5	|	27491.7	|	**4.24x**	|
>> |	ArraysSort.Double.testSort	|	REPEATED	|	800	|	2.3	|	1.7	|	1.35x	|
>> |	ArraysSort.Double.testSort	|	REPEATED	|	7000	|	23.3	|	12...
>
>> @vamsi-parasa I submitted our testing of latest v28 version. It found issue in `ArraysSort.java` new benchmark file. You missed `,`after year in copyright line:
>> 
>> ```
>>  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
>> ```
> 
> Thank you, Vladimir!

Hi @vamsi-parasa ,

I did some runs on linux by disabling intrinsification of  _arraySort and _arrayPartition since these are not handled for windows and non-x86 targets, just to measure the impact of java side code re-factoring. 

![image](https://github.com/openjdk/jdk/assets/59989778/2866e684-955d-4902-af61-e08ac3f548d9)

![image](https://github.com/openjdk/jdk/assets/59989778/0a5e3265-b821-4a43-874e-6f1501423a07)

![image](https://github.com/openjdk/jdk/assets/59989778/f192f259-36e6-4e3e-8082-5cb0c05c9f10)


Please find the results, may I request you to kindly verify performance number on windows to be sure that there are no performance degradation.

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1696209731

From lmesnik at openjdk.org  Mon Aug 28 19:06:11 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 28 Aug 2023 19:06:11 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <kTqMYPi97NeiCYDUN5NRbc7Z3eUlU8h4KxhgxYmRlTA=.06936fb1-58f7-4779-9814-55872d529630@github.com>

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

The. changes looks good. Please update copyrights for changed filed.
I expect that you completed execution of all tests to ensure that nothing is broken.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1598884378

From dfuchs at openjdk.org  Mon Aug 28 19:07:10 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 28 Aug 2023 19:07:10 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v5]
In-Reply-To: <XGLP17y0oTVvSQoDACtgpWQiIH6WzaS6ZZI-AA7oFVc=.505cae58-0220-4cb4-a350-d034f7085963@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <yymNHSguBFUdANfiYohZnRvBrjV9teC-sqNQkCVOlQI=.768ca0ec-c710-4ed3-8939-672c1b884192@github.com>
 <XGLP17y0oTVvSQoDACtgpWQiIH6WzaS6ZZI-AA7oFVc=.505cae58-0220-4cb4-a350-d034f7085963@github.com>
Message-ID: <wtdPdrri-xCiK-e7ZQ14HTzhJ6zqX17rgqFXPlp_11w=.4217dd5c-0090-49a3-ab09-9d7549d1ee40@github.com>

On Mon, 28 Aug 2023 18:49:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix up test cases
>
> test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRecursiveLoadingTest.java line 64:
> 
>> 62:         logs.stream().map(SimpleLogRecord::of).forEach(System.out::println);
>> 63:         logs.stream().map(SimpleLogRecord::of).forEach(SimpleLogRecord::check);
>> 64:         assertEquals(String.valueOf(logs.size()), String.valueOf(2));
> 
> Suggestion:
> 
>         assertEquals(String.valueOf(logs.size()), String.valueOf(3));
> 
> See suggestions to SimpleLoggerFinder below...

Creating a logger from within the SimpleLoggerFinder constructor ensures that we get the expected StackOverFlow when the patch is not present. I believe it's a better emulation for the issue that was detected with signed jars, where a logger was created while loading the provider.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1307798105

From duke at openjdk.org  Mon Aug 28 19:50:21 2023
From: duke at openjdk.org (Qing Xiao)
Date: Mon, 28 Aug 2023 19:50:21 GMT
Subject: RFR: 8297777: jdk.jlink StringSharingPlugin uses
 com.sun.tools.classfile library
Message-ID: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>

Migrate jdk.jlink StringSharingPlugin to use new classfile library

-------------

Commit messages:
 - Migrate jdk.jlink StringSharingPlugin to use new classfile library

Changes: https://git.openjdk.org/jdk/pull/15408/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15408&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297777
  Stats: 126 lines in 1 file changed: 12 ins; 54 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/15408.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15408/head:pull/15408

PR: https://git.openjdk.org/jdk/pull/15408

From asotona at openjdk.org  Mon Aug 28 19:50:21 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 28 Aug 2023 19:50:21 GMT
Subject: RFR: 8297777: jdk.jlink StringSharingPlugin uses
 com.sun.tools.classfile library
In-Reply-To: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>
References: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>
Message-ID: <ybE8winQLS2s3BVgY31FYLLxFKbAfE_k9Cp2TD8gGdo=.812c4827-1812-496a-8eb6-db07aff5b0b3@github.com>

On Wed, 23 Aug 2023 23:50:29 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Migrate jdk.jlink StringSharingPlugin to use new classfile library

It looks good, thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15408#issuecomment-1695382042

From naoto at openjdk.org  Mon Aug 28 20:02:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Aug 2023 20:02:38 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v9]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <7dG6GEy8w0hzvsilNcMt3ggialmCLclYRFyYo7y-x1E=.8ee62abd-5176-4dae-9318-45a9d222c386@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/5b536fab..f651ff7e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=07-08

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From naoto at openjdk.org  Mon Aug 28 20:05:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Aug 2023 20:05:41 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v10]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <J5WJ-mD95CWpEutUSXMzOtg5Gta5GGKOLCljA-FNU4g=.7db43831-4429-4877-852c-3f9fcddf6fad@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/text/ListFormat.java
  
  Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/f651ff7e..7d7aaf48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=08-09

  Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From naoto at openjdk.org  Mon Aug 28 20:49:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Aug 2023 20:49:12 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v10]
In-Reply-To: <J5WJ-mD95CWpEutUSXMzOtg5Gta5GGKOLCljA-FNU4g=.7db43831-4429-4877-852c-3f9fcddf6fad@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
 <J5WJ-mD95CWpEutUSXMzOtg5Gta5GGKOLCljA-FNU4g=.7db43831-4429-4877-852c-3f9fcddf6fad@github.com>
Message-ID: <2OcLQsNLR3byAza7ZetDDQKjwtpoUCTxRWoNyvWKW44=.99888069-f14a-49e2-9749-12bc9883d92a@github.com>

On Mon, 28 Aug 2023 20:05:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/text/ListFormat.java
>   
>   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>

Thanks, Roger. All comments make sense to me. Will update the PR soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15130#issuecomment-1696388823

From vpetko at openjdk.org  Mon Aug 28 21:12:13 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 28 Aug 2023 21:12:13 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v6]
In-Reply-To: <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
 <KkqO3s9EDHXsh20N5165P41_KohAhJSI4e3AIFGa4lU=.9f90910a-13b2-4562-8af0-22e9c6e21d60@github.com>
Message-ID: <Jec8XZGvgSiEFdUOWTbJuX2q55jzEgT5WUrEQQHxmT0=.a2ab605f-ff0a-4305-b282-fbb3163f5368@github.com>

On Fri, 25 Aug 2023 07:04:50 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> 8314491: Linux: jexec launched via PATH fails to find java
>
> Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8314491-jexec-resolve-symlink
>  - declare error in-place
>  - remove unused imports
>  - Review comment: use /proc/self/exe as the backup option
>  - Merge branch 'master' into 8314491-jexec-resolve-symlink
>  - correct copyright statement
>  - Use /proc/self/exec to identify path to the executable.
>  - Create failing test for jexec in PATH issue

Would it be ok to type "integrate" at this stage?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15343#issuecomment-1696415438

From jlu at openjdk.org  Mon Aug 28 21:22:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 28 Aug 2023 21:22:42 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies
Message-ID: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>

Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).

The exceptions occur in the two static `getInstance()` methods. They are thrown generally when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.

-------------

Commit messages:
 - line breaks
 - Invalid implies not length of 3
 - init

Changes: https://git.openjdk.org/jdk/pull/15458/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314611
  Stats: 37 lines in 2 files changed: 26 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15458/head:pull/15458

PR: https://git.openjdk.org/jdk/pull/15458

From duke at openjdk.org  Mon Aug 28 21:27:25 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 28 Aug 2023 21:27:25 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
Message-ID: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
> 
> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
> |	ArraysSort.longSort	|	1000	|	10.449	|	6.239	|	1.7	|
> |	ArraysSort.longSort	|	10000	|	307.074	|	70.284	|	**4.4**	|
> |	ArraysSor...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Clean up parameters passed to arrayPartition; update the check to load library

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/e44f11a6..9642d852

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=28-29

  Stats: 56 lines in 7 files changed: 17 ins; 19 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14227/head:pull/14227

PR: https://git.openjdk.org/jdk/pull/14227

From duke at openjdk.org  Mon Aug 28 21:27:30 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 28 Aug 2023 21:27:30 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <oFL692TCzBpuGQWhrLUupjz3MsUYTh5UVMrYPB1sbY8=.761dc8e8-6b82-440d-b934-9a8bfc33a2ed@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <oFL692TCzBpuGQWhrLUupjz3MsUYTh5UVMrYPB1sbY8=.761dc8e8-6b82-440d-b934-9a8bfc33a2ed@github.com>
Message-ID: <Q9wilI9EIr6mNEnWqWiaU0X5r31PAENGqYkFkarheZ8=.7af532ed-deaf-4ad3-8dd8-0ba45a9f75b7@github.com>

On Fri, 25 Aug 2023 22:04:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary import in Arrays.java
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4143:
> 
>> 4141:     log_info(library)("Loaded library %s, handle " INTPTR_FORMAT, JNI_LIB_PREFIX "x86_64" JNI_LIB_SUFFIX, p2i(libx86_64));
>> 4142: 
>> 4143:     if (UseAVX > 2 && VM_Version::supports_avx512dq()) {
> 
> This check should be done before you locate and load library

Please see the check moved to before loading the library in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1307962504

From duke at openjdk.org  Mon Aug 28 21:27:31 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 28 Aug 2023 21:27:31 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v26]
In-Reply-To: <jrMoX9BW_Zb6w0272TbJkG0Zf5U03vzbO8Zb97TgArc=.0d3e2b61-82d7-4947-b1ed-cddbeead2305@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ywYEnYVj4jxQ7seKbrlbd59oQ0fYx2aJHeTxd5q8cAY=.8c8c132f-c67e-412c-a3ea-bcace2a4e44c@github.com>
 <BGuoqIeApSqY2ZF86u1n6kk3htboZdmmoXoKb95k0t0=.aa724806-d994-46d9-9c0a-607f569b84dd@github.com>
 <N1R4l5gwhjALnVS7lJ8DL9jq1Aua43Xri6e_-IV0jvo=.9458c954-eb96-4086-971a-389418e0f9ed@github.com>
 <jrMoX9BW_Zb6w0272TbJkG0Zf5U03vzbO8Zb97TgArc=.0d3e2b61-82d7-4947-b1ed-cddbeead2305@github.com>
Message-ID: <N1ReikEo2zR_lgrexD_I1supnzenykCNy3ACkdnSGwU=.54f7c130-3d96-400b-b70f-bb8044bc0f6e@github.com>

On Fri, 25 Aug 2023 01:52:32 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> pivotIndices array is being passed as a parameter to the partition intrinsic as it is updated in-place with the new pivot indices after partitioning. The Unsafe.ARRAY_INT_BASE_OFFSET is being used in libary_call.cpp to get the address of pivotIndices.
>
> As PivotIndices is local to the DualPivotQuickSort and is always going to be int array, there are other ways to compute the address in library_call.cpp without having to pass an additional argument.

As suggested, the code was updated to no longer pass the offset(Unsafe.ARRAY_INT_BASE_OFFSET) for pivotIndices array. Please see the code in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1307964768

From jlu at openjdk.org  Mon Aug 28 21:33:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 28 Aug 2023 21:33:34 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes
Message-ID: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>

Please review this PR which refines the spec of `equals()` and `hashCode()` in `java.text.Format` related classes.

The current spec for most of these methods is either  "_Overrides <method_name>_" or are incomplete/wrong (i.e. see `ChoiceFormat`).

This fix adjusts the spec to provide a consistent definition for the overridden methods and specify what is being compared/used to generate a hash code value.

For implementations that use at most a few fields, the values are stated, otherwise a more general term is used as a substitution (i.e. see `DecimalFormat`).

-------------

Commit messages:
 - Remove additional see tag from dFmt.hashCode()
 - Include CompactNumberFormat.java
 - Drop 'Obeys the general contract' wording and further standardizing
 - Touch up and standardize
 - Update rest of related classes
 - Adjust ChoiceFormat (refer to public method)
 - Update NumberFormat
 - Update DecimalFormat
 - Update DateFormat
 - Adjust ChoiceFormat
 - ... and 1 more: https://git.openjdk.org/jdk/compare/7c169a42...84bd4708

Changes: https://git.openjdk.org/jdk/pull/15459/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15459&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5066247
  Stats: 117 lines in 9 files changed: 92 ins; 1 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15459.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15459/head:pull/15459

PR: https://git.openjdk.org/jdk/pull/15459

From jlu at openjdk.org  Mon Aug 28 21:36:34 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 28 Aug 2023 21:36:34 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v2]
In-Reply-To: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
Message-ID: <e5RWUuW23y25t-FIGEgZtVnqLR7rtGGn6lgkl5u62Kg=.daac1a7a-b49f-4109-a3d3-c48665ef9e64@github.com>

> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
> 
> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - 4217->3166
 - Include the private table methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15458/files
  - new: https://git.openjdk.org/jdk/pull/15458/files/afa2e835..4fe94845

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15458/head:pull/15458

PR: https://git.openjdk.org/jdk/pull/15458

From naoto at openjdk.org  Mon Aug 28 22:07:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Aug 2023 22:07:09 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v2]
In-Reply-To: <e5RWUuW23y25t-FIGEgZtVnqLR7rtGGn6lgkl5u62Kg=.daac1a7a-b49f-4109-a3d3-c48665ef9e64@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
 <e5RWUuW23y25t-FIGEgZtVnqLR7rtGGn6lgkl5u62Kg=.daac1a7a-b49f-4109-a3d3-c48665ef9e64@github.com>
Message-ID: <oTmxHculhwzC5WVze6sQLJCYeXVF2iELSsUeRoQm2Fw=.d9967e2d-b038-4722-9b48-6663db2f5734@github.com>

On Mon, 28 Aug 2023 21:36:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
>> 
>> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 4217->3166
>  - Include the private table methods

Looks good. Minor suggestion to the exception message.

src/java.base/share/classes/java/util/Currency.java line 347:

> 345:                 if (ocEntry == null) {
> 346:                     throw new IllegalArgumentException("The input currency code" +
> 347:                             " is not a supported ISO 4217 code");

I think "valid" is more appropriate than "supported." Applies to other locations as well.

-------------

PR Review: https://git.openjdk.org/jdk/pull/15458#pullrequestreview-1599192074
PR Review Comment: https://git.openjdk.org/jdk/pull/15458#discussion_r1308004193

From duke at openjdk.org  Mon Aug 28 22:45:21 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Mon, 28 Aug 2023 22:45:21 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
Message-ID: <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>

On Fri, 25 Aug 2023 13:20:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary import in Arrays.java
>
> make/modules/java.base/Lib.gmk line 239:
> 
>> 237: ################################################################################
>> 238: 
>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
> 
> Is there a reason for this to only be supported on Linux?

Hi Erik,

The reason this PR is focused on Linux is because the AVX512 sort and partitioning routines are based on Intel?s x86-simd-library (https://github.com/intel/x86-simd-sort) which was originally developed with GCC as the target compiler. Thus, this PR has restricted itself to Linux as the code was tested using GCC/Linux platforms. 
Additionally, the x86_64 library is compiled for AVX512 using file specific compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for Windows/MSVC++ compiler.?

Thanks,
Vamsi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1308027470

From jlu at openjdk.org  Mon Aug 28 22:45:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 28 Aug 2023 22:45:40 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v3]
In-Reply-To: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
Message-ID: <EpY5kSddCBfI-3m-EvH9GWsTai71dsULmOc5JEhXzaE=.932c0c83-dbc7-4c94-8daa-6ebde5266666@github.com>

> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
> 
> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Wording: supported -> valid

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15458/files
  - new: https://git.openjdk.org/jdk/pull/15458/files/4fe94845..d134adf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=01-02

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15458/head:pull/15458

PR: https://git.openjdk.org/jdk/pull/15458

From brent.christian at oracle.com  Mon Aug 28 23:02:47 2023
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 28 Aug 2023 16:02:47 -0700
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <10f5712c-d537-9af2-7318-d9db5ce559ae@oracle.com>

Vote: Yes

On 8/25/23 8:24 AM, Roger Riggs wrote:
> I hereby nominate Michael McMahon to Membership in the Core Libraries Group
> 

From brent.christian at oracle.com  Mon Aug 28 23:03:15 2023
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 28 Aug 2023 16:03:15 -0700
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <001d0386-3a5a-2525-65fd-93a841e78c86@oracle.com>

Vote: Yes

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group
> 

From brent.christian at oracle.com  Mon Aug 28 23:03:56 2023
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 28 Aug 2023 16:03:56 -0700
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <537c2ba4-52b1-4ba0-5891-cd038afc8cc2@oracle.com>

Vote: Yes

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Lance Andersen to Membership in the Core Libraries Group
> 

From sviswanathan at openjdk.org  Mon Aug 28 23:19:21 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 28 Aug 2023 23:19:21 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <RGXwzFHFbGKgurLPRFlg2Swo8o6wIjwqYUGY_9_e7Nk=.11c40d11-41bc-43b3-bce6-835b3d6571d0@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

Thanks for considering all the review comments and fixing them. The PR looks good to me.

@PaulSandoz Could you please review the Java part?

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14227#pullrequestreview-1599251153
PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1696551426

From naoto at openjdk.org  Mon Aug 28 23:34:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 28 Aug 2023 23:34:49 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v11]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <fno8eyS5v9TFu0LTQq8MLgsKxe2UP8bTxU7_bO8ys3A=.8fa3c9f3-89bd-402b-8c91-2ad03a443e36@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato 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 17 additional commits since the last revision:

 - Added tests
 - Review comments
 - Merge branch 'master' into JDK-8041488-ListPatterns-PR
 - Removed unnecessary spaces
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Update src/java.base/share/classes/java/text/ListFormat.java
   
   Co-authored-by: Roger Riggs <Roger.Riggs at Oracle.com>
 - Reflecting review comments
 - ... and 7 more: https://git.openjdk.org/jdk/compare/9c462970...36974db7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/7d7aaf48..36974db7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=09-10

  Stats: 22411 lines in 951 files changed: 13246 ins; 3823 del; 5342 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From erikj at openjdk.org  Mon Aug 28 23:48:25 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Aug 2023 23:48:25 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <H8S-sUP_B-wBoc-Gu-Zo_wEtiYeNSKlZto8djNsIX-Y=.8d060054-ec20-43e9-a965-fccc1689c44a@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

make/modules/java.base/Lib.gmk line 240:

> 238: 
> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
> 240:   $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \

As this is a C++ lib, consider using g++ for linking by setting:

TOOLCHAIN := TOOLCHAIN_LINK_CXX

make/modules/java.base/Lib.gmk line 241:

> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
> 240:   $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \
> 241:       NAME := x86_64, \

This looks like a rather generic name for a library. I would expect something a bit more descriptive. 

I also noted that @vnkozlov questioned needing a separate library for this and I didn't really find an answer. What do we gain from separating this into a separate dynamic library?

make/modules/java.base/Lib.gmk line 247:

> 245:       LDFLAGS := $(LDFLAGS_JDKLIB) \
> 246:           $(call SET_SHARED_LIBRARY_ORIGIN), \
> 247:       LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \

This is set by default since JDK-8314554.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1308053768
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1308051118
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1308052384

From erikj at openjdk.org  Mon Aug 28 23:48:20 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Aug 2023 23:48:20 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
 <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>
Message-ID: <gnJRko8Ivf2ptENdp38Ghz22tXEpR2LtF4fVvnrkTPk=.ec080953-9439-4e08-92e1-995463563191@github.com>

On Mon, 28 Aug 2023 22:42:50 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 239:
>> 
>>> 237: ################################################################################
>>> 238: 
>>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
>> 
>> Is there a reason for this to only be supported on Linux?
>
> Hi Erik,
> 
> The reason this PR is focused on Linux is because the AVX512 sort and partitioning routines are based on Intel?s x86-simd-library (https://github.com/intel/x86-simd-sort) which was originally developed with GCC as the target compiler. Thus, this PR has restricted itself to Linux as the code was tested using GCC/Linux platforms. 
> Additionally, the x86_64 library is compiled for AVX512 using file specific compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for Windows/MSVC++ compiler.?
> 
> Thanks,
> Vamsi

If it's tied to GCC as well, then we should probably include that in the condition here unless it's also expected to work with Clang. (`TOOLCHAIN_TYPE` = `gcc`)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1308050702

From bpb at openjdk.org  Tue Aug 29 00:02:31 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 29 Aug 2023 00:02:31 GMT
Subject: RFR: 8274122: java/io/File/createTempFile/SpecialTempFile.java fails
 in Windows 11
Message-ID: <BgLNtJLbs5h-AFwNCrvVh1tMpU5af-WShvYgBpaqvjE=.b66bfb62-8dcf-4983-b8d3-02d681915f3c@github.com>

Windows 11 does not reserve as many names as prior versions of Windows so do not expect exceptions for COM7 and LPT1.

-------------

Commit messages:
 - 8274122: java/io/File/createTempFile/SpecialTempFile.java fails in Windows 11

Changes: https://git.openjdk.org/jdk/pull/15460/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15460&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8274122
  Stats: 7 lines in 2 files changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15460.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15460/head:pull/15460

PR: https://git.openjdk.org/jdk/pull/15460

From mchung at openjdk.org  Tue Aug 29 00:16:40 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 29 Aug 2023 00:16:40 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `StackWalker.Kind` enum to specify the information that a stack walker
> collects.  If no method information is needed, a `StackWalker` of `CLASS_INFO` can be used
> instead and such stack walker will save the overhead (1) to extract the method information
> and (2) the memory used for the stack walking.   In addition, this can also fix
> 
> - [8311500](https://bugs.openjdk.org/browse/JDK-8311500): StackWalker.getCallerClass() throws UOE if invoked reflectively
> 
> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
> This provides a simple way for existing code, for example logging frameworks, to take advantage of
> this enhancement with the least change as it can keep the existing function for traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can call `StackWalker::getInstance(CLASS_INFO, ...)` to create a stack walker instance:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Kind.CLASS_INFO, Option.RETAIN_CLASS_REFERENCE);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(interestingClasses::contains)
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> #### Javadoc & specdiff
> 
> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
> 
> #### Alternatives Considered
> One alternative is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> Another alte...

Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:

 - Revised the API change.  Add Option::DROP_METHOD_INFO
 - Review feedback from Remi

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15370/files
  - new: https://git.openjdk.org/jdk/pull/15370/files/4c5c5d79..3ca53c74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=05-06

  Stats: 277 lines in 10 files changed: 28 ins; 168 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From smarks at openjdk.org  Tue Aug 29 03:06:12 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 29 Aug 2023 03:06:12 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v8]
In-Reply-To: <hm8v3HONdRkzGDXcRcyeTpFyBLm4Hc2drvVWOFCPlg0=.91eaa5be-a90c-4139-86c7-161dae94ee5f@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <hm8v3HONdRkzGDXcRcyeTpFyBLm4Hc2drvVWOFCPlg0=.91eaa5be-a90c-4139-86c7-161dae94ee5f@github.com>
Message-ID: <ZebsTdDoVdW_oS4AL9hg4RBCkW6HE-ICHaeFHhWRVGY=.d1d40f98-5c42-485e-8693-66ccf2185152@github.com>

On Fri, 25 Aug 2023 13:20:54 GMT, Nikita Sakharin <duke at openjdk.org> wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List<Byte> list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Nikita Sakharin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   fix overflow in Collections.rotate and write tests

(The bot has already admonished you about avoiding rebasing. In practice merging works well and is helpful so that reviewers can see incremental changes.)

The additional test cases look good. Sorry I forgot to mention this previously: it would be good to have a comment in the test that says that the test is _only_ testing the index computations and not the actual rotation of elements.

Meanwhile, I'll pull in the changes from your branch and run them through our internal build system, which is more reliable (and comprehensive) than GHA.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1696698071

From dholmes at openjdk.org  Tue Aug 29 05:06:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Aug 2023 05:06:08 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <na05dDa2ZtCK2sfdXwnvzPgInmAMd9J9qUwSGVjhw_Q=.e63bc687-31af-47ac-ac0a-1a874693fff5@github.com>

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

I think the admonition about using this method is a bit strong in that it is natural to use this plain process builder method when a test is going to set its own specific flags for the exec'd process. But I'm okay with renaming to avoid copy'n'paste errors that accidentally use the wrong version.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1599483514

From sspitsyn at openjdk.org  Tue Aug 29 07:15:10 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Aug 2023 07:15:10 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v3]
In-Reply-To: <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
 <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>
Message-ID: <CkaqugdE-EQSCIDxc0aildERGiYcb1nl-wKEH_sUfzY=.6250652a-4c7a-4bd9-ae13-c692e84ec9b5@github.com>

On Thu, 24 Aug 2023 21:38:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>> 
>> Port clashes when run at the same time on the same machine have been a problem.
>> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
>> Either way, jstatd fails to startup and and the test fails.
>> 
>> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
>> 
>> Should update its test to check for "Could not bind".
>> Should limit the retries also.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modernisation

Good fix.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15414#pullrequestreview-1599655246

From mbaesken at openjdk.org  Tue Aug 29 08:00:21 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Aug 2023 08:00:21 GMT
Subject: RFR: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test enhance
 output of children
Message-ID: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>

We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.

-------------

Commit messages:
 - JDK-8315213

Changes: https://git.openjdk.org/jdk/pull/15466/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15466&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315213
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15466/head:pull/15466

PR: https://git.openjdk.org/jdk/pull/15466

From alanb at openjdk.org  Tue Aug 29 08:03:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Aug 2023 08:03:09 GMT
Subject: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException:
 Couldn't get file lock.
In-Reply-To: <mT0AsjSWcNxDslmoyi71h9H3-oKMV2hfncsSitCRtqM=.9cbd90dd-4b3d-42ea-9521-89131c1796df@github.com>
References: <0fMrCfHJTaYz5UMBfM57zV7fp9SojRMQDfarEj0QOUs=.51bbcc76-8581-4b2e-9902-f660de90a9a5@github.com>
 <-9ggQjGeVJMy229ytb_52JBr9VVsnEC8_-kxLaDye30=.1db9281c-e049-4d7c-a9bf-68821aaade22@github.com>
 <D7pWJa9Kgpp_gUvE4k64y6OGJfQENnxebBmxiq5hGpM=.d46dcac8-2a8e-4295-8b97-9d3a2996084a@github.com>
 <kl1nZKcKJ50pznWkSgmJ1FMgwyI3QsCWCeJaraoJjS8=.40ab384b-b91e-45a1-9bf5-fbdd19e54552@github.com>
 <dz875Wg1UGzws9xBWcSHUM6nlPWwP2z1AdXyY-deyRs=.f0a9093e-2313-4693-b64f-3cc0497a0335@github.com>
 <mT0AsjSWcNxDslmoyi71h9H3-oKMV2hfncsSitCRtqM=.9cbd90dd-4b3d-42ea-9521-89131c1796df@github.com>
Message-ID: <pROhvg4horEsnBUhXzg6RVXGWqJobFzpCR2vQqlT-YE=.08a04a8a-9108-4505-92ee-1298123aa765@github.com>

On Mon, 28 Aug 2023 07:28:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Alan , when adding the test group sun/tools/jhsdb in TEST.root to the exclusiveAccess.dirs , I cannot see the error any more. So it seems your suggestions is correct .

My command was actually wondering why we didn't have a TEST.properties in java/util/prefs to define this property, I didn't spot that it is already defined in TEST.ROOT in the root directory. If that wasn't there then I would have expected to see a lot more issues running these tests concurrently. It sounds like this may be useful for the SA or jhsdb tests too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1696957881

From stuefe at openjdk.org  Tue Aug 29 08:07:16 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Aug 2023 08:07:16 GMT
Subject: RFR: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test
 enhance output of children
In-Reply-To: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
References: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
Message-ID: <-mnOSPRdzpR32bKR0gbFffLXWtf4UugyWjAM1HGgOdw=.fc9dd36d-db62-426e-b532-e1d17f19a762@github.com>

On Tue, 29 Aug 2023 07:51:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.

Looks good. Small nit inline.

test/jdk/java/lang/ProcessHandle/TreeTest.java line 451:

> 449:                     subprocesses.stream().map(p -> p.pid())
> 450:                     .collect(Collectors.toList()));
> 451: 

Small nit: I would not reuse the variable, but use an own one.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15466#pullrequestreview-1599761848
PR Review Comment: https://git.openjdk.org/jdk/pull/15466#discussion_r1308381401

From clanger at openjdk.org  Tue Aug 29 08:33:11 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 29 Aug 2023 08:33:11 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <PAAwyDFEoXNEw3LDkKa6CqSJxpcfks7qfx4f-0T0oE0=.b60e7d57-0170-4b85-ba50-028b2cc45190@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
 <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
 <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>
 <PAAwyDFEoXNEw3LDkKa6CqSJxpcfks7qfx4f-0T0oE0=.b60e7d57-0170-4b85-ba50-028b2cc45190@github.com>
Message-ID: <H9F_dHHhUBiUCjutO9FEtmFSZ2Ayp9n-B9TFNNDAWFk=.88bc4463-d533-4abb-99ab-87f583a6150b@github.com>

On Mon, 28 Aug 2023 05:24:09 GMT, Arno Zeller <azeller at openjdk.org> wrote:

>> I think you might use System.getProperty("user.name"). But I am not sure about domain names of users on Windows.
>> I am also not sure why the user name is currently determined by creating a file - there might be a reason for this that is not obvious to me.
>
> It seems that ProcessHandle.info()  returns **DOMAIN/USERNAME** on Windows but System.getProperty("user.name") only the **USERNAME**.
> You can get **DOMAIN** and **USERNAME** on **Windows** by calling:
> com.sun.security.auth.module.NTSystem NTSystem = new com.sun.security.auth.module.NTSystem();
> String user = NTSystem.getName();
> String domain = NTSystem.getDomain();

Yes, I think using System.getProperty("user.name") is brittle as well. If we'd use `com.sun.security.auth.module.NTSystem`, we would introduce the dependency to another module - `jdk.security.auth`. Not sure, whether this is a good option.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1308412488

From kevinw at openjdk.org  Tue Aug 29 08:38:11 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 29 Aug 2023 08:38:11 GMT
Subject: RFR: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note [v2]
In-Reply-To: <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
 <C5kGr7qQ_fC9geF37lYc85_0qyKkbcztgM4FEjPkpKo=.3a0540af-5f39-4ac0-a4fb-fda64372c109@github.com>
Message-ID: <Zn7adx5B-3hODmkTGQ95D-ELw_EXmduHbtgSvBJmQoc=.a00e7a98-1be5-40ff-b144-8d08aacbe5d1@github.com>

On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this trivial PR.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into 8314753
>  - Initial commit

Looks good, thanks.

-------------

Marked as reviewed by kevinw (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15385#pullrequestreview-1599820441

From kevinw at openjdk.org  Tue Aug 29 08:54:13 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 29 Aug 2023 08:54:13 GMT
Subject: RFR: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table" [v3]
In-Reply-To: <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
 <wvtvasxl8j2RceQdlhP4ms3KcUK-7RvH0ZUs660Fdbo=.8ffe1dda-8762-415d-82b8-ceb939329342@github.com>
Message-ID: <_gx66iZySxUwGTI88t_7MiyXmQ15V6Fs3kNpyO6WBZU=.6da98252-d206-4f11-a1c8-b1d406d3c425@github.com>

On Thu, 24 Aug 2023 21:38:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Several tests from test/jdk/sun/tools/jstatd are intermittent.
>> 
>> Port clashes when run at the same time on the same machine have been a problem.
>> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
>> Either way, jstatd fails to startup and and the test fails.
>> 
>> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
>> 
>> Should update its test to check for "Could not bind".
>> Should limit the retries also.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modernisation

Thanks Mark and Seguei!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15414#issuecomment-1697030288

From kevinw at openjdk.org  Tue Aug 29 08:57:20 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 29 Aug 2023 08:57:20 GMT
Subject: Integrated: 8314476: TestJstatdPortAndServer.java failed with
 "java.rmi.NoSuchObjectException: no such object in table"
In-Reply-To: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
References: <7tqILhhALiAV1xmAof5hDP76ZhD8jrpE4skmM1TynDk=.c9e13ba0-63f8-43cd-927d-eef12fed27b6@github.com>
Message-ID: <nuKTn9XjTCmWkRaDEOALXP7tt0XywySFrO_G9_xFqxI=.d849e632-6455-4b1f-8a06-09b41592fb3d@github.com>

On Thu, 24 Aug 2023 11:34:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Several tests from test/jdk/sun/tools/jstatd are intermittent.
> 
> Port clashes when run at the same time on the same machine have been a problem.
> The RMI error "no such object in table" can mean a reference on the RMI server has been GC'd.
> Either way, jstatd fails to startup and and the test fails.
> 
> These both have jstatd reporting "Could not bind" which should be recognised and retried, as we already do for (some) port in use problems. i.e. JstatdTest.java: the isJstadReady() method (will correct that typo also) checks for "Port already in use", which can be printed by TCPTransport.java.
> 
> Should update its test to check for "Could not bind".
> Should limit the retries also.

This pull request has now been integrated.

Changeset: 1d025070
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d0250709a6ee97f5647edff589761bd9d0b7f4c
Stats:     11 lines in 1 file changed: 5 ins; 1 del; 5 mod

8314476: TestJstatdPortAndServer.java failed with "java.rmi.NoSuchObjectException: no such object in table"

Reviewed-by: msheppar, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/15414

From lkorinth at openjdk.org  Tue Aug 29 09:12:51 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 29 Aug 2023 09:12:51 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/4b2d1711..f3418c80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=00-01

  Stats: 344 lines in 344 files changed: 0 ins; 0 del; 344 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From duke at openjdk.org  Tue Aug 29 11:35:23 2023
From: duke at openjdk.org (chenggwang)
Date: Tue, 29 Aug 2023 11:35:23 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
Message-ID: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>

eg:5 individuals in the first round of written exams,ending with a ranking based on everyone's score points; and a second round of interviews, with a ranking based on the average of the three interviewers' scores;The two rounds of ranking methods are the barrierCommand, and they are different

-------------

Commit messages:
 - Set new barrierCommand under a new generation

Changes: https://git.openjdk.org/jdk/pull/15239/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15239&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314194
  Stats: 49 lines in 1 file changed: 47 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15239.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15239/head:pull/15239

PR: https://git.openjdk.org/jdk/pull/15239

From robilad at openjdk.org  Tue Aug 29 11:35:23 2023
From: robilad at openjdk.org (Dalibor Topic)
Date: Tue, 29 Aug 2023 11:35:23 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
Message-ID: <DpFxknIistO9KCCQMKCHhE5Lw65bcMGQYrWo2pfd-k8=.f5f9c98b-9e4c-4347-9e2b-69cdff577eec@github.com>

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke at openjdk.org> wrote:

> eg:5 individuals in the first round of written exams,ending with a ranking based on everyone's score points; and a second round of interviews, with a ranking based on the average of the three interviewers' scores;The two rounds of ranking methods are the barrierCommand, and they are different

Hi, please send an e-mail to dalibor.topic at oracle.com so that I can mark your OCA as verified.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1680518238

From duke at openjdk.org  Tue Aug 29 11:35:23 2023
From: duke at openjdk.org (chenggwang)
Date: Tue, 29 Aug 2023 11:35:23 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
Message-ID: <Dv59Sby33WsMY7qIJkHa9Jt26JeKuIirQuRqVixKLlM=.840cb9a5-1472-413d-828e-572503f90e21@github.com>

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke at openjdk.org> wrote:

> eg:5 individuals in the first round of written exams,ending with a ranking based on everyone's score points; and a second round of interviews, with a ranking based on the average of the three interviewers' scores;The two rounds of ranking methods are the barrierCommand, and they are different

> Hi, please send an e-mail to [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) so that I can mark your OCA as verified.

Hi! I have completed my personal information and re-signed the OCA, which is currently in UNDER REVIEW status. And I have also replied to the email to [dalibor.topic at oracle.com](mailto:dalibor.topic at oracle.com) about the OCA re-signing.I'm sorry for the trouble.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1680826866

From coffeys at openjdk.org  Tue Aug 29 11:58:14 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 29 Aug 2023 11:58:14 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v6]
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <up3Oi6wpijE9FLmX6EDwnlHwWPzs2xTBOZAKVx8_XKg=.d4337646-4694-4285-9597-c5ecc5dcffd6@github.com>

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Review comments from Daniel. Further test clean up

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15404/files
  - new: https://git.openjdk.org/jdk/pull/15404/files/ca4cd4f0..cf53841b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=04-05

  Stats: 43 lines in 4 files changed: 7 ins; 24 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From prappo at openjdk.org  Tue Aug 29 12:03:23 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 29 Aug 2023 12:03:23 GMT
Subject: Integrated: 8314753: Remove support for @beaninfo, @ToDo,
 @since.unbundled, and @Note
In-Reply-To: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
References: <ZkpogJm2EDFo__5q8dYGb1dNXcJJk2dlQBHYDufYl3M=.a69b191e-f8d6-421f-a6ce-56b0dd573ab2@github.com>
Message-ID: <Qd_K5bwqb0rkvi99woNSL6V_jtnTiV7JcsbU0FEl8W4=.90a043de-8bac-4296-9600-2e7d604b2c24@github.com>

On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR.

This pull request has now been integrated.

Changeset: a4e97aa4
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a4e97aa4ebe6fcfc3ed9e45ed81df1d55e52d621
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note

Reviewed-by: rriggs, azvegint, kevinw

-------------

PR: https://git.openjdk.org/jdk/pull/15385

From mbaesken at openjdk.org  Tue Aug 29 12:10:34 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Aug 2023 12:10:34 GMT
Subject: RFR: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test
 enhance output of children [v2]
In-Reply-To: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
References: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
Message-ID: <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>

> We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use 2 containers for children and descendants

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15466/files
  - new: https://git.openjdk.org/jdk/pull/15466/files/fb420eab..07434cd8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15466&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15466&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15466/head:pull/15466

PR: https://git.openjdk.org/jdk/pull/15466

From sgehwolf at openjdk.org  Tue Aug 29 12:38:10 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 29 Aug 2023 12:38:10 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: <nQlctZ3ctF4Wsn8cKLir4kn51OAqKChwyQ5Z-tPI-CM=.72a25210-016a-43a6-acca-5f3065e2bbba@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <nQlctZ3ctF4Wsn8cKLir4kn51OAqKChwyQ5Z-tPI-CM=.72a25210-016a-43a6-acca-5f3065e2bbba@github.com>
Message-ID: <_uNwDdZONPRN_Ve3ePW4nK_qXvra5usXGjSa9Mx7QCw=.e5afa50b-feac-4dff-b79c-9f71e3006a7e@github.com>

On Thu, 10 Aug 2023 17:21:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a "jmodless" jlink mode to the JDK. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JmodLessArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.management.jmod  jdk.jlink.jmod       jdk.naming.dns.j...
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Implementation for run-image link and single-hop
>    
>    This uses a stamp file in 'lib/modules' jimage in order to recognize
>    multi-hop links. However, this has the caveat of no longer producing
>    reproducible builds as compared to a packaged module-based link.
>    
>    Add an option to allow for multi-hop, which disables the stamp file
>    addition and makes it reproducible again.
>  - Exit the jlink on modified files by default
>    
>    This is configurable so add tests for both scenarios.

@AlanBateman Gentle ping.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1697359809

From dfuchs at openjdk.org  Tue Aug 29 13:07:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Aug 2023 13:07:15 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v6]
In-Reply-To: <up3Oi6wpijE9FLmX6EDwnlHwWPzs2xTBOZAKVx8_XKg=.d4337646-4694-4285-9597-c5ecc5dcffd6@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <up3Oi6wpijE9FLmX6EDwnlHwWPzs2xTBOZAKVx8_XKg=.d4337646-4694-4285-9597-c5ecc5dcffd6@github.com>
Message-ID: <VOpVvCfCqKLxlt1KuWqp-DrsB4YkhoF2O4OaGVLMxvg=.4501510c-d24d-49c4-8ff7-fc6c6655ef91@github.com>

On Tue, 29 Aug 2023 11:58:14 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments from Daniel. Further test clean up

Only minor comment updates. Otherwise LGTM!

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/PlatformRecursiveLoadingTest.java line 46:

> 44: 
> 45:     /**
> 46:      * This test triggers recursion by calling `System.getLogger` in the class init

Suggestion:

     * This test triggers recursion by calling `System.getLogger` in the class init and constructor

test/jdk/java/lang/System/LoggerFinder/RecursiveLoading/RecursiveLoadingTest.java line 41:

> 39: 
> 40:     /**
> 41:      * This test triggers recursion by calling `System.getLogger` in the class init

Suggestion:

     * This test triggers recursion by calling `System.getLogger` in the class init and constructor

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15404#pullrequestreview-1600360266
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1308784213
PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1308785012

From alanb at openjdk.org  Tue Aug 29 13:29:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Aug 2023 13:29:12 GMT
Subject: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3
In-Reply-To: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
References: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
Message-ID: <fkwF0gHtxgwnnKq4lrRGSUPq_7BE_PSlQghCsCzdVCg=.ba65655d-c811-43e5-99c8-23095421a773@github.com>

On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib ) has released Zlib 1.3 on August 18, 2023.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.2.13...master ) between 1.2.13 and 1.3 
> 
> Mach5 tiers1-6 have run clean as do the JCK tests

Okay, assuming tests are passing on windows-x64 and macos-aarch64 as these are the two that will usually use the bundled zlib.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15453#pullrequestreview-1600414491

From dfuchs at openjdk.org  Tue Aug 29 13:31:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Aug 2023 13:31:15 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
Message-ID: <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>

On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revised the API change.  Add Option::DROP_METHOD_INFO
>  - Review feedback from Remi

Hi Mandy, I like the new DROP_METHOD_INFO constant. Just a couple of minor suggestions on the wording (which you may chose to ignore as English is not my primary language).

src/java.base/share/classes/java/lang/StackWalker.java line 73:

> 71:  * <p>1. To find the first caller filtering a known list of implementation class:
> 72:  * {@snippet lang="java" :
> 73:  *     StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);

Would this read better as "filtering **out** a known list of implementation **classes**" ?

src/java.base/share/classes/java/lang/StackWalker.java line 98:

> 96:      *
> 97:      * <p> The information of a {@code StackFrame} available is determined by the
> 98:      * {@linkplain Option stack walking options} of a stack walker.

Would this read better as "The information available from a {@code StackFrame} is determined ... "?

-------------

PR Review: https://git.openjdk.org/jdk/pull/15370#pullrequestreview-1600394012
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1308804787
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1308807710

From stuefe at openjdk.org  Tue Aug 29 13:45:11 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Aug 2023 13:45:11 GMT
Subject: RFR: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test
 enhance output of children [v2]
In-Reply-To: <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>
References: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
 <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>
Message-ID: <2Ac6wObLxstfoYOdjSm9KhA1nBB4HhqwHj6artMNNvw=.d9561317-f2ce-4a6f-90d1-998f02aa4d45@github.com>

On Tue, 29 Aug 2023 12:10:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use 2 containers for children and descendants

Good.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15466#pullrequestreview-1600456967

From mbaesken at openjdk.org  Tue Aug 29 13:52:13 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Aug 2023 13:52:13 GMT
Subject: RFR: JDK-8315214: Do not run sun/tools/jhsdb tests concurrently
Message-ID: <tgBJDOXuPiSjJJg8sNk3IjH-2dKnx3rLSG_TCrtkxJI=.2c8ebdec-5032-4469-9345-91a3af48a964@github.com>

The sun/tools/jhsdb tests have issues when we run them concurrently .
So add a related config to TEST.root.

-------------

Commit messages:
 - JDK-8315214

Changes: https://git.openjdk.org/jdk/pull/15469/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315214
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15469/head:pull/15469

PR: https://git.openjdk.org/jdk/pull/15469

From rriggs at openjdk.org  Tue Aug 29 14:00:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Aug 2023 14:00:11 GMT
Subject: RFR: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test
 enhance output of children [v2]
In-Reply-To: <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>
References: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
 <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>
Message-ID: <X6xJNNksULZ8a24q21lcZMxmb15dSD_l03HPr7dN_7c=.37a9b31a-0b88-4909-8241-0fa3dc808151@github.com>

On Tue, 29 Aug 2023 12:10:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use 2 containers for children and descendants

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15466#pullrequestreview-1600490400

From rriggs at openjdk.org  Tue Aug 29 14:09:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Aug 2023 14:09:12 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2]
In-Reply-To: <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
Message-ID: <pnAnjv8HLt1sykmB9jRamtiVRoTbmwQi9xGuaSnCi10=.34427fd4-7b88-436e-946b-04c7364a1853@github.com>

On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

I don't think this is the best change across so many files.
It gives a very ugly name to a common test function and affects a very large number of tests.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1600512718

From lkorinth at openjdk.org  Tue Aug 29 15:13:11 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 29 Aug 2023 15:13:11 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2]
In-Reply-To: <pnAnjv8HLt1sykmB9jRamtiVRoTbmwQi9xGuaSnCi10=.34427fd4-7b88-436e-946b-04c7364a1853@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
 <pnAnjv8HLt1sykmB9jRamtiVRoTbmwQi9xGuaSnCi10=.34427fd4-7b88-436e-946b-04c7364a1853@github.com>
Message-ID: <HCFLeG3EfMrzIj9IjcMM4NeSOpSu6cC3Nr4Ws85M4lU=.00c1992b-c510-4349-a998-24a06b2b31a5@github.com>

On Tue, 29 Aug 2023 14:06:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> I don't think this is the best change across so many files.
> It gives a very ugly name to a common test function and affects a very large number of tests.

@RogerRiggs If it is only the name you want changed, maybe you can offer a better name?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1697634872

From coffeys at openjdk.org  Tue Aug 29 15:31:03 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 29 Aug 2023 15:31:03 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v7]
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <uMzMHq9dsfai0UNdquL2lBY4AYdt1K9bG8Gaf2ErxG0=.1b432c29-d765-4270-9bf6-9d8324b0a826@github.com>

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  more tidying up in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15404/files
  - new: https://git.openjdk.org/jdk/pull/15404/files/cf53841b..f8d7545e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15404&range=05-06

  Stats: 19 lines in 4 files changed: 0 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/15404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15404/head:pull/15404

PR: https://git.openjdk.org/jdk/pull/15404

From jbhateja at openjdk.org  Tue Aug 29 15:52:23 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 29 Aug 2023 15:52:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <kWrwkZtY255YOdQh5vs2gRZeBVdLxVN5LB7vbC-R4Ho=.bae68110-2b47-4749-9e9d-8fa5340c5c92@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

> 
Hi @vamsi-parasa ,

Please find below the perf data collected over ?Linux? with following JMH options.

java -jar target/benchmarks.jar -p builder=RANDOM -f 1 -wi 1 -i 10 -w 30 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition" ArraysSort.Long.testSort

Baseline numbers are with stock JDK. 

![image](https://github.com/openjdk/jdk/assets/59989778/d3bf2591-38bb-4924-b77d-6889c5dbc3c0)

Best Regards,
Jatin

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697715820

From kvn at openjdk.org  Tue Aug 29 16:08:28 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Aug 2023 16:08:28 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <45lBRB5Jf3jkviwJnCUuiub6BDr-qqwNal1Bbr982ik=.6ce497c0-d2bb-4d2c-b700-28dc4842bf7c@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

My testing passed. But I am not sure correctness of code is fully tested. For now we have only JMH benchmark for this new code.  Do we have JDK test which can check correctness of this code?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697743981

From kvn at openjdk.org  Tue Aug 29 16:08:29 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Aug 2023 16:08:29 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <gnJRko8Ivf2ptENdp38Ghz22tXEpR2LtF4fVvnrkTPk=.ec080953-9439-4e08-92e1-995463563191@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
 <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>
 <gnJRko8Ivf2ptENdp38Ghz22tXEpR2LtF4fVvnrkTPk=.ec080953-9439-4e08-92e1-995463563191@github.com>
Message-ID: <2s4hZgw7KRQ5AoYzTZ3-8BS5V6JAslioJXeil_jvfQA=.fb1a1a31-8726-494b-b77c-a66565a963da@github.com>

On Mon, 28 Aug 2023 23:28:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi Erik,
>> 
>> The reason this PR is focused on Linux is because the AVX512 sort and partitioning routines are based on Intel?s x86-simd-library (https://github.com/intel/x86-simd-sort) which was originally developed with GCC as the target compiler. Thus, this PR has restricted itself to Linux as the code was tested using GCC/Linux platforms. 
>> Additionally, the x86_64 library is compiled for AVX512 using file specific compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for Windows/MSVC++ compiler.?
>> 
>> Thanks,
>> Vamsi
>
> If it's tied to GCC as well, then we should probably include that in the condition here unless it's also expected to work with Clang. (`TOOLCHAIN_TYPE` = `gcc`)

> The reason this PR is focused on Linux is because the AVX512 sort and partitioning routines are based on Intel?s x86-simd-library (https://github.com/intel/x86-simd-sort) which was originally developed with GCC as the target compiler. Thus, this PR has restricted itself to Linux as the code was tested using GCC/Linux platforms. Additionally, the x86_64 library is compiled for AVX512 using file specific compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for Windows/MSVC++ compiler.?

That is why I am questioning this approach to have additional separate C++ code library - too much dependencies on other tools.

As I suggested before try to disassemble this library and use assembler code in VM new stubs. You can create specialized stubGenerator_x86_64_array_sort.cpp file for it. Then you don't need to depend on C++ compiler or OS.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309054538

From asotona at openjdk.org  Tue Aug 29 16:11:09 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 29 Aug 2023 16:11:09 GMT
Subject: RFR: 8297777: jdk.jlink StringSharingPlugin uses
 com.sun.tools.classfile library
In-Reply-To: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>
References: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>
Message-ID: <_v26zYaBLh8zLl04_bsCQ9NwS1OfOUmmugRNy-iYEpk=.0e123bd4-59ce-44dd-b417-c24fd5b49cd8@github.com>

On Wed, 23 Aug 2023 23:50:29 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Migrate jdk.jlink StringSharingPlugin to use new classfile library

Marked as reviewed by asotona (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15408#pullrequestreview-1600806536

From lancea at openjdk.org  Tue Aug 29 16:14:11 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 29 Aug 2023 16:14:11 GMT
Subject: RFR: 8315117: Update Zlib Data Compression Library to Version 1.3
In-Reply-To: <fkwF0gHtxgwnnKq4lrRGSUPq_7BE_PSlQghCsCzdVCg=.ba65655d-c811-43e5-99c8-23095421a773@github.com>
References: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
 <fkwF0gHtxgwnnKq4lrRGSUPq_7BE_PSlQghCsCzdVCg=.ba65655d-c811-43e5-99c8-23095421a773@github.com>
Message-ID: <fYpDgD4A4rBDVLbo0D1R3wxPWqrpNptoqCAuY4w2wew=.69a4fb49-4d49-4cb0-8dbd-e74db06f1c41@github.com>

On Tue, 29 Aug 2023 13:25:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay, assuming tests are passing on windows-x64 and macos-aarch64 as these are the two that will usually use the bundled zlib.

Yes, both were clean in my mach5 runs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15453#issuecomment-1697754639

From alanb at openjdk.org  Tue Aug 29 16:20:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Aug 2023 16:20:15 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
Message-ID: <kedJo33I07HVm_k1RI1imbQWaudaybGkFr3t-Rk-t1E=.54d538ba-8d9a-4b95-a377-0355b9e6d881@github.com>

On Tue, 29 Aug 2023 00:16:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revised the API change.  Add Option::DROP_METHOD_INFO
>  - Review feedback from Remi

src/java.base/share/classes/java/lang/StackWalker.java line 53:

> 51:  *
> 52:  * <p> The {@linkplain Option <em>stack walking option</em>} specifies
> 53:  * what the information a stack walker collects from the stack frames.

I think this needs to use "Stack walking options" or "A stack walking option". Alternatively, just copy the first sentence from the Option javadoc so it changes to "Stack walker options configure the stack frame information obtained by a StackWalker".

src/java.base/share/classes/java/lang/StackWalker.java line 54:

> 52:  * <p> The {@linkplain Option <em>stack walking option</em>} specifies
> 53:  * what the information a stack walker collects from the stack frames.
> 54:  * By default, the class name and method information are available but

What would you think about changing "available" to "collected"?

src/java.base/share/classes/java/lang/StackWalker.java line 58:

> 56:  * The method information can be dropped via {@link Option#DROP_METHOD_INFO
> 57:  * DROP_METHOD_INFO} option. The {@code Class} object can be retained for
> 58:  * access via {@link Option#RETAIN_CLASS_REFERENCE RETAIN_CLASS_REFERENCE} option.

Probably should be "via the" rather than "via" in all cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309066013
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309066916
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309067884

From naoto at openjdk.org  Tue Aug 29 16:28:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 16:28:09 GMT
Subject: RFR: 8312521: Unused field
 LocaleProviderAdapter#defaultLocaleProviderAdapter could be removed
In-Reply-To: <V8wbOFhzUYfyrMj6Q7UUvyb88QxfwxPgkY0J0T6-wxo=.18ed1683-f57c-4bcc-8037-88d1e1e558b4@github.com>
References: <V8wbOFhzUYfyrMj6Q7UUvyb88QxfwxPgkY0J0T6-wxo=.18ed1683-f57c-4bcc-8037-88d1e1e558b4@github.com>
Message-ID: <yx7Q81GVm8Wad90mdZkFRysvMxbKeYN8SV864P4Q2EE=.7b110c8b-bac9-4d40-b982-8527a34ad648@github.com>

On Tue, 22 Aug 2023 12:22:54 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> After [JDK-8245241](https://bugs.openjdk.org/browse/JDK-8245241), the field `sun.util.locale.provider.LocaleProviderAdapter#defaultLocaleProviderAdapter` is only written in `<clinit>` and then is not used after.
> We can remove it.

Thanks for cleaning the leftovers. Looks good.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15388#pullrequestreview-1600838247

From mchung at openjdk.org  Tue Aug 29 16:30:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 29 Aug 2023 16:30:17 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <kedJo33I07HVm_k1RI1imbQWaudaybGkFr3t-Rk-t1E=.54d538ba-8d9a-4b95-a377-0355b9e6d881@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
 <kedJo33I07HVm_k1RI1imbQWaudaybGkFr3t-Rk-t1E=.54d538ba-8d9a-4b95-a377-0355b9e6d881@github.com>
Message-ID: <pFJyXbv2FpT0e0-9xZItwiKPLlT7FP3O91T9SShNa64=.dfca9048-4af6-4b05-b791-8f2ecf72561b@github.com>

On Tue, 29 Aug 2023 16:12:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revised the API change.  Add Option::DROP_METHOD_INFO
>>  - Review feedback from Remi
>
> src/java.base/share/classes/java/lang/StackWalker.java line 53:
> 
>> 51:  *
>> 52:  * <p> The {@linkplain Option <em>stack walking option</em>} specifies
>> 53:  * what the information a stack walker collects from the stack frames.
> 
> I think this needs to use "Stack walking options" or "A stack walking option". Alternatively, just copy the first sentence from the Option javadoc so it changes to "Stack walker options configure the stack frame information obtained by a StackWalker".

Updated to use the first sentence from the Option javadoc.  Use it in the class spec of StackWalker and StackFrame consistently.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309082363

From mchung at openjdk.org  Tue Aug 29 16:30:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 29 Aug 2023 16:30:18 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
 <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>
Message-ID: <HHxZ51HBEZZoOtR1_c4rocUlGg0wi_P8qLbEQgQ218E=.d245b241-839a-4413-a907-ac01541482bc@github.com>

On Tue, 29 Aug 2023 13:19:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revised the API change.  Add Option::DROP_METHOD_INFO
>>  - Review feedback from Remi
>
> src/java.base/share/classes/java/lang/StackWalker.java line 98:
> 
>> 96:      *
>> 97:      * <p> The information of a {@code StackFrame} available is determined by the
>> 98:      * {@linkplain Option stack walking options} of a stack walker.
> 
> Would this read better as "The information available from a {@code StackFrame} is determined ... "?

What about "Stack walker options configure the stack frame information obtained by a StackWalker." - the first sentence from the Option javadoc and use it in the class spec of StackWalker and StackFrame.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309081786

From mchung at openjdk.org  Tue Aug 29 16:36:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 29 Aug 2023 16:36:16 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <kedJo33I07HVm_k1RI1imbQWaudaybGkFr3t-Rk-t1E=.54d538ba-8d9a-4b95-a377-0355b9e6d881@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
 <kedJo33I07HVm_k1RI1imbQWaudaybGkFr3t-Rk-t1E=.54d538ba-8d9a-4b95-a377-0355b9e6d881@github.com>
Message-ID: <HRtOgDOUOrIfPB_8c63OPYZN6WVISLGdsr50BD0yu1M=.0cf21403-4ca0-4c83-960b-f8c012e5115f@github.com>

On Tue, 29 Aug 2023 16:13:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revised the API change.  Add Option::DROP_METHOD_INFO
>>  - Review feedback from Remi
>
> src/java.base/share/classes/java/lang/StackWalker.java line 54:
> 
>> 52:  * <p> The {@linkplain Option <em>stack walking option</em>} specifies
>> 53:  * what the information a stack walker collects from the stack frames.
>> 54:  * By default, the class name and method information are available but
> 
> What would you think about changing "available" to "collected"?

"collected" is better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309089304

From naoto at openjdk.org  Tue Aug 29 16:43:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 16:43:12 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v3]
In-Reply-To: <EpY5kSddCBfI-3m-EvH9GWsTai71dsULmOc5JEhXzaE=.932c0c83-dbc7-4c94-8daa-6ebde5266666@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
 <EpY5kSddCBfI-3m-EvH9GWsTai71dsULmOc5JEhXzaE=.932c0c83-dbc7-4c94-8daa-6ebde5266666@github.com>
Message-ID: <KbhKvRmscpAFDBErIp-ZdaeEL5SMHkhE5VIQD-3W7f4=.767ac931-29f2-454f-9a7b-311b7362e31d@github.com>

On Mon, 28 Aug 2023 22:45:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
>> 
>> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording: supported -> valid

I think the same wording changes are needed in the test, as it checks the error messages word by word.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15458#issuecomment-1697797322

From mchung at openjdk.org  Tue Aug 29 16:43:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 29 Aug 2023 16:43:16 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
 <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>
Message-ID: <EVkyDkXJYrS__w0GzhCwKMZkw2OjUyFAfD23UkmORYc=.8cd3c5b0-dc03-4284-a9d7-e6cc4ce5016d@github.com>

On Tue, 29 Aug 2023 13:16:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revised the API change.  Add Option::DROP_METHOD_INFO
>>  - Review feedback from Remi
>
> src/java.base/share/classes/java/lang/StackWalker.java line 73:
> 
>> 71:  * <p>1. To find the first caller filtering a known list of implementation class:
>> 72:  * {@snippet lang="java" :
>> 73:  *     StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
> 
> Would this read better as "filtering **out** a known list of implementation **classes**" ?

how about "s/filtering/excluding"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309095990

From rriggs at openjdk.org  Tue Aug 29 16:48:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Aug 2023 16:48:15 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2]
In-Reply-To: <pnAnjv8HLt1sykmB9jRamtiVRoTbmwQi9xGuaSnCi10=.34427fd4-7b88-436e-946b-04c7364a1853@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
 <pnAnjv8HLt1sykmB9jRamtiVRoTbmwQi9xGuaSnCi10=.34427fd4-7b88-436e-946b-04c7364a1853@github.com>
Message-ID: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com>

On Tue, 29 Aug 2023 14:06:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright
>
> I don't think this is the best change across so many files.
> It gives a very ugly name to a common test function and affects a very large number of tests.

> @RogerRiggs If it is only the name you want changed, maybe you can offer a better name?
@lkorinth 

Sorry for the too short comment; I wanted to make sure it wasn't integrated before I could look at it more closely.
Neither the bug report or the PR describe the problem and its ramifications, only the solution.
Can you elaborate on the conditions that lead to this. (and include them in the bug report).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1697803842

From naoto at openjdk.org  Tue Aug 29 16:51:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 16:51:49 GMT
Subject: RFR: 8041488: Locale-Dependent List Patterns [v12]
In-Reply-To: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
References: <vSIIgyRBbbhd4UaqGeQlgM_ZHLTA8hmlHu5HrCqkRME=.67662dcd-6b5d-491b-9697-3d036db94b9b@github.com>
Message-ID: <h3bv_Rs3ANVUKPg033cdj72VJeiGvfFINYkSl6Yzmg4=.08f61ee2-5e6a-4003-8985-4ebfeb4314f3@github.com>

> Introducing a new formatting class for locale-dependent list patterns. The class is to provide the functionality from the Unicode Consortium's LDML specification for [list patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). For example, given a list of String as "Monday", "Wednesday", "Friday", its `format` method would produce "Monday, Wednesday, and Friday" in US English. A CSR has also been drafted, and its draft javadoc can be viewed here: https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removing unnecessary commas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15130/files
  - new: https://git.openjdk.org/jdk/pull/15130/files/36974db7..a228a3e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15130&range=10-11

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130

PR: https://git.openjdk.org/jdk/pull/15130

From jlu at openjdk.org  Tue Aug 29 16:53:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 16:53:38 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v4]
In-Reply-To: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
Message-ID: <fuFlwFM9enGP3lCtvzcXVqrUm9HcpB2UYGrmtkE5b1c=.6fc66fb8-1c86-495b-bc81-da5d5fbdcc6b@github.com>

> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
> 
> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Change wording in test as well

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15458/files
  - new: https://git.openjdk.org/jdk/pull/15458/files/d134adf8..96efc13a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15458&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15458.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15458/head:pull/15458

PR: https://git.openjdk.org/jdk/pull/15458

From naoto at openjdk.org  Tue Aug 29 16:53:38 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 16:53:38 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v4]
In-Reply-To: <fuFlwFM9enGP3lCtvzcXVqrUm9HcpB2UYGrmtkE5b1c=.6fc66fb8-1c86-495b-bc81-da5d5fbdcc6b@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
 <fuFlwFM9enGP3lCtvzcXVqrUm9HcpB2UYGrmtkE5b1c=.6fc66fb8-1c86-495b-bc81-da5d5fbdcc6b@github.com>
Message-ID: <9eZj8AETBHiQ2lyHNAWAt_aZr1PmjeWXG126FQ8T7WE=.87c30c06-fa77-4c4b-8c3f-37a0ddbea8a4@github.com>

On Tue, 29 Aug 2023 16:48:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
>> 
>> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change wording in test as well

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15458#pullrequestreview-1600876737

From jlu at openjdk.org  Tue Aug 29 16:53:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 16:53:39 GMT
Subject: RFR: JDK-8314611: Provide more explicative error message parsing
 Currencies [v3]
In-Reply-To: <KbhKvRmscpAFDBErIp-ZdaeEL5SMHkhE5VIQD-3W7f4=.767ac931-29f2-454f-9a7b-311b7362e31d@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
 <EpY5kSddCBfI-3m-EvH9GWsTai71dsULmOc5JEhXzaE=.932c0c83-dbc7-4c94-8daa-6ebde5266666@github.com>
 <KbhKvRmscpAFDBErIp-ZdaeEL5SMHkhE5VIQD-3W7f4=.767ac931-29f2-454f-9a7b-311b7362e31d@github.com>
Message-ID: <M5wKUtLBWduWiwCbSLVRGsmbdEF6nherV8lqWziwKJo=.ba1652a9-915e-49aa-b3be-ee0cfb2db42b@github.com>

On Tue, 29 Aug 2023 16:40:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think the same wording changes are needed in the test, as it checks the error messages word by word.

You're totally right, just fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15458#issuecomment-1697803949

From jlu at openjdk.org  Tue Aug 29 17:01:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 17:01:32 GMT
Subject: RFR: 8314925: ChoiceFormat does not specify IllegalArgumentExceptions
Message-ID: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315148) which is a conformance change to specify exceptions in java.text.ChoiceFormat.

Makes `IllegalArgumentException` apparent for `applyPattern` and `setChoices`, as well as for the associated constructors that call the methods.

This change also improves the error message for the `setChoices` IAE.

-------------

Commit messages:
 - Include constructor + grab exceptions from 'pull/15392'
 - init

Changes: https://git.openjdk.org/jdk/pull/15473/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15473&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314925
  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15473.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15473/head:pull/15473

PR: https://git.openjdk.org/jdk/pull/15473

From jlu at openjdk.org  Tue Aug 29 17:01:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 17:01:32 GMT
Subject: RFR: 8314925: ChoiceFormat does not specify
 IllegalArgumentExceptions
In-Reply-To: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>
References: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>
Message-ID: <2aiO0mXFVC_VVSTQFnm_VuNtxqgAXUUQwII6eJlM_L0=.8ea51cc1-e6b0-4c35-9941-a4cddd84a053@github.com>

On Tue, 29 Aug 2023 16:53:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315148) which is a conformance change to specify exceptions in java.text.ChoiceFormat.
> 
> Makes `IllegalArgumentException` apparent for `applyPattern` and `setChoices`, as well as for the associated constructors that call the methods.
> 
> This change also improves the error message for the `setChoices` IAE.

src/java.base/share/classes/java/text/ChoiceFormat.java line 180:

> 178:      *            is {@code null}
> 179:      * @throws    IllegalArgumentException if {@code newPattern}
> 180:      *            is invalid

This would probably more informative if it was changed to `IllegalArgumentException if {@code newPattern} violates the ChoiceFormat pattern syntax`.

However, as of now I kept it this way because there is no defined syntax ATM (although I have a PR for that here -> https://github.com/openjdk/jdk/pull/15392) and the other Format classes all also follow the "... is invalid" wording.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15473#discussion_r1309114867

From dfuchs at openjdk.org  Tue Aug 29 17:02:17 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Aug 2023 17:02:17 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <EVkyDkXJYrS__w0GzhCwKMZkw2OjUyFAfD23UkmORYc=.8cd3c5b0-dc03-4284-a9d7-e6cc4ce5016d@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
 <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>
 <EVkyDkXJYrS__w0GzhCwKMZkw2OjUyFAfD23UkmORYc=.8cd3c5b0-dc03-4284-a9d7-e6cc4ce5016d@github.com>
Message-ID: <tmoe6WvFE3gJAnvQkWKv0nl7sJCOzhhb6iqUTSZHdrk=.ccb9a562-5c87-4f21-9011-19c74fe37e1c@github.com>

On Tue, 29 Aug 2023 16:39:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StackWalker.java line 73:
>> 
>>> 71:  * <p>1. To find the first caller filtering a known list of implementation class:
>>> 72:  * {@snippet lang="java" :
>>> 73:  *     StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>> 
>> Would this read better as "filtering **out** a known list of implementation **classes**" ?
>
> how about "s/filtering/excluding"?

Yes - that's better.

>> src/java.base/share/classes/java/lang/StackWalker.java line 98:
>> 
>>> 96:      *
>>> 97:      * <p> The information of a {@code StackFrame} available is determined by the
>>> 98:      * {@linkplain Option stack walking options} of a stack walker.
>> 
>> Would this read better as "The information available from a {@code StackFrame} is determined ... "?
>
> What about "Stack walker options configure the stack frame information obtained by a StackWalker." - the first sentence from the Option javadoc and use it in the class spec of StackWalker and StackFrame.

Sounds good!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309117609
PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309116727

From duke at openjdk.org  Tue Aug 29 17:03:22 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 29 Aug 2023 17:03:22 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <45lBRB5Jf3jkviwJnCUuiub6BDr-qqwNal1Bbr982ik=.6ce497c0-d2bb-4d2c-b700-28dc4842bf7c@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <45lBRB5Jf3jkviwJnCUuiub6BDr-qqwNal1Bbr982ik=.6ce497c0-d2bb-4d2c-b700-28dc4842bf7c@github.com>
Message-ID: <AZkxLiaFG7n5WLxFeiGMAS4XDG79mw1TrqZihq45JQM=.947f32ae-98ae-4c78-a27d-8f9c5ad41f46@github.com>

On Tue, 29 Aug 2023 16:04:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> My testing passed. But I am not sure correctness of code is fully tested. For now we have only JMH benchmark for this new code. Do we have JDK test which can check correctness of this code?

Hi Vladimir, will add the JDK tests to check for correctness and let you know.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697820155

From duke at openjdk.org  Tue Aug 29 17:03:26 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 29 Aug 2023 17:03:26 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <H8S-sUP_B-wBoc-Gu-Zo_wEtiYeNSKlZto8djNsIX-Y=.8d060054-ec20-43e9-a965-fccc1689c44a@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H8S-sUP_B-wBoc-Gu-Zo_wEtiYeNSKlZto8djNsIX-Y=.8d060054-ec20-43e9-a965-fccc1689c44a@github.com>
Message-ID: <3MsIs3kNxvxNOftvjnsisc7eWu6CEb-BbBsHJnj9SH4=.64c640da-61c4-49b2-9e19-02de020d2976@github.com>

On Mon, 28 Aug 2023 23:35:56 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up parameters passed to arrayPartition; update the check to load library
>
> make/modules/java.base/Lib.gmk line 240:
> 
>> 238: 
>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
>> 240:   $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \
> 
> As this is a C++ lib, consider using g++ for linking by setting:
> 
> TOOLCHAIN := TOOLCHAIN_LINK_CXX

Thanks Erik. Will update Lib.gmk to use g++ for linking.

> make/modules/java.base/Lib.gmk line 247:
> 
>> 245:       LDFLAGS := $(LDFLAGS_JDKLIB) \
>> 246:           $(call SET_SHARED_LIBRARY_ORIGIN), \
>> 247:       LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
> 
> This is set by default since JDK-8314554.

Thanks Erik. Will update Lib.gmk accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309118874
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309118373

From alanb at openjdk.org  Tue Aug 29 17:08:13 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Aug 2023 17:08:13 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v7]
In-Reply-To: <tmoe6WvFE3gJAnvQkWKv0nl7sJCOzhhb6iqUTSZHdrk=.ccb9a562-5c87-4f21-9011-19c74fe37e1c@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <Egn2xAs31EWmwryh5oZuLRhnw5p9DbjpIrsNyLn7UCo=.ab546e60-aab6-49bf-98b9-c47d2017de96@github.com>
 <lnzWnaCnDUbFpet9kDfWRCQd0KfRpPxftQS7LJzerSM=.d94dbf57-8d95-4fcc-890c-d93cfad54d56@github.com>
 <EVkyDkXJYrS__w0GzhCwKMZkw2OjUyFAfD23UkmORYc=.8cd3c5b0-dc03-4284-a9d7-e6cc4ce5016d@github.com>
 <tmoe6WvFE3gJAnvQkWKv0nl7sJCOzhhb6iqUTSZHdrk=.ccb9a562-5c87-4f21-9011-19c74fe37e1c@github.com>
Message-ID: <g2QFl7P4UDv1Az6fGPHL1UZhvm14y7FAawuGvRhm8Ug=.ebc5f6bd-3982-4d5a-a23c-67a8ba1136a6@github.com>

On Tue, 29 Aug 2023 16:59:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> how about "s/filtering/excluding"?
>
> Yes - that's better.

The example use filter so it might be better to have the text use the same word, up to you, I think "filtering out known implementation classes" works too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1309122820

From alanb at openjdk.org  Tue Aug 29 17:34:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Aug 2023 17:34:10 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: <_uNwDdZONPRN_Ve3ePW4nK_qXvra5usXGjSa9Mx7QCw=.e5afa50b-feac-4dff-b79c-9f71e3006a7e@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <nQlctZ3ctF4Wsn8cKLir4kn51OAqKChwyQ5Z-tPI-CM=.72a25210-016a-43a6-acca-5f3065e2bbba@github.com>
 <_uNwDdZONPRN_Ve3ePW4nK_qXvra5usXGjSa9Mx7QCw=.e5afa50b-feac-4dff-b79c-9f71e3006a7e@github.com>
Message-ID: <F7ZQIz60A5-3Tc9W0OfWcjEf4zrMn7RmL4G7ZZhYRpc=.bf783a37-1ead-4242-aa1c-ca77cb2efc94@github.com>

On Tue, 29 Aug 2023 12:35:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> @AlanBateman Gentle ping.

On my list, it's a lot to get through and a number of aspects to this that I think will require refinement and discussion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1697864131

From duke at openjdk.org  Tue Aug 29 17:36:22 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 29 Aug 2023 17:36:22 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <2s4hZgw7KRQ5AoYzTZ3-8BS5V6JAslioJXeil_jvfQA=.fb1a1a31-8726-494b-b77c-a66565a963da@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
 <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>
 <gnJRko8Ivf2ptENdp38Ghz22tXEpR2LtF4fVvnrkTPk=.ec080953-9439-4e08-92e1-995463563191@github.com>
 <2s4hZgw7KRQ5AoYzTZ3-8BS5V6JAslioJXeil_jvfQA=.fb1a1a31-8726-494b-b77c-a66565a963da@github.com>
Message-ID: <f1Hoc-w_LUPLaN57BM-EW8w96ZH__IyjRBPhs2rLYoE=.076578a6-df82-490d-af05-7e9cb1e7208a@github.com>

On Tue, 29 Aug 2023 16:02:57 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> If it's tied to GCC as well, then we should probably include that in the condition here unless it's also expected to work with Clang. (`TOOLCHAIN_TYPE` = `gcc`)
>
>> The reason this PR is focused on Linux is because the AVX512 sort and partitioning routines are based on Intel?s x86-simd-library (https://github.com/intel/x86-simd-sort) which was originally developed with GCC as the target compiler. Thus, this PR has restricted itself to Linux as the code was tested using GCC/Linux platforms. Additionally, the x86_64 library is compiled for AVX512 using file specific compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for Windows/MSVC++ compiler.?
> 
> That is why I am questioning this approach to have additional separate C++ code library - too much dependencies on other tools.
> 
> As I suggested before try to disassemble this library and use assembler code in VM new stubs. You can create specialized stubGenerator_x86_64_array_sort.cpp file for it. Then you don't need to depend on C++ compiler or OS.

The shared library approach is being followed currently as an initial implementation to demonstrate the value of AVX512 sorting. This will be followed up in future with support for Windows as well. 
If it is ok with you, the shared library approach could be pursued for now to be later replaced with specialized assembly stubs (which are agnostic to OS and compiler) when AVX512 sort is enabled for Windows. Please let us know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309151742

From naoto at openjdk.org  Tue Aug 29 18:06:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 18:06:10 GMT
Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is
 not clear
In-Reply-To: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
Message-ID: <FRzc0M7Ng3uen4jNGgHlbMUQwAy-0IJ4Rq4AO8LskE0=.e60f2dec-6ed4-4680-860a-69e84e2de2a6@github.com>

On Fri, 18 Aug 2023 21:28:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns  in regards to the max integer digits in j.text.DecimalFormat.
> 
> The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`.
> 
> See below,
> 
> DecimalFormat df = new DecimalFormat();
> df.applyPattern("000.000E0");
> df.getMaximumIntegerDigits(); //  ==> 3
> df.applyPattern("000.000");
> df.getMaximumIntegerDigits(); // ==> 2147483647
> 
> DecimalFormat df = new DecimalFormat("000.000");
> df.getMaximumIntegerDigits(); // ==> 2147483647
> DecimalFormat df = new DecimalFormat("000.000E0");
> df.getMaximumIntegerDigits(); // ==> 3
> 
> 
> Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well.

src/java.base/share/classes/java/text/DecimalFormat.java line 458:

> 456:      * is the typical end-user desire. Use {@link #setMaximumIntegerDigits(int)}
> 457:      * if you want to set a specific limit to integer digits when the
> 458:      * given pattern is not in scientific notation.

It could be simpler if the normal case (Integer.MAX_VALUE) comes first, then the scientific notation case in which you can refer to the max integer digit in the class description. Also, `setMaximumIntegerDigits` can be called on a scientific notation as well, correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15349#discussion_r1309181469

From jlu at openjdk.org  Tue Aug 29 18:21:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 18:21:09 GMT
Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is
 not clear
In-Reply-To: <FRzc0M7Ng3uen4jNGgHlbMUQwAy-0IJ4Rq4AO8LskE0=.e60f2dec-6ed4-4680-860a-69e84e2de2a6@github.com>
References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
 <FRzc0M7Ng3uen4jNGgHlbMUQwAy-0IJ4Rq4AO8LskE0=.e60f2dec-6ed4-4680-860a-69e84e2de2a6@github.com>
Message-ID: <kFpM8Zf1CCklFPfeVD_D8LshsQC2-ZQwB18tOHtJL3o=.2cea37fd-0198-44cf-8c14-378ddc29642f@github.com>

On Tue, 29 Aug 2023 18:02:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns  in regards to the max integer digits in j.text.DecimalFormat.
>> 
>> The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`.
>> 
>> See below,
>> 
>> DecimalFormat df = new DecimalFormat();
>> df.applyPattern("000.000E0");
>> df.getMaximumIntegerDigits(); //  ==> 3
>> df.applyPattern("000.000");
>> df.getMaximumIntegerDigits(); // ==> 2147483647
>> 
>> DecimalFormat df = new DecimalFormat("000.000");
>> df.getMaximumIntegerDigits(); // ==> 2147483647
>> DecimalFormat df = new DecimalFormat("000.000E0");
>> df.getMaximumIntegerDigits(); // ==> 3
>> 
>> 
>> Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well.
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 458:
> 
>> 456:      * is the typical end-user desire. Use {@link #setMaximumIntegerDigits(int)}
>> 457:      * if you want to set a specific limit to integer digits when the
>> 458:      * given pattern is not in scientific notation.
> 
> It could be simpler if the normal case (Integer.MAX_VALUE) comes first, then the scientific notation case in which you can refer to the max integer digit in the class description. Also, `setMaximumIntegerDigits` can be called on a scientific notation as well, correct?

Thank you for the review. Will adjust with your suggestions.

> Also, `setMaximumIntegerDigits` can be called on a scientific notation as well, correct?

I meant that you pretty much only need to consider calling `setMaximumIntegerDigits` when the pattern is not in scientific notation, not that you are not able to. Will make this clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15349#discussion_r1309195909

From naoto at openjdk.org  Tue Aug 29 18:43:07 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 18:43:07 GMT
Subject: RFR: 6333341: [BI] Doc: java.text.BreakIterator class
 specification is unclear
In-Reply-To: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
References: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
Message-ID: <hMHiS-cjFXQTB5tDlwegDWKpL6UulAj1nA6y3t2qnG4=.71e27c4c-442d-4b10-9d37-9a246ff74683@github.com>

On Thu, 24 Aug 2023 21:39:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR ](https://bugs.openjdk.org/browse/JDK-8314974)which clarifies behavior for BreakIterator instances when text has not been set.
> 
> For example,  calling `BreakIterator.getWordInstance().next();` has an ambiguous result.
> A boundary searching operation was called but no text was supplied. Is the result an exception, 0, -1 (BreakIterator.DONE), or something else? In reality, the operation will be performed on any empty string.
> 
> 
> This change makes it apparent that failing to set the text will cause the BreakIterator instance to default to a `StringCharacterIterator` with an empty string (equivalent to calling setText("")).

src/java.base/share/classes/java/text/BreakIterator.java line 112:

> 110:  * of calling {@code setText("")} if the text hasn't been set by either
> 111:  * {@link #setText(String)} or {@link #setText(CharacterIterator)}
> 112:  * and a boundary searching operation is called by the {@code BreakIterator} instance.

`@implNote` would be desired here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15422#discussion_r1309215800

From rriggs at openjdk.org  Tue Aug 29 18:48:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Aug 2023 18:48:25 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <3BYkSKH633EJPmI86EavRQeaLmvursnu0VsHWIRvceU=.25709139-26db-4e5d-b07d-cf693a9bc62d@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

@mcimadamore Does Panama have anything to offer over hard coded stubs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697957043

From cjplummer at openjdk.org  Tue Aug 29 19:25:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 29 Aug 2023 19:25:12 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2]
In-Reply-To: <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
Message-ID: <SAf3vxbCOAXOTb9egSyc50Z7lt8fCMzE86nBLEHFyrw=.276f82b8-6889-4c50-93fe-5f69ef56f22f@github.com>

On Tue, 29 Aug 2023 09:12:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright

> I kind of like that it is long and clumsy, that makes it harder to use...

...but it's used in 462 files. That implies it is commonly used. Are you suggesting nearly all those uses are incorrect and eventually should be converted to `createTestJvm()`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698003837

From alanb at openjdk.org  Tue Aug 29 19:35:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Aug 2023 19:35:21 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <_yPxZATuaIq3XrDJWKxHuK674VN0QsuSph_5qLlCmKI=.06e3ca81-bdc9-4bd7-9f66-b5a28a71af1b@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

The changes to DualPivotQuicksort will need detailed review to ensure that this is understandable and maintainable, there is a lot here to study.

The addition of libx86_64 and having the stub generation call out to this library also needs discussion to make sure there is an agreement on how this would be integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698011712

From duke at openjdk.org  Tue Aug 29 19:35:23 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 29 Aug 2023 19:35:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

Hi,
We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java

The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698016905

From duke at openjdk.org  Tue Aug 29 19:35:22 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 29 Aug 2023 19:35:22 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <AZkxLiaFG7n5WLxFeiGMAS4XDG79mw1TrqZihq45JQM=.947f32ae-98ae-4c78-a27d-8f9c5ad41f46@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <45lBRB5Jf3jkviwJnCUuiub6BDr-qqwNal1Bbr982ik=.6ce497c0-d2bb-4d2c-b700-28dc4842bf7c@github.com>
 <AZkxLiaFG7n5WLxFeiGMAS4XDG79mw1TrqZihq45JQM=.947f32ae-98ae-4c78-a27d-8f9c5ad41f46@github.com>
Message-ID: <LGoc76iLjvjt-FA0WJnusQWTPgyyQFQPzH0uDlw5XbY=.62377e83-5086-46e2-a843-18f600cb2e62@github.com>

On Tue, 29 Aug 2023 16:57:11 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> > My testing passed. But I am not sure correctness of code is fully tested. For now we have only JMH benchmark for this new code. Do we have JDK test which can check correctness of this code?
> 
> Hi Vladimir, will add the JDK tests to check for correctness and let you know

Hi,
We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java

The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698014609

From duke at openjdk.org  Tue Aug 29 20:00:49 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Tue, 29 Aug 2023 20:00:49 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v9]
In-Reply-To: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
Message-ID: <xtJfRg446EGGTd0cErJeFEwqBomGHQHHgx7pDDH4rks=.9280285e-f4cd-4ede-99fc-2c20a88a167f@github.com>

> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
> 
> final int size = (1 << 30) + 1;
> final List<Byte> list = new ArrayList<>(size);
> for (int i = 0; i < size; ++i)
>     list.add((byte) 0);
> Collections.rotate(list, size - 1);
> 
> Output:
> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
> 
> In that case private method `Collections.rotate1` will be called. And the line:
> `i += distance;`
> will cause overflow. I fixed this method and wrote a test for it.
> 
> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
> 
> Kindly ask you to raise a bug.

Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:

  8314236: add comment for test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15270/files
  - new: https://git.openjdk.org/jdk/pull/15270/files/a7d7722b..2bbcffac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15270&range=07-08

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15270/head:pull/15270

PR: https://git.openjdk.org/jdk/pull/15270

From duke at openjdk.org  Tue Aug 29 20:04:12 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Tue, 29 Aug 2023 20:04:12 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v8]
In-Reply-To: <ZebsTdDoVdW_oS4AL9hg4RBCkW6HE-ICHaeFHhWRVGY=.d1d40f98-5c42-485e-8693-66ccf2185152@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <hm8v3HONdRkzGDXcRcyeTpFyBLm4Hc2drvVWOFCPlg0=.91eaa5be-a90c-4139-86c7-161dae94ee5f@github.com>
 <ZebsTdDoVdW_oS4AL9hg4RBCkW6HE-ICHaeFHhWRVGY=.d1d40f98-5c42-485e-8693-66ccf2185152@github.com>
Message-ID: <wxlPMYtEktwoxfcfx-xJoVCVWLcNwOjsLQ0zwOJbxCs=.5a8102c4-8cc0-427f-8775-964344fde2d4@github.com>

On Tue, 29 Aug 2023 03:02:56 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Nikita Sakharin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   fix overflow in Collections.rotate and write tests
>
> (The bot has already admonished you about avoiding rebasing. In practice merging works well and is helpful so that reviewers can see incremental changes.)
> 
> The additional test cases look good. Sorry I forgot to mention this previously: it would be good to have a comment in the test that says that the test is _only_ testing the index computations and not the actual rotation of elements.
> 
> Meanwhile, I'll pull in the changes from your branch and run them through our internal build system, which is more reliable (and comprehensive) than GHA.

@stuart-marks

Thank you for your review!

I added comment for the test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1698051561

From jlu at openjdk.org  Tue Aug 29 20:09:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 20:09:37 GMT
Subject: RFR: 6333341: [BI] Doc: java.text.BreakIterator class
 specification is unclear [v2]
In-Reply-To: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
References: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
Message-ID: <0i_hISwf4CoARewrpJc4V79Iob6YzKjTCafd-Q6VYRQ=.548fe24a-a316-47ac-9952-ee17903cfcba@github.com>

> Please review this PR and [CSR ](https://bugs.openjdk.org/browse/JDK-8314974)which clarifies behavior for BreakIterator instances when text has not been set.
> 
> For example,  calling `BreakIterator.getWordInstance().next();` has an ambiguous result.
> A boundary searching operation was called but no text was supplied. Is the result an exception, 0, -1 (BreakIterator.DONE), or something else? In reality, the operation will be performed on any empty string.
> 
> 
> This change makes it apparent that failing to set the text will cause the BreakIterator instance to default to a `StringCharacterIterator` with an empty string (equivalent to calling setText("")).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use implNote tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15422/files
  - new: https://git.openjdk.org/jdk/pull/15422/files/4f260622..e842dd8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15422&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15422&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15422.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15422/head:pull/15422

PR: https://git.openjdk.org/jdk/pull/15422

From naoto at openjdk.org  Tue Aug 29 20:21:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 20:21:09 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes
In-Reply-To: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>
References: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>
Message-ID: <40Xk4qJLPGjJQHhslejdmheMW400kF_cEyGM7M3URI0=.b6e374f2-c08f-4f62-baed-3ec70894e0af@github.com>

On Mon, 28 Aug 2023 21:24:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refines the spec of `equals()` and `hashCode()` in `java.text.Format` related classes.
> 
> The current spec for most of these methods is either  "_Overrides <method_name>_" or are incomplete/wrong (i.e. see `ChoiceFormat`).
> 
> This fix adjusts the spec to provide a consistent definition for the overridden methods and specify what is being compared/used to generate a hash code value.
> 
> For implementations that use at most a few fields, the values are stated, otherwise a more general term is used as a substitution (i.e. see `DecimalFormat`).

src/java.base/share/classes/java/text/ChoiceFormat.java line 501:

> 499:      *
> 500:      * The hash code value is based on the values returned by {@link #getLimits()} and
> 501:      * {@link #getFormats()}.

Could this part (and its counterpart in `equals()`) be more generalized? In this method, it spells out the fields to be considered, and in other classes, it simply mentions "same format configuration." Maybe using links to `Serialized Form` and making the sentence more generic?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15459#discussion_r1309312616

From sviswanathan at openjdk.org  Tue Aug 29 20:28:21 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 29 Aug 2023 20:28:21 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <_yPxZATuaIq3XrDJWKxHuK674VN0QsuSph_5qLlCmKI=.06e3ca81-bdc9-4bd7-9f66-b5a28a71af1b@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <_yPxZATuaIq3XrDJWKxHuK674VN0QsuSph_5qLlCmKI=.06e3ca81-bdc9-4bd7-9f66-b5a28a71af1b@github.com>
Message-ID: <p74iClZ-ZHTgTtidGz6DjmBum9Zl5XUkKWDYeZbcM8k=.5a072cbe-387b-457e-8a04-37352c52eb02@github.com>

On Tue, 29 Aug 2023 19:28:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up parameters passed to arrayPartition; update the check to load library
>
> The changes to DualPivotQuicksort will need detailed review to ensure that this is understandable and maintainable, there is a lot here to study.
> 
> The addition of libx86_64 and having the stub generation call out to this library also needs discussion to make sure there is an agreement on how this would be integrated.

@AlanBateman If it helps, the changes made by @vamsi-parasa to DualPivotQuickSort.java don't change the logic as written in Java. They only carve out the functionality into separate Java methods retaining the meaning exactly as before. These Java methods are then optimized through a stub.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698079501

From kvn at openjdk.org  Tue Aug 29 20:28:23 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Aug 2023 20:28:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <f1Hoc-w_LUPLaN57BM-EW8w96ZH__IyjRBPhs2rLYoE=.076578a6-df82-490d-af05-7e9cb1e7208a@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
 <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>
 <gnJRko8Ivf2ptENdp38Ghz22tXEpR2LtF4fVvnrkTPk=.ec080953-9439-4e08-92e1-995463563191@github.com>
 <2s4hZgw7KRQ5AoYzTZ3-8BS5V6JAslioJXeil_jvfQA=.fb1a1a31-8726-494b-b77c-a66565a963da@github.com>
 <f1Hoc-w_LUPLaN57BM-EW8w96ZH__IyjRBPhs2rLYoE=.076578a6-df82-490d-af05-7e9cb1e7208a@github.com>
Message-ID: <qAwCU58umL8A4l8Gj38UTHvTL6G7HnZC2FMx_tatFA4=.c81b66d1-e2ef-4401-a539-7141ec8f2e17@github.com>

On Tue, 29 Aug 2023 17:32:26 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>>> The reason this PR is focused on Linux is because the AVX512 sort and partitioning routines are based on Intel?s x86-simd-library (https://github.com/intel/x86-simd-sort) which was originally developed with GCC as the target compiler. Thus, this PR has restricted itself to Linux as the code was tested using GCC/Linux platforms. Additionally, the x86_64 library is compiled for AVX512 using file specific compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for Windows/MSVC++ compiler.?
>> 
>> That is why I am questioning this approach to have additional separate C++ code library - too much dependencies on other tools.
>> 
>> As I suggested before try to disassemble this library and use assembler code in VM new stubs. You can create specialized stubGenerator_x86_64_array_sort.cpp file for it. Then you don't need to depend on C++ compiler or OS.
>
> The shared library approach is being followed currently as an initial implementation to demonstrate the value of AVX512 sorting. This will be followed up in future with support for Windows as well. 
> If it is ok with you, the shared library approach could be pursued for now to be later replaced with specialized assembly stubs (which are agnostic to OS and compiler) when AVX512 sort is enabled for Windows. Please let us know.

I am okay with such incremental approach. Please, file RFE to replace library with stubs in a future (it could be still separate library but with assembler code).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309316767

From kvn at openjdk.org  Tue Aug 29 20:39:21 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Aug 2023 20:39:21 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
Message-ID: <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>

On Tue, 29 Aug 2023 19:32:44 GMT, iaroslavski <duke at openjdk.org> wrote:

> Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java
> 
> The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files

Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic without additional flags?
@vamsi-parasa can you check?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698092741

From duke at openjdk.org  Tue Aug 29 20:45:22 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 29 Aug 2023 20:45:22 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
 <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
Message-ID: <4b8E1FzKQ4-Q_gCsL9Fn7jJwz21mEnUJJKiLCBeplrg=.54a06fcb-bcce-4866-b9b3-71cb1052f5e9@github.com>

On Tue, 29 Aug 2023 20:36:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java
> 
> The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files

Hello Vladimir (@iaroslavski),

Thank you for providing the link to the correctness tests!

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698101345

From naoto at openjdk.org  Tue Aug 29 20:49:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 29 Aug 2023 20:49:12 GMT
Subject: RFR: 8314925: ChoiceFormat does not specify
 IllegalArgumentExceptions
In-Reply-To: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>
References: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>
Message-ID: <0LguXLM_w0fvTwqzNiT3k4o3sOBEIN3uUR9c7xoLOjs=.e325fac5-035f-4b18-8c1a-33017b9cf32e@github.com>

On Tue, 29 Aug 2023 16:53:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315148) which is a conformance change to specify exceptions in java.text.ChoiceFormat.
> 
> Makes `IllegalArgumentException` apparent for `applyPattern` and `setChoices`, as well as for the associated constructors that call the methods.
> 
> This change also improves the error message for the `setChoices` IAE.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15473#pullrequestreview-1601251583

From mchung at openjdk.org  Tue Aug 29 20:51:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 29 Aug 2023 20:51:56 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
> can be used instead and such stack walker will save the overhead of extracting the method information
> and the memory used for the stack walking.
> 
> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
> This provides a simple way for existing code, for example logging frameworks, to take advantage of
> this enhancement with the least change as it can keep the existing function for traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(Predicate.not(implClasses::contains))
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> #### Javadoc & specdiff
> 
> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
> 
> #### Alternatives Considered
> One alternative is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> ### Implementation Details
> 
> A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]`
> buffer that is filled by the VM during stack walking.   `Sta...

Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:

 - update mode to be int rather than long
 - update tests
 - Review feedback on javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15370/files
  - new: https://git.openjdk.org/jdk/pull/15370/files/3ca53c74..5a48c709

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=06-07

  Stats: 127 lines in 14 files changed: 81 ins; 0 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From stuart.marks at oracle.com  Tue Aug 29 21:10:56 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 29 Aug 2023 14:10:56 -0700
Subject: CFV: New Core Libraries Group Member: Michael McMahon
In-Reply-To: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
References: <cbde4245-9ab9-cbc2-692d-8d2df16a3f5a@oracle.com>
Message-ID: <55e21af1-0ebd-078c-9687-e098ff80f2ca@oracle.com>

Vote: yes

On 8/25/23 8:24 AM, Roger Riggs wrote:
> I hereby nominate Michael McMahon to Membership in the Core Libraries Group
> 
> Michael has been contributing to the OpenJDK Core Libraries since 2008, originally 
> at Sun Microsystems, now Oracle. He has deep networking experience and has made more 
> than 260 contributions to OpenJDK.
> 
> Votes are due by September 8th, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing list For Lazy 
> Consensus voting instructions, see [2].
> 
> Roger Riggs
> 
> [1] https://openjdk.org/census#core-libs
> 
> [2] https://openjdk.org/groups/#member-vote
> 

From stuart.marks at oracle.com  Tue Aug 29 21:12:11 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 29 Aug 2023 14:12:11 -0700
Subject: CFV: New Core Libraries Group Member: Daniel Fuchs
In-Reply-To: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
References: <7fa4befa-7b78-554e-1f6e-6ce690cb37b9@oracle.com>
Message-ID: <13891e38-c40c-abf6-afd0-510bd9f3d536@oracle.com>

Vote: yes

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Daniel Fuchs to Membership in the Core Libraries Group
> 
> Daniel has been contributing to the OpenJDK Core Libraries at Oracle since 2012. He 
> is leading the networking team and has made nearly 400 contributions to OpenJDK 
> since JDK 6.
> 
> Votes are due by September 8th, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Roger Riggs
> 
> [1] https://openjdk.org/census#core-libs
> 
> [2] https://openjdk.org/groups/#member-vote

From stuart.marks at oracle.com  Tue Aug 29 21:13:52 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 29 Aug 2023 14:13:52 -0700
Subject: CFV: New Core Libraries Group Member: Lance Andersen
In-Reply-To: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
References: <bd43bfaa-2d22-11a2-6524-97314e8c06e6@oracle.com>
Message-ID: <4a07fb20-6fe1-6c59-7bfc-7424075a7493@oracle.com>

Vote: yes

On 8/25/23 8:23 AM, Roger Riggs wrote:
> I hereby nominate Lance Andersen to Membership in the Core Libraries Group
> 
> Lance has been contributing to the OpenJDK at Oracle since 2007. He has been the 
> JDBC spec lead since 2005 and an OpenJDK committer since day 1. He has extensive 
> experience with Java EE, Databases and SQL and is improving the integrity and 
> performance of Zip and JAR implementations.
> 
> Votes are due by September 8th, 2023.
> 
> Only current Members of the Core Libraries Group [1] are eligible to vote on this 
> nomination. Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Roger Riggs
> 
> [1] https://openjdk.org/census#core-libs
> 
> [2] https://openjdk.org/groups/#member-vote||
> 

From jlu at openjdk.org  Tue Aug 29 21:42:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 21:42:28 GMT
Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is
 not clear [v2]
In-Reply-To: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
Message-ID: <goNwkmTiYeJgf4xC7t97bYOIjA9Oe7uYsesAN89hc_Y=.01510cd4-f6ba-4b81-b8a1-6c6e29a74e9c@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns  in regards to the max integer digits in j.text.DecimalFormat.
> 
> The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`.
> 
> See below,
> 
> DecimalFormat df = new DecimalFormat();
> df.applyPattern("000.000E0");
> df.getMaximumIntegerDigits(); //  ==> 3
> df.applyPattern("000.000");
> df.getMaximumIntegerDigits(); // ==> 2147483647
> 
> DecimalFormat df = new DecimalFormat("000.000");
> df.getMaximumIntegerDigits(); // ==> 2147483647
> DecimalFormat df = new DecimalFormat("000.000E0");
> df.getMaximumIntegerDigits(); // ==> 3
> 
> 
> Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Reflect review comments: Non sci notation first. Link to Scientific Notation section

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15349/files
  - new: https://git.openjdk.org/jdk/pull/15349/files/3702f48b..93b0053e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15349&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15349&range=00-01

  Stats: 33 lines in 1 file changed: 4 ins; 0 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/15349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15349/head:pull/15349

PR: https://git.openjdk.org/jdk/pull/15349

From jlu at openjdk.org  Tue Aug 29 21:42:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Aug 2023 21:42:29 GMT
Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is
 not clear [v2]
In-Reply-To: <FRzc0M7Ng3uen4jNGgHlbMUQwAy-0IJ4Rq4AO8LskE0=.e60f2dec-6ed4-4680-860a-69e84e2de2a6@github.com>
References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
 <FRzc0M7Ng3uen4jNGgHlbMUQwAy-0IJ4Rq4AO8LskE0=.e60f2dec-6ed4-4680-860a-69e84e2de2a6@github.com>
Message-ID: <kfxG2466nYO0YNh4SNiPO4SdIXaDo4ID4DNkanJscOI=.662c277c-2890-482d-b02b-98c901669412@github.com>

On Tue, 29 Aug 2023 18:02:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments: Non sci notation first. Link to Scientific Notation section
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 458:
> 
>> 456:      * is the typical end-user desire. Use {@link #setMaximumIntegerDigits(int)}
>> 457:      * if you want to set a specific limit to integer digits when the
>> 458:      * given pattern is not in scientific notation.
> 
> It could be simpler if the normal case (Integer.MAX_VALUE) comes first, then the scientific notation case in which you can refer to the max integer digit in the class description. Also, `setMaximumIntegerDigits` can be called on a scientific notation as well, correct?

@naotoj Updated with your suggestions. Held off on updating CSR as well in case the wording still needs to be further adjusted. I also considered adding these changes to the class description (instead of each method/constructor), but I thought the class description was already quite long, and it could easily be missed if added that way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15349#discussion_r1309378808

From mseledtsov at openjdk.org  Tue Aug 29 22:08:27 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Tue, 29 Aug 2023 22:08:27 GMT
Subject: RFR: 8313718: make container at requires command configurable
Message-ID: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>

Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().

-------------

Commit messages:
 - Renamed docker support to container support
 - Added useful logging; updated comments
 - Allow use of u0020 unicode to escape spaces
 - 8313718: make container at requires command configurable - initial drop

Changes: https://git.openjdk.org/jdk/pull/15475/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313718
  Stats: 44 lines in 2 files changed: 26 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/15475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15475/head:pull/15475

PR: https://git.openjdk.org/jdk/pull/15475

From smarks at openjdk.org  Tue Aug 29 22:17:11 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 29 Aug 2023 22:17:11 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate [v9]
In-Reply-To: <xtJfRg446EGGTd0cErJeFEwqBomGHQHHgx7pDDH4rks=.9280285e-f4cd-4ede-99fc-2c20a88a167f@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <xtJfRg446EGGTd0cErJeFEwqBomGHQHHgx7pDDH4rks=.9280285e-f4cd-4ede-99fc-2c20a88a167f@github.com>
Message-ID: <X19EjUAr5KgIf2veJYLgnydtC1DlAH_FJhcuFTm3cT0=.4c05cdae-d45e-45fd-881c-0f901a005a21@github.com>

On Tue, 29 Aug 2023 20:00:49 GMT, Nikita Sakharin <duke at openjdk.org> wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List<Byte> list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Nikita Sakharin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8314236: add comment for test

Thanks for the update. Test run looks good! Approved.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15270#pullrequestreview-1601360793

From duke at openjdk.org  Tue Aug 29 23:32:23 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Tue, 29 Aug 2023 23:32:23 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
 <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
Message-ID: <d36ibn4WjxLfZUT50JG4685z3DJs2CnN-xjZ05HG_nA=.2318ca21-1b60-4105-9e65-db24b066f4e4@github.com>

On Tue, 29 Aug 2023 20:36:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java
> > The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files
> 
> Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic without additional flags? @vamsi-parasa can you check?

Sure Vladimir (@vnkozlov). Will check if test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags and let you know.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698103318

From kvn at openjdk.org  Tue Aug 29 23:32:25 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 29 Aug 2023 23:32:25 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <E4eunt6DoV9u6Ru8JCOXYtty5-CQPNsAYfzYb84AfdU=.3f533345-ebbe-40b2-8d8a-18daffa99f0d@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

I looked on my testing log and I see that this test was run on machines which do not have avx512. I am re-running jdk/util tests with -Xcomp flag on avx512 machines.

My testing  with -Xcomp flag on avx512 machines passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698106526
PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698272873

From duke at openjdk.org  Wed Aug 30 00:40:32 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 30 Aug 2023 00:40:32 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <d36ibn4WjxLfZUT50JG4685z3DJs2CnN-xjZ05HG_nA=.2318ca21-1b60-4105-9e65-db24b066f4e4@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
 <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
 <d36ibn4WjxLfZUT50JG4685z3DJs2CnN-xjZ05HG_nA=.2318ca21-1b60-4105-9e65-db24b066f4e4@github.com>
Message-ID: <kl9YhXeptEVVdsRW3IdXc7JanAlofL-SOGCT1mJWfDg=.b03924c6-3519-407a-b62e-6880eb135d5f@github.com>

On Tue, 29 Aug 2023 20:44:32 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> > > Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java
> > > The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files
> > 
> > 
> > Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic without additional flags? @vamsi-parasa can you check?
> 
> Sure Vladimir (@vnkozlov). Will check if test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags and let you know.

Hi Vladimir,
Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags as shown in the output snapshot below:
![image](https://github.com/openjdk/jdk/assets/23087109/a2d4edb1-9377-4f92-bed2-3e40bc5a7654)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698322922

From kvn at openjdk.org  Wed Aug 30 02:04:22 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Aug 2023 02:04:22 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
Message-ID: <EBSDLUr3_6yOMAZt4b5o9NU2bQuFvMI6Zws2otu1TmU=.2d936565-7114-4e9a-8df0-ed591fa108b0@github.com>

On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up parameters passed to arrayPartition; update the check to load library

Good. Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698380569

From dholmes at openjdk.org  Wed Aug 30 02:56:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Aug 2023 02:56:08 GMT
Subject: RFR: 8313718: make container at requires command configurable
In-Reply-To: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
Message-ID: <sSy90GfXVf1cKiihTMYaoDWTM6fkAgPF9ITRVbPcZEg=.b82c7c71-70bb-494f-9f93-02796e36fa6a@github.com>

On Tue, 29 Aug 2023 22:01:22 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().

I'm unclear how this is supposed to work. We have existing tests that have `@requires docker.support` that may or may not work for arbitrary "container" environments. What if they are really docker specific tests? Won't we still need `dockerSupport`?

Thanks

test/jtreg-ext/requires/VMProps.java line 538:

> 536:         log("Entering containerSupport()");
> 537: 
> 538:         boolean isSupported = true;

This needs to be initialized to false.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15475#pullrequestreview-1601779598
PR Review Comment: https://git.openjdk.org/jdk/pull/15475#discussion_r1309562341

From mseledtsov at openjdk.org  Wed Aug 30 03:06:18 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 30 Aug 2023 03:06:18 GMT
Subject: RFR: 8313718: make container at requires command configurable
In-Reply-To: <sSy90GfXVf1cKiihTMYaoDWTM6fkAgPF9ITRVbPcZEg=.b82c7c71-70bb-494f-9f93-02796e36fa6a@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
 <sSy90GfXVf1cKiihTMYaoDWTM6fkAgPF9ITRVbPcZEg=.b82c7c71-70bb-494f-9f93-02796e36fa6a@github.com>
Message-ID: <Kv5G9q-SL9cjxJp-eUYu557-0pLp9TrIem649kpEU4Y=.93405061-8dfc-47fd-86cc-167a00f0a1be@github.com>

On Wed, 30 Aug 2023 02:49:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().
>
> test/jtreg-ext/requires/VMProps.java line 538:
> 
>> 536:         log("Entering containerSupport()");
>> 537: 
>> 538:         boolean isSupported = true;
> 
> This needs to be initialized to false.

Good catch, thank you. This is a bug, a leftover from my experimentation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15475#discussion_r1309571210

From mseledtsov at openjdk.org  Wed Aug 30 03:18:14 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 30 Aug 2023 03:18:14 GMT
Subject: RFR: 8313718: make container at requires command configurable
In-Reply-To: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
Message-ID: <P_vZm7uXWzIs_rB6BlugOQNUPiz3uSijLaSG9kBbeOk=.3c6ca2da-bf9a-484c-a0e4-d2f7c525e9e3@github.com>

On Tue, 29 Aug 2023 22:01:22 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().

Hi David,

Thank you for taking a look at this change.  To answer your questions:
 -- how is this supposed to work ? 
 If user running the tests does not specify the newly introduced property things will work same as before. If user specifies -Djdk.test.container.requires.check.command then the specified command will be executed to check whether container testing can be performed on a given host/system. 

By default the code in VMProps.java runs "docker ps". With this change we could override it with any other relevant command, such as "podman version" or other type of container command.

-- What if they are really docker specific tests?
I think our container tests should be fairly container-generic (or container agnostic), but need to check this. This raises a good question. Perhaps we should consider removing the at-requires check entirely, and rely on individual checks in individual tests. This will give us more flexibility, we run a specific check in each test and throw a jtreg.SkippedException upon failure. We already do some additional checks in each test, such as podman version, cgroups v1 vs v2, etc.

Let me know what you think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15475#issuecomment-1698424798

From mseledtsov at openjdk.org  Wed Aug 30 03:25:54 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Wed, 30 Aug 2023 03:25:54 GMT
Subject: RFR: 8313718: make container at requires command configurable [v2]
In-Reply-To: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
Message-ID: <LRXONRMx_WRJUuBw1AFXFotxsmuIrYp7FzHw7MdMZRU=.6665f01a-f87c-41cb-abc9-773c17fe8684@github.com>

> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().

Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:

  Fixed initialization issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15475/files
  - new: https://git.openjdk.org/jdk/pull/15475/files/3605d604..7ad1371a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15475&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15475/head:pull/15475

PR: https://git.openjdk.org/jdk/pull/15475

From liach at openjdk.org  Wed Aug 30 06:44:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 30 Aug 2023 06:44:27 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v5]
In-Reply-To: <KsHPJN-4NOFaU1Tu8qSVJdkO__GHD0J07cZNiHrBkJc=.0d58d5ce-2bfc-4dbc-b17e-c3756e887b35@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <KsHPJN-4NOFaU1Tu8qSVJdkO__GHD0J07cZNiHrBkJc=.0d58d5ce-2bfc-4dbc-b17e-c3756e887b35@github.com>
Message-ID: <48xqGNO8NgBG4Jpewau111hFGsUTjGCroIwy9GPVTGs=.3ea065d6-bde6-45d7-b5aa-a75237c48724@github.com>

On Tue, 1 Aug 2023 20:21:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
>  - small cleanup
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Update ReferencedKeyTest.java
>  - Simple versions of create
>  - Add flag for reference queue type
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Remove warning tied to String Templates
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/7ba8c69a...0e435898

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 96:

> 94: 
> 95:     // Non-normalized to normalized BaseLocale cache for saving costly normalizations
> 96:     private static final Map<BaseLocale, BaseLocale> CACHE = ReferencedKeyMap.create(true, ConcurrentHashMap::new);

You can now simply use a `ReferencedKeySet<BaseLocale>` and call [`intern(T, UnaryOperator<T>)`](https://github.com/openjdk/jdk/blob/ce2a7ea40a22c652e5f8559c91d5eea197e2d708/src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java#L202) to cache a normalized variety computed from a non-normalized base.

test/jdk/jdk/internal/util/ReferencedKeyTest.java line 1:

> 1: /*

Is the test removal intentional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1309756538
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1309757683

From mbaesken at openjdk.org  Wed Aug 30 06:50:25 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Aug 2023 06:50:25 GMT
Subject: RFR: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test
 enhance output of children [v2]
In-Reply-To: <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>
References: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
 <CKaDRj7rZfT4SJ_OcNWldw8dehc4gV4j7m9A9uPJ-Gs=.28ff76f5-c976-43a6-a169-16bb0a621efe@github.com>
Message-ID: <SFzOKpwSuz0kvNc7ZOoK80kMsOCV-9OTxBlxfrbOH_w=.9ed841d1-0265-4f35-9198-f5be59879352@github.com>

On Tue, 29 Aug 2023 12:10:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use 2 containers for children and descendants

Hi Roger and Thomas, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15466#issuecomment-1698589971

From mbaesken at openjdk.org  Wed Aug 30 06:50:26 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 30 Aug 2023 06:50:26 GMT
Subject: Integrated: JDK-8315213: java/lang/ProcessHandle/TreeTest.java test
 enhance output of children
In-Reply-To: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
References: <k0gaMrz1Aqs7rdzROpLb4Mp2Kf6027Csb_Grl90A1h8=.563740c8-1cf6-4203-9a6b-0b1ebec56538@github.com>
Message-ID: <rOxHdrg9NPWShnw3bKnIalx0ecReiKShwrAcKj7RIQ0=.9a6608c0-3463-468b-9267-8ba315a2213c@github.com>

On Tue, 29 Aug 2023 07:51:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have some failures in TreeTest.java where the expected number of child processes is differing from what we really get. It would be good to have more output to analyze these cases.

This pull request has now been integrated.

Changeset: f3aeb024
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3aeb024d91c2d2088359d261be9a4b56a90663c
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8315213: java/lang/ProcessHandle/TreeTest.java test enhance output of children

Reviewed-by: stuefe, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/15466

From alanb at openjdk.org  Wed Aug 30 07:12:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Aug 2023 07:12:24 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
Message-ID: <HLRQsz7QLRGMxteBZfOJ3F5iyJef7DFe5RWTwsecldM=.5e9b9cef-5fa5-446d-bf7e-cbc9b5a5f042@github.com>

On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update mode to be int rather than long
>  - update tests
>  - Review feedback on javadoc

The updated proposal/javadoc looks good, just in two minds on whether the overload with the varargs should be added. The Set.of factory methods make is really easy to use the existing getInstance(Set) method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1698616974

From dholmes at openjdk.org  Wed Aug 30 07:22:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Aug 2023 07:22:10 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v2]
In-Reply-To: <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <ISuejqIr1InBH-hXEzgOt7iBXrhH4iv93glC3woOewQ=.3a7357d0-a911-4dfa-834b-2c5123915ce7@github.com>
 <pnAnjv8HLt1sykmB9jRamtiVRoTbmwQi9xGuaSnCi10=.34427fd4-7b88-436e-946b-04c7364a1853@github.com>
 <5AjL4PbmGc-9jQdiCK1jd4LDdC-B7NgJ_dwIZW1U-aA=.0ad22596-a1f9-4e87-946f-dceedf0a37e5@github.com>
Message-ID: <LC17h9qCmoHNn4rcN1kgdrvaYOrkTkPXn_BlKTXyN0s=.e1d9cbdc-8991-455b-be06-166476c6436f@github.com>

On Tue, 29 Aug 2023 16:45:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I don't think this is the best change across so many files.
>> It gives a very ugly name to a common test function and affects a very large number of tests.
>
>> @RogerRiggs If it is only the name you want changed, maybe you can offer a better name?
> @lkorinth 
> 
> Sorry for the too short comment; I wanted to make sure it wasn't integrated before I could look at it more closely.
> Neither the bug report or the PR describe the problem and its ramifications, only the solution.
> Can you elaborate on the conditions that lead to this. (and include them in the bug report).

@RogerRiggs , @plummercj , please see the additional discussion in the parent bug: https://bugs.openjdk.org/browse/JDK-8314823

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698629345

From dholmes at openjdk.org  Wed Aug 30 07:27:09 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Aug 2023 07:27:09 GMT
Subject: RFR: 8313718: make container at requires command configurable
In-Reply-To: <P_vZm7uXWzIs_rB6BlugOQNUPiz3uSijLaSG9kBbeOk=.3c6ca2da-bf9a-484c-a0e4-d2f7c525e9e3@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
 <P_vZm7uXWzIs_rB6BlugOQNUPiz3uSijLaSG9kBbeOk=.3c6ca2da-bf9a-484c-a0e4-d2f7c525e9e3@github.com>
Message-ID: <Mrm_wyjiRG-ulyMYBJtGUUgkMO3rUwqjoB-5WWIwrAA=.51a1256d-01de-4768-a530-0de35304ebe6@github.com>

On Wed, 30 Aug 2023 03:15:18 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().
>
> Hi David,
> 
> Thank you for taking a look at this change.  To answer your questions:
>  -- how is this supposed to work ? 
>  If user running the tests does not specify the newly introduced property things will work same as before. If user specifies -Djdk.test.container.requires.check.command then the specified command will be executed to check whether container testing can be performed on a given host/system. 
> 
> By default the code in VMProps.java runs "docker ps". With this change we could override it with any other relevant command, such as "podman version" or other type of container command.
> 
> -- What if they are really docker specific tests?
> I think our container tests should be fairly container-generic (or container agnostic), but need to check this. This raises a good question. Perhaps we should consider removing the at-requires check entirely, and rely on individual checks in individual tests. This will give us more flexibility, we run a specific check in each test and throw a jtreg.SkippedException upon failure. We already do some additional checks in each test, such as podman version, cgroups v1 vs v2, etc.
> 
> Let me know what you think.

@mseledts  My concern is that given:

map.put("docker.support", this::containerSupport)

we will now have a situation where `containerSupport` may indicate `podman` but that will enable `requires docker.support`. It seems to me that we need a range of potential checks where the generic `requires container.support` is for a test targeted to any container environment (though I wonder in that case what exactly it requires that the test depends on???); and we would then potentially need separate `docker.support`, `podman.support` if tests did things specific to those container environments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15475#issuecomment-1698636023

From duke at openjdk.org  Wed Aug 30 08:24:21 2023
From: duke at openjdk.org (Nikita Sakharin)
Date: Wed, 30 Aug 2023 08:24:21 GMT
Subject: RFR: 8314236: Overflow in Collections.rotate
In-Reply-To: <nL2GHQrXWUoaggM6Z7EbJ24lUiBq8vRYuQS3w7DcGew=.a53b3bef-cedb-4151-8132-a51a5518a394@github.com>
References: <SmRoYjYN8ph_k1mZBpd8tgWA9ogkTQj12T5SrBWbWWQ=.1825473e-4f62-4ca6-8166-617a1ffcfee3@github.com>
 <nL2GHQrXWUoaggM6Z7EbJ24lUiBq8vRYuQS3w7DcGew=.a53b3bef-cedb-4151-8132-a51a5518a394@github.com>
Message-ID: <iQhSeUuG3qMvoMGrHN18excoTtISugTolMLEMuVSedA=.2cb4ff69-7c15-4196-8d47-ffb84838c880@github.com>

On Mon, 14 Aug 2023 20:23:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `Collections.rotate` method contains a bug. This method throws IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way to reproduce:
>> 
>> final int size = (1 << 30) + 1;
>> final List<Byte> list = new ArrayList<>(size);
>> for (int i = 0; i < size; ++i)
>>     list.add((byte) 0);
>> Collections.rotate(list, size - 1);
>> 
>> Output:
>> ```Exception in thread "main" java.lang.IndexOutOfBoundsException: Index -2147483648 out of bounds for length 1073741825```
>> 
>> In that case private method `Collections.rotate1` will be called. And the line:
>> `i += distance;`
>> will cause overflow. I fixed this method and wrote a test for it.
>> 
>> I've signed the Oracle Contributor Agreement, but I don't have permission to raise a bug in the JDK Bug System.
>> 
>> Kindly ask you to raise a bug.
>
> Submitted: [JDK-8314236](https://bugs.openjdk.org/browse/JDK-8314236)
> 
> Please change the PR synopsis to: "8314236: Overflow in Collections.rotate".
> 
> Also go to https://github.com/nikita-sakharin/jdk/actions, and enable testing workflows.

@shipilev

Stuart Marks has approved my changes. You are reviewer for that PR too.

Could I kindly ask you to review the PR, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15270#issuecomment-1698712675

From sgehwolf at openjdk.org  Wed Aug 30 08:44:13 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 30 Aug 2023 08:44:13 GMT
Subject: RFR: 8311302: Allow for jlinking a custom runtime without packaged
 modules being present [v3]
In-Reply-To: <F7ZQIz60A5-3Tc9W0OfWcjEf4zrMn7RmL4G7ZZhYRpc=.bf783a37-1ead-4242-aa1c-ca77cb2efc94@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <nQlctZ3ctF4Wsn8cKLir4kn51OAqKChwyQ5Z-tPI-CM=.72a25210-016a-43a6-acca-5f3065e2bbba@github.com>
 <_uNwDdZONPRN_Ve3ePW4nK_qXvra5usXGjSa9Mx7QCw=.e5afa50b-feac-4dff-b79c-9f71e3006a7e@github.com>
 <F7ZQIz60A5-3Tc9W0OfWcjEf4zrMn7RmL4G7ZZhYRpc=.bf783a37-1ead-4242-aa1c-ca77cb2efc94@github.com>
Message-ID: <Slf5EP_Wk3f4MUVUMkF02UM4bacUSPhpJ9XV1axyY-c=.c5bfceeb-a8aa-4f68-aefc-7b7c3e1a3ae8@github.com>

On Tue, 29 Aug 2023 17:31:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @AlanBateman Gentle ping.
> 
> On my list, it's a lot to get through and a number of aspects to this that I think will require refinement and discussion.

Thanks for the heads-up! Your input is much appreciated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1698743940

From alanb at openjdk.org  Wed Aug 30 08:51:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Aug 2023 08:51:28 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <kl9YhXeptEVVdsRW3IdXc7JanAlofL-SOGCT1mJWfDg=.b03924c6-3519-407a-b62e-6880eb135d5f@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
 <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
 <d36ibn4WjxLfZUT50JG4685z3DJs2CnN-xjZ05HG_nA=.2318ca21-1b60-4105-9e65-db24b066f4e4@github.com>
 <kl9YhXeptEVVdsRW3IdXc7JanAlofL-SOGCT1mJWfDg=.b03924c6-3519-407a-b62e-6880eb135d5f@github.com>
Message-ID: <Vrv3F-LtwPbwk1fVOWkQwSgmMI9na399bp5cpwUFArQ=.24a9180c-d376-4580-a968-d8d8127a9842@github.com>

On Wed, 30 Aug 2023 00:37:26 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags

Just to add that Sorting.java has short and long run modes. The default when running with jtreg or make run-test is the short run so that it doesn't take too long.  It might be useful to try it without -shortrun to give the intrinsic a better work out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698754202

From aturbanov at openjdk.org  Wed Aug 30 09:11:14 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 30 Aug 2023 09:11:14 GMT
Subject: RFR: 8314263: Signed jars triggering Logger finder recursion and
 StackOverflowError [v7]
In-Reply-To: <uMzMHq9dsfai0UNdquL2lBY4AYdt1K9bG8Gaf2ErxG0=.1b432c29-d765-4270-9bf6-9d8324b0a826@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
 <uMzMHq9dsfai0UNdquL2lBY4AYdt1K9bG8Gaf2ErxG0=.1b432c29-d765-4270-9bf6-9d8324b0a826@github.com>
Message-ID: <YczmmOom_f8dvHZgvouUzwgXHubuFspIS9xrgRAKaqI=.51a8b523-e73a-45d5-a6da-fb51ddaf8b80@github.com>

On Tue, 29 Aug 2023 15:31:03 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Recursive initialization calls possible during loading of LoggerFinder service.  
>> 
>> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more tidying up in tests

test/jdk/java/lang/System/LoggerFinder/SignedLoggerFinderTest/SignedLoggerFinderTest.java line 214:

> 212:     private static Runnable runnableWithSleep(Supplier s, long sleep, String desc) {
> 213:         return () -> {
> 214:             while(!testComplete) {

Suggestion:

            while (!testComplete) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15404#discussion_r1309949039

From lkorinth at openjdk.org  Wed Aug 30 09:23:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 30 Aug 2023 09:23:55 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  fix static import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/f3418c80..27da7150

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

PR: https://git.openjdk.org/jdk/pull/15452

From lbourges at openjdk.org  Wed Aug 30 09:31:06 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 30 Aug 2023 09:31:06 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v8]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <1-wYAhYnWp_w8eVjA1aD8LuQzClFT0v9PGQIySpwxsA=.a15bae13-8662-40c6-81ee-8d0a9f2d4934@github.com>

> * improved  mixed insertion sort (makes whole sorting faster)
> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
> * improved merging sort for almost sorted data
> * optimized parallel sorting
> * improved step for pivot candidates and pivot partitioning
> * extended existing tests
> * added benchmarking JMH tests
> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'openjdk:master' into dpqs23
 - Merge branch 'dpqs23' of github.com:bourgesl/jdk-official into dpqs23
 - Merge branch 'openjdk:master' into dpqs23
 - simplified test to enable radix sort (improved sorting on period and shuffle data) + updated version to 22
 - fixed javadoc and size renamed to length for clarity
 - improved and more obvious max length test to always respect max heap memory footprint
 - Merge branch 'openjdk:master' into dpqs23
 - rewritten radix sort condition + fixed max buffer size
 - optimized radix sort heuristic
 - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
       * Optimized mixed insertion sort
       * Optimized insertion sort
       * Optimized Radix sort
       * Updated microbenchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/f7f7e11a..1d6d69d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=06-07

  Stats: 491505 lines in 7445 files changed: 306730 ins; 129358 del; 55417 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From stsypanov at openjdk.org  Wed Aug 30 09:58:26 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 30 Aug 2023 09:58:26 GMT
Subject: RFR: 8315351: Rid synchronization in PipedInputStream.close() in
 favour of benign race
Message-ID: <xnDhBIF33tLNxjT1w4mFuclrUaYd_XQcjaq7fUYStf4=.7a05a22b-4b5d-4d04-97de-3b6b48331ce2@github.com>

Assuming that the value written into `in` is always `-1` we can rid synchronized block in favour of guarding `in = - 1` with writing into volatile `closedByReader `:

public void close() throws IOException {
    closedByReader = true;
    synchronized (this) {
        in = -1;
    }
}

-->

public void close() throws IOException {
    in = -1;
    closedByReader = true;
}

-------------

Commit messages:
 - Drop redundant synchronization from PipedInputStream.close()

Changes: https://git.openjdk.org/jdk/pull/15486/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15486&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315351
  Stats: 6 lines in 1 file changed: 1 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15486.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15486/head:pull/15486

PR: https://git.openjdk.org/jdk/pull/15486

From lbourges at openjdk.org  Wed Aug 30 10:55:48 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 30 Aug 2023 10:55:48 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
Message-ID: <YOZ7-cCyDtKbLO_eWpoi2FD6GswBFO6Azaeln-m9a20=.638c4153-c55a-4846-ae8d-978f8fefbfff@github.com>

> * improved  mixed insertion sort (makes whole sorting faster)
> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
> * improved merging sort for almost sorted data
> * optimized parallel sorting
> * improved step for pivot candidates and pivot partitioning
> * extended existing tests
> * added benchmarking JMH tests
> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
> 
> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938

Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:

  updated comments (v23.08)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13568/files
  - new: https://git.openjdk.org/jdk/pull/13568/files/1d6d69d7..42e17e45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13568&range=07-08

  Stats: 123 lines in 1 file changed: 16 ins; 6 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/13568.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13568/head:pull/13568

PR: https://git.openjdk.org/jdk/pull/13568

From duke at openjdk.org  Wed Aug 30 11:07:10 2023
From: duke at openjdk.org (chenggwang)
Date: Wed, 30 Aug 2023 11:07:10 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
Message-ID: <eDTP9AzD5hmJZ4bWZz1UCAcFcVa_Nutg1kly_2JjzGQ=.91f6a641-8b91-494e-ad94-81584cc95e23@github.com>

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke at openjdk.org> wrote:

> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.

@vicente-romero-oracle  @albertnetymk  Hi, can you take a look at this PR for me?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1698950580

From vtewari at openjdk.org  Wed Aug 30 11:13:08 2023
From: vtewari at openjdk.org (Vyom Tewari)
Date: Wed, 30 Aug 2023 11:13:08 GMT
Subject: RFR: 8315351: Rid synchronization in PipedInputStream.close() in
 favour of benign race
In-Reply-To: <xnDhBIF33tLNxjT1w4mFuclrUaYd_XQcjaq7fUYStf4=.7a05a22b-4b5d-4d04-97de-3b6b48331ce2@github.com>
References: <xnDhBIF33tLNxjT1w4mFuclrUaYd_XQcjaq7fUYStf4=.7a05a22b-4b5d-4d04-97de-3b6b48331ce2@github.com>
Message-ID: <4eVDmbXGQhGLKCPXgZ6h_l3r7ZfifQxAgHs_U_G7o_w=.e1e5e872-796e-4e15-a0d3-b66409dafb93@github.com>

On Wed, 30 Aug 2023 09:49:39 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Assuming that the value written into `in` is always `-1` we can rid synchronized block in favour of guarding `in = - 1` with writing into volatile `closedByReader `:
> 
> public void close() throws IOException {
>     closedByReader = true;
>     synchronized (this) {
>         in = -1;
>     }
> }
> 
> -->
> 
> public void close() throws IOException {
>     in = -1;
>     closedByReader = true;
> }

src/java.base/share/classes/java/io/PipedInputStream.java line 448:

> 446:     @Override
> 447:     public void close() throws IOException {
> 448:         in = -1;

I am not sure if this is write thing to do, variable 'in' is accessed from "synchronized void receive(byte[] b, int off, int len)". What if  'close()' is called simultaneously ?.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15486#discussion_r1310102524

From asotona at openjdk.org  Wed Aug 30 11:27:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 30 Aug 2023 11:27:00 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v8]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <VVhIPSFD3qjFAVprdO_E9X13u6rtKl0yfx8meUlPPjQ=.2a035afe-caef-4576-9517-c811f56ab4cb@github.com>

> This pull request updates Classfile API snippets and examples and adds missing javadoc.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixing javadoc
 - fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/cd182173..c2c65575

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=06-07

  Stats: 424 lines in 4 files changed: 0 ins; 5 del; 419 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From duke at openjdk.org  Wed Aug 30 11:29:15 2023
From: duke at openjdk.org (Qing Xiao)
Date: Wed, 30 Aug 2023 11:29:15 GMT
Subject: Integrated: 8297777: Convert jdk.jlink StringSharingPlugin to use
 Class File API
In-Reply-To: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>
References: <rGYpQyHW7JwKf_dv15tIzVk2bwD0kBK8IjTk2Fk2uiY=.08272a50-c042-4c24-82c3-1885adb17d4a@github.com>
Message-ID: <uN0_0b_80eelYVSxZPI4_tlTlO4Ak-DvwEJnRtYn0cg=.7a017028-87e9-47a2-adc7-ce924f3d307f@github.com>

On Wed, 23 Aug 2023 23:50:29 GMT, Qing Xiao <duke at openjdk.org> wrote:

> Migrate jdk.jlink StringSharingPlugin to use new classfile library

This pull request has now been integrated.

Changeset: e29f0c2d
Author:    Qing Xiao <qing.xiao at oracle.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e29f0c2d75ed2592682ae718f46be2bb7d2363a4
Stats:     126 lines in 1 file changed: 12 ins; 54 del; 60 mod

8297777: Convert jdk.jlink StringSharingPlugin to use Class File API

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/15408

From msheppar at openjdk.org  Wed Aug 30 11:34:12 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 30 Aug 2023 11:34:12 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <wVUv1MM9_YCMellQujMDEORehLIrVzlkDgDgTiLM3f8=.0693ba3b-61bb-4af2-b680-dabb4ec099aa@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

I don't think  a name change is required. The method is createJavaProcessBuilder with a "list" of argurments and a builder is returned. As such, there is no inference, in the name, that test args will be propagated. Adding the additional java doc description should be sufficient to dispell any misconceptions. 
The createTestJvm is a misnomer as it returns a ProcessBulder rather than a Process, which is what I would expected from createTestJvm, without looking at its signature.

So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g.
createJavaProcessBuilder(List<String> command, boolean addTestOpts) { ... }

createProcessBuilderIgnoreJavaTestOpt(cmdArgs)  maps to createJavaProcessBuilder(cmdArgs, false)

createTestJvm(cmdArgs) maps to createJavaProcessBuilder(cmdArgs, true)

But this is a lot more work.

alternatively change createTestJvm to createTestJavaProcessBuilder  or createJavaProcessBuilderAddTestOpts

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1698985460

From lancea at openjdk.org  Wed Aug 30 11:48:20 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 30 Aug 2023 11:48:20 GMT
Subject: Integrated: 8315117: Update Zlib Data Compression Library to Version
 1.3
In-Reply-To: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
References: <y_PfKJSTs5UJ0_fLUgQ3XnM3Xg3MNc1FqnV5eHwkZYg=.ecd33228-cfc6-4c49-a9d4-6b0769cc492e@github.com>
Message-ID: <2zock1rRcHM3WV1wxgq9l_0FYVQbPY8UbkHkbQO31SM=.adbcfc60-0509-4cd2-8f39-f916128de4d3@github.com>

On Mon, 28 Aug 2023 16:31:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> Please review this PR which updates zlib from 1.2.13 to 1.3 in openJDK
> 
> The [Zlib Data Compression Library](https://github.com/madler/zlib ) has released Zlib 1.3 on August 18, 2023.
> 
> There are a [small number of updates](https://github.com/madler/zlib/compare/v1.2.13...master ) between 1.2.13 and 1.3 
> 
> Mach5 tiers1-6 have run clean as do the JCK tests

This pull request has now been integrated.

Changeset: 6701eba7
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6701eba736ac51db4b0d0d7db6c7bdd4ae8a1c16
Stats:     2075 lines in 25 files changed: 532 ins; 1006 del; 537 mod

8315117: Update Zlib Data Compression Library to Version 1.3

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15453

From duke at openjdk.org  Wed Aug 30 12:05:10 2023
From: duke at openjdk.org (chenggwang)
Date: Wed, 30 Aug 2023 12:05:10 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
Message-ID: <ifgJ-JcckmvodPeQvhD6fFKKYX2isP-SvZISxUAk5m0=.9ddb0a21-818c-449e-ae67-66944503cab7@github.com>

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke at openjdk.org> wrote:

> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.

Hi Can anyone help me to review this PR @sormuras @asotona or any other reviewer?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1699032171

From asotona at openjdk.org  Wed Aug 30 12:34:44 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 30 Aug 2023 12:34:44 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v9]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <igaueSpuNdxdrS7TV7i6CNaR9scCF7rYDpZ2z8FO5lY=.cc87bc47-5640-46e8-b7f4-a20b97f2964b@github.com>

> This pull request updates Classfile API snippets and examples and adds missing javadoc.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/c2c65575..0a333e18

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=07-08

  Stats: 118 lines in 10 files changed: 0 ins; 0 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From asotona at openjdk.org  Wed Aug 30 12:39:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 30 Aug 2023 12:39:45 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v10]
In-Reply-To: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
Message-ID: <7slK1NkVgYdrdZG918Ui70SsEUUXvULX3WT1O3sRrCw=.a12c45e8-3c6e-4643-9a30-f88353701440@github.com>

> This pull request updates Classfile API snippets and examples and adds missing javadoc.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14968/files
  - new: https://git.openjdk.org/jdk/pull/14968/files/0a333e18..f4f74cac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14968&range=08-09

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14968/head:pull/14968

PR: https://git.openjdk.org/jdk/pull/14968

From coffeys at openjdk.org  Wed Aug 30 12:58:32 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 30 Aug 2023 12:58:32 GMT
Subject: Integrated: 8314263: Signed jars triggering Logger finder recursion
 and StackOverflowError
In-Reply-To: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
References: <8YmLHAhvLtSxFloIMrxpzyUw2b8mEIHeEgZXiW2SDG4=.4efcfdf0-1431-46f2-9177-77822012a5f7@github.com>
Message-ID: <2O00-B2ijfmFt6F0BuDLHlM51L1OLVISHxD553YnFIk=.a63d6873-392b-461d-a6d7-c01fabd4b251@github.com>

On Wed, 23 Aug 2023 15:41:16 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Recursive initialization calls possible during loading of LoggerFinder service.  
> 
> This fix detects the recursive call and returns a temporary LoggerFinder that is backed by a lazy logger. Automated test case developed to simulate loading of an external LoggerFinder service while also having other threads poke System.getLogger during this framework initialization.

This pull request has now been integrated.

Changeset: 7daae1fb
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7daae1fb4267f92b38f0152611d69b7b89691087
Stats:     818 lines in 12 files changed: 790 ins; 3 del; 25 mod

8314263: Signed jars triggering Logger finder recursion and StackOverflowError

Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/15404

From alanb at openjdk.org  Wed Aug 30 13:24:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Aug 2023 13:24:10 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <ifgJ-JcckmvodPeQvhD6fFKKYX2isP-SvZISxUAk5m0=.9ddb0a21-818c-449e-ae67-66944503cab7@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
 <ifgJ-JcckmvodPeQvhD6fFKKYX2isP-SvZISxUAk5m0=.9ddb0a21-818c-449e-ae67-66944503cab7@github.com>
Message-ID: <hti5Q1JV6m_cXFxOmKyIKyW5sI9iXmCysvVfeMCtWjo=.582baaed-e7db-4754-a199-1012b266b441@github.com>

On Wed, 30 Aug 2023 12:02:12 GMT, chenggwang <duke at openjdk.org> wrote:

> Hi Can anyone help me to review this PR @sormuras @asotona or any other reviewer?

I think you first need to make a case for changing the CyclicBarrier API as opposed to dealing with the phases in your BarrierAction or using the Phaser API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1699162700

From duke at openjdk.org  Wed Aug 30 14:48:14 2023
From: duke at openjdk.org (chenggwang)
Date: Wed, 30 Aug 2023 14:48:14 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <hti5Q1JV6m_cXFxOmKyIKyW5sI9iXmCysvVfeMCtWjo=.582baaed-e7db-4754-a199-1012b266b441@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
 <ifgJ-JcckmvodPeQvhD6fFKKYX2isP-SvZISxUAk5m0=.9ddb0a21-818c-449e-ae67-66944503cab7@github.com>
 <hti5Q1JV6m_cXFxOmKyIKyW5sI9iXmCysvVfeMCtWjo=.582baaed-e7db-4754-a199-1012b266b441@github.com>
Message-ID: <9zlnzfpdY9WtcVaQE9LWNlulNImxnV9t5tVY8NCGJtw=.a2def79e-9a91-44ea-bc29-77a33d6cf7a1@github.com>

On Wed, 30 Aug 2023 13:20:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Hi Can anyone help me to review this PR @sormuras @asotona or any other reviewer?
> 
> I think you first need to make a case for changing the CyclicBarrier API as opposed to dealing with the phases in your BarrierAction or using the Phaser API.

Hi @AlanBateman?First thank you for coming to review, in this case use:
For example, the U.S. Army 'Gordon Sullivan Cup'.
Five tanks competing.
1. The first round is for artillery strikes against targets.
2. Second round of anti-aircraft machine gun targets.
3. The third round is minefield racing.

It takes five threads to represent five tanks in a race,
? When all five threads reach the first Barrier, execute the first barrierCommand to score and rank the artillery firing.
? Then continue the second round of anti-aircraft machine gun competition, five threads have reached the second Barrier, and the anti-aircraft machine gun score is determined and ranked.
? Finally, race in the tank minefield, reach the third Barrier, score and rank

The above three rounds only need to use one CyclicBarrier, because it can open the next generation at the end of each generation, so the CyclicBarrier can be reused, but the barrierCommand is final. Passing barrierCommand when a CyclicBarrier object is created through the constructor is an immutable object that cannot be used with a new barrierCommand every generation. But artillery attacks, anti-aircraft machine guns, minefield scoring rules are different, we need a variable barrierCommand

With the Phaser API, I'm not talking about using it. Instead, someone commented under my bugreport on using Phaser instead of CyclicBarrier. I mention Phaser here, feeling that it can dynamically add and subtract threads, but it doesn't fit my problem with this five-tank race

So you can ignore the phaser I mentioned and go all out to review the five tank races, each scoring criteria is different, that is, barrierCommand should be able to change, but the current version of barrierCommand is final and immutable

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1699323655

From duke at openjdk.org  Wed Aug 30 15:06:24 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 30 Aug 2023 15:06:24 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <Vrv3F-LtwPbwk1fVOWkQwSgmMI9na399bp5cpwUFArQ=.24a9180c-d376-4580-a968-d8d8127a9842@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
 <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
 <d36ibn4WjxLfZUT50JG4685z3DJs2CnN-xjZ05HG_nA=.2318ca21-1b60-4105-9e65-db24b066f4e4@github.com>
 <kl9YhXeptEVVdsRW3IdXc7JanAlofL-SOGCT1mJWfDg=.b03924c6-3519-407a-b62e-6880eb135d5f@github.com>
 <Vrv3F-LtwPbwk1fVOWkQwSgmMI9na399bp5cpwUFArQ=.24a9180c-d376-4580-a968-d8d8127a9842@github.com>
Message-ID: <TVMtttm0BWiUc7XazJiv9a4cUAQMmJM2PYQhcYWMkL0=.062f94cf-2d63-474f-aea1-f7148a7bed30@github.com>

On Wed, 30 Aug 2023 08:48:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags
> 
> Just to add that Sorting.java has short and long run modes. The default when running with jtreg or make run-test is the short run so that it doesn't take too long. It might be useful to try it without -shortrun to give the intrinsic a better work out.

Hi Alan,
The tests in Sorting.java were run in both short and long modes. The screenshot showing the usage of intrinsics was from long mode run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1699355402

From rriggs at openjdk.org  Wed Aug 30 15:10:13 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Aug 2023 15:10:13 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <QhskrdnUTvPoXQkFzEXv6cXGiyHNCtGZ4NiHqz5SO_s=.7d87a087-bf3a-4ae8-8aa4-999220667db7@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

In the context of the goal is to declaratively identify tests that do or do not benefit from additional test flags renaming the `createjavaProcessBuilder` method does not further that goal.

The method name and javadoc of `createjavaProcessBuilder` do not imply that the test options are consulted or used; it only says it creates a ProcessBuilder, and does not promise or document more than that.  The javadoc should probably describe the use of the the three properties that modify the way that the java is launched.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699362435

From duke at openjdk.org  Wed Aug 30 15:14:28 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 30 Aug 2023 15:14:28 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <Vrv3F-LtwPbwk1fVOWkQwSgmMI9na399bp5cpwUFArQ=.24a9180c-d376-4580-a968-d8d8127a9842@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H2sgaUoV197EpUf2txboD9BLRP-xM5e6qJ_XbeCAo3A=.7379c3d4-65a8-4b1a-9e43-0d9b0f82d698@github.com>
 <jROwjEN-rZG9JMPtGHdZ7nbu6ZkXxYQd2BUcZ8mdF1c=.32354c51-165f-4e94-808a-25fa758727f0@github.com>
 <d36ibn4WjxLfZUT50JG4685z3DJs2CnN-xjZ05HG_nA=.2318ca21-1b60-4105-9e65-db24b066f4e4@github.com>
 <kl9YhXeptEVVdsRW3IdXc7JanAlofL-SOGCT1mJWfDg=.b03924c6-3519-407a-b62e-6880eb135d5f@github.com>
 <Vrv3F-LtwPbwk1fVOWkQwSgmMI9na399bp5cpwUFArQ=.24a9180c-d376-4580-a968-d8d8127a9842@github.com>
Message-ID: <vIII1mSAEN1ci3KljmdPs1i12XGtc12TuL4cwjrHIuc=.c4a42ef6-3ebf-4e36-992f-4d2f98e1c9ec@github.com>

On Wed, 30 Aug 2023 08:48:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > > Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java
>>> > > The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files
>>> > 
>>> > 
>>> > Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic without additional flags? @vamsi-parasa can you check?
>>> 
>>> Sure Vladimir (@vnkozlov). Will check if test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags and let you know.
>> 
>> Hi Vladimir,
>> Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags as shown in the output snapshot below:
>> ![image](https://github.com/openjdk/jdk/assets/23087109/a2d4edb1-9377-4f92-bed2-3e40bc5a7654)
>
>> Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags
> 
> Just to add that Sorting.java has short and long run modes. The default when running with jtreg or make run-test is the short run so that it doesn't take too long.  It might be useful to try it without -shortrun to give the intrinsic a better work out.

> @AlanBateman If it helps, the changes made by @vamsi-parasa to DualPivotQuickSort.java don't change the logic as written in Java. They only carve out the functionality into separate Java methods retaining the meaning exactly as before. These Java methods are then optimized through a stub.

Hi Alan,

As Sandhya (@sviswa7) mentioned, this PR does not make any logic changes to the DualPivotQuickSort.java. 

The code was refactored to separate out the partitioning logic (dual pivot and single pivot) into separate methods. These methods are being intrinsified using AVX512 to do vectorized partitioning preserving the logic of Java side. Similarly, the methods to sort small arrays (insertionSort/mixedInsertionSort) are being intrinsified as well to use AVX512 sort while preserving the logic on Java side.

Could you please go through the changes and provide your comments and suggestions?

Thanks,
Vamsi

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1699367300

From dfuchs at openjdk.org  Wed Aug 30 15:20:20 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 30 Aug 2023 15:20:20 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
Message-ID: <CFFME4QkjaLcnB5JO9F_1w-e2ctxbDu6wcfYnhWrjyI=.a445437c-e004-4311-b2df-6e854e9d7ea9@github.com>

On Tue, 29 Aug 2023 20:51:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8268829: Provide an optimized way to walk the stack with Class object only
>> 
>> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
>> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
>> like logging may only interest in the Class object but not the method name nor the BCI,
>> for example, filters out its implementation classes to find the caller class.  It's
>> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
>> 
>> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
>> can be used instead and such stack walker will save the overhead of extracting the method information
>> and the memory used for the stack walking.
>> 
>> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
>> This provides a simple way for existing code, for example logging frameworks, to take advantage of
>> this enhancement with the least change as it can keep the existing function for traversing
>> `StackFrame`s.
>> 
>> For example: to find the first caller filtering a known list of implementation class,
>> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
>> 
>> 
>>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>>      Optional<Class<?>> callerClass = walker.walk(s ->
>>              s.map(StackFrame::getDeclaringClass)
>>               .filter(Predicate.not(implClasses::contains))
>>               .findFirst());
>> 
>> 
>> If method information is accessed on the `StackFrame`s produced by this stack walker such as
>> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
>> 
>> #### Javadoc & specdiff
>> 
>> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
>> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
>> 
>> #### Alternatives Considered
>> One alternative is to provide a new API:
>> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
>> 
>> In this case, the caller would need to pass a function that takes a stream
>> of `Class` object instead of `StackFrame`.  Existing code would have to
>> modify calls to the `walk` method to `walkClass` and the function body.
>> 
>> ### Implementation Details
>> 
>> A `StackWalker` configured with `DROP_METHOD_INFO` ...
>
> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - update mode to be int rather than long
>  - update tests
>  - Review feedback on javadoc

src/java.base/share/classes/java/lang/StackStreamFactory.java line 694:

> 692:             // no method information is available; should just filter
> 693:             // "Continuation::yield0".
> 694:             return classFrames[index].declaringClass() == Continuation.class;

Is that going to be an issue if by chance the frame is some other method on continuation?
Could that comment be clarified a bit?
I am not sure what is meant by `should just filter "Continuation::yield0"`; Does it mean: that's what we should do, but we can't, so we filter any method on `Continuation` instead? Or does it mean: the only method we expect here if declaringClass is `Continuation` is `yield0`, so the line below should only filter out `Continuation::yield0`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310422354

From alanb at openjdk.org  Wed Aug 30 15:34:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 30 Aug 2023 15:34:21 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <CFFME4QkjaLcnB5JO9F_1w-e2ctxbDu6wcfYnhWrjyI=.a445437c-e004-4311-b2df-6e854e9d7ea9@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
 <CFFME4QkjaLcnB5JO9F_1w-e2ctxbDu6wcfYnhWrjyI=.a445437c-e004-4311-b2df-6e854e9d7ea9@github.com>
Message-ID: <bJyMJmX8sMzTpoVkexa0o6bHIEOuUnGGNG71CBjUNCg=.bdc4364a-968a-4c15-9aee-0e9e4cb995ca@github.com>

On Wed, 30 Aug 2023 15:03:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - update mode to be int rather than long
>>  - update tests
>>  - Review feedback on javadoc
>
> src/java.base/share/classes/java/lang/StackStreamFactory.java line 694:
> 
>> 692:             // no method information is available; should just filter
>> 693:             // "Continuation::yield0".
>> 694:             return classFrames[index].declaringClass() == Continuation.class;
> 
> Is that going to be an issue if by chance the frame is some other method on continuation?
> Could that comment be clarified a bit?
> I am not sure what is meant by `should just filter "Continuation::yield0"`; Does it mean: that's what we should do, but we can't, so we filter any method on `Continuation` instead? Or does it mean: the only method we expect here if declaringClass is `Continuation` is `yield0`, so the line below should only filter out `Continuation::yield0`?

The Continuation frames around enter and yielding are hidden. Continuation.yield0 was the only frame that required special handling here, it may need to be re-checked to see if it is still required when using SHOW_HIDDEN_FRAMES.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310462843

From rriggs at openjdk.org  Wed Aug 30 16:01:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Aug 2023 16:01:11 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <H9F_dHHhUBiUCjutO9FEtmFSZ2Ayp9n-B9TFNNDAWFk=.88bc4463-d533-4abb-99ab-87f583a6150b@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
 <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
 <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>
 <PAAwyDFEoXNEw3LDkKa6CqSJxpcfks7qfx4f-0T0oE0=.b60e7d57-0170-4b85-ba50-028b2cc45190@github.com>
 <H9F_dHHhUBiUCjutO9FEtmFSZ2Ayp9n-B9TFNNDAWFk=.88bc4463-d533-4abb-99ab-87f583a6150b@github.com>
Message-ID: <F5Zhgxv8Uxml8va7ddyoAb0FJmdBWxdjHBIj6DF5024=.ce105193-dbaf-4cf4-8e21-6db89c937fbe@github.com>

On Tue, 29 Aug 2023 08:30:10 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> It seems that ProcessHandle.info()  returns **DOMAIN/USERNAME** on Windows but System.getProperty("user.name") only the **USERNAME**.
>> You can get **DOMAIN** and **USERNAME** on **Windows** by calling:
>> com.sun.security.auth.module.NTSystem NTSystem = new com.sun.security.auth.module.NTSystem();
>> String user = NTSystem.getName();
>> String domain = NTSystem.getDomain();
>
> Yes, I think using System.getProperty("user.name") is brittle as well. If we'd use `com.sun.security.auth.module.NTSystem`, we would introduce the dependency to another module - `jdk.security.auth`. Not sure, whether this is a good option.

The system environment has the domainname and the username.

String username = (System.getenv("USERDOMAIN") + "/" + System.getenv("USERNAME")).toLowerCase(Locale.ROOT);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1310499879

From duke at openjdk.org  Wed Aug 30 16:05:26 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Wed, 30 Aug 2023 16:05:26 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v29]
In-Reply-To: <qAwCU58umL8A4l8Gj38UTHvTL6G7HnZC2FMx_tatFA4=.c81b66d1-e2ef-4401-a539-7141ec8f2e17@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <ix7J1e-vUfZnxhVgqwsTt22Gja6ytuWpFML_KDoqw2U=.2f0c6051-483e-4fb2-9b38-30d94170a1ff@github.com>
 <MBupxle1ORd-0bpA-oGX2eJQInVHUMg9I7vJqVuJDU4=.fcce4eca-992a-43ef-a07e-42e4bbc8575d@github.com>
 <LXnG2u6tPSlNSzw8NtSa0vdyWcNFjGezeCdFkLL9L-o=.f6b20143-fc96-4148-9aee-f28931074e19@github.com>
 <gnJRko8Ivf2ptENdp38Ghz22tXEpR2LtF4fVvnrkTPk=.ec080953-9439-4e08-92e1-995463563191@github.com>
 <2s4hZgw7KRQ5AoYzTZ3-8BS5V6JAslioJXeil_jvfQA=.fb1a1a31-8726-494b-b77c-a66565a963da@github.com>
 <f1Hoc-w_LUPLaN57BM-EW8w96ZH__IyjRBPhs2rLYoE=.076578a6-df82-490d-af05-7e9cb1e7208a@github.com>
 <qAwCU58umL8A4l8Gj38UTHvTL6G7HnZC2FMx_tatFA4=.c81b66d1-e2ef-4401-a539-7141ec8f2e17@github.com>
Message-ID: <13CHm6P2gQzkmUNYGXDlwXtnXjx0_NUnzTKHC2FiMJ4=.af15a026-e777-4510-8f18-3668e5007c88@github.com>

On Tue, 29 Aug 2023 20:23:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The shared library approach is being followed currently as an initial implementation to demonstrate the value of AVX512 sorting. This will be followed up in future with support for Windows as well. 
>> If it is ok with you, the shared library approach could be pursued for now to be later replaced with specialized assembly stubs (which are agnostic to OS and compiler) when AVX512 sort is enabled for Windows. Please let us know.
>
> I am okay with such incremental approach. Please, file RFE to replace library with stubs in a future (it could be still separate library but with assembler code).

Thank you Vladimir!  Please see the link to Windows RFE to replace library with assembly stubs here : https://bugs.openjdk.org/browse/JDK-8315382

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1310504519

From mchung at openjdk.org  Wed Aug 30 16:32:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 30 Aug 2023 16:32:16 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <HLRQsz7QLRGMxteBZfOJ3F5iyJef7DFe5RWTwsecldM=.5e9b9cef-5fa5-446d-bf7e-cbc9b5a5f042@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
 <HLRQsz7QLRGMxteBZfOJ3F5iyJef7DFe5RWTwsecldM=.5e9b9cef-5fa5-446d-bf7e-cbc9b5a5f042@github.com>
Message-ID: <pevI_jE0H6Fiai8KZmsfCUZIJ08j4OYgZkV40iqRdio=.3996d9ed-0f8b-4856-bf13-43f0037e2e83@github.com>

On Wed, 30 Aug 2023 07:09:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The updated proposal/javadoc looks good, just in two minds on whether the overload with the varargs should be added. The Set.of factory methods make is really easy to use the existing getInstance(Set) method.

Indeed, Set.of factory methods are easy to use.   I'm okay with taking it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1699497438

From lkorinth at openjdk.org  Wed Aug 30 17:13:53 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 30 Aug 2023 17:13:53 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <3xqrbByJLBJTDN1-C_aG0wwe6PFy09-tMyL0TwEn4Gc=.88dbe2a2-ad5d-4545-ab30-4a9e5312641f@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

I have some ideas that I will work on that might lead to a new proposal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699542111

From naoto at openjdk.org  Wed Aug 30 17:22:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Aug 2023 17:22:14 GMT
Subject: RFR: 6333341: [BI] Doc: java.text.BreakIterator class
 specification is unclear [v2]
In-Reply-To: <0i_hISwf4CoARewrpJc4V79Iob6YzKjTCafd-Q6VYRQ=.548fe24a-a316-47ac-9952-ee17903cfcba@github.com>
References: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
 <0i_hISwf4CoARewrpJc4V79Iob6YzKjTCafd-Q6VYRQ=.548fe24a-a316-47ac-9952-ee17903cfcba@github.com>
Message-ID: <PwVifvZX1vbtLymG1654ubU_0Ky3u0GD4QlRQeAldHc=.c49696f3-6903-4dc3-a6bb-d3417d73bfe6@github.com>

On Tue, 29 Aug 2023 20:09:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR ](https://bugs.openjdk.org/browse/JDK-8314974)which clarifies behavior for BreakIterator instances when text has not been set.
>> 
>> For example,  calling `BreakIterator.getWordInstance().next();` has an ambiguous result.
>> A boundary searching operation was called but no text was supplied. Is the result an exception, 0, -1 (BreakIterator.DONE), or something else? In reality, the operation will be performed on any empty string.
>> 
>> 
>> This change makes it apparent that failing to set the text will cause the BreakIterator instance to default to a `StringCharacterIterator` with an empty string (equivalent to calling setText("")).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use implNote tag

LGTM. Reviewed the CSR as well.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15422#pullrequestreview-1603171201

From stefank at openjdk.org  Wed Aug 30 17:40:33 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 30 Aug 2023 17:40:33 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <VAAsfW_V1GEfQezmwBQwvXa3svN5cMzanUtpk4W4kv8=.6ff00b4d-01f4-4607-a7be-b17ae9669ae3@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

>From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't.

I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function.

I also think it is too obscure that functions with *Test* in the name prepend the extra test options, and those without *Test* don't, so I'd like to get rid of that convention. 

I wouldn't be opposed to a change that:
* Keeps the `createJavaProcessBuilder` name
* Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
* Renames `executeTestJvm` to `executeJavaPrependTestOpts`
* Removes `createTestJava`
* Removes `executeTestJava`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1699588853

From mchung at openjdk.org  Wed Aug 30 18:09:34 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 30 Aug 2023 18:09:34 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <bJyMJmX8sMzTpoVkexa0o6bHIEOuUnGGNG71CBjUNCg=.bdc4364a-968a-4c15-9aee-0e9e4cb995ca@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
 <CFFME4QkjaLcnB5JO9F_1w-e2ctxbDu6wcfYnhWrjyI=.a445437c-e004-4311-b2df-6e854e9d7ea9@github.com>
 <bJyMJmX8sMzTpoVkexa0o6bHIEOuUnGGNG71CBjUNCg=.bdc4364a-968a-4c15-9aee-0e9e4cb995ca@github.com>
Message-ID: <7tOxwC_i6O7yPZUvq_7g2ocDI1KOERbjd_mblthaS_A=.a699200f-a696-4db4-b1c4-1af257c7ccee@github.com>

On Wed, 30 Aug 2023 15:31:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StackStreamFactory.java line 694:
>> 
>>> 692:             // no method information is available; should just filter
>>> 693:             // "Continuation::yield0".
>>> 694:             return classFrames[index].declaringClass() == Continuation.class;
>> 
>> Is that going to be an issue if by chance the frame is some other method on continuation?
>> Could that comment be clarified a bit?
>> I am not sure what is meant by `should just filter "Continuation::yield0"`; Does it mean: that's what we should do, but we can't, so we filter any method on `Continuation` instead? Or does it mean: the only method we expect here if declaringClass is `Continuation` is `yield0`, so the line below should only filter out `Continuation::yield0`?
>
> The Continuation frames around enter and yielding are hidden. Continuation.yield0 was the only frame that required special handling here, it may need to be re-checked to see if it is still required when using SHOW_HIDDEN_FRAMES.

Looks like the filtering is not needed.   https://bugs.openjdk.org/browse/JDK-8304919 marked those methods with `@Hidden`.   If `SHOW_HIDDEN_FRAMES` is set, those frames should be included unless there is a reason not to.  

I will update the patch to remove the filtering in both `StackFrameBuffer` and `ClassFrameBuffer`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15370#discussion_r1310645327

From naoto at openjdk.org  Wed Aug 30 18:47:27 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Aug 2023 18:47:27 GMT
Subject: RFR: 8314604: j.text.DecimalFormat behavior regarding patterns is
 not clear [v2]
In-Reply-To: <goNwkmTiYeJgf4xC7t97bYOIjA9Oe7uYsesAN89hc_Y=.01510cd4-f6ba-4b81-b8a1-6c6e29a74e9c@github.com>
References: <4IjlWcNJRJ3nFa3cWecEbIZu8JE6n2MswgQyx_fbYP8=.0686c00f-94ee-499e-b3eb-759f6ad75d55@github.com>
 <goNwkmTiYeJgf4xC7t97bYOIjA9Oe7uYsesAN89hc_Y=.01510cd4-f6ba-4b81-b8a1-6c6e29a74e9c@github.com>
Message-ID: <UxB_-Dc1Ba7_Mx3KFQK1OKtuk6mM30ETfv24Sn0oyQI=.c6ade1a2-a6c3-4103-84a9-3f02b6611045@github.com>

On Tue, 29 Aug 2023 21:42:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314607) which clarifies the behavior of patterns  in regards to the max integer digits in j.text.DecimalFormat.
>> 
>> The current specification (of `applyPattern`) states that patterns do not set the value of max integer digits. This is incorrect, these methods/constructors do set a value for the max integer digits. If the pattern is in scientific notation, the max integer digits value is derived from the pattern. Otherwise, the pattern is ignored, and the limit is set to `Integer.MAX_VALUE`.
>> 
>> See below,
>> 
>> DecimalFormat df = new DecimalFormat();
>> df.applyPattern("000.000E0");
>> df.getMaximumIntegerDigits(); //  ==> 3
>> df.applyPattern("000.000");
>> df.getMaximumIntegerDigits(); // ==> 2147483647
>> 
>> DecimalFormat df = new DecimalFormat("000.000");
>> df.getMaximumIntegerDigits(); // ==> 2147483647
>> DecimalFormat df = new DecimalFormat("000.000E0");
>> df.getMaximumIntegerDigits(); // ==> 3
>> 
>> 
>> Method descriptions should be fixed, and the relevant constructors need to mention the behavior as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments: Non sci notation first. Link to Scientific Notation section

Thanks for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15349#pullrequestreview-1603303466

From duke at openjdk.org  Wed Aug 30 19:15:33 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 30 Aug 2023 19:15:33 GMT
Subject: RFR: 8315383: jlink SystemModulesPlugin incorrectly parses the options
Message-ID: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>

Fixes https://bugs.openjdk.org/browse/JDK-8315383

-------------

Commit messages:
 - 8315383: jlink SystemModulesPlugin incorrectly parses the options

Changes: https://git.openjdk.org/jdk/pull/15495/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15495&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315383
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15495/head:pull/15495

PR: https://git.openjdk.org/jdk/pull/15495

From mchung at openjdk.org  Wed Aug 30 19:33:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 30 Aug 2023 19:33:26 GMT
Subject: RFR: 8315383: jlink SystemModulesPlugin incorrectly parses the
 options
In-Reply-To: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>
References: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>
Message-ID: <kptcFzTf30rbIGf1mTzZS22OouvYONP0rmHzZqrBdgU=.fb6a9bea-2e30-4e9d-92c1-3dadfd5b7350@github.com>

On Wed, 30 Aug 2023 19:07:53 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fixes https://bugs.openjdk.org/browse/JDK-8315383

Looks good.   Thanks for catching this.

There are a few unused imports in JLinkDedupTestBatchSizeOne.java.  Can you remove them as you are in that file?

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15495#pullrequestreview-1603366535

From vpetko at openjdk.org  Wed Aug 30 20:34:01 2023
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 30 Aug 2023 20:34:01 GMT
Subject: RFR: 8314491: Linux: jexec launched via PATH fails to find java
 [v7]
In-Reply-To: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
References: <tVY5zhCURM79yI73dWhnAMD_Z3rPEWiNWyStRJrmwAs=.45e1b439-b498-478b-a523-c5896914c61a@github.com>
Message-ID: <HJwkHUKy5N6Wfx9HXfoPBlPem6UwhAw7b53aX7mHMsU=.20644032-aba9-4f1d-97a7-78e688180d17@github.com>

> 8314491: Linux: jexec launched via PATH fails to find java

Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into 8314491-jexec-resolve-symlink
 - Merge branch 'master' into 8314491-jexec-resolve-symlink
 - declare error in-place
 - remove unused imports
 - Review comment: use /proc/self/exe as the backup option
 - Merge branch 'master' into 8314491-jexec-resolve-symlink
 - correct copyright statement
 - Use /proc/self/exec to identify path to the executable.
 - Create failing test for jexec in PATH issue

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15343/files
  - new: https://git.openjdk.org/jdk/pull/15343/files/5354ceba..be995fc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15343&range=05-06

  Stats: 11416 lines in 245 files changed: 7461 ins; 2137 del; 1818 mod
  Patch: https://git.openjdk.org/jdk/pull/15343.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15343/head:pull/15343

PR: https://git.openjdk.org/jdk/pull/15343

From naoto at openjdk.org  Wed Aug 30 20:37:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Aug 2023 20:37:42 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v5]
In-Reply-To: <48xqGNO8NgBG4Jpewau111hFGsUTjGCroIwy9GPVTGs=.3ea065d6-bde6-45d7-b5aa-a75237c48724@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <KsHPJN-4NOFaU1Tu8qSVJdkO__GHD0J07cZNiHrBkJc=.0d58d5ce-2bfc-4dbc-b17e-c3756e887b35@github.com>
 <48xqGNO8NgBG4Jpewau111hFGsUTjGCroIwy9GPVTGs=.3ea065d6-bde6-45d7-b5aa-a75237c48724@github.com>
Message-ID: <o4AaVcfdcs2lQ1BzPh_IuYoX4vnbNt1kDi5bEAIvlbA=.ce0497fa-4b36-4c1a-aaa1-26e14b7fe5da@github.com>

On Wed, 30 Aug 2023 06:40:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
>>  - small cleanup
>>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>>  - Update ReferencedKeyTest.java
>>  - Simple versions of create
>>  - Add flag for reference queue type
>>  - Merge branch 'master' into 8310913
>>  - Update to use VirtualThread friendly stale queue.
>>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>>  - Remove warning tied to String Templates
>>  - ... and 19 more: https://git.openjdk.org/jdk/compare/7ba8c69a...0e435898
>
> src/java.base/share/classes/sun/util/locale/BaseLocale.java line 96:
> 
>> 94: 
>> 95:     // Non-normalized to normalized BaseLocale cache for saving costly normalizations
>> 96:     private static final Map<BaseLocale, BaseLocale> CACHE = ReferencedKeyMap.create(true, ConcurrentHashMap::new);
> 
> You can now simply use a `ReferencedKeySet<BaseLocale>` and call [`intern(T, UnaryOperator<T>)`](https://github.com/openjdk/jdk/blob/ce2a7ea40a22c652e5f8559c91d5eea197e2d708/src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java#L202) to cache a normalized variety computed from a non-normalized base.

I need to double-check that it won't cause performance regression, will be visiting this later.

> test/jdk/jdk/internal/util/ReferencedKeyTest.java line 1:
> 
>> 1: /*
> 
> Is the test removal intentional?

Ah, thanks. My bad for unintentionally removing the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1310790705
PR Review Comment: https://git.openjdk.org/jdk/pull/14404#discussion_r1310790739

From mchung at openjdk.org  Wed Aug 30 21:30:09 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 30 Aug 2023 21:30:09 GMT
Subject: RFR: 8315413: Remove special filtering of Continuation.yield0 in
 StackWalker
Message-ID: <-xgvLCocJ3avyqm5wMbctIWgz1wUA6akr07oGAFYtIw=.f744e034-54d9-4a84-8ab2-8bab26078fcd@github.com>

Loom added a special filtering of Continuation.yield0 in stack walker.  After the initial implementation, JDK-8304919 marks the yielding and entering methods with `@Hidden` and hidden frames are filtered by stack walker by default.   With `@Hidden` the special filtering should not be needed.

-------------

Commit messages:
 - 8315413: Remove special filtering of Continuation.yield0 in StackWalker

Changes: https://git.openjdk.org/jdk/pull/15498/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315413
  Stats: 33 lines in 4 files changed: 0 ins; 24 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15498/head:pull/15498

PR: https://git.openjdk.org/jdk/pull/15498

From naoto at openjdk.org  Wed Aug 30 22:35:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 30 Aug 2023 22:35:43 GMT
Subject: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v6]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Restored the test
 - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
 - small cleanup
 - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
 - Update ReferencedKeyTest.java
 - Simple versions of create
 - Add flag for reference queue type
 - Merge branch 'master' into 8310913
 - Update to use VirtualThread friendly stale queue.
 - ... and 21 more: https://git.openjdk.org/jdk/compare/99ea8bf2...b1f64e93

-------------

Changes: https://git.openjdk.org/jdk/pull/14404/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=05
  Stats: 522 lines in 6 files changed: 129 ins; 266 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/14404.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404

PR: https://git.openjdk.org/jdk/pull/14404

From duke at openjdk.org  Wed Aug 30 23:39:31 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 30 Aug 2023 23:39:31 GMT
Subject: RFR: 8315383: jlink SystemModulesPlugin incorrectly parses the
 options [v2]
In-Reply-To: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>
References: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>
Message-ID: <Kjog27WeOffDtuaQUruZbJyCoitsGnxwFlt1GlzE2Xw=.0e2f3b28-95c2-4b9a-9c22-7b607a04e1c3@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8315383

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Remove obsolete imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/15495/files
  - new: https://git.openjdk.org/jdk/pull/15495/files/8fd76f62..d929f9a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15495&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15495&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15495.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15495/head:pull/15495

PR: https://git.openjdk.org/jdk/pull/15495

From jlu at openjdk.org  Wed Aug 30 23:43:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Aug 2023 23:43:14 GMT
Subject: Integrated: JDK-8314611: Provide more explicative error message
 parsing Currencies
In-Reply-To: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
References: <fEmB0av540N-gwb_GcZjp5ddcTq9xdJijI5uPT1szfA=.286e64b6-6149-4646-893c-7818a315dbf9@github.com>
Message-ID: <1qmZCAyTUjpxddrISbU-5RofxRlarpuXjvx5RvMpy9Y=.6a96f41c-9d1c-4120-a4a8-1109c6ddfc7f@github.com>

On Mon, 28 Aug 2023 21:14:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates some exceptions in j.util.Currency to have an explicit error message (as opposed to nothing).
> 
> The exceptions are thrown when the ISO 4217/3166 currency/country codes are in an invalid form, or do not exist.

This pull request has now been integrated.

Changeset: 3c8a6678
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c8a6678feac8e3225bc1c44593a78d9e7c4d77c
Stats:     41 lines in 2 files changed: 28 ins; 0 del; 13 mod

8314611: Provide more explicative error message parsing Currencies

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15458

From duke at openjdk.org  Thu Aug 31 02:39:03 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 31 Aug 2023 02:39:03 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
Message-ID: <RFPBBGpkSdIdNyrf7cyzwUVU8_S9Gq-bn-WxGcS9-mk=.787dec04-c4b4-4483-baf8-b410d4c0bd05@github.com>

On Tue, 18 Jul 2023 01:49:17 GMT, ??? <duke at openjdk.org> wrote:

>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*" 
>> make test TEST="micro:java.lang.Longs.toString*" 
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
>> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
>> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
>> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
>> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
>> 
>> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
>> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
>> 
>> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
>> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
>> 
>> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
>> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
>> 
>> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
>> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
>> 
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
>> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
>> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  5.036 ? 0.005  us/op (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert bounds check

@cl4es can you help me to review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1700286359

From duke at openjdk.org  Thu Aug 31 02:50:00 2023
From: duke at openjdk.org (=?UTF-8?B?5rip57uN6ZSm?=)
Date: Thu, 31 Aug 2023 02:50:00 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3]
In-Reply-To: <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
Message-ID: <USOCkzRqac8YgaeQFwnZhJ0oEnAVBVC9QIc-poVcx1U=.a015db96-874a-4523-88fc-d78a40ae6ea0@github.com>

On Thu, 6 Jul 2023 05:20:14 GMT, ??? <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add method CharacterDataLatin1#isLowerCaseEx

@cl4es can you help me to review this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1700292780

From dholmes at openjdk.org  Thu Aug 31 05:48:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Aug 2023 05:48:04 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <wVUv1MM9_YCMellQujMDEORehLIrVzlkDgDgTiLM3f8=.0693ba3b-61bb-4af2-b680-dabb4ec099aa@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <wVUv1MM9_YCMellQujMDEORehLIrVzlkDgDgTiLM3f8=.0693ba3b-61bb-4af2-b680-dabb4ec099aa@github.com>
Message-ID: <sXekzx-YhGFu-1-ONgzSYf1puehFR4QlJ2OaiCT_q98=.b2781fc0-3201-4a24-af79-143b94260469@github.com>

On Wed, 30 Aug 2023 11:31:20 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g.
createJavaProcessBuilder(List command, boolean addTestOpts) { ... }

@msheppar that is actually where we started, and it was then split into two differently named methods to "make it clear" which one included the test opts without having to remember the name of the parameter that the true/false argument was bound to.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700402301

From stsypanov at openjdk.org  Thu Aug 31 06:10:08 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 31 Aug 2023 06:10:08 GMT
Subject: Withdrawn: 8315351: Rid synchronization in PipedInputStream.close() in
 favour of benign race
In-Reply-To: <xnDhBIF33tLNxjT1w4mFuclrUaYd_XQcjaq7fUYStf4=.7a05a22b-4b5d-4d04-97de-3b6b48331ce2@github.com>
References: <xnDhBIF33tLNxjT1w4mFuclrUaYd_XQcjaq7fUYStf4=.7a05a22b-4b5d-4d04-97de-3b6b48331ce2@github.com>
Message-ID: <KMSHJBDJpM4OT_YF7PcYzRIjNF555uw-vMR-ESRknwU=.b6121414-6e18-4af7-a265-057a8914e535@github.com>

On Wed, 30 Aug 2023 09:49:39 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Assuming that the value written into `in` is always `-1` we can rid synchronized block in favour of guarding `in = - 1` with writing into volatile `closedByReader `:
> 
> public void close() throws IOException {
>     closedByReader = true;
>     synchronized (this) {
>         in = -1;
>     }
> }
> 
> -->
> 
> public void close() throws IOException {
>     in = -1;
>     closedByReader = true;
> }

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15486

From alanb at openjdk.org  Thu Aug 31 06:38:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 06:38:00 GMT
Subject: RFR: 8315413: Remove special filtering of Continuation.yield0 in
 StackWalker
In-Reply-To: <-xgvLCocJ3avyqm5wMbctIWgz1wUA6akr07oGAFYtIw=.f744e034-54d9-4a84-8ab2-8bab26078fcd@github.com>
References: <-xgvLCocJ3avyqm5wMbctIWgz1wUA6akr07oGAFYtIw=.f744e034-54d9-4a84-8ab2-8bab26078fcd@github.com>
Message-ID: <RhvRSc16H5kSRhJEVT56oOcaRQ8fdAycQ4Fr9oaAOhQ=.00e6f3c8-97b1-476b-9917-23fca4cff8af@github.com>

On Wed, 30 Aug 2023 20:57:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Loom added a special filtering of Continuation.yield0 in stack walker.  After the initial implementation, JDK-8304919 marks the yielding and entering methods with `@Hidden` and hidden frames are filtered by stack walker by default.   With `@Hidden` the special filtering should not be needed.

If tests are passing then this should be okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15498#pullrequestreview-1604036758

From alanb at openjdk.org  Thu Aug 31 06:51:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 06:51:00 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <VAAsfW_V1GEfQezmwBQwvXa3svN5cMzanUtpk4W4kv8=.6ff00b4d-01f4-4607-a7be-b17ae9669ae3@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <VAAsfW_V1GEfQezmwBQwvXa3svN5cMzanUtpk4W4kv8=.6ff00b4d-01f4-4607-a7be-b17ae9669ae3@github.com>
Message-ID: <RdenHruw4C5Yd3ZAu4G-QXF00NV99-fdZUipQwrPJ4M=.4329acd6-8a3a-4aed-9384-35cd8e2a6246@github.com>

On Wed, 30 Aug 2023 17:38:01 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I wouldn't be opposed to a change that:
> 
> * Keeps the `createJavaProcessBuilder` name
> * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> * Removes `createTestJava`
> * Removes `executeTestJava`

The good thing with this is that it very explicit at the use-sites where the test opts are prepended. Also moving from "Jvm" to "Java" is probably right as it executes the "java" launcher, the options are a mix of java launcher options (that the VM doesn't know about) and VM options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700459277

From azeller at openjdk.org  Thu Aug 31 06:59:04 2023
From: azeller at openjdk.org (Arno Zeller)
Date: Thu, 31 Aug 2023 06:59:04 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <F5Zhgxv8Uxml8va7ddyoAb0FJmdBWxdjHBIj6DF5024=.ce105193-dbaf-4cf4-8e21-6db89c937fbe@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
 <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
 <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>
 <PAAwyDFEoXNEw3LDkKa6CqSJxpcfks7qfx4f-0T0oE0=.b60e7d57-0170-4b85-ba50-028b2cc45190@github.com>
 <H9F_dHHhUBiUCjutO9FEtmFSZ2Ayp9n-B9TFNNDAWFk=.88bc4463-d533-4abb-99ab-87f583a6150b@github.com>
 <F5Zhgxv8Uxml8va7ddyoAb0FJmdBWxdjHBIj6DF5024=.ce105193-dbaf-4cf4-8e21-6db89c937fbe@github.com>
Message-ID: <FYM5t8Ec-O1df9axTxEcCYq84394YzWnPLFb64JmF5Q=.ff470087-fb2a-4da1-bbbb-6e9642ed2812@github.com>

On Wed, 30 Aug 2023 15:58:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yes, I think using System.getProperty("user.name") is brittle as well. If we'd use `com.sun.security.auth.module.NTSystem`, we would introduce the dependency to another module - `jdk.security.auth`. Not sure, whether this is a good option.
>
> The system environment has the domainname and the username.
> 
> String username = (System.getenv("USERDOMAIN") + "/" + System.getenv("USERNAME")).toLowerCase(Locale.ROOT);

The problem with the environment variables is, that jtreg only passes very few of them down to the testee process  -  USERDOMAIN and USERNAME are not part of these as far as I know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1311176210

From jpai at openjdk.org  Thu Aug 31 07:00:16 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Aug 2023 07:00:16 GMT
Subject: RFR: 8233160: Add java.vendor.url.bug to list of recognized standard
 system properties
Message-ID: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>

Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8233160?

It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that:

> The java.vendor.url.bug property has been defined by every Sun/Oracle JDK going all the way back to JDK 5 (and possibly earlier; JDK 5 is the oldest release that I can still run on my development machine). Yet, it's never been specified.

The OpenJDK builds too by default set a value for this system property.

The commit in this PR updates the javadoc of `System.getProperties()` to include this system property in the list of specified properties. Additionally, the `test/jdk/java/lang/System/PropertyTest.java` test has been updated to verify that this property is indeed available in the Properties returned by `System.getProperites()`.

I'll create a CSR shortly for this change.

-------------

Commit messages:
 - 8233160: Add java.vendor.url.bug to list of recognized standard system properties

Changes: https://git.openjdk.org/jdk/pull/15504/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15504&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8233160
  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15504/head:pull/15504

PR: https://git.openjdk.org/jdk/pull/15504

From dholmes at openjdk.org  Thu Aug 31 07:02:02 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Aug 2023 07:02:02 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
Message-ID: <8NKp6Q4LtB2Vza6zKFFfFAhiU9rfEvjwJuqfo-qAfKM=.9348b3ab-699f-4c0c-a011-bdef1a59e43b@github.com>

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke at openjdk.org> wrote:

> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.

As I wrote in the JBS issue and as Alan mentioned again above you can use the single `BarrierAction` object to track the state changes and count the generations/phase:

Runnable barrierAction = new Runnable() {
  int phase = 0;
  public void run() {
    switch(phase++) {
      case 0: doArtillery(); break;
      case 1: doAntiAircraft(); nreak;
      case 2: doMinefield(); break;
    }
   void doArtillery() { ... }
   ...
  }

I do not believe there is sufficient justification for expanding the `CyclicBarrier` API as proposed.

Happy to hear what @DougLea and @martin-buchholz think about this though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1700472066

From alanb at openjdk.org  Thu Aug 31 07:06:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 07:06:22 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
Message-ID: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>

In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM.

The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition.

Testing: tier1-5

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/15492/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15492&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315373
  Stats: 45 lines in 2 files changed: 10 ins; 16 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/15492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15492/head:pull/15492

PR: https://git.openjdk.org/jdk/pull/15492

From alanb at openjdk.org  Thu Aug 31 07:23:09 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 07:23:09 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v8]
In-Reply-To: <pevI_jE0H6Fiai8KZmsfCUZIJ08j4OYgZkV40iqRdio=.3996d9ed-0f8b-4856-bf13-43f0037e2e83@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
 <6LniLY2k906SYWewwmwQoGQrJ2kI9MM88pqUPgjl7b8=.8522ef13-0571-47aa-a088-0f57e2e7ab8d@github.com>
 <HLRQsz7QLRGMxteBZfOJ3F5iyJef7DFe5RWTwsecldM=.5e9b9cef-5fa5-446d-bf7e-cbc9b5a5f042@github.com>
 <pevI_jE0H6Fiai8KZmsfCUZIJ08j4OYgZkV40iqRdio=.3996d9ed-0f8b-4856-bf13-43f0037e2e83@github.com>
Message-ID: <EZupHncTt3_RLCvlRQSQmwqMq7wcqQWJlJXgg1-IPGY=.260dae56-4fcf-468c-aaae-468aef147656@github.com>

On Wed, 30 Aug 2023 16:29:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Indeed, Set.of factory methods are easy to use. I'm okay with taking it out.

It would be easy to add in the future if needed, say if more options were introduced and the common case requires 2 or more options.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15370#issuecomment-1700499172

From duke at openjdk.org  Thu Aug 31 07:26:01 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 31 Aug 2023 07:26:01 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <8NKp6Q4LtB2Vza6zKFFfFAhiU9rfEvjwJuqfo-qAfKM=.9348b3ab-699f-4c0c-a011-bdef1a59e43b@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
 <8NKp6Q4LtB2Vza6zKFFfFAhiU9rfEvjwJuqfo-qAfKM=.9348b3ab-699f-4c0c-a011-bdef1a59e43b@github.com>
Message-ID: <MGzlIyyFpSFaydkqIzmDt3awxFH_D29mB0kOSLQ0vRg=.29121c75-37f0-4752-9324-a6924f5c14f6@github.com>

On Thu, 31 Aug 2023 06:59:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
>> For example, the U.S. Army 'Gordon Sullivan Cup'.
>> Five tanks competing.
>> 1. The first round is for artillery strikes against targets.
>> 2. Second round of anti-aircraft machine gun targets.
>> 3. The third round is minefield racing.
>> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.
>
> As I wrote in the JBS issue and as Alan mentioned again above you can use the single `BarrierAction` object to track the state changes and count the generations/phase:
> 
> Runnable barrierAction = new Runnable() {
>   int phase = 0;
>   public void run() {
>     switch(phase++) {
>       case 0: doArtillery(); break;
>       case 1: doAntiAircraft(); nreak;
>       case 2: doMinefield(); break;
>     }
>    void doArtillery() { ... }
>    ...
>   }
> 
> I do not believe there is sufficient justification for expanding the `CyclicBarrier` API as proposed.
> 
> Happy to hear what @DougLea and @martin-buchholz think about this though.

I agree with @dholmes-ora ? the transition is in/belongs to the action, not the barrier.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1700503736

From alanb at openjdk.org  Thu Aug 31 07:37:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 07:37:59 GMT
Subject: RFR: 8233160: Add java.vendor.url.bug to list of recognized
 standard system properties
In-Reply-To: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>
References: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>
Message-ID: <NnqTnqBsCG5LcymfLgV4vUX-mDfIVdVg_hTy_iE1KE8=.5e5f7cda-f2f7-40c5-9890-c285193bc8aa@github.com>

On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8233160?
> 
> It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that:
> 
>> The java.vendor.url.bug property has been defined by every Sun/Oracle JDK going all the way back to JDK 5 (and possibly earlier; JDK 5 is the oldest release that I can still run on my development machine). Yet, it's never been specified.
> 
> The OpenJDK builds too by default set a value for this system property.
> 
> The commit in this PR updates the javadoc of `System.getProperties()` to include this system property in the list of specified properties. Additionally, the `test/jdk/java/lang/System/PropertyTest.java` test has been updated to verify that this property is indeed available in the Properties returned by `System.getProperites()`.
> 
> I'll create a CSR shortly for this change.

No objection to making this a standard property,  I just wonder if it should be optional (like java.vendor.version), and whether the value must be parsable as a URL. The question on whether the value can be interpreted as a URL applies to the exiting java.vendor.url property too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15504#issuecomment-1700518322

From jpai at openjdk.org  Thu Aug 31 09:08:03 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 31 Aug 2023 09:08:03 GMT
Subject: RFR: 8233160: Add java.vendor.url.bug to list of recognized
 standard system properties
In-Reply-To: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>
References: <eGXBuA25OQADEjNQXlWYOUCfXdPZZ84KGm7VgtIr3Ik=.15ffdb50-be18-4f15-a9d1-0cb46cc3ac80@github.com>
Message-ID: <a2CregNBPzKIcTz_TRw92OnJ_adLKXAcp8dEmoAnNR0=.58f37e58-dab4-4a24-a511-93776b0e2f2c@github.com>

On Thu, 31 Aug 2023 06:53:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to address https://bugs.openjdk.org/browse/JDK-8233160?
> 
> It has been noted in https://bugs.openjdk.org/browse/JDK-8232753 that:
> 
>> The java.vendor.url.bug property has been defined by every Sun/Oracle JDK going all the way back to JDK 5 (and possibly earlier; JDK 5 is the oldest release that I can still run on my development machine). Yet, it's never been specified.
> 
> The OpenJDK builds too by default set a value for this system property.
> 
> The commit in this PR updates the javadoc of `System.getProperties()` to include this system property in the list of specified properties. Additionally, the `test/jdk/java/lang/System/PropertyTest.java` test has been updated to verify that this property is indeed available in the Properties returned by `System.getProperites()`.
> 
> I'll create a CSR shortly for this change.

Hello Alan,

> I just wonder if it should be optional (like java.vendor.version),

I am unsure too. I decided to go with non-optional for now to match with the `java.vendor.url` system property which too is non-optional.



> and whether the value must be parsable as a URL. The question on whether the value can be interpreted as a URL applies to the exiting java.vendor.url property too.

My understanding is that these URLs are there mainly to be visible in log files or other such places and not for programatic parsing/construction. Especially for `java.vendor.url.bug`, I think it would be a rare thing to have it being parsed into URL programatically. So it may not be useful to add the restriction that this must be a parsable URL.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15504#issuecomment-1700650920

From duke at openjdk.org  Thu Aug 31 10:06:03 2023
From: duke at openjdk.org (chenggwang)
Date: Thu, 31 Aug 2023 10:06:03 GMT
Subject: RFR: JDK-8314194: Reusing CyclicBarrier,
 it should be possible to change the barrierCommand
In-Reply-To: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
References: <gI3tMpWbRpVPkaxWhn5zUUhdaZsBeOjbh39em0HEcg0=.4b5c9e15-e69c-434d-9337-27c431ec1e2f@github.com>
Message-ID: <6ay7PmY4OxewnaOmKJ3QyrClRC0BqoRSBcUOoCkZvG0=.b043f2a6-0244-4381-be99-9202e457938c@github.com>

On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang <duke at openjdk.org> wrote:

> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous and makes you think of Phaser. My intention is that each generation of CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S. Army 'Gordon Sullivan Cup'.
> Five tanks competing.
> 1. The first round is for artillery strikes against targets.
> 2. Second round of anti-aircraft machine gun targets.
> 3. The third round is minefield racing.
> The scoring criteria are different for each round, so the CyclicBarrier's barrierCommand should be different for each round. But in the current code, `private final Runnable barrierCommand`, constructing the CyclicBarrier instance is already determined to be unchangeable.

> As I wrote in the JBS issue and as Alan mentioned again above you can use the single `BarrierAction` object to track the state changes and count the generations/phase:
> 
> ```
> Runnable barrierAction = new Runnable() {
>   int phase = 0;
>   public void run() {
>     switch(phase++) {
>       case 0: doArtillery(); break;
>       case 1: doAntiAircraft(); nreak;
>       case 2: doMinefield(); break;
>     }
>    void doArtillery() { ... }
>    ...
>   }
> ```
> 
> I do not believe there is sufficient justification for expanding the `CyclicBarrier` API as proposed.
> 
> Happy to hear what @DougLea and @Martin-Buchholz think about this though.

Thank you @dholmes-ora @viktorklang-ora Your proposal is indeed a good solution! Enhancements and improvements became less urgent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15239#issuecomment-1700741431

From msheppar at openjdk.org  Thu Aug 31 10:11:02 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 31 Aug 2023 10:11:02 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <sXekzx-YhGFu-1-ONgzSYf1puehFR4QlJ2OaiCT_q98=.b2781fc0-3201-4a24-af79-143b94260469@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <wVUv1MM9_YCMellQujMDEORehLIrVzlkDgDgTiLM3f8=.0693ba3b-61bb-4af2-b680-dabb4ec099aa@github.com>
 <sXekzx-YhGFu-1-ONgzSYf1puehFR4QlJ2OaiCT_q98=.b2781fc0-3201-4a24-af79-143b94260469@github.com>
Message-ID: <vCLRZwJrzYryyifx7o1JmbNDvnCt9bPwJKPd3DqOR30=.447ed116-dbae-4192-8300-ac7eaba309b3@github.com>

On Thu, 31 Aug 2023 05:45:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > So you could create a single createJavaProcessBuilder with add an additional parameter boolean addTestOpts e.g.
> > createJavaProcessBuilder(List command, boolean addTestOpts) { ... }
> 
> @msheppar that is actually where we started, and it was then split into two differently named methods to "make it clear" which one included the test opts without having to remember the name of the parameter that the true/false argument was bound to.

cheers David  thanks for the clarification on background

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1700749844

From mgronlun at openjdk.org  Thu Aug 31 10:41:02 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Aug 2023 10:41:02 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
In-Reply-To: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
References: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
Message-ID: <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>

On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM.
> 
> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition.
> 
> Testing: tier1-5

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 410:

> 408:   }
> 409:   if (JAVA_SAMPLE == type) {
> 410:     if (thread_state_in_java(thread) && !is_vthread_in_transition(thread)) {

I think this check can be postponed until after the thread is suspended.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 415:

> 413:   } else {
> 414:     assert(NATIVE_SAMPLE == type, "invariant");
> 415:     if (thread_state_in_native(thread) && !is_vthread_in_transition(thread)) {

Is this possible? I assume the thread is in _thread_in_Java during the transition?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1311439052
PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1311437865

From asotona at openjdk.org  Thu Aug 31 11:16:21 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 31 Aug 2023 11:16:21 GMT
Subject: RFR: 8313258: RuntimeInvisibleTypeAnnotationsAttribute.annotations()
 API Index out of Bound error
Message-ID: <AQ5NoeZ0UZKjMa-A-UinTnqrm-PSiwwUNHSaJi7tZ1c=.5970e420-88bc-427c-ad92-60371d87b0b5@github.com>

Classfile API suppose to throw IllegalArgumentException in situations where bytecode offset is out of allowed range. Such situation includes invalid offset parsed from a TypeAnnotation as well as from other CodeAttribute attributes.

This patch throws IAE for invalid bytecode offset when requested Label for the parsed CodeAttribute, so it cover even wider range of cases than mentioned in the bug report.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8313258: RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound error

Changes: https://git.openjdk.org/jdk/pull/15511/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15511&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313258
  Stats: 13 lines in 2 files changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15511.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15511/head:pull/15511

PR: https://git.openjdk.org/jdk/pull/15511

From alanb at openjdk.org  Thu Aug 31 11:44:01 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 11:44:01 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
In-Reply-To: <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>
References: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
 <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>
Message-ID: <gsa0FCBjORRIiR3TFZ4Ev2BJJYddW53NaaSThmu2efw=.e931c3a4-1319-4c44-b5d8-3bfb34c6083f@github.com>

On Thu, 31 Aug 2023 10:38:32 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM.
>> 
>> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition.
>> 
>> Testing: tier1-5
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 410:
> 
>> 408:   }
>> 409:   if (JAVA_SAMPLE == type) {
>> 410:     if (thread_state_in_java(thread) && !is_vthread_in_transition(thread)) {
> 
> I think this check can be postponed until after the thread is suspended.

Is the check in OSThreadSampler::protected_task in the right place? That seems to be a suspended context.

For JfrThreadSampleClosure::do_sample_thread, I think I may have mis-read the code. I thought it was suspended but looking at it again them maybe it should be the JfrNativeSamplerCallback implementation. This is probably an area where I need help to get right.



Is JfrNativeSamplerCallback

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1311502783

From redestad at openjdk.org  Thu Aug 31 11:48:03 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 31 Aug 2023 11:48:03 GMT
Subject: RFR: 8311220: Optimization for StringLatin UpperLower [v3]
In-Reply-To: <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
References: <ELD9dLNgq65KHjgylAXSl47OBf1k7dHpWD5zfDoQIlY=.90891669-63c7-431a-855c-a425f35371b4@github.com>
 <qj2QzoxFNnxHTsUfNhVodTgagWMsYKJdE5UgYcEN3Bw=.f1035c20-249b-478e-8003-5af0906ec34d@github.com>
Message-ID: <Kmp7A3PBv6WBRNEN8VjnUNsLsMN1lv4lfUoGjjgNRMA=.94dc3ee7-1eba-4391-a7b8-c831b248ed6c@github.com>

On Thu, 6 Jul 2023 05:20:14 GMT, ??? <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ? 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ? 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ? 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ? 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ? 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ? 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ? 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ? 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ? 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ? 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ? 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ? 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ? 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ? 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ? 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ? 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ? 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ? 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ? 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ? 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ? 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ? 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ? 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ? 0.038  ns/op
>> 
>> +B...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add method CharacterDataLatin1#isLowerCaseEx

I think this overall looks reasonable, but I think a more thorough proof / test would help to build confidence that all these changes are semantically neutral. 

The `isLowerCaseEx` needs to explain why two lower-case codepoints are omitted (perhaps this should be `hasUpperCase`?)

src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template line 94:

> 92: 
> 93:     boolean isLowerCaseEx(int ch) {
> 94:         return ch >= 'a' && (ch <= 'z' || ch == 181 || (ch >= 223 && ch != 247));

What is the contract for this? Specifically there are two special superscripte codepoints (170 and 186) which are lower-case (`Character.isLowerCase(170) => true`) but doesn't have an upper-case (`Character.toUpperCase(170) => 170`). It seems reasonable to exclude them if only used for operations like toUpper/toLower (since they won't change), but it should be spelled out to avoid surprises.

For consistency I think we should use hex literals in this file, e.g. `0xDF` instead of `223`

-------------

Changes requested by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14751#pullrequestreview-1604562360
PR Review Comment: https://git.openjdk.org/jdk/pull/14751#discussion_r1311501588

From asotona at openjdk.org  Thu Aug 31 12:20:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 31 Aug 2023 12:20:25 GMT
Subject: RFR: 8313983: jmod create --target-platform should replace existing
 ModuleTarget attribute
Message-ID: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>

ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple' in the Classfile API.
This patch removed the flags and allows at most one instance of each attribute.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8313983: jmod create --target-platform should replace existing ModuleTarget attribute

Changes: https://git.openjdk.org/jdk/pull/15514/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15514&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313983
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15514.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15514/head:pull/15514

PR: https://git.openjdk.org/jdk/pull/15514

From mgronlun at openjdk.org  Thu Aug 31 13:33:01 2023
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 31 Aug 2023 13:33:01 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
In-Reply-To: <gsa0FCBjORRIiR3TFZ4Ev2BJJYddW53NaaSThmu2efw=.e931c3a4-1319-4c44-b5d8-3bfb34c6083f@github.com>
References: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
 <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>
 <gsa0FCBjORRIiR3TFZ4Ev2BJJYddW53NaaSThmu2efw=.e931c3a4-1319-4c44-b5d8-3bfb34c6083f@github.com>
Message-ID: <pvpE5XK4JO7FIiXkAMljdM0tbR_Cgcmn23g3YqQfkBE=.538be85f-df31-47a5-9381-fa6afe107c38@github.com>

On Thu, 31 Aug 2023 11:41:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 410:
>> 
>>> 408:   }
>>> 409:   if (JAVA_SAMPLE == type) {
>>> 410:     if (thread_state_in_java(thread) && !is_vthread_in_transition(thread)) {
>> 
>> I think this check can be postponed until after the thread is suspended.
>
> Is the check in OSThreadSampler::protected_task in the right place? That seems to be a suspended context.
> 
> For JfrThreadSampleClosure::do_sample_thread, I think I may have mis-read the code. I thought it was suspended but looking at it again them maybe it should be the JfrNativeSamplerCallback implementation. This is probably an area where I need help to get right.

OSThreadSampler::protected_task() is the correct place to perform the test. The sampled thread is completely suspended at this location. The other locations are optimistic, they read the thread state while the sampled thread is running to avoid signalling a thread unnecessarily. You don't need the is_vthread_in_transtition() check there, especially not for the thread_in_native case, since that would not be possible, would it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1311632129

From jhendrikx at openjdk.org  Thu Aug 31 14:18:05 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 31 Aug 2023 14:18:05 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
Message-ID: <ELnVRqGtqPQIqMk7kyQ0DdWCg3ysoZHXnh3t-HfsV0w=.c8c58c6a-c820-4d04-85dd-e95640691657@github.com>

On Tue, 18 Jul 2023 01:49:17 GMT, ??? <duke at openjdk.org> wrote:

>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*" 
>> make test TEST="micro:java.lang.Longs.toString*" 
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
>> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
>> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
>> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
>> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
>> 
>> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
>> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
>> 
>> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
>> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
>> 
>> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
>> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
>> 
>> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
>> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
>> 
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
>> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
>> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  5.036 ? 0.005  us/op (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert bounds check

I'm wondering if a micro benchmark like this is very realistic.  They may score positive as eventually these helper tables are in the inner most cache level, but it may be a net negative for larger functions that only do integer conversion occasionally, and almost always have a cache miss when doing a conversion.  The tables may also be displacing other more useful cache lines.

In my opinion, cache is a limited resource, and having a low level function use a big chunk of it may be optimal for a micro benchmark, but seems unlikely to be optimal overall.  If you are only doing mass string to integer conversion, I'm sure it will do better.  If you are writing out JSON that sometimes contains integers, the integer conversions may now sometimes have cache misses (in which case a non-cached based conversion would perform better), or the conversion is displacing other more useful cache lines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701138931

From liach at openjdk.org  Thu Aug 31 14:21:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 31 Aug 2023 14:21:05 GMT
Subject: RFR: 8313258:
 RuntimeInvisibleTypeAnnotationsAttribute.annotations() API Index out of Bound
 error
In-Reply-To: <AQ5NoeZ0UZKjMa-A-UinTnqrm-PSiwwUNHSaJi7tZ1c=.5970e420-88bc-427c-ad92-60371d87b0b5@github.com>
References: <AQ5NoeZ0UZKjMa-A-UinTnqrm-PSiwwUNHSaJi7tZ1c=.5970e420-88bc-427c-ad92-60371d87b0b5@github.com>
Message-ID: <TzrPutLCIaniRveTAZzCbUvm1Dlco52QeRXhOPAyJAI=.b1347399-e1f7-40a9-8bd4-3582a4f84f95@github.com>

On Thu, 31 Aug 2023 11:09:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API suppose to throw IllegalArgumentException in situations where bytecode offset is out of allowed range. Such situation includes invalid offset parsed from a TypeAnnotation as well as from other CodeAttribute attributes.
> 
> This patch throws IAE for invalid bytecode offset when requested Label for the parsed CodeAttribute, so it cover even wider range of cases than mentioned in the bug report.
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java line 101:

> 99:     public Label getLabel(int bci) {
> 100:         if (bci < 0 || bci > codeLength)
> 101:             throw new IllegalArgumentException(String.format("Bytecode offset out of range; bci=%d, codeLength=%d",

Should we get an IAE formatter in `jdk.internal.util.Preconditons` for classfile-specific bound checking, so we can do `Preconditions.checkIndex(bci, codeLength, Preconditions.IAE_FORMATTER);` and share it with other use sites of classfile-specific exceptions.

In addition, we might move the `new IllegalArgumentException` constructor calls to a utility method in our `Util` class in case we migrate our exceptions to a new subclass of IAE. Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15511#discussion_r1311708857

From duke at openjdk.org  Thu Aug 31 14:32:02 2023
From: duke at openjdk.org (iaroslavski)
Date: Thu, 31 Aug 2023 14:32:02 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v9]
In-Reply-To: <YOZ7-cCyDtKbLO_eWpoi2FD6GswBFO6Azaeln-m9a20=.638c4153-c55a-4846-ae8d-978f8fefbfff@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <YOZ7-cCyDtKbLO_eWpoi2FD6GswBFO6Azaeln-m9a20=.638c4153-c55a-4846-ae8d-978f8fefbfff@github.com>
Message-ID: <8wFp2rFtTWDGTQ4AKB4QYNjb0eJrg6aDznXP3p8agKE=.a0b699ac-f725-4bfd-9d07-bc7ace20b0a0@github.com>

On Wed, 30 Aug 2023 10:55:48 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comments (v23.08)

Hi team,
@AlanBateman, @rose00, @mbreinhold 

There are a big efforts now to improve sorting with x86_64 AVX512
https://github.com/openjdk/jdk/pull/14227, no changes of
Dual-Pivot Quicksort logic.

But at the same time this PR offers algorithmic improvements,
like optimized insertion sort, merging sort, better partitioning
and Radix sort for fully random data. Radix sort has linear complexity
instead of n*ln(n), much faster!. Also we handle properly situation if
no enough memory for additional buffer, now we will face with OOM.

Alan, you mentioned that DualPivotQuicksort will need detailed review.
Can we go ahead and start reviewing? Laurent checked performance,
JMH results look fine.

I think it would be logical to integrate new DualPivotQuicksort first,
and then apply AVX512 changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1701162875

From aph at openjdk.org  Thu Aug 31 14:35:04 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 31 Aug 2023 14:35:04 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <ELnVRqGtqPQIqMk7kyQ0DdWCg3ysoZHXnh3t-HfsV0w=.c8c58c6a-c820-4d04-85dd-e95640691657@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
 <ELnVRqGtqPQIqMk7kyQ0DdWCg3ysoZHXnh3t-HfsV0w=.c8c58c6a-c820-4d04-85dd-e95640691657@github.com>
Message-ID: <jN1DbvlmN1SitkTidxyYHyhEdMj0YCHIxGcrEPsCvas=.8c7d0e07-d5db-430f-b4ce-b981431e4b18@github.com>

On Thu, 31 Aug 2023 14:15:41 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I'm wondering if a micro benchmark like this is very realistic. 

Exactly so! This is almost the canonical example of the "JMH considered harmful" talk I gave recently.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701167979

From aph at openjdk.org  Thu Aug 31 14:46:02 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 31 Aug 2023 14:46:02 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <jN1DbvlmN1SitkTidxyYHyhEdMj0YCHIxGcrEPsCvas=.8c7d0e07-d5db-430f-b4ce-b981431e4b18@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
 <ELnVRqGtqPQIqMk7kyQ0DdWCg3ysoZHXnh3t-HfsV0w=.c8c58c6a-c820-4d04-85dd-e95640691657@github.com>
 <jN1DbvlmN1SitkTidxyYHyhEdMj0YCHIxGcrEPsCvas=.8c7d0e07-d5db-430f-b4ce-b981431e4b18@github.com>
Message-ID: <P4ul03y1HAeouwcCVDDOK6H-HHE6HvmKZ9wAT92miMI=.7afc6627-f7de-4685-bde8-cb481338f2c7@github.com>

On Thu, 31 Aug 2023 14:32:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > I'm wondering if a micro benchmark like this is very realistic.
> 
> Exactly so! This is almost the canonical example of the "JMH considered harmful" talk I gave recently.

The subject is a joke! Yes, I love JMH, but be very careful how you use it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701185887

From rriggs at openjdk.org  Thu Aug 31 15:11:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Aug 2023 15:11:02 GMT
Subject: RFR: 8314094: java/lang/ProcessHandle/InfoTest.java fails on
 Windows when run as user with Administrator privileges
In-Reply-To: <FYM5t8Ec-O1df9axTxEcCYq84394YzWnPLFb64JmF5Q=.ff470087-fb2a-4da1-bbbb-6e9642ed2812@github.com>
References: <NV4aQH-dFj-x5UJnNkKT7s1mEwHgJxJUSGQAQV0b4hA=.3b002fe1-2f4e-419f-abe8-0af876af330f@github.com>
 <2qBOL4we7ScqNYGkXnHhZcEUjEwMEyHKDOuWAdmUP0I=.95096c0d-398f-41c3-b85e-8dfee1307ad5@github.com>
 <uceU7AjqQ_7gVZ5dQAyi1CCqgrGUt03qEki7RjaHDpM=.06323e70-a3bc-4be5-8f0d-51bac816fd76@github.com>
 <PAAwyDFEoXNEw3LDkKa6CqSJxpcfks7qfx4f-0T0oE0=.b60e7d57-0170-4b85-ba50-028b2cc45190@github.com>
 <H9F_dHHhUBiUCjutO9FEtmFSZ2Ayp9n-B9TFNNDAWFk=.88bc4463-d533-4abb-99ab-87f583a6150b@github.com>
 <F5Zhgxv8Uxml8va7ddyoAb0FJmdBWxdjHBIj6DF5024=.ce105193-dbaf-4cf4-8e21-6db89c937fbe@github.com>
 <FYM5t8Ec-O1df9axTxEcCYq84394YzWnPLFb64JmF5Q=.ff470087-fb2a-4da1-bbbb-6e9642ed2812@github.com>
Message-ID: <aQs9r7XAVeVB71T4OmvNmFm_XdvVqD5a57bupOnGLtY=.a2a9ae0d-f5cc-4487-8adb-3b51fdfaaa55@github.com>

On Thu, 31 Aug 2023 06:56:06 GMT, Arno Zeller <azeller at openjdk.org> wrote:

>> The system environment has the domainname and the username.
>> 
>> String username = (System.getenv("USERDOMAIN") + "/" + System.getenv("USERNAME")).toLowerCase(Locale.ROOT);
>
> The problem with the environment variables is, that jtreg only passes very few of them down to the testee process  -  USERDOMAIN and USERNAME are not part of these as far as I know.

ok, more overhead than value in the suggestion. 
If its windows, strip off the domain (before "/") and compare.
If that doesn't work then just drop the username compare on windows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15222#discussion_r1311783371

From alanb at openjdk.org  Thu Aug 31 15:19:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 15:19:02 GMT
Subject: RFR: 8313983: jmod create --target-platform should replace
 existing ModuleTarget attribute
In-Reply-To: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>
References: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>
Message-ID: <ZKXfWtiC0XSRIvmDPqkq09gLZBs7Vof4pPXi-mbNxh4=.5f9349a9-5582-4b05-9d0f-3bfb48bf943b@github.com>

On Thu, 31 Aug 2023 12:13:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple' in the Classfile API.
> This patch removed the flags and allows at most one instance of each attribute.
> 
> Please review.
> 
> Thanks,
> Adam

Thanks for fixing this.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15514#pullrequestreview-1605009014

From asotona at openjdk.org  Thu Aug 31 15:54:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 31 Aug 2023 15:54:01 GMT
Subject: RFR: 8312491: Update Classfile API snippets and examples [v10]
In-Reply-To: <7slK1NkVgYdrdZG918Ui70SsEUUXvULX3WT1O3sRrCw=.a12c45e8-3c6e-4643-9a30-f88353701440@github.com>
References: <nVyKedwy0qFK7cZ0UpXGdoHJDl3WTL2RiF96oO4EsSE=.0b92e342-5104-4474-8da2-d4664d360b3a@github.com>
 <7slK1NkVgYdrdZG918Ui70SsEUUXvULX3WT1O3sRrCw=.a12c45e8-3c6e-4643-9a30-f88353701440@github.com>
Message-ID: <-x4LRt_dPjqvlkLh-z3r1cTiu1wwwNSuN55jW_M6W4o=.e15c744d-c0cc-4185-ab90-b51365324243@github.com>

On Wed, 30 Aug 2023 12:39:45 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This pull request updates Classfile API snippets and examples and adds missing javadoc.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing javadoc

The javadoc and snippets are available online at:
https://cr.openjdk.org/~asotona/8312491/classfile-api/javadoc/java.base/jdk/internal/classfile/package-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14968#issuecomment-1701299020

From mchung at openjdk.org  Thu Aug 31 16:14:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Aug 2023 16:14:12 GMT
Subject: Integrated: 8315413: Remove special filtering of Continuation.yield0
 in StackWalker
In-Reply-To: <-xgvLCocJ3avyqm5wMbctIWgz1wUA6akr07oGAFYtIw=.f744e034-54d9-4a84-8ab2-8bab26078fcd@github.com>
References: <-xgvLCocJ3avyqm5wMbctIWgz1wUA6akr07oGAFYtIw=.f744e034-54d9-4a84-8ab2-8bab26078fcd@github.com>
Message-ID: <ChVB_F2ft95TjszmIoZL6k0A3g18WKzt1Fc_txw1i-4=.ad431082-4c5b-4498-87a1-f3ba746078f4@github.com>

On Wed, 30 Aug 2023 20:57:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Loom added a special filtering of Continuation.yield0 in stack walker.  After the initial implementation, JDK-8304919 marks the yielding and entering methods with `@Hidden` and hidden frames are filtered by stack walker by default.   With `@Hidden` the special filtering should not be needed.

This pull request has now been integrated.

Changeset: c8acab1d
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8acab1d913a6c676706fce7ad98a7f831a95682
Stats:     33 lines in 4 files changed: 0 ins; 24 del; 9 mod

8315413: Remove special filtering of Continuation.yield0 in StackWalker

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/15498

From duke at openjdk.org  Thu Aug 31 16:14:13 2023
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 31 Aug 2023 16:14:13 GMT
Subject: Integrated: 8315383: jlink SystemModulesPlugin incorrectly parses the
 options
In-Reply-To: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>
References: <8JLvIydPLtNKzBHiCLLM6Q4RbScQLPvShTSw_VtBn68=.ba04e37c-3ed6-46e0-be78-acee7ef3711f@github.com>
Message-ID: <273UV02IdI5Y0KS8FGXF-BYkiCxNEof8tksA96JaYpE=.943fd1c9-80fd-4f1b-ab16-88d3af581dc9@github.com>

On Wed, 30 Aug 2023 19:07:53 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fixes https://bugs.openjdk.org/browse/JDK-8315383

This pull request has now been integrated.

Changeset: ea5aa61c
Author:    Oliver Kopp <kopp.dev at gmail.com>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea5aa61c8cc5caa04f7c7eac9634df28011581dc
Stats:     6 lines in 2 files changed: 0 ins; 4 del; 2 mod

8315383: jlink SystemModulesPlugin incorrectly parses the options

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/15495

From duke at openjdk.org  Thu Aug 31 16:21:05 2023
From: duke at openjdk.org (Andriy Plokhotnyuk)
Date: Thu, 31 Aug 2023 16:21:05 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <RFPBBGpkSdIdNyrf7cyzwUVU8_S9Gq-bn-WxGcS9-mk=.787dec04-c4b4-4483-baf8-b410d4c0bd05@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
 <RFPBBGpkSdIdNyrf7cyzwUVU8_S9Gq-bn-WxGcS9-mk=.787dec04-c4b4-4483-baf8-b410d4c0bd05@github.com>
Message-ID: <o3TaSPOST-QBIiVOlD8wZRO5w5LT2WIJGv5U8Qmnn14=.bae3ffa1-e8c3-4eff-94f5-dff2ea09d151@github.com>

On Thu, 31 Aug 2023 02:36:09 GMT, ??? <duke at openjdk.org> wrote:

>> ??? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   assert bounds check
>
> @cl4es can you help me to review this PR?

@wenshao How about of approach used in James Anhalt's algorithm: https://jk-jeon.github.io/posts/2022/02/jeaiii-algorithm/

It reduces number of multiplications (and store operation in case of writing by 4-8 byte words) but increases the total number of instructions for the routine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14699#issuecomment-1701346461

From mchung at openjdk.org  Thu Aug 31 16:45:02 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Aug 2023 16:45:02 GMT
Subject: RFR: 8313983: jmod create --target-platform should replace
 existing ModuleTarget attribute
In-Reply-To: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>
References: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>
Message-ID: <u13sUkhT26tlBHyQfI3iD9X9XrNYC_2WVsC8-5MPjCw=.b09b07e6-caa3-49f0-9df6-6ef591918855@github.com>

On Thu, 31 Aug 2023 12:13:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple' in the Classfile API.
> This patch removed the flags and allows at most one instance of each attribute.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/15514#pullrequestreview-1605194954

From mchung at openjdk.org  Thu Aug 31 16:50:01 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Aug 2023 16:50:01 GMT
Subject: RFR: 8313983: jmod create --target-platform should replace
 existing ModuleTarget attribute
In-Reply-To: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>
References: <6hJKama5viHce-gD7tPXLhgnuUce93e5NJgdvMnaNak=.e4df38a6-eb4e-4e0b-8b5c-9c2c227c9d27@github.com>
Message-ID: <rRL4Befy-WAv2BEvLRnfgGBwMWLfHfiaapsE1udjdoI=.928a3ff8-09d3-415d-b000-b6314a2f6816@github.com>

On Thu, 31 Aug 2023 12:13:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> ModuleTarget and ModuleResolution attributes were flagged as 'allow multiple' in the Classfile API.
> This patch removed the flags and allows at most one instance of each attribute.
> 
> Please review.
> 
> Thanks,
> Adam

Would you consider documenting in the javadoc of XXXAttribute in the ClassFile API if it allows multiple?   It will make clear to the readers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15514#issuecomment-1701404915

From mseledtsov at openjdk.org  Thu Aug 31 16:56:00 2023
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 31 Aug 2023 16:56:00 GMT
Subject: RFR: 8313718: make container at requires command configurable [v2]
In-Reply-To: <LRXONRMx_WRJUuBw1AFXFotxsmuIrYp7FzHw7MdMZRU=.6665f01a-f87c-41cb-abc9-773c17fe8684@github.com>
References: <5MNRj3EEfoOB95ew6g5ViHMHQEZtlTIJ20ePnQrFXoM=.c71f19e8-af37-4ab4-a5f1-2415b43b4001@github.com>
 <LRXONRMx_WRJUuBw1AFXFotxsmuIrYp7FzHw7MdMZRU=.6665f01a-f87c-41cb-abc9-773c17fe8684@github.com>
Message-ID: <xtbzwzwqwPqFgiA5UtxVe3O55_mIxM7-GkUILLA5iPw=.cc0742f7-2bd5-4dd4-8bf1-ae66e0f4aaac@github.com>

On Wed, 30 Aug 2023 03:25:54 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Container ecosystem is growing. It would be beneficial to define custom command to figure out whether a specific test host or environment allows for container testing. This enhancement seeks to make the command used by jtreg "requires" extension configurable, specifically test/jtreg-ext/requires/VMProps.java checkContainerSupport().
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed initialization issue

David,
  We already have a way to configure engine executable, that is 'docker' vs 'podman' vs 'some-other-engine'. However the command that we use to test whether the engine is available and working on a given test host is "<CONTAINER_ENGINE> ps". However the "ps" sub-command may not be applicable for all container types, and it may be "heavy" at times on some busy hosts.
  One option is to replace it with something more universal and light-weight, such as "<CONTAINER_ENGINE> help". The "help" command should be available for all containers, and be reasonably light-weight. 
  The other option is to make it fully configurable as this change. 
It would also be good to have an ability to skip such check entirely for hosts know to be properly configured.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15475#issuecomment-1701413581

From mchung at openjdk.org  Thu Aug 31 17:09:40 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Aug 2023 17:09:40 GMT
Subject: RFR: 8268829: Provide an optimized way to walk the stack with
 Class object only [v9]
In-Reply-To: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
References: <sMqNhyBB5yWbImc2u9tsHcOJaZ7zXBS6Wj7o96E-MQg=.28ebf649-0487-415d-a9be-9a78f07ab353@github.com>
Message-ID: <6hreBEM3qw8FZmOCseR6hgu4-avV-C-2oK7PlOs-IYU=.b3345812-391b-4ed1-b7a2-cdb0e63e2be6@github.com>

> 8268829: Provide an optimized way to walk the stack with Class object only
> 
> `StackWalker::walk` creates one `StackFrame` per frame and the current implementation
> allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks
> like logging may only interest in the Class object but not the method name nor the BCI,
> for example, filters out its implementation classes to find the caller class.  It's
> similar to `StackWalker::getCallerClass` but allows a predicate to filter out the element.
> 
> This PR proposes to add `Option::DROP_METHOD_INFO` enum that requests to drop the method information.  If no method information is needed, a `StackWalker` with `DROP_METHOD_INFO`
> can be used instead and such stack walker will save the overhead of extracting the method information
> and the memory used for the stack walking.
> 
> New factory methods to take a parameter to specify the kind of stack walker to be created are defined.
> This provides a simple way for existing code, for example logging frameworks, to take advantage of
> this enhancement with the least change as it can keep the existing function for traversing
> `StackFrame`s.
> 
> For example: to find the first caller filtering a known list of implementation class,
> existing code can create a stack walker instance with `DROP_METHOD_INFO` option:
> 
> 
>      StackWalker walker = StackWalker.getInstance(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE);
>      Optional<Class<?>> callerClass = walker.walk(s ->
>              s.map(StackFrame::getDeclaringClass)
>               .filter(Predicate.not(implClasses::contains))
>               .findFirst());
> 
> 
> If method information is accessed on the `StackFrame`s produced by this stack walker such as
> `StackFrame::getMethodName`, then `UnsupportedOperationException` will be thrown.
> 
> #### Javadoc & specdiff
> 
> https://cr.openjdk.org/~mchung/api/java.base/java/lang/StackWalker.html
> https://cr.openjdk.org/~mchung/jdk22/specdiff/overview-summary.html
> 
> #### Alternatives Considered
> One alternative is to provide a new API:
> `<T> T walkClass(Function<? super Stream<Class<?>, ? extends T> function)`
> 
> In this case, the caller would need to pass a function that takes a stream
> of `Class` object instead of `StackFrame`.  Existing code would have to
> modify calls to the `walk` method to `walkClass` and the function body.
> 
> ### Implementation Details
> 
> A `StackWalker` configured with `DROP_METHOD_INFO` option creates `ClassFrameInfo[]`
> buffer that is filled by the VM during stack walking.   `Sta...

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge
 - Remove the new getInstance method taking varargs
 - update mode to be int rather than long
 - update tests
 - Review feedback on javadoc
 - Revised the API change.  Add Option::DROP_METHOD_INFO
 - Review feedback from Remi
 - fixup javadoc
 - Review feedback: move JLIA to ClassFrameInfo
 - review feedback and javadoc clean up
 - ... and 19 more: https://git.openjdk.org/jdk/compare/c8acab1d...111661bc

-------------

Changes: https://git.openjdk.org/jdk/pull/15370/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15370&range=08
  Stats: 1256 lines in 34 files changed: 690 ins; 276 del; 290 mod
  Patch: https://git.openjdk.org/jdk/pull/15370.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15370/head:pull/15370

PR: https://git.openjdk.org/jdk/pull/15370

From pchilanomate at openjdk.org  Thu Aug 31 17:39:02 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Aug 2023 17:39:02 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
In-Reply-To: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
References: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
Message-ID: <dPfUi78lJPKpkYzTR8feFaSlSh0HxHz8jp1Bqg7ZIGg=.31531fb6-0837-4c81-aaf1-4f5033ff0f5b@github.com>

On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM.
> 
> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition.
> 
> Testing: tier1-5

Looks good to me.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15492#pullrequestreview-1605291739

From pchilanomate at openjdk.org  Thu Aug 31 17:39:04 2023
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Aug 2023 17:39:04 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
In-Reply-To: <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>
References: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
 <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>
Message-ID: <n8-PKjzdsm-fDfTvRqQIAXvoblhkCxExxI3RqX0QqGQ=.6375eb64-f1f3-48b9-b031-18090450564a@github.com>

On Thu, 31 Aug 2023 10:37:26 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> In the virtual thread implementation, thread identity switches to the carrier before freezing and switches back to the virtual thread after thawing. This was a forced move due to issues getting JVMTI to work with virtual threads. JVMTI can now hide events during transitions so we can invert the sequence back to mounting before running the continuation, unmounting after freezing, and re-mounting after thawing. This sequence is important for future changes that will initiate the freezing from the VM.
>> 
>> The change requires an update to the JFR thread sampler to skip sampling when it samples during a transition.
>> 
>> Testing: tier1-5
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 415:
> 
>> 413:   } else {
>> 414:     assert(NATIVE_SAMPLE == type, "invariant");
>> 415:     if (thread_state_in_native(thread) && !is_vthread_in_transition(thread)) {
> 
> Is this possible? I assume the thread is in _thread_in_Java during the transition?

There are some native methods that we execute during mount/unmount transitions. From what I see they all seem to be defined as `@IntrinsicCandidate`, but if for some reason we don't execute the intrinsic version (interp only mode for instance) then we would call a normal native method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1311970316

From sviswanathan at openjdk.org  Thu Aug 31 18:32:02 2023
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Thu, 31 Aug 2023 18:32:02 GMT
Subject: RFR: 8314085: Fixing scope from benchmark to thread for JMH tests
 having shared state
In-Reply-To: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
References: <TcbapXQN7SL8uQQMtJ7fjfzXDnYL5Sc5Vbrew7GZb-k=.d497a964-ae89-4b0f-bd17-38c6b5f945f3@github.com>
Message-ID: <Hnm2J7fEH1J0DdTzsI3RO8ZhRcyNMzdS4Xt0tYvFF6s=.8661df64-679e-4c77-ab84-e76c16086ac7@github.com>

On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma <duke at openjdk.org> wrote:

> In addition to the issue [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing the scope from benchmark to thread for below benchmark files having shared state, also which fixes few of the benchmarks scalability problems.
> 
> org/openjdk/bench/java/io/DataInputStreamTest.java
> org/openjdk/bench/java/lang/ArrayClone.java
> org/openjdk/bench/java/lang/StringCompareToDifferentLength.java
> org/openjdk/bench/java/lang/StringCompareToIgnoreCase.java
> org/openjdk/bench/java/lang/StringComparisons.java
> org/openjdk/bench/java/lang/StringEquals.java
> org/openjdk/bench/java/lang/StringFormat.java
> org/openjdk/bench/java/lang/StringReplace.java
> org/openjdk/bench/java/lang/StringSubstring.java
> org/openjdk/bench/java/lang/StringTemplateFMT.java
> org/openjdk/bench/java/lang/constant/MethodTypeDescFactories.java
> org/openjdk/bench/java/lang/constant/ReferenceClassDescResolve.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesConstant.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesIdentity.java
> org/openjdk/bench/java/lang/invoke/MethodHandlesThrowException.java
> org/openjdk/bench/java/lang/invoke/MethodTypeAppendParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeParam.java
> org/openjdk/bench/java/lang/invoke/MethodTypeChangeReturn.java
> org/openjdk/bench/java/lang/invoke/MethodTypeDropParams.java
> org/openjdk/bench/java/lang/invoke/MethodTypeGenerify.java
> org/openjdk/bench/java/lang/invoke/MethodTypeInsertParams.java
> org/openjdk/bench/java/security/CipherSuiteBench.java
> org/openjdk/bench/java/time/GetYearBench.java
> org/openjdk/bench/java/time/InstantBench.java
> org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java
> org/openjdk/bench/java/util/ListArgs.java
> org/openjdk/bench/java/util/LocaleDefaults.java
> org/openjdk/bench/java/util/TestAdler32.java
> org/openjdk/bench/java/util/TestCRC32.java
> org/openjdk/bench/java/util/TestCRC32C.java
> org/openjdk/bench/java/util/regex/Exponential.java
> org/openjdk/bench/java/util/regex/Primality.java
> org/openjdk/bench/java/util/regex/Trim.java
> org/openjdk/bench/javax/crypto/AESReinit.java
> org/openjdk/bench/jdk/incubator/vector/LoadMaskedIOOBEBenchmark.java
> org/openjdk/bench/vm/compiler/Rotation.java
> org/openjdk/bench/vm/compiler/x86/ConvertF2I.java
> org/openjdk/bench/vm/compiler/x86/BasicRules.java
> 
> Please review and provide your feedback.
> 
> Thanks,
> Swati

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15230#pullrequestreview-1605442680

From duke at openjdk.org  Thu Aug 31 18:45:39 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 31 Aug 2023 18:45:39 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v31]
In-Reply-To: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
Message-ID: <gogztSVJ2BjpT7n__Iv2jiIjRrQWW3P8FQIkPeGXGPE=.021ab422-8f99-48d4-9399-8da61a1ee97d@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
> 
> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
> |	ArraysSort.longSort	|	1000	|	10.449	|	6.239	|	1.7	|
> |	ArraysSort.longSort	|	10000	|	307.074	|	70.284	|	**4.4**	|
> |	ArraysSor...

Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - update build script
 - Merge branch 'master' of https://git.openjdk.org/jdk into avx512sort
 - Clean up parameters passed to arrayPartition; update the check to load library
 - Remove unnecessary import in Arrays.java
 - Move sort and partition intrinsics from Arrays.java to DPQS.java
 - Fix unused assignment in DPQS.java and space in Arrays.java
 - add parallelSort benchmarking
 - Update copyright for DPQS.java; replace avx512 pivot calculation with scalar version
 - Update avx512-common-qsort.h
 - Decomposed DPQS using AVX512 partitioning and AVX512 sort (for small arrays). Works for serial and parallel sort.
 - ... and 22 more: https://git.openjdk.org/jdk/compare/c8acab1d...1746eedd

-------------

Changes: https://git.openjdk.org/jdk/pull/14227/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=30
  Stats: 3502 lines in 21 files changed: 2995 ins; 280 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/14227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14227/head:pull/14227

PR: https://git.openjdk.org/jdk/pull/14227

From duke at openjdk.org  Thu Aug 31 18:45:39 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 31 Aug 2023 18:45:39 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <3MsIs3kNxvxNOftvjnsisc7eWu6CEb-BbBsHJnj9SH4=.64c640da-61c4-49b2-9e19-02de020d2976@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H8S-sUP_B-wBoc-Gu-Zo_wEtiYeNSKlZto8djNsIX-Y=.8d060054-ec20-43e9-a965-fccc1689c44a@github.com>
 <3MsIs3kNxvxNOftvjnsisc7eWu6CEb-BbBsHJnj9SH4=.64c640da-61c4-49b2-9e19-02de020d2976@github.com>
Message-ID: <rdCLfJeMVIUT6Q3mfhFKXGD5_KQitlpgJwhRNJ5h0hs=.2d647b01-c7bf-4411-b2c7-7525cd23589b@github.com>

On Tue, 29 Aug 2023 17:00:33 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 240:
>> 
>>> 238: 
>>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
>>> 240:   $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \
>> 
>> As this is a C++ lib, consider using g++ for linking by setting:
>> 
>> TOOLCHAIN := TOOLCHAIN_LINK_CXX
>
> Thanks Erik. Will update Lib.gmk to use g++ for linking.

Please see the linking updated to use g++ in the latest commit.

>> make/modules/java.base/Lib.gmk line 247:
>> 
>>> 245:       LDFLAGS := $(LDFLAGS_JDKLIB) \
>>> 246:           $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> 247:       LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \
>> 
>> This is set by default since JDK-8314554.
>
> Thanks Erik. Will update Lib.gmk accordingly.

Based on your suggestion, please see the LDFLAGS_linux removed in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1312061806
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1312061283

From darcy at openjdk.org  Thu Aug 31 19:04:01 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 31 Aug 2023 19:04:01 GMT
Subject: RFR: 5066247: Refine the spec of equals() and hashCode() for
 j.text.Format classes
In-Reply-To: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>
References: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>
Message-ID: <xwqSp5fWDwcJSheWBoCKlRQmPfMesFWZdrg_lqZVoGs=.7d8d249e-5473-4f3b-be63-31ec34932cc5@github.com>

On Mon, 28 Aug 2023 21:24:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refines the spec of `equals()` and `hashCode()` in `java.text.Format` related classes.
> 
> The current spec for most of these methods is either  "_Overrides <method_name>_" or are incomplete/wrong (i.e. see `ChoiceFormat`).
> 
> This fix adjusts the spec to provide a consistent definition for the overridden methods and specify what is being compared/used to generate a hash code value.
> 
> For implementations that use at most a few fields, the values are stated, otherwise a more general term is used as a substitution (i.e. see `DecimalFormat`).

This class hierarchy is based around a getClass based notion of class identity rather than an instanceof notion of class identity. The drawbacks of doing this are discussed in "Effective Java, 3rd edition" item 10.

Regardless, getClass vs instanceof cannot be changed now for behavioral compatibility. However, this should be better documented so that subclass outside of the JDK could be written to do the right things in their own equals methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15459#issuecomment-1701599344

From alanb at openjdk.org  Thu Aug 31 19:32:06 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Aug 2023 19:32:06 GMT
Subject: RFR: 8315373: Change VirtualThread to unmount after freezing,
 re-mount before thawing
In-Reply-To: <n8-PKjzdsm-fDfTvRqQIAXvoblhkCxExxI3RqX0QqGQ=.6375eb64-f1f3-48b9-b031-18090450564a@github.com>
References: <vqo-PQd2vWAWa0RzdgY-E8HsG2MbiA559Tiw9YZQSsM=.c8f34138-7c14-423f-af76-dbe28e841512@github.com>
 <rs6IUJWyLbHfTjpVqIsVLJf7B9KmmuMY4gf7Y8TRZVs=.d94d75ef-934b-4796-8e9b-d962716245d4@github.com>
 <n8-PKjzdsm-fDfTvRqQIAXvoblhkCxExxI3RqX0QqGQ=.6375eb64-f1f3-48b9-b031-18090450564a@github.com>
Message-ID: <fNthuVUQc1U3y91IhCcSw1uLwwQBc1-ZsFIkc8AmRrk=.e56a280f-382a-4658-b105-dd2b91a14b63@github.com>

On Thu, 31 Aug 2023 17:31:34 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 415:
>> 
>>> 413:   } else {
>>> 414:     assert(NATIVE_SAMPLE == type, "invariant");
>>> 415:     if (thread_state_in_native(thread) && !is_vthread_in_transition(thread)) {
>> 
>> Is this possible? I assume the thread is in _thread_in_Java during the transition?
>
> There are some native methods that we execute during mount/unmount transitions. From what I see they all seem to be defined as `@IntrinsicCandidate`, but if for some reason we don't execute the intrinsic version (interp only mode for instance) then we would call a normal native method.

Just to ad that  Patricio suggested today to run the stress tests with -Xint and that does lead to triggered the assert quickly when the thread is sampled in native. There are several native methods that are @IntrinsicCandidate that are invoked after the thread identity has changed to the virtual thread and before the continuation is mounted. Probably less likely on the unmount as the only native method is the one that reverts the thread identity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15492#discussion_r1312128046

From erikj at openjdk.org  Thu Aug 31 19:43:18 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 31 Aug 2023 19:43:18 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v31]
In-Reply-To: <gogztSVJ2BjpT7n__Iv2jiIjRrQWW3P8FQIkPeGXGPE=.021ab422-8f99-48d4-9399-8da61a1ee97d@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <gogztSVJ2BjpT7n__Iv2jiIjRrQWW3P8FQIkPeGXGPE=.021ab422-8f99-48d4-9399-8da61a1ee97d@github.com>
Message-ID: <7md3I9bm2H5mJ5u4eVOmzAwk30cVVkpQM20OtiJY0CE=.b795aae3-0602-45d1-afee-f3590ba51432@github.com>

On Thu, 31 Aug 2023 18:45:39 GMT, Srinivas Vamsi Parasa <duke at openjdk.org> wrote:

>> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
>> 
>> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
>> 
>> 
>> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
>> 
>> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
>> |	---	|	---	|	---	|	---	|	---	|
>> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
>> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
>> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
>> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
>> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
>> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
>> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
>> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
>> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
>> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
>> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
>> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
>> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
>> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
>> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
>> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
>> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
>> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
>> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
>> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
>> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
>> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
>> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
>> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
>> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
>> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
>> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
>> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
>> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
>> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
>> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
>> |	ArraysSort.longSort	|	1000	|	10.449	|	6....
>
> Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - update build script
>  - Merge branch 'master' of https://git.openjdk.org/jdk into avx512sort
>  - Clean up parameters passed to arrayPartition; update the check to load library
>  - Remove unnecessary import in Arrays.java
>  - Move sort and partition intrinsics from Arrays.java to DPQS.java
>  - Fix unused assignment in DPQS.java and space in Arrays.java
>  - add parallelSort benchmarking
>  - Update copyright for DPQS.java; replace avx512 pivot calculation with scalar version
>  - Update avx512-common-qsort.h
>  - Decomposed DPQS using AVX512 partitioning and AVX512 sort (for small arrays). Works for serial and parallel sort.
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/c8acab1d...1746eedd

make/modules/java.base/Lib.gmk line 255:

> 253:         TARGETS += $(BUILD_LIB_X86_64)
> 254:   endif
> 255: endif

Indentation looks off here (https://openjdk.org/groups/build/doc/code-conventions.html)
Suggestion:

ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
  ifeq ($(TOOLCHAIN_TYPE), gcc)
    $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \
        NAME := x86_64, \
        TOOLCHAIN := TOOLCHAIN_LINK_CXX, \
        OPTIMIZATION := HIGH, \
        CFLAGS := $(CFLAGS_JDKLIB), \
        CXXFLAGS := $(CXXFLAGS_JDKLIB), \
        LDFLAGS := $(LDFLAGS_JDKLIB) \
            $(call SET_SHARED_LIBRARY_ORIGIN), \
        LIBS := $(LIBCXX), \
        LIBS_linux := -lc -lm -ldl, \
    ))

    TARGETS += $(BUILD_LIB_X86_64)
  endif
endif


I'm also still wondering about the library name. It's very generic for something that seems to be rather specific.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1312139279

From redestad at openjdk.org  Thu Aug 31 20:08:04 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 31 Aug 2023 20:08:04 GMT
Subject: RFR: 8310929: Optimization for Integer.toString [v13]
In-Reply-To: <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
References: <81FMblrGtwta64LkyHKMk5oRHc0Vp49fj-Kt-92ZFLM=.9888c096-7266-4416-ba38-f5bd0ef642c7@github.com>
 <Q40yhMfrkRyDx5Zfz_y6UUPXTspFUMWQuo_BPl9Dc8U=.ff88f1af-07b6-4a8f-b916-a2e4dd97f21d@github.com>
Message-ID: <mWSqYQT4ZWVh-bdtnXLKwxRNLjpd7PwJiOgjTO_IqdA=.b7798e30-0936-47e8-aed7-8bb30838d702@github.com>

On Tue, 18 Jul 2023 01:49:17 GMT, ??? <duke at openjdk.org> wrote:

>> Optimization for:
>> Integer.toString
>> Long.toString
>> StringBuilder#append(int)
>> 
>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.Integers.toString*" 
>> make test TEST="micro:java.lang.Longs.toString*" 
>> make test TEST="micro:java.lang.StringBuilders.toStringCharWithInt8"
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.825 ? 0.023  us/op
>> -Integers.toStringSmall     500  avgt   15  4.823 ? 0.023  us/op
>> -Integers.toStringTiny      500  avgt   15  3.878 ? 0.101  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  6.002 ? 0.054  us/op (+13.71%)
>> +Integers.toStringSmall     500  avgt   15  4.025 ? 0.020  us/op (+19.82%)
>> +Integers.toStringTiny      500  avgt   15  3.874 ? 0.067  us/op (+0.10%)
>> 
>> -Benchmark            (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Longs.toStringBig       500  avgt   15  9.224 ? 0.021  us/op
>> -Longs.toStringSmall     500  avgt   15  4.621 ? 0.087  us/op
>> 
>> +Benchmark            (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Longs.toStringBig       500  avgt   15  7.483 ? 0.018  us/op (+23.26%)
>> +Longs.toStringSmall     500  avgt   15  4.020 ? 0.016  us/op (+14.95%)
>> 
>> -Benchmark                           Mode  Cnt     Score    Error  Units (baseline)
>> -StringBuilders.toStringCharWithInt8 avgt   15    89.327 ?  0.733  ns/op
>> 
>> +Benchmark                            Mode  Cnt   Score   Error  Units (PR Update 04 f4aa1989)
>> +StringBuilders.toStringCharWithInt8  avgt   15  36.639 ? 0.422  ns/op (+143.80%)
>> 
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark               (size)  Mode  Cnt  Score   Error  Units (baseline)
>> -Integers.toStringBig       500  avgt   15  6.753 ? 0.007  us/op
>> -Integers.toStringSmall     500  avgt   15  4.470 ? 0.005  us/op
>> -Integers.toStringTiny      500  avgt   15  2.764 ? 0.020  us/op
>> 
>> +Benchmark               (size)  Mode  Cnt  Score   Error  Units (PR Update 04 f4aa1989)
>> +Integers.toStringBig       500  avgt   15  5.036 ? 0.005  us/op (+...
>
> ??? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   assert bounds check

While I share the wariness against lookup tables (and the microbenchmarks that lend them too much credence), I think the approach in this PR is mostly an incremental improvement on an existing design and should be evaluated as such. By packing two lookup tables into one we reduce the opportunity for cache misses. The new lookup table is no larger as the two existing ones, so we're not wasting memory or sacrificing density. Having it in a single table makes it less likely that the arrays will end up in different locations on the heap or in compiled code. I see mostly positives here.

The main drawback is the proliferation of `Unsafe` usage.

Switching out the lookup table-based algorithm for something clever without a lookup table is laudable, but comes with a new set of challenges and should be done as a follow up. Since these tables can be aggressively constant-folded into the code section by our JITs it might even turn out to be a wash. 

If @RogerRiggs is happy with asserts in lieu of explicit bounds checking then I move to approve this.

src/java.base/share/classes/java/lang/StringUTF16.java line 1585:

> 1583:                     buf,
> 1584:                     Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1),
> 1585:                     PACKED_DIGITS_UTF16[r]);

What performance would you get if you used the same lookup table as the other implementations, but inflate the value to UTF-16 on the fly?


int packed = (int)Integer.PACKED_DIGITS[r];
int inflated = ((packed & 0xFF00) << 8) & (packed & 0xFF));
UNSAFE.putIntUnaligned(
                    buf,
                    Unsafe.ARRAY_BYTE_BASE_OFFSET + (charPos << 1),
                    inflated);


This would avoid juggling more lookup table data around than before, alleviating some of the concerns voiced in this PR comment thread.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14699#pullrequestreview-1605608821
PR Review Comment: https://git.openjdk.org/jdk/pull/14699#discussion_r1312156127

From aturbanov at openjdk.org  Thu Aug 31 20:13:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 31 Aug 2023 20:13:09 GMT
Subject: Integrated: 8312521: Unused field
 LocaleProviderAdapter#defaultLocaleProviderAdapter could be removed
In-Reply-To: <V8wbOFhzUYfyrMj6Q7UUvyb88QxfwxPgkY0J0T6-wxo=.18ed1683-f57c-4bcc-8037-88d1e1e558b4@github.com>
References: <V8wbOFhzUYfyrMj6Q7UUvyb88QxfwxPgkY0J0T6-wxo=.18ed1683-f57c-4bcc-8037-88d1e1e558b4@github.com>
Message-ID: <_CMDvItq5vBz2bK6Aho2dlRjywhpenRyoF0-AFTGJi0=.601dba4f-f9a6-4e62-a97d-5da291848ca9@github.com>

On Tue, 22 Aug 2023 12:22:54 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> After [JDK-8245241](https://bugs.openjdk.org/browse/JDK-8245241), the field `sun.util.locale.provider.LocaleProviderAdapter#defaultLocaleProviderAdapter` is only written in `<clinit>` and then is not used after.
> We can remove it.

This pull request has now been integrated.

Changeset: c12ca885
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c12ca885cc96b510c9ee2d54b520b7d4a98a0434
Stats:     11 lines in 1 file changed: 0 ins; 8 del; 3 mod

8312521: Unused field LocaleProviderAdapter#defaultLocaleProviderAdapter could be removed

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15388

From duke at openjdk.org  Thu Aug 31 20:37:19 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 31 Aug 2023 20:37:19 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v32]
In-Reply-To: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
Message-ID: <AN9IPCmoHHg2v5Q6U3sw7lzJ_bUUqJQ5-Gmj2k2Gtek=.deb4d94a-869a-42a6-b3fa-4d993b51aec9@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
> 
> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
> |	ArraysSort.longSort	|	1000	|	10.449	|	6.239	|	1.7	|
> |	ArraysSort.longSort	|	10000	|	307.074	|	70.284	|	**4.4**	|
> |	ArraysSor...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Update make/modules/java.base/Lib.gmk
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/1746eedd..a0f006b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=30-31

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14227/head:pull/14227

PR: https://git.openjdk.org/jdk/pull/14227

From duke at openjdk.org  Thu Aug 31 21:31:40 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 31 Aug 2023 21:31:40 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v33]
In-Reply-To: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
Message-ID: <V34vA-CPtip4nlJQruNRPtXv-eZTW1qeynPzCmOH2sM=.8b50265e-e57d-4664-b07d-2d106788987b@github.com>

> The goal is to develop faster sort routines for x86_64 CPUs by taking advantage of AVX512 instructions. This enhancement provides an order of magnitude speedup for Arrays.sort() using int, long, float and double arrays.
> 
> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the performance data below.
> 
> 
> **Arrays.sort performance data using JMH benchmarks for arrays with random data** 
> 
> |	Arrays.sort benchmark	|	Array Size	|	Baseline (us/op)	|	AVX512 Sort (us/op)	|	Speedup	|
> |	---	|	---	|	---	|	---	|	---	|
> |	ArraysSort.doubleSort	|	10	|	0.034	|	0.035	|	1.0	|
> |	ArraysSort.doubleSort	|	25	|	0.116	|	0.089	|	1.3	|
> |	ArraysSort.doubleSort	|	50	|	0.282	|	0.291	|	1.0	|
> |	ArraysSort.doubleSort	|	75	|	0.474	|	0.358	|	1.3	|
> |	ArraysSort.doubleSort	|	100	|	0.654	|	0.623	|	1.0	|
> |	ArraysSort.doubleSort	|	1000	|	9.274	|	6.331	|	1.5	|
> |	ArraysSort.doubleSort	|	10000	|	323.339	|	71.228	|	**4.5**	|
> |	ArraysSort.doubleSort	|	100000	|	4471.871	|	1002.748	|	**4.5**	|
> |	ArraysSort.doubleSort	|	1000000	|	51660.742	|	12921.295	|	**4.0**	|
> |	ArraysSort.floatSort	|	10	|	0.045	|	0.046	|	1.0	|
> |	ArraysSort.floatSort	|	25	|	0.103	|	0.084	|	1.2	|
> |	ArraysSort.floatSort	|	50	|	0.285	|	0.33	|	0.9	|
> |	ArraysSort.floatSort	|	75	|	0.492	|	0.346	|	1.4	|
> |	ArraysSort.floatSort	|	100	|	0.597	|	0.326	|	1.8	|
> |	ArraysSort.floatSort	|	1000	|	9.811	|	5.294	|	1.9	|
> |	ArraysSort.floatSort	|	10000	|	323.955	|	50.547	|	**6.4**	|
> |	ArraysSort.floatSort	|	100000	|	4326.38	|	731.152	|	**5.9**	|
> |	ArraysSort.floatSort	|	1000000	|	52413.88	|	8409.193	|	**6.2**	|
> |	ArraysSort.intSort	|	10	|	0.033	|	0.033	|	1.0	|
> |	ArraysSort.intSort	|	25	|	0.086	|	0.051	|	1.7	|
> |	ArraysSort.intSort	|	50	|	0.236	|	0.151	|	1.6	|
> |	ArraysSort.intSort	|	75	|	0.416	|	0.332	|	1.3	|
> |	ArraysSort.intSort	|	100	|	0.63	|	0.521	|	1.2	|
> |	ArraysSort.intSort	|	1000	|	10.518	|	4.698	|	2.2	|
> |	ArraysSort.intSort	|	10000	|	309.659	|	42.518	|	**7.3**	|
> |	ArraysSort.intSort	|	100000	|	4130.917	|	573.956	|	**7.2**	|
> |	ArraysSort.intSort	|	1000000	|	49876.307	|	6712.812	|	**7.4**	|
> |	ArraysSort.longSort	|	10	|	0.036	|	0.037	|	1.0	|
> |	ArraysSort.longSort	|	25	|	0.094	|	0.08	|	1.2	|
> |	ArraysSort.longSort	|	50	|	0.218	|	0.227	|	1.0	|
> |	ArraysSort.longSort	|	75	|	0.466	|	0.402	|	1.2	|
> |	ArraysSort.longSort	|	100	|	0.76	|	0.58	|	1.3	|
> |	ArraysSort.longSort	|	1000	|	10.449	|	6.239	|	1.7	|
> |	ArraysSort.longSort	|	10000	|	307.074	|	70.284	|	**4.4**	|
> |	ArraysSor...

Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Change name of the avxsort library to libx86_64_sort

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14227/files
  - new: https://git.openjdk.org/jdk/pull/14227/files/a0f006b6..0ec5f52d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14227&range=31-32

  Stats: 18 lines in 7 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/14227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14227/head:pull/14227

PR: https://git.openjdk.org/jdk/pull/14227

From duke at openjdk.org  Thu Aug 31 21:34:58 2023
From: duke at openjdk.org (Srinivas Vamsi Parasa)
Date: Thu, 31 Aug 2023 21:34:58 GMT
Subject: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods
 (int, long, float and double arrays) [v30]
In-Reply-To: <H8S-sUP_B-wBoc-Gu-Zo_wEtiYeNSKlZto8djNsIX-Y=.8d060054-ec20-43e9-a965-fccc1689c44a@github.com>
References: <W6gQD2_qb5CFHrkL8L0tr_7U896Hi45EKpXELXJLTJY=.67a41842-f995-46e7-abb7-a464011e8610@github.com>
 <2pgGFUpvYiaaQ0Oj81o5YPjTHOOYWhE26H0VJzVgyIE=.50633006-98e5-4258-8629-b883652cddc7@github.com>
 <H8S-sUP_B-wBoc-Gu-Zo_wEtiYeNSKlZto8djNsIX-Y=.8d060054-ec20-43e9-a965-fccc1689c44a@github.com>
Message-ID: <hT59UdIu8xcLH9_r4s3eKEWmIp3elvjXrnmlpYtGjOM=.3631858b-a372-46f8-8c66-ecba83caf842@github.com>

On Mon, 28 Aug 2023 23:29:43 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up parameters passed to arrayPartition; update the check to load library
>
> make/modules/java.base/Lib.gmk line 241:
> 
>> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64)+$(INCLUDE_COMPILER2), true+true+true)
>> 240:   $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \
>> 241:       NAME := x86_64, \
> 
> This looks like a rather generic name for a library. I would expect something a bit more descriptive. 
> 
> I also noted that @vnkozlov questioned needing a separate library for this and I didn't really find an answer. What do we gain from separating this into a separate dynamic library?

Hi Erik, 
As per your suggestion, the name of the library is updated to `libx86_64_sort`. Thank you for fixing the indentation in the build script! 
Please see the changes in the latest commit that was pushed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1312308146

From jlu at openjdk.org  Thu Aug 31 21:45:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Aug 2023 21:45:46 GMT
Subject: Integrated: 6333341: [BI] Doc: java.text.BreakIterator class
 specification is unclear
In-Reply-To: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
References: <mKAWPEZ8qwCwhfPgMX18_j0c4vpBP3vmnleBnz1-hV4=.252f957e-a2fc-4f26-96f4-b8e9c6dac9ae@github.com>
Message-ID: <G_4sL8jw5ols2crZFJnd_vdlH7Uaf8RKRME-S33lFWU=.9c1b7222-d4aa-4cbd-b023-9336a4bdc774@github.com>

On Thu, 24 Aug 2023 21:39:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR ](https://bugs.openjdk.org/browse/JDK-8314974)which clarifies behavior for BreakIterator instances when text has not been set.
> 
> For example,  calling `BreakIterator.getWordInstance().next();` has an ambiguous result.
> A boundary searching operation was called but no text was supplied. Is the result an exception, 0, -1 (BreakIterator.DONE), or something else? In reality, the operation will be performed on any empty string.
> 
> 
> This change makes it apparent that failing to set the text will cause the BreakIterator instance to default to a `StringCharacterIterator` with an empty string (equivalent to calling setText("")).

This pull request has now been integrated.

Changeset: d5973bdb
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5973bdb986a1dd823b6a761ff719de005c549f6
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

6333341: [BI] Doc: java.text.BreakIterator class specification is unclear

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15422

From aefimov at openjdk.org  Thu Aug 31 22:55:44 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Thu, 31 Aug 2023 22:55:44 GMT
Subject: RFR: 8277954: Replace use of monitors with explicit locks in the JDK
 LDAP provider implementation
Message-ID: <sHulVzvrpkTnsdsi1fy5FoA0AGUhBR4-esl0fLHVLKI=.32b11d77-f9e3-431e-b7e7-64416b60661c@github.com>

The change proposed in this PR improves the behavior of the JDK JNDI/LDAP provider when running in a virtual thread. Currently, when an LDAP operation is performed from a virtual thread context a pinned carrier thread is detected:

     Thread[#29,ForkJoinPool-1-worker-1,5,CarrierThreads]
        java.naming/com.sun.jndi.ldap.Connection.read reply(Connection.java:444) <== monitors:1
        java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:369) <== monitors:1
        java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:196) <== monitors:1
        java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2896) <== monitors:1

To fix that monitor usages are replaced with `j.u.c` locks. All synchronized blocks/methods have been replaced with locks even if it is only guarding memory access - the motivation behind such a decision was to avoid an analysis of scenarios where a mix of monitors and `j.u.c` locks is used.

There are three types of mechanical changes done in this PR:

1. Classes with `synchronized` blocks or `synchronized` methods have been updated to include a new `ReentrantLock` field. These new fields are used to replace `synchronized` blocks/methods.
1. classes that use notify/wait on object monitor have been updated to use `ReentrantLock.Condition`s signal/await.
1. if one class `synchronized` on an instance of another class - the `ReentrantLock` added in item (1) was made a package-protected to give access to another class.

With the proposed changes pinned carrier threads are no longer detected during execution of LDAP operations. 

Testing: `jdk-tier1` to `jdk-tier3`, other `jndi/ldap` regression and JCK naming tests show no failures.

-------------

Commit messages:
 - revert incorrect changes in LdapCtx.addNamingListener, formatting and (c) updates
 - draft version

Changes: https://git.openjdk.org/jdk/pull/15526/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15526&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277954
  Stats: 970 lines in 11 files changed: 394 ins; 101 del; 475 mod
  Patch: https://git.openjdk.org/jdk/pull/15526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15526/head:pull/15526

PR: https://git.openjdk.org/jdk/pull/15526

From jlu at openjdk.org  Thu Aug 31 23:05:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Aug 2023 23:05:48 GMT
Subject: Integrated: 8314925: ChoiceFormat does not specify
 IllegalArgumentExceptions
In-Reply-To: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>
References: <SATHizRvBNgFv9_2bz4kXV9KuarxbI1LjC6isB2uunE=.ea885296-11d3-49fa-9194-13a750fecf68@github.com>
Message-ID: <IzBZB94pYPzUFUhb6jiBmgSdx5fcpFCPHu5pwXtqYNU=.5c2eb316-2b73-4ade-bc19-a5b2b08b0b4d@github.com>

On Tue, 29 Aug 2023 16:53:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315148) which is a conformance change to specify exceptions in java.text.ChoiceFormat.
> 
> Makes `IllegalArgumentException` apparent for `applyPattern` and `setChoices`, as well as for the associated constructors that call the methods.
> 
> This change also improves the error message for the `setChoices` IAE.

This pull request has now been integrated.

Changeset: 7754ac05
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7754ac05062c698b8601048ae447849d982c8dbe
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8314925: ChoiceFormat does not specify IllegalArgumentExceptions

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/15473