> First, thanks for the info, Richard. > > Interesting. I am now left to wonder if your disposition is typical > of most JVM developers and deployers. I'll have to continue asking > my inquiry.
I'm actually not a typical JVM developer -- I come from a Common Lisp background, and I avoid writing Java whenever I can -- and I'm most definitely not a Java fanboy. Java makes up the minority of my work. In fact, I've only started using it for real work in the past couple of years, because it happened to be the best tool for the job. I was responding from the perspective of the times I've deployed Java applications, but that's not the majority of my experience. >> Sure, under load that will increase, but it's still negligible in the >> context of available memory (only a few percent). Additionally, in my >> experience the memory "profile" of Java server applications is better >> than our C++ applications, which typically experience some bloating >> or >> memory leak issues. > > Is that a positive for Java? Or a negative for the programmers that > wrote your C++ apps? Many of the leaks I've been privy to have been in vendors' binaries or in libraries, which are hard to fix! The rest are 'common or garden' bloat, and would arise in most C++ applications developed under the same circumstances. I certainly don't attribute any exceptional blame to the teams involved. Part of the reason why GC is so fantastic is that writing truly correct memory handling code is actually quite hard, particularly for long-running applications, and getting it right is costly. I view GC as a good thing. I would not write any new applications in C++, and that's been true for several years. Additionally, applications with GC can outperform those with malloc/ free-based approaches, which is fascinating. >> I'd take steady-state 300MB memory consumption any day over a >> startup at 50MB ending up at 1.4GB after a couple of months' uptime >> (a situation I've seen with C++ server applications). > > In general, I agree. But I would need to take into account few other > variables before I made that decision for a specific application. > Consider, for an app that starts at 50MB yet has allocated 1.4GB of > "leaked memory" after a couple months, that application could easily > restart itself very quickly; and that's a low-cost operation. Unless you have current sessions, and a gentle restart involves rerouting traffic. (I work in a high-availability domain.) I don't like writing "bounce the server" as a routine recommendation in an ops guide :) >> So, in short: if you're on a low-resource machine, running graphical >> Java clients: yes, the JVM's memory consumption might concern you, >> as will its startup time. > > Errrm - so Java's value is limited to large systems ? For me, yes. Put another way: there's no way I'd write Unix utilities in Java (because of the startup time). Its applicable domains for me are limited. Other people are much more enthusiastic about its applicability -- they're running Java on televisions, Blu-ray players, mobile handsets, VoIP desk phones, network appliances, cash registers... > That statement > does not seem to take into account all of the small systems, including > mobile devices, that use Java. What am I missing here? There are different profiles of Java: ME, SE, EE. Java ME is a very different beast to an "enterprise" (*gag*) Java application server. I wouldn't use Java ME either, but that's a different story :) > IOW, when I see a increase of 4 orders of magnitude of attribute A in > exchange for 1 order of magnitude of improvement in attribute B, my > alarms are triggered. I do my value calculations, start asking > questions and looking for something to kill. In this case, the JVM > allocating 400MB instead of 40k; I expected something on the order of > MBs, not HUNDREDs of MBs. I don't see similar measurements to you. My Nailgun server for Clojure development, started with -server and -Xmx512M, is at 19MB RSIZE on my 64-bit Mac. After loading all of my code and its dependencies, that jumps to 37MB. After quite a bit of work, it's at 65MB. I rarely see it rise above 100MB. My Java app server -- actually deployed and handling requests -- on Solaris x86 is at 158MB RSS, which actually impresses me given the amount of code loaded. Those sizes are smaller than some non-Java apps I've deployed recently, one of which is hovering around 500MB RSS right now. Java memory usage no longer enters into the technology choice equation for me. It did a few years ago. >> ...but it doesn't bother most people running Java services on >> 2008/2009-era servers. > > If my initial observations were true for all cases then I suspect that > your comment would reflect poorly on your group of "most people". > Sorry. :( Indeed, which is why I think either your measurements are flawed, or that measuring standalone memory consumption (no matter how accurately) is an irrelevant metric for real-world applications. Measured in response time, active sessions, calls per second, etc. etc., I've been fairly happy with the JVM on modern hardware. Apparently lots of other people are, too. In my domain it compares favorably to established C and C++ servers, and is a good deal easier to instrument and extend. I wouldn't use it on embedded devices, or where a JVM has to be instantiated rapidly. Java has plenty of failings (particularly as a language), but I don't regard its memory footprint as significant. It's possible your measurements are simply inaccurate (as others have pointed out), or that you need to spend some time tuning GC parameters for your application. > Funny thing about that. I tried to limit the heap-size w/ the "-Xmx" > and "-Xms" CLI parameters. They exacerbated the situation, i.e., the > JVM allocated MORE memory. Go figure. -Xms defines the *minimum* heap size. If you specified that, it's very likely that the JVM would allocate more memory up-front. That might have knock-on effects on later heap expansion. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
