एप्लीकेशन वर्चुअलाइजेशन सॉफ्टवेयर की तुलना: Difference between revisions
Line 173: | Line 173: | ||
एक दुभाषिया आभासी निर्देशों से बने कार्यक्रमों को मूल मशीन निर्देशों में संभावित रूप से महंगे संकलन के बिना तुरंत लोड करने और चलाने की अनुमति देता है। कोई भी वर्चुअल मशीन जिसे चलाया जा सकता है, उसकी व्याख्या की जा सकती है, इसलिए यहाँ स्तंभ पदनाम से तात्पर्य है कि क्या डिज़ाइन में कुशल व्याख्या (सामान्य उपयोग के लिए) के प्रावधान सम्मिलित हैं। | एक दुभाषिया आभासी निर्देशों से बने कार्यक्रमों को मूल मशीन निर्देशों में संभावित रूप से महंगे संकलन के बिना तुरंत लोड करने और चलाने की अनुमति देता है। कोई भी वर्चुअल मशीन जिसे चलाया जा सकता है, उसकी व्याख्या की जा सकती है, इसलिए यहाँ स्तंभ पदनाम से तात्पर्य है कि क्या डिज़ाइन में कुशल व्याख्या (सामान्य उपयोग के लिए) के प्रावधान सम्मिलित हैं। | ||
जस्ट-इन-टाइम संकलन ( | जस्ट-इन-टाइम संकलन (जेआईटी), नवीनतम संभव समय पर मूल निर्देशों को संकलित करने की एक विधि को संदर्भित करता है, सामान्यतः कार्यक्रम के चलने से ठीक पहले या उसके दौरान। जेआईटी की चुनौती वर्चुअल मशीन डिज़ाइन की तुलना में कार्यान्वयन की अधिक है, तथापि, आधुनिक डिज़ाइनों ने दक्षता में मदद करने के लिए विचार करना प्रारंभ कर दिया है। सरलतम जेआईटी विधियाँ केवल एक ऑफ़लाइन संकलक के समान एक कोड खंड में संकलित होती हैं। तथापि, अधिक जटिल विधियों को अक्सर नियोजित किया जाता है, जो संकलित कोड अंशों को केवल रनटाइम पर ज्ञात मापदंडों के लिए विशेषज्ञ बनाते हैं ([[अनुकूली अनुकूलन]] देखें)। | ||
अहेड-ऑफ-टाइम संकलन (एओटी) मूल निर्देशों का एक सेट उत्पन्न करने के लिए प्रीकंपलर का उपयोग करने की अधिक क्लासिक विधि को संदर्भित करता है जो प्रोग्राम के रनटाइम के दौरान नहीं बदलता है। क्योंकि आक्रामक संकलन और अनुकूलन में समय लग सकता है, एक पूर्व-संकलित प्रोग्राम एक से अधिक तेजी से लॉन्च हो सकता है जो अकेले जेआईटी पर निष्पादन के लिए निर्भर करता है। JVM के कार्यान्वयन ने इस स्टार्टअप लागत को प्रारंभिक लॉन्च समय की व्याख्या करके कम कर दिया है, जब तक कि JIT द्वारा मूल कोड के टुकड़े उत्पन्न नहीं किए जा सकते। | अहेड-ऑफ-टाइम संकलन (एओटी) मूल निर्देशों का एक सेट उत्पन्न करने के लिए प्रीकंपलर का उपयोग करने की अधिक क्लासिक विधि को संदर्भित करता है जो प्रोग्राम के रनटाइम के दौरान नहीं बदलता है। क्योंकि आक्रामक संकलन और अनुकूलन में समय लग सकता है, एक पूर्व-संकलित प्रोग्राम एक से अधिक तेजी से लॉन्च हो सकता है जो अकेले जेआईटी पर निष्पादन के लिए निर्भर करता है। JVM के कार्यान्वयन ने इस स्टार्टअप लागत को प्रारंभिक लॉन्च समय की व्याख्या करके कम कर दिया है, जब तक कि JIT द्वारा मूल कोड के टुकड़े उत्पन्न नहीं किए जा सकते। |
Revision as of 14:46, 26 February 2023
एप्लिकेशन वर्चुअलाइजेशन सॉफ़्टवेयर एप्लिकेशन आभासी मशीन और उन्हें लागू करने के लिए जिम्मेदार सॉफ़्टवेयर दोनों को संदर्भित करता है। एप्लिकेशन वर्चुअल मशीन का उपयोग सामान्यतः एप्लिकेशन बाईटकोड को कई अलग-अलग कंप्यूटर आर्किटेक्चर और ऑपरेटिंग सिस्टम पर आंशिक रूप से चलाने की अनुमति देने के लिए किया जाता है। एप्लिकेशन सामान्यतः दुभाषिया या जस्ट-इन-टाइम संकलन (जेआईटी) का उपयोग करके कंप्यूटर पर चलाया जाता है। किसी दिए गए वर्चुअल मशीन के अक्सर कई कार्यान्वयन होते हैं, जिनमें से प्रत्येक कार्यों के एक अलग सेट को कवर करता है।
आभासी मशीनों की तुलना
- जावास्क्रिप्ट मशीनें सम्मिलित नहीं हैं। उन्हें खोजने के लिए ईसीएमए स्क्रिप्ट इंजनों की सूची देखें।
यहां दी गई तालिका उन तत्वों को सारांशित करती है जिनके लिए वर्चुअल मशीन डिज़ाइन कुशल होने का इरादा है, न कि किसी कार्यान्वयन में उपस्थित क्षमताओं की सूची।
आभासी मशीन | मशीन मॉडल | स्मृति प्रबंधन | कोड सुरक्षा | दुभाषिया | जेआईटी | एओटी | साझा पुस्तकालय | सामान्य भाषा
वस्तु मॉडल |
गतिशील टाइपिंग |
---|---|---|---|---|---|---|---|---|---|
एंड्रॉइड रनटाइम (एआरटी) | पंजीकृत | स्वचालित | Yes | Yes | Yes | Yes | ? | Yes | Yes |
सामान्य भाषा रनटाइम (सीएलआर) | ढेर | स्वचालित या मैनुअल | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
जिले (नरक) | पंजीकृत | स्वचालित | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
डॉटजीएनयू पोर्टेबल.नेट | ढेर | स्वचालित या मैनुअल | Yes | Yes | Yes | Yes | Yes | Yes | No |
जावा वर्चुअल मशीन (जेवीएम) | ढेर | स्वचालित | Yes | Yes | Yes | Yes | Yes | Yes | Yes[1] |
जाइक्स आरवीएम | ढेर | स्वचालित | Yes | Yes | Yes | Yes | ? | Yes | Yes |
एलएलवीएम | पंजीकृत | मैनुअल | No | Yes | Yes | Yes | Yes | Yes | No |
मोनो | ढेर | स्वचालित या मैनुअल | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
तोता | पंजीकृत | स्वचालित | No | Yes | No[2] | Yes | Yes | Yes | Yes |
डैलविक | पंजीकृत | स्वचालित | Yes | Yes | Yes | No | ? | No | No |
चीख़ | ढेर | स्वचालित | No | Yes | Yes | No | Yes | No | Yes |
बीम (एरलांग) | पंजीकृत | स्वचालित | ? | Yes | Yes | Yes | Yes | Yes | Yes |
मूर वीएम | पंजीकृत | स्वचालित | ? | Yes | Yes | Yes | Yes | Yes | Yes |
वर्चुअल मशीन निर्देश संगणना के एक मुख्य मॉडल का उपयोग करके स्थानीय चर में डेटा को प्रोसेस करते हैं, सामान्यतः स्टैक मशीन, रजिस्टर मशीन या रैंडम एक्सेस मशीन जिसे अक्सर मेमोरी मशीन कहा जाता है। इन तीन तरीकों का उपयोग आभासी मशीनों बनाम भौतिक मशीनों में अलग-अलग ट्रेडऑफ़ से प्रेरित है, जैसे सुरक्षा के लिए व्याख्या, संकलन और सत्यापन में आसानी।
इन पोर्टेबल वर्चुअल मशीनों में मेमोरी प्रबंधन को भौतिक मशीनों की तुलना में उच्च स्तर के अमूर्तता पर संबोधित किया जाता है। कुछ वर्चुअल मशीनें, जैसे कि लोकप्रिय जावा वर्चुअल मशीन (जेवीएम), पतों के साथ इस तरह से जुड़ी होती हैं, जैसे कि वर्चुअल मशीन को पॉइंटर संदर्भों का पता लगाने की अनुमति देकर सुरक्षित स्वचालित मेमोरी प्रबंधन की आवश्यकता होती है, और मैन्युअल रूप से पॉइंटर्स को मेमोरी में बनाने से मशीन के निर्देशों को अस्वीकार कर दिया जाता है। अन्य आभासी मशीनें, जैसे एलएलवीएम, पारंपरिक भौतिक मशीनों की तरह अधिक हैं, जो पॉइंटर्स के प्रत्यक्ष उपयोग और हेरफेर की अनुमति देती हैं। सामान्य मध्यवर्ती भाषा (सीआईएल) मेमोरी के दोनों नियंत्रित उपयोग (जैसे जेवीएम, जो सुरक्षित स्वचालित मेमोरी प्रबंधन की अनुमति देता है) की अनुमति देते हुए बीच में एक हाइब्रिड प्रदान करता है, जबकि एक 'असुरक्षित' मोड की भी अनुमति देता है जो प्रत्यक्ष पॉइंटर हेरफेर को उन तरीकों से अनुमति देता है जो प्रकार का उल्लंघन कर सकते हैं। सीमाएं और अनुमति।
कोड सुरक्षा सामान्यतः पोर्टेबल वर्चुअल मशीन की कोड चलाने की क्षमता को संदर्भित करती है जबकि इसे केवल क्षमताओं का एक निर्धारित सेट प्रदान करती है। उदाहरण के लिए, वर्चुअल मशीन केवल फ़ंक्शन या डेटा के एक निश्चित सेट तक कोड पहुंच की अनुमति दे सकती है। पॉइंटर्स पर वही नियंत्रण जो स्वत: मेमोरी प्रबंधन को संभव बनाता है और वर्चुअल मशीन को टाइपसेफ डेटा एक्सेस सुनिश्चित करने की अनुमति देता है, यह सुनिश्चित करने के लिए उपयोग किया जाता है कि एक कोड खंड केवल मेमोरी के कुछ तत्वों के लिए अनुमति है और वर्चुअल मशीन को बायपास नहीं कर सकता है। अन्य सुरक्षा तंत्रों को फिर कोड सत्यापनकर्ता, स्टैक सत्यापनकर्ता और अन्य विधियों के रूप में शीर्ष पर स्तरित किया जाता है।
एक दुभाषिया आभासी निर्देशों से बने कार्यक्रमों को मूल मशीन निर्देशों में संभावित रूप से महंगे संकलन के बिना तुरंत लोड करने और चलाने की अनुमति देता है। कोई भी वर्चुअल मशीन जिसे चलाया जा सकता है, उसकी व्याख्या की जा सकती है, इसलिए यहाँ स्तंभ पदनाम से तात्पर्य है कि क्या डिज़ाइन में कुशल व्याख्या (सामान्य उपयोग के लिए) के प्रावधान सम्मिलित हैं।
जस्ट-इन-टाइम संकलन (जेआईटी), नवीनतम संभव समय पर मूल निर्देशों को संकलित करने की एक विधि को संदर्भित करता है, सामान्यतः कार्यक्रम के चलने से ठीक पहले या उसके दौरान। जेआईटी की चुनौती वर्चुअल मशीन डिज़ाइन की तुलना में कार्यान्वयन की अधिक है, तथापि, आधुनिक डिज़ाइनों ने दक्षता में मदद करने के लिए विचार करना प्रारंभ कर दिया है। सरलतम जेआईटी विधियाँ केवल एक ऑफ़लाइन संकलक के समान एक कोड खंड में संकलित होती हैं। तथापि, अधिक जटिल विधियों को अक्सर नियोजित किया जाता है, जो संकलित कोड अंशों को केवल रनटाइम पर ज्ञात मापदंडों के लिए विशेषज्ञ बनाते हैं (अनुकूली अनुकूलन देखें)।
अहेड-ऑफ-टाइम संकलन (एओटी) मूल निर्देशों का एक सेट उत्पन्न करने के लिए प्रीकंपलर का उपयोग करने की अधिक क्लासिक विधि को संदर्भित करता है जो प्रोग्राम के रनटाइम के दौरान नहीं बदलता है। क्योंकि आक्रामक संकलन और अनुकूलन में समय लग सकता है, एक पूर्व-संकलित प्रोग्राम एक से अधिक तेजी से लॉन्च हो सकता है जो अकेले जेआईटी पर निष्पादन के लिए निर्भर करता है। JVM के कार्यान्वयन ने इस स्टार्टअप लागत को प्रारंभिक लॉन्च समय की व्याख्या करके कम कर दिया है, जब तक कि JIT द्वारा मूल कोड के टुकड़े उत्पन्न नहीं किए जा सकते।
साझा पुस्तकालय कई चल रहे कार्यक्रमों में देशी कोड के खंडों का पुन: उपयोग करने की सुविधा है। आधुनिक ऑपरेटिंग सिस्टम में, इसका आम तौर पर मतलब होता है कि स्मृति सुरक्षा के माध्यम से एक दूसरे से सुरक्षित विभिन्न प्रक्रियाओं में साझा लाइब्रेरी वाले मेमोरी पेजों को साझा करने के लिए आभासी मेमोरी का उपयोग करना। यह दिलचस्प है कि अनुकूली अनुकूलन जैसे आक्रामक जेआईटी विधियां अक्सर प्रक्रियाओं या प्रोग्राम के लगातार चलने वाले साझा करने के लिए अनुपयुक्त कोड टुकड़े उत्पन्न करती हैं, जिसके लिए प्रीकंपिल्ड और साझा कोड की क्षमता और एडवांटा के बीच व्यापार की आवश्यकता होती है।अनुकूली विशेष कोड के जीईएस। उदाहरण के लिए, CIL के कई डिज़ाइन प्रावधान कुशल साझा पुस्तकालयों की अनुमति देने के लिए मौजूद हैं, संभवतः अधिक विशिष्ट JIT कोड की कीमत पर। ओएस एक्स पर जेवीएम कार्यान्वयन जावा साझा संग्रह का उपयोग करता है[3] साझा पुस्तकालयों के कुछ लाभ प्रदान करने के लिए।
एप्लिकेशन वर्चुअल मशीन कार्यान्वयन की तुलना
ऊपर वर्णित पोर्टेबल वर्चुअल मशीनों के अलावा, वर्चुअल मशीनों का उपयोग अक्सर व्यक्तिगत स्क्रिप्टिंग भाषाओं के निष्पादन मॉडल के रूप में किया जाता है, आमतौर पर दुभाषिया द्वारा। यह तालिका उपरोक्त पोर्टेबल वर्चुअल मशीन और स्क्रिप्टिंग भाषा वर्चुअल मशीन दोनों के विशिष्ट वर्चुअल मशीन कार्यान्वयन को सूचीबद्ध करती है।
Virtual machine | Languages | Comments | Interpreter | JIT | Implementation language | SLoC |
---|---|---|---|---|---|---|
Common Language Runtime (CLR) | C#, C++/CLI, F#, VB.NET | bytecode is CIL; .NET Core Runtime on GitHub | No | Yes | C#, C++ | |
Adobe Flash Player (aka Tamarin) | ActionScript, SWF (file format) | interactive web authoring tool. bytecode is named "ActionScript Byte Code (.abc)" | Yes | Yes | C++ | 135k (initially released) |
Dis (Inferno) | Limbo | Dis Virtual Machine Specification | Yes | Yes | C | 15k + 2850 per JIT arch + 500 per host OS |
DotGNU-Portable.NET | CLI languages including: C# | Common Language Runtime clone | No | Yes | C, C# | |
Forth | Forth | Features are simplified, usually include assembler, compiler, text-level and binary-level interpreters, sometimes editor, debugger and OS. Compiling speeds are >20 SKLOC/S and behave much like JIT. | Yes | No | Forth, Forth Assembler | 2.8K to 5.6K; advanced, professional implementations are smaller. |
Glulx | Inform 6, Inform 7, others | Yes | No | Various implementations exist | ||
HHVM | PHP, Hack | Is an open-source virtual machine designed for executing programs written in Hack and PHP. | Yes | Yes | C++, OCaml | |
Icon | Icon | Base source code provides both the interpreter as well as an unsupported compile-to-C version. The runtime code, that is shared between the compiler and the interpreter, is written in a variant of C called RTT. | Yes | No | C, RTT (a custom front-end to C, provided with the base source for Icon). | ~180k total. (source to bytecode: ~11k, bytecode interpreter: ~46k, iconc: ~23k, common/headers: ~13k, rtt: ~15k) |
JVM | Java, Kotlin, Jython, Groovy, JRuby, C, C++, Clojure, Scala and several others | Reference implementation by Sun ; OpenJDK: code under GPL ; IcedTea: code and tools under GPL | Yes | Yes | JDK, OpenJDK & IcedTea with regular JIT : Java, C, C++, ASM ; IcedTea with the "Zero" JIT : Java, C, C++ | JVM is around 6500k lines; TCK is 80k tests and around 1000k lines |
LLVM | C, C++, Kotlin, Objective-C, Swift, Ada, Fortran, and Rust | MSIL, C and C++ output are supported. ActionScript Byte Code output is supported by Adobe Alchemy. bytecode is named "LLVM Bytecode (.bc)". assembly is named "LLVM Assembly Language (*.ll)". | Yes | Yes | C++ | 811k [4] |
Lua | Lua | Yes | LuaJIT | C | 13k + 7k LuaJIT | |
MMIX | MMIXAL | |||||
Mono | CLI languages including: C#, VB.NET, IronPython, IronRuby, and others | Common Language Runtime clone | Yes | Yes | C#, C | 2332k |
NekoVM | currently Neko and Haxe | Yes | x86 only | C | 46k | |
Oz | Oz, Alice | |||||
O-code machine | BCPL | |||||
p-code machine | Pascal | UCSD Pascal, widespread in late 70s including Apple II | Yes | No | assembly, Pascal | |
Parrot | Perl 5, Raku, NQP-rx, PIR, PASM, PBC, BASIC, bc, C99, ECMAScript, Lisp, Lua, m4, Tcl, WMLScript, XML, and others | Yes | Yes | C, Perl | 111k C, 240k Perl | |
Perl virtual machine | Perl | op-code tree walker | Yes | No | C, Perl | 175k C, 9k Perl |
CPython | Python | Yes | C | 387k C, 368k Python, 10k ASM, 31k Psyco | ||
PyPy | Python | Self-hosting implementation of Python, next generation of Psyco | Yes | Yes | Python | |
Rubinius | Ruby | Virtual machine for another Ruby implementation | Yes | Yes | C++, Ruby | |
Silverlight | C#, VB.NET | A Micro-version of Microsoft .NET Framework to let applications run sandboxed inside browser | Yes | Yes | C++ | 7MB (initially released) |
ScummVM | Scumm | Computer game engine | ||||
SECD | ISWIM, Lispkit Lisp | |||||
Squirrel | Squirrel | Yes | Squirrel_JIT | C++ | 12k | |
Smalltalk | Smalltalk | |||||
SQLite | SQLite opcodes | Virtual database engine | ||||
Squeak | Squeak Smalltalk | Self hosting implementation of Squeak virtual machine. Rich multi-media support. | Yes | Cog & Exupery | Smalltalk/Slang | 110k Smalltalk, ~300K C |
SWI-Prolog | Prolog: SWI-Prolog, YAP | Yes | No | C, SWI-Prolog | ||
TraceMonkey | JavaScript | Based on Tamarin | No | Yes | C++ | 173k |
TrueType | TrueType | Font rendering engine | Yes | No | C (typically) | |
Valgrind | x86/x86-64 binaries | Checking of memory accesses and leaks under Linux | C | 467k [5] | ||
VisualWorks | Smalltalk | No | Yes | C | ||
Vx32 virtual machine | x86 binaries | Application-level virtualization for native code | No | Yes | ||
Waba | Virtual machine for small devices, similar to Java | |||||
Yet Another Ruby VM (YARV) | Ruby | Virtual machine of the reference implementation for Ruby 1.9 and newer versions | Yes | Yes | C | |
Z-machine | Z-Code | |||||
Zend Engine | PHP | Yes | No | C | 75k |
यह भी देखें
- आवेदन वर्चुअलाइजेशन
- भाषा बंधन
- विदेशी फ़ंक्शन इंटरफ़ेस
- कॉलिंग कन्वेंशन
- नाम मंगलिंग
- अप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई)
- अनुप्रयोग बाइनरी इंटरफ़ेस (एबीआई)
- [[अनुप्रयोग वर्चुअलाइजेशन सॉफ्टवेयर की तुलना]]
- ईसीएमएस्क्रिप्ट इंजनों की सूची
- वेब असेंबली
संदर्भ
- ↑ "The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 292". Jcp.org. Retrieved 2013-07-04.
- ↑ "JITRewrite – Parrot". Trac.parrot.org. Retrieved 2013-07-04.
- ↑ Apple docs on OS X use of Java Shared Archive
- ↑ The LLVM Compiler Infrastructure, ohloh.net, 2011 Nov 30
- ↑ Valgrind, ohloh.net, 2011 Nov 30.