Some more minor amplifications:
* Again, the intent of Gosling et al was that immutable objects be
threadsafe. (This intent is reflected and propagated in my CPJ
book.) Everyone at Sun I've mentioned problems to over the past few
years considers it a MISTAKE in chapter 17 that this is not
guaranteed. Despite Raymie's valuable comments trying to make the
case that this is a feature, not a bug, I think the consensus is
still that this is a mistake that must be fixed to preserve the
intended semantics of the language. The fact that fixing it would
also preclude nasty problems with object headers etc is a happy
convergence of Java programmers' and JVM developers' interests. On
the other hand, the scope of any such fix should be limited to
preserving intended semantics, and not opening things up to further
unanticipated abuse.
* It comes as no surprise that compilers and runtimes for processors
with extremely loose ordering and visibility guarantees require a
lot more sophistication than those that don't. This is exactly the
tradeoff (also known as the compiler-writer's full-time employment
act :-) made by people who design these processors. It may be a
while before a Merced can run Java as fast as a Pentium or Sparc.
But it does seem possible: By default insert all potentially
necessary barriers, and then optimize most of them away via
points-to, escape, and related analyses. As has been recently
demonstrated (by, among others, V.C. Sreedhar and IBM colleagues in
their upcoming OOPSLA paper), many Java programs are mostly
single-threaded, and contain a lot of code that can be statically
determined as such. In a language where safety is a primary goal, it
seems wiser all around for compilers to remove unnecessary
synchronization and barriers than for programmers to do
so. (Premature optimization being the root of all evil...)
-- Doug Lea, Computer Science Department, SUNY Oswego, Oswego, NY 13126 USA dl@cs.oswego.edu 315-341-2688 FAX:315-341-5424 http://gee.cs.oswego.edu/ ------------------------------- This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.To send a message to the list, email JavaMemoryModel@cs.umd.edu To send a request to the list, email majordomo@cs.umd.edu and put your request in the body of the message (use the request "help" for help). For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:13 EDT