fixed address objects (was Calling straight C code)

Tim Rowledge rowledge at interval.com
Tue Mar 9 20:17:18 UTC 1999


A couple of weeks ago there were some questions about being able to handle
objects that do not move, for things like bitmap buffers etc. I said I had some
code that could do just that and that I would look it out and post it.

Weeeee-ell.... it turns out it is a bit more problematic than simply having to
search about a gazillion places for the old files. Like we're surprised, eh?

Ok, this is how it (should) works:-
a) add a prim that calls a modified allocate routine - instead of grabbing
memory in the squeak space it calls 'platMallocChunk' which is intended to be a
wrapper for the platform's equivalent of 'malloc'.
b) add a linked list and handling routines to hold onto these external objects
c) add a bit to ObjectMemory>sweepPhase that runs through the linked list and
checks to see if each object has been marked - if not, it removes it from the
list and calls 'platFree' to free the chunk of memory.

Obviously there are some minor details additional to this simple explanation,
but nothing devious. It works really rather well and causes minimal disturbance
to the GC code.

Except. Windows, which it turns out seems to be the only system that normally
returns memory chunks with addresses _lower_ than that of the squeak memory
space. Theses chunks are considered 'old' by the GC marking code and so appear
to be unwanted after a GC and the sweepPhase code frees them. Ka-Boom!
Now, it ought to still work if we add further checks to various places (ie
almost anywhere that compares an oop to youngStart) to pretend that fixed
address objects are young rather than old. I've obviously missed somewhere in
my playing around since I still get occasional blowups on W95. Mac, Acorn and
the unix boxes I have tried it on all seem ok. The extra checks would obviously
be a small performance hit, and ought to be in some form of macro to keep them
out of platforms that don't need them.

A _much_ better solution would be to find some way to convince Windows to
return memory chunks with higher addresses. Does anyone know of a practical way
to do that? In the older code, someone had solved the improper freeing problem
by setting the lock flag for each chunk, and so it made a fairly drastic memory
leak - but it didn't blow up. :-)

I've pretty much run out of time for this particular problem, unless somebody
knows a simple way to fudge Windows. The code so far is on my website as
sq23FixedObjects.cs in http://sumeru.stanford.edu/tim/pooters/SqFiles/deltas/

Another route to getting much of the functionality that this provides might be
a decent memory proxy setup, perhaps using the weak pointers stuff to free it.
Anybody done that?

tim

-- 
SET DEVICE=EXXON to screw up your environment.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>





More information about the Squeak-dev mailing list