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, 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 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
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
> *
