Re: gc issues

[Michael Livshin]

Jim Blandy <address@hidden> writes:

> 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.
>
> [...]
> 
> 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.

aha.  well, this is good enough for the discussed situation, then.
I'm not very worried about possible store order changes.

I mean, what's so catastrophic about getting the tag initialized
before the data?  the code for Guile's primitive types should be
prepared to find a freecell link (or SCM_EOL) in the data -- well,
it's not prepared now, but it's doable.  that would leave
`scm_make_smob' as the only constructor that would need to do locking.
this is probably OK.

on the other paw, all through this discussion it is assumed that
making NEWCELL incur the cost of a function call would be very very
bad.  but in POSIX-threaded Guile, NEWCELL will have at least to call
`getspecific' to get the freelist, right?  I wonder if we should stop
worrying at this point ;).

> 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.

thanks!

(I hope Subversion is coming along well).

-- 
Who's afraid of the garbage collector?