tim@hoptoad.uucp (Tim Maroney) (12/27/89)
In article <4525@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >With virtual memory on the horizon, Handles may not be long for this world. Generally a good message, but I wanted to take issue with this. In the new Mac virtual memory system, applications can't increase their heap allocations at runtime. Therefore, heap fragmentation can still be a problem, and handles remain important. It is a mistake to extrapolate from other VM systems to the Mac's, which is rather limited. For instance, under ordinary VM, a RAM-based editor is automatically a disk-based editor. Many large documents can be kept in RAM, apparently, even though in fact they are being kept largely in paging space on the disk. With the Mac VM system, though, you are limited to your initial allocation of RAM. So a RAM-based editor does not approximate to the performance of a disk-based editor, and you would still be well advised to handle your own temporary files, purgeable lines, and so forth. I am also a bit concerned about the performance of the Memory Manager under VM. The Mac uses a linked-list block allocation scheme, which involves searching through linked lists of free blocks in RAM for allocation operations. This is suboptimal for a VM system -- there may be a lot of paging overhead as you go through the linked list, and your page reference counts will be affected strangely. For VM, it is generally better to use an index-based allocator, where the information on free blocks is kept separate from the blocks themselves and concentrated in a few pages of indices. This way, free blocks do not have to be paged in to be checked for suitability. Does anyone have any information on the performance impact of the Mac MM algorithm under VM? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Because there is something in you that I respect, and that makes me desire to have you for my enemy." "On those terms, sir, I will accept your enmity or any man's." - Shaw, "The Devil's Disciple"
ts@cup.portal.com (Tim W Smith) (12/29/89)
Even if the heap size could be changed, handles are a nice thing to have under a VM system. The ability to shuffle things around to compact (virtual) memory will make almost any memory allocation algorithm run better. Especially linked list schemes. If the typical memory allocation size is larger than the page size, then it probably doesn't matter much. But if a lot of small things need to be allocated, handles are great. Also, having your working set in contiguous virtual memory rather than scatter all over the place should make paging run better. Tim Smith
dorner@pequod.cso.uiuc.edu (Steve Dorner) (12/29/89)
In article <25471@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Even if the heap size could be changed, handles are a nice thing to >have under a VM system. The ability to shuffle things around to >compact (virtual) memory will make almost any memory allocation >algorithm run better. Handles are a pain for programmers; they clutter the code, making applications not only harder to write, but harder to comprehend and debug. That translates into bugs, which either surface in finished applications, or delay the release of nifty things. I for one would rather see the VM system take a few more hits, and applications have a few less bugs. Down with handles! -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
hirchert@ux1.cso.uiuc.edu (12/30/89)
Steve Dorner (dorner@pequod.cso.uiuc.edu) writes >Handles are a pain for programmers; they clutter the code, making applications >not only harder to write, but harder to comprehend and debug. That translates >into bugs, which either surface in finished applications, or delay the release >of nifty things. > >I for one would rather see the VM system take a few more hits, and applications >have a few less bugs. Down with handles! It seems to me that the problem is not with the use of handles, but with their abuse, especially the failure of the languages in use to reflect the abstraction behind handles. Many of the problems cited stem simply from the fact that there is no way to tell the compilers to defer dereferencing of a handle until after a system call or procedure call has taken place. Others would be eliminated if the standard mechanism for locating objects (especially procedure arguments) were a handle and displacement rather than a pointer, so that determination of the actual location of the object could be deferred. With these changes in abstraction, many of the current situations that "require" locked handles could be handled perfectly well without locking. Eliminating the "necessity" of locking would eliminate much of the difficulty in writing code involving handles, most of the clutter in that code, and eliminate the latent bugs by letting the compiler recognize the necessary constraints and deal with them automatically. Locking handles would be appropriate only when one felt one was taking too much of a performance hit because of the deferred dereferencing. Even here, the language could support notations that would allow the compiler to generate the getstate, lock, and setstate automatically, as well then optimizing the generated code. I suspect that with a little cleverness, these concepts could even have been incorporated into a standard language like C or Pascal. Unfortunately, none of the vendors have chosen to do so, so programmers end up having to work around the limitations of the compilers. Complaining about handles as a means of managing storage because of these problems is a little like complaining about screws as a means of holding pieces of wood together because it is so hard to hammer them in. The real problem is that you don't have the right tool for using them. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
matthews@eleazar.dartmouth.edu (Jim Matthews) (12/30/89)
In article <18300010@ux1.cso.uiuc.edu> hirchert@ux1.cso.uiuc.edu writes: >Many of the problems cited stem simply from the fact that there is no way to >tell the compilers to defer dereferencing of a handle until after a system call >or procedure call has taken place. Others would be eliminated if the standard >mechanism for locating objects (especially procedure arguments) were a handle >and displacement rather than a pointer, so that determination of the actual >location of the object could be deferred. I think this would clutter up code as much as the current workarounds. Instead of saying FillRect(r, black) you would say FillRect(rhandle, roffset, bhandle, boffset); And since much of the time you're dealing with stationary data anyway these extra arguments would often be pure overhead. >Complaining about handles as a means of managing storage because of these >problems is a little like complaining about screws as a means of holding >pieces of wood together because it is so hard to hammer them in. The real >problem is that you don't have the right tool for using them. Perhaps the question is why we should set out to invent new kinds of screwdrivers when nails would do the job as well (and we have decades of experience with hammers). With virtual memory most of the rationale for relocatable blocks disappears. It is backwards compatibility, not the advantages of handles, that keeps Apple from revamping the memory manager to match the new reality. I've been programming the Mac for five years and I've learned how to deal with handles. But I would trade that knowledge for a stationary memory scheme in a second. Jim Matthews Dartmouth Software Development
hirchert@ux1.cso.uiuc.edu (12/30/89)
Jim Matthews (matthews@eleazar.dartmouth.edu) writes: >In article <18300010@ux1.cso.uiuc.edu> hirchert@ux1.cso.uiuc.edu writes: >>Many of the problems cited stem simply from the fact that there is no way to >>tell the compilers to defer dereferencing of a handle until after a system call >>or procedure call has taken place. Others would be eliminated if the standard >>mechanism for locating objects (especially procedure arguments) were a handle >>and displacement rather than a pointer, so that determination of the actual >>location of the object could be deferred. > >I think this would clutter up code as much as the current workarounds. >Instead of saying FillRect(r, black) you would say FillRect(rhandle, >roffset, bhandle, boffset); And since much of the time you're dealing >with stationary data anyway these extra arguments would often be pure >overhead. You've misunderstood the nature of my suggestion. It is the _language_ that should be dealing with these details, not the programmer. Imagine, for example, a language in which a "locator" (the combination of a handle and an offset were a primitive). In such a language, you could create locators and reference the objects the locate with the same simplicity that you can create pointers and reference the objects pointed to in C. The important difference would be that where pointers get messed up when memory is shuffled, the deferred dereferencing in using a locator would allow the compiler to automatically avoid those problems without any use of handle locking. If even the system calls were converted to using locators, then you would still write FillRect(r,black), but r and black would now be locators. (With a slightly different language philosophy, r and black could be the same types as they are now and it would be the language's responsibility to automatically constuct locators for them. The language could still enforce the restriction that the type of data located had to be the same, so only the indirection method was automatically converted.) > >>Complaining about handles as a means of managing storage because of these >>problems is a little like complaining about screws as a means of holding >>pieces of wood together because it is so hard to hammer them in. The real >>problem is that you don't have the right tool for using them. > >Perhaps the question is why we should set out to invent new kinds of >screwdrivers when nails would do the job as well (and we have decades of >experience with hammers). With virtual memory most of the rationale for >relocatable blocks disappears. It is backwards compatibility, not the >advantages of handles, that keeps Apple from revamping the memory >manager to match the new reality. I've been programming the Mac for >five years and I've learned how to deal with handles. But I would >trade that knowledge for a stationary memory scheme in a second. VM eliminates the need for handles only in those cases where there logical static layout for memory (e.g. segmentation of code). If you are doing dynamic storage management of the sort that fragments memory, you still eventually will have to consolidate/compact memory to continue running. The use of handles reduces the cost of this step. The best you can do with VM is delay the time when consolidation/compaction is necessary by increasing the size of the address space. Unfortunately, if you then have to consolidate/ compact anyway, the cost will be proportionately larger and even slower per unit memory (because the "memory" will largely be on disk). Even when VM helps, it has its cost - the swap or page file. I would prefer it if address space of most programs remained small, so I could continue to use most of my hard disk for programs and data rather than allocating large chunks of it to swap space. In other words, I would welcome the availability of VM to eliminate code overlay/segmentation hassles, but better support for the use of handles to manage dynamic data and customization resources still seems highly desirable to me.
tim@hoptoad.uucp (Tim Maroney) (12/31/89)
In article <18054@dartvax.Dartmouth.EDU> matthews@eleazar.dartmouth.edu (Jim Matthews) writes: >With virtual memory most of the rationale for >relocatable blocks disappears. As I've already pointed out, that's not true on the Mac. It would be true on a virtual memory system where the OS could grow an application's memory when it is unable to allocate a block (as the library routine malloc does using the system call sbrk on UNIX systems). However, on the Mac, VM does nothing to prevent fragmented memory problems, because application memory spaces don't grow. >It is backwards compatibility, not the >advantages of handles, that keeps Apple from revamping the memory >manager to match the new reality. I've been programming the Mac for >five years and I've learned how to deal with handles. But I would >trade that knowledge for a stationary memory scheme in a second. I've been programming the Mac that long myself, with the result that I no longer think of handles as a chore. I kind of like them, they don't send me tearing my hair, I rarely even have to devote any conscious thought to them. I don't understand why they are so reviled. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I am of the opinion that my life belongs to the whole community, and as long as I live it is my privilege to do for it whatever I can." -- Shaw
amanda@mermaid.intercon.com (Amanda Walker) (01/03/90)
In article <9438@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > I've been programming the Mac that long myself, with the result that I > no longer think of handles as a chore. I kind of like them, they don't > send me tearing my hair, I rarely even have to devote any conscious > thought to them. I don't understand why they are so reviled. Indeed, I've often been tempted to write a rudimentary version of the Mac memory manager for things like UNIX machines or PCs, simply so that I can have relocatable (and more importantly, *resizable*) blocks of memory without having to do my own memory management & reallocation. Of course, I cut my memory management teeth on Lisp, which also usually has garbage collection, which makes life even nicer... Amanda Walker InterCon Systems Corporation --
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/03/90)
In article <1669@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >Indeed, I've often been tempted to write a rudimentary version of the Mac >memory manager for things like UNIX machines or PCs, simply so that I >can have relocatable (and more importantly, *resizable*) blocks of memory >without having to do my own memory management & reallocation. Go for it! It will take you about 1 minute: consider: typedef char *Ptr, **Handle; Handle UnixNewHandle(size)long size;{ Handle h; h = (Handle) malloc(sizeof(Handle)); *h = (Ptr) malloc(size); return h; } void SetHandleSize(h, newSize)Handle h;long newSize;{ realloc(*h, newsize); } does almost all the work for you. Error handling is left as an exercise. (The above assumes you have a virtual memory system, and a decent implementation of malloc(), so you don't have to worry about fragmentation of the heap.) --- David Phillip Oster -- No, I come from Boston. I just work Arpa: oster@dewey.soe.berkeley.edu -- in cyberspace. Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
amanda@mermaid.intercon.com (Amanda Walker) (01/04/90)
In article <33448@ucbvax.BERKELEY.EDU>, oster@dewey.soe.berkeley.edu (David Phillip Oster) writes: > (The above assumes you have a virtual memory system, and a decent > implementation of malloc(), so you don't have to worry about fragmentation > of the heap.) Well, until recently, I haven't been willing to assume the latter, especially on things like PC's (bleah :-)). Under UNIX it works pretty well. OK, now that David has done the Memory Manager, who wants to do the Resource Manager :-)? Amanda Walker InterCon Systems Corporation --
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/04/90)
In article <1675@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >OK, now that David has done the Memory Manager, who wants to do the Resource >Manager :-)? 1.) If you are using X, it has a component called "resource manager", which, particularly with Motif, will strongly remind you of the Mac and Rez. 2.) Actually, I already have re-implemented the Resource Manager: Address Book Plus uses it for its data files. While I was at it, I removed some of the resource Manager's limits: a.) The Resource Manager supports 2 levels of indicies, a 32-bit type, and a 16-bit id. My object manager supports an arbitrary number of 32-bit indices. (Isn't recursion wonderful.) b.) The resource manager uses 16-bit ints, so it can only support about 2K objects per file. Mine supports > 2^30 objects per file. c.) The R.M. uses linear search to find things, which gets slow as the file gets large. Mine uses binary search. d.) The R.M. tends to garble files that were not closed properly before a crash. Mine uses a back-up list scheme so that you may loose the session, but you won't loose the file. But, this piece of code is one I'm being mercenary about. After all, I write this stuff for a living. Thanks for giving me this chance to brag. Probably, on Unix, the right thing to do is to extend the binary program file with resources. There should be some fairly standard way to do this, since the linker usually puts symbol table info in the file that is not normally read into memory when the file is run. This would keep the whole shebang in one file, Mac style. Finding your binary cheaply at run-time seems like a problem, though.
dee@XAIT.Xerox.COM (Donald Eastlake) (01/06/90)
The funky hardware instruction addressing modes on the 68030 that look
like they are designed to take a handle and an offset should make
possible extremely efficient implementations of language features
designed to defer dereferncing of handles.
--
+1 617-969-9570 Donald E. Eastlake, III
ARPA: dee@XAIT.Xerox.COM usenet: {cbosg,decvax,linus}!cca!dee
AppleLink: D2002 Box N, MIT Branch PO, Cambridge, MA 02139 USA