AARCH64: 8139041: Redundant DMB instructions (CORRECTED )

Christian Thalinger christian.thalinger at oracle.com
Fri Oct 9 18:47:03 UTC 2015


> On Oct 9, 2015, at 5:37 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> Hi,
> 
> On 10/09/2015 03:59 PM, Roland Westrelin wrote:
> 
>>> There is a much simpler way: remove adjacent barriers in
>>> MacroAssembler.  Thanks to the way that the AArch64 ISA is designed,
>>> barriers can be merged simply by ORing them together.  Of course, this
>>> technique works for C1 and C2, and it adds essentially nothing to the
>>> compilation time.
>>> 
>>> http://cr.openjdk.java.net/~aph/8139041/
>>> 
>>> One thing which may be controversial is that I've added a field to
>>> CodeBuffer to keep track of barriers and labels.  I had to do this
>>> because when we're compiling there is (AFAICS) essentially nowhere
>>> else to keep the state.

I don’t think it matters to have an additional field in CodeBuffer.  It’s a temporary data structure and we use much more memory for graphs.

I would even go that far and questioning putting it under #ifdef AARCH64.

>> 
>> Isn’t your new field a bit like:
>> 
>>  address       insts_mark() const       { return _insts.mark();       }
>>  void      set_insts_mark()             {        _insts.set_mark();   }
>>  void    clear_insts_mark()             {        _insts.clear_mark(); }
>> 
>> which is used in very few locations AFAIK. Do you think you could reuse that one?
> 
> Yes, that's what it's based on.  I guess that is possible in theory,
> but AbstractAssembler::InstructionMark() looks like this:
> 
>    InstructionMark(AbstractAssembler* assm) : _assm(assm) {
>      assert(assm->inst_mark() == NULL, "overlapping instructions");
>      _assm->set_inst_mark();
>    }
> 
> so any instruction which leaves the mark set will trigger an assertion
> failure the next time InstructionMark is used.  I suppose that in
> extremis I could make every instruction which is not a memory barrier
> clear the mark, but ewww.  :(
> 
> I suppose I could define an AArch64-specific version of
> InstructionMark which does not have this assert, but I'm not sure I
> like that either.
> 
> [An aside: we use InstructionMark unnecessarily in AArch64, and it's
> on my list of things to remove, but that's for another day.]
> 
> Thanks for looking at this,
> 
> Andrew.



More information about the hotspot-compiler-dev mailing list