我工作的公司对 JVM 开发平台有一种非常不同的看法。
此处基于本文 - http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf
他们说 oracle jvm 需要 3-5 倍的内存开销，即运行 1GB JVM 我们需要 3-5GB 的额外 RAM 来抵消 JVM 开销，而快速风格的 ARC 是解决 GC 问题的答案。
我提出了一些反驳论点，即他们进行研究的不是 Oracle/Sun JVM，而且一些实验性 VM 和 ARC 有其自身的问题，例如循环引用。
是否有关于 JVM 中 GC 对内存的开销究竟/大约是多少的研究，我找不到任何研究。
我的问题总结
1) GC 是否有任何可见的开销。如果事实属实，RAM 的 3-5 倍成本似乎真的不合理。
此外，Apache spark、hbase、cassandra 等大数据应用程序在 TB/PB 内存规模上运行。如果 GC 有这样的开销，他们为什么要在这样的平台上开发？
2) ARC 被认为不如其他运行时 GC 跟踪算法。如果这是真的，如果有任何论文直接比较 ARC 编译时 malloc/free 与 JVM GC 运行时清理的效果，那也会很有帮助
Chris Lattner 声称 GC 在这里消耗 3-5 倍的内存 - https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html
Is there any visible overhead for GC. Cause the 3-5x cost of RAM seems to really unreasonable if the fact is true.
这很可能是一种误解。您可以运行一个使用了 99% 堆的 JVM，但它会定期进行 GC。如果您为应用程序提供更多内存，它将能够更高效地工作。向堆中添加更多内存可以提高吞吐量。我已经看到这项工作高达大约 3 倍。除非在极端情况下，您不太可能看到添加更多内容有任何好处。
Also, big data applications such as Apache spark,hbase,cassandra operate in terabyte/petabyte memory scale. If there is such an overhead in GC why would they develop in such a platform?
处理大数据时，您经常使用内存映射文件和堆外内存。这使得大部分数据由应用程序而不是 GC 管理。这与用 C++ 编写的数据库的运行方式没有什么不同。
ARC is considered to be inferior to other runtime GC tracing algorithms.
我无法评论 ARC 有多聪明。 Java 没有对 GC 的操作方式施加任何限制，但潜台词是；它至少必须处理循环引用。任何不足都被认为是 Not Acceptable 。
顺便说一句，Java 通过直接字节缓冲区使用 malloc/free。
jobs with datasets such as 1 GB
什么使数据集达到 1 GB。压缩在磁盘上可能是 100 MB。作为未压缩的原始数据，它可能是 1 GB。在作为数据结构的内存中，它可能是 2 GB，如果您使用另外 1 或 2 GB 来处理该数据结构，吞吐量可能会更快。