🚀 go-pugleaf

In article <446df2$3ae@wolfe.wimsey.com>,
William Robert Night <wnight@vanbc.wimsey.com> wrote:
 >Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
 >: In article <nevin-2309950419270001@mac-nevin.cs.arizona.edu>,
 >: Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
 >
 >: >No.  Unlike you, they had practical problems to solve.  You stating that
 >: >it wasn't a problem doesn't make it so.  You *still* haven't posted a
 >: >solution to what to do if the heap is so fragmented that you can't satisfy
 >: >an allocation request, other than quitting the app or buying more
 >: >hardware.
 >
 >: You can block the process until the request can be satisfied. You can
 >: raise some sort of exception and let the process handle it in whatever
 >: way it wants (including the option to try to restart the request).
 >
 >And this is going to work really well on a single-tasking system... What 
 >if the process itself is what has (through normal usage) fragmented the 
 >memory? Block it until the cows come home?
 >
 >: In any case, you have saved space by not bloating your code with silly
 >: wrappers around an overzealous global heap management scheme.
 >
 >You still haven't explained what you'd have the OS do if all the memory 
 >was available to meet the request, but was fragmented... Just sit there 
 >and wait, or should you let the process move its own data around system 
 >memory? Nah, let the OS do it in a reliable and documented way.

Ok, but that only delays the problem of _really_ running out of memory?
You have put all your trust in the OS; now the OS says that there truly
is no more space. What do you do? You still have to deal with that.

If you write code to deal with the case of really running out of memory,
you have covered the case when an allocation request can't be satisified
because the space is fragmented, since you can deal with both contingencies
in essentially the same ways.

So, to summarize:  heap management with compaction forces the programmer
into a circus act of juggling handles:  locking and unlocking, extra
dereferencing and assuming that cooperative threading is in effect---all
for the benefit of squeezing some additional bytes out of the heap.  You
still need to handle the case of _really_ running out of memory, as you
would with any ordinary heap allocator, thus nowhere in an application
is complexity _reduced_.  I don't dispute that compaction works; I'm
claiming that it's not worthwhile because it only delays a problem at
the expense of complicating application code and preventing it from
being pre-emptively multitaskable.  There is a small benefit, but it's
outweighed by the costs of making it work.
-- 
PGP key id is 0xD3C7995D.
Molybdenum 95! Got your ounce of fission byproduct yet?