KR100577366B1 - 이종의 자바 메소드를 실행하는 방법 및 장치 - Google Patents

Abstract

이종의 자바 메소드를 실행하는 방법 및 장치에 관한 것이다.

본 발명의 일 실시예에 따른 이종의 자바 메소드를 실행하는 방법은 제 1 메소드가 제 2 메소드를 호출할 경우 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하는 단계, 상기 제 2 메소드를 실행하기 위한 제 2 스택 프레임을 스택에 추가하는 단계, 상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하는 단계를 포함하며, 상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성이다.

자바 바이트 코드, 네이티브 코드, 스택 프레임, 컴파일, 인터프리터

Description

이종의 자바 메소드를 실행하는 방법 및 장치{Method and apparatus for executing different forms of java methods}

도 1은 자바 클래스 코드가 인터프리터와 컴파일러에 의해 동작되는 방식을 보여주는 구성도이다.

도 2는 종래의 이종의 코드사이에 발생하는 예외 처리와 관련된 기술의 구성도이다.

도 3은 종래의 바이트 코드를 컴파일 코드로 변환하여 처리하는 기술과 관련된 구성도이다.

도 4는 종래의 바이트 코드와 컴파일 코드가 서로 다른 스택을 참조하는 기술과 관련된 구성도이다.

도 5는 본 발명의 일 실시예에 따른 자바 가상 머신의 구성도이다.

도 6은 본 발명의 일 실시예에 따른 메소드 실행에 관련된 스택 프레임의 구조를 보여주는 구성도이다.

도 7은 본 발명의 일 실시예에 따른 메소드 호출에 의한 스택 프레임 생성을 보여주는 구성도이다.

도 8은 본 발명의 일 실시예에 따른 이종의 코드간에 메소드 호출을 통해 컨트롤이 이동되는 과정을 보여주는 블록도이다.

도 9는 본 발명의 일 실시예에 따라 바이트 코드와 네이티브 코드간에 공유되는 레지스터를 보여주는 블록도이다.

도 10은 본 발명의 일 실시예에 따른 예외 처리 루틴의 수행을 보여주는 블록도이다.

도 11은 본 발명의 일 실시예에 따른 메소드 호출에 따른 스택의 구성을 보여주는 블록도이다.

도 12는 본 발명의 일 실시예에 따른 메모리 할당을 보여주는 순서도이다.

도 13은 본 발명의 일 실시예에 따른 자바 가상 머신이 탑재된 디지털 장치의 구성도이다.

<도면의 주요 부분에 대한 부호의 설명>

100 : 스택 프레임 500 : 자바 가상 머신

510 : 인터프리터` 520 : 컴파일러

540 : 메모리 관리자

이종의 자바 코드를 실행하는 방법 및 장치에 관한 것이다.

객체지향 프로그래밍(Object-Oriented Programming)은 컴퓨터 프로그램의 개발 방법의 하나로 동작보다는 객체, 논리보다는 자료를 바탕으로 구성된다. 과거 프로그램은 전통적으로 논리적인 수행 즉, 입력을 받아 처리한 다음, 결과를 내는 것으로 보는 시각이 지배적이었다. 또한 프로그래밍을 한다는 것은 어떻게 자료를 정의할까 보다는 어떻게 논리를 써나가는 것인가로 간주되었다.

그러나 객체지향 프로그래밍은 프로그램에서 중요한 것이 논리보다는 오히려 다루고자 하는 객체라는 시각에서 접근하고 있다. 객체의 예로는, 사람(이름, 주소 등으로 묘사되는)에서부터 건물까지, 그리고 상품 판매를 위한 매장(특성이 서술되고 다뤄질 수 있는)에서부터 컴퓨터 바탕화면의 아주 작은 요소인 버튼이나 스크롤바 같은 것들까지를 모두 망라한다.

객체지향 프로그래밍에서의 첫 단계는 다루고자 하는 모든 객체와 그것들이 서로 어떤 연관성이 있는지를 식별하는 - 흔히 데이터 모델링이라고 부르는 - 작업이다. 일단 모든 객체를 식별했으면, 객체 클래스로 일반화하고 그것이 담고 있는 데이터의 종류와 그것을 다룰 수 있는 모든 논리 순서를 정의한다.

논리 순서는 메소드(method)라고 부르며, 클래스의 실제 인스턴스(instance)를 하나의 "객체"라 하거나, 어떤 상황에서는 하나의 "클래스 활성체"라 한다. 객체 또는 활성체는 컴퓨터 내에서 실제로 수행되는 것이다. 메소드는 컴퓨터 명령어를 규정하고, 클래스 객체의 특성은 관련 데이터를 규정한다.

자바는 특별히 인터넷의 분산환경에서 사용되도록 설계된 프로그래밍 언어이다. 자바는 C++ 언어처럼 보이지만, C++ 보다는 사용하기에 간단하고 프로그래밍의 완전한 객체지향성을 강화하였다. 자바는 한 대의 컴퓨터나, 네트웍 상의 분산 클라이언트/서버 환경에서도 실행되는 응용프로그램을 만드는데 모두 사용될 수 있다. 이것은 또한 웹페이지의 일부로서 쓰이는 작은 응용프로그램 모듈이나 애플릿 등을 만드는 데에도 사용될 수 있다. 애플릿들은 사용자들이 웹페이지를 통해 상호작용을 할 수 있도록 해준다.

한편 자바 프로그램을 실행하는 방식에는 크게 인터프리터 방식(Interpreter)과 컴파일 방식(Compile)이 있다. 인터프리터 방식은 프로그램 코드를 하나씩 읽어들여서 이것을 수행하는 것을 의미한다. 컴파일 방식은 기계어로 만들어진 코드를 실행하는 것을 의미한다. 인터프리터 방식은 명령어를 하나씩 수행하므로, 시스템에 부담을 주지는 않으나 속도에 있어서 느리다. 컴파일 방식은 전체 프로그램을 메모리에 로딩해야 하므로, 속도면에서는 인터프리터 방식보다 빠르지만, 메모리 용량을 많이 차지한다.

도 1은 자바 클래스 코드가 인터프리터와 컴파일러에 의해 동작되는 방식을 보여주는 구성도이다. 자바 소스 코드(1)는 에디터 등을 통해 자바 언어의 문법에 맞게 작성한 원시 프로그램 코드이다. 이는 사람이 읽을 수 있으며, 기계는 읽을 수 없다. 이러한 소스 코드를 바이트 코드 컴파일러(2)를 통해 자바 가상 머신(500)에서 수행되는 기계어인 바이트 코드(3)로 변환한다. 자바 가상 자신은 자바 바이트 코드를 실행하기 위한 에뮬레이터의 역할을 한다. 자바 가상 머신은 하드웨어에 독립적인 자바 바이트 코드를 실행한다. 동일한 바이트 코드가 여러 이종의 하드웨어에서 실행이 가능한 이유는 자바 가상 머신이 중간에서 하드웨어를 에뮬레이트 하기 때문이다.

자바 가상 머신(500)은 바이트 코드(3)를 특정 하드웨어 또는 운영체계(Operating system, OS)에서 수행한다. 이 과정에서 전술한 명령어를 하나씩 해석하는 인터프 리터 방식을 사용하는 인터프리터(510)와 컴파일 방식으로 바이트 코드를 기계어로 바꾸어 직접 기계어로 수행하는 컴파일러(520)가 존재한다.

한편, 자바 가상 머신은 메소드의 수행 빈도에 따라서 각기 다른 방식으로 바이트 코드를 실행한다. 예를 들어, 자주 호출되지 않은 메소드의 경우 인터프리터 방식의 바이트 코드(이하 '인터프리터 코드'라 한다)로 수행하고 빈번하게 호출되는 메소드의 경우 컴파일된 기계어 코드(이하 '네이티브 코드'(native code)라 한다)로 수행한다. 따라서, 자바 가상 머신의 특성상 이종의 메소드간의 호출이 일어날 경우에 파라미터, 리턴 주소, 로컬 변수 등의 수행 상태을 저장하는 스택(stack)의 관리가 필요하다. 특히, 어느 순간에 인터프리터 방식으로 수행되던 메소드가 수행성능을 높이기 위하여 컴파일 방식으로 수행될 수도 있고, 반대로 메모리 사용을 절감하기 위하여 컴파일 방식으로 수행되던 메소드가 쉽게 인터프리터 방식으로 전환되어 수행될 수도 있어야 한다. 자바 가상 머신에서는 이러한 이종의 메소드간의 상호 운용성(interoperability)을 제공하는 것이 매우 중요한 기술이다. 과거 이러한 이종의 메소드간의 호출시의 스택을 관리하기 위해서 여러가지 방법이 제시되었다.

도 2는 종래의 이종의 메소드사이에 발생하는 호출에 대해 스택을 관리하는 기술의 구성도이다. 이 기술은 혼합된 실행 스택을 통해 메소드 사이의 호출을 수행하는 것이다(미국 특허, US6009517). 인터프리트 코드(Java frame)와 네이티브 코드(C++ frame)의 메소드는 모두 하나의 실행 스택(Execution stack)에 프레임들을 저장한다. 그리고 이들 프레임간에 컨트롤 플로우는 중간에 존재하는 엔트리 프레임 을 통해 정보를 교환한다. 그러나 인터프리트 코드의 프레임과 네이티브 코드의 프레임은 서로 다른 포맷으로 구성되며, 컴파일된 메소드가 어느 순간에 인터프리터 방식으로 전환되어야 할 경우에 네이티브 코드의 프레임을 인터프리트 코드의 프레임으로 변경하는 과정이 매우 복잡해진다.

도 3은 종래의 바이트 코드를 컴파일 코드로 변환하여 처리하는 기술과 관련된 구성도이다. 이는 인터프리터(22)와 컴파일러(23)가 자바 가상 머신에 포함되어 클래스 파일(21)을 실행한다(미국 특허, US6292935). 다만, 컴파일러(23)를 통해 생성된 메소드인 네이티브 메소드가 인터프리터 코드의 메소드를 호출하는 경우, 인터프리터 코드를 무조건 컴파일러를 통해 컴파일 시켜서 단일 스택 구조를 사용할 수 있으므로 상호 운용성의 문제를 해결한다. 그러나, 이는 인터프리터의 장점인 메모리 점유 공간을 줄이지 못하고, 오히려 인터프리터를 통해 실행 가능한 코드들도 모두 컴파일시킨다는 문제점을 가지고 있다.

도 4는 종래의 바이트 코드와 컴파일 코드가 서로 다른 스택을 참조하는 기술과 관련된 구성도이다. 이는 인터프리터를 통해 실행되는 메소드의 스택(31)과 네이티브 메소드(32)의 스택을 독립적으로 두어 달리 운용하는 방식이다(미국 특허, US6604167). 이 방법은 서로 다른 포맷의 프래임이 각기 다른 스택에 존재하므로, 추후 메소드의 실행 방식이 변경되는 경우, 탄력적으로 적용하기 어려운 점이 있다.

지금까지 살펴본 기술들은 메소드를 실행시에 서로 다른 형식의 프레임으로 스택을 구성하거나, 이종의 스택에 저장하거나, 또는 인터프리터 코드를 컴파일 코드로 변 환하여 실행하는 방식을 통해 상호운용성에 근접하고자 하였다. 그러나 이러한 방식들은 인터프리터 코드와 컴파일 코드간의 실시간적인 상호 운용성을 높이지 못하며, 스택 프레임의 이종 구성으로 인해 코드의 신속한 전환과 이에 따른 실행이 보장되지 못한다. 특히, 디지털 기기에서 임베디드 자바(Embedde java)를 사용할 경우, 인터프리터 코드와 네이티브 코드간의 상호 운용성과 메모리 용량에 적응하기 위한 코드간의 변환을 위해서는 하나의 공통된 포맷의 스택을 사용하는 것이 필요하다.

본 발명의 기술적 과제는 하나의 통일된 포맷을 가진 자바 실행 스택을 구현하는데 있다.

본 발명의 다른 기술적 과제는 통일된 포맷으로 구성된 자바 실행 스택을 통해 이종의 메소드간의 상호 운용성을 향상시키는데 있다.

본 발명의 목적들은 이상에서 언급한 목적들로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

이종의 자바 메소드를 실행하는 방법 및 장치에 관한 것이다.

본 발명의 일 실시예에 따른 이종의 자바 메소드를 실행하는 방법은 제 1 메소드가 제 2 메소드를 호출할 경우 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하는 단계, 상기 제 2 메소드를 실행하기 위한 제 2 스택 프레임을 스택에 추가하는 단계, 상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하는 단계를 포함하며, 상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성이다.

본 발명의 일 실시예에 따른 이종의 자바 메소드를 실행하는 자바 가상 머신은 바이트 코드를 실행하는 인터프리터, 상기 바이트 코드를 컴파일하여 네이티브 코드를 생성하는 컴파일러, 상기 컴파일된 네이티브 코드의 메모리를 관리하는 코드 버퍼 관리자를 포함하며, 상기 바이트 코드 인터프리터 또는 네이티브 코드가 수행중인 제 1 메소드에 대해 상기 제 1 메소드가 제 2 메소드를 호출하는 경우, 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하고, 상기 제 2 메소드에 대한 제 2 스택 프레임을 상기 스택에 추가하며, 상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하며, 상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성이다.

본 발명의 일 실시예에 따른 디지털 장치는 이종의 자바 메소드를 실행하는 자바 가상 머신을 저장하는 보조 기억부, 상기 자바 가상 머신에 메모리를 할당하는 주기억부, 상기 자바 가상 머신과 데이터를 송수신하는 입출력부, 및 상기 주기억부와 상기 자바 가상 머신 및 상기 입출력부를 제어하는 제어부를 포함하며, 상기 자바 가상 머신은 바이트 코드를 실행하는 인터프리터, 상기 바이트 코드를 컴파일하여 네이티브 코드를 생성하는 컴파일러, 상기 컴파일된 네이티브 코드의 메모리를 관리하는 코드 버퍼 관리자를 포함하며, 상기 바이트 코드 인터프리터 또는 네이티브 코드가 수행중인 제 1 메소드에 대해 상기 제 1 메소드가 제 2 메소드를 호출하는 경우, 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하고, 상기 제 2 메소드에 대한 제 2 스택 프레임을 상기 스택에 추가하며, 상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하며, 상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성이다.

상기 바이트 코드 또는 네이티브 코드로 구성된 메소드의 실행 정보는 하나의 스택 프레임에 저장되며, 상기 스택 프레임을 하나의 스택에 저장된다. 또한, 상기 스택은 하나의 쓰레드의 수행을 나타내며, 하나 또는 그 이상의 쓰레드가 수행될 수 있다.

본 명세서에서 사용하게 되는 용어를 정의하면 다음과 같다.

- 자바 어플리케이션

자바 어플리케이션은 자바의 객체들을 이용하여 자바 가상 머신(Java Virtual Machine)에서 실행되는 프로그램을 의미한다. 자바 어플리케이션에는 애플릿(Applet), 엑슬릿(Xlet), 미들렛(Midlet) 등이 존재한다.

- 자바 컴파일러

자바 컴파일러는 하드웨어 독립적인 바이트 코드를 하드웨어에 맞는 기계어로 변환한다. 자바 컴파일러로는 JIT(Just-In-Time) 컴파일러라 하여, 자바 가상 머신 내에 설치된 컴파일러이다. 이외에도 AOT(Ahead-On-Time) 컴파일러가 있다. 이하 본 명세서에서는 JIT 컴파일러를 중심으로 설명하지만, 이는 일 실시예이며, 바이트 코드를 컴파일시키는 모든 컴파일러에 적용 가능하다.

- 애플릿(Applet)

자바 애플릿이란 HTML 페이지에 포함되어 자바 호환(java-compatible) 웹 브라우저 에 의해 실행될 수 있는 자바 프로그램으로, 자바 호환 웹 브라우저가 자바 애플릿이 포함된 HTML 페이지를 보여줄 때, 웹 서버쪽에 있는 자바 애플릿 코드를 다운로드 한 후 브라우저 내의 특정 영역에서 실행하게 된다.

애플릿은 웹 브라우져에서 수행되는 임베이디드 어플리케이션이다. 애플릿이 실행되고 있는 그 페이지에서 애플릿이 디스플레이되는 영역을 제공하기 때문에 애플릿은 자신을 포함하고 있는 웹 페이지와 밀접히 관련되어 있다.

애플릿의 라이프-사이클의 네 가지 상태가 있는데, 로딩 상태(Loaded), 중지(Stopped), 시작(Started), 소멸(Destroyed)가 있다. 로딩 상태는 애플릿의 인스턴스가 생성되었지만 아직 초기화는 되지 않은 상태를 의미하고, 중지 상태는 애플릿이 초기화 되었지만 실행중이 아닌 상태이다. 시작은 애플릿이 활성화된 상태이며, 소멸은 애플릿이 종료되었고, 애플릿 인스턴스는 모든 자원을 반납하고 가비지 수집에 의해 메모리가 회수되길 기다리는 상태를 의미한다.

- 미들렛(Midlet)

미들렛은 모바일 정보 장치 프로파일(Mobile Information Device Profile, MIDP) 어플리케이션이다. 미들렛은 애플릿과 달리 웹 브라우져에 의해 관리되는 것이 아니고, 양방향 페이져나 핸드폰에 탑재되는 어플리케이션을 제어하기 위해 특별히 만들어진 소프트웨어에 의해 관리된다. 어플리케이션이 실행되는 도중 전화가 온다면, 어플리케이션으로 인해 전화 수신이 방해받아서는 안될 것이다. 그러므로 이런 경우, 무선 기기에서 실행되는 어플리케이션의 경우 이러한 외부적인 관리가 적절하다.

- 엑슬릿(Xlet)

엑슬릿은 본래 자바 TV API의 일부분이었으나, 개인 기초 프로파일(Personal Basis Profile, PBP)과 그 슈퍼셋인 개인 프로파일(Personal Profile, PP)에 의해 사용되고 있다. 소멸시에는 엑슬릿이 종료되며, 사용한 자원을 반납하고 가비지 수집되기를 기다리는 상태가 된다.

- 스택 프레임

스택 프레임은 메소드들을 실행하기 위해 필요한 정보를 저장하는 스택에 메소드 단위로 저장되는 것을 의미한다. 스택 프레임에는 해당 메소드를 실행하기 위해 필요한 프로그램 카운터, 로컬 변수, 복귀 주소(return address)등으로 구성된다. 프로그램 카운터는 해당 메소드의 어느 명령어를 실행할 것인지를 가리키는 포인터이고, 복귀 주소는 해당 메소드를 실행한 후, 복귀할 주소를 의미한다. 흔히, A라는 메소드가 B라는 메소드를 호출한 경우, A 메소드에서 B 메소드를 호출하는 그 위치는 A 메소드의 프로그램 카운터가 지칭할 수 있고, B 메소드가 그 실행을 완료한 뒤 복귀할 A 메소드의 특정 위치가 될 수 있다. 이하, 본 명세서에서 복귀 스택 프레임(return stack frame)은 특정 메소드의 스택 프레임이 실행을 완료할 경우, 복귀하게 되는, 즉 상기 특정 메소드를 호출한 메소드의 스택 프레임을 의미한다. 상기 호출한 메소드는 복귀 메소드라고 부른다.

한번의 메소드 호출는 하나의 스택 프레임을 형성하게 되며, 하나의 메소드를 여러 메소드에서 호출할 경우, 스택 프레임은 그 호출 회수에 따라 증가할 수 있다. 따라서, 본 명세서에서는 스택 프레임은 하나의 메소드에 대해 하나 이상 존재함을 의미한다.

한편 바이트 코드 스택 프레임은 바이트 코드로 구성된 메소드의 스택 프레임을 의미하며, 네이티브코드 스택 프레임은 컴파일러에 의해 기계어로 변환된 메소드의 스택 프레임을 의미한다.

도 5는 본 발명의 일 실시예에 따른 자바 가상 머신의 구성도이다. 라이브러리 클래스(501)는 자바 실행에 있어 필요한 클래스들의 집합이다. 어플리케이션 클래스(503)는 라이브러리 클래스(501)에 포함되지 않는, 사용자가 개발하거나 작성한 클래스를 의미한다. 어플리케이션 클래스(503)도 라이브러리화 하여 라이브러리 클래스(501)에 추가할 수 있으므로, 라이브러리 클래스와 어플리케이션 클래스를 크게 구분지을 필요는 없다. 이러한 클래스를 실행시키기 위해서는 클래스 로더(502)를 통해 메모리에 저장하는 과정이 필요하다. 클래스 링커(504)는 메모리에 올라온 클래스의 기능을 연결시킨다. 클래스 링커(504)를 통해 제공되는 네이티브 코드(530)를 인터프리터가 사용할 수 있다. 인터프리터(510)와 컴파일러(520)는 바이트 코드를 실행시키는 역할을 한다.

본 명세서에서는 네이티브 코드와 인터프리터된 코드를 실행함에 있어서, 상호 운용성을 높이기 위해 통일된 포맷으로 상기 코드들의 메소드를 스택을 저장하게 한다. 한편, 코드 버퍼 관리자(540)를 통해 컴파일된 네이티브 코드 메모리의 현재 상태를 체크하여 인터프리터 코드를 컴파일 시켜 실행시키거나, 또는 컴파일된 코드를 디컴파일(decompile)하여 인터프리터를 통해 실행시킬 수 있다. 코드 버퍼 관리자(540)는 현재 메모리 상태를 체크하여, 컴파일 코드에 할당할 메모리의 여유 공간을 체크하여, 자바 가상 머신이 코드 수행을 인터프리터로 할 것인지, 또는 컴파일러를 통해 할 것인지에 대한 정보를 제공한다.

전반적인 실행 흐름은 다음과 같다. 자바 가상 머신이 제 1 메소드를 인터프리터 방식으로 실행시킬 경우, 이 메소드를 구성하는 바이트 코드, 즉 명령어(instruction)를 페치(fetch)하여 수행한다. 명령어 수행 후에는 다음 명령어 수행을 위해 PC(Program Counter)를 수정하고 또 그 다음 명령어를 수행하는 방식으로 진행된다. 이러한 명령어 해석 과정에서 다른 제 2의 메소드를 호출하는 경우 그 명령어가 어떤 코드인가에 따라, 혹은 시스템의 상황에 따라 달리 처리할 수 있다. 호출할 제 2 메소드가 인터프리터 코드인 경우, 스택 프레임을 작성하여 해당 제 2 메소드에 대한 실행을 계속한다. 스택 프레임에는 상기 제 2 메소드가 인터프리터 코드임을 나타내는 정보를 저장할 수 있으며, 이러한 스택 프레임의 구조는 도 6에서 상세히 살펴본다. 그리고 호출할 제 2 메소드가 네이티브 코드인 경우, 역시 스택 프레임을 작성하여 해당 제 2 메소드에 대한 실행을 계속한다. 스택 프레임에는 상기 제 2 메소드가 네이티브 코드임을 나타내는 정보를 저장할 수 있다. 앞서 설명한 바와 같이 네이티브 코드 역시 인터프리터로 수행하는 바이트 코드와 같은 포맷으로 같은 스택에 프레임으로 저장된다. 한편, 실행의 편의와 속도를 고려하여 인터프리터 코드라 하여도 컴파일 시켜서 동작시킬 수 있다. 인터프리터 코드는 전술한 바와 같이 메모리의 공간은 적게 차지하지만, 실행 속도가 느린 반면, 컴파일한 네이티브 코드는 메모리의 공간은 바이트 코드보다 많이 차지하지만 실행 속도가 빠르다. 따라서 코드 버퍼 메모리에 여유 공간이 많은 경우, 또는 자주 사용하 게 되는 메소드인 경우, 컴파일시켜서 네이티브 코드로 유지하는 것이 시스템의 성능을 높일 수 있다. 또한 컴파일된 코드라 하여도, 당분간 사용할 가능성이 없거나, 현재 메모리 공간이 부족한 경우에는 이 코드를 코드 버퍼 메모리에서 제거하고, 인터프리터를 통해 수행할 수 있다.

호출할 메소드가 바이트 코드이며, 이를 컴파일을 통해 수행하고자 할 경우, 자바 가상 머신은 컴파일러(520)에 코드를 컴파일 할 것을 요청한다. 컴파일러(520)는 코드 버퍼 관리자(540)에 컴파일에 필요한 메모리의 여유 공간이 존재하는지를 검토한다. 만약 메모리 공간이 없다면, 코드 버퍼 관리자는 이전에 컴파일러(520)를 통해 컴파일 한 메소드 중에서 하나를 디컴파일(decompile)한다. 디컴파일이란, 컴파일되어 메모리에 로딩된 메소드를 메모리에서 제거하고, 이를 바이트 코드를 통해 인터프리터로 실행시키는 것을 의미한다. 따라서 메모리에서 네이티브 코드가 차지하는 메모리가 코드 버퍼에서 제거된다. 이 과정에서 필요한 메모리 공간이 확보되면, 컴파일을 수행하여 제 2 메소드를 실행한다. 물론 제 2 메소드 역시 하나의 스택에 프레임으로 저장되어 실행된다.

디컴파일을 통해 메모리에서 제거된 제 3의 메소드에 대한 정보는 여전히 스택에 존재한다. 따라서 컴파일된 메소드였으나 디컴파일된 경우, 제 3 메소드에 대한 스택 프레임은 정보를 수정한다. 제 3 메소드는 네이티브 코드가 아닌 인터프리트 코드, 즉 바이트 코드임을 명시한다. 이후, 상기 제 3 메소드에 대한 스택 프레임이 실행할 순서가 오게 되면, 바이트 코드를 읽어서 인터프리터를 통해 상기 제 3 메소드를 실행하게 된다.

물론, 상기 제 3 메소드를 실행함에 있어서, 전술한 과정과 같이 다시 컴파일하여 컴파일된 코드를 실행할 수도 있다. 이는 메모리의 여유 공간과 프로세싱 타임이 어떠한가에 따라, 컴파일러를 통해 실행할 수도 있고, 바이트 코드로 인터프리터를 통해 실행할 수 있다.

메소드(method)는 객체 지향 프로그램에서 어떤 기능을 수행하는 것이다. 메소드는 구조적인 프로그램에서 기능을 나타내는 함수의 개념을 포함하지만, 함수의 개념보다는 넓다. 메소드는 객체 지향 프로그램에서 객체의 기능을 나타내는 것으로, 객체 지향 프로그램은 객체와 이들에 대한 정의, 그리고 객체 또는 클래스의 메소드들로 구성되므로, 메소드의 호출은 객체 지향 프로그램 전반에 걸쳐 나타난다. 통상의 함수와 유사하게 메소드는 다른 제 2의 메소드를 호출할 수 있으며, 호출된 제 2의 메소드 역시 다른 제 3의 메소드를 호출할 수 있다. 메소드를 호출할 경우, 이 메소드를 실행하기 위해서는 스택에 프레임의 형태로 저장하는 것이 필요하다. 메소드를 호출하여 특정 기능을 수행한 후에는 그 메소드를 호출한 원래의 메소드로 돌아가야 하며, 이러한 메커니즘의 구현은 스택을 통해 이루어진다.

따라서, 메소드를 실행시키기 위해서는 명령어를 실행하는 스택에 상기 메소드에 대한 정보를 저장하는 과정이 필요하다. 프레임(frame) 또는 스택 프레임(stack frame)은 하나의 메소드에 대한 정보를 스택에 저장하기 위해 특정 포맷에 따라 구성한 것을 의미한다. 실행 스택에는 이들 메소드를 실행하기 위한 스택 프레임이 하나 이상 존재할 수 있다. 한편, 자바는 멀티쓰레드(multi-threaded) 기반이므로, 쓰레드는 하나 이상일 수 있다. 따라서, 각 쓰레드마다 스택이 주어진다. 여러 쓰 레드에서 하나의 동일한 메소드를 호출할 경우에도, 각 쓰레드를 위한 실행[명령어] 스택에는 상기 하나의 메소드에 대한 스택 프레임이 별도로 존재한다.

도 6은 본 발명의 일 실시예에 따른 메소드 실행에 관련된 스택 프레임의 구조를 보여주는 구성도이다.

102, 103은 메소드 실행에 필요한 변수에 대한 정보를 저장한다. 111은 이전 프레임을 가리키는 프레임 포인터(Frame pointer)이다. 이전 프레임이란, 전술한 복귀 프레임을 의미하며, 111은 메소드를 호출한 메소드에 대한 스택 프레임에 대한 위치 정보를 가지고 있다. 이전 프레임에 대한 정보를 가지고 있어야, 메소드의 기능을 수행하면, 이 메소드를 호출한 프레임(복귀 프레임, 다른 메소드의 프레임)으로 돌아가야 하므로, 프레임 포인터가 필요하다. 다음은 프로그램 카운터에 대한 정보를 가진다. 도 6에서는 바이트 코드 PC(112)와 컴파일된 코드 PC(113)을 각기 나누어 저장하며, 인터프리터 코드인가 혹은 네이티브 코드인가에 따라 달리 저장하도록 한다. 한편 구현 방법에 따라 프레임 종류(115)를 기록하여 이 메소드가 컴파일된 코드인지, 인터프리터 코드인지에 대한 정보를 제시할 수 있다. 또다른 방법으로는 프레임 종류(115)를 기록하지 않고 컴파일된 코드 PC(113) 값을 NULL로 기록함으로써 바이트 코드로 수행되는 코드임을 표시할 수도 있다. 편의상 본 발명에서는 프레임 종류를 기록하는 방법에 대해 기술한다. 프레임 종류(115)를 통해 인터프리터 코드인지 네이티브 코드인지 알 수 있으므로, 112와 113은 프로그램 카운터(PC)로 통합하여 구현할 수도 있다. 그외에 메소드 실행에 필요한 정보(117)와 수행중의 임시값들을 [명령어를] 저장하는 오퍼랜드(operand) 스택(119)을 저장한다. 이는 일 실시예에 해당하며, 스택 프레임은 이러한 정보 이외의 다른 정보를 포함할 수 있으며, 도 6의 항목들은 다른 명칭으로 제시될 수도 있다.

도 6에서 살펴본 이러한 자바 스택의 구조를 동일하게 사용함으로써, 프로그램 수행중 여러 이종의 코드로 구성된 메소드 간에 컨트롤의 이동이 자유롭다. 또한 컴파일한 코드와 인터프리터를 통한 코드간의 전환이 프레임의 종류 부분만을 수정하여 이루어지므로, 시스템의 성능에 따라 어떤 방식으로 실행할 것인지를 선택할 수 있다. 한편, 공통된 자바 스택을 사용하므로, 인터프리터 코드와 컴파일된 코드간에 메소드 호출과 복귀, 그리고 예외 처리가 가능하다.

도 7은 본 발명의 일 실시예에 따른 메소드 호출에 의한 스택 프레임 생성을 보여주는 구성도이다. 도 7은 이종의 코드사이에 발생하는 메소드 호출을 보여주고 있다. 먼저 A라는 메소드는 바이트 코드로 존재하며, 이 메소드에 대한 스택 프레임은 151과 같다. A 메소드는 B 메소드를 호출하는데, B 메소드는 컴파일된, 네이티브 코드이다. B 메소드에 대한 스택 프레임은 152와 같다. B 메소드는 네이티브 코드이지만 A 메소드의 스택 프레임과 동일한 포맷으로 하나의 스택 내에 저장된다. B 메소드는 다시 C 메소드를 호출하는데, C 메소드는 바이트 코드다. C 메소드에 대한 스택 프레임은 153과 같다. 도 7과 같이 스택 프레임이 하나의 스택내부에 존재하며, 공통된 포맷을 가지게 되므로, 메소드 호출에 따른 컨트롤의 이동이 자유롭다. 즉, C 메소드의 기능이 완료하면 컨트롤은 C 메소드를 호출한 B 메소드로 복귀한다. 그리고 이 B 메소드의 기능이 완료하면, 역시 컨트롤은 A 메소드로 복귀한다. 이는 점프(jump) 명령어와 같이 특정 위치로 프로그램의 플로우를 이동하는 명 령어를 통해 가능하다. 점프(jump) 명령어는 일 실시예이며, 시스템의 구성 또는 기계어의 구성에 따라 고(go) 명령어등 다양하게 존재한다.

도 7과 같이 하나의 스택 내에서 메소드를 호출하는 경우에는, 그 기능을 다한 메소드에 대한 스택 프레임은 제거된다. 예를 들어, 도 7에서 C 메소드에 대한 스택 프레임은 C 메소드가 그 기능을 완료하고 B 메소드로 복귀할 경우에는 C 메소드에 대한 스택 프레임이 제거된다. 스택 프레임이 제거된다는 것은 그 스택 프레임이 차지하는 메모리 영역을 가용 공간으로 인식하도록 하여, 추후 다른 메모리 요청이 들어올 경우, 다른 데이터 혹은 다른 스택 프레임이 차지할 수 있음을 의미한다.

본 발명의 또다른 장점은 인터프리터 자체의 코드로 컴파일러에 의해 생성된 네이티브 코드에서 직접 분기할 수 있다는 것이다. 예를 들어서, 예외 처리(exception handling)하는 과정이 매우 복잡한데, 이러한 처리를 수행하는 코드를 컴파일러가 직접 생성하지 않고 인터프리터에 존재하는 코드로 분기하도록 코드를 생성할 경우 생성되는 코드의 양을 상당히 줄일 수 있다. 도 8은 본 발명의 일 실시예에 따른 이종의 코드간에 메소드 호출을 통해 컨트롤이 이동되는 과정을 보여주는 블록도이다. 도 8은 인터프리터 자체의 기계어 코드(인터프리터 자체는 기계어로 수행됨)와 컴파일러로 생성된 네이티브 코드의 두가지 기계어 코드를 나타내며, 인터프리터에서 네이티브 코드를 호출한 다음 네이트 코드의 수행중에 예외 상황(exception)이 발생한 경우 인터프리터에 존재하는 예외 처리(exception handling)을 수행하는 과정을 나타낸다. 네이티브 코드에서 예외 처리(exception handling)가 필요할 때 네이티브 코드내에서 처리를 하지 않고 인터프리터내에 존재하는 예외 처리 루틴 (null_pointer_exception이란 주소를 가짐)으로 컨트롤이 이동한다(S10). 이후 null_pointer_exception에 대한 처리를 수행하고, goto 문을 통해 다시 네이티브 코드로 돌아갈 수 있다(S20).

도 9는 본 발명의 일 실시예에 따라 바이트 코드와 네이티브 코드간에 공유되는 레지스터를 보여주는 블록도이다. 컴파일된 네이티브 코드와 바이트 코드 인터프리터 사이에는 서로의 프로그램 카운터에 대한 정보(34, 35)와 스택의 톱(Top)이 어디인지를 알리는 레지스터(36)가 존재한다. 네이티브 코드를 생성하는 컴파일러, 예를 들어 JIT-컴파일러는 이러한 값을 가지고 컴파일된 네이티브 코드를 생성하여 네이티브 코드가 레지스터를 공유할 수 있게 한다. 레지스터를 공유하는 이유는 어느 순간에도 네이티브 코드가 수행되다가도 인터프리터로 수행을 빠르게 전환할 수 있도록 하기 위한 것이다.

도 10은 본 발명의 일 실시예에 따른 예외 처리 루틴의 수행을 보여주는 블록도이다. 바이트 코드 인터프리터는 루프코드를 가지고 있다(41). 그리고 레이블(label)과 서브루틴(subroutine)들이 42에서 47까지 예시적으로 나타나 있다. 도 10에 나타나는 서브루틴들은 예외 처리(Exception handling)을 위한 서브루틴들이다. JIT-컴파일러는 컴파일할 코드가 인터프리터에서 제공하는 서브루틴을 이용할 수 있도록 네이티브 코드를 컴파일한다. 이후 네이티브 코드에서 도 10에 나타난 예외 처리 서브 루틴을 호출하는 경우, 컨트롤이 컴파일된 코드에서 바이트 코드로 이동하여 어떤 루틴으로 점프하여야 하는지에 대한 정보를 얻는다. 이 정보를 가지고 바이트 코드에서 정의한 서브루틴을 수행한다. 이러한 서브 루틴은 수행 종료시 현재 스택 프레임에 저장된 프로그램 카운터를 참조하여 어디로 분기할 지를 결정함으로써 본래 수행되던 메소드가 계속하여 수행할 수 있다.

도 11은 본 발명의 일 실시예에 따른 메소드 호출에 따른 스택의 구성을 보여주는 블록도이다. 도 11은 A 메소드가 B 메소드를 호출하는 과정을 보여준다. 먼저 A 메소드의 스택 프레임(50)을 살펴보면, 로컬 변수들(local var()), 이전 프레임 포인터와 컴파일 코드 프로그램 카운터(52)와 컴파일 프레임(53)및 오퍼랜드 스택(54)으로 구성된다. 종류 필드(53)은 A 메소드가 컴파일된 코드에 대한 스택 프레임임을 나타내고 있다. 프로그램 카운터(52)에서는 현재 어느 명령어를 수행하는지, 앞으로 수행할 명령어의 위치를 가리키고 있다. 도 11에서 프로그램 카운터(52)는 Call method_B라는 명령어를 가리키고 있다. 이 명령어가 지시하는 대로 B 메소드를 호출해야 하므로, B 메소드에 대한 스택 프레임을 생성하여야 하며 그 구성은 A 메소드의 스택 프레임(50)과 같은 포맷으로 구성된다.

이전 프레임 포인터(57)은 B 메소드를 호출한 A 메소드의 스택 프레임의 시작을 가리킨다. B 메소드는 바이트 코드로 인터프리터를 통해 수행되므로 바이트 코드 프로그램 카운터(58)에서 명령어 위치를 나타내고 있다. 그리고 바이트 코드 프레임임을 종류 필드(59)를 통해 알 수 있다. B 메소드의 수행이 끝나면 57의 이전 프레임 포인터를 통해 A 메소드로 복귀할 수 있으며, 명령어 스택에서는 계속 명령어를 읽어들여서 수행할 수 있다.

도 11에서는 A 메소드의 경우 바이트 코드 PC가 NULL값을, 그리고 B 메소드에서는 컴파일 코드 PC가 NULL 값을 가지고 있다. A 메소드의 경우, 컴파일된 코드이지만, 메모리의 여유 공간의 문제가 발생할 경우, 이는 다시 바이트 코드로 수행할 수 있다. 즉, 컴파일된 코드를 메모리에서 제거하는 대신에, 스택 프레임은 그대로 유지하며, 컴파일 코드 PC를 바이트 코드 PC로 바꾸고, 컴파일된 프레임을 알리는 종류 필드(53)을 바이트 코드 프레임을 알리도록 바꾸며, 프로그램 카운터 위치(51)를 바이트 코드 PC를 가리키게 하면, 이후 B 메소드를 수행한 후 다시 A 메소드로 복귀할 경우, 이전의 컴파일된 코드가 아니라 바이트 코드이어도 수행이 가능하다. 따라서 스택 프레임의 일부 정보만 수정하면 컴파일된 코드와 바이트 코드 사이의 전환이 쉽게 이루어져, 시스템 성능에 따라 달리 선택할 수 있다.

도 12는 본 발명의 일 실시예에 따른 코드 버퍼에서 메모리 할당을 보여주는 순서도이다. 도 12에서는 자바 가상 머신에 포함된 JIT 컴파일러를 일 실시예로 하여 설명하고자 한다. 코드 버퍼 관리자는 JIT 컴파일러로부터 컴파일될 메소드에 할당할 버퍼를 요청받는다(S101). 코드 버퍼 관리자는 메모리에 가용 공간이 존재하는지, 즉, 현재의 공간에 컴파일될 메소드가 저장될 메모리 공간이 충분한지 검토한다(S102). 메모리 공간이 충분하다면, 코드 버퍼 관리자는 메모리 공간을 JIT 컴파일 메소드에 할당한다(S118). 메모리 공간이 충분하지 않다면 메모리 공간을 확보하기 위한 작업을 수행한다. 먼저 일시적으로 모든 쓰레드를 중지한다(S103). 자바는 멀티쓰레드 기반이므로, 하나 이상의 쓰레드가 존재할 수 있다. 따라서, 각 쓰레드마다 스택을 가지므로 스택도 하나 이상이 존재할 수 있다. 그리고 실행 스택(Execution stack)은 현재 실행중인 쓰레드의 스택을 의미한다.

코드 버퍼 관리자는 쓰레드 실행 스택의 탑에 있는 JIT 컴파일러로 컴파일한 메소 드를 'non-disposable'(제거불가)로 표시한다(S104). 쓰레드 실행 스택의 탑에 있는 메소드는 곧 실행이 예상되는 메소드이므로, 메모리에서 제거하면 오히려 성능에 악영향을 미치기 때문이다. 다음으로 쓰레드 실행 스택의 탑이 아닌 메소드들중에 컴파일된 메소드는 'last-disposable'(마지막에 제거)로 표시한다(S105). 이는 현재 실행 중인 쓰레드에 있는 메소드는 당장은 아니지만 곧 실행할 가능성이 높기 때문이다. 그러므로 다른 스택에 제거할 메소드가 없는 경우 제거를 고려하기 때문이다. 이렇게 실행 스택에 있는 메소드들에 표시를 한 후에 메모리 관리자는 JIT 컴파일러가 컴파일한 네이티브 코드로 구성된 메소드 중에서 표시되지 않은 메소드를 검색한다(S106). 검색결과(S110) 표시안된 JIT-메소드(JIT 컴파일러로 컴파일한 메소드)가 존재하는 경우, 그 메소드의 메모리를 코드 버퍼에서 제거한다(S115). 여기서 검색된 메소드가 둘 이상인 경우, 어떤 메소드를 제거할 것인지는 여러 가지 판단 기준에 따라 이루어진다. 예를 들어 앞으로 늦게 사용할 가능성이 있는 메소드를 선택할 수도 있고, 코드의 크기가 가장 큰 메소드를 선택할 수도 있다. 또한 여러 메소드를 삭제할 수도 있다. 코드 버퍼에서 메모리를 제거하였기 때문에 메모리에 가용 공간이 증가하게 되므로, 이 새로이 컴파일될 메소드에 할당할 만큼 충분한지 검토한다(S116). 그 결과 충분하다면, 모든 쓰레드를 재개하고(S117), 해당 가용 메모리 공간을 새로이 컴파일될 메소드에 할당한다(S118).

한편, S110 단계에서 표시안된 JIT-메소드가 존재하지 않는 경우, 또는 이러한 메소드를 제거하였어도 여전히 메모리에 가용 공간이 부족한 경우(S116), 'last-disposal'(마지막에 제거)로 표시한 메소드의 코드 버퍼를 제거한다. 이렇게 메소 드의 코드 버퍼를 제거한 후, 가용 공간을 검토한다(S112). 그 결과 가용 공간이 새로이 컴파일될 메소드에 할당할 만큼 충분하다면, S117단계로 간다. 한편, 여전히 가용 공간이 부족하다면, 모든 쓰레드를 제개하고, 메모리 공간 요청에 대해 여유 공간이 없음을 알린다(S113).

이러한 과정은 스택 프레임이 공통된 포맷으로 존재하므로, 컴파일된 코드가 메모리에서 제거되어도, 상기 코드의 스택 프레임이 컴파일된 코드임을 알리는 부분(Frame 종류)을 바이트 코드임을 알리도록 수정하면, 다시 그 메소드를 재개할 때에는 그 메소드는 바이트 코드를 통해 인터프리터로 실행할 수 있다. 또한 그 메소드를 재개할 때, 다시 메모리에 공간이 있을 경우, 컴파일 하여 수행할 수 있는데, 컴파일 할 경우에는, 상기 바이트 코드임을 알리는 부분을 다시 컴파일된 코드임을 알리도록 수정할 수 있다.

한편, 하나의 메소드에 대해서 다수의 스택 프레임이 존재할 수 있다. B라는 메소드를 A라는 메소드가 호출할 수 있으며, C라는 메소드가 호출할 수도 있다. 이 경우, B 메소드에 대한 스택 프레임은 A 메소드가 호출해서 발생한 스택 프레임(B1)과 C 메소드가 호출해서 발생한 스택 프레임(B2) 두 개가 존재할 수 있다. 따라서 도 12의 과정에서 B 메소드가 컴파일된 네이티브 메소드인데, B 메소드가 디컴파일 되어 메모리 코드 버퍼가 제거된다면, 상기 B1, B2 스택 프레임의 프레임 종류 필드를 모두 바이트 코드 스택 프레임으로 수정하는 과정이 필요하다.

도 13은 본 발명의 일 실시예에 따른 자바 가상 머신이 탑재된 디지털 장치의 구성도이다.

본 실시예에서 사용되는 '~부'라는 용어, 즉 '~모듈' 또는 '~테이블' 등은 소프트웨어, FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, 모듈은 어떤 기능들을 수행한다. 그렇지만 모듈은 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. 모듈은 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 모듈은 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 모듈들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 모듈들로 결합되거나 추가적인 구성요소들과 모듈들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 모듈들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.

자바 가상 머신(500)은 디지털 장치내의 특정 기능을 수행한다. 자바 가상 머신은 디지털 티비의 메뉴를 보여주는 기능을 수행할 수 있고, 수신된 방송 정보를 보여주는 기능을 수행할 수 있다. 또한, 디지털 티비가 인터넷에 연결되었을 때, 인터넷을 사용할 수 있도록 브라우저의 역할을 할 수 있으며, 인터넷의 애플릿, 미들릿, 엑슬릿 등을 수행하는 기능을 제공할 수 있다. 이외에도, 컴퓨터, 노트북에서는 자바 어플리케이션을 수행하는 기능을 제공한다. 이외에도, 자바 가상 머신은 여러 디지털 장치에 임베디드(embedded)될 수 있는데, 휴대폰, PDA와 같은 정보 기 기 외에도, 임베디드 자바의 형태로, 냉장고, 전자레인지와 같은 디지털 가전 제품이 이에 해당한다. 현재 자바 가상 머신과 이를 이용한 임베디드 자바는 여러 디지털 장치에서 인터넷과 유무선 통신, 홈 네트워크, 유비쿼터스 등의 기능을 수행하고 있다.

주기억부(910)은 자바 가상 머신이 어플리케이션을 수행하기 위한 스택과 버퍼등을 구현하도록 메모리를 제공한다. 주기억부는 통상적으로 램(Random Access Memory)을 사용하며, DRAM, SRAM, SDRAM 등 다양하게 존재한다. 본 명세서에서의 주기억부는 램과 같은, 휘발성 있는 메모리를 포함한다. 도면에 미도시 되었으나, 보조기억부를 둘 수 있다. 보조기억부는 자바 가상 머신을 코드형태로 저장하는 공간을 의미한다. 이는 칩으로 구현될 수도 있고, 프로그램 코드로 구현될 수 있다.

입출력부(920)는 자바 가상 머신에 데이터를 송수신하는 기능을 한다. 자바 가상 머신에 어떤 어플리케이션을 수행할 것인지, 혹은 사용자가 리모트컨트롤, 키보드, 키패드, 마우스 등의 입력 장치를 통해 자바 어플리케이션에 어떤 명령을 내리는 경우, 이러한 입력 정보를 자바 가상 머신에 송신한다. 이러한 입력를 자바 가상 머신이 처리하여 그 결과를 디스플레이부, 스피커와 같은 외부 출력 장치에 보낼 수 있다. 또한, 이러한 결과가 통신을 통해 외부의 기기로 전송될 필요가 있는 경우, 입출력부를 통해 이 데이터는 송신될 수 있다.

제어부(930)는 상기 구성요소들 간의 정보를 제어하고, 자바 가상 머신의 수행을 제어하는 기능을 수행한다. 통상 CPU와 같은 중앙 처리 장치가 이러한 제어부의 역할을 할 수 있다.

본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구의 범위에 의하여 나타내어지며, 특허청구의 범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

본 발명을 구현함으로써 컴파일된 코드와 인터프리터를 통해 실행하는 코드간의 상호 운용성을 증가시키며, 이종의 코드 간에 컨트롤의 이동이 가능하다.

본 발명을 구현함으로써 컴파일된 코드를 사용하거나, 혹은 인터프리터를 통해 바이트 코드를 사용할 수 있으며, 이에 따라 시스템을 효율적으로 이용할 수 있다.

Claims (31)

1. 제 1 메소드가 제 2 메소드를 호출할 경우 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하는 단계;

   상기 제 2 메소드를 실행하기 위한 제 2 스택 프레임을 스택에 추가하는 단계; 및

   상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하는 단계를 포함하며,

   상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성인, 이종의 자바 메소드를 실행하는 방법.
2. 제 1항에 있어서,

   상기 제 1 또는 제 2 메소드는 인터프리터를 통해 실행하는 바이트 코드 또는 컴파일러를 통해 기계어로 변환된 네이티브 코드 중 어느 하나인, 이종의 자바 메소드를 실행하는 방법.
3. 제 1항에 있어서,

   상기 제 1 스택 프레임은

   제 1 메소드의 현재 실행 위치에 대한 필드, 상기 제 1 메소드를 호출한 복귀 메소드에 대한 정보를 포함하는 복귀 스택 프레임의 위치 필드 및 상기 제 1 메소드를 실행하는데 필요한 데이터를 포함하는, 이종의 자바 메소드를 실행하는 방법.
4. 제 3항에 있어서,

   상기 제 1 스택 프레임은

   실행 위치에 대한 필드는 바이트 코드 프로그램 카운터와 네이티브 코드 프로그램 카운터를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
5. 제 1항에 있어서,

   상기 제 1 메소드 또는 제 2 메소드가 바이트 코드인 경우, 상기 제 1 메소드 또는 제 2 메소드를 컴파일러를 통해 네이티브 코드로 변환하는 단계; 및

   상기 제 1 스택 프레임 또는 제 2 스택 프레임을 구성하는 메소드의 종류가 네이티브 코드 스택 프레임임을 나타내도록 수정하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
6. 제 1항에 있어서,

   상기 제 1 메소드가 네이티브 코드인 경우, 이 코드가 차지하는 메모리를 제거하는 단계 및

   상기 제 1 스택 프레임을 구성하는 메소드의 종류가 바이트 코드 스택 프레임임을 나타내도록 수정하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
7. 제 1항에 있어서,

   상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하는 단계는

   상기 제 2 메소드의 종류가 바이트 코드일 경우 상기 바이트 코드를 컴파일러를 통해 기계어로 변환하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
8. 제 7항에 있어서,

   상기 바이트 코드를 컴파일러를 통해 기계어로 변환하는 단계는,

   상기 컴파일러를 통해 변환되는 기계어 코드를 저장할 코드 버퍼의 메모리 공간이 부족할 경우 상기 코드 버퍼에서 네이티브 코드 형태의 제 3 메소드를 검색하는 단계;

   상기 검색 결과, 제 3 메소드가 존재할 경우, 상기 제 3 메소드를 구성하는 네이티브 코드가 차지하는 메모리를 코드 버퍼에서 제거하는 단계; 및

   상기 제거로 인해 가용가능한 메모리의 공간을 상기 제 2 메소드에 할당하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
9. 제 1항에 있어서,

   상기 제 3 스택 프레임을 검색하는 단계는

   상기 메모리에 존재하는 스택에서 네이티브 코드 스택 프레임인 제 3 스택 프레임을 검색하는 단계를 포함하며,

   상기 스택은 현재 실행중인 쓰레드의 스택이 아닌, 이종의 자바 메소드를 실행하는 방법.
10. 제 6항 내지 제 9항 중 어느 한 항에 있어서,

    상기 제 3 메소드를 수행하는 모든 스택 프레임의 종류가 바이트 코드 스택 프레임임을 나타내도록 수정하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
11. 제 1항에 있어서,

    상기 제 2 메소드의 실행이 완료하면 상기 제 1 스택 프레임으로 복귀하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
12. 바이트 코드를 실행하는 인터프리터;

    상기 바이트 코드를 컴파일하여 네이티브 코드를 생성하는 컴파일러;

    상기 컴파일된 네이티브 코드의 메모리를 관리하는 코드 버퍼 관리자를 포함하며,

    상기 바이트 코드 인터프리터 또는 네이티브 코드가 수행중인 제 1 메소드에 대해

    상기 제 1 메소드가 제 2 메소드를 호출하는 경우, 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하고, 상기 제 2 메소드에 대한 제 2 스택 프레임을 상기 스택에 추가하며,

    상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하며,

    상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성인, 이종의 자바 메소드를 실행하는 자바 가상 머신.
13. 제 12항에 있어서,

    상기 제 1 또는 제 2 메소드는 인터프리터를 통해 실행하는 바이트 코드 또는 컴파일러를 통해 기계어로 변환된 네이티브 코드 중 어느 하나인, 이종의 자바 메소드를 실행하는 자바 가상 머신.
14. 제 12항에 있어서,

    상기 제 1 스택 프레임은

    제 1 메소드의 현재 실행 위치에 대한 필드, 상기 제 1 메소드의 종류를 알리는 필드, 상기 제 1 메소드를 호출한 복귀 메소드에 대한 정보를 포함하는 복귀 스택 프레임의 위치 필드 및 상기 제 1 메소드를 실행하는데 필요한 데이터를 포함하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
15. 제 12항에 있어서,

    상기 제 1 스택 프레임은

    실행 위치에 대한 필드는 바이트 코드 프로그램 카운터와 네이티브 코드 프로그램 카운터를 더 포함하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
16. 제 12항에 있어서,

    상기 제 2 메소드가 바이트 코드인 경우,

    상기 코드 버퍼 관리자는 제 2 메소드를 컴파일러를 통해 네이티브 코드로 변환하며,

    상기 제 2 스택 프레임을 구성하는 종류가 네이티브 코드 스택 프레임임을 나타내도록 수정하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
17. 제 16항에 있어서,

    상기 제 2 메소드의 바이트 코드를 컴파일러를 통해 변환하여 생성되는 기계어 코드를 저장할 코드 버퍼의 메모리 공간이 부족할 경우 상기 코드 버퍼에서 네이티브 코드 형태의 제 3 메소드를 검색하고,

    상기 검색 결과, 제 3 메소드가 존재할 경우, 상기 제 3 메소드를 구성하는 네이티브 코드가 차지하는 메모리를 코드 버퍼에서 제거하고,

    상기 제거로 인해 가용가능한 메모리의 공간을 상기 제 2 메소드에 할당하는 단계를 더 포함하는, 이종의 자바 메소드를 실행하는 방법.
18. 제 16 또는 제 17항에 있어서,

    상기 코드 버퍼 관리자는 상기 제 3 메소드에 대한 모든 스택 프레임의 종류가 바이트 코드 스택 프레임임을 나타내도록 수정하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
19. 제 12항에 있어서,

    상기 제 2 메소드의 실행이 완료하면 상기 제 1 스택 프레임으로 복귀하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
20. 이종의 자바 메소드를 실행하는 자바 가상 머신을 저장하는 보조 기억부;

    상기 자바 가상 머신에 메모리를 할당하는 주기억부;

    상기 자바 가상 머신과 데이터를 송수신하는 입출력부; 및

    상기 주기억부와 상기 자바 가상 머신 및 상기 입출력부를 제어하는 제어부를 포함하며,

    상기 자바 가상 머신은

    바이트 코드를 실행하는 인터프리터;

    상기 바이트 코드를 컴파일하여 네이티브 코드를 생성하는 컴파일러;

    상기 컴파일된 네이티브 코드의 메모리를 관리하는 코드 버퍼 관리자를 포함하며,

    상기 바이트 코드 인터프리터 또는 네이티브 코드가 수행중인 제 1 메소드에 대해

    상기 제 1 메소드가 제 2 메소드를 호출하는 경우, 상기 제 1 메소드로 복귀하기 위한 정보를 제 1 스택 프레임에 저장하고, 상기 제 2 메소드에 대한 제 2 스택 프레임을 상기 스택에 추가하며,

    상기 제 2 메소드를 실행하기 위한 정보를 상기 제 2 스텍 프레임에 저장하며,

    상기 제 1 스택 프레임과 상기 제 2 스택 프레임은 동일한 스택에 동일한 구성인, 디지털 장치
21. 제 20항에 있어서,

    상기 메소드는 인터프리터를 통해 실행하는 바이트 코드 또는 컴파일러를 통해 기계어로 변환된 네이티브 코드 중 어느 하나인, 디지털 장치.
22. 제 20항에 있어서,

    상기 스택 프레임은

    상기 메소드의 현재 실행 위치에 대한 필드, 상기 메소드의 종류를 알리는 필드, 상기 메소드를 호출한 복귀 메소드에 대한 정보를 포함하는 복귀 스택 프레임의 위치 필드 및 상기 메소드를 실행하는데 필요한 데이터 및 명령어를 포함하는, 디지털 장치.
23. 제 20항에 있어서,

    상기 제 2 메소드가 바이트 코드인 경우,

    상기 코드 버퍼 관리자는 제 2 메소드를 컴파일러를 통해 네이티브 코드로 변환하며,

    상기 제 2 스택 프레임을 구성하는 종류가 네이티브 코드 스택 프레임임을 나타내도록 수정하는, 이종의 자바 메소드를 실행하는 자바 가상 머신.
24. 제 20항에 있어서,

    상기 제 2 메소드의 바이트 코드를 컴파일러를 통해 변환하여 생성되는 기계어 코드를 저장할 코드 버퍼의 메모리 공간이 부족할 경우 상기 코드 버퍼에서 네이티브 코드 형태의 제 3 메소드를 검색하고,

    상기 검색 결과, 제 3 메소드가 존재할 경우, 상기 제 3 메소드를 구성하는 네이티브 코드가 차지하는 메모리를 코드 버퍼에서 제거하고,

    상기 제거로 인해 가용가능한 메모리의 공간을 상기 제 2 메소드에 할당하는 단계를 더 포함하는, 디지털 장치
25. 제 20항에 있어서,

    상기 스택 프레임은

    실행 위치에 대한 필드는 바이트 코드 프로그램 카운터와 네이티브 코드 프로그램 카운터를 더 포함하는, 디지털 장치
26. 제 20항에 있어서,

    상기 메소드가 바이트 코드인 경우, 상기 메모리 관리자는 메소드를 컴파일러를 통해 네이티브 코드로 변환하며,

    상기 스택 프레임의 정보를 네이티브 코드 스택 프레임으로 수정하고,

    상기 스택 프레임을 구성하는 종류 필드가 네이티브 코드 스택 프레임임을 나타내도록 수정하는, 디지털 장치.
27. 제 20항에 있어서,

    상기 메소드가 네이티브 코드인 경우, 상기 코드 버퍼 관리자는 이 코드가 차지하는 메모리 코드 버퍼를 제거하며,

    상기 스택 프레임을 구성하는 종류 필드가 바이트 코드 스택 프레임임을 나타내도록 수정하는, 디지털 장치.
28. 제 20항에 있어서,

    상기 코드 버퍼 관리자는 제 1 메소드에 대한 제 1 스택 프레임을 상기 메모리에 저장하며,

    상기 제 1 메소드가 제 2 메소드를 호출하는 경우, 상기 제 2 메소드에 대한 제 2 스택 프레임을 상기 메모리에 저장하는, 디지털 장치.
29. 제 28항에 있어서,

    상기 제 2 메소드의 실행이 완료하면 상기 제 1 스택 프레임으로 복귀하는, 디지털 장치.
30. 제 27항 또는 제 28항에 있어서,

    상기 코드 버퍼 관리자는 상기 제 3 또는 제 4 메소드에 대한 모든 스택 프레임의 종류 필드가 바이트 코드 스택 프레임임을 나타내도록 수정하는, 디지털 장치.
31. 제 20항에 있어서,

    상기 디지털 장치는 디지털 티비, 휴대폰, PDA, 노트북, 컴퓨터, 셋톱박스, 디지털 가전기기를 포함하는, 디지털 장치.

Images