No, it's very common. It's widely used in garbage collectors (instead of write barriers) and JIT compilers (for changing the code and also just for halting code execution) among other places. It's so common that userfaultfd was added as a better approach:
man7.org/linux/man-page
Conversation
Firefox also has a custom linker using this. On Android, the traditional officially supported approach to native libraries has them stored compressed in the apk and automatically extracted by the package manager to a library directory not writable by the application.
1
2
The more modern officially supported approach leaves them uncompressed in the apk (which only impacts installed size, since apk downloads should be compressed due to this approach for various kinds of resources, etc.) and aligned to page size. The linker knows how to map those.
1
Firefox stores the libraries compressed using a path not extracted as native libraries by the package manager. Instead, they manually extract / decompress the libraries. On low-memory ones, they put them in app data. On high-memory ones, they extract them directly into memory.
1
The insane part is that they use some nasty hacks to perform this extraction / decompression lazily. They catch segmentation faults from attempts to use the libraries and then map them in to those locations on demand, either paged from app data (low mem) or as dirty pages...
1
Chromium takes the officially supported approach of having them stored aligned / uncompressed in the apk and mapped directly from there. In fact, that was originally created for Chromium in a custom "crazy_linker" (doesn't deserve that name when you look at what Firefox does).
1
They added it as an officially supported approach to the OS as part of the standard linker, and Chromium moved to using that instead of crazy_linker. The real crazy linker is the Firefox GeckoLinker though. It's insane. It even monkey patches functions in libc to hijack them.
2
3
Are you sure any of that's still present? I don't think it is, because musl-based dists aren't having to do anything to rip it out, and I'm pretty sure it would break so bad they'd have to be ripping it out not to have serious visible breakage.
1
Yes, it's all still present. It's specific to mobile though. I linked to the sources for the Firefox code at the end of the thread. They do it because they want to minimize storage usage instead of just having a single uncompressed copy mapped directly from the apk like Chromium.
2
1
Their libraries are huge, and for whatever reason they decided it's saner to have them as massive spans of dirty pages in memory instead of storage, because apparently wasting a huge amount of memory is better for users. Makes it more likely people have enough storage to install.
1
They are quite literally choosing to make the libraries ~30% or so smaller on storage (they're just compressed) at the cost of having the entirety of them in memory as dirty pages. It's ridiculously hard to justify and the opposite of what most people would consider optimization.