[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Synchronisation and Optimisation
Hi Stephen,
Before pushing the issue further, you should read some more about the problems
in the current JVM specifications, in regards to threads and synchronization.
The current specification is not as clean as you might have expected...
Here are two links for you:
http://jsp.java.sun.com/javaone/javaone2000/pdfs/TS-754.pdf
http://www.cs.umd.edu/~pugh/java/memoryModel/
Have fun!
Etienne
Stephen Cheng wrote:
> Hello Gurus,
>
> I have been reading Java VM Specification for its specification of
> synchronisation and variable updates. I have also been going through the
> Soot code, and when the two are considered together they raise some rather
> interesting questions about the current Soot's treatment of monitorenter and
> monitorexit bytecodes.
>
> Lets for the moment assume that a Java application correctly synchronises
> all variables acess across multiple thread. It is critical that the
> optimisation algorithms to produce an optimised version that provides
> correctly synchronised access to all shared variables, and exhibits the
> "same" behaviour. I would however argue that it is not necessary for the
> optimisation algorithms to produce a "correct" optimised version if the
> original program does not correctly synchronise all shared variable. Under
> the Java VM specification, such programs (even unoptimised) would never not
> have a deterministic behaviour, and they would behave differently under
> different VMs.
>
> The Java VM Specifications 2nd Edition (Chapter 8.6, page 403) specifies
> that "Less formally: a lock operation behaves as if it flushes all variables
> from the thread's working memory after which the thread must either assign
> them itself or load copies from the main memory". This has interesting
> implications: other threads may have changed the variables in the working
> memory. If the subsequent Jimple units refer to the same underlying
> variable, the value may have changed, i.e., they can not possibly refer to
> the same SSA target.
>
> When Soot translates from bytecode to Jimple, monitorenter and monitorexit
> bytecodes are respectively translated to Jimple EnterMonitorStmt and
> ExitMonitorStmt. Soot does not create additional Jimple assign statements to
> "flush" the variables. In other words the algorithms built on Jimple must
> specifically and independentally take account of the effects of
> ExitMonitorStmt and EnterMonitorStmt, since Jimple is no longer strict-SSA.
>
> I might have got these all wrong, as I am still new to soot. I would like to
> know:
> 1. Does Soot currently adequately take account of synchronisation?
> 2. Which of the algorithms are correct w.r.t. to synchronisation?
>
> There is another related issue: volatile variables. But I will leave that to
> a seperate post.
>
> Regards,
> Stephen
>
>
--
Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/