Path: csiph.com!usenet.pasdenom.info!news.albasani.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: Thu, 21 Jun 2012 23:46:23 +0200 Lines: 102 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net 3s6FXnmfGuXdBbMdDIbVCgilvye8Y1w3YCULY/Wv0MxfRcMiUxAN5Tr8+kuGUTYJQ= Cancel-Lock: sha1:zVOheFhE9ZJagK+lc0HfTljUwG8= 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:15496 On 21.06.2012 20:24, Aaron W. Hsu wrote: > On Wed, 20 Jun 2012 21:19:01 -0400, Arne Vajh=F8j wrote: > >> On 6/16/2012 12:51 PM, Aaron W. Hsu wrote: > >>> In some languages (Chez Scheme) I can get quite explicit >>> control over when and how garbage collection occurs, which can make i= t >>> possible to do very fine grained things to avoid some of the corner >>> case problems that can manifest in garbage collected languages. >> >> What do you mean by corner case? > > So, you mentioned that you thought real-time was not a corner case, but= I > guess I would consider it one compared to general purpose programming i= n > the majority. However, there are other, less broad things where I have > found it extremely helpful to have control of the collector. Your statement illustrates one of the biggest problems of Java (or maybe = even any GC'ed language): GC should be automatic but humans still need=20 control (just count the collectors and all the JVM options for GC)=20 because the automatisms are not good enough (yet). Question is: will=20 they ever be good enough that we can get by without settings - or at=20 least a dramatic reduced number of settings? I do not see that coming=20 soon. Sun took seven or eight years from the first experimental=20 implementation of G1 to production ready. Go figure. > For instance, I implemented a number of weak pointer structures which > required me to be able to extend what happened during collections. This= > can be done in user-space efficiently if there is an efficient way to > extend the garbage collector and trigger events to occur on certain > conditions. This would be an example of a relatively obscure data > structure that can be really useful in some situations. Can you explain what you did at collection time? I am asking because=20 anytime I would prefer to do cleanup when I do not need an object any=20 more. This is the typical resource deallocation in a finally block or=20 other piece of code which is invoked after some operation has finished=20 (hooks for example). Advantage is that you free your resources as early = as possible and do not need to cope with the downsides of finalizers.=20 Finalizers in Java have so many disadvantages (i.e. when making objects=20 live again, effects on GC performance) that they are short of being=20 deprecated - at least that's my impression from what I read. > 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 memo= ry > until the end when I can explicitly trigger the collector at that point= =2E But what do you gain if a GC pause occurs after this operation? The=20 time is spent either way. Btw, depending on collector chosen you might=20 not even notice that it is running because it works in separate threads. > 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. Long lived objects which live shorter than the application (i.e. not=20 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=20 objects too often and yet run often enough to ensure enough free memory=20 is available. > 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. 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=20 be visited because they may have references to other objects not in the=20 uncollectable space. You'll probably do not gain much - if anything at a= ll. > 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. Use many cores and G1. At least try it out. Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/