جافا الافتراضية آلة CLR

Question

كنوع من متابعة مسألة يسمى الاختلافات بين MSIL و جافا بايت كود?, ما هو (أهم) الاختلاف أو التشابه في كيفية آلة جافا الافتراضية يعمل مقابل كيف .NET Framework وقت تشغيل اللغة العامة (CLR) يعمل ؟

أيضا ، .NET framework CLR a "الجهاز الظاهري" أو أنها لا تملك سمات الجهاز الظاهري ؟

Answer 1

هناك الكثير من أوجه التشابه بين كل من تطبيقات (و في رأيي:نعم, أنهم كل من "الظاهرية").

من أجل شيء واحد كلاهما كومة القائم على VM ، مع عدم وجود مفهوم "سجلات" كما اعتدنا أن نرى في الحديث مثل وحدة المعالجة المركزية x86 أو PowerPC.تقييم جميع عبارات ((1 + 1) / 2) تتم عن طريق دفع المعاملات على "كومة" ثم ظهرت تلك المعاملات خارج المكدس كلما تعليمات (إضافة, تقسيم, الخ) يجب أن تستهلك تلك المعاملات.كل التعليمات يدفع نتائجها تعود إلى المكدس.

انها وسيلة مريحة لتنفيذ الجهاز الظاهري ، لأن كل وحدة المعالجة المركزية في العالم لديه كومة ، ولكن عدد السجلات في كثير من الأحيان مختلفة (وبعض السجلات لأغراض خاصة و كل التعليمات تتوقع المعاملات في سجلات مختلفة ، إلخ).

لذا ، إذا كنت تريد الذهاب إلى نموذج مجردة آلة بحتة كومة على أساس النموذج هو وسيلة جيدة للذهاب.

بالطبع الحقيقي الأجهزة لا تعمل بهذه الطريقة.حتى JIT هو المسؤول عن أداء "enregistration" من بايت كود عمليات أساسا جدولة وحدة المعالجة المركزية الفعلية سجلات تحتوي على المعاملات و النتائج كلما كان ذلك ممكنا.

لذا أعتقد أن هذا هو واحد من أكبر القواسم المشتركة بين CLR و JVM.

أما عن الخلافات...

واحدة مثيرة للاهتمام الفرق بين اثنين من تطبيقات هذا CLR يتضمن إرشادات حول إنشاء أنواع عامة ، ومن ثم تطبيق حدودي التخصصات إلى تلك الأنواع.حتى في وقت التشغيل ، CLR ترى قائمة<int> أن يكون نوع مختلف تماما من قائمة<String>.

تحت الأغطية ، فإنه يستخدم نفس MSIL على كل إشارة من نوع التخصصات (حتى قائمة<String> يستخدم نفس التنفيذ قائمة<Object>مع نوع مختلف-يلقي في API حدود) ، ولكن كل قيمة من نوع يستخدم فريدة من نوعها تنفيذ (قائمة<int> يولد مختلفة تماما رمز من القائمة<double>).

في جاوة ، أنواع عامة هي محض مترجم خدعة.JVM لديه أي فكرة من الذي الطبقات نوع الحجج و هو غير قادر على أداء حدودي التخصصات في وقت التشغيل.

من منظور عملي ، وهذا يعني أنك لا يمكن أن تفرط جافا الطرق على الأنواع العامة.لا يمكن أن يكون اثنين من أساليب مختلفة مع نفس الاسم ، واختلاف فقط على ما إذا كانت تقبل قائمة<String> أو قائمة<Date>.بالطبع, منذ CLR يعرف عن حدودي أنواع ، ليس لديها أي مشكلة في التعامل مع أساليب طاقتها على نوع عام التخصصات.

في يوم ما, هذا هو الفرق الذي ألاحظ أكثر بين CLR ، JVM.

غيرها من الاختلافات الهامة تشمل:

• CLR وقد الإغلاق (تنفذ C# المندوبين).JVM لا يدعم الإغلاق فقط منذ جافا 8.

• CLR وقد coroutines (تنفذ مع C# 'المحصول' الكلمة).JVM لا.

• CLR يسمح رمز المستخدم لتحديد القيمة الجديدة أنواع (البنيات) ، بينما توفر JVM ثابت عن مجموعة من أنواع قيمة (بايت, قصيرة, int, طويل, float, double, char, منطقية) و يسمح فقط للمستخدمين تحديد مرجعية جديدة-أنواع (الطبقات).

• CLR يوفر الدعم معلنا والتلاعب المؤشرات.هذا هو مثيرة للاهتمام خصوصا لأن كلا JVM و CLR توظيف صارمة الأجيال ضغط القمامة جامع تطبيقات مثل إدارة الذاكرة الاستراتيجية.تحت الظروف العادية ، صارمة ضغط GC لديه الوقت الصعب حقا مع مؤشرات ، لأن عند نقل القيمة من موقع الذاكرة إلى آخر ، كل المؤشرات (و المؤشرات إلى مؤشرات) تصبح غير صالحة.ولكن CLR يوفر "تعلق" آلية بحيث يمكن للمطورين تعلن كتلة من التعليمات البرمجية التي CLR لا يجوز نقل بعض المؤشرات.انها مريحة جدا.

• أكبر وحدة من التعليمات البرمجية في JVM إما 'حزمة' بدليل 'المحمية' الكلمة أو القول جرة (أيجافا أرشيف) كما يتضح من كونها قادرة على تحديد جرة في classpath و قد تعامل مثل مجلد من التعليمات البرمجية.في CLR, دروس مجمعة في الجمعيات ، CLR يوفر منطق التفكير حول والتلاعب الجمعيات (التي يتم تحميلها في "AppDomains" ، وتوفير الفرعية على مستوى التطبيق المرامل على تخصيص الذاكرة و تنفيذ التعليمات البرمجية).

• CLR بايت كود شكل (التي تتألف من MSIL التعليمات الفوقية) أقل التعليمات أنواع من JVM.في JVM كل عملية فريدة من نوعها (إضافة اثنين الباحث القيم ، إضافة إلى اثنين تطفو القيم ، الخ) فريدة من نوعها التعليمات.في CLR كل MSIL تعليمات متعددة الأشكال (إضافة قيمتين) و JIT هو المسؤول عن تحديد أنواع المعاملات وخلق المناسبة رمز الجهاز.أنا لا أعرف الذي هو يفضل أن تكون استراتيجية ، على الرغم من.كلاهما المفاضلة.نقطة ساخنة مترجم JIT ، JVM ، يمكن استخدام أبسط رمز الجيل آلية (أنها لا تحتاج إلى تحديد المعامل أنواع لأنهم بالفعل المشفرة في التعليمات) ، ولكن هذا يعني أنه يحتاج أكثر تعقيدا بايت كود تنسيق, مع المزيد من التعليمات أنواع.

لقد تم استخدام جافا (والاعجاب JVM) لمدة عشر سنوات الآن.

ولكن في رأيي CLR الآن متفوقة في كل شيء تقريبا.

Answer 2

السؤال الأول هو مقارنة JVM مع .الإطار الصافي - أفترض أنك قصدت مقارنة مع CLR بدلا من ذلك.إذا كنت تعتقد أنك يمكن أن يكتب كتاب صغير على هذا (تحرير: يبدو بنجي بالفعل :-)

فارق واحد مهم هو أن CLR مصممة لتكون لغة محايدة العمارة ، على عكس JVM.

فرق آخر مهم هو أن CLR تم تصميمه خصيصا للسماح مستوى عال من التشغيل البيني مع التعليمات البرمجية الأصلية.وهذا يعني أن CLR أن إدارة الموثوقية والأمن عند الأم ذاكرة الوصول إليها وتعديلها, و أيضا إدارة التنظيم بين CLR-بناء هياكل البيانات الأصلية هياكل البيانات.

للإجابة على السؤال الثاني ، فإن مصطلح "الجهاز الظاهري" هو أقدم من الأجهزة العالمية (مثلا ، IBM الافتراضية 360 في 1960s) التي كانت تعني البرمجيات/الأجهزة مضاهاة الجهاز الأساسي لتحقيق نفس النوع من الأشياء التي VMWare لا.

CLR غالبا ما يشار إليها باعتبارها "تنفيذ المحرك".في هذا السياق ، أن تنفيذ IL الجهاز على رأس x86.وهذا هو أيضا ما JVM ، على الرغم من أنه يمكن القول بأن هناك فارق هام بين CLR متعددة الأشكال bytecodes و JVM ما كتبته bytecodes.

حتى متحذلق الجواب على سؤالك الثاني هو "لا".ولكن الأمر في الواقع إلى كيفية تعريف هذين المصطلحين.

تحرير: أحد أكثر الفرق بين JVM CLR أن JVM (الإصدار 6) مترددة جدا إلى الإفراج عن تخصيص الذاكرة مرة أخرى إلى نظام التشغيل ، حتى حيث أنها يمكن أن.

على سبيل المثال, دعونا نقول أن JVM تبدأ العملية و يخصص 25 ميغابايت من الذاكرة من نظام التشغيل في البداية.التطبيق البرمجية ثم محاولات المخصصات التي تتطلب 50 ميغابايت إضافية.JVM سيتم تخصيص 50 ميغابايت إضافية من نظام التشغيل.مرة واحدة على رمز التطبيق قد توقفت عن استخدام تلك الذاكرة ، فمن القمامة التي تم جمعها JVM حجم كومة الذاكرة المؤقتة نقصان.ومع ذلك ، JVM فقط مجانا على تخصيص نظام التشغيل الذاكرة تحت بعض ظروف محددة للغاية ، .وإلا لبقية عملية عمر أن الذاكرة تبقى المخصصة.

CLR ، من ناحية أخرى ، النشرات الذاكرة المخصصة إلى نظام التشغيل إذا لم يعد هناك حاجة.في المثال أعلاه ، CLR قد صدر الذاكرة مرة واحدة كومة قد انخفض.

Answer 3

المزيد من التفاصيل على الاختلافات يمكن العثور عليها في مختلف الأكاديمية والخاصة.مرة واحدة على CLR خيارات التصميم.

بعض الأمثلة على ذلك:

• بعض مستوى منخفض opperands يتم كتابة مثل "إضافة إلى اثنين من رجات" حيث CLR يستخدم متعدد الأشكال المعامل.(أيfadd/iadd/لاد مقابل فقط إضافة)
• حاليا ، JVM لا أكثر عدوانية وقت التنميط الأمثل (أينقطة ساخنة).CLR حاليا لا جيت التحسينات ، ولكن ليس وقت التشغيل الأمثل (أياستبدال التعليمات البرمجية في حين كنت تعمل).
• CLR لا مضمنة طرق افتراضية ، JVM لا...
• دعم أنواع قيمة في CLR أبعد من مجرد "الأوليات".

Answer 4

ووCLR وJVM على حد سواء الأجهزة الظاهرية.

وو.NET Framework و بيئة جافا هي تجميع للنظام رصد السفن المعنية ومكتباتها. بدون مكتبات نظام رصد السفن غير مجدية جدا.

Answer 5

وليس من جهاز ظاهري، والإطار الصافي يجمع المجالس إلى ثنائي الأصلي في وقت الجولة الأولى:

في الحوسبة، ترجمة في الوقت المناسب (JIT)، المعروف أيضا باسم الترجمة الدينامية، هي تقنية لتحسين أداء وقت التشغيل من برنامج كمبيوتر. يبني JIT على فكرتين السابقة في بيئات وقت التشغيل: تجميع بايت كود وتجميع الحيوية. كان تحويل رمز وقت مسبق لتنفيذ المشروع أصلا، على سبيل المثال بايت كود إلى رمز الجهاز الأصلي. تحسين الأداء خلال مترجمين تنبع من التخزين المؤقت نتائج ترجمة كتل من التعليمات البرمجية، وليس مجرد إعادة تقييم كل سطر أو المعامل في كل مرة يتحقق ذلك (انظر تفسير اللغة). كما أن لديها مزايا أكثر من تجميع ثابت رمز في وقت التطوير، كما أنه يمكن إعادة ترجمة التعليمات البرمجية إذا كان هذا وجدت لتكون مفيدة، ويمكن أن تكون قادرة على فرض ضمانات أمنية. وهكذا JIT يمكن الجمع بين بعض من مزايا تفسير وثابت (قبل من الوقت) تجميع.

والعديد من بيئات وقت التشغيل الحديثة، مثل الإطار مايكروسوفت .NET، معظم تطبيقات جافا، وآخرها أكشن 3، تعتمد على تجميع JIT بتنفيذ التعليمات البرمجية عالية السرعة.

المصدر: http://en.wikipedia.org/wiki/Just-in -time_compilation

وإضافة ما يصل صافي الإطار يحتوي على الجهاز الظاهري، تماما مثل جافا.