我可以編程的方式找出實例在哪個GC代中生存？

此問題僅限於HotSpot generations。有沒有什麼方法可以通過編程找出某個特定實例在哪一代存在。數據如：我可以編程的方式找出實例在哪個GC代中生存？

年輕一代還是老一代？
如果年輕，哪個倖存者空間？
Inside TLAB？哪個線程？（當然，BTrace，JVMTI）

任何技術的工作原理，只要我可以做這樣的事情：

Object x = new Object(); 
HotSpotGenerationInfo info = HotSpotGenerationUtil.getInfo(x);

乞丐不能挑肥揀瘦，但理想的我也可以學習時的實例興趣是從一個代移動到另一個此刻正好（即事件回調基礎 - 在延遲&開銷輪詢隱含不感興趣）

不要在答案有興趣這只是說「不」沒有理由:)

來源

2010-12-16 Brian Harris

我很好奇你爲什麼會對此感興趣。除了純粹的好奇心:) :) – drekka 2010-12-16 02:42:18

它可能無法完成，因爲a）它會使移動資源變得更加昂貴，並且b）沒有人發現這樣做的好用處。也許你有一個很好的使用，並可以揭示它？ – 2010-12-16 08:11:24

如果執行gen0集合意味着所有存活對象都是gen1或更高，並且gen1或gen2集合意味着所有存活對象都是gen2或更高，並且系統爲每個對象保留一對標誌，指示gen0或gen1集合自上一次修改對象以來，系統可以知道何時執行gen0或gen1集合，該對象不包含任何gen0或gen1引用。一個非常有用的優化。 – supercat 2012-02-03 18:11:13

據我所知，你不能直接查詢一個對象目前居住在哪個內存池。然而，對象通過垃圾收集運行提升到不同的內存池，您可以使用JMX查詢自VM啓動以來主要/次要gc運行的次數。如果在創建對象時另外注意到這些計數器，則可以重建是否存在GC，因爲該物體所處的池是哪一個池。

來源

2010-12-16 02:30:23 meriton

還有一個複雜因素是「自從計數GC數以來該對象被創建「的方法 - 它沒有考慮到過早的對象提升。

如果倖存者空間基本上太小，並且來自Eden的記憶壓力（即對象的存活率至少有一次）很高，那麼對象將在達到完整的持續時間閾值之前被提升到終身。

在實際例子中，健康的應用程序通常會有過早提升的百分比非零。事實上，0％的過早提升率是一個非常糟糕的跡象 - 它說你的倖存者空間太大了，太大了，你正在浪費大量的記憶。

來源

2012-02-01 15:23:48 kittylyst

我可以編程的方式找出實例在哪個GC代中生存？

回答

相關問題