On Aug 16, 2011, at 5:31 AM, Michael Neale wrote: > really?? every machine on the planet? that attitude is a worry, and a > good example of what I feared is still the prevailing attitude.
I don't understand.. et me restate this. End users may do the final install of an application on their phone, tablet, desktop,.. what ever.. but some expert some where as looked into the issues of how to get that done. The more complex the system, the more one off or customized the deployment, the more expertise is needed. Regards, Kirk > > On Aug 15, 4:52 pm, Kirk <[email protected]> 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 <[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 >>> 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 [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.
