[concurrency-interest] Amazon Graviton and implications for concurrent Java apps

Nathan Reynolds numeralnathan at gmail.com
Mon Mar 16 12:01:36 EDT 2020


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.
>


More information about the Concurrency-interest mailing list