🚀 go-pugleaf

In article <4444pkINNm49@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) 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.

The heap is fragmented.  There is no more space.  What the hell are you
going to wait for, Pinhead?  Someone to buy you another disk drive or more
RAM and hot swap it in while you are blocked?

> 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).

In practical terms, people don't handle this case without system or
library support, as it adds far too much complexity to the code.  If the
heap is fragmented, you have three choices:  do nothing, compact the heap,
or find more space.  Saying that it is the application's problem, and not
the system's problem, doesn't make the problem go away.

> In any case, you have saved space by not bloating your code with silly
> wrappers around an overzealous global heap management scheme.

Then you bloat your code trying to find more space, or doing explicit heap
compaction.  Or you do what most programmers do, decide that the
complexity of the problem isn't worth handling; the users always manage to
cope no matter how badly they program.

I'll ask you again:  what would you, as an applications programmer, do
when your heap is so fragmented that you cannot get a contiguous block of
memory that you need?  This situation can happen on almost any allocation
request, so your solution had better be a general one.  And no coping out
by saying that it isn't your problem or that you'll abort and let the user
get stuck with dealing with it.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799