Can I programmatically find out in which GC generation an instance lives?

Question

This question is limited in scope to HotSpot generations. Is there any way to programmatically find out in which generation a particular instance lives. Data such as:

• Young or old generation?
• If young, which survivor space?
• Inside TLAB? Which thread?

Any technique (ex., BTrace, JVMTI) works so long as I can do something like this:

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

Beggars can't be choosers but ideally I could also learn when the instance of interest was being moved from one generation to another at the moment it happens (i.e., event callback based -- not interested in the delay & overhead implicit in polling.)

Not interested in answers that just say "no" without justification :)

Fluting

I'm curious as to why you would be interested in this. Apart from a pure curiosity of course :) – Stake

It probably can't be done because a) it would make moving resources much more expensive, and b) no one has found a good use for doing this. Perhaps you have a good use, and can reveal it? – Thaumatology

If performing a gen0 collection implies that all surviving objects are gen1 or higher, and a gen1 or gen2 collection implies that all surviving objects are gen2 or higher, and if the system keeps a couple flags for each object indicating whether a gen0 or gen1 collection has been performed since the object was last modified, the system could know when performing a gen0 or gen1 collection that the object doesn't hold any gen0 or gen1 references. A very useful optimization. – Semidiurnal

Answer 1

As far as I know, you can not directly query which memory pool an object currently lives in. However, objects are promoted to a different memory pool by a garbage collection run, and you can query the number of major/minor gc runs since VM start using JMX. If you additionally take note of these counters when the object is created, you can reconstruct whether there was a GC since and from that which pool the object lives in.

Yetty

Answer 2

There's an additional complication to the "count the number of GCs since the object was created" approach - it doesn't take into account premature object promotion.

If the survivor spaces are basically too small, and memory pressure from Eden (ie the rate of objects surviving at least once) is high, then objects will be promoted to tenured before they hit the full tenuring threshold.

In real examples, healthy applications will typically have non-zero percentages of premature promotion. In fact, a 0% premature promotion rate is a really bad sign - it says that your survivor spaces are much, much too big and you're wasting a lot of memory.

Gabardine