jesperancinha / good-story

An investigation and comparison between Kotlin and Java on an engineering level. Since beauty is in the eye of the beholder, this repository is not meant to evaluate Java or Kotlin on an aesthetic level.

good-story

---

---

Technologies used

Please check the TechStack.md file for details.

1. Introduction

An investigation and comparison between Kotlin and Java on an engineering level. Since beauty is in the eye of the beholder, this repository is not meant to evaluate Java or Kotlin on an aesthetic level.

This project started as an idea to explore differences in performance between different projects. It has grown now into a full fledge comparison between Java and Kotlin and ONLY for engineering purposes.

I won't dive into style IT discussions in this project. And of course the elegant card is not the focal point here.

If you understand these terms, then I think you'll find this project interesting.

The way we are going to compare performance, response times and memory usage is going to be by processing a small novel I'm developing in the GoodStory file. We will apply algorithms to it, make objects, and explore the limits of our own machines.

Further, you may find that I'm using for, while and a do..while in both Java and Kotlin implementations. This is purposely done in some cases. I may find that in some cases there is no point in using the already implemented algorithm for some situations. Especially if they can be implemented in exactly the same way in Java or Kotlin without the use of a DSL.

Lombok usage will be avoided as much as possible and so please do not be surprised if you get to see any manual implementation of the builder pattern.

1.1. About performance

It caught my attention recently that in many blogs and videos, people are stressing out that coroutines and virtual threads are not about performance. That is of course directly true. What they are about is making a better use of a resource that has been there for ages. Sometimes called Continuation, sometimes called coroutines, but this is a concept that has been here for a long time. This repository is, regardless, about performance, because if we use our resources better, then that will ultimately result in better performance as a whole. So this repo is not about comparing the individual performance of one coroutine to one virtual thread. They work as a whole, both switch context, both can be suspended and both have different states. So I am measuring, or better yet, attempting to measure performance on a local machine and try to see if there is any significant difference there. These tests are also allowing to exhaust resources and therefore forcing each implementation to manage itself. It's here where the performance study comes in.

This repo is the official support repo to my article on medium:

Stable releases

• 1.0.0 - 315e7260b1214c8be1bc48a4af5446c8ad68bd9f - JDK19 runs with Jesperancinha GitHub Action for LoomJDK
• 1.0.1 - 64fcf38b3448f692353dffcc3a7150bdd1b2b645 - JDK19 is now installed as available
• 1.0.2 - 64fcf38b3448f692353dffcc3a7150bdd1b2b645 - Adds kotlin-loom with a Coroutine Dispatcher using a Loom Virtual Thread (original idea from apatrida. Check kotlin-loom-good-story for more details)

---

2. Environment

Java Project Loom is itself a JDK and in order to use it, you need first to install it

Be sure to run . ./sdk19.sh before running any of the commands, but only if you don't have JDK19 installed. This script installs JDK19 using SDK-MAN.

---

3. Tech comparisons

We cannot 100% compare Kotlin and Java in a direct way, but we will compare them using their best performant version.

JDK 19 is now available to install in different ways and it has been released. This means that this project is being updated as standard.

• Kotlin Coroutines
• Project Loom

Please keep checking the evolution of file Log.md if you want to keep up to date with the results of the comparisons. It gets updated per commit. You can also check the detailed file for Java and the detailed file for Kotlin.

---

4. How top run

You can run the whole test in one go by running:

make clean build-run

For heavier tests please run:

make clean build-run-loccal

---

5. Coffee Sessions ☕️

• How I created a JDK 19 Loom GitHub Action

---

6. Resources

Online

• Coroutines are not about multi-threading at all
• Structured concurrency by Roman Elizarov
• libdill: Structured Concurrency for C
• Java Virtual Threads by Gaetano Piazzolla
• Carrier Kernel Thread Pinning of Virtual Threads (Project Loom)
• GitHub's "Our response to the war in Ukraine" 🇺🇦
• Why Continuations are Coming to Java
• Coroutines overview
• JetBrains’ Statement on Ukraine 🇺🇦
• Scala (programming language)
• History of Scala
• Project Loom (Java 19)
• Java (programming language) ☕
• Project Loom: Fibers and Continuations for the Java Virtual Machine
• Coming to Java 19: Virtual threads and platform threads
• STAR method interview ✨
• Amazon Leadership Examples on Youtube
• System Design Messenger on Youtube
• Behavioral Interview Prep
• System - Design - Primer
• Grokking the System Design Interview
• Grokking the Coding Interview: Patterns for Coding Questions
• Big O Notation and Time/Space Complexity
• Analysis of Algorithms | Big-O analysis
• BTech smart class - Introduction to algorithms
• Splay tree
• Big-O Quiz
• Sieve of Eratosthenes
• Binary search tree
• The height of an AVL tree containing n nodes
• AVL Tree
• Data Structure and Algorithms - AVL Trees
• AVL Tree Insertion, Rotation, and Balance Factor Explained
• What is an AVL tree? 🌳
• AVL Tree program in Java
• How to insert Strings into an AVL Tree
• Big O Factorial Time Complexity
• BIG O NOTATION PRIMER
• What would cause an algorithm to have O(log log n) complexity?
• What does O(log n) mean exactly?
• Big O Notation, Part Two: Space Complexity
• ALGORITHMS IN KOTLIN, BIG-O-NOTATION, PART 1/7
• Big O Cheat Sheet
• Time complexity vs. space complexity
• Complexity and Big-O Notation
• Going inside Java’s Project Loom and virtual threads
• Kotlin Coroutines dispatchers
• VisualVM
• Picocli
• Issues with Spring, how Micronaut solves it, and latter’s support for GraalVM
• Kotlin Coroutines
• Java Project Loom
• GitHub Action for GraalVM
• Project Loom: Understand the new Java concurrency model
• Going inside Java’s Project Loom and virtual threads

Videos

• The Complete Guide to Big O Notation & Complexity Analysis for Algorithms: Part 1 of 2
• P99 CONF: High-Performance Networking Using eBPF, XDP, and io_uring

Books

• Mcdowell, G. (23rd April 2020). Cracking the Coding Interview 189 Programming Questions and Solutions. (6th Edition). CareerCup
• Cormen, T. Leiserson, C. Rivest, R. Stein, C. (2009). Introduction to Algorithms. (Third Edition). MIT Press

---

About me

good-story's Issues

In platform Threads there "is no context switch"?

Hello Joao,

I've read your article at https://itnext.io/kotlin-coroutines-vs-java-virtual-threads-a-good-story-but-just-that-91038c7d21eb .
I couldn't find out how to connect with you otherwise, so I'm trying it here.

In your article, you say,

In a concurrent environment with just the use of just of platform Threads, there is no context switch, and therefore making a blocking call always means waiting for the blocking call to finish before being allowed to continue. Coroutines or Continuations explore threads to the maximum by making sure that we avoid anything to block whenever that is possible.

Well, wrong. Or at least misleading. The thing is, in a multitasking operating system, we have

• processes,
• threads,
• and now in both kotlin and java: coroutines (aka virtual threads aka fibers).

All of these execution models are being managed by some scheduler, and on blocking operations, control (i. e. the CPU) is given away to others.

The difference is, processes and threads are managed by the OS, whereas the coroutines discussed are managed by the Java/Kotlin compiler and/or runtime.

From a programmer's standpoint, one can partly abstract away who manages his multitasking. So at first glance, "inventing" coroutines in Java/Kotlin seems like re-inventing the wheel. The sole point is, in my judgement: coroutines are more lightweight than threads, just as threads are more lightweight than processes.

P. S.: There already happened a step in previous Java versions to make multithreading more lightweight: The introduction of thread pools, and the idea that so-called executors distribute runnables across the thread pool. This lowered thread construction/termination costs (as opposed to constructing one thread for each runnable).

P. P. S.: It is interesting to see that browsers kind of went the other way: browser tabs are running in separate processes, for better isolation (security, and perhaps stability).

Kotlin Coroutines can dispatch on LOOM threads

Nice article!

Have you considered dispatching Kotlin coroutines onto Loom VirtualThreads?

Example idea:
https://kt.academy/article/dispatcher-loom

Here just create a simple dispatcher...

val Dispatchers.LOOM: CoroutineDispatcher
    get() = Executors.newVirtualThreadPerTaskExecutor().asCoroutineDispatcher()

And change your async { ... } call to use this dispatcher as

async(Dispatchers.LOOM) { ... }

Note your controlTest can have both a Thread { ... } version and a Thread.startVirtualThread { ... } version since nothing stops Kotlin from using LOOM virtual threads directly.

A lot of this code in the samples can be shared between them as Kotlin has no problem accessing Java classes, and most concepts in Kotlin are readable from Java as well. Unless you are worried about performance of basic code between the two, the total codebase could be reduced.

sample run-local with Java, Kotlin coroutines, Kotlin w/Loom async coroutines

Time	Method	Time Complexity	Space Complexity	Repetitions	Java Duration	Kotlin Duration	Kotlin-Loom Duration	Machine
2023-01-15T15:03:16.502528	wait0Nanos - Wait 0 Nanos - Running - Yielding - Virtual Thread	n/a	n/a	2	8	-1	-1	Prototype
2023-01-15T15:03:16.508950	wait100Mills - Wait 100 Mills - Running - Parking - Yield - Virtual Thread	n/a	n/a	2	101	-1	-1	Prototype
2023-01-15T15:03:16.509022	saveWordsNio - Write to 1 file - Yield - Virtual Thread	n/a	n/a	2	112	-1	-1	Prototype
2023-01-15T15:03:16.509055	saveWordsNio - Write to 1 file - Pinning - Yield - Virtual Thread	n/a	n/a	2	222	-1	-1	Prototype
2023-01-15T15:03:16.509082	findAllUniqueWords - All Unique Words	n/a	n/a	10000	1464	2839	2292	Prototype
2023-01-15T15:03:16.509110	findAllUniqueWordsWithCount - All Words with count	n/a	n/a	10000	1031	2081	1261	Prototype
2023-01-15T15:03:16.509137	revertText - Reverted Text	O(n)	O(1)	10000	324	866	594	Prototype
2023-01-15T15:03:16.509170	contentSplitIterateSubtractAndSum - Double iteration of an array of words	O(n^2)	O(1)	10000	373	1496	1120	Prototype
2023-01-15T15:03:16.509198	repetitionCount - Repetition count	O(n^2)	O(n)	10000	2238	2734	721	Prototype
2023-01-15T15:03:16.509223	createAvlTree - Create AVL Tree	O(log n)	O(n)	10000	1197	749	178	Prototype
2023-01-15T15:03:16.509249	findPrimeSecret - Secret word in Sieve of Eratosthenes	O(n * log(log n))	O(n)	10000	556	1632	519	Prototype
2023-01-15T15:03:16.509277	createSplayTree - Create Splay Tree	O(log n)	O(n)	10000	153	604	215	Prototype
2023-01-15T15:03:16.509303	quickSort - Quick sort	O(n * log n)	O(log n)	10000	1057	3616	2815	Prototype
2023-01-15T15:03:16.509334	makeTextFromWordFlow - Make text from word Flow	n/a	n/a	10000	889	519	147	Prototype
2023-01-15T15:03:16.509367	createIntersectionWordList - Intersection Text Algorithm	O(n)	O(n)	10000	83	956	482	Prototype
2023-01-15T15:03:16.509397	controlTest - N/A	n/a	n/a	10000	742	596	722	Prototype
2023-01-15T15:03:16.509424	generalTest - N/A	n/a	n/a	10000	182	59	173	Prototype
2023-01-15T15:03:16.509450	findAllUniqueWords - wait0Nanos	n/a	n/a	2	-1	12	21	Prototype
2023-01-15T15:03:16.509475	controlTest-Loom - N/A	n/a	n/a	10000	-1	-1	10	Prototype

That last controlTest-Loom is just Kotlin controlTest changed to use VirtualThread

@DelicateCoroutinesApi
        suspend fun controlTestWithVirtualThreads(repeats: Int) {
            log.info("----====>>>> Starting LOOM controlTest <<<<====----")
            val startTimeT = LocalDateTime.now()
            val aiThread = AtomicInteger(0)
            withContext(Dispatchers.IO) {
                (1..repeats).map {
                    Thread.startVirtualThread { aiThread.getAndIncrement() }
                }.forEach { it.join() }
            }
            val endTimeT = LocalDateTime.now()
            log.info("Imma be the main Thread")
            log.info(aiThread.get().toString())
            log.info("It took me {} ms to finish", Duration.between(startTimeT, endTimeT).toMillis())     }