Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Controlling the Garbage Collector Date: Thu, 21 Jun 2012 15:24:40 -0400 Organization: A noiseless patient Spider Lines: 42 Message-ID: References: <6KSdnTwztJvtR0bSnZ2dnUVZ_t-dnZ2d@giganews.com> <_JmdnUu_Z-scJEHSnZ2dnUVZ_t6dnZ2d@giganews.com> <4fe27687$0$281$14726298@news.sunsite.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 21 Jun 2012 19:24:44 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="03ebLEozl+tXCe7JS60Feg"; logging-data="11964"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/aKii2oDNeYb2/DeL+Dqw/" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: Cancel-Lock: sha1:BGDeRcTvuiaebyA1qYmwuupHx20= Xref: csiph.com comp.lang.java.programmer:15493 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