[cross-project-issues-dev] Add JFR Events (Java Flight Recording)
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