Do executables in different containers share shared objects that are define in the same common image layer?

I am investigating the memory impact of containerising two processes that depend on the same shared object. My main question is whether the shared object will be loaded in memory twice or not. This question has been asked before, but the answers were not complete and contradicting with my experiments. I will cite what I already encountered: https://unix.stackexchange.com/questions/116327/loading-of-shared-libraries-and-ram-usage --> Use -fPIC for your .so https://unix.stackexchange.com/questions/671259/do-docker-containers-share-ram-for-files-memory-mapped-from-the-same-layer-but-a --> Yes, but depends on your setup. You can prove it but checking the device and inode id of the loaded shared object. No indication of what setup to use. https://stackoverflow.com/questions/35863608/shared-library-in-containers --> Yes, depends on your storage driver. aufs, overlay or overlay2 storage drivers support this. https://stackoverflow.com/questions/63145223/about-loading-dynamic-library-in-container --> Each container is its own execution unit. No sharing occurs. Contradicting with the previous. I used the following setup: - base layer --> Contains the OS and two shared objects (G and S - Precompiled using -fPIC) - dependsOnG layer --> Starts from base, contains the executable which depends only on G (Precompiled) - dependsOnGandS layer --> Starts from base, contains the executable that depends both on G and S (Precompiled) Storage driver: Overlay Below you can see the information from grep glib /proc/PID/maps. The PIDs are the processes of the executables inside the container.

| /proc/17/maps:7efd3b630000-7efd41980000 | r-xp | 00000000 | 00:a2             | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41980000-7efd41b7f000 | ---p | 06350000 | 00:a2             | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b7f000-7efd41b80000 | r--p | 0634f000 | 00:a2             | 16802420 | /app/libglib.so |
| /proc/17/maps:7efd41b80000-7efd41b81000 | rw-p | 06350000 | 00:a2             | 16802420 | /app/libglib.so |

| /proc/39/maps:7fca97208000-7fca9d558000 | r-xp | 00000000 | 00:bb             | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d558000-7fca9d757000 | ---p | 06350000 | 00:bb             | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d757000-7fca9d758000 | r--p | 0634f000 | 00:bb             | 16802420 | /app/libglib.so |
| /proc/39/maps:7fca9d758000-7fca9d759000 | rw-p | 06350000 | 00:bb             | 16802420 | /app/libglib.so |

If I interpret the result correctly, the two processes view completely different files (the device id is different), thus, the shared object will be loaded twice in memory (seems consistent with what I see with the free command). According to the information I found online this shouldn't happen. I have the following questions: 1. Should the shared object be loaded only once? 2. Does the overlay storage driver support this functionality? 3. Should I be constructing my images/containers in a different way? (I did the same experiments using volumes instead of common layers and indeed the files were identical, however, that's not quite what I want) Thanks in advance!