Current "compact" heuristics has this trigger:

  if (available < threshold_bytes_allocated) {
    log_info(gc)("Trigger: Free (" SIZE_FORMAT "%s) is lower than allocated recently (" SIZE_FORMAT "%s)",

First of all, it lies about the value it checks: it says "allocated recently", but actually checks the threshold. Second, this is excessive, given the prior check for "available < min_free_threshold", that is supposed to start the GC anyway with any large allocation threshold. Exploring the source code history, it seems the check was always there to trigger the GC the similar way "available < min_free_threshold" does it. "available < min_free_threshold" was added later, making this check completely redundant. It is even more redundant, as default setting of "min_free_threshold" is 10, making it exactly the same check.

This bug makes cycles more frequent with *larger* -XX:ShenandoahAllocationThreshold on busy heaps. At the extreme, setting -XX:SAT=100 devolves to back-to-back cycles, because available space is always less than entire heap.