🚀 go-pugleaf

In article <444tqdINNsqs@keats.ugrad.cs.ubc.ca>, c2a192@ugrad.cs.ubc.ca
(Kazimir Kylheku) wrote:

> I'm not saying that the compaction never happens or that it doesn't
> squeeze out extra memory. I'm just saying that it's not worth the trouble.

Then later on, In article <44504jINN43m@keats.ugrad.cs.ubc.ca>,
c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) wrote:

> My solution was still O(n^2), but well over a 100 times faster. All I
> did was look for the 128 highest strings in each pass, keeping their
> (16 bit) addresses in a page of 256 bytes.

I thought you said that compaction is not worth the trouble?  There isn't
any practical difference between heap compaction and BASIC string garbage
collection.  Macintosh heap compaction is simply a generalization of
string garbage collection, and needed for the same reasons (until memory
isn't a scarce resource).  Both are dealing with variable-length objects. 
Both have the pointers stored in well-known places.  Both don't have to
worry about aliasing or duplication of handles.  Etc., etc.

Why didn't you implement one of your other "solutions" instead?  Here is a
refresher, in case you forgot them:

> I believe that if
> things get so bad that the heap has to be compacted, you are getting close
> to running out of memory. Something is going to have to quit.

Why didn't you app just quit, instead of bothering with that string region
compaction?

Or how about:

> My solution is to block allocation requests that can't be satisifed, or
> raise some sort of exception when an allocation request fails so that
> the process can take action, such as inform the user that memory is
> low and then restart the request.

Again, why didn't you implement it this way?

You really ought to practice what you preach.

> Quite a bit less mature than the people working at Apple
> or Microsoft.

You certainly are; no arguments on that account here.