OperationType in SafepointBegin event

[Jean-Philippe Bempel]

Hi Erik,

I don't have a better solution except adjusting the threshold to 0ms
for ExecuteVMOperation to always get it and having SafepointId that we
could correlate with the SafepointBegin event.
So if you think it's not worth it, let's forget about it and let's
leave it like this.

Thanks

On Wed, Dec 2, 2020 at 9:36 AM Erik Gahlin <erik.gahlin at oracle.com> wrote:
>
> Hi Jean-Philippe,
>
> I would prefer to not duplicate information. Can we come up with something better?
>
> Which VM operation events would flood the system? Will the removal of biased locking help here (revoke bias). Maybe handshakes should move to a separate event?
>
> Erik
>
> > On 2 Dec 2020, at 09:05, Jean-Philippe Bempel <jean-philippe.bempel at datadoghq.com> wrote:
> >
> > Hello,
> >
> > Does this proposition make sense to you?
> >
> > Thanks
> >
> > On Tue, Nov 24, 2020 at 4:57 PM Jean-Philippe Bempel
> > <jean-philippe.bempel at datadoghq.com> wrote:
> >>
> >> Hello All,
> >>
> >> With default JFR settings (default.jfc) you may end up with no 1:1
> >> mapping between SafepointBegin event and ExecuteVMOperation event.
> >> While having ExecuteVMOperation without SafepointBegin could be normal
> >> (Some VMOperation does not require Safepoint like Handshake for
> >> example), Having a SafepointBegin should normally be associated with a
> >> VM operation.
> >>
> >> By default JFR settings record SafepointBegin & ExecutionVMOperation
> >> events greater than 10ms (threshold). So your VM Operation could be
> >> quick (less than 10ms, so not recorded along with VMOperation type)
> >> but the SafepointBegin event can have a long duration because bringing
> >> all Java threads at safepoint (so called Time-To-SafePoint) can take
> >> several ms in itself (ex System.arraycopy call on large buffers).
> >>
> >> So you’re ending up with a long SafepointBegin event, but without
> >> ExecuteVMOperation event associated, and could not figure out what
> >> triggers this safepoint.
> >> Currently, SafepointBegin event does not record the VMOperation
> >> type[1] unlike ExecuteVMOperation event[2] which does not facilitate
> >> the troubleshooting.
> >>
> >> Note: Xlog tracing (-Xlog:safepoint) give us the VMOperation type[3]
> >>
> >> My proposal is the following:
> >>
> >> Add the same operation field in SafepointBegin than in
> >> ExecuteVMOperation event in metadata.xml and modify
> >> post_safepoint_begin_event to add VMThread::vm_op_type() and set it
> >> into the event.
> >> If you are ok with that I can open a ticket and push a PR.
> >>
> >> Regards,
> >> Jean-Philippe
> >>
> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/metadata/metadata.xml#L560
> >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/metadata/metadata.xml#L589
> >> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/safepoint.cpp#L1114-L1125
>