luk*_*uke 22
这是一篇关于垃圾收集器中常设生成的好文章:
编辑:
我没有看到任何可以表明为什么他们做出设计决定对永久发电机尺寸有最大限制的东西.但我想这是出于几个原因.
它使实现起来更容易,GC显然是非常重要的,因此以任何方式简化您的实现可能是一个好主意.
YAGNI(你不需要它)大多数应用程序加载固定数量的类,通常它不是特别大,所以它们可能已针对常见情况进行了优化,只选择了一个合理的默认值并使其可配置.
假设你的perm gen大小正在增长到不可预测的大,那么你可能在类加载器中有一个错误(或者需要重新考虑你的架构).即使在运行时生成类(或执行其他此类技巧)的应用程序中,生成的类的数量通常也是固定的,因此您应该能够调整maxperm以满足您的需求.
我不是Java类加载和垃圾收集的所有细节的专家,但它们都是JVM的复杂部分,所以我想他们会尽量保持这两个组件尽可能正交,并允许perm gen增长动态地可能会以复杂的方式将这两个组件耦合在一起(特别是因为两个组件都有严重的线程考虑)
限制最大perm生成可能有一些性能优势,允许它增长可能涉及额外的集合复制,或者它可能意味着你的perm生成不再存在于连续的地址空间中,这可能会影响其他算法的方式管理集合的工作.
显然这些都是猜测.但即使所有这些都是错误的我绝对不认为太阳选择固定尺寸是"愚蠢的",可能有更多的工程和实施考虑因素,甚至可能是我梦寐以求:)
为了呈现略微不同的视角,IBM JVM没有permgen,而是转向操作系统并根据需要分配内存块.(谣言是jrockit也一样,但我无法确认.)
这是有利的,因为你不会达到(看似)任意限制,需要针对合法的增长情况进行调整.
另一方面,对于失控的应用程序(基本上是泄漏类)来说,这是一个问题 - JVM本质上会占用地址空间中的所有内存.这可能导致错误,其中本机代码将突然失败malloc()调用,或Java以奇怪的方式破坏 - 如无法分配新线程(消耗堆栈的内存).另一个缺点是它没有提供关于JVM的内存部分将消耗多少"成本确定性".
所以这是一个权衡 - 你如何在"潜在的不良"情景中失败？
| 归档时间： |
|
| 查看次数： |
42682 次 |
| 最近记录： |