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

311–320 of 373 posts

Re: The JVM is not that heavy

#311

Post by falcolas »

deepsun wrote: post #195
falcolas wrote: post #141

Earlier quoted context omitted.

And yet we do that every time we install the JVM (and Ruby, and Python, and...)

No, when you install JVM (you probably meant JRE) on the server -- there's no `javac` (compiler) installed, only `java` -- JVM. I never needed `javac` on production server.

The JIT is a realtime compiler, so yes, there's still a compiler when you put the JVM on a machine (whatever form you use).

Of course, I know of a lot of developers who just put the whole JDK in a Docker image to save on the complexity of having to manage two different installs or containers.

> I never needed `javac` on production server.

Good; that's how it should be; but not how it always is.

Re: The JVM is not that heavy

#312

Post by mi100hael »

falcolas wrote: post #311
deepsun wrote: post #195

Earlier quoted context omitted.

No, when you install JVM (you probably meant JRE) on the server -- there's no `javac` (compiler) installed, only `java` -- JVM. I never needed `javac` on production server.

The JIT is a realtime compiler, so yes, there's still a compiler when you put the JVM on a machine (whatever form you use). Of course, I know of a lot of developers who just put the whole JDK in a Docker image to save on the complexity of having to manage two different installs or containers. > I never needed `javac` on production server. Good; that's how it should be; but not how it always is.

JIT is part of a platform's runtime environment, not part of its build environment. Since you appear to be a super-pedant, I'll revise my initial statement to:

> If you're installing any tooling or programs on a production server or opening ports other than those strictly necessary for running your production application (as a pre-built binary or package whenever applicable) conforming to industry standards for that application/server environment, you're doing it wrong.

Re: The JVM is not that heavy

#313

Post by tonyedgecombe »

alimbada wrote: post #291
frant-hartm wrote: post #282

Earlier quoted context omitted.

I could more or less agree with most of it apart from > arguably the best dev IDE available (Visual Studio) and one of the best up-and-coming dev text editors (VS Code) https://www.jetbrains.com/resharper/documentation/comparison... Refactoring, Coding assistance, Navigation & search sections being most important.

Although the last version I used seriously was VS2013, VS on its own is pretty mediocre. With ReSharper though, nothing beats it in my opinion. On the other hand I've been using Eclipse and IntelliJ for the past year. Eclipse is not even worth talking about but even IntelliJ does not come close to vanilla VS in terms of usability. Again, my opinion.

Yes, it will be interesting to see what the JetBrains C# IDE is like when it's released.

Re: The JVM is not that heavy

#314

Post by hrjet »

mike_hearn wrote: post #262
jshen wrote: post #226

Earlier quoted context omitted.

That's not it. A fairly small http server in go will run in tens of megabytes. The same thing on the JVM requires a couple hundred megabytes at best. The difference in startup time is roughly the same as well.

Are you sure? I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immediately). It's a very poor default because even though there are technical arguments for doing that (goes faster), they a…

> I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much.

I second that. I have deployed a medium traffic web-server written in Scala backed by a postgresql DB on 128MB VPS, back in 2009!

> I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immediately).

I don't think that is true. The default heap size for Oracle and OpenJDK VMs has been bounded as far as I remember. In fact, I would like it if the VM, by default, allowed the heap size to grow upto available RAM when GC pressure increases, but that doesn't seem to be the case as of now.

Edit: Did you mean non-heap VM arenas grow indefinitely? If so, I am not aware of them.

Re: The JVM is not that heavy

#315

Post by tonyedgecombe »

janwillemb wrote: post #222
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…

"Don't rewrite an application from scratch. There is absolutely no reason to believe that you are going to do a better job than you did the first time." -- Joel on Software, Things You Should Never Do, Part I [1] [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

I do like that article but have ignored it several times for good reasons.

Re: The JVM is not that heavy

#316

Post by fnord123 »

uluyol wrote: post #307
fnord123 wrote: post #253

Earlier quoted context omitted.

"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?

I am saying that when you go from fully in memory (due to having a small dataset) to having to move things to and from disk, disk increasingly becomes your bottleneck rather than memory. And disk is much slower than memory.

I thought a main point of Cassandra was to be distributed so the working dataset could stay in memory across the cluster. And the smaller memory footprint you typically get when you're not in the JVM means more of your working dataset can be cached in memory. So I would expect superlinear speedups compared to Java for exactly the reason you describe (depending on the request distribution).

But yeah, I'm always up for pouring over more benchmarks. :)

Here are more details on benchmarks here:

https://qconsf.com/system/files/presentation-slides/avikivit...

The YCSB benchmark suite they use is the same one as used in this paper from the Cassandra homepage:

http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf

Re: The JVM is not that heavy

#317

Post by kazagistar »

Zach_the_Lizard wrote: post #289
ldev wrote: post #287

Earlier quoted context omitted.

Exactly, that's how some not very bright people were tricked into thinking that Node.js is actually fast.

And at work, we're now rewriting all those NodeJS services in Go or Java. We hired some Node maintainer(s) a long time ago, rumor has it, who got us on the Node train.

How do you do async in java? While it does have CompletableFutures now, none of the libraries (specifically databard drivers) seem to support it, so I always end up with a blocked thread per request.

Re: The JVM is not that heavy

#318

Post by jshen »

hrjet wrote: post #314
mike_hearn wrote: post #262

Earlier quoted context omitted.

Are you sure? I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immediately). It's a very poor default because even though there are technical arguments for doing that (goes faster), they a…

> I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I second that. I have deployed a medium traffic web-server written in Scala backed by a postgresql DB on 128MB VPS, back in 2009! > I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immed…

128mb is a lot compared to go which will often run around 10mb. Was your jvm back then 32mb or 64mb? If it was 32 your memory requirement will be higher on 64.

Re: The JVM is not that heavy

#319

Post by hrjet »

jshen wrote: post #318
hrjet wrote: post #314

Earlier quoted context omitted.

> I've written small HTTP servers in Java that can happily run with a heap of 30-50mb or less. Runtime overheads add some on top of that, but not much. I second that. I have deployed a medium traffic web-server written in Scala backed by a postgresql DB on 128MB VPS, back in 2009! > I think the perception of Java suffers a lot because it will consume all the RAM on your machine by default if you let it (but not immed…

128mb is a lot compared to go which will often run around 10mb. Was your jvm back then 32mb or 64mb? If it was 32 your memory requirement will be higher on 64.

128MB was the total RAM in the VPS including OS + nginx + JVM + Postgresql. The heap allocated to the JVM process was about 64MB, but bear in mind that this was an actual application. So, it's hard to do a detailed comparison between JVM and Go without standardising on the application. All that I am claiming is that JVM is in the same ball park.

Re: The JVM is not that heavy

#320

Post by geocar »

adrianN wrote: post #288
geocar wrote: post #273

Earlier quoted context omitted.

> Who said the 10MB is all used at once? The parent was suggesting that this was all that was actually needed out of the 100mb or so downloadable. If you think the JVM is smaller, how small is it exactly? > If you were referring strictly to CPU cache, then I'm even more confused, because the entire existence of that stuff is predicated on it being faster than memory, so... (and even still, if your total CPU cache isn…

Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching. You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application.

> Unless you linearly scan the whole binary all the time, your CPU makes sure that only the stuff you're currently using is in the cache, so only the data your hot loop is touching.

Cache fills optimize for linear scans, and have nothing to do with eviction.

> You could easily see that your assumption is wrong by observing that a typical C application is not 1000 times faster than a typical Java application.

What assumption are you talking about?

Where do you find your typical applications? Spark is supposed to be one the fastest Java-implementations of a database system, and it's 1000x slower than the fastest C-implementation database systems, but this is clearly a problem limited by memory.

What about problems that are just CPU-bound? C is at least 3x faster than Java for those[1], so just by being "a little bit faster" (if 3x is a "little" faster) then as soon as we introduce latency (like memory, or network, or disk, and so on) this problem magnifies quickly.

[1]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Post reply on HN