RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds

[David Holmes]

Thanks for the explanation John!

To summarise for my own benefit. Patching an unaligned address may not 
be atomic at the hardware level, but for a uniprocessor it is 
effectively atomic as nothing else can concurrently examine the address 
(we "can't" field interrupts that might trigger a context switch in the 
middle of an instruction executing). For MP concurrent access is 
possible so we always force alignment.

I will assume is_MP is true and always use the aligning code. Though I 
already noticed this would have some non-trivial flow on where we check 
for un-aligned patching and assert !is_MP. That will reduce to adding a 
guarantee that the patching location is aligned and only use the code 
for the aligned case.

Thanks,
David

On 14/09/2018 11:17 AM, John Rose wrote:
> On Sep 13, 2018, at 7:10 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
>>
>> 2. to align certain patchable code sequences (method entry, call sites)
>>
>> The is_MP is currently retained. This is because I have no idea what 
>> this alignment logic is or how it relates to uniprocessor or 
>> multiprocessor implementations. Can anyone shed some light?
> 
> Patchable instruction sequences inherently exhibit race conditions,
> where thread A is patching an instruction at the same time thread B
> is executing it.  The algorithms we use ensure that any observation
> that B can make on any intermediate states during A's patching will
> always end up with a correct outcome.  This is easiest if there are
> few or no intermediate states.  (Some inline caches have two related
> instructions that must be patched in tandem.  For those, intermediate
> states seem to be unavoidable, but we will get the right answer from
> all possible observation orders.)
> 
> When patching the entry instruction at the head of a method, or a
> linkable call instruction inside of a method, we try very hard to use
> a patch sequence which executes as a single memory transaction.
> This means, in practice, that when thread A patches an instruction,
> it should patch a 32-bit or 64-bit word that somehow overlaps the
> instruction or is contained in it.  We believe that memory hardware
> will never break up such an word write, if it is naturally aligned
> for the word being written.  We also know that some CPUs work
> very hard to create atomic updates even of naturally unaligned
> words, but we don't want to bet the farm on this always working.
> 
> Therefore, if there is any chance of a race condition, we try to
> patch only naturally aligned words, as single, full-word writes.
> 
> The is_MP query is asking, "do we have to worry about races?"
> Just set it to constant-true.  It's not worth trying to maintain the
> alternative algorithm.  In fact, pre-emptive single-processor
> systems have race conditions too, although they are rarer and
> more constrained than in modern systems.
> 
> — John