2011/8/15 Kirk <[email protected]> > If an implementation was not constrained by requiring a contiguous heap and > there was plenty of resources available, then a reasonable action could be > to reserve more memory from the OS. It needn't take all the memory, it > could be smart and look at available resources and system configuration > (e.g. over-commit limits) and fall back to existing means to dealing with a > rapidly exhausting heap, before the OOM killer kicks in. This would allow > the default configuration of a JVM to be much more conservative with its > initial startup defaults. The 1/4 of resources always seemed to me like an > overly aggressive default. > > > That is the way it current works, you take what you need and reserve the > rest. If you have an OOME you've generally got a problem, a bug in your > application and it would behove you to fix the bug. If you have a temporary > high water mark, use the parallel collector. It handles this situation very > very well. I've got evidence of that from a JVM supporting a website that I > bet everyone on this list uses (sorry can't name it) that is subject to > spikes in load every time something happens in webosphereland. > > I would disagree with 'If you have an OOME you've generally got a problem, a bug in your application'. This may be true in some circumstances, but not in all. In some applications, you can't predict how much memory the user has, and also you can't predict what they will do with it.
Let's take the example of a successful Java desktop application: Eclipse. Sometimes I get an OOME from Eclipse, because I've run a long running process, and haven't increased the -Xmx parameter. So I get an OOME. So I have to manually increase the -Xmx. And rerun. And repeat until I give up and just use the maximum value possible for -Xmx. The choice by default that Eclipse (or indeed the JVM) makes is incorrect for my usage pattern. I think that is really what people are complaining about. As a developer of an application, this complicates my life to have to work out a strategy to allow the user to change the memory allocation, which has to include restarting the application. I understand why the -Xmx parameter exists. I've had experience in the past of a value of -Xmx which was greater than the available memory, which made the GC run like a dog. But I would like to be able to say on occasion 'Just take what you need'. Matthew. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
