From vpurnam at openjdk.org Fri Mar 1 04:35:51 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Fri, 1 Mar 2024 04:35:51 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v3] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 10:47:23 GMT, Brice Dutheil wrote: >> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8204: Keyboard traps in flamegraph view for search option > > LGTM albeit a few things to fix. > > Not tested on either Linux or Windows. Hi @bric3, I have done the required changes. Could you please re-review the changes. Thanks. ------------- PR Comment: https://git.openjdk.org/jmc/pull/554#issuecomment-1972489824 From geniusgaurav27 at gmail.com Fri Mar 1 13:49:49 2024 From: geniusgaurav27 at gmail.com (Gaurav Gupta) Date: Fri, 1 Mar 2024 19:19:49 +0530 Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems In-Reply-To: <032401da671d$971ddc40$c55994c0$@hirt.se> References: <032401da671d$971ddc40$c55994c0$@hirt.se> Message-ID: Thanks Marcus and Erik. HeapMemoryAfterGC - Our service framework in Amazon emits a JMX metrics for HeapMemoryAfterGC - i.e. the percent occupancy of the part of the Java heap *that excludes Eden* by both live and garbage objects *after the last collection that affected that part of the Java heap*. It is *not* an instantaneously measured value: it changes *only after* a collection. HeapMemoryAfterGCUse stays fairly constant. Heap memory Xmx and Xms values are set to 24G on the server The rise is from 10% to 30%. When I disable the JFR VM params, the HeapMomoryAfterGCuse falls bacl to 5-10%. So its the enables of JFR causing the issue. Do you think additional JVM parameters could cause the issue though I have capped the memory to 60MB. -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 On Sat, Feb 24, 2024 at 6:02?PM Marcus Hirt wrote: > Hi Gaurav, > > I?ve invited you to the JMC slack. > > > > Kind regards, > > Marcus > > > > *From:* jmc-dev *On Behalf Of *Erik Gahlin > *Sent:* Saturday, 24 February 2024 11:09 > *To:* Gaurav Gupta ; hotspot-jfr-dev at openjdk.org; > jmc-dev at openjdk.org > *Subject:* Re: JFR causes spike in HeapMemoryAfterGC in prod ssystems > > > > Hi Guarav, > > > > > it is claimed to be safe in prod systems with continuous JFR profiling. > > > > The overhead should be less than 1% by default (-XX:StartFlightRecording, > no other options) and it should not crash, cause memory leaks etc. if you > run it for a long time. > > > > I don't know where the HeapMemoryAfterGC metric comes from. Is it > something shown in JMC? We don't have targets for memory usage. That said, > JFR should probably not use more than 50 MB of the Java heap, so if 30% is > normal or not depends on how large heap you are using. > > > > There is a slack channel for JMC developers. I don't manage it and I'm not > sure if this is really a bug. > > https://wiki.openjdk.org/display/jmc/Contributing > > > > Best regards, > > Erik > > > ------------------------------ > > *From:* hotspot-jfr-dev on behalf of > Gaurav Gupta > *Sent:* Friday, February 23, 2024 6:26 AM > *To:* hotspot-jfr-dev at openjdk.org ; > jmc-dev at openjdk.org > *Subject:* JFR causes spike in HeapMemoryAfterGC in prod ssystems > > > > Hi Team, > > > > I am Gaurav Gupta, Principal Engineer at Amazon India (gagup at amazon.com). > My team is trying to enable JFR on production systems for studying any > issues using custom events in JMC. Also we plan to study the impact of code > changes in our application on system performance by studying JFR dumps > using JMC and Flamescope (sub-second profiling). > > > > We tried enabling JFR in our prod system by adding following JVM args in > our application startup (we have not yet added any custom event in our code: > > -XX:+FlightRecorder > -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false > -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 > > (The reason we turned off the disk parameter is to avoid disk space issues > during spiky traffic. We plan to take JFR dump on demand basis by running > JFR.dump command line option to study application behavior and keep JFR > recording on all the time). > > > > We saw the system performance metrics on HeapMemoryAfterGC rising from 5% > to 30% (on our test fleet) after starting our application with above JVM > args (i.e. with JFR enabled). As per our reading about JFR, it is claimed > to be safe in prod systems with continuous JFR profiling. But the rise of > the HeapMemory use raised concern. > > I seek your advice in this regard, if we are missing anything (wrt > parameter configuration above) or are there other options to try without > affecting the prod system. > > > > Also, is there a slack channel that I join for live discussion in this > regard? How can I get added? > > > > PS: I won't be able to share the JFR dump file outside Amazon as it > records events and stack traces for our proprietary software. But I am > happy to come to a meeting on slack or other means and discuss this. Slack > email: gagup at amazon.com > > > -- > > Best regards, > *Gaurav Gupta* > > > ------------------------------------------------------------------------------------------------------------------------------- > *"Perfection is achieved not when there is nothing more to add,but rather > when there is nothing more to take away."* > -- Best regards, *Gaurav Gupta* ------------------------------------------------------------------------------------------------------------------------------- *"Perfection is achieved not when there is nothing more to add,but rather when there is nothing more to take away."* -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Fri Mar 1 15:10:36 2024 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Fri, 1 Mar 2024 15:10:36 +0000 Subject: [External] : Re: JFR causes spike in HeapMemoryAfterGC in prod ssystems In-Reply-To: References: <032401da671d$971ddc40$c55994c0$@hirt.se> Message-ID: The options you have modified changes native memory, not the Java heap. That said, I would run JFR with the default configuration unless you experience issues. 5% of 24G is 1,2 GB. That doesn't sound reasonable, but I can't rule out JFR impacts GC heuristics somehow. You could do a Java heap dump and see if there are classes held by JFR. You could also run with NMT (native memory tracking) to get a more detailed view of what is happening from a memory perspective. What JDK version are you using? Erik ________________________________ From: Gaurav Gupta Sent: Friday, March 1, 2024 2:49 PM To: Marcus Hirt Cc: Erik Gahlin ; hotspot-jfr-dev at openjdk.org ; jmc-dev at openjdk.org Subject: [External] : Re: JFR causes spike in HeapMemoryAfterGC in prod ssystems Thanks Marcus and Erik. HeapMemoryAfterGC - Our service framework in Amazon emits a JMX metrics for HeapMemoryAfterGC - i.e. the percent occupancy of the part of the Java heap that excludes Eden by both live and garbage objects after the last collection that affected that part of the Java heap. It is not an instantaneously measured value: it changes only after a collection. HeapMemoryAfterGCUse stays fairly constant. Heap memory Xmx and Xms values are set to 24G on the server The rise is from 10% to 30%. When I disable the JFR VM params, the HeapMomoryAfterGCuse falls bacl to 5-10%. So its the enables of JFR causing the issue. Do you think additional JVM parameters could cause the issue though I have capped the memory to 60MB. -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 On Sat, Feb 24, 2024 at 6:02?PM Marcus Hirt > wrote: Hi Gaurav, I?ve invited you to the JMC slack. Kind regards, Marcus From: jmc-dev > On Behalf Of Erik Gahlin Sent: Saturday, 24 February 2024 11:09 To: Gaurav Gupta >; hotspot-jfr-dev at openjdk.org; jmc-dev at openjdk.org Subject: Re: JFR causes spike in HeapMemoryAfterGC in prod ssystems Hi Guarav, > it is claimed to be safe in prod systems with continuous JFR profiling. The overhead should be less than 1% by default (-XX:StartFlightRecording, no other options) and it should not crash, cause memory leaks etc. if you run it for a long time. I don't know where the HeapMemoryAfterGC metric comes from. Is it something shown in JMC? We don't have targets for memory usage. That said, JFR should probably not use more than 50 MB of the Java heap, so if 30% is normal or not depends on how large heap you are using. There is a slack channel for JMC developers. I don't manage it and I'm not sure if this is really a bug. https://wiki.openjdk.org/display/jmc/Contributing Best regards, Erik ________________________________ From: hotspot-jfr-dev > on behalf of Gaurav Gupta > Sent: Friday, February 23, 2024 6:26 AM To: hotspot-jfr-dev at openjdk.org >; jmc-dev at openjdk.org > Subject: JFR causes spike in HeapMemoryAfterGC in prod ssystems Hi Team, I am Gaurav Gupta, Principal Engineer at Amazon India (gagup at amazon.com). My team is trying to enable JFR on production systems for studying any issues using custom events in JMC. Also we plan to study the impact of code changes in our application on system performance by studying JFR dumps using JMC and Flamescope (sub-second profiling). We tried enabling JFR in our prod system by adding following JVM args in our application startup (we have not yet added any custom event in our code: -XX:+FlightRecorder -XX:StartFlightRecording=name=SomeServiceJFR,disk=false,path-to-gc-roots=false -XX:FlightRecorderOptions=stackdepth=256,memorysize=60M,numglobalbuffers=2,globalbuffersize=30M,old-object-queue-size=64 (The reason we turned off the disk parameter is to avoid disk space issues during spiky traffic. We plan to take JFR dump on demand basis by running JFR.dump command line option to study application behavior and keep JFR recording on all the time). We saw the system performance metrics on HeapMemoryAfterGC rising from 5% to 30% (on our test fleet) after starting our application with above JVM args (i.e. with JFR enabled). As per our reading about JFR, it is claimed to be safe in prod systems with continuous JFR profiling. But the rise of the HeapMemory use raised concern. I seek your advice in this regard, if we are missing anything (wrt parameter configuration above) or are there other options to try without affecting the prod system. Also, is there a slack channel that I join for live discussion in this regard? How can I get added? PS: I won't be able to share the JFR dump file outside Amazon as it records events and stack traces for our proprietary software. But I am happy to come to a meeting on slack or other means and discuss this. Slack email: gagup at amazon.com -- Best regards, Gaurav Gupta ------------------------------------------------------------------------------------------------------------------------------- "Perfection is achieved not when there is nothing more to add,but rather when there is nothing more to take away." -- Best regards, Gaurav Gupta ------------------------------------------------------------------------------------------------------------------------------- "Perfection is achieved not when there is nothing more to add,but rather when there is nothing more to take away." -------------- next part -------------- An HTML attachment was scrubbed... URL: From aptmac at openjdk.org Fri Mar 1 15:18:55 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 1 Mar 2024 15:18:55 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v4] In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 11:28:15 GMT, Virag Purnam wrote: >> Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: >> >> 1. Focus is trapped in JMC Agent Preset Manager >> >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times >> >> 2. Focus is trapped in Description of Template Manager >> >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description >> >> 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph >> >> Solution: >> 1. PresetManagerPage.java : Setting the focus back to tableInspector. >> 2. TemplateEditPage.java : Added TraverseListener() for description field. >> 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. >> >> These issues are kind of blocker with respect to accessibility. Could someone please review the changes. > > Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: > > 8204: Keyboard traps in flamegraph view for search option Left a few minor things in the comments. Overall looks good. I'm not sure if anyone else is running Linux, but my tab navigation is still stuck if the Outline tab is opened in JMC, regardless of the flameview being open or not. Would be nice to see if this is just me or not, otherwise this issue could be updated to be (mainly) Windows-focused. Scenario 2 looks to be fixed across all platforms though, which is nice. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 603: > 601: Display.getDefault().syncExec(new Runnable() { > 602: public void run() { > 603: IWorkbenchPage activePage = PlatformUI.getWorkbench().getWorkbenchWindows()[0].getActivePage(); Minor syntax nit, but I think this could be replaced with `PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()` ? application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 622: > 620: * Adding key listener to transfer focus forward or backward based on 'TAB' or 'Shift + TAB' > 621: * > 622: * @param comp This and the following 3 methods have a `@param` but no extra details, I think maybe either remove it or just add what comp is. application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 835: > 833: var fileName = fd.getFileName().toLowerCase(); > 834: // FIXME: FileDialog filterIndex returns -1 > 835: // (https://bugs.eclipse.org/bugs/show_bug.cgi?id=546256) As a side note, it would be nice to see if this is still an issue. The bug mentions that it was not an Eclipse issue, but rather a gtk 3 issue from 2019. ------------- PR Review: https://git.openjdk.org/jmc/pull/554#pullrequestreview-1911313521 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1509102706 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1509108639 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1509111971 From aptmac at openjdk.org Fri Mar 1 15:18:55 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Fri, 1 Mar 2024 15:18:55 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Tue, 27 Feb 2024 16:50:24 GMT, Virag Purnam wrote: >> application/org.openjdk.jmc.console.agent/src/main/java/org/openjdk/jmc/console/agent/manager/wizards/PresetManagerPage.java line 209: >> >>> 207: >>> 208: tableInspector.getViewer().refresh(); >>> 209: tableInspector.setFocus(); >> >> **suggestion:** Might be worth extracting all `setFocus()` statements in a single method with a comment, since the issue is not quite straightforward. > > I have addressed this and extracted a method. Reading Brice's comment above, I'm thinking he meant move the `tableInspector.setFocus()` lines into it's own method so there is a centralized location to add a comment as to why this line is needed? Something like .. // 8204: this set focus is required in order to .. private void setFocusOnTableInspector() { tableInspector.setFocus(); } ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1509093655 From bdutheil at openjdk.org Fri Mar 1 16:39:52 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 1 Mar 2024 16:39:52 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 14:33:35 GMT, Alex Macdonald wrote: >> I have addressed this and extracted a method. > > Reading Brice's comment above, I'm thinking he meant move the `tableInspector.setFocus()` lines into it's own method so there is a centralized location to add a comment as to why this line is needed? > > Something like .. > > // 8204: this set focus is required in order to .. > private void setFocusOnTableInspector() { > tableInspector.setFocus(); > } That was my original suggestion, but since there's `setFocus` (a single statement), but at the same time it's just a suggestion that does not bring as much value since the goal of `setFocus` is somewhat straightforward. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1509233631 From bdutheil at openjdk.org Fri Mar 1 16:39:53 2024 From: bdutheil at openjdk.org (Brice Dutheil) Date: Fri, 1 Mar 2024 16:39:53 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v4] In-Reply-To: References: Message-ID: <68Zh77wCvgIjIKooDToeSvIr0wKfJYlj4SKZN16TIYM=.45af4f09-b515-44e2-9fab-dc1f67922e5f@github.com> On Fri, 1 Mar 2024 14:40:57 GMT, Alex Macdonald wrote: >> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8204: Keyboard traps in flamegraph view for search option > > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 603: > >> 601: Display.getDefault().syncExec(new Runnable() { >> 602: public void run() { >> 603: IWorkbenchPage activePage = PlatformUI.getWorkbench().getWorkbenchWindows()[0].getActivePage(); > > Minor syntax nit, but I think this could be replaced with `PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()` ? Interesting, I think Eclipse workbench allows for multiple windows (or detached one), could that be an issue for `PlatformUI.getWorkbench().getWorkbenchWindows()[0]` ? ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1509237283 From vpurnam at openjdk.org Sun Mar 3 11:39:03 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Sun, 3 Mar 2024 11:39:03 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v5] In-Reply-To: References: Message-ID: > Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: > > 1. Focus is trapped in JMC Agent Preset Manager > > Select Window -> JMC Agent Preset Manager > Click on "Import Fils..."/ "Export File" button > Press Esc button when dialog is displayed > Press "Tab" button for multi times > > 2. Focus is trapped in Description of Template Manager > > Select JVM Browser > Start Flight Recording > Template Manager > Click New > Click Edit > Focus to Description > > 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) > > Launch JDK Mission Control > Open any JFR file > Navigate to "Outline" tab > In Java Application, choose "Threads" > Move focus to search tool in Flame Graph > > Solution: > 1. PresetManagerPage.java : Setting the focus back to tableInspector. > 2. TemplateEditPage.java : Added TraverseListener() for description field. > 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. > > These issues are kind of blocker with respect to accessibility. Could someone please review the changes. Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: 8204: Keyboard traps in flamegraph view for search option ------------- Changes: - all: https://git.openjdk.org/jmc/pull/554/files - new: https://git.openjdk.org/jmc/pull/554/files/66c47719..7b7aaa2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=04 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=554&range=03-04 Stats: 17 lines in 2 files changed: 5 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/554.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/554/head:pull/554 PR: https://git.openjdk.org/jmc/pull/554 From vpurnam at openjdk.org Sun Mar 3 11:48:51 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Sun, 3 Mar 2024 11:48:51 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v2] In-Reply-To: References: Message-ID: On Fri, 1 Mar 2024 16:30:11 GMT, Brice Dutheil wrote: >> Reading Brice's comment above, I'm thinking he meant move the `tableInspector.setFocus()` lines into it's own method so there is a centralized location to add a comment as to why this line is needed? >> >> Something like .. >> >> // 8204: this set focus is required in order to .. >> private void setFocusOnTableInspector() { >> tableInspector.setFocus(); >> } > > That was my original suggestion, but since there's `setFocus` (a single statement), but at the same time it's just a suggestion that does not bring as much value since the goal of `setFocus` is somewhat straightforward. I have added setFocus to Import Button as well as Export Button. I have extracted that to a method now. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1510246163 From vpurnam at openjdk.org Sun Mar 3 11:48:52 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Sun, 3 Mar 2024 11:48:52 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v4] In-Reply-To: References: Message-ID: <5UqjwfwS59siH1Vg-HuVZNcutYZmkTaYNUTyqjATL0w=.40489e6c-7bdb-4dc8-a897-7ff7d8a124be@github.com> On Fri, 1 Mar 2024 14:45:46 GMT, Alex Macdonald wrote: >> Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: >> >> 8204: Keyboard traps in flamegraph view for search option > > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 622: > >> 620: * Adding key listener to transfer focus forward or backward based on 'TAB' or 'Shift + TAB' >> 621: * >> 622: * @param comp > > This and the following 3 methods have a `@param` but no extra details, I think maybe either remove it or just add what comp is. I have removed all `@param` > application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 835: > >> 833: var fileName = fd.getFileName().toLowerCase(); >> 834: // FIXME: FileDialog filterIndex returns -1 >> 835: // (https://bugs.eclipse.org/bugs/show_bug.cgi?id=546256) > > As a side note, it would be nice to see if this is still an issue. The bug mentions that it was not an Eclipse issue, but rather a gtk 3 issue from 2019. Currently I have only Mac and Windows. We can check on Linux later. (9.1.0) ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1510246508 PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1510246802 From vpurnam at openjdk.org Sun Mar 3 11:48:52 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Sun, 3 Mar 2024 11:48:52 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v4] In-Reply-To: <68Zh77wCvgIjIKooDToeSvIr0wKfJYlj4SKZN16TIYM=.45af4f09-b515-44e2-9fab-dc1f67922e5f@github.com> References: <68Zh77wCvgIjIKooDToeSvIr0wKfJYlj4SKZN16TIYM=.45af4f09-b515-44e2-9fab-dc1f67922e5f@github.com> Message-ID: On Fri, 1 Mar 2024 16:33:27 GMT, Brice Dutheil wrote: >> application/org.openjdk.jmc.flightrecorder.flamegraph/src/main/java/org/openjdk/jmc/flightrecorder/flamegraph/views/FlamegraphSwingView.java line 603: >> >>> 601: Display.getDefault().syncExec(new Runnable() { >>> 602: public void run() { >>> 603: IWorkbenchPage activePage = PlatformUI.getWorkbench().getWorkbenchWindows()[0].getActivePage(); >> >> Minor syntax nit, but I think this could be replaced with `PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()` ? > > Interesting, I think Eclipse workbench allows for multiple windows (or detached one), could that be an issue for `PlatformUI.getWorkbench().getWorkbenchWindows()[0]` ? Idea is to get the active editor and we get the same with PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage() as well. I have done the required change. ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/554#discussion_r1510246467 From aptmac at openjdk.org Sun Mar 3 16:56:51 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Sun, 3 Mar 2024 16:56:51 GMT Subject: RFR: 8204 : Keyboard traps in flamegraph view for search option [v5] In-Reply-To: References: Message-ID: On Sun, 3 Mar 2024 11:39:03 GMT, Virag Purnam wrote: >> Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: >> >> 1. Focus is trapped in JMC Agent Preset Manager >> >> Select Window -> JMC Agent Preset Manager >> Click on "Import Fils..."/ "Export File" button >> Press Esc button when dialog is displayed >> Press "Tab" button for multi times >> >> 2. Focus is trapped in Description of Template Manager >> >> Select JVM Browser >> Start Flight Recording >> Template Manager >> Click New >> Click Edit >> Focus to Description >> >> 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) >> >> Launch JDK Mission Control >> Open any JFR file >> Navigate to "Outline" tab >> In Java Application, choose "Threads" >> Move focus to search tool in Flame Graph >> >> Solution: >> 1. PresetManagerPage.java : Setting the focus back to tableInspector. >> 2. TemplateEditPage.java : Added TraverseListener() for description field. >> 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. >> >> These issues are kind of blocker with respect to accessibility. Could someone please review the changes. > > Virag Purnam has updated the pull request incrementally with one additional commit since the last revision: > > 8204: Keyboard traps in flamegraph view for search option Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/554#pullrequestreview-1913042378 From vpurnam at openjdk.org Mon Mar 4 07:40:51 2024 From: vpurnam at openjdk.org (Virag Purnam) Date: Mon, 4 Mar 2024 07:40:51 GMT Subject: Integrated: 8204 : Keyboard traps in flamegraph view for search option In-Reply-To: References: Message-ID: <_QuAv3_bdD0N_d_XFFdOfPCF0jP9HFM94Chx9D1Bhtc=.03421261-4969-494f-b019-554136526d28@github.com> On Fri, 23 Feb 2024 11:03:53 GMT, Virag Purnam wrote: > Focus Trapped Issue. Keyboard focus is trapped in three specific scenarios mentioned below: > > 1. Focus is trapped in JMC Agent Preset Manager > > Select Window -> JMC Agent Preset Manager > Click on "Import Fils..."/ "Export File" button > Press Esc button when dialog is displayed > Press "Tab" button for multi times > > 2. Focus is trapped in Description of Template Manager > > Select JVM Browser > Start Flight Recording > Template Manager > Click New > Click Edit > Focus to Description > > 3. Focus is trapped in search tool in Flame Graph (Mostly on Windows) > > Launch JDK Mission Control > Open any JFR file > Navigate to "Outline" tab > In Java Application, choose "Threads" > Move focus to search tool in Flame Graph > > Solution: > 1. PresetManagerPage.java : Setting the focus back to tableInspector. > 2. TemplateEditPage.java : Added TraverseListener() for description field. > 3. FlamegraphSwingView.java : Fix is not straight forward as SWT to Swing and back to SWT traversal is creating issue here. I have just implemented work around for this. I have added KeyListener() to all the swing components. Once it traverse through all the components, I am setting the Focus back to SWT. With this there is no keyboard focus trap. > > These issues are kind of blocker with respect to accessibility. Could someone please review the changes. This pull request has now been integrated. Changeset: d0fb28ff Author: Virag Purnam URL: https://git.openjdk.org/jmc/commit/d0fb28ffb5a22fad4e33b02abfd782a5caa89ab8 Stats: 202 lines in 3 files changed: 170 ins; 15 del; 17 mod 8204: Keyboard traps in flamegraph view for search option Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/554 From duke at openjdk.org Thu Mar 7 07:21:11 2024 From: duke at openjdk.org (Martin Skarsaune) Date: Thu, 7 Mar 2024 07:21:11 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: Message-ID: > Replaces parts of https://github.com/openjdk/jmc/pull/332 Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: JMC-7455: Pick up protocol extension and use it ------------- Changes: - all: https://git.openjdk.org/jmc/pull/548/files - new: https://git.openjdk.org/jmc/pull/548/files/a8016ec2..449a7ec1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=10 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=548&range=09-10 Stats: 75 lines in 1 file changed: 1 ins; 60 del; 14 mod Patch: https://git.openjdk.org/jmc/pull/548.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/548/head:pull/548 PR: https://git.openjdk.org/jmc/pull/548 From aptmac at openjdk.org Thu Mar 7 16:23:07 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 7 Mar 2024 16:23:07 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v11] In-Reply-To: References: Message-ID: On Thu, 7 Mar 2024 07:21:11 GMT, Martin Skarsaune wrote: >> Replaces parts of https://github.com/openjdk/jmc/pull/332 > > Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision: > > JMC-7455: Pick up protocol extension and use it Nice! I gave this a quick run and crawl through the debugger, and it looks like it's wired up correctly now (at least from what I ran). These changes will also require the new `org.openjdk.jmc.jolokia` and `org.openjdk.jmc.jolokia.test` dependencies be added to `application/coverage/pom.xml` for test coverage runs. Other than that I went through the code and made a couple comments. application/org.openjdk.jmc.jolokia/src/main/java/org/openjdk/jmc/jolokia/AbstractCachedDescriptorProvider.java line 49: > 47: * changes. > 48: */ > 49: @SuppressWarnings("restriction") As this will be added to JMC proper and not as an external extension, `org.openjdk.jmc.jolokia` could be added to the `org.openjdk.jmc.rjmx.descriptorprovider;x-friends` list at: https://github.com/openjdk/jmc/blob/master/application/org.openjdk.jmc.rjmx/META-INF/MANIFEST.MF#L19 application/org.openjdk.jmc.jolokia/src/main/java/org/openjdk/jmc/jolokia/AbstractCachedDescriptorProvider.java line 119: > 117: */ > 118: private void initialize() { > 119: empty space application/org.openjdk.jmc.jolokia/src/main/java/org/openjdk/jmc/jolokia/JmcJolokiaJmxConnectionProvider.java line 48: > 46: public JMXConnector newJMXConnector(JMXServiceURL serviceURL, Map environment) throws IOException { > 47: if (!"jolokia".equals(serviceURL.getProtocol())) { //$NON-NLS-1$ > 48: throw new MalformedURLException("I only serve Jolokia connections"); //$NON-NLS-1$ I think it'd be nicer if these strings were moved into `Messages.java` application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ProtocolInitializer.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. License year update 2023 -> 2024 application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServerHandle.java line 35: > 33: package org.openjdk.jmc.rjmx.internal; > 34: > 35: import java.io.IOException; This file will need a license year update too application/org.openjdk.jmc.rjmx/src/main/java/org/openjdk/jmc/rjmx/internal/ServerHandle.java line 147: > 145: descriptor.getEnvironment()); > 146: } catch (IOException e) { > 147: Logger.getLogger(getClass().getName()).log(Level.INFO, "Error attempting JMX protocol extensions", e); Could use the `RJMXPlugin.getDefault().getLogger()` here and save on the import application/tests/org.openjdk.jmc.jolokia.test/META-INF/MANIFEST.MF line 11: > 9: Require-Bundle: org.junit, > 10: org.openjdk.jmc.jolokia, > 11: org.eclipse.osgi;bundle-version="3.16.200", For osgi and hamcrest listed here, is it necessary for them to be targeted to specific versions? application/tests/org.openjdk.jmc.jolokia.test/pom.xml line 68: > 66: ${test.includes} > 67: > 68: Will need to add `${surefireArgLine}` in here for Jacoco to pick it up, once added to the `coverage/pom.xml` core/org.openjdk.jmc.rjmx.common/src/main/java/org/openjdk/jmc/rjmx/common/internal/RJMXConnection.java line 591: > 589: > 590: private void connectJmxConnector(JMXServiceURL serviceURL, Map env) throws IOException { > 591: if (m_jmxc == null) { This file will need a license year update too ------------- PR Review: https://git.openjdk.org/jmc/pull/548#pullrequestreview-1922664846 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516329219 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516329913 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516337637 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516293491 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516294248 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516351189 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516353673 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516426135 PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516294427 From aptmac at openjdk.org Thu Mar 7 16:23:08 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 7 Mar 2024 16:23:08 GMT Subject: RFR: 7455: Add support for jolokia JMX service connection [v4] In-Reply-To: References: Message-ID: On Fri, 26 Jan 2024 13:16:07 GMT, Martin Skarsaune wrote: >> Martin Skarsaune has updated the pull request incrementally with four additional commits since the last revision: >> >> - JMC-7455: Ensure that jolokia version is set >> - JMC-7455: Fix copy paste and outdated errors in Jolokia plugin manifest >> - JMC-7455: Fixed whitespace of feature declaration >> - JMC-7455: Fix copyright notices (change year) in Jolokia plugin > > pom.xml line 112: > >> 110: 4.7.3.5 >> 111: 0.8.7 >> 112: 1.7.2 > > Wondering whether this was too high up in the chain. I was hoping to have a way to keep versions consistent among third-party and internally in plugins. Then again, due to manifests etc. there is a question on to what extent managing versions centrally is a point at all. > > When it comes to the actual version. 1.7.2 has the needed features. I should probably retest with 2.0.1 and check to what extent the 2.0 stream works well enough. Is there a way to put PR in draft mode while we test? Just noticed this comment, there should be away to mark the PR as draft, I believe the option should be in the right-side column at the top of: https://github.com/openjdk/jmc/pull/548 ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/548#discussion_r1516367742 From hirt at openjdk.org Mon Mar 11 20:42:36 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 11 Mar 2024 20:42:36 GMT Subject: RFR: 8202: JMC 9 release notes Message-ID: First draft! Please let me know what I missed. :) ------------- Commit messages: - Adding images and various fixes - Some more text - Removing wrongly located file - 8202: JMC 9 Release Notes tmp Changes: https://git.openjdk.org/jmc/pull/555/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8202 Stats: 263 lines in 37 files changed: 261 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jmc/pull/555.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/555/head:pull/555 PR: https://git.openjdk.org/jmc/pull/555 From aptmac at openjdk.org Tue Mar 12 13:49:21 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 12 Mar 2024 13:49:21 GMT Subject: RFR: 8202: JMC 9 release notes In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 20:37:13 GMT, Marcus Hirt wrote: > First draft! Please let me know what I missed. :) Looks good! I left a couple comments inline. I think it's a comprehensive list of features, but if you want to pad it a bit more there is the Dark Mode feature that could look nice in there, as well as the File Force Rule from https://github.com/openjdk/jmc/commit/f7ee5856528f474936b032361cc46a5ccfc6d4a7 releng/tools/org.openjdk.jmc.util.releasenotes/notes/9.0/notes.xml line 12: > 10: several new features, enhancements, and bug fixes. This version continues to support connecting to, and parsing > 11: JFR recordings from, OpenJDK 8u272+ and Oracle JDK 7u40+, and can open and visualize flight recordings from JDK 7 > 12: and 8. JDK Mission Control is available for Windows (x86_64), Mac OS X (ARM and x86_64), and Linux (x86_64). The Linux part should mention ARM releng/tools/org.openjdk.jmc.util.releasenotes/notes/9.0/notes.xml line 47: > 45: Add user configuration for local JVM refresh interval > 46: > 47: Previously the JVM Browser checked every 5000 ms [0] for new JVMs. This can now be configured. Doesn't need the `[0]` here releng/tools/org.openjdk.jmc.util.releasenotes/notes/9.0/notes.xml line 77: > 75: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common > 76: > 77: There are a number of classes currently in jmc.ui.common that would be a great asset to the core distribution (and the Since the refactoring has happened, I think the first part of this sentence should probably be put in the past tense, something like: There were a number of classes previously in jmc.ui.common that are a great asset to the core distribution (and the third-party applications that consume jmc core libraries), and these classes now live in jmc.common. releng/tools/org.openjdk.jmc.util.releasenotes/notes/9.0/notes.xml line 95: > 93: > 94: The org.openjdk.jmc.flightrecorder.configuration bundle contains many classes useful for working with jfr, > 95: and would be a great asset to have in core. Please see JMC-7307 for further information. Maybe re-word the last part of that first sentence to something like: s/and would be a great asset to have in core./and are now made available in core./ ------------- PR Review: https://git.openjdk.org/jmc/pull/555#pullrequestreview-1931080499 PR Review Comment: https://git.openjdk.org/jmc/pull/555#discussion_r1521475025 PR Review Comment: https://git.openjdk.org/jmc/pull/555#discussion_r1521475596 PR Review Comment: https://git.openjdk.org/jmc/pull/555#discussion_r1521479779 PR Review Comment: https://git.openjdk.org/jmc/pull/555#discussion_r1521481955 From hirt at openjdk.org Tue Mar 12 14:18:37 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 12 Mar 2024 14:18:37 GMT Subject: RFR: 8202: JMC 9 release notes [v2] In-Reply-To: References: Message-ID: > First draft! Please let me know what I missed. :) Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Acting on feedback ------------- Changes: - all: https://git.openjdk.org/jmc/pull/555/files - new: https://git.openjdk.org/jmc/pull/555/files/cb0c0cfa..64ab04ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jmc/pull/555.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/555/head:pull/555 PR: https://git.openjdk.org/jmc/pull/555 From aptmac at openjdk.org Tue Mar 12 14:23:18 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 12 Mar 2024 14:23:18 GMT Subject: RFR: 8202: JMC 9 release notes [v2] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:18:37 GMT, Marcus Hirt wrote: >> First draft! Please let me know what I missed. :) > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Acting on feedback releng/tools/org.openjdk.jmc.util.releasenotes/notes/9.0/notes.xml line 77: > 75: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common > 76: > 77: There were a number of classes prviously in jmc.ui.common that would be a great asset to the core distribution s/prviously/previously/ ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/555#discussion_r1521558300 From aptmac at openjdk.org Tue Mar 12 14:24:25 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 12 Mar 2024 14:24:25 GMT Subject: RFR: 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward Message-ID: This PR adds some information to the devguide about using Eclipse 2023-06 and above. Newer Eclipse IDEs force the use of HTTPS for external update sites and artifacts, which out of the box conflicts with our local p2 repository. The fix is to allow http in Preferences > Install/Update > Trust > Authorities > Protocol Rules. I've added a screenshot to doc as well highlighting where to find it. I had run into this yesterday when taking a look at some interesting behaviour I was seeing when testing the Jolokia PR https://github.com/openjdk/jmc/pull/548#issuecomment-1989331436. ------------- Commit messages: - 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward Changes: https://git.openjdk.org/jmc/pull/556/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=556&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8210 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/556.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/556/head:pull/556 PR: https://git.openjdk.org/jmc/pull/556 From hirt at openjdk.org Tue Mar 12 14:57:35 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 12 Mar 2024 14:57:35 GMT Subject: RFR: 8202: JMC 9 release notes [v3] In-Reply-To: References: Message-ID: > First draft! Please let me know what I missed. :) Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Adding dark mode, file channel force and a nicer image for linux aarch64 ------------- Changes: - all: https://git.openjdk.org/jmc/pull/555/files - new: https://git.openjdk.org/jmc/pull/555/files/64ab04ca..fe3d25ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=01-02 Stats: 17 lines in 5 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/555.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/555/head:pull/555 PR: https://git.openjdk.org/jmc/pull/555 From hirt at openjdk.org Tue Mar 12 15:07:19 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 12 Mar 2024 15:07:19 GMT Subject: RFR: 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:19:46 GMT, Alex Macdonald wrote: > This PR adds some information to the devguide about using Eclipse 2023-06 and above. Newer Eclipse IDEs force the use of HTTPS for external update sites and artifacts, which out of the box conflicts with our local p2 repository. > > The fix is to allow http in Preferences > Install/Update > Trust > Authorities > Protocol Rules. I've added a screenshot to doc as well highlighting where to find it. > > I had run into this yesterday when taking a look at some interesting behaviour I was seeing when testing the Jolokia PR https://github.com/openjdk/jmc/pull/548#issuecomment-1989331436. Isn't this dealt with earlier in the dev guide? " Install Eclipse, and before starting it, add the following two lines to the eclipse.ini file: ``` -Dp2.httpRule=allow -Dp2.trustedAuthorities=https://download.eclipse.org,https://archive.eclipse.org,http://localhost ``` " ------------- PR Comment: https://git.openjdk.org/jmc/pull/556#issuecomment-1991867947 From hirt at openjdk.org Tue Mar 12 15:11:39 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 12 Mar 2024 15:11:39 GMT Subject: RFR: 8202: JMC 9 release notes [v4] In-Reply-To: References: Message-ID: > First draft! Please let me know what I missed. :) Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Fixing typos ------------- Changes: - all: https://git.openjdk.org/jmc/pull/555/files - new: https://git.openjdk.org/jmc/pull/555/files/fe3d25ff..ab63bff9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=03 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jmc/pull/555.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/555/head:pull/555 PR: https://git.openjdk.org/jmc/pull/555 From hirt at openjdk.org Tue Mar 12 17:02:39 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 12 Mar 2024 17:02:39 GMT Subject: RFR: 8202: JMC 9 release notes [v5] In-Reply-To: References: Message-ID: > First draft! Please let me know what I missed. :) Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Better file force image ------------- Changes: - all: https://git.openjdk.org/jmc/pull/555/files - new: https://git.openjdk.org/jmc/pull/555/files/ab63bff9..dac8289c Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=04 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=555&range=03-04 Stats: 1 line in 3 files changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jmc/pull/555.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/555/head:pull/555 PR: https://git.openjdk.org/jmc/pull/555 From aptmac at openjdk.org Wed Mar 13 14:05:18 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 13 Mar 2024 14:05:18 GMT Subject: RFR: 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 15:04:57 GMT, Marcus Hirt wrote: > Isn't this dealt with earlier in the dev guide? > > " Install Eclipse, and before starting it, add the following two lines to the eclipse.ini file: > > ``` > -Dp2.httpRule=allow > -Dp2.trustedAuthorities=https://download.eclipse.org,https://archive.eclipse.org,http://localhost > ``` > > " Ah yes, although maybe it'd be useful to have both options described in the devguide. I'll reword the preferences part and move it up closer to where the eclipse.ini file content is. ------------- PR Comment: https://git.openjdk.org/jmc/pull/556#issuecomment-1994481965 From aptmac at openjdk.org Wed Mar 13 14:28:19 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 13 Mar 2024 14:28:19 GMT Subject: RFR: 8202: JMC 9 release notes [v5] In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 17:02:39 GMT, Marcus Hirt wrote: >> First draft! Please let me know what I missed. :) > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Better file force image Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/555#pullrequestreview-1934335262 From aptmac at openjdk.org Wed Mar 13 14:52:40 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Wed, 13 Mar 2024 14:52:40 GMT Subject: RFR: 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward [v2] In-Reply-To: References: Message-ID: > This PR adds some information to the devguide about using Eclipse 2023-06 and above. Newer Eclipse IDEs force the use of HTTPS for external update sites and artifacts, which out of the box conflicts with our local p2 repository. > > The fix is to allow http in Preferences > Install/Update > Trust > Authorities > Protocol Rules. I've added a screenshot to doc as well highlighting where to find it. > > I had run into this yesterday when taking a look at some interesting behaviour I was seeing when testing the Jolokia PR https://github.com/openjdk/jmc/pull/548#issuecomment-1989331436. Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Move the mention of the Preferences setting to be alongside the eclipse.ini method - 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward ------------- Changes: https://git.openjdk.org/jmc/pull/556/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=556&range=01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jmc/pull/556.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/556/head:pull/556 PR: https://git.openjdk.org/jmc/pull/556 From hirt at openjdk.org Wed Mar 13 18:15:27 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 13 Mar 2024 18:15:27 GMT Subject: Integrated: 8202: JMC 9 release notes In-Reply-To: References: Message-ID: On Mon, 11 Mar 2024 20:37:13 GMT, Marcus Hirt wrote: > First draft! Please let me know what I missed. :) This pull request has now been integrated. Changeset: 95749c57 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/95749c57e97919fd900be5a807ad83d62f264023 Stats: 279 lines in 43 files changed: 277 ins; 0 del; 2 mod 8202: JMC 9 release notes Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/555 From duke at openjdk.org Wed Mar 13 18:21:34 2024 From: duke at openjdk.org (duke) Date: Wed, 13 Mar 2024 18:21:34 GMT Subject: git: openjdk/jmc: Added tag 9.0.0-rc for changeset 4ee71fe7 Message-ID: <759d3f82-a7b8-4112-9307-f662325bc7ce@openjdk.org> Tagged by: thegreystone Date: 2024-03-13 19:19:29 +0000 Release candidate for JMC 9.0.0 Changeset: 4ee71fe7 Author: Marcus Hirt Committer: thegreystone Date: 2024-03-13 18:12:54 +0000 URL: https://git.openjdk.org/jmc/commit/4ee71fe72d117088c40f6bae2fa2e7f7d6f7a004 From marcus at hirt.se Wed Mar 13 19:51:55 2024 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 13 Mar 2024 20:51:55 +0100 Subject: JMC 9.0 RC tag set Message-ID: <005a01da757f$e6c70530$b4550f90$@hirt.se> Hi all, As of today, the JMC 9.0 release candidate tag has been set: https://github.com/openjdk/jmc/tags If no release-blocking problems are found, I plan on setting the GA tag by the end of next week. A big thank you to all contributors! Kind regards, Marcus From marcus at hirt.se Wed Mar 13 19:59:43 2024 From: marcus at hirt.se (Marcus Hirt) Date: Wed, 13 Mar 2024 20:59:43 +0100 Subject: JMC 9.1.0 plan Message-ID: <006501da7580$fd938c60$f8baa520$@hirt.se> Hi all, I think the following plan could work for JMC 9.1.0: * 2024-11-06 - Rampdown Start * 2024-12-18 - Rampdown Phase 2 * 2025-01-29 - GA This gives us a little bit more time in each phase for 9.1.0. Please let me know what you think! Kind regards, Marcus From hirt at openjdk.org Wed Mar 13 21:23:43 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Wed, 13 Mar 2024 21:23:43 GMT Subject: RFR: 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward [v2] In-Reply-To: References: Message-ID: On Wed, 13 Mar 2024 14:52:40 GMT, Alex Macdonald wrote: >> This PR adds some information to the devguide about using Eclipse 2023-06 and above. Newer Eclipse IDEs force the use of HTTPS for external update sites and artifacts, which out of the box conflicts with our local p2 repository. >> >> The fix is to allow http in Preferences > Install/Update > Trust > Authorities > Protocol Rules. I've added a screenshot to doc as well highlighting where to find it. >> >> I had run into this yesterday when taking a look at some interesting behaviour I was seeing when testing the Jolokia PR https://github.com/openjdk/jmc/pull/548#issuecomment-1989331436. > > Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Move the mention of the Preferences setting to be alongside the eclipse.ini method > - 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward Marked as reviewed by hirt (Lead). ------------- PR Review: https://git.openjdk.org/jmc/pull/556#pullrequestreview-1935241607 From aptmac at openjdk.org Thu Mar 14 00:12:43 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Thu, 14 Mar 2024 00:12:43 GMT Subject: Integrated: 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward In-Reply-To: References: Message-ID: On Tue, 12 Mar 2024 14:19:46 GMT, Alex Macdonald wrote: > This PR adds some information to the devguide about using Eclipse 2023-06 and above. Newer Eclipse IDEs force the use of HTTPS for external update sites and artifacts, which out of the box conflicts with our local p2 repository. > > The fix is to allow http in Preferences > Install/Update > Trust > Authorities > Protocol Rules. I've added a screenshot to doc as well highlighting where to find it. > > I had run into this yesterday when taking a look at some interesting behaviour I was seeing when testing the Jolokia PR https://github.com/openjdk/jmc/pull/548#issuecomment-1989331436. This pull request has now been integrated. Changeset: a735f51e Author: Alex Macdonald URL: https://git.openjdk.org/jmc/commit/a735f51ef1e572895ab90ac5578e909151357108 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8210: Update devguide to mention Protocol Rules for Eclipse 2023-06 onward Reviewed-by: hirt ------------- PR: https://git.openjdk.org/jmc/pull/556 From jbachorik at openjdk.org Thu Mar 14 11:06:15 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 14 Mar 2024 11:06:15 GMT Subject: RFR: 7992: Add API to easily write annotated Java JFR events [v3] In-Reply-To: References: Message-ID: > This PR extends the JFR Writer API with the ability to use the custom JFR event types (eg. classes extending `jdk.jfr.Event`) and register new writer type for them and also directly accept the instances of those types to write them in the recording. Jaroslav Bachorik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into jb/JMC-7992 - Add more explanatory comments - Add javadoc for the new public methods - Update copyright year - JMC-7992: Add API to easily write annotated Java JFR events ------------- Changes: - all: https://git.openjdk.org/jmc/pull/457/files - new: https://git.openjdk.org/jmc/pull/457/files/e4e6c7cf..5bd8c044 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=457&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=457&range=01-02 Stats: 495 lines in 49 files changed: 459 ins; 15 del; 21 mod Patch: https://git.openjdk.org/jmc/pull/457.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/457/head:pull/457 PR: https://git.openjdk.org/jmc/pull/457 From schaturvedi at openjdk.org Fri Mar 15 14:48:08 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Fri, 15 Mar 2024 14:48:08 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC Message-ID: This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. JVM PID before the change: image JVM PID after the change: image The issue is more prominent when the identifier value is converted to exponential. ------------- Commit messages: - 7506: Incorrect numeric formatting of PID by JMC Changes: https://git.openjdk.org/jmc/pull/557/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=00 Issue: https://bugs.openjdk.org/browse/JMC-7506 Stats: 33 lines in 3 files changed: 29 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jmc/pull/557.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/557/head:pull/557 PR: https://git.openjdk.org/jmc/pull/557 From duke at openjdk.org Fri Mar 22 21:37:42 2024 From: duke at openjdk.org (duke) Date: Fri, 22 Mar 2024 21:37:42 GMT Subject: git: openjdk/jmc: Added tag 9.0.0-ga for changeset 4ee71fe7 Message-ID: Tagged by: thegreystone Date: 2024-03-22 22:35:15 +0000 GA source release for JMC 9.0.0 Changeset: 4ee71fe7 Author: Marcus Hirt Committer: thegreystone Date: 2024-03-13 18:12:54 +0000 URL: https://git.openjdk.org/jmc/commit/4ee71fe72d117088c40f6bae2fa2e7f7d6f7a004 From schaturvedi at openjdk.org Mon Mar 25 05:05:39 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Mon, 25 Mar 2024 05:05:39 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v2] In-Reply-To: References: Message-ID: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. > > JVM PID before the change: > image > > JVM PID after the change: > image > > The issue is more prominent when the identifier value is converted to exponential. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Fixed the pid formatting issue on Event Browser and Properties section also ------------- Changes: - all: https://git.openjdk.org/jmc/pull/557/files - new: https://git.openjdk.org/jmc/pull/557/files/e3a35004..265d1a83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=00-01 Stats: 27 lines in 6 files changed: 4 ins; 4 del; 19 mod Patch: https://git.openjdk.org/jmc/pull/557.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/557/head:pull/557 PR: https://git.openjdk.org/jmc/pull/557 From schaturvedi at openjdk.org Mon Mar 25 05:18:26 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Mon, 25 Mar 2024 05:18:26 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v2] In-Reply-To: References: Message-ID: <5BJzHKIvnZz3VWfueZNjWC5krQshH8Ay1e9cu8ae0uY=.e96faa2b-d90e-4afe-9786-20939e8b21a5@github.com> On Mon, 25 Mar 2024 05:05:39 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed the pid formatting issue on Event Browser and Properties section also For the JVM PID 2177: ![image](https://github.com/openjdk/jmc/assets/11155712/1a7ee492-a970-4c1c-826d-93b36be297c0) **Before the Change:** JVM Internal Page Screenshot 2024-03-25 103611 Event Browser Page Screenshot 2024-03-25 104001 **After the Change:** JVM Internal Page Screenshot 2024-03-25 104207 Event Browser Page Screenshot 2024-03-25 104343 ------------- PR Comment: https://git.openjdk.org/jmc/pull/557#issuecomment-2017233921 From hirt at openjdk.org Mon Mar 25 15:30:29 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 25 Mar 2024 15:30:29 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v2] In-Reply-To: References: Message-ID: <9RXxU0k7LLFMwMGuooxy_OKNJVhM31w38XEfqFjDl-E=.351d635a-4489-4b12-900a-215d6704a3e0@github.com> On Mon, 25 Mar 2024 05:05:39 GMT, Suchita Chaturvedi wrote: >> This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. >> >> As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. >> >> JVM PID before the change: >> image >> >> JVM PID after the change: >> image >> >> The issue is more prominent when the identifier value is converted to exponential. > > Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed the pid formatting issue on Event Browser and Properties section also Changes requested by hirt (Lead). core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/Aggregators.java line 1051: > 1049: } > 1050: > 1051: public static IAggregator getIdentifier(String typeId, IAttribute attribute) { Do we need a special aggregator for this? We should override the value type for the PID field so that the correct value type is returned. core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/Aggregators.java line 1057: > 1055: @Override > 1056: public IType getValueType() { > 1057: return UnitLookup.RAW_NUMBER; If we're going this route, I guess this should be RAW_LONG. It does make process identifiers prone to any changes to default formatting of longs though. Another solution would be to introduce a ProcessIdentifier content type, and handle the formatting of that content type more explicitly. This is a smaller change though, and I think acceptable for now. ------------- PR Review: https://git.openjdk.org/jmc/pull/557#pullrequestreview-1958055833 PR Review Comment: https://git.openjdk.org/jmc/pull/557#discussion_r1537787635 PR Review Comment: https://git.openjdk.org/jmc/pull/557#discussion_r1537779076 From hirt at openjdk.org Mon Mar 25 22:15:35 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Mon, 25 Mar 2024 22:15:35 GMT Subject: RFR: 8212: Update trunk to 9.1.0 Message-ID: Also EA splash and minor versioning fixes. ------------- Commit messages: - EA splash - Minor fixes - Update to 9.1.0 Changes: https://git.openjdk.org/jmc/pull/558/files Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=558&range=00 Issue: https://bugs.openjdk.org/browse/JMC-8212 Stats: 251 lines in 151 files changed: 0 ins; 0 del; 251 mod Patch: https://git.openjdk.org/jmc/pull/558.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/558/head:pull/558 PR: https://git.openjdk.org/jmc/pull/558 From hirt at openjdk.org Tue Mar 26 11:44:39 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 26 Mar 2024 11:44:39 GMT Subject: RFR: 8212: Update trunk to 9.1.0 [v2] In-Reply-To: References: Message-ID: > Also EA splash and minor versioning fixes. Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: Copyright updates ------------- Changes: - all: https://git.openjdk.org/jmc/pull/558/files - new: https://git.openjdk.org/jmc/pull/558/files/18311642..dd157427 Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=558&range=01 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=558&range=00-01 Stats: 10 lines in 6 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jmc/pull/558.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/558/head:pull/558 PR: https://git.openjdk.org/jmc/pull/558 From aptmac at openjdk.org Tue Mar 26 14:54:26 2024 From: aptmac at openjdk.org (Alex Macdonald) Date: Tue, 26 Mar 2024 14:54:26 GMT Subject: RFR: 8212: Update trunk to 9.1.0 [v2] In-Reply-To: References: Message-ID: On Tue, 26 Mar 2024 11:44:39 GMT, Marcus Hirt wrote: >> Also EA splash and minor versioning fixes. > > Marcus Hirt has updated the pull request incrementally with one additional commit since the last revision: > > Copyright updates Marked as reviewed by aptmac (Reviewer). ------------- PR Review: https://git.openjdk.org/jmc/pull/558#pullrequestreview-1960673185 From hirt at openjdk.org Tue Mar 26 18:43:27 2024 From: hirt at openjdk.org (Marcus Hirt) Date: Tue, 26 Mar 2024 18:43:27 GMT Subject: Integrated: 8212: Update trunk to 9.1.0 In-Reply-To: References: Message-ID: On Mon, 25 Mar 2024 22:11:43 GMT, Marcus Hirt wrote: > Also EA splash and minor versioning fixes. This pull request has now been integrated. Changeset: 12dba597 Author: Marcus Hirt URL: https://git.openjdk.org/jmc/commit/12dba597abd009f41e97f47ac4197f0c5ee9fc0e Stats: 260 lines in 151 files changed: 0 ins; 0 del; 260 mod 8212: Update trunk to 9.1.0 Reviewed-by: aptmac ------------- PR: https://git.openjdk.org/jmc/pull/558 From schaturvedi at openjdk.org Fri Mar 29 02:57:30 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Fri, 29 Mar 2024 02:57:30 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v3] In-Reply-To: References: Message-ID: > This PR is to fix the formatting issue of the JVM PID on JVM information screen. JVM PID attribute is received as NUMBER from JFR and hence the JMC application is treating is as number. When the number is smaller , the PID is displayed using commas and when the number is larger, its converted to exponential format. This is a long pending bug in product. > > As part of this PR we have introduced a new aggregator JVM_PID_ID which will contain the value of Identifier in plain text format instead of number format. This new aggregator is displayed on JVM Information page so that formatting is not applied as per NUMBER formatting rules. > > JVM PID before the change: > image > > JVM PID after the change: > image > > The issue is more prominent when the identifier value is converted to exponential. Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: Used changed pid datatype from NUMBER to LONG as per review comment ------------- Changes: - all: https://git.openjdk.org/jmc/pull/557/files - new: https://git.openjdk.org/jmc/pull/557/files/265d1a83..43abce3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=02 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=557&range=01-02 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jmc/pull/557.diff Fetch: git fetch https://git.openjdk.org/jmc.git pull/557/head:pull/557 PR: https://git.openjdk.org/jmc/pull/557 From schaturvedi at openjdk.org Fri Mar 29 03:14:35 2024 From: schaturvedi at openjdk.org (Suchita Chaturvedi) Date: Fri, 29 Mar 2024 03:14:35 GMT Subject: RFR: 7506: Incorrect numeric formatting of PID by JMC [v2] In-Reply-To: <9RXxU0k7LLFMwMGuooxy_OKNJVhM31w38XEfqFjDl-E=.351d635a-4489-4b12-900a-215d6704a3e0@github.com> References: <9RXxU0k7LLFMwMGuooxy_OKNJVhM31w38XEfqFjDl-E=.351d635a-4489-4b12-900a-215d6704a3e0@github.com> Message-ID: On Mon, 25 Mar 2024 15:22:22 GMT, Marcus Hirt wrote: >> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed the pid formatting issue on Event Browser and Properties section also > > core/org.openjdk.jmc.common/src/main/java/org/openjdk/jmc/common/item/Aggregators.java line 1057: > >> 1055: @Override >> 1056: public IType getValueType() { >> 1057: return UnitLookup.RAW_NUMBER; > > If we're going this route, I guess this should be RAW_LONG. It does make process identifiers prone to any changes to default formatting of longs though. Another solution would be to introduce a ProcessIdentifier content type, and handle the formatting of that content type more explicitly. This is a smaller change though, and I think acceptable for now. I have changed the RAW_NUMBER to RAW_LONG in aggregator. But JDKAttribute will still be RAW_NUMBER because pid content type is in raw number format only. ContentTypePID If I change it there then accessors are not compatible and the attribute value is not read. It shows N/A on JVM Internal screen. image However it shows proper value in Event Browser and Properties tab. image ------------- PR Review Comment: https://git.openjdk.org/jmc/pull/557#discussion_r1544001602