This is a simplistic approach for sure, but it seems to me if z/OS supported something like this, there would be a significant amount of physical memory savings on the system. At least at our shop.
1. (Assuming z/OS does not already do this) Set up infrastructure, so every PDS/PDSE member gets its own unique identifier (or inode). For example, CICS.USERLIB1(PROGRAM1) and CICS.USERLIB2(PROGRAM1) would each have their own inode. 2. When a load module (i.e. PDS/PDSE member) is going to be loaded into an address space, check if the inode has already been loaded on the system by another address space. If yes, go to 4. If no, go to 3. 3. (First time load of a load module into the system by address space A) Load the module into the virtual address space A and physical memory as normal. However, also track any virtual pages for that load module that did not need to be altered (i.e. ADCON, VCON, etc.). 4. (Nth time load of a load module into the system by secondary address space B) When loading the module into the virtual address space B and physical memory, make sure any virtual pages for the load module that do not need to be altered for B and were not altered for A point to the same physical frame. These "shared" virtual pages for B will also be marked as copy-on-write. Any future writes to these "shared" virtual pages in address space B will result in B getting its own separate physical frame. Again, I am sure this is an incredible over-simplification of how this works, but the general idea of being able to share physical frames for the same unique load module that are loaded in separate address spaces should result in a significant amount of physical memory savings on a z/OS system, I would think. Thanks, Tim -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Friday, July 25, 2014 3:49 PM To: [email protected] Subject: Re: z/OS physical memory usage with multiple copies of same load module at different virtual addresses On Fri, 25 Jul 2014 14:57:15 -0500, Tom Marchant wrote: >On Fri, 25 Jul 2014 15:17:48 -0400, Shmuel Metz (Seymour J.) wrote: > >>on at 09:42 AM, John Gilmore said: >> >>>If 1) the execution loader has brought a load module or program >>>object into storage and 2) that executable is marked refreshable >>>and/or reentrant, the execution loader will not bring second or >>>subseq >> >>Nonsense. It would be nice if it worked that way, but it never has and >>probably never will. If you want to share, put it in LPA or use a DLL. > >Just to clarify, it does, but only within an address space. The OP asked about >multiple address spaces. > >>There's more than one address space. > >Right. > As Joe D'Alessandro pointed out, with a citation in the PoP, there's considerable hardware support for this function. z/OS chooses to exploit it, but not as fully as it might -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
