Native Memory Allocation in Java

From time to time, we run into a memory problem that is not related to Java Heap but Native Memory. Let's imagine the situation where we have a running container that is restarted once per day. We look at Prometheus/Grafana to check the reason behind this issue. However, we don't spot any problem with Java Heap size (exported via JMX) and start blaming our container scheduler to do any inconvenient operations with our containers :). The real problem can be hidden a bit deeper — in Native Memory.

Do you use any native memory allocator in your code or do you use any library that stores its internal state outside the Java Heap? It could be whatever third-party code that tries to minimize GC, such as I/O libraries or databases/caches keeping data in memory inside your process.

Pros and Cons for Using GraalVM Native-Images

Java is becoming very progressive with a new release policy and we receive regularly every 6 month new features, enhancements or just previews to test it out and write them back our feedback that can be taken into account in further development.

The second line might be even more interesting. It's GraalVM Project that especially contains a new C2 JIT Compiler and multi-language support based on Truffle Framework. There is one more technology that deserves our attention — GraalVM Native-Image. Native image is a utility for converting Java applications into fully compiled binary code which is called native-image. The process of creating a native-image is called ahead-of-time compilation.

Principles to Handle Thousands of Connections in Java Using Netty

C10K problem is a term that stands for ten thousand concurrently handling connections. To achieve this, we often need to make changes in the settings of created network sockets and default settings of Linux kernel, monitor the usage of the TCP Send/Receive Buffers and Queues, and, in particular, adjust our application to be a good candidate for solving this problem.

In today's article, I'm going to discuss common principles that need to be followed if we want to build a scalable application that can handle thousands of connections. I will refer to Netty Framework, TCP, and Socket internals and some useful tools if you want to get some insights from your application and underlying system.

Digging Into Sockets With Java Flight Recorder

Let's look at one amazing tool for gathering information about what's going on in your JVM — the Java Flight Recorder.
Let's look at one amazing tool for gathering information about what's going on in your JVM. The tool is called the  Java Flight Recorder, and in today's article, I'm going to use it to dig into how Sockets behave in your Java application.

A lot of people use HTTP APIs to communicate between their services (let's have another article about whether it's a good solution or not), and in a majority of cases, it works fine. However, we can get into situations where performance really matters, and especially for libraries writers, JFR can be a very useful tool to see I/O works in their code.

You may also like: Using Java Flight Recorder With OpenJDK 11

This article is not an introduction to Flight Recorder, it's rather more practical. If you want to learn more about this technology, you can start with JEP 328: Flight Recorder.

How to Split Up Synchronous and Asynchronous Parts of Your System in Java

A lot of developers say that it's very complicated to switch their applications over to asynchronous processing because they have a web app with naturally synchronous communication. In this post, I would like to introduce one way to do it using a few well-known libraries and tools to use while designing their systems. The example below is written in Java but I believe it's more about the basic principles and the same app can be re-written into any language.

Tools and libraries needed:

Increase Throughput by Eliminating Blocking Code in Your Java REST App

Blocking code is code which blocks executing threads until their operations finish. It's not always bad to block a thread and wait until the result is ready but there are situations where it's not optimal from a throughput and memory point of view. This article assumes some basic knowledge about the differences between blocking and non-blocking code.

What I am going to do is to introduce a very simple app with some blocking code inside and show you how you can easily figure out where your threads are usually blocked and then you might identify a better way to implement those certain parts of code and do it much more efficiently.

Pitfalls in JVM and Docker Defaults

First, there are a lot of articles about JVM and container-awareness:

In this post, I use Java 11, which means the default for garbage collector is supposed to be G1GC! Let's look at the defaults, which are automatically chosen by the JVM depending on memory size and provided CPUs.