934314 - Add possibility to make thread-safe relocatable pointers.

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, defect)

Description

[Nicolas B. Pierron [:nbp | PTO until 11/11]]

Attachment: x64 - thread-safe relocatable pointers.

To handle the laziness introduced in Bug 932627 with PJS, we need to be able to relocate/substitute call pointers safely.

Currently, on x64, we have 2 modes for encoding calls.  One which is a relative-imm32, or a fixed relative-imm32 to an absolute address contained in the extended jump section.  These extended sections are contained in one cache line (as aligned on 16 bytes), which means that all changes would be transmitted consistently.

ARM can also encode pointers in the Pool of immediate values, in which case these pointers are also relocatable.  The Pool is aligned on 4 bytes, which makes any changes to it thread-safe.

Only x86 does not have an extended section, but we can deal with it by doing the same trick as done on x64.

* I am attaching a patch which make the relocation thread safe on x64.

01:50:35 <shu> nbp: f=me, nit on threadSafeIf, which reads kind of weird
01:50:59 <shu> nbp: maybe needsThreadSafe

Comment 1

[Dan Gohman [:sunfish]]

The patch appears to assume that any 8-byte store on x64 which doesn't cross a cache line is atomic. However, in Intel's x86 manual [0] section 8.2.3.1, it says:

"The [memory-ordering model] guarantees that, for each of the following 
memory-access instructions, the constituent memory operation appears to execute as a single memory access:
• Instructions that read or write a single byte.
• Instructions that read or write a word (2 bytes) whose address is aligned on a 2 byte boundary.
• Instructions that read or write a doubleword (4 bytes) whose address is aligned on a 4 byte boundary.
• Instructions that read or write a quadword (8 bytes) whose address is aligned on an 8 byte boundary."

This pretty specifically requires that 8-byte stores be 8-byte aligned in order to be atomic. 

Coincidentally, there is a patch in bug 934175 which aligns the address data in x64's jump table entries to 8-byte boundaries.

[0] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

Comment 2

[Nicolas B. Pierron [:nbp | PTO until 11/11]]

(In reply to Dan Gohman [:sunfish] from comment #1)
> • Instructions that read or write a quadword (8 bytes) whose address is
> aligned on an 8 byte boundary."
> 
> This pretty specifically requires that 8-byte stores be 8-byte aligned in
> order to be atomic. 

Oh, I thought the memory model was done per-cache line, and not divided like that.
Thanks for the pointer :)

Comment 3

[Nicolas B. Pierron [:nbp | PTO until 11/11]]

(In reply to Dan Gohman [:sunfish] from comment #1)
> • Instructions that read or write a doubleword (4 bytes) whose address is
> aligned on a 4 byte boundary.

So another option to make x86 jumps relocatable would be to align the pointers such as the address contained in the instruction is correctly aligned such as it is completed in a single memory access:

  nop {0-3}
  jmp 0x12345678

In which case this would take less memory than having an extra 4 Bytes for each thread-safe jump, and also knowing that x86 does not have rip-addressing.

Comment 4

[Lars T Hansen [:lth]]

We move slowly into the future, but we move nonetheless:

"The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically:
* Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line"

nbp, this is about support for PJS, can it be closed?  If not please prioritize it.

Comment 5

[Nicolas B. Pierron [:nbp | PTO until 11/11]]

(In reply to Lars T Hansen [:lth] from comment #4)
> nbp, this is about support for PJS, can it be closed?  If not please
> prioritize it.

Indeed, we no longer have PJS, and this work is no longer necessary.