JVM 스택 기반 및 Dalvik VM 레지스터 기반 이유는 무엇입니까?

궁금합니다. Sun이 JVM 스택 기반을 만들기로 결정하고 Google이 DalvikVM 레지스터 기반을 만들기로 결정한 이유는 무엇입니까?

JVM은 플랫폼 독립적이어야하므로 대상 플랫폼에서 특정 수의 레지스터를 사용할 수 있다고 실제로 가정 할 수 없다고 가정합니다. 따라서 JIT 컴파일러에 대한 레지스터 할당 등을 연기합니다. (틀 렸으면 말해줘.)

그래서 Android 직원들은 "이건 비효율적입니다. 즉시 레지스터 기반 VM을 사용합시다 ..."라고 생각 했습니까? 하지만 잠깐, 여러 다른 안드로이드 기기가 있는데, Dalvik은 몇 개의 레지스터를 목표로 했나요? Dalvik opcode는 특정 수의 레지스터에 대해 하드 코딩됩니까?

현재 시장에 나와있는 모든 Android 장치에 거의 동일한 수의 레지스터가 있습니까? 또는 dex-loading 중에 레지스터 재 할당이 수행됩니까? 이 모든 것이 어떻게 결합됩니까?

Java의 설계 목표에 잘 맞는 스택 기반 VM의 몇 가지 속성이 있습니다.

1. 스택 기반 설계는 대상 하드웨어 (레지스터, CPU 기능)에 대한 가정을 거의하지 않으므로 다양한 하드웨어에서 VM을 쉽게 구현할 수 있습니다.

2. 명령어의 피연산자는 대부분 암시 적이므로 개체 코드는 더 작은 경향이 있습니다. 느린 네트워크 링크를 통해 코드를 다운로드하려는 경우 중요합니다.

레지스터 기반 체계를 사용한다는 것은 아마도 Dalvik의 코드 생성기가 성능이 뛰어난 코드를 생성하기 위해 열심히 일할 필요가 없음을 의미합니다. 레지스터가 매우 풍부하거나 레지스터가 부족한 아키텍처에서 실행하면 Dalvik이 핸디캡을받을 수 있지만 일반적인 목표는 아닙니다. ARM은 매우 중간 수준의 아키텍처입니다.

Dalvik의 초기 버전에는 JIT가 전혀 포함되어 있지 않다는 것도 잊었습니다. 지침을 직접 해석하려는 경우 레지스터 기반 체계가 해석 성능에서 승자가 될 수 있습니다.

참조를 찾을 수 없지만, Sun은 레지스터가 적은 아키텍처 (예 : IA32)에서 JVM을 쉽게 실행할 수 있도록 스택 기반 바이트 코드 접근 방식을 선택했다고 생각합니다.

에서 달빅 VM 내부 구조 구글 I / O 2008에서, 달빅 작성자 댄 스틴은 의 슬라이드 (35)에 레지스터 기반 VM을 선택하는 다음 인수 제공 프리젠 테이션 슬라이드를 :

기계 등록

왜?

• 지시 파견을 피하십시오
• 불필요한 메모리 액세스 방지
• 명령 스트림을 효율적으로 사용 (명령 당 의미 밀도가 높음)

그리고 슬라이드 36에서 :

기계 등록

통계

• 지침 30 % 감소
• 코드 단위 35 % 감소
• 지침 스트림에서 35 % 더 많은 바이트
  • 하지만 한 번에 두 개씩

Bornstein에 따르면 이것은 "클래스 파일 세트를 dex 파일로 변환 할 때 찾을 수있는 일반적인 기대"입니다.

프리젠 테이션 비디오 의 관련 부분은 25:00에 시작됩니다 .

Shi et al.의 "Virtual Machine Showdown : Stack Versus Registers" 라는 통찰력있는 논문도 있습니다 . (2005) , 스택 및 레지스터 기반 가상 머신의 차이점을 탐구합니다.

Sun이 JVM 스택 기반을 만들기로 결정한 이유를 모르겠습니다. Erlangs 가상 머신, BEAM은 성능상의 이유로 등록됩니다. 그리고 Dalvik은 성능상의 이유로 등록 기반으로 보입니다.

에서 프로 안드로이드 2 :

Dalvik은 레지스터를 스택 대신 주로 데이터 저장 단위로 사용합니다. 결과적으로 Google은 30 % 적은 수의 지침을 달성하기를 희망합니다.

코드 크기와 관련하여 :

Dalvik VM은 생성 된 Java 클래스 파일을 가져 와서 하나 이상의 Dalvik Executables (.dex) 파일로 결합합니다. 여러 클래스 파일의 중복 정보를 재사용하여 기존 .jar 파일의 공간 요구 사항 (비 압축)을 절반으로 효과적으로 줄입니다. 예를 들어 Android에서 웹 브라우저 앱의 .dex 파일은 약 200k 인 반면 압축되지 않은 동등한 .jar 버전은 약 500k입니다. 알람 시계의 .dex 파일은 약 50k이며 .jar 버전의 경우 약 두 배입니다.

그리고 제가 기억하는 것처럼 Computer Architecture : A Quantitative Approach 는 레지스터 머신이 스택 기반 머신보다 더 잘 수행된다는 결론을 내립니다.