Re: Amazon Graviton and implications for concurrent Java apps

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
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest