From: Godmar Back (gback@cs.utah.edu)
Date: Tue Jan 05 1999 - 16:32:26 EST
>
> Godmar Back writes:
> > Therefore, I feel that we should always collect if we run out.
>
> I agree with this.
>
I talked with Jason about it some more and while it the old criteria was
clearly bogus, it appears that it may indeed make sense to sometimes get
memory from the system instead of collecting.
Suppose you have an application that has 16MB of live data, and you start
with ms=16m and as=1m; you gc everytime you hit 17MB. You'd do much better
if you collected only if you hit 24MB (cause then you could pick up 8MB
for walking the heap one time.) So it appears that while the old
criteria would lead us to run out of memory wrongly, the current state
may make as collect too often --- unless -as is set to increase the heap
by a substantial amount.
As a work-around, set -ms to the amount of data you expect your app
to keep alive, and set -as to the amount of leeway you want to give it.
The question is then what heuristic do you use.
One possible heuristics may be to say that a gc should keep approximately
60-70 percent of heap data alive. I.e., you expand the heap (if you can)
as long you have less than 30-40% free. If you hit your limit, you must
collect -- you have no choice.
The question then becomes to estimate how much is free. A good estimation
is the free ratio after the last gc, but there may be better estimates,
such as those including the amount of memory allocated since the last
gc, and/or the time passed since the last gc.
I'm sure the literature must have some information on strategies for gc.
Interestingly, Sun has problems with that as well, see:
http://developer.java.sun.com/developer/bugParade/bugs/4158673.html
Finally, Jason pointed out that our gc statistics includes objects on
the finalize list. This would at least partly explain the phenomenon
I saw where more objects where marked as you increased the heap size.
Still, more investigation is needed since we've already optimized gc
to not finalize objects with empty finalizers.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:29 EDT