How does OAuth work in REST API?

Why is Kafka important?

What is a JEP in Java?

How much do software engineers make?

The Promise is still relevant and great for async operations where you are only concerned with the result of one async operation.  While the observable handles this well with Angular, it's still perfectly reasonable to use the Promise library for http requests, etc.

stackchief

Quickly understand JavaScript observables.  Implement the Observable class from scratch and understand what makes observables different from promises.

JavaScript Observables in 5 Minutes

@Qualifier annotation example in Spring Boot including @Qualifier vs @Primary, the use of @Qualifier and examples.

 @Qualifier Example | Spring Boot

MongoDB aggregate vs find performance?

What is the difference between TLS and HTTP?

most Java developers take JIT compiler for granted.  It is largely a black box that automagically seems to optimize performance.

While taking advantage of this is something we all do, this article sheds some light on the innerworkings and i love it.

Java is both a compiled and interpreted language. While the javac tool takes the source code .java files you writes and compiles them to bytecode .class files, the JVM interprets this bytecode to produce machine code. This machine code is then fed to the CPU to ultimately process or run your program.

To maximize performance, Java utilizes a just-in-time (JIT) compiler to dynamically compile bytecode to machine code.  This JIT compiler is baked into the JVM and works automatically without any developer intervention.

While developers rarely need to concern themselves with the inner workings of this JIT, it's beneficial to understand what's happening under the hood.  This starts with understanding the difference between compiled vs interpreted languages..

Preface: Compiled vs Interpreted Languages

Languages like C and C++ are compiled languages.  These languages compile source code into an executable binary file that runs directly on the processor (CPU).

Compiled languages are good because they don't require any overhead during runtime.  Unlike an interpreted language, compiled code doesn't need to be evaluated at runtime.  This makes compiled languages generally faster than interpreted languages.

Compiled languages can be bad because they lack portability.  The compiled binary output is often specific to a certain architecture or platform.  The compiled output of your program may work on this machine but not that machine etc.

Compiled languages are also slower on startup and during testing.  This is because they need to be compiled first!

Languages like php, Python, and JavaScript are interpreted languages.  These languages rely on a separate program (the interpreter) to "interpret" the code during runtime.

Instead of compiling the source code upfront, interpreted languages read source code line by line, generating the binary instructions through the interpreter itself.  This makes it possible for interpreted languages to be "platform agnostic" meaning they can run on different platforms the same way.

Interpreted languages are good because they are portable.  You can download php for Mac, Windows, etc and your program will execute the same way.

Interpreted languages are bad because they take longer to execute code.  Unlike a compiled language, interpreters can't feed compiled code directly to a processor.  They have to "interpret" the source code line by line.

Interpreted languages make for faster startup times.  You don't have to wait for the compile step when your program starts.

The JIT compiler allows Java to be both a compiled and interpreted language.  It combines the performance advantage of a compiled language with the flexibility of an interpreted language.

When your Java program executes, the JVM interprets bytecode as part of code analysis and optimization.  It then uses this analysis to dynamically compile and store frequently reused methods to avoid interpreting the same bytecode over and over.

What does this JIT compiler look like?  Where does it live? How does it work?

The JIT compiler is part of the JVM that continuously runs to optimize performance.  While the JVM interprets bytecode, the JIT analyses execution and dynamically compiles frequently executed bytecode to machine code.  This prevents the JVM from having to interpret the same bytecode over and over.

The JIT compiler is not some separate application you download and run alongside your program.  It is simply a description of functionality that exists within the JVM.

The source code you write (.java) is compiled by javac to bytecode. When your program executes, the JVM starts interpreting this bytecode.

The interpreter translates the bytecode into machine code and feeds it to the CPU for processing.  While this happens, the JIT profiles and analyses the code execution.  It tracks the most frequently called methods and dynamically compiles these to machine code at runtime.

This dynamic process prevents the interpreter from having to "interpret" the same methods over and over.  Instead of having to translate bytecode to machine code, the interpreter can instead leverage cached machine code instructions from memory.

This is what makes Java both a compiled and interpreted language.  While the JVM initially interprets code, the JIT compiler works to selectively compile frequently executed code "just in time".

This gives Java the advantage of interpreted languages (faster startup times, more portability) and compiled languages (faster execution, optimized performance).

Client Side, Server Side, and Tiered Compilers

Before Java 8, you could specify either client or server JIT compilers.  While client compilers were better suited for apps having fewer resources available, server compilers worked better for long running apps.

A client side application may be more sensitive to startup time and have fewer resources available for code optimizations and JIT overhead.   A server side application may be long running and more appropriate for heavier optimizations and longer compile times.

The key difference between the two is the level of optimization and profiling. While profiling allows the JIT to better optimize the machine code it sends to the processor, it comes with a performance cost. Client side compilers minimize profiling to reduce overhead and startup time whereas server side compilers rely more heavily on profiling and optimizations.

Beginning with Java 8, the JVM takes a "tiered approach" where both client side and server side techniques are used.  During execution, the JVM initially interprets the bytecode.  It tracks frequently used methods and optimizes code based on the client side (C1) approach.  The JIT continuously analyzes execution and migrates to more of a server side (C2) approach for additional optimizations.

While modern Java installs utilize the tiered approach of combining C1 and C2 compilers, the C2 compiler is dated and hard to maintain.  For these reasons, the Graal JIT compiler was developed as part of a larger GraalVm project.

The Graal JIT compiler is written in Java, giving it the advantage of IDE integration, exception handling, and integration with profilers and debuggers.

The Graal JIT compiler also allows ahead of time (AOT) compiling where execution code is compiled upfront.  This reduces startup time experienced with the conventional JIT compiler.

There is a popular misconception that you can "download" a JIT compiler for Java.  While older versions allowed you to install a JIT as a plugin, all standard Java installations include the JIT compiler as part of the JVM.

As the JIT dynamically compiles code to machine language, it also performs optimizations on your source code to maximize performance.  Following are some examples of these optimizations:

The JIT compiler will optimize the original myMethod() through several steps...

Notice how the get() method is replaced with directly accessing the value. This eliminates method invocations and improves efficiency.

By setting z = a, the compiler reduces the latencies of accessing b.value to improve performance.

Notice how this optimization removes unnecessary variables. Since z ultimately just equals a the JIT compiler removes it altogether.

Since a = a is redundant, the JIT compiler simply removes this "dead code" during optimization.

Apart from these steps, JIT compiler also includes other optimizations like:

Let's say you have a basic null check like:

If JIT notices myVar is never called with null then it will remove this code altogether.

Let's say you have an if..else branch like this:

If the JIT compiler notices that x < y more often than not, it will reverse the branch...

If you have a nested loop, the JIT compiler will unroll it to minimize assembly jumps..

The JIT Compiler in Java including what is the JIT compiler, how the JIT compiler works, JIT compiler optimizations and more.

The JIT Compiler in Java

How does the JIT compiler work in Java?

This happens when Java can't find or load the class running your application.

It sounds obvious but this error can happen for very frustrating reasons like:

IDE configurations if these are off then your JRE may not look for things in the right places. Specifically if you've configured the wrong class as the main entry point of your application you're going to have issues...

Wrong Class Name like if you run your program with helloworld and the class is defined as HelloWorld...

Wrong extension like when you run "java HelloWorld.java" when you should run "java HelloWorld"...

Wrong Class Path like when you run your application specifying the -cp argument and it points to the wrong place...or if you run your application from the wrong directory.

What causes Java "Could not find or load main class" error

What causes Java "Could not find or load main class" error?

Understanding Java garbage collection begins with the heap and the stack. If you aren't familiar with <a id=1 href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>Java Heap vs Stack</a> be sure to read <a id=1 href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>this</a> first.

Garbage collection is the automatic process for handling memory management.  Memory management is the dynamic process of allocating/deallocating memory to/from your application.

Memory management is not unique to Java.  Every programming language must provide a means of requesting memory from the underlying OS and releasing memory when it's no longer needed. This allows programs to run without consuming too much memory or causing applications to crash.

Some languages like C and C++ require a manual process for allocating/deallocating memory.  Programmers must write constructor and destructor functions to allocate memory when it's needed and release it when objects are no longer being referenced by the application.

While this manual process gives developers more control over memory management, it's ultimately more tedious, repetitive, and vulnerable to memory leaks and other errors.  For these reasons, programming languages like Java implement an automatic garbage collection mechanism for managing memory.  This mechanism operates independently from the application code allowing developers to write code without worrying about memory management.

Why is garbage collection important in Java?

Garbage collection (GC) is important because it automatically handles memory management in Java.  This makes Java memory-efficient without the developer's intervention. As a developer, you can write Java code without worrying about memory allocation.  GC handles all of this for you.

While GC "magically" handles memory management for the developer, it's still important to understand what's going on under the hood. If you've ever experienced a OutOfMemory exception then you know GC won't save you every time. Furthermore, there are different implementations of GC and various configurations for optimizing this process based on the nature of your application.

Having a good grasp on the GC mechanism will help you write better code and avoid performance issues related to memory management.

Java applications run inside the JVM. The OS running your Java program allocates a configurable amount of <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>heap space</a> memory to the JVM for running your applications.

The above are two sample arguments for configuring min and max <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>heap space</a> for the JVM.

Since the JVM has a predetermined allotment of memory for running applications, it doesn't need to synchronize with the underlying OS for memory resources.  Instead, it can utilize this same memory space and free up unused memory without deleting or requesting more from the OS.  This is fundamental to what makes Java memory-efficient as a programming language.

Application execution: Java Heap vs Stack

When your application starts up, classes and methods are loaded into the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>heap space</a>. As your program executes, objects are created and referenced in the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>heap space</a> by the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>stack</a>

While the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>heap</a> represents a global space of memory that exists throughout the duration of your application, the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>stack</a> only exists during method or thread execution. Once a method finishes execution, the memory used is released from the stack via a relatively simple FIFO approach.

This simple approach is sufficient for automatically handling memory living in the stack (local variables and references to objects stored in the heap) but what about actual objects referenced in the heap?

Since the heap space is much larger and more permanent, it must be managed through more sophisticated means.  This is where GC comes into play.  GC automatically handles the memory used by the heap space.

Confused? I highly recommend checking out <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>Java Heap vs Stack</a> before continuing any further...

With the understanding that memory management for the heap is automatically handled via GC, it's time to understand exactly how GC works in Java.

GC works by identifying or "marking" unused objects by the application.  An unused object is anything that isn't being referenced by a GC root.  A GC root is either:

1) Objects referenced in the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>stack</a>

2) Objects referenced by class static attributes

These special "root" objects give GC a starting point to search for "living" objects.  Any object that isn't referenced by one of these root objects is considered "unused".  Take the following code snippet as an example:

    public static final MyClass myC = MyClass("final");

While setting c = null will dereference c, it's static member myC won't be garbage collected after testMyClass() executes.

Since the instance of MyClass c is created within the <a href='https://www.stackchief.com/blog/Java%20Heap%20vs%20Stack'>VM stack</a>, it will be garbage collected.

A combination of the following GC algorithms are used by modern GC collectors in Java:

GC algorithms follow a high-level "mark-sweep" phase concept.  In the "mark phase", GC identifies objects that are no longer being referenced by the application.  In the "sweep phase", the memory addresses used for these unreferenced objects are freed up by the JVM.  This essentially "deletes" the unreferenced objects and makes memory available to the heap.

While the "mark-sweep" algorithm is fairly simple, it presents problems related to fragmentation.  When memory is released, it becomes available in many fragments or segments.  Since memory is allocated in contiguous blocks, this makes it harder to assign address space and wastes unused memory.

Unlike the mark-sweep algorithm, the copy algorithm avoids memory fragmentation by copying all of the "unmarked" living objects to a new space.  This is more efficient as living memory can exist in a contiguous block.  The downside is memory is less efficiently used as memory space must be reserved as a "destination" for copied data.

This is a hybrid of the traditional mark-sweep and copy algorithm.  Mark-compact identifies unused objects similar to mark-sweep.  Unlike mark-sweep, mark-compact moves living objects to one end of boundary and reclaims the leftover space.

This is similar to the copy algorithm in that living memory is isolated from unused memory.  Unlike the copy algorithm, mark-compact moves memory instead of copying it.

While mark-compact provides a nice hybrid approach to mark-sweep and copy, it takes a performance hit with frequent manipulation and sorting of the memory space.  For these reasons, generations and regions are used with GC.

GC algorithms have their pros and cons.  While "mark sweep" is simple, it introduces fragmentation.  While copy eliminates fragmentation, it wastes memory.  While mark-compact serves as a nice hybrid, it can be inefficient.

To leverage these tradeoffs, heap space is divided into blocks called "generations".  These blocks categorize objects based on their age or how long they've been in the heap.

By categorizing objects as "young" vs "old", GC can run different algorithms best suited for the lifespan of memory...

The young generation of the heap holds all newly created objects. This space is further divided into the Eden and Survivor space:

Empirical data and research shows that 98% of objects created are short lived. For these reasons, most newly created objects are allocated to the Eden space. When the eden space becomes full, minor gc takes place. During a minor GC event, objects surviving the eden space are moved to the survivor space.

The survivor space itself exists in two spaces (S0, S1).  This is sometimes referred to as the "to" and "from" space but the important thing is that two separate spaces exist within the survivor space.

When a minor GC occurs, surviving objects from the eden space are moved to the S0 space.  The next time GC occurs, surviving objects from eden and S0 are copied into S1.  The next time GC occurs, surviving objects now living in S1 are copied (along with Eden objects) to the S0 space.

Why is this so complicated? Why can't the eden space graduate objects to the old generation if they survive GC?  It turns out the survivor space(s) act as a buffer between young and old generation.  While many objects may survive a single "minor GC event", they won't likely last more than a few cycles.  The survivor space gives objects the "opportunity" to die as it collects anything surviving up to 16 GC cycles.

Remember the copy algorithm?  By having two spaces in the survivor space, one space can be used as a destination for everything copied over from the eden and other survivor space.  This eliminates the memory fragmentation issue and works well for more short-lived objects found in the younger generation.

If an object survives enough rounds of minor GC, it will be promoted to the old generation.  Major garbage collection events are performed on the old generation.

Major GC happens less often and adopts a "mark-sweep" algorithm for cleanup.  This is better for the older generation space as most objects are long lived.  This minimizes the number of objects needing to be "marked" and resorted as per the "mark-sweep" approach.

If an object survives enough GC events, it will eventually be promoted to the old generation space.  Other objects, such as very large objects, will automatically be promoted to the old generation space.  Objects that can't fit within the eden/survivor space will be promoted to the old generation.

Older implementations of GC represent the heap space as one contiguous block of memory.  More modern implementations used with Java 8, 11+ implement a "garbage first" (G1) approach to GC.

With the G1 approach, the heap space is divided into equally sized heap regions.  Each region can represent a different generation at any given time.  While a region may sometimes represent a young generation (eden, survivor space), it may represent an old generation after being reallocated.

By subdividing the heap space into regions, multiple threads can scan regions in parallel.  Generations aren't confined to a predetermined size and can dynamically change (young space vs old space) based on the algorithm's needs.

Regions also work to identify spaces with the most garbage (fewest live objects) during global "mark" phases.  These regions are "evacuated" by copying any surviving objects to a new single region.  This compacts and frees up memory in parallel ultimately leading to faster throughput and smaller pause times.

Through the use of regions, you can see how the G1 collector performs differently than alternatives.  So what are these alternatives?

Serial GC: This is the most basic implementation of GC. Utilizing a single thread, the application is paused and GC is performed. Once GC has run and compaction is complete, the application thread resumes.

Serial GC is the most basic form of GC and is not recommended for use in environments where low latency is emphasized. You can use serial GC by specifying -XX:+UseSerialGC.

Parallel GC: Also known as "throughput collector", parallel GC works by utilizing multiple threads to perform young generation collection. A single thread is used for major GC in the old generation.

You can specify parallel GC with the -XX:+UseParallelGC option.

Parallel Old GC: Very similar to Parallel GC except that multiple threads are used across young and old generations. You can specify use of Parallel Old GC with the -XX:+UseParallelOldGC.

Concurrent Mark Sweep (CMS) GC: Unlike the already mentioned alternatives, CMS works concurrently with the application execution. Multiple threads work alongside application threads to minimize the pause time in between GC cycles.

While CMS sounds great, it only pays off if you have the CPU power to throw at it.  CMS requires more CPU and no compaction is performed with this option.

You can enable CMS with the -XX:+UseConcMarkSweepGC option (deprecated)..

G1 (Garbage first): This is the default GC used in modern Java programs. Since G1 prioritizes GC on regions having the most garbage (fewest live objects), it's considered "garbage first".

Epsilon: This GC was released as an experimental feature of JDK 11. The reason for using Epsilon is essentially to not use a memory reclamation mechanism at all. Since memory reclamation can be a costly to performance, the Epsilon GC is meant for hyper low latency applications where memory is being handled well by the developer.

You can enable Epsilon with the -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC.

Shenandoah: Shenandoah is relatively new (released as part of JDK 12). It's basically the newer/more improved version of today's G1 collector and can evacuate its heap concurrently with the application. While more CPU intensive than G1, Shenandoah can be thought of as a "better" version of G1.

You can enable Shenandoah with the -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGCM/span> option.

ZGC: Released with 11 and improved with 12, ZGC allows the application to continue running while performing all GC operations. ZGC prides itself on the lowest pause times and points to the future of GC in Java.

You can enable ZGC via the -XX:+UnlockExperimentalVMOptions -XX:+UseZGC option.

GC is performed automatically in Java whenever the Eden space becomes full. If there isn't enough free space around to allocate an object, GC will also be performed.

Minor GC events occur every time the Eden space reaches capacity.  A major GC event occurs whenever younger generations are full or when the older generation becomes full.

Major GC also occurs whenever you force garbage collection programatically....

Garbage collection in Java including understanding what is garbage collection, why garbage collection, how garbage collection works in Java, force garbage collection, monitoring garbage collection and interview questions.

Garbage Collection in Java

much better than other explanations out there...

The Java ObjectMapper including what it is, how it works, and examples of using the ObjectMapper with Jackson Annotations

imDifferent

How does OAuth work in REST API?

Why is Kafka important?

What is a JEP in Java?

How much do software engineers make?

JavaScript Observables in 5 Minutes

@Qualifier Example | Spring Boot

MongoDB aggregate vs find performance?

What is the difference between TLS and HTTP?

The JIT Compiler in Java

How does the JIT compiler work in Java?

What causes Java "Could not find or load main class" error?

Garbage Collection in Java

Java ObjectMapper | What it is | How it works

imDifferent

How does OAuth work in REST API?

Why is Kafka important?

What is a JEP in Java?

How much do software engineers make?

JavaScript Observables in 5 Minutes

@Qualifier Example | Spring Boot

MongoDB aggregate vs find performance?

What is the difference between TLS and HTTP?

The JIT Compiler in Java

How does the JIT compiler work in Java?

What causes Java "Could not find or load main class" error?

Garbage Collection in Java

Java ObjectMapper | What it is | How it works

Trending