Closed Bug 1480587 Opened Last year Closed Last year

add atomic operation support for aarch64 windows


(Core :: JavaScript Engine: JIT, enhancement, P2)




Tracking Status
firefox63 --- fixed


(Reporter: froydnj, Assigned: froydnj)


(Blocks 1 open bug)



(1 file)

This could be as simple as defining a case for _M_ARM64 to include AtomicOperations-feeling-lucky.h, but it would be splendid if we had real atomic op support.
Yeah, I keep meaning to write the code that jit-generates known-good known-appropriate atomics for all our jit-supporting architectures, but other projects keep getting in the way...
Tell me if I am wrong, but this feature should not block Sean form adding the Arm64 IonMonkey backend, as long as SharedArrayBuffer are behind a flag[1] ? Or do we have any other use of Atomics?

Also, should this a blocker for Bug 1480548, if the only use of Atomics is currently disabled?

[1] javascript.options.shared_memory
Priority: -- → P3
This is a blocker for actually compiling the JS engine on AArch64 Windows, since the functions for atomic operations are used unconditionally...hence the big #ifdef chain in the AtomicOperations.h header.  Even if the pref is off, we still need things to compile.

The good news is that tweaking the existing MSVC header slightly will work just fine--at least to compile things--on AArch64 Windows; I just need to submit the patch or have somebody else write the patch for me. :)
I'm not set up to write the patch but I'm happy to review, of course.
Priority: P3 → P2
The patch is simple enough.  Two things to note here:

- I don't know what to do about the naming of the header file.  I realize that
  it's a little weird to include an x86 file on AArch64...should I rename it?
  Where should it go?

- The substitution in fenceSeqCst requires some justification.  MemoryBarrier
  on x86oid processors is defined as __faststorefence, which is documented
  here:  The
  documentation states that the effect is comparable to but faster than the
  _mm_mfence intrinsic.

  MemoryBarrier on ARM and AArch64 translates to the __dmb intrinsic, which
  seems correct.
Attachment #9002826 - Flags: review?(lhansen)
Comment on attachment 9002826 [details] [diff] [review]
add support for atomic operations on AArch64 Windows

Review of attachment 9002826 [details] [diff] [review]:

For hack value: There's vigorous debate on the 'net about whether __faststorefence is faster than _mm_mfence.  __faststorefence generates a LOCK OR with memory, this is effectively equivalent to the LOCK ADD 0, [rsp] trick that Linux uses for a barrier on older systems.  In the past, a message I saw from the Java team at Sun/Oracle stated that whether one is better than the other is microarchitecture-dependent.  Microsoft's documentation states that __faststorefence is better on Intel and mfence is better on AMD64...  Don't we love it.

This particular code is not performance critical so substituting for MemoryBarrier if that is a platform-independent value is fine with me.

About the naming and placement of the header file.  Canonically we fork the file and place it in jit/arm64/AtomicOperations-arm64-msvc.h, and rename the one that's already in that directory to jit/arm64/AtomicOperations-arm64-gcc.h.  This duplicates code but has served us well in avoiding ifdeffery so far.  If you have the energy for it I think you should do that, as it keeps things simple.

I'm making good progress on jitting the atomic ops, and once that code is ready I foresee a substantial cleanup of some of these files anyway.  For Tier 1 platforms we'll only have support for jitting with a fallback to shared feeling-lucky implementations (one for gcc, one for msvc).  Thus a number of these apparently duplicated files will disappear.
Attachment #9002826 - Flags: review?(lhansen) → review+
Assignee: nobody → nfroyd
Pushed by
add support for atomic operations on AArch64 Windows; r=lth
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Blocks: 1489601
You need to log in before you can comment on or make changes to this bug.