How about deploying Oracle RDB? Regards, Kirk
On Aug 17, 2011, at 6:32 AM, Michael Neale wrote: > 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. > -- 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.
