Tại sao JVM vẫn không hỗ trợ tối ưu hóa cuộc gọi đuôi?

Hai năm sau khi tối ưu hóa cuộc gọi-does-the-jvm-ngăn-đuôi , dường như có một triển khai nguyên mẫu và MLVM đã liệt kê tính năng này là "proto 80%" trong một thời gian.

Có phải không có sự quan tâm tích cực nào từ phía Sun / Oracle trong việc hỗ trợ các lệnh gọi đuôi hay chỉ là các lệnh gọi đuôi "[...] định mệnh đứng ở vị trí thứ hai trong mọi danh sách ưu tiên tính năng [...]" như đã đề cập tại JVM Hội nghị thượng đỉnh ngôn ngữ ?

Tôi sẽ thực sự quan tâm nếu ai đó đã thử nghiệm bản dựng MLVM và có thể chia sẻ một số ấn tượng về cách nó hoạt động tốt (nếu có).

Cập nhật: Lưu ý rằng một số máy ảo như Avian hỗ trợ các cuộc gọi đuôi phù hợp mà không gặp bất kỳ sự cố nào.

Chẩn đoán mã Java: Cải thiện hiệu suất của mã Java của bạn ( alt ) giải thích lý do tại sao JVM không hỗ trợ tối ưu hóa cuộc gọi đuôi.

Nhưng mặc dù đã biết cách tự động biến đổi một hàm đệ quy đuôi thành một vòng lặp đơn giản, nhưng đặc tả Java không yêu cầu phải thực hiện chuyển đổi này. Có lẽ, một lý do khiến nó không phải là một yêu cầu là nói chung, việc chuyển đổi không thể được thực hiện một cách tĩnh trong một ngôn ngữ hướng đối tượng. Thay vào đó, việc chuyển đổi từ hàm đệ quy đuôi sang vòng lặp đơn giản phải được thực hiện động bởi trình biên dịch JIT.

Sau đó, nó đưa ra một ví dụ về mã Java sẽ không biến đổi.

Vì vậy, như ví dụ trong Liệt kê 3 cho thấy, chúng ta không thể mong đợi các trình biên dịch tĩnh thực hiện chuyển đổi đệ quy đuôi trên mã Java trong khi vẫn bảo toàn ngữ nghĩa của ngôn ngữ. Thay vào đó, chúng ta phải dựa vào biên dịch động của JIT. Tùy thuộc vào JVM, JIT có thể thực hiện hoặc không.

Sau đó, nó đưa ra một bài kiểm tra mà bạn có thể sử dụng để tìm hiểu xem JIT của bạn có thực hiện điều này hay không.

Đương nhiên, vì đây là một bài báo của IBM, nó bao gồm một phích cắm:

Tôi đã chạy chương trình này với một vài Java SDK và kết quả thật đáng ngạc nhiên. Chạy trên Hotspot JVM của Sun cho phiên bản 1.3 cho thấy rằng Hotspot không thực hiện chuyển đổi. Ở cài đặt mặc định, không gian ngăn xếp sẽ hết trong vòng chưa đầy một giây trên máy của tôi. Mặt khác, JVM của IBM cho phiên bản 1.3 chạy mà không có vấn đề gì, cho thấy rằng nó chuyển đổi mã theo cách này.

Một lý do mà tôi đã thấy trước đây cho việc không triển khai TCO (và nó được coi là khó) trong Java là mô hình quyền trong JVM nhạy cảm với ngăn xếp và do đó, các cuộc gọi đuôi phải xử lý các khía cạnh bảo mật.

Tôi tin rằng điều này đã được Clements và Felleisen [1] [2] chứng minh không phải là một trở ngại và tôi khá chắc chắn rằng bản vá MLVM được đề cập trong câu hỏi cũng giải quyết được vấn đề đó.

Tôi nhận ra điều này không trả lời câu hỏi của bạn; chỉ thêm thông tin thú vị.

1. http://www.ccs.neu.edu/scheme/pubs/esop2003-cf.pdf
2. http://www.ccs.neu.edu/scheme/pubs/cf-toplas04.pdf

Có lẽ bạn đã biết điều này rồi, nhưng tính năng này không quá tầm thường vì ngôn ngữ Java thực sự để lộ dấu vết ngăn xếp cho lập trình viên.

Hãy xem xét chương trình sau:

public class Test {

    public static String f() {
        String s = Math.random() > .5 ? f() : g();
        return s;
    }

    public static String g() {
        if (Math.random() > .9) {
            StackTraceElement[] ste = new Throwable().getStackTrace();
            return ste[ste.length / 2].getMethodName();
        }
        return f();
    }

    public static void main(String[] args) {
        System.out.println(f());
    }
}

Mặc dù điều này có một "cuộc gọi đuôi", nó có thể không được tối ưu hóa. (Nếu nó được tối ưu hóa, nó vẫn yêu cầu lưu trữ toàn bộ call-stack vì ngữ nghĩa của chương trình dựa vào nó.)

Về cơ bản, điều này có nghĩa là rất khó để hỗ trợ điều này trong khi vẫn tương thích ngược.

Java là ngôn ngữ ít chức năng nhất mà bạn có thể tưởng tượng (tốt, OK, có lẽ không !) Nhưng đây sẽ là một lợi thế lớn đối với các ngôn ngữ JVM, chẳng hạn như Scala .

Quan sát của tôi là việc biến JVM trở thành nền tảng cho các ngôn ngữ khác dường như chưa bao giờ đứng đầu danh sách ưu tiên đối với Sun và tôi đoán, bây giờ là đối với Oracle.