的Java：增加YoungGen大小以提高GC性能

我讀了下面的文章：http://java.sun.com/docs/hotspot/gc1.4.2/example.html和無法理解下面幾行：的Java：增加YoungGen大小以提高GC性能

Young generation size is too small 

The young generation heap size in this first example is about 4 Mbytes with an overall heap size of about 32 Mbytes. 

[GC [DefNew: 4032K->64K(4032K), 0.0429742 secs] 9350K->7748K(32704K), 0.0431096 secs] 

[GC [DefNew: 4032K->64K(4032K), 0.0403446 secs] 11716K->10121K(32704K), 0.0404867 secs] 

[GC [DefNew: 4032K->64K(4032K), 0.0443969 secs] 14089K->12562K(32704K), 0.0445251 secs] 

This output seems reasonable from the point of view of the time spent in garbage collection but note that although the occupancy of the young generation is decreasing (e.g., in the first line from 4032 to 64k by 3968k) the occupancy of the entire heap is decreasing by considerably less (by 1602k from 9350k to 7748k). This indicates that only about 40% objects in the young generation were garbage and the rest survive the collection and are being promoted into the old generation. 


Increasing the young generation size to increase the free space after the collection 


The young generation heap size in this next run is increased to 8 Mbytes. 


[GC [DefNew: 8128K->64K(8128K), 0.0453670 secs] 13000K->7427K(32704K), 0.0454906 secs] 

[GC [DefNew: 8128K->64K(8128K), 0.0388632 secs] 15491K->9663K(32704K), 0.0390013 secs] 

[GC [DefNew: 8128K->64K(8128K), 0.0388610 secs] 17727K->11829K(32704K), 0.0389919 secs] 


With an 8 Mbyte size most of young generation is garbage at the time of the minor collection. In the first line the young generation heap decreases by 8064k from 8128k to 64k and the entire heap decreases by 5573k from 13000k to 7427k meaning about 68% of the young generation was garbage. As would be expected the size of the young generation does not change the amount of live objects that survive the minor collection (about 2.4M bytes in each case) but there are fewer minor collections and the cost of the collections in terms of the minor collection pause times are comparable (fractions of a second listed at the end of each line).

我的問題是，如何提高YoungGen的大小可以幫助我們在這案件。應用程序在YoungGen中分配的對象總數將保持不變。

來源

2012-02-21 Chander Shivdasani

答案在於文章本身英寸

正如所預料的年輕一代的大小不會改變倖存的小的收集活動對象的量（在每種情況下約 2.4M字節），但也有少次要集合和成本在次要採集暫停時間方面的集合具有可比性（每行末尾列出的小數部分）。

這是增加YoungGen的直接後果。

來源

2012-02-22 00:14:24

促進東西出來的YoungGen是昂貴的，它會導致：

它活更長的時間，浪費內存
未來的垃圾收集（每一個，直到它死了）要更貴
YoungGen系列將忽略它，而且你必須等到你耗盡更多寶貴資源，並且推出更昂貴的系列。

通過增加YoungGen的大小，他們確保更多的對象被它收集，因此不會觸及上面的任何壞點。也就是說，物體快速死亡，不會讓任何人損失任何壞處，所以一切都更快？

此外，還有一個更現代的版本，你正在閱讀的文件，但它似乎缺少您的例子： http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

來源

2012-02-22 00:11:13 FauxFaux

關於確保通過增加YoungGen來收集更多對象的觀點，您錯了。但我並不是低調，因爲你的其他觀點是有效的。 – 2012-02-22 00:15:41

如何？小的YoungGen可以容納5個物體。 6分配。爲了分配第六名，我們需要將所有五個都提升到老一代。所有六個變得無法訪問。 YoungGen系列運行。一個被收集，剩下五個？在YoungGen大小爲10個物體的情況下，所有這些都將在該示例結束時收集起來？ – FauxFaux 2012-02-22 00:22:49

你是對的 - 我錯了。 +1 – 2012-02-22 04:20:39

年輕收藏的成本與保留的對象數成正比。年輕的收藏品越大，不再需要這些物品的可能性越大，這意味着您可以發現年輕收藏品的成本增幅不會超過一定的規模。

對於小的年輕gen尺寸它的比例，但較大的尺寸沒有那麼多。收集頻率與大小成比例下降。您可以達到每天收集少於一次的時間點。 ;）

YMMV取決於您的應用程序的行爲。

來源

2012-02-22 08:02:29

的Java：增加YoungGen大小以提高GC性能

回答

相關問題