Java 12-GC (JEP 346) Является ли поведение особенно невыгодным в контейнерных средах, где ресурсы оплачиваются путем использования?

Question

Заявленная цель этого JEP - улучшить сборщик мусора G1, чтобы он автоматически возвращал кучи памяти Java операционной системе при простое

Поскольку G1 старается полностью избежать полных сборок мусора и запускает только параллельный циклоснованный на занятии и распределении кучи Java, во многих случаях он не будет возвращать память кучи Java, если только не будет вынужден делать это внешне.

Итак, является ли это невыгодным в контейнерных средах, где ресурсы оплачиваются путем использования?

Может кто-нибудь уточнить, пожалуйста ....

Ссылка: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8204089

Answer 1

В соответствии с документом JEP новое поведение включено

В значениях конфигурации по умолчанию мы отключаем эту функцию.Это не приводит к неожиданным изменениям в поведении виртуальной машины для приложений, чувствительных к задержке или пропускной способности.

, поэтому не будет никакого влияния на любую систему.Для сред, где это может стоить того, его можно включить, а затем оценить влияние.

Хотя цель состоит в том, чтобы помочь совместно используемым контейнерам или средам виртуальных машин, это не обязательно означает, что все такие среды действительно выиграют, поскольку это зависитс точки зрения их использования, сколько пиковой памяти можно сократить во время периодов простоя, является ли ЦП или память более ценным и многие другие факторы.

Так что, будет ли это (не) выгодно, придется оценивать по случаюна индивидуальной основе.

Answer 2

Если я вас не правильно понимаю, то, по-видимому, вы спрашиваете, невыгодно ли использование памяти GC для восстановления памяти в контейнерах, поскольку пользователь может не полностью использовать память и, следовательно, перегружен для ресурсов.

Ссылка, которую вы указали, на самом деле гласит следующее:

Такое поведение особенно невыгодно в контейнерных средах, где ресурсы оплачиваются путем использования.Даже на этапах, когда виртуальная машина использует только часть назначенных ей ресурсов памяти из-за неактивности, G1 сохранит всю кучу Java.Это приводит к тому, что клиенты все время платят за все ресурсы, а облачные провайдеры [не могут в полной мере использовать свое оборудование] [4].

Если бы виртуальная машина могла обнаруживать фазы недоиспользования кучи Java («незанятые» фазы), и автоматически уменьшит использование кучи в течение этого времени, оба выиграют.

Разработчики этого JEP, похоже, полагают, что и пользователь, и поставщик облачных вычислений выиграют от восстановлениянеиспользуемой памяти, и, кажется, это имеет смысл из приведенного выше утверждения.

Однако, если ваша программа работает в синхронизированной среде (такой как AWS Lambda) и она недолговечна, вы можете даже использоватьEpsilon GC, где никакая память не восстанавливается, поскольку в некоторых случаях это может принести вам еще большую пользу (зачем тратить циклы ЦП на восстановление памяти, если контейнер будет просто уничтожен?).