In the spirit of offering introductions, I'm Sam Midkiff, a Research Staff
Member at IBM Watson Research. I do work on Java for technical computing (see
www.research.ibm.com/ninja, and www.alphaworks.ibm.com/tech/ninja for details),
and the optimization of explicitly parallel programs. I am a co-author
(although near or at the end of the list) on the paper Doug mentioned allowing
synchronizations to be removed.
We have an algorithm for doing the analysis that David Bacon describes, and it
is very simple compared to performing escape analysis. So, I would have to say
that the additional compiler complexity and run-time, although not zero, would
be small. What has not been done are experiments to show the benefit of the
analysis in removing the synchronization part of locking operation. And,
without these numbers the fact that our algorithm is fast may well be
irrelevant.
Sam
"David F. Bacon" <dfb@watson.ibm.com> on 06/29/99 12:06:15 PM
Please respond to javaMemoryModel@cs.umd.edu
To: javaMemoryModel@cs.umd.edu
cc: (bcc: Sam Midkiff/Watson/IBM)
Subject: JavaMemoryModel: Removal of Synchronization on Weakly Ordered Machines
Doug Lea writes:
> 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.
Note however that the semantics of an unlock operation in the general
case disallow removing the synchronization associated with the unlock,
even if the object is thread-local.
At an unlock *all* writes must be made globally visible, so to optimize
away the synchronization the compiler must prove not only that the
object is thread local, but also that there have been no intervening
writes to shared variables (accessible without locking the object in
question) since the last unlock. In the absence of such proof, you can
eliminate the mutual exclusion operations but not the synchronization
operation(s).
The result is both a reduction in the number of synchronizations that
can be eliminated and an increase in compile complexity and run time.
david
-------------------------------
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 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