2.85 KB, patch
|Details | Diff | Splinter Review|
46 bytes, text/x-phabricator-request
|Details | Review|
In a quick browsing session (CNN, ArsTechnica, small google doc) I had >300K mutex locks on TransportSecurityInfo mutexes. 99.99% of these are from GetErrorCode(). Moving mErrorCode to be an unlocked Atomic<> cuts the max lock() calls per mutex from ~15K to 81. Note that this is an incomplete solution, since we need to figure out what to do with the code that sets it under a lock and other info as well, and perhaps update the API and the code that polls for errors and grabs data from the object.
Looks like most calls to GetErrorCode() are asking if an error has been set and don't care what it is. I imagine we could add an atomic boolean that gets set when we set the error code.
Assignee: nobody → dkeeler
Priority: -- → P1
Before this patch, Necko functions polling the state of TLS sockets (essentially, TransportSecurityInfo) would cause a considerable amount of locking on TransportSecurityInfo::mMutex instances via GetErrorCode(). Most of this code only cared if an error had been set via SetCanceled(), so this patch adds an atomic boolean mCanceled (and associated accessor GetCanceled()) that can be used to the same effect but without acquiring the lock.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/7b439431eb95 avoid acquiring TransportSecurityInfo::mMutex in hot code r=jesup,jcj
What tool were you using to measure lock() calls? (i.e. how would I measure the effectiveness of this change?)
Dana: see the patch on bug 1498643 (I'll update it with the latest version, which covers Windows too). Note that you may need to disable sandboxing (fprintf(stderr...)) or use a non-e10s run.
You need to log in before you can comment on or make changes to this bug.