RFR: Concurrent code cache evac should not update ptrs outside of safepoint

[Andrew Haley]

On 01/07/17 08:54, Aleksey Shipilev wrote:
> On 07/01/2017 09:39 AM, Andrew Haley wrote:
>> On 30/06/17 13:55, Aleksey Shipilev wrote:
>>
>>> Turns out, I made the hell of the mistake by trying to update
>>> embedded code cache ptrs during concurrent code cache evac. Updating
>>> code cache roots outside safepoint is fine. Until it is not, when
>>> address you overwrite is not aligned.  Then you have the non-atomic
>>> store, and crash on a weird ptr, if application is unlucky to be at
>>> that insn at that time. On x86, you need code cache ptr to span
>>> cache lines.
>>>
>>> The answer is to still evacuate code cache concurrently, but update
>>> the pointers only at STW:
>>
>> On some processors it's illegal to change code while it is executing.
>> Or rather, it is undefined what happens if you do.  Are these embedded
>> pointers OOPs, or something else?
> 
> Yes, embedded pointer oops, like these:
> 
> ;   {oop(a 'java/lang/Class'{0x00000005cac2d8c0} =
> 'org/openjdk/EmbeddedOops')}
> 0x00007f9e33539dc3: movabs $0x5cac2d8c0,%r10
> 0x00007f9e33539dcd: mov    0x14(%r10),%r11d

It might make sense to move these into the constant pool rather than
patching them up during STW.  I suppose, like everything else to do
with Shenandoah, it's a compromise between absolute performance and
pause time.  Loads usually have a 4-cycle latency, so that appears
to be an unattractive prospect, but they can be scheduled before use
so this might not have a great impact.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671