allan.stal...@kbmg.com (Staller, Allan) writes: > There can also be performance advantages from GC. GC moves objects > together in storage, making it much more likely that your application > data will be in the processor caches. If GC keeps your data in > processor cache it will perform much better than if it's scattered > across a GB of storage.
apl\360 would allocate new storage for every assignment statement, quickly using every available location in workspace ... and then it would collect everything in contiguous storage (garbage collect) and then start all over again.. This wasn't too bad with apl\360 typically 16kbyte (sometimes 32kbyte) workspaces there were swapped as integral unit. the initial port of apl\360 to cp67/cms for cms\apl was something of a problem because it allowed workspaces that were the size of virtual memory ... and strategy would quickly result in page thrashing (repeatedly touching every virtual page regardless of actual program&data size). before release of cms\apl, this all had to be reworked in order to reduce the massive page thrashing. Besides doing virtual machines, cp67/cms, the technology for the internal network (and corporate sponsored univ bitnet ... where ibm-main originated), GML, and lots of other things ... the science center http://www.garlic.com/~lynn/subtopic.html#545tech also did a number of performance & analysis tools. One did processing & storage use analysis ... which was used for analyzing cms\apl and bunch of other things. It was also used extensively inside ibm by most product groups in their transition to virtual memory operation (would identify hot-spot instruction use as well as hot-spot storage use) ... and eventually released to customers as VS/Repack (which attempt semi-automated program reoganization to improve operation in virtual memory environment). references to internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet references to bitnet http://www.garlic.com/~lynn/subnetwork.html#bitnet references to gml (sgml, html, etc) http://www.garlic.com/~lynn/submain.html#sgml a major factor in the motivation in transition from os/360 MVT to virtual memory OS/VS2 was significant problems with the way MVT managed real storage, GETMAIN, etc ... regions had to typically be four times larger than really needed. The analysis showed that typical 370/165 MVT 1mbyte machine only supported four regions. A "virtual memory" MVT on 370/165 1mbyte machine could support 16 regions with little or no paging (aka keep all the in-use data in the 370/165 1mbyte "processor" cache). Old reference to study motivating to move all 370 to virtual memory: http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory -- 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
