JavaScript কীভাবে চলে — engine, JIT আর call stack

১ · আপনার কোড আর CPU-র মাঝখানে কে আছে

পর্ব ০৪-এ আপনি console.log("Hello") লিখে চালিয়েছেন, আর সাথে সাথে লেখাটি এসেছে। মনে হয় যেন কম্পিউটার JavaScript পড়েই বুঝে ফেলল। আসলে তা নয়। কম্পিউটারের CPU বোঝে শুধু নিজের machine code — খুব ছোট ছোট নির্দেশ, যেমন “এই দুটি সংখ্যা যোগ করো”, “এই ঠিকানা থেকে মান আনো”।

তাহলে মাঝখানে কে? একটি প্রোগ্রাম, যার নাম JavaScript engine. Engine আপনার লেখা পড়ে, বোঝে, আর CPU চালাতে পারে এমন রূপে বদলে দেয়। প্রতিটি বড় ব্রাউজারের নিজের engine আছে:

Microsoft Edge আগে নিজের engine (Chakra) ব্যবহার করত। ২০২০ সালের শুরুতে নতুন Edge Chromium-এর ওপর তৈরি হয়, তাই এখন সেটিও V8 চালায়। এই কোর্সে আমরা উদাহরণ হিসেবে মূলত V8 দেখব, কারণ আপনার Chrome, Edge আর Node.js — তিন জায়গাতেই একই engine. তবে মূল ধারণাগুলো তিনটি engine-এই প্রায় একই।

২ · Engine-এর ভেতরের পাইপলাইন — লেখা থেকে machine code

Engine একবারে সরাসরি machine code বানায় না। কয়েকটি ধাপে কাজ করে, আর প্রতিটি ধাপ পরের ধাপের জন্য জিনিস তৈরি করে দেয়। নিচের ডায়াগ্রামে “পরে” চাপুন — একটি ছোট function কীভাবে লেখা থেকে দ্রুত machine code হয়, আবার দরকার হলে কীভাবে পিছিয়ে আসে, দেখুন।

function area(r) {
    return 3.14 * r * r;
}
for (let i = 1; i <= 100000; i++) area(i);
area("5");   // শেষে একবার string!

function  area  (  r  )  {
return  3.14  *  r  *  r  ;
}
keyword · নাম · চিহ্ন · সংখ্যা — space আর comment বাদ

FunctionDeclaration  area
├─ params: [ r ]
└─ body
   └─ ReturnStatement
      └─ BinaryExpression  *
         ├─ BinaryExpression  *
         │  ├─ Literal  3.14
         │  └─ Identifier  r
         └─ Identifier  r

LdaConstant [3.14]   ; 3.14 হাতে নাও
Mul  r               ; r দিয়ে গুণ
Mul  r               ; আবার r দিয়ে গুণ
Return
; চলার সময় নোট রাখে: "r এ পর্যন্ত সবসময় number"

check: r কি number?  না হলে → deopt
x = 3.14 × r         ; সরাসরি CPU-র গুণ
x = x × r
return x
; type খোঁজার কোনো ঝামেলা নেই — তাই বহু গুণ দ্রুত

check: r কি number?  → না, এটা string "5"
→ optimized কোড বাদ, Ignition-এর bytecode-এ ফেরা
→ bytecode নিয়ম মেনে চালায়: 3.14 * "5" * "5"
→ ফল 78.5   (ভুল ফল কখনো নয়, শুধু কিছুটা ধীর)

V8-এর কয়েক স্তরের compiler

উপরের ছবিতে “Optimizer” একটি বাক্স, কিন্তু সাম্প্রতিক V8 version-গুলোতে আসলে কয়েকটি স্তর আছে। প্রতিটি স্তর আগেরটির চেয়ে compile করতে বেশি সময় নেয়, কিন্তু বেশি দ্রুত কোড বানায়:

Ignition আর TurboFan একসাথে চালু হয় ২০১৭ সালে, Sparkplug আসে ২০২১ সালে, আর Maglev ২০২৩ সালে। Engine-এর এই অংশ প্রায় প্রতি বছর বদলায় — তাই নামগুলো মুখস্থ করার চেয়ে মূল চিন্তাটা মনে রাখুন: শুরুতে দ্রুত চালু, পরে দ্রুত চলা।

৩ · Hidden class আর inline cache — object-এর “আকার” কেন গুরুত্বপূর্ণ

JavaScript-এ object-এ যখন খুশি নতুন property যোগ করা যায়, মুছেও ফেলা যায়। এটি লেখার জন্য আরামদায়ক, কিন্তু engine-এর জন্য কঠিন। C বা Java-তে compiler আগেই জানে একটি object-এর ভেতরে কোন field কোথায় আছে। JavaScript-এ p.x পড়তে গেলে engine-কে প্রতিবার খুঁজতে হতো “x কোথায় আছে?” — অভিধানে শব্দ খোঁজার মতো, যা ধীর।

সমাধান হলো hidden class (V8-এর ভেতরে এর নাম “Map”, অন্য engine-এ “Shape” বা “Structure”). একই property একই ক্রমে আছে এমন সব object একই hidden class ভাগ করে নেয়। Hidden class লিখে রাখে: “x আছে ঘর ০-এ, y আছে ঘর ১-এ”। তখন p.x মানে সরাসরি ঘর ০ — খোঁজার দরকার নেই।

// একই আকার: একই property, একই ক্রমে
const a = { x: 1, y: 2 };
const b = { x: 5, y: 9 };          // a আর b একই hidden class

// আকার আলাদা হয়ে যায় এমন কাজ
const c = { y: 2, x: 1 };          // ক্রম উল্টো → নতুন hidden class
const d = { x: 1 };  d.y = 2;      // পরে যোগ → hidden class বদল (transition)
d.z = 3;                           // আরেকটি বদল
delete a.x;                        // delete → প্রায়ই ধীর "অভিধান" রূপে চলে যায়

এবার এর সাথে যোগ করুন inline cache. ধরুন একটি function বারবার p.x + p.y পড়ে। প্রথমবার engine খুঁজে বের করে x কোথায়, তারপর সেই জায়গায় লিখে রাখে: “গতবার hidden class ছিল H1, x ছিল ঘর ০-এ”। পরের বার একই hidden class এলে খোঁজা ছাড়াই সরাসরি ঘর ০। একটি লুপে কী ঘটে, দেখুন:

৪ · Call stack — কে কাকে ডাকল, তার হিসাবের স্তূপ

এবার কোড চলার সময় engine কীভাবে মনে রাখে “এখন কোন function চলছে, শেষ হলে কোথায় ফিরতে হবে”। এর জন্য আছে call stack — বিয়েবাড়িতে একটার ওপর একটা রাখা প্লেটের স্তূপের মতো। নতুন প্লেট রাখা হয় ওপরে, তোলাও হয় ওপর থেকে।

যখনই একটি function ডাকা হয়, engine তার জন্য একটি execution context তৈরি করে — সেই function-এর local variable, argument, this আর “শেষ হলে কোথায় ফিরব” এর ঠিকানা। এই তথ্যের প্যাকেটটি একটি stack frame হিসেবে স্তূপের ওপরে বসে। Function শেষ হলে frame সরে যায়। সবার নিচে থাকে global context — পুরো script-এর জন্য।

1function format(name) {2    return "Hello, " + name;3}4function greet(name) {5    const msg = format(name);6    console.log(msg);7}8greet("Rafi");

Error হলে আপনি যে stack trace দেখেন, সেটি আসলে এই স্তূপের একটি ছবি — error-এর মুহূর্তে কোন function কাকে ডেকেছিল, ওপর থেকে নিচে। পর্ব ২৯-এ error নিয়ে বিস্তারিত দেখবেন।

Stack ভরে গেলে — RangeError

প্লেটের স্তূপ অসীম উঁচু হতে পারে না। Call stack-এরও একটি সীমা আছে। একটি function যদি নিজেকে ডাকে (recursion) কিন্তু কখনো থামার শর্ত না থাকে, frame জমতেই থাকে — শেষে engine হাল ছেড়ে দেয়। চালিয়ে দেখুন:

let depth = 0;

function dive() {
  depth++;        // কতগুলো frame জমল গুনছি
  dive();         // থামার কোনো শর্ত নেই!
}

try {
  dive();
} catch (e) {
  console.log(e.name);
  console.log(e.message);
  console.log("হাজারের বেশি frame জমেছিল?", depth > 1000);
}

// থামার শর্ত থাকলে কোনো সমস্যা নেই
function countdown(n) {
  return n === 0 ? "শেষ!" : countdown(n - 1);
}
console.log(countdown(100));

৫ · Heap আর garbage collection — কে মেমরি পরিষ্কার করে

Call stack ছোট আর গোছানো — frame আসে, frame যায়। কিন্তু object, array, function-এর মতো বড় বা দীর্ঘজীবী জিনিস থাকে আরেক জায়গায়: heap. Heap একটি বড় গুদামঘরের মতো; stack-এর variable-এ থাকে শুধু গুদামের সেই তাকের ঠিকানা (reference).

C-তে malloc দিয়ে নেওয়া মেমরি আপনাকে নিজেই free করতে হয়। JavaScript-এ সেই দায়িত্ব engine-এর — garbage collector (GC). প্রশ্ন হলো, GC কীভাবে জানে কোন object আর দরকার নেই? উত্তর: reachability. কিছু সূচনাবিন্দু আছে, যাদের বলে root — global object, call stack-এ থাকা সব local variable. Root থেকে reference ধরে ধরে যে object-এ পৌঁছানো যায়, সেটি “জীবিত”। যেটিতে কোনোভাবেই পৌঁছানো যায় না, সেটি আবর্জনা।

Orinoco — V8 কীভাবে GC-কে চোখের আড়ালে রাখে

পুরোনো GC চলার সময় পুরো প্রোগ্রাম থামিয়ে দিত (“stop-the-world”). একটি অ্যানিমেশন বা গেমে ১০০ মিলিসেকেন্ডের থামা মানে চোখে পড়ার মতো ঝাঁকুনি। V8-এর GC প্রজেক্ট Orinoco কয়েকটি কৌশলে এই থামা অনেক কমিয়েছে:

• Generational: বেশিরভাগ object খুব অল্প সময় বাঁচে (একটি লুপের ভেতরের অস্থায়ী object). তাই heap দুই ভাগে — নতুন object-এর ছোট “young generation”, যা ঘনঘন ও দ্রুত পরিষ্কার হয়; আর কয়েকবার টিকে যাওয়া object চলে যায় বড় “old generation”-এ, যা কম পরিষ্কার হয়।
• Parallel: GC-র কাজ কয়েকটি helper thread-এ ভাগ করে করা, যাতে থামার সময় কম হয়।
• Concurrent ও incremental: চিহ্ন দেওয়ার বড় অংশ আপনার কোড চলার সাথে সাথে পেছনের thread-এ করা, বা ছোট ছোট টুকরোয় ভাগ করা — যাতে একবারে লম্বা থামা না হয়।

৬ · একটিই thread — পাতা কেন জমে যায়, আর event loop-এর ছবি

আপনার JavaScript কোড চলে একটি thread-এ — অর্থাৎ একটিমাত্র call stack, একসময়ে একটিমাত্র কাজ। ব্রাউজারে এই thread-কে বলে main thread, আর এই একই thread পাতা আঁকা, বোতামের ক্লিক সামলানো, scroll — সবকিছুর দায়িত্বেও থাকে। একে বলে single-threaded execution.

এর ফল কী, ভাবুন। নিচের কোডটি কোনো বোতামের ক্লিকে চললে কী হবে?

button.addEventListener("click", () => {
  let total = 0;
  for (let i = 0; i < 3_000_000_000; i++) {   // কয়েকশো কোটি বার
    total += i;
  }
  result.textContent = total;
});

তাহলে setTimeout বা নেটওয়ার্ক থেকে ডেটা আনার মতো “অপেক্ষার” কাজ কীভাবে হয়, যদি thread একটিই? উত্তর: অপেক্ষার কাজটা JavaScript engine করেই না। Timer, নেটওয়ার্ক, ক্লিক শোনার কাজ করে ব্রাউজার (বা Node.js) নিজে — এদের বলে Web API. কাজ শেষ হলে আপনার callback একটি লাইনে (queue) অপেক্ষা করে। Call stack খালি হলেই event loop সেই লাইন থেকে পরের কাজটি stack-এ তোলে। লাইন দুই রকম: সাধারণ task queue (setTimeout, ক্লিক) আর অগ্রাধিকারের microtask queue (Promise-এর then). নিচের ছবিটি শুধু মূল ধারণা — বিস্তারিত পর্ব ৩১-এ।

1console.log("1: শুরু");2setTimeout(() => console.log("4: timeout"), 0);3Promise.resolve().then(() => console.log("3: promise"));4console.log("2: শেষ");

নিজে চালিয়ে মিলিয়ে নিন — এখানে একটি বাড়তি then-ও আছে:

console.log("A: script শুরু");

setTimeout(() => console.log("E: setTimeout 0"), 0);

Promise.resolve()
  .then(() => console.log("C: প্রথম then"))
  .then(() => console.log("D: দ্বিতীয় then"));

console.log("B: script শেষ");

৭ · ভাষা বনাম runtime — ECMAScript, ব্রাউজার আর Node.js

খেয়াল করেছেন, setTimeout বা document engine-এর অংশ নয় বললাম? এখানে একটি গুরুত্বপূর্ণ পার্থক্য আছে। JavaScript ভাষার নিয়ম লেখা আছে একটি মানদণ্ডে, যার নাম ECMAScript (Ecma International-এর TC39 কমিটি প্রতি বছর নতুন version প্রকাশ করে — ES2015, ES2016 … )। এতে আছে variable, function, object, Promise, Array-এর মতো মূল জিনিস। কিন্তু “পাতায় লেখো”, “ফাইল পড়ো”, “৩ সেকেন্ড পরে চালাও” — এগুলো ভাষার অংশ নয়।

এসব যোগ করে runtime বা host environment — engine-কে ঘিরে থাকা পরিবেশ, যা বাড়তি ক্ষমতা দেয়:

এজন্যই Node.js-এ document লিখলে ReferenceError: document is not defined আসে, আর ব্রাউজারে require("fs") কাজ করে না। দুই জায়গাতেই engine একই (V8), ভাষাও একই — শুধু চারপাশের পরিবেশ আলাদা। console আর setTimeout দুই runtime-ই দেয়, তাই দুই জায়গায় চলে। Node.js-এর সাথে Deno আর Bun-ও এখন জনপ্রিয় runtime — প্রথম ভাবনার প্রশ্নে এ নিয়ে আরও আছে।

৮ · ভুল কখন ধরা পড়ে — parse time বনাম run time, আর strict mode

পাইপলাইন বোঝার একটি বড় লাভ: error দেখে বলতে পারবেন সেটি কোন ধাপের। JavaScript-এ ভুল মূলত দুই সময়ে ধরা পড়ে।

console.log("a");
let x = ;

SyntaxError: Unexpected token ';'

একটি সূক্ষ্ম বিষয়: ব্রাউজারে প্রতিটি <script> ট্যাগ আলাদাভাবে parse হয়। তাই একটি ফাইলে SyntaxError থাকলে শুধু সেই script বাদ পড়ে; অন্য script ঠিকই চলে — আর তারা যদি ভাঙা script-এর function খোঁজে, পাবে run-time-এর ReferenceError.

Strict mode — ভুলকে চুপচাপ মেনে না নেওয়া

শুরুর দিকের JavaScript অনেক ভুল চুপচাপ মেনে নিত। ২০০৯ সালের ES5 যোগ করে strict mode — ফাইল বা function-এর শুরুতে "use strict"; লিখলে engine কড়া নিয়মে চলে। কয়েকটি প্রভাব:

• ঘোষণা না করা variable-এ মান বসালে (score = 10) চুপচাপ global variable তৈরি হয় না — আসে ReferenceError: score is not defined.
• সাধারণ function কলে this হয় undefined, global object নয় (পর্ব ২৪)।
• একই নামের দুটি parameter, বা with statement — parse time-এই SyntaxError.
• শুধু-পড়া যায় এমন property-তে লিখলে নীরবে ব্যর্থ না হয়ে TypeError.

সুখবর: ES module (import/export, পর্ব ৪৫) আর class-এর ভেতরের কোড নিজে থেকেই strict. তাই আধুনিক প্রজেক্টে আলাদা করে লেখার দরকার খুব কম হয়।

৯ · AI-এর যুগে — পারফরম্যান্সের পুরোনো গল্প বনাম মাপজোখ

“JavaScript দ্রুত করার ১০টি টিপস” — এমন লেখা ইন্টারনেটে অগণিত, আর AI সেগুলো থেকেই শিখেছে। সমস্যা হলো, এর অনেকগুলো লেখা হয়েছিল ২০১০-এর আগের engine-এর জন্য, যখন JIT ছিল না বা খুব সরল ছিল। আজকের engine সেই সব কৌশল নিজেই করে ফেলে, আর কিছু কৌশল উল্টো ক্ষতি করে — কোড কঠিন হয়, কিন্তু গতি বাড়ে না।

AI-এর পারফরম্যান্স পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• আগে মেপেছি সমস্যাটা আসলে কোথায় — অনুমানের ওপর কোড বদলাইনি
• পরামর্শটি কোন সময়ের, কোন engine-এর জন্য — জিজ্ঞেস করেছি বা খুঁজে দেখেছি
• বদলের পরে আবার একই অবস্থায় মেপে উন্নতি দেখেছি — একবারের console.time নয়
• কোড কি পড়তে কঠিন হলো? সামান্য লাভের জন্য বোধগম্যতা বিসর্জন দিইনি
• আগে বড় কারণগুলো দেখেছি — অপ্রয়োজনীয় নেটওয়ার্ক কল, বিশাল DOM বদল, main thread-এ লম্বা কাজ