কেন জেভিএম স্ট্যাক-ভিত্তিক এবং ডালভিক ভিএম রেজিস্টার ভিত্তিক?

Question 1

আমি কৌতূহলী, কেন সান জেভিএম স্ট্যাক-ভিত্তিক এবং গুগল ডালভিকভিএমকে নিবন্ধভিত্তিক করার সিদ্ধান্ত নিয়েছে?

আমি মনে করি যে জেভিএম সত্যিই ধরে নিতে পারে না যে লক্ষ্য প্ল্যাটফর্মে একটি নির্দিষ্ট সংখ্যক নিবন্ধক পাওয়া যায়, যেহেতু এটি প্ল্যাটফর্মটি স্বাধীন বলে মনে করা হয়। এর জন্য এটি কেবল জেআইটি সংকলককে রেজিস্টার-বরাদ্দ ইত্যাদি স্থগিত করে। (আমি ভুল হলে শুধরে.)

সুতরাং অ্যান্ড্রয়েড ছেলেরা ভেবেছিল, "আরে, এটি অদক্ষ, চলুন এখনই ভিজিএম ভিত্তিক ভিএম এর জন্য যাই ..."? তবে অপেক্ষা করুন, একাধিক বিভিন্ন অ্যান্ড্রয়েড ডিভাইস রয়েছে, ডালভিক কোন সংখ্যক নিবন্ধককে লক্ষ্য করেছিল? ডালভিক ওপকডগুলি নির্দিষ্ট সংখ্যক নিবন্ধকের জন্য হার্ডকোডযুক্ত?

বাজারে বর্তমান সমস্ত অ্যান্ড্রয়েড ডিভাইসগুলিতে প্রায় একই সংখ্যক নিবন্ধক রয়েছে? বা, ডেক্স-লোডিংয়ের সময় কোনও রেজিস্টার পুনরায় বরাদ্দ সঞ্চালিত হয়? এই সব একসাথে ফিট করে?

Question 2

স্ট্যাক-ভিত্তিক ভিএম এর কয়েকটি বৈশিষ্ট্য রয়েছে যা জাভার ডিজাইনের লক্ষ্যগুলির সাথে উপযুক্ত fit

স্ট্যাক-ভিত্তিক নকশা লক্ষ্যযুক্ত হার্ডওয়্যার (রেজিস্টারস, সিপিইউ বৈশিষ্ট্যগুলি) সম্পর্কে খুব কম ধারণা তৈরি করে, তাই বিভিন্ন ধরণের হার্ডওয়্যারে ভিএম প্রয়োগ করা সহজ।
যেহেতু নির্দেশাবলীর অপারেশনগুলি মূলত অন্তর্নিহিত, তাই অবজেক্ট কোডটি আরও ছোট হবে। যদি আপনি ধীর নেটওয়ার্ক লিঙ্কে কোড ডাউনলোড করতে যাচ্ছেন তবে এটি গুরুত্বপূর্ণ।

একটি রেজিস্টার-ভিত্তিক স্কিমের সাথে যাওয়ার সম্ভবত সম্ভবত ডালভিকের কোড জেনারেটরের পারফরম্যান্ট কোড তৈরি করতে তেমন পরিশ্রম করতে হবে না। অত্যন্ত নিবন্ধভুক্ত সমৃদ্ধ বা নিবন্ধ-দরিদ্র আর্কিটেকচারে দৌড়ানো সম্ভবত ডালভিককে প্রতিবন্ধক করে তুলবে, তবে এটি সাধারণ লক্ষ্য নয় - এআরএম একটি রাস্তার খুব মাঝারি আর্কিটেকচার।

আমি এটাও ভুলে গিয়েছিলাম যে ডালভিকের প্রাথমিক সংস্করণে কোনও জেআইটি অন্তর্ভুক্ত ছিল না। আপনি যদি নির্দেশাবলী সরাসরি ব্যাখ্যা করতে চলেছেন, তবে কোনও রেজিস্টার-ভিত্তিক স্কিম সম্ভবত ব্যাখ্যার পারফরম্যান্সের জন্য একটি বিজয়ী।

Question 3

আমি কোনও রেফারেন্স খুঁজে পাচ্ছি না, তবে আমি মনে করি সান স্ট্যাক-ভিত্তিক বাইকোড পদ্ধতির জন্য সিদ্ধান্ত নিয়েছে কারণ এটি কয়েকটি রেজিস্টার (যেমন IA32) সহ একটি আর্কিটেকচারে জেভিএম চালানো সহজ করে তোলে।

ইন Dalvik VM- র internals গুগল ইনপুট / আউটপুট 2008 থেকে Dalvik স্রষ্টা ড্যান Bornstein এর স্লাইড 35 একটি রেজিস্টার ভিত্তিক VM- র চয়নের জন্য নিম্নলিখিত আর্গুমেন্ট দেয় উপস্থাপনার স্লাইড :

নিবন্ধন মেশিন

কেন?

নির্দেশ প্রেরণ এড়ানো

অপ্রয়োজনীয় মেমরি অ্যাক্সেস এড়ানো

নির্দেশের স্ট্রিমটি দক্ষতার সাথে গ্রাস করুন (প্রতি নির্দেশের চেয়ে উচ্চতর ঘনত্ব)

এবং স্লাইড 36:

নিবন্ধন মেশিন

পরিসংখ্যান

30% কম নির্দেশাবলী

35% কম কোড ইউনিট

নির্দেশাবলী স্ট্রিমে আরও 35% বাইট

তবে আমরা একবারে দু'টি গ্রাস করতে পারি

বর্নস্টেইনের মতে এটি "ক্লাস ফাইলগুলির একটি সেটকে ডেক্স ফাইলে রূপান্তর করার সময় আপনি কী খুঁজে পেতে পারেন সেটাই একটি সাধারণ প্রত্যাশা"।

উপস্থাপনা ভিডিওটির প্রাসঙ্গিক অংশটি 25:00 এ শুরু হয় ।

শি এট আল রচিত "ভার্চুয়াল মেশিন শোডাউন: স্ট্যাক ভার্সাস রেজিস্টারস" শীর্ষক একটি অন্তর্দৃষ্টিপূর্ণ কাগজও রয়েছে । (2005) , যা স্ট্যাক- এবং নিবন্ধভিত্তিক ভার্চুয়াল মেশিনের মধ্যে পার্থক্যগুলি আবিষ্কার করে।

Question 4

আমি জানি না কেন সান জেভিএম স্ট্যাক ভিত্তিক করার সিদ্ধান্ত নিয়েছে। ভার্চুয়াল মেশিনটি ত্রুটিযুক্ত, বিএএম কার্য সম্পাদনের কারণে নিবন্ধভুক্ত। এবং ডালভিকও পারফরম্যান্সের কারণে নিবন্ধভুক্ত বলে মনে হচ্ছে।

থেকে প্রো অ্যান্ড্রয়েড 2 :

ডালভিক স্ট্যাকের পরিবর্তে প্রাথমিকভাবে ডেটা স্টোরেজের একক হিসাবে নিবন্ধগুলি ব্যবহার করে। গুগল ফলাফল হিসাবে 30 শতাংশ কম নির্দেশাবলী সম্পন্ন আশা করি।

এবং কোড আকার সম্পর্কিত:

ডালভিক ভিএম উত্পাদিত জাভা ক্লাসের ফাইলগুলি গ্রহণ করে এবং তাদের এক বা একাধিক ডালভিক এক্সিকিউটেবল (.dex) ফাইলে একত্রিত করে। এটি একাধিক শ্রেণীর ফাইল থেকে নকল তথ্য পুনরায় ব্যবহার করে, কার্যকরভাবে স্থানের প্রয়োজনীয়তা (সংকুচিত) traditionalতিহ্যগত .jar ফাইল থেকে অর্ধেকে কমিয়ে দেয়। উদাহরণস্বরূপ, অ্যান্ড্রয়েডে ওয়েব ব্রাউজার অ্যাপ্লিকেশনটির .dex ফাইলটি প্রায় 200k, অন্যদিকে সমতুল্য সঙ্কুচিত .ar সংস্করণটি প্রায় 500k। অ্যালার্ম ঘড়ির .dex ফাইলটি প্রায় 50 কিলোমিটার এবং তার .jar সংস্করণে আকারের দ্বিগুণ।

এবং যেমনটি আমি কম্পিউটার আর্কিটেকচারের কথা স্মরণ করি : একটি পরিমাণগত পদ্ধতিরও এই সিদ্ধান্তে পৌঁছে যে একটি রেজিস্টার মেশিন স্ট্যাক ভিত্তিক মেশিনের চেয়ে আরও ভাল সম্পাদন করে।