From duke at openjdk.org  Tue Jan  3 22:06:57 2023
From: duke at openjdk.org (Martin Skarsaune)
Date: Tue, 3 Jan 2023 22:06:57 GMT
Subject: RFR: 7455: Add support for jolokia JMX service connection [v31]
In-Reply-To: <Y7aRG1pITZMqsxgoil5h629cZPSCR58D2DuP4Ofco68=.05449cc7-ce01-4852-b2c4-e356209ab11f@github.com>
References: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
 <Y7aRG1pITZMqsxgoil5h629cZPSCR58D2DuP4Ofco68=.05449cc7-ce01-4852-b2c4-e356209ab11f@github.com>
Message-ID: <rYB33-HHR_Aa7_qO8uNgrhSMJqiTJiO5r5YBvdFWSFE=.cedc33a8-be52-4add-a7e7-5c02ba26d548@github.com>

On Mon, 26 Dec 2022 22:15:10 GMT, Martin Skarsaune <duke at openjdk.org> wrote:

>> Setting back for review. The azure problem requires a fix in Jolokia.
>> 
>> Make use of support for JMX service connection in jolokia 1.7.0 and later to connect to JVMs over this protocol.
>
> Martin Skarsaune has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Merge remote-tracking branch 'origin/master' into jolokia-support

Found a functional problem with the Kubernetes test after upgrading to jolokia 1.7.2. will investigate ASAP

-------------

PR: https://git.openjdk.org/jmc/pull/332

From duke at openjdk.org  Tue Jan  3 22:30:09 2023
From: duke at openjdk.org (Martin Skarsaune)
Date: Tue, 3 Jan 2023 22:30:09 GMT
Subject: RFR: 7455: Add support for jolokia JMX service connection [v32]
In-Reply-To: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
References: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
Message-ID: <GIhErc6Yn_8wQLAPs9FCuDdsH6GhyzZRgoR_R31ahng=.0081d890-f3a3-4a04-87c6-76c7c2faa9bb@github.com>

> Setting back for review. The azure problem requires a fix in Jolokia.
> 
> Make use of support for JMX service connection in jolokia 1.7.0 and later to connect to JVMs over this protocol.

Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision:

  JMC-7455: Adjust wiremock path usage to match changes in jolokia update

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/332/files
  - new: https://git.openjdk.org/jmc/pull/332/files/1783f1bc..b33f15be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=31
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=30-31

  Stats: 17 lines in 15 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jmc/pull/332.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/332/head:pull/332

PR: https://git.openjdk.org/jmc/pull/332

From duke at openjdk.org  Wed Jan  4 07:52:18 2023
From: duke at openjdk.org (Martin Skarsaune)
Date: Wed, 4 Jan 2023 07:52:18 GMT
Subject: RFR: 7455: Add support for jolokia JMX service connection [v33]
In-Reply-To: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
References: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
Message-ID: <XjxvL4fJP1vfTB5oBqcxorewsa-S_9Dg7P_1XWEvWLc=.2120cc5a-96a0-42af-9157-c80147211485@github.com>

> Setting back for review. The azure problem requires a fix in Jolokia.
> 
> Make use of support for JMX service connection in jolokia 1.7.0 and later to connect to JVMs over this protocol.

Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision:

  JMC-7455: Review comments. Improve javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/332/files
  - new: https://git.openjdk.org/jmc/pull/332/files/b33f15be..a8d49090

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=32
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=31-32

  Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jmc/pull/332.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/332/head:pull/332

PR: https://git.openjdk.org/jmc/pull/332

From schaturvedi at openjdk.org  Sun Jan  8 19:44:04 2023
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Sun, 8 Jan 2023 19:44:04 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v6]
In-Reply-To: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
Message-ID: <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>

> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.

Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:

  Removed the synchronized block and used ConcurrentLinkedQueue instead

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/419/files
  - new: https://git.openjdk.org/jmc/pull/419/files/4206f70c..292b2251

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=05
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=04-05

  Stats: 36 lines in 5 files changed: 24 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jmc/pull/419.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/419/head:pull/419

PR: https://git.openjdk.org/jmc/pull/419

From schaturvedi at openjdk.org  Sun Jan  8 19:51:57 2023
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Sun, 8 Jan 2023 19:51:57 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v6]
In-Reply-To: <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
 <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>
Message-ID: <f0SZ7ltwqnYNBDKhJLwWwUig8rdJW2pGIEcDw1kcFFg=.566be353-0ef2-4cda-859e-f365e076baeb@github.com>

On Sun, 8 Jan 2023 19:44:04 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the synchronized block and used ConcurrentLinkedQueue instead

In the latest patch, I have removed the synchronized block which was the main bottle neck for the approval of this PR. Also, used the suggested data structure i.e. ConcurrentLinkedQueue for the processing of records. 

I have debugged in detail and figured out that the reason for inconsistent results for the customer JFR which has around 65000 class entries to process was the time multithreaded tasks were taking to complete which was dependent on many factors like how many cores our CPU has OR how busy our CPU is when its performing those tasks. Hence, for safer side I have added a check to see whether all tasks are performed or not. If not, I have added a console message to alert the user for increasing the configured timeout. The default timeout is 5 min which is quite sufficient to complete all the tasks still if the count of entries are too much and there are some pending tasks, user will be alerted for the same.

-------------

PR: https://git.openjdk.org/jmc/pull/419

From erik.helin at oracle.com  Fri Jan 13 14:42:37 2023
From: erik.helin at oracle.com (Erik Duveblad)
Date: Fri, 13 Jan 2023 14:42:37 +0000
Subject: Can JMC handle multiple YoungGarbageCollectionEvents with the same
 value for the gcId field?
Message-ID: <65AFF026-29C6-4931-BAB0-D5379021DC37@oracle.com>

Hey all,

I?m looking at the JFR events that will be sent for generational ZGC [0].

With generational ZGC there are broadly speaking two kinds of garbage collections (?minor? and ?major?) and each garbage collection can collect one or more generations, zero or more times. More concretely, a minor garbage collection will collect the young generation once and a major garbage collection will collect the young generation _one or two times_ and the old generation once.

The JFR events I plan for generational ZGC to send are:

- a ?jdk.GarbageCollection? event when a ?minor? or ?major? garbage collection occurs
- a ?jdk.YoungGarbageCollection? event when the young generation is collected
- a ?jdk.OldGarbageCollection? event when the old generation is collected

Combining the above means that there is a new situation: when a major garbage collection occurs that collects the young generation *two* times and the old generation once, then the following events will be sent:

- one ?jdk.GarbageCollection? event with a given gcId ?n"
- two ?jdk.YoungGarbageCollection? events with the gcId field set to ?n?
- one ?jdk.OldGarbageCollection? event with the gcId field to to ?n?

This would be the first time a HotSpot garbage collector sends multiple (two in this case) ?jdk.YoungGarbageCollection? events with the same value for the gcId field. So I wanted to check with you all if JMC makes any assumptions or relies upon the fact that up until now all ?jdk.YoungGarbageCollection? events have a unique value for the ?gcId? field?

Thanks,
Erik


[0]: https://openjdk.org/jeps/8272979

From duke at openjdk.org  Sat Jan 14 19:22:15 2023
From: duke at openjdk.org (Martin Skarsaune)
Date: Sat, 14 Jan 2023 19:22:15 GMT
Subject: RFR: 7455: Add support for jolokia JMX service connection [v28]
In-Reply-To: <m9xSgsBitw5LRXk49xuaYcF5SvxrcR4mqUjeqhzldYY=.1e6db6aa-5153-4b4b-953e-437a4fe2ea2a@github.com>
References: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
 <YcnNCyI9B7B0tNwd1Z3ap6Dgs4qHBSOdZpPydswuQ4o=.36e971a3-c3b0-40c3-99e8-51731daf99a8@github.com>
 <CZu3GGq0eQBd-sqbJ9ZwXYq4cKkd0zpGKmIUcCk7EQ8=.c4d98f6b-6bc8-4ebc-9e04-ffc9aa42e9b4@github.com>
 <m9xSgsBitw5LRXk49xuaYcF5SvxrcR4mqUjeqhzldYY=.1e6db6aa-5153-4b4b-953e-437a4fe2ea2a@github.com>
Message-ID: <h-cG9Tb3eUUMx96IoZakc391S8NC-HmHBdPChEt5hFw=.592ce9c4-e61b-457d-9049-a54325aa0843@github.com>

On Mon, 19 Dec 2022 22:49:46 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Manual tests look good. Solved a problem with stored credentials. Have requested merges and a release on the jolokia side.
>> Still problems running the test though. Would it be possible to request a CI run on this PR?
>
> Hi @skarsaune! Are you ready to make this PR ready for review? 
> 
> Regarding the tests, typically the tests would be run in your fork, on commits to your branch. I can try running them on a few OSes locally here though.

@thegreystone : I believe the previous review should be addressed. You can have a new look when you have time, and any assistance on running the test would be appreciated.

-------------

PR: https://git.openjdk.org/jmc/pull/332

From erik.helin at oracle.com  Mon Jan 16 11:09:13 2023
From: erik.helin at oracle.com (Erik Duveblad)
Date: Mon, 16 Jan 2023 11:09:13 +0000
Subject: Can JMC handle multiple YoungGarbageCollectionEvents with the
 same value for the gcId field?
In-Reply-To: <163463CB-2D49-4DD1-8773-EF4494568BF5@me.com>
References: <65AFF026-29C6-4931-BAB0-D5379021DC37@oracle.com>
 <163463CB-2D49-4DD1-8773-EF4494568BF5@me.com>
Message-ID: <B8FA0228-2F55-4169-87AF-2E5A332C09F7@oracle.com>

> On 15 Jan 2023, at 13:09, Peter Booth <peter_booth at me.com> wrote:
> 
> How does this compare to the existing behavior of pre-existing collectors? 

Not at all actually, any collector in HotSpot is free to implement a garbage collection as one or more attempts to collect one or more generations. There are concepts such as ?last ditch collections? and has been concepts such as ?scavenge before remark?, this is nothing an application observes.

> Does it mean that IDEs, debuggers, profilers, monitoring tools might break when used with ZGC?

No, they will continue to work just fine, what I?m discussing does not affect them.

> For the scenario where there two minor GCs does this we have two events that aren?t equal yet can?t be distinguished or ?looked up?? Are these event objects conceptually immutable value objects or are they owned by the first GC event object?

The JFR event system doesn?t really work like that. Each event is just data and has a unique id per event. We use the field ?gcId? in a number of events to logically group multiple events as part of one logical garbage collection (this is a human interpretation of the field ?gcId?, to JFR it is (almost) just a field).

> I guess I?m trying to diplomatically ask ?is this a bad smell??

Nope, but there might be ?a bad smell? in JMC :)

I don?t know the JMC source code, but if there is code that for example has a `HashMap<Integer, Event> youngCollectionEventPerGC` where the code (conceptually) does `youngCollectionEventPerGC.put(event.gcId(), event)`, then such code will now be buggy (since generational ZGC might send *two* YoungGarbageCollection events with the same value for the ?gcId? field). The property that there is only one YoungGarbageCollection JFR event per GC isn?t something that HotSpot has ever guaranteed, but it is also the way things have worked until now, so I can see why code like the one I just showed could have found its way into JMC.

Which is the exact reason I?m asking here if anyone is aware if such an assumption have found their way into the JMC source code? I don?t expect anyone to go through JMC?s entire source code, I was more on the lookout for anyone potentially recalling ?oh, yes, we actually made this exact assumption for view X, Y and Z?.

Thanks,
Erik

> Peter
> 
> Sent from my iPhone
> 
>> On Jan 13, 2023, at 5:43 PM, Erik Duveblad <erik.helin at oracle.com> wrote:
>> 
>> ?Hey all,
>> 
>> I?m looking at the JFR events that will be sent for generational ZGC [0].
>> 
>> With generational ZGC there are broadly speaking two kinds of garbage collections (?minor? and ?major?) and each garbage collection can collect one or more generations, zero or more times. More concretely, a minor garbage collection will collect the young generation once and a major garbage collection will collect the young generation _one or two times_ and the old generation once.
>> 
>> The JFR events I plan for generational ZGC to send are:
>> 
>> - a ?jdk.GarbageCollection? event when a ?minor? or ?major? garbage collection occurs
>> - a ?jdk.YoungGarbageCollection? event when the young generation is collected
>> - a ?jdk.OldGarbageCollection? event when the old generation is collected
>> 
>> Combining the above means that there is a new situation: when a major garbage collection occurs that collects the young generation *two* times and the old generation once, then the following events will be sent:
>> 
>> - one ?jdk.GarbageCollection? event with a given gcId ?n"
>> - two ?jdk.YoungGarbageCollection? events with the gcId field set to ?n?
>> - one ?jdk.OldGarbageCollection? event with the gcId field to to ?n?
>> 
>> This would be the first time a HotSpot garbage collector sends multiple (two in this case) ?jdk.YoungGarbageCollection? events with the same value for the gcId field. So I wanted to check with you all if JMC makes any assumptions or relies upon the fact that up until now all ?jdk.YoungGarbageCollection? events have a unique value for the ?gcId? field?
>> 
>> Thanks,
>> Erik
>> 
>> 
>> [0]: https://openjdk.org/jeps/8272979


From marcus.hirt at datadoghq.com  Mon Jan 16 17:40:11 2023
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 16 Jan 2023 18:40:11 +0100
Subject: Result: New jmc Committer: Virag Purnam
Message-ID: <CAOpWGx1Tq9pnuoPMbjh3XAzb+4OG0JRPOjJdavB1QaJZVC9GvQ@mail.gmail.com>

Voting for Virag Purnam [1] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Kind regards,
Marcus

[1] https://mail.openjdk.org/pipermail/jmc-dev/2022-December/005092.html

From duke at openjdk.org  Mon Jan 16 18:28:58 2023
From: duke at openjdk.org (Pierre-Yves Bigourdan)
Date: Mon, 16 Jan 2023 18:28:58 GMT
Subject: RFR: 8006: GcFreedRatio rule doesn't have all preferences in
 preferences list
Message-ID: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>

The shared preference `RulePreferences.SHORT_RECORDING_LIMIT` was not included in the GcFreedRatio rule where it is used. This was causing `Could not find typed preference in rule` warnings.

-------------

Commit messages:
 - Fix formatting
 - 8006: GcFreedRatio rule doesn't have all preferences in preferences list

Changes: https://git.openjdk.org/jmc/pull/462/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=462&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-8006
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jmc/pull/462.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/462/head:pull/462

PR: https://git.openjdk.org/jmc/pull/462

From hirt at openjdk.org  Mon Jan 16 18:28:58 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 16 Jan 2023 18:28:58 GMT
Subject: RFR: 8006: GcFreedRatio rule doesn't have all preferences in
 preferences list
In-Reply-To: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>
References: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>
Message-ID: <CFRtds3y3IHAf0Fia8URYwM9z6J2TLxNYF738ojwl_Q=.be954028-f639-4b9f-af3d-bc3e794dedfc@github.com>

On Mon, 16 Jan 2023 10:03:03 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

> The shared preference `RulePreferences.SHORT_RECORDING_LIMIT` was not included in the GcFreedRatio rule where it is used. This was causing `Could not find typed preference in rule` warnings.

Marked as reviewed by hirt (Lead).

-------------

PR: https://git.openjdk.org/jmc/pull/462

From duke at openjdk.org  Mon Jan 16 18:30:56 2023
From: duke at openjdk.org (Pierre-Yves Bigourdan)
Date: Mon, 16 Jan 2023 18:30:56 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
Message-ID: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>

A new `jdk.FinalizerStatistics` JFR event was introduced in JDK 18. This pull requests adds a simple rule that makes use of it:
![Screenshot 2022-11-30 at 14 19 49](https://user-images.githubusercontent.com/10694593/204806915-0da90fe3-ccc0-430e-96f8-ebc529f8e7a1.png)

-------------

Commit messages:
 - Remove Datadog from copyright header of files that were simply modified
 - Add Datadog to copyright header in modified files
 - Add proper unit test for new rule
 - Fix JFR rule tests
 - 7514: Add rule for finalizers run

Changes: https://git.openjdk.org/jmc/pull/456/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=456&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-7514
  Stats: 543 lines in 11 files changed: 538 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jmc/pull/456.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/456/head:pull/456

PR: https://git.openjdk.org/jmc/pull/456

From hirt at openjdk.org  Mon Jan 16 18:30:58 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 16 Jan 2023 18:30:58 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
In-Reply-To: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
Message-ID: <nreYIFG1FP9mUn4BAF-Z9L0vYR4_kE32UNRbxpAWC6E=.de9863db-7246-40c9-99a9-f6f9519a57b0@github.com>

On Wed, 30 Nov 2022 13:24:50 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

> A new `jdk.FinalizerStatistics` JFR event was introduced in JDK 18. This pull requests adds a simple rule that makes use of it:
> ![Screenshot 2022-11-30 at 14 19 49](https://user-images.githubusercontent.com/10694593/204806915-0da90fe3-ccc0-430e-96f8-ebc529f8e7a1.png)

Changes requested by hirt (Lead).

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/FinalizersRunRule.java line 3:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 3:  *

Should add Datadog to the license header. See other headers where Datadog is included.

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/messages/internal/Messages.java line 3:

> 1: /*
> 2:  * Copyright (c) 2018, 2022, Oracle and/or its affiliates. All rights reserved.
> 3:  *

Here as well.

-------------

PR: https://git.openjdk.org/jmc/pull/456

From duke at openjdk.org  Mon Jan 16 18:30:59 2023
From: duke at openjdk.org (Pierre-Yves Bigourdan)
Date: Mon, 16 Jan 2023 18:30:59 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
In-Reply-To: <nreYIFG1FP9mUn4BAF-Z9L0vYR4_kE32UNRbxpAWC6E=.de9863db-7246-40c9-99a9-f6f9519a57b0@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
 <nreYIFG1FP9mUn4BAF-Z9L0vYR4_kE32UNRbxpAWC6E=.de9863db-7246-40c9-99a9-f6f9519a57b0@github.com>
Message-ID: <FnqbWfeNARCMg9ksZqhnIZmWLD_FNsDr_JhEneThvdk=.880248ab-8476-478c-b7e4-274b2e9806f2@github.com>

On Wed, 30 Nov 2022 17:06:24 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> A new `jdk.FinalizerStatistics` JFR event was introduced in JDK 18. This pull requests adds a simple rule that makes use of it:
>> ![Screenshot 2022-11-30 at 14 19 49](https://user-images.githubusercontent.com/10694593/204806915-0da90fe3-ccc0-430e-96f8-ebc529f8e7a1.png)
>
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/FinalizersRunRule.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
>> 3:  *
> 
> Should add Datadog to the license header. See other headers where Datadog is included.

Added Datadog to all modified files.

-------------

PR: https://git.openjdk.org/jmc/pull/456

From hirt at openjdk.org  Mon Jan 16 18:30:59 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 16 Jan 2023 18:30:59 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
In-Reply-To: <FnqbWfeNARCMg9ksZqhnIZmWLD_FNsDr_JhEneThvdk=.880248ab-8476-478c-b7e4-274b2e9806f2@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
 <nreYIFG1FP9mUn4BAF-Z9L0vYR4_kE32UNRbxpAWC6E=.de9863db-7246-40c9-99a9-f6f9519a57b0@github.com>
 <FnqbWfeNARCMg9ksZqhnIZmWLD_FNsDr_JhEneThvdk=.880248ab-8476-478c-b7e4-274b2e9806f2@github.com>
Message-ID: <vFpA4kKCvt91te6e7ZU8I8wfZvYJTABbPlEoGoleTOs=.87a0201c-2312-416d-86dc-f04f83d70efc@github.com>

On Thu, 1 Dec 2022 18:52:19 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

>> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/general/FinalizersRunRule.java line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
>>> 3:  *
>> 
>> Should add Datadog to the license header. See other headers where Datadog is included.
>
> Added Datadog to all modified files.

Not to all modified. The ones that were originally contributed by Oracle will keep having only the Oracle copyright, even if we modify them. Only do this for newly added files created by you (Datadog).

-------------

PR: https://git.openjdk.org/jmc/pull/456

From duke at openjdk.org  Mon Jan 16 18:31:00 2023
From: duke at openjdk.org (Pierre-Yves Bigourdan)
Date: Mon, 16 Jan 2023 18:31:00 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
In-Reply-To: <vFpA4kKCvt91te6e7ZU8I8wfZvYJTABbPlEoGoleTOs=.87a0201c-2312-416d-86dc-f04f83d70efc@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
 <nreYIFG1FP9mUn4BAF-Z9L0vYR4_kE32UNRbxpAWC6E=.de9863db-7246-40c9-99a9-f6f9519a57b0@github.com>
 <FnqbWfeNARCMg9ksZqhnIZmWLD_FNsDr_JhEneThvdk=.880248ab-8476-478c-b7e4-274b2e9806f2@github.com>
 <vFpA4kKCvt91te6e7ZU8I8wfZvYJTABbPlEoGoleTOs=.87a0201c-2312-416d-86dc-f04f83d70efc@github.com>
Message-ID: <2U9B9cAgemGctfLbwGP_1-p3eRnSV-mTjoaaHbHFOe4=.142ce6e8-fde0-4d06-a96b-b3d4964e7622@github.com>

On Thu, 1 Dec 2022 19:50:13 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

>> Added Datadog to all modified files.
>
> Not to all modified. The ones that were originally contributed by Oracle will keep having only the Oracle copyright, even if we modify them. Only do this for newly added files created by you (Datadog).

Okay, this should hopefully be good now.

We seem to be quite inconsistent with regards to copyright headers, we often add Datadog for files that were just modified for example in 303031fa3d0238574e2f30a0d28b1c76b065f609. Maybe this could benefit from some clarification in the docs?

-------------

PR: https://git.openjdk.org/jmc/pull/456

From hirt at openjdk.org  Mon Jan 16 18:31:01 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 16 Jan 2023 18:31:01 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
In-Reply-To: <2U9B9cAgemGctfLbwGP_1-p3eRnSV-mTjoaaHbHFOe4=.142ce6e8-fde0-4d06-a96b-b3d4964e7622@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
 <nreYIFG1FP9mUn4BAF-Z9L0vYR4_kE32UNRbxpAWC6E=.de9863db-7246-40c9-99a9-f6f9519a57b0@github.com>
 <FnqbWfeNARCMg9ksZqhnIZmWLD_FNsDr_JhEneThvdk=.880248ab-8476-478c-b7e4-274b2e9806f2@github.com>
 <vFpA4kKCvt91te6e7ZU8I8wfZvYJTABbPlEoGoleTOs=.87a0201c-2312-416d-86dc-f04f83d70efc@github.com>
 <2U9B9cAgemGctfLbwGP_1-p3eRnSV-mTjoaaHbHFOe4=.142ce6e8-fde0-4d06-a96b-b3d4964e7622@github.com>
Message-ID: <5TtOptzYZqInSbxo59OHMtUjtb-CXX8sIMEOMtPvvb0=.5153ca42-aeef-422a-9c56-162112ddf2ba@github.com>

On Fri, 2 Dec 2022 09:20:17 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

>> Not to all modified. The ones that were originally contributed by Oracle will keep having only the Oracle copyright, even if we modify them. Only do this for newly added files created by you (Datadog).
>
> Okay, this should hopefully be good now.
> 
> We seem to be quite inconsistent with regards to copyright headers, we often add Datadog for files that were just modified for example in 303031fa3d0238574e2f30a0d28b1c76b065f609. Maybe this could benefit from some clarification in the docs?

Yup. This is clearly not known well enough amongst the committers. I'll add a section in the developer guide.

-------------

PR: https://git.openjdk.org/jmc/pull/456

From hirt at openjdk.org  Mon Jan 16 19:41:15 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Mon, 16 Jan 2023 19:41:15 GMT
Subject: RFR: 8006: GcFreedRatio rule doesn't have all preferences in
 preferences list
In-Reply-To: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>
References: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>
Message-ID: <cYvn72pma9zKoYkUPXRIoe1lpe51-8M4WCB4gZDTZ6E=.966facb5-b42d-4924-9973-898c2dbe6213@github.com>

On Mon, 16 Jan 2023 10:03:03 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

> The shared preference `RulePreferences.SHORT_RECORDING_LIMIT` was not included in the GcFreedRatio rule where it is used. This was causing `Could not find typed preference in rule` warnings.

Hi PY! Thanks for the contribution! You're good to go. Simply write /integrate in a comment. There is no need for manual rebasing or squashing. The tooling will handle it automatically.

-------------

PR: https://git.openjdk.org/jmc/pull/462

From duke at openjdk.org  Tue Jan 17 12:20:24 2023
From: duke at openjdk.org (Pierre-Yves Bigourdan)
Date: Tue, 17 Jan 2023 12:20:24 GMT
Subject: Integrated: 8006: GcFreedRatio rule doesn't have all preferences in
 preferences list
In-Reply-To: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>
References: <wHPQonc2H5eHXvaYlmMeu2c5JDTLp2B4-UA3JKH3XW0=.00fbd98a-0636-4cf4-b756-6113acdb5731@github.com>
Message-ID: <muUYu_yincxkdFtjk1UzMFX6VOBBgA9QGzIdXu2olIQ=.d06eace3-29af-4fd2-8fc9-15b34ceaed39@github.com>

On Mon, 16 Jan 2023 10:03:03 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

> The shared preference `RulePreferences.SHORT_RECORDING_LIMIT` was not included in the GcFreedRatio rule where it is used. This was causing `Could not find typed preference in rule` warnings.

This pull request has now been integrated.

Changeset: e90f2582
Author:    Pierre-Yves Bigourdan <pierreyves.bigourdan at datadoghq.com>
Committer: Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/e90f2582eb36b1563ce478322508d588fda883de
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8006: GcFreedRatio rule doesn't have all preferences in preferences list

Reviewed-by: hirt

-------------

PR: https://git.openjdk.org/jmc/pull/462

From hirt at openjdk.org  Tue Jan 17 12:26:27 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Tue, 17 Jan 2023 12:26:27 GMT
Subject: RFR: 7514: Rule for FinalizationStatistics
In-Reply-To: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
Message-ID: <sxS7lN4v_fGvQUYIRziolXYs4jZKBL4JPM9hFEch3Gc=.375f2376-78cf-43c4-9989-21cf26ad71cf@github.com>

On Wed, 30 Nov 2022 13:24:50 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

> A new `jdk.FinalizerStatistics` JFR event was introduced in JDK 18. This pull requests adds a simple rule that makes use of it:
> ![Screenshot 2022-11-30 at 14 19 49](https://user-images.githubusercontent.com/10694593/204806915-0da90fe3-ccc0-430e-96f8-ebc529f8e7a1.png)

Marked as reviewed by hirt (Lead).

-------------

PR: https://git.openjdk.org/jmc/pull/456

From duke at openjdk.org  Tue Jan 17 12:43:24 2023
From: duke at openjdk.org (Pierre-Yves Bigourdan)
Date: Tue, 17 Jan 2023 12:43:24 GMT
Subject: Integrated: 7514: Rule for FinalizationStatistics
In-Reply-To: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
References: <9yup0UM3WMM2gnEuhKFH9vopMrKs4wrKDNtCPwGVN4Y=.263a8177-754e-4253-8ec6-0a860fae75f3@github.com>
Message-ID: <-DEpBmDkb0PSEgqP_uc3lrp8eIdrsJ41_QLttYLRw9g=.7abe09f1-d088-42e9-a395-2da9ca3eb001@github.com>

On Wed, 30 Nov 2022 13:24:50 GMT, Pierre-Yves Bigourdan <duke at openjdk.org> wrote:

> A new `jdk.FinalizerStatistics` JFR event was introduced in JDK 18. This pull requests adds a simple rule that makes use of it:
> ![Screenshot 2022-11-30 at 14 19 49](https://user-images.githubusercontent.com/10694593/204806915-0da90fe3-ccc0-430e-96f8-ebc529f8e7a1.png)

This pull request has now been integrated.

Changeset: b3b42593
Author:    Pierre-Yves Bigourdan <pierreyves.bigourdan at datadoghq.com>
Committer: Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/b3b42593e8213cc2e989310db18876daef139515
Stats:     543 lines in 11 files changed: 538 ins; 0 del; 5 mod

7514: Rule for FinalizationStatistics

Reviewed-by: hirt

-------------

PR: https://git.openjdk.org/jmc/pull/456

From peter_booth at me.com  Sun Jan 15 12:09:53 2023
From: peter_booth at me.com (Peter Booth)
Date: Sun, 15 Jan 2023 15:09:53 +0300
Subject: Can JMC handle multiple YoungGarbageCollectionEvents with the
 same value for the gcId field?
In-Reply-To: <65AFF026-29C6-4931-BAB0-D5379021DC37@oracle.com>
References: <65AFF026-29C6-4931-BAB0-D5379021DC37@oracle.com>
Message-ID: <163463CB-2D49-4DD1-8773-EF4494568BF5@me.com>

How does this compare to the existing behavior of pre-existing collectors? 

Does it mean that IDEs, debuggers, profilers, monitoring tools might break when used with ZGC?

For the scenario where there two minor GCs does this we have two events that aren?t equal yet can?t be distinguished or ?looked up?? Are these event objects conceptually immutable value objects or are they owned by the first GC event object?

I guess I?m trying to diplomatically ask ?is this a bad smell??

Peter

Sent from my iPhone

> On Jan 13, 2023, at 5:43 PM, Erik Duveblad <erik.helin at oracle.com> wrote:
> 
> ?Hey all,
> 
> I?m looking at the JFR events that will be sent for generational ZGC [0].
> 
> With generational ZGC there are broadly speaking two kinds of garbage collections (?minor? and ?major?) and each garbage collection can collect one or more generations, zero or more times. More concretely, a minor garbage collection will collect the young generation once and a major garbage collection will collect the young generation _one or two times_ and the old generation once.
> 
> The JFR events I plan for generational ZGC to send are:
> 
> - a ?jdk.GarbageCollection? event when a ?minor? or ?major? garbage collection occurs
> - a ?jdk.YoungGarbageCollection? event when the young generation is collected
> - a ?jdk.OldGarbageCollection? event when the old generation is collected
> 
> Combining the above means that there is a new situation: when a major garbage collection occurs that collects the young generation *two* times and the old generation once, then the following events will be sent:
> 
> - one ?jdk.GarbageCollection? event with a given gcId ?n"
> - two ?jdk.YoungGarbageCollection? events with the gcId field set to ?n?
> - one ?jdk.OldGarbageCollection? event with the gcId field to to ?n?
> 
> This would be the first time a HotSpot garbage collector sends multiple (two in this case) ?jdk.YoungGarbageCollection? events with the same value for the gcId field. So I wanted to check with you all if JMC makes any assumptions or relies upon the fact that up until now all ?jdk.YoungGarbageCollection? events have a unique value for the ?gcId? field?
> 
> Thanks,
> Erik
> 
> 
> [0]: https://openjdk.org/jeps/8272979

From marcus at hirt.se  Mon Jan 16 15:17:03 2023
From: marcus at hirt.se (Marcus Hirt)
Date: Mon, 16 Jan 2023 16:17:03 +0100
Subject: Can JMC handle multiple YoungGarbageCollectionEvents with the
 same value for the gcId field?
In-Reply-To: <B8FA0228-2F55-4169-87AF-2E5A332C09F7@oracle.com>
References: <65AFF026-29C6-4931-BAB0-D5379021DC37@oracle.com>
 <163463CB-2D49-4DD1-8773-EF4494568BF5@me.com>
 <B8FA0228-2F55-4169-87AF-2E5A332C09F7@oracle.com>
Message-ID: <027601d929bd$96d15800$c4740800$@hirt.se>

Hi all,

Sorry for the HTML-email; I?ll be sprinkling with screenshots. 

As far as I can remember, JMC does not make any such assumptions. We usually try to pick all events related to a @relational attribute when we visualize them. 

For example, in the GC page, any and all phases with a matching gcId to the selected GC will be showed in the phases table. 


That said, more generally JMC does not specifically constrain associations to be made only for @relational fields/attributes. It is enough for the id and type to be the same to be considered a match.




?though using the feature will, of course, be even more useful for fields that are @relational (since the annotation suggest that there is a relation across event types, and it is therefore likely that a match can be found across multiple types). Here is an example of matching on gcId being 11, and showing the matching entries in the event browser. 



If you find an actual problem in a specific visualization, just file it as a bug.

Kind regards,

Marcus



-----Original Message-----
From: jmc-dev <jmc-dev-retn at openjdk.org> On Behalf Of Erik Duveblad
Sent: Monday, 16 January 2023 12:09
To: Peter Booth <peter_booth at me.com>
Cc: jmc-dev at openjdk.org; zgc-dev at openjdk.org
Subject: Re: Can JMC handle multiple YoungGarbageCollectionEvents with the same value for the gcId field?

 

> On 15 Jan 2023, at 13:09, Peter Booth < <mailto:peter_booth at me.com> peter_booth at me.com> wrote:

> 

> How does this compare to the existing behavior of pre-existing collectors? 

 

Not at all actually, any collector in HotSpot is free to implement a garbage collection as one or more attempts to collect one or more generations. There are concepts such as ?last ditch collections? and has been concepts such as ?scavenge before remark?, this is nothing an application observes.

 

> Does it mean that IDEs, debuggers, profilers, monitoring tools might break when used with ZGC?

 

No, they will continue to work just fine, what I?m discussing does not affect them.

 

> For the scenario where there two minor GCs does this we have two events that aren?t equal yet can?t be distinguished or ?looked up?? Are these event objects conceptually immutable value objects or are they owned by the first GC event object?

 

The JFR event system doesn?t really work like that. Each event is just data and has a unique id per event. We use the field ?gcId? in a number of events to logically group multiple events as part of one logical garbage collection (this is a human interpretation of the field ?gcId?, to JFR it is (almost) just a field).

 

> I guess I?m trying to diplomatically ask ?is this a bad smell??

 

Nope, but there might be ?a bad smell? in JMC :)

 

I don?t know the JMC source code, but if there is code that for example has a `HashMap<Integer, Event> youngCollectionEventPerGC` where the code (conceptually) does `youngCollectionEventPerGC.put(event.gcId(), event)`, then such code will now be buggy (since generational ZGC might send *two* YoungGarbageCollection events with the same value for the ?gcId? field). The property that there is only one YoungGarbageCollection JFR event per GC isn?t something that HotSpot has ever guaranteed, but it is also the way things have worked until now, so I can see why code like the one I just showed could have found its way into JMC.

 

Which is the exact reason I?m asking here if anyone is aware if such an assumption have found their way into the JMC source code? I don?t expect anyone to go through JMC?s entire source code, I was more on the lookout for anyone potentially recalling ?oh, yes, we actually made this exact assumption for view X, Y and Z?.

 

Thanks,

Erik

 

> Peter

> 

> Sent from my iPhone

> 

>> On Jan 13, 2023, at 5:43 PM, Erik Duveblad < <mailto:erik.helin at oracle.com> erik.helin at oracle.com> wrote:

>> 

>> ?Hey all,

>> 

>> I?m looking at the JFR events that will be sent for generational ZGC [0].

>> 

>> With generational ZGC there are broadly speaking two kinds of garbage collections (?minor? and ?major?) and each garbage collection can collect one or more generations, zero or more times. More concretely, a minor garbage collection will collect the young generation once and a major garbage collection will collect the young generation _one or two times_ and the old generation once.

>> 

>> The JFR events I plan for generational ZGC to send are:

>> 

>> - a ?jdk.GarbageCollection? event when a ?minor? or ?major? garbage collection occurs

>> - a ?jdk.YoungGarbageCollection? event when the young generation is collected

>> - a ?jdk.OldGarbageCollection? event when the old generation is collected

>> 

>> Combining the above means that there is a new situation: when a major garbage collection occurs that collects the young generation *two* times and the old generation once, then the following events will be sent:

>> 

>> - one ?jdk.GarbageCollection? event with a given gcId ?n"

>> - two ?jdk.YoungGarbageCollection? events with the gcId field set to ?n?

>> - one ?jdk.OldGarbageCollection? event with the gcId field to to ?n?

>> 

>> This would be the first time a HotSpot garbage collector sends multiple (two in this case) ?jdk.YoungGarbageCollection? events with the same value for the gcId field. So I wanted to check with you all if JMC makes any assumptions or relies upon the fact that up until now all ?jdk.YoungGarbageCollection? events have a unique value for the ?gcId? field?

>> 

>> Thanks,

>> Erik

>> 

>> 

>> [0]:  <https://openjdk.org/jeps/8272979> https://openjdk.org/jeps/8272979

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 227474 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 41292 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/image002-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 101206 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230116/be392f4f/image003-0001.png>

From marcus at hirt.se  Tue Jan 17 13:01:19 2023
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 17 Jan 2023 14:01:19 +0100
Subject: invitation to slack group
In-Reply-To: <CAE9ARBT4F33+KQsmg6kJB8zTiZ4TQd3MerG3tgaxQB7Dha452w@mail.gmail.com>
References: <CAE9ARBT4F33+KQsmg6kJB8zTiZ4TQd3MerG3tgaxQB7Dha452w@mail.gmail.com>
Message-ID: <040401d92a73$cb002410$61006c30$@hirt.se>

Invitation sent!

 

/M

 

From: jmc-dev <jmc-dev-retn at openjdk.org> On Behalf Of Onder SEZGIN
Sent: Friday, 9 December 2022 15:05
To: jmc-dev at openjdk.java.net
Subject: invitation to slack group

 

hi,

 

may i request an invitation to jmc slack?

 

Thanks

Onder

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jmc-dev/attachments/20230117/8fa2e672/attachment.htm>

From bdutheil at openjdk.org  Tue Jan 17 15:15:41 2023
From: bdutheil at openjdk.org (Brice Dutheil)
Date: Tue, 17 Jan 2023 15:15:41 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v6]
In-Reply-To: <f0SZ7ltwqnYNBDKhJLwWwUig8rdJW2pGIEcDw1kcFFg=.566be353-0ef2-4cda-859e-f365e076baeb@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
 <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>
 <f0SZ7ltwqnYNBDKhJLwWwUig8rdJW2pGIEcDw1kcFFg=.566be353-0ef2-4cda-859e-f365e076baeb@github.com>
Message-ID: <MgMeF7BSj-hINgD-KAyIpW6VnZ2lqywu19b7ZWnQ5Es=.b09226ea-25f0-4ea4-8e2f-17fc33b2922b@github.com>

On Sun, 8 Jan 2023 19:49:01 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed the synchronized block and used ConcurrentLinkedQueue instead
>
> In the latest patch, I have removed the synchronized block which was the main bottle neck for the approval of this PR. Also, used the suggested data structure i.e. ConcurrentLinkedQueue for the processing of records. 
> 
> I have debugged in detail and figured out that the reason for inconsistent results for the customer JFR which has around 65000 class entries to process was the time multithreaded tasks were taking to complete which was dependent on many factors like how many cores our CPU has OR how busy our CPU is when its performing those tasks. Hence, for safer side I have added a check to see whether all tasks are performed or not. If not, I have added a console message to alert the user for increasing the configured timeout. The default timeout is 5 min which is quite sufficient to complete all the tasks still if the count of entries are too much and there are some pending tasks, user will be alerted for the same.
> 
> @bric3 Please let me know when can we have a zoom (if required).

Hi @Suchitainf I'll have a look tommorrow.

-------------

PR: https://git.openjdk.org/jmc/pull/419

From bdutheil at openjdk.org  Wed Jan 18 21:08:53 2023
From: bdutheil at openjdk.org (Brice Dutheil)
Date: Wed, 18 Jan 2023 21:08:53 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v6]
In-Reply-To: <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
 <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>
Message-ID: <So45vJNpdlgNnkaZnmXw4ZEOiY_N-5mSRs-A5-zh3TU=.e981f147-6e87-4da8-9cdb-1baeb23f04d2@github.com>

On Sun, 8 Jan 2023 19:44:04 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.
>
> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed the synchronized block and used ConcurrentLinkedQueue instead

OK for me. There's one tidbit I think should be changed is using the jul logger over `System.out`.

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 75:

> 73: 		aggregators.addAll(query.getAggregators());
> 74: 		info = new HashMap<>(attributes.size() + aggregators.size());
> 75: 		exec = Executors.newWorkStealingPool();

Later, I think we may need to find a may to inject thread pools rather than creating them in each result sets (Maybe via `ItemResultSetFactory`. But this is a different task (need to create a jira ticket).

core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 166:

> 164: 			System.out.println(
> 165: 					"The results may be inaccurate as JMC is unable to process all the class entries to determine "
> 166: 							+ "the class leak results. Please increase the configured timeout in preferences to see the accurate results.  ");

I believe this should be changed to use the jul logger. Other flighrecorder component uses that.

E.g.


private final static Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flighrecorder.rules.jdk.util");

-------------

Marked as reviewed by bdutheil (Author).

PR: https://git.openjdk.org/jmc/pull/419

From schaturvedi at openjdk.org  Thu Jan 19 08:03:19 2023
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Thu, 19 Jan 2023 08:03:19 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v7]
In-Reply-To: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
Message-ID: <yhvzL66lKqOqiyfFAFxqwLxVICjl6CKnvNyBwXQwsmc=.6a0846c0-0357-437d-9c3e-df25332499e4@github.com>

> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.

Suchita Chaturvedi has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed spotless error
 - Replaced sysout with Logger

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/419/files
  - new: https://git.openjdk.org/jmc/pull/419/files/292b2251..56a90a79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=06
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=05-06

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jmc/pull/419.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/419/head:pull/419

PR: https://git.openjdk.org/jmc/pull/419

From schaturvedi at openjdk.org  Thu Jan 19 08:06:16 2023
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Thu, 19 Jan 2023 08:06:16 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v6]
In-Reply-To: <So45vJNpdlgNnkaZnmXw4ZEOiY_N-5mSRs-A5-zh3TU=.e981f147-6e87-4da8-9cdb-1baeb23f04d2@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
 <0Rid6hcDukcmJ0Ok0bS78xixjJ7PXSIDk7CEkEkk19A=.9733b6dc-2056-442b-b1cf-9354823af84f@github.com>
 <So45vJNpdlgNnkaZnmXw4ZEOiY_N-5mSRs-A5-zh3TU=.e981f147-6e87-4da8-9cdb-1baeb23f04d2@github.com>
Message-ID: <CX8GRNwg8dlKE4iK72LZdgWuyeSa5oRXtpkQDwmPYxc=.e471c440-ecac-4685-85ad-2a4567b085c3@github.com>

On Wed, 18 Jan 2023 21:03:53 GMT, Brice Dutheil <bdutheil at openjdk.org> wrote:

>> Suchita Chaturvedi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed the synchronized block and used ConcurrentLinkedQueue instead
>
> core/org.openjdk.jmc.flightrecorder.rules.jdk/src/main/java/org/openjdk/jmc/flightrecorder/rules/jdk/util/DefaultIItemResultSet.java line 166:
> 
>> 164: 			System.out.println(
>> 165: 					"The results may be inaccurate as JMC is unable to process all the class entries to determine "
>> 166: 							+ "the class leak results. Please increase the configured timeout in preferences to see the accurate results.  ");
> 
> I believe this should be changed to use the jul logger. Other flighrecorder component uses that.
> 
> E.g.
> 
> 
> private final static Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flighrecorder.rules.jdk.util");

Hi @bric3 Thanks for taking out time and reviewing the PR. I have replaced sysout with Logger now.

-------------

PR: https://git.openjdk.org/jmc/pull/419

From hdafgard at openjdk.org  Thu Jan 19 12:46:06 2023
From: hdafgard at openjdk.org (Henrik =?UTF-8?B?RGFmZ8OlcmQ=?=)
Date: Thu, 19 Jan 2023 12:46:06 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v7]
In-Reply-To: <yhvzL66lKqOqiyfFAFxqwLxVICjl6CKnvNyBwXQwsmc=.6a0846c0-0357-437d-9c3e-df25332499e4@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
 <yhvzL66lKqOqiyfFAFxqwLxVICjl6CKnvNyBwXQwsmc=.6a0846c0-0357-437d-9c3e-df25332499e4@github.com>
Message-ID: <fbhix38A7jTaur_VvwojsPEQPxIAwomKoBD3aYhm6zs=.636a61be-c1bd-4fb7-b47d-3e450bd6cacd@github.com>

On Thu, 19 Jan 2023 08:03:19 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

>> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.
>
> Suchita Chaturvedi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed spotless error
>  - Replaced sysout with Logger

Marked as reviewed by hdafgard (Reviewer).

-------------

PR: https://git.openjdk.org/jmc/pull/419

From schaturvedi at openjdk.org  Thu Jan 19 16:49:49 2023
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Thu, 19 Jan 2023 16:49:49 GMT
Subject: RFR: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results. [v8]
In-Reply-To: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
Message-ID: <wxJBIiVahBRSAfbzFIeyCdtvTL2dTeQW2oZnh_F4XWs=.bd2d05db-000e-4f95-ab46-a9e7603c5d25@github.com>

> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.

Suchita Chaturvedi 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 ten additional commits since the last revision:

 - Merge branch 'master' into 7879
 - Fixed spotless error
 - Replaced sysout with Logger
 - Removed the synchronized block and used ConcurrentLinkedQueue instead
 - Implemented minor review comments
 - Adding higher timeout as default value
 - Added check for default configured timeout
 - Implemented review comments
 - 7879 : Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results.

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/419/files
  - new: https://git.openjdk.org/jmc/pull/419/files/56a90a79..db00e1b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=07
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=419&range=06-07

  Stats: 11656 lines in 416 files changed: 8871 ins; 1586 del; 1199 mod
  Patch: https://git.openjdk.org/jmc/pull/419.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/419/head:pull/419

PR: https://git.openjdk.org/jmc/pull/419

From schaturvedi at openjdk.org  Thu Jan 19 16:49:52 2023
From: schaturvedi at openjdk.org (Suchita Chaturvedi)
Date: Thu, 19 Jan 2023 16:49:52 GMT
Subject: Integrated: 7879: Automated Analysis taking very long time to produce
 results for Class Leak Rule and showing wrong results.
In-Reply-To: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
References: <O1zBHVRTCZY4R-YebBwcj-VuqnoX8gTh52GpFqR9Kww=.03e244f7-c76c-444c-a1aa-58b8fb240381@github.com>
Message-ID: <iGcmwUFL5xBwqZ79OxLzsGE3FETDcoAdxJ37uazwP1g=.00b293dd-4ee9-41d9-bc99-1f2343ee59df@github.com>

On Sat, 20 Aug 2022 18:59:14 GMT, Suchita Chaturvedi <schaturvedi at openjdk.org> wrote:

> This PR takes care of optimizing and correcting the Class leak rule results on Automated Analysis Page.

This pull request has now been integrated.

Changeset: 2b1b5972
Author:    Suchita Chaturvedi <schaturvedi at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/2b1b5972738b97ba60f0b03960fda6d1994ce1dc
Stats:     115 lines in 6 files changed: 81 ins; 1 del; 33 mod

7879: Automated Analysis taking very long time to produce results for Class Leak Rule and showing wrong results.

Reviewed-by: hdafgard, bdutheil

-------------

PR: https://git.openjdk.org/jmc/pull/419

From duke at openjdk.org  Sun Jan 22 19:08:32 2023
From: duke at openjdk.org (Martin Skarsaune)
Date: Sun, 22 Jan 2023 19:08:32 GMT
Subject: RFR: 7455: Add support for jolokia JMX service connection [v34]
In-Reply-To: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
References: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
Message-ID: <OEjN9NW74MH0YbEBHDvQlGqVNvgEL6xlcunM-vQd83U=.f2c976fb-1dae-47ae-8175-ce6a571054f1@github.com>

> Setting back for review. The azure problem requires a fix in Jolokia.
> 
> Make use of support for JMX service connection in jolokia 1.7.0 and later to connect to JVMs over this protocol.

Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision:

  JMC-7455: Correct hamcrest version

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/332/files
  - new: https://git.openjdk.org/jmc/pull/332/files/a8d49090..cfc26886

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=33
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=32-33

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jmc/pull/332.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/332/head:pull/332

PR: https://git.openjdk.org/jmc/pull/332

From duke at openjdk.org  Sun Jan 22 19:32:28 2023
From: duke at openjdk.org (Martin Skarsaune)
Date: Sun, 22 Jan 2023 19:32:28 GMT
Subject: RFR: 7455: Add support for jolokia JMX service connection [v35]
In-Reply-To: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
References: <V5HVftATlhcY-J3P7RedCgruJpd5CISO6C7p06Df348=.a378eb7f-073a-4841-92ed-a8e93be922e5@github.com>
Message-ID: <PfFwj31huv8yuvbHwpFEylRHtYOs2grDR2MQJ1QznUU=.997d9ea9-b84f-4e1d-94d7-1ea9d774e15f@github.com>

> Setting back for review. The azure problem requires a fix in Jolokia.
> 
> Make use of support for JMX service connection in jolokia 1.7.0 and later to connect to JVMs over this protocol.

Martin Skarsaune has updated the pull request incrementally with one additional commit since the last revision:

  JMC-7455: Fixed API warning by using standard Java package

-------------

Changes:
  - all: https://git.openjdk.org/jmc/pull/332/files
  - new: https://git.openjdk.org/jmc/pull/332/files/cfc26886..cbb06d89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=34
 - incr: https://webrevs.openjdk.org/?repo=jmc&pr=332&range=33-34

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jmc/pull/332.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/332/head:pull/332

PR: https://git.openjdk.org/jmc/pull/332

From duke at openjdk.org  Mon Jan 23 17:10:24 2023
From: duke at openjdk.org (Virag Purnam)
Date: Mon, 23 Jan 2023 17:10:24 GMT
Subject: RFR: 7952: JfrRulesReport -format xml produce incorrect results
Message-ID: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>

While generating JFR Rules Report in xml produces incorrect result for Method Profiling, Allocated Classes and Threads Allocating.


For example, for Method Profiling XML shows:

The methods that used the most CPU are:
org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodPro
filingWindowResult at 53fb3dab

when it should be :
org.eclipse.jetty.server.HttpOutput.acquireBuffer() (43.4?% of samples)
10/21/2022, 12:25:52.000 PM ? 12:26:22 PM


After the fix, I have compared the outputs. Now it provides a readable list. Earlier it was dumping the object directly. Please refer the below screen shot. 
<img width="925" alt="7952" src="https://user-images.githubusercontent.com/97600378/214099759-1465ae74-646b-4483-994a-af323986c627.png">

-------------

Commit messages:
 - 7952: JfrRulesReport -format xml produce incorrect results

Changes: https://git.openjdk.org/jmc/pull/463/files
 Webrev: https://webrevs.openjdk.org/?repo=jmc&pr=463&range=00
  Issue: https://bugs.openjdk.org/browse/JMC-7952
  Stats: 30 lines in 1 file changed: 26 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jmc/pull/463.diff
  Fetch: git fetch https://git.openjdk.org/jmc pull/463/head:pull/463

PR: https://git.openjdk.org/jmc/pull/463

From jpbempel at openjdk.org  Wed Jan 25 08:40:17 2023
From: jpbempel at openjdk.org (Jean-Philippe Bempel)
Date: Wed, 25 Jan 2023 08:40:17 GMT
Subject: RFR: 7952: JfrRulesReport -format xml produce incorrect results
In-Reply-To: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
References: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
Message-ID: <ct2J1_yS0W2RT-faLnRp8goij7A285Ft9uYbfK7sAqU=.bfebf6c0-c19f-466b-ae09-f7bffeeab860@github.com>

On Mon, 23 Jan 2023 16:55:26 GMT, Virag Purnam <duke at openjdk.org> wrote:

> While generating JFR Rules Report in xml produces incorrect result for Method Profiling, Allocated Classes and Threads Allocating.
> 
> 
> For example, for Method Profiling XML shows:
> 
> The methods that used the most CPU are:
> org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodPro
> filingWindowResult at 53fb3dab
> 
> when it should be :
> org.eclipse.jetty.server.HttpOutput.acquireBuffer() (43.4?% of samples)
> 10/21/2022, 12:25:52.000 PM ? 12:26:22 PM
> 
> 
> After the fix, I have compared the outputs. Now it provides a readable list. Earlier it was dumping the object directly. Please refer the below screen shot. 
> <img width="925" alt="7952" src="https://user-images.githubusercontent.com/97600378/214099759-1465ae74-646b-4483-994a-af323986c627.png">

Marked as reviewed by jpbempel (Committer).

-------------

PR: https://git.openjdk.org/jmc/pull/463

From hirt at openjdk.org  Wed Jan 25 21:31:32 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Wed, 25 Jan 2023 21:31:32 GMT
Subject: RFR: 7952: JfrRulesReport -format xml produce incorrect results
In-Reply-To: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
References: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
Message-ID: <Oq6U8YxlDYCgiCh6fpkkFUBaLPPOPNXyhBaKK1Vy0L0=.9a13412e-42ad-4efa-b861-75b17c9cf9aa@github.com>

On Mon, 23 Jan 2023 16:55:26 GMT, Virag Purnam <duke at openjdk.org> wrote:

> While generating JFR Rules Report in xml produces incorrect result for Method Profiling, Allocated Classes and Threads Allocating.
> 
> 
> For example, for Method Profiling XML shows:
> 
> The methods that used the most CPU are:
> org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodPro
> filingWindowResult at 53fb3dab
> 
> when it should be :
> org.eclipse.jetty.server.HttpOutput.acquireBuffer() (43.4?% of samples)
> 10/21/2022, 12:25:52.000 PM ? 12:26:22 PM
> 
> 
> After the fix, I have compared the outputs. Now it provides a readable list. Earlier it was dumping the object directly. Please refer the below screen shot. 
> <img width="925" alt="7952" src="https://user-images.githubusercontent.com/97600378/214099759-1465ae74-646b-4483-994a-af323986c627.png">

Marked as reviewed by hirt (Lead).

-------------

PR: https://git.openjdk.org/jmc/pull/463

From hirt at openjdk.org  Thu Jan 26 21:09:30 2023
From: hirt at openjdk.org (Marcus Hirt)
Date: Thu, 26 Jan 2023 21:09:30 GMT
Subject: RFR: 7952: JfrRulesReport -format xml produce incorrect results
In-Reply-To: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
References: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
Message-ID: <rnMits__NKk_PS12AAb0I2xq9k4yco5v5D77_Bk4Iac=.046f5b6e-4cd6-494d-817d-2e442f42b0e8@github.com>

On Mon, 23 Jan 2023 16:55:26 GMT, Virag Purnam <duke at openjdk.org> wrote:

> While generating JFR Rules Report in xml produces incorrect result for Method Profiling, Allocated Classes and Threads Allocating.
> 
> 
> For example, for Method Profiling XML shows:
> 
> The methods that used the most CPU are:
> org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodPro
> filingWindowResult at 53fb3dab
> 
> when it should be :
> org.eclipse.jetty.server.HttpOutput.acquireBuffer() (43.4?% of samples)
> 10/21/2022, 12:25:52.000 PM ? 12:26:22 PM
> 
> 
> After the fix, I have compared the outputs. Now it provides a readable list. Earlier it was dumping the object directly. Please refer the below screen shot. 
> <img width="925" alt="7952" src="https://user-images.githubusercontent.com/97600378/214099759-1465ae74-646b-4483-994a-af323986c627.png">

Weird that I need to sponsor. Looks like you should now be registered as a committer in the census. Perhaps this PR was opened just before you were officially registered. Anyways, will sponsor.

-------------

PR: https://git.openjdk.org/jmc/pull/463

From duke at openjdk.org  Thu Jan 26 21:09:30 2023
From: duke at openjdk.org (Virag Purnam)
Date: Thu, 26 Jan 2023 21:09:30 GMT
Subject: Integrated: 7952: JfrRulesReport -format xml produce incorrect results
In-Reply-To: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
References: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
Message-ID: <ZgcROyuSU4mXOdD9gSmCRO1Rfz7MCba1BCvwlipCCtM=.35da4305-a13d-4536-bcb2-4d5b9e79e5ac@github.com>

On Mon, 23 Jan 2023 16:55:26 GMT, Virag Purnam <duke at openjdk.org> wrote:

> While generating JFR Rules Report in xml produces incorrect result for Method Profiling, Allocated Classes and Threads Allocating.
> 
> 
> For example, for Method Profiling XML shows:
> 
> The methods that used the most CPU are:
> org.openjdk.jmc.flightrecorder.rules.jdk.latency.MethodProfilingRule$MethodPro
> filingWindowResult at 53fb3dab
> 
> when it should be :
> org.eclipse.jetty.server.HttpOutput.acquireBuffer() (43.4?% of samples)
> 10/21/2022, 12:25:52.000 PM ? 12:26:22 PM
> 
> 
> After the fix, I have compared the outputs. Now it provides a readable list. Earlier it was dumping the object directly. Please refer the below screen shot. 
> <img width="925" alt="7952" src="https://user-images.githubusercontent.com/97600378/214099759-1465ae74-646b-4483-994a-af323986c627.png">

This pull request has now been integrated.

Changeset: b57bb6ed
Author:    vpurnam <vpurnam at VPURNAM-7420.in.oracle.com>
Committer: Marcus Hirt <hirt at openjdk.org>
URL:       https://git.openjdk.org/jmc/commit/b57bb6ed659dd5e012f48c38fb9efea1cb35e5f4
Stats:     30 lines in 1 file changed: 26 ins; 1 del; 3 mod

7952: JfrRulesReport -format xml produce incorrect results

Reviewed-by: jpbempel, hirt

-------------

PR: https://git.openjdk.org/jmc/pull/463

From duke at openjdk.org  Fri Jan 27 04:23:27 2023
From: duke at openjdk.org (Virag Purnam)
Date: Fri, 27 Jan 2023 04:23:27 GMT
Subject: RFR: 7952: JfrRulesReport -format xml produce incorrect results
In-Reply-To: <rnMits__NKk_PS12AAb0I2xq9k4yco5v5D77_Bk4Iac=.046f5b6e-4cd6-494d-817d-2e442f42b0e8@github.com>
References: <Fghbt3Oy_k4A4eVVnc50GkL9I1jnsSaLTgUlsZdd9i4=.16429a37-e169-4bad-8e5a-d9ea4630f7f6@github.com>
 <rnMits__NKk_PS12AAb0I2xq9k4yco5v5D77_Bk4Iac=.046f5b6e-4cd6-494d-817d-2e442f42b0e8@github.com>
Message-ID: <-9svnv4GzAIUKN5BSS9GrjN5wVhKNTiwJ8YSlxCo9Fw=.a5e7e4dd-ba10-4ee0-86e2-9cf16bed9fe2@github.com>

On Thu, 26 Jan 2023 21:05:12 GMT, Marcus Hirt <hirt at openjdk.org> wrote:

> Weird that I need to sponsor. Looks like you should now be registered as a committer in the census. Perhaps this PR was opened just before you were officially registered. Anyways, will sponsor.

@thegreystone: Yes.. Even I was thinking what is wrong. Thanks Marcus for sponsor.

-------------

PR: https://git.openjdk.org/jmc/pull/463