> 1) Garbage collections are scheduled within Smalltalk and are not
> initiated during the execution of any individual primitive. Object
> addresses do not move around during the execution of a primitive.

Wrong! If you allocate an object the allocator may have to do a garbage
collection in order to clean up unused space (hey, where do you think a GC
should get triggered if not in allocation?!). Also, for the sake of speed
the VM does a GC every N allocations (where N is a number that can be set
from the ST side - see SystemDictionary>>setGCParameters). Since allocations
can (and *do*) trigger GCs one has to make sure that all pointers to ST
objects are either remapped (using #pushRemappableOop: and
#popRemappableOop) or that they are reloaded after allocation (and don't
forget to check the callers of any method possibly allocating objects!).

> 2) Outside of a primitive, or between calls to a primitive, objects get
> moved around freely by the garbage collector unless they are registered
> as external objects with SystemDictionary>>registerExternalObject:

Nope. SystemDictionary>>registerExternalObject returns an integer that you
may pass to some C function so the C function can use
#signalSemaphoreWithIndex: - e.g., the external 'objects' are really
intended to be semaphores. Other than this there are no further implications
to object persistance - the registered semaphore *will* be moved around it's
just that you don't see it since you're never directly using it.

> 3) A primitive can't maintain a static reference to a Smalltalk object
> unless the object is registered as external, otherwise horrible things
> happen randomly.

Nope. Registering the object as 'external' doesn't mean it don't get moved
around.

> 4) If you try to allocate an object within a primitive and the allocation
> fails, the garbage collector cannot help you out, and your primitive
> needs to fail in some graceful manner.

Nope. Since, the allocator will GC you should never get into problems as
long as you are allocating sufficiently small chunks. Everything that is a
large object (where the meaning of 'large' certainly depends) should be
allocated from Smalltalk because failure to allocate will be signalled
through the low space semaphore. As an example, all the Balloon (2D and 3D)
structures are allocated by Smalltalk code (since they can get quite large).
If the primitive doesn't have enough space to work with it simply fails and
signals the reason back to the ST side - which in turn is aware of this and
reallocates the buffer if necessary.

  Andreas