[aarch64-port-dev ] RFR: Large code cache

Andrew Haley aph at redhat.com
Tue Dec 9 11:27:50 UTC 2014


On 09/12/14 11:00, Andrew Dinn wrote:
> On 08/12/14 15:51, Andrew Haley wrote:
>> Comments welcome.
> 
> I have ony seen one thing I don't follow so far (just eyeballing the
> code at present). In src/cpu/aarch64/vm/nativeInst_aarch64.cpp you have
> 
> void NativeCall::set_destination_mt_safe(address dest, bool assert_lock) {
>   if (...) {  // not via trampoline
>     . . .
>   } else {    // is via trampoline
>     . . .
>     nativeCallTrampolineStub_at(trampoline_stub_addr)
>         ->set_destination(dest);
> 
>     // And patch the call to point to the trampoline
>     set_destination(trampoline_stub_addr);
>   }
>   ICache::invalidate_range(addr_call, instruction_size);
> }
> 
> The first set_destination call does this:
> 
> void NativeCallTrampolineStub::set_destination(address new_destination) {
>   set_ptr_at(data_offset, new_destination);
>   OrderAccess::release();
> }
> 
> Is that really all that is needed? i.e. release works with __clear_cache
> to order this hw thread's data cache changes wrt other hw thread's
> instruction caches? 

invalidate_range() flushes its caches as the first thing it does.  The
release() prevents the store of the destination from being moved after
the change to the code is visible.  So, there are two data fences here:

  store pointer; release; patch the call; full barrier; icache flush

> Or is there a need to call invalidate_range for the first write?

The first write does not touch any instructions, so there's no point.

Andrew.



More information about the aarch64-port-dev mailing list