Java6 vs Java5

[Shaun Hennessy]

Y.S.Ramakrishna at Sun.COM wrote:
>
>>> 3b) - If I am going to the throughput collector, is there anyway to 
>>> force the application to keep
>>> a certain amount of the heap free (ie -Xms=Xms=256M --) I always 
>>> want to get say 100M free
>>> so once the free heap drop to that level trigger a GC?  (Basically I 
>>> want a CmsInitiatingOccupancyFraction
>>> but for the throughput collector)
>
> Do you want that much heap free in say the old generation?
>
Yes I guess I would want old (technically the application is reporting 
on total heap rather than
a particular generation so with Xmx=256 it reports X Used of 256,) but 
if I could keep
a certain amount free in old than I could accomplish what I attempting 
to do.

> What would be your rationale for wanting that kind of behaviour?
> Looks to me you would be wasting that much of space since you
> don't really get to allocate from it (or once you exceed that
> level, each scavenge becomes a full gc at least as i read your
> specification above).
>
--- My rationale?  Saving the designers from fixing problem properly :-)
I agree completely if there was some magic option to do this the end result
would be I'd be end up "reserving" (aka wasting)  X amount of memory that
I would never ever use.   A full gc would be fine as we were using 
throughput
collector before anyways and the GC time on a 256M or 512M heap should 
be fine.

Basically here's my problem....

Application, Rel1;  Java 5u16
Xms=256m;Xmx=512m;Perm=40m;MaxPerm=40M,ThreadStackSize=128
-- No other options - this would be run on multi-cpu systems
-- Our application checks on total heap used --
-- once 70% used switch Behavior to X - at 90% switch to Behavior Y
 (revert back to original behavior if we go below 70%)

-- apparently we never hit the 70%+ or if we did it wasn't very 
often/didn't last long
 -- I still have try our previous release to confirm we weren't seeing 
this behavior
 change more often with my current testing recipe


Now...


Application, Rel2; Java6u12
- with the same parameters as in previous Application Release all of sudden
we starting having extended periods where we are > 70% used and hence
our behavior switches to X/Y.
I say with the same parameters (ie 512) - but we've also seen it with
 Xms=Xmx=256 and Xms=Xmx=512


The most likely scenario is of course we've added some new bug in Rel2
causing us to have a scenario/leak where we can spike our memory up
much quicker than in Rel1 - but I was wondering if there was some change
in Java6.    And of course trying to switch to CMS just to get the 
OccupancyFraction
has opened up a whole can of worms in concurrent-mode-failures;
out-of-heap; continuous cms collections...

thanks,
Shaun


> -- ramki