I come from the IBM VMCMS and IBM Mainframe days (MVT MFT, TSO) etc.

When we wrote programs, particularly for vmcms, the compiler always made one segment for data, and multiple ones for constants and code.

When a program was initiated, the first thing that happened was to load the data, and then for the constants and code, determine if that segment was already loaded by another copy of the same program, or by other programs that may make use of the same segments / constant data section.

So, if there was 5 copies of a program like nautilus, for example, there would only be 5 data sections in memory and 1 copy each of the costant and code segments.

That functionality of course meant that memory consumption was optimized. In the mainframe environment the author could determine, if that a code segment in memory was deemed private, shareable by all or by group.

How does that work in Linux with Intel / Amd architecture?

If program X was comprised of 100k data, 100k constant, and 300k code segments, what would be in memory if, while program X was executing, a second program X was loaded by another user(process id)?

I would expect 1x100k data segment added to what is already in memory.

Is that what happens?
__________________

Number one is I'm not versed well enough to answer your question fully and describe in detail the sequencing and manners in which memory is allocated for Linux programs when they run. However I'll offer some references as well as my opinions for what it's worth.

There are processes and there are threads. My impression is that any given process owns all its memory and does not share that memory for re-use or duplication purposes such as you describe where the memory model re-uses constants as a method to efficiently manage memory.

Processes are an entire program's copy of every resource it requires to run.

Even if you fork() to create a child process, the child starts as a complete copy of the parent process with the minor exceptions that the identify of the process itself and the knowledge of parent/child is different between the parent and the child - being that the parent knows it has a child, it also knows the higher parent which created it and meanwhile the child knows who it's parent is. Otherwise the programs are identical in resources, however they are copies and therefore occupy unique memory spaces.

Threads have typically been called "lightweight processes" where they are copies of the process resources, but things like open files are direct re-uses. In other words, things which are mostly public are defined as shared resources between threads. There are very specific, but also understandable descriptions of the exactness of all of this, and I'd recommend you just do some general web searching to see those distinctions for yourself.

Below are some links for processes, threads, and thread vs process comparisons. I think the process description is very inclusive and will tell you a lot about how memory is managed. However I also think the thread vs process summary I happened to find is helpful but there are probably better descriptions which can relate the exact memory details of what is shared versus what is private per thread ID.

I think the bottom line (or my bottom line) here is that my opinion is that the Operating System does not do similar things to what you're speaking about. Instead it makes unique resource allocations per process and the use of threads was less about memory efficiency versus the need to have interprocess communications. In that you will notice that the many forms of IPC (also a good read for Linux) include things like sockets, shared memory, threads, pipes, and a few other techniques.

http://www.tldp.org/LDP/tlk/kernel/processes.html
http://www.tldp.org/FAQ/Threads-FAQ/index.html
http://www.thegeekstuff.com/2013/11/...s-and-threads/

Modern OS's, including Linux, have "anonymous" and non anonymous memory. Non anonymous memory is "mapped" from files and brought into ram by demand paging. Anonymous memory is created in ram and might be paged out to the swap space.

Non anonymous memory is typically shareable, meaning any pages brought into memory by demand paging the file can be shared among any processes mapping the same file.

In terms of the original question, most code and constants will be mapped and shareable. Most writeable data in most processes will by anonymous.

In 4Kb chunks, whichever parts of that 100k of constants have been referenced by one of the two processes would be in ram once (shared if both processes have accessed it). The same is mostly true of the 300k of code. But some 4kb pages of some code need load time fixups, which I think aren't shared even when identical, and if the code is in .so files the fixups typically aren't identical across processes sharing the code.

The 100k of data is created as "demand zero" (meaning it doesn't really exist in ram) or in some cases "copy on write" mappings when the program starts. Each 4Kb page of "demand zero" or "copy on write" memory that is written to is allocated as a real page of ram the first time it is written to.

Each process has its own mapping, which acts like it (the mapping tables themselves) are not shared. But even parts of the mapping tables can be shared when the OS can make shared mapping tables act as if they are not shared. Similarly, "demand zero" and "copy on write" mappings are shared in a way that lets the OS make it appear to the process that they are not shared (including converting to actually not shared when necessary to preserve the illusion that it never had been shared.

But there are also parts of the address space that are explicitly shared across processes.

Apologies if I'm landing on the wrong side of the tradeoff between avoiding misinforming the OP and avoiding being nasty to others who answer, but ...

These are much more matters of fact than opinion. I might have some of the subtle details incorrect in what I said earlier, but you have the basic facts much more fundamentally wrong. What Linux does is similar to (though more complicated than) what the OP described.

In modern systems, the amount of anonymous data has grown more than the amount of code and constants, and typical amounts of physical ram has grown even more than that. So all that complicated code and constant sharing is becoming a minor efficiency feature, rather than a fundamental part of what makes a Linux system usable. But it is all still in there.

I might quibble with the last paragraph.
KSM and z{ram,swap,cache} show that this is still an active area of interest and development in the kernel. All could be viewed as extensions to what the OP asked, but have an influence on which memory pages are ultimately shared.
Large pages throws another spanner in the works as well.