4 ms·

The solution here, rather than using OS-internals is for Firefox to implement spin locks themselves, which is the level that they should be thinking if they're

by olliej 4y ago

The solution here, rather than using OS-internals is for Firefox to implement spin locks themselves, which is the level that they should be thinking if they're making their own allocator. This is what webkit, chromium, etc - webkit even has a blog post: https://webkit.org/blog/6161/locking-in-webkit/ https://webkit.org/blog/6161/locking-in-webkit/

saagarjha 4y ago
I get the impression the author was a little hesitant to do any spinning in userspace.
ben-schaaf 4y ago
> As an intermediate solution, I initially fell back to OSSpinLock on older systems. Later I managed to get rid of it for good by relying on os_unfair_lock plus manual spinning in user-space.
gsvelto 4y ago
You're confusing general purpose locks with special-purpose ones used in the memory allocator. Firefox has its own GP locks, you can find them here: https://searchfox.org/mozilla-central/search?q=&path=xpcom%2Fthreads%2F*Mutex https://searchfox.org/mozilla-central/search?q=&path=xpcom%2...* However those are not suitable for use in the memory allocator, and neither are WebKit's. WebKit uses os_unfair_lock within its memory allocator: https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de9957ab2afc97185879bc4/Source/bmalloc/libpas/src/libpas/pas_lock.h#L120 https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de995... And so does Chromium: https://source.chromium.org/chromium/chromium/src/+/main:base/allocator/partition_allocator/spinning_mutex.h;l=54 https://source.chromium.org/chromium/chromium/src/+/main:bas...
- olliej 4y ago
  Correct, and that isn't what this article is talking about. This article is about an internal function in the OS that they've decided to is what they'd like to use, and that the only reason they aren't using it is because it doesn't exist in older versions of macOS, because you know, it is an implementation detail of the OS. os_unfair_lock are a documented part of the OS API: https://developer.apple.com/documentation/os/1646466-os_unfair_lock_lock https://developer.apple.com/documentation/os/1646466-os_unfa...
  - Vinnl 4y ago
    Just a note thay you're replying to the author, so I'm sure they know what it's talking about :)

by olliej 4y ago

saagarjha 4y ago

I get the impression the author was a little hesitant to do any spinning in userspace.

ben-schaaf 4y ago

> As an intermediate solution, I initially fell back to OSSpinLock on older systems. Later I managed to get rid of it for good by relying on os_unfair_lock plus manual spinning in user-space.

gsvelto 4y ago

You're confusing general purpose locks with special-purpose ones used in the memory allocator. Firefox has its own GP locks, you can find them here: https://searchfox.org/mozilla-central/search?q=&path=xpcom%2Fthreads%2F*Mutex https://searchfox.org/mozilla-central/search?q=&path=xpcom%2...* However those are not suitable for use in the memory allocator, and neither are WebKit's. WebKit uses os_unfair_lock within its memory allocator: https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de9957ab2afc97185879bc4/Source/bmalloc/libpas/src/libpas/pas_lock.h#L120 https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de995... And so does Chromium: https://source.chromium.org/chromium/chromium/src/+/main:base/allocator/partition_allocator/spinning_mutex.h;l=54 https://source.chromium.org/chromium/chromium/src/+/main:bas...

olliej 4y ago
Correct, and that isn't what this article is talking about. This article is about an internal function in the OS that they've decided to is what they'd like to use, and that the only reason they aren't using it is because it doesn't exist in older versions of macOS, because you know, it is an implementation detail of the OS. os_unfair_lock are a documented part of the OS API: https://developer.apple.com/documentation/os/1646466-os_unfair_lock_lock https://developer.apple.com/documentation/os/1646466-os_unfa...
- Vinnl 4y ago
  Just a note thay you're replying to the author, so I'm sure they know what it's talking about :)