Re: Controlling the Garbage Collector
On 6/21/2012 2:24 PM, Aaron W. Hsu wrote:
[...]
On the other side, there are times when I know that I am going to be
doing a number of very small, little allocations all in a row, and I do
not want the GC to run during this tight loop, because it will cause a
noticeable hit. I would rather delay the collector, consuming more memory
until the end when I can explicitly trigger the collector at that point.
Sounds like you might be better off collecting first, when there
are fewer objects to be discovered and analyzed. Also, since you've
said you're not speaking of real-time applications, I don't see why
you should be concerned about the precise timing of the "hit:" Before,
after, during, what difference does it make? (If you're worried about
GC roiling the caches, please provide actual measurements.)
Or, I may know that some structure is going to be extremely long lived
and I need to keep it out of the collector entirely.
Generational collectors do a pretty good imitation of this. It's
not perfect because it takes time for the GC to discover what's long-
lived and what's not, but it's pretty effective. Also, it has the
huge advantage of always being right; few programmers can match that
accuracy. (See also "memory leak.")
Finally, there are times when I want to do a large bulk allocation
outside of the collector, and then selectively move certain things into
the collected space, but still have a checked, high-level way of
accessing data structures in the uncollected space.
JNI, if you simply must.
Now, all of these are corner cases to me because you can get by without
them in most situations, unless you are trying to eek out all of the
performance you can from your system.
"Eek" is right ...
--
Eric Sosman
esosman@ieee-dot-org.invalid