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 |
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 |
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 |
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. _______________________________________________ Concurrency-interest mailing list [hidden email] http://cs.oswego.edu/mailman/listinfo/concurrency-interest |
In reply to this post by 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 |
Free forum by Nabble | Edit this page |