Re: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v8]

2025-05-15 Thread Andrew Dinn
On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for >> Panama segment operations for all writes larger than about 8 bytes in size, >> increasing to more than 2* the performance on larger memory blocks on >> Graviton 2,

Re: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v6]

2025-05-14 Thread Andrew Dinn
On Wed, 14 May 2025 10:47:40 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for >> Panama segment operations for all writes larger than about 8 bytes in size, >> increasing to more than 2* the performance on larger memory blocks on >> Graviton 2,

Re: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v3]

2025-05-12 Thread Andrew Dinn
On Mon, 12 May 2025 09:37:24 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for >> Panama segment operations for all writes larger than about 8 bytes in size, >> increasing to more than 2* the performance on larger memory blocks on >> Graviton 2,

Re: RFR: 8354674: AArch64: Intrinsify Unsafe::setMemory [v2]

2025-05-12 Thread Andrew Dinn
On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley wrote: >> This intrinsic is generally faster than the current implementation for >> Panama segment operations for all writes larger than about 8 bytes in size, >> increasing to more than 2* the performance on larger memory blocks on >> Graviton 2,

Re: RFR: 8354890: AOT-initialize j.l.i.MethodHandleImpl and inner classes

2025-05-01 Thread Andrew Dinn
On Tue, 29 Apr 2025 22:59:29 GMT, Ioi Lam wrote: > This is a general fix for all the "points to a static field that may hold a > different value" failures related to `java/lang/invoke/MethodHandleImpl`. > E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840), > [JDK-8353330](https:/

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]

2025-03-21 Thread Andrew Dinn
On Fri, 21 Mar 2025 17:26:08 GMT, Quan Anh Mai wrote: >>> Hi again Per! >>> >>> Here are some brief notes from our face-to-face chat at JavaOne. >>> >>> Debuggers want/need a "hook" for tentative evaluation of stables. It is an >>> error for a debugger to trigger stable value decisions. This a

Re: RFR: 8341028: Do not use lambdas or method refs for verifyConstantPool [v3]

2024-10-28 Thread Andrew Dinn
On Mon, 21 Oct 2024 14:13:35 GMT, David M. Lloyd wrote: >> Currently, `ParserVerifier#verifyConstantPool` uses a `switch` to produce a >> `Runnable`, which is consumed by a `Consumer` (instantiated within >> a loop) which runs the task inside if a `try`/`catch`. We can eliminate a >> number of

Re: RFR: 8293336: AOT-linking of invokedynamic for lambda expression and string concat

2024-10-08 Thread Andrew Dinn
On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam wrote: > This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading & > Linking](https://bugs.openjdk.org/browse/JDK-8315737). > > This PR implements the AOT-linking of invokedynamic callsites: > - We only link lambda expressions (`LambdaMet

Re: [External] : Re: New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

2024-06-17 Thread Andrew Dinn
Asking if they will bypass these methods. Why can you not look at David's repo? He is a JDK author (dmlloyd) and this work is being done as part of his employment by Red Hat. regards, Andrew Dinn ---

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v24]

2024-04-05 Thread Andrew Dinn
On Fri, 5 Apr 2024 09:31:18 GMT, Severin Gehwolf wrote: >> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän" >> prejudice of German. ;-) >> >> >> >> (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone) > > Hah! My kids just recently informed me about >

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2024-01-29 Thread Andrew Dinn
On Sat, 27 Jan 2024 05:11:28 GMT, Alexander Kriegisch wrote: > Bytecode transformation should not be rocket science, but it progressively is > developing in that direction. Hmm? Bytecode transformation of the JDK runtime implementation is a lot more complicated than your comments seem to ackno

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2024-01-29 Thread Andrew Dinn
On Sun, 28 Jan 2024 22:33:01 GMT, Rafael Winterhalter wrote: > What stops people from supplying a fake instance? Wouldn't you need to "test > run" the instance first? Not necessarily. When the generated API implementation relies on the capabilities of class `Instrumentation` -- such as openin

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2024-01-26 Thread Andrew Dinn
On Fri, 26 Jan 2024 10:17:16 GMT, Alexander Kriegisch wrote: >>> @AlanBateman, the AspectJ weaving agent creates an auxiliary class to >>> implement an "around" advice for a method, i.e. a method execution is >>> intercepted and the user has options to do something before optionally >>> callin

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2024-01-25 Thread Andrew Dinn
On Thu, 25 Jan 2024 12:16:13 GMT, Rafael Winterhalter wrote: > Requiring such an API opens the module to anybody, though, punching a hole > into the module boundary. How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null In

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]

2024-01-25 Thread Andrew Dinn
On Thu, 25 Jan 2024 06:39:56 GMT, Alexander Kriegisch wrote: >> Setting '-javaagent' is mainly an operations problem. Many build tools do >> not allow to declare a test dependency this way as the life cycles are not >> laid out for it, the internal repository location might be machine >> dependen

Re: RFR: 8309191: Reduce JDK dependencies of cgroup support

2023-06-20 Thread Andrew Dinn
On Tue, 13 Jun 2023 15:48:31 GMT, Christian Wimmer wrote: > We (as the Native Image team) are OK with this. Our testing will detect that > pretty quickly, and then the new code can be fixed. That may well be the case. However, until all the concerns raised by OpenJDK reviewers who have looked