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

261–270 of 373 posts

Re: The JVM is not that heavy

#261

Post by nikcub »

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right:

* a small and fast CLR (JVM)

* a class library that defaults to almost nothing but primitive classes

* proper and standardized version, platform and package management (NuGet)

* open source and MIT license[0]

* a patent promise[1]

* arguably the best dev IDE available (Visual Studio) and one of the best up-and-coming dev text editors (VS Code)

* Native ORM, templating, MVC, web server so there is one way to do things

* open source middleware standard (OWIN)

* they left out, for now, attempting the hard ugly stuff like x-platform GUI

* all platforms are equal citizens, they acquired Xamarin for dev tools and release their own Docker containers.

* it's already getting good distribution (on RedHat) even tho it's only 6 months out from a 1.0 release.

Java may have missed the window for fixing some of these issues in their platform - I feel that if Android were being developed today, they'd almost certainly take .NET Core as the runtime.

I've yet to commit to using .NET Core anywhere, but from what I know about it so far it is impressive.

[0] https://github.com/dotnet/coreclr

[1] https://raw.githubusercontent.com/dotnet/coreclr/master/PATE...

Re: The JVM is not that heavy

#262

Post by mike_hearn »

jshen wrote: post #226
exabrial wrote: post #167

Earlier quoted context omitted.

These types of arguments cause many intelligent people to headdesk. They're hardly an apples to apples comparison. Of course "Go was Faster". It's because you started with a clean slate!

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 aren't well known and people tend to assume "more memory usage == worse design".

There are a lot of myths about the JVM out there. We can see on this thread the idea that it takes 1.5 seconds to start being repeated multiple times, each time someone else points out that it's actually more like tens of milliseconds to start.

Re: The JVM is not that heavy

#263

Post by aedron »

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

I'm running a bunch of Java stuff off a t2.micro, runs fine.

Re: The JVM is not that heavy

#264

Post by makapuf »

noselasd wrote: post #76
makapuf wrote: post #59

Earlier quoted context omitted.

$ ls -sh /usr/bin/gcc-5 896K /usr/bin/gcc-5 $ ldd /usr/bin/gcc-5 linux-vdso.so.1 => (0x00007ffc64bf5000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda3da4f000) /lib64/ld-linux-x86-64.so.2 (0x000055f2460a1000) (so no specific .so dependencies) And why would you need that in production ? (hint: use fpm) This article seems strange : why do you include xcode in npm ? why use a mac if it's that heavy ? sure an…

I certainly agree that you don't need that for production machines. However /usr/bin/gcc is just a frontend, and calls a slew of other binaries(such as cpp, collect2, cc1, normally found somewhere in /usr/libexec/gcc/). You also need binutils, and to be useful, likely headers for at least the standard C library. The gcc + binutils package comes up at around 75MB on my machine.

I stand corrected - duh of course I should have added called binaries. So it seems 100M is the right ballpark.

Re: The JVM is not that heavy

#265

Post by eklavya »

beagle3 wrote: post #249
CountHackulus wrote: post #210

Earlier quoted context omitted.

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 have, and gave up after a month of touching every couple of days trying to find the sweet spot. Someone more familiar with JVM internals would have probably succeeded - but somehow C Python Go and even OCaml runtimes don't need this level of tuning in my experience. JVM deployments tend to assume nothing else happens on the same machine, in my experience.

You last point is probably true. In every application I have ever deployed I only ever set the Xmx and J-Server settings, I never faced any problems. You need to give the GC some breathing room though.

Re: The JVM is not that heavy

#266

Post by dm3 »

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).

Actually, the new G1 collector deals very well with latency-sensitive workflows. I'd say it's comparable to Go if you adjust your heap size to the working set. You can try running the benchmarks here - https://gitlab.com/gasche/gc-latency-experiment.

Re: The JVM is not that heavy

#267

Post by jerven »

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).

Just use one of the other JVM's that have GC that are latency optimised such as Zing from Azul, Metronome from IBM or OpenJDK with Shendoah from RedHat.

The power of Java is that there is more than one JVM and that can really save you a lot of money/developer time if the world changes under your ass ;) i.e. had a JVM based graph database, ran it on Hotspot -> big GC pauses, moved to Zing no more pauses. All we needed to do is run a different VM and problem went away (new problem was of course that Zing costs but not much, also now with Shendoah coming for free we could probably have moved to that)

With GO you can't do that yet. If your app is not latency, bound but throughput bound there is no place to switch too other that a rewrite. That flexibility of deployment on JVM tech gives us a lot insurance for no costs, until we need it.

Re: The JVM is not that heavy

#268

Post by mike_hearn »

hannob wrote: post #100

I must admit my experience is a few years old, but one thing that the whole text doesn't mention and that has contributed a lot to the negativity I feel towards the java ecosystem: It seemed not well integrated in the Linux ecosystem. What do I mean? I often experienced that Java dependencies were not readily available in Linux distros. Packaging Java stuff was - weird and complicated, not sure how to better phrase i…

Python, Ruby, JavaScript etc all have their own dependency repositories and packaging systems. Java does too. It's not Java that's the problem here, it's the Linux distros that insist on packaging everything themselves (almost always badly).

You could if you really wanted to just auto-convert Maven Central to DEBs. The metadata is there. The problem is that "dependency hell" would then visit you in the same way it does for Linux apps. Upgrading libraries is something that should either be done by developers, or by OS vendors very carefully, not by having some random part time packager run a script and push a new version that immediately propagates down to everyone else without any app-compat testing.

Re: The JVM is not that heavy

#269

Post by mike_hearn »

Jach wrote: post #183

Work on an enterprise-sized "app", the JVM starts seeming "heavy". It feels super slow (and memory greedy, and you have to make sure it has enough of the right 'type' of memory) in executing on a whole (when it gets going it can do limited, specific things quite fast) and for productivity, as does all the tooling around it. Unless perhaps you're Google and you have server farms constantly compiling crap and so on so…

I think a part of the reputation of Java being big and slow comes from its popularity in the enterprise. This is partly because in that space you're usually writing apps for a captive audience (your fellow employees) so there isn't much incentive to optimise. The business managers understand things like "the app has feature X by date Y" but don't really understand or care about "it is productive to develop on this app" or "the app uses half as much memory as last month". Those things make the lives of developers nicer, but don't change much about the business.

Moreover, I think enterprise software managers often don't really have a grip on how much work needs to be done or how long it should take. So you can get situations where a team of say 10 people is staffed up to build an in house app, they deliver it, there are some improvements that can be made, they deliver the improvements, etc. After a few years the app is largely in maintenance mode and doesn't need much done to it, but ... who wants to fire the loyal employees who understand the app? Unless there is another app of roughly the same size and type waiting in the wings, what can happen is the team starts doing busywork. The managers don't notice because they aren't programmers to begin with and can't tell the difference between "creating a new in house framework because no reasonable alternative exists" and "creating a new in house framework because we're bored".

So over time enterprise software can bloat to extreme levels. Combined with Java's verbosity, and the fact that a long time ago it really was very slow, you get a platform with a reputation for ponderousness that is only partly deserved.

Re: The JVM is not that heavy

#270

Post by geocar »

hota_mazi wrote: post #213
geocar wrote: post #144

Earlier quoted context omitted.

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

> I don't know. 10MB still sounds really too big. Can't tell if sarcastic or... o_O. In the unlikely case you're actually serious, you really need to rethink your perception of memory costs in 2017.

No, I'm really quite serious.

KDB[1] is about 1000x faster than Spark[2], and is only about 600kb (and most of that is shared library dynamic linker stuff that makes interfacing with the rest of the OS easier). A big part of why it's fast is because it's small -- once you're inside cache memory everything gets faster.

That's the real cost of memory in 2017. So what did we gain for paying it?

[1]: https://news.ycombinator.com/item?id=13481824

[2]: http://tech.marksblogg.com/billion-nyc-taxi-rides-spark-2-1-...

Post reply on HN