Open Bug 1049083 Opened 11 years ago Updated 2 years ago

Improve multi-threaded performance in DeadlockDetector

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Type:
defect

Tracking

()

People

(Reporter: erahm, Unassigned)

References

Details

Look into "better" locking for deadlock detector. Currently there is one lock that guards access to the DeadlockDetector's hashtable and must be acquired every time a thread wants to lock. DeadlockDetection can be costly, so causing a thread to block while another is determining whether or not it will deadlock can lead to greater delays than necessary. Options include finer grained lock, maybe an rwlock, etc. We should add a scalability test to stress this as well as unit tests. Additionally we should profile how often locks are removed/added vs deadlock-detected to determine if an rwlock would provide any benefit.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.