Re: [webkit-dev] VM::setExclusiveThread()

It would be surprising if it did, since JS benchmarks usually acquire the JS lock around the whole benchmark. -Filip > On Feb 28, 2017, at 2:50 PM, Maciej Stachowiak wrote: > > > Good news that it doesn't affect Speedometer. Does this have any effect on > pure JS benchmarks

Re: [webkit-dev] VM::setExclusiveThread()

Good news that it doesn't affect Speedometer. Does this have any effect on pure JS benchmarks running in the browser (e.g. JetStream)? - Maciej > On Feb 28, 2017, at 10:48 AM, Filip Pizlo wrote: > > Sounds good! > > I agree that a 20% regression on a microbenchmark of the

Re: [webkit-dev] VM::setExclusiveThread()

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 wrote: > > I’ve run Speedometer

Re: [webkit-dev] VM::setExclusiveThread()

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

Re: [webkit-dev] VM::setExclusiveThread()

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 wrote: > > The JSC VM has this method setExclusiveThread(). Some details: > 1. setExclusiveThread() is only used to forego

[webkit-dev] VM::setExclusiveThread()

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