I know how to set the Java heap size in Tomcat and Eclipse. My question is why? Was there an arbitrary limit set on the initial heap back when Java was first introduced so the VM wouldn't grow over a certain size? It seems with most machines today with large memory space available this isn't something we should have to deal with.
Thanks,
Tom
-
The Microsoft JVM did not have a limit to the heap size. It is a vendor specific issue. – Thorbjørn Ravn Andersen Nov 26 '11 at 18:57
4 Answers
Even now, the heap doesn't grow without limit.
When the oldest generation is full, should you expand it or just GC? Or should you only expand it if a GC doesn't free any memory?
.NET takes the approach you'd like: you can't tell it to only use a certain amount of heap. Sometimes it feels like that's a better idea, but other times it's nice to be able to have two processes on the same machine and know that neither of them will be able to hog the whole of the memory...

- 1,421,763
- 867
- 9,128
- 9,194
-
Better yet, why can't we simply have both. Why can't we define it to continually expand, OR limit it. – cgp May 12 '09 at 13:34
-
2Generally I would like to see this as an operating system feature. In different flavours of Unix you can place limitations on process or user memory usage. It helps keep machines responsive. In the .NET case where a single app can take all the memory the machine might become so busy swapping that you cannot even get to the task manager to kill it. So even though Java's model might seem outdated, I really like it - if somethings needs that much memory, I'd like to know in advance and assign a well-known maximum knowingly. – Daniel Schneller May 12 '09 at 13:36
-
@altCognito: it should just be possible for someone to come up with a different JVM implementation that behaves this way – matt b May 12 '09 at 15:34
-
just give the jvm a limit which is really, really big, and it is effectively unlimited. – james May 12 '09 at 17:12
I glanced by this the other day, but I'm not sure if this is what you want: -XX:+AggressiveHeap
. According to Sun:
This option instructs the JVM to push memory use to the limit: the overall heap is more than 3850MB, the allocation area of each thread is 256K, the memory management policy defers collection as long as possible, and (beginning with J2SE 1.3.1_02) some GC activity is done in parallel.
Because this option sets heap size, do not use the -Xms or -Xmx options in conjunction with -XX:+AggressiveHeap. Doing so will cause the options to override each other's settings for heap size.
I wasn't sure if this really meant what I thought it meant, though - that you could just let the JVM gobble up heap space until it is satisfied. However, it doesn't sound like it's a good option to use for most situations.

- 85,990
- 32
- 182
- 176
I would think that it's good to be able to provide a limit so that if you have a memory issue it doesn't gobble up all the system memory leaving you with only a reboot option.

- 5,674
- 4
- 48
- 71
Java is a cross-platform system. Some systems (like Unix and derviates) have a ulimit
command which allows you to limit how much memory a process can use. Others don't. Plus Java is sometimes run embedded, for example in a web browser. You don't want a broken applet to bring down your desktop (well, that was at least the idea but applets never really caught on but that's another story). Essentially, this option is one of the key cornerstones for sandboxing.
So the VM developers needed a portable solution: They added an option to the VM which would allow anyone (user, admin, web browser) to control how much RAM a VM could allocate tops. The needs of the various uses of Java are just too diverse to have one size fits all.
This becomes even more important today when you look at mobile devices. You desktop has 2-8GB RAM but your mobile has probably much less. And for these things, you really don't want one bad app to bring down the device because there might not even be a user who could check.

- 321,842
- 108
- 597
- 820