Tại sao JVM cache JIT không biên dịch mã?

Việc triển khai JVM chuẩn từ Sun áp dụng một số tối ưu hóa khá phức tạp cho bytecode để có được tốc độ thực thi gần như nguyên bản sau khi mã được chạy một vài lần.

Câu hỏi đặt ra là, tại sao mã đã biên dịch này không được lưu trong bộ nhớ cache vào đĩa để sử dụng trong các lần sử dụng tiếp theo của cùng một hàm / lớp?

Như hiện tại, mỗi khi một chương trình được thực thi, trình biên dịch JIT khởi động lại, thay vì sử dụng phiên bản mã được biên dịch trước. Việc thêm tính năng này sẽ không tăng đáng kể thời gian chạy ban đầu của chương trình, khi mã bytecode về cơ bản đang được diễn giải?

Tôi nghi ngờ điều này là do các tối ưu hóa mà JVM thực hiện không phải là tĩnh, mà là động, dựa trên các mẫu dữ liệu cũng như các mẫu mã. Có khả năng các mẫu dữ liệu này sẽ thay đổi trong suốt thời gian tồn tại của ứng dụng, khiến các mức tối ưu được lưu trong bộ nhớ cache kém hơn mức tối ưu.

Vì vậy, bạn cần một cơ chế để xác định xem liệu các tối ưu hóa đã lưu có còn là tối ưu hay không, tại thời điểm đó, bạn có thể chỉ cần tối ưu hóa lại ngay lập tức.

JVM của Oracle thực sự được ghi nhận để làm như vậy - trích lời Oracle,

trình biên dịch có thể tận dụng mô hình phân giải lớp của Oracle JVM để tùy chọn duy trì các phương thức Java đã biên dịch trên các lệnh gọi, phiên hoặc phiên bản cơ sở dữ liệu. Sự bền bỉ như vậy tránh được chi phí biên dịch lại không cần thiết giữa các phiên hoặc phiên bản, khi biết rằng về mặt ngữ nghĩa mã Java không thay đổi.

Tôi không biết tại sao tất cả các triển khai VM phức tạp không cung cấp các tùy chọn tương tự.

Bản cập nhật cho các câu trả lời hiện có - Java 8 có một JEP dành riêng để giải quyết vấn đề này:

=> JEP 145: Mã biên dịch bộ nhớ cache . Liên kết mới .

Ở cấp độ rất cao, mục tiêu đã nêu của nó là :

Lưu và sử dụng lại mã gốc đã biên dịch từ các lần chạy trước để cải thiện thời gian khởi động của các ứng dụng Java lớn.

Hi vọng điêu nay co ich.

Excelsior JET có trình biên dịch JIT bộ nhớ đệm kể từ phiên bản 2.0, được phát hành vào năm 2001. Hơn nữa, trình biên dịch AOT của nó có thể biên dịch lại bộ nhớ cache thành một DLL / đối tượng chia sẻ duy nhất bằng cách sử dụng tất cả các tối ưu hóa.

Tôi không biết lý do thực sự, không liên quan đến việc thực hiện JVM, nhưng tôi có thể nghĩ ra một số lý do chính đáng:

• Ý tưởng của Java là trở thành một ngôn ngữ viết-một-lần-chạy-ở bất cứ đâu và việc đưa những thứ được biên dịch sẵn vào tệp lớp là loại vi phạm điều đó (chỉ "loại" vì tất nhiên mã byte thực vẫn sẽ ở đó)
• Nó sẽ làm tăng kích thước tệp lớp vì bạn sẽ có cùng một mã ở đó nhiều lần, đặc biệt nếu bạn tình cờ chạy cùng một chương trình dưới nhiều JVM khác nhau (điều này không thực sự phổ biến, khi bạn coi các phiên bản khác nhau là các JVM khác nhau, mà bạn thực sự phải làm)
• Bản thân các tệp lớp có thể không ghi được (mặc dù sẽ khá dễ dàng để kiểm tra điều đó)
• Các tối ưu hóa JVM một phần dựa trên thông tin về thời gian chạy và trên các lần chạy khác, chúng có thể không áp dụng được (mặc dù chúng vẫn sẽ mang lại một số lợi ích)

Nhưng tôi thực sự đang đoán, và như bạn có thể thấy, tôi không thực sự nghĩ rằng bất kỳ lý do nào trong số những lý do của tôi là thực sự dừng show. Tôi nghĩ Sun không coi hỗ trợ này là ưu tiên, và có lẽ lý do đầu tiên của tôi gần với sự thật, vì việc làm này theo thói quen cũng có thể khiến mọi người nghĩ rằng các tệp lớp Java thực sự cần một phiên bản riêng biệt cho mỗi máy ảo thay vì đa nền tảng.

Cách ưa thích của tôi thực sự sẽ là có một trình dịch bytecode-to-native riêng biệt mà bạn có thể sử dụng để làm điều gì đó như thế này một cách rõ ràng trước đó, tạo các tệp lớp được xây dựng rõ ràng cho một máy ảo cụ thể, có thể có mã byte gốc trong chúng để bạn cũng có thể chạy với các máy ảo khác nhau. Nhưng điều đó có lẽ xuất phát từ kinh nghiệm của tôi: Tôi hầu như chỉ làm Java ME, nơi mà thực sự đau đầu là trình biên dịch Java không thông minh hơn về biên dịch.