David Holmes wrote:
> > Let me reverse your question and ask you for an example where
> > a compiler might try to fuse locks and accidently blow liveness. We'll
> > start by ruling out all calls in the inbetween area; if the compiler can't
> > inline the call away all bets are off. Also, nix on unbounded loops or loops
> > where we can't determine the trip count is short.
>
> Well if you remove all the interesting cases ... all that's left are the
> trivial examples you motivated above. ;-) If the JMM spec guarantees that
> the interesting cases (such as the with the r/w lock) can not happen then
> I'm probably happy. Though I still have concerns about how these
> transformations will be made visible to the programmer for debugging,
> profiling and manual optimisations.
Ok, maybe I can summarize as "HotSpot intends to never remove liveness,
if you had it already", so if the Spec says "you can't blow liveness" I'm happy.
The analysis nessecary to discover "not blowing liveness" basically limits me
to coarsening locks in trivial cases - which actually covers all the cases I'm
really interested in.
Cliff
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT