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

[Roman Kennke]

Only evacuating concurrently, without patching, seems a reasonable compromise for now. Aleksey suggested to record all code cache pop locations, this way we could very quickly scan+update oops during stw, without having to parse the code cache.

Roman

Am 1. Juli 2017 10:23:17 MESZ schrieb Andrew Haley <aph at redhat.com>:
>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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.