RFC: 8185062: os::is_MP() sometimes returns false

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: 8185062: os::is_MP() sometimes returns false

David Holmes
https://bugs.openjdk.java.net/browse/JDK-8185062

Is it time to completely remove runtime optimizations aimed at
uniprocessor systems ie.

if (os::is_MP()) {
   x();
}

just becomes:

x();

?

Does anyone care about uniprocessor systems _and_ care to the extent
that the overhead of things only necessary on MP systems (_lock
prefixes, explicit atomic instructions, memory barriers) would be a problem?

As outlined in the "bug" report there are three basic options:

1. Switch AssumeMP to be true by default (arguably necessary regardless
due to dynamic container environments)

2. Allow non-MP support to be built, but by default only build MP
support ie no runtime means to disable MP support, and compile-time
MP_ONLY/NOT_MP macros.

3. Assume the universe is MP and only allow MP to be built

Cheers,
David
-----
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Vladimir Kozlov
I am fine to drop non_MP now (3.) if people are fine with it.
Lets hear from our colleges who support other systems and give them build macros (2.) if needed.

1. choice regarding AssumeMP flag could be used in previous releases. And done per platform by converting flag to product_pd() if needed.

Thanks,
Vladimir

On 8/1/17 9:35 PM, David Holmes wrote:

> https://bugs.openjdk.java.net/browse/JDK-8185062
>
> Is it time to completely remove runtime optimizations aimed at uniprocessor systems ie.
>
> if (os::is_MP()) {
>    x();
> }
>
> just becomes:
>
> x();
>
> ?
>
> Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would be a
> problem?
>
> As outlined in the "bug" report there are three basic options:
>
> 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container environments)
>
> 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP macros.
>
> 3. Assume the universe is MP and only allow MP to be built
>
> Cheers,
> David
> -----
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Aleksey Shipilev-4
In reply to this post by David Holmes
On 08/02/2017 06:35 AM, David Holmes wrote:
> Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things
> only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would
> be a problem?

Very happy to see os::is_MP phased out and go. Performance-wise, as the experience with expunging
is_MP from Atomics [1] shows, there is a benefit for MP systems with expunging is_MP checks from
native code paths. My only concern is with low-power single-processor ARMs and MIPSes. Looking
around HS codebase, I think only that matters now.

> As outlined in the "bug" report there are three basic options:
>
> 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container
> environments)

FWIW, we (Red Hat) are shipping our RPMs with AssumeMP switched to "true" by default [2, 3], because
of the container issues. Recent glibc helps there too [4].

> 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to
> disable MP support, and compile-time MP_ONLY/NOT_MP macros.
> 3. Assume the universe is MP and only allow MP to be built

On the fence between these two. Completely fine with removing is_MP from the native codepaths,
because that yields benefits for others. Kinda see the reason to keep is_MP checks/macros in the
compiler code, to claim the benefits on lower ARMs and MIPSes.

Thanks,
-Aleksey


[1] https://bugs.openjdk.java.net/browse/JDK-8169061
[2] https://git.centos.org/blob/rpms!java-1.8.0-openjdk.git/c7/SOURCES!always_assumemp.patch
[3] https://git.centos.org/blob/rpms!java-1.8.0-openjdk.git/c7/SPECS!java-1.8.0-openjdk.spec#L963
[4] https://sourceware.org/ml/libc-alpha/2017-06/msg00101.html

Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

David Holmes
In reply to this post by David Holmes
Surprising lack of response to this.

Conservatism will likely dictate we go option #1 if we get no more feedback.

Thanks,
David

On 2/08/2017 2:35 PM, David Holmes wrote:

> https://bugs.openjdk.java.net/browse/JDK-8185062
>
> Is it time to completely remove runtime optimizations aimed at
> uniprocessor systems ie.
>
> if (os::is_MP()) {
>    x();
> }
>
> just becomes:
>
> x();
>
> ?
>
> Does anyone care about uniprocessor systems _and_ care to the extent
> that the overhead of things only necessary on MP systems (_lock
> prefixes, explicit atomic instructions, memory barriers) would be a
> problem?
>
> As outlined in the "bug" report there are three basic options:
>
> 1. Switch AssumeMP to be true by default (arguably necessary regardless
> due to dynamic container environments)
>
> 2. Allow non-MP support to be built, but by default only build MP
> support ie no runtime means to disable MP support, and compile-time
> MP_ONLY/NOT_MP macros.
>
> 3. Assume the universe is MP and only allow MP to be built
>
> Cheers,
> David
> -----
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Vladimir Kozlov
On 8/21/17 5:56 PM, David Holmes wrote:
> Surprising lack of response to this.

You need more? I and Aleksey replied.

Vladimir

>
> Conservatism will likely dictate we go option #1 if we get no more
> feedback.
>
> Thanks,
> David
>
> On 2/08/2017 2:35 PM, David Holmes wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8185062
>>
>> Is it time to completely remove runtime optimizations aimed at
>> uniprocessor systems ie.
>>
>> if (os::is_MP()) {
>>    x();
>> }
>>
>> just becomes:
>>
>> x();
>>
>> ?
>>
>> Does anyone care about uniprocessor systems _and_ care to the extent
>> that the overhead of things only necessary on MP systems (_lock
>> prefixes, explicit atomic instructions, memory barriers) would be a
>> problem?
>>
>> As outlined in the "bug" report there are three basic options:
>>
>> 1. Switch AssumeMP to be true by default (arguably necessary
>> regardless due to dynamic container environments)
>>
>> 2. Allow non-MP support to be built, but by default only build MP
>> support ie no runtime means to disable MP support, and compile-time
>> MP_ONLY/NOT_MP macros.
>>
>> 3. Assume the universe is MP and only allow MP to be built
>>
>> Cheers,
>> David
>> -----
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

David Holmes
On 22/08/2017 11:08 AM, Vladimir Kozlov wrote:
> On 8/21/17 5:56 PM, David Holmes wrote:
>> Surprising lack of response to this.
>
> You need more? I and Aleksey replied.

So I'm good on feedback quality, just lacking in quantity :)

David

> Vladimir
>
>>
>> Conservatism will likely dictate we go option #1 if we get no more
>> feedback.
>>
>> Thanks,
>> David
>>
>> On 2/08/2017 2:35 PM, David Holmes wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8185062
>>>
>>> Is it time to completely remove runtime optimizations aimed at
>>> uniprocessor systems ie.
>>>
>>> if (os::is_MP()) {
>>>    x();
>>> }
>>>
>>> just becomes:
>>>
>>> x();
>>>
>>> ?
>>>
>>> Does anyone care about uniprocessor systems _and_ care to the extent
>>> that the overhead of things only necessary on MP systems (_lock
>>> prefixes, explicit atomic instructions, memory barriers) would be a
>>> problem?
>>>
>>> As outlined in the "bug" report there are three basic options:
>>>
>>> 1. Switch AssumeMP to be true by default (arguably necessary
>>> regardless due to dynamic container environments)
>>>
>>> 2. Allow non-MP support to be built, but by default only build MP
>>> support ie no runtime means to disable MP support, and compile-time
>>> MP_ONLY/NOT_MP macros.
>>>
>>> 3. Assume the universe is MP and only allow MP to be built
>>>
>>> Cheers,
>>> David
>>> -----
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Andrew Haley
In reply to this post by David Holmes
On 22/08/17 01:56, David Holmes wrote:
> Surprising lack of response to this.
>
> Conservatism will likely dictate we go option #1 if we get no more feedback.

Nuke it.  Virtualization is the modern world, and a JVM has no way
to know when it migrates.  Also, the inline tests in x86 needlessly
hurt performance.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Thomas Stüfe-2
In reply to this post by David Holmes
Hi David,

We opt for option #3.

Kind Regards, Thomas

On Tue, Aug 22, 2017 at 2:56 AM, David Holmes <[hidden email]>
wrote:

> Surprising lack of response to this.
>
> Conservatism will likely dictate we go option #1 if we get no more
> feedback.
>
> Thanks,
> David
>
>
> On 2/08/2017 2:35 PM, David Holmes wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8185062
>>
>> Is it time to completely remove runtime optimizations aimed at
>> uniprocessor systems ie.
>>
>> if (os::is_MP()) {
>>    x();
>> }
>>
>> just becomes:
>>
>> x();
>>
>> ?
>>
>> Does anyone care about uniprocessor systems _and_ care to the extent that
>> the overhead of things only necessary on MP systems (_lock prefixes,
>> explicit atomic instructions, memory barriers) would be a problem?
>>
>> As outlined in the "bug" report there are three basic options:
>>
>> 1. Switch AssumeMP to be true by default (arguably necessary regardless
>> due to dynamic container environments)
>>
>> 2. Allow non-MP support to be built, but by default only build MP support
>> ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP
>> macros.
>>
>> 3. Assume the universe is MP and only allow MP to be built
>>
>> Cheers,
>> David
>> -----
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Erik Österlund-2
In reply to this post by David Holmes
Hi,

I would go with #3.

Thanks,
/Erik

> On 22 Aug 2017, at 04:33, David Holmes <[hidden email]> wrote:
>
>> On 22/08/2017 11:08 AM, Vladimir Kozlov wrote:
>>> On 8/21/17 5:56 PM, David Holmes wrote:
>>> Surprising lack of response to this.
>> You need more? I and Aleksey replied.
>
> So I'm good on feedback quality, just lacking in quantity :)
>
> David
>
>> Vladimir
>>>
>>> Conservatism will likely dictate we go option #1 if we get no more feedback.
>>>
>>> Thanks,
>>> David
>>>
>>>> On 2/08/2017 2:35 PM, David Holmes wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8185062
>>>>
>>>> Is it time to completely remove runtime optimizations aimed at uniprocessor systems ie.
>>>>
>>>> if (os::is_MP()) {
>>>>    x();
>>>> }
>>>>
>>>> just becomes:
>>>>
>>>> x();
>>>>
>>>> ?
>>>>
>>>> Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would be a problem?
>>>>
>>>> As outlined in the "bug" report there are three basic options:
>>>>
>>>> 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container environments)
>>>>
>>>> 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to disable MP support, and compile-time MP_ONLY/NOT_MP macros.
>>>>
>>>> 3. Assume the universe is MP and only allow MP to be built
>>>>
>>>> Cheers,
>>>> David
>>>> -----

Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

Daniel D. Daugherty
In reply to this post by David Holmes
Vote: option #3

Dan


On 8/21/17 6:56 PM, David Holmes wrote:

> Surprising lack of response to this.
>
> Conservatism will likely dictate we go option #1 if we get no more
> feedback.
>
> Thanks,
> David
>
> On 2/08/2017 2:35 PM, David Holmes wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8185062
>>
>> Is it time to completely remove runtime optimizations aimed at
>> uniprocessor systems ie.
>>
>> if (os::is_MP()) {
>>    x();
>> }
>>
>> just becomes:
>>
>> x();
>>
>> ?
>>
>> Does anyone care about uniprocessor systems _and_ care to the extent
>> that the overhead of things only necessary on MP systems (_lock
>> prefixes, explicit atomic instructions, memory barriers) would be a
>> problem?
>>
>> As outlined in the "bug" report there are three basic options:
>>
>> 1. Switch AssumeMP to be true by default (arguably necessary
>> regardless due to dynamic container environments)
>>
>> 2. Allow non-MP support to be built, but by default only build MP
>> support ie no runtime means to disable MP support, and compile-time
>> MP_ONLY/NOT_MP macros.
>>
>> 3. Assume the universe is MP and only allow MP to be built
>>
>> Cheers,
>> David
>> -----

Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

David Holmes
On 24/08/2017 5:49 AM, Daniel D. Daugherty wrote:
> Vote: option #3

Thanks for all the additional input folks - seems option #3 is preferred
by hardcore VM folk :)

I'll look into this further now.

Thanks,
David

> Dan
>
>
> On 8/21/17 6:56 PM, David Holmes wrote:
>> Surprising lack of response to this.
>>
>> Conservatism will likely dictate we go option #1 if we get no more
>> feedback.
>>
>> Thanks,
>> David
>>
>> On 2/08/2017 2:35 PM, David Holmes wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8185062
>>>
>>> Is it time to completely remove runtime optimizations aimed at
>>> uniprocessor systems ie.
>>>
>>> if (os::is_MP()) {
>>>    x();
>>> }
>>>
>>> just becomes:
>>>
>>> x();
>>>
>>> ?
>>>
>>> Does anyone care about uniprocessor systems _and_ care to the extent
>>> that the overhead of things only necessary on MP systems (_lock
>>> prefixes, explicit atomic instructions, memory barriers) would be a
>>> problem?
>>>
>>> As outlined in the "bug" report there are three basic options:
>>>
>>> 1. Switch AssumeMP to be true by default (arguably necessary
>>> regardless due to dynamic container environments)
>>>
>>> 2. Allow non-MP support to be built, but by default only build MP
>>> support ie no runtime means to disable MP support, and compile-time
>>> MP_ONLY/NOT_MP macros.
>>>
>>> 3. Assume the universe is MP and only allow MP to be built
>>>
>>> Cheers,
>>> David
>>> -----
>
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

John Rose-3
In reply to this post by David Holmes
On Aug 1, 2017, at 9:35 PM, David Holmes <[hidden email]> wrote:
>
> 3. Assume the universe is MP and only allow MP to be built

I vote #3.  My conservative first impulse was to drive towards an is_MP
that returns true always, but remains for the sake of commenting the MP
dependencies in our logic.  But there are so few uses of it, that a few well
written comments could do the same job.  I left a comment on the bug with
a few more details.

https://bugs.openjdk.java.net/browse/JDK-8185062?focusedCommentId=14167081

— John
Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

John Rose-3
(Wow the miracle of full-text search over one's inbox.  Sorry about the spam.)

On Mar 26, 2018, at 6:06 PM, John Rose <[hidden email]> wrote:

>
> On Aug 1, 2017, at 9:35 PM, David Holmes <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> 3. Assume the universe is MP and only allow MP to be built
>
> I vote #3.  My conservative first impulse was to drive towards an is_MP
> that returns true always, but remains for the sake of commenting the MP
> dependencies in our logic.  But there are so few uses of it, that a few well
> written comments could do the same job.  I left a comment on the bug with
> a few more details.
>
> https://bugs.openjdk.java.net/browse/JDK-8185062?focusedCommentId=14167081 <https://bugs.openjdk.java.net/browse/JDK-8185062?focusedCommentId=14167081>
>
> — John

Reply | Threaded
Open this post in threaded view
|

Re: RFC: 8185062: os::is_MP() sometimes returns false

David Holmes
On 27/03/2018 11:07 AM, John Rose wrote:
> (Wow the miracle of full-text search over one's inbox.  Sorry about the
> spam.)

Not at all John - this is good input! Thanks.

Progress on this stalled for a number of reasons, but one was the
resurgence of UP environments through containers.

David

> On Mar 26, 2018, at 6:06 PM, John Rose <[hidden email]
> <mailto:[hidden email]>> wrote:
>>
>> On Aug 1, 2017, at 9:35 PM, David Holmes <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>>
>>> 3. Assume the universe is MP and only allow MP to be built
>>
>> I vote #3.  My conservative first impulse was to drive towards an is_MP
>> that returns true always, but remains for the sake of commenting the MP
>> dependencies in our logic.  But there are so few uses of it, that a
>> few well
>> written comments could do the same job.  I left a comment on the bug with
>> a few more details.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8185062?focusedCommentId=14167081
>>
>> — John
>
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
Bug: https://bugs.openjdk.java.net/browse/JDK-8188764

Further to the discussion on this under "8185062: os::is_MP() sometimes
returns false":

http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/027720.html

then:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/031038.html

I've recommenced working on this for JDK 12.

John identifies 4 different uses of os::is_MP in the bug report which I
plan to address as follows:

1. to gate the introduction of MP-specific features, notably memory barriers

The is_MP check will be removed and we will always issue memory barriers
or pre-pend lock prefix etc.

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?

3. to gate certain optimizations which are questionable on uniprocessors
(see quicken_jni_functions)

These are psuedo-memory-barriers where we manufacture a data-dependency
instead of inserting mfence/lfence (x86 example). These are treated as
#1 and is_MP is removed.

4. to gate optimizations which are desirable on uniprocessors
(mutex/monitor short circuits)

These are spin controls and so is_MP remains.

There's an initial partial webrev (mainly x86):

http://cr.openjdk.java.net/~dholmes/8188764/webrev/

Comments welcome.

Thanks,
David
Reply | Threaded
Open this post in threaded view
|

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

John Rose-3
On Sep 13, 2018, at 7:10 PM, David Holmes <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]
> <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

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

Andrew Haley
In reply to this post by David Holmes
On 09/14/2018 01:10 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764
>
> There's an initial partial webrev (mainly x86):
>
> http://cr.openjdk.java.net/~dholmes/8188764/webrev/

AArch64 part looks good.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

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

Andrew Haley
In reply to this post by John Rose-3
On 09/14/2018 02:17 AM, John Rose wrote:

> Therefore, if there is any chance of a race condition, we try to
> patch only naturally aligned words, as single, full-word writes.

Thanks for that. It was very difficult to understand what the code was
doing when I ported it to AArch64.

It would be very nice to have this commentary in the source code. May
I submit this as a comment-only patch?

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Andrew Haley
On 14/09/2018 7:05 PM, Andrew Haley wrote:
> On 09/14/2018 01:10 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764
>>
>> There's an initial partial webrev (mainly x86):
>>
>> http://cr.openjdk.java.net/~dholmes/8188764/webrev/
>
> AArch64 part looks good.

Thanks Andrew. I'll send out actually RFR shortly.

David

12