From adamh at basis.com Mon May 12 11:57:03 2008 From: adamh at basis.com (Adam Hawthorne) Date: Mon, 12 May 2008 14:57:03 -0400 Subject: Question about GCOverheadLimit Message-ID: <200805121457.07091.adamh@basis.com> Hi all, I just have a quick question about the GC Overhead Limit. The docs say: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. What "total time" is it referring to there? Thanks, Adam -- Adam Hawthorne Software Engineer BASIS International Ltd. www.basis.com +1.505.345.5232 Phone -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20080512/99286f0f/attachment.bin From Jon.Masamitsu at Sun.COM Mon May 12 12:35:01 2008 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Mon, 12 May 2008 12:35:01 -0700 Subject: Question about GCOverheadLimit In-Reply-To: <200805121457.07091.adamh@basis.com> References: <200805121457.07091.adamh@basis.com> Message-ID: <48289BE5.3050906@Sun.COM> The total time is measured as the time from the end of a full GC to the end of the next full GC. Adam Hawthorne wrote: > Hi all, > > I just have a quick question about the GC Overhead Limit. The docs say: if > more than 98% of the total time is spent in garbage collection and less than > 2% of the heap is recovered, an OutOfMemoryError will be thrown. > > What "total time" is it referring to there? > > Thanks, > > Adam > > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From fw at deneb.enyo.de Tue May 13 00:40:34 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 13 May 2008 09:40:34 +0200 Subject: java.lang.OutOfMemoryError: nativeGetNewTLA In-Reply-To: <304E9E55F6A4BE4B910C2437D4D1B4960A622D2BEA@MERCMBX14.na.sas.com> (Keith Holdaway's message of "Sat, 26 Apr 2008 10:45:09 -0400") References: <9BADD5B8-F9DA-4656-843B-7D44FF36963A@mugfu.com> <477C09ED.9020400@Sun.COM> <22133221-306B-41D3-AE57-155876104354@mugfu.com> <477C1718.70004@Sun.COM> <304E9E55F6A4BE4B910C2437D4D1B49608FC799162@MERCMBX14.na.sas.com> <5d649bdb0801031600j7d36c5e9k4049421726346cf3@mail.gmail.com> <477D8067.8050802@Sun.COM> <304E9E55F6A4BE4B910C2437D4D1B4960A622D2BEA@MERCMBX14.na.sas.com> Message-ID: <87hcd2abyl.fsf@mid.deneb.enyo.de> * Keith Holdaway: > Any ideas what this refers to? > > java.lang.OutOfMemoryError: nativeGetNewTLA It's likely a stack trace from Bea JRockit, and not from Hotspot. From tony.printezis at sun.com Thu May 29 13:52:06 2008 From: tony.printezis at sun.com (Tony Printezis) Date: Thu, 29 May 2008 16:52:06 -0400 Subject: What values do use for MaxTenuringThreshold? Message-ID: <483F1776.6000606@sun.com> (this is a follow-up to a discussion on the hotspot-gc-dev list) We're trying to take a quick poll on what values you use for MaxTenuringThreshold and whether the decrease in age field size from 5 to 4 bits (from 1.5u6) seemed to have affected the performance of your app. This is the thread, if you're interested: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html Tony, HS GC Group -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From jamesnichols3 at gmail.com Fri May 30 06:37:10 2008 From: jamesnichols3 at gmail.com (James Nichols) Date: Fri, 30 May 2008 09:37:10 -0400 Subject: What values do use for MaxTenuringThreshold? In-Reply-To: <483F1776.6000606@sun.com> References: <483F1776.6000606@sun.com> Message-ID: <83a51e120805300637l1494bceasaddcc4a01680f6c9@mail.gmail.com> Hey Tony, A while back I exchanged some messages about the tenuring threshold on this list, see: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2008-January/000027.html My MaxTenuringThreshold at the time was set to 30, but if you look at the plots attached to the email thread above, you can see it never went above 16. I had MTT set so high since I had a lot of short-lived data that would get promoted and GC'd when the next tenured area collection ran, which to me meant they were getting promoted too soon. I was using 1.5.0_12 and was always on it, so the change in bit size for the age value wasn't that big of deal, I guess. I was somewhat perplexed at the time as to why the threshold never went above 16 and now I know why. I currently have it set to 4 (along with a modified survivor space size), since I had a lot of unnecessary copying and the premature promotion issues discussed in the above post. My experience has shown that having a really high MTT leads to a ton of extra copying. Likewise, I'm not sure in what circumstances NeverTenure would be a good idea. The whole point of generational garbage collection is to get junk that sticks around a while out of the hot area of memory, isn't it? Both of these settings seem to indicate that you'ld be better off using non generational GC. For what it's worth, if I am working with a new application that has gc problems on a jvm that hasn't been tuned, I would set MTT to 4 with CMS and see how it worked and iterate from there. In Summary, current MTT=4. As to the change impacting performance, I'm not sure since I never ran this particular app on a rev of the JVM that old. Jim On Thu, May 29, 2008 at 4:52 PM, Tony Printezis wrote: > (this is a follow-up to a discussion on the hotspot-gc-dev list) > > We're trying to take a quick poll on what values you use for > MaxTenuringThreshold and whether the decrease in age field size from 5 > to 4 bits (from 1.5u6) seemed to have affected the performance of your app. > > This is the thread, if you're interested: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html > > Tony, HS GC Group > > -- > ---------------------------------------------------------------------- > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > | | MS BUR02-311 | > | e-mail: tony.printezis at sun.com | 35 Network Drive | > | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | > ---------------------------------------------------------------------- > e-mail client: Thunderbird (Solaris) > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20080530/421da1d1/attachment.html From tony.printezis at sun.com Fri May 30 09:18:14 2008 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 30 May 2008 12:18:14 -0400 Subject: What values do use for MaxTenuringThreshold? In-Reply-To: <83a51e120805300637l1494bceasaddcc4a01680f6c9@mail.gmail.com> References: <483F1776.6000606@sun.com> <83a51e120805300637l1494bceasaddcc4a01680f6c9@mail.gmail.com> Message-ID: <484028C6.3090904@sun.com> Hi Jim, See inline. James Nichols wrote: > Hey Tony, > > A while back I exchanged some messages about the tenuring threshold on > this list, see: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2008-January/000027.html > > My MaxTenuringThreshold at the time was set to 30, but if you look at > the plots attached to the email thread above, you can see it never > went above 16. I had MTT set so high since I had a lot of short-lived > data that would get promoted and GC'd when the next tenured area > collection ran, which to me meant they were getting promoted too > soon. I was using 1.5.0_12 and was always on it, so the change in > bit size for the age value wasn't that big of deal, I guess. I was > somewhat perplexed at the time as to why the threshold never went > above 16 and now I know why. I currently have it set to 4 (along with > a modified survivor space size), since I had a lot of unnecessary > copying and the premature promotion issues discussed in the above post. Thanks for the feedback. > My experience has shown that having a really high MTT leads to a ton > of extra copying. It really depends on the application / requirements / etc. A lot of the time the extra copying is worth it, if you can eventually reclaim the majority of those objects in the young generation and avoid promoting them. > Likewise, I'm not sure in what circumstances NeverTenure would be a > good idea. If you have quite a lot of free space in your survivor spaces, maybe you can retain objects in the young gen much longer with NeverTenure and reclaim them there, saving promoting them. But, I'd guess, in most cases, space in the survivor spaces will be at a premium. So, the NeverTenure policy (as I think I said in a previous e-mail?) could either prematurely promote objects or causing excessive object copying (or both!). I'm really curious whether anyone is using it and seeing a benefit from it. > The whole point of generational garbage collection is to get junk that > sticks around a while out of the hot area of memory, isn't it? I would actually say it's the opposite; to cheaply get rid of the short-lived "chaff". > Both of these settings seem to indicate that you'ld be better off > using non generational GC. Having observed GC patterns for Java applications for a long time, I don't think there would be many cases where a non-generational GC would win (I'm referring to real apps here, not small micro benchmarks...). > For what it's worth, if I am working with a new application that has > gc problems on a jvm that hasn't been tuned, I would set MTT to 4 with > CMS and see how it worked and iterate from there. > > In Summary, current MTT=4. As to the change impacting performance, > I'm not sure since I never ran this particular app on a rev of the JVM > that old. Thanks again for the feedback, Tony > On Thu, May 29, 2008 at 4:52 PM, Tony Printezis > > wrote: > > (this is a follow-up to a discussion on the hotspot-gc-dev list) > > We're trying to take a quick poll on what values you use for > MaxTenuringThreshold and whether the decrease in age field size from 5 > to 4 bits (from 1.5u6) seemed to have affected the performance of > your app. > > This is the thread, if you're interested: > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html > > Tony, HS GC Group > > -- > ---------------------------------------------------------------------- > | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | > | | MS BUR02-311 | > | e-mail: tony.printezis at sun.com > | 35 Network Drive | > | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | > ---------------------------------------------------------------------- > e-mail client: Thunderbird (Solaris) > > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > > -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris) From Y.S.Ramakrishna at Sun.COM Fri May 30 12:15:58 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 30 May 2008 12:15:58 -0700 Subject: What values do use for MaxTenuringThreshold? In-Reply-To: <484028C6.3090904@sun.com> References: <483F1776.6000606@sun.com> <83a51e120805300637l1494bceasaddcc4a01680f6c9@mail.gmail.com> <484028C6.3090904@sun.com> Message-ID: Some random thoughts/ramblings below ... > > My experience has shown that having a really high MTT leads to a ton > > > of extra copying. > It really depends on the application / requirements / etc. A lot of > the > time the extra copying is worth it, if you can eventually reclaim the > > majority of those objects in the young generation and avoid promoting > them. Or, put another way, it depends on the relative costs (where cost is relative to an application-specific utility function) of the potentially repeated copying versus the cost of reclaiming them in the old generation (where the cost of reclaiming them in the old generation might include not just the measured cost of old gen collection, but also the cost of potentially increased mutator costs because of loss of spatial locality, or increase in young gen costs because of greater occupancy of the old generation for example increasing card-scanning costs etc.) > > Likewise, I'm not sure in what circumstances NeverTenure would be > a > > good idea. > If you have quite a lot of free space in your survivor spaces, maybe > you > can retain objects in the young gen much longer with NeverTenure and > reclaim them there, saving promoting them. But, I'd guess, in most > cases, space in the survivor spaces will be at a premium. So, the > NeverTenure policy (as I think I said in a previous e-mail?) could > either prematurely promote objects or causing excessive object copying > > (or both!). I'm really curious whether anyone is using it and seeing a > > benefit from it. The flip answer is that it's useful if you want to avoid promotion altogether (perhaps because the cost of an old generation collection is considered excessive given the user's utility function) and your objects all die just a little after 2^n scavenges, n the number of age bits available. > > The whole point of generational garbage collection is to get junk > that > > sticks around a while out of the hot area of memory, isn't it? > I would actually say it's the opposite; to cheaply get rid of the > short-lived "chaff". > > Both of these settings seem to indicate that you'ld be better off > > > using non generational GC. I agree that used in the manner of NeverTenure scenario I described above, one is essentially using a generational collector in non-generational mode, if you will. > Having observed GC patterns for Java applications for a long time, I > don't think there would be many cases where a non-generational GC > would > win (I'm referring to real apps here, not small micro benchmarks...). There is probably a small class of very specific applications (such as seen sometimes in telecoms -- and occasionally in certain ecommerce settings as Peter will attest -- where there is no state associated with very short-lived transactions for example) which are essentially non-generational in the time-scale of the scavenges. At a finer time-scale I am sure some generational behaviour would emerge even in these applications. However, to the extent that one can in most such cases simulate the non-generational configuration from a generational configuration that never promotes and does not allocate any space for the old generation, one would feel comfortable using generational collector implementations always (because it appears to be a simulation, not a bisimulation: it would seem that a non-generational collector would not be able to simulate a generational one, or may be we should not be splitting hairs on the semantics of what is or is not a non-generational collector). -- ramki From Y.S.Ramakrishna at Sun.COM Fri May 30 12:39:02 2008 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Fri, 30 May 2008 12:39:02 -0700 Subject: What values do use for MaxTenuringThreshold? In-Reply-To: References: <483F1776.6000606@sun.com> <83a51e120805300637l1494bceasaddcc4a01680f6c9@mail.gmail.com> <484028C6.3090904@sun.com> Message-ID: Please ignore this:- > There is probably a small class of very specific applications (such as > seen sometimes in telecoms -- and occasionally in certain ecommerce > settings as Peter will attest -- where there is no state associated with > very short-lived transactions for example) which are essentially > non-generational in the time-scale of the scavenges. At a finer time-scale > I am sure some generational behaviour would emerge even in these > applications. What I described above certainly conforms to the accepted definition of "generational behaviour" -- most objects die young -- in this case it turns out that the small fraction of objects that do not die very young die in middle age; they are not "long-lived" for some notion of "long". In fact this would be a highly generational application that never needs to use the older generation. I guess i entangled generational configurations and generational behaviour and hence my confused ramblings for which my apologies ... :-) -- ramki From tony.printezis at sun.com Fri May 30 13:04:43 2008 From: tony.printezis at sun.com (Tony Printezis) Date: Fri, 30 May 2008 16:04:43 -0400 Subject: What values do use for MaxTenuringThreshold? In-Reply-To: References: <483F1776.6000606@sun.com> <83a51e120805300637l1494bceasaddcc4a01680f6c9@mail.gmail.com> <484028C6.3090904@sun.com> Message-ID: <48405DDB.4000902@sun.com> Ramki, Y Srinivas Ramakrishna wrote: > Please ignore this:- > > >> There is probably a small class of very specific applications (such as >> seen sometimes in telecoms -- and occasionally in certain ecommerce >> settings as Peter will attest -- where there is no state associated with >> very short-lived transactions for example) which are essentially >> non-generational in the time-scale of the scavenges. At a finer time-scale >> I am sure some generational behaviour would emerge even in these >> applications. >> > > What I described above certainly conforms to the accepted definition of > "generational behaviour" -- most objects die young -- in this case > it turns out that the small fraction of objects that do not die very young die in middle > age; they are not "long-lived" for some notion of "long". > > In fact this would be a highly generational application that never needs > to use the older generation. > (playing Devil's advocate here a bit!) It is indeed a highly generational application. Most Java JVMs use a two-generation approach and, for better or worse, we seem to always try to fit the an application's patter into that. For many, it works. However, for some (like the above), it might not work out as well (due to the medium-lived objects generally surviving the young generation). But it doesn't mean the app is not generational; in fact, maybe a 3-generation system might fit such applications better. Tony > I guess i entangled generational configurations and generational behaviour > and hence my confused ramblings for which my apologies ... :-) > -- ramki > -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Solaris)