Even for server apps it is at odds with, well, everything else. If you want to limit resource usage on a per process (JVM, in this case) there are plenty of tools that do that for you, give the system admin more control etc... the JVM is a unique pain in the rear in this regard ;)
There really is no good reason for it from a system management/ perspective - like all other "odd" things most reasons given are speculation after the fact - I am sure there is a real reason and probably some ancient decision to do with running applets in constrained devices... the fact that is is a -X means that it is meant to be a non core settings too ? On Aug 13, 9:32 am, Reinier Zwitserloot <[email protected]> wrote: > On Friday, August 12, 2011 11:37:15 PM UTC+2, mbien wrote: > > > see it as performance optimisation. A GC impl which would have to deal > > with fragmented, non continuous and resizing heap would have a hard > > time to compete with the current VM. A JVM is a operating system for > > java applications. You can't plug in new RAM brick in your system > > easily at runtime for the same reasons. > > > I would go even further and say that writing java applications with > > unknown memory requirements is not that professional :P > > This is spot on. For large server apps. For client apps or quick command > line tools, being forced to prepick total memory load (and treating the JVM > that's going to start up to host your app as an OS-in-a-OS), is ridiculous. -- 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.
