Bill wrote:
> If we made final be different than "volatile final", then on some
> architectures (e.g., DEC Alpha) referencing a final variable would be
> more efficient than accessing a final volatile variable (a memory
> barrier would be required on the Alpha to access a final volatile
> variable).
> ...
OK, thanks. I think I get it.
> For example, if you had a final private variable, and all of the
> methods of the class were synchronized, then you could be guaranteed
> that you don't have a data race on it and you could mark safely the
> variable as non-volatile.
Arguing which way defaults should go is intrinsically religious.
Still, the programmer's story seems much more desirable with the
default of final giving initialization safety: If you bother to claim
a field final, then both the compiler and run-time will help as much
as they can to make good on semantic guarantees. But if you are sure
that you've synchronized all paths potentially involving multiple
threads, and you want to improve performance, then just drop the
`final' keyword. Both the compiler and JVM will then be less helpful
in guaranteeing semantic safety properties, but may be able to speed
things up.
-- 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:17 EDT