

While shared memory is a feature in linux, it’s mostly used for inter-process communication and isn’t something that happens by default with shared libraries.
When a program loads a shared library, it creates a new instance of it that runs in the same memory space as the program.
In the example you’re using with KDE, that’s actually a system process that your program is communicating with, so it’s not quite the same as just loading a shared library (.so). Since new programs can connect to the existing system service, that can end up saving RAM by having a single system program service multiple user applications.
This isn’t really any different on Windows where the desktop environment (dwm.exe) is handling drawings and compositing for all user apps.
Edit: Based on the downvotes, maybe I got something wrong here. Maybe someone can comment on what? I’m happy to learn






Ahh, okay. I think the main confusion is I was kind of ignoring the code portion of the library, which is easily deduplicated like you said.
Any allocations done by the library running (opencl.so in this example) will still be separate per process though, unless the program is passing mutable shared memory buffers around, which could be the case if there’s IPC going on.
The point about memory usage being hard to measure is definitely true, especially since linux won’t actually consume memory until a write is made to the block, unlike Windows which preemptively allocates the full requested size.