> Martin wrote:
>
> > The way that the GC thread does this
> > is to stop all the other threads in some way either by
> forcing them to
> > cooperate or
> > simply by getting the OS to suspend them forcibly.
>
> While conceivable, I have a very hard time believing that this would
> ever be a winning strategy for cache maintenance (Sylvia's
> use case). A
> lot of research and development in GC is devoted to avoiding
> the need to
> do this.
>
I agree, though for a slightly different reason. Suspend/resume
is extremely dangerous and error prone, if you let the caller
do anything of interest between suspend and resume. In fact, it's
unclear whether there is any way to use them correctly, since you
may run into system or library locks that the target happened to hold.
If you really needed to do this (and I'm not ready to conclude that),
I think it would be far cleaner to do this with a new
suspend-then-force-acquire-then-resume
primitive that doesn't allow the client to make intervening calls. As
Bill points out, reasoning about this would still be hard.
I'm less convinced that the use of suspend/resume within a GC needs to
be much of a problem, unless you need a very fine-grain incremental collector.
But it's allowed to know a lot more about run-time internals than user
code. I think this is a different situation, and (probably unlike the GC
case) the alternative of using volatiles should not be terribly expensive.
Hans
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT