RFR(m): 8220351: Cross-modifying code

[Andrew Haley]

On 3/14/19 10:20 AM, Robbin Ehn wrote:
> On 3/14/19 11:03 AM, Andrew Haley wrote:
>> On 3/11/19 8:08 AM, Robbin Ehn wrote:
>>
>> You've put fences into shared code, but the semantics to make this
>> work correctly are different on different platforms. For example, some
>> platforms may not use patching, but instead use the constant
>> pool. Some platforms may need cache flushes as well as fences, so the
>> solution presented here is either inadequate, inefficient, or both.
>>
> The barrier placement, if any barrier is needed, would be the same for all
> platforms.

I'm not so sure of that. Not all platforms necessarily patch
instructions; it should up to the port to do something appropriate
when necessary. AArch64, for example, patches code in only limited
circumstances.

> So this patch places those barrier where we need them and add
> implementation for x86 (and PPC/s390). So for platforms that also
> need cache flushes this is inadequate and is not intended to fix
> that.

I have an idea that might work. Let's say that icache::flush(),
executed whenever we patch code, increments a global patching
counter. When a Java thread returns from a handshake, it compares a
thread-local copy of the old value of the patching counter with the
current value. If they are different, do whatever local fencing is
necessary and record the current value of the patching counter.

That should work, right? So we only execute necessary barriers, and
if some port keeps most constants in the constant pool (rather than
patching) it'll benefit.

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