Amazon Graviton and implications for concurrent Java apps

[JSR166 Concurrency mailing list]

Hi everyone,

I note that Amazon's Graviton processor is approaching availability
and has some interesting performance and other stats:

https://www.infoq.com/news/2020/03/Graviton2-benchmarks/

I was reminded of the oft-repeated idea that Java programmers don't
actually code to the JMM, they code to the stronger x86 hardware
memory model.

With the arrival of these new processors at an attractive price point
in AWS, are we going to see a wave of previously-dormant concurrency
bugs that are tickled by the difference in hardware memory model?

What can we do to prepare for such bugs, and is there anything clever
we can do to help spot them before they cause issues in production?

Thanks,

Ben
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[JSR166 Concurrency mailing list]

Hi,

On 3/16/20 12:11 PM, Ben Evans via Concurrency-interest wrote:

> I note that Amazon's Graviton processor is approaching availability
> and has some interesting performance and other stats:
>
> https://www.infoq.com/news/2020/03/Graviton2-benchmarks/
>
> I was reminded of the oft-repeated idea that Java programmers don't
> actually code to the JMM, they code to the stronger x86 hardware
> memory model.
>
> With the arrival of these new processors at an attractive price point
> in AWS, are we going to see a wave of previously-dormant concurrency
> bugs that are tickled by the difference in hardware memory model?

I don't think so, because we've been running a bunch of stuff on
AArch64 without many problems. If I had to guess the reasons for that,
they'd be

1. Lock-free programming is something of an extreme sport among Java
programmers: normal people use synchronized regions and j.u.c
structures.

2. Many of the reorderings that processors with relaxed memory
ordering do are also allowed to be done by compilers, and Java's C2
compiler is quite happy to do them. So even though x86 has a total
store order model, the compiler will still mess things up for people
who write racy programs.

> What can we do to prepare for such bugs, and is there anything clever
> we can do to help spot them before they cause issues in production?

Ooh, great question! I don't think we have race detectors for Java, but
there are severl projects out there.  See also
https://openjdk.java.net/jeps/8208520.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[JSR166 Concurrency mailing list]

Java Pathfinder is a great tool for finding races, hangs and deadlocks. 
It is a JVM written in Java.  It executes bytecode. Every time the
bytecode accesses a shared variable, synchronizes, etc. then Java
Pathfinder makes a schedule branch.  This means Java Pathfinder
interleaves every possible thread ordering.  If a deadlock can happen,
Java Pathfinder will reproduce the problem.

With only 2 threads, the number of thread orderings can be exponential. 
Java Pathfinder keeps track of visited states and when two different
interleavings are identical then the duplicates are no longer explored. 
However, do not attempt to run anything very large.  Typically, a single
class is complex enough.

https://en.wikipedia.org/wiki/Java_Pathfinder

-Nathan

On 3/16/2020 9:43 AM, Andrew Haley via Concurrency-interest wrote:

> Hi,
>
> On 3/16/20 12:11 PM, Ben Evans via Concurrency-interest wrote:
>
>> I note that Amazon's Graviton processor is approaching availability
>> and has some interesting performance and other stats:
>>
>> https://www.infoq.com/news/2020/03/Graviton2-benchmarks/
>>
>> I was reminded of the oft-repeated idea that Java programmers don't
>> actually code to the JMM, they code to the stronger x86 hardware
>> memory model.
>>
>> With the arrival of these new processors at an attractive price point
>> in AWS, are we going to see a wave of previously-dormant concurrency
>> bugs that are tickled by the difference in hardware memory model?
> I don't think so, because we've been running a bunch of stuff on
> AArch64 without many problems. If I had to guess the reasons for that,
> they'd be
>
> 1. Lock-free programming is something of an extreme sport among Java
> programmers: normal people use synchronized regions and j.u.c
> structures.
>
> 2. Many of the reorderings that processors with relaxed memory
> ordering do are also allowed to be done by compilers, and Java's C2
> compiler is quite happy to do them. So even though x86 has a total
> store order model, the compiler will still mess things up for people
> who write racy programs.
>
>> What can we do to prepare for such bugs, and is there anything clever
>> we can do to help spot them before they cause issues in production?
> Ooh, great question! I don't think we have race detectors for Java, but
> there are severl projects out there.  See also
> https://openjdk.java.net/jeps/8208520.
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[JSR166 Concurrency mailing list]

I used it. Java pathfinder gives you false hope.

That is, if it finds races, they exist. If it doesn't, it is not a proof of correctness. 

For example, how to decide how many threads should be run in a test? Two? It can be shown to be wrong for most locks.

More threads - more states that it cannot determine to be the same.

Alex

On Mon, 16 Mar 2020, 16:03 Nathan Reynolds via Concurrency-interest, <[hidden email]> wrote:

Java Pathfinder is a great tool for finding races, hangs and deadlocks. 
It is a JVM written in Java.  It executes bytecode. Every time the
bytecode accesses a shared variable, synchronizes, etc. then Java
Pathfinder makes a schedule branch.  This means Java Pathfinder
interleaves every possible thread ordering.  If a deadlock can happen,
Java Pathfinder will reproduce the problem.

With only 2 threads, the number of thread orderings can be exponential. 
Java Pathfinder keeps track of visited states and when two different
interleavings are identical then the duplicates are no longer explored. 
However, do not attempt to run anything very large.  Typically, a single
class is complex enough.

https://en.wikipedia.org/wiki/Java_Pathfinder

-Nathan

On 3/16/2020 9:43 AM, Andrew Haley via Concurrency-interest wrote:
> Hi,
>
> On 3/16/20 12:11 PM, Ben Evans via Concurrency-interest wrote:
>
>> I note that Amazon's Graviton processor is approaching availability
>> and has some interesting performance and other stats:
>>
>> https://www.infoq.com/news/2020/03/Graviton2-benchmarks/
>>
>> I was reminded of the oft-repeated idea that Java programmers don't
>> actually code to the JMM, they code to the stronger x86 hardware
>> memory model.
>>
>> With the arrival of these new processors at an attractive price point
>> in AWS, are we going to see a wave of previously-dormant concurrency
>> bugs that are tickled by the difference in hardware memory model?
> I don't think so, because we've been running a bunch of stuff on
> AArch64 without many problems. If I had to guess the reasons for that,
> they'd be
>
> 1. Lock-free programming is something of an extreme sport among Java
> programmers: normal people use synchronized regions and j.u.c
> structures.
>
> 2. Many of the reorderings that processors with relaxed memory
> ordering do are also allowed to be done by compilers, and Java's C2
> compiler is quite happy to do them. So even though x86 has a total
> store order model, the compiler will still mess things up for people
> who write racy programs.
>
>> What can we do to prepare for such bugs, and is there anything clever
>> we can do to help spot them before they cause issues in production?
> Ooh, great question! I don't think we have race detectors for Java, but
> there are severl projects out there.  See also
> https://openjdk.java.net/jeps/8208520.
>
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[JSR166 Concurrency mailing list]

* Andrew Haley via Concurrency-interest:

> I don't think so, because we've been running a bunch of stuff on
> AArch64 without many problems. If I had to guess the reasons for that,
> they'd be
>
> 1. Lock-free programming is something of an extreme sport among Java
> programmers: normal people use synchronized regions and j.u.c
> structures.
>
> 2. Many of the reorderings that processors with relaxed memory
> ordering do are also allowed to be done by compilers, and Java's C2
> compiler is quite happy to do them. So even though x86 has a total
> store order model, the compiler will still mess things up for people
> who write racy programs.

Porting enterprise Java software to run on POWER probably has ironed
out quite a few bugs as well.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest