Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!hirchert
From: hirchert@ux1.cso.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Handles and Virtual Memory
Message-ID: <18300011@ux1.cso.uiuc.edu>
Date: 30 Dec 89 01:38:35 GMT
References: <9415@hoptoad.uucp>
Lines: 66
Nf-ID: #R:hoptoad.uucp:9415:ux1.cso.uiuc.edu:18300011:000:4051
Nf-From: ux1.cso.uiuc.edu!hirchert    Dec 29 16:42:00 1989


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.