Am 04.03.2016 um 17:27 schrieb David P Grove:
> 
> 
> Andreas Zwinkau <zwin...@kit.edu> wrote on 03/04/2016 07:02:30 AM:
> 
>> From: Andreas Zwinkau <zwin...@kit.edu>
>> To: x10-users@lists.sourceforge.net
>> Date: 03/04/2016 07:03 AM
>> Subject: [X10-users] Fences Java implementation
>>
>> The x10.util.concurrent.Fences implementation looks reasonable for C++,
>> but the Java implementation seems weird to me.
>>
>> For example, loadLoadBarrier is implemented via two volatile reads. Why
>> *two*? I could ask more questions ...
>>
>> The code was added by David Grove in 2009 it seems:
>> https://github.com/x10-lang/x10/commit/
>> f4f5420ce476f2538f358509ad13ef52b8c2c4c1
>>
>> Any idea where that came from? Any sources? Any reasons why it is the
>> way it is?
> 
> Hi Andreas,
> 
>       Best as I can remember, the Java code that is there was based on
> discussion being had in 2009 about how to get memory fences given the
> definition of the Java memory model and java.util.concurrent as it existed
> at the time.
> 
> --dave

I compared it with the JMM Cookbook [0] and it follows it very directly.
For example, "volatile load then volatile store means loadStore barrier".

The problem is the JMM considers volatile variables separately, so the
JVM can optimize volatiles. If the JVM figures out the volatile
variables in FencesUtils.java are never accessed concurrently, then they
can be optimized away. I made a toy example and this became
loadLoadBarrier assembly:

  # {method} 'loadLoadBarrier' '()V' in 'FencesUtils'
  #           [sp+0x20]  (sp of caller)
  0x00007fa3f905f5c0: sub    $0x18,%rsp
  0x00007fa3f905f5c7: mov    %rbp,0x10(%rsp)    ;*synchronization entry
                                                ; -
FencesUtils::loadLoadBarrier@-1 (line 38)
  0x00007fa3f905f5cc: mov    $0x7acd4eee8,%r10  ;   {oop(a
'java/lang/Class' = 'FencesUtils')}
  0x00007fa3f905f5d6: mov    0x58(%r10),%r8d
  0x00007fa3f905f5da: mov    %r8d,0x60(%r10)    ;*getstatic v1
                                                ; -
FencesUtils::loadLoadBarrier@0 (line 38)
  0x00007fa3f905f5de: mov    0x5c(%r10),%r11d
  0x00007fa3f905f5e2: mov    %r11d,0x64(%r10)   ;*getstatic v2
                                                ; -
FencesUtils::loadLoadBarrier@6 (line 39)
  0x00007fa3f905f5e6: add    $0x10,%rsp
  0x00007fa3f905f5ea: pop    %rbp
  0x00007fa3f905f5eb: test   %eax,0xc967a0f(%rip)        #
0x00007fa4059c7000
                                                ;   {poll_return}
  0x00007fa3f905f5f1: retq

No synchronization instruction. The other three barriers contained a
"lock addl" instruction.

I think this sometimes might work, but not reliably. Afaik there is no
way to correctly implement FencesUtils.java. This implies
x10.util.concurrent.Fences cannot be provided with the Java backend.

[0] http://gee.cs.oswego.edu/dl/jmm/cookbook.html
-- 
Andreas Zwinkau

 KIT  IPD Snelting
 Web: http://pp.ipd.kit.edu/personhp/andreas_zwinkau.php

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
X10-users mailing list
X10-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/x10-users

Reply via email to