darwin-libplatform VS profiler

Apple Open Source Resources

Apple does plenty of open source stuff. Safari's browser engine, Swift, libdispatch, the XNU kernel used by iOS and macOS, etc. And macOS is generally packed with open source things, like the default shell, zsh. Also, Metal actually predates Vulkan, so Vulkan was definitely not established when they started focusing on Metal. Yeah, they probably should consider supporting Vulkan now, but it's nothing to do with open source. The main beneficiaries of Apple supporting Vulkan would be people porting closed-source games.

It's still not a great thing to do. Apple used to contribute a lot more, even if some of their stuff was exclusive to their platform. https://opensource.apple.com

There's quite a bit of macOS that's open source. The author links to source code in Firefox, and that source code has links to Apple's source code:

> // For information about the following undocumented flags and functions see

> // https://github.com/apple/darwin-xnu/blob/main/bsd/sys/ulock.... and

> // https://github.com/apple/darwin-libplatform/blob/main/privat...

Yes, but it's not so uncommon for "spinlocks" to evolve into not-actually-spinlocks. In the Linux kernel, spinlock_t is actually a mutex if PREEMPT_RT is enabled [1]. And Darwin has some code to do this in userspace [2], although I'm not sure if it's actually used.

[1] https://www.kernel.org/doc/html/latest/locking/locktypes.htm...

[2] https://github.com/apple/darwin-libplatform/blob/main/src/os...

Probably your best bet is to use the Firefox Profiler once it starts hogging the CPU to try to see what it's doing. I'd be happy to take a look at the result although I don't have a lot of experience at diagnosing performance problems; hopefully the profile will make it obvious what's going on.

I tried using the https://profiler.firefox.com/ and running with:

You can try to reproduce while taking a profile using the Firefox profiler, then share it in the #perf:mozilla.org room on Mozilla's Matrix instance.

Run a profiling session for ~30 sec when you notice something is running slower than you expect, see https://profiler.firefox.com/. Share results here if you want help interpreting them.

Next time, send a SIGABRT to the main process (kill -6 $(pidof firefox)) and use the resulting backtrace (you will find a link to the crash report in about:crashes) to file a bug. A performance profile could be useful, but you'll need to know first what to capture. This seems like a graphics issue, so try the Graphics preset. Share a link to your report.

https://profiler.firefox.com will be useful if you can capture and share it to developers.

If you can reproduce it in safe mode and a clean profile, capture a performance profile using the clean profile while trying to load a problematic webpage, don't remove any information from it, and share it here (although it's typically not easy for users to analyse them), or file a bug with it attached.

Next time, capture a performance profile using the Graphics preset, and kill the browser by entering kill -6 $(pidof firefox) in a shell. This will create a bug report (unless debian disables the crash reporter) that would indicate where Firefox is stuck at. You might need to use an official build to get useful results.