lori@hacgate.scg.hac.com (Lori Barfield + 7/9) (02/07/90)
In article <3322@paperboy.OSF.ORG> lwa@osf.org (Larry Allen) writes: >[...] >[regarding the munching of virtual space by programs which don't run in >worst-case mode very often] As Dave notes, this adversely >affected some applications (eg old Fortran programs) >that allocated huge amounts of virtual memory not intending >to ever use most of it. You said it. The old scientific applications I have to maintain are STAYING at SR9 and JLRA! We have no plans to re-write our old 20K-80K line programs in C or Pascal (or funky FORTRAN) just to take advantage of linked lists. (Although I have enforced the use of dynamic memory allocation in the development of one new analysis program. That's one out of....) Actually, I'm assuming here that the use of dynamic memory allocation obviates this problem. Does it? >[regarding how to implement both OS vmem allocation methods] Off the top >of my head, the only thing I can imagine is some kind of >option (perhaps a per-object-file stamp??) that tells the >OS "for this application, don't preallocate backing storage". >This seems pretty ugly and hard to administer, as well as >being pretty non-obvious to the "average user". How about a single system call at the start of a program to set something like a process parameter or environment flag? This takes it out of the hands of the user. Under JLRA, I had my large Pascal applications allocate, then deallocate a certain amount of memory at the start, depending on what options the user chose on the command line. This gave us the advanced error checking and speedier execution down the line. The software was smarter than Unix in guessing how much room it would need. ...lori