JVM이 테일콜 최적화를 지원하지 않는 이유는 무엇입니까?

JVM이 테일콜 최적화를 지원하지 않는 이유는 무엇입니까?

do-the-jvm-prevent-tail-call-optimizations 이후 2년이 지난 현재 시제품 구현이 이루어지고 있으며 MLVM은 한동안 이 기능을 "proto 80%"로 표시했습니다.

Sun/Oracle 측에서는 테일콜 지원에 적극적인 관심이 없습니까?아니면 테일콜이 모든 기능 우선 순위 목록에서 2위를 차지할 운명입니까?[...]JVM Language Summit에서 언급한 바와 같이요?

MLVM 빌드를 테스트한 적이 있는 사람이 있다면, 그 빌드의 동작에 대한 인상을 공유해 주실 수 있으면 좋겠습니다.

업데이트: Avian과 같은 일부 VM은 문제 없이 적절한 테일콜을 지원합니다.

Java 코드 진단: Java 코드 성능 향상(alt)은 JVM이 테일콜 최적화를 지원하지 않는 이유를 설명합니다.

그러나 테일 재귀 함수를 자동으로 단순한 루프로 변환하는 방법은 잘 알려져 있지만 Java 사양에서는 이러한 변환을 수행할 필요가 없습니다.아마도, 이것이 요건이 되지 않는 이유 중 하나는 일반적으로 객체 지향 언어에서는 변환을 정적으로 수행할 수 없기 때문일 것입니다.대신 테일 재귀 함수에서 단순 루프로의 변환은 JIT 컴파일러에 의해 동적으로 수행되어야 합니다.

변환되지 않는 Java 코드의 예를 나타냅니다.

따라서 목록 3의 예에서 보듯이 정적 컴파일러가 언어의 의미를 유지하면서 Java 코드에서 테일 재귀 변환을 수행할 것으로 기대할 수 없습니다.대신 우리는 JIT에 의한 동적 컴파일에 의존해야 한다.JVM에 따라서는, JIT가 이것을 실시할 수도, 실시하지 않을 수도 있습니다.

그런 다음 JIT가 이를 수행할 수 있는지 확인하기 위해 사용할 수 있는 테스트를 제공합니다.

당연히 이 문서는 IBM 문서이므로 다음과 같은 플러그가 포함되어 있습니다.

이 프로그램을 Java SDK 몇 개로 실행했는데 결과는 놀라웠습니다.Sun의 Hotspot JVM 버전 1.3에서 실행하면 Hotspot이 변환을 수행하지 않음을 알 수 있습니다.디폴트 설정에서는 스택공간이 1초 이내에 모두 소진됩니다.한편, IBM의 JVM for version 1.3은 문제없이 작동하며, 이러한 방식으로 코드를 변환한다는 것을 나타냅니다.

지금까지 Java에서 TCO를 구현하지 않은 이유 중 하나는 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());
    }
}

이것이 "테일 콜"을 가지고 있어도 최적화되지 않을 수 있습니다.(최적화 되어 있는 경우 프로그램의 의미에 의존하기 때문에 콜 스택 전체의 부킹이 필요합니다.)

기본적으로 하위 호환성을 유지하면서 이를 지원하는 것은 어렵다는 것을 의미합니다.

Java는 상상할 수 있는 가장 기능성이 낮은 언어입니다(글쎄요, OK, 아마 아닐 겁니다). 그러나 이는 Scala와 같은 JVM 언어에는 큰 이점이 될 것입니다.

JVM을 다른 언어용 플랫폼으로 만드는 것이 Sun과 Oracle의 우선 순위 목록 상위에 오른 적은 없었던 것 같습니다.

자바 문제가 아니라...JVM 중 하나입니다.Java는 JVM 언어의 그랜드그랜드올에 불과합니다.

현재 스택 프레임을 삭제한 상태에서 TCO를 작성하면 실행 중인 프로그램과 현재 스택 호출 변수 사이에 다른 곳에 있어야 합니다.;)

가장 좋은 방법은 점프콜을 위한 새로운 특별한 콜 opcode를 만드는 다른 프레임으로 설정하는 것입니다.그들은 이미 가상 콜을 위해 그렇게 했다.해석상으로는 문제가 되지 않습니다.JIT는 다른 문제를 일으킬 수 있으며 JVM은 충분히 비대합니다.

Java 또는 다른 언어에서는 적절한 TCO가 없기 때문에 trampolining이 있지만 많은 코드가 추가됩니다.아니면 특정한 예외를 사용하지만, 그것은 매우 혼란스럽다.그리고 그건 네 암호에 있지만, 다른 사람들의 도서관에는 없어

아! Rich Hickey가 (기능이 아님)을 추가했다면, 실제 TCO가 부족하기 때문에 사람들이 있다고 생각하지 않았으면 합니다.사내의 테일콜로 TCO를 자동화할 수 있었습니다.또, 테일 위치에 없는 부정한 테일 콜을 검출하는 데도 도움이 됩니다.

외부 TCO에 대한 (트램폴린...)도 있지만, (트램폴린처럼) 지저분하고 끔찍한 스택 상황을 제외하고는 거의 사용되지 않습니다.

하지만 많은 VM가 TCO를 관리합니다.CLR이 할 거라고 들었어요.유료 JVM을 관리하는 경우도 있습니다(예전에는 기억나지 않습니다).

js의 트램폴리닝 예:https://codeinjavascript.com/2020/06/13/tail-call-optimization-tco/

프레임 덮어쓰기를 사용한 HotSpot VM의 TCO에 관한 오래된 논문: https://ssw.jku.at/Research/Papers/Schwaighofer09Master/schwaighofer09master.pdf

언급URL : https://stackoverflow.com/questions/3616483/why-does-the-jvm-still-not-support-tail-call-optimization