[concurrency-interest] DCL using Fence Intrinsics

Vitaly Davidovich vitalyd at gmail.com
Sat Mar 14 01:05:59 EDT 2015


No disagreement with your first paragraph.  Ultimately it's up to the
authors of code to decide if and where they want to go off the beaten path.

Data dependence is pointer dereference and arithmetic.  In java, this
really means loading a reference to a heap object (base address) and then
accessing its fields (base address + offset_to_field, i.e. pointer
arithmetic).

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.  The reason this is tractable  in, say, C (e.g. linux kernel
supports alpha) land is because there isn't a language construct/notion of
final fields.

'a' and 'b' are independent, so yes, there's no data dependence as far as
compiler or cpu is concerned.  My attempt to avoid back to back loadFence
calls when exiting the loop was a thought experiment as to whether it still
works with that exact code structure that I gave; I stated my reasoning,
but admit it's brittle.

sent from my phone
On Mar 14, 2015 12:37 AM, "Justin Sampson" <jsampson at guidewire.com> wrote:

> Vitaly wrote:
>
> > So yes, theoretically you always want to put a loadFence there
> > (assuming that we have only the existing fence intrinsics), but I
> > don't think it's practically (now or in the future) necessary.
>
> As a mere mortal trying to write reliable, portable code without
> knowing the details of every processor that Oracle is planning to
> support in HotSpot, "theoretically" is pretty important to me.
>
> That said, what actually counts as a dependent load? Is it purely a
> matter of dereferencing pointers? That works for final field
> semantics, since they are carefully defined in the JMM in terms of
> reachability (i.e. kind of like happens-before but not transitive
> with other happens-before edges). So that covers Vikas's Code1 vs.
> Code4, as long as all he cares about is anything reachable from that
> specific object. But in Vikas's Code2/Code3, are 'a' and 'b'
> actually "dependent" in any way? Neither one is a pointer, so
> there's no question of reachability. The processor doesn't know of
> any relationship between them. So surely we do need the load fence
> both inside the loop and after it, right? Regardless of instruction
> reordering, don't we have to worry about a variety of cache effects
> as well?
>
> Cheers,
> Justin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150314/f6d9655b/attachment.html>


More information about the Concurrency-interest mailing list