Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had an amazing week!
You don't remember that meeting. Nobody does.
I bet right now you couldn't tell me what your last meeting or lecture was about even if your life depended on it.
Don't worry, I can't either. I have the memory of a goldfish.
That's why I started using Granola.
It picks up your meetings automatically and transcribes everything in the background while you take notes like normal. No bot joining your call, no “recording in progress” sound, nobody knows it's there.
After the meeting, it takes your messy notes and the full transcript and turns it into a clear summary of the meeting and what you actually need to do next.
You can even share that summary with your team because I bet they forgot too.
Now nobody has to pretend they remember.
Try Granola in your next meeting. Free for a month with code CODINGSLOTH
JIT (Just-In-Time) Compilation
For the longest time, I had no clue what JIT actually was. I just knew that it was used to make things faster and was an optimization, but no idea how.
I also didn’t really understand the difference between it and normal compilation.
Turns out, JIT compilation is a major runtime technique used across several language ecosystems—but it’s one point on a spectrum, not a magic “make code fast” switch.
You're Already Using JIT (You Just Don't Know It)
Browsers: Modern JavaScript engines such as Chrome’s V8, Firefox’s SpiderMonkey, and Safari’s JavaScriptCore combine parsing/interpreting with one or more optimizing compilation tiers. Hot code can be compiled and recompiled based on runtime behavior.
Java applications: JVM implementations such as HotSpot can profile running bytecode and JIT-compile frequently executed methods. Long-running workloads may improve after warm-up as profiling data accumulates and hotter code gets optimized.
C# and .NET: C# is normally compiled ahead of time into Common Intermediate Language (CIL/IL). At runtime, .NET can JIT-compile that IL into native machine code; modern .NET can also use tiered compilation and ahead-of-time options.
Android: ART uses a hybrid strategy that can combine interpretation, JIT compilation, runtime profiling, and ahead-of-time compilation. Real runtimes often mix techniques instead of picking one forever.
JIT compilation is everywhere.
Okay, But What Actually Is JIT?
JIT (Just-In-Time) compilation means generating native machine code during program execution. The input might be bytecode, an intermediate representation, or another compiled form—not necessarily the original source code.
Think of it like packing for a trip:
Option A (Ahead-of-Time / AOT compilation): Generate machine code before the program starts running. The compiler has time to optimize without adding compilation work to the program’s runtime path.
Option B (JIT compilation): Start running with an interpreter, baseline compiler, or lower optimization tier, observe real behavior, and compile selected code during execution. Hot functions may later be recompiled more aggressively.
The tradeoff is flexibility versus runtime cost. A JIT can optimize using information it only learns while the application runs, but profiling and compilation consume time, CPU, and memory.
JIT vs. Regular Compilation: What's The Difference?
Traditional Compilers (like GCC for C++)
Generate native code before the application runs
Can spend more compile time on expensive optimizations
Often produce native binaries or native-code artifacts
Avoid JIT compilation work during execution, although the program can still have plenty of other runtime overhead
Usually have less knowledge about the exact runtime values and hot paths a specific execution will see
JIT Compilers
Generate some native code while the program is running
Often use multiple tiers: start quickly, then optimize hotter code later
Can profile real types, branches, call targets, and hot paths
May make speculative optimizations and deoptimize if those assumptions stop being true
Spend CPU/memory on profiling, compilation, metadata, and generated machine code
Why Not Always Use JIT Compilers?
So why do we still use traditional compilation? Why isn't everything JIT-compiled?
Good question.
1. Startup and latency predictability — JIT compilation, profiling, garbage collection, and tier changes can make latency vary during startup or warm-up.
For some applications, that's a dealbreaker.
That can matter for latency-sensitive or tightly resource-constrained workloads. It does not mean “JIT can never be used in serious systems”; the right choice depends on runtime guarantees, workload shape, platform constraints, and how much latency variance is acceptable.
Short-lived command-line tools where startup dominates total runtime
Latency-sensitive services where tail-latency consistency matters
Embedded/resource-constrained environments with little spare CPU or memory
Platforms that restrict runtime code generation
Those environments may prefer AOT compilation, precompilation, profile-guided AOT, or carefully controlled runtimes—but there is no universal “serious software = no JIT” rule.
2. More Resource - JIT compilers need:
RAM for the compiler itself, plus both original code and compiled machine code
CPU cycles to profile and compile while your app is running
Battery on mobile devices
Embedded systems, IoT devices, and resource-constrained environments can't always afford this overhead.
This is one reason native AOT languages such as C, C++, and Rust are common in embedded and systems programming: they can produce compact native programs without requiring a general-purpose JIT runtime. But language/runtime choice is still workload-specific.
3. Security and Control JIT compilers generate code at runtime, which some security models really don't like.
Some operating systems and application sandboxes restrict writable-and-executable memory or runtime code generation because JIT engines expand the security surface. Platforms can grant special entitlements or use tightly controlled JIT implementations, so the exact rules depend on the OS and app environment.
Security-sensitive software can still use managed/JIT runtimes, but runtime-generated executable code requires additional hardening. AOT can simplify some deployment and attack-surface concerns; it does not automatically make software secure.
4. Cold-start and short-lived workloads — If a process starts, does a tiny amount of work, and exits, there may be not enough time for profiling and higher-tier JIT optimizations to repay their cost.
5. Deployment/runtime tradeoffs — A native AOT build can sometimes ship as a self-contained executable, while JIT-based applications typically need an appropriate runtime or bundle one with the application. But dependencies, native libraries, OS/CPU compatibility, configuration, and packaging still exist either way.
So the practical choice is rarely “JIT or AOT?” in isolation. Modern runtimes increasingly combine interpretation, baseline compilation, optimizing JIT tiers, profile-guided optimization, cached code, and AOT/native compilation depending on what helps startup, throughput, memory use, and deployment.
The runtime environment (JVM, Node.js, .NET CLR)
All the dependencies
Consistent behavior across different runtime versions
So when should you use JIT?
JIT works especially well when a runtime can benefit from observing real execution behavior and the program runs long enough for optimized code to repay compilation cost.
AOT is attractive when startup time, predictable deployment, memory footprint, or restrictions on runtime code generation matter more.
Hybrid approaches are extremely common, so you often choose a runtime/platform rather than manually choosing one compilation strategy.
Here’s some resource if you want to dive deeper (nerd)
V8 and JavaScript JIT:
Understanding JIT Compilation in V8 (Medium) - Deep dive into V8's pipeline
Inside the V8 JavaScript Engine - Comprehensive V8 architecture
V8 JIT Optimization Techniques - Performance improvements with real benchmarks
Java and HotSpot:
Introduction to HotSpot JVM C2 JIT Compiler - Technical deep dive
How the JIT Compiler Boosts Java Performance - Red Hat's guide
What the JIT!? Anatomy of OpenJDK HotSpot VM - Comprehensive overview
JIT vs AOT (traditional) Compilation:
JIT vs AOT Compilation in Java - Clear comparison with GraalVM
AOT vs JIT: How to Pick the Right Approach - Expert discussion on trade-offs
Ahead-of-time Compilation (Wikipedia) - Technical overview
The Battle: AOT vs JIT Compilation - Use cases and scenarios
If you want to keep learning
WebAssembly explained — see another compilation target designed to run fast code alongside JavaScript on the web.
How to choose a programming language — compilation model is one of many tradeoffs behind different language ecosystems.
Code profiling explained — JIT optimizations sound cool, but profile real applications before guessing where performance is going.
Thanks to everyone who submitted!
Find the Missing Number
Create a function that takes an array of numbers between 1 and 10 (excluding one number) and returns the missing number.
Examples
missingNum([1, 2, 3, 4, 6, 7, 8, 9, 10])
output = 5
missingNum([7, 2, 3, 6, 5, 9, 1, 4, 8])
output 10
missingNum([10, 5, 1, 2, 4, 6, 8, 3, 9])
output = 7Notes
The array of numbers will be unsorted (not in order).
Only one number will be missing.
How To Submit Answers
Reply with
A link to your solution (github, twitter, personal blog, portfolio, replit, etc)
or if you’re on the web version leave a comment!
If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
