Я не особенно знаком с тем, как обычно ведет себя новый Шенандоа. Однако в этом графике нет ничего особенно тревожного (для меня).
Согласно https://shipilev.net/talks/devoxx-Nov2017-shenandoah.pdf, modus operandi (MO) этого ГХ в отношении использования памяти немного отличается от некоторых других сборщиков.
«Мы заберем всю память, когда она нам понадобится, но мы также вернем ее, когда не будем».
Если распределитель имеет значительную нагрузку (т.е. выделяется много объектов), Шенандоа будет активно расширять кучу. Это основано на наблюдении, что ГХ с низкой паузой наиболее эффективен (и, скорее всего, будет продолжать работать!), Если в нем достаточно места для работы.
Но обратная сторона в том, что если ваша система простаивает, ГХ будет отдавать память ОС более свободно, чем многие другие ГХ.
Это похоже на график памяти в вашем вопросе.
Еще одна вещь, на которую следует обратить внимание, это то, что размер кучи (оранжевый) далеко не соответствует вашему пределу максимальной кучи. Если вы приблизитесь к этому пределу, сборщик мусора прекратит наращивать кучу.
Наконец, обратите внимание, что вы, вероятно, можете поощрять Shenandoah быстрее возвращать незафиксированную память, используя меньшее значение для параметра -XX:ShenandoahUncommitDelay=<millis>. Однако рекомендуется НЕ делать его слишком маленьким, поскольку это может замедлить работу распределителя.
(Источник: https://www.javacodegeeks.com/2017/11/minimize-java-memory-usage-right-garbage-collector.html)