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
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
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
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
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
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
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
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 &
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
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
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
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
>
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
>
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
>
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
&
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
>
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:
>
>>
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
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
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
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:
>
>>
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) {
>&
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
>
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
>
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
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
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
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
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
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.
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.
>> `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT.
>> I've implemented the new lock with a semaphore so that it can be used
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Sun, 25 May 2025 14:54:13 GMT, Markus Grönlund wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThrea
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Mon, 26 May 2025 09:02:39 GMT, Markus Grönlund wrote:
>> Yes, but it might be an indeterminate time between entering and exiting the
>> native thread state. So I need to walk them in between. Your sampler
>> implementation also walks threads in native state.
>
> T
On Mon, 26 May 2025 08:30:00 GMT, Johannes Bechberger
wrote:
>> A thread in native is still stackwalked at a safe location, a safepoint code
>> position.
>>
>> It's guaranteed by the last java frame (ljf).
>
> Yes, but it might be an indeterminate time between entering and exiting the
> nativ
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Mon, 26 May 2025 06:23:08 GMT, Johannes Bechberger
wrote:
>> You can have a field as a pointer: timer_t* timer and test it, timer !=
>> nullptr.
>
> Wouldn't I need to store it somewhere?
Of course. A pointer is less space compared to an inlined struct AND a bool.
-
PR Review
On Mon, 26 May 2025 06:32:03 GMT, Johannes Bechberger
wrote:
>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 200:
>>
>>> 198: void sample_thread(JfrSampleRequest& request, void* ucontext,
>>> JavaThread* jt, JfrThreadLocal* tl);
>>> 199:
>>> 200: // sample all
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Sun, 25 May 2025 15:36:59 GMT, Markus Grönlund wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix compilation
>
> src/hotspot/share/jfr/periodic/sampling/jfrThreadSa
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Sun, 25 May 2025 20:49:37 GMT, Johannes Bechberger
wrote:
>> src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 378:
>>
>>> 376:
>>> 377: void unset_cpu_timer() {
>>> 378: _has_cpu_timer = false;
>>
>> Do we really need a separate bool to understand whether the thread has a
>> ti
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Fri, 23 May 2025 21:20:39 GMT, Johannes Bechberger
wrote:
>> This is the code for the [JEP 509: CPU Time based profiling for
>> JFR](https://openjdk.org/jeps/509).
>>
>> Currently tested using [this test
>> suite](https://github.com/parttimenerd/basic-profiler-tests). This runs
>> profile
On Sun, 25 May 2025 15:29:38 GMT, Markus Grönlund wrote:
>> Johannes Bechberger has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix compilation
>
> src/hotspot/share/jfr/recorder/service/jfrEventThrottler
1 - 100 of 194 matches
Mail list logo
