Bug 185119 – WordLock doesn't need per-thread data

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Geoffrey Garen]

WordLock doesn't need per-thread data

[Geoffrey Garen]

Created attachment 339092 [details]
Patch

[Geoffrey Garen]

Benchmark results look neutral to me:

~/OpenSource> ./LockSpeedTest-baseline wordlock 1 4 1 0 40 2
WTFWordLock: 40014.319 KHz
WTFWordLock = {40014.319};
=====
~/OpenSource> ./LockSpeedTest wordlock 1 4 1 0 40 2
WTFWordLock: 41667.624 KHz
WTFWordLock = {41667.624};
=====
~/OpenSource> ./LockSpeedTest-baseline wordlock 1 4 10 20 40 2
WTFWordLock: 15257.590 KHz
WTFWordLock = {15257.590};
=====
~/OpenSource> ./LockSpeedTest wordlock 1 4 10 20 40 2
WTFWordLock: 15336.106 KHz
WTFWordLock = {15336.106};
=====
~/OpenSource> ./LockSpeedTest-baseline wordlock 1 4 128 1024 40 2
WTFWordLock: 1505.244 KHz
WTFWordLock = {1505.244};
=====
~/OpenSource> ./LockSpeedTest wordlock 1 4 128 1024 40 2
WTFWordLock: 1506.206 KHz
WTFWordLock = {1506.206};

[Yusuke Suzuki]

Comment on attachment 339092 [details]
Patch

r=me if it does not cause perf regression. I think it should be perf-neutral since basically constructing ThreadData is cheap.
I think we can use this approach in ParkingLot to remove ThreadSpecific.

[WebKit Commit Bot]

Comment on attachment 339092 [details]
Patch

Clearing flags on attachment: 339092

Committed r231151: <https://trac.webkit.org/changeset/231151>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/39825097>

[Geoffrey Garen]

> I think we can use this approach in ParkingLot to remove ThreadSpecific.

That would be cool!