Trace object allocation flag proposal

[Y. S. Ramakrishna]

On 12/16/10 11:26, Xiaobin Lu wrote:
...
> Most of time when GC becomes wild, we have to take it offline since we 
> have no choice. We had one appserver here doing full GC every 1 second. 
> It does nothing but to collect garbage :-). Having a way to 
> understanding the allocation is critical to solve this kind of 
> production issue.

For cases where you end up doing full gc's every second,
I am not sure understanding allocation is as critical. Rather understanding
what caused a leak is probably the issue? (Put another way, in most cases
that i have encountered, GC goes wild not because of unexpectedly high
birth-rates, but because of unexpectedly low death-rates, and at the
risk of sounding morbid, you typically need to investigate the root cause of the
low death-rates, if you know what i mean.)

In any case, if you really need to understand what got allocated,
as David said, that information is there in the snapshot. Those
would be the unexpectedly populous types in your snapshot.

Now what might be useful sometimes is counting at allocation sites,
and may be that was what you were intending? But that usually allows
you to tune optimal performance, rather than catch GC-gone-wild issues.

> 
> Taking snapshot is ok, but analysing the heap is pain of neck. So far, I 
> had no luck to get jhat to work with 2G heap dump even with -Xmx12g 
> specified (maybe I should fix that problem instead, John Rose suggested 
> me a while ago to file a bug, maybe I should work on that problem 
> instead. Sorry for taking so long.).

I have heard of better heap analysis tools than jhat to analyze heap dumps.
I agree that jhat is not easy to use. Besides, in typical cases,
you want to have several dumps and be able to take their "difference" etc
(which is not easy given that object identity is somewhat difficult
unless you calculate a hashcode for each object, which has prohibitively
high scaling costs, and object addresses are meaningless in the presence
of moving GC's).

Fixing bugs in jhat would be a good thing regardless, so go for it :-)

-- ramki