Why I Don't Use The JVM (yakkstr.com)

Further, today bandwidth equals performance. use 100M of memory? suddenly you've clobbered your cache. Use 10K instead, and it'll fit inside your cache neatly.

I just checked, and a small Clojure web app I am working on does indeed take almost 100MB of RSIZE - but it have its only JETTY container and a lot of other overhead that it is not sharing with other deployed apps. Also, a large app with a lot of code would not take much more. Hosting ten small web apps in the same Tomcat or Jetty instance would probably take much less than the 1 GB of RSIZE mentioned in the article.

I do agree though with the goodness of reducing memory use and I like to check memory use and execution speed when I look at comparative benchmarks like Computer Language Benchmarks Game.

I'm reading this article while Eclipse restarts after I shutdown the app because it ran out of PermGen space.

I ran web apps that serviced 10x more users off of a 512 meg VPS with SBCL :-|

Anybody up for a sword-fight? jousting?

But JVM is here to stay.

Hello world and hobby projects are not the target for the JVM. It may take a good chunk of RAM to fire it up at all but you can serve far more clients in that same chunk than you could with the number of Ruby processes, for example, you could run in the same memory. Look at how much more performance Lift/Scala can squeeze out of the same box than Rails.

TLDR: JVM uses too much memory for little/hobby projects.

Response: Learn to manually configure its memory useage, don't just go with the default.

Not really front-page worthy.

I feel like the JVM has already proven its self to be viable as a production VM. The 'helloworld' argument doesn't really hold water because you would never run helloworld in a vm. If you care about fast setup/teardowns or small memory footprints then don't use ANY vm. If you want things like easier security policies, garbage collection and maybe more the point: scalability then the VM is a great platform to develop for.

Good for you.. Mr. Knuth

Hold on, my rails processes take 80 megs. Am I doing something wrong?

While I see his point regarding excessive memory usage WRT the JVM, I don’t think this matters much. The fact is memory is cheap these days and the convenience of the JVM is something that’s tough to overlook. Furthermore, while a Hello World app may require 100MB when implemented on the JVM, much of that is overhead which will stay relatively constant as your process grows more complex (to a point, obviously). I can run multiple processes on the same JVM instance and stay within reasonable memory bounds.

Also, we need to consider the alternative. Where would we go if we didn’t have the JVM? It’s not like .Net is much better in this regard. We could go without a system as heavyweight as these two but then we lose all the advantages that come along with that weight.

Certainly, those advantages are not needed for a lot of purposes. Looking at what he’s running I would say he probably doesn’t need the weight of the JVM.

That said, I’m pretty sure I couldn’t do my current project anywhere but the JVM (well, okay, they’re all Turing machines so technically I can, but bear with me). I’ll gladly fork over the cash for a beefier VPS if it that’s the cost of the JVM.

Full disclosure: I am considered a Scala evangelist.

The JVM is the one part of Java that is actually Gaining more mindshare. Granted "hello world" is not the ideal usecase - but you are missing the point. The cost you pay for hello world still remains the same up to a moderately sized app, and the more the complexity of your app, the more benefits you start to see from the JVM's memory model.

A better comparison would be a real world app that scales to a number of users - tell me about JVM memory usage and performance then.

You want to develop a server app and 100MB required by container is your concern? BTW This is year 2011 not 1996.

Yup, JVM takes up huge resources. But, when you put the app in production, you can be rest assured it will perform. JVM gives you piece of mind.

I guess you should just run a golang HTTP service behind nginx if memory is your biggest concern.

If that's not good enough go ahead and write the whole thing using C. You can get one hell of a small "Hello, World!" program using C.

Yes, Java uses a lot of memory. It uses a lot of memory mostly because it doesn't mmap static shared lib files. Most c library based systems (e.g PHP, Python, Ruby) do. When the system can mmap read only shared lib files, that uses a lot less memory because multiple processes can share them and they are only read in to memory as they are accessed thanks to the page fault mechanism of 386 protected-mode architecture.

Java can't do this because Java self-modifies code (JIT) to run faster while it's running. Once all your classes are loaded into ram though, the memory gets consumed at a much more leisurely pace. However, multiple apps can't reuse each other's already mapped into memory code like they can with PHP, etc. As far as appserver restarts, just pay the money for JRebel already and quit complaining. Your life will be so much better.

The JVM (at least the Oracle/Sun version) has some scary seeming memory allocation policies. One of the biggest offenders is its complete unwillingness to ever shrink the system allocated memory, even if the heap is 95% empty. For instance, if your application has a huge peak allocation period (whether your fault or an issue with soft references sticking about when you really don't want them), it will put memory pressure on the OS for the rest of its (process) life. If the JVM has an option of garbage collecting large amounts of objects or growing the heap, it generally prefers growing the heap. You can run quite a few Java applications with amazingly small heaps at everything will be fine (except for performance due to GC overhead).

The abstraction breaker here is that your application often has a set of ideal GC settings, which need to be set. You cannot forget about the garbage collector when using the JVM.

A blanket statement for a fairly specific use case seems irresponsible.

Great comment:

You can allocate as much or as little memory as your application needs. I run many personal web projects on a JVM sitting on top of a free-tier AWS EC2 micro-instance. I have tomcat6 instances running with <32MB footprint.

Perhaps you need to better understand what you're putting on the JVM and why it needs what it does

   java -cp .:servlet-api-2.5.jar:jetty-all-7.0.2.v20100331.jar -client -XX:MaxPermSize=1M -Xmx2M -Xms2M HelloWorld

I fired up an application written in play framework with -Xms64m -Xmx100m and hit it with ab -n 500 -c 20 http://localhost:9000/ the RES column in top remained under 86m. The application does alot more than "hello world", I can speed it up and decrease memory consumption by substituting groovy based templates with java based templates using a module called japid. If you want to use JVM for hobbyist apps start using frameworks which are not based on j2ee.

"hello world" - win xp 32 bit, sun jdk 6:

public static void main(String[] args) throws Exception { Thread.sleep(10000); System.out.println("hello world"); }

Heap - 5M, Used heap - below 2M. All defaults.

(the "sleep" is there to have time to connect Java VisualVM)

If one actually has a true practical reason to be concerned that processes won't consume less than $1 worth of RAM, I have to wonder why anything involving a managed environment such as the JVM was ever up for consideration in the first place.

I'd figure when dealing with that kind of memory constraint the only real contenders would be things like C, FORTH, or maybe PICAXE BASIC.