A recent rr recording has identified two races in the implementation of ShenandoahFreeSet::available()

See https://pernos.co/debug/3zDvN8_0jxESra4SmMfkAw/index.html for more details.

1. The implementation of available() consults used() and capacity() without acquiring the heap lock. There are many situations under which we adjust capacity() and used() together, while holding the heap lock to assure the intermediate states are not inconsistent. Since the implementation of available() does not hold the heap lock, it may obtain the value of capacity() from after such an adjustment, but he value of used() from before the adjustments. This results in an assertion error, because used() is greater than capacity().

2. It is possible that the heuristics that trigger the start of the next GC invoke available before (or during) the next rebuild of the ShenandoahFreeSet. This is because the Free Set is built concurrently. If this happens, the trigger heuristic may come to believe that memory is already exhausted and immediately trigger another GC.

We need to address both of these races.