다빈치 기계
Da Vinci Machine![]() |
![]() | |
개발자 | 선 마이크로시스템스 |
---|---|
운영 체제 | 크로스 플랫폼 |
유형 | 도서관 |
면허증 | GPL+링크 예외 |
웹사이트 | openjdk |
다빈치 머신은 다국어 가상 머신이라고도 불리며 동적 언어 지원을 추가하기 위해 자바 가상 머신(JVM)의 확장을 프로토타입화하는 것을 목표로 한 선 마이크로시스템스 프로젝트였다.
이미 JVM 위에서 동적 언어를 실행할 수 있었지만 새로운 동적 언어 구현을 완화하고 성능을 높이는 것이 목표다.이 프로젝트는 JSR 292(Java 플랫폼에서 동적으로 타이핑된 언어 지원)의 참조 구현이었다.[1]
역사
Java 7 이전에 Java Virtual Machine은 동적으로 입력된 언어에 대한 기본 지원이 없었다.
JSR 292(Java 플랫폼에서 동적으로 타이핑된 언어 지원)[1]는 다음을 제안한다.
- 새것을 추가하다
invokedynamic
동적 유형 검사에 의존하는 메서드 호출을 허용하는 [3][4][5]JVM 수준의 지침 - 운영 환경에서 동적으로 런타임에 클래스와 방법을 변경할 수 있다.
JRuby Java 이행의 성공에 따라, 다빈치 프로젝트는 2008년 1월 말에 시작되었다.[6]다빈치에 의해 실험된 능력은 자바 7에 추가될 계획이었다.이 회사는 이 JSR을 프로토타입으로 제작하는 것을 목표로 하고 있지만, 다른 낮은 우선순위의 확장도 목표로 하고 있다.[7]OpenJDK의 패치로 개발된 최초의 작업 시제품이 2008년 8월 말에 발표되어 출시되었다.[8][9][10]
이후 JRuby 팀은 코드베이스에서 동적 호출에 성공했다.동적 호출은 1.1.5 릴리스와 함께 제공되며, JVM에서 사용하지 않도록 설정됨invokedynamic
능력[11]
이후 이 프로젝트는 JDK 7 코드베이스에[12] 통합되었다가 자바 7 릴리스에 통합되었다.
건축
동적 호출은 자바어가 언어 수준에서 강력한 정적 언어라고 해도, 유형 정보는 바이트코드 수준에서 훨씬 덜 만연된다는 사실에 기초하여 구축된다.
그러나 동적 언어 구현은 좋은 성능을 얻기 위해 (반성이 아닌) 적시 컴파일(just-in-time composition)을 사용할 수 있어야 하며, 따라서 런타임에 스크립트를 바이트 코드로 컴파일할 수 있어야 한다.[citation needed]자바 가상 머신에 의해 실행되도록 허용되려면 실행 전에 이러한 바이트 코드를 확인해야 하며, 확인자는 코드 전체에 걸쳐 유형이 정적인지 확인한다.그것은 이러한 구현으로 인해 인수 서명이 바뀔 때마다 메서드 호출의 다른 컨텍스트에 대해 많은 다른 바이트 코드를 생성해야 한다.
이는 많은 메모리를 사용할 뿐만 아니라 JVM이 클래스에 대한 정보를 저장하기 위해 사용하는 힙의 일부인 Metaspace(Java 8 이전의 영구 생성)라는 메모리 영역을 채운다.이 영역에서 사용되는 메모리는 Java 프로그램의 맥락에서 불변의 데이터를 저장하기 때문에 수집된 쓰레기가 거의 없으며, 그 때문에 동적 언어 구현은 스크립트의 일부분만 컴파일할 수 있다.[13]
JSR 292는 다음을 제안한다.
- 기존 클래스를 로드하고 수정할 수 있는 메커니즘을 제공하여 이러한 수정으로 새 클래스를 생성하지만 나머지 구조와 데이터를 공유하여 영구 생성 공간을 채우지 않도록 한다.
- 신제품을 제공하다
invokedynamic
JVM이 이러한 종류의 호출을 최적화할 수 있는 바이트 코드.[3]
참고 항목
- Java 플랫폼용 스크립팅
- JVM 언어 목록
- Dynamic Language Runtime - 에 동적 언어를 지원하는 Microsoft 환경.NET Framework 공용 언어 런타임
- 내쇼른(JavaScript 엔진) - 다빈치 기계 기반
참조
- ^ a b JSR 292 참조
- ^ Nutter, Charles (2007-01-03). "InvokeDynamic: Actually Useful?". Retrieved 2008-02-06.
- ^ a b Ed Ort (July 2009). "New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine". Retrieved 2009-07-26.
- ^ Jeff Friesen (2014-12-16). "How To Invokedynamic". JavaWorld. Retrieved 2020-06-10.
- ^ Rafael Winterhalter (2015-03-02). "Dismantling invokedynamic". dzone.com. Retrieved 2020-06-10.
- ^ Krill, Paul (2008-01-31). "Sun's Da Vinci Machine broadens JVM coverage". Archived from the original on 2009-03-28. Retrieved 2008-02-06.
- ^ "Sub-Projects and Investigations". Sun Microsystems. 2007. Retrieved 2008-02-06.
- ^ Rose, John (2008-08-26). "Happy International Invokedynamic Day!". Archived from the original on 2008-09-03. Retrieved 2008-09-03.
- ^ Rose, John (2008-09-02). "Happy International Invokedynamic Day!". Retrieved 2008-09-07.
- ^ Lorimer, R.J. (2008-09-01). "Dynamic Invocation Runs on OpenJDK". infoq.com. Retrieved 2008-09-03.
- ^ Nutter, Charles (2008-09-11). "A First Taste of InvokeDynamic". Retrieved 2008-09-13.
I managed to successfully wire InvokeDynamic directly into JRuby's dispatch process! Such excitement! The code is already in JRuby's trunk, and will ship with JRuby 1.1.5 (though it obviously will be disabled on JVMs without InvokeDynamic).
- ^ Rose, John (2009-04-22). "progress: indy.patch -> JDK7". Retrieved 2009-04-30.
The majority of indy.patch has entered the JDK7 VM at my workgroup's integration repo, today at about 4:00AM PDT:
- ^ Nutter, Charles (2008-09-11). "A First Taste of InvokeDynamic". Retrieved 2008-02-06.
The dirty secret of several JVM implementations, Hotspot included, is that there's a separate heap (or a separate generation of the heap) used for special types of data like class definitions, class metadata, and sometimes bytecode or JITted native code. And it couldn't have a scarier name: The Permanent Generation. Except in rare cases, objects loaded into the PermGen are never garbage collected (because they're supposed to be permanent, get it?) and if not used very, very carefully, it will fill up(...)