> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Wed, 19 May 2021 17:21:26 GMT, Erik Gahlin wrote:
> I think you need to add the hook, for the event metadata to be correct.
> Otherwise, the "period" setting will not show up.
Yes. The failed test log would indicate also the rest of the metadata not being
in a good shape. But with the hook
On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik 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.
>
> I wonder if something similar to
On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik 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.
>
> I wonder if something similar to
On Wed, 19 May 2021 15:23:55 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Wed, 19 May 2021 14:11:40 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Wed, 19 May 2021 10:00:04 GMT, Severin Gehwolf wrote:
>> Jaroslav Bachorik has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 10 commits:
>>
>> - Small fixes
>> - Remove trailing spaces
>> - Doh
>> - Report container type and
On Mon, 3 May 2021 13:16:06 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Mon, 3 May 2021 13:16:06 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Tue, 27 Apr 2021 09:40:01 GMT, Severin Gehwolf wrote:
>> 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 13 additional
>>
On Mon, 26 Apr 2021 21:20:57 GMT, Erik Gahlin wrote:
>> 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 13 additional
>>
On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik
wrote:
>> I wonder if something similar to below could be added to
>> jdk.jfr.internal.Utils:
>>
>> private static Metrics[] metrics;
>> public static Metrics getMetrics() {
>> if (metrics == null) {
>> metrics =
On Thu, 22 Apr 2021 16:00:32 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Thu, 22 Apr 2021 15:08:59 GMT, Jaroslav Bachorik
wrote:
>> I wonder if something similar to below could be added to
>> jdk.jfr.internal.Utils:
>>
>> private static Metrics[] metrics;
>> public static Metrics getMetrics() {
>> if (metrics == null) {
>> metrics =
On Thu, 22 Apr 2021 16:00:32 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Wed, 21 Apr 2021 22:38:32 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix event metadata
>
> I wonder if something similar to below could be added to
> jdk.jfr.internal.Utils:
>
>
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Wed, 21 Apr 2021 13:34:28 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Wed, 21 Apr 2021 11:49:10 GMT, Erik Gahlin wrote:
>> Ok. So what would be a good rule-of-thumb for when one should introduce a
>> flag?
>
> I think we want to limit the number flags/options There are already too many,
> preferably we would have none, but some of the ones we have today, like
On Wed, 21 Apr 2021 13:21:32 GMT, Jaroslav Bachorik
wrote:
>> How does it look in proc?
>
> This was based on
> https://github.com/openjdk/jdk/blob/da860290c2657c0fb1de8c77c8dffdb35f1cf938/src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java#L149
>
> However, that metric is
On Wed, 21 Apr 2021 11:50:25 GMT, Erik Gahlin wrote:
>> I guess we could fit those events under `Operating System/Memory` and
>> `Operating System/Processor` categories.
>> What about I/O? Currently, there is only `Operating System/Network`
>> category. The options are:
>> * Add `Operating
On Wed, 14 Apr 2021 10:26:44 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 11 commits:
>>
>> - Roll back conditional registration of container events
>> - Remove container events
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Wed, 21 Apr 2021 11:55:48 GMT, Erik Gahlin wrote:
>> I don't see this event field being set anywhere? Which Metrics API call is
>> this using?
>
> How does it look in proc?
This was based on
On Wed, 14 Apr 2021 14:32:32 GMT, Severin Gehwolf wrote:
>> This is taken as reported by cgroups - I didn't want to change the semantics
>> so it does not confuse people familiar with cgroups.
>
> I don't see this event field being set anywhere? Which Metrics API call is
> this using?
How
On Wed, 14 Apr 2021 08:28:01 GMT, Jaroslav Bachorik
wrote:
>> src/jdk.jfr/share/conf/jfr/default.jfc line 1051:
>>
>>> 1049: false
>>> 1050:
>>> 1051: true
>>
>> I don't think we should create "flag" for "Container Events". Instead we
>> should treat them like CPU and other OS
On Wed, 14 Apr 2021 12:14:33 GMT, Jaroslav Bachorik
wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerCPUThrottlingEvent.java
>> line 44:
>>
>>> 42: @Category({"Operating System", "Container", "Processor"})
>>> 43: @Description("Container CPU throttling related information.")
>>>
On Wed, 14 Apr 2021 12:03:12 GMT, Jaroslav Bachorik
wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/events/ContainerMemoryUsageEvent.java line
>> 46:
>>
>>> 44: public final class ContainerMemoryUsageEvent extends AbstractJDKEvent {
>>> 45: @Label("Memory Pressure")
>>> 46:
On Wed, 14 Apr 2021 10:25:09 GMT, Erik Gahlin wrote:
>> 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 11 additional
>>
On Wed, 14 Apr 2021 11:17:14 GMT, Erik Gahlin wrote:
>> 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 11 additional
>>
On Wed, 14 Apr 2021 08:31:55 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Wed, 14 Apr 2021 08:28:37 GMT, Jaroslav Bachorik
wrote:
>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line
>> 163:
>>
>>> 161: private static void initializeContainerEvents() {
>>> 162: containerMetrics = Container.metrics();
>>> 163: if
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Mon, 12 Apr 2021 18:53:07 GMT, Erik Gahlin wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove trailing spaces
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 163:
>
>>
On Fri, 2 Apr 2021 12:33:03 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Thu, 1 Apr 2021 15:55:59 GMT, Jaroslav Bachorik
wrote:
>>> Does each getter call result in parsing /proc, or do things aggregated over
>>> several calls or hooks?
>>
>> From the looks of it the event emitting code uses `Metrics.java` interface
>> for retrieving the info. Each call to a
On Fri, 26 Mar 2021 11:05:56 GMT, Severin Gehwolf wrote:
>> Does each getter call result in parsing /proc, or do things aggregated over
>> several calls or hooks?
>>
>> Do you have any data how expensive the invocations are?
>>
>> You could for example try to measure it by temporary making
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
On Thu, 25 Mar 2021 23:28:18 GMT, Erik Gahlin wrote:
> Does each getter call result in parsing /proc, or do things aggregated over
> several calls or hooks?
>From the looks of it the event emitting code uses `Metrics.java` interface for
>retrieving the info. Each call to a method exposed by
On Wed, 24 Mar 2021 18:39:06 GMT, Severin Gehwolf wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>> turned
On Mon, 22 Mar 2021 15:57:12 GMT, Jaroslav Bachorik
wrote:
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
> With this change it becomes possible to surface various cgroup level metrics
> (available via `jdk.internal.platform.Metrics`) as JFR events.
>
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
> turned into JFR events to start with.
> * CPU related metrics
> *
With this change it becomes possible to surface various cgroup level metrics
(available via `jdk.internal.platform.Metrics`) as JFR events.
Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
turned into JFR events to start with.
* CPU related metrics
* Memory related
50 matches
Mail list logo
