Re: gc issues

[Jim Blandy]

> or maybe it does, after all.
> 
> when the hypothetical future kernel-threaded Guile is running on a
> real multiprocessor machine, is it guaranteed that the tag in the cell 
> will be either the freecell tag or the target tag?  i.e. is there any
> memory coherence guarantee?  I don't think so, but I don't know alot
> about the subject.

You're correct --- the memory coherence guarantees are sometimes weak
on multiprocessor systems.  Even if you do store your tag word last,
other processors might see that store before the other initializing
stores.

The POSIX threads spec and the Java thread spec both address this
issue by specifying that locking and unlocking mutexes synchronize
cache with the main memory.  So in order to get this right, you really
need to lock the freelist, initialize the cell, and unlock the
freelist.  Then, the GC can lock the freelist, stop the thread to scan
its stack, and unlock the freelist --- I think this would guarantee
that the GC won't see half-initialized cells.

All the processors I know of do, however, ensure that pointer-sized
stores are seen completely, or not at all.  So even if you don't lock
everything properly, other processors may see your stores out of
order, but they won't see corrupted pointers.  Java promises this, so
I assume it's a decent assumption.

See Chapter 17 of the Java Language Specification.  It specifies
exactly what promises a language implementation must make; I take this
as a decent guide to what you can expect from processors, since the
Java folks expressly didn't want to specify something that couldn't be
implemented efficiently --- like total memory coherence, for example.