RFR(m): 8220351: Cross-modifying code

[David Holmes]

On 15/03/2019 4:36 am, Andrew Haley wrote:
> On 3/14/19 6:18 PM, Andrew Haley wrote:
>> 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.
> 
> But, I should stress, all of this can be done in platform-specific code,
> so the main code base doesn't have to be bothered by any of it.

I'm glad to see all the discussion on this - it is multi-faceted and a 
typical "multi-reader/single-writer" style synchronization problem: 
depending on the platform we may have to do something in the writer 
(patching thread), something in the reader (patchee thread), or both. 
The patching thread changes are most likely in platform specific code. 
But the patchee thread, AFAICS, will be executing shared 
handshake/safepoint code, so there has to be some kind of barrier 
function added there, even if it is empty on some platforms.

Optimising the barrier is then a second level problem. Tracking when the 
barrier is actually needed is desirable as long as the bookkeeping cost 
doesn't outweigh the actual barrier cost.

I suppose that if the optimising results in the barrier locations being 
pushed "deep enough" they may end up in platform-specific code after 
all. But it's far from clear to me that we will always enter platform 
specific code.

Cheers,
David
-----

>> And, just to complicate this even more, on some processors you'd not
>> only need to to do local fencing but you might need to know which
>> memory addresses had changed.
> 
> For avoidance of doubt, I don't think that we support any such processors.
>