Comment by jshen | Hacker News Reader

Comment by jshen | Hacker News Reader

First, Cringley is simply wrong on many of his points. I don't think he's kept up with this stuff very closely, but that isn't the main point I want to make.

I think everyone is missing a major point in these sort of debates. The JVM uses a shit ton of memory, and this makes it expensive to host. If someone is a poor student that is trying out different ideas for websites, then they can do it much cheaper if they don't use the JVM.

There is a reason there aren't a bunch of shared hosting providers offering jvm support, and if you look at VPN prices I'll bet money that the two things you look at are the memory allocated to your VPS and the price.

Even on the development front, I just had to order a new laptop at work because we're using the JVM and I need to run 3 JVM web services at a time every now and then, plus an IDE and I simply can't do that with 4 gigs of ram which is the max for my current laptop. The JVM process for a hello world servlet, after being hit by a number of requests, will need about 100MB of ram, for a hello world string response!

The JVM is great in certain circumstances, but it's terrible as a cheap platform for people trying to bootstrap and test the viability of ideas. I can run 3 or more ruby, python, or php sites on a $20/month VPS. I can't do that with the JVM, and I'll always bet on the bottom up technologies.

Also, he's assuming that modern times are like the past, and that you can't easily mix interpreted and compiled languages, but on the JVM this isn't so. You can use JRuby and rails, and code the hotspots in java. Hell, you can even code some of the urls in pure java and leave the less significant bits in rails. To make the situation even better, you can start off with C ruby on a cheap vps and if you're idea takes off convert it to JRuby and then start replacing the bottlenecks in java, scala, or whatever.

The last time I paid attention to the Java vs Lisp vs C++ discussion, the shibboleth about JVM memory usage was that the JVM pre-allocated lots of memory to optimize for the case where the application was going to be big and long lived, at the cost of longer start up times and bad memory usage benchmarks for toy programs. I was under the impression that huge JVM footprints were mostly because of this pre-allocation behavior, not because the JVM itself uses lots of memory to maintain itself - am I wrong?

Both. JVM also allocates a lot of memory (relatively) for even its smallest objects (round sizes up, frequent boxing and copying of primitives, everybody gets an automatic mutex), and fragments significantly because it has good garbage collectors that deal fine with that.

A lot of Java is optimized for this, and it would take a fair bit of work to make a JVM (and compiler!) implementation that changed the behavior pervasively.

Java assumes memory is cheap at many levels. And usually, it's right.

"Java assumes memory is cheap at many levels. And usually, it's right."

I would say it's usually wrong. Imagine how much ram you'd need if all of your GUI apps were on the JVM. Imagine how much ram you'd need if '$ cat blah.txt | grep "something" | uniq | sort' were all JVM processes. Etc, etc, etc.

It seems to only be right for long lived server side processes that have enough load to make it a benefit.

You wouldn't architect that in that way in JVM. Instead, you'd use threads rather than processes, use heavier-weight but more capable tools and so on.

The JVM is not The Unix Way. You have to do things differently - and in Java-land, they do.

It's not really my thing either, but it's not as bad as you'd think if you just pretend we're mapping all our existing Unix stuff, unchanged, into Java.

Right, and my point is that the JVM way only fits a narrow range of use cases. Primarily long running server side processes.

I'm not sure where all the memory goes. My 'hello world' test app used around 30MB heap and 25+MB for permgen. It had a fair number of threads running, not sure what the overhead is there, but the process as a whole was using about 100MB. I couldn't make the heap any small without getting out of memory errors if I hit it with a light load.

edit: keep in mind this memory includes your app server, in my case I was using jetty.

Likely, most of those threads are HTTP request handlers. Try to let ab loose on your application and watch it's memory usage. I'm pretty sure you won't see any significant increase.

Maintaining a garbage collector requires overhead, hence why C++ does not implement one as part of the language.

From my experience at University, the JVM uses an indirect method of accessing and storing objects. So each reference to an object is effectively a handle, hence as big as a pointer. It points to a table that contains the actual pointer to the object in memory (or something to that effect), so that the garbage collector can move the object in memory.

Therefore an object that just has a single integer will require 2 pointers and an integers worth of memory (at least). Any less than that and it would be garbage collected since there are no live references in the code to the object.

Garbage collection isn't free.

While that’s one way to do it, I believe that current JVMs use an index directly to the target object in the Java heap. Since the garbage collector is following all the references anyway, it can eventually update all the old references to point directly to an object after moving it.

In 64-bit VMs without a very large maximum heap size, the JVM usually uses "compressed" pointers, too, so 32-bit values can, in practice, address 32GB of data. Intel CPUs have addressing modes that work quite well with this. See: http://wikis.sun.com/display/HotSpotInternals/CompressedOops

Garbage collection isn’t free, but it’s getting pretty good.

I agree that the JVM memory usage is a problem, but also because we are running out of memory bandwidth on modern architectures for many use cases.

While switching to immutable state and using things like STM can help in many ways in order to program all these cores that we are getting thrown at us, we pay with the memory bandwidth costs. Doing this stuff on the JVM surely makes the problem worse.

As VMs as well as multi-core and functional style become more popular I can't help feeling we need typical memory bandwidth of new systems to grow a bit faster.

I was going to start a new post but I think you covered most of the points I would have made anyway.

Reading that article just irritated me, how can someone make so many factual errors in one blog post?

He's never worked with Java to write a web application. Deployment xml configuration files can DIAFF.

He also completely missed the point why all of those Perl++ languages became popular, and it wasn't because disk speed slow/database slow so language being slow didn't matter, it was because you can genuinely get more out the door and tune your way out of performance issues (arguably :))

And when I say "get more done" it was in reference to java rather than perl.

Reply on news.ycombinator.com