Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

301–310 of 373 posts

Re: The JVM is not that heavy

#301
post #218

Earlier quoted context omitted.

Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.

I could use the exact same arguments but for PHP.

Not quite, I omited here that it is also statically typed and is a future proof language. Mainly because these are properties already shared with Java. However this is not true of PHP.

PHP is a great velocity language, provided you have a small(er) team or are willing to commit to additional controls on how you write your PHP (document types/structure of arguments mainly) to ensure that your PHP code is able to be read quickly by other developers.

Personally I prefer Go here because it enforces good readability by default and therefore scales better with team size.

Re: The JVM is not that heavy

#302
post #261

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…

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.

I couldn't agree more. I constantly see this claim made about Visual Studio. I find it to be in the way most of the time. It does sound like most of the features that I want are in Resharper; I'll have to try it out.

Re: The JVM is not that heavy

#303

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…

Java8 has profiles already, Java9 will be able to customize further. I'm not a Java guy, but node.js after npm-install the suddenly increased base is hundreds MB easily, I somehow now feel Java/whatever is better organized and manageable. After learning node.js for a product for a few months, I'm actually returning to PHP7, which has nearly identical OOP as Java.

Re: The JVM is not that heavy

#304
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…

> it will consume all the RAM on your machine by default if you let it

I wonder if Oracle documents are plain wrong for JDK 8 docs for maximum heap size[1]:

"Smaller of 1/4th of the physical memory or 1GB. Before Java SE 5.0, the default maximum heap size was 64MB. You can override this default using the -Xmx command-line option.

Also Oracle has chosen correct defaults because it took Java long time to shed its reputation of being dog slow and if they optimize for memory it will start looking worse in performance.

1. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...

Re: The JVM is not that heavy

#305
post #153

Earlier quoted context omitted.

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.

It was given by company I was contracting for few years back. I recall Laptops were 'upgraded' to 6GB from 4GB to give developer better performance.

I think my main point was making luxury as basic because even more luxurious stuff exist.

Re: The JVM is not that heavy

#306
post #261

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…

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

What is the status of this? Will MS be bringing WPF (XAML) to all platforms?

Re: The JVM is not that heavy

#307
post #30

Earlier quoted context omitted.

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?

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.

Re: The JVM is not that heavy

#308

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.

What is better than VS? PHPStorm etc?

Re: The JVM is not that heavy

#309
post #13

I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…

4. Garbage collection. The fact that Java does not have a refcount collector, that can release memory back to the process's pool as soon as something goes out of scope and is no longer referenced, is horrid. Nearly every major software written in Java goes through the worst kind of struggle wherein users have to assign a 4 GB heap size to run a service that only really needs 500 MB. When fatal Out-Of-Memory crashes a…

I'm sorry to call out this comment specifically, but almost everything you said here is not true. Out-Of-Memory crashes are not the status quo. The JVM garbage collector is (generally) a very high performance system that has improved incredibly over the past decade, it's not as simple as saying it's missing reference counting so it's "horrid".

These are the kind of lazy generalization that causes people to make poor technology decisions.

Re: The JVM is not that heavy

#310
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…

Try to do it and shoot me a github link. Trust me, I've tried, but I'm no JVM expert so there could be some magic flag I'm unaware of.

I can get it to start around 30-50mb, but as soon as you hit it with traffic the memory usage jumps up.

Post reply on HN