সফ্টওয়্যারগুলি ওএসে খুব সাধারণ ভিত্তিতে চালিত হয় - তাদের মেমরির প্রয়োজন হয়। ডিভাইস ওএস এটিকে র্যাম আকারে সরবরাহ করে। প্রয়োজনীয় মেমরির পরিমাণ পৃথক হতে পারে - কিছু সফ্টওয়্যারগুলির জন্য বিশাল মেমরির প্রয়োজন হয়, কারও কারও কাছে পালট্রি মেমরির প্রয়োজন। বেশিরভাগ (সমস্ত না থাকলে) ব্যবহারকারীরা ওএসে একসাথে একাধিক অ্যাপ্লিকেশন চালায় এবং মেমরিটি ব্যয়বহুল (এবং ডিভাইসের আকার সীমাবদ্ধ) প্রদত্ত মেমরির পরিমাণ সর্বদা সীমাবদ্ধ। সুতরাং প্রদত্ত যে সমস্ত সফ্টওয়্যারগুলিতে নির্দিষ্ট পরিমাণের র্যামের প্রয়োজন হয় এবং সেগুলি সমস্ত একই সাথে চালানো যায়, ওএসকে দুটি জিনিস যত্ন নিতে হবে:
- যেটি সফ্টওয়্যারটি সর্বদা চলমান অবধি ব্যবহারকারী চালায় না, অর্থাৎ এটি স্বয়ংক্রিয়ভাবে বাতিল হওয়া উচিত নয় কারণ ওএসের স্মৃতিশক্তি শেষ হয়ে গেছে।
- উপরের ক্রিয়াকলাপটি চলমান সফ্টওয়্যারগুলির জন্য সম্মানজনক পারফরম্যান্স বজায় রেখে।
এখন মেমরিটি কীভাবে পরিচালনা করা হচ্ছে সে সম্পর্কে মূল প্রশ্নটি ফুটে উঠেছে। ঠিক কোনটি নিয়ন্ত্রণ করে যেখানে প্রদত্ত সফ্টওয়্যার সম্পর্কিত ডেটা মেমোরিতে থাকবে?
সম্ভাব্য সমাধান 1 : স্বতন্ত্র সফ্টওয়্যারগুলিতে তারা ডিভাইসে মেমরির ঠিকানাটি স্পষ্টভাবে নির্দিষ্ট করে দেয়। ধরুন ফটোশপ ঘোষণা করে যে এটা সবসময় মেমরি থেকে ছোটো ঠিকানাগুলি ব্যবহার করবে 0করার 1023(বাইটস একটি রৈখিক অ্যারে হিসাবে মেমরির কল্পনা, তাই প্রথম বাইট অবস্থানে রয়েছে 0, 1024ম বাইট অবস্থানে রয়েছে 1023) - অর্থাত অধিষ্ঠিত 1 GBমেমরির। একইভাবে, ভিএলসি ঘোষণা করে যে এটি মেমরি পরিসর দখল করবে 1244করার 1876, ইত্যাদি
সুবিধাদি:
- প্রতিটি অ্যাপ্লিকেশন একটি মেমরি স্লট পূর্ব নির্ধারিত হয়, সুতরাং এটি ইনস্টল এবং সম্পাদিত হয়ে গেলে, এটি কেবল সেই মেমরির অঞ্চলে তার ডেটা সংরক্ষণ করে এবং সবকিছু ঠিকঠাক কাজ করে।
অসুবিধাগুলি:
এটি স্কেল হয় না। তাত্ত্বিকভাবে, যখন কোনও অ্যাপ্লিকেশনটির ভারী ভারী দায়িত্ব কিছু করা হয় তখন একটি অ্যাপ্লিকেশনটির জন্য প্রচুর পরিমাণে মেমরির প্রয়োজন হতে পারে। সুতরাং এটি কখনই মেমোরির বাইরে চলে না যায় তা নিশ্চিত করার জন্য, এটি বরাদ্দ হওয়া মেমরি অঞ্চলটি সর্বদা মেমরির পরিমাণের চেয়ে বেশি বা সমান হতে হবে। যদি কোনও সফ্টওয়্যার, যার সর্বাধিক তাত্ত্বিক মেমরির ব্যবহার হয় 2 GB(সুতরাং 2 GBর্যামের কাছ থেকে মেমরি বরাদ্দকরণ প্রয়োজন ), কেবল মেমরিযুক্ত কোনও মেশিনে ইনস্টল করা থাকে 1 GB? উপলব্ধ র্যামের চেয়ে কম কি এই বলে সফটওয়্যারটি কেবল স্টার্টআপে বাতিল করতে হবে 2 GB? বা এটি কি চালিয়ে যাওয়া উচিত, এবং মেমরির প্রয়োজনীয় মুহুর্তটি কেবল মেমোরিটি 2 GBউপলব্ধ নয় যে কেবল পর্যাপ্ত স্মৃতি উপলব্ধ নয়?
স্মৃতি জালিয়াতি রোধ করা সম্ভব নয়। সেখানে লক্ষ লক্ষ সফ্টওয়্যার রয়েছে, এমনকি যদি তাদের প্রত্যেককে কেবল 1 kBমেমরি বরাদ্দ করা হয় তবে প্রয়োজনীয় মোট মেমরিটি ছাড়িয়ে যায় 16 GBযা বেশিরভাগ ডিভাইসের অফারের চেয়ে বেশি। তাহলে, কীভাবে বিভিন্ন সফ্টওয়্যার মেমরি স্লট বরাদ্দ করা যায় যা একে অপরের ক্ষেত্রগুলিতে অঘটন ঘটাচ্ছে না? প্রথমত, এমন কোনও কেন্দ্রীয় সফ্টওয়্যার বাজার নেই যা নিয়ন্ত্রন করতে পারে যে কোনও নতুন সফ্টওয়্যার প্রকাশিত হওয়ার পরে, নিজেকে এখনও এই অনাবৃত অঞ্চল থেকে এটিকে অনেক বেশি মেমরি দিতে হবে, এবং দ্বিতীয়ত, এমনকি থাকলেও এটি করা সম্ভব নয় কারণ এটি নেই। সফ্টওয়্যারগুলির কার্যত কার্যত অসীম (এইভাবে তাদের সকলের সাথে সামঞ্জস্য করার জন্য অসীম মেমরির প্রয়োজন হয়), এবং কোনও ডিভাইসে পাওয়া মোট র্যাম প্রয়োজনীয় জিনিসগুলির একটি অংশও সামঞ্জস্য করতে যথেষ্ট নয়, ফলে একটি সফ্টওয়্যারের মেমরির সীমানা অতিক্রম করা অনিবার্য হয়ে পড়ে making অন্য যে। তাই কি যখন ঘটে ফটোশপ মেমরির অবস্থানে নির্ধারিত হয় 1করতে 1023এবং ভিএলসি নির্ধারিত হয় 1000করতে 1676? যদি ফটোশপ লোকেশনটিতে কিছু ডেটা সঞ্চয় করে 1008, তবে ভিএলসি নিজের ডেটা এবং পরে ফটোশপের সাহায্যে ওভাররাইট করেএটি কি এই ভেবে ভেবে অ্যাক্সেস করে যে এটি একই ডেটা আগে সেখানে সংরক্ষণ করা হয়েছিল? আপনি কল্পনা করতে পারেন, খারাপ জিনিস ঘটবে।
সুতরাং পরিষ্কার, আপনি দেখতে পারেন, এই ধারণা বরং নিষ্পাপ।
সম্ভাব্য সমাধান 2 : আসুন অন্য একটি স্কিম চেষ্টা করুন - যেখানে ওএস মেমরির বেশিরভাগ পরিচালনার কাজ করবে। সফ্টওয়্যার, যখনই তাদের কোনও মেমরির প্রয়োজন হয়, কেবল ওএসকে অনুরোধ করবে এবং ওএস সেই অনুযায়ী সামঞ্জস্য করবে। বলুন ওএস নিশ্চিত করে যে যখনই কোনও নতুন প্রক্রিয়া মেমোরির জন্য অনুরোধ করছে, এটি সর্বনিম্ন বাইট ঠিকানা থেকে মেমরিটি বরাদ্দ করবে (যেমন আগে বলা হয়েছে, র্যামকে বাইটের লিনিয়ার অ্যারে হিসাবে কল্পনা করা যেতে পারে, তাই কোনও 4 GBর্যামের জন্য, ঠিকানাগুলির সীমাটি একটির জন্য থাকে থেকে বাইট 0থেকে2^32-1) যদি প্রক্রিয়াটি শুরু হয়, অন্যথায় যদি এটি মেমরির অনুরোধ করে একটি চলমান প্রক্রিয়া হয়, তবে এটি শেষ মেমরির অবস্থান থেকে বরাদ্দ হবে যেখানে সেই প্রক্রিয়া এখনও অবধি রয়েছে। যেহেতু সফ্টওয়্যারগুলি সেই ডেটা সংরক্ষণ করা হবে সেখানে প্রকৃত মেমরি ঠিকানাটি কী হবে তা বিবেচনা না করেই ঠিকানাগুলি নির্গমন করবে, সুতরাং ওএসকে সফ্টওয়্যার দ্বারা প্রকৃত শারীরিক ঠিকানায় নির্গত ঠিকানাটির ম্যাপিং বজায় রাখতে হবে (দ্রষ্টব্য: এটি যে দুটি কারণকে আমরা এই ধারণাটি বলি তার মধ্যে একটি এটি Virtual Memory। সফ্টওয়্যারগুলি যেখানে তাদের ডেটা সংরক্ষণ করা হয় সেই আসল মেমরি ঠিকানার যত্ন করে না, তারা কেবল ফ্লাইয়ের ঠিকানাগুলিই বের করে দেয় এবং ওএস এটি ফিট করার জন্য এবং সঠিক জায়গা খুঁজে পায় পরে যদি প্রয়োজন হয়)।
বলুন ডিভাইসটি কেবল চালু হয়েছে, ওএস সবেমাত্র চালু হয়েছে, এখনই অন্য কোনও প্রক্রিয়া চলছে না (ওএসকে উপেক্ষা করা, এটিও একটি প্রক্রিয়া!), এবং আপনি ভিএলসি চালু করার সিদ্ধান্ত নিয়েছেন । সুতরাং ভিএলসি সর্বনিম্ন বাইট ঠিকানাগুলি থেকে র্যামের একটি অংশ বরাদ্দ করা হয়। ভাল. এখন ভিডিওটি চলার সময়, কিছু ওয়েবপৃষ্ঠা দেখার জন্য আপনার ব্রাউজারটি শুরু করা দরকার। তারপরে কিছু পাঠ্য লেখার জন্য আপনাকে নোটপ্যাড চালু করতে হবে । এবং তারপর Eclipse কিছু কোডিং .. আপনার মেমরি করতে বেশ তাড়াতাড়ি 4 GBসব ব্যবহার করা হবে, এবং এই মত র্যাম দেখায়:
সমস্যা 1: এখন আপনি অন্য কোনও প্রক্রিয়া শুরু করতে পারবেন না, কারণ সমস্ত র্যাম ব্যবহৃত। সুতরাং প্রোগ্রামগুলিকে সর্বাধিক স্মৃতি মেমরির সাথে উপলব্ধ রেখে লিখতে হবে (অন্যান্য সফ্টওয়্যারগুলিও সমান্তরালভাবে চলবে!)। অন্য কথায়, আপনি আপনার র্যামশ্যাকল 1 GBপিসিতে একটি উচ্চ-স্মৃতি গ্রাহক অ্যাপ চালাতে পারবেন না ।
ঠিক আছে, সুতরাং এখন আপনি সিদ্ধান্ত নিয়েছেন যে আপনাকে আর গ্রহন এবং ক্রোম খোলা রাখার দরকার নেই , কিছু স্মৃতি মুক্ত করার জন্য আপনি এগুলি বন্ধ করে দিন। এই প্রক্রিয়াগুলির দ্বারা র্যামে স্থান দখল করা ওএস দ্বারা পুনরুদ্ধার করা হয়েছে, এবং এটি এখন এর মতো দেখাচ্ছে:
মনে করুন যে এই দুটি বন্ধ করে দেওয়ার ফলে 700 MBস্থান মুক্ত হয় - ( 400+ 300) এমবি। এখন আপনাকে অপেরা চালু করতে হবে, যা 450 MBস্থান গ্রহণ করবে । 450 MBমোটামুটি, আপনার কাছে মোট জায়গার তুলনায় আরও বেশি কিছু রয়েছে , তবে ... এটি সংক্ষিপ্ত নয়, এটি পৃথক অংশে বিভক্ত, যার কোনওটিই যথেষ্ট উপযুক্ত নয় 450 MB। সুতরাং আপনি একটি উজ্জ্বল ধারণাটি পেয়েছেন, আসুন নীচের সমস্ত প্রক্রিয়া যতটা সম্ভব উপরে উপরে সরিয়ে দিন, যা 700 MBনীচের অংশে খালি স্থানটি ছেড়ে দেবে । এই বলা হয়compaction। দুর্দান্ত, ব্যতীত ... সেখানে যে সমস্ত প্রক্রিয়া চলছে তা চলছে। তাদের স্থানান্তরিত করার অর্থ তাদের সমস্ত সামগ্রীর ঠিকানা সরিয়ে নেওয়া হবে (মনে রাখবেন, ওএস সফ্টওয়্যার দ্বারা মেমরি স্পটটির প্রকৃত মেমরি ঠিকানায় ম্যাপিং রাখে gine কল্পনা করুন সফ্টওয়্যারটি 45ডেটা সহ একটি ঠিকানা ছড়িয়ে দিয়েছে 123এবং ওএস এটিকে লোকেশনে সংরক্ষণ করেছিল 2012এবং মানচিত্রে একটি এন্ট্রি, ম্যাপিং নির্মিত 45করার 2012। সফ্টওয়্যারটি এখন স্মৃতিতে সরানো হয়, তাহলে কি অবস্থানে ব্যবহার করা হয় 2012আর হতে হবে 2012, কিন্তু একটি নতুন অবস্থানে এবং OS মানচিত্র আপডেট করতে তদনুসারে ম্যাপ হয়েছে 45থেকে নতুন ঠিকানা, যাতে সফ্টওয়্যার প্রত্যাশিত তথ্য (পেতে পারেন 123) যখন এটি মেমরি অবস্থানের জন্য অনুসন্ধান করে 45। যতদূর সফ্টওয়্যার উদ্বিগ্ন হয়, সব জানে যে ঠিকানা45তথ্য রয়েছে 123!)! এমন কোনও প্রক্রিয়াটি কল্পনা করুন যা স্থানীয় ভেরিয়েবলের উল্লেখ করে i। এটি আবার অ্যাক্সেস করার সময় এর ঠিকানাটি পরিবর্তিত হয়েছে, এবং এটি আর খুঁজে পাবে না। এটি একই সাথে সমস্ত ফাংশন, অবজেক্টস, ভেরিয়েবলের জন্য ধারণ করে, মূলত প্রত্যেকটিরই একটি ঠিকানা থাকে এবং একটি প্রক্রিয়া সরিয়ে নেওয়া মানে তাদের সকলের ঠিকানা পরিবর্তন করা। যা আমাদের দিকে নিয়ে যায়:
সমস্যা 2: আপনি কোনও প্রক্রিয়া সরাতে পারবেন না। এই প্রক্রিয়াটির মধ্যে থাকা সমস্ত ভেরিয়েবল, ফাংশন এবং অবজেক্টের মানগুলি সংকলনের সময় সংকলক দ্বারা বিস্তৃত হিসাবে হার্ডকোডযুক্ত মান রয়েছে, প্রক্রিয়াটি তার জীবদ্দশায় একই স্থানে থাকার উপর নির্ভর করে এবং সেগুলি পরিবর্তন ব্যয়বহুল। ফলস্বরূপ, প্রসেসগুলি প্রস্থান করার পরে বড় " holes" পিছনে ছেড়ে যায় । একে বলা হয়
External Fragmentation।
ভাল। মনে করুন কোনওভাবেই, কিছু অলৌকিক উপায়ে আপনি প্রক্রিয়াগুলি সরিয়ে নিতে পরিচালনা করেন। এখন 700 MBনীচে মুক্ত স্থান রয়েছে:
অপেরাটি নীচে মসৃণভাবে ফিট করে। এখন আপনার র্যাম এর মতো দেখাচ্ছে:
ভাল. সবকিছু ঠিক আছে দেখাচ্ছে। তবে, খুব বেশি জায়গা বাকি নেই, এবং এখন আপনাকে আবার ক্রোম চালু করতে হবে, একটি পরিচিত স্মৃতি-হগ! এটি শুরু করার জন্য প্রচুর স্মৃতি দরকার, এবং আপনার খুব কমই বাকী আছে ... বাদে আপনি এখন লক্ষ্য করুন যে কয়েকটি প্রক্রিয়া, যা প্রাথমিকভাবে বড় জায়গা দখল করে ছিল, এখন খুব বেশি জায়গার প্রয়োজন নেই। হতে আপনি আপনার ভিডিও বন্ধ করে ভিএলসি , অত এটি এখনও কিছু জায়গা দখল করা হয়, কিন্তু যতটা না হাই রেজোলিউশনের ভিডিও চালানোর সময় যেমন প্রয়োজন। একইভাবে নোটপ্যাড এবং ফটোগুলির জন্য । আপনার র্যাম এখন দেখতে এমন দেখাচ্ছে:
Holes, আরেকবার! স্কয়ার এক ফিরে! পূর্বে, প্রক্রিয়াগুলি সমাপ্তির কারণে গর্তগুলি ঘটেছিল, এখন এটি আগের তুলনায় কম স্থানের প্রসেসের কারণে ঘটে! এবং আপনার আবার একই সমস্যা রয়েছে, holesসম্মিলিত ফলন প্রয়োজনের চেয়ে আরও বেশি জায়গা দেয় তবে এগুলি চারদিকে ছড়িয়ে ছিটিয়ে থাকে, বিচ্ছিন্নতায় খুব বেশি ব্যবহার হয় না। সুতরাং আপনাকে আবার সেই প্রক্রিয়াগুলি সরিয়ে নিতে হবে, একটি ব্যয়বহুল ক্রিয়াকলাপ এবং খুব ঘন ঘন একটি, যেহেতু প্রক্রিয়াগুলি তাদের জীবনকালের তুলনায় প্রায়শই আকারে হ্রাস পাবে।
সমস্যা 3: প্রক্রিয়াগুলি, তাদের জীবদ্দশায়, আকারে হ্রাস পেতে পারে, অব্যবহৃত স্থান পিছনে রেখে, যদি এটি ব্যবহার করার প্রয়োজন হয়, তবে অনেকগুলি প্রক্রিয়া চালিত করার ব্যয়বহুল অপারেশন প্রয়োজন হবে। একে বলা হয়
Internal Fragmentation।
ভাল, এখন, আপনার ওএস প্রয়োজনীয় জিনিসটি করে, প্রক্রিয়াগুলি প্রায় ঘুরিয়ে দেয় এবং ক্রোম শুরু করে এবং কিছুক্ষণ পরে, আপনার র্যামটি দেখতে দেখতে এটি:
শীতল। এখন অনুমান করা আপনি আবার দেখা শুরু অবতার মধ্যে ভিএলসি । এর স্মৃতিশক্তি প্রয়োজন আপ! তবে ... নোটপ্যাডটি নীচে ছড়িয়ে পড়েছে বলে এটি বাড়ার কোনও জায়গা নেই left সুতরাং, আবার, ভিএলসি পর্যাপ্ত স্থান না পাওয়া পর্যন্ত সমস্ত প্রক্রিয়া নীচে চলে যেতে হবে !
সমস্যা 4: যদি প্রক্রিয়াগুলি বাড়ার প্রয়োজন হয় তবে এটি খুব ব্যয়বহুল অপারেশন হবে
ভাল। এখন অনুমান, ফটো একটি বহিস্থিত হার্ড ডিস্ক থেকে কিছু ফটো লোড করতে ব্যবহার করা হচ্ছে। হার্ড-ডিস্ক অ্যাক্সেস আপনাকে ক্যাশে এবং র্যামের ক্ষেত্র থেকে ডিস্কের মতো করে নিয়ে যায়, যা প্রস্থের আদেশের সাহায্যে ধীর হয়। বেদনাদায়ক, অকাট্যভাবে, অতিক্রম করা ধীরে ধীরে। এটি একটি আই / ও অপারেশন, যার অর্থ এটি সিপিইউ আবদ্ধ নয় (এটি ঠিক বিপরীত), যার অর্থ এই মুহূর্তে র্যাম দখল করার প্রয়োজন নেই। তবে এটি এখনও জেদীভাবে র্যাম দখল করে। আপনি যদি এর মধ্যে ফায়ারফক্স চালু করতে চান তবে আপনি পারবেন না, কারণ সেখানে খুব বেশি মেমরি পাওয়া যায় না, অন্যদিকে ফটোগুলি যদি তার আই / ও বাউন্ডের ক্রিয়াকলাপের সময়কালের জন্য স্মৃতি থেকে সরিয়ে নেওয়া হয়, তবে এটি প্রচুর স্মৃতি মুক্ত করে দিতে পারে, এর পরে (ব্যয়বহুল) কমপ্যাকশন, তারপরে ফায়ারফক্স ফিট করে।
সমস্যা 5: আই / ও বাউন্ড জবগুলি র্যাম দখল করে রাখে, যার ফলে র্যামের স্বল্প-ব্যবহার হয়, যা এর মধ্যে সিপিইউ আবদ্ধ চাকরিগুলি ব্যবহার করতে পারত।
সুতরাং, আমরা দেখতে পাচ্ছি, ভার্চুয়াল মেমরির পদ্ধতির সাথেও আমাদের অনেক সমস্যা রয়েছে।
এই সমস্যাগুলি মোকাবেলায় দুটি পন্থা রয়েছে - pagingএবং segmentation। আমাদের আলোচনা করা যাক paging। এই পদ্ধতির, একটি প্রক্রিয়ার ভার্চুয়াল অ্যাড্রেস স্পেস অংশ প্রকৃত মেমরি ম্যাপ করা হয় - বলা pages। একটি সাধারণ pageআকার হয় 4 kB। ম্যাপিংটি page tableকোনও ভার্চুয়াল ঠিকানা প্রদত্ত একটি নামক দ্বারা বজায় রাখা হয় , এখন আমাদের যা করতে হবে তা pageঠিকানাটি কোনটির সাথে সম্পর্কিত তা খুঁজে বের করার পরেpage table , pageপ্রকৃত শারীরিক মেমরির (যার হিসাবে পরিচিত frame) এর জন্য সংশ্লিষ্ট অবস্থানটি খুঁজে বের করতে হবে এবং দেওয়া হবে যে ভার্চুয়াল ঠিকানার অফসেট মধ্যে pageজন্য একই pageসেইসাথে frameযোগ ঠিকানাটি দ্বারা ফিরে যাও অফসেট দ্বারা প্রকৃত ঠিকানা জানতে page table। উদাহরণ স্বরূপ:
বামদিকে একটি প্রক্রিয়ার ভার্চুয়াল ঠিকানা স্থান। বলুন ভার্চুয়াল ঠিকানার জায়গার জন্য মেমরির 40 ইউনিট প্রয়োজন। যদি শারীরিক ঠিকানার জায়গার (ডানদিকে) মেমরির 40 ইউনিট থাকে তবে ডানদিকে একটি অবস্থান থেকে বাম দিক থেকে সমস্ত অবস্থানের মানচিত্র তৈরি করা সম্ভব হত এবং আমরা খুব খুশি হতাম। তবে দুর্ভাগ্য হিসাবে এটি হবে, শারীরিক স্মৃতিতে কেবল কম নয় (এখানে 24) মেমরি ইউনিট পাওয়া যায়, এটি একাধিক প্রক্রিয়ার মধ্যেও ভাগ করে নিতে হয়! ভাল, আসুন আমরা এটি দিয়ে কী করে তা দেখি।
প্রক্রিয়া শুরু হওয়ার পরে, অবস্থানের জন্য একটি মেমরি অ্যাক্সেসের অনুরোধটি 35তৈরি করুন বলুন। এখানে পৃষ্ঠার আকার 8(প্রতিটি ) বর্তমানে খালি রয়েছে। সুতরাং ওএস সিপিইউ ত্যাগ করে, একটি ডিভাইস ড্রাইভারকে ডিস্ক অ্যাক্সেস করতে দেয় এবং নম্বর নং পৃষ্ঠাটি আনতে দেয়।page8 অবস্থানের মধ্যে রয়েছে, অবস্থানগুলির পুরো ভার্চুয়াল ঠিকানা স্পেসে পৃষ্ঠা 40রয়েছে 5)। সুতরাং এই অবস্থানটি পৃষ্ঠা নং এর অন্তর্গত। 4( 35/8)। এর মধ্যে page, এই অবস্থানটির 3( 35%8) অফসেট রয়েছে । সুতরাং এই অবস্থানটি টিপল (pageIndex, offset)= দ্বারা নির্দিষ্ট করা যেতে পারে (4,3)। এটি কেবলমাত্র শুরু, সুতরাং প্রক্রিয়াটির কোনও অংশই প্রকৃত শারীরিক স্মৃতিতে এখনও সংরক্ষণ করা হয়নি। সুতরাং page table, যা ডানদিকে প্রকৃত পৃষ্ঠাগুলিতে বাম পৃষ্ঠাগুলির ম্যাপিং বজায় রাখে (যেখানে তারা ডাকা হয়)frames4এই প্রক্রিয়াটির জন্য (ডিস্কের প্রোগ্রাম থেকে মূলত একটি মেমরি খণ্ড যার ঠিকানাগুলি থেকে শুরু 32করে 39)। এটি উপস্থিত হয়ে ওএস পৃষ্ঠার র্যামের কোথাও কোথাও বরাদ্দ দেয়, নিজেই প্রথমে ফ্রেম বলুন এবং page tableএই প্রক্রিয়াটির জন্য সেই পৃষ্ঠা 4মানচিত্রটি 0র্যামে ফ্রেম করতে নোট করে । এখন তথ্য শেষ পর্যন্ত শারীরিক স্মৃতিতে আছে। ওএস আবার টিপলের জন্য পৃষ্ঠা সারণীটি অনুসন্ধান করে (4,3)এবং এই পৃষ্ঠার টেবিলটি বলে যে 4র্যামটিতে ফ্রেম বদ্ধ করার জন্য পৃষ্ঠাটি ইতিমধ্যে ম্যাপ করা আছে 0। সুতরাং ওএস সহজেই 0র্যামের ত্রিম ফ্রেমে যায় , 3ফ্রেমে অফসেটে ডেটা অ্যাক্সেস করে (এটি বুঝতে কিছুক্ষণ সময় নিন The সম্পূর্ণpageযা ডিস্ক থেকে আনা হয়েছিল তাতে সরানো হয়েছে frame। সুতরাং কোনও পৃষ্ঠায় একটি পৃথক মেমরি অবস্থানের অফসেট যাই হোক না কেন, ফ্রেমের ক্ষেত্রেও এটি একই হবে, যেহেতু page/ এর মধ্যে frame, মেমরি ইউনিট এখনও একই জায়গায় অপেক্ষাকৃত একই স্থানে থাকে!), এবং ডেটা ফেরত দেয়! যেহেতু প্রথম ক্যোয়ারীতে নিজেই ডেটা মেমরিতে পাওয়া যায় নি, বরং স্মৃতিতে লোড করার জন্য ডিস্ক থেকে আনতে হয়েছিল, এটি একটি মিস গঠন করে ।
ভাল। এখন ধরা যাক, অবস্থানের জন্য একটি মেমরি অ্যাক্সেস 28করা হয়েছে। এটি ফুটন্ত (3,4)। Page tableএই মুহূর্তে কেবলমাত্র একটি প্রবেশ রয়েছে, 4ফ্রেমে ম্যাপিং পৃষ্ঠা 0। সুতরাং এটি আবার একটি মিস , প্রক্রিয়াটি সিপিইউ ছেড়ে দেয়, ডিভাইস ড্রাইভারটি ডিস্ক থেকে পৃষ্ঠাটি আনে, প্রক্রিয়াটি আবার সিপিইউর নিয়ন্ত্রণ ফিরে পায় এবং page tableএটি আপডেট হয়। বলুন এখন পৃষ্ঠাটি র্যামের 3ফ্রেমে ম্যাপ করা হয়েছে 1। সুতরাং (3,4)হয়ে যায় (1,4)এবং র্যামের সেই অবস্থানের ডেটা ফেরত দেওয়া হয়। ভাল. এইভাবে, ধরুন পরবর্তী মেমরির অ্যাক্সেসটি অবস্থানের জন্য 8, যা অনুবাদ করে (1,0)। পৃষ্ঠাটি 1এখনও মেমরিতে নেই, একই পদ্ধতিটি পুনরাবৃত্তি pageকরা হয় এবং ফ্রেমটিতে বরাদ্দ দেওয়া হয়2 র্যাম থাকে। এখন র্যাম-প্রসেস ম্যাপিং উপরের ছবির মতো দেখাচ্ছে। এই মুহুর্তে, র্যাম, যা কেবলমাত্র 24 ইউনিট মেমরি উপলব্ধ ছিল তা পূর্ণ হয়ে যায়। ধরুন এই প্রক্রিয়া জন্য পরবর্তী মেমরির অ্যাক্সেসের অনুরোধ ঠিকানা থেকে 30। এটি মানচিত্র করে (3,6)এবং page tableবলে যে পৃষ্ঠাটি 3র্যামে রয়েছে এবং এটি ফ্রেমের মানচিত্র 1। হ্যাঁ! সুতরাং তথ্যটি র্যামের অবস্থান থেকে পাওয়া যায় (1,6)এবং ফিরে আসে। এটি গঠন করে aআঘাত , যেহেতু প্রয়োজনীয় ডেটা সরাসরি র্যাম থেকে পাওয়া যায়, এইভাবে খুব দ্রুত। একইভাবে, আগামী কয়েক অ্যাক্সেসের অনুরোধ, স্থান বলতে 11, 32, 26, 27সব হিট , অর্থাত্ প্রক্রিয়া দ্বারা অনুরোধ করা তথ্য অন্যত্র দেখুন ছাড়াই র্যাম সরাসরি পাওয়া যায়।
এখন ধরুন যে কোনও লোকেশনের জন্য মেমরি অ্যাক্সেসের অনুরোধ 3আসে। এটা তোলে অনুবাদ (0,3)এবং page tableএই প্রক্রিয়া বর্তমানে 3 এন্ট্রি, পৃষ্ঠাগুলির জন্য রয়েছে, যার জন্য 1,3 এবং 4বলছেন যে এই পৃষ্ঠার মেমরি নয়। পূর্ববর্তী কেসগুলির মতো এটিও ডিস্ক থেকে আনা হয়, তবে পূর্ববর্তী কেসগুলির মতো নয়, র্যামটি পূর্ণ হয়! তাহলে এখন কি করতে হবে? এখানে ভার্চুয়াল মেমরির সৌন্দর্য রয়েছে, র্যামের একটি ফ্রেম উচ্ছেদ করা হয়েছে! (বিভিন্ন উপাদানগুলি পরিচালনা করে যে কোন ফ্রেমটি উচ্ছেদ করতে হবে It এটি LRUভিত্তিক হতে পারে , যেখানে কোনও প্রক্রিয়াটির জন্য সম্প্রতি যে ফ্রেমটি অ্যাক্সেস করা হয়েছিল তা খালি করা হতে পারে It এটি first-come-first-evictedভিত্তি হতে পারে , যেখানে ফ্রেমটি দীর্ঘকাল আগে বরাদ্দকৃত, খালি করা ইত্যাদি ইত্যাদি) basis ।) তাই কিছু ফ্রেম উচ্ছেদ করা হয়। ফ্রেম 1 বলুন (কেবল এলোমেলোভাবে এটি চয়ন করা)। যাইহোক, এটি frameকিছু ম্যাপ করা হয়page! (বর্তমানে, এটি 3আমাদের এক এবং একমাত্র প্রক্রিয়ার পৃষ্ঠায় পৃষ্ঠার সারণিতে ম্যাপ করা হয়েছে )। সুতরাং সেই প্রক্রিয়াটি এই মর্মান্তিক সংবাদটি বলতে হবে frame, যেটি দুর্ভাগ্যক্রমে আপনার মালিকানাধীন, অন্যটির জন্য জায়গা তৈরির জন্য র্যাম থেকে উচ্ছেদ করা উচিত pages। প্রক্রিয়াটি নিশ্চিত করতে হবে যে এটি page tableএই তথ্যের সাথে তার আপডেট হয়, অর্থাত্, সেই পৃষ্ঠা-ফ্রেমের দ্বীপের জন্য এন্ট্রি সরিয়ে দেয়, যাতে পরবর্তী বারের জন্য অনুরোধ করা হয় page, সঠিকভাবে প্রক্রিয়াটি জানায় যে এটি pageআর স্মৃতিতে নেই , এবং ডিস্ক থেকে আনতে হবে। ভাল. সুতরাং ফ্রেমটি 1উচ্ছেদ করা হয়েছে, পৃষ্ঠাটি 0এনে এখানে র্যামে রাখা হয়েছে, এবং পৃষ্ঠার জন্য এন্ট্রি 3সরিয়ে ফেলা হবে এবং পৃষ্ঠা 0ম্যাপিং দ্বারা একই ফ্রেমে প্রতিস্থাপন করা হবে1। সুতরাং এখন আমাদের ম্যাপিংটি এর মতো দেখাচ্ছে ( frameডানদিকে দ্বিতীয়টিতে রঙ পরিবর্তনটি নোট করুন ):
সবে কি হয়েছে দেখেছি? প্রক্রিয়াটি বাড়াতে হয়েছিল, এটি উপলব্ধ র্যামের চেয়ে আরও বেশি জায়গার প্রয়োজন ছিল, তবে আমাদের পূর্বের দৃশ্যের বিপরীতে যেখানে র্যামের প্রতিটি প্রক্রিয়া একটি ক্রমবর্ধমান প্রক্রিয়াটি সামঞ্জস্য করতে চলেছিল, এখানে এটি কেবলমাত্র একটি pageপ্রতিস্থাপনের মাধ্যমে ঘটেছিল ! এটি সম্ভব হয়েছিল যে কোনও প্রক্রিয়াটির জন্য স্মৃতিটিকে আর সুস্পষ্ট হওয়া দরকার না, এটি খণ্ডগুলিতে বিভিন্ন স্থানে থাকতে পারে, ওএস কোথায় রয়েছে সে সম্পর্কিত তথ্য বজায় রাখে এবং যখন প্রয়োজন হয়, তাদের যথাযথ অনুসন্ধান করা হয়। দ্রষ্টব্য: আপনি ভাবছেন, হু, বেশিরভাগ সময় যদি এটি হয় missএবং ডেটাটি ডিস্ক থেকে মেমরিতে ক্রমাগত লোড করতে হয়? হ্যাঁ, তাত্ত্বিকভাবে এটি সম্ভব, তবে বেশিরভাগ সংকলকগুলি এমনভাবে ডিজাইন করা হয়েছে যা অনুসরণ করেlocality of referenceউদাহরণস্বরূপ, যদি কিছু মেমোরি অবস্থানের ডেটা ব্যবহার করা হয়, পরবর্তী প্রয়োজনীয় তথ্যগুলি কোথাও খুব কাছাকাছি অবস্থিত হবে, সম্ভবত একই থেকে page, pageযা সবেমাত্র মেমরিতে লোড হয়েছিল। ফলস্বরূপ, পরবর্তী মিসটি বেশ কিছু সময়ের পরে ঘটবে, আসন্ন মেমরির বেশিরভাগ প্রয়োজনীয়তা সবেমাত্র আনা পৃষ্ঠায় বা ইতিমধ্যে ব্যবহৃত মেমরিতে থাকা পৃষ্ঠাগুলি দ্বারা পূরণ করা হবে। সঠিক একই নীতিটি আমাদের সাম্প্রতিককালে ব্যবহৃত হওয়া উচ্ছেদ করার অনুমতি দেয় page, যুক্তি দিয়ে যা কিছুক্ষণ ব্যবহৃত হয়নি, কিছুক্ষণের মধ্যে ব্যবহৃত হওয়ার সম্ভাবনাও নেই। তবে এটি সবসময় হয় না এবং ব্যতিক্রমী ক্ষেত্রে হ্যাঁ, পারফরম্যান্স ক্ষতিগ্রস্থ হতে পারে। এটি সম্পর্কে আরও পরে।
সমস্যার সমাধান 4: প্রক্রিয়াগুলি এখন সহজেই বাড়তে পারে, যদি স্থান সমস্যার সম্মুখীন হয়, তবে pageঅন্য যে কোনও প্রক্রিয়া সরিয়ে না রেখে কেবল একটি সহজ প্রতিস্থাপন করা দরকার requires
সমস্যার সমাধান 1: একটি প্রক্রিয়া সীমাহীন মেমরি অ্যাক্সেস করতে পারে। যখন উপলভ্য চেয়ে বেশি মেমরির প্রয়োজন হয় তখন ডিস্কটিকে ব্যাকআপ হিসাবে ব্যবহার করা হয়, প্রয়োজনীয় নতুন ডেটা ডিস্ক থেকে মেমরিতে লোড করা হয় এবং সর্বশেষে ব্যবহৃত ডেটা frame(বা page) ডিস্কে স্থানান্তরিত হয়। এটি সীমাহীনভাবে চলতে পারে এবং যেহেতু ডিস্কের স্থানটি সস্তা এবং কার্যত সীমাহীন তাই এটি সীমাহীন মেমরির একটি মায়া দেয়। নামের আরেকটি কারণVirtual Memory , এটি আপনাকে স্মৃতির মায়া দেয় যা সত্যই পাওয়া যায় না!
শীতল। এর আগে আমরা একটি সমস্যার মুখোমুখি হয়েছি যেখানে একটি প্রক্রিয়া আকারে হ্রাস হলেও খালি স্থানটি অন্য প্রক্রিয়াগুলির দ্বারা পুনরুদ্ধার করা কঠিন (কারণ এটি ব্যয়বহুল সংকোচনের প্রয়োজন হবে)। এখন এটি সহজ, যখন কোনও প্রক্রিয়া আকারে ছোট হয়ে যায়, এর অনেকগুলি pagesআর ব্যবহার করা হয় না, সুতরাং যখন অন্যান্য প্রক্রিয়াগুলিকে আরও মেমরির প্রয়োজন হয়, একটি সাধারণ LRUভিত্তিক উচ্ছেদটি pagesর্যাম থেকে স্বল্পভাবে ব্যবহৃত সেইগুলিকে স্বয়ংক্রিয়ভাবে উচ্ছেদ করে এবং সেখান থেকে নতুন পৃষ্ঠাগুলির সাথে প্রতিস্থাপন করে অন্যান্য প্রক্রিয়াগুলি (এবং অবশ্যই page tablesসেই সমস্ত প্রক্রিয়াগুলি আপডেট করার পাশাপাশি সেই মূল প্রক্রিয়াটির জন্য এখন কম জায়গার প্রয়োজন রয়েছে), এগুলি কোনও ব্যয়বহুল সংক্ষেপণ অপারেশন ছাড়াই!
সমস্যার সমাধান 3: যখনই প্রক্রিয়াগুলি আকারে হ্রাস পায়, তখন এটির framesর্যাম কম ব্যবহৃত হবে, সুতরাং একটি সাধারণ LRUভিত্তিক উচ্ছেদ উক্ত পৃষ্ঠাগুলিকে উচ্ছেদ করতে এবং pagesনতুন প্রক্রিয়াগুলির দ্বারা প্রয়োজনীয়গুলির সাথে সেগুলি প্রতিস্থাপন করতে পারে , যাতে Internal Fragmentationপ্রয়োজন ছাড়াই এড়ানো যায় compaction।
সমস্যা 2 হিসাবে, এটি বুঝতে কিছুক্ষণ সময় নিন, দৃশ্যটি নিজেই পুরোপুরি সরানো হয়েছে! একটি নতুন প্রক্রিয়া সমন্বিত করার জন্য কোনও প্রক্রিয়া সরানোর দরকার নেই, কারণ এখন পুরো প্রক্রিয়াটি কখনই একসাথে খাপ খায় না, কেবলমাত্র কয়েকটি নির্দিষ্ট পৃষ্ঠায় অ্যাডহক ফিট করতে হবে যা framesর্যাম থেকে উচ্ছেদ করে ঘটে । সবকিছু ইউনিটগুলিতে ঘটে থাকে pages, সুতরাং holeএখনকার কোনও ধারণা নেই , এবং তাই কোনও কিছুর চলমান নিয়ে প্রশ্নই আসে না! pagesএই নতুন প্রয়োজনীয়তার কারণে 10 টি স্থানান্তরিত হতে হয়েছিল, এমন হাজার হাজারও pagesরয়ে গেছে যাঁর হাতছাড়া। যদিও এর আগে, সমস্ত প্রক্রিয়া (তাদের প্রতিটি বিট) সরানো হয়েছিল!
সমস্যার সমাধান 2: একটি নতুন প্রক্রিয়া সামঞ্জস্য করার জন্য, অন্যান্য প্রসেসের সাম্প্রতিক ব্যবহৃত ব্যবহৃত অংশগুলির ডেটা প্রয়োজনীয় হিসাবে উচ্ছেদ করতে হবে, এবং এটি স্থির আকারের ইউনিটগুলিতে ডাকা হয় pages। সুতরাং এই সিস্টেমের সাথে holeবা এর কোনও সম্ভাবনা নেই External Fragmentation।
এখন যখন প্রক্রিয়াটির জন্য কিছু I / O অপারেশন করা দরকার তখন এটি সিপিইউ সহজেই ছাড়তে পারে! ওএসগুলি কেবল এগুলি সমস্ত pagesর্যাম থেকে উচ্ছেদ করে (সম্ভবত এটি কোনও ক্যাশে সংরক্ষণ করুন) যখন নতুন প্রক্রিয়াগুলি এর মধ্যে র্যামটি দখল করে। আই / ও অপারেশন হয়ে গেলে, ওএসগুলি কেবল এটিকে pagesর্যামে পুনরুদ্ধার করে (অবশ্যই pagesকিছু অন্যান্য প্রক্রিয়া থেকে এটি প্রতিস্থাপন করে, মূল প্রক্রিয়াটি প্রতিস্থাপনকারীদের হতে পারে বা এমন কিছু হতে পারে যা তাদের নিজেরাই আই / ও এখন, এবং তাই স্মৃতি ত্যাগ করতে পারেন!)
সমস্যার সমাধান 5: যখন কোনও প্রক্রিয়া I / O ক্রিয়াকলাপগুলি করে, তখন এটি সহজেই র্যাম ব্যবহার ছেড়ে দিতে পারে, যা অন্যান্য প্রক্রিয়াগুলি ব্যবহার করতে পারে। এটি র্যামের যথাযথ ব্যবহারের দিকে নিয়ে যায়।
এবং অবশ্যই, এখন কোনও প্রক্রিয়া সরাসরি র্যাম অ্যাক্সেস করছে না। প্রতিটি প্রক্রিয়া একটি ভার্চুয়াল মেমরি অবস্থান অ্যাক্সেস করা হয়, যা একটি শারীরিক র্যাম ঠিকানায় ম্যাপ করা হয় এবং page-tableসেই প্রক্রিয়াটি দ্বারা রক্ষণাবেক্ষণ করা হয় । ম্যাপিংটি ওএস-ব্যাকড, ওএস প্রক্রিয়াটি জানতে দেয় যে কোন ফ্রেমটি খালি রয়েছে যাতে কোনও প্রক্রিয়াটির জন্য একটি নতুন পৃষ্ঠা সেখানে লাগানো যায়। যেহেতু এই মেমরি বরাদ্দটি ওএস নিজেই তদারকি করে চলেছে, এটি সহজেই নিশ্চিত করতে পারে যে র্যাম থেকে কেবল ফাঁকা ফ্রেম বরাদ্দ করে, বা র্যামের অন্য কোনও প্রক্রিয়ার বিষয়বস্তু অতিক্রম করে কোনও প্রক্রিয়া অন্য প্রক্রিয়ার বিষয়বস্তুতে অকার্যকর হয় না, প্রক্রিয়াটির সাথে যোগাযোগ করে এটি আপডেট করতে page-table।
আসল সমস্যার সমাধান: কোনও প্রক্রিয়া অন্য প্রক্রিয়ার বিষয়বস্তু অ্যাক্সেস করার কোনও সম্ভাবনা নেই, যেহেতু পুরো বরাদ্দটি ওএস নিজেই পরিচালনা করে এবং প্রতিটি প্রক্রিয়া তার নিজস্ব স্যান্ডবক্সযুক্ত ভার্চুয়াল ঠিকানার জায়গায় চালিত হয়।
সুতরাং paging(অন্যান্য কৌশলগুলির মধ্যে) ভার্চুয়াল মেমরির সাথে একত্রে, আজকের সফ্টওয়্যারগুলি ওএস-এস-তে চালিত করার ক্ষমতা রাখে! এটি সফ্টওয়্যার বিকাশকারীকে ব্যবহারকারীর ডিভাইসে কতটা মেমরি উপলব্ধ তা নিয়ে চিন্তাভাবনা থেকে মুক্ত করে, কোথায় ডেটা সঞ্চয় করবে, অন্যান্য প্রক্রিয়াগুলিকে কীভাবে তাদের সফ্টওয়্যারটির ডেটা ক্ষতিগ্রস্থ হওয়া থেকে রোধ করবে ইত্যাদি। তবে এটি অবশ্যই সম্পূর্ণ প্রমাণ নয়। ত্রুটি রয়েছে:
Pagingচূড়ান্তভাবে, ব্যবহারকারীকে গৌণ ব্যাকআপ হিসাবে ডিস্ক ব্যবহার করে অসীম স্মৃতির মায়া দেয়। মেমোরিতে ফিট করার জন্য গৌণ স্টোরেজ থেকে ডেটা পুনরুদ্ধার করা (বলা হয় page swapএবং র্যামে পছন্দসই পৃষ্ঠাটি খুঁজে না পাওয়ার ইভেন্টটি ডাকা হয় page fault) এটি আইও অপারেশন হিসাবে ব্যয়বহুল। এটি প্রক্রিয়াটি ধীর করে দেয়। এই জাতীয় বেশ কয়েকটি পৃষ্ঠার পরিবর্তনগুলি পরপর ঘটে এবং প্রক্রিয়াটি বেদনাদায়কভাবে ধীর হয়ে যায়। আপনার সফ্টওয়্যারটি কখনও সূক্ষ্ম ও জঘন্যভাবে চলতে দেখেছে, এবং হঠাৎ এটি এতটা ধীর হয়ে গেছে যে এটি প্রায় স্তব্ধ হয়ে গেছে, বা আপনাকে পুনরায় আরম্ভ করার কোনও বিকল্প নেই? সম্ভবত খুব বেশি পৃষ্ঠাগুলির অদলবদল ঘটছে, এটি ধীর করে দিয়েছে (ডাকা হয়)thrashing )।
সুতরাং ওপিতে ফিরে আসছি,
কোনও প্রক্রিয়া সম্পাদনের জন্য আমাদের ভার্চুয়াল মেমরির প্রয়োজন কেন? - উত্তরটি দৈর্ঘ্যে ব্যাখ্যা করার সাথে সাথে সফ্টওয়্যারগুলিকে ডিভাইস / ওএসের অসীম মেমরির ধারণা দেয়, যাতে বড় বা ছোট কোনও সফ্টওয়্যার চালানো যায়, মেমরির বরাদ্দের চিন্তা না করে বা অন্য প্রক্রিয়াগুলি তার ডেটাটিকে দূষিত করে, এমনকি যখন সমান্তরালে চলমান। এটি এমন একটি ধারণা, যা বাস্তবে বাস্তবায়িত হয় বিভিন্ন কৌশলগুলির মাধ্যমে, যার মধ্যে একটি এখানে বর্ণিত রয়েছে, পেজিং । এটি সেগমেন্টেশনও হতে পারে ।
বাহ্যিক হার্ড ড্রাইভ থেকে প্রক্রিয়া (প্রোগ্রাম) সম্পাদনের জন্য মূল স্মৃতিতে (শারীরিক মেমরি) আনা হলে এই ভার্চুয়াল মেমরিটি কোথায় দাঁড়াবে? - ভার্চুয়াল মেমরিটি প্রতি সেও কোথাও দাঁড়ায় না, এটি একটি বিমূর্ততা, সর্বদা উপস্থিত থাকে, যখন সফ্টওয়্যার / প্রক্রিয়া / প্রোগ্রাম বুট করা হয়, তখন এটির জন্য একটি নতুন পৃষ্ঠা সারণী তৈরি করা হয়, এবং এতে ঠিকানাগুলি থেকে ম্যাপিং থাকা থাকে that র্যামের প্রকৃত শারীরিক ঠিকানায় প্রক্রিয়া। প্রক্রিয়াটির দ্বারা প্রকাশিত ঠিকানাগুলি যেহেতু প্রকৃত ঠিকানা নয়, এক অর্থে, সেগুলি আসলে, আপনি যা বলতে পারেন তা the virtual memory।
ভার্চুয়াল মেমরি কে কে যত্ন করে এবং ভার্চুয়াল মেমরির আকার কত? - এটি ওএস এবং সফ্টওয়্যার দ্বারা ব্যবহৃত হয় is আপনার কোডে এমন কোনও ফাংশনটি কল্পনা করুন (যা শেষ পর্যন্ত সংকলন করে কার্য সম্পাদনযোগ্য করে তোলে যা প্রক্রিয়া তৈরি করেছিল) যা একটি স্থানীয় ভেরিয়েবল - একটি int i। কোডটি কার্যকর করে, iফাংশনের স্ট্যাকের মধ্যে একটি মেমরি ঠিকানা পায়। এই ফাংশনটি নিজেই অন্য কোথাও একটি বস্তু হিসাবে সঞ্চিত। এই ঠিকানাগুলি সংকলক উত্পন্ন হয় (সংকলক যা কার্যকরভাবে আপনার কোডটি সংকলন করে) - ভার্চুয়াল ঠিকানাগুলি। যখন মৃত্যুদন্ড কার্যকর করা হয়, iসেই ফাংশনের সময়কালের জন্য প্রকৃত শারীরিক ঠিকানায় কোথাও বসবাস করতে হয় (যদি না এটি একটি স্ট্যাটিক ভেরিয়েবল হয়!), সুতরাং ওএসের সংকলকটি তৈরির ভার্চুয়াল ঠিকানার মানচিত্র তৈরি করেi করা একটি আসল শারীরিক ঠিকানায়, যাতে যখনই that ফাংশনের মধ্যে কিছু কোডের মান দরকার হয়i, সেই প্রক্রিয়াটি ভার্চুয়াল ঠিকানার জন্য ওএসকে জিজ্ঞাসা করতে পারে এবং ওএস পরিবর্তে সঞ্চিত মানটির জন্য শারীরিক ঠিকানাটিকে জিজ্ঞাসা করতে পারে এবং এটি ফিরিয়ে দিতে পারে।
মনে করুন র্যামের আকার যদি 4 গিগাবাইট হয় (অর্থাৎ 2 ^ 32-1 ঠিকানা স্পেস) ভার্চুয়াল মেমরির আকার কত? - র্যামের আকার ভার্চুয়াল মেমরির আকারের সাথে সম্পর্কিত নয়, এটি ওএসের উপর নির্ভর করে। উদাহরণস্বরূপ, 32 বিট উইন্ডোতে, এটি 16 TB, 64 বিট উইন্ডোতে এটি হয় 256 TB। অবশ্যই এটি ডিস্ক আকার দ্বারা সীমাবদ্ধ, যেহেতু মেমরিটি ব্যাক আপ করা হয়।