What values do use for MaxTenuringThreshold?

[Y Srinivas Ramakrishna]

Some random thoughts/ramblings below ...

> > My experience has shown that having a really high MTT leads to a ton 
> 
> > of extra copying.
> It really depends on the application / requirements / etc. A lot of 
> the 
> time the extra copying is worth it, if you can eventually reclaim the 
> 
> majority of those objects in the young generation and avoid promoting 
> them.

Or, put another way, it depends on the relative costs (where cost is
relative to an application-specific utility function) of the potentially
repeated copying versus the cost of reclaiming them in the old
generation (where the cost of reclaiming them in the old generation
might include not just the measured cost of old gen collection,
but also the cost of potentially increased mutator costs because of
loss of spatial locality, or increase in young gen costs because
of greater occupancy of the old generation for example increasing
card-scanning costs etc.)

> >   Likewise, I'm not sure in what circumstances NeverTenure would be 
> a 
> > good idea.  
> If you have quite a lot of free space in your survivor spaces, maybe 
> you 
> can retain objects in the young gen much longer with NeverTenure and 
> reclaim them there, saving promoting them. But, I'd guess, in most 
> cases, space in the survivor spaces will be at a premium. So, the 
> NeverTenure policy (as I think I said in a previous e-mail?) could 
> either prematurely promote objects or causing excessive object copying 
> 
> (or both!). I'm really curious whether anyone is using it and seeing a 
> 
> benefit from it.

The flip answer is that it's useful if you want to avoid promotion
altogether (perhaps because the cost of an old generation collection
is considered excessive given the user's utility function) and
your objects all die just a little after 2^n scavenges,
n the number of age bits available. 

> > The whole point of generational garbage collection is to get junk 
> that 
> > sticks around a while out of the hot area of memory, isn't it?
> I would actually say it's the opposite; to cheaply get rid of the 
> short-lived "chaff".
> >   Both of these settings seem to indicate that you'ld be better off 
> 
> > using non generational GC.

I agree that used in the manner of NeverTenure scenario I described above,
one is essentially using a generational collector in non-generational
mode, if you will.

> Having observed GC patterns for Java applications for a long time, I 
> don't think there would be many cases where a non-generational GC 
> would 
> win (I'm referring to real apps here, not small micro benchmarks...).

There is probably a small class of very specific applications (such as
seen sometimes in telecoms -- and occasionally in certain ecommerce
settings as Peter will attest -- where there is no state associated with
very short-lived transactions for example) which are essentially
non-generational in the time-scale of the scavenges. At a finer time-scale
I am sure some generational behaviour would emerge even in these
applications. However, to the extent that one can in most such cases simulate
the non-generational configuration from a generational configuration that
never promotes and does not allocate any space for the old generation,
one would feel comfortable using generational collector implementations
always (because it appears to be a simulation, not a bisimulation:
it would seem that a non-generational collector would not be able to
simulate a generational one, or may be we should not be splitting hairs on the
semantics of what is or is not a non-generational collector).

-- ramki
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use