From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7b69a8818c20ab9f X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Y21C Bug Date: 2000/01/07 Message-ID: #1/1 X-Deja-AN: 569567050 Sender: bobduff@world.std.com (Robert A Duff) References: <84nqbo$q28$1@nnrp1.deja.com> <84o0g2$u8v$1@nnrp1.deja.com> <84pvrs$7q1@ftp.kvaerner.com> <84sltt$7s3@ftp.kvaerner.com> <84t966$be0$1@nnrp1.deja.com> <84vev2$7p4@ftp.kvaerner.com> <38737352.B282CC2@easystreet.com> <851j2q$78q1@ftp.kvaerner.com> <852dt0$vdl$1@nnrp1.deja.com> <87iu16yxv4.fsf@deneb.cygnus.argh.org> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-01-07T00:00:00+00:00 List-Id: Florian Weimer writes: > I think commit on use is the same thing what's called copy on write > on Linux. Really? I thought "copy on write" (or "virtual copy") meant what, for example, most modern Unix systems do for fork() -- the fork() system call is defined to copy the entire address space of the process, producing two identical processes. Using memory-mapping hardware, you can map all the pages to the same physical locations, and mark them read-only. If either process actually wants to write, it traps into the OS, which actually makes the copy. I thought "commit on use" (or "zero on use") meant that (as in your example below), virtual memory is allocated, but physical memory is not. Then, a read or write of that memory will trap, and the operating system will gin up an all-zeros page of memory. Still nobody has answered my question about which operating systems support these fancy things. > For example, you can run the following program on a box > which only has some 300 MB of virtual memory (RAM + swap), and it will > `allocate' approximately 1.5 GB of `memory': [program that allocates large numbers of huge strings] > Of course, you shouldn't use an initialized allocator here. ;) Indeed. I once wrote a program that was doing something like that for arrays-of-pointers-to-records. I might allocate millions of pointers, and only use 3 or 4 of them in a typical case, but once in a while need a whole lot. Unfortunately, Ada wants to initialize pointers to null, which caused my program to run extremely slowly -- it spent most of its time initializing data that I was never going to use in the typical case (and probably paging it out disk for me, too -- I don't remember). I solved the problem with an ugly hack: allocate an array of integers, and unchecked-convert to an array of pointers. Or maybe I unchecked-converted a pointer to the arrays -- I don't remember. I think the DEC Ada compiler would have handled it better -- I think it was clever enough to know that the VMS operating system was going to zero those pages if they were ever referenced, and null is represented as zero, so the compiler didn't actually zero them. On the other hand, I once wrote something like: X: array(1..One_Zillion) of Integer := (others => 0); and the DEC Ada compiler blew up at compile time, apparently trying to be clever at run time. Anyway, none of these fancy memory-mapping tricks are much good if they're not portable. - Bob