Đúc hiệu suất trong mức độ khác nhau khi đúc xuống

Question

Cho phép giả định chúng tôi có ba (hoặc nhiều) lớp

public class A {}

public class B kéo dài A {}

public class C mở rộng B triển khai G {}

Giả sử mỗi lớp có 20 phương thức riêng (hoặc hơn).

Việc truyền tới C và truyền tới A có tác động lớn hơn đến hiệu suất không? Làm thế nào để đúc Java làm việc dưới mui xe?

Có phải kiểm tra tất cả các phương thức và trường để hiện diện bằng cách phản chiếu khi truyền xuống không?

Chỉnh sửa: Kích cỡ lớp (số trường và phương pháp) có ảnh hưởng đến hiệu suất khi truyền không? Tôi quan tâm đến cả hai OpenJRE và Dalvik.

Để tham khảo, tôi biết rằng upcasting có thể được thực hiện mà không có vấn đề gì.

Answer 1

Hiệu suất của quá trình truyền phụ thuộc vào việc triển khai JVM.

JLS 5.5 chỉ xác định các yêu cầu cho phép đúc (bao gồm thuật toán đệ quy), nhưng không đặt bất kỳ yêu cầu nào khi triển khai. Trên thực tế, runtime cast rules in 5.5.3 cũng được xác định theo cùng một cách. Tất cả các triển khai JVM tạo ra cùng một kết quả như thuật toán được đề xuất được chấp nhận như một JVM thích hợp.

Nói chung, truyền xuống C mất thêm một chút thời gian kể từ khi JVM phải kiểm tra loại thời gian chạy của đối tượng. Khi truyền tối đa A, không có lý do gì để thực hiện kiểm tra tương tự, vì B mở rộng A.

Thực ra, JVM không quan tâm đến số lượng phương thức và trường. Nó chỉ so sánh phân cấp kiểu, cùng bạn có thể kiểm tra với sự phản ánh (o.getClass())

tôi đã thực hiện một mẫu mã như sau, một trong những yếu hèn, sau đó là một sự liệng lên:

Object o = new Integer(1); 
Integer i = (Integer) o; 

Object o2 = i; 

Các bytecode biên soạn như sau:

0 new java.lang.Integer [16] 
3 dup 
4 iconst_1  <-- 1 as a parameter to the constructor 
5 invokespecial java.lang.Integer(int) [18] <-- constructor 
8 astore_1 [o]  <-- store in 'o' 
9 aload_1 [o] 
10 checkcast java.lang.Integer [16] <-- DOWNCAST CHECK, SPECIAL BYTECODE 
13 astore_2 [i] 
14 aload_2 [i] 
15 astore_3 [o2] <-- WITH UPCAST NO CHECK 

Vì vậy, có một hướng dẫn JVM cụ thể kiểm tra phần tử ở đầu ngăn xếp với một lớp nhất định.

Với upcast, không có kiểm tra nào cả.

Kích thước của các lớp (số trường, phương pháp, dấu chân thực tế) không quan trọng, vì đoạn kiểm tra Class (siêu dữ liệu, thực sự là đối tượng).

Số cấp độ phân cấp và số nếu giao diện được triển khai (nếu truyền tới giao diện) không quan trọng, bởi vì đó là cây kế thừa/thực thi di chuyển để kiểm tra.

Tôi sẽ ngạc nhiên nếu không có loại bộ nhớ nào là cache cho lần kiểm tra này.

Answer 2

Đối với một kiến ​​trúc chi tiết của checkcast (được đề cập trong câu trả lời khác như một cơ chế JVM cho downcasting) trong HotSpot, hãy nhìn vào giấy hội nghị này:

Fast subtype checking in the HotSpot JVM

Một câu nói từ trừu tượng:

trong benchmark thực tế chạy kỹ thuật của chúng tôi thực hiện hoàn chỉnh kiểu phụ kiểm tra trong 3 hướng dẫn (chỉ có 1 bộ nhớ tham khảo) về cơ bản tất cả các thời gian . Trong những trường hợp hiếm hoi, nó sẽ chuyển sang quét mảng chậm hơn. Bộ nhớ mức sử dụng vừa phải (6 từ mỗi lớp) và có thể được giao dịch theo thời gian.

Vì vậy, nếu bạn không viết một số mã rất thấp với nhiều quá trình truyền, tác động là không đáng kể.