RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds
david.holmes at oracle.com
Fri Sep 14 01:37:53 UTC 2018
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.
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
More information about the hotspot-dev