sipp...@sg.ibm.com (Timothy Sipples) writes: > z/VM performs such magic in at least three different ways: Discontiguous > Saved Segments, Named Saved Systems, and VM Data Spaces. These mechanisms > are probably somewhat relevant to z/OS when it operates as a z/VM guest. > > I hate to disagree with Jim Mulder. :-) But I'm going to disagree with his > absolute "No." Specifically and as an example, Java on z/OS does some > interesting things with shared memory that, in my view, fit the question as > stated.
re: http://www.garlic.com/~lynn/2014i.html#66 z/OS physical memory usage with multiple copies of same load module at different virtual addresses http://www.garlic.com/~lynn/2014i.html#67 z/OS physical memory usage with multiple copies of same load module at different virtual addresses http://www.garlic.com/~lynn/2014i.html#68 z/OS physical memory usage with multiple copies of same load module at different virtual addresses having continued to work on 370 all during the FS period ... even periodically ridiculing FS http://www.garlic.com/~lynn/submain.html#futuresys ... when FS failed, there was mad rush to get stuff back into the 370 product pipelines (during FS which was to totally replace 370, lots of 370 activity was suspended &/or killed, lack of 370 products during the period was credited with giving clone processors a market foothold) ... which contributed to decision to release lots of the stuff that I had been doing ... some old email: http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 an extremely small subset of the page-mapped filesystem stuff was released as discontiguous saved segments. part of the issue was that FS was going to be paged-mapped filesystem as single-level-store ... but done so very badly that it gave paged-mapped filesystem a bad name. so a lot of work that I had done on cms code to have it run in shared segments was released ... but a drasticly reduced subset of the CP & CMS support (w/o paged mapped filesystem support) was released as discontiguous saved segments. some related recent discussion over in a.f.c.: http://www.garlic.com/~lynn/2014i.html#69 IBM Programmer Aptitude Test http://www.garlic.com/~lynn/2014i.html#70 IBM Programmer Aptitude Test Part of the issue was that FS single-level-store was somewhat brought over from tss/360 w/o any performance improvements. I mentioned as undergraduate I got to play with cp67/cms on weekends sometimes sharing the 360/67 with IBM SE playing with tss/360. We both did the same synthetic benchmark workload for fortran edit, compile, link & execute. I could show 35 simulated cp67/cms user test that had better throughput and response than he did with 4 simulated tss/360 user test. I claimed when I did the cms paged-mapped filesystem, I had learned all the stuff not to do from watching tss/360. With cms paged-mapped filesystem that had three times the throughput of the standard cms filesystem (on same disks and hardware). However, it wasn't enough to overcome the prejudice resulting from the FS failure. past posts http://www.garlic.com/~lynn/submain.html#mmap as an aside ... I also felt a little rivalry with the multics group one floor up in 545 tech sq ... which was also a virtual memory paged mapped filesystem. http://www.garlic.com/~lynn/subtopic.html#545tech Multics http://en.wikipedia.org/wiki/Multics from above: Multics implemented a single level store for data access, discarding the clear distinction between files (called segments in Multics) and process memory. The memory of a process consisted solely of segments which were mapped into its address space. To read or write to them, the process simply used normal CPU instructions, and the operating system took care of making sure that all the modifications were saved to disk. In POSIX terminology, it was as if every file was mmap()ed; however, in Multics there was no concept of process memory, separate from the memory used to hold mapped-in files, as Unix has. All memory in the system was part of some segment, which appeared in the file system; this included the temporary scratch memory of the process, its kernel stack, etc. ... snip ... some of the CTSS people http://en.wikipedia.org/wiki/Compatible_Time-Sharing_System had gone to the 5th flr and multics ... others had gone to the IBM science center on 4th flr and did cp40 (later morphs into cp67 and then vm370), internal network, lots of performance and online stuff, as well as the technology used for the internal network and corporate sponsored univ. BITNET. GML was also invented at the science center in 1969 (a decade later morphs into international standard SGML, and another decade morphs into HTML at CERN). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
