On Wed, 2003-10-29 at 21:40, Sylvia Else wrote:
> It would appear that a program that
> uses volatiles will incur extra costs in this architecture.
There is always some cost of using volatiles (otherwise we wouldn't
bother distinguishing them). Some of the cost is lost optimization
opportunities, and some is CPU/memory coordination. Which of these is
the larger cost, and just how big that cost is, varies across both JVMs
and hardware. Finding ways to selectively use volatiles, locks, and/or
atomics in concurrent data structures to balance cost vs benefit can be
challenging, but that's what makes programming so much fun :-)
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.
-Doug
-------------------------------
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