A collection of experiments around Java, the JVM, performance, concurrency, memory, and data structures.
The goal of this repository is not to collect Java syntax exercises or framework tutorials. It is a place to investigate how Java applications behave below the application layer and to build a stronger mental model of the JVM and the machine underneath it.
Experiments here may involve benchmarking, profiling, deliberately inefficient implementations, alternative data representations, JVM flags, GC behavior, concurrency primitives, and custom implementations of common data structures.
I use this repository to explore questions such as:
- How expensive are allocations under different workloads?
- When can the JVM eliminate allocations through escape analysis?
- How do different GC strategies behave under allocation pressure?
- What effect does object layout have on memory usage and cache locality?
- When does object reuse help, and when does it hurt?
- How does false sharing affect concurrent workloads?
- What are the performance characteristics of different synchronization strategies?
- How do custom data structures compare with implementations from the JDK?
- How does load factor affect different hash table designs?
- How much of a performance difference comes from algorithms versus memory layout?
java-systems-lab/
├── jvm/
│ ├── allocation/
│ ├── escape-analysis/
│ ├── gc/
│ ├── object-layout/
│ └── jit/
│
├── concurrency/
│ ├── false-sharing/
│ ├── atomics/
│ ├── locks/
│ ├── contention/
│ └── virtual-threads/
│
├── data-structures/
│ ├── hash-table/
│ ├── ring-buffer/
│ └── bloom-filter/
│
├── io/
│ ├── nio/
│ ├── mmap/
│ └── zero-copy/
│
└── benchmarks/
Whenever possible, an experiment should answer a specific question.
Instead of:
Implement a hash map.
I prefer:
How do separate chaining, linear probing, and Robin Hood hashing behave as the load factor increases?
An experiment may contain:
a hypothesis; one or more implementations; a benchmark or reproducible workload; profiling or runtime observations; results; conclusions and limitations.
Not every experiment will require all of these, but the objective is to understand why something behaves the way it does rather than merely producing working code.
Performance experiments may use tools such as:
JMH Java Flight Recorder Java Mission Control async-profiler JVM diagnostic flags OS-level profiling tools
Benchmarks should be treated skeptically.
Results are only meaningful within the environment in which they were obtained, and JVM warmup, JIT compilation, CPU architecture, GC selection, memory pressure, and benchmark design can significantly change the outcome.
For this reason, benchmark results should include enough information to reproduce the experiment whenever possible.
Some experiments I plan to explore:
custom hash table implementations; object allocation versus object reuse; escape analysis and scalar replacement; Array of Structures vs Structure of Arrays; false sharing; lock contention; synchronized vs explicit locks vs atomics; platform threads vs virtual threads; ring buffers; direct vs heap buffers; memory-mapped files; GC behavior under different allocation patterns; cache-aware data structures; branch-heavy versus branch-light implementations.
This repository is not intended to be:
a Java beginner tutorial; a collection of LeetCode solutions; a production-ready library; a list of microbenchmarks without explanation.
Some implementations may deliberately sacrifice readability, safety, or generality in order to isolate a particular behavior.
Conclusions in this repository represent what I observed while learning and experimenting.
They should not automatically be interpreted as production recommendations.
A faster implementation under one benchmark may perform worse under a different workload, JVM version, GC, CPU, or memory hierarchy.
That uncertainty is part of what this repository is meant to explore.