RFR: 8323883: JFR AssertionError: Missing object ID 15101

2024-02-08 Thread Markus Grönlund
Greetings, The following adjustments fix the intermittent issues with incomplete tag sets for a chunk. The situations are pretty subtle: 1. A situation can occur where an event is emitted during the event instrumentation callback as part of JVMTI Retransform (ErrorThrownEvent). A stack trace i

Re: RFR: 8323883: JFR AssertionError: Missing object ID 15101

2024-02-14 Thread Markus Grönlund
On Fri, 9 Feb 2024 15:51:32 GMT, Erik Gahlin wrote: >> Greetings, >> >> The following adjustments fix the intermittent issues with incomplete tag >> sets for a chunk. The situations are pretty subtle: >> >> 1. A situation can occur where an event is emitted during the event >> instrumentation

Integrated: 8323883: JFR AssertionError: Missing object ID 15101

2024-02-14 Thread Markus Grönlund
On Thu, 8 Feb 2024 13:46:40 GMT, Markus Grönlund wrote: > Greetings, > > The following adjustments fix the intermittent issues with incomplete tag > sets for a chunk. The situations are pretty subtle: > > 1. A situation can occur where an event is emitted during the event

Re: RFR: 8322812: Manpage for jcmd is missing JFR.view command

2024-07-01 Thread Markus Grönlund
On Fri, 28 Jun 2024 14:51:57 GMT, Erik Gahlin wrote: > Could I have a review of a change to the jcmd man page? A typo was also fixed > for JFR.start. > > Testing: tier1 > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/199

Re: RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd)

2024-07-03 Thread Markus Grönlund
On Wed, 3 Jul 2024 12:05:43 GMT, Erik Gahlin wrote: > Could I have a review of a typo for JFR.start and JFR.dump? > > Testing: tier1 > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20003#pullrequestreview-2156282430

Re: [jdk23] RFR: 8322812: Manpage for jcmd is missing JFR.view command

2024-07-04 Thread Markus Grönlund
On Thu, 4 Jul 2024 10:51:48 GMT, Erik Gahlin wrote: > 8322812: Manpage for jcmd is missing JFR.view command Marked as reviewed by mgronlun (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20028#pullrequestreview-2158707721

Re: [jdk23] RFR: 8324089: Fix typo in the manual page for "jcmd" (man jcmd)

2024-07-04 Thread Markus Grönlund
On Thu, 4 Jul 2024 10:54:22 GMT, Erik Gahlin wrote: > 8324089: Fix typo in the manual page for "jcmd" (man jcmd) Marked as reviewed by mgronlun (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/20030#pullrequestreview-2158706543

RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

2024-07-13 Thread Markus Grönlund
Greetings, Please help review this adjustment, which fixes rare situations where methods that have been retransformed or redefined can be perceived as being tagged by JFR when they, in fact, are not. The fix unconditionally sets the metatag clear bits on artefact initialization and adds asserti

Re: RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

2024-07-16 Thread Markus Grönlund
On Tue, 16 Jul 2024 00:05:36 GMT, Serguei Spitsyn wrote: >> Greetings, >> >> Please help review this adjustment, which fixes rare situations where >> methods that have been retransformed or redefined can be perceived as being >> tagged by JFR when they, in fact, are not. The fix unconditionall

Integrated: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

2024-07-17 Thread Markus Grönlund
On Sat, 13 Jul 2024 14:47:21 GMT, Markus Grönlund wrote: > Greetings, > > Please help review this adjustment, which fixes rare situations where methods > that have been retransformed or redefined can be perceived as being tagged by > JFR when they, in fact, are not. The fix

[jdk23] RFR: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

2024-07-17 Thread Markus Grönlund
8334781: JFR crash: assert(JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits( != 0))) failed: invariant - Commit messages: - Backport 67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce Changes: https://git.openjdk.org/jdk/pull/20217/files Webrev:

[jdk23] Integrated: 8334781: JFR crash: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

2024-07-17 Thread Markus Grönlund
On Wed, 17 Jul 2024 11:21:04 GMT, Markus Grönlund wrote: > 8334781: JFR crash: assert(JfrTraceIdBits::load(klass)) & > ((JfrTraceIdEpoch::this_epoch_method_and_class_bits( != 0))) failed: > invariant This pull request has now been integrated. Changeset: 88775f95 Auth

Re: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/

2023-01-20 Thread Markus Grönlund
On Thu, 19 Jan 2023 20:44:33 GMT, Johan Sjölen wrote: >> Do the conversion in the share/jfr/ sub-directory and all of its files. > > src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1157: > >> 1155: const int orig_stream_length = orig_stream->length(); >> 1156: // allo

RFR: 8257967: JFR: Event for loaded agents

2023-03-08 Thread Markus Grönlund
Greetings, We are adding support to let JFR report on Agents. Design An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents in

Re: RFR: 8257967: JFR: Events for loaded agents [v2]

2023-03-08 Thread Markus Grönlund
The previous implementation was > located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their > older places wil

Re: RFR: 8257967: JFR: Events for loaded agents [v3]

2023-03-08 Thread Markus Grönlund
alled AgentLibrary. The previous implementation was > located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their > older

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-03-08 Thread Markus Grönlund
alled AgentLibrary. The previous implementation was > located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their > old

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-03-08 Thread Markus Grönlund
On Wed, 8 Mar 2023 18:56:55 GMT, Markus Grönlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most >> agents are

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-03-09 Thread Markus Grönlund
On Wed, 8 Mar 2023 23:28:52 GMT, Markus Grönlund wrote: >> Markus Grönlund has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - remove JVMPI >> - cleanup > > No need to load any JFR classes. No chang

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-03-09 Thread Markus Grönlund
olmes wrote: >> Markus Grönlund has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - remove JVMPI >> - cleanup > > src/hotspot/share/runtime/threads.cpp line 338: > >> 336: if (EagerXrunInit &

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-03-09 Thread Markus Grönlund
On Thu, 9 Mar 2023 00:23:39 GMT, David Holmes wrote: > > No need to load any JFR classes. > > I thought JFR was all Java-based these days. But if no Java involved then > that is good. Ehh, no. Far from it. > > No change to startup logic. > > I flagged a change in my comment above. Thanks, p

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-03-09 Thread Markus Grönlund
On Thu, 9 Mar 2023 09:36:28 GMT, Andrew Dinn wrote: > Yes, I appreciate that `dynamic` can be derived from `initializationMethod` > -- and vice versa. However, I was approaching this semantically from the > opposite end. To me the primary characteristic that the user would be > interested in i

Re: RFR: 8257967: JFR: Events for loaded agents [v5]

2023-03-09 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their

Re: RFR: 8257967: JFR: Events for loaded agents [v6]

2023-03-09 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their >

Re: RFR: 8257967: JFR: Events for loaded agents [v7]

2023-03-09 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their >

Re: RFR: 8257967: JFR: Events for loaded agents [v8]

2023-03-09 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their >

Re: RFR: 8257967: JFR: Events for loaded agents [v9]

2023-03-09 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their &

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-10 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their >

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-14 Thread Markus Grönlund
On Mon, 13 Mar 2023 06:22:21 GMT, David Holmes wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> more cleanup > > src/hotspot/share/prims/agent.cpp line 34: > >>

Re: RFR: 8257967: JFR: Events for loaded agents [v9]

2023-03-14 Thread Markus Grönlund
On Fri, 10 Mar 2023 06:57:46 GMT, David Holmes wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> handle multiple envs with same VMInit callback > > src/hotspot/share/prims/agent

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-14 Thread Markus Grönlund
On Mon, 13 Mar 2023 09:49:39 GMT, Andrew Dinn wrote: >> src/hotspot/share/prims/agentList.cpp line 64: >> >>> 62: void AgentList::add_xrun(const char* name, char* options, bool >>> absolute_path) { >>> 63: Agent* agent = new Agent(name, options, absolute_path); >>> 64: agent->_is_xrun = tru

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-14 Thread Markus Grönlund
On Tue, 14 Mar 2023 06:01:05 GMT, David Holmes wrote: > I've had a good look through now and have a better sense of the refactoring. > Seems good. > > > > I'll wait for any tweaks before hitting the approve button though. > > > > Thanks Thanks so much for taking a look. I realized that im

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-14 Thread Markus Grönlund
On Mon, 13 Mar 2023 09:46:04 GMT, Andrew Dinn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> more cleanup > > src/hotspot/share/jfr/metadata/metadata.xml line 1182: > >>

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-30 Thread Markus Grönlund
On Tue, 14 Mar 2023 12:23:08 GMT, Markus Grönlund wrote: >> src/hotspot/share/prims/agentList.cpp line 419: >> >>> 417: const jint err = (*on_load_entry)(&main_vm, >>> const_cast(agent->options()), NULL); >>> 418: if (err != JNI_OK) { >&

Re: RFR: 8257967: JFR: Events for loaded agents [v11]

2023-03-30 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their >

Re: RFR: 8257967: JFR: Events for loaded agents [v12]

2023-03-30 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their >

Re: RFR: 8257967: JFR: Events for loaded agents [v13]

2023-03-30 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their > o

Re: RFR: 8257967: JFR: Events for loaded agents [v14]

2023-03-30 Thread Markus Grönlund
s, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, > prims/agent.hpp and prims/agentList.hpp. Breaking out this code from

Re: RFR: 8257967: JFR: Events for loaded agents [v14]

2023-03-30 Thread Markus Grönlund
On Thu, 30 Mar 2023 19:20:11 GMT, Markus Grönlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most >> agents are

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-30 Thread Markus Grönlund
On Tue, 14 Mar 2023 12:26:16 GMT, Markus Grönlund wrote: > I've had a good look through now and have a better sense of the refactoring. > Seems good. > > I'll wait for any tweaks before hitting the approve button though. > > Thanks Moving the loading logic to th

Re: RFR: 8257967: JFR: Events for loaded agents [v9]

2023-03-30 Thread Markus Grönlund
On Tue, 14 Mar 2023 12:19:50 GMT, Markus Grönlund wrote: >> src/hotspot/share/prims/agent.cpp line 41: >> >>> 39: char* copy = AllocateHeap(length + 1, mtInternal); >>> 40: strncpy(copy, str, length + 1); >>> 41: assert(strncmp(copy, str, length

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-30 Thread Markus Grönlund
On Tue, 14 Mar 2023 12:22:16 GMT, Markus Grönlund wrote: >> n.b. that also applies for accesses/updates to field _next. > > I wanted all accesses to use the iterator. The only access is given to the > iterator and AgentList by way of being friends. No need to expose more.

Re: RFR: 8257967: JFR: Events for loaded agents [v15]

2023-03-31 Thread Markus Grönlund
ame, options) and measure the time it takes for the JavaAgent to > initialize. > > When implementing this capability, it was necessary to refactor the code used > to represent agents, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but

Re: RFR: 8257967: JFR: Events for loaded agents [v14]

2023-03-31 Thread Markus Grönlund
On Fri, 31 Mar 2023 03:05:31 GMT, David Holmes wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> restore misssing frees > > src/hotspot/share/prims/agent.cpp line

Re: RFR: 8257967: JFR: Events for loaded agents [v15]

2023-04-03 Thread Markus Grönlund
On Sat, 1 Apr 2023 03:47:26 GMT, Serguei Spitsyn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixes > > src/hotspot/share/prims/agentList.cpp line 204: > >> 202:

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-04 Thread Markus Grönlund
ame, options) and measure the time it takes for the JavaAgent to > initialize. > > When implementing this capability, it was necessary to refactor the code used > to represent agents, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but

Re: RFR: 8257967: JFR: Events for loaded agents [v15]

2023-04-04 Thread Markus Grönlund
On Sat, 1 Apr 2023 03:31:48 GMT, Serguei Spitsyn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixes > > src/hotspot/share/prims/agent.hpp line 1: > >> 1: /* > &g

Re: RFR: 8257967: JFR: Events for loaded agents [v15]

2023-04-05 Thread Markus Grönlund
On Wed, 5 Apr 2023 06:55:16 GMT, Serguei Spitsyn wrote: >> I changed the names because I found it very hard to understand what the old >> names represented: "AgentLibrary" vs "Library"? "add_init_agent" vs >> "add_instrumentation_agent", or even "add_loaded_agent"? Also a bit >> confusing that

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-05 Thread Markus Grönlund
On Wed, 5 Apr 2023 01:48:19 GMT, David Holmes wrote: > Renamings look good to me. Thank you for your review! - PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1497209787

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-11 Thread Markus Grönlund
On Tue, 4 Apr 2023 14:39:19 GMT, Markus Grönlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most >> agents are

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-11 Thread Markus Grönlund
On Tue, 11 Apr 2023 16:56:49 GMT, Serguei Spitsyn wrote: > > Can I please get a second review to close this one out? > > Markus, I'm still working on it and close to finish. I have some questions to > ask. In fact, I gave up to prove this refactoring does not break anything. > So, we should re

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-12 Thread Markus Grönlund
On Wed, 12 Apr 2023 10:31:37 GMT, Serguei Spitsyn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> renames > > src/hotspot/share/prims/jvmtiAgent.cpp line 323: > >> 321

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-12 Thread Markus Grönlund
On Tue, 4 Apr 2023 14:39:19 GMT, Markus Grönlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most >> agents are

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-12 Thread Markus Grönlund
On Wed, 12 Apr 2023 11:01:43 GMT, Serguei Spitsyn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> renames > > src/hotspot/share/prims/jvmtiAgent.cpp line 357: > >> 3

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-13 Thread Markus Grönlund
On Thu, 13 Apr 2023 10:07:50 GMT, Serguei Spitsyn wrote: > What was the reason to clone the classes below ?: > `JvmtiJavaThreadEventTransition` => `AgentJavaThreadEventTransition` > `JvmtiThreadEventMark` => `AgentThreadEventMark` `JvmtiEventMark` => > `AgentEventMark` The reason is they are

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-13 Thread Markus Grönlund
On Thu, 13 Apr 2023 10:15:02 GMT, Serguei Spitsyn wrote: > Your fix introduced a hidden dependency of this new structure on the > JPLISEnvironment structure and some Java agents implementation details: > > ``` > 202 struct JPLISEnvironmentMirror { > 203 jvmtiEnv* mJVMTIEnv; // the JVMTI envir

Re: RFR: 8257967: JFR: Events for loaded agents [v17]

2023-04-13 Thread Markus Grönlund
ame, options) and measure the time it takes for the JavaAgent to > initialize. > > When implementing this capability, it was necessary to refactor the code used > to represent agents, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but

Re: RFR: 8257967: JFR: Events for loaded agents [v16]

2023-04-13 Thread Markus Grönlund
On Thu, 13 Apr 2023 10:24:55 GMT, Serguei Spitsyn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> renames > > src/hotspot/share/prims/jvmtiAgentList.cpp line 72: > >> 70:

Re: RFR: 8257967: JFR: Events for loaded agents [v17]

2023-04-14 Thread Markus Grönlund
On Fri, 14 Apr 2023 07:43:23 GMT, Serguei Spitsyn wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> line breaks > > src/hotspot/share/prims/jvmtiExport.cpp line 717: > >&g

Re: RFR: 8257967: JFR: Events for loaded agents [v17]

2023-04-14 Thread Markus Grönlund
On Fri, 14 Apr 2023 07:50:39 GMT, Serguei Spitsyn wrote: > Markus, It looks good to me. Overall, it is a nice consolidation of the agent > code, good move in general! Thank you for your patience. I've posted one > minor request though. Thanks, Serguei Thanks for taking a look Serguei, apprecia

Re: RFR: 8257967: JFR: Events for loaded agents [v17]

2023-04-17 Thread Markus Grönlund
On Fri, 14 Apr 2023 22:22:13 GMT, Serguei Spitsyn wrote: >> Ok. the terminology here might be confusing. The concept of an agent being >> "initialized" is introduced and reported by JFR. For example, here is the >> JFR event type definition for a NativeAgent: >> ``` >> > label="Native Agent"

Re: RFR: 8257967: JFR: Events for loaded agents [v18]

2023-04-17 Thread Markus Grönlund
ame, options) and measure the time it takes for the JavaAgent to > initialize. > > When implementing this capability, it was necessary to refactor the code used > to represent agents, AgentLibrary. The previous implementation was located > primarily in arguments.cpp, and threads.cpp but

Re: RFR: 8257967: JFR: Events for loaded agents [v4]

2023-04-17 Thread Markus Grönlund
On Thu, 9 Mar 2023 00:23:39 GMT, David Holmes wrote: >> No need to load any JFR classes. No change to startup logic. > >> No need to load any JFR classes. > > I thought JFR was all Java-based these days. But if no Java involved then > that is good. > >> No change to startup logic. > > I flag

Integrated: 8257967: JFR: Events for loaded agents

2023-04-17 Thread Markus Grönlund
On Wed, 8 Mar 2023 12:41:15 GMT, Markus Grönlund wrote: > Greetings, > > We are adding support to let JFR report on Agents. > > Design > > An Agent is a library that uses any instrumentation or profiling APIs. Most > agents are started and initialized on the comm

RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967

2023-04-18 Thread Markus Grönlund
Greetings, With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the r

Re: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v2]

2023-04-18 Thread Markus Grönlund
ructs to let > linux-arm32-open-cmp-baseline build successfully. > > It does not look good, but there you go... > > Testing: > > Building: linux-arm32-open-cmp-baseline > Building: regular platforms > > Thanks > Markus Markus Grönlund has updated the pull requ

Re: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3]

2023-04-18 Thread Markus Grönlund
ructs to let > linux-arm32-open-cmp-baseline build successfully. > > It does not look good, but there you go... > > Testing: > > Building: linux-arm32-open-cmp-baseline > Building: regular platforms > > Thanks > Markus Markus Grönlund has updated the pull requ

Integrated: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967

2023-04-18 Thread Markus Grönlund
On Tue, 18 Apr 2023 14:22:21 GMT, Markus Grönlund wrote: > Greetings, > > With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much > refactoring was done to the JVMTI code concerning agents. However, some > platforms do not have JVMTI support, and tier5 of te

RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967

2023-04-18 Thread Markus Grönlund
Greetings, For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. Easiest to remove the assertio

Re: RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967

2023-04-19 Thread Markus Grönlund
On Tue, 18 Apr 2023 17:15:46 GMT, Serguei Spitsyn wrote: >> Greetings, >> >> For most platforms, os::dll_address_to_library_name() only sets offset = -1 >> in case of errors. If there is an error, the function returns false. This is >> fine. >> >> On AIX, the offset, being optional, is invari

Integrated: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967

2023-04-19 Thread Markus Grönlund
On Tue, 18 Apr 2023 16:59:29 GMT, Markus Grönlund wrote: > Greetings, > > For most platforms, os::dll_address_to_library_name() only sets offset = -1 > in case of errors. If there is an error, the function returns false. This is > fine. > > On AIX, the offset, being opt

Re: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3]

2023-04-19 Thread Markus Grönlund
On Wed, 19 Apr 2023 02:22:38 GMT, David Holmes wrote: > @mgronlun I agree this does not look good. I'm not sure this was the right > way to conditionalize the new code, rather than ensuring the callsites were > conditionalized on INCLUDE_JVMTI. It follows the same pattern as for other jvmti*.c

Re: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v8]

2023-05-08 Thread Markus Grönlund
On Mon, 8 May 2023 10:09:29 GMT, Johan Sjölen wrote: >> Hi, this PR changes all occurrences of NULL to nullptr for the subdirectory >> share/jfr/. Unfortunately the script that does the change isn't perfect, and >> so we >> need to comb through these manually to make sure nothing has gone wrong

Re: RFR: JDK-8300245: Replace NULL with nullptr in share/jfr/ [v8]

2023-05-08 Thread Markus Grönlund
On Mon, 8 May 2023 11:01:56 GMT, Johan Sjölen wrote: >> Johan Sjölen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Dead assert > > Passes tier1. Thanks @jdksjolen , I am rubberstamping this. - PR Comment: https://git.ope

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-08-31 Thread Markus Grönlund
On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman 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. > JV

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-08-31 Thread Markus Grönlund
On Thu, 31 Aug 2023 11:41:03 GMT, Alan Bateman 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 che

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-09-01 Thread Markus Grönlund
On Thu, 31 Aug 2023 19:28:50 GMT, Alan Bateman wrote: >> 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 mod

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-09-01 Thread Markus Grönlund
On Wed, 30 Aug 2023 13:56:42 GMT, Alan Bateman 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. > JV

Re: RFR: 8315373: Change VirtualThread to unmount after freezing, re-mount before thawing

2023-09-01 Thread Markus Grönlund
On Fri, 1 Sep 2023 11:26:48 GMT, Alan Bateman wrote: >> Ok. If the thread can run native code as part of the mount / unmount, and >> the sampler can see the intermediary state there too, the check is needed. > > Thanks. One other thing that I see when more testing with generational ZGC is > tha