Android 8.0 রিলিজের মাধ্যমে Android রানটাইম (ART) উল্লেখযোগ্যভাবে উন্নত করা হয়েছে। নিচে দেওয়া তালিকা থেকে ডিভাইস প্রস্তুতকারকরা ART-তে কী কী উন্নতি আশা করতে পারেন তার একটি সংক্ষিপ্তসার পাবেন।
Concurrent compacting garbage collector
Google I/O-তে ঘোষণা করা হয়েছে যে, Android 8.0-তে ART-তে নতুন কনকারেন্ট কম্প্যাক্টিং গার্বেজ কালেক্টর (GC) ফিচার আছে। এই কালেক্টর প্রতিবার GC রান করার সময় এবং অ্যাপ রান করার সময় হিপকে কম্প্যাক্ট করে, থ্রেড রুট প্রসেস করার জন্য শুধুমাত্র একটি ছোট পজ নেয়। এর সুবিধাগুলি এখানে দেওয়া হল:
- GC সবসময় হিপ কম্প্যাক্ট করে: Android 7.0-এর তুলনায় গড়ে ৩২% ছোট হিপ সাইজ।
- কম্প্যাকশন থ্রেড লোকাল বাম্প পয়েন্টার অবজেক্ট অ্যালোকেশন চালু করে: অ্যালোকেশন Android 7.0-এর তুলনায় ৭০% দ্রুত হয়।
- Android 7.0 GC-এর তুলনায় H2 বেঞ্চমার্কের জন্য ৮৫% কম পজ টাইম অফার করে।
- হিপ সাইজের সাথে পজ টাইম আর স্কেল করা হয় না; অ্যাপগুলি এখন জ্যাঙ্ক নিয়ে চিন্তা না করেই বড় হিপ ব্যবহার করতে পারবে।
- GC প্রয়োগের বিবরণ - রিড ব্যারিয়ার:
- রিড ব্যারিয়ার হল প্রতিটি অবজেক্ট ফিল্ড রিডের জন্য করা কাজের একটি ছোট অংশ।
- এগুলি কম্পাইলারে অপ্টিমাইজ করা হয়, তবে কিছু ব্যবহারের ক্ষেত্রে এগুলি ধীরগতির হতে পারে।
লুপ অপ্টিমাইজেশন
Android 8.0 রিলিজে ART-এর মাধ্যমে বিভিন্ন ধরনের লুপ অপ্টিমাইজেশন করা হয়েছে:
- Bounds check eliminations
- স্ট্যাটিক: কম্পাইল-টাইমে রেঞ্জ সীমার মধ্যে আছে বলে প্রমাণিত হয়
- ডায়নামিক: রান-টাইম টেস্ট নিশ্চিত করে যে লুপগুলি সীমার মধ্যে আছে (অন্যথায় ডিঅপ্টিমাইজ করা হয়)
- ইনডাকশন ভেরিয়েবল এলিমিনেশন
- ডেড ইন্ডাকশন সরানো
- ক্লোজড-ফর্ম এক্সপ্রেশন দ্বারা লুপের পরে ব্যবহৃত ইন্ডাকশন পরিবর্তন করুন এক্সপ্রেশন
- লুপ-বডির মধ্যে ডেড কোড এলিমিনেশন, সম্পূর্ণ লুপ সরিয়ে দেওয়া যা ডেড হয়ে গেছে
- শক্তি কমে যাওয়া
- লুপ ট্রান্সফর্মেশন: রিভার্সাল, ইন্টারচেঞ্জিং, স্প্লিটিং, আনরোলিং, ইউনিমডুলার ইত্যাদি।
- SIMDization (ভেক্টরাইজেশনও বলা হয়)
লুপ অপ্টিমাইজার ART কম্পাইলারে নিজস্ব অপ্টিমাইজেশন পাসে থাকে। বেশিরভাগ লুপ অপ্টিমাইজেশন হল অপ্টিমাইজেশন ও সরলীকরণের মতো। কিছু অপ্টিমাইজেশনের ক্ষেত্রে সমস্যা দেখা দেয়, কারণ সেগুলি CFG-কে অত্যন্ত বিস্তারিতভাবে রিরাইট করে। বেশিরভাগ CFG ইউটিলিটি (nodes.h দেখুন) CFG তৈরি করার উপর ফোকাস করে, রিরাইট করার উপর নয়।
ক্লাস হায়ারার্কি বিশ্লেষণ
Android 8.0-এ ART ক্লাস হায়ারার্কি অ্যানালিসিস (CHA) ব্যবহার করে, এটি একটি কম্পাইলার অপ্টিমাইজেশন যা ক্লাস হায়ারার্কি বিশ্লেষণ করে তৈরি করা তথ্যের উপর ভিত্তি করে ভার্চুয়াল কলগুলিকে সরাসরি কলে ডেভার্চুয়ালাইজ করে। ভার্চুয়াল কল অনেক ব্যয়বহুল কারণ এগুলি vtable লুকআপের মাধ্যমে প্রয়োগ করা হয় এবং এগুলি নির্ভরশীল লোড নেয়। এছাড়াও, ভার্চুয়াল কল ইনলাইন করা যায় না।
সম্পর্কিত উন্নতির সারসংক্ষেপ এখানে দেওয়া হল:
- ডায়নামিক সিঙ্গল-ইমপ্লিমেন্টেশন পদ্ধতির স্ট্যাটাস আপডেট করা - ক্লাস লিঙ্ক করার সময় শেষে, vtable পূরণ করা হয়ে গেলে, ART সুপার ক্লাসের vtable-এর সাথে এন্ট্রি-বাই-এন্ট্রি তুলনা করে।
- কম্পাইলার অপ্টিমাইজেশন - কম্পাইলার কোনও পদ্ধতির সিঙ্গেল-ইমপ্লিমেন্টেশন সংক্রান্ত তথ্য ব্যবহার করবে। কোনও মেথড A.foo-এর সিঙ্গেল-ইমপ্লিমেন্টেশন ফ্ল্যাগ সেট করা থাকলে, কম্পাইলার ভার্চুয়াল কলকে ডাইরেক্ট কলে ডিভার্চুয়ালাইজ করবে এবং এর ফলে ডাইরেক্ট কলকে ইনলাইন করার চেষ্টা করবে।
- কম্পাইল করা কোড বাতিল করা - এছাড়াও ক্লাস লিঙ্ক করার সময় শেষে যখন সিঙ্গেল-ইমপ্লিমেন্টেশন তথ্য আপডেট করা হয়, যদি পদ্ধতি A.foo-তে আগে সিঙ্গেল-ইমপ্লিমেন্টেশন ছিল কিন্তু সেই স্ট্যাটাস এখন বাতিল করা হয়েছে, তাহলে সমস্ত কম্পাইল করা কোড যা এই অনুমানের উপর নির্ভর করে যে পদ্ধতি A.foo-তে সিঙ্গেল-ইমপ্লিমেন্টেশন আছে তাদের কম্পাইল করা কোড বাতিল করতে হবে।
- ডিপ্টিমাইজেশন - স্ট্যাকে থাকা লাইভ কম্পাইল করা কোডের জন্য, ডিপ্টিমাইজেশন শুরু করা হবে যাতে ভুল কম্পাইল করা কোডকে ইন্টারপ্রেটার মোডে বাধ্য করা যায় এবং সঠিকতা নিশ্চিত করা যায়। ডিপ্টিমাইজেশনের একটি নতুন মেকানিজম ব্যবহার করা হবে যা হল সিনক্রোনাস ও অ্যাসিনক্রোনাস ডিপ্টিমাইজেশনের হাইব্রিড।
.oat ফাইলে ইনলাইন ক্যাশে
ART এখন ইনলাইন ক্যাশে ব্যবহার করে এবং কল সাইট অপ্টিমাইজ করে যার জন্য পর্যাপ্ত ডেটা আছে। ইনলাইন ক্যাশে ফিচার প্রোফাইলে অতিরিক্ত রানটাইম তথ্য রেকর্ড করে এবং এটি ব্যবহার করে আগে থেকে কম্পাইলেশনের জন্য ডায়নামিক অপ্টিমাইজেশন যোগ করে।
Dexlayout
Dexlayout হল Android 8.0-এ চালু করা একটি লাইব্রেরি যা dex ফাইল বিশ্লেষণ করে এবং প্রোফাইল অনুযায়ী সেগুলি আবার সাজায়। Dexlayout-এর লক্ষ্য হল ডিভাইসে আইডল মেইনটেন্যান্স কম্পাইলেশনের সময় dex ফাইলের বিভাগগুলি আবার সাজাতে রানটাইম প্রোফাইলিং তথ্য ব্যবহার করা। dex ফাইলের সেইসব অংশকে একসাথে গ্রুপ করে যেগুলি প্রায়ই একসাথে অ্যাক্সেস করা হয়, প্রোগ্রামগুলি উন্নত লোকালিটি থেকে আরও ভালো মেমরি অ্যাক্সেস প্যাটার্ন পেতে পারে, এর ফলে RAM সেভ হয় এবং স্টার্ট-আপ টাইম কমে যায়।
যেহেতু প্রোফাইল সংক্রান্ত তথ্য বর্তমানে অ্যাপ চালানোর পরেই উপলভ্য হয়, তাই dexlayout, dex2oat-এর অন-ডিভাইস কম্পাইলেশনের সাথে ইন্টিগ্রেট করা হয়, যা ডিভাইস যখন আইডল মোডে থাকে তখন পরিচালিত হয়।
Dex ক্যাশে সরানো
Android 7.0 পর্যন্ত, DexCache অবজেক্টে চারটি বড় অ্যারে থাকে, যা DexFile-এর নির্দিষ্ট এলিমেন্টের সংখ্যার অনুপাতে থাকে, যেমন:
- স্ট্রিং (DexFile::StringId পিছু একটি রেফারেন্স),
- প্রকার (DexFile::TypeId প্রতি একটি রেফারেন্স),
- পদ্ধতি (প্রতি DexFile::MethodId-এর জন্য একটি নেটিভ পয়েন্টার),
- ফিল্ড (প্রতিটি DexFile::FieldId-এর জন্য একটি নেটিভ পয়েন্টার)।
আগে সমাধান করা অবজেক্ট দ্রুত রিট্রিভ করার জন্য এইসব অ্যারে ব্যবহার করা হয়েছে। Android 8.0-তে, মেথড অ্যারে ছাড়া সব অ্যারে সরিয়ে দেওয়া হয়েছে।
দোভাষীর পারফর্ম্যান্স
Android 7.0 রিলিজের সাথে ইন্টারপ্রেটর পারফর্ম্যান্স উল্লেখযোগ্যভাবে উন্নত হয়েছে। "mterp" - অ্যাসেম্বলি ভাষায় লেখা একটি কোর ফেচ/ডিকোড/ইন্টারপ্রেট মেকানিজম ফিচার করা ইন্টারপ্রেটর - এর মাধ্যমে এটি সম্ভব হয়েছে। Mterp হল দ্রুত Dalvik ইন্টারপ্রেটারের মডেল এবং এটি arm, arm64, x86, x86_64, mips ও mips64-এর সাথে কাজ করে। কম্পিউটেশনাল কোডের জন্য, Art-এর mterp মোটামুটিভাবে Dalvik-এর ফাস্ট ইন্টারপ্রেটারের সাথে তুলনীয়। তবে, কিছু পরিস্থিতিতে এটি অনেক বেশি - এমনকি নাটকীয়ভাবে - ধীরে হতে পারে:
- পারফর্ম্যান্স ইনভোক করুন।
- স্ট্রিং ম্যানিপুলেশন এবং Dalvik-এ ইন্ট্রিনসিক হিসেবে পরিচিত পদ্ধতির অন্যান্য হেভি ব্যবহারকারী।
- স্ট্যাক মেমরি বেশি ব্যবহার করা।
Android 8.0-এ এই সমস্যাগুলি সমাধান করা হয়েছে।
আরও ইনলাইনিং
Android 6.0 থেকে, ART একই dex ফাইলের মধ্যে যেকোনও কল ইনলাইন করতে পারে, কিন্তু শুধুমাত্র আলাদা dex ফাইল থেকে লিফ মেথড ইনলাইন করতে পারে। এই সীমাবদ্ধতার দুটি কারণ ছিল:
- অন্য dex ফাইল থেকে ইনলাইন করার জন্য সেই অন্য dex ফাইলের dex ক্যাশে ব্যবহার করতে হয়। এটি একই dex ফাইল ইনলাইন করার মতো নয়, যেখানে শুধু কলারের dex ক্যাশে আবার ব্যবহার করা যায়। স্ট্যাটিক কল, স্ট্রিং লোড বা ক্লাস লোডের মতো কয়েকটি নির্দেশের জন্য কম্পাইল করা কোডে dex ক্যাশে প্রয়োজন।
- স্ট্যাক ম্যাপ শুধুমাত্র বর্তমান dex ফাইলের মধ্যে একটি মেথড ইন্ডেক্স এনকোড করছে।
এইসব সীমাবদ্ধতা দূর করতে, Android 8.0:
- কম্পাইল করা কোড থেকে dex ক্যাশে অ্যাক্সেস সরিয়ে দেয় (এছাড়াও, "Dex ক্যাশে সরিয়ে দেওয়া" বিভাগ দেখুন)
- স্ট্যাক ম্যাপ এনকোডিং এক্সটেন্ড করে।
সিঙ্ক্রোনাইজেশন সংক্রান্ত উন্নতি
ART টিম MonitorEnter/MonitorExit কোড পাথ টিউন করেছে এবং ARMv8-এ আমাদের ঐতিহ্যবাহী মেমরি ব্যারিয়ারের উপর নির্ভরতা কমিয়েছে, যেখানে সম্ভব সেখানে সেগুলিকে নতুন (অ্যাকোয়ার/রিলিজ) নির্দেশাবলী দিয়ে প্রতিস্থাপন করেছে।
আরও দ্রুত নেটিভ পদ্ধতি
@FastNative এবং @CriticalNative অ্যানোটেশন ব্যবহার করে Java Native Interface (JNI)-এ আরও দ্রুত নেটিভ কল উপলভ্য আছে।
এইসব বিল্ট-ইন ART রানটাইম
অপ্টিমাইজেশন JNI ট্রানজিশন দ্রুত করে এবং এখন আর ব্যবহার করা হয় না এমন
!bang JNI নোটেশন পাল্টে দেয়। অ্যানোটেশনগুলি নন-নেটিভ
মেথডের উপর কোনও প্রভাব ফেলে না এবং শুধুমাত্র প্ল্যাটফর্মের জাভা ল্যাঙ্গুয়েজ কোডের জন্য উপলভ্য
bootclasspath (Play Store আপডেট নেই)।
@FastNative অ্যানোটেশন নন-স্ট্যাটিক পদ্ধতিতে কাজ করে। কোনও পদ্ধতি প্যারামিটার বা রিটার্ন ভ্যালু হিসেবে jobject অ্যাক্সেস করলে, এটি ব্যবহার করুন।
@CriticalNative অ্যানোটেশন নেটিভ পদ্ধতি চালানোর আরও দ্রুত উপায় প্রদান করে, তবে নিম্নলিখিত বিধিনিষেধ সহ:
-
মেথডকে অবশ্যই স্ট্যাটিক হতে হবে—প্যারামিটার, রিটার্ন ভ্যালু বা
ইমপ্লিসিট
this-এর জন্য কোনও অবজেক্ট নয়। - নেটিভ পদ্ধতিতে শুধুমাত্র আদিম ধরনের ডেটা পাস করা হয়।
-
নেটিভ মেথড তার ফাংশন ডেফিনিশনে
JNIEnvএবংjclassপ্যারামিটার ব্যবহার করে না। -
ডায়নামিক JNI লিঙ্কিংয়ের উপর নির্ভর না করে,
RegisterNatives-এর সাথে পদ্ধতিটি রেজিস্টার করতে হবে।
@FastNative নেটিভ পদ্ধতির পারফর্ম্যান্স ৩ গুণ পর্যন্ত এবং
@CriticalNative ৫ গুণ পর্যন্ত উন্নত করতে পারে। যেমন, Nexus 6P ডিভাইসে পরিমাপ করা JNI ট্রানজিশন:
| Java Native Interface (JNI) ইনভোকেশন | এক্সিকিউশন টাইম (ন্যানোসেকেন্ডে) |
|---|---|
| রেগুলার JNI | 115 |
| !bang JNI | ৬০ |
@FastNative |
৩৫ |
@CriticalNative |
25 |