I mean that the JVM isn't "special" in deployment - there are many other systems that have to be dealt with - but it is one of the most problematic.
The explanations to do with GC implementation make sense - that is fine - but that doesn't mean it has to be like that for ever (as Azul are showing, and I am sure others will). On Aug 16, 8:35 pm, Kirk <kirk.pepperd...@gmail.com> wrote: > 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 <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 > > 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.
