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

201–210 of 373 posts

Re: The JVM is not that heavy

#201

Post by krallja »

nv-vn wrote: post #200
taneq wrote: post #189

Earlier quoted context omitted.

You don't need the entire executable file in cache in order to run the program. For comparison, a C++ wxWidgets 3.0 application isn't going to be much smaller than 10MB in release mode if you statically link it. Much as I hate to admit it, 10MB just isn't that big in an age of terabyte SSDs and systems with 32GB of RAM.

Not that the majority of users have that. Even eschewing those outside of wealthy countries, most users are on mobile devices (laptops, tablets, cell phones). Of those who have desktop PCs, very few have terabyte SSDs and even fewer have 32gb of RAM. For most people, RAM is probably somewhere between 4-8GB.

10MB fits comfortably within 4GB of RAM.

Re: The JVM is not that heavy

#202

Post by paulddraper »

nhumrich wrote: post #198

If you don't think the JVM is heavy try running it on a t2.micro. It can never get enough memory to start. I haven't ran in to any other language runtime that won't run on a t2.micro

Huh? I ran Atlassian Stash (now Bitbucket Server) on a micro while trialing it.

That's a many-hundreds-of-MB Spring enterprise behemoth of a Java server.

Have you ever tried running Java on a micro?

Re: The JVM is not that heavy

#203

Post by cutler »

bjoernw wrote: post #172
snuxoll wrote: post #147

Earlier quoted context omitted.

I mean, even the "enterprisey" stuff like Spring Boot is more than fast enough. I have a little REST service I just deployed to production today, 5 seconds to start up on my laptop's SSD (unfortunately it took about 50 seconds in production because our SAN is dog-slow for some reason).

How is Spring Boot "enterprisey"? It makes modern java programming simpler and more accessible by hiding some of the unnecessary complexity. It enables things like https://jhipster.github.io/ which to me is the Rails equivalent in the java world.

JHipster equivalent to Rails? You have to be joking, surely. I just setup a JHipster site and when I opened it up in IntelliJ it was the same labyrinthine mess I've come to expect from Java frameworks, ie. knee-deep in endless subdirectories and everything abstracted away to the point of incomprehension. Contrast that with the simplicity of Ruby and Rails. Java by its very nature makes it impossible to build simple, easily comprehended frameworks and apps. The trouble is that devs who have spent most of their lives in the Java ecosystem can only think relatively, ie. Java Framework X is simpler than Java Framework Y. Unless they expose themselves to something like Ruby or Clojure they will never experience true simplicity.

Re: The JVM is not that heavy

#205

Post by vardump »

geodel wrote: post #153
nightcracker wrote: post #86

OP is impressed by running 5 processes at once while claiming that the JVM is not that heavy. Is this cognitive dissonance? Dishonesty? I don't understand.

I think it is genuine sense of wonder of a web developer. I have been told many times to update my ancient hardware when I say Java is memory hog and slow on a 6GB Windows7 laptop. Some people don't think that those massive 16/32G MBPs etc with SSDs are not available to everyone.

6 GB? Your laptop is probably not running optimally, because 2 GB of address space has just 64-bit bus, 4 GB has 128-bit bus.

You should ensure both memory modules are same size (say, 4 GB or 8 GB), otherwise performance can suffer noticeably.

Re: The JVM is not that heavy

#206

Post by quanticle »

froh42 wrote: post #35
saosebastiao wrote: post #12

Interesting that all the comparisons were with server frameworks. As if anybody ever cared about a few hundred megabytes of overhead on a server. Hell, even a bloated JVM implementation fits in most server L3 caches. On the desktop, laptop, phone, or embedded environment, the JVM is heavy. It starts up slow, jars carry around ridiculous amounts of dead dependencies, garbage collectors require immense amounts of tunin…

Haha, AOT native compilation. This comes back time and time again. AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. Where AOT really makes sense is for an interactive app on a mobile device where you don't care about the last millisecond of performance bu…

    AOT native results in slower runtimes for applications with one simple 
    exception: startup time. In every other case a modern JIT compiler like the 
    JVM will win due to gathering information and layered compilation.
That's not necessarily true. JIT compilation is severely constrained in the amount of analysis that it can do for the simple reason that JIT has to be fast. Fast enough to not noticeably slow down the app. Meanwhile, an AOT compiler can take all the sweet time it needs, and roam all over the program in order to discover optimizations.

JIT compilers work very well on untyped languages like Smalltalk because the compiler can discover the type information at runtime, and then pre-compile the types that it sees most often. But that's not really that useful on the JVM, because Java is typed, as are most other JVM languages, with the exception of Clojure.

    Most funnily Microsoft was heavily advertising AOT with .net framework 1.0 
    but in general switched to dynamic profiling and optimization in later 
    versions of .net. (System assemblies that everybody uses during startup are 
    AOT compiled using ngen, however)
Actually, with .Net Native, Microsoft is back to advertising AOT.

http://blog.metaobject.com/2015/10/jitterdammerung.html

Re: The JVM is not that heavy

#207

Post by liveoneggs »

deepsun wrote: post #192
liveoneggs wrote: post #186

The reputation of "heavy" was hard-earned back in the bad-old-days (1.3 era) when EVERYTHING NEEDED to be written in java and the JVM still sucked . I, literally, had a party at work when we got our web app to three days of continuous uptime without an OOM error; nevermind that the early JIT (1.4 era) took 12+ hours to get "warmed up" and give peak performance. Don't misunderstand me- java's horribleness has given me…

I think topic poster point was that _other_ ecosystems (JS and Ruby) became so heavyweight that JVM now looks light in comparison.

It's true. node.js issues also pay the bills.

Re: The JVM is not that heavy

#208

Post by jmspring »

I've never had a problem with Java the language being heavy. However, many code bases due to annotations, dependency injection, etc. from a development perspective really aren't any longer Java. You need to understand the code base, the app itself, etc.

This happens with open source projects as well. I contributed to the Azure support for JClouds and the bulk of my ramp up time was understanding how things were done more than writing the code itself.

Re: The JVM is not that heavy

#209

Post by sk5t »

nostrademons wrote: post #176
martingxx wrote: post #110

Earlier quoted context omitted.

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?

Take a look at the TechEmpower benchmarks: https://www.techempower.com/benchmarks/ DropWizard is modern, but it isn't fast. Go and even Node.js are significantly faster. If you want performance, you cut layers out of the stack - check out the numbers for raw servlets or even just straight Jersey annotations in that benchmark. If I were doing JSON-over-HTTP microservices in Java, I'd likely use straight Jersey + Jacks…

On first glance the dropwizard test app appears to be doomed to mediocrity via reliance on hibernate.

Call me crazy, but I like my dropwizard with Spring DI for (singleton) resource setup, a micro-ORM to get work done, and HikariCP datasources at runtime.

Re: The JVM is not that heavy

#210

Post by CountHackulus »

Jeaye wrote: post #157
jwr wrote: post #149

Earlier quoted context omitted.

Yes, the startup is slow. But nothing afterwards is. The JVM gets bad press because of startup time while in reality that hardly matters.

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'd say that this is both expected and the correct behaviour.
Post reply on HN