Sounds good! I agree that a 20% regression on a microbenchmark of the exclusive JSLock is not a problem, since that's not how WebCore usually behaves and Speedometer doesn't seem to care.
-Filip > On Feb 28, 2017, at 10:38 AM, Mark Lam <[email protected]> wrote: > > I’ve run Speedometer many times on a quiet 13” MacBookPro: removing the use > of exclusive thread status does not appear to impact performance in any > measurable way. I also did some measurements on a microbenchmark locking and > unlocking the JSLock using a JSLockHolder in a loop. The microbenchmark > shows that removing exclusive thread status results in the locking and > unlocking operation increasing by up to 20%. > > Given that locking and unlocking the JSLock is a very small fraction of the > work done in a webpage, it’s not surprising that the 20% increase in time for > the lock and unlock operation is not measurable in Speedometer. Note also > that the 20% only impacts WebCore which uses the exclusive thread status. > For all other clients of JSC (which never uses exclusive thread status), it > may actually be faster to have exclusive thread checks removed (simply due to > that code doing less work). > > I’ll put up a patch to remove the use of exclusive thread status. This will > simplify the code and make it easier to move forward with new features. > > Mark > > >> On Feb 24, 2017, at 9:01 PM, Filip Pizlo <[email protected]> wrote: >> >> Seems like if the relevant benchmarks (speedometer) are ok with it then we >> should just do this. >> >> -Filip >> >>> On Feb 24, 2017, at 20:50, Mark Lam <[email protected]> wrote: >>> >>> The JSC VM has this method setExclusiveThread(). Some details: >>> 1. setExclusiveThread() is only used to forego actually locking/unlocking >>> the underlying lock inside JSLock. >>> 2. setExclusiveThread() is only used by WebCore where we can guarantee that >>> the VM will only ever be used exclusively on one thread. >>> 3. the underlying lock inside JSLock used to be a slow system lock. >>> >>> Now that we have fast locking, I propose that we simplify the JSLock code >>> by removing the concept of the exclusiveThread and always lock/unlock the >>> underlying lock. This also give us the ability to tryLock the JSLock >>> (something I would like to be able to do for something new I’m working on). >>> >>> Does anyone see a reason why we can’t remove the concept of the >>> exclusiveThread? >>> >>> Thanks. >>> >>> Mark >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> [email protected] >>> https://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
