fixed address objects (was Calling straight C code)

Tim Rowledge rowledge at interval.com
Wed Mar 10 06:09:47 UTC 1999


Wow - so much feedback. Obviously this has triggered our collective
braincells in interesting ways!

On Tue 09 Mar, Jan Bottorff wrote:
> At 12:17 PM 3/9/99 -0800, Tim Rowledge wrote:
> >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.
> 
> ((JanB brain) at:#uglyExternalObjects) dumpOn:emailer.
> 
> Hmmm. I'm a bit puzzled by how this really would work. The Squeak object
> format assumes there is a header in the bytes just before the object data
> (correct me if this is wrong).
Correct - header is one to three words depending on size, class etc.

> If you want to create say a bitmap that's
> actually a real live frame buffer you will not be able to put the header
> where Squeak expects it to be. For objects malloced, you can shift things
> along in memory, although this may then destroy certain alignment
> expectations. For example, if you memory map a file, and want it to show up
> as a ByteArray, there is simply no place to put the header.
Urk. The memory mapping is an interesting one. For 'normal' cases, my code
mallocs (size + 3words) and makes a three word header:-
	next link
	locked flag
	actual oop
followed of course by the object header and data. Why have the oop in
the link structure? Well it seemed neater, and allows somechance to have
the object somewhere else than immediately inline. Might be useful oneday.
It sounds like it might be useful for this alignement issue in fact -
malloc some extra space, make the link structure and work out the right oop
in order to get the desired alignment.
> 
> [snip clever stuff with magic incantations]

> The problem of doing GC on arbitrary binary structures is sticky too. You
> could have some sort of GC map to describe where references in the binary
> structure may be. A not insurmountable, but still sticky strategy would be
> to just follow everything that might be a pointer, and somehow determine if
> its really is a reference. In the past, I've used both exception trapping,
> and a sparse address space tree to decide valid references from binary
> garbage (things had to work in a sparse memory environment with ROM and
> RAM). Lot's of people (some from PARC) have looked into GC in assorted
> languages very deeply. I personally think this is all really ugly compared
> to the nice clean run-time/memory environment in Smalltalk where you know
> where the references are.
No arguments from me on that one. Smalltalk gc is quite tricky enough for
me. How those poor deluded people doing java/c++ gc stuff stay sane beats
me.... hmm, maybe that explains it....


tim

-- 
Why Dogs Hate WIn95:-19)  Fetch command not available on all platforms.
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