|[cross-project-issues-dev] Add JFR Events (Java Flight Recording)|
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, lengthMost 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, reasonBuild 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 Threadto 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
Back to the top