Virtual Threads : Java 21

Java 21 came with an exciting feature of Virtual Thread - Lightweight Threads. The idea is to achieve optimal hardware utilisation, which has been a bottleneck for the conventional java.lang.Thread - platform threads.

Platform threads are 1:1 mapped with OS Thread, which makes them powerful to accomplish all possible tasks. java.lang.Thread is a thin layer on actual OS threads, which are quite heavy. The number of thread application can support depends on the hardware capacity of the system.

Let’s say thread memory consumption is 1 MB, to support 1 million threads in concurrent application at the time of heavy load, you will need 1 TB of memory. One thread per request style of implementation also suffer due to this limitation - asynchronous programming can solve this upto some extent but it has its own drawbacks.

Virtual threads effectively shares the platform thread. Rather than holding the platform thread for entire lifetime, it runs short lived tasks and for the needed executions - not while it waits for I/O. This allows insane number of concurrent operations without need of additional threads or hardware capacity. This brings up the new way to deal with concurrency in Java applications.

Virtual threads can be created with java.lang.Thread builder approach,

Runnable function = () -> System.out.println("Something to execute in Virtual Thread!");
Thread virtual = Thread.startVirtualThread(function);

In addition to that, java.util.concurrent.ExecutorService also has factory method for Virtual threads,

ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor();

Virtual threads are daemon threads, join() to wait on the main thread. Thread local variables of virtual thread are not accessible to carrier thread or vice versa.

Deep vs Shallow Copy

In programming language like Java, everything revolves around objects. Lifecycle of object from creation to garbage collection is something that keeps happening continuously in any realtime application.

There are different ways you can use to create and Object of a Class. However, the object creation with new keyword is the straightforward one.

Car mercedes = new Mercedes();

While we keep creating objects on-demand, in some realtime scenarios we may need to create new object which is a copy of existing object. In that case new Object should hold same state as current Object is holding.

You may ask, what kind of scenarios require copying existing object?

Well, it completely depends on the software you are developing but in any application where you see copy option, whether it can be copying table row, copying form etc. such cases are good candidates to use object copying mechanism.

There are two approaches you can use to copy object,

• Shallow copy

• Deep copy

There are different methods to implement copying approach,

• Using clone method

• Copy constructor

• Static factory method

There are certain third party libraries available which provides methods to copy the objects.

For example, BeanUtils#copyProperties(Object destination, Object source)

Which option to choose majorly depends on your requirement.

Shallow copy

All the fields of existing object is copied to new object.

Consider following diagram, while copying Car object, company object reference is reused in the copy object, which simply means shallow copy only copies values (variable and object references).

Basically, it doesn’t create copy of objects referenced inside the object we want to copy, thus it is called shallow copy.

Following is a shallow copy example using copy constructor method,

class Car {

    private String model;

    private Company company;

    public Car(String model, Company company) {
        this.model = model;
        this.company = company;
    }

    public Car(Car carToCopyFrom) {
        this(carToCopyFrom.model, carToCopyFrom.company);
    }

}

Deep copy

All the fields along with the objects referenced by existing object are copied to new object.

Consider following diagram, company object is also copied and reference to this new object is used in car object. Note that all the referenced objects at any level (direct or indirect) are copied and referred in copy object.

Following is a deep copy example using copy constructor method,

class Car {

    private String model;

    private Company company;

    public Car(String model, Company company) {
        this.model = model;
        this.company = company;
    }

    public Car(Car carToCopyFrom) {
        this(carToCopyFrom.model, new Company(carToCopyFrom.company.getName()));
    }
}

Java EE to Jakarta EE

Jakarta EE is nothing but aquisition and rebranding of Java EE done by Eclipse Foundation.  By the time I'm writing this post, Jakarta EE 10 is the latest released version.

Few years back Oracle decided not to manage Java EE anymore and give it's ownership to an open source foundation.  Finally, it was given to Eclipse Foundation, however, the Java trademarks including existing specification names can not be used by Jakarta EE specifications. Thus javax.* could not be used as package due to which it had to be renamed to something else, which decided to be jakarta.*. 

So it was shift of ownership from Oracle to Eclipse Foundation. This shift ended up with concerns of backward compatibility for existing libraries and frameworks which were heavily relying on Java EE. 

Basically, all the users of Java EE had to switch to this Jakarta EE in near future for long term support and updates with the cost of backward compatibility. Even Jakarta EE didn't explicitly addressed this issue but consumers of Java EE realized and started moving to Jakarta EE gradually seeing the first release of Jakarta EE 8.

This has impacted different frameworks, application servers and libraries al together including Spring, Glashfish, Tomcat, Jetty, JBoss, etc. 

Few months ago Spring Boot 3 got released with GA having new baseline of Java 17 and Jakarta 9 (and support for Jakarta EE 10 as well). As you see not just Jakarta EE but even Java 17 is being pushed to be considered for upgrade considering it to be LTS. In case you are using older pre-jakarta Spring version and looking forward to upgrade to Spring Boot 3, you have to deal with updating your classes and interfaces using javax.* to jakarta.* imports if you have any.

IntelliJ Idea has option of doing this refactoring of imports Refactor > Migrate Packages and Classes > Java EE to Jakarta EE.

Bottom line is, everything which was under javax.* can now be found and referred at jakarta.*. In upcoming days we may see major changes at Jakarta which will make migration even difficult if we don't switch to it in near future. 

References :

• Transition from Java EE to Jakarta EE
• Updates on Jakarta EE Rights to Java Trademarks
• Spring Boot 3.0 Goes GA

Java 17 PRNG API

Java 17 come up with new API for Pseudo-Random Number Generators. There are several resons behind introducing new PRNG API. Which provides uniform ways to use existing and new PRNG algorithms.

New interface is introduced due to following reasons,

• ThreadLocalRandom extends Random class and overrides pretty similar set of methods which can be avoided by using interface.
• To replace usage of SplittableRandom PRGN objects with Random we have to change every variable even though the classes having some similar behaviors.
• Code duplication in Random, SplittableRandom and ThreadLocalRandom
• Make it easy to introduce new PRGN implementation without much code changes.
• Provide support for PRGNs which are jumpable or leapable. (i.e. Xoroshiro128+)

What does new Random generator API provides?

Following diagram can explain hierarchy of random generators,

As we can see RandomGenerator is the parent interface extended by StreamableGenerator interface which enables streams of object to generate statistically independent objects.

Two child interfaces SplittableGenerator and JumpableGenerator extends StreamableGenerator interface which are introduced as part of Java 17.

Also, old Random class is now extending the RandomGenerator, which is done to bring older random generation into one umbrella and preserve it. As a result child class SecureRandom now automatically supports RandomGenerator. Thus we won’t need to reimplement SecureReandom class or it’s associated implementations. 

SplittableGenerator

Allows to create new SplittableGenerator from existing one which will generate statistically independent results. After split, high probability is that both objects will together generate values with same statistical properties like it is generated by single object. Provides two major split() and splits() methods to return split off and effectively unlimited stream of splits from existing generator.

Worth to note that the SplittableRandom (which is an implementation of SplittableGenerator) instances are not thread-safe.

Java 17 also has implementation of LXM family of PRNG algorithms which includes following classes,

• L32X64MixRandom
• L32X64StarStarRandom
• L64X128MixRandom
• L64X128StarStarRandom
• L64X256MixRandom
• L64X1024MixRandom
• L128X128MixRandom
• L128X256MixRandom
• L128X1024MixRandom

JumpableGenerator

Allows to generate random values and jump to a point in state cycle.

Provides jump() method, which jump forward to fixed distance (typically 2⁶⁴). Also, jumps() method returns effectively unlimited stream of object post jumping forward. This are major methods, but it also provides other methods as well like jumpDistance() which returns the distance by which the jump() method will jump forward, copyAndJump() which copies existing generator, jumps it forward and returns the copy etc. Unlike split() which returns the split off object, jump() is void which just jumps.

LeapableGenerator interface extends JumpableGenerator. Which allow to jump ahead a large number of draws.

Following implementations of JumpableGenerator are provided in Java 17,

• Xoshiro256PlusPlus
• Xoroshiro128PlusPlus

Sample program to get implemented random generators in Java 17, Output:

Provided RandomGenerators :
L32X64MixRandom
L128X128MixRandom
L64X128MixRandom
SecureRandom
L128X1024MixRandom
L64X128StarStarRandom
Xoshiro256PlusPlus
L64X256MixRandom
Random
Xoroshiro128PlusPlus
L128X256MixRandom
SplittableRandom
L64X1024MixRandom
---------
Create RandomGenerator :Xoshiro256PlusPlus
-1083384208

Reference :

• JEP 356: Enhanced Pseudo-Random Number Generators

JVM Overview

 

What is JVM?

JVM stands for Java Virtula Machine. To understand JVM let’s first understand what exactly VM (Virtual Machine) is.

Virtual Machine, as name suggests, it is a machine which is virtual (non-physical). Basically, VM is a software which behaves like an actual physical machine. You can run one or more VM on actual physical machine, just like we use any applications on our laptop.

Alright, so now we have basic idea of what VM is, let’s understand JVM.

JVM is an abstract computing machine which…

• extends runtime environment for execution of Java bytecode.
• enables operating system independence of Java.
• enables hardware inpenedence of Java.
• protects users from malicious programs. etc.

JVM has different responsibilities and features but in nutshell it executes provided Java byte code instructions.Actually, it does not even know anything about Java, it just knows about class file format which contains the instructions (or bytecode).

JVM Architecture

Class Loader Subsystems

To execute the byte code in JVM it first needs to be prepared for execution, this class loader subsystem takes care of that with the help of following steps,

• Loading : Loads binary representation of class or interface into method area.
• Linking : Includes verification, preparation and resolution
• Initializing : Executes initialization method <clinit>, of class or interface.

Let’s understand each of them in more details.

Loading

Loading reads .class file and generates implementation specific bytecode and stores it into method area.

Threre are three categories of class loaders in JVM,

• Bootstrap Class Loader
  • Loads rt.jar file (contains essential java runtime libraries (classes)).
  • Starting point of class loading process
  • Written in Native code
• Extension Class Loader : Loads Jar located inside $JAVA_HOME/jre/lib/ext directory. (extension to existing runtime libraries)
• Application Class Loader : Loads files from the classpath.

With following program we will be able to understand a bit more,

Output

Class Loaders used for CheckClassLoader class
sun.misc.Launcher.AppClassLoader
sun.misc.Launcher.ExtClassLoader
--
Class Loaders used for String
null 

As you can see for our CheckClassLoader, AppClassLoader is used. Also, the parent of AppClassLoader is ExtClassLoader which is nothing but Extension Class Loader.

Apparently, the String class is directly loaded with BootStrap Class Loader which is written in native code and thus we don’t get Java class of it and the program prints null.

The overall process can be summarized with following diagram.

 

Linking

Linking step involves following,

• Verification of binrary representation structure. If the verification of binanry represnetation doesn’t match with the expected static and structural constraints, VerifyError is thrown.
  • Constraints includes,
    • Static constraints ensures correct form of the binary representation.
    • Structural constraints ensures well defined relationship between the instructions.
• Preparation creates static fields and initializes them with default values. This step does not require execution of JVM code but explicit initializers are executed.
• Resolution of symbolic references of run-time constant pool.
  • JVM instruction like getstatic, invokespecial, invokevirtual, instanceof, new etc. rely on symbolic references in run-time constant pool.
  • Runtime constant pool is used for multiple purposes but in this context specifically, it contains a symbol table. Basically, it provides the actual entity associated with the given symbolic reference.

Consider following HelloWorld program, if we disassemble our HelloWorld with javap we can see multiple code items listed, which includes symbolic references (i.e. ldc, getstatic etc.). So, the resolution step actually resolves these symbolic references with the help of runtime constant pool.

Initialization

This step is all about executing initialization method of class or interface.

However, specific class or interface can only be initialized in one of the following cases :

• Due to execution of JVM instructions new, getstatic, putstatic or invokestatic which references the particular class.
• Due to initialization of its subclasses.
• If it is designated as the initial class or inteface at JVM start up.
• If its an interface and the initialization of a class that implements it directly and indirectly happens.
• Through invocation of reflective method.

Runtime Data Area

JVM holds multiple data (memory) areas which are utilised for different purposes. Two kinds of data areas exists,

• JVM Level : Created on JVM start up and gets cleared up on JVM exit.
• Thread Level : Created for individual Java Thread and gets destroyed when Thread exits.

Following are different data areas that exists in JVM,

pc Register

pc stands for Program Counter, used to store context of the thread or in other way gives address of JVM instruction being executed for particular thread. This context is usefull to support multi threaded environment by JVM.

pc Registers are simply data which provides information about Thread’s state to the JVM.

JVM Stacks

JVM Stacks is created for each thread and it stores frames.

Each Thread will have some methods to execute, for such execution we need to store following data somewhere,

• sequence of methods
• local variables of particular method
• partial results during method execution

JVM Stacks can be fixed size or dynamically expanding. Also, the memory allocation for JVM stack need not to be contagious.

We can use -Xss argument to allocate size to JVM stack.

java -Xss 32m HelloWorld

Two well known exceptions can occur due to JVM Stacks,

• StackOverflowError if computation required by Thread requires higher stacks than permitted by JVM stacks.
• OutOfMemoryError if JVM stacks is dynamically expanded but expansion is not possible due to insufficient memory.

Heap

Heap is created on JVM start up and shared across all JVM threads. This is the place where memory for objects and arrays are allocated.

Heap for objects is reclaimed by Garbage Collector (automatic memory management system of Java). Heap can be of fixed size or can expand or contracted based on requirement.

Memory allocated to heap need not to be contagious in nature.

We can configure the heap size with following JVM arguments,

• -Xms : size of heap required on start up.
• -Xmx : maximum allowed size of heap.

In case the memory is not available to allocate to the Heap, it throws OutOfMemoryError.

Method Area

Method area is shared among the JVM threads and created during the JVM start up.

It stores, run-time contant pool, field and method data, code for method data etc. per class basis.

Logically method area is part of the heap. Similar to heap, the memory allocated to method area need not to be contagious. Also, it can be fixed size or expandable (and contractable as well).

In case the memory is not available to allocate to Method Area it throws OutOfMemoryError.

The overall runtime data area can be visualised with following diagram,

 

Execution Engine

This is core of JVM which executes the Java byte code. It actually converts the bytecode to machine code and executes it.

It has three major components,

• Interpreter
  • Reads and converts byte code to machine code.
  • Interprets line of instruction to machine instruction in isolation.
  • One drawback is, it actually interprets everytime, even the same method comes multiple times which decreases the performance of the system.
• JIT (Just In Time) Compiler
  • The compilation from byte code to machine code is done at runtime in optimized way.
  • Increases performance by overcoming slow execution drawback of interpreter.
• Garbage Collector
  • Performs automatic memory management for Java.

Note : For the sake of simplicity, things like native methods, class format structure, workings of garbage collector etc. are kept out of the scope of this article.

Reference :

• https://docs.oracle.com/javase/specs/jvms/se17/html/index.html