Tại sao JVM dựa trên ngăn xếp và Dalvik VM dựa trên đăng ký?

Tôi tò mò, tại sao Sun lại quyết định tạo JVM dựa trên ngăn xếp và Google quyết định làm dựa trên đăng ký DalvikVM?

Tôi cho rằng JVM không thể thực sự cho rằng một số lượng đăng ký nhất định có sẵn trên nền tảng đích, vì nó được cho là độc lập với nền tảng. Vì vậy, nó chỉ trì hoãn việc phân bổ đăng ký, v.v., cho trình biên dịch JIT. (Hãy sửa cho tôi nếu tôi sai.)

Vì vậy, các chàng trai Android nghĩ, "này, điều đó không hiệu quả, chúng ta hãy đăng ký dựa trên vm ngay lập tức ..."? Nhưng khoan đã, có nhiều thiết bị Android khác nhau, Dalvik đã nhắm mục tiêu vào số lượng đăng ký nào? Các mã opcodes Dalvik có được mã hóa cứng cho một số lượng đăng ký nhất định không?

Có phải tất cả các thiết bị Android hiện tại trên thị trường đều có cùng số lượng đăng ký không? Hoặc, có sự phân bổ lại thanh ghi được thực hiện trong quá trình tải dex không? Làm thế nào để tất cả những điều này phù hợp với nhau?

Có một số thuộc tính của máy ảo dựa trên ngăn xếp phù hợp với các mục tiêu thiết kế của Java:

1. Thiết kế dựa trên ngăn xếp tạo ra rất ít giả định về phần cứng đích (thanh ghi, tính năng CPU), vì vậy thật dễ dàng triển khai một máy ảo trên nhiều loại phần cứng.

2. Vì các toán hạng cho các lệnh chủ yếu là ẩn, mã đối tượng sẽ có xu hướng nhỏ hơn. Điều này quan trọng nếu bạn đang tải xuống mã qua liên kết mạng chậm.

Đi với một lược đồ dựa trên thanh ghi có thể có nghĩa là trình tạo mã của Dalvik không phải làm việc vất vả để tạo ra mã hiệu quả. Chạy trên một kiến ​​trúc cực kỳ giàu có hoặc nghèo có đăng ký có thể sẽ gây khó khăn cho Dalvik, nhưng đó không phải là mục tiêu thông thường - ARM là một kiến ​​trúc rất trung thành.

Tôi cũng đã quên rằng phiên bản đầu tiên của Dalvik không bao gồm một JIT nào cả. Nếu bạn định giải thích các hướng dẫn một cách trực tiếp, thì một lược đồ dựa trên sổ đăng ký có thể là một chiến thắng cho hiệu suất diễn giải.

Tôi không thể tìm thấy tài liệu tham khảo, nhưng tôi nghĩ Sun đã quyết định cách tiếp cận bytecode dựa trên ngăn xếp vì nó giúp dễ dàng chạy JVM trên một kiến ​​trúc có ít thanh ghi (ví dụ: IA32).

Trong Dalvik VM Internals từ Google I / O 2008, Dan Bornstein, người tạo ra Dalvik, đưa ra các đối số sau để chọn một VM dựa trên đăng ký trên slide 35 của các slide trình bày :

Đăng ký máy

Tại sao?

• tránh công văn hướng dẫn
• tránh truy cập bộ nhớ không cần thiết
• sử dụng luồng lệnh một cách hiệu quả (mật độ ngữ nghĩa cao hơn trên mỗi lệnh)

và trên slide 36:

Đăng ký máy

Các số liệu thống kê

• Giảm 30% hướng dẫn
• Giảm 35% đơn vị mã
• Thêm 35% byte trong luồng hướng dẫn
  • nhưng chúng ta phải tiêu thụ hai

Theo Bornstein, đây là "kỳ vọng chung mà bạn có thể tìm thấy khi chuyển đổi một tập hợp các tệp lớp thành tệp dex".

Phần liên quan của video thuyết trình bắt đầu lúc 25:00 .

Ngoài ra còn có một bài báo sâu sắc có tiêu đề "Cuộc biểu tình máy ảo: Ngăn xếp so với đăng ký" của Shi et al. (2005) , khám phá sự khác biệt giữa máy ảo dựa trên ngăn xếp và đăng ký.

Tôi không biết tại sao Sun lại quyết định dựa trên JVM stack. Máy ảo Erlangs, BEAM được đăng ký dựa trên lý do hiệu suất. Và Dalvik dường như cũng sẽ đăng ký vì lý do hiệu suất.

Từ Pro Android 2 :

Dalvik chủ yếu sử dụng các thanh ghi làm đơn vị lưu trữ dữ liệu thay vì ngăn xếp. Do đó, Google hy vọng sẽ thực hiện được ít hơn 30% hướng dẫn.

Và về kích thước mã:

Dalvik VM lấy các tệp lớp Java đã tạo và kết hợp chúng thành một hoặc nhiều tệp Dalvik Executables (.dex). Nó sử dụng lại thông tin trùng lặp từ nhiều tệp lớp, giảm một nửa yêu cầu về dung lượng (không nén) so với tệp .jar truyền thống. Ví dụ: tệp .dex của ứng dụng trình duyệt web trên Android là khoảng 200k, trong khi phiên bản .jar không nén tương đương là khoảng 500k. Tệp .dex của đồng hồ báo thức có dung lượng khoảng 50k, và gần gấp đôi kích thước đó trong phiên bản .jar của nó.

Và như tôi nhớ Kiến trúc Máy tính: Phương pháp Tiếp cận Định lượng cũng kết luận rằng một máy đăng ký hoạt động tốt hơn một máy dựa trên ngăn xếp.