Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

2023-04-28 Thread Dan Heidinga
Hi Ron, Thanks for writing up the JEP draft outlining the proposal to disallow dynamic loading of agents by default. The Red Hat Java team has continued to discuss this proposal internally and with our stakeholders. While there is a general agreement (or at least acceptance) with the overall dir

Re: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

2023-05-01 Thread Dan Heidinga
On Sun, Apr 30, 2023 at 10:19 AM Ron Pressler wrote: > Hi Dan! > > > On 29 Apr 2023, at 03:30, Dan Heidinga wrote: > > > > Hi Ron, > > > > Thanks for writing up the JEP draft outlining the proposal to disallow > dynamic loading of agents by default. T

Re: RFR: JDK-8307331: Correctly update line maps when class redefine rewrites bytecodes

2023-05-04 Thread Dan Heidinga
On Thu, 4 May 2023 17:17:19 GMT, Andrew Dinn wrote: >> This small change ensures that repeated bytecode rewrites necessitated by >> class pool index updates are applied cumulatively when updating the method >> line number table. The current code applies each change to the original >> table whi

Re: JEP draft: Integrity and Strong Encapsulation

2023-05-04 Thread Dan Heidinga
Hi Ron, I’ve read this draft a number of times and each time I struggled with the framing of the problem given Java’s success over the past almost 30 years. Framing the problem with statements like: “Strong encapsulation offers a solid foundation to build on. Without it, code is a cas

Re: [External] : Re: JEP draft: Integrity and Strong Encapsulation

2023-05-08 Thread Dan Heidinga
Thanks for the response, Ron. My comments are in line. On Fri, May 5, 2023 at 8:10 AM Ron Pressler wrote: > > > On 4 May 2023, at 21:32, Dan Heidinga wrote: > > > I’ve read this draft a number of times and each time I struggled with the > framing of the problem given Ja

Re: [External] : Re: JEP draft: Integrity and Strong Encapsulation

2023-05-11 Thread Dan Heidinga
on future directions given it refers to the preventing dynamic loading of agents (a future action) and restricting JNI (future) while also talking about strong encapsulation (past). > > > On 8 May 2023, at 09:41, Dan Heidinga wrote: > > > > > > I agree the old regime worke

Re: Clarifying jmethodID Usage and Potential JVM Crashes

2023-05-31 Thread Dan Heidinga
On Wed, May 31, 2023 at 7:13 AM Jaroslav Bachorík < jaroslav.bacho...@datadoghq.com> wrote: > Dear Team, > > I've been investigating the unusual JVM crashes occurring in JVMTI calls > on a J9 JVM. During my investigation, I scrutinized the `jmethodID` > definition closely, available here: [jmethod

Re: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v3]

2024-10-24 Thread Dan Heidinga
On Wed, 23 Oct 2024 04:46:51 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & >> Linking](https://openjdk.org/jeps/483). >> >> >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https

Re: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6]

2024-11-04 Thread Dan Heidinga
On Mon, 4 Nov 2024 03:08:02 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/aotClassInitializer.cpp line 348: >> >>> 346: } >>> 347: JavaValue result(T_VOID); >>> 348: JavaCalls::call_static(&result, ik, >> >> Based on the discussions in JDK-8342283, do we need a memory fence after the

Re: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6]

2024-10-31 Thread Dan Heidinga
On Thu, 31 Oct 2024 02:23:24 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & >> Linking](https://openjdk.org/jeps/483). >> >> >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https

Re: RFR: 8346567: Make Class.getModifiers() non-native

2025-02-03 Thread Dan Heidinga
On Wed, 11 Dec 2024 15:06:54 GMT, Viktor Klang wrote: >> I don't think this needs to be stable - finals in java.lang is trusted by >> the JIT compiler. > > Yeah, I was just thinking whether something set from inside the VM which is > marked @Stable is constant-folded :) @viktorklang-ora `@Stab

Re: RFR: 8346567: Make Class.getModifiers() non-native

2025-02-03 Thread Dan Heidinga
On Mon, 9 Dec 2024 19:26:53 GMT, Coleen Phillimore wrote: > The Class.getModifiers() method is implemented as a native method in > java.lang.Class to access a field that we've calculated when creating the > mirror. The field is final after that point. The VM doesn't need it anymore, > so ther

Re: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3]

2025-04-08 Thread Dan Heidinga
On Tue, 8 Apr 2025 16:26:28 GMT, Ioi Lam wrote: >> Yes, but I think we should do it only if `AOTClassLinking` is enabled. For >> legacy CDS we should continue use `-Xlog:cds`. >> I am using `-Xlog:aot+codecache` in AOT code caching. > > I created [JDK-8354055 - Change "cds" logging tag to > "a

Re: RFR: 8353597: Refactor handling VM options for AOT cache input and output [v3]

2025-04-07 Thread Dan Heidinga
On Thu, 3 Apr 2025 20:31:50 GMT, Ioi Lam wrote: >> Since [JEP 483: Ahead-of-Time Class Loading & >> Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache >> `are implemented as aliases of "classical" CDS options such as >> `-XX:SharedArchiveFile`. >> >> In anticipation of t

Re: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v15]

2025-05-12 Thread Dan Heidinga
On Mon, 12 May 2025 19:29:18 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an >> application instantly available, when the HotSpot Java Virtual Machine >> starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) >> to store me