really?? every machine on the planet? that attitude is a worry, and a good example of what I feared is still the prevailing attitude.
On Aug 15, 4:52 pm, Kirk <kirk.pepperd...@gmail.com> wrote: > 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 <reini...@gmail.com> 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 javaposse@googlegroups.com. > > To unsubscribe from this group, send email to > > javaposse+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://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 javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
