RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds
john.r.rose at oracle.com
Fri Sep 14 01:17:44 UTC 2018
On Sep 13, 2018, at 7:10 PM, David Holmes <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.
More information about the hotspot-dev