UI24PC320CS · OOP THROUGH JAVA · UNIT I · PART C · CRIMSON
What the JVM actually is —
and why WORA is real.
Class 5 gave you Gosling's promise: write once, run anywhere. A promise needs machinery. Today you walk through that machinery — a building with five rooms — following the exact HelloStudent.class file you compiled in Lab 0.
Carry one question through this hour: when you typed java HelloStudent in Lab 0, the output appeared in well under a second. In that blink, a file was found, checked for forgery, shelved, given memory, and executed. Where did each of those five things happen? By the end of today you'll name every room.
CLASS 6 · THE ROAD FOR TODAY
One building. Five rooms. Your bytecode walks them all.
Still no new syntax — Part C is the "how does it actually work" arc. Today's map is the single most-asked diagram question of Unit 1: draw and label the JVM architecture. You'll build it room by room, with real numbers in every room.
BY THE END OF TODAY YOU CAN
- labelthe 5 runtime zones on a blank JVM box-diagram — Method Area · Heap · Stack · PC Register · Native Method Stack — from memory
- orderwhat happens in the first blink after
java HelloStudent— load, verify, allocate, start, run - explainJVM ⊂ JRE ⊂ JDK in one sentence each — and say which of the three your phone has, and which your lab PC has
- connectthe five rooms back to WORA — why the SAME .class file worked on two different lab machines
WHERE THIS SITS
TODAY'S ROAD · 12 PARTS
- The nesting — JVM inside JRE inside JDKDIAGRAM
- What "virtual machine" actually meansCONCEPT
- The floor plan — 5 zones, walked liveEXAM CORE
- The Class Loader — the front door with a bouncerZONE 0
- Runtime data areas — with real megabytesMATHS
- Bytecode portability — WORA, proven with arithmeticMATHS
- Activity 1 — label the blank floor planNOTEBOOK
- Activity 2 — order the 5 startup stepsNOTEBOOK
- The delegation model — why your fake String losesCLOSER
CLASS 06 OF 60 · 12 PAGES · FEEDS CLASS 7
PART 3 · THREE LETTERS, THREE BOXES
JDK, JRE, JVM — one lives inside the next.
Three abbreviations that every exam, every interview and every installer screen throws at you. They are not three rival things — they are three boxes, each nested inside the next, like a kitchen inside a restaurant inside a cooking school.
BUILD-UP · OUTERMOST BOX FIRST — ONE RING PER PRESS
Everything a developer needs: the compiler javac, debugger, JShell, docs tools — plus the whole JRE inside it. This is what YOU installed in Class 2. You write and build here.
Everything needed to run Java — the ready-made class libraries (String, System, thousands more) — plus the JVM inside it. A user who only runs Java apps needs only this.
The machine that actually executes bytecode — today's whole subject. Loads your .class, checks it, gives it memory, runs it. The innermost box does all the cooking.
One sentence for the exam: JDK = develop, JRE = run, JVM = execute — and each contains the next. ✓
No — a bare JVM without the JRE's libraries is a kitchen with no ingredients. Your program says System.out.println and System itself lives in the JRE's library shelf. JVM executes; JRE supplies; JDK builds. Write the triple in the margin of your notebook now.
PART 4 · THE WORD "VIRTUAL"
A machine made of software, not metal.
Your laptop's real CPU speaks ONE dialect — Intel's, or Apple's, or ARM's — and refuses all others. The JVM is a pretend CPU written as a program: a machine whose "hardware" is code, and whose one dialect is bytecode.
…is silicon. It executes its own instruction set and nothing else. An Intel chip cannot run ARM instructions any more than a Telugu-only speaker can read Japanese.
…is software that behaves like a CPU. It has its own instruction set (bytecode), its own memory areas, its own execution engine — all simulated in code.
Sun wrote one JVM per real machine — Windows JVM, Mac JVM, Linux JVM. Each speaks bytecode on one side and its host's dialect on the other. Your .class only ever talks to the JVM.
The Hyderabad Metro card analogy: your metro card works at every station because every station installed the same kind of card reader. Nobody rebuilt your card per station — they standardised the reader. Bytecode is the card; the JVM is the reader; stations are operating systems. Sun shipped readers everywhere so your card never changes.
PART 5 · THE EXAM'S FAVOURITE DIAGRAM
The JVM floor plan — five rooms, lit one by one.
This is the architecture. Your HelloStudent.class chip enters at the front door and the building lights up room by room. Watch WHERE the chip goes and WHAT each room stores — the labels are exactly what the exam asks you to draw.
BUILD-UP · FOLLOW THE BYTECODE CHIP — ONE ROOM PER PRESS
Finds HelloStudent.class on disk, verifies the bytecode isn't forged or corrupted, and carries it inside. Every class enters through this one door — no exceptions.
The library shelf: class structure, method bytecode, static fields — stored ONCE per class, shared by everyone. Your class's blueprint gets shelved here.
▣ blueprint shelvedThe warehouse: every object made with new lives here — including every String your program prints. Biggest room in the building, shared by all threads.
The worktable — one per thread. Each method call gets a tray (a frame) with its local variables; finish the method, the tray is removed. main's tray goes down first.
The bookmark — one per thread. Holds the address of the current bytecode instruction, so the JVM always knows exactly which line it's on. Tiny, and never forgets.
▣ instruction #3 of 9…The service corridor to the host OS — used when Java must call code written in C/C++ (drawing pixels, touching files). Your println ends its journey here: the actual "put characters on screen" is an OS job.
▣ characters handed to the OS — "Hello, VCE!" appearsThat whole walk — door, shelf, warehouse, worktable, bookmark, corridor — ran in under 400 milliseconds in Lab 0. You watched it and never saw it.
Shared by all threads: Method Area + Heap (one library, one warehouse). One per thread: Stack + PC Register + Native Method Stack (each worker gets their own table, bookmark and corridor pass). This split IS the 3-mark answer when the exam says "classify the runtime areas".
PART 6 · ZONE 0 · THE FRONT DOOR
The Class Loader — a door with a bouncer.
No class strolls into memory. Three checks happen at the door, in order, every time — and the second one is the reason Java earned its Secure buzzword from Class 5.
Find the .class file — on disk, inside a JAR, even across a network — and read its bytes in. Like the door scanner reading your ID card's chip.
The bytecode verifier checks every instruction: no forged jumps, no type lies, no stack overflows built into the file. A tampered .class is refused at the door — before it runs a single instruction.
Static fields get their real starting values and static blocks run — the class is now awake, shelved in the Method Area, ready to be used.
Why so paranoid? Remember Class 5: Java was built for a networked world — code arriving over the internet from strangers. The verifier means even a malicious .class downloaded from anywhere gets frisked at the door. C++ has no such door: whatever you link, runs. This one room is most of the "Secure" buzzword.
PART 7 · REAL MEGABYTES
Put actual numbers in the rooms.
"Method Area, Heap, Stack" stays abstract until you weigh them. Here are honest, typical numbers for a default JVM on your lab PC — and two computations you can do in your head.
| ROOM | TYPICAL SIZE (DEFAULT JVM, 8 GB LAB PC) | WHAT THAT BUYS |
|---|---|---|
| Heap | ~2 GB max (¼ of RAM by default) | the warehouse — millions of objects |
| Stack (per thread) | 1 MB (the -Xss default) | roughly 10,000–20,000 nested method frames |
| Method Area | grows as needed (~a few MB for small apps) | every loaded class's blueprint, once each |
| PC Register | a few bytes per thread | one bookmark — the smallest "room" in computing |
DO THE MATHS WITH ME — TWO QUICK COMPUTATIONS, ONE PER PRESS
Each thread needs its own 1 MB stack. Suppose the JVM can spend 2 GB on stacks: 2 GB ÷ 1 MB = 2,048 threads. That's why a server handling 10,000 users does NOT give each a thread with a fat stack — and why "Multithreaded" (buzzword #7) needed careful engineering, not just enthusiasm.
A food-delivery backend creates 10 lakh order objects a day, all from one Order class whose blueprint is ~50 KB. Shared shelf: 50 KB × 1 = 50 KB. If every object carried its own copy: 50 KB × 10,00,000 ≈ 50 GB — more than the server's entire RAM, spent on duplicate blueprints. Store the class ONCE, stamp objects thin: that's the Method-Area/Heap split earning its keep.
Blueprint once (Method Area) + thin objects many (Heap) — the Class-2 stamp idea, now with an address and a size.
Spot the callback: Class 2 said "the class is drawn once, objects are stamped many". Today you learned WHERE: the drawing lives in the Method Area, the stamps pile up in the Heap, and each running method holds its stamps' addresses in a Stack frame. Same idea, now physical.
PART 8 · WORA, PROVEN
One file, every machine — the arithmetic of portability.
Class 5's porting-maths said N + M beats N × M. Today you can finally see why the trick works: the .class file never changes because it only ever speaks to the JVM — and a JVM was pre-installed for every kind of machine.
BUILD-UP · THE SAME FILE, THREE MACHINES — ONE PRESS EACH
Those 427 bytes are pure bytecode — instructions for the JVM's pretend CPU, containing zero Windows-isms, zero Mac-isms. Check the byte count yourself next lab: dir HelloStudent.class.
Windows JVM reads the 427 bytes, translates to Intel dialect, prints Hello, VCE!
Mac JVM reads the same 427 bytes, translates to ARM dialect, prints Hello, VCE! Same file. Different silicon. Zero edits — you did this in Lab 0.
Linux JVM, same 427 bytes, third dialect. This is why a Hyderabad team ships ONE build to every client — 1 build, not 3; at 1,000 programs and 20 platforms, 1,020 pieces, not 20,000.
The .class never travels with an adapter — because every destination already installed the socket.
PART 9 · YOUR TURN · ACTIVITY 1
Label the blank floor plan.
Draw the JVM box-diagram in your notebook: one big rectangle, the front door on top, five inner rooms. Write the five zone names in — and beside each, one word saying what Lab 0's HelloStudent put there. Notebook first; the key is locked below.
DRAW One outer box titled JVM · front door labelled at top · five rooms inside.
LABEL The five runtime zones — the exact names from Part 5.
ANNOTATE Beside each zone, ONE word for what HelloStudent put there. (Hint for room 2: what does println's text live as?)
CLASSIFY Mark each room S (shared) or T (per-thread) — the warn-note split.
Rule of the room: five names + five words in your notebook before this opens.
- METHOD AREAblueprint — HelloStudent's class structure and method bytecode, shelved once · S shared
- HEAPString — the "Hello, VCE!" text object lives here · S shared
- STACKframe — main( )'s tray with its local variables · T per-thread
- PC REGISTERbookmark — the address of the instruction being executed right now · T per-thread
- NATIVE METHOD STACKcorridor — the OS-level call that actually paints characters on your screen · T per-thread
Front door = Class Loader (load · verify · initialise, in that order). If you also wrote S/S/T/T/T — full marks, twice over.
PART 10 · YOUR TURN · ACTIVITY 2
Five shuffled steps — put the blink in order.
The instant you type java HelloStudent, five things happen — here they are, deliberately shuffled. Number them 1–5 in your notebook. Then the key below confirms.
- CARD AMemory areas are allocated — heap space, main's stack frame, the PC register set to instruction #1
- CARD B
mainexecutes, instruction by instruction - CARD CThe class loader finds
HelloStudent.classon disk - CARD DThe main thread starts
- CARD EThe verifier checks the bytecode for forgery and corruption
Five numbers in the notebook margin first — it takes 40 seconds.
- 1 · CARD CLoad — the class loader finds the file. Nothing can happen to a class that isn't found.
- 2 · CARD EVerify — the bouncer frisks it BEFORE it gets memory or a thread. Security first, always.
- 3 · CARD AAllocate — only clean bytecode earns heap space, a stack frame and a bookmark.
- 4 · CARD DStart — the main thread begins with everything already in place.
- 5 · CARD BExecute — main runs. Output appears. Total elapsed: a few hundred milliseconds.
Memory hook: "Late Very Angry Students Exit" — Load · Verify · Allocate · Start · Execute.
PART 11 · ONE LAST DOOR RULE
Why your fake String can never win.
A sneaky thought experiment: what if you wrote your OWN class named String that secretly emails passwords somewhere? Would the JVM load yours instead of the real one?
Every class loader asks its parent first before loading anything itself. The request for "String" climbs to the top — the bootstrap loader — which finds the REAL String in the JRE's shelf and returns it.
…is never even considered. The parent answered first; the search stops. Your fake String sits on disk, permanently ignored. The core library cannot be silently replaced.
"Parent-first delegation prevents core classes from being spoofed by user code." That sentence, plus the verifier from Part 6, is the Secure buzzword made mechanical.
The mess-card analogy, one last time: if someone prints a fake mess card, the reader doesn't ask the student "is this real?" — it asks the central office first. Whatever the office says, wins. Parent-first, every time, no exceptions.
PART 12 · WALK OUT WITH THIS
The building, in one breath.
Front door checks it (Class Loader) · shelf stores the blueprint (Method Area) · warehouse holds the objects (Heap) · each worker gets a table (Stack), a bookmark (PC Register) and a corridor pass (Native Method Stack). Load · Verify · Allocate · Start · Execute — every run, every machine, same building.
Class 6, in one line: WORA works because the .class file only ever talks to this building — and Sun built an identical building on every operating system. Next class we go INSIDE the last piece of machinery: the engine that actually runs the instructions, and the maths of why it got fast.
Your folder after this class — nothing to save: Class 6 is a concept class. No new coding files in this class — Desktop\java-practice\ is untouched. The Hello-on-two-machines demo you revisited today used the SAME java-practice\lab-00\HelloStudent.class you built in Lab 0.