KR20040111149A - 내장형 가비지 수집 - Google Patents

내장형 가비지 수집 Download PDF

Info

Publication number
KR20040111149A
KR20040111149A KR1020040045409A KR20040045409A KR20040111149A KR 20040111149 A KR20040111149 A KR 20040111149A KR 1020040045409 A KR1020040045409 A KR 1020040045409A KR 20040045409 A KR20040045409 A KR 20040045409A KR 20040111149 A KR20040111149 A KR 20040111149A
Authority
KR
South Korea
Prior art keywords
objects
root
garbage collection
memory
changed
Prior art date
Application number
KR1020040045409A
Other languages
English (en)
Inventor
제라드 쇼블
라쎄르세르쥬
덩베르노도니미끄
꾸셀라마이자
카빌리끄질베르
르쏘쟝필립
바나뜨르미셸
루또쟝-뽈
마주르살람
빠랭프레데릭
Original Assignee
텍사스 인스트루먼츠 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 텍사스 인스트루먼츠 인코포레이티드 filed Critical 텍사스 인스트루먼츠 인코포레이티드
Publication of KR20040111149A publication Critical patent/KR20040111149A/ko

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • G06F12/0269Incremental or concurrent garbage collection, e.g. in real-time systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99956File allocation
    • Y10S707/99957Garbage collection

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Memory System (AREA)

Abstract

전자 시스템은 프로세서, 프로세서에 결합된 메모리, 및 내장형 가비지 수집(embedded garbage collection) 오브젝트가 활성되게 하는 어플리케이션 프로그래밍 인터페이스를 포함한다. 메모리는 루트 오브젝트들로부터 참조들을 선택적으로 갖는 하나 이상의 오브젝트들을 저장한다. 내장형 가비지 수집 오브젝트는 바람직하게는 제어 데이타를 사용하여 오브젝트들이 상기 메모리로부터 제거되게 하고, 이 제거된 오브젝트들은, 내장형 가비지 수집 오브젝트가 활성인 동안에 생성되고 루트 오브젝트들로부터 참조들을 갖지 않는 오브젝트들을 포함한다.

Description

내장형 가비지 수집{EMBEDDED GARBAGE COLLECTION}
<발명의 기술 분야>
본 발명은 일반적으로 프로세서들에 관한 것으로, 특히 프로세서들과 연관된 메모리의 관리에 관한 것이다.
<발명의 배경>
많은 유형의 전자 디바이스들이 배터리에 의해 동작되며, 따라서 바람직하게는 가능한 한 적은 전력을 소모한다. 예로는 셀룰러 전화기가 있다. 또한, 셀 폰같은 전자 디바이스에 다양한 유형들의 멀티미디어 기능을 구현하는 것이 바람직할 수 있다. 멀티미디어 기능의 예로는, 게임, 오디오 디코더, 디지탈 카메라 등을 포함할 수 있으며, 이에 제한되지 않는다. 따라서, 이러한 기능을 전자 디바이스에서, 다른 모든 조건들이 동일하다면, 빠르고, 가능한한 적은 전력을 소모하며, 가능한한 메모리를 적게 필요로하는 방법으로 구현하는 것이 바람직하다. 이러한 영역에서의 개선이 필요하다.
일부 실시예에서는, 전자 시스템은 프로세서, 프로세서에 결합된 메모리, 및 내장형 가비지 수집 오브젝트(embedded garbage collection object)가 활성되게 하는 어플리케이션 프로그래밍 인터페이스를 포함한다. 메모리는 루트 오브젝트들로부터 참조들을 선택적으로 갖는 하나 이상의 오브젝트들을 저장한다. 내장형 가비지 수집 오브젝트는 바람직하게는 제어 데이타를 사용하여 오브젝트들이 상기 메모리로부터 제거되게 하고, 이 제거된 오브젝트들은 내장형 가비지 수집 오브젝트가 활성인 동안에 생성되고 루트 오브젝트들로부터 참조들을 갖지 않는 오브젝트들을 포함한다.
다른 실시예에서는, 방법은 내장형 가비지 수집기를 개시시키는 단계, 및 메모리로부터 제거하기 위한 오브젝트를 선택하는 단계 - 상기 메모리는 연관된 오브젝트들에 대한 참조들을 선택적으로 가질 수 있는 루트 오브젝트들을 포함함 -, 및 선택된 오브젝트를 제거하는 단계를 포함한다. 제거하기 위한 오브젝트를 선택하는 단계는, 콘텍스트가 변경된 루트 오브젝트들을 식별하는 단계 및 어느 오브젝트들이 콘텍스트가 변경된 루트 오브젝트와 연관되어 있는지를 결정하기 위해 참조 오브젝트들에 대한 상기 식별된 루트 오브젝트들을 추적하는 단계를 포함한다. 선택된 오브젝트를 제거하는 단계는, 상기 내장형 가비지 수집기가 활성이었던 동안에 생성되고, 콘텍스트가 변경된 루트 오브젝트와 연관된 것으로서 결정되지 않은 오브젝트를 제거하는 단계를 포함한다.
<표기 및 명명>
이하의 상세한 설명 및 특허청구범위 전체를 통해 특정한 시스템 구성요소들을 지칭하는 특정한 용어가 사용된다. 당업자가 이해하는 바와 같이, 반도체 회사들은 구성요소를 서로 다른 명칭으로 언급하는 경우가 있다. 이 서류는 명칭은 서로 다르나 기능은 다르지 않은 구성 요소들을 구별하고자 하는 것은 아니다. 다음의 설명 및 특허청구범위에서, "포함(including)" 및 "포함(comprising)"이라는 용어는 개방적인 의미로 사용되며, 따라서 "포함하나, 이에 제한되는 것은 아닌..."을 의미하는 것으로 해석되어야 한다. 또한, "결합(couple)" 또는 "결합들(couples)"이라는 용어도 간접 또는 직접 접속 중 하나를 의미하는 것으로 의도된다. 따라서, 제1 장치가 제2 장치에 결합되면, 그 접속은 직접적인 접속을 통해 또는 다른 장치 및 접속을 경유한 간접 접속을 통한 것일 수 있다.
도 1은 전자 시스템의 예시적인 힙(heap)의 블록도.
도 2는 본 발명의 바람직한 실시예에 따르며 JSM(Java Stack Machine) 및 MPU(Main Processor Unit)를 포함하는 시스템의 다이어그램.
도 3은 본 발명의 바람직한 실시예에 따르며 데이타 구조들을 포함하는 힙의 블록도.
도 4는 본 발명의 바람직한 실시예에 따른 가비지 실행의 제1 스테이지 동안의 힙의 블록도.
도 5는 본 발명의 바람직한 실시예에 따른 가비지 실행의 제2 스테이지 동안의 힙의 블록도.
도 6은 본 발명의 바람직한 실시예에 따른 가비지 실행의 제3 스테이지 동안의 힙의 블록도.
도 7은 본 발명의 바람직한 실시예에 따른 가비지 실행의 제4 스테이지 동안의 힙의 블록도.
도 8은 본 발명의 바람직한 실시예에 따른 가비지 실행의 제5 스테이지 동안의 힙의 블록도.
<도면의 주요 부분에 대한 부호의 설명>
200: 시스템
202: JSM
204: MPU
206: 메모리
208: JVM
210: 컴파일러
212: 바이트코드
214: 디스플레이
본 발명의 바람직한 실시예들에 대한 더욱 상세한 설명을 위하여, 첨부하는 도면들이 참조된다.
다음은, 본 발명의 다양한 실시예들에 관한 설명이다. 비록 하나 이상의 이 실시예들이 바람직한 것들이라 해도, 다르게 특정되지 않는 한, 청구범위를 포함하는 개시된 실시예들은 개시의 범주를 제한하는 것으로써 해석되어서는 안되며, 또는 다른 경우에는 제한하는 것으로 사용되어서는 안된다. 또한, 당업자라면, 다음의 설명은 광범위한 응용 분야를 포함하며, 어떠한 실시예에 대한 설명도 그 실시예의 예시일 뿐이지, 청구범위를 포함하는 개시의 범주를 제한하고자 하는 것으로 의도되어서는 안된다.
여기에 개시된 주제는 스택-기반 랭귀지(예를 들어, Java)와 관련된 프로그램이 저장될 수 있는 메모리를 갖는 프로세서 등의 프로그램가능한 전자 디바이스에 관한 것이다. 컴퓨터 프로그램들은 하드웨어, 소프트웨어, 또는 하드웨어 및 소프트웨어 양자에 의해 구현될 수 있는 "가상(virtual)" 머신을 통해 실행될 수 있다. 가상 머신은 컴퓨터 프로그램을 머신 코드(예를 들어, 자바 바이트코드(Java bytecodes))로 변환할 수 있으며, 이 머신 코드는 "스택"으로 지칭되는 메모리의 일부분에서 기본적인 컴퓨터 동작들을 수행할 수 있다. 가상 머신에 의해 실행되는 동안에, 자바 바이트코드는 스택을 이용하여 중간값들을 저장할 수 있다.
스택 외에도, 메모리의 일부가 자바 오브젝트(예를 들어, 변수, 클래스, 유형)의 저장을 위해 예약될 수 있다. 메모리의 이 부분을 "힙(heap)"이라고 부를 수 있다. 자바 오브젝트가 생성되면, 오브젝트는 힙에 메모리를 할당한다. 힙에 할당되는 메모리의 크기는 생성된 오브젝트에 포함된 자바 필드(Java fields)의 유형(예를 들어, int, long, array)에 따라 달라질 수 있다. 가상 머신은 이용되는 힙의 비율에 따라 힙을 위해 예약된 메모리의 양을 조절할 수 있다. 예를 들면, 힙이 과도 사용되면(over-utilized), 가상 머신은 힙을 위해 추가 메모리를 예약한다.
힙에 저장된 오브젝트들은 "참조(reference)"로서 지칭되는 메카니즘을 통해 힙에 저장된 다른 오브젝트들을 사용할 수 있다. 예를 들면, 제1 오브젝트는 제2 오브젝트와 관련된 변수를 사용할 수 있다. 일단 힙에 로드되면, 제1 오브젝트는 제2 오브젝트에 대한 참조를 생성할 수 있다. 오브젝트들 사이의 참조가 생성되면, 제1 오브젝트는 제2 오브젝트와 관련된 변수를 액세스할 수 있다. 오브젝트와 관련된 모든 참조들의 세트는 그 오브젝트에 대한 "콘텍스트(context)"로서 지칭된다. 참조 필드 상에 또는 어레이 엘리먼트 상에 기입을 행하는 모든 자바 바이트코드에 대응하는 "PutRef" 동작을 통해 참조들이 삽입되고 변경된다. 이렇게 해서, 자바 오브젝트의 콘텍스트는 오브젝트에 대해 오직 PutRef 동작이 발행될 때에만 변경할 수 있다.
힙의 크기는 시스템과 관련된 메모리의 총량에 의해 제한될 수 있다. 일단 힙이 이 최대 크기에 도달하여 완전히 사용되게 되면, 추가의 오브젝트들이 생성되지 않는다. 이 상태가 발생하면, 더이상 필요 없을 수 있는 현재 힙에 저장된 오브젝트들은 자바 프로세스에 의해 힙으로부터 꺼내져서 다른 오브젝트들을 위한 공간을 만들게 된다. 힙으로부터 오브젝트들을 제거할 책임이 있는 자바 프로세스는 "가비지 수집(garbage collection)" 프로세스라고 지칭될 수 있다. 가비지는, 가비지 수집 프로세스가 힙으로부터 영원히 제거하기 위해 선택하는 오브젝트들을 나타낸다. 가비지 수집 프로세스가 힙으로부터 오브젝트들을 영원히 제거한 후에, 이 오브젝트들과 관련된 메모리는 다른 오브젝트들을 위해 할당될 수 있다.
가비지 수집 프로세스는 힙으로부터 영원히 제거될 수 있는 오브젝트들을 식별하기 위해 "루트(roots)"를 이용한다. 비록 사용자가 루트를 할당한다고 해도, 일반적으로 루트는 기본적인(underlying) 오브젝트 실행시간(runtime)에 의해 자동적으로 할당된다. 이 오브젝트 실행시간은, 어플리케이션 자신이 보았을 때 필요하지 않은 오브젝트들인 어플리케이션의 제1 오브젝트들을 생성하거나, 또는 오브젝트들에 대한 참조를 포함하고 이 오브젝트들을 루트로서 할당하는 스택들(메모리 블록들)을 생성한다.
루트를 식별하고 할당한 후에, 가비지 수집 프로세스는 루트들로부터 다른 오브젝트들로 참조를 검사한다. 예를 들면, 도 1은 루트(102) 및 오브젝트들(104, 106, 108, 및 110)을 포함하는 예시의 힙(100)을 도시한다. 비록 명확히 도시되지는 않았지만, 루트(102)는 가비지 수집 프로세스에 의해 루트로서 할당된 힙에 저장된 임의의 오브젝트들을 포함할 수 있다. 루트(102)는 참조(112)를 통해 오브젝트(104)를 직접 참조할 수 있다. 오브젝트(104)는 참조(114)를 통해 오브젝트(106)를 참조할 수 있다. 가비지 수집 프로세스가 힙(100) 상에서 실행될 때, 루트(102)로부터의 모든 참조들을 가비지 수집 프로세스 내의 절차가 따를 수 있다. 루트 오브젝트로부터 힙에 저장된 다른 오브젝트로의 후속 참조들의 절차는 "추적 루틴(trace routine)"으로서 지칭될 수 있다. 예를 들면, 힙(100) 상의 추적 루틴은 자바 오브젝트들(104 및 106)을 루트(102)에 의해 액세스가능한 것으로서 식별할 수 있다. 추적 루틴 중에 식별된 오브젝트들에 기초하여, 가비지 수집 프로세스는 어느 오브젝트들이 힙으로부터 제거되어야 하는지를 결정할 수 있다. 추적 루틴(tracing routine)에서 식별된 오브젝트들은 통상적으로 제거되지 않으며, 추적 루틴에서 식별되지 않은 오브젝트들은 제거된다. 추적 루틴이 루트로부터 시작하기 때문에, 식별된 오브젝트들은 루트로부터 "도달가능한(reachable)" 오브젝트라고 부르며, 식별되지 않은 오브젝트들은 "도달불가능한(unreachable)" 오브젝트라고 부른다. 이 제거 기술에 대한 이론적 해석은 추적 루틴에서 식별되지 않은 오브젝트들을, 실행 어플리케이션에서 필요하지 않은 것으로써 고려하므로, 제거될 수 있다는 것이다. 도 1의 예에서, 오브젝트들(108 및 110)은 참조들을 갖지 않으므로, 힙(100) 상의 추적 루틴에서 식별되지 않을 것이다. 이렇게 해서, 가비지 수집 프로세스는 이 오브젝트들을 힙으로부터 제거할 수 있다. 본 발명의 바람직한 실시예는 상술한 것과 같은 가비지 수집기들을, 이하에 기술하는 바람직한 가비지 수집기들과 결합할 수 있다.
이하에서는 머신(예를 들어, 프로세서, 가상 머신)에 의해 오브젝트들이 이용된 후에, 가비지 수집 프로세스가 힙으로부터 오브젝트들을 제거할 수 있는 시스템의 바람직한 실시예의 동작이 기술된다. 그외의 프로세서 아키텍처들 및 실시예들을 사용할 수 있으며, 따라서 본 개시 및 후속하는 청구범위는 프로세서의 임의의 특정 유형에 제한되지 않는다. 가비지 수집 프로세스에 대한 상세한 설명은 프로세서 및 가상 머신의 설명을 따른다.
여기에 기술된 프로세서는 JavaTM바이트코드(Bytecodes) 또는 필적하는 코드를 실행하기에 특히 적합하다. 공지된 바와 같이, 자바는 특히 임베디드 어플리케이션들에 적합하다. 자바는 평균적으로 각 명령어가 다양한 다른 프로그래밍 랭귀지들에 비해 많은 수의 기능들을 수행하는 것을 의미하는 비교적 "조밀한(dense)" 랭귀지이다. 자바의 조밀한 특성은, 바람직하게는 가능한한 작은 메모리를 포함하여 공간과 전력을 절약할 수 있는 휴대형의 배터리 동작되는 디바이스들에 특히 적합하다. 그러나, 자바 코드를 실행하기 위한 이유는 본 개시 또는 후속하는 청구범위의 소재가 아니다.
이제 도 2를 참조하면, 본 발명의 바람직한 실시예에 따른 시스템(200)이 도시되어 있다. 도시된 바와 같이, 시스템은 적어도 2개의 프로세서들(202 및 204)을 포함한다. 프로세서(202)는 본 개시의 목적을 위해 JSM(Java Stack Machine)으로서 지칭되고, 프로세서(204)는 MPU(Main Processor Unit)으로서 지칭된다. 시스템(200)은 또한 JSM(202) 및 MPU(204) 모두에 결합되었으며, 따라서 두 프로세스들에 의해 액세스 가능한 메모리(206)를 포함할 수 있다. 적어도 메모리(206)의 일부는 두개의 프로세서들에 의해 공유될 수 있으며, 이것은 두 프로세서들이 동일한 공유된 메모리 위치들을 액세스할 수 있음을 의미한다. 또한, 원한다면, 메모리(206)의 일부는 한 프로세서 또는 다른 프로세서에게 비밀의 것으로써 설계될 수 있다. 시스템(200)은 또한 JVM(Java Virtual Machine)(208), 컴파일러(210) 및 디스플레이(214)를 포함한다. JSM(202)은 바람직하게는 키패드 등의 하나 이상의 입력/출력("I/O") 디바이스들에 대한 인터페이스를 포함하여 사용자로 하여금 시스템(200)의 다양한 특징들을 제어할 수 있게 한다. 또한, I/O 공간으로부터 JSM(202)으로 데이타 스트림들을 수신하여 JSM(202)에 의해 처리될 수 있다. 그외의 컴포넌트들(특별히 도시되지느 않음)은 원하는대로 포함될 수 있다.
계속해서 도 2를 참조하면, 일반적으로 알려진 바와 같이, 자바 코드는 복수의 "바이트코드(Bytecodes)"(212)를 포함한다. 바이트코드(212)는 컴파일러(210)에 의해 컴파일되는 JVM(208)에 제공되고, 그 안에서의 실행을 위해 JSM(202) 및/또는 MPU(204)에 제공된다. 본 발명의 바람직한 실시예에 따르면, JSM(202)은 자바 바이트코드들의 적어도 일부를, 일반적으로는 대부분을 실행할 수 있다. 그러나, 적절할 때에는, JSM(202)은, JSM(202)에 의해 실행되지 않거나 실행가능하지 않은 하나 이상의 자바 바이트코드들을 실행하라고 MPU(204)에게 요청할 수 있다. 자바 바이트코드를 실행하는 것에 추가하여, MPU(204)는 비-자바(non-Java) 명령어들을 실행할 수도 있다. MPU(204)는 또한 오퍼레이팅 시스템("O/S")(특별히 도시되지는 않음)을 호스팅하며, 이 오퍼레이팅 시스템들은 시스템 메모리 관리, JVM(208) 및 시스템 상에서 실행하는 다른 네이티브(native) 태스크들의 대부분 또는 모두를 스케줄링하는 시스템 태스크 관리, 디스플레이(214)의 관리, 입력 장치로부터의 입력을 수신 등을 포함하는 다양한 기능들을 수행한다. 제한 없이, 자바 코드는 멀티미디어, 게임 또는 웹 기반의 어플리케이션들을 포함하는 다양한 어플리케이션들 중의 임의의 하나를 시스템(200)에서 수행하는데 사용될 수 있는 한편, O/S 및 그외의 네이티브 어플리케이션들을 포함할 수 있는 비-자바 코드는 MPU(204) 상의 시스템에서 여전히 실행될 수 있다.
JVM(208)은 일반적으로 소프트웨어 및 하드웨어의 결합을 포함한다. 소프트웨어는 컴파일러(210)를 포함할 수 있고, 하드웨어는 JSM(202)을 포함할 수 있다. JVM은 클래스 로더(class loader), 바이트코드 검증기(bytecode verifier), 여기에기술되는 바람직한 가비지 수집기와는 기능적으로 구별될 수 있는 일반적인 가비지 수집기, 및 JSM 프로세서(202) 상에서 실행되지 않는 바이트코드들을 해석하기 위한 바이트코드 인터프리터 루프를 포함할 수 있다.
본 발명의 바람직한 실시예들에 따르면, 가비지 수집 프로세스는 어플리케이션 프로그래밍 인터페이스(API)를 사용하여 컴퓨터 프로그램 내에 임베디드될 수 있다. API는 바람직하게는 프로그램 개발자들이 가비지 수집을 제어하기 위해 실행할 수 있는 일련의 기능들을 포함한다. 가비지 수집 프로세스를 프로그램 내에서 인스턴트화(instantiate)되기 때문에, 프로세스는 이 프로세스를 실행하는 프로그램과 동일한 메모리 쓰레드(thread)에서 실행된다. 동일한 메모리 쓰레드에서 실행함으로써, 내장형 가비지 수집 프로세스는 특정 프로그램에 의해 사용된 오브젝트들을 효과적으로 제거할 수 있다. 이 내장형 가비지 수집 프로세스는 여기에서 EGC(embedded garbage collector)라고 지칭될 수 있다.
내장형 가비지 수집기 API(EGC-API)는 바람직하게는 EGC의 동작을 제어하기 위한 3개의 기능들을 포함한다. 첫번째 기능은 EGC 오브젝트의 생성자(constructor) 기능으로, 이 기능은 힙의 EGC를 인스턴트화하고, EGC에 의해 사용되는 데이타 구조들을 셋업한다. 두번째 기능은 "egc.start()"이며, 이 기능은 EGC를 "활성(active)" 상태로 설정한다. 세번째 기능은 "egc.stop()"이며, 이 기능은 바람직하게는 추적 루틴을 수행하여, 힙으로부터 선택된 오브젝트들을 제거하고, 활성 EGC를 종결시킨다. EGC의 상태는 egc.start() 기능이 실행되었던 때부터 egc.stop() 기능이 실행될 때까지의 임의의 시간에 활성인 것으로 고려될 수 있다. egc.start() 및 egc.stop()은 바람직하게는 제거하기 위해 호출하는 방법의 동일한 레벨 내에 있다. 이것은 참조 검색을 위해 관련된 스택 프레임의 내용들을 분석하는 필요성을 제거할 수 있다.
EGC는 바람직하게는 EGC가 활성인 동안에 힙에 생성된 오브젝트들만을 제거하는 것에 대해 고려한다. 상술한 것 같은 그외의 가바지 수집기들은, EGC와의 조합에 사용되어 EGC가 고려하지 않은 힙으로부터의 오브젝트들을 제거할 수 있다. 또한, 추적 루틴을 위해 루트를 자동적으로 할당하는 것과는 반대로, EGC는 바람직하게는 프로그램 개발자가, 관련 EGC의 생성자의 파라미터들을 사용하는 루트를 특정할 수 있게 한다.
특정 루트들은 "루트 어레이(root array)"로 지칭되는 데이타 구조를 사용함으로써 EGC에 포함될 수 있다. EGC의 추적 루틴에 대한 루트들을 정의하는 오브젝트들에 대한 참조는 루트 어레이에 포함될 수 있다. 예를 들면, 개발자는 루트 어레이 내의 특정 오브젝트에 대한 참조를 포함할 수 있다. 이 오브젝트와 관련된 모든 참조들은 추적 루틴 중에 식별될 수 있다. 추적 루틴 중에 식별된 오브젝트들은 바람직하게는 EGC에 의해 제거되지 않는다. 현재에 또는 이전의 액티베이션 시에, EGC가 활성인 동안에 생성되었으며, 추적 루틴에서 식별되지 않은 다른 오브젝트들은 바람직하게는 제거된다. 루트 오브젝트들의 기술을 가능하게 하는 EGC의 용량은 프로그램 개발자에게 종래의 가비지 수집기들에서보다 가비지 수집 프로세스에서의 더 많은 제어를 제공한다.
도 3은 EGC에 사용하기 위한 예시의 힙(350)을 도시한다. 비록 루트 어레이가 임의의 수의 오브젝트들에 대한 참조들을 포함할 수 있다고 해도, 도 3의 예에서, 루트 어레이(300)는 3개의 루트 오브젝트들(302, 304, 및 306)에 대한 참조들을 포함한다. 각각의 루트 오브젝트는 바람직하게는 3개의 관련 데이타 변수들을 포함한다. 제1 데이타 변수는 "리치 세트(reach set)"로서 지칭되며, 참조들을, EGC의 추적 루틴 중에 식별된 오브젝트들에 배치하기 위해 사용될 수 있다. 이 참조들은 특정 루트 오브젝트에 의해 참조되는 힙에 저장된 모든 오브젝트들을 포함할 수 있다. 따라서, 루트의 리치 세트 변수는 루트 콘텍스트에 대응한다. 루트 오브젝트들(302, 304, 및 306)은 도시된 바와 같이, 리치 세트들(308, 310, 및 312)을 포함할 수 있다.
제2 데이타 변수는, 루트 오브젝트와 관련된 직접적인 또는 과도적인 참조들, 참조들의 콘텍스트가 변경되었는지의 여부를 나타내기 위해 각 루트 오브젝트와 관련될 수 있는 상태 비트이다. 이 상태 비트는 "변경(modified)" 비트로 지칭될 수 있다. 예를 들면, egc.start() 기능의 실행 시에, 루트 오브젝트들의 변경 비트는 초기에 거짓으로 설정될 수 있다. EGC의 활성 상태 동안에, 참조가 변경되거나, 생성되거나, 현재의 루트 콘텍스트의 오브젝트로부터 삭제되면, 그 루트 오브젝트의 변경 비트는 참으로 설정된다. 도시된 바와 같이, 루트 오브젝트들(302, 304, 및 306)은 각각 변경 비트들(314, 316, 및 318)을 포함한다.
본 발명의 바람직한 실시예에 따르면, 변경 비트는 JVM(208)에 의해 자동적으로 변경될 수 있다. 참조가 생성되거나 변경될 때마다, "PutRef" 명령어가 오브젝트 상의 JVM에게 발행된다. PutRef 명령어의 변경은, PutRef가 루트 콘텍스트내측의 오브젝트 상에서 행해진다면, 바람직하게는 루트 오브젝트의 변경 비트를 참으로 설정하도록 행해진다. 오브젝트가 루트 콘텍스트 내측에 있는지의 여부를 결정하기 위하여, "루트 식별자(root identifier)"로 지칭되는 제3 변수가 이하에 기술된다.
최종적으로, 각 루트 오브젝트의 제3 데이타 변수는 루트 식별자이다. 루트 식별자는 루트 오브젝트에 대한 참조를 저장한다. 따라서, 루트 오브젝트들(302, 304, 및 306)은 루트 식별자들(360, 362, 및 364)을 포함한다.
계속해서 도 3을 참조하면, 2개의 변수 어레이들이 EGC와 조합하여 사용될 수 있다. 제1 어레이(320)는 "힙세트"라고 지칭되는 것으로, 바람직하게는 오브젝트들에 대한 참조를, EGC가 활성되기 전 및 후에 EGC 루트 콘텍스트의 내측에 있는 힙에 저장하기 위해 사용된다. 예를 들면, 힙세트(320)는 EGC가 시작되기 전에 힙에 있는 오브젝트들을 포함할 수 있다. 제2 어레이(322)는 "템프세트"라고 지칭되는 것으로, 바람직하게는 EGC가 활성인 동안에 힙에 생성된 오브젝트들의 참조들을 저장하기 위해 사용된다. 힙(350)은 또한 힙 오브젝트(324)를 포함할 수 있다. 비록 도 3의 예에서 임의 소정의 시점에 임의의 수의 오브젝트들이 힙에 있을 수 있다고 해도, 힙 오브젝트(324)는 도시된 바와 같이 3개의 오브젝트들(326, 328, 및 330)을 포함한다. 각각의 오브젝트(326, 328, 및 330)와 관련되어 루트 식별자들(332, 334, 및 336)이 있다. 루트 오브젝트들의 루트 식별자와 마찬가지로, 루트 식별자는 오브젝트를 생성할 때 NULL로 설정된다. 힙 오브젝트의 루트 식별자는 바람직하게는, 힙 오브젝트를 참조하는 루트 오브젝트에 대한 참조를 저장한다.예를 들면, EGC가 활성인 동안에 오브젝트를 생성하고, 그 오브젝트를 루트 오브젝트의 콘텍스트 내로 삽입할 수 있다. 이 새롭게 생성된 오브젝트와 관련된 루트 식별자는 오브젝트를 참조하는 루트 오브젝트에 대한 참조를 포함할 수 있다. EGC 알고리즘은, 어느 루트들이 변경된 콘텍스트를 갖는지를 검출하기 위한 추적 루틴 중에, 힙 내의 오브젝트들의 루트 식별자를 설정하는 것을 담당한다
바람직한 실시예들에 따르면, 루트 식별자는 JVM(208)에 의해 자동적으로 생성될 수 있다. 힙에서 오브젝트가 생성될 때마다, "새로운(new)" 명령어가 JVM에게 발행된다. "새로운" 명령어는 바람직하게 오브젝트를 생성하고 그 오브젝트를 힙에 저장한다. "새로운" 명령어의 변경은 바람직하게는, EGC가 활성인 동안에 생성된 각각의 새로운 오브젝트에 대한 루트 식별자와 연관되어 만들어질 수 있다. 최초에는, 루트 식별자는 NULL 값으로 설정될 수 있다.
지금부터 도 4 - 도 8을 참조하여, EGC를 사용하는 예시의 힙이 설명될 것이다. EGC의 기능을 예시하기 위하여 실행의 5개 스테이지들이 도시될 것이다. 이 5개 스테이지들은 EGC의 동작을 설명하기 위하여 단독으로 사용된다. EGC의 실제적인 동작은 임의의 원하는 수의 스테이지들을 사용할 수 있다. 제1 스테이지(도 4)는 egc.start() 기능의 실행 중의 힙의 상태 및 관련된 데이타 구조들을 나타낸다. 제2 스테이지(도 5)는, EGC가 활성되고 새로운 오브젝트가 힙에 생성될 때, 힙의 상태 및 관련된 데이타 구조들을 나타낸다. 제3 스테이지(도 6)는 EGC가 활성되고 루트 오브젝트들의 콘텍스트가 변경된 동안의 힙의 상태 및 관련된 데이타 구조들을 나타낸다. 제4 스테이지(도 7)는 egc.stop() 기능의 실행 중에 힙의 상태 및 관련된 데이타 구조들을 나타낸다. 마지막으로, 제5 스테이지(도 8)는 egc.stop() 기능의 실행 후에 힙의 상태 및 관련된 데이타 구조들을 나타낸다.
이제 도 4를 참조하면, 실행의 제1 스테이지에서의 힙(350)이 도시된다. 비록 임의의 수의 루트 오브젝트들이 루트 어레이에 포함될 수 있다고 해도, 설명을 용이하게 하기 위해 3개의 루트 오브젝트들(302, 304, 및 306)이 도시된다. 이 오브젝트들은 프로그램 개발자에 의해 루트 어레이(300)에 배치된다. 변경 비트들(314, 316, 및 318)은 egc.start() 중에, 초기에는 거짓으로 설정된다. 상술한 바와 같이, 오브젝트 상에서 PutRef 동작이 수행될 때, 루트 오브젝트와 관련된 변경 비트들은 참으로 설정되며, 루트 식별자는 NULL이 아니다.
힙세트 데이타 구조는 이전 경우의 EGC에 의해 힙에 남아 있으며 루트 콘텍스트 내측에 있는 오브젝트들에 대한 참조를 포함한다. 예시의 목적을 위하여, 힙세트(320)는 2개의 오브젝트들(326 및 328)에 대한 참조를 포함할 수 있다. 오브젝트(326)는 루트(302)의 루트 콘텍스트 내측에 있으며(참조는 루트(302)와 오브젝트(326) 사이에 존재함), 오브젝트(328)는 루트(304)의 루트 콘텍스트 내측에 있다(참조는 루트(304)와 오브젝트(328) 사이에 존재함). 대응하여, 오브젝트들(326 및 328)은 각각 302 및 304로 설정된 루트 식별자들을 갖는다. 루트 식별자들은 초기의 egc.start() 호출 중에 및 모든 egc.stop() 호출 중에 설정된다. 리치세트들(308, 310, 및 312)은 템프세트(322)와 마찬가지로 실행의 제1 스테이지에서 엠프티이다. EGC가 활성인 동안에 오브젝트(330)가 생성되지 않았기 때문에, 그것은 힙세트(320)에 포함되지 않으며, EGC에 의한 제거의 대상으로 고려되지 않을 것이다.
도 5는 실행의 제2 스테이지(힙의 오브젝트 생성)에서의 힙(350)을 도시한다. 비록 이 스테이지에서 임의의 수의 오브젝트들이 생성될 수 있다고 해도, 설명을 용이하게 하기 위해 2개의 오브젝트들(352 및 354)이 도시된다. 오브젝트들(352 및 354)은 EGC가 활성인 중에 생성된다. 따라서, 오브젝트들(352 및 354)에 대한 참조는 템프세트(322)에 배치된다. 또한, 이 오브젝트들의 루트 식별자는 "널(Null)"로 설정된다. 그외의 모든 데이타 구조들은 실행의 제2 스테이지에서 변경없는 채로 남아있는다.
이제 도 6을 참조하면, 실행의 제3 스테이지(오브젝트 콘텍스트 변경)에서의 예시의 힙(350)이 도시된다. 예시의 목적을 위하여, 루트 오브젝트(304)의 참조는 오브젝트(328)로부터 오브젝트(352)로 변경된다(putref 기반의 opcode를 사용함). 오브젝트 상에서 putref opcode를 구현할 때에, 실행시간은 그 오브젝트의 루트 식별자를 사용하여 대응하는 루트 오브젝트의 변경 비트를 참으로 설정한다. 도 6에서, putref는 오브젝트(304) 상에서 실행되며, 오브젝트(304) 자신이 루트이기 때문에, 관련된 루트 식별자(360)는 오브젝트(304)와 동일하다. 그러므로, 루트 오브젝트(304)의 변경 비트는 참으로 설정된다. 그외의 모든 데이타 구조들은 실행의 제2 스테이지에서 변경없는 채로 남아있는다.
도 7은 실행의 제4 스테이지(egc.stop)에서의 힙(350)을 도시한다. 이 스테이지 중에, 여러개의 단계들이 만들어진다. 제1 단계에서, 참으로 설정된 변경 비트를 갖는 각 루트 오브젝트 및 오직 이들 루트들에 따라 추적 루틴이 이용된다.추적 루틴은 이 루트 오브젝트에 의해 참조되는 힙의 모든 오브젝트들을 식별할 수 있다. 특정 루트 오브젝트에 대해 추적 루틴 중에 식별된 모든 오브젝트들은 각각의 루트 오브젝트와 관련된 리치세트에 배치될 수 있다. 예를 들면, 루트 오브젝트(304)와 관련된 변경 비트가 참으로 설정되기 때문에, 루트 오브젝트(304) 상의 추적 루틴이 이용된다. 추적 루틴에서 오브젝트(352)가 식별되어 리치세트(310)에 배치된다. 바람직하게는, 한번에 오직 한 세트(리치세트, 힙세트, 템프세트)에만 오브젝트가 포함된다. 그러므로, 오브젝트(352)에 대한 참조는 템프세트로부터 제거된다. 제2 단계에서, 변경으로 표시된 모든 루트들로부터 추적이 행해진 후에, 여전히 템프세트(322)에 존재하는 모든 오브젝트들은 메모리로부터 제거될 수 있다. 예시의 경우에, 오브젝트(354)가 제거된다. 알고리즘의 제3 단계는 힙세트를 스캔하여, 오브젝트가 루트 콘텍스트로부터 제거되었는지의 여부를 결정한다. 제3 단계는 변경 비트가 참으로 설정된 루트 오브젝트가 있는 경우에만 수행된다. 힙세트를 스캐닝하는 경우에, 오브젝트가 변경된 루트 식별자를 가지면, 그 오브젝트는 메모리로부터 제거될 수 있다. 예를 들면, 오브젝트(328)는 실행의 이 스테이지 중에는 힙세트에 있는다. 오브젝트(328)가, 변경된 콘텍스트를 가졌던 루트 오브젝트를 참조하는 루트 식별자를 가지기 때문에, 오브젝트(328)는 EGC에 의해 힙으로부터 제거될 수 있다. 힙세트의 그외의 오브젝트인, 오브젝트(326)(도 6)는, 그것의 루트 식별자가 루트 오브젝트(302)를 참조하고 루트 오브젝트(302)가 변경된 콘텍스트를 가지지 않았기 때문에, 제거되지 않는다. 실행의 이 스테이지 중의 제4 단계는 EGC의 힙세트를 구축하는 것으로 구성된다. 힙세트를 구축하기 위하여, 참으로 설정된 변경 비트를 갖는 루트 오브젝트의 모든 리치세트는 힙세트의 내부에서 병합된다. 따라서 루트 오브젝트의 리치세트들은 엠프티가 된다.
마지막으로, 도 8은 실행의 제5 스테이지에서의 힙(350)을 도시한다. 루트 오브젝트들은 바람직하게는 루트 어레이(300)로부터 클리어된다. 힙세트의 모든 오브젝트들은 힙(350)에 남아 있는다. 임의의 이전 경우의 EGC가 활성이었던 동안에 오브젝트(352)가 생성되지 않았기 때문에, 오브젝트(352)는 역시 힙(350)에 남게 된다. 모든 다른 오브젝트들은 힙(350)으로부터 제거된다. 이제 모든 데이타 구조들은 그들의 초기 상태에 있게 되고, egc.start()가 실행될 때, EGC가 다시 액티베이트되게 한다.
상술한 개시의 내용을 충분히 이해하면, 당업자들에게는 많은 변동 및 수정이 있을 수 있다는 것이 명백할 것이다. 이하의 특허청구의 범위는 이러한 모든 변동 및 수정을 포함하는 것으로 해석되는 것을 의도한다.
본 발명에 따르면, 전자 디바이스의 기능을, 다른 모든 조건들이 동일하다면, 빠르고, 가능한 한 적은 전력을 소모하며, 가능한 한 메모리를 적게 필요로하는 방법으로 구현할 수 있다.

Claims (13)

  1. 전자 시스템에 있어서,
    프로세서;
    상기 프로세서에 결합된 메모리 - 상기 메모리는 루트 오브젝트들로부터 참조들(references)을 갖는 하나 이상의 오브젝트들을 저장함 -; 및
    내장형 가비지 수집(embedded garbage collection) 오브젝트의 상태를 제어하는 어플리케이션 프로그래밍 인터페이스
    를 포함하고,
    상기 어플리케이션 프로그래밍 인터페이스는 프로그램으로부터 호출되고, 상기 내장형 가비지 수집 오브젝트는 제어 데이타를 사용하여 오브젝트들이 상기 메모리로부터 제거되도록 하며, 상기 제거된 오브젝트들은 내장형 가비지 수집 오브젝트가, 활성 상태인 동안에 생성되고 루트 오브젝트들로부터의 참조들을 갖지 않는 오브젝트들을 포함하는 전자 시스템.
  2. 제1항에 있어서,
    상기 내장형 가비지 수집기의 상태는 초기화, 활성, 또는 비활성(inactive) 상태를 포함하는 전자 시스템.
  3. 제2항에 있어서,
    상기 제어 데이타는 각각의 루트 오브젝트와 연관된 변경 비트 및 템프세트(tempset)를 포함하며, 상기 변경 비트는 상기 내장형 가비지 수집기가 활성 상태에 있을 때 상기 루트 오브젝트의 콘텍스트(context)가 변경되었는지의 여부를 나타내고, 상기 템프세트는 내장형 가비지 수집 오브젝트가 활성 상태에 있으며 루트 오브젝트에 의해 참조되지 않는 동안에 생성된 오브젝트들을 나타내는 전자 시스템.
  4. 제3항에 있어서,
    상기 루트 오브젝트와 연관된 변경 비트는 상기 루트 오브젝트의 콘텍스트가 변경되었을 때 참(true)으로 설정되는 전자 시스템.
  5. 제3항에 있어서,
    상기 루트 오브젝트의 콘텍스트의 변경은 상기 루트 오브젝트의 콘텍스트에 참조를 추가, 변경, 또는 제거하는 것을 포함하는 전자 시스템.
  6. 제3항에 있어서,
    상기 내장형 가비지 수집 오브젝트는, 콘텍스트가 변경된 루트 오브젝트들을 추적하고, 콘텍스트가 변경되지 않은 루트 오브젝트들은 추적하지 않는 전자 시스템.
  7. 제3항에 있어서,
    상기 메모리로부터 제거될 오브젝트들은, 상기 내장형 가비지 수집 오브젝트가 활성 상태에 있을 때 할당되고, 모든 변경된 루트들이 추적된 후에 상기 템프세트에 여전히 포함되어 있는 오브젝트들을 더 포함하는 전자 시스템.
  8. 제3항에 있어서,
    상기 내장형 가비지 수집 오브젝트는 상기 어플리케이션 프로그래밍 인터페이스를 호출하는 상기 프로그램과 동일한 쓰레드(thread)에서 동작하는 전자 시스템.
  9. 제3항에 있어서,
    상기 루트 오브젝트들은 상기 어플리케이션 프로그래밍 인터페이스를 호출하는 상기 프로그램에 의해 생성되고, 상기 내장형 가비지 수집 오브젝트로 패스되는 전자 시스템.
  10. 제3항에 있어서,
    상기 내장형 가비지 수집기가 활성 상태에 있는 동안에 생성되지 않은 오브젝트들을 위한 추가의 가비지 수집을 더 포함하는 전자 시스템.
  11. 가비지 수집 방법에 있어서,
    내장형 가비지 수집기를 개시시키는 단계;
    메모리로부터 제거하기 위한 오브젝트를 선택하는 단계 - 상기 메모리는 연관된 오브젝트들에 대한 참조들을 가질 수 있는 루트 오브젝트들을 포함함 -; 및
    상기 선택된 오브젝트를 제거하는 단계
    를 포함하며,
    상기 제거하기 위한 오브젝트를 선택하는 단계는, 콘텍스트가 변경된 루트 오브젝트들을 식별하는 단계, 및 어느 오브젝트들이 콘텍스트가 변경된 루트 오브젝트와 연관되어 있는지를 결정하기 위해 참조된 오브젝트들에 대해 상기 식별된 루트 오브젝트들을 추적하는 단계를 포함하며,
    상기 선택된 오브젝트를 제거하는 단계는, 상기 내장형 가비지 수집기가 활성이었던 동안에 생성되고, 콘텍스트가 변경된 루트 오브젝트와 연관된 것으로서 결정되지 않은 오브젝트를 제거하는 단계를 포함하는 가비지 수집 방법.
  12. 제11항에 있어서,
    상기 내장형 가비지 수집기를 개시하면, 각 루트 오브젝트와 연관된 변경 비트를 클리어하고, 그 다음에 상기 루트 오브젝트와 연관된 콘텍스트가 변경되었을 때 루트 오브젝트의 변경 비트를 설정하는 가비지 수집 방법.
  13. 제11항에 있어서,
    상기 식별된 루트 오브젝트들을 추적하는 단계는 콘텍스트들이 변경되지 않은 루트 오브젝트들을 추적하는 단계는 포함하지 않는 가비지 수집 방법.
KR1020040045409A 2003-06-19 2004-06-18 내장형 가비지 수집 KR20040111149A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP03291506A EP1489518B1 (en) 2003-06-19 2003-06-19 Embedded garbage collection
EP03291506.8 2003-06-19

Publications (1)

Publication Number Publication Date
KR20040111149A true KR20040111149A (ko) 2004-12-31

Family

ID=33396045

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020040045409A KR20040111149A (ko) 2003-06-19 2004-06-18 내장형 가비지 수집

Country Status (5)

Country Link
US (1) US7565385B2 (ko)
EP (1) EP1489518B1 (ko)
JP (1) JP2005011349A (ko)
KR (1) KR20040111149A (ko)
DE (1) DE60318993T2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100737345B1 (ko) * 2006-03-28 2007-07-09 한국전자통신연구원 점진적인 가비지 콜렉션 수행 시에 순환적 가비지의 회수방법 및 장치
KR100978630B1 (ko) * 2009-09-17 2010-08-27 (주)제이모바일 사전 검증 절차를 거치지 않은 자바 응용프로그램을 실행하는 방법

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7886294B2 (en) * 2004-12-28 2011-02-08 Sap Ag Virtual machine monitoring
KR100753821B1 (ko) 2005-11-01 2007-08-31 한국전자통신연구원 가비지 컬렉션 장치 및 그 방법
US20070100919A1 (en) * 2005-11-01 2007-05-03 Electronics And Telecommunications Research Institute Garbage collection unit and method thereof
KR100809293B1 (ko) 2006-03-10 2008-03-04 삼성전자주식회사 가상 머신에서 스택을 관리하는 장치 및 그 방법
US8001336B2 (en) * 2007-03-02 2011-08-16 International Business Machines Corporation Deterministic memory management in a computing environment
US8914424B2 (en) * 2008-08-13 2014-12-16 Oracle America, Inc. Efficient object pinning in a multi-threaded environment
US8200718B2 (en) * 2009-07-02 2012-06-12 Roberts Michael L Parallelized, incremental garbage collector
US8346821B2 (en) * 2010-05-07 2013-01-01 International Business Machines Corporation Orphan object tracking for objects having acquire-release semantics
US9600411B2 (en) 2011-01-31 2017-03-21 The Mathworks, Inc. System and method for determining an object's lifetime in an object oriented environment
US8892610B1 (en) 2011-07-29 2014-11-18 Google Inc. System and method for garbage collection pause reduction

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5819299A (en) * 1996-06-06 1998-10-06 Electric Communities Process for distributed garbage collection
US6629113B1 (en) * 1999-06-30 2003-09-30 International Business Machines Corporation Method and system for dynamically adjustable and configurable garbage collector
GB9907283D0 (en) * 1999-03-31 1999-05-26 Koninkl Philips Electronics Nv Memory reclamation method
US6237060B1 (en) * 1999-04-23 2001-05-22 Sun Microsystems, Inc. Cache management techniques
US6865585B1 (en) * 2000-07-31 2005-03-08 Microsoft Corporation Method and system for multiprocessor garbage collection
US6502111B1 (en) * 2000-07-31 2002-12-31 Microsoft Corporation Method and system for concurrent garbage collection
GB0027045D0 (en) * 2000-11-06 2000-12-20 Ibm Computer system with heap reset
US6611898B1 (en) * 2000-12-22 2003-08-26 Convergys Customer Management Group, Inc. Object-oriented cache management system and method
US7111294B2 (en) * 2001-01-16 2006-09-19 Microsoft Corporation Thread-specific heaps
US6542911B2 (en) * 2001-03-01 2003-04-01 Sun Microsystems, Inc. Method and apparatus for freeing memory from an extensible markup language document object model tree active in an application cache
US6999980B2 (en) * 2002-08-23 2006-02-14 Sun Microsystems, Inc. Eliminating write barriers for young objects

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100737345B1 (ko) * 2006-03-28 2007-07-09 한국전자통신연구원 점진적인 가비지 콜렉션 수행 시에 순환적 가비지의 회수방법 및 장치
KR100978630B1 (ko) * 2009-09-17 2010-08-27 (주)제이모바일 사전 검증 절차를 거치지 않은 자바 응용프로그램을 실행하는 방법

Also Published As

Publication number Publication date
US7565385B2 (en) 2009-07-21
EP1489518B1 (en) 2008-02-06
US20040260732A1 (en) 2004-12-23
EP1489518A1 (en) 2004-12-22
JP2005011349A (ja) 2005-01-13
DE60318993T2 (de) 2009-01-29
DE60318993D1 (de) 2008-03-20

Similar Documents

Publication Publication Date Title
CA2290086C (en) Method for loading a java application program
US6651080B1 (en) Techniques for implementing pluggable virtual machines
US7543285B2 (en) Method and system of adaptive dynamic compiler resolution
EP1342159B1 (en) Method and apparatus for lazy instantiation of objects in a virtual machine
US20060277368A1 (en) Method and apparatus for feedback-based management of combined heap and compiled code caches
JP2003167737A (ja) スタック使用方法
EP1489518B1 (en) Embedded garbage collection
US6681234B2 (en) Method and apparatus for storing long-lived objects in a virtual machine
US6931638B2 (en) Method and apparatus to facilitate sharing optimized instruction code in a multitasking virtual machine
US20120198184A1 (en) Memory management method, computer system and computer readable medium
WO2002091175A1 (en) Specialized heaps for creation of objects in object-oriented environments
KR100493893B1 (ko) 자바 프로그램에서 클래스 로딩 과정을 단축시키는 시스템및 방법
EP2244185B1 (en) A mobile communications device application processing system
JP2005507103A (ja) Javaヒープを実現するフレームワーク
KR101085763B1 (ko) 멀티-프로세서 시스템에서의 메모리 할당
US6854113B1 (en) Mixed-mode execution for object-oriented programming languages
KR101140522B1 (ko) 객체 관리 시스템 및 방법
EP1489492A1 (en) Two-step instruction resolution
US7150009B2 (en) Space-efficient object models for object-oriented programming languages
Cai et al. Towards a high integrity real-time Java virtual machine
US20040123289A1 (en) Multi-processing inside a virtual machine
CN105607912A (zh) 一种Java对象分配优化方法、装置及设备
McDowell et al. Unloading Java classes that contain static fields
Kato et al. Mobile substrate: Experiences of middleware-layer object mobility
JP2003271393A (ja) インライン割付による最適化方法およびそのコンパイラ

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid