Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]

On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: RFR: 8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs

On Fri, 19 Apr 2024 23:56:00 GMT, ExE Boss wrote: >> We can reduce overhead of first use of a switch bootstrap by moving >> `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` >> and `equals`. The first change avoids loading and initializing the >> `TypePairs` class in

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Turned out this whole time I was only replying to David. I have to thank him for his patience explaining me how this whole mailing thing work. To summarize what has been missed out, besides what have you seen in quotes. I have pointed out that, while flexibility and simplicity is important, the

Re: RFR: 8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad wrote: > We can reduce overhead of first use of a switch bootstrap by moving > `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and > `equals`. The first change avoids loading and initializing the `TypePairs` > class in

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

> That was what i referred to as "Map-solvable" problems, > but if this way of doing it is a thing, then I agree with > the point. Doing it the Map way would not only be slower, but it would force you to include more concepts than you need. Your identifier is your index. Lists/arrays have index.

Re: Integrated: 8295111: dpkg appears to have problems resolving symbolically linked native libraries

I was apparently at least partly misunderstanding this. I thought I verified a missing file on one exception trace. I installed what appeared to be missing packages and that one no longer shows up. I still get exception traces on some .so files which appear to be reporting errors on dpkg -S

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

> I think that, while finding the index of a matching > element is not a very common task, especially among > commercial developers, when discussing indexed streams, > this would be the most common use case. To be honest, I > don't even see any other use cases right now, besides > maybe some

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

> Any stream can be "indexed", having an index is not an > intrisinc property of a stream of List, so adding an > index is more an intermediate operation than a source > operation. > > So more like > list.stream().withIndex() > than like > list.streamWithIndex() I will start of by conceding

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]

On Fri, 19 Apr 2024 22:08:52 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]

On Fri, 19 Apr 2024 20:58:43 GMT, Vladimir Kozlov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2638: >> >>> 2636:L_exit, _masm); >>> 2637: } >>> 2638: __ jmp(L_exit); >> >> Here is long jump to `L_exit` after

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]

On Fri, 19 Apr 2024 20:53:31 GMT, Vladimir Kozlov wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments > > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2550: > >> 2548: >> 2549: //

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v24]

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See > [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around > this change. > > Overall, making this an intrinsic improves overall performance of > `Unsafe::setMemory` by up to 4x for all buffer sizes.

Re: RFR: 8330542: Add two sample configuration files in preparation for a more secure by default configuration [v3]

On Fri, 19 Apr 2024 20:45:36 GMT, Lance Andersen wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> fix typo > > src/java.xml/share/conf/jaxp-compat.properties line 20: > >> 18: # JDK has switched to a strict

Re: RFR: 8330542: Add two sample configuration files in preparation for a more secure by default configuration [v4]

> Add two sample configuration files: > > jaxp-strict.properties: used to set strict configuration, stricter than > jaxp.properties in previous versions such as JDK 22 > > jaxp-compat.properties: used to regain compatibility from any more > restricted configuration than previous versions

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

> From: "David Alayachew" > To: "Remi Forax" > Cc: "ІП-24 Олександр Ротань" , "core-libs-dev" > > Sent: Friday, April 19, 2024 11:02:12 PM > Subject: Re: Addition of Predicate-based findIndex and findLastIndex methods > to > java.util.List > No Rémi, I don't think your idea is the right

Re: RFR: 8329760: Add indexOf(Predicate filter) to java.util.List interface [v11]

On Fri, 19 Apr 2024 15:49:11 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

It is not the goal of Java to be verbose, but it is also not the goal of Java to be concise either. It is the goal of Java to be clear, correct, and readable, in order to maximize maintainability, correctness, and flexibility. When you focus on accomplishing that goal first, you will find that

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Thanks for the advice. Indeed, it was a mistake to implement this before discussing it in mail. This is my first open-source experience, so i guess this will be a valuable experience for my future contributions сб, 20 апр. 2024 г. в 00:12, David Alayachew : > Hello > > Thanks for sending this

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Hello Thanks for sending this email. Your idea makes a lot of sense, but I feel that it only serves a very specific use case. That does not make it bad, but it does make it narrow. I already suggested my idea in my email to Rémi, where the index is just another field in the data type being

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]

On Fri, 19 Apr 2024 20:54:32 GMT, Vladimir Kozlov wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comments > > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2638: > >> 2636:

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]

On Fri, 19 Apr 2024 20:13:03 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

On Fri, 19 Apr 2024 20:38:05 GMT, Naoto Sato wrote: > OK, fair enough. Approving for the `icu` part Thank you. - PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067280359

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

No Rémi, I don't think your idea is the right approach. You are working on the wrong level of abstraction. Many users ask requests like this all the time, and what you are suggesting would be even more error-prone than the equivalent for loop or the IntStream suggestion that the user above

Re: RFR: 8330542: Add two sample configuration files in preparation for a more secure by default configuration [v3]

On Fri, 19 Apr 2024 17:39:30 GMT, Joe Wang wrote: >> Add two sample configuration files: >> >> jaxp-strict.properties: used to set strict configuration, stricter than >> jaxp.properties in previous versions such as JDK 22 >> >> jaxp-compat.properties: used to regain compatibility from any

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons wrote: >> Please review a set of updates to clean up use of `/**` comments in the >> vicinity of declarations. >> >> There are various categories of update: >> >> * "Box comments" beginning with `/**` >> * Misplaced doc comments before

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

On Fri, 19 Apr 2024 19:47:20 GMT, Naoto Sato wrote: > Unless it is absolutely necessary, I would not fix comments in > `jdk.internal.icu` sources, as they are in the upstream code, and would like > to minimize the merging effort. @naotoj Given the policy and strong desire to compile

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Fri, 19 Apr 2024 19:18:13 GMT, Scott Gibbons wrote: >> src/hotspot/share/opto/runtime.cpp line 786: >> >>> 784: fields[argp++] = TypePtr::NOTNULL;// dest >>> 785: fields[argp++] = TypeLong::LONG; // size >>> 786: fields[argp++] = Type::HALF; // size >> >> Since the

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Fri, 19 Apr 2024 18:16:33 GMT, Vladimir Kozlov wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add enter() and leave(); remove Windows-specific register stuff > > src/hotspot/share/utilities/copy.hpp line 303:

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Fri, 19 Apr 2024 15:50:05 GMT, Jorn Vernee wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add enter() and leave(); remove Windows-specific register stuff > >

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]

On Fri, 19 Apr 2024 17:42:36 GMT, Jorn Vernee wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address review comments; update copyright years > > src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2523:

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Fri, 19 Apr 2024 18:14:05 GMT, Vladimir Kozlov wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 4013: >> >>> 4011: // Initialize table for unsafe copy memeory check. >>> 4012: if (UnsafeMemoryAccess::_table == nullptr) { >>> 4013: UnsafeMemoryAccess::create_table(26); >>

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]

On Fri, 19 Apr 2024 18:25:17 GMT, Vladimir Kozlov wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address review comments; update copyright years > > General comment/suggestion before I dive into review. > Can we

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v23]

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See > [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around > this change. > > Overall, making this an intrinsic improves overall performance of > `Unsafe::setMemory` by up to 4x for all buffer sizes.

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons wrote: >> Please review a set of updates to clean up use of `/**` comments in the >> vicinity of declarations. >> >> There are various categories of update: >> >> * "Box comments" beginning with `/**` >> * Misplaced doc comments before

Re: RFR: 8329581: Java launcher no longer prints a stack trace [v3]

> Hi folks, > > This PR aims to fix > [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). > > I think the regression got introduced in > [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). > > In the issue linked above, >

Re: RFR: 8329581: Java launcher no longer prints a stack trace

On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles wrote: > Hi folks, > > This PR aims to fix > [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). > > I think the regression got introduced in > [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). > > In the issue

Re: RFR: 8329581: Java launcher no longer prints a stack trace [v2]

> Hi folks, > > This PR aims to fix > [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581). > > I think the regression got introduced in > [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458). > > In the issue linked above, >

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Fri, 19 Apr 2024 19:18:31 GMT, Jonathan Gibbons wrote: > We do not have an overall style guide. The conventional wisdom for editing > any existing file is to follow the style in that file, if such a style can be > discerned. That's what I do. I saw either style used in JDK. Yet I didn't

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons wrote: >> Please review a set of updates to clean up use of `/**` comments in the >> vicinity of declarations. >> >> There are various categories of update: >> >> * "Box comments" beginning with `/**` >> * Misplaced doc comments before

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Fri, 19 Apr 2024 11:32:55 GMT, Pavel Rappo wrote: > This comment is not a review. I simply use the opportunity provided by this > PR to suggest that we stop making new `/** ... */` and separately fix old > jtreg comments like this: > > ``` > /** > * @test TestSmallHeap > * @bug 8067438

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

> Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or import statements > * Misplaced doc comments after the

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base` [v2]

On Fri, 19 Apr 2024 10:49:11 GMT, Alexey Ivanov wrote: >> Jonathan Gibbons has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update >> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java >> >> Fix

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote: > Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Fri, 19 Apr 2024 10:44:27 GMT, Alexey Ivanov wrote: >> Please review a set of updates to clean up use of `/**` comments in the >> vicinity of declarations. >> >> There are various categories of update: >> >> * "Box comments" beginning with `/**` >> * Misplaced doc comments before package

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Fri, 19 Apr 2024 10:53:11 GMT, Alexey Ivanov wrote: >> Please review a set of updates to clean up use of `/**` comments in the >> vicinity of declarations. >> >> There are various categories of update: >> >> * "Box comments" beginning with `/**` >> * Misplaced doc comments before package

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]

On Fri, 19 Apr 2024 16:25:28 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Fri, 19 Apr 2024 15:43:17 GMT, Jorn Vernee wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add enter() and leave(); remove Windows-specific register stuff > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line

Re: Integrated: 8295111: dpkg appears to have problems resolving symbolically linked native libraries

I don’t know what flavors you are looking to support but there seems to be somewhat different issues on a Raspberry Pi. I was just trying to use jpackage there. I am getting errors like the command dpkg -S /lib/aarch64-linux-gnu/libXau.so .6 The file isn’t found These

Withdrawn: 8326617: String Template FMT removes unnecessary int to long type cast

On Mon, 2 Oct 2023 23:05:29 GMT, Shaojin Wen wrote: > In the current version, FMT."v =%d{1}" will call the > StringConcatHelper.prepend(long/byte[]/long) method, which should behave the > same as STR."v ={1}". Call StringConcatHelper.prepend(long/byte[]/int), > should not convert int to long

Withdrawn: 8327425: String Template FMT Refactor use call direct instead of MethodHandle

On Tue, 3 Oct 2023 06:19:11 GMT, Shaojin Wen wrote: > Currently FormatItem uses MethodHandler to handle latin1 and utf16, which is > not readable. This PR uses direct calls instead of MethodHandle. > > Please review and don't hesitate to critique my approach and patch. This pull request has

Withdrawn: 8327429: String Template FMT built-in optimization for DateTimes

On Wed, 4 Oct 2023 22:30:42 GMT, Shaojin Wen wrote: > # Goal > Improve String Template FMT's processing performance of date types. > Currently, FMT processes date types by toString and then calls > j.u.Formatter#print. Because there is less parse processing than > String.format, the

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]

On Fri, 19 Apr 2024 16:25:28 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Hello, for me, it seems what you want is Collector on Stream which is able to short-circuit, so you can write list.stream().collect(Collectors.findFirst(s -> s.contains("o"))) and in reverse list.reversed().stream().collect(Collectors.findFirst(s -> s.contains("o"))) Using a Stream here is

Re: RFR: 8330542: Add two sample configuration files in preparation for a more secure by default configuration [v2]

On Thu, 18 Apr 2024 23:40:22 GMT, Naoto Sato wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add description of the three configuration files. > > src/java.xml/share/conf/jaxp-strict.properties line 2: > >> 1: >>

Re: RFR: 8330542: Add two sample configuration files in preparation for a more secure by default configuration [v3]

> Add two sample configuration files: > > jaxp-strict.properties: used to set strict configuration, stricter than > jaxp.properties in previous versions such as JDK 22 > > jaxp-compat.properties: used to regain compatibility from any more > restricted configuration than previous versions

Re: RFR: 8328481: Implement Module Imports [v11]

On Fri, 19 Apr 2024 13:17:18 GMT, Jan Lahoda wrote: >> This is an implementation of JEP JDK-8315129: Module Import Declarations >> (Preview). Please see the JEP for details: >> https://bugs.openjdk.org/browse/JDK-8315129 >> >> It is mostly straightforward - the module imports are parsed, and

Re: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v3]

On Fri, 19 Apr 2024 07:42:19 GMT, Claes Redestad wrote: >> Investigating a recent regression in mainline I realized we have an >> opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap >> by using `invokeExact` in a way similar to what we already do for LMF and >> SCF

Re: RFR: 8329581: Java launcher no longer prints a stack trace

On Thu, 18 Apr 2024 20:41:05 GMT, Sonia Zaldana Calles wrote: > Just to clarify, this would still mean converting “isStatic” and “noArgs” > from local variables to fields so I am able to read them on the C side of > things. Did I understand this correctly? I'm okay with adding static boolean

Re: RFR: 8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad wrote: > We can reduce overhead of first use of a switch bootstrap by moving > `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and > `equals`. The first change avoids loading and initializing the `TypePairs` > class in

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v22]

> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See > [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around > this change. > > Overall, making this an intrinsic improves overall performance of > `Unsafe::setMemory` by up to 4x for all buffer sizes.

Addition of Predicate-based findIndex and findLastIndex methods to java.util.List

Subject Addition of Predicate-based findIndex and findLastIndex methods to java.util.List Motivation The motivation behind this proposal is to enhance the functionality of the List interface by providing a more flexible way to find the index of an element. Currently, the indexOf and lastIndexOf

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v10]

On Fri, 19 Apr 2024 15:39:12 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v9]

On Fri, 19 Apr 2024 14:11:20 GMT, Roger Riggs wrote: >> Evemose has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update Vector.java > > Please revert the formatting as soon as possible; its noise as far as > reviewers are concerned. >

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v11]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v10]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Fri, 19 Apr 2024 13:25:33 GMT, Jatin Bhateja wrote: >> Scott Gibbons has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add enter() and leave(); remove Windows-specific register stuff > >

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v9]

On Fri, 19 Apr 2024 12:59:24 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more

Re: RFR: 8324651: Compiler Implementation for Derived Record Creation (Preview) [v11]

> This is a patch for javac, that adds the Derived Record Creation expressions. > The current draft specification for the feature is: > https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html > > The current CSR is here: >

Re: RFR: 8329331: Intrinsify Unsafe::setMemory [v21]

On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons wrote: >> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See >> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around >> this change. >> >> Overall, making this an intrinsic improves overall

Re: RFR: 8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs

On Fri, 19 Apr 2024 13:23:53 GMT, Claes Redestad wrote: > We can reduce overhead of first use of a switch bootstrap by moving > `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and > `equals`. The first change avoids loading and initializing the `TypePairs` > class in

RFR: 8330681: Explicit hashCode and equals for java.lang.runtime.SwitchBootstraps$TypePairs

We can reduce overhead of first use of a switch bootstrap by moving `typePairToName` into `TypePairs` and by explicitly overriding `hashCode` and `equals`. The first change avoids loading and initializing the `TypePairs` class in actual cases, the second remove some excess code generation from

Re: RFR: 8328481: Implement Module Imports [v11]

> This is an implementation of JEP JDK-8315129: Module Import Declarations > (Preview). Please see the JEP for details: > https://bugs.openjdk.org/browse/JDK-8315129 > > It is mostly straightforward - the module imports are parsed, and then > expanded to import-on-demand in `TypeEnter`. > There

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v9]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v8]

On Fri, 19 Apr 2024 12:47:12 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v8]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v2]

On Fri, 19 Apr 2024 12:10:34 GMT, Chen Liang wrote: >> @minborg Sorry to bother you with this kind of question, but i cant manage >> to find where exactly and how I can file CSR review request. Could you help >> me out? > > @Evemose Please revert formatting changes in existing classes.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v7]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v2]

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose wrote: > but i cant manage to find where exactly and how I can file CSR review > request. Could you help me out? I think you can ignore CSR for now, the first step when proposing an API in this area is to start a discussion on core-libs-dev to make

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v6]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v2]

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose wrote: >> Adding (default) methods to `List` would have significant compatibility >> ramifications. Also, the PR needs to contain significant testing of the new >> proposed methods. > > @minborg Sorry to bother you with this kind of question, but i

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v5]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v4]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v3]

> **Subject** > Addition of Predicate-based `indexOf` and `lastIndexOf` methods to > `java.util.List` > > **Motivation** > The motivation behind this proposal is to enhance the functionality of the > `List` interface by providing a more flexible way to find the index of an > element.

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v2]

On Fri, 19 Apr 2024 11:33:59 GMT, Evemose wrote: >> Adding (default) methods to `List` would have significant compatibility >> ramifications. Also, the PR needs to contain significant testing of the new >> proposed methods. > > @minborg Sorry to bother you with this kind of question, but i

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v2]

On Fri, 19 Apr 2024 09:39:40 GMT, Per Minborg wrote: >> Evemose has updated the pull request incrementally with one additional >> commit since the last revision: >> >> empty commit to trigger check rerun > > Adding (default) methods to `List` would have significant compatibility >

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote: > Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote: > Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote: > Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or

Re: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote: > Please review a set of updates to clean up use of `/**` comments in the > vicinity of declarations. > > There are various categories of update: > > * "Box comments" beginning with `/**` > * Misplaced doc comments before package or

Re: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll enhance jli tracing [v3]

On Fri, 19 Apr 2024 09:20:27 GMT, Christoph Langer wrote: > This trace seems a bit unsymmetric to its Windows counterpart. Maybe it > should be left out here, too, since there is tracing in GetJREPath. I removed the JLI trace output for the launcher exe path. - PR Review Comment:

Re: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll enhance jli tracing [v4]

> We have already good JLI tracing capabilities. But GetApplicationHome and > GetApplicationHomeFromDll lack some tracing and should be enhanced. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: remove launcher executable path

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v2]

On Thu, 18 Apr 2024 22:21:11 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more

Re: RFR: 8326836: Incorrect `@since` tags for ClassSignature methods [v4]

> # Issue > - [JDK-8326836](https://bugs.openjdk.org/browse/JDK-8326836): changes were > made to the method signatures but this modification isn't reflected in the @ > since tags. The @ since tags need to be updated. > > I changed the `@since` tags to better accurately show when the methods

Re: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll enhance jli tracing

On Tue, 16 Apr 2024 10:20:23 GMT, Alan Bateman wrote: >> We have already good JLI tracing capabilities. But GetApplicationHome and >> GetApplicationHomeFromDll lack some tracing and should be enhanced. > > I think this is way too ad hoc and looks like lefts over from a debugging > session. So

Re: RFR: 8329862: GetApplicationHome and GetApplicationHomeFromDll enhance jli tracing [v3]

On Thu, 18 Apr 2024 06:57:05 GMT, Matthias Baesken wrote: >> We have already good JLI tracing capabilities. But GetApplicationHome and >> GetApplicationHomeFromDll lack some tracing and should be enhanced. > > Matthias Baesken has updated the pull request incrementally with one > additional

Re: RFR: 8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container [v2]

On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote: >> Please review this enhancement to the container detection code which allows >> it to figure out whether the JVM is actually running inside a container >> (`podman`, `docker`, `crio`), or with some other means that enforces >>

Re: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v3]

> Investigating a recent regression in mainline I realized we have an > opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by > using `invokeExact` in a way similar to what we already do for LMF and SCF > BSMs. This avoids generating type checking adapters and equates to

Re: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v2]

On Fri, 19 Apr 2024 04:45:56 GMT, Chen Liang wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use Arrays.copyOfRange > > src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line > 150: > >>

Re: RFR: 8330595: Invoke ObjectMethods::bootstrap method exactly [v2]

> Investigating a recent regression in mainline I realized we have an > opportunity to improve the bootstrap overheads of ObjectMethods::bootstrap by > using `invokeExact` in a way similar to what we already do for LMF and SCF > BSMs. This avoids generating type checking adapters and equates to

  1   2   >