On Aug 15, 2011, at 3:58 AM, Michael Neale wrote:
> 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 ;) will, it means that the JVM needs to be understood by those deploying it. But guess what, that is the same for just about every machine on the planet. > > 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... correct, but there are good GC ergonomic reasons in the current implementations for having a max memory, min memory and incremental resizing option. BTW, I think I saw someone mention setting -Xmx == -Xms in an earlier thread. For 1.6.0 I would not recommend it as a starting point when tuning GC as it will turn off ergonomics. Which means, GC will not be adaptive. > > the fact that is is a -X means that it is meant to be a non core > settings too ? The -X means that the setting is non-standard. FYI, you don't need to have a collector to be compliant with the JVM specification (I believe there is one implementation that in fact doesn't have a collector and -Xmx setting makes no sense in that case) which would make it hard to have a standard switch setting ;-) > > > > 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. > -- 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.
