[concurrency-interest] DCL using Fence Intrinsics

Stephan Diestelhorst stephan.diestelhorst at gmail.com
Sat Mar 14 05:54:39 EDT 2015

On 14 Mar 2015 05:28, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:
> The reason I mentioned things like Alpha not being practical for final
field semantics is the following.  If the JVM (interpreter or compiler)
sees a read of some heap object that contains final fields followed by a
read of some field on that object, how does it guarantee that this data
dependence is enforced? It can't allow the read to observe initial/"zero"
state of those final fields due to this reordering.  So, it would have to
insert LoadLoad fence in between.  On Alpha, that's a cpu fence.  So now
we're talking about a cpu level fence on all such reads - it's impractical.

I fail to see why adding such a fence is "impractical".  If it is
performance, then such a fence could be built equally fast as the current
dependency-observing architectures.  If it is instruction bloat, annotate
the second load directly.  The only impracticalities IMHO are if (1) the
compiler has a hard time figuring out if it needs a fence or not, and (2)
if these fences would constitute a large fraction of all accesses.

AFAICS, neither applies here.  So please stop assuming things about the
HW.  IIRC, some IBM architecture did not honour cancelling out
data-dependencies; not relevant here, but it shows that people are looking
for weakened load load ordering.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150314/9c3b30d2/attachment.html>

More information about the Concurrency-interest mailing list