[llvm-dev] Managed Languages BOF @ Dev Meeting

[Sanjoy Das via llvm-dev]

David Chisnall wrote:
 > Yes, that would probably be the trickiest part of this.  Note that
 > this is also somewhat language dependent.  If the source language does
 > not define ordering of memory operations, then reordering them would
 > be fine.  I’m definitely not sufficiently familiar with the Java spec
 > to say exactly when this would or wouldn’t be permitted - I think Java
 > is a lot stricter than C/C++ with respect to evaluation order.  We’d
 > probably need some metadata on each basic block, along with the unwind
 > target, to specify what the requirements are.  Alternatively, we could
 > use the atomic load and store instructions with a new ordering that
 > would guarantee ordering within a single thread but not actually
 > guarantee atomicity.

This is what the spec says: "The Java programming language guarantees
that the operands of operators appear to be evaluated in a specific
evaluation order, namely, from left to right."

Apart from re-ordering, we need to be careful about removing
faulting_load instructions too -- removing an unused load instruction
does not mean we can remove the implied null check.

Joachim Durchholz wrote:
 > Actually Java is relatively relaxed in general, but some language
 > constructs impose strict guarantees.

 > See https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
 > for the programmer perspective, and http://gee.cs.oswego.edu/dl/jmm
 > /cookbook.html for the implementer perspective.

The multi-threaded memory model does allow "re-ordering", but
semantically it is phrased in terms of which read sees which write,
not re-ordering memory operations.

-- Sanjoy