Re: RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception [v2]

2024-07-04 Thread Hannes Greule
> Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this > change adds special casing for `VarHandle.{access-mode}` methods. > > The exception message is less exact, but I think that's acceptable. Hannes Greule has updated the pull request incrementa

RFR: 8335638: Calling VarHandle.{access-mode} methods reflectively throws wrong exception

2024-07-03 Thread Hannes Greule
Similar to how `MethodHandle#invoke(Exact)` methods are already handled, this change adds special casing for `VarHandle.{access-mode}` methods. The exception message is less exact, but I think that's acceptable. - Commit messages: - add test (and find missing method) - make

[jdk23] Integrated: 8334708: FFM: two javadoc problems

2024-06-24 Thread Hannes Greule
On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule wrote: > Hi all, > > This pull request contains a backport of commit > [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Re: [jdk23] RFR: 8334708: FFM: two javadoc problems

2024-06-24 Thread Hannes Greule
On Sun, 23 Jun 2024 06:32:50 GMT, Hannes Greule wrote: > Hi all, > > This pull request contains a backport of commit > [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

[jdk23] RFR: 8334708: FFM: two javadoc problems

2024-06-23 Thread Hannes Greule
Hi all, This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Hannes Greule on 22 Jun 2024

Integrated: 8334708: FFM: two javadoc problems

2024-06-22 Thread Hannes Greule
On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule wrote: > Addresses two simple problems regarding javadocs in the FFM API. This pull request has now been integrated. Changeset: 72ca7baf Author: Hannes Greule Committer: Chen Liang URL: https://git.openjdk.org/jdk/com

Re: RFR: 8334708: FFM: two javadoc problems

2024-06-21 Thread Hannes Greule
On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule wrote: > Addresses two simple problems regarding javadocs in the FFM API. Thank you for your review. > Should we backport to 23? I leave that up to you, I don't know how those things are handled normally. But a backport would be very

RFR: 8334708: FFM: two javadoc problems

2024-06-21 Thread Hannes Greule
Addresses two simple problems regarding javadocs in the FFM API. - Commit messages: - fix two javadoc problems in FFM Changes: https://git.openjdk.org/jdk/pull/19820/files Webrev: https://webrevs.openjdk.org/?repo=jdk=19820=00 Issue: https://bugs.openjdk.org/browse/JDK-8334708

Re: RFR: 8330005: RandomGeneratorFactory.getDefault() throws exception when the runtime image only has java.base module [v4]

2024-04-27 Thread Hannes Greule
On Fri, 26 Apr 2024 15:24:30 GMT, Raffaello Giulietti wrote: >> Move all random generators mandated in package `java.util.random` and >> currently implemented in module `jdk.random` to module `java.base`, and >> remove module `jdk.random`. > > Raffaello Giulietti has updated the pull request

Re: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes

2024-01-24 Thread Hannes Greule
On Wed, 24 Jan 2024 20:54:43 GMT, Joshua Cao wrote: > > The current benchmark and the change don't really cover the case where many > > keys exist in _both_ maps. Could you add a benchmark for that? > > I added a benchmark that assumes the worse case. Please see the top post. > Yes, this

Re: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes

2024-01-24 Thread Hannes Greule
On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao wrote: > This change mirrors what we did for ConcurrentHashMap in > https://github.com/openjdk/jdk/pull/17116. When we add all entries from one > map to anther, we should resize that map to the size of the sum of both maps. > > I used the command

Re: RFR: 8324573: HashMap::putAll should resize to sum of both map sizes

2024-01-24 Thread Hannes Greule
On Wed, 24 Jan 2024 00:26:09 GMT, Joshua Cao wrote: > This change mirrors what we did for ConcurrentHashMap in > https://github.com/openjdk/jdk/pull/17116. When we add all entries from one > map to anther, we should resize that map to the size of the sum of both maps. > > I used the command

Re: RFR: 8322292: Rearrange comparison of fields in Record.equals()

2023-12-19 Thread Hannes Greule
On Tue, 19 Dec 2023 09:41:45 GMT, Sergey Tsypanov wrote: > Isn't `Arrays.equals()` used under the hood? The JLS and the API spec don't mention any special-casing of arrays, and the code seems to use `Objects.equals` for all non-primitive types:

Re: RFR: 8322292: Rearrange comparison of fields in Record.equals()

2023-12-18 Thread Hannes Greule
On Mon, 18 Dec 2023 13:42:35 GMT, Sergey Tsypanov wrote: > Currently if we create a record it's fields are compared in their declaration > order. This might be ineffective in cases when two objects have "heavy" > fields equals to each other, but different "lightweight" fields (heavy and >

Re: RFR: 8317980: Optimization for Integer.parseInt and Long.parseLong

2023-10-12 Thread Hannes Greule
On Thu, 12 Oct 2023 00:39:27 GMT, David Schlosnagle wrote: >> He means to pull the `radix< Character,MIN_RADIX` and `radix > >> Character.MAX_RADIX` shared code in Integer and Long.parseInt (with radix >> version) to a helper method. > > More explicitly I was thinking something like below. >

Re: RFR: 8315454: Add an immutable BitSet

2023-09-01 Thread Hannes Greule
On Fri, 1 Sep 2023 08:21:13 GMT, Per Minborg wrote: > This PR proposes adding a new method to BitSet that provides an immutable > snapshot of the set in the form of an `IntPredicate`. > > The predicate is eligible for constant folding. > > Here are some classes in the JDK that would benefit

Re: RFR: 8308804: Improve UUID.randomUUID performance with bulk/scalable PRNG access

2023-05-26 Thread Hannes Greule
On Thu, 25 May 2023 23:54:14 GMT, Andrei Pangin wrote: >> UUID is the very important class that is used to track identities of objects >> in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% >> of total CPU time, and is frequently a scalability bottleneck due to >>

Integrated: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names

2023-04-29 Thread Hannes Greule
On Thu, 23 Mar 2023 19:45:21 GMT, Hannes Greule wrote: > After merging master into https://github.com/openjdk/jdk/pull/9862, we > encountered test failures (e.g., > https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). > The Classfile API tries

Re: RFR: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names [v3]

2023-04-28 Thread Hannes Greule
On Fri, 28 Apr 2023 22:16:09 GMT, Vicente Romero wrote: >> Hannes Greule has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Move and fix test comment > > looks good Thank you for your review, @vicente-rom

Re: RFR: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names [v3]

2023-03-24 Thread Hannes Greule
On Fri, 24 Mar 2023 06:42:30 GMT, Hannes Greule wrote: >> After merging master into https://github.com/openjdk/jdk/pull/9862, we >> encountered test failures (e.g., >> https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). >> The Classfil

Re: RFR: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names [v3]

2023-03-24 Thread Hannes Greule
ce or if the test can be improved somehow. > > As I don't have a JBS account, someone needs to create a bug report there for > me. Thanks. Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: Move and fix test comme

Re: RFR: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names [v2]

2023-03-23 Thread Hannes Greule
ce or if the test can be improved somehow. > > As I don't have a JBS account, someone needs to create a bug report there for > me. Thanks. Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code rev

RFR: 8304837: Classfile API throws IOOBE for MethodParameters attribute without parameter names

2023-03-23 Thread Hannes Greule
After merging master into https://github.com/openjdk/jdk/pull/9862, we encountered test failures (e.g., https://github.com/SirYwell/jdk/actions/runs/4500940829/jobs/7923018438#step:9:2541). The Classfile API tries to read from constant pool index 0 if a MethodParameters attribute has an entry

Re: RFR: 8294982: Implementation of Classfile API [v8]

2023-01-26 Thread Hannes Greule
On Wed, 25 Jan 2023 13:14:43 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and >> benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, >> and transforming >>

Confusing exception message in MethodHandles#tableSwitch

2022-10-14 Thread Hannes Greule
Hi, I hope this is the right mailing list. I recently fiddled around with MethodHandles#tableSwitch and stumbled across a confusing exception message. As a simple example, consider following code: import java.lang.invoke.*; import static java.lang.invoke.MethodType.*; import static