오픈소스 범용 VM

틀린 부분을 찾으시면 알려주세요. 🙂

최근 몇년새에 CPU가 하도 빨라져서 그런지, 범용VM이 트렌드로
떠오르고 있는 듯 합니다. 90년대 말의 Java의 유행의 뒤를 이어서
.NET(ECMA CLI)가 여러 언어들이 동시에 통합된 인터페이스로 라이브러리를 공유하는 것을 VM의 주요 특징으로 뽑아내기 시작한 것이 대중적으로는 그 시초라고 볼 수 있겠습니다. 한동안 GNU lightning이나 Psyco같은 VM을 포함하지 않은 JIT 시스템이 뭔가 비전을 제시해줄 것만 같았지만, 결국엔 JIT에서 높은 효율을 내기 위해서 빠질 수 없는 타입 인퍼런스, 메모리 참조 단축, 가비지 컬렉션 같은 것 때문에, 돌아가는 상황을 완전히 제어할 수 있는 VM 수준의 것이 있어야 안정하게 좋은 성능을 낼 수 있었기에 결국은 이렇게 범용 VM의 유행이 왔을 것이라고 봅니다.

Parrot

오픈소스 범용VM으로 처음 알려지기 시작한 것은 아무래도 parrot이라고 할 수 있겠습니다. parrot은 스크립트 언어를 위한 범용VM을 표방하고, 인스트럭션들을 굉장히 스크립트 언어의 주요 작업들에 직관적으로 대응될 수 있을 정도로 간단한 환경을 만들어 주었습니다. 그렇지만, 너무 원대한 꿈을 꾸면서 만든터라, 새로운 아키텍처로의 이식이 다른 VM들에 비해서 쉽지 않고, 내부적인 구조가 너무 어려워서 처음 보는 사람들이 길을 잃어버리기 좋은 환경이라 새로운 개발자의 참여가 적어서 결국은 지금의 상태처럼 다른 사람들은 베이퍼웨어라고 부르지만, 자기들은 곧 릴리스한다고 우기는 상태가 된 것 같습니다.

Mono

그 다음으로 뜬 범용VM은 Mono라고 할 수 있겠는데, 물론 Mono는 ECMA CLI의 스펙을 구현한 것이기 떄문에 VM의 디자인은 독창적인 것은 아니지만 Microsoft제품과의 호환성을 충분히 확보함으로써, 일단은 사용자 뿐만 아니라 개발자들의 관심을 많이 얻었습니다. Mono는 Parrot이 헤메는 과정을 어느정도 보고 나서 개발이 되었기 때문에, 초기부터 너무 큰 꿈을 그리는 것보다 돌아가는 작은 것들을 엮어놓고 나중에 좋은 것으로 부분 부분을 교체하는 방식으로 발전이 되어 와서 결과적으로 쓸만한 것이 나오는 시간이 훨씬 적게 들었고, 그에 따라 지금과 같은 성공을 거둘 수 있었습니다. Mono는 가비지 콜렉터로 boehm-gc를 쓰고 있는데, 이게 겉으로나 소스에서나 보이는 것에 비해서 훨씬 포터블하지가 못합니다. 포팅하기도 쉽지가 않고요.. 그래서, 결국은 Mono는 마이너 플랫폼에 포팅할 때 boehm-gc가 상당한 걸림돌인데, 곧 Mono에서 자체적으로 만든 gc를 도입한다고 하니까 기대를 걸만 하겠습니다. 🙂

LLVM

LLVM은 2002년 정도부터 다른 VM들과는 달리 최적화를 위한 플랫폼이 주요 목적으로 개발되었습니다. 이 VM을 만든 사람은 석사,박사학위 논문의 주제로 LLVM을 썼는데, 박사학위 논문은 “광범위 데이터 구조 분석과 최적화”라는 제목인데, 그에 걸맞게 LLVM은 머신 코드를 실행하면서 데이터 구조적으로 발생하는 여러가지 최적화 가능 지점들을 자동으로 발견해서 최적화를 수행합니다. 대표적인 예로 strcat의 두번째 인자로 변하지 않는 스트링 상수가 들어가는 경우에 memcpy로 교체해버리는 것이 있는데, 이런 것이 컴파일타임에 수행되는 경우 상당한 부작용을 유발할 수도 있다는 점을 생각해 보면, valgrind같이 틈새시장을 굉장히 잘 노린 기발한 착상이라고 할 수 있겠습니다.

LLVM은 valgrind처럼 머신코드를 직접 받아주는 것은 아니고, LLVM의 바이트코드로 생성된 코드를 만들어주는 C/C++ 등의 컴파일러를 사용해서 컴파일하면 그 코드를 실행하면서 분석하고 최적화를 해 주게 되어있는데, 최적화 자료를 토대로 컴파일할 때 아예 머신코드로 컴파일해버리는 기능도 있어서, mono의 머신코드 컴파일러보다도 한단계 더 발전한 것이라고 볼 수 있습니다. LLVM은 현재 PyPy같은 여러 다른 언어 프로젝트에서도 LLVM 코드를 생성하는 기능이 들어가고 있다는 점에서 많은 사용자들을 확보해가고 있어서 앞으로 아주 장래가 기대가 됩니다.

NekoVM

NekoVM은 올해 나온 것이라 다른 것들에 비해서 상대적으로 역사가 짧습니다. NekoVM도 Parrot 만큼이나 굉장히 고수준의 인스트럭션을 갖고 있어서 스크립트 언어를 만들기가 굉장히 간단하게 되어 있습니다. 그리고, NekoVM은 VM 코드가 라이브러리 코드로 단지 50KB 내외밖에 안 된다는 점에서 고속의 실행 코드가 필요한 고수준 도메인 언어에서 뭔가 아주 쓸모가 있어 보입니다. 그런데, NekoVM은 Parrot보다도 더 고수준으로 올라가 있어서 속도를 위해서는 저수준 VM보다는 약간의 희생이 있고, 런타임 최적화를 수행하지 않기 때문에, 장기간 돌더라도 크게 빨라지지는 않습니다. 게다가, 라이선스가 다른 VM과는 달리 GPL이 적용되어 있기 때문에, 기업 사용자들이나 X11/BSD 계열 라이선스를 쓰는 오픈소스 프로젝트들에게 어필하기가 어렵다는 점이 걸림돌로 작용합니다. 만약 GPL을 감수할 수 있는 환경이라면 특히 웹 애플리케이션의 템플릿용 언어로는 굉장한 효율을 발휘할 수 있을 것 같네요.

이제 VM이 이렇게 점점 늘어감에 따라서, 새로운 언어를 만들거나 독특한 동적 실행환경을 만들기에는 점점 좋아지고 있습니다. DSL(Domain Specific Language)로 프로그램 내부에 스크립팅 기능을 추가하면서도 빠른 속도를 유지할 수 있고, 여러가지 다른 언어들을 하나의 VM 위에서 서로 호출하고 참조할 수 있다는 점에서 옛날 패러다임과는 다른 색다른 시도를 할 여지가 많아지고 있는 것 같아서 기대가 됩니다! 🙂

알림: 이 외에도 GNU Portable .NET이나 여러 오픈소스 JVM들이 있겠지만, 거기는 관심이 없어서 자세히 안 본터라 안 적었습니다. =3=3

10 thoughts on “오픈소스 범용 VM”

  1. boehm-gc 같은 경우는 nptl only glibc 와 문제를 일으키기도 했죠 -_ㅜ

    그나저나 gtk# 을 쓰는 프로그램들 중에 쓸만한게 상당히 많은거 같아요

  2. 지금은 모노를 가장 관심있게 보고 있습니다.
    C#이 언어적으로 마음에 들어서 말이죠~
    근데 MS가 만든 닷넷 API는 별로인 것 같습니다.;;

  3. llvm 자바 프론트엔드(컴파일러)하고 백엔드(VM)가 나오면 아주 재밌겠군요. c로 짜서 자바 머신에서 돌리거나 자바로 네이티브 바이너리를 짤 수 있게 된다는…

  4. NekoVM 뭔가 흥미로워 보여서 제 데탑 겸 개발머신(FreeBSD)에 설치하고 간단한 페이지 하나 만들어 띄어보고.. 흥미롭긴 한데, _-_ 아직 언어 레퍼런스도 제대로 보지도 않아서 좀더 테스트해보고 그래봐야겠…

  5. 6일에 Parrot 0.3.1버젼이 릴리즈되었었네요. 아예 아무 릴리즈도 안한줄 알았는데..; 아직 개발단계이긴 해도 여러가지 테스트용으로 언어들을 지원하긴 하나보네요. 🙂

  6. JVM, CLI와 Mono, 패럿밖에 몰랐었는데 역시 오픈소스 쪽에 다양한 VM들이 있군요.
    개인적으로 패럿에 기대가 많았었는데 저런 평가를 듣고 있었다니….OTL

  7. open source vm 이라는건 크리티컬한 환경에서는 쓸물건이 못됩니다. 물론 LLVM 은 퓨어한 머신 앱스트랙션이라서 카테고리가 다르다고 볼 수 있껬지요.

    VM 이 제공해줘야 하는 기능은 instruction set 이외에

    1. GC
    2. code/class loading mechanism
    3. reflection
    이고

    그 이유는 인더스트리얼 스트렝쓰를 위해서 필요한 multi-threaded 환경에서 훌륭한 GC 를 만들 수 있어야 하는데, 이게 어렵습니다. jvm도 1.4.1 이 되서야 했던 물건입니다.

    뵘GC 는 conservative GC 로
    1. false negative 합니다. 내부표현형식이 아닌 포인터로 추정되는 것을 트레이스합니다.

    2. 그렇지만 보통 foreign function interface 를 heap 을 통째로 관리하는 GC 에 비해서 쉽게 구현 가능합니다.

    그렇지만 마찬가지로 시리어스한 환경에서 쓰기는 어렵겠죠.

  8. boehm-gc가 실제로 쓸 만한게 아니라는 것은 전적으로 동의합니다. 아무도 그런 걸 응답성이나 속도가 중요한 곳에서는 진지하게 쓰지 않겠죠.. 🙂

    훌륭한 GC를 만드는게 어렵기는 하겠지만, 이미 JVM이 그걸 해낸만큼, 오픈소스 VM들도 몇몇은 해낼 수 있지 않을까 합니다. 최근의 오픈소스 프로젝트 중 몇몇은 산업계에서 쓰이고 있는 것보다도 훨씬 완성도가 높은 것을 보여주는 것들이 있는데, Ximian이나 IBM, Apache Foundation 등의 제품들을 보고 있으면 Sun 정도의 회사가 할 수 있는 일을 다른 곳에서 못하지는 않을 것 같군요.. 🙂

    물론 parrot이나 neko같은 것이 그런 위치가 될 것 같아보이지는 않습니다. parrot은 든든한 시스템적 지원이 없고, neko는 아예 디자인적으로 하이레벨로 한계를 놓았기 때문에.. 반면에, LLVM은 Apple의 지원이 있고, Mono는 Novel의 자금력이 되고 MS나 HP를 포함한 여러 회사에서 전적인 것은 아니지만 많은 도움을 주고 있죠..

Comments are closed.