The reason .net doesn't have this problem is due to the different (perceived) target markets for each.
Java has taken a "let's make it so the server admins like us" approach, and thus have strictly limited the JVM to take up only as much memory as you tell it to use. Furthermore, while the JVM should not eat more than the set amount of memory I give it, it should also have enough memory to comfortably run my app, lest it slow down to a crawl. Therefore, if I know my app needs let's say 512m of heap, then if I tell java it should have no less (and no more!) than 512m heap, all those 512m need to go to heap. Thus, separate settings for heap, stack, permgen, etc. .net takes the consumer approach, which is indeed simpler: If I need more memory, I'll just take it. I'll keep taking up more memory until the host system doesn't want to give me any more (which will occur only after exhausting the entire swap drive as well). If I don't get an opportunity to garbage collect, this is indeed going to spiral into a disaster. There's a nicer solution available which neither fully implements, though .net is a little closer to this: Be Smarter. There ought to be a JVM option that says: Use however much memory there is, but be smart about it. This option should take into consideration total system memory, and create many soft borders which it won't break unless there's no other way to continue (e.g. it should start aggressively garbage collecting before taking more than 10% of the total system's memory, but if that isn't helping, then break through and set a new soft border of 20%). For server VMs, you can still use the -Xmx settings to set up uncrossable memory boundaries. For system response, a JVM that is in dynamic mode should still consider something like 75% of total system memory as an unbreakable boundary; it's very likely there's a memory leak if it ever goes that far, so if 75% isn't enough, soon 100% won't be enough either, and at that point the app is slow as molasses (due to constant swapping), and the OS, also starved for resources, will be so irresponsive it'll be tough to close this app. This isn't exactly easy to do; for example, giving each stack a variable stacksize to accomodate really big stacks is somewhat complex, as is dynamically growing a stack. You also don't want to grow a stack too far, as 95% of all stackoverflowexceptions are not an indicator for a small stack, they are instead an indicator for an endless recursive loop. You want those to blow up early, and not grind the system to a halt as the VM marshalls half your swap space and almost all core memory to create one gigantic stack for the runaway process to churn for minutes on end before finally crashing. On Dec 19, 4:45 pm, Casper Bang <[email protected]> wrote: > I won't even try to pretend that I understand all the intricate > details of the class loaders, GC and leakage. However you turn and > twist it, it's a design issue somewhere between the JVM and the > application server concept (accidental complexity?). And it's one hell > of a good reason to run your app as an embedded Grizzly or Jetty > instead - much more predictable. Now what I would REALLY love to know, > is how on earth is GAE handling this?! > > /Casper > > PS: I have never seen something a kin to PermGenSpace on .NET and I > assume this is due to the fact that they took a more KISS attitude (no > custom low-level class loader, only dynamic assembly modules > responsible for their own mess). > > On Dec 19, 5:49 am, Brian Leathem <[email protected]> wrote: > > > > > On 18/12/09 3:44 AM, Casper Bang wrote: > > > > All good points. Startup time with 15-20 applications deployed would > > > also be more interesting than pure container startup - given how that > > > can easily take 5+ minutes, a long time in a production environment > > > which just suffered from PermGenSpace problems and had to be > > > restarted. > > > How *do* you get rid of those PermGenSpace problems (aside from > > increasing the PermGenSpace). I get them often and have to completely > > restart Glassfish/Netbeans to get back to normal. This can take a > > while, as Glassfish doesn't stop nicely when it runs out of PermGen. > > > I made significant improvements by moving some of my 3rd party Jars into > > the app server lib folder, so that those classes wouldn't have to be > > re-loaded with every re-deploy. But it still happens. > > > Maybe with GF v3 finally having support for compile/deploy on save for > > maven projects, I'll finally escape this problem. > > > Brian Leathem -- 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.
