1. © 2004 IBM Corporation | Boston MA, April 19, 2004 John Arthorne, Eclipse Platform Core Team The Road to Responsiveness in Eclipse 3.0

2. The road to responsiveness | © 2004 IBM Corporation2 The road to responsiveness  Step 0 - If you make no changes, you will be ok (even slightly better)  Step 1 - Revisit locks to reduce contention with background jobs  Step 2 – Move long read only operations to background  Step 3 – Move long writing operations to background

3. The road to responsiveness | © 2004 IBM Corporation3 Step 0 – what if I do nothing?  Backwards compatibility: no worse than Eclipse 2.1  Blockage will always be reported to the user  The UI is kept alive (painting) at all costs  Cancelation is now always possible (even during deadlock)  Lack of responsiveness in one component can kill responsiveness gains in other components

4. The road to responsiveness | © 2004 IBM Corporation4 Step 1 - Revisit locks to reduce contention  ISchedulingRule: generic hierarchical locks  A given scheduling rule can only be “owned” by one thread at a time  No two threads can own rules that conflict with each other  Implemented by clients – every plug-in can define their own rules  Rules can be nested to form rule hierarchies  ILock: re-entrant lock, like Java object monitors, except:  Aware of syncExec: carries over to UI thread  Deadlock reporting and recovery

5. The road to responsiveness | © 2004 IBM Corporation5 Step 1 – Reducing contention (continued)  IWorkspace.run was used for both batching and locking  This has been decoupled: new IWorkspace.run with scheduling rule, WorkspaceJob subclass to obtain batching inside a job  Can now use scheduling rules to lock selected resources  IResource implements ISchedulingRule

6. The road to responsiveness | © 2004 IBM Corporation6 Step 2 – Move read-only operations to background  Less risk in moving read-only operations into background  Can be done with little or no contention  Watch for assumptions about UI thread and thread safety  Examples: searching, indexing, decoration, repository view  We have been doing this all along, but difficulties arise  Hard to coordinate access to resources, CPU  Background processes that don’t know about each other are prone to deadlock

7. The road to responsiveness | © 2004 IBM Corporation7 Step 2 – Moving to the background (continued)  Job API: org.eclipse.core.runtime.jobs  Job: a unit of work scheduled to run asynchronously  Why not just java.lang.Thread?  Lighter weight: uses a shared thread pool  Support for progress feedback and cancellation  Priorities and scheduling rules  Richer scheduling: run now, run later, run repeatedly  Job listeners can find out when jobs start, finish

8. The road to responsiveness | © 2004 IBM Corporation8 Step 3 – Move writing operations to background  Identify the big win operations – what common tasks will the user want to be able to perform in the background?  Trade-off is added complexity of code versus important responsiveness gains  Need to be aware of concurrency requirements of code you’re calling: locks acquired, etc  Be aware of deadlock risks and know avoidance strategies

9. The road to responsiveness | © 2004 IBM Corporation9 Step 3 (continued)  Avoid hold and wait:  ISchedulingRule: allows jobs to specify requirements before they even start (two phase locking).  Impossible to hold a rule and be waiting for a rule  Avoid holding locks while client code is called  Avoid syncExec and use asyncExec where possible  Avoid circular wait  Always acquire locks in a consistent order  Preemption:  If all else fails, preempt the thread that introduced deadlock and report error in log. This happens for free with ILock and ISchedulingRule

10. The road to responsiveness | © 2004 IBM Corporation10 UI presentation of jobs  Generic job feedback  Status line animation  Progress view  User initiated jobs need strong feedback (out of box)  User wants to feel in control  When did it start/finish?  What are the results?  View-specific jobs  Tell the user if the view is busy or invalid (half-busy cursor, title font)  System jobs: no feedback at all  Must not block the user

11. The road to responsiveness | © 2004 IBM Corporation11 Further reading  Examples plug-in (dev.eclipse.org/home/eclipse: org.eclipse.ui.examples.job  http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-core- home/plan_concurrency.html  GUI Bloopers, Jeff Johnson – Chapter 7: Responsiveness Bloopers  Concurrent Programming in Java, Doug Lea  Modern Operating Systems, Andrew S. Tanenbaum