Path: csiph.com!usenet.pasdenom.info!gegeweb.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Controlling the Garbage Collector Date: Tue, 26 Jun 2012 22:28:56 +0200 Lines: 55 Message-ID: References: <6KSdnTwztJvtR0bSnZ2dnUVZ_t-dnZ2d@giganews.com> <_JmdnUu_Z-scJEHSnZ2dnUVZ_t6dnZ2d@giganews.com> <4fe27687$0$281$14726298@news.sunsite.dk> <5d156697-1477-49c1-a098-f7bfa76783b4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net ybjt/UyuhgZXivaEWqqFmgJqT+9sW4b5H2C5F3+qGUfnm76yrBtocO6fUKoX+JIj8= Cancel-Lock: sha1:px6pLnL4Awpz11Bbc00HLSCFLmU= User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:15608 On 26.06.2012 19:07, Eric Sosman wrote: > On 6/26/2012 12:26 PM, Andreas Leitgeb wrote: >> [...] >> Oh, seems I got the motivation wrong, then. If that was your point, >> then obviously my essay didn't address that. Just to recollect what I wrote earlier: > Long lived objects which live shorter than the application (i.e. not > classes) are actually the Achilles heel of GC because it is very hard > to tune the collector in a way that it does not visit those long > living objects too often and yet run often enough to ensure enough > free memory is available. > On 21.06.2012 20:24, Aaron W. Hsu wrote: >> 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. me again: > I once mused about such a thing as well. I you think a bit longer > about this then you'll notice that it won't work: these objects still > have to be visited because they may have references to other objects > not in the uncollectable space. You'll probably do not gain much - > if anything at all. >> My motivation was having >> some large objects, whose memory could be explicitly freed, as soon as >> the memory was no longer needed in the program. > > And my question, still, is "Why?" At a guess, the intent is > to make the large objects' memory available for re-use right away, > without waiting for GC (and thereby, perhaps, reducing the number > of GC's required). But in all the scenarios so far, I think it's > been shown that the effort to support manual release safely is at > least as great as that of a GC, maybe more. I second that: if memory is low and the object is eligible for collection, GC will take it away anyway. If memory isn't low, any object lurking around doesn't hurt. In fact, it might be better to have the space occupied by a single large object instead of many small objects because that makes so many objects less to visit... Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/