Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

251–260 of 373 posts

Re: The JVM is not that heavy

#251

Post by fnord123 »

CountHackulus wrote: post #210
Jeaye wrote: post #157

Earlier quoted context omitted.

In production, what matters is the ridiculous memory usage. Both Java and App Engine are to blame about this, but the Python and Go folks aren't running into the same issue.

If memory usage matters to you, have you tried telling the JVM not to use all the memory? Have you tried any of the tuning options? Can't say I've ever used app engine, but the pure java applications I've worked on did in fact use a fair bit of memory, much like windows and OSX will aggressively use spare memory for caching. Then I use -Xmx to tell it not to use all the memory and now it's much better. For a server,…

I use -Xmx and then the process crashes because it runs out of memory. It's very wasteful with memory and I wish jep 169 was implemented to mitigate it. It's unfortunate that it was written in 2012 and remains a draft.

Re: The JVM is not that heavy

#252

Post by ksec »

gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

That is why i am looking forward and VERY excited for TruffleRuby, SubstrateVM, Graal, along with C Extention.

I think once there is official way to trim JDK down, making deployment super easy and fast ( Single executable File ), Java will pick up stream again.

The only problem and hesitation we have...is Oracle.

Re: The JVM is not that heavy

#253

Post by fnord123 »

uluyol wrote: post #30
sandGorgon wrote: post #7

I used to think this too, until I came across http://www.scylladb.com/ It is a fork of cassandra written in the Seastar c++ framework and is drop-in compatible with cassandra. Claims 10x increase in performance. I always thought there was a few percentage points difference - never a 10x performance difference between java and c++. And that too for a project with as many man hours and facebook-scale tuning as cassandr…

I don't believe their claims. Many benchmarks (including those done by ScyllaDB) are done badly. They'll take a database built to operate on larger than memory data (e.g. 10x) and run on a dataset that can fit entirely in memory. So whoever optimized for in memory wins. But run on an appropriately sized dataset or reduce system memory and you see little difference. This might seem like a good thing (ScyllaDB gives yo…

"it does mean that if your dataset grows, performance falls off a cliff."

Are you saying you know ScyllaDB does not handle larger datasets and Cassandra is better in this respect? Or are you saying that their benchmarks are not yet conclusive?

Re: The JVM is not that heavy

#254

Post by nvarsj »

linkmotif wrote: post #19

This interview with Bob Lee is really interesting on this topic: https://www.infoq.com/interviews/lee-java-di . Apparently, Square was first built out on Ruby with the mindset that the JVM is an old clunker. Fast-forward a few years they switched to the JVM because it was faster and the language (I know, not related) provided compile-time safety.

Almost anything would be better than the Ruby runtime, which is notoriously bad. JVM performs best with largish heaps (>512Mi) - if your services fit into that model, it's a great piece of technology that is very fast.

But I have to agree w/ others that after using golang, where an equivalent web app would run in <50Mi of RAM with far better tail latencies, the memory cost of the JVM feels very large.

Re: The JVM is not that heavy

#255

Post by nvarsj »

brianwawok wrote: post #96
martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

You're still limited by the JVM technology, regardless of how you write your app - large heap, and big tail latencies (JVM's GC is designed to be throughput optimised, whereas golang is latency optimised).

Re: The JVM is not that heavy

#256

Post by nb777 »

CountHackulus wrote: post #210
Jeaye wrote: post #157

Earlier quoted context omitted.

In production, what matters is the ridiculous memory usage. Both Java and App Engine are to blame about this, but the Python and Go folks aren't running into the same issue.

If memory usage matters to you, have you tried telling the JVM not to use all the memory? Have you tried any of the tuning options? Can't say I've ever used app engine, but the pure java applications I've worked on did in fact use a fair bit of memory, much like windows and OSX will aggressively use spare memory for caching. Then I use -Xmx to tell it not to use all the memory and now it's much better. For a server,…

> As an added annoyance, which is specific to App Engine but a result of using the JVM, it's impossible to specify JAVA_OPTS, so any of the -X flags, without switching to the Flexible environment

I haven't used App Engine either but I suspect that the flexible environment is more expensive.

Re: The JVM is not that heavy

#257

Post by lmm »

Macha wrote: post #180
lmm wrote: post #152

Earlier quoted context omitted.

Yes. Maven has been doing package management right for years (and avoids the wasteful repetition that node does, that can often hide silent incompatibilities until runtime).

If you're building jars with a classpath on the filesystem, maybe. If you're building wars, fat-jars or anything else that gets you to that "single jar deployment" which is often mentioned as a pro, you're definitely not immune to duplication. Especially when you get to libraries that have changed their package name over the year like say jackson.

> If you're building wars, fat-jars or anything else that gets you to that "single jar deployment" which is often mentioned as a pro, you're definitely not immune to duplication.

True, though at least it's once per transitive dependency per deployable application rather than once per path to transitive dependency per project.

> Especially when you get to libraries that have changed their package name over the year like say jackson.

Yeah, you do have to deal with those, though it's a relatively small number IME. It would be nice if maven had some integrated support for saying that library x and y are actually what was previously combined library z or similar, though I'm not aware of any package manager that does that yet.

Re: The JVM is not that heavy

#258

Post by [deleted] »

nvarsj wrote: post #255
brianwawok wrote: post #96

Earlier quoted context omitted.

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

You're still limited by the JVM technology, regardless of how you write your app - large heap, and big tail latencies (JVM's GC is designed to be throughput optimised, whereas golang is latency optimised).

[deleted]

Re: The JVM is not that heavy

#259

Post by ominous »

ksec wrote: post #252
gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

That is why i am looking forward and VERY excited for TruffleRuby, SubstrateVM, Graal, along with C Extention. I think once there is official way to trim JDK down, making deployment super easy and fast ( Single executable File ), Java will pick up stream again. The only problem and hesitation we have...is Oracle.

Not to sound rude, but the expression you were aiming to use is maybe "pick up steam". Random example: http://idioms.thefreedictionary.com/pick+up+steam

Re: The JVM is not that heavy

#260

Post by mike_hearn »

jshen wrote: post #225
kasey_junk wrote: post #98

Earlier quoted context omitted.

I've spent a fair bit of time in both, most recently the last couple of years in go. I think its a very mixed bag and there is no clear winner. The tooling, especially for runtime operations, are so much superior to the golang options its night and day. I have much more success modeling complex business models in java with its better type system, and for doing low latency work its much easier to do on the jvm due to…

I have golang website/web app that runs at tens of megabytes per process. A very similar java web app runs in a few hundred megabytes per process. I also run these in on cloud platforms that auto scale. The golang processes spin up very quickly, the java ones not so much. In these two respects the JVM is heavy compared to golang for my very common scenarios. The heaviness also causes me to spend more money for the JV…

But what max heap size did you set for the JVM?

I have an app that people were complaining took too much memory. A quick look with VisualVM showed that its actual heap usage when idling was only 50 mb but because we hadn't set any heap size limit, it was reserving hundreds of megs from the OS. The idea is that it can run faster if it does that. The fix was simply to use the -Xmx option to tell it to use less memory and GC more often.

Post reply on HN