JavaMemoryModel: Forwarded email from Ras Bodik on speculative writes

From: Bill Pugh (
Date: Fri May 28 2004 - 15:00:05 EDT

An interesting question.

> The current JMM spec implies that x=1 must not be observed
> if the loop doesn't terminate (it has implied this
> for a long time; this isn't a recent change). And almost
> everyone in the discussion is absolutely convinced that this is
> the right answer.

I am not a JMM expert, but I side with the majority. 

  In fact, it seems clear that x=1 should not be observed prior to the
  even if the loop _does_ terminate (because the loop may be a
  synchronization).  But you guys know this better than I do.

> However, there is some question as to whether or not
> there might be any compilers that would violate this.

In principle, there might be a compiler that violates this
restriction.  If
  several conditions are met, what you suggested is a legal

        Condition 1: As far as I can tell, in any code that's
guaranteed to
  run only in a single-threaded environment (which some compiler may
  moving x:=1 prior to the loop is semantically harmless. 


        Condition 2: This "code motion" is semantics preserving only if
  compiler can prove that x:=1 doesn't raise an exception, such a page
  because otherwise the optimized program may raise an exception when the
  original program wouldn't.  If the compiler cannot prove this, it may
  able to delay such an exception to the original point of x:=1 (various
  processors proposed such instructions.)

To put Cliff's example into this context, his very nice example assumes
  multiple threads.

> Does anyone know if any compiler analysis or transformation
> might make this transformation? For example, if an analysis
> assumed "the only way to exit this loop is to take this
> branch, so this branch must be taken in all executions",
> then it might allow such a transformation.

I can think of one optimization that may perform this powerful code
  Region Scheduling by Gupta and Soffa.   The "region" here is a program
  dependence graph region; the regions before and after the loop are
  equivalent, there are no data dependences, and so x:=1 may be
movable.  Not
sure though, if the move across loops.

On an "inverse" theme, if you are concerned about moving x:=1 from
  the to after the loop, then partial dead code elimination is an
  that may perform this code motion, which may also be illegal in a
  multithreaded environment.

I don't know (personally) of any compiler that implements either of 
  two transformations so I don't know whether and how they ensure
  for multi-threaded code.

To conclude, I don't know of any compiler that does what you asked
about but
  I wouldn't be surprised if there was one.


JavaMemoryModel mailing list -

This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:08 EDT