เหตุใด JVM จึงยังไม่รองรับการเพิ่มประสิทธิภาพการโทรหาง?

สองปีหลังจากการเพิ่มประสิทธิภาพdo -the-jvm-Prevent-tail-call-optimizationsดูเหมือนว่าจะมีการนำไปใช้งานต้นแบบ และMLVMได้ระบุคุณลักษณะนี้เป็น "โปรโต 80%" ในบางครั้ง

ไม่มีความสนใจอย่างแข็งขันจากฝั่งของ Sun / Oracle ในการสนับสนุนการโทรหางหรือเป็นเพียงการเรียกหางคือ "[... ] โชคชะตาที่จะมาเป็นอันดับสองในทุกรายการลำดับความสำคัญของคุณลักษณะ [... ]" ตามที่กล่าวไว้ที่JVM การประชุมสุดยอดภาษา ?

ฉันจะสนใจจริงๆถ้ามีคนทดสอบบิลด์ MLVM และสามารถแบ่งปันความประทับใจว่ามันทำงานได้ดีเพียงใด (ถ้าเป็นเช่นนั้น)

อัปเดต: โปรดทราบว่า VM บางตัวเช่นAvianรองรับการโทรหางที่เหมาะสมโดยไม่มีปัญหาใด ๆ

การวินิจฉัยรหัส Java: การปรับปรุงประสิทธิภาพของ Java Code ของคุณ ( alt ) อธิบายว่าเหตุใด JVM จึงไม่สนับสนุนการเพิ่มประสิทธิภาพการโทรหาง

แต่ถึงแม้ว่าจะเป็นที่ทราบกันดีว่าจะแปลงฟังก์ชัน tail-recursive โดยอัตโนมัติให้เป็น loop แบบธรรมดาได้อย่างไร แต่ข้อกำหนดของ Java ไม่จำเป็นต้องทำการแปลง สันนิษฐานว่าสาเหตุหนึ่งที่ไม่ใช่ข้อกำหนดก็คือโดยทั่วไปแล้วการเปลี่ยนแปลงไม่สามารถทำแบบคงที่ในภาษาเชิงวัตถุได้ แต่การแปลงจากฟังก์ชัน tail-recursive ไปเป็น simple loop จะต้องทำแบบไดนามิกโดยคอมไพเลอร์ JIT

จากนั้นให้ตัวอย่างโค้ด Java ที่จะไม่แปลง

ดังตัวอย่างในรายการที่ 3 แสดงเราไม่สามารถคาดหวังว่าคอมไพเลอร์แบบคงที่จะทำการแปลงการเรียกซ้ำหางบนโค้ด Java ในขณะที่ยังคงรักษาความหมายของภาษาไว้ แต่เราต้องพึ่งพาการรวบรวมแบบไดนามิกโดย JIT JIT อาจทำหรือไม่ทำทั้งนี้ขึ้นอยู่กับ JVM

จากนั้นจะให้การทดสอบที่คุณสามารถใช้เพื่อดูว่า JIT ของคุณทำสิ่งนี้หรือไม่

โดยปกติแล้วเนื่องจากเป็นกระดาษ IBM จึงมีปลั๊ก:

ฉันรันโปรแกรมนี้ด้วย Java SDK สองสามตัวและผลลัพธ์ก็น่าประหลาดใจ การทำงานบน Sun's Hotspot JVM สำหรับเวอร์ชัน 1.3 เผยให้เห็นว่า Hotspot ไม่ได้ทำการเปลี่ยนแปลง ที่การตั้งค่าเริ่มต้นพื้นที่สแต็กจะหมดภายในเวลาไม่ถึงหนึ่งวินาทีบนเครื่องของฉัน ในทางกลับกัน JVM ของไอบีเอ็มสำหรับเวอร์ชัน 1.3 ส่งเสียงฟี้อย่างไม่มีปัญหาแสดงว่ามันแปลงรหัสด้วยวิธีนี้

เหตุผลหนึ่งที่ฉันเคยเห็นมาก่อนในการไม่ใช้ TCO (และถูกมองว่าเป็นเรื่องยาก) ใน Java คือรูปแบบการอนุญาตใน JVM นั้นมีความไวต่อสแต็กดังนั้นการโทรหางจึงต้องจัดการด้านความปลอดภัย

ฉันเชื่อว่าสิ่งนี้แสดงให้เห็นแล้วว่า Clements และ Felleisen ไม่เป็นอุปสรรค [1] [2] และฉันค่อนข้างมั่นใจว่าแพตช์ MLVM ที่กล่าวถึงในคำถามนั้นเกี่ยวข้องด้วยเช่นกัน

ฉันตระหนักดีว่านี่ไม่ได้ตอบคำถามของคุณ เพียงแค่เพิ่มข้อมูลที่น่าสนใจ

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

บางทีคุณอาจจะรู้เรื่องนี้อยู่แล้ว แต่คุณลักษณะนี้ไม่สำคัญเท่าที่ควรเนื่องจากภาษา Java เปิดเผยการติดตามสแต็กกับโปรแกรมเมอร์

พิจารณาโปรแกรมต่อไปนี้:

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());
    }
}

แม้ว่าจะมี "tail-call" แต่ก็อาจไม่ได้รับการปรับให้เหมาะสม (หากมีการปรับให้เหมาะสมที่สุดก็ยังคงต้องมีการจัดเก็บหนังสือของ call-stack ทั้งหมดเนื่องจากความหมายของโปรแกรมขึ้นอยู่กับมัน)

โดยทั่วไปหมายความว่าเป็นการยากที่จะรองรับสิ่งนี้ในขณะที่ยังใช้งานร่วมกันได้แบบย้อนหลัง

Java เป็นภาษาที่ใช้งานได้น้อยที่สุดที่คุณอาจจินตนาการได้ (โอเคอาจจะไม่ใช่ !) แต่นี่จะเป็นข้อได้เปรียบที่ดีสำหรับภาษา JVM เช่นScalaซึ่งก็คือ

ข้อสังเกตของฉันคือการทำให้ JVM เป็นแพลตฟอร์มสำหรับภาษาอื่นดูเหมือนจะไม่เคยอยู่ในอันดับต้น ๆ ของรายการลำดับความสำคัญของ Sun และฉันเดาว่าตอนนี้สำหรับ Oracle