[discussion] 8242220: Capture JFR stack trace and thread other than the one the event is committed on

[Jaroslav Bachorík]

Hello,

I would like to start a discussion about the prototype PR:
https://github.com/openjdk/jdk/pull/2238 allowing to commit an event
on a custom Java thread.

The reasons for this are explained in the PR but for an easier
jumpstart I am attaching the PR description here:
---
This is an early prototype of an enhanced Event.commit(thread) method
which allows committing a JFR event on a custom java thread. This
would allow, for example, having a scheduled 'sampling' thread
generating events and filling them up with shared aggregation data and
then committing them on behalf of a 'sampled' thread.

Committing an event on the given thread means that the event will be
associated with that particular thread, will receive the stack trace
of that thread at that particular moment and, internally, will be
written out using that thread's thread-local structures. The
association is on 'best-effort' basis as the target thread may be
terminated and gone by the time the event is committed and in that
case the event will be committed on the caller thread and will be
missing the stacktrace data.

The change is rather trivial - extend the Event API to provide
commit(Thread) method and then use thread-local handshake to fill in
the stacktrace details of the indicated thread. The code changes are,
however, more extensive as all the supporting classes need to be also
aware of the new Event method.

As already mentioned this is a very early prototype of this particular
functionality. I am aware that finalizing this will take much more
work but at least for DataDog this feature is quite useful and
starting the discussion about it with a concrete piece of code seems
to be the right way to go.
---

Looking forward to hearing back on this topic!

Cheers,

-JB-