Java কীভাবে চলে — JVM, bytecode, JIT আর GC

১ · Java-র অনুবাদ হয় দুইবার

পর্ব ০৪-এ আপনি দুটি কমান্ড চালিয়েছেন — javac Main.java, তারপর java Main. প্রশ্ন হলো, একটি প্রোগ্রাম চালাতে দুটি কমান্ড কেন? C-তে তো gcc একবার চালালেই চালানো যায় এমন ফাইল পাওয়া যায়। আর Python-এ একটিমাত্র কমান্ড। Java মাঝখানে কেন দাঁড়িয়ে?

উত্তরটি এই পর্বের কেন্দ্রীয় ধারণা। Java আপনার কোডকে সরাসরি আপনার CPU-র ভাষায় অনুবাদ করে না। প্রথম অনুবাদক javac কোডটিকে অনুবাদ করে এমন এক কম্পিউটারের ভাষায়, যার আসলে কোনো শারীরিক অস্তিত্ব নেই। সেই কাল্পনিক কম্পিউটারের নাম Java Virtual Machine, সংক্ষেপে JVM. আর তার ভাষার নাম bytecode.

তারপর আপনার কম্পিউটারে একটি আসল প্রোগ্রাম — java — সেই কাল্পনিক কম্পিউটারের ভূমিকায় অভিনয় করে। সে bytecode পড়ে, বোঝে, আর আপনার আসল CPU-কে দিয়ে কাজটি করিয়ে নেয়। অর্থাৎ অনুবাদ হয় দুইবার: একবার আগে (source → bytecode), আরেকবার চলার সময় (bytecode → আসল machine code).

২ · Source থেকে আউটপুট — পুরো পাইপলাইন

এবার পুরো যাত্রাটি ধাপে ধাপে দেখি। নিচের ছোট প্রোগ্রামটি দুটি সংখ্যা যোগ করে ফল ছাপে। “পরে” চাপুন, আর প্রতিটি ধাপে ভেতরের জিনিস কীভাবে বদলায়, খেয়াল করুন:

public class Main {
    public static void main(String[] args) {
        int total = add(2, 3);
        System.out.println(total);
    }
    static int add(int a, int b) {
        return a + b;
    }
}

CA FE BA BE 00 00 00 41 ...
↑ CAFEBABE = “এটি একটি class ফাইল” চিহ্ন
↑ 0x41 = 65 = Java 21-এর class ফাইল version
... তারপর constant pool, method আর তাদের bytecode

Main          ← application class loader আনল
java.lang.String, System, PrintStream ...
              ← bootstrap loader (JDK-র নিজের class)
verify Main:  stack ঠিক আছে? type মিলছে? ✔

iconst_2                 // 2 রাখো
iconst_3                 // 3 রাখো
invokestatic  add        // add(2, 3) ডাকো
istore_1                 // ফল total-এ রাখো
getstatic     System.out
iload_1
invokevirtual println    // ছাপো
return

add() ডাকা হয়েছে মাত্র ১ বার  → JIT দরকার নেই
(একই add() ১০,০০০ বার ডাকলে:)
add() → x86/ARM machine code
     lea eax, [rsi+rdx]   ; উদাহরণ মাত্র
     ret

$ javac Main.java
$ java Main
5

৩ · Bytecode নিজের চোখে দেখুন — javap

Bytecode কোনো রহস্য নয়। JDK-র সাথেই একটি টুল আসে, javap, যা .class ফাইল খুলে মানুষ পড়তে পারে এমনভাবে দেখায়। ধরুন Calc.java ফাইলে এই ছোট class লিখলেন:

class Calc {
    static int add(int a, int b) {
        return a + b;
    }
}

এবার terminal-এ compile করে javap -c চালান (-c মানে “method-এর bytecode-ও দেখাও”):

javac Calc.java
javap -c Calc

JDK 21-এ সাধারণত এমন আউটপুট আসে:

Compiled from "Calc.java"
class Calc {
  Calc();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  static int add(int, int);
    Code:
       0: iload_0
       1: iload_1
       2: iadd
       3: ireturn
}

কয়েকটি জিনিস খেয়াল করুন। প্রথমত, আপনি কোনো constructor লেখেননি, তবু Calc() আছে — javac নিজে একটি default constructor যোগ করেছে, যা Object-এর constructor ডাকে (পর্ব ১৬-এ বিস্তারিত)। দ্বিতীয়ত, বাঁ পাশের সংখ্যাগুলো (0, 1, 2, 3) byte-এর অবস্থান। প্রতিটি নির্দেশের নাম এক byte-এর একটি সংকেত, তাই নাম bytecode. তৃতীয়ত, নির্দেশের নামেই type লেখা: iload, iadd, ireturn-এর i মানে int. long হলে দেখতেন lload, ladd; double হলে dadd.

JVM হিসাব করে একটি stack দিয়ে

আসল CPU-তে register থাকে — ছোট ছোট দ্রুত ঘর। JVM-এর কাল্পনিক কম্পিউটারে register নেই; আছে প্রতিটি method কলের জন্য একটি operand stack — যেন টেবিলে একটার ওপর একটা প্লেট রাখা। নতুন মান যায় ওপরে, কাজের সময় ওপর থেকে তোলা হয়। add(2, 3) ডাকলে কী হয়, দেখুন:

0iload_01iload_12iadd3ireturn

৪ · এক bytecode, সব জায়গায় — portability

এখন বোঝা সহজ, কেন একই Main.class Windows ল্যাপটপে, Linux সার্ভারে আর Mac-এ বদল ছাড়াই চলে। Bytecode কোনো নির্দিষ্ট CPU বা OS-এর জন্য নয় — তা JVM-এর জন্য। আর প্রতিটি প্ল্যাটফর্মের জন্য আলাদা JVM আগে থেকেই বানানো আছে। প্ল্যাটফর্মের সব ঝামেলা JVM-এর নির্মাতারা একবার সামলান; আপনাকে আর সামলাতে হয় না।

একটি সতর্কতা: “সব জায়গায় চলে” মানে bytecode বহনযোগ্য, কিন্তু আপনার কোডের সব আচরণ নয়। যেমন ফাইলের path-এ Windows ব্যবহার করে \, Linux ব্যবহার করে /; কোডে হাতে C:\data লিখলে Linux-এ কাজ করবে না। Java এসব সামলানোর উপায় দেয় (পর্ব ৩৭-এ java.nio.file), কিন্তু ব্যবহার করার দায়িত্ব আপনার।

Android-এর ভিন্ন পথ — DEX আর ART

Android অ্যাপ Java বা Kotlin-এ লেখা হয়, কিন্তু ফোনে কোনো HotSpot JVM চলে না। অ্যাপ build করার সময় আগে সাধারণ .class ফাইল তৈরি হয়, তারপর d8 নামের একটি টুল সেগুলোকে DEX (Dalvik Executable) ফরম্যাটে বদলে দেয় — ফোনের সীমিত মেমরির কথা ভেবে বানানো আরেক ধরনের bytecode. শুরুর দিকে এটি চালাত Dalvik নামের VM; Android 5.0 থেকে তার জায়গা নিয়েছে ART (Android Runtime). ART অ্যাপ ইনস্টল ও ব্যবহারের সময় কোডের বড় অংশ আগেভাগে machine code-এ compile করে রাখে, আবার দরকারে JIT-ও ব্যবহার করে। ভাষা একই, ধারণাও একই — মাঝখানে একটি virtual machine — কিন্তু bytecode আর runtime আলাদা।

একই JVM, অনেক ভাষা

JVM আসলে Java ভাষাকে চেনে না — সে চেনে শুধু class ফাইল। তাই যে ভাষার compiler সঠিক class ফাইল বানাতে পারে, সেই ভাষাই JVM-এ চলে, আর Java-র সব library ব্যবহার করতে পারে। Kotlin (Android-এর জন্য Google-এর পছন্দের ভাষা), Scala (বড় ডেটা প্রক্রিয়াকরণে জনপ্রিয়), Clojure (Lisp-ঘরানার ভাষা) আর Groovy (Gradle build script-এ দেখবেন, পর্ব ৪৬) — সবই একই JVM-এ চলে। একটি Kotlin class একটি Java class-কে সরাসরি ডাকতে পারে, কারণ নিচে দুটিই bytecode.

আপনার কোড এখন কোন JVM-এ চলছে, তা প্রোগ্রাম নিজেই জিজ্ঞেস করতে পারে। নিচের কোডটি চালান — এটি যে JDK-তে চলবে, তার তথ্যই ছাপবে। এই পাতার রানার Java 21 ব্যবহার করে, তাই সেখানে 21 আসবে; আপনার কম্পিউটারে অন্য version থাকলে সংখ্যা বদলাবে:

class Main {
    public static void main(String[] args) {
        // যে JVM কোডটি চালাচ্ছে, তার নিজের দেওয়া তথ্য
        System.out.println("Java version  : " + System.getProperty("java.specification.version"));
        System.out.println("Runtime.version: " + Runtime.version().feature());
        System.out.println("Class file ver: " + System.getProperty("java.class.version"));
        System.out.println("JVM name      : " + System.getProperty("java.vm.name"));

        // কোন class কোন loader আনল?
        System.out.println("String-এর loader : " + String.class.getClassLoader());
        System.out.println("platform loader  : " + ClassLoader.getPlatformClassLoader().getName());
        System.out.println("app loader       : " + ClassLoader.getSystemClassLoader().getName());
    }
}

৫ · Class loader আর verifier — দরজার পাহারাদার

JVM চালু হলে সব class একসাথে মেমরিতে আনে না। আনে যখন প্রথম দরকার পড়ে তখন — একে বলে lazy loading. আপনার প্রোগ্রাম হয়তো এমন একটি class ব্যবহার করে যা শুধু কোনো বিরল error হলে লাগে; সেই error না ঘটলে class-টি কখনো লোডই হয় না। এতে JVM দ্রুত চালু হয়, মেমরিও বাঁচে।

Class আনার কাজ তিন স্তরের loader ভাগ করে নেয়। কেউ কোনো class চাইলে loader আগে তার ওপরের স্তরকে জিজ্ঞেস করে, “এই class কি আগে থেকেই আছে?” — ওপরে না পেলে তবেই নিজে খোঁজে। এতে কেউ নিজের বানানো নকল java.lang.String ঢুকিয়ে দিতে পারে না, কারণ আসলটি সবসময় আগে bootstrap loader থেকে আসে।

লোড হওয়ার পর আসে linking — যার প্রথম কাজ যাচাই। Verifier কিছু প্রশ্নের উত্তর না পেলে class চালাতেই দেয় না:

• প্রতিটি নির্দেশ সঠিক type-এর মান পাচ্ছে কি? (iadd-কে দুটি int দিতে হবে, একটি String নয়।)
• Operand stack কখনো খালি অবস্থায় তোলা হচ্ছে, বা সীমার বেশি ভরে যাচ্ছে কি?
• কোনো jump নির্দেশ method-এর বাইরে বা কোনো নির্দেশের মাঝখানে লাফ দিচ্ছে কি?
• private জিনিসে অন্য class হাত দিচ্ছে কি? কোনো সংখ্যাকে জোর করে reference বানানো হচ্ছে কি?

প্রশ্ন জাগতে পারে — javac তো আগেই সব যাচাই করেছে, আবার কেন? কারণ JVM জানে না class ফাইলটি কে বানিয়েছে। হয়তো javac, হয়তো Kotlin compiler, হয়তো কোনো library যা চলার সময় bytecode তৈরি করে, আবার হয়তো কেউ ইচ্ছা করে হাতে বানানো ক্ষতিকর ফাইল। JVM কাউকে অন্ধভাবে বিশ্বাস করে না। যাচাইয়ের পর class-এর static ঘরগুলো তৈরি হয় এবং initialization হয় — static ভ্যারিয়েবলে প্রাথমিক মান বসে (পর্ব ১৮-এ বিস্তারিত)।

৬ · Interpreter থেকে JIT — Java কেন চলতে চলতে দ্রুত হয়

Interpreter-এর সুবিধা হলো সঙ্গে সঙ্গে শুরু। অসুবিধা — প্রতিটি নির্দেশ প্রতিবার পড়তে, বুঝতে, তারপর করতে হয়। একটি লুপ দশ লাখবার ঘুরলে একই নির্দেশ দশ লাখবার “বোঝা” হয়। Java-র প্রথম দিকের version (১৯৯০-এর দশকের মাঝামাঝি) মূলত এভাবেই চলত, আর “Java ধীর” খ্যাতিটা তখনই তৈরি।

HotSpot নামটিই এসেছে এই চিন্তা থেকে: প্রোগ্রামের বেশিরভাগ সময় খরচ হয় অল্প কিছু “hot spot”-এ। JVM প্রতিটি method কতবার ডাকা হলো আর প্রতিটি লুপ কতবার ঘুরল, গুনে রাখে। সংখ্যা একটি সীমা পেরোলে সেই method-কে compile করতে পাঠায় — পেছনের আলাদা thread-এ, যাতে প্রোগ্রাম থেমে না থাকে।

HotSpot-এ দুটি JIT compiler আছে। C1 (আগে নাম ছিল “client compiler”) দ্রুত compile করে, অপ্টিমাইজেশন মাঝারি। C2 (“server compiler”) সময় বেশি নেয়, কিন্তু অনেক গভীর অপ্টিমাইজেশন করে। দুটিকে ধাপে ধাপে ব্যবহার করার নিয়মকে বলে tiered compilation, যা Java 8 থেকে ডিফল্ট। একটি method ১০,০০০ বার ডাকা হলে তার যাত্রাটা দেখুন:

শুরুর সময়ের সমস্যা — native image আর AOT

সার্ভারের জন্য warm-up তেমন সমস্যা নয় — সার্ভার চলে দিনের পর দিন। কিন্তু কিছু জায়গায় শুরুটাই সব: একটি command-line টুল যা আধা সেকেন্ড চলে, বা cloud-এর একটি function যা অনুরোধ এলে চালু হয়ে কয়েক মিলিসেকেন্ডে কাজ শেষ করে। সেখানে JVM চালু হওয়া, class লোড আর warm-up-এর সময়টাই বড় খরচ।

এর একটি সমাধান হলো AOT (ahead-of-time) compilation — চালানোর আগেই পুরো প্রোগ্রাম machine code-এ বানিয়ে রাখা। GraalVM-এর native-image টুল ঠিক এটি করে: আপনার অ্যাপ আর দরকারি JDK অংশ মিলিয়ে একটি স্বতন্ত্র চালানো যায় এমন ফাইল বানায়, যা মিলিসেকেন্ডে চালু হয় আর কম মেমরি নেয়। বিনিময়ে দিতে হয় কিছু: build অনেক ধীর, প্রতিটি OS-এর জন্য আলাদা build (C-র মতোই), আর চলার সময় নতুন class লোড বা reflection-এর মতো কাজের জন্য আগে থেকে জানিয়ে রাখতে হয়। দীর্ঘ সময় চলা অ্যাপে JIT-এর প্রোফাইল-নির্ভর অপ্টিমাইজেশনও হারায়। OpenJDK নিজেও Project Leyden নামে শুরুর সময় কমানোর কাজ করছে। এখনকার জন্য এটুকু জানলেই যথেষ্ট: JIT = ধীর শুরু, দ্রুত দীর্ঘ দৌড়; AOT = দ্রুত শুরু, কম নমনীয়তা।

৭ · Stack আর heap — reference-এর মানসিক ছবি

এখন আসি এই পর্বের সবচেয়ে কাজের ছবিতে, যা পুরো কোর্সে বারবার লাগবে। একটি Java প্রোগ্রাম চলার সময় মেমরির দুটি অংশ নিয়ে ভাবুন:

Stack-এ ভ্যারিয়েবল int x = 5; মানে সেই ঘরে সরাসরি 5. কিন্তু Car a = new Car(); লিখলে দুটি আলাদা জিনিস তৈরি হয়: heap-এ একটি Car object, আর stack-এ a নামের একটি ঘর, যাতে object-টি নেই — আছে শুধু object-টি কোথায় আছে তার খোঁজ। এই খোঁজকে বলে reference.

এবার এই ছবিটি কোডে দেখুন। চারটি লাইন, একটি object, আর তার দিকে কতগুলো reference আছে — খেয়াল রাখুন:

1Car a = new Car();2Car b = a;3a = null;4b = null;5// ... পরে কোনো এক সময় GC চলে

এবার কোডটি নিজে চালিয়ে দেখুন। এখানে দুটি reference একই object দেখায় কি না, তা == দিয়ে পরীক্ষা করা হচ্ছে, আর পাশাপাশি primitive-এর আচরণও:

class Main {
    public static void main(String[] args) {
        Car a = new Car();
        a.color = "লাল";
        Car b = a;              // নতুন Car নয় — একই object-এর দ্বিতীয় reference
        b.color = "নীল";
        System.out.println("a.color = " + a.color);
        System.out.println("a == b : " + (a == b));

        Car c = new Car();      // এবার সত্যিই নতুন object
        c.color = "নীল";
        System.out.println("a == c : " + (a == c));

        int x = 5;
        int y = x;              // primitive: মানটাই কপি হলো
        y = 10;
        System.out.println("x = " + x + ", y = " + y);
    }
}

class Car {
    String color;
}

৮ · Garbage collection — কে মুছে দেয়, কীভাবে, কী দামে

C-তে malloc দিয়ে নেওয়া মেমরি আপনাকেই free দিয়ে ফেরত দিতে হয়। ভুলে গেলে মেমরি ফুরোতে থাকে (memory leak); দুবার ফেরত দিলে বা ফেরত দেওয়ার পর আবার ব্যবহার করলে প্রোগ্রাম ক্র্যাশ করে, কিংবা আরও খারাপ — নিরাপত্তা-ছিদ্র তৈরি হয়। Java এই দায়িত্ব প্রোগ্রামারের কাছ থেকে নিয়ে JVM-কে দিয়েছে। এর নাম garbage collection (GC).

প্রশ্নটা “কোনটা garbage?” নয় — “কোনটা জীবিত?”

GC সরাসরি garbage খোঁজে না; সে খোঁজে কোনগুলো এখনো পৌঁছানো যায় (reachable). শুরু করে কিছু নিশ্চিত শুরুর বিন্দু থেকে, যাদের বলে GC root — চলমান প্রতিটি thread-এর stack-এর local ভ্যারিয়েবল, class-এর static ভ্যারিয়েবল ইত্যাদি। সেখান থেকে reference ধরে ধরে যতদূর যাওয়া যায়, সব object জীবিত। বাকি সব — যত বড়ই হোক, যতই দরকারি মনে হোক — garbage. এতে একটি সুন্দর সুবিধা আছে: দুটি object যদি শুধু একে অপরকে দেখায়, কিন্তু root থেকে তাদের কাছে পৌঁছানো না যায়, তবু দুটিই garbage. (Python-এর reference counting এই ধরনের চক্র একা ধরতে পারে না; তার জন্য আলাদা cycle collector লাগে।)

বেশিরভাগ আধুনিক collector একটি পর্যবেক্ষণের ওপর দাঁড়িয়ে: বেশিরভাগ object খুব অল্প বয়সেই মারা যায়। একটি লুপের ভেতরে বানানো অস্থায়ী String, একটি method-এর ভেতরের ছোট list — এগুলো কয়েক মিলিসেকেন্ডেই অনাথ হয়। তাই heap-কে ভাগ করা হয় নতুন (young) আর পুরোনো (old) অংশে; নতুন অংশ ঘন ঘন আর দ্রুত পরিষ্কার হয়, পুরোনো অংশ কদাচিৎ। একে বলে generational collection. বিস্তারিত পর্ব ৪৪-এ।

দাম — GC pause

বিনামূল্যে কিছু নেই। GC-কে কাজ করতে CPU লাগে, আর কাজের সুবিধার জন্য heap-এ বাড়তি ফাঁকা জায়গা রাখতে হয়। সবচেয়ে বড় খরচ — কোনো কোনো মুহূর্তে GC-কে আপনার প্রোগ্রামের সব thread থামিয়ে দিতে হয়, যাতে কাজের মাঝখানে object সরে না যায়। একে বলে stop-the-world pause. একটি ব্যাংকের সার্ভারে হঠাৎ এক সেকেন্ডের pause মানে সেই মুহূর্তের সব bKash বা কার্ড লেনদেনের উত্তর এক সেকেন্ড দেরিতে। এজন্যই গত দুই দশকে JVM-এর সবচেয়ে বেশি গবেষণা হয়েছে এই pause ছোট করা নিয়ে।

আপনাকে এখন কোনোটি বেছে নিতে হবে না — বেশিরভাগ অ্যাপে ডিফল্ট G1 ভালোই কাজ করে। নামগুলো চিনে রাখুন; কোনটি কীভাবে কাজ করে, কখন কোনটি বাছবেন, আর GC log কীভাবে পড়বেন — পর্ব ৪৪-এ।

৯ · AI-এর যুগে — JVM নিয়ে পুরোনো তথ্য যাচাই

JVM নিয়ে প্রশ্ন করলে AI সাধারণত গুছিয়ে, আত্মবিশ্বাসের সাথে উত্তর দেয়। সমস্যা হলো, ইন্টারনেটে Java 6–8 যুগের লেখা অগণিত — টিউটোরিয়াল, পুরোনো ব্লগ, Stack Overflow উত্তর। AI সেগুলো থেকেই শিখেছে। ফলে বহু বছর আগে বদলে যাওয়া তথ্য সে এখনো বর্তমান হিসেবে বলে। Java প্রতি ছয় মাসে একটি নতুন version পায়, আর JVM-এর ভেতরটা এই সময়ে অনেক বদলেছে।

AI-এর JVM-ব্যাখ্যা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• উত্তরে PermGen, CMS, finalize(), -XX:MaxPermSize — এসব শব্দ বর্তমান হিসেবে আছে কি না দেখেছি
• নিজের JDK-তে java -version দিয়ে version মিলিয়েছি, আর java -XX:+PrintCommandLineFlags -version দিয়ে দেখেছি কোন GC বেছে নেওয়া হয়েছে
• দাবি করা JEP নম্বর openjdk.org/jeps-এ খুলে দেখেছি — JEP আসলে আছে কি না, কোন version-এ এসেছে
• গতির দাবি হলে দেখেছি মাপার সময় warm-up হয়েছিল কি না (একবার চালিয়ে মাপা ফল বিশ্বাস করিনি)
• JVM flag কপি করার আগে জেনেছি সেটি কী করে, আর নতুন JDK-তে সেটি এখনো আছে কি না