JVM. Intro

Java Virtual Machine

TL;DR; JVM is an application that can be configured by CLI parameters, environment variables and configuration files, called java classes. Classes tell the JVM WHAT to do; env variables and CLI parameters tell it HOW to do those things.

"Java eats up all the memory!", "java is bloated", "java is slow", ...
All of the above is true if are using the JVM wrong. The JVM (Java Virtual Machine) is itself an application, like any other on your computer. In GUI applications (Notepad, VLC, Chrome,..) you can ask an application to do things for you by clicking buttons, links, entering data manually. You can ask most of the applications to do things by passing them command-line parameters. As for JVM - it's also an application, that can be asked to do things: either via command-line parameters, via environment variables or via long configuration files written in java bytecode, called java class files. As it is with most of the applications, configuration files are passed to the java.exe application when you start the process.

It's not exactly the traditional perspective, is it? :) Nevertheless, it is correct. Java application code is nothing but a configuration file for the Java Virtual Machine. JVM, once started, reads that java (byte)code and does what it's asked to do. That also holds true for most (if not all) (pseudo)interpreted programming languages: python, groovy, javascript, PHP, bash, etc.

Why the middle-man?

That is a good question. Well, there are several reasons. The middleware (the middleman) allows you to write code only once and run it on all the platforms that the middleware can run on. Consider Python - you can install Python on nearly any device and when you write python code, you don't need to worry about the CPU architecture, memory (de)allocation, memory layout, system libraries, etc. If you managed to install Python on 15 different systems, it means you will be able to run the same .py file on all of them.

The middle layer also decouples the "HOWs" from the "WHATs". Your application code doesn't have to cover HOW you want things to be done. You only have to code WHAT you need to be done. All the rest will be taken care of by the middleware.

And the latter is the reason why I love Java the most. Not only it decouples application code from platform intricacies, but it also allows you to tweak them separately, also, in a platform-independent way! It allows you to configure your network stack, memory management, optimization techniques, security, monitoring and many, many other nuts and bolts are at your disposal.

In other words, you can configure HOW the middleware works. You have all the means to optimize or kill the JVM's performance.

Okay, but middle-man means it's slower, right?

Yes, and no. JVM was significantly slower in the '90s and 2000s. The hardware was very limited, sluggish, the JVM was slowish as well -- all that added up to significantly slower responsiveness, when compared to native applications (low-level code, like C, C++, ASM, ..., that, once compiled, is run directly on the CPU). However, since those days Java has implemented plenty of optimization tricks to boost its performance. It's still not as fast as compiled C code, but in most cases, it is so close that you might not feel the difference. You know, how CPUs have the branch prediction hardwired, trying to guess what the application will try to do next? Well, the JVM has very similar techniques as well, on top of the branch prediction.

How to use the JVM "right"?

Complaining, that java is bloated, just because default settings are no longer enough for you, is like complaining, that cars are useless at night because they come with their headlights off by default.

Usually, the default settings are enough for most applications. The rule of thumb is: "keep defaults unless they are no longer enough". Each application requires different system resources in different amounts and patterns, so it's only natural that defaults for some applications will not be enough. Others run in containerized environments, or on hardware that allows for performance optimization - you might need to change the defaults there too. If you see that your JVM is growing in size beyond levels you can tolerate, it means that defaults are no longer enough and it's a good time to change them. Complaining, that java is bloated, just because default settings are no longer enough for you, is like complaining, that cars are useless at night because they come with their headlights off by default.

Written with StackEdit.