From Jon.Masamitsu at Sun.COM Tue Jul 10 15:23:50 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Tue, 10 Jul 2007 15:23:50 -0700 Subject: -XX:+MaximizeHeapSize? Message-ID: <469406F6.6020806@Sun.COM> We've heard from users in the past that it would be nice if there was no maximum heap size limit. Users say they don't know what the limit for their application is and have to experiment to find an adequate value. I did the following refworkload experiments. Ran "reference_client" and "startup2" (sets of client application like benchmarks) with the -client (uses the serial GC which does not have GC ergonomics) and a 1g heap. The point of this experiment was to see if the size of the committed heap increased because of the 1g heap size limit. There was no discernible difference in the committed size of the heap nor in the amount of GC work. I ran "reference_server" (set of server application like benchmarks) with -server and the parallel GC (does has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default) and with -XX:DefaultMaxRAM=1700m (the amount of physical memory on the platform minus some for the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment was to see if the GC ergonomics drove the heap to sizes larger that the 1g default limit. As one would expect the heaps for some benchmarks grew considerably (up to the higher limits in some cases) and for some the heaps did not change. I think that these results are not unexpected. The heap sizing policy used by the serial collector depends on the amount of live data and the live data for the client like applications fit nicely into the 64m default heap size (i.e., the larger 1g heap was not needed). On the larger server like benchmarks run with GC ergonomics, the high default throughput goal of GC ergonomics means that some benchmarks will just use as much heap as they can get in trying to reach the throughput goal. I'd like to propose an additional policy under a new command line flag. Let me use MaximizeHeapSize for the name for now. If MaximizeHeapSize is set, the VM will calculate the amount of physical memory on the platform and try to use that as the upper limit on the heap size. As with the current GC ergonomics the upper limit will be ~4g on a 32bit system. If the VM cannot actually reserve that amount of space at initialization, it will try reserving some smaller amounts until it succeeds. There will be some minimum size (probably 64m) that it will not go below. The user would have to turn MaximizeHeapSize on explicitly. It will be off by default until we get some experience with it. Users who turn it on and also use GC ergonomics will manage the heap size via a smaller or larger throughput goal (i.e., the larger the throughput goal the more heap space the VM will try to get to meet the throughput goal). For the non ergonomics collectors it should only matter if the application would otherwise have bumped into a heap limit (i.e., the application would have thrown an out-of-memory or just spent too much time doing garbage collections because the heap limit set by default or on the command line was too small). In that case this change would allow the application to get the additional space it needs. I expect there will be some corner cases or bugs where the heap will grow to the limit when it shouldn't. Comments on this proposal? From fw at deneb.enyo.de Wed Jul 11 00:25:10 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 11 Jul 2007 09:25:10 +0200 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <469406F6.6020806@Sun.COM> (Jon Masamitsu's message of "Tue, 10 Jul 2007 15:23:50 -0700") References: <469406F6.6020806@Sun.COM> Message-ID: <87ps2z8krt.fsf@mid.deneb.enyo.de> * Jon Masamitsu: > Comments on this proposal? In this mode, you really should mmap the heap PROT_NONE in the beginning (so that you reserve a continuous memory area, which is required AFAIK), and use mprotect to actually allocate backing store when the used portion of the heap grows. Without this change, it's impossible to run more than two or three VMs on systems which do not support memory overcommitment (which is getting more and more common on Linux). From Jon.Masamitsu at Sun.COM Wed Jul 11 06:34:43 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 11 Jul 2007 06:34:43 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <87ps2z8krt.fsf@mid.deneb.enyo.de> References: <469406F6.6020806@Sun.COM> <87ps2z8krt.fsf@mid.deneb.enyo.de> Message-ID: <4694DC73.2040401@Sun.COM> Florian Weimer wrote: >* Jon Masamitsu: > > > >>Comments on this proposal? >> >> > >In this mode, you really should mmap the heap PROT_NONE in the >beginning (so that you reserve a continuous memory area, which is >required AFAIK), and use mprotect to actually allocate backing store >when the used portion of the heap grows. Without this change, it's >impossible to run more than two or three VMs on systems which do not >support memory overcommitment (which is getting more and more common >on Linux). > > Yes, hotspot does do a reserve of a continuous address space for the entire heap at initialization with an mmap call using MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS As the heap is actually expanded the space is mmap'ed with MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS so it can actually be used. See the reserve_memory() and commit_memory() methods in os/linux/vm/os_linux.cpp for the details. Thanks. From Paul.Hohensee at Sun.COM Wed Jul 11 07:29:02 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE) Date: Wed, 11 Jul 2007 10:29:02 -0400 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <469406F6.6020806@Sun.COM> References: <469406F6.6020806@Sun.COM> Message-ID: <4694E92E.6070108@sun.com> You might try running the reference_client and startup2 using the client vm and the parallel collector (UseParallelGC, right?) with a 1gb heap. I think you'll see startup time improvements along with a footprint increase. At least that's what I saw experimenting with 1.4.2 some years ago. Got +20% on startup then, but have no idea what would happen now. Larger heap sizes really need a parallel collector to avoid excessive pause times. 1g is about the outer limit of what the serial collector can handle: the 1.4.2 experiments showed it to be ~20 slower than the parallel collector on jbb2k with that heap size. Acceptable, but not optimal. So thoughtless use of MaximizeHeapSize could result in an unacceptable gc time increase. Maybe instead we should have a switch that enables server class machine heap ergo in the client (and server, though it's somewhat redundant) vm? Paul Jon Masamitsu wrote: > We've heard from users in the past that it would be nice if > there was no maximum heap size limit. Users say > they don't know what the limit for their application is and > have to experiment to find an adequate value. > > I did the following refworkload experiments. > > Ran "reference_client" and "startup2" (sets of client > application like benchmarks) with the -client > (uses the serial GC which does not have GC ergonomics) and > a 1g heap. The point of this experiment was to see if the > size of the committed heap increased because of the 1g heap > size limit. There was no discernible difference in the > committed size of the heap nor in the amount of GC work. > > I ran "reference_server" (set of server application like > benchmarks) with -server and the parallel GC (does > has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default) > and with -XX:DefaultMaxRAM=1700m (the amount of physical > memory on the platform minus some for > the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment > was to see if the > GC ergonomics drove the heap to sizes larger that the 1g > default limit. As one would expect the heaps for some > benchmarks grew considerably (up to the higher limits > in some cases) and for some the heaps did not change. > > I think that these results are not unexpected. The heap sizing > policy used by the serial collector depends on the amount of > live data and the live data for the client like applications > fit nicely into the 64m default heap size (i.e., the larger > 1g heap was not needed). On the larger server like benchmarks run > with GC ergonomics, the high default throughput goal of GC > ergonomics means that some benchmarks will just use as much > heap as they can get in trying to reach the throughput goal. > > I'd like to propose an additional policy under a new command line > flag. Let me use MaximizeHeapSize for the name for now. If > MaximizeHeapSize is set, the VM will calculate > the amount of physical memory on the platform and > try to use that as the upper limit on the heap size. As > with the current GC ergonomics the upper limit will > be ~4g on a 32bit system. If the VM cannot actually > reserve that amount of space at initialization, it will > try reserving some smaller amounts until it succeeds. There > will be some minimum size (probably 64m) that it will not > go below. > > The user would have to turn MaximizeHeapSize on > explicitly. It will be off by default until we get some > experience with it. Users who turn it on and also use > GC ergonomics will manage the heap size via > a smaller or larger throughput goal (i.e., the larger > the throughput goal the more heap space the VM will > try to get to meet the throughput goal). > For the non ergonomics collectors it should only matter > if the application would otherwise have bumped into a > heap limit (i.e., the application would have thrown > an out-of-memory or just spent too much time doing > garbage collections because the heap limit set by > default or on the command line was too small). In that > case this change would allow the application to > get the additional space it needs. I expect there will > be some corner cases or bugs where the heap will grow to > the limit when it shouldn't. > Comments on this proposal? > > From Jon.Masamitsu at Sun.COM Wed Jul 11 08:06:56 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 11 Jul 2007 08:06:56 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <4694E92E.6070108@sun.com> References: <469406F6.6020806@Sun.COM> <4694E92E.6070108@sun.com> Message-ID: <4694F210.4000207@Sun.COM> Paul Hohensee - Java SE wrote: > You might try running the reference_client and startup2 using the > client vm > and the parallel collector (UseParallelGC, right?) with a 1gb heap. I > think > you'll see startup time improvements along with a footprint increase. At > least that's what I saw experimenting with 1.4.2 some years ago. Got > +20% > on startup then, but have no idea what would happen now. With today's GC ergonomics (not server class default heap sizing), I would expect the GC to grow the heap faster than non ergonomics GC so there would be a faster start up and larger footprint (assuming the start up continued long enough to do ~10 or more GC's). > > Larger heap sizes really need a parallel collector to avoid excessive > pause > times. 1g is about the outer limit of what the serial collector can > handle: > the 1.4.2 experiments showed it to be ~20 slower than the parallel > collector > on jbb2k with that heap size. Acceptable, but not optimal. So > thoughtless > use of MaximizeHeapSize could result in an unacceptable gc time increase. > Maybe instead we should have a switch that enables server class machine > heap ergo in the client (and server, though it's somewhat redundant) vm? You mean such as the flag "AlwaysActAsServerClassMachine". Yes, there are more flags in hotspot than the human brain can hold. :^) Careless use of MaximizeHeapSize would sometimes result in sub-optimal GC configurations but we would be trading that off against less frequent out-of-memory exceptions that are the result of a sub-optimal choice of the maximum heap size and trading that off against the times when the applications continues to run in a heap that is too small (so is spending too much time in GC). I think the usefulness of MaximizeHeapSize is a question that we can still consider in a non-ergonomics, non server-class world. It's an ease of use thing which I hope in that world will mostly do no harm and relieve the user of having to make a blind decision. In the GC ergonomics, server-class world MaximizeHeapSize changes the choice from maximum heap size to "pause time goal" and "throughput goal" which is where I think we should be heading. > Paul > > Jon Masamitsu wrote: > >> We've heard from users in the past that it would be nice if >> there was no maximum heap size limit. Users say >> they don't know what the limit for their application is and >> have to experiment to find an adequate value. >> >> I did the following refworkload experiments. >> >> Ran "reference_client" and "startup2" (sets of client >> application like benchmarks) with the -client >> (uses the serial GC which does not have GC ergonomics) and >> a 1g heap. The point of this experiment was to see if the >> size of the committed heap increased because of the 1g heap >> size limit. There was no discernible difference in the >> committed size of the heap nor in the amount of GC work. >> >> I ran "reference_server" (set of server application like >> benchmarks) with -server and the parallel GC (does >> has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default) >> and with -XX:DefaultMaxRAM=1700m (the amount of physical >> memory on the platform minus some for >> the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment >> was to see if the >> GC ergonomics drove the heap to sizes larger that the 1g >> default limit. As one would expect the heaps for some >> benchmarks grew considerably (up to the higher limits >> in some cases) and for some the heaps did not change. >> >> I think that these results are not unexpected. The heap sizing >> policy used by the serial collector depends on the amount of >> live data and the live data for the client like applications >> fit nicely into the 64m default heap size (i.e., the larger >> 1g heap was not needed). On the larger server like benchmarks run >> with GC ergonomics, the high default throughput goal of GC >> ergonomics means that some benchmarks will just use as much >> heap as they can get in trying to reach the throughput goal. >> >> I'd like to propose an additional policy under a new command line >> flag. Let me use MaximizeHeapSize for the name for now. If >> MaximizeHeapSize is set, the VM will calculate >> the amount of physical memory on the platform and >> try to use that as the upper limit on the heap size. As >> with the current GC ergonomics the upper limit will >> be ~4g on a 32bit system. If the VM cannot actually >> reserve that amount of space at initialization, it will >> try reserving some smaller amounts until it succeeds. There >> will be some minimum size (probably 64m) that it will not >> go below. >> >> The user would have to turn MaximizeHeapSize on >> explicitly. It will be off by default until we get some >> experience with it. Users who turn it on and also use >> GC ergonomics will manage the heap size via >> a smaller or larger throughput goal (i.e., the larger >> the throughput goal the more heap space the VM will >> try to get to meet the throughput goal). >> For the non ergonomics collectors it should only matter >> if the application would otherwise have bumped into a >> heap limit (i.e., the application would have thrown >> an out-of-memory or just spent too much time doing >> garbage collections because the heap limit set by >> default or on the command line was too small). In that >> case this change would allow the application to >> get the additional space it needs. I expect there will >> be some corner cases or bugs where the heap will grow to >> the limit when it shouldn't. >> Comments on this proposal? >> >> > From Peter.Kessler at Sun.COM Wed Jul 11 10:45:54 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 11 Jul 2007 10:45:54 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <469406F6.6020806@Sun.COM> References: <469406F6.6020806@Sun.COM> Message-ID: <46951752.10806@Sun.COM> Jon Masamitsu wrote: > We've heard from users in the past that it would be nice if > there was no maximum heap size limit. Users say > they don't know what the limit for their application is and > have to experiment to find an adequate value. > > I did the following refworkload experiments. > > Ran "reference_client" and "startup2" (sets of client > application like benchmarks) with the -client > (uses the serial GC which does not have GC ergonomics) and > a 1g heap. The point of this experiment was to see if the > size of the committed heap increased because of the 1g heap > size limit. There was no discernible difference in the > committed size of the heap nor in the amount of GC work. > > I ran "reference_server" (set of server application like > benchmarks) with -server and the parallel GC (does > has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default) > and with -XX:DefaultMaxRAM=1700m (the amount of physical > memory on the platform minus some for > the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment > was to see if the > GC ergonomics drove the heap to sizes larger that the 1g > default limit. As one would expect the heaps for some > benchmarks grew considerably (up to the higher limits > in some cases) and for some the heaps did not change. > > I think that these results are not unexpected. The heap sizing > policy used by the serial collector depends on the amount of > live data and the live data for the client like applications > fit nicely into the 64m default heap size (i.e., the larger > 1g heap was not needed). On the larger server like benchmarks run > with GC ergonomics, the high default throughput goal of GC > ergonomics means that some benchmarks will just use as much > heap as they can get in trying to reach the throughput goal. > > I'd like to propose an additional policy under a new command line > flag. Let me use MaximizeHeapSize for the name for now. If > MaximizeHeapSize is set, the VM will calculate > the amount of physical memory on the platform and > try to use that as the upper limit on the heap size. As > with the current GC ergonomics the upper limit will > be ~4g on a 32bit system. If the VM cannot actually > reserve that amount of space at initialization, it will > try reserving some smaller amounts until it succeeds. There > will be some minimum size (probably 64m) that it will not > go below. > > The user would have to turn MaximizeHeapSize on > explicitly. It will be off by default until we get some > experience with it. Users who turn it on and also use > GC ergonomics will manage the heap size via > a smaller or larger throughput goal (i.e., the larger > the throughput goal the more heap space the VM will > try to get to meet the throughput goal). > For the non ergonomics collectors it should only matter > if the application would otherwise have bumped into a > heap limit (i.e., the application would have thrown > an out-of-memory or just spent too much time doing > garbage collections because the heap limit set by > default or on the command line was too small). In that > case this change would allow the application to > get the additional space it needs. I expect there will > be some corner cases or bugs where the heap will grow to > the limit when it shouldn't. > Comments on this proposal? Don't forget to leave some address space for thread stacks, other libraries, malloc space, etc. A simple backoff policy from trying to reserve all of memory might be too simplistic. I don't know how to estimate beforehand how many thread stacks an app will need. :-) ... peter From Andreas.Sterbenz at Sun.COM Wed Jul 11 10:53:00 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Wed, 11 Jul 2007 10:53:00 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <469406F6.6020806@Sun.COM> References: <469406F6.6020806@Sun.COM> Message-ID: <469518FC.4080504@sun.com> Jon Masamitsu wrote: > > I'd like to propose an additional policy under a new command line > flag. Let me use MaximizeHeapSize for the name for now. If > MaximizeHeapSize is set, the VM will calculate > the amount of physical memory on the platform and > try to use that as the upper limit on the heap size. As > with the current GC ergonomics the upper limit will > be ~4g on a 32bit system. If the VM cannot actually > reserve that amount of space at initialization, it will > try reserving some smaller amounts until it succeeds. There > will be some minimum size (probably 64m) that it will not > go below. Does this proposal address the perm gen as well? Or will it still be necessary to set the size of the perm gen manually? Andreas. From Jon.Masamitsu at Sun.COM Wed Jul 11 10:58:12 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 11 Jul 2007 10:58:12 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <469518FC.4080504@sun.com> References: <469406F6.6020806@Sun.COM> <469518FC.4080504@sun.com> Message-ID: <46951A34.7090301@Sun.COM> This initial proposal does not include the perm gen. Andreas Sterbenz wrote: > Jon Masamitsu wrote: > >> >> I'd like to propose an additional policy under a new command line >> flag. Let me use MaximizeHeapSize for the name for now. If >> MaximizeHeapSize is set, the VM will calculate >> the amount of physical memory on the platform and >> try to use that as the upper limit on the heap size. As >> with the current GC ergonomics the upper limit will >> be ~4g on a 32bit system. If the VM cannot actually >> reserve that amount of space at initialization, it will >> try reserving some smaller amounts until it succeeds. There >> will be some minimum size (probably 64m) that it will not >> go below. > > > Does this proposal address the perm gen as well? Or will it still be > necessary to set the size of the perm gen manually? > > Andreas. From Jon.Masamitsu at Sun.COM Wed Jul 11 12:07:47 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 11 Jul 2007 12:07:47 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <46951752.10806@Sun.COM> References: <469406F6.6020806@Sun.COM> <46951752.10806@Sun.COM> Message-ID: <46952A83.4090205@Sun.COM> Peter B. Kessler wrote: > ... > > Don't forget to leave some address space for thread stacks, > other libraries, malloc space, etc. A simple backoff policy > from trying to reserve all of memory might be too simplistic. > I don't know how to estimate beforehand how many thread stacks > an app will need. :-) > Yes, it would be very annoying not to be able to start all the threads you needed. There's no feedback from a failed thread start to the GC so that we would know we should shrink the reserved size of the heap and try the thread creation again. Short of building some feedback mechanism we'd have to do something static like leaving a fixed amount of space for everything else. Perhaps this is not much of an improvement. From fw at deneb.enyo.de Wed Jul 11 12:33:09 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 11 Jul 2007 21:33:09 +0200 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <4694DC73.2040401@Sun.COM> (Jon Masamitsu's message of "Wed, 11 Jul 2007 06:34:43 -0700") References: <469406F6.6020806@Sun.COM> <87ps2z8krt.fsf@mid.deneb.enyo.de> <4694DC73.2040401@Sun.COM> Message-ID: <87fy3uzqfe.fsf@mid.deneb.enyo.de> * Jon Masamitsu: > Yes, hotspot does do a reserve of a continuous address space for the > entire heap at initialization with an mmap call using > > MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS > > As the heap is actually expanded the space is mmap'ed with > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS > > so it can actually be used. See the reserve_memory() and > commit_memory() methods > in os/linux/vm/os_linux.cpp for the details. This is not sufficient in vm.overcommit_memory = 2 mode. Without PROT_NONE, the allocation still counts against the beancounter limit. Perhaps this is a kernel bug, but is has been this way for quite some time. From Y.S.Ramakrishna at Sun.COM Wed Jul 11 14:33:40 2007 From: Y.S.Ramakrishna at Sun.COM (Y Srinivas Ramakrishna) Date: Wed, 11 Jul 2007 14:33:40 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <87fy3uzqfe.fsf@mid.deneb.enyo.de> References: <469406F6.6020806@Sun.COM> <87ps2z8krt.fsf@mid.deneb.enyo.de> <4694DC73.2040401@Sun.COM> <87fy3uzqfe.fsf@mid.deneb.enyo.de> Message-ID: Is there dependable public documentation on the semantics of various memory overcommit modes in Linux and especially the one you have in mind here? Pointers, anyone? -- ramki. ----- Original Message ----- From: Florian Weimer Date: Wednesday, July 11, 2007 12:33 pm Subject: Re: -XX:+MaximizeHeapSize? To: Jon Masamitsu Cc: hotspot-gc-dev at openjdk.java.net > * Jon Masamitsu: > > > Yes, hotspot does do a reserve of a continuous address space for the > > entire heap at initialization with an mmap call using > > > > MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS > > > > As the heap is actually expanded the space is mmap'ed with > > > > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS > > > > so it can actually be used. See the reserve_memory() and > > commit_memory() methods > > in os/linux/vm/os_linux.cpp for the details. > > This is not sufficient in vm.overcommit_memory = 2 mode. Without > PROT_NONE, the allocation still counts against the beancounter limit. > Perhaps this is a kernel bug, but is has been this way for quite some > time. From fw at deneb.enyo.de Fri Jul 13 12:56:46 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 13 Jul 2007 21:56:46 +0200 Subject: -XX:+MaximizeHeapSize? In-Reply-To: (Y. Srinivas Ramakrishna's message of "Wed, 11 Jul 2007 14:33:40 -0700") References: <469406F6.6020806@Sun.COM> <87ps2z8krt.fsf@mid.deneb.enyo.de> <4694DC73.2040401@Sun.COM> <87fy3uzqfe.fsf@mid.deneb.enyo.de> Message-ID: <87odig13i9.fsf@mid.deneb.enyo.de> * Y. Srinivas Ramakrishna: > Is there dependable public documentation on the semantics of > various memory overcommit modes in Linux and especially the > one you have in mind here? Sorry, no idea. I even asked (in a running thread, admittedly) on the kernel mailing list in February, but I got no reply. I can ask again, this time on linx-mm, if this would help. From Peter.Kessler at Sun.COM Mon Jul 16 14:22:41 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 16 Jul 2007 14:22:41 -0700 Subject: Two asserts where only 1 is needed? Message-ID: <469BE1A1.7080801@Sun.COM> In hotspot/src/share/vm/utilities/taskqueue.hpptaskqueue.hpp, there's template GenericTaskQueue::GenericTaskQueue():TaskQueueSuper() { assert(sizeof(Age) == sizeof(jint), "Depends on this."); } which seems good and proper (except it doesn't say why it depends on the sizes being equal). But there's also template bool GenericTaskQueue:: pop_local_slow(juint localBot, Age oldAge) { .... assert(sizeof(Age) == sizeof(jint) && sizeof(jint) == sizeof(juint), "Assumption about CAS unit."); which checks an additional condition and has a better failure message. Since Atomic::cmpxchg only deals in jint's, I don't see the reason for the check of sizeof(juint). This is the only place in the VM that checks sizeof(jint) == sizeof(juint). Can anyone think of a reason for the assert at each call of pop_local_slow if we've passed already passed the assert in the ctor? ... peter P.S. I'll probably fix the weird-line wrapping in the declaration of GenericTaskQueue::pop_local_slow while I'm in there. From tony.printezis at sun.com Tue Jul 17 07:38:09 2007 From: tony.printezis at sun.com (Tony Printezis) Date: Tue, 17 Jul 2007 10:38:09 -0400 Subject: Two asserts where only 1 is needed? In-Reply-To: <469BE1A1.7080801@Sun.COM> References: <469BE1A1.7080801@Sun.COM> Message-ID: <469CD451.1070300@sun.com> Peter, No, I can't think of a good reason to check the assertion for every call to pop_local_slow(). I would think that checking the condition once in the constructor would be enough. Tony Peter B. Kessler wrote: > In hotspot/src/share/vm/utilities/taskqueue.hpptaskqueue.hpp, > there's > > template > GenericTaskQueue::GenericTaskQueue():TaskQueueSuper() { > assert(sizeof(Age) == sizeof(jint), "Depends on this."); > } > > which seems good and proper (except it doesn't say why it > depends on the sizes being equal). But there's also > > template > bool GenericTaskQueue:: > pop_local_slow(juint localBot, Age oldAge) { > .... > assert(sizeof(Age) == sizeof(jint) && sizeof(jint) == > sizeof(juint), > "Assumption about CAS unit."); > > which checks an additional condition and has a better failure > message. > > Since Atomic::cmpxchg only deals in jint's, I don't see the reason > for the check of sizeof(juint). This is the only place in the VM > that checks sizeof(jint) == sizeof(juint). > > Can anyone think of a reason for the assert at each call of > pop_local_slow if we've passed already passed the assert in > the ctor? > > ... peter > > P.S. I'll probably fix the weird-line wrapping in the declaration > of GenericTaskQueue::pop_local_slow while I'm in there. -- ---------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS BUR02-311 | | e-mail: tony.printezis at sun.com | 1 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA01803-0902, USA | ---------------------------------------------------------------------- e-mail client: Thunderbird (Linux) From ted at tedneward.com Wed Jul 25 00:36:22 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 25 Jul 2007 00:36:22 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <46951752.10806@Sun.COM> Message-ID: <094801c7ce8e$81fa4950$802ca8c0@XPWork> Perhaps this flag would be used in conjunction with another, thread-specific allocation flag? A la Java -XX:+MaximumHeapSize -XX:+ThreadStackSize=256m .... Or, just use -ss (which IIRC is stack size, correct)? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev- > bounces at openjdk.java.net] On Behalf Of Peter B. Kessler > Sent: Wednesday, July 11, 2007 10:46 AM > To: Jon Masamitsu > Cc: hotspot-gc-dev at openjdk.java.net > Subject: Re: -XX:+MaximizeHeapSize? > > Jon Masamitsu wrote: > > > We've heard from users in the past that it would be nice if > > there was no maximum heap size limit. Users say > > they don't know what the limit for their application is and > > have to experiment to find an adequate value. > > > > I did the following refworkload experiments. > > > > Ran "reference_client" and "startup2" (sets of client > > application like benchmarks) with the -client > > (uses the serial GC which does not have GC ergonomics) and > > a 1g heap. The point of this experiment was to see if the > > size of the committed heap increased because of the 1g heap > > size limit. There was no discernible difference in the > > committed size of the heap nor in the amount of GC work. > > > > I ran "reference_server" (set of server application like > > benchmarks) with -server and the parallel GC (does > > has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default) > > and with -XX:DefaultMaxRAM=1700m (the amount of physical > > memory on the platform minus some for > > the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment > > was to see if the > > GC ergonomics drove the heap to sizes larger that the 1g > > default limit. As one would expect the heaps for some > > benchmarks grew considerably (up to the higher limits > > in some cases) and for some the heaps did not change. > > > > I think that these results are not unexpected. The heap sizing > > policy used by the serial collector depends on the amount of > > live data and the live data for the client like applications > > fit nicely into the 64m default heap size (i.e., the larger > > 1g heap was not needed). On the larger server like benchmarks run > > with GC ergonomics, the high default throughput goal of GC > > ergonomics means that some benchmarks will just use as much > > heap as they can get in trying to reach the throughput goal. > > > > I'd like to propose an additional policy under a new command line > > flag. Let me use MaximizeHeapSize for the name for now. If > > MaximizeHeapSize is set, the VM will calculate > > the amount of physical memory on the platform and > > try to use that as the upper limit on the heap size. As > > with the current GC ergonomics the upper limit will > > be ~4g on a 32bit system. If the VM cannot actually > > reserve that amount of space at initialization, it will > > try reserving some smaller amounts until it succeeds. There > > will be some minimum size (probably 64m) that it will not > > go below. > > > > The user would have to turn MaximizeHeapSize on > > explicitly. It will be off by default until we get some > > experience with it. Users who turn it on and also use > > GC ergonomics will manage the heap size via > > a smaller or larger throughput goal (i.e., the larger > > the throughput goal the more heap space the VM will > > try to get to meet the throughput goal). > > For the non ergonomics collectors it should only matter > > if the application would otherwise have bumped into a > > heap limit (i.e., the application would have thrown > > an out-of-memory or just spent too much time doing > > garbage collections because the heap limit set by > > default or on the command line was too small). In that > > case this change would allow the application to > > get the additional space it needs. I expect there will > > be some corner cases or bugs where the heap will grow to > > the limit when it shouldn't. > > Comments on this proposal? > > Don't forget to leave some address space for thread stacks, > other libraries, malloc space, etc. A simple backoff policy > from trying to reserve all of memory might be too simplistic. > I don't know how to estimate beforehand how many thread stacks > an app will need. :-) > > ... peter > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: 7/11/2007 > 4:09 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 7/24/2007 1:50 PM From Jon.Masamitsu at Sun.COM Wed Jul 25 06:50:04 2007 From: Jon.Masamitsu at Sun.COM (Jon Masamitsu) Date: Wed, 25 Jul 2007 06:50:04 -0700 Subject: -XX:+MaximizeHeapSize? In-Reply-To: <094801c7ce8e$81fa4950$802ca8c0@XPWork> References: <094801c7ce8e$81fa4950$802ca8c0@XPWork> Message-ID: <46A7550C.9090504@Sun.COM> ThreadStackSize sets the stack size for limit for each thread. The difficulty I see is that we don't know how many threads an application uses. On 32bit if I reserved most of the 4g address space for the heap (but had not used it all yet) and then could not allocate a stack for a new thread, I would have to find a way to return some of the address space for the thread stack. I would likely have to do a full collection to move all the objects to the bottom of the heap so that I could free space at the top of the heap. This is conceivable with the UseParallelGC collector because of the layout of the generations in the heap (perm gen at the low end, then the tenured gen and then the young gen at the high end). We'd have to try it to find out where the pitfalls are. Ted Neward wrote: >Perhaps this flag would be used in conjunction with another, thread-specific >allocation flag? A la > >Java -XX:+MaximumHeapSize -XX:+ThreadStackSize=256m .... > >Or, just use -ss (which IIRC is stack size, correct)? > >Ted Neward >Java, .NET, XML Services >Consulting, Teaching, Speaking, Writing >http://www.tedneward.com > > > > >>-----Original Message----- >>From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev- >>bounces at openjdk.java.net] On Behalf Of Peter B. Kessler >>Sent: Wednesday, July 11, 2007 10:46 AM >>To: Jon Masamitsu >>Cc: hotspot-gc-dev at openjdk.java.net >>Subject: Re: -XX:+MaximizeHeapSize? >> >>Jon Masamitsu wrote: >> >> >> >>>We've heard from users in the past that it would be nice if >>>there was no maximum heap size limit. Users say >>>they don't know what the limit for their application is and >>>have to experiment to find an adequate value. >>> >>>I did the following refworkload experiments. >>> >>>Ran "reference_client" and "startup2" (sets of client >>>application like benchmarks) with the -client >>>(uses the serial GC which does not have GC ergonomics) and >>>a 1g heap. The point of this experiment was to see if the >>>size of the committed heap increased because of the 1g heap >>>size limit. There was no discernible difference in the >>>committed size of the heap nor in the amount of GC work. >>> >>>I ran "reference_server" (set of server application like >>>benchmarks) with -server and the parallel GC (does >>>has GC ergonomics) with -XX:DefaultMaxRAM=1g (the default) >>>and with -XX:DefaultMaxRAM=1700m (the amount of physical >>>memory on the platform minus some for >>>the OS) and -XX:DefaultMaxRAMFraction=1. The point of this experiment >>>was to see if the >>>GC ergonomics drove the heap to sizes larger that the 1g >>>default limit. As one would expect the heaps for some >>>benchmarks grew considerably (up to the higher limits >>>in some cases) and for some the heaps did not change. >>> >>>I think that these results are not unexpected. The heap sizing >>>policy used by the serial collector depends on the amount of >>>live data and the live data for the client like applications >>>fit nicely into the 64m default heap size (i.e., the larger >>>1g heap was not needed). On the larger server like benchmarks run >>>with GC ergonomics, the high default throughput goal of GC >>>ergonomics means that some benchmarks will just use as much >>>heap as they can get in trying to reach the throughput goal. >>> >>>I'd like to propose an additional policy under a new command line >>>flag. Let me use MaximizeHeapSize for the name for now. If >>>MaximizeHeapSize is set, the VM will calculate >>>the amount of physical memory on the platform and >>>try to use that as the upper limit on the heap size. As >>>with the current GC ergonomics the upper limit will >>>be ~4g on a 32bit system. If the VM cannot actually >>>reserve that amount of space at initialization, it will >>>try reserving some smaller amounts until it succeeds. There >>>will be some minimum size (probably 64m) that it will not >>>go below. >>> >>>The user would have to turn MaximizeHeapSize on >>>explicitly. It will be off by default until we get some >>>experience with it. Users who turn it on and also use >>>GC ergonomics will manage the heap size via >>>a smaller or larger throughput goal (i.e., the larger >>>the throughput goal the more heap space the VM will >>>try to get to meet the throughput goal). >>>For the non ergonomics collectors it should only matter >>>if the application would otherwise have bumped into a >>>heap limit (i.e., the application would have thrown >>>an out-of-memory or just spent too much time doing >>>garbage collections because the heap limit set by >>>default or on the command line was too small). In that >>>case this change would allow the application to >>>get the additional space it needs. I expect there will >>>be some corner cases or bugs where the heap will grow to >>>the limit when it shouldn't. >>>Comments on this proposal? >>> >>> >>Don't forget to leave some address space for thread stacks, >>other libraries, malloc space, etc. A simple backoff policy >>from trying to reserve all of memory might be too simplistic. >>I don't know how to estimate beforehand how many thread stacks >>an app will need. :-) >> >> ... peter >> >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.476 / Virus Database: 269.10.4/896 - Release Date: 7/11/2007 >>4:09 PM >> >> >> > >No virus found in this outgoing message. >Checked by AVG Free Edition. >Version: 7.5.476 / Virus Database: 269.10.17/915 - Release Date: 7/24/2007 >1:50 PM > > > >