I agree with Phil. All VM's should allow memory usage to grow without bound. Someone should alert VMWare to this great idea too.
While we're fixing shorted-sighted design problems in Java, let's take care of some other things too: - I should be able to access arbitrary memory locations with pointers. Let's get rid of that artificial limitation. - Bytecodes are inefficient. Let's change javac so it compiles everything to machine code. - The Windows API should be built directly into the JDK. In all seriousness, maybe it wouldn't be completely crazy to have a JVM option to allow memory to grow until the operating system denies further allocations. That might be useful in specialized cases (e.g. an embedded system where the user can add additional physical memory). But it shouldn't be the default behavior. On Dec 31 2008, 4:53 pm, "[email protected]" <[email protected]> wrote: > Your test app is going to behave differently than your production > app. So you may not know how much memory you will use until you > launch it. And then when it crashes, you make the adjustment. > > But even if you are right, it's to keep your whole server from > failing.... why not have an option to use as much memory as needed? > > AFAIK the CLR doesn't have this limitatino. Nor do any of the myriad > of other VMs out there..... > > On Dec 31, 11:45 am, "Matthew Beldyk" <[email protected]> > wrote: > > > My impression was that a fixed size of the heap was designed to keep > > the program from using all the ram on the machine. Personally, I'd > > rather have a single program crash than have an entire machine come to > > it's knees (I no longer have any machines running a single application > > unless they are running some low level embedded operation, and that's > > a completely different beast). > > > I will admit, 64M is a little on the low side for modern desktop > > applications (this from a guy with 8 gigs or ram on his workstation, > > so take that statement with a grain of salt). But 64M is actually on > > the large side some embedded systems. I'm going to guess that 64M was > > decided upon as a good place to start; I imagine it would cover most > > usual programs. > > > Configuring the maximum heap size is also fairly trivial (the -Xms and > > -Xmx flags, I believe). And having a ballpark idea how much ram your > > program should use should be a basic benchmarking test before you put > > something into production (I've been guilty of missing that test > > before and won't make that mistake again). > > > All this being said, I have been burnt by this with tomcat before when > > we forgot to configure this correctly and ended up with some very > > strange behaviors (suddenly some of our applications could no longer > > find libraries that tomcat was dropping out of the heap; I don't know > > the exact details as I was on vacation that week and this is all > > hearsay). > > > In my opinion, the fixed max heap size is a required annoyance. > > Unless I were better able to manually manage memory usage in java, I'm > > disinclined to allow program's ram usage to grow unchecked. > > > -Matt > > > On Wed, Dec 31, 2008 at 10:54 AM, [email protected] > > > <[email protected]> wrote: > > > > I've never understood why sun chose to have a "max heap size" setting > > > and default it to 64 megs. To figure out what your max heap size > > > should be you pretty much have to use trial and error. This makes > > > java inherently unstable. I can't count the # of times I've had > > > processes crash with an OutOfMemoryException because the heap size is > > > set either to the default 64 meg or too low. > > > > Why not do what every other runtime does and just allocate memory as > > > needed? And what exactly does the max heap size setting do anyway? > > > -- > > Calvin: Know what I pray for? > > Hobbes: What? > > Calvin: The strength to change what I can, the inability to accept > > what I can't, and the incapacity to tell the difference. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
