[cross-project-issues-dev] Add JFR Events (Java Flight Recording)

[Jörg Kubitz <jkubitz-eclipse@xxxxxx>]

Hi,
I would like to know if others would like to see Eclipse specific JFR 
Events in Eclipse too. They do not offer any value for the user. But 
they would allow eclipse developers to get a better understanding of 
what is going on in eclipse. Hopefully help to understand performance 
issues or optimization possibilities.
JFR adds stacktrace, thread name, timestamps and duration for free.
Additional events would only help if they provide additional information 
like a name of something.
Events do add information how often the events occurred for how long 
with a very fine time resolution. While sampling only reveals a coarse 
total amount time. And profiling is often a no go due to the big overhead.
Unlike logging/tracing the Events are well structured and can be 
sorted/grouped with Tools like JDK Mission Control. Also JFR has a much 
smaller performance and space overhead then tracing. This allows to 
enable Events that are otherwise too frequent to log:

Possible additional Events for Platform:
1. File: name, length
 Most of performance issues are OS related (SWT or File access). Since 
many of eclipses file method are native they can not be observed with 
the JDK's standards Events. Seeing which files where accessed hopefully 
helps to eliminate such calls. Example: Currently at IDE start the same 
files/directories are accessed multiple times.

2. Build: name, reason
 Build time for big workspaces is a problem. I'd like to understand why 
which projects is build (for us sometimes it feels like they are 
unnecessary build again and again) and which project takes longest.

3. Job: name, class, result, (locking) rule, ...
 Sometimes Jobs lock workspace or project for some time. I don't know 
yet how it may help but there is a lot of information available that may 
give a deeper insight.

4. SWT Display.syncExec(), Display.asyncExec(): runnable, scheduling Thread
 to see which Threads adds which events. By adding a further Event for 
the Runnable.run() and sharing a common ID it can then be seen which 
Display.asyncExec() caller caused the time spend in SWT Thread. I hope 
that that would help to analyse performance problems. Often when i look 
at sampling it is not obvious what caused the Action and if it was the 
sheer amount of events or few long running actions that caused lag.

In a long run JFR could replace Eclipses tracing to logfiles. Another 
advantage over logfiles is that the Event's can be dumped to disk on 
demand. So one could start eclipse with recording enabled but only dump 
events to disk if a strange behaviour occcured and then upload that dump 
to bug tracker.

Please see screenshot and join dicsussion in Bug 578055

https://bugs.eclipse.org/bugs/show_bug.cgi?id=578055

Jörg