KR20020085876A

KR20020085876A - 객체지향 컴퓨터 프로그램의 로딩

Info

Publication number: KR20020085876A
Application number: KR1020027003350A
Authority: KR
Inventors: 레노프티모씨
Original assignee: 타오 그룹 리미티드
Priority date: 1999-09-14
Filing date: 1999-12-23
Publication date: 2002-11-16
Also published as: EP1416378A3; WO2001019159A2; HK1048525A1; EP1214649A2; US20040015914A1; US7191434B2; WO2001019159A3; CA2381779A1; EP1416378A2; AU1880800A; US20050240907A1; GB9921720D0; JP2003509761A; AU776957B2

Abstract

객체 지향 프로그램을 로딩하는 방법은 최초의 프로그램 코드를 또한 유지할 필요없는 실행 환경에서 실행하기 위해, 상기 프로그램을 컴파일된 코드로 번역하는 단계와, 상기 코드를 유지하는 단계를 포함하고 있다. 바람직한 실시예에서, 최초의 클래스 파일은 상기 프로그램을 실행하기 전에 메모리로부터 버려진다. 본 발명은 특히 이동전화와 같은 다수의 클라이언트 장치로 이루어진 무선 통신 네트워크에 적용되고, 상기 클라이언트 장치 각각은 일반적으로 적은 양의 이용 가능한 메모리만을 가지고 있다. 본 발명의 이용으로, 상기 최초의 클래스 파일은 번역후 버려지고 상기 클라이언트 장치 메모리에 유지될 필요가 없다.

Description

객체지향 컴퓨터 프로그램의 로딩{Loading Object-Oriented Computer Programs}

객체지향 프로그래밍 언어의 공지된 예는 "자바(Java)"(썬 마이크로시스템즈사(Sun Microsystems Inc.)의 상표명)이다. "자바 구현"은 하나 이상의 클래스 파일로 이루어진 소프트웨어 애플리케이션을 실행되게 하는 소프트웨어 시스템이다. 이들 클래스 파일은 썬 마이크로시스템즈사에 의해 공개된 것처럼, 어떤 버전의 표준 자바 가상장치 사양(standard Java Virtual Machine Specification)에 따라야 한다. 클래스 파일은 특정 클래스에 필요한 데이터와 프로그램 코드를 정의한다.

비록 약간의 상호적인 영향이 있을 지라도, 자바 구현은 개념상 두 부분으로 나뉠 수 있다:

·자바 가상장치(JVM). 이는 클래스 파일을 읽고 썬(Sun)의 어떤 버전의 자바 가상장치 사양에 따르는 방식으로 그 안에 포함된 명령을 실행한다. 클래스에포함된 일부 명령들은 다른 클래스들의 데이터 또는 프로그램 코드를 참조할 수도 있으며; 또한 JVM은 클래스 간의 관계를 관리한다.

·자바 클래스 라이브러리(Java Class Library). 이는 썬의 자바 클래스 라이브러리 사양에 따르는 방식으로 작용하는 데이터와 프로그램 코드를 가지는 사전 정의된 클래스의 한 셋트이다. 이들 라이브러리 클래스들은 실재 클래스 파일(real class file)들로서, 예를 들어 C 또는 어셈블러 프로그래밍 언어를 사용하는 것 이외의 방식으로 구현될 수 있는데, 그 경우 JVM은 그들의 데이터 및 프로그램 코드에 대한 참조가 실재 클래스 파일로부터 비롯된 클래스에 대한 참조와 동일한 방식으로 작동한다는 것을 보장해야 한다.

클래스 파일에서 프로그램 코드는 자바 바이트코드(JBC), 또는 단순히 바이트코드로 알려진 명령 포맷이다. 클래스에서 각 메소드(method)는 자신의 바이트코드 순서를 가진다. 메소드에 대한 바이트코드는 JBC 명령의 순서로 이루어져 있다.

상기 JVM이 바이트코드를 실행하는데 사용하는 스킴(scheme)이 두 개 있다:

·인터프리터. 이러한 스킴에서, 상기 JVM은 인터프리터를 포함하는데, 이것은 차례로 각 JBC 명령을 검사하고, 그것을 해독하고, 그것이 요구하는 작동을 수행함으로써 바이트코드를 실행하는 프로그램 코드의 한 피스이다. 이러한 접근 방식으로는 이행하기가 가장 간단하나, 단 하나의 상기 JBC 명령을 해석하기 위해 인터프리터 프로그램의 많은 단계들이 요구되기 때문에 다른 방식보다 더 느리다는 단점이 있다.

·컴파일러. 이러한 스킴에서, 상기 JVM은 바이트코드의 상기 JBC 명령을 실행하기 전에, 계속 실행되고 있는 CPU에 의해 인지되는 장치 코드 명령(원시 장치 코드)으로 변환한다. 이어서, 메소드에 대한 프로그램 코드를 실행하기 위해, 컴파일된 장치 코드가 대신 실행된다. 비록 이는 애플리케이션이 시작될 때 보다 오히려 애플리케이션을 준비하는 동안 행해질 수도 있지만, JBC 명령에서 장치 코드 명령으로의 초기 컴파일을 위한 제반 시간이다. 일단 컴파일이 행해지면, 메소드 프로그램 코드는 C와 같은 다른 전통적으로 컴파일된 언어와 필적할만한 속도로, 매우 빠르게 실행한다. 컴파일러 스킴의 특별한 경우는 저스트-인-타임 컴파일러(JIT)인데, 여기서 클래스에 대한 바이트코드는 그것이 처음 사용되기 바로 전에 컴파일된다. 몇몇 JVM은 두개의 스킴을 조합하여 사용하는데, 여기서는 여러번 실행되는 프로그램 코드만이 컴파일되고, 나머지는 해독된다.

연결(linking)은 하나의 클래스 C1에서 다른 하나의 클래스 C2(또는 C2에서 데이터나 메소드)로의 참조가 결정되는 프로세스이다. 만약 C2가 이미 로딩되어 있지 않다면, 그것은 로딩되고, 만약 컴파일러 스킴을 사용하면 컴파일되고, 자체 연결된다. 이어서, C1에서 C2(또는 C2에서 데이터나 메소드의 몇몇 아이템)로의 참조는 변경되어 이제 C2에서 참조되는 어떤 것이라도 그에 대한 직접적인 포인터가 있도록 한다.

썬의 자바 가상 장치 사양은 연결 스킴의 범위를 고려한다:

·정적 연결: 애플리케이션의 모든 클래스의 로딩 및 연결은 애플리케이션이 준비될 때 수행된다. 이러한 스킴은 전형적으로 애플리케이션이 장치에 영구적으로 내장될 때 사용된다.

·다이나믹 로드 타임 연결(Dynamic load time linking): 먼저 C2(또는 일부 데이터 항목 또는 C2내 메소드)를 참조하는 또 다른 클래스가 로드될 때 클래스 C2가 로드된다.

·다이나믹 레이트 바인딩(Dynamic late binding): 먼저 C2(또는 일부 데이터 항목 또는 C2내 메소드)를 참조하는 JBC 명령이 실행될 때 클래스 C2가 로드된다.

작동시, 개별 클래스의 개별 메소드가 호출될 때, 요구된 개별 클래스는 JVM에 이미 존재하고 있을 수도 있고 그렇지 않을 수도 있다. 만약 요구된 클래스가 존재하고 있지 않다면, 그 때는 그 클래스에 대한 클래스 파일이 먼저 JVM 외부로부터(예를 들어 디스크로부터 또는 네트워크로부터) 로드되고, 연결되며 JVM으로 초기화되어야만 한다. 그 다음, 요구된 메소드는 클래스에 대한 메소드의 리스트를 검사함으로써 발견될 수 있다. 일단 요구된 메소드가 발견되면, 그 메소드의 자바 바이트코드는 복귀(return) 명령을 만날때까지 실행되고, 그 결과 그 메소드는 종료되고 컨트롤은 메소드의 인보커(invoker)로 복귀된다. 메소드 호출은 또한 메소드에서 포함되지 않는 것을 버리는 예외로 종결될 수 있다.

도 1은 JVM이 JIT 컴파일러를 이용하는 전형적인 종래 기술의 실행을 예시하고 있다. JIT 컴파일러(120)는 사용되기 바로 전에 클래스 바이트코드(110)를 받아들이고, 그것을 특정한 프로세서에서 실행될 준비가 된 원시코드(130)로 번역한다. 클래스(140)의 나머지(또는 어쩌면 클래스의 전체)는 상기 원시코드(130)가 실행되는 동안 그것을 참조할 필요가 있는 경우 메모리에서 이용가능한 상태로 남아있다.전형적으로, 참조될 필요가 있는 상기 클래스 파일의 나머지는 상기 데이터 필드의 테이블 및 상수 풀등을 포함한다. 정적 연결이 사용된 곳에, 애플리케이션이 마련될 때 상기 로딩 및 아마도 일부 또는 모든 번역이 발생한다. 다시, 상기 최초의 클래스 파일(또는 그 파일의 일부)은 상기 원시코드가 상기 데이터 필드의 테이블 및 상수 풀을 참조할 수 있도록 메모리에 여전히 유지되어야만 한다.

도 3은 다중 프로세서 환경에서 전형적인 종래 기술의 JVM 실행을 예시하고 있다. 서버(210)는 클라이언트 프로세서(230, 240)가 요구할 수도 있는 다양한 클래스의 바이트코드를 확보하기 위해 클래스 스토어(220)를 유지하고 있다. 그 내부에 다수의 개별 메소드(212)를 포함하는 전형적인 자바 클래스(211)가 상기 클래스 스토어(220)에 도시되어 있다.

상기 서버(210)는 필요에 따라 250으로 전체 표시되어 있는 통신 네트워크를 가로질러 클라이언트(230, 240)로 클래스 파일(211)을 공급한다. 이 예에서, 상기 프로세서(230,240)는 2개의 다른 형태 - 즉, 각각, 1 형 클라이언트 및 2 형 클라이언트이다. 각각의 클라이언트는 자신의 JIT, 각각 231, 241을 유지하여, 전송 받은 클래스 파일(211)을 자신의 원시코드(233,243)의 버전으로 컴파일하고 자신의 원시 코드 스토어(232, 242)에 저장할 수 있도록 한다. 게다가, 도 1을 참조로 앞서 설명된 바와 같이, 상기 원시코드(233,243)가 로컬 프로세서상에 실행되는 동안 클래스 파일을 참조할 필요가 있어야 하는 경우, 상기 클래스 파일(211)의 나머지(또는 어쩌면 상기 전체 클래스 파일)는 234,244로 전체 표시된 로컬 메모리에 남아 있을 것이다.

또 다른 종래 기술 (도시도지 않은) 배열에서 상기 클라이언트 JIT(231,241)는 상기 클라이언트(230,240)에서 보다는 오히려 서버상에 실행되어지는 원시코드로의 변환으로 상기 서버(210)상에 유지될 수 있다.

(도시되지 않은) 다른 방법의 종래 기술 배열에서 상기 클라이언트 JIT(231,241)는 상기 서버(210)상에 유지될 수 있으며, 원시코드로의 변환은 상기 클라이언트(230,240)에서 보다는 오히려 서버상에서 행해진다.

종래 기술 배열로도 몇 가지 불이익이 있다. 각 경우에서, 먼저, 큰 실행 환경이 각각의 클라이언트상에 요구된다. 게다가, 상기 자바 클래스 파일(211)이거나 상기 클래스 파일에 따른 상기 원시버전(native version)(233,243)이 통신 네트워크(250)를 가로질러 전송될 필요가 있으며, 클라이언트 메모리에 남아있게 된다. 상기 클래스 파일은 일반적으로 크기 때문에, 특히 이동 전화 네트워크와 같은 무선 클라이언트 네크워크와 관련한 실행에서 이들 접근방식은 실재적으로 만족스럽지 못하다.

본 발명의 제 1 형태에 따르면 다수의 메소드를 각각 포함하는 클래스 형태로 제공되는 프로그램 코드를 구비하고, 상기 클래스의 프로그램 코드를 또한 유지할 필요가 없는 실행환경에서 실행하기 위해, 상기 클래스 파일의 메소드를 컴파일된 코드로 컴파일하는 단계와 상기 코드를 유지하는 단계를 포함하는 객체지향 컴퓨터 프로그램을 로딩하기 위한 방법을 제공하고 있다. 상기 방법은 전형적으로, 비록 필수적이진 않지만, 각 클래스는 개별 클래스 파일에 의해 정의될 것이며, 이 경우 본 발명은 상기 실행환경이 최초의 클래스 파일을 또한 유지할 필요가 없도록한다.

상기 최초의 클래스 및/또는 클래스 파일을 나타내는 프로그램 코드는 본 발명에서 상기 컴파일된 코드가 상기 실행환경에서 실행되게 할 필요는 없다.

바람직한 실시예에서, 번역은 2 단계 프로세서에 의해 실행된다. 제 1 단계에서, (상기 클래스의 바이트코드의 예에 대해) 상기 프로그램 코드는 가상 프로세서의 명령셋트를 이용한 가상 프로세서로 번역된다. 제 2 단계에서, 상기 가상 프로세서 코드는 원시코드로 번역되며, 상기 원시 코드는 실재, 물리적 프로세서의 명령 셋트를 이용한다.

다양한 형태로 본 발명은 최초의 클래스 파일이 메모리에 유지될 필요가 없음으로 인해서 메모리 활용을 향상시키며, 이 경우, 애플리케이션을 실행하기만 하면 된다. 앞서 설명한 2 단계 번역 프로세서를 이용함으로써, 애플리케이션 프로그래머는 전형적인 큰 크기의 자바 클래스 파일에 대해 전혀 걱정할 필요없이, (자바와 같은) 높은 수준의 언어로 프로그램을 계획할 수 있다. 본 발명은 바람직한 형태로 자바와 같은 고 수준의 메모리-집약 프로그래밍 언어로 번역될 수 있으며, 동시에 최종 프로그램이 매우 작은 "풋프린트(footprint)" 내에 실행될 수 있다. 이는 상기 애플리케이션이 내장된 시스템에 사용될 때 특히 유용하다.

본 발명은 예를 들면 정적 연결과, 다이나믹 로드 타임 연결(dynamic load time linking), 및 다이나믹 레이트 바인딩(dynamic late binding)과 같은 많은 다른 연결 구성과 연계하여 사용될 수 있다.

본 발명의 또 다른 하나의 형태에 따르면 다수의 메소드를 각각 포함하는 클래스 형태로 제공되는 코드를 구비하고, 실행 환경을 정의하며 상기 클래스의 프로그램 코드를 또한 유지할 필요가 없는 상기 실행 환경에서 실행을 준비하기 위해, 상기 클래스의 메소드를 컴하일하며 컴파일된 코드를 유지하게 작동될 수 있는 객체지향 컴퓨터 프로그램을 로딩하기 위한 컴퓨터 시스템이 제공된다.

본 발명의 또 다른 하나의 형태에 따르면, 전송 수단을 통해 다수의 클라이언트 장치와 통신하는 서버를 구비하고, 상기 각각의 클라이언트 장치는 다수의 메소드를 각각 포함한 클래스 형태로 제공된 프로그램 코드를 구비한 객체지향 컴퓨터 프로그램을 실행하기 위한 각각의 실행환경을 가지고 있으며,

(a) 상기 프로그램 코드를 컴파일된 코드로 컴파일하기 위한 수단과,

(b) 상기 클라이언트 장치중 하나에 실행하기 위해 상기 클래스중 하나에 대한 상기 메소드중 하나를 선택하기 위한 수단과,

(c) 상기 서버로부터 상기 클라이언트 장치까지 상기 선택된 클래스의 프로그램 코드을 필수적으로 전송하지 않아도 컴파일된 코드를 전송하는 수단을 포함하는 분산 컴퓨터 시스템이 제공되고 있다.

본 발명의 또 다른 하나의 형태에 따르면 각각의 실행 환경을 포함한 다수의 각 클라이언트 장치로 다수의 메소드를 각각 포함하는 클래스의 형태로 제공된 프로그램 코드를 구비하고,

(a) 선택된 클래스의 선택된 메소드를 컴파일된 코드로 컴파일하기 위한 수단과,

(b) 상기 실행환경으로 프로그램 코드를 로딩할 필요없이 실행을 하기 위해,상기 컴파일된 코드를 각각의 실행환경으로 로딩하기 위한 수단을 구비한 객체 지향 컴퓨터 프로그램을 로딩하기 위한 컴퓨터 시스템이 제공되어 있다.

이 형태에서 본 발명은 애플리케이션 프로그램이 예를 들면 이동전화와 같은 다수의 개별 클라이언트 장치로 다중 업로드되게 한다. 상기 컴파일된 코드는 최초의 클래스 파일 또는 프로그램 코드가 업로드되게 할 필요없이도 상기 전화 메모리에 업로드될 수 있다.

본 발명의 또 다른 형태에 따르면 다수의 메소드를 각각 포함한 클래스의 형태로 제공된 코드를 구비하고,

(a) 실행을 위해 상기 클래스중 하나에 대한 메소드중 하나를 선택하는 단계와,

(b) 상기 선택된 클래스 전체를 상기 실행환경으로 로딩할 필요없이도 선택된 메소드를 실행환경으로의 로딩하는 단계를 포함하는 객체 지향 컴퓨터 프로그램을 로딩하는 방법이 제공되어 있다.

본 발명의 방법은 상기 자바 가상머신(JVM)의 모든 동적 특성을 제공하나, 종래 접근과 비교하여 상당히 감소된 풋프린트로서 제공된다.

이 바람직한 형태로, 본 발명은 바인딩/연결의 미세한 입도(granularity), 로딩, 통신 네트워크를 가로지른 번역 및 전송을 제공한다. 더 구체적으로, 상기 입도는 종래 객체지향 시스템에 대한 클래스 레벨보다는 오히려 메소드/툴 레벨에 있다. 본 발명은 특히 배타적이지는 않지만 자바 가상머신(JVM) 환경에 적용될 수 있다. 본 발명은 전 범위의 JVM 연결 구성, 즉 정적 연결, 다이나믹 로드 타임 연결 및 다이나믹 레이트 바인딩에 대해 제공되고 있다. 본 발명의 바람직한 실시예에 대한 애플리케이션의 특정 필드는 무선 통신(무선 클라이언트 네트워크)과, 특히 배타적이지는 않지만 이동전화 네트워크를 포함한다. 본 발명은 또한 예를 들면 (제한없이) 휴대용 컴퓨터, 게임 콘솔, 카메라 또는 다른 형태의 네트워크 또는 네트워크 가능한 장치와 같이, 다른 내장 장치, 바람직하게는 네트워크 장치에 적용될 수 있다. 일 실시예에서, 상기 시스템은 네트워크는 무선 네트워크를 구성하거나 또는 포함할 수 있는 반면에, 다른 실시예에서는 개인 또는 공적 고정 네트워크 또는 인터넷을 포함할 수 있다. 상기 클라이언트 장치가 무선 통신을 할 수 없는 곳에서, 요청에 따라 (예를 들면 표준 모뎀 또는 ISDN 링크를 통해) 설비가 상기 클라이언트 장치를 상기 인터넷과 결합되게 제공될 수 있다. 이와 같은 방식으로, 본 발명은 내장된 장치의 광범위한 범위, 예를 들면, 카메라, 텔레비젼, 세척기, 모터차량, 또는 실재적으로 착상될 수 있는 컴퓨터 작동되는 어떤 다른 형태의 장치에 응용될 수 있다.

본 발명의 한 잇점은, 무선 클라이언트 네트워크에 적용될 때, (메소드/툴의) 각 개별 전송은 전체 클래스 파일이 다운로드되어야만 하는 종래 시스템보다는 시간이 상당히 더 짧아진다는 것이다. 이는 상기 네트워크 제공자가 상기 네트워크의 가상 회로를 장시간 동안 개방할 필요가 없다는 것을 의미한다. 전송되어야 할 각각의 작은 메소드/툴은 필요하다면 차등적으로 보내질 수 있다. 뿐만 아니라, 데이터의 더 작게 분리된 양의 전송은 더 작은 중복 및 에러 수정이 요구됨을 의미한다. 따라서 네트워크상으로의 로드는 상기 데이터 전송율의 참작에 의해서만 예측되는 것보다도 더 큰 양으로 감소되어 질 수 있다.

바람직한 형태로, 본 발명은 실행전에 (오히려 해석되기 보다는) 컴파일되는 객체 지향 컴퓨터 프로그램의 사용에 특히 적용될 수 있다. 본 발명이 분산 컴퓨터 시스템과 관련하여 사용될 때, 상기 개별 메소드는 네트워크를 가로질러 클라이언트 장치에 전해지기 전 또는 후에 컴파일 될 수 있다.

바람직하기로는, 본 발명은 상기 클래스를 가상 프로세서 명령 셋트를 사용하는 다수의 가상 프로세서 툴로 번역하는 예비단계를 포함한다. 그리고 나서, 실행을 위한 상기 메소드중 하나를 선택하는 단계는 상기 가상 프로세서 툴중 하를 선택하는 단계를 포함할 수도 있다. 네트워크 시스템과 관련하여 사용될 때, 상기 가상 프로세서 툴은 상기 네트워크를 가로질러 상기 클라이언트 장치에 개별적으로 전송될 수 있거나, 또는 다른 방안으로서 상기 개별 가상 프로세서 툴이 먼저 컴파일되고 원시 컴파일된 코드가 상기 네트워크를 가로질러 전송될 수도 있다.

본 발명은 앞서 설명한 바와 같이 메소드를 실행하기 위해 채택된 컴퓨터 시스템으로 더 확장된다.

본 발명은 다수의 메소드를 각각 포함한 클래스 형태로 제공된 코드를 구비하고, 상기 시스템은 실행 환경을 정의하며 상기 클래스중 하나에 대한 메소드중 하나를 실행하기 위해 선택하고, 상기 실행환경으로 상기 선택된 클래스의 전체를 로딩할 필요없이 상기 선택된 메소드를 상기 실행환경으로 로드하도록 작동될 수 있는 객체 지향 컴퓨터 프로그램을 로딩 및/또는 실행하기 위한 컴퓨터 시스템으로 더 확장된다.

본 발명의 또 다른 형태에 따르면, 전송 수단을 통해 다수의 클라이언트 장치와 통신하는 서버와, 상기 각각의 클라이언트 장치는 다수의 메소드를 각각 포함하는 클래스 형태로 제공된 코드를 구비한 객체지향 컴퓨터 프로그램을 실행하기 위한 각각의 실행 환경을 가지고 있으며,

(a) 상기 클라이언트 장치중 하나에 실행하도록 상기 클래스중 하나에 대한 메소드중 하나를 선택하기 위한 수단과,

(b) 상기 실행환경으로 상기 선택된 클래스 전체를 로딩할 필요없이 상기 클라이언트 장치에서 상기 선택된 메소드를 상기 실행환경으로의 로딩을 포함하는 분산 컴퓨터 시스템이 제공되어 있다.

본 발명은 객체지향 컴퓨터 프로그램을 로딩하기 위한 방법 및 장치 뿐만 아니라 또한 통신 네트워크를 가로질러 이와 같은 프로그램을 컴파일하고, 바인딩하고, 실행하며, 전송하는 방법 및 장치로 확장된다.

마지막으로, 본 발명은 또한 데이터 캐리어(data carrier)상에 구체화되든지 구체화되지 않든지 간에 상기 설명한 메소드중 어느 하나를 구현하기 위한 컴퓨터 프로그램으로 확장된다. 상기 설명한 메소드를 실행하기 위한 컴퓨터 프로그램을 나타내는 데이터 스트림(data stream)으로 또한 확장된다.

본 명세서 및 청구항에 사용된 단어 "코드(code)"는 데이터는 자체적으로 프로그램의 부분인 데이터를 포함하고 있다.

따라서, 제한됨이 없이, "코드" 표현은 상수, 변수 명 및 형태, 플래그(flags), 포인터(pointers), 객체 명등과 같은 것을 포함한다.

본 발명은 기술한 어떤 방법을 실행하기 위한 컴퓨터 시스템과, 데이터 캐리어상에 내장되든지 않든지 간에 해당하는 컴퓨터 프로그램으로 확장된다. 본 발명은 기술한 방법을 실행하기 위한 컴퓨터 프로그램을 대표하는 데이터 스트림으로 확장된다.

본 발명은 다양한 방식으로 실행될 수 있으며 예로서, 일 구체적인 실시예가 첨부도면에 대해 기술될 것이다;

본 발명은 일반적으로 객체지향 컴퓨터 프로그램을 로딩하기 위한 방법 및 컴퓨터 시스템에 관한 것이다. 보다 상세하게는, 비록 배타적으로는 아니지만, 본 발명은 다수의 메소드를 각각 포함하는 클래스 파일 형태로 코드가 제공되는 객체지향 프로그램과 관련되어 있다.

도 1은 JVM내에 종래 지트 컴파일러(JIT compiler)의 오퍼레이션을 예시하고 있다;

도 2는 본 발명의 바람직함 실시예의 2 단계 번역 프로세서를 예시하고 있다;

도 3은 전형적인 종래의 클라이언트/서버 시스템을 도시하고 있다;

도 4는 클라이언트/서버 시스템내에 본 발명의 바람직한 실시예의 오퍼레이션을 예시하고 있다;

도 4a는 도 4에서 도시된 실시예의 변형을 예시하고 있다;

도 5는 무선 네트워크내 본 발명의 오퍼레이션을 예시하고 있다; 그리고

도 6은 본 발명의 바람직한 실시예에 따른 바이트코드를 중간 가상 프로세서 코드로 번역의 어떤 형태를 예시하고 있다.

도 7은 본 발명의 바람직한 작동을 개략적으로 예시하고 있다;

앞서 설명한 도 1은 자바 가상머신(JVM)내 지트 컴파일러(JIT compiler)가 특정 프로세서 실행을 위해 프로세서 독립의(processor-indepedent) 바이트코드 (bytecode)를 프로세서 의존의(processor-depedent) 원시코드(native code)로 변역하는 방식을 도시하고 있다. 종래 기술접근에서와 같이, 클래스(140)(또는 어쩌면 전체 클래스)의 나머지는 원시코드(130)가 실행되는 동안 클래스 바이트코드를 참조할 필요가 있는 경우 메모리에 유지되어야 한다. 도 7에서 개략적으로 도시된 본 발명의 바람직한 실시예는 다른 접근을 취한다. 여기서, 클래스 바이트코드(710)는 컴파일러(720)에 의해 원시코드(730)으로 번역된다. 상기 컴파일러는 최초의 클래스 바이트코드 파일의 필수적인 부분 모두를 상수 풀(constant pool)내 어떤 데이터를 포함하는 원시코드로 번역한다. 상기 원시코드(730)는 자체적으로 완결하며, 실행될 때 상기 최초의 클래스의 어떤 부분을 참조할 필요가 없다. 따라서 상기 컴파일러(720)는 개략적으로 화살표(740)에 의해 도시된 바와 같이, 전체 클래스(즉, 최초의 클래스 파일의 전체)를 메모리로부터 버릴수 있다.

상기 컴파일러(720)는 정적 연결, 다이나믹 로드 타임 연결 또는 다이나믹 레이트 바인딩을 하도록 배열될 수 있다. 직접적으로 상기 클래스를 원시코드로 변환할 수 있거나, 또는 다른 방안으로서 하기에 설명한 바와 같이, 2 단계로 변환을 실행 할 수 있다.

본 발명에서, 바이트코드를 원시코드로의 변환은 2개의 분리 단계로 일어난다.

1.클래스 파일로부터 중간 프로세서 독립의 형태로의 변환. 이는 가상프로세서 또는 VP 코드로서 언급된다. 변환기 그자체는 바람직한 구현에서 "제이코드 번역기(jcode translator)"로 공지되어 있다.

2.중간 VP 형태로부터 원시 기계코드로의 변환. 상기 변환기는 "원시번역기(native translator)"로서 공지될 것이다.

도 2는 클래스 바이트코드로부터 원시코드로의 변역을 더 상세히 예시하고 있다. 상기 클래스 바이트코드(210)는 클래스 검사장치(class verifier)(211)에 의해 타당성이 먼저 검사되어 진다. 이는 개별 바이트코드 자체 뿐만 아니라 타당한 외부 및 내부 기준(reference)을 검사한다. 필요하다면 상기 클래스 검사장치는 부가적인 클래스를 로드하여 상기 외부 기준을 검사한다.

일단 상기 코드가 검사되고 나면, 하기에 보다 상세히 기술되는 바와 같이, 상기 코드는 제이코드 번역기(212)로 전해져 VP 코드(213)로 변환된다. 그런 후 상기 VP 코드(213)는 원시번역기(214)에 의해 원시코드(230)로 변환된다.

상기 클래스 검사장치(211)와, 상기 제이코드 번역기(212)와 상기 VP 코드(213)는 모두 프로세서 독립임을 인식하는 것이 중요하다. 단지 상기 원시번역기(214)와 물론 상기 최종 원시코드(230)만이 고유 프로세서(processor-specific)이다.

번역 프로세스동안 조작되어지는 객체의 개략적인 표현이 도 2의 오른쪽 측면에 도시되어 있다. 상기 프로세스는 다수의 개별 메소드(202)로 이루어진 자바 클래스 파일(201)의 형태의 상기 클래스 바이트코드로 시작한다. 상기 제이코드 번역기는 상기 클래스 파일을 다수의 개별 가상 프로세서 툴(203)로 번역한다. 실행되는 애플리케이션에 따라, 필요되어질 가상 프로세서 툴(203)이 선택되고, 그런 후 이들 선택된 툴(및 이들 툴만)은 원시번역기에 의해 개별 원시메소드(204)로 번역된다. 최초의 클래스 파일(201) 전체가 상기 원시 번역기(214)를 통해야하는 것이 필수적이지 않다는 것을 아는 것이 중요하다: 애플리케이션에 의해 실재적으로 필요되는 이들 가상 프로세서 툴(203)만이 상기 클라이언트 상에 실행하기 위해 번역되고 최종적으로 저장될 것이다. 일단 상기 번역 프로세스가 완성되면, 상기 클래스 파일(201) 전체 뿐만 아니라 상기 VP 툴(203)도 메모리에서 버려진다. 단지 상기 개별 원시 메소드(204)만이 남아있어, 가장 능률적인 메모리 활용을 하게 한다.

이종 다중 프로세서(heterogeneous multi-processor) 환경내에 바람직한 실시예의 사용이 도 4에 개략 도시되어 있다. 이는 도 3에 도시된 상응하는 종래 기술적 접근과 비교되어야만 한다.

도 4에서, 서버(410)는 통신 네트워크(450)를 통하여 (다른 프로세서를 갖는) 2개의 클라이언트(430,440)를 서브하고 있다. 모든 프로세서-독립 계산은 서버상에서 수행되며; 구체적으로, 상기 서버는 클래스 스토어(class store)(420)와, 클래스 검사장치(421)와, 제이코드 번역기(422)와 VP 스토어(VP store)(423)를 유지하고 있다. 다수의 메소드(481)로 이루어진 초기 자바 클래스 파일(480)은 앞서 설명한 2단계 프로세스를 통해, 상기 VP 스토어(423)내부에 저장된 다수의 VP 툴(482)로 번역된다. 그런 후 상기 VP (프로세서-독립) 코드는, 필요시, 상기 네트워크(450)을 통해 상기 개별 클라이언트에 제공될 수 있다. 그리고 나서 상기 VP툴은 개별 클라이언트 번역기(424,425)에 의해 각각의 프로세서에 대해 최적화된 원시 메소드(483,484)로 번역된다. 이들 원시 메소드는 각각의 원시코드 스토어(432,442) 내부에 저장된다.

도 4에 도시된 바와 같이, 상기 서버상에 VP의 사용은 클래스 파일 및 제 1 번역 단계(VP 코드의 변환)의 검증이 상기 서버에 의해서만 일단 실행되도록 한다.그런 후, (상기 프로세서 형태에 따라 다른) 상기 원시 번역만이 실행전 클라이언트 장치에 의해 수행되어야 한다. 이와 같은 배열은 서버가 업데이트된 클래스의 사용을 원하는 개별 클라이언트의 세부사항에 대해 어떠한 것도 알 필요가 없이 상기 서버에 업데이트된 클래스를 제공하기가 용이하게 하여 준다. 업데이트된 클래스는 클래스 바이트코드에서 한번만 수정되어 지고난 후 VP로 한번만 번역되면 된다. 상기 VP는 상기 클라이언트 장치에 전송되며, 필연적으로, 상기 원시코드로의 최종 번역은 최종 사용자에게 아주 투명한 방식으로 클라이언트에서 실행될 수 있다. 게다가, 새로운 형태의 클라이언트가 다른 원시코드를 필요로 하는 거래에 나타나는 경우에 상기 서버 또는 상기 VP 코드에 대한 어떤 수정도 필요하지 않다. 상기 클라이언트 제조업자는 단지 상기 클라이언트에게 적절한 원시번역기를 제공하며, 상기 장치는 서버에 어떤 수동적인 조정없이 작동해야만 한다.

설명된 접근방식으로, 네크워크를 가로질러 자바 클래스 파일(480)을 다운로드 할 필요가 없으며, 또한 자바 클래스 파일의 개별 메소드(481) 모두도 다운로드할 필요는 없다. 실재적으로 각 개별 클라이어트 애플리케이션에 의해 필요된 이들 VP 툴만이 상기 네트워크를 통해 전송될 수 있다. 상기 필요된 VP 툴은 다운로드되거나 또는 요구될 수 있으며(예를 들면, 상기 클라이언트로부터 서버로 다시 전송되는 콘트롤 신호에 의해), 또는 다른 방안으로서 상기 서버가 상기 VP 툴이 필수적이라고 결정될 때 전송될 수 있다. 예를 들면 일 실시예에서, 상기 서버는 상기 클라이언트 상에서 실행되는 애플리케이션 프로그램을 업데이트하기 위해 업데이트된 VP 툴을 네트워크를 통해 전송될 수 있다. 이는 실시간으로 행해 질 수 있으며, 이 방식으로 끝단의 사용자에게 전적으로 투명하다. 대안적이거나 또는 부가적으로 상기 개별 전송된 VP 툴은 상기 사용자가 애플리케이션 프로그램에 부가하여 상기 클라이언트상에 실행되도록 바라는 "애드-인(add-in)" 또는 부가적인 기능을 나타낼 수 있다. 일 구체적인 종래 접근에서, 상기 사용자는 코드가 상기 클라이언트에서 이용가능하지 않게 하는 애플리케이션 프로그램에서의 기능을 사용하려고 시도할 때, 상기 클라이언트는 필수적인 VP 툴이 다운로드되게 상기 서버에 요청하는 신호를 자동적을 전송한다. 상기 서버는 상기 요청된 VP 툴을 전송함으로써 응답한 후 상기 VP 툴은 로컬 원시 번역기(424,425)에 의해 원시 형태로 번역된다.

일단 상기 클래스 파일(480)이 적절한 VP 툴(482)로 변환된 후, 상기 클래스 파일은 상기 서버 메모리로부터 버려질 수 있다. 마찬가지로, 각각의 클라이언트상에서, 일단 상기 다운로드된 VP 툴이 원시 메소드(483,484)로 변환되고 나서, 상기 VP 툴은 클라이언트 메모리로부터 버려질 수 있다.

도 4a는 개별 원시 번역기가 서버상에 유지된 다른 실시예를 도시하고 있다. 도 4a에서, 상기 참조부호는 도 4에 사용된 참조부호와 동일한 의미를 갖는다.

이 실시예의 한 버전에서, 각각의 상기 클라이언트 프로세서에 대한 원시 메소드의 전체 모음은 각각의 원시코드 스토어(432',442') 상기 서버상의 내부에 저장된다. 메소드가 각 개별 클라이언트에 의해 필요될 것인지 필수적으로 미리 결정될 수 없기 때문에, 상기 VP 툴(482) 전체가 원시 메소드(483,484)의 포괄적인 선택을 제공하도록 각각의 원시 번역기(424,425)를 지나는 것이 바람직하다. 특정의 새롭거나 업데이트된 메소드가 클라이언트에 의해 요구되거나 또는 서버에의해 보내지도록 요청될 때, 적합한 개별 원시 메소드는 상기 통신 네트워크(450)를 가로질러 보내진다. 앞에서와 같이, 단지 개별 메소드만이 보내지며, 전체 클래스도 또는 최초의 클래스로부터 생성된 모든 원시 메소드도 보내지지 않는다.

이 실시예에서, 상기 클래스 파일(480) 및 상기 개별 VP 툴(482) 모두는 일단 상기 원시 메소드(483,484)가 구성된 후 서버 메모리로부터 버려질 수 있다 .상기 클래스 파일의 어느 부분도 또는 어떤 VP 툴도 상기 네트워크를 가로질러 다운될 수 없다는 것을 주목해야 한다. 마찬가지로, 상기 클래스 파일의 일부 또는 어떤 VP 툴도 클라이언트 메모리에 있지 않다. 이는 특히 효율적인 클라이언트 메모리 활용을 하게 한다.

또 하나의 다른 메소드에서, 상기 서버는 각각의 가능한 클라이언트 프로세서에 대한 미리 번역된 메소드의 완전한 모음을 유지할 필요가 없다. 대신에, 특정 VP 툴이 필요될 때, 적절한 원시 번역기(424, 425)와 상기 클라이언트에 직접 전해지는 상기 원시 메소드에 의해 플라이(fly) 상에 번역된다.

도 5에 예시된 한가지 특정의 구현은 이동 전화 네트워크의 구현이다. 각각의 네트워크를 이용한 개개의 이동 전화(530,550)는 각각의 원시번역기(524,525)및 원시코드 스토어(532,542)를 포함한다. 상기 전화의 기능을 업그레이드하는 것이 필요할 때, 업데이트된 VP 코드는 중앙서버(520)상의 VP 스토어(523)로부터 공급된다. 상기 업데이트된 VP 코드는 랜드-기반의 통신 네트워크(land-based communication network)(511)를 통해 무선 송신기(512)에 보내진다. 그런 후, 상기 코드는 패킷화되고 무선 링크(513)를 통해 개인 전화에 전해진다. 전송 받자마자, 상기 VP 코드는 자동적으로 원시코드로 번역되고 원시코드 스토어에 저장된다. 상기 전 공정은 전화 사용자에게 투명하거나; 또는 대안으로서, 상기 업데이트된 코드는 상기 무선 링크(513)를 통해 상기 전화 사용자로부터 특정의 요청을 받을 때 보낼 수도 있다.

이 방식에서 이동 전화 네트워크(또는 다른 형태의 무선 클라이언트 네트워크) 구현은 클라이언트가 (예를 들면 1 메가바이트가 될 수 있는) 전체 클래스를 다운로드해야만 하는 대신에 (예를 들면, 각각이 100바이트의 길이가 될 수 있는) 개별 메소드를 다운로드하게 한다. 가상 회로는 큰 파일이 전송되는 동안 장시간 개방된 채 유지될 필요가 없기 때문에, 이 방식에서 개별 메소드 전송은 또한 무선 네트워크 공급자에 대해 잇점을 갖는다. 각각의 작은 개별 메소드가 차등적으로 보내질 수 있다. 또한 데이터의 더 작은 양의 전송은 중복 및 에러 수정 기술에 대한 필요를 감소시키므로, 원 데이터 전송율과 비교해서 단지 예측되는 네트워크 능력 이상으로 증가시킨다. 상기 최초의 클래스 파일의 어떤 부분도 또는 VP 툴도 클라이어트 메모리 수단에 전혀 남아 있을 필요가 없다는 사실은 그 메모리 전체가 원시 메소드의 스토리지 및 애플리케이션 실행에 그대로 이바지될 수 있다는 것을 의미한다.

완벽을 위해, 클래스 파일이 VP로 변환되고, 상기 VP 툴이 원시코드로 변환되는 바람직한 메소드에 대해 상세한 설명이 주어질 것이다. 이느 순전히 예시이며, 본 발명은 2 단계 번역, 즉 먼저 바이트코드로부터 VP로 번역된 후, VP로부터 원시코드로 변환되는 실시예에 국한되지 않음을 알게 될 것이다.

도 2를 다시 참조하면, 클래스 바이트코드(210)로부터 원시코드(230)로 바람직한 2단계의 번역에 대해 더욱 세부적인 사항들이 주어질 것이다. 전술한 바와 같이, 상기 클래스 검사장치(211)는 타당성을 위해 상기 클래스 바이트코드를 검사한다. 상기 클래스 검사장치는 어떤 실시예에서는 상기 제이코드 번역기내에 합체될 수도 있으며, 이 경우 상기 클래스 바이트코드(210)는 화살표(240)로 도시된 바와 같이 상기 제이코드 번역기(212)에 직접 전해진다.

타당성을 실행하는 상기 자바 가상머신 및 상기 바이트코드 명령은 스택(stack) 기반이며, 이것은 오퍼랜드(operand)(숫자, 객체에 대한 포인터)가 스택상에 유지되고, 푸시된 마지막 항목이 먼저 팝오프(popped off)되는 것을 의미한다. 바이트코드 명령은 일반적으로 상기 스택으로부터 하나 또는 그 이상 오퍼랜드를 이동하고, 어떤 동작을 실행하며, 상기 스택상에 (있다면) 결과 오퍼랜드를 다시 푸시한다. 반면에, VP는 상기 VP 명령에 의해 직접 어드레스된 한 셋트의 레지스터(register)를 갖는다는 점에서 레지스터 기반이다. 명령은 일반적으로 상기 명령에서 특정된 레지스터로부터 그 오퍼랜드를 받아, 어떤 동작을 수행하고, 그 결과 오퍼랜드(있다면)를 상기 명령에서 특정된 또 다른 하나의 레지스터에 둔다. 이레지스터 기반의 구조는 VP가 아주 많은 수의 레지스터를 가지며, VP로 전환하는 어떤 시스템이 얼마나 많이 있는가에 대해 염려할 필요가 없을 정도로 충분히 많다는 것을 제외하고는, 대부분의 실재 프로세서와 아주 유사하다.

VP 명령은 대략적인 표현식(expression)에 근거한다. 단일 명령은 일반적으로 1개 또는 2개의 오퍼랜드를 가지고, 각 오퍼랜드는 상수, 레지스터 또는 표현식일 수 있다. 그래서 각 표현식은 1개 또는 2개의 오퍼랜드를 가지며, 오퍼랜드 각각은 상수, 레지스터 또는 표현식일 수 있다. 이러한 방식으로, 임의의 복잡한 명령이 구축될 수 있다.

이하에 어떻게 클래스 파일의 부분들이 변환되는지에 대하여 상세히 설명한다. 상기 설명에서는 용어 "픽스업(fixup)"을 사용하는데, 이것은 컴파일러의 출력 코드내 특정 포인트에 첨부된 데이터나 또는 상기 특정 포인트에서의 상기 코드 또는 데이터가 사용될 수 있기 전에 이들 특정 포인트에서의 코드 또는 데이터가 어떤 방식으로 변경될 필요가 있는 상기 자바 가상머신을 명령하는 데이터에 대한 작은 항목이다. 픽스업은 상기 원시코드가 또 하나의 다른 클래스, 또는 필드 또는 그 내에 있는 메소드에 대해 직접적인 참조를 얻을 수 있도록 원시명령 또는 데이터 항목을 변경하는데 사용된다.

자바 클래스 파일은 하기의 부분들로 구성되어 있다;

·이름대신에, 여기에 저장된 이름에 대한 참조가 있는 클래스 파일의 다른 부분에서 상수 및 이름을 포함한 상수 풀(constant pool).

·이 클래스와, 상위 클래스 및 어떤 직계 상위 인터페이스의 이름과 같은정보.

·각 필드에 대한 정보를 갖는 필드 리스트.

·각 메소드에 대한 정보를 갖는 메소드 리스트. 이 정보는 코드부를 포함한다. 따라서 각 메소드에 대해 하나의 코드부가 있는 몇 개의 코드부가 있다

상기 자바 클래스 파일은 하기와 같은 VP 툴로 변환된다:

·데이터 툴. 그 이름에도 불구하고, 이는 상기 클래스에 의해 사용되기 위한 데이터와 아무관련 없다. 대신에 이름, 매개변수 및 모든 형태의 구성자, 필드, 메소드 및 클래스의 API를 구성하는 메소드 및 다른 엔트리(entities)를 포함하나 이들에 제한되지 않는 클래스에 대한 정보를 포함한다. 이를 위한 일반적인 사용은 반사(reflection)에 대한 것이다(즉, 자바 라이브러리(java library)에서 java.lang.reflect에 있는 기능). 반사는 프로그래머가 구성자(constructor), 필드, 메소드 및 클래스가 속하는 다른 엔트리를 열거하고 다루도록 하는 프로그램적인 인터페이스이다. 상기 데이터 툴은 또한 상기 클래스 파일이 이용가능하지 않거나 또는 상기 클래스 파일이 이미 번역된 상황에서, 상기 제이코드 번역기를 검사함으로써 사용된다. 상기 클래스가 VP로 번역된 곳에는, 어쨌든 클래스 파일이 없다.

·클래스 툴. 이는 (상기 클래스의 어떤 정적 데이터의 크기 및 상위 클래스 및 상위 인터페이스를 할당하기 위한 객체의 크기를 포함한) 상기 자바 가상머신에 의해 사용된 어떤 표시 정보(housekeeping information)와, 메소드가 전혀없거나, 또는 메소드의 일부, 또는 모두에 대한 코드를 포함한다.

·제로 또는 그 이상 메소드 툴. 상기 클래스 툴에 나타나지 않은 메소드는 자기 자신의 개별 툴을 갖는다. 자신의 툴에 메소드를 둘지의 결정은 상기 메소드의 크기와 같은 다수의 요인에 근거할 수 있다.

·픽스업 툴. 상기 픽스업 툴은 전형적으로 특정필드의 객체내에 오프셋을 결정하는데 사용되는 상수 픽스업 값으로 복귀한다. 상기 툴은 픽스업 시에 호출되어 상기 오프셋을 제공하며, 바인더/연결은 이 오프셋을 사용하기를 원하는 코드에 패치시킨다. 따라서 바이트코드로 "필드 읽기" 및 "필드 두기" 둘 다 구현하는데 사용된다. 더 일반적으로, 상기 픽스업 툴은 픽스업에 사용되는 데이터로 복귀한다. 이는 컴파일 시가 아니라 픽스업 시에만 결정될 수 있다. 상기 데이터는 클래스 인스턴스(class instance)의 크기 및 필드의 클래스 인스턴스 내의 오프셋을 포함하나 이에 국한되지 않는다.

상기 데이터 툴은 만일 상기 자바 애플리케이션이 어떤 편의를 사용하지 않는 것(대부분 반사한다)으로 알려진다면 무시될 수 있고, 상기 픽스업 툴은 만일 상기 자바 애플리케이션이 또 다른 자바 클래스를 동적으로 로드하지 않는 장치에 내장된다면 무시될 수 있다.

상기 제이코드 번역기는 스택상에 각 항목에 대한 VP 레지스트를 사용한다.

VP 코드는 상기 바이코드내에 또 다른 클래스, 메소드 또는 필드를 접속하기 위한 클래스 파일의 메카니즘을 직접적으로 구현하지 않는다. 상기 바이트코드에는 (이 클래스 또는 다른 클래스에서) 메소드 호출과, (이 클래스 또는 다른 클래스에서) 필드의 내용 읽기와, 상기 스택상에 값을 푸시하기와, 상기 스택 밖으로 값을나타내기와 필드의 내용을 설정하는 명령이 있다. 상기 제이코드 번역기는 이 명령들을 하기 명령(이는 포괄 리스트가 아니다)중 한 명령을 수행하는 VP 명령들로 변환한다.

·클래스에서 비-정적 메소드(non-static method) 호출(즉, 객체 포인터는 통과되어야만 한다는 것에 대한 명령). VP는 자바 클래스를 구현하는데 사용되는 메소드를 갖는 클래스의 개념을 갖는다. 이와 같은 메소드는 가상적(호출된 실재 메소드는 객체의 포인터가 통과되는 클래스에 의존한다)또는 비가상적(호출된 메소드는 호출시에 특정된 클래스에 있다)이라 부를 수 있다.

·서브루틴 호출. 이는 정적 메소드(즉,어떤 객체포인터도 통과될 필요가 없는 명령), 및 어떤 경우에는 비정적 메소드의 바이트코드 호출을 구현하는데 사용된다.

·상기 상수 필스업의 값을 상기 픽스업 툴로부터 읽기.

클래스 파일내 상기 상수 풀은 하기와 같이 변환된다:

·상수(정수 또는 부동 소수점)를 포함한 상수 풀 엔트리는 상수를 참조하는 상기 JBC 명령의 컴파일된 버전에 통합된다.

·JBC 명령에 의해 직접 사용된 스트링 데이터(string data)를 포함한 상수 풀 엔트리는 상기 컴파일러의 출력 코드에 첨부된 상기 데이터로 복사된다.

·스트링 데이터를 포함한 다른 상수 풀 엔트리는 직접 사용되지 않고 하기의 상수 풀 형태 또는 상기 클래스 파일의 다른 부분에 의해 참조될 때 사용된다.

·클래스 C를 참조한 상수 풀 엔트리(entry)는 상기 클래스 C를 참조하는 픽스업(또는 상기 클래스에 대한 상기 JVM의 내부 이름)이 상기 컴파일러의 출력 코드/데이터에 첨부되도록 하여 C를 참조하기 위한 이 상수 풀 엔트리를 사용한 JBC 명령이 상기 픽스업을 적용한 후 클래스 C의 코드 및 데이터에 대한 접근을 얻는 원시코드 순서로 컴파일된다.

·클래스 C에서 필드 F를 참조하는 상수 풀 엔트리는 C에서 F를 참조한 픽스업(또는 C에서 F에 대한 상기 JVM의 내부 이름)이 상기 컴파일러의 출력 코드/데이터에 첨부되도록 하여 F를 참조하기 위한 이 상수 풀 엔트리를 사용한 JBC 명령이 상기 픽스업을 적용한 후, 필드 F에 접근을 얻는 원시 코드순서로 컴파일된다.

·클래스 C에서 메소드 M을 참조한 상수 풀 엔트리는 C에서 M을 참조한 픽스업(또는 C에서 F에 대한 상기 JVM의 내부 이름)이 상기 컴파일러의 출력 코드/데이터에 첨부되도록 하여 M을 참조하기 위한 이 상수 풀 엔트리를 이용한 JBC 명령이 상기 픽스업 적용후, 메소드 M에 대한 접근을 얻는 원시코드 순서로 컴파일된다.

·필드 또는 메소드의 이름 및 형태를 주는 상수 풀 엔트리는 직접사용되지 않고, 다른 상수 풀 엔트리 형태 또는 상기 클래스 파일의 다른 부분에 의해 참조될 때 사용된다.

클래스 파일내 코드부는 하기와 같이 변환된다:

·순수한 숫자 계산을 하는 코드(즉, 외부 메소드를 참조하지 않음)는 바이트코드로부터 VP에서 상응하는 툴로 직접 번역되어 진다.

·도 6에서 도시된 바와 같이, 상기 바이트코드(600)는 픽스업시에 호출(611)에 의해 상기 픽스업 툴로 변환되는 필드에 대한 참조(610)를 가지고 있다. 상기 픽스업 툴에 대한 호출은 상기 필드의 위치를 참조하는 값으로 복귀한다. 따라서, 명령이 실행되는 시기에 올바른 오프셋을 포함하도록 패치된다.

·정적 메소드(static method)(620)는 상응하는 VP 툴로 변환되나 픽스업 코드(620)가 추가된다.

·비-정적 메소드(630)는 상응하는 VP 툴에 메소드 호출(즉 상기 메소드 이름에 대한 참조)용 픽스업을 추가한다. 이는 결국 최종 원시코드내 아톰(atom)이 된다.

·호출 규정(callling convention)은 바이트코드 및 VP에서 오히려 다르다. 자바 바이트코드와 같은 종래 바이트코드에서, 서브루틴에 전해지게 될 매개변수는 상기 스택상에 위치되고 나서 호출되도록 상기 메소드에 대한 참조로써 뒤따른다. 그리고 나서 상기 스택으로부터 상기 메소드 참조를 하고, 분석하고, 상기 스택으로부터 매개변수를 갖는 새로운 매소드 실행을 개시하는 메소드 호출을 위한 바이트코드 명령이 실행된다. 콘트롤은 복귀(return) 명령이 실행될 때 최초의 메소드로 복귀된다. 이는 수신지 메소드를 가리키도록 설정된 고 명령(gos instruction) (goto 서브루틴)을 실행하기 전에 모든 매개변수를 VP 레지스터에 로드하는 VP로 변환된다(이 픽스업은 통계적이거나 또는 동적으로 묶일 수 있다). 실행은 'ret' 명령이 실행될 때 서브루틴에 전해지고 복귀한다.

상기 파일의 다른 부분들은 하기와 같이 변환된다:

·상기 클라스의 이름은 컴파일러에 의한 코드와 데이터 출력을 참조하기 위한 상기 JVM에 의해 사용되는 이름을 결정한다.

·슈퍼클래스의 이름은 컴파일러의 의한 코드 및 데이터 출력내 슈퍼클래스에 대해 어떤 참조가 된다. 바람직한 실시예에서, 출력 데이터는 연결(linking)후에 포인터가 슈퍼클래스 코드와 데이터를 지시하도록 첨부된 픽스업을 갖는 포인터를 포함하고 있다.

·각각의 인터페이스의 이름은 출력 코드 및 데이터내에 인터페이스에 대해 어떤 참조가 된다. 바람직한 실시예에서, 출력 데이터는 연결후에 포인터가 인터페이스 코드와 데이터를 지시하도록 첨부된 픽스업을 갖는 각각의 인터페이스에 대한 포인터를 포함하고 있다.

·각각의 방법 (및 클래스 파일에 저장된 소스 파일 이름)에 첨부된 디버그 정보는, 존재시, JBM이 구동되는 환경에 적합한 포맷으로 변환된다. 바람직한 실시예에서, 상기 디버그 정보는 시스템의 비-자바 부분에 대해 사용되는 동일한 포맷으로 변환된다.

최종 VP 클래스는 적어도 데이터 툴, 클래스 툴, 픽스업 툴, 제로 또는 그 이상의 메소드 툴을 포함하는 일반적으로, 하나 또는 그 이상의 명명된 툴을 구비하고 있다. 툴명은 제이코드 번역기에 의해서 자동적으로 생성되고, 이들 각각의 이름은 각 상기 클래스명의 이름과 이 클래스에서 구현된 각 툴의 기능과 관련되어 있다.

도 2를 참조하여, VP코드를 원시코드로 번역하는 원시 번역기에 관해 보다 상세한 설명이 이루어질 것이다. 물론 VP 코드는 자체적으로 라이브 애플리케이션에서 절대 직접 구동되지 않고; 프로세서 의존의 원시 번역기에 의해서 프로세서상에서 실행되어질 프로세서에 대한 적절한 원시코드로 항상 변환된다는 것을 이해할 수 있을 것이다.

원시 번역기(214)는 (프로세서에 따른, 약 150k) 상당히 작은 코드 피스여서, 내장된 시스템내에서 메모리에 용이하게 저장되어질 수 있다. 원시 번역기는 VP 레지스터를 사용중인 특정한 프로세서의 레지스터에 맵핑할 수 있다. 원시 번역기는 리얼 프로세서의 레지스터 구성에 있는 자체 지식을 사용하여 출력 원시코드 각각의 포인트에서 어떤 VP 레지스터가 리얼 프러세서 레지스터에 맵핑되는지를 결정하고, 이는 (접근이 보다 늦은) 메모리내에 유지되어야 한다. 번역기는 또한 장치 의존 명령의 최적화를 제공한다. 상기 원시코드가 바운드될 때까지, 원시 코드는 픽스업 코드부를 여전히 정상적으로 포함하고 있다. 바인딩시 (또는 종종 가동시간에) 픽스업 코드는 적절한 장치 의존적인 명령에 의해서 대체되어진다. 예를 들면, 비-정적 방법에 대한 픽스업은 상기 원시 코드내에서 아톰으로 변환된다.

제이코드 번역기와 원시 번역기 둘 다는 저체적으로 VP 코드로 번역되는 것이 바람직하고, 이에 따라서 다른 필요한 플랫폼 상에서 (원시 번역기 자체를 사용하여) 구동되게 번역되어질 수 있다. 최초 VP 코드에서, 양쪽 모두의 번역기의 컴파일된 버전은 원시 코드의 형태로 제공되어질 수 있고, 상기 번역기가 수행되는 특정한 프로세서에 대해 최적화되어질 수 있다. 상기 제이코드 번역기에 대한 VP 코드를 컴파일하기 위해서, 이 코드는 상기 원시 번역기를 거친다. 상기 원시 번역기용 VP 코드를 컴파일하기 위해, 상기 코드는 스스로 원시 번역기를 거친다.

비록 바람직한 실시예가 자바 가상머신(Java Virtual Machine)을 사용하지만, 전반적인 발명의 개념은 보다 일반적이고, JVM을 사용하는 것이 필수적인 것은 아니며, 또는 자바만을 사용하는 것은 전혀 아니다. 그러나 자바가 사용되는 경우에, 기술된 본 발명은 자바에 숙련된 응용 프로그래머가 VP코드에 대한 이해나 지식이 전혀 없는 상태에서도 자신이 선호하는 언어로 프로그램을 개발할 수 있게 한다.

본 발명의 상세한 설명에 포함됨.

Claims

다수의 메소드를 각각 포함하는 클래스 형태로 제공된 프로그램 코드를 구비하고, 상기 클래스의 프로그램 코드를 또한 유지할 필요없는 실행환경에서 실행하기 위해, 상기 클래스의 메소드를 컴파일된 코드로 컴파일하는 단계와, 상기 코드를 유지하는 단계를 포함한 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 프로그램 코드는 상기 실행환경으로 로드되지 않는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 프로그램 코드는 상기 실행환경으로 로드되고 나서 버려지는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 메소드를 컴파일 하는 단계는 상기 메소드를 가상 프로세서의 명령 셋트를 이용한 가상 프로세서 코드로 번역하고 나서 상기 가상 프로세서 코드를 원시 코드로 번역하는 단계를 포함한 객체지향 컴퓨터 프로그램의 로딩 방법.
제 4 항에 있어서,

상기 가상 프로세서 코드는 상기 실행환경으로 로드되지 않는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 4 항에 있어서,

상기 가상 프로세서 코드는 상기 실행환경으로 로드되고 나서 버려지는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 실행 환경은 클라이어트 장치에 있고, 상기 컴파일된 코드는 통신 네트워크를 가로질러 상기 클라이언트 장치에 전송되며, 상기 프로그램 코드는 전송되는 것이 필수적이지 않는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 4 항에 있어서,

상기 실행환경은 클라이어트 장치에 있고, 상기 가상 프로세서 코드는 통신 네트워크를 가로질러 상기 클라이언트 장치에 전송되며, 상기 프로그램 코드는 전송되는 것이 필수적이지 않는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 4 항에 있어서,

상기 실행 환경은 클라이어트 장치에 있고, 상기 원시 코드는 통신 네트워크를 가로질러 상기 클라이언트 장치에 전송되며, 상기 프로그램 코드는 전송되는 것이 필수적이지 않는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 클래스의 다수의 메소드를 컴파일하는 단계와 정적으로 상기 다수의 메소드를 연결하는 단계를 포함하는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 실행환경으로 상기 컴파일된 코드의 로딩시 상기 클래스의 다수의 메소드를 결합하는 단계와 동적으로 상기 다수의 메소드를 연결하는 단계를 포함하는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 실행환경에 상기 컴파일된 코드의 실행시 상기 클래스의 다수의 메소드를 컴파일하는 단계와 동적으로 상기 다수의 메소드를 바인딩하는 단계를 포함하는 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항에 있어서,

상기 클래스는 자바 클래스인 객체지향 컴퓨터 프로그램의 로딩 방법.
제 1 항 내지 제 13 항 중 어느 한 항에 있어서,

상기 프로그램을 로딩하는 단계와, 상기 실행환경에서 상기 프로그램을 실행하는 단계를 구비한 객체지향 컴퓨터 프로그램의 실행 방법.
제 1 항 내지 제 14항 중 어느 한 항에 따른 메소드를 실행하기 위해 채택된 객체지향 컴퓨터 프로그램.
다수의 메소드를 각각 포함하는 클래스 형태로 제공된 프로그램 코드를 구비하고, 실행환경을 정의하며 상기 클래스의 프로그램 코드를 또한 유지할 필요없는 상기 실행환경에서 실행하기 위해, 상기 클래스의 메소드를 컴파일된 코드로 컴파일하고 상기 컴파일된 코드를 유지하도록 작동될 수 있는 객체지향 컴퓨터 프로그램의 로딩을 위한 컴퓨터 시스템.
전송 수단을 통해 다수의 클라이언트 장치와 통신하는 서버를 구비하고, 상기 각각의 클라이언트 장치는 다수의 메소드를 각각 포함한 클래스 형태로 제공된 프로그램 코드를 구비한 객체지향 컴퓨터 프로그램을 실행하기 위한 각각의 실행환경을 가지고 있으며,

(a) 상기 프로그램 코드를 컴파일된 코드로 컴파일하기 위한 수단과,

(b) 상기 클라이언트 장치중 하나에 실행하기 위해 상기 클래스중 하나에 대한 상기 메소드중 하나를 선택하기 위한 수단과,

(c) 상기 서버로부터 상기 클라이언트 장치까지 상기 선택된 클래스의 프로그램 코드를 필수적으로 전송하지 않아도 컴파일된 코드를 전송하는 수단을 포함하는 분산 컴퓨터 시스템.
제 17 항에 있어서,

상기 프로그램 코드를 컴파일하기 위한 수단은 상기 프로그램 코드를 가상 프로세서의 명령셋트를 이용한 가상 프로세서 코드로 번역하는 수단과, 상기 가상 프로세서 코드를 원시 코드로 번역하는 수단을 구비한 분산 컴퓨터 시스템.
제 18 항에 있어서,

상기 컴파일된 코드를 전송하기 위한 수단은 상기 서버로부터 상기 클라이언트 장치로 상기 가상 프로세서 코드를 전송하기 위한 수단을 구비한 분산 컴퓨터 시스템.
제 18 항에 있어서,

상기 컴파일된 코드를 전송하기 위한 수단은 상기 서버로부터 상기 클라이언트 장치로 상기 원시 코드를 전송하기 위한 수단을 구비한 분산 컴퓨터 시스템.
제 17 항 내지 제 20 항 중 어느 한 항에 있어서,

상기 전송 수단은 무선 네트워크로 이루어지거나 포함하는 분산 컴퓨터 시스템.
제 21 항에 있어서,

상기 클라이언트 장치는 이동전화인 분산 컴퓨터 시스템.
제 21 항에 있어서,

상기 클라이언트 장치는 게임 콘솔인 분산 컴퓨터 시스템.
제 21 항에 있어서,

상기 클라이언트 장치는 휴대용 컴퓨터인 분산 컴퓨터 시스템.
다수의 클라이언트 장치로 다수의 메소드를 각각 포함하는 클래스 형태로 제공된 프로그램 코드를 구비하고, 상기 각각의 클라이언트 장치는 각각의 실행환경을 포함하고 있으며,

(a) 선택된 클래스의 선택된 메소드를 컴파일된 코드로 번역하기 위한 수단과,

(b) 상기 실행환경으로 프로그램 코드를 필수적으로 로딩하지 않고도 각각의 실행환경으로 실행하기 위해, 상기 컴파일된 코드를 로딩하기 위한 수단을 구비한 객체지향 컴퓨터 프로그램의 로딩을 위한 컴퓨터 시스템.
제 25 항에 있어서,

각각의 실행환경에서 상기 선택된 메소드를 정적으로 연결하도록 배열된 객체지향 컴퓨터 프로그램의 로딩을 위한 컴퓨터 시스템.
제 1 항 내지 14 항 중 어느 한 항에 따른, 방법을 실행하기 위해 채택된 객체지향 컴퓨터 프로그램의 로딩을 위한 컴퓨터 시스템.
제 1 항 내지 14 항 중 어느 한 항에 따른 방법을 실행하기 위해 채택된 컴퓨터 프로그램을 실행하는 데이터 캐리어.
제 1 항 내지 14 항 중 어느 한 항에 따른 방법을 실행하기 위해 채택된 컴퓨터 프로그램을 나타내는 데이터 스트림.