UI24PC320CS · OOP THROUGH JAVA · UNIT I · PART C · CRIMSON
What happens between typing
java — and seeing your output.
Class 6 gave you the building: five rooms, one front door. Today you enter the last room's machinery — the execution engine that actually runs your bytecode — and walk the FULL journey of HelloStudent.java from your keyboard to your screen.
Carry one question through this hour: in Lab 0 you ran java HelloStudent and the output appeared instantly — but Class 5 told you bytecode is NOT machine code. Someone translated it. Who, when, and why is it still fast? Three names answer that today: interpreter, JIT, garbage collector.
PART 2 · TODAY'S MAP
One class, one journey:
keyboardchipscreen.
Class 6 drew the JVM's five rooms and stopped at the door of the last one. Today that door opens. By the end of this hour you can narrate — step by step, with real numbers — everything that happens when you press ENTER after java HelloStudent.
BY THE END YOU CAN
- Orderthe six steps from editing
HelloStudent.javato seeing output — without notes. - Connectthe interpreter, the JIT compiler and the garbage collector to the ONE second-long blink you saw in Lab 0.
- Matcheach stage of the compile-run pipeline to the file it reads and the file (if any) it produces.
- Recapwhy Java chose a two-step path — and defend it against "C compiles in one step, isn't that simpler?"
WHERE THIS SITS
TODAY'S ROUTE · 9 STOPS
- The execution engine's three workers — interpreter, JIT, GCCORE
- Interpreter-vs-JIT arithmetic on a 10-crore loopMATHS
- The compilation pipeline — .javajavac.classJVMSIM
- End-to-end run of
java HelloStudent, frame by frameSIM - Why the two-step path beats one-step compilationCORE
- Java in 2026 — where it still rulesCONTEXT
- Hyderabad — HITEC City employers who will interview youCONTEXT
- JVM alternatives — GraalVM, OpenJ9, Zing · AOT vs JITSTRETCH
- Two locked activities — sequencing + employer pickACTIVITY
CLASS 07 OF 60 · 12 PAGES · FEEDS CLASS 8
PART 3 · THE EXECUTION ENGINE
Three workers live
in the last room.
Class 6's floor plan ended at a box labelled execution engine. It is not one machine — it is a three-person crew, and they divide the work exactly the way a smart kitchen divides a dinner rush.
Reads your bytecode one instruction at a time and performs it immediately. Zero warm-up: your program starts producing output the moment it loads. The cost? It re-translates the SAME instruction every single time it meets it again.
Watches the interpreter work and keeps a tally. When one method or loop runs again and again — hot code — the Just-In-Time compiler translates that piece to native machine code ONCE. Every later visit runs at raw chip speed, no re-translation.
While the other two run your code, the GC patrols the heap from Class 6 and reclaims objects no reference can reach any more. You never call free() in Java — this worker is why.
Kitchen picture, hold it all hour: the interpreter is the cook who reads the recipe aloud line by line — dinner starts NOW. The JIT notices dosa has been ordered 40 times, memorises the dosa recipe cold, and now flips one per minute. The garbage collector is the cleaner quietly taking dead plates off tables so the kitchen never runs out of plates. Same kitchen, three jobs, all at once.
They run together. The interpreter handles everything from the first millisecond; the JIT only takes over the pieces that PROVE they are hot. Cold code stays interpreted forever — compiling it would cost more than it saves. Write this as one line: interpreter = start fast, JIT = run fast, GC = stay clean.
PART 4 · REAL NUMBERS
Why the JIT exists —
prove it with arithmetic.
"JIT makes hot code fast" is a sentence. Numbers make it a fact. Take one loop that adds a number 10 crore times (10,00,00,000 = 10⁸ iterations) — a size real banking batch jobs hit before lunch — and cost it both ways.
BUILD-UP · ONE ROW OF THE COSTING PER PRESS — CHECK EACH LINE IN YOUR NOTEBOOK
| STEP | INTERPRETER ONLY | WITH JIT |
|---|---|---|
| Cost per iteration | ≈ 50 ns (translate + do, EVERY time) | ≈ 1 ns (pre-compiled native) |
| Iterations | 10,00,00,000 (10⁸) | 10,00,00,000 (10⁸) |
| Loop time | 50 × 10⁸ ns = 5 × 10⁹ ns = 5.0 s | 1 × 10⁸ ns = 0.1 s |
| One-time JIT cost | — | compile the loop once ≈ 0.01 s |
| TOTAL | 5.0 s | 0.1 + 0.01 ≈ 0.11 s — ×45 faster |
Check the division yourself: 5.0 ÷ 0.11 ≈ 45. One ten-millisecond investment by the JIT bought back 4.9 seconds. That is the whole business case for hot-code compilation — in four lines of arithmetic.
And why not JIT-compile everything? Suppose a method runs once and takes 200 ns interpreted. Compiling it costs ≈ 10,00,000 ns (1 ms) — you'd pay 10 lakh ns to save 196 ns. Loss: ×5,000. That is why the JIT waits for a tally to prove code is hot. Cold code interpreted, hot code compiled — each worker where the maths says it wins.
PART 5 · THE COMPILATION PROCESS
Five stations, two commands,
exactly one new file.
Now zoom out from the engine room and see the whole assembly line. Everything you type passes through five stations — and only ONE of them creates a new file on your disk. Watch which.
BUILD-UP · ONE STATION LIGHTS UP PER PRESS
Two commands, five stations, ONE new file — and the new file is javac's. The JVM never writes your program to disk; it runs it in memory. ✓
javac HelloStudent.java takes the file name with extension. java HelloStudent takes the class name, NO extension. Type java HelloStudent.class and the JVM searches for a class literally named "HelloStudent.class" — and fails. You proved this in Lab 0; now you know why.
PART 6 · THE FULL JOURNEY
Replay Lab 0 —
in slow motion.
In Lab 0 the whole run took under a second. Here is that second, stretched out frame by frame. Every line below happened on YOUR machine — you just couldn't see it yet.
BUILD-UP · ONE FRAME PER PRESS — NARRATE EACH ALOUD · PROMPT = YOUR REAL LAB 0 FOLDER
Interpreter ran it, JIT judged it too cold to bother, GC had almost nothing to sweep — and every C6 room got used exactly once. ✓
Say it as one breath for the exam: "javac turns source into bytecode; the class loader brings the bytecode in; the verifier screens it; the execution engine — interpreter first, JIT for hot code, GC alongside — turns bytecode into behaviour." Four clauses, full marks.
PART 7 · THE DESIGN DEFENCE
"C compiles once and runs.
Isn't Java's two-step slower and sillier?"
A fair challenge — someone WILL ask it in your interview. A C compiler goes straight from source to machine code for one specific chip + OS. Java deliberately stops halfway, at bytecode. What does stopping halfway buy?
The C route needs a separate build per platform: 5 programs × 6 platforms = 30 builds. The bytecode route needs 5 compiles + 6 JVMs = 11 artefacts — Class 5's N×M vs N+M maths. Your lab .class from a Windows machine runs unchanged on the department's Linux server.
Because code arrives as bytecode, the JVM gets to inspect it before running it — the verifier from Part 6. Machine code handed straight to a chip gets no such interview. This checkpoint is why banks trust Java with money.
"Two-step = slow" died with the JIT. Hot code ends up as native machine code anyway — ×45 on our 10-crore loop — and the JIT can even use live run-time facts (which branch actually happens) that a one-shot C compiler can never see.
Java pays a real cost: start-up warm-up (the interpreter carries the first seconds while the JIT tallies) and the JVM's own memory footprint. For a script that runs 0.2 s, C wins. For a server that runs for months, the JIT has compiled everything hot by minute one — and portability + safety came free. Choose tools by workload, not loyalty.
PART 8 · WHY THIS STILL MATTERS IN 2026
Thirty years old —
and still holding the money.
You are not learning a museum language. The machinery you just traced — JVM, JIT, GC — is exactly why Java still owns the workloads where failure costs crores.
| WHERE JAVA RUNS IN 2026 | WHY THE JVM MACHINERY WINS THERE | NAMES YOU KNOW |
|---|---|---|
| Banking & payments | Verifier checkpoint + decades of hardening — code that touches money gets interviewed before it runs (Part 6). | UPI-scale bank backends, NPCI-connected systems, stock exchanges |
| Big-tech backends | JIT-compiled hot paths serve crores of requests; GC keeps month-long uptimes leak-free (Parts 3–4). | Google, Amazon, Netflix, LinkedIn services |
| Android's roots | The write-once discipline and class-file idea shaped Android's runtime; Kotlin itself runs on the JVM. | Every Play-Store era app stack |
| Big data | The N+M portability maths (Part 7) lets one cluster codebase run on any node hardware. | Hadoop, Spark, Kafka, Elasticsearch — all JVM-born |
| Enterprise India | The largest hiring pipeline for freshers who can explain — exactly — what you explained today. | TCS, Infosys, Wipro, Accenture delivery floors |
One number to carry: across index after index (TIOBE, Stack Overflow, GitHub Octoverse), Java has never left the top 4 languages on Earth in your entire lifetime. Languages come and go; the JVM's three workers keep paying rent.
PART 9 · TWENTY KILOMETRES FROM THIS ROOM
HITEC City runs
on this machinery.
This is not an abstract global story. Within one Metro ride of VCE, thousands of engineers ship JVM code every working day — and their interview panels ask exactly today's questions.
Microsoft's largest campus outside the US · Google Hyderabad · Amazon's biggest office building in the world (Financial District) · JPMorgan, Goldman Sachs, Wells Fargo tech centres — all with heavy JVM backends and all hiring freshers.
TCS, Infosys, Wipro, Tech Mahindra, Accenture run some of their largest Java delivery centres here — plus product firms like ServiceNow, Salesforce and Uber Hyderabad building JVM microservices.
"What does javac produce?" · "Difference between JDK, JRE, JVM?" · "What makes Java platform-independent?" · "What is the JIT?" — you now hold complete, numbers-backed answers to all four. Today was interview prep in disguise.
Anchor it to a person: a 2023 VCE graduate on a Financial District payments team spends her day inside exactly this pipeline — her code is javac-compiled in a build server, class-loaded on Linux boxes she has never seen, JIT-heated within minutes, GC-swept for months. Distance between her desk and yours: one syllabus.
PART 10 · STRETCH — ONE JVM SPEC, MANY ENGINES
"The JVM" is a rulebook.
Several teams build engines for it.
Everything today described the JVM specification — the rulebook. HotSpot (inside your JDK) is the reference engine, but any engine that obeys the rulebook runs your .class unchanged. Three rivals worth recognising by name:
| ENGINE | BUILT BY | ITS BIG IDEA |
|---|---|---|
| HotSpot | Oracle / OpenJDK | The default in your lab. Named after what it does: finds hot spots and JIT-compiles them — Part 4's exact strategy. |
| GraalVM | Oracle Labs | Adds native image: compile Java Ahead-Of-Time into a standalone binary — start-up in milliseconds. Loved by cloud microservices. |
| OpenJ9 | Eclipse / IBM | Tuned for a small memory footprint — the same app can run in roughly half the RAM. Popular in dense container fleets. |
| Zing | Azul | A pauseless GC (C4) for trading systems where even a 10 ms collection pause is money lost. |
Waits, watches, compiles only proven-hot code — and can use live run-time facts. Cost: warm-up seconds. King for long-running servers.
Everything translated to native code ahead of time (GraalVM native image). Instant start-up, smaller memory — but no run-time facts to optimise with. King for short-lived cloud functions.
Runs for months? JIT wins. Starts, answers, dies in seconds? AOT wins. Same trade-off logic as Part 7: workload decides, not fashion.
Why this is examinable gold: "The JVM is a specification with multiple implementations" is a one-line answer that instantly separates you from students who think the JVM is one program. Name GraalVM as an alternative and the panel sits up.
PART 11 · ACTIVITY 1 — NOTEBOOK FIRST
Six shuffled cards.
Put the second back in order.
TASK The six steps of a full Java run are shuffled below. In your notebook: (a) write the correct order as a chain of letters, and (b) mark the ONE step that produces a new file on disk with a star.
- CARD AThe console prints the output and the JVM shuts down.
- CARD BYou type
java HelloStudentand press ENTER. - CARD CYou edit and save
HelloStudent.javain your editor. - CARD DThe class loader reads the bytecode into the method area and the verifier screens it.
- CARD E
HelloStudent.classappears on disk. - CARD FYou type
javac HelloStudent.javaand press ENTER.
Chain written in your notebook first — the order is the marks.
- ORDERC · F · E★ · B · D · A. Edit the source (C) · run javac (F) · the .class appears (E) · run java (B) · class loader + verifier bring it in (D) · engine runs it and output prints (A).
- THE STARE is the only step that creates a new file — and E is javac's doing. The java command creates NOTHING on disk; the whole run lives in memory (Part 5's pipeline).
- TOP TRAPMost wrong answers swap B and D — remember the loader can only act after you launch the JVM. No
java, no loading. - SELF-CHECKCover the sheet and re-say the chain with the four-clause exam breath from Part 6. Same content, two formats — you own it both ways.
PART 12 · ACTIVITY 2 + BEFORE YOU GO
Pick your employer.
Then pack the toolkit.
TASK From Part 9, pick one Hyderabad employer you would genuinely want to join. In your notebook, write two sentences: (1) which of today's four round-1 questions you would answer FIRST to impress their panel, and (2) the exact one-line answer you would give, with one number in it.
Any employer is a right answer — the grading is on your one-liner.
- MODEL"Amazon, Financial District." Question picked: What is the JIT? One-liner: "The JIT watches the interpreter's tally and compiles proven-hot code to native — on a 10-crore-iteration loop that's ≈5 s interpreted vs ≈0.11 s with JIT, about ×45 faster."
- WHY IT SCORESIt names the mechanism (tally, then hot, then native), AND carries a number. Panels remember candidates who bring arithmetic, not adjectives.
- YOUR TURNWhatever employer you chose, rewrite your one-liner until it contains one mechanism + one number. That template answers half of every technical interview.
| TODAY'S TOOLKIT | THE ONE LINE THAT EARNS THE MARKS |
|---|---|
| Execution engine | Three workers: interpreter starts fast, JIT runs hot code fast, GC keeps the heap clean — all simultaneously. |
| JIT arithmetic | 10⁸ iterations: 5.0 s interpreted vs 0.11 s with a one-time 0.01 s compile — ×45. Cold code stays interpreted because compiling it would LOSE time. |
| Pipeline | .java · javac · .class (the only new file) · class loader · execution engine — in that order. Two commands, one artefact. |
| Two-step defence | Bytecode buys portability (N+M not N×M), a safety checkpoint, and JIT speed — at the honest cost of warm-up. |
| JVM = specification | HotSpot is the default engine; GraalVM (AOT native image), OpenJ9 (low memory), Zing (pauseless GC) are rival implementations. |
Your folder after this class — nothing to save: Class 7 is a concept class. No new coding files in this class — the terminal walk-through above re-ran the SAME Desktop\java-practice\lab-00\HelloStudent.java from Lab 0; no new folder, no new file. Your next new files arrive in Class 8, inside java-practice\class-08\.