Накладные расходы, если GC для памяти в JVM vs Swift style ARC

Question

Компания, в которой я работаю, имеет совершенно разные точки зрения относительно платформы разработки JVM.

На основании этой статьи здесь - http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf

Они говорят, что оракул требует JVM 3-5x памяти overheead т.е. работать с 1 Гб JVM мы требуем 3-5 Гб оперативной памяти дополнительно, чтобы противодействовать служебную виртуальную машину Java и Быстрый стиль ARC - это ответ на вопросы GC.

Я сделал несколько аргументов противников о том, что они не проводили исследование на базе Oracle/Sun JVM, и некоторые экспериментальные VM и ARC имеют свои собственные проблемы, такие как круговые ссылки.

Проведено ли какое-либо исследование о том, что именно/приблизительно является накладными расходами GC для памяти в JVM, я не смог найти.

Мои вопросы кратко

1) Есть никаких видимых накладных расходов для GC. Причина, по которой объем оперативной памяти в 3-5 раз кажется действительно необоснованным, если факт верен.

Кроме того, большие приложения данных, такие как Apache spark, hbase, cassandra, работают в масштабе памяти терабайта/петабайта. Если в GC есть такие накладные расходы, почему они будут развиваться на такой платформе?

2) ARC считается уступающим другим алгоритмам трассировки GC. Если это так, было бы также полезно, если бы были какие-либо документы, непосредственно сравнивающие эффекты времени компиляции ARC malloc/free vs JVM GC runtime cleanup

Существует требование Криса Лэттнера, в котором говорится, что GC потребляет 3-5-кратную память здесь - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html

Answer 1

Есть ли видимые накладные расходы для GC. Причина, по которой объем оперативной памяти в 3-5 раз кажется действительно необоснованным, если факт верен.

Это, скорее всего, недоразумение. Вы можете запустить JVM, где используется 99% кучи, однако это будет GC регулярно. Если вы придадите программе больше памяти, она сможет работать более эффективно. Добавление большего объема памяти в кучу может повысить пропускную способность. Я видел эту работу примерно до 3 раз. За исключением крайних случаев, вы вряд ли увидите какую-либо выгоду при добавлении большего количества.

Кроме того, большие массивы данных, такие как Apache spark, hbase, cassandra, работают в масштабе терабайта/петабайта. Если в GC есть такие накладные расходы, почему они будут развиваться на такой платформе?

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

ARC считается уступающим другим алгоритмам трассировки GC.

Я не мог комментировать, как работает умный ARC. Java не устанавливает каких-либо ограничений в отношении того, как GC должен работать, но субтекст; он должен хотя бы обрабатывать круговые ссылки. Все, что меньше, считается неприемлемым.

BTW Java использует malloc/free через прямые ByteBuffers.

работы с наборами данных, такими как 1 Гб

Что делает набор данных 1 ГБ. Сжатый на диске может быть 100 МБ. Как сырые несжатые данные, это может быть 1 ГБ. В памяти в качестве структуры данных она может составлять 2 ГБ, а пропускная способность может быть быстрее, если вы используете еще 1 или 2 ГБ для работы над этой структурой данных.