[concurrency-interest] DCL using Fence Intrinsics
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...
More information about the Concurrency-interest