[llvm-dev] Managed Languages BOF @ Dev Meeting
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 19 11:53:46 PDT 2015
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.
More information about the llvm-dev