KR101702708B1 - 화상 처리 장치, 그 제어 방법 및 저장 매체 - Google Patents

화상 처리 장치, 그 제어 방법 및 저장 매체 Download PDF

Info

Publication number
KR101702708B1
KR101702708B1 KR1020140068234A KR20140068234A KR101702708B1 KR 101702708 B1 KR101702708 B1 KR 101702708B1 KR 1020140068234 A KR1020140068234 A KR 1020140068234A KR 20140068234 A KR20140068234 A KR 20140068234A KR 101702708 B1 KR101702708 B1 KR 101702708B1
Authority
KR
South Korea
Prior art keywords
application
memory
control unit
class
file
Prior art date
Application number
KR1020140068234A
Other languages
English (en)
Other versions
KR20140143336A (ko
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 KR20140143336A publication Critical patent/KR20140143336A/ko
Application granted granted Critical
Publication of KR101702708B1 publication Critical patent/KR101702708B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3485—Performance evaluation by tracing or monitoring for I/O devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/504—Resource capping
    • Y—GENERAL 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
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE 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/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Memory System (AREA)
  • Facsimiles In General (AREA)
  • Debugging And Monitoring (AREA)

Abstract

이를 달성하기 위해, 화상 처리 장치는, 애플리케이션에 대한 기동 요구에 응답하여, 애플리케이션의 클래스의 클래스 파일을 판독하고, 애플리케이션을 나타내는 애플리케이션 정보를 스레드에 기록하는 코드를 판독된 클래스 파일에 포함된 메소드의 최초에 추가하며, 클래스를 로딩한다. 또한, 상기 화상 처리 장치는, 판독된 클래스 파일에 포함된 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 메모리 또는 파일 크기를 확보하고, 스레드에 기록된 애플리케이션 정보를 확보된 메모리 또는 파일 크기에 기록하는 동시에, 오브젝트를 생성하고 생성된 오브젝트의 애플리케이션 정보를 메모리 크기 또는 디스크 사용량과 결부하여 관리한다.

Description

화상 처리 장치, 그 제어 방법 및 저장 매체{IMAGE PROCESSING APPARATUS, CONTROL METHOD THEREOF AND STORAGE MEDIUM}
본 발명은 복수의 애플리케이션을 동작시키는 화상 처리 장치, 그 제어 방법 및 저장 매체에 관한 것이다.
문서의 복사, 스캔 및 인쇄와 같은 다기능 주변 기기(MFP)에 포함된 기능 이외의 애플리케이션을 실행하는 기능을 가진 현재의 MFP의 수가 증가하고 있다. 많은 MFP들이 애플리케이션 실행 환경으로서 Java 실행 환경을 가지며, Java(등록 상표)로 기술된 애플리케이션을 실행할 수 있다. 예시적인 애플리케이션 실행 환경에는 캐논(등록 상표)이 개발한 MEAP(등록 상표)가 포함된다.
한편, PC 상의 Java 애플리케이션의 경우에는 애플리케이션 당 1개의 프로세스로 애플리케이션들을 실행하지만, 많은 MFP는 CPU 또는 메모리의 제한으로 인해 OSGi 프레임워크 등을 사용하여 1개의 Java 프로세스로 복수의 애플리케이션을 실행한다. 따라서, MFP 상에서 실행되고 있는 애플리케이션들 중 하나에 버그가 있으면, 메모리 누수가 발생하고, OutOfMemoryError가 발생하여, 모든 애플리케이션이 정지할 수 있다. 또한, OutOfMemoryError는 애플리케이션이 메모리를 요구할 때 확보할 메모리가 없는 경우에 발생하기 때문에, 원활하게 작동하고 있는 애플리케이션의 실행중에 발생할 수 있다. 따라서, 메모리 누수를 야기하고 있는 애플리케이션을 특정하는 것이 곤란하다.
일본 특허 공개 번호 제 2005-269439 호에서는 스레드 마다 메모리를 측정하는 기술을 제안하고 있다. 그러나, 후술하는 도 13에 도시된 바와 같이 1개의 스레드가 복수의 애플리케이션의 코드를 실행하는 경우 등에서는, 각 애플리케이션에 대해 사용되는 메모리를 측정할 수 없다.
현재는, 메모리 누수를 발견하기 위해 다음과 같은 두 가지 방법을 고려할 수 있다. 하나의 방법은 프로파일러라는 툴을 사용하여 애플리케이션에 의해 생성된 오브젝트의 상태를 모니터링하는 것이다. 다른 방법은 Java VM이 사용하는 힙 메모리의 내용을 덤핑하고(이하, "힙 덤핑"이라 함), 애플리케이션에 의해 생성된 오브젝트를 분석하는 것이다.
이 방법들 중에서, 프로파일러를 사용하여 오브젝트의 상태를 모니터링하면, 애플리케이션의 실행 속도가 크게 저하되기 때문에, CPU 또는 메모리가 매우 제한적인 MFP에 대한 적용은 곤란하다. 따라서, 힙 덤핑을 실행하고 애플리케이션에 의해 생성된 오브젝트를 분석하는 기술이 사용되어 왔다. 마찬가지로, 애플리케이션 실행 환경으로서 사용가능한 디스크 용량이 미리 정해져 있는 경우가 있다. 디스크 풀(Disk Full)인 경우에는, 메모리 누수와는 달리, MFP를 재기동하여도 상황을 자동으로 복구할 수 없다. 따라서, "iR-ADV 매뉴얼"(캐논, "애플리케이션의 설치" 페이지, "애플리케이션의 사용" 페이지(2013년 5월 17일 검색), 인터넷 <URL:http://cweb.canon.jp/manual/ir-adv/>)에는, 애플리케이션이 미리 사용량을 선언하고, 이 사용량을 초과하지 않도록 설치 제한을 실시하는 기술이 공개되어 있다.
그러나, 상술한 종래의 기술에는 다음과 같은 문제가 있다. 종래의 힙 덤핑에서는, 취득된 힙 덤핑 정보를 디바이스로부터 취출하고 분석하여 메모리 누수를 야기하고 있는 애플리케이션의 위치를 찾고, 애플리케이션이 사용하는 메모리의 양을 집계한다. 따라서, 각 애플리케이션의 메모리 사용량을 실시간으로 알 수 없다. 한편, 프로파일러에서는, 애플리케이션의 실행 속도가 극단적으로 저하되기 때문에, 현실적으로, 각 애플리케이션이 사용하는 메모리의 양을 실시간으로 측정하는 것이 곤란하다.
애플리케이션이 미리 디스크 사용량을 선언하고 이 사용량을 초과하지 않도록 설치 제한을 실시하는 경우에도, MFP 상에서 실행되고 있는 애플리케이션들 중 하나에 버그가 있을 수 있고, 애플리케이션 실행 환경 전체가 디스크 풀 상태에 놓일 수 있다. 이 경우, 버그-프리 애플리케이션에서도 기입 오류(write error)가 발생하여, 정상적인 동작이 더 이상 가능하지 않을 수 있다.
본 발명은 성능을 유지하면서도 각 애플리케이션이 사용하는 메모리 또는 디스크의 사용량을 실시간으로 측정하기 위한 메커니즘의 실현을 가능하게 한다.
본 발명의 일 양태는 복수의 애플리케이션을 실행하는 화상 처리 장치를 제공하며, 상기 화상 처리 장치는, 애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 스레드에 기록하는 코드를 판독된 클래스 파일에 포함된 메소드(method)에 추가하며, 상기 클래스를 로딩하도록 구성된 제어 유닛과; 판독된 클래스 파일에 포함된 상기 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 메모리를 확보하고, 상기 스레드에 기록된 애플리케이션 정보를 확보된 메모리에 기록하는 동시에 해당 오브젝트를 생성하도록 구성된 오브젝트 생성 유닛과; 상기 오브젝트 생성 유닛에 의해 생성된 오브젝트의 애플리케이션 정보를 메모리 크기와 결부하여 관리하도록 구성된 메모리 관리 유닛을 포함한다.
본 발명의 다른 양태는 복수의 애플리케이션을 실행하는 화상 처리 장치를 제공하며, 상기 화상 처리 장치는, 애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 스레드에 기록하는 코드를 판독된 클래스 파일에 포함된 메소드에 추가하며, 상기 클래스를 로딩하도록 구성된 제어 유닛과; 판독된 클래스 파일에 포함된 상기 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 파일 크기를 확보하고, 상기 스레드에 기록된 애플리케이션 정보를 확보된 파일 크기와 함께 디스크 사용량으로서 기록하는 동시에 해당 오브젝트를 생성하도록 구성된 오브젝트 생성 유닛과; 상기 오브젝트 생성 유닛에 의해 생성된 오브젝트의 애플리케이션 정보와 디스크 사용량을 결부하여 관리하도록 구성된 디스크 관리 유닛을 포함한다.
본 발명의 또 다른 양태는 복수의 애플리케이션을 실행하는 화상 처리 장치의 제어 방법을 제공하며, 상기 화상 처리 장치의 제어 방법은, 제어 유닛을 사용하여, 애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 스레드에 기록하는 코드를 판독된 클래스 파일에 포함된 메소드에 추가하며, 상기 클래스를 로딩하는 단계와; 오브젝트 생성 유닛을 사용하여, 판독된 클래스 파일에 포함된 상기 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 메모리를 확보하고, 상기 스레드에 기록된 애플리케이션 정보를 확보된 메모리에 기록하는 동시에 해당 오브젝트를 생성하는 단계와; 메모리 관리 유닛을 사용하여, 상기 오브젝트 생성 유닛에 의해 생성된 오브젝트의 애플리케이션 정보를 메모리 크기와 결부하여 관리하는 단계를 포함한다.
본 발명의 또 다른 양태는 복수의 애플리케이션을 실행하는 화상 처리 장치의 제어 방법을 제공하며, 상기 화상 처리 장치의 제어 방법은, 제어 유닛을 사용하여, 애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 스레드에 기록하는 코드를 판독된 클래스 파일에 포함된 메소드에 추가하며, 상기 클래스를 로딩하는 단계와; 오브젝트 생성 유닛을 사용하여, 판독된 클래스 파일에 포함된 상기 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 파일 크기를 확보하고, 상기 스레드에 기록된 애플리케이션 정보를 확보된 파일 크기와 함께 디스크 사용량으로서 기록하는 동시에 해당 오브젝트를 생성하는 단계와; 디스크 관리 유닛을 사용하여, 상기 오브젝트 생성 유닛에 의해 생성된 오브젝트의 애플리케이션 정보와 디스크 사용량을 결부하여 관리하는 단계를 포함한다.
본 발명의 또 다른 양태는 상기 화상 처리 장치의 제어 방법의 단계를 컴퓨터가 실행하도록 하는 컴퓨터 프로그램을 저장한 컴퓨터-판독가능한 저장 매체를 제공한다.
첨부 도면을 참조한 이하의 예시적 실시예에 대한 상세한 설명으로부터 본 발명의 다른 특징들이 명확해질 것이다.
도 1은 애플리케이션 관리 장치의 구성을 나타내는 도면.
도 2는 애플리케이션 관리 장치의 소프트웨어 구성을 나타내는 도면.
도 3은 애플리케이션 관리 장치의 모듈 구성을 나타내는 도면.
도 4는 매니페스트 파일.
도 5는 앱 클래스 로더 테이블과 사용 메모리 테이블.
도 6은 클래스 로드 처리의 흐름도.
도 7은 TASKINFO 클래스 메소드가 추가된 예시적인 코드를 나타내는 도면.
도 8은 제1 실시예에 따른 스레드 구조체의 도면.
도 9는 제1 실시예에 따라 TASKINFO 명령이 삽입된 메소드의 실행시의 흐름도.
도 10은 오브젝트 구조체와 힙 메모리를 나타내는 도면.
도 11은 제1 실시예에 따른 오브젝트 생성 처리를 나타내는 흐름도.
도 12는 GC 처리의 흐름도.
도 13은 복수의 애플리케이션들 간의 예시적인 호출 처리를 나타내는 도면.
도 14는 제2 실시예에 따른 스레드 구조체를 나타내는 도면.
도 15는 제2 실시예에 따라 TASKINFO 명령이 삽입된 메소드의 실행시의 흐름도.
도 16은 제2 실시예에 따른 오브젝트 생성 처리를 나타내는 흐름도.
도 17은 제3 실시예에 따른 애플리케이션 관리 장치의 구성을 나타내는 도면.
도 18은 사용 메모리량 선언 테이블.
도 19는 제3 실시예에 따른 오브젝트 생성 처리를 나타내는 흐름도.
도 20은 제4 실시예에 따른 애플리케이션 관리 장치의 구성을 나타내는 도면.
도 21은 사용 디스크 테이블(2002)과 사용 디스크량 선언 테이블(2003)의 구성을 나타내는 도면.
도 22는 제4 실시예에 따른 매니페스트 파일을 나타내는 도면.
도 23은 제4 실시예에 따른 기동시의 흐름도.
도 24는 FileOutputStream 오브젝트 생성시의 흐름도.
도 25는 FileOutputStream 오브젝트의 write 메소드 실행시의 흐름도.
도 26은 RandomAccessFile 오브젝트의 setLength 메소드 실행시의 흐름도.
도 27은 RandomAccessFile 오브젝트의 write 메소드 실행시의 흐름도.
도 28은 File 오브젝트의 delete 메소드 실행시의 흐름도.
이제는, 도면을 참조하여, 본 발명의 실시예들에 대해 상세하게 설명한다. 이 실시예들에 개시된 구성 요소들의 상대적 배열, 수치적 표현 및 수치값은, 구체적으로 다르게 언급되지 않으면, 본 발명의 범위를 제한하지 않음을 이해하여야 한다.
<제1 실시예>
＜애플리케이션 관리 장치의 구성＞
이하, 도 1 내지 도 12를 참조하여 본 발명의 제1 실시예에 대해 설명한다. 먼저, 도 1을 참조하여, 애플리케이션 관리 장치(100)의 하드웨어 구성에 대해 설명한다. 애플리케이션 관리 장치(100)는 화상 처리 장치의 일례이다. 애플리케이션 관리 장치(100)는 제어부(120), 스캐너(111), 프린터(112) 및 조작 패널(113)을 구비하며, 착탈가능한 IC 카드 리더(116)를 더 구비한다. 제어부(120)는 CPU(101), ROM(102), RAM(103), 외부 저장 장치(104), USBH I/F 제어부(105), 스캐너 I/F 제어부(106), 프린터 I/F 제어부(107), NVRAM(108), 패널 제어부(109) 및 네트워크 I/F 제어부(110)를 구비한다.
CPU(101)는 애플리케이션 관리 장치(100)의 소프트웨어 프로그램을 실행하며, 장치 전체의 제어를 실시한다. ROM(102)은 리드 온리 메모리이며, 장치의 부트 프로그램과 고정 파라미터 등을 저장한다. RAM(103)은 랜덤 액세스 메모리이며, CPU(101)가 장치를 제어할 때, 일시적인 데이터 저장 등을 위해 사용된다. 외부 저장 장치(104)는 설치된 애플리케이션, 애플리케이션 데이터 및 인쇄 데이터의 저장과 같은, 다양한 데이터의 저장을 위해 사용된다.
USBH I/F 제어부(105)는 USB 호스트 인터페이스를 제어하기 위한 것이며, 다양한 USB 장치와의 통신을 제어한다. 스캐너 I/F 제어부(106)는 스캐너(111)를 제어하는 장치이다. 프린터 I/F 제어부(107)는 프린터(112)를 제어하는 장치이다. NVRAM(108)은 비휘발성 메모리이며, 애플리케이션 관리 장치(100)의 각종 설정치가 그 내부에 저장된다.
패널 제어부(109)는 조작 패널(113)을 제어하고, 각종 정보를 표시하며, 사용자의 지시 입력을 수취하기 위한 것이다. 네트워크 I/F 제어부(110)는 네트워크(115)와의 데이터 송수신을 제어한다. 버스(114)에는 CPU(101), ROM(102), RAM(103), 외부 저장 장치(104), USBH I/F 제어부(105), 스캐너 I/F 제어부(106), 프린터 I/F 제어부(107), NVRAM(108), 패널 제어부(109) 및 네트워크 I/F 제어부(110)가 연결된다. 또한, 버스(114)는 CPU(101)로부터의 제어 신호와 여러 장치들 간의 데이터 신호가 송수신되는 시스템 버스이다. IC 카드 리더(116)는 인증을 실시하기 위한 USB 장치이다.
<소프트웨어 구성>
다음에는, 도 2를 참조하여, 애플리케이션 관리 장치(100)의 소프트웨어(200)의 일례에 대해 설명한다. 하드웨어(201)는 애플리케이션 관리 장치의 소프트웨어를 실행한다. OS(202)는 프로세스의 관리, 메모리 관리 및 입출력 관리를 실행한다. Native 애플리케이션(203)은 복사 등과 같은 기기의 기본적인 기능을 실현하는 프로그램이다.
애플리케이션 관리 장치(100)의 소프트웨어(200)는 Java VM(204)과 애플리케이션 플랫폼(205)으로 구성된다. Java VM(204)은 Java 프로그램을 실행하는 가상의 머신이다. 애플리케이션 플랫폼(205)은 단일의 Java VM 상에서 애플리케이션의 라이프사이클, 즉, 적어도 하나 이상의 애플리케이션 프로그램의 기동, 정지, 설치 및 제거를 관리하는 프로그램이다. 앱 A(206)와 앱 B(207)는 애플리케이션 플랫폼(205) 상에서 동작하는 애플리케이션 프로그램이다. Java VM(204)은 애플리케이션 플랫폼(205), 앱 A(206) 및 앱 B(207)를 단일의 Java 애플리케이션(208)으로서 처리한다.
<모듈 구성>
다음에는, 도 3을 참조하여, 본 발명의 애플리케이션 관리 장치(100)의 소프트웨어(200)를 구성하는 모듈의 일례에 대해 설명한다. Java VM(204)은 바이트 코드 실행 유닛(301), 메모리 관리 유닛(302), 힙 메모리(305) 및 시스템 클래스 로더(306)를 구비한다.
바이트 코드 실행 유닛(301)은 Java 프로그램 코드인 바이트 코드를 해석하고 실행한다. 힙 메모리(305)는 Java VM(204)에 의해 관리되는 메모리 영역이며, Java 프로그램의 실행에 의해 생성된 Java 오브젝트를 유지한다. 메모리 관리 유닛(302)은 애플리케이션에 의해 사용되는 메모리를 관리한다. 메모리 관리 유닛(302)은 오브젝트 생성 유닛(303)과 GC 실행 유닛(304)으로 구성된다. 오브젝트 생성 유닛(303)은 바이트 코드 실행 유닛(301)에 의해 실행되는 프로그램 코드의 지시에 따라 Java 오브젝트를 생성한다. GC 실행 유닛(304)은 힙 메모리(305)에 저장되어 있는 Java 오브젝트들 중에서 더 이상 사용되지 않는 Java 오브젝트를 삭제하는 가비지 콜렉션을 실행한다. 시스템 클래스 로더(306)는 Java VM(204)에 의해 관리되는 클래스를 로딩한다. 일반적으로, Java 클래스는, 필요할 때, 즉, 처리를 실행할 때, 클래스 로더에 의해 처음 로딩된다.
애플리케이션 플랫폼(205)은 애플리케이션 관리 유닛(308), 애플리케이션 메모리 관리 유닛(307) 및 앱 클래스 로더 관리 유닛(309)으로 구성된다. 애플리케이션 메모리 관리 유닛(307)은 각 앱에 대해 사용되는 메모리를 관리하는 사용 메모리 테이블(313)을 갖고, 애플리케이션 별로 사용되는 메모리를 관리한다. 애플리케이션 관리 유닛(308)은 애플리케이션의 설치, 기동, 정지 및 제거와 같은 애플리케이션의 라이프사이클을 관리한다. 앱 클래스 로더 관리 유닛(309)은 앱 클래스 로더 테이블(310)을 가지며, 애플리케이션 마다 앱 클래스 로더를 생성하고 관리한다. 앱 클래스 로더는 외부 저장 장치(104)에 저장되어 있는 애플리케이션의 프로그램 파일(312)로부터 클래스를 로딩한다.
<매니페스트 파일>
다음에는, 도 4를 참조하여, 애플리케이션의 매니페스트 파일의 내용에 대해 설명한다. 매니페스트 파일은 애플리케이션의 Jar 파일에 포함된 파일이다. 매니페스트 파일에는 다음과 같은 정보가 기술되어 있다.
Bundle-Name(401)은 애플리케이션의 명칭이다. Application-Id(402)는 애플리케이션 ID이며, 애플리케이션을 식별하기 위한 고유의 식별자이다. MaximumMemoryUsage(403)은 애플리케이션이 사용할 수 있는 최대 메모리 사용량이다. 이러한 설정 항목은 애플리케이션 플랫폼(205)에 의해 규정된다. 상기 설정 항목 및 설정치는 일례이며, 본 발명을 한정하고자 하는 의도가 없으며, 상기 설정 항목 및 설정치 이외에, 다양한 설정 항목과 설정치가 매니페스트 파일에 기술될 수도 있다.
<테이블>
다음에는, 도 5를 참조하여, 애플리케이션 플랫폼(205)에 의해 관리되는 앱 클래스 로더 테이블(310)과 사용 메모리 테이블(313)에 대해 설명한다. 앱 클래스 로더 테이블(310)은 애플리케이션의 식별자인 애플리케이션 ID(501)와 애플리케이션의 앱 클래스 로더(502)를 결부하여 관리하는 테이블이다. 사용 메모리 테이블(313)은 애플리케이션의 식별자인 애플리케이션 ID(503)와 애플리케이션에 의해 현재 사용되고 있는 메모리량(504)을 결부하여 관리하는 테이블이다.
<로드 처리>
다음에는, 도 6을 참조하여, 본 실시예에 따른 애플리케이션 플랫폼(205)이 애플리케이션의 클래스를 로딩할 때의 처리 절차에 대해 설명한다. 이하에서 설명하는 처리는 CPU(101)가 ROM(102)이나 외부 저장 장치(104)에 저장되어 있는 제어 프로그램을 RAM(103)으로 독출하고 제어 프로그램을 실행함으로써 실현된다.
애플리케이션에 대한 기동 요구가 실행되면, CPU(101)는 앱 클래스 로더 관리 유닛(309)에 대하여 앱 클래스 로더의 요구를 실시한다. S602에서, 앱 클래스 로더 관리 유닛(309)은 앱 클래스 로더의 취득을 개시한다. 먼저, S603에서, 앱 클래스 로더 관리 유닛(309)은 클래스 로더의 요구를 실시한 애플리케이션의 애플리케이션 ID에 대응하는 클래스 로더가 앱 클래스 로더 테이블(310)에 존재하는지의 여부를 판정한다. 대응하는 클래스 로더가 존재하면, 처리는 S607로 이행하고, 대응하는 클래스 로더가 존재하지 않으면, 처리는 S604로 이행한다.
S604에서, 앱 클래스 로더 관리 유닛(309)은 앱 클래스 로더를 생성한다. 그리고, S605에서, 앱 클래스 로더 관리 유닛(309)은 S604에서 생성된 앱 클래스 로더에 애플리케이션 ID를 저장한다. 또한, S606에서, 앱 클래스 로더 관리 유닛(309)은 클래스 로더의 요구를 실시한 애플리케이션의 애플리케이션 ID와 S604에서 생성된 앱 클래스 로더를 앱 클래스 로더 테이블(310)에 등록한다. 그 후, 처리는 S607로 이행하여, 애플리케이션으로 반환된다.
S603에서, 대응하는 클래스 로더가 존재하는 것으로 판정되거나, S606의 처리 이후에, S607에서, CPU(101)는 앱 클래스 로더 관리 유닛(309)으로부터 취득한 앱 클래스 로더를 사용하여 애플리케이션(206)의 기동을 개시한다. 그리고, 개시된 애플리케이션(206)은 S608에서 애플리케이션 오브젝트의 생성을 개시한다. 또한, 애플리케이션(206)은, S609에서, 애플리케이션의 클래스를 로딩하기 위해, 앱 클래스 로더 관리 유닛(309)으로부터 취득한 앱 클래스 로더에 대해 애플리케이션 클래스에 대한 클래스 로드의 요구를 실시한다.
S610에서, 애플리케이션 클래스 로더는, 애플리케이션(206)으로부터 앱 클래스에 대한 클래스 로드의 요구를 수취하면, 먼저, Java VM에 포함된 시스템 클래스 로더(306)에 대해 클래스의 로딩을 요구한다. S611에서, 시스템 클래스 로더(306)는, 클래스 로드의 요구를 수취하면, 요구된 클래스의 클래스 파일의 바이트 코드를 판독한다. 그리고, S612에서, 시스템 클래스 로더(306)는 클래스 파일의 판독이 완료되었는지의 여부를 판정하고, 완료되었으면, S613으로 이행한다. 한편, 클래스 파일의 판독이 완료되지 않았으면, 애플리케이션 고유의 클래스가 로딩되고 있는 것이기 때문에, 처리는 앱 클래스 로더로 반환되어 S614로 이행한다. S613에서, 시스템 클래스 로더(306)는 S611에서 판독된 바이트 코드에 기초하여 클래스를 로딩하고, S619로 이행하여, 애플리케이션(206)으로 클래스 오브젝트를 반환한다.
한편, S614에서, 앱 클래스 로더는 앱의 Jar 파일(312)로부터 요구된 클래스의 바이트 코드를 판독한다. 그리고, S615에서, 앱 클래스 로더는 클래스 파일이 존재하고 판독이 성공적이었는지의 여부를 판정하고, 성공적이면 S616로 이행하고, 성공적이지 않으면 S618로 이행한다.
S616에서, 앱 클래스 로더는 판독된 바이트 코드에 TASKINFO 명령을 삽입하고, S617에서, TASKINFO 명령이 삽입된 바이트 코드에 기초하여 클래스를 로딩한다. TASKINFO 명령은 도 7을 이용하여 상세하게 후술한다. 그 후, 처리는 S619로 이행하고, 애플리케이션(206)으로 클래스 오브젝트를 반환한다.
한편, S615에서, 클래스 파일이 존재하지 않는 것으로 판정되면, S618에서, 애플리케이션(206)은 ClassNotFoundException을 생성하고 애플리케이션의 기동을 종료한다. S619에서, 애플리케이션(206)은 S617에서 로딩된 클래스를 사용하여 애플리케이션 오브젝트의 인스턴스를 생성하고, 앱의 기동을 종료한다.
<TASKINFO 명령>
다음에는, 도 7을 참조하여, 본 발명에 따른 S616에서 바이트 코드에 삽입되는 TASKINFO 명령에 대해 설명한다. 참조 번호 "701"은 TASKINFO 명령이 삽입되기 전의 코드를 나타낸다. 참조 번호 "702"는 TASKINFO 명령이 삽입된 후의 코드를 나타낸다.
참조 번호 "703"으로 나타낸 바와 같이, 메소드의 최초에 "TASKINFO.set(애플리케이션 ID);"를 삽입한다. 여기서는, 애플리케이션 ID의 일례로서 "11-1111-1111"이 제시되어 있다. S605에서 클래스 로더에 저장된 값이 문자열로 변환되어 애플리케이션 ID로서 삽입된다. 또한, 참조 번호 "704"로 나타낸 바와 같이, 메소드의 최후에 "TASKINFO.remove();"가 삽입된다. TASKINFO.set() 메소드와 TASKINFO.remove() 메소드에 대해서는 상세하게 후술한다.
<스레드 구조체>
다음에는, 도 8을 참조하여, 본 발명의 제1 실시예에 따른 스레드의 구조체에 대해 설명한다. 스레드의 구조체(801)는 애플리케이션 ID를 저장하는 필드(802)를 갖는다. 필드(802)는 TASKINFO.set() 메소드와 TASKINFO.remove() 메소드에 의해 사용된다. 구체적으로, 애플리케이션 ID는 TASKINFO.set() 메소드에 의해 설정되며, TASKINFO.remove() 메소드에 의해 소거된다.
<메소드의 처리>
다음에는, 도 9를 참조하여, 본 발명에 따른 바이트 코드 실행 유닛(301)에서 애플리케이션의 프로그램에 포함되어 있는 TASKINFO 명령이 삽입된 메소드가 실행될 때의 처리 절차에 대해 설명한다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
애플리케이션의 메소드의 실행이 개시되면, 애플리케이션(206)은 메소드의 선두에 있는 "TASKINFO.set(애플리케이션 ID)"를 호출한다. 이 때, 애플리케이션 ID를 인수로서 추가한다. 그 후, TASKINFO 클래스의 set 메소드로 처리가 이행한다.
S903에서, TASKINFO 클래스의 set 메소드는 먼저 처리를 실행하고 있는 현재의 스레드를 취득한다. 그리고, set 메소드는 S904에서 취득한 스레드 구조체의 애플리케이션 ID 필드(802)에 set 메소드의 인수로서 전달된 애플리케이션 ID의 값을 저장하고, 애플리케이션(206)으로 처리를 반환한다.
S905에서, 애플리케이션(206)은 앱의 메소드 내의 처리를 실행하고, S906에서, 메소드의 최후에 있는 "TASKINFO.remove();"를 호출한다. 그 후, TASKINFO 클래스의 remove 메소드로 처리가 이행한다.
S907에서, TASKINFO 클래스의 remove 메소드는 먼저 처리를 실행하고 있는 현재의 스레드를 취득한다. S908에서, remove 메소드는 S907에서 취득한 스레드의 스레드 구조체의 필드(802)에 설정되어 있는 애플리케이션 ID의 값을 소거하고, 애플리케이션으로 처리를 반환한다. 애플리케이션은 메소드의 처리를 종료한다. 이에 따라, 메소드의 실행 중에 스레드에 대응하는 애플리케이션 정보가 기억된다. 이 정보를 사용하여, 본 실시예에 따른 화상 처리 장치는 실시간으로 메모리 사용량을 파악할 수 있다.
<오브젝트 구조체 및 힙 메모리>
다음에는, 도 10을 참조하여, 본 발명의 오브젝트의 구조체와 힙 메모리에 대해 설명한다. 참조 번호 "1001"은 비교예로서의 역할을 하는 Java VM의 힙 메모리를 나타낸다. 본 실시예에 따른 오브젝트의 구조체(1002)는 힙 메모리(1001)와는 달리, 오브젝트의 고유 정보 이외에, 애플리케이션 ID(애플리케이션 정보)를 저장하는 필드(1003)를 더 구비하고 있다. 따라서, 본 실시예에 따른 Java VM(204)의 힙 메모리(305)는 참조 번호 "1004"로 나타낸 바와 같이 될 것이다. 예컨대, 힙 메모리(305)는 도 10에 나타낸 바와 같이 오브젝트(A 내지 E)의 구조체를 위한 영역을 확보한다. 확보된 공간에는 구조체에 포함된 애플리케이션 ID를 저장하기 위한 영역도 각각 마련된다. 따라서, 임의의 오브젝트가 어떤 애플리케이션에 관련되는지를 용이하게 확인할 수 있다. 도 10에서는, 사용되고 있지 않은 메모리 영역을 빈 메모리로 표시한다.
<오브젝트 생성 처리>
다음에는, 도 11을 참조하여, 제1 실시예에 따른 오브젝트 생성 처리의 처리 절차에 대해 설명한다. 오브젝트 생성 처리는 전술한 도 9의 S905의 처리 중에 실행된다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
오브젝트 생성을 실시하는 애플리케이션의 코드가 바이트 코드 실행 유닛(301)에 의해 실행되면 오브젝트 생성 처리가 개시되고, Java VM(204)의 오브젝트 생성 유닛(303)이 호출된다. S1102에서, 오브젝트 생성 유닛(303)은 먼저 현재의 스레드를 취득한다. 그리고, S1103에서, 오브젝트 생성 유닛(303)은 S1102에서 취득한 스레드의 구조체의 애플리케이션 ID 필드(802)를 판독하고, 애플리케이션 ID를 취득한다.
S1104에서, 오브젝트 생성 유닛(303)은 오브젝트 생성용 메모리를 취득하고, 오브젝트를 생성한다. 또한, S1105에서, 오브젝트 생성 유닛(303)은 오브젝트의 구조체의 애플리케이션 ID 필드(1003)에 S1103에서 취득한 애플리케이션 ID를 기록한다. S1106에서, 오브젝트 생성 유닛(303)은 메모리 증가량을 기록하기 위해, S1105에서 기록된 애플리케이션 ID와 S1104에서 생성된 오브젝트의 크기를 인수로 하여, 애플리케이션 메모리 관리 유닛(307)을 호출한다.
S1107에서, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리 테이블(313)의 애플리케이션 ID 필드(503)를 S1106에서 인수로 지정된 애플리케이션 ID로 검색한다. 여기서, 애플리케이션 ID가 존재하면 S1109로 처리가 이행하고, 애플리케이션 ID가 존재하지 않으면 S1108로 이행한다.
S1108에서, 애플리케이션 관리 유닛(308)은 사용 메모리 크기가 0인 새로운 레코드를 생성하고, 생성된 레코드를 사용 메모리 테이블(313)에 등록하며, S1109로 이행한다. S1109에서, 애플리케이션 관리 유닛(308)은 사용 메모리 테이블(313)의 애플리케이션 ID에 대응하는 사용 메모리의 값(504)을 갱신하고, 오브젝트 생성 유닛(303)으로 처리를 반환한다. S1110에서, 오브젝트 생성 유닛(303)은 생성된 오브젝트를 애플리케이션으로 반환한다. 애플리케이션(206)은 생성된 오브젝트를 수취하고, 오브젝트 생성 처리를 종료한다. 이러한 방식으로, 본 실시예에 따른 애플리케이션 관리 장치는, 오브젝트를 생성할 때, 대응하는 애플리케이션 ID와 확보된 메모리 크기를 애플리케이션 메모리 관리 유닛(307)으로 관리한다.
<GC 처리>
다음에는, 도 12를 참조하여, 본 발명의 제1 실시예에 따른 GC 처리의 처리 절차에 대해 설명한다. Java VM(204)은 오브젝트의 생성을 위해 필요한 빈 메모리가 부족할 때 더 이상 필요하지 않은 오브젝트를 해방하여 빈 메모리를 증대시키는 처리를 실시한다. 이러한 처리를 가비지 콜렉션(GC)이라 한다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
오브젝트 생성 유닛(303)의 오브젝트 생성에 필요한 빈 메모리가 부족하면, GC 실행 유닛(304)에 의해 GC 처리가 개시된다. S1202에서, GC 실행 유닛(304)은 힙 메모리(305)에서 GC 대상이 되는 어느 누구로부터도 참조되지 않는 오브젝트를 검색한다. S1203에서, GC 실행 유닛(304)은 대상 오브젝트가 발견되었는지의 여부를 판정한다. 여기서, 대상 오브젝트가 존재하면 S1204로 처리가 이행되고, 대상 오브젝트가 존재하지 않으면 처리가 S1209로 이행되어 종료된다.
S1204에서, GC 실행 유닛(304)은 힙 메모리(305)로부터 대상 오브젝트의 내용을 취득한다. 그리고, GC 실행 유닛(304)은 S1204에서 취득한 오브젝트의 애플리케이션 ID 필드의 값을 취득한다. 또한, S1206에서, GC 실행 유닛(304)은 메모리 감소량을 기록하기 위해, S1205에서 기록된 애플리케이션 ID와 S1204에서 취득된 오브젝트의 크기를 인수로 하여, 애플리케이션 메모리 관리 유닛(307)을 호출한다.
S1207에서, 애플리케이션 메모리 관리 유닛(307)은 S1206에서 인수로 지정된 애플리케이션 ID에 대응하는 사용 메모리 테이블(313)의 사용 메모리의 값(504)을 갱신하고, GC 실행 유닛(304)으로 처리를 반환한다. 애플리케이션 메모리 관리 유닛(307)으로부터 처리가 반환되면, S1208에서, GC 실행 유닛(304)은 오브젝트를 해방하고, GC 대상이 되는 다음 오브젝트를 찾기 위해 S1202로 이행한다.
이상 설명한 바와 같이, 본 실시예에 따른 화상 처리 장치는, 애플리케이션에 대한 기동 요구에 응답하여, 애플리케이션의 클래스의 클래스 파일을 판독하고, 애플리케이션을 나타내는 애플리케이션 정보를 스레드에 기록하는 코드를 판독된 클래스 파일에 포함된 메소드의 최초에 추가하며, 클래스를 로딩한다. 또한, 본 화상 처리 장치는, 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 메모리를 확보하고, 스레드에 기록된 애플리케이션 정보를 확보된 메모리에 기록하는 동시에, 오브젝트를 생성하고 생성된 오브젝트의 애플리케이션 정보를 메모리 크기와 결부하여 관리한다. 이에 따라, 본 화상 처리 장치에 의하면, 성능을 유지하면서도 개별 애플리케이션에 의한 메모리 사용량 또는 디스크 사용량을 실시간으로 측정할 수 있다.
<제2 실시예>
이하에서는, 도 13 내지 도 16을 참조하여, 본 발명의 제2 실시예에 대해 설명한다. 이하에서는, 제1 실시예와 유사한 구성 및 제어에 대한 설명은 생략한다. 클래스 로드 처리는 제1 실시예와 유사하게 실행한다. 먼저, 도 13을 참조하여, 애플리케이션 플랫폼(205) 상에서 복수의 애플리케이션이 연대하여 동작하는 시퀀스에 대해 설명한다.
브라우저(1301)는 본 발명의 화상 처리 장치로서의 역할을 하는 애플리케이션 관리 장치(100)와 네트워크로 연결된 디바이스에 의해 동작하게 된다. 상기 디바이스는 PC, 스마트 폰 또는 태블릿이다. HTTP 서버 앱(1302)은 애플리케이션 플랫폼(205) 상에서 동작하는 HTTP 서버 프로그램이며, 애플리케이션 ID("44-4444-4444")를 갖고 있다. servlet 앱(1303)은 HTTP 서버 애플리케이션(1302)과 연대하여 동작하는 servlet 타입의 애플리케이션이며, 애플리케이션 ID("11-1111-1111")를 갖고 있다.
S1304에서, 브라우저(1301)는 네트워크를 통해 HTTP 서버 앱(1302)에 대해 HTTP 요구를 송신한다. 그리고, S1305에서, HTTP 서버 앱(1302)은, HTTP 요구를 수신하면, HTTP 요구 응답 처리를 실시하는 스레드를 1개 생성하고, HTTP 요구 분석 처리를 실시한다.
HTTP 요구가 servlet 앱(1303)에 대한 것이라면, S1306에서, HTTP 서버 앱(1302)은 HTTP 요구에 정보를 부착하고 servlet 앱(1303)을 호출한다. S1307에서, servlet 앱(1303)은 servlet으로 구현되는 고유의 처리를 실행하고, S1308에서, HTTP 서버 앱(1302)으로 servlet의 처리 결과를 반환한다.
S1309에서, HTTP 서버 앱(1302)은 수취한 servlet의 처리 결과에 기초하여 HTTP 응답을 생성하고, S1310에서, 네트워크를 통해 브라우저로 HTTP 응답을 반환한다. 이 때, S1305 내지 S1309는 1개의 스레드로 처리된다.
애플리케이션 플랫폼(205) 상에서, 도면에 도시된 바와 같이, 복수의 애플리케이션이 연대하여 동작하는 것이 일반적이다. 오브젝트 생성은 HTTP 요구 처리(S1305), servlet 처리(S1307) 또는 HTTP 응답 처리(S1309)에 의해, 또는 이들 모두에 의해 실시된다. 따라서, HTTP 서버 앱(1302) 또는 servlet 앱(1303)에 의해 오브젝트가 생성되었는지의 여부를 판별할 필요가 있다.
<스레드 구조체>
다음에는, 도 14를 참조하여, 본 발명의 제2 실시예에 따른 스레드의 구조체를 설명한다. 스레드 구조체(1401)는 필드로서 애플리케이션 ID 스택(1402)을 갖는다. 도 13의 처리에서 servlet 고유의 처리인 S1307이 실행되고 있으면, 실행되고 있는 애플리케이션 ID들이 적층된다. 이 경우, 애플리케이션 ID 스택(1402)에는 위에서부터 순서대로 servlet 앱(1303)의 애플리케이션 ID(1403)와 HTTP 서버 앱(1302)의 애플리케이션 ID(1404)가 적층되어 있다.
<메소드의 처리>
다음에는, 도 15를 참조하여, 본 발명의 제2 실시예에 따른 바이트 코드 실행 유닛(301)에서 애플리케이션의 프로그램에 포함되어 있는 TASKINFO 명령이 삽입된 메소드가 실행될 때의 처리에 대해 설명한다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
애플리케이션의 메소드의 실행이 개시되면, 애플리케이션(206)은 메소드의 선두에 있는 "TASKINFO.set(애플리케이션 ID)"(703)를 호출하고, TASKINFO 클래스의 set 메소드로 처리가 이행한다. S903에서, TASKINFO 클래스의 set 메소드는 먼저 처리를 실행하고 있는 현재의 스레드를 취득한다. 그리고, S1501에서, set 메소드는 취득한 스레드 구조체의 애플리케이션 ID 스택(1402)의 선두에 set 메소드의 인수로서 전달된 애플리케이션 ID의 값을 추가하고, 애플리케이션으로 처리를 반환한다.
S905에서, 애플리케이션(206)은 애플리케이션의 메소드 내의 처리를 실행하고, 메소드의 최후에 있는 "TASKINFO.remove();"(704)를 호출하며, TASKINFO 클래스의 remove 메소드로 처리가 이행한다. S907에서, TASKINFO 클래스의 remove 메소드는 먼저 처리를 실행하고 있는 현재의 스레드를 취득한다. 그리고, S1502에서, remove 메소드는 S907에서 취득한 스레드의 스레드 구조체의 애플리케이션 ID의 스택의 선두에 있는 애플리케이션 ID를 삭제하고, 애플리케이션으로 처리를 반환한다. 그 후, 애플리케이션(206)은 메소드의 처리를 종료한다.
<오브젝트 생성 처리>
다음에는, 도 16을 참조하여, 본 발명의 제2 실시예에 따른 오브젝트 생성 처리에 대해 설명한다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다. 오브젝트 생성을 실시하는 애플리케이션의 코드가 바이트 코드 실행 유닛(301)에 의해 실행되면 오브젝트 생성 처리가 개시되고, Java VM(204)의 오브젝트 생성 유닛(303)이 호출된다.
S1102에서, 오브젝트 생성 유닛(303)은 현재의 스레드를 취득한다. 그리고, S1601에서, 오브젝트 생성 유닛(303)은 S1102에서 취득한 스레드의 구조체의 애플리케이션 ID의 스택의 선두에 있는 애플리케이션 ID를 취득한다.
S1104에서, 오브젝트 생성 유닛(303)은 오브젝트 생성용 메모리를 취득하고, 오브젝트를 생성한다. 그리고, S1105에서, 오브젝트 생성 유닛(303)은 오브젝트의 구조체의 애플리케이션 ID 필드(1003)에 S1601에서 취득한 애플리케이션 ID를 기록한다. 또한, S1106에서, 오브젝트 생성 유닛(303)은 메모리 증가량을 기록하기 위해, S1105에서 기록된 애플리케이션 ID와 S1104에서 생성된 오브젝트의 크기를 인수로 하여, 애플리케이션 메모리 관리 유닛(307)을 호출한다.
S1107에서, 애플리케이션 관리 유닛(308)은 사용 메모리 테이블(313)의 애플리케이션 ID 필드(503)를 애플리케이션 ID로 검색하고, 애플리케이션 ID가 존재하는지의 여부를 판정한다. 애플리케이션 ID가 존재하면 S1109로 처리가 이행하고, 애플리케이션 ID가 존재하지 않으면 S1108로 이행한다. S1108에서, 애플리케이션 관리 유닛(308)은 사용 메모리 크기가 0인 새로운 레코드를 생성하고, 생성된 레코드를 사용 메모리 테이블(313)에 등록하며, S1109로 처리를 이행한다. S1109에서, 애플리케이션 관리 유닛(308)은 사용 메모리 테이블(313)의 애플리케이션 ID에 대응하는 사용 메모리의 값(504)을 갱신하고, 오브젝트 생성 유닛(303)으로 처리를 반환한다.
S1110에서, 오브젝트 생성 유닛(303)은 생성된 오브젝트를 애플리케이션으로 반환한다. 애플리케이션(206)은 생성된 오브젝트를 수취하고, 오브젝트 생성 처리를 종료한다. GC 처리는 제1 실시예와 유사하므로, 이에 대한 설명은 생략한다.
이상 설명한 바와 같이, 본 실시예에 따르면, 복수의 애플리케이션이 연대하여 동작하는 경우에는, 스레드에 기록되는 애플리케이션 정보가 스택 구조를 갖게 된다. 이에 따라, 도 13에 도시된 바와 같은 경우에도, 제1 실시예와 마찬가지로, 성능을 유지하면서도 개별 애플리케이션에 의한 메모리 사용량 또는 디스크 사용량을 실시간으로 측정할 수 있다.
<제3 실시예>
다음에는, 도 17 내지 도 19를 참조하여, 본 발명의 제3 실시예에 대해 설명한다. 이하에서는, 제1 및 제2 실시예와 유사한 구성 및 제어에 대한 설명은 생략한다. 먼저, 도 17을 참조하여, 본 실시예의 애플리케이션 관리 장치의 소프트웨어(200) 내의 모듈의 예시적인 구성에 대해 설명한다.
도 17에 도시된 바와 같이, 도 3에 도시된 구성 이외에, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리량 선언 테이블(1701)을 구비하고 있다. 클래스 로드 처리는 제1 실시예와 유사하게 실행된다. TASKINFO 명령이 삽입된 메소드의 실행시의 처리는 제1 실시예와 유사하게 실행된다.
<사용 메모리량 선언 테이블>
다음에는, 도 18을 참조하여, 사용 메모리량 선언 테이블(1701)에 대해 설명한다. 사용 메모리량 선언 테이블(1701)은 애플리케이션 ID(1801)와 애플리케이션 ID로 식별되는 애플리케이션이 사용하는 최대 메모리량을 나타내는 최대 사용 메모리(1802)를 결부하여 관리하는 테이블이다.
애플리케이션의 최대 메모리 사용량은 도 4에 나타낸 애플리케이션의 매니페스트 파일의 MaximumMemoryUsage 설정(403)에 기술되어 있다. 애플리케이션 관리 유닛(308)은, 애플리케이션이 설치되면, 애플리케이션의 Jar 파일로부터 Application-Id 설정(402)과 MaximumMemoryUsage 설정(403)을 판독한다. 또한, 애플리케이션 관리 유닛(308)은 판독된 값을 사용 메모리량 선언 테이블(1701)에 추가한다.
<오브젝트 생성 처리>
다음에는, 도 19를 참조하여, 본 실시예에 따른 오브젝트 생성 처리의 처리 절차에 대해 설명한다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
오브젝트 생성을 실시하는 애플리케이션의 코드가 바이트 코드 실행 유닛(301)에 의해 실행되면 오브젝트 생성 처리가 개시되고, Java VM(204)의 오브젝트 생성 유닛(303)이 호출된다. S1102에서, 오브젝트 생성 유닛(303)은 먼저 현재의 스레드를 취득한다. 그리고, S1601에서, 오브젝트 생성 유닛(303)은 S1102에서 취득한 스레드의 구조체의 애플리케이션 ID 필드(802)를 판독하고, 애플리케이션 ID를 취득한다.
S1104에서, 오브젝트 생성 유닛(303)은 오브젝트 생성용 메모리를 취득하고, 오브젝트를 생성한다. 그리고, S1105에서, 오브젝트 생성 유닛(303)은 오브젝트 구조체의 애플리케이션 ID 필드(1003)에 S1103에서 취득한 애플리케이션 ID를 기록한다. S1106에서, 오브젝트 생성 유닛(303)은 메모리 증가량을 기록하기 위해, S1105에서 기록된 애플리케이션 ID와 S1104에서 생성된 오브젝트의 크기를 인수로 하여, 애플리케이션 메모리 관리 유닛(307)을 호출한다.
S1107에서, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리 테이블(313)의 애플리케이션 ID 필드(503)를 애플리케이션 ID로 검색하고, 애플리케이션 ID가 존재하는지의 여부를 판정한다. 애플리케이션 ID가 존재하면 S1901로 처리가 이행하고, 애플리케이션 ID가 존재하지 않으면 S1108로 이행한다. S1108에서, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리 크기가 0인 새로운 레코드를 생성하고, 생성된 레코드를 사용 메모리 테이블(313)에 등록하며, S1901로 처리를 이행한다.
S1901에서, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리 테이블(313)의 애플리케이션 ID 필드(503)를 애플리케이션 ID로 검색하고, 현재의 사용 메모리 크기를 취득한다.
그 다음, S1902에서, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리량 선언 테이블(1701)을 애플리케이션 ID로 검색하고, 애플리케이션 ID에 대응하는 애플리케이션의 사용 메모리 선언량을 취득한다. S1903에서, 애플리케이션 메모리 관리 유닛(307)은 S1106에서 오브젝트 생성 유닛(303)으로부터 전달된 오브젝트 크기와 S1901에서 취득한 현재 사용 메모리 크기의 합계가 S1902에서 취득한 최대 메모리 사용량 이하인지의 여부를 판정한다. 합계가 최대 메모리 사용량 이하이면 S1109으로 처리가 이행하고, 합계가 최대 메모리 사용량을 초과하면 S1904로 이행한다.
S1109에서, 애플리케이션 메모리 관리 유닛(307)은 사용 메모리 테이블(313)의 애플리케이션 ID에 대응하는 사용 메모리의 값(504)을 갱신하고, 오브젝트 생성 유닛(303)으로 처리를 반환한다. S1110에서, 오브젝트 생성 유닛(303)은 생성된 오브젝트를 애플리케이션으로 반환한다. 애플리케이션은 생성된 오브젝트를 수취하고, 오브젝트 생성 처리를 종료한다.
한편, S1903에서 합계가 최대 메모리 사용량을 초과하는 것으로 판정되면, S1904에서, 애플리케이션 메모리 관리 유닛(307)은 메모리 오류를 생성한다. 그리고, S1905에서, 애플리케이션 메모리 관리 유닛(307)은 애플리케이션 관리 유닛(308)에 대해 애플리케이션 ID에 대응하는 애플리케이션의 정지 처리 실시를 요구하고, 처리를 애플리케이션으로 반환한다. 애플리케이션은 오브젝트 생성 처리를 종료한다.
이상 설명한 바와 같이, 본 실시예에 따르면, 제1 실시예와 제2 실시예의 적어도 하나의 구성 이외에, 각 애플리케이션의 최대 메모리 사용량을 정의한 테이블을 더 구비하고 있다. 또한, 본 화상 처리 장치는, 오브젝트 생성시 확보한 메모리 크기에 따라, 현재 이미 사용되고 있는 메모리 사용량과 확보한 메모리 크기의 합계가 최대 메모리 사용량을 초과할 경우, 오브젝트의 생성을 정지하도록 제어를 실시할 수 있다.
<제4 실시예>
다음에는, 도 20 내지 도 28을 참조하여, 본 발명의 제4 실시예에 대해 설명한다. 본 실시예에서는, 제1 내지 제3 실시예의 메커니즘을 사용하여, 메모리와 유사하게 외부 저장 장치(104)의 디스크 사용량을 제한하는 실시예에 대해 설명한다. 따라서, 본 실시예는 제1 내지 제3 실시예와 각각 조합될 수 있다. 이하에서는, 제1 내지 제3 실시예와 유사한 구성 및 제어에 대한 설명은 생략한다. 클래스 로드 처리는 제1 실시예와 유사하게 실행된다. TASKINFO 명령이 삽입된 메소드의 실행시의 처리는 제1 실시예와 유사하게 실행된다.
본 실시예에서는, 애플리케이션 관리 유닛(308)에 의해 설치된 애플리케이션이 외부 저장 장치(104)의 소정의 디렉토리에 저장된다. 또한, 애플리케이션은 애플리케이션 자체가 설치된 디렉토리 아래의 용량만을 사용할 수 있도록 제한되는 것으로 가정한다.
<모듈 구성>
먼저, 도 20을 참조하여, 본 실시예에 따른 애플리케이션 관리 장치(100)의 소프트웨어(200) 내의 모듈의 예시적인 구성에 대해 설명한다. 도 17에 도시된 구성 이외에, 애플리케이션 플랫폼(205)은 애플리케이션 디스크 관리 유닛(2001)을 구비하고, Java VM(204)은 파일 액세스 관리 유닛(2004)을 구비한다.
애플리케이션 디스크 관리 유닛(2001)은 후술하는 사용 디스크 테이블(2002)과 사용 디스크량 선언 테이블(2003)로 구성된다. 파일 액세스 관리 유닛(2004)은 액세스 제어부(2005)로 구성되며, 애플리케이션(206)에 의한 외부 저장 장치(104)로의 파일 액세스를 제어한다.
<사용 디스크 테이블 및 사용 디스크량 선언 테이블>
도 21은 사용 디스크 테이블(2002)과 사용 디스크량 선언 테이블(2003)의 구성을 나타낸다. 사용 디스크 테이블(2002)에서는, 애플리케이션 ID(2101)와 해당 애플리케이션의 현재 디스크 사용량(2102)이 결부하여 관리된다. 사용 디스크량 선언 테이블(2003)에서는, 애플리케이션 ID(2201)와 해당 애플리케이션의 최대 사용량(2202)이 결부하여 관리된다. 사용 디스크 테이블(2002)과 사용 디스크량 선언 테이블(2003)은 단일의 테이블로 관리될 수도 있고, 동등한 정보가 관리되는 한, 본 실시예의 구성에 한정되지 않는다.
도 22는 본 실시예의 애플리케이션의 매니페스트 파일의 내용을 나타낸다. 도 4에 나타낸 내용 이외에, 애플리케이션의 최대 디스크 사용량을 나타내는 MaximumFilespaceUsage(2301)가 추가되었다. 여기서는, MaximumMemoryUsage 설정(403)도 포함되었지만, 본 발명은 이에 한정되지 않으며, 예컨대, MaximumFilespaceUsage(2301)만 포함된 구성을 채용할 수도 있다.
<초기화 처리>
다음에는, 도 23을 참조하여, 본 실시예의 애플리케이션 플랫폼(205)이 기동될 때 애플리케이션 관리 유닛(308)의 초기화 처리에 대해 설명한다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
애플리케이션 플랫폼(205)이 기동되면, S2401에서, 애플리케이션 관리 유닛(308)은 설치된 애플리케이션의 개수를 취득한다. S2402에서, 애플리케이션 관리 유닛(308)은 변수(i)를 0으로 초기화하고, S2403에서, 변수(i)를 애플리케이션의 개수(j)와 비교하여, i < j 이면 S2404로 이행하고, 그렇지 않으면 모든 애플리케이션에 대해 후술하는 처리를 실시하였다고 판단하고 처리를 종료한다. S2404에서, 애플리케이션 관리 유닛(308)은 애플리케이션 ID를 취득하고, S2405에서, 애플리케이션에 의해 선언된 디스크 사용량을 취득한다. 그리고, 애플리케이션 디스크 관리 유닛(2001)을 호출한다.
S2406에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크량 선언 테이블에 해당하는 애플리케이션 ID가 등록되어 있는지의 여부를 판정하고, 등록되지 않았다면, S2407에서 레코드를 추가하고 S2408로 이행한다. 한편, 등록되어 있다면, 처리는 S2408로 직접 진행한다. S2408에서, 애플리케이션 디스크 관리 유닛(2001)은, 처리를 애플리케이션 관리 유닛(308)으로 반환하기 전에, 애플리케이션 ID(2201)와 최대 사용량(2202)의 데이터를 결부하여 이 데이터를 사용 디스크량 선언 테이블(2003)에 추가한다.
그 다음, S2409에서, 애플리케이션 관리 유닛(308)은 애플리케이션이 설치된 폴더 이하의 용량을 취득하며, 애플리케이션 디스크 관리 유닛(2001)을 다시 호출한다. S2410에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블에 해당하는 애플리케이션 ID가 등록되어 있는지의 여부를 판정하고, 등록되지 않았다면, S2411에서 레코드를 추가하고 S2412로 이행한다. 한편, 등록되어 있다면, 처리는 S2412로 직접 진행한다. S2412에서, 애플리케이션 디스크 관리 유닛(2001)은, 처리를 애플리케이션 관리 유닛(308)으로 반환하기 전에, 애플리케이션 ID(2101)와 사용량(2102)의 데이터를 결부하여 이 데이터를 사용 디스크 테이블(2002)에 추가한다. S2413에서, 애플리케이션 관리 유닛(308)은 변수(i)를 증분하고 S2403의 판정으로 반환한다.
애플리케이션 관리 유닛(308)은, 애플리케이션을 새로 설치할 때, 외부 저장 장치(104)의 소정의 폴더에 애플리케이션을 설치한다. 그 후, 이 흐름도와 유사한 처리를 실시하고, 사용 디스크량 선언 테이블(2003)과 사용 디스크 테이블(2002)에 정보를 추가하는 것은 당연한다. 또한, 애플리케이션 관리 유닛(308)은, 애플리케이션을 제거할 때, 애플리케이션이 설치된 폴더를 삭제한다. 이 때, 사용 디스크량 선언 테이블(2003)과 사용 디스크 테이블(2002)로부터 해당 애플리케이션의 관련 정보를 삭제하는 것은 당연한다.
본 흐름도의 처리에 의하면, 화상 처리 장치로서의 역할을 하는 애플리케이션 관리 장치(100)를 기동할 때, 애플리케이션 관리 유닛(308)에 의해 관리되는 애플리케이션의 기동 초기 상태의 디스크 사용량을 관리할 수 있다.
<오브젝트 생성 처리>
도 24는 파일의 생성 및 기입을 실시하기 위한 FileOutputStream 오브젝트가 생성될 때의 흐름도이다. 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다. 여기서는, 제1 실시예에서 설명한 도 11의 제어와 다른 부분에 대해 설명한다.
S1103에서 애플리케이션 ID를 취득하면, S2501에서, 오브젝트 생성 유닛(303)은 생성될 오브젝트가 FileOutputStream인지의 여부를 판정한다. FileOutputStream이면 처리가 S2502로 진행하고, 다른 오브젝트의 생성인 경우에는 S1104로 진행한다.
S2502에서, 오브젝트 생성 유닛(303)은 FileOutputStream 오브젝트를 생성하기 위한 인수를 취득하고, S2503에서, 취득한 인수로부터 조작 대상의 파일 크기를 취득한다. 그리고, S2504에서, 오브젝트 생성 유닛(303)은 본래의 FileOutputStream 오브젝트의 생성 처리를 호출한다. 그리고, S2505에서, 오브젝트 생성 유닛(303)은, S2502에서 취득한 인수 또는 오브젝트의 생성 방법에 기초하여, FileOutputStream 오브젝트가 Append Mode에서 생성되고 있는지의 여부를 판정한다. Java에서 FileOutputStream 오브젝트의 사양은 Append Mode인 경우 기존 파일의 최종단에 데이터를 추가하도록 동작하고, 그렇지 않으면 파일 크기를 0으로 되돌려 재기입을 실시하도록 동작한다. 판정 결과가 Append Mode인 경우, S1110으로 처리가 진행한다.
한편, Append Mode가 아니면, 조작 대상의 파일 크기가 0인 것으로 판단하고 S2506으로 처리가 이행한다. S2506에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블(2002)의 현재 애플리케이션의 사용량(2102)으로부터 S2503에서 취득한 크기를 감산하고, 처리를 오브젝트 생성 유닛(303)으로 반환하며, S1110으로 이행한다.
S1110에서, 오브젝트 생성 유닛(303)은 애플리케이션으로 처리를 반환하고, 애플리케이션은 오브젝트 생성 처리를 종료한다.
<FileOutputStream 오브젝트의 write 메소드>
다음에는, 도 25를 참조하여, 애플리케이션(206)이 FileOutputStream 오브젝트의 write 메소드를 호출할 때의 처리 절차에 대해 설명한다. 후술하는 처리는 도 9 및 도 15의 S905의 처리 중에 실행된다. 또한, 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다. 실행시에, 바이트 코드 실행 유닛(301)에 의해 파일 액세스 관리 유닛(2004)의 액세스 제어부(2005)의 처리가 호출된다.
S2601에서, 바이트 코드 실행 유닛(301)은 메소드가 FileOutputStream 오브젝트의 write 메소드인지의 여부를 판정한다. 메소드가 FileOutputStream 오브젝트의 write 메소드이면, S2602로 처리가 진행하고, 그렇지 않으면 S2611에서 다른 메소드의 처리를 호출하고, 현재의 처리를 종료한다.
write 메소드의 실행에 있어서, S2602에서, 파일 액세스 관리 유닛(2004)은 현재 스레드의 스레드 구조체의 애플리케이션 ID 필드(802)를 판독한다. 그리고, S2603에서, 파일 액세스 관리 유닛(2004)은 write 메소드에 전달된 기입 데이터의 크기(=a)를 취득하고, 처리를 애플리케이션 디스크 관리 유닛(2001)으로 전달한다.
그 다음, S2604에서, 애플리케이션 디스크 관리 유닛(2001)은 S2602에서 취득한 애플리케이션 ID를 사용하여, 사용 디스크 테이블(2002)로부터 해당 애플리케이션의 사용량(2102)(=X)을 취득한다. 또한, S2605에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크량 선언 테이블(2003)로부터 최대 사용량(2202)(=Y)을 취득하고, 처리를 파일 액세스 관리 유닛(2004)으로 반환한다.
S2606에서, 파일 액세스 관리 유닛(2004)은 해당 애플리케이션의 사용량(X)을 기입 데이터 크기(a)에 추가하여 얻은 크기가 최대 사용량(Y)을 초과하는지의 여부를 판정한다. 최대 사용량(Y)을 초과하는 경우, S2608로 처리가 이행하고, 파일 액세스 관리 유닛(2004)은 애플리케이션(206)에 의해 선언된 최대 사용량(2202)을 초과하는 기입이 실시될 것으로 판단하여, 소정의 오류(디스크 오류)를 통지하고, 현재의 처리를 종료한다.
최대 사용량(Y)을 초과하지 않는 경우, S2607로 처리가 진행하고, 파일 액세스 관리 유닛(2004)은 본래의 write 메소드를 호출하여 파일의 기입을 실행한다. 그 후, S2609에서, 파일 액세스 관리 유닛(2004)은 파일 기입에 실패하였는지의 여부를 판정한다. 파일 기입에 실패한 경우 처리를 종료하고, 파일 기입에 성공하면, 처리를 애플리케이션 디스크 관리 유닛(2001)으로 전달하고 S2610으로 이행한다. S2610에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블(2002)의 해당 애플리케이션의 사용량(2102)에 기입 데이터 크기(=a)를 추가하고 처리를 종료한다.
Java는 FileOutputStream과 유사한 FileWriter 클래스를 갖고 있다. FileWrite 클래스가 사용되면 FileOutputStream과 동일한 구성을 채용하여 지원될 수 있기 때문에, 본 실시예에서 이에 대한 설명은 생략한다.
<RandomAccessFile 오브젝트의 setLength 메소드>
다음에는, 도 26을 참조하여, 애플리케이션(206)이 RandomAccessFile 오브젝트의 setLength 메소드를 호출할 때의 처리 절차에 대해 설명한다. 후술하는 처리는 도 9 및 도 15의 S905의 처리 중에 실행된다. 또한, 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다. 실행시에, 바이트 코드 실행 유닛(301)에 의해 파일 액세스 관리 유닛(2004)의 액세스 제어부(2005)의 처리가 호출된다. Java에서 RandomAccessFile 오브젝트의 setLength 사양은 조작 대상의 파일 크기를 setLength에 의해 지정된 크기로 변경하도록 동작한다.
S2701에서, 바이트 코드 실행 유닛(301)은 메소드가 RandomAccessFile 오브젝트의 setLength 메소드인지의 여부를 판정한다. 메소드가 RandomAccessFile 오브젝트의 setLength 메소드이면, S2702로 처리가 이행하고, 그렇지 않으면 S2716으로 처리가 이행하여 다른 메소드의 처리를 호출한 후 현재의 처리를 종료한다.
setLength 메소드의 실행에 있어서, S2702에서, 파일 액세스 관리 유닛(2004)은 현재 스레드의 스레드 구조체의 애플리케이션 ID 필드(802)를 판독한다. 그리고, S2703에서, 파일 액세스 관리 유닛(2004)은 setLength 메소드의 대상 파일의 크기(=a)를 취득하고, S2704에서 setLength 메소드에 지정된 크기(=b)를 취득한다. 그 후, S2705에서, 파일 액세스 관리 유닛(2004)은 a와 b를 비교하고, b가 더 크면, 즉, 파일 크기가 더 크면, S2709로 이행한다. 그렇지 않으면, 파일 액세스 관리 유닛(2004)은 S2706으로 이행하고, 본래의 setLentgh 메소드를 호출하며, S2707에서 setLength 메소드의 실행 결과를 판정한다. 성공적이면 S2708로 처리가 이행하고, 성공적이지 않으면 처리를 종료한다. S2708에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블(2002)의 해당 애플리케이션의 사용량(2102)으로부터 a-b로 구한 값을 감산하고, 처리를 종료한다.
한편, S2705에서 파일 크기가 더 큰 것으로 판정되면, S2709에서, 애플리케이션 디스크 관리 유닛(2001)은 S2701에서 취득한 해당 애플리케이션 ID의 디스크 사용량(2102)(=X)을 취득한다. 그리고, S2710에서, 애플리케이션 디스크 관리 유닛(2001)은 최대 사용량(2202)(=Y)을 취득한다. 그리고, S2711에서, 파일 액세스 관리 유닛(2004)은 현재 사용량(X)에서 setLength 메소드로 인한 증가분이 최대 사용량(Y)을 초과하는지의 여부를 판정한다(X+(b-a) > Y).
최대 사용량(Y)을 초과하는 경우, S2715로 처리가 이행하고, 파일 액세스 관리 유닛(2004)은 애플리케이션(206)에 의해 선언된 최대 사용량(2202)을 초과하는 기입이 실시될 것으로 판단하여, 소정의 오류를 통지하고, 현재의 처리를 종료한다. 한편, 최대 사용량(Y)을 초과하지 않는 것으로 판단되는 경우, S2712로 처리가 이행하고, 파일 액세스 관리 유닛(2004)은 본래의 setLentgh 메소드를 호출한다. 그리고, S2713에서, 파일 액세스 관리 유닛(2004)은 setLength 메소드의 실행 결과를 판정하고, 성공적이면 S2714로 이행한다. S2714에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블(2002)의 해당 애플리케이션의 사용량(2102)에 b-a로 구한 값을 추가하고, 처리를 종료한다. 한편, S2713에서 실행 결과가 오류인 것으로 판정되면, 처리를 종료한다.
<RandomAccessFile 오브젝트의 write 메소드>
다음에는, 도 27을 참조하여, 애플리케이션(206)이 RandomAccessFile 오브젝트의 write 메소드를 호출할 때의 처리 절차에 대해 설명한다. 후술하는 처리는 도 9 및 도 15의 S905의 처리 중에 실행된다. 또한, 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다. 실행시에, 바이트 코드 실행 유닛(301)에 의해 파일 액세스 관리 유닛(2004)의 액세스 제어부(2005)의 처리가 호출된다. Java에서 RandomAccessFile 오브젝트의 write 사양은 조작 대상인 파일의 파일 포인터의 위치로부터 데이터를 기입하도록 동작한다. 이 때, write 사양은, 기입 크기가 파일 크기를 초과하면, 파일 크기가 증가하도록 동작한다.
S2801에서, 바이트 코드 실행 유닛(301)은 메소드가 RandomAccessFile 오브젝트의 write 메소드인지의 여부를 판정한다. 메소드가 RandomAccessFile 오브젝트의 write 메소드이면, S2802로 처리가 진행하고, 그렇지 않으면 S2815에서 다른 메소드의 처리를 호출하고, 현재의 처리를 종료한다.
write 메소드의 실행에 있어서, S2802에서, 파일 액세스 관리 유닛(2004)은 현재 스레드의 스레드 구조체의 애플리케이션 ID 필드(802)를 판독한다. 그리고, S2803에서, 파일 액세스 관리 유닛(2004)은 write 메소드에 전달된 기입 데이터의 크기(=a)를 취득하고, S2804에서 파일 포인터의 현재 위치(=b)를 취득한다. 또한, S2805에서, 파일 액세스 관리 유닛(2004)은 조작 대상 파일의 크기(=c)를 취득한다. 그 후, S2806에서, 파일 액세스 관리 유닛(2004)은 기입 크기(a)에 파일 포인터(b)의 위치를 추가하고, 파일 크기가 증가할 것인지의 여부를 판정한다(a+b>c). 파일 크기가 증가할 경우에는, S2808로 처리가 이행하고, 그렇지 않으면, S2807에서 본래의 write 메소드를 호출하고, 파일 크기가 변경되지 않기 때문에, 처리를 종료한다.
S2808에서, 애플리케이션 디스크 관리 유닛(2001)은 S2801에서 취득한 해당 애플리케이션 ID의 디스크 사용량(2102)(=X)을 취득하고, S2809에서, 최대 사용량(2202)(=Y)을 취득하며, S2810로 이행한다. S2810에서, 파일 액세스 관리 유닛(2004)은 현재 사용량(X)에서 write 메소드로 인한 증가분이 최대 사용량(Y)을 초과하는지의 여부를 판정한다((a+b)-c+X>Y). 최대 사용량(Y)을 초과하는 경우, S2814로 처리가 이행하고, 파일 액세스 관리 유닛(2004)은 애플리케이션(206)에 의해 선언된 최대 사용량(2202)을 초과하는 기입이 실시될 것으로 판단하여, 소정의 오류를 통지하고, 현재의 처리를 종료한다.
한편, 최대 사용량(Y)을 초과하지 않는 것으로 판단되는 경우, S2811로 처리가 이행하고, 파일 액세스 관리 유닛(2004)은 본래의 write 메소드를 호출한다. 그 후, S2812에서, 파일 액세스 관리 유닛(2004)은 write 메소드의 실행 결과를 판정한다. 성공적이면, S2813으로 처리가 이행하고, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블(2002)의 해당 애플리케이션의 사용량(2102)에 a+b-c로 구한 값을 추가하고, 처리를 종료한다. 한편, S2811에서 write 메소드가 성공적으로 실행되지 않은 것으로 판정되면, 본 처리를 종료한다.
<File 오브젝트의 delete 메소드>
다음에는, 도 28을 참조하여, 애플리케이션(206)이 File 오브젝트의 delete 메소드를 호출할 때의 처리 절차에 대해 설명한다. 후술하는 처리는 도 9 및 도 15의 S905의 처리 중에 실행된다. 또한, 후술하는 처리는 CPU(101)가 ROM(102) 또는 외부 저장 장치(104)에 저장된 제어 프로그램을 RAM(103)으로 독출하여 제어 프로그램을 실행함으로써 실현된다.
S2901에서, 바이트 코드 실행 유닛(301)은 메소드가 File 오브젝트의 delete 메소드인지의 여부를 판정한다. 메소드가 File 오브젝트의 delete 메소드이면, S2902로 처리가 진행하고, 그렇지 않으면 S2907로 처리가 이행하여 다른 메소드의 처리를 호출한 후, 현재의 처리를 종료한다.
delete 메소드의 실행에 있어서, S2902에서, 파일 액세스 관리 유닛(2004)은 현재 스레드의 스레드 구조체의 애플리케이션 ID 필드(802)를 판독한다. 그리고, S2903에서, 파일 액세스 관리 유닛(2004)은 delete 메소드의 대상 파일의 크기(=a)를 취득하고, S2904에서 본래의 delete 메소드를 호출한다.
S2905에서, 파일 액세스 관리 유닛(2004)은 delete 메소드의 실행 결과를 판정하고, delete 메소드가 성공적으로 실행되지 않은 것으로 판정되면, 현재의 처리를 종료한다. 한편, delete 메소드가 성공적으로 실행된 것으로 판정되면, S2906으로 처리가 이행한다. S2906에서, 애플리케이션 디스크 관리 유닛(2001)은 사용 디스크 테이블(2002)의 해당 애플리케이션의 사용량(2102)으로부터 조작 대상의 파일 크기(a)를 감산하고, 처리를 종료한다.
본 실시예에서는, 애플리케이션(206)이 선언한 최대 사용량을 초과하는 경우, 소정의 오류를 통지한다(S2608, S2715, S2814). 애플리케이션 관리 유닛(308)은, 이 통지가 검출된 경우, 대응하는 애플리케이션을 정지하도록 구성될 수도 있다.
이상 설명한 바와 같이, 본 실시예에 따른 화상 처리 장치는, 애플리케이션 기동 요구에 응답하여, 애플리케이션의 클래스의 클래스 파일을 판독하고, 애플리케이션을 나타내는 애플리케이션 정보를 기록하는 코드를 판독된 클래스 파일에 포함된 메소드의 최초에 추가하며, 클래스를 로딩한다. 또한, 본 화상 처리 장치는, 메소드를 실행하는 동안, 생성될 오브젝트에 사용될 파일 크기를 확보하고, 스레드에 기록된 애플리케이션 정보를 확보된 파일 크기와 함께 디스크 사용량으로서 기록하는 동시에, 오브젝트를 생성하고 생성된 오브젝트의 애플리케이션 정보를 디스크 사용량과 결부하여 관리한다. 이에 따라, 본 실시예에서는, 디스크 사용량과 관련하여, 제1 내지 제3 실시예와 유사한 효과를 얻을 수 있다.
<다른 실시예>
본 발명의 실시예들은, 본 발명의 전술한 실시예(들) 중 하나 이상의 기능을 실시하기 위해 저장 매체(예컨대, 비일시적 컴퓨터-판독가능한 저장 매체) 상에 기록된 컴퓨터 실행가능한 지시를 독출하여 실행하는 시스템 또는 장치의 컴퓨터에 의해, 또는, 예컨대, 본 발명의 전술한 실시예(들) 중 하나 이상의 기능을 실시하기 위해 저장 매체로부터 컴퓨터 실행가능한 지시를 독출하여 실행함으로써, 시스템 또는 장치의 컴퓨터에 의해 실시되는 방법에 의해, 실현될 수도 있다. 컴퓨터는 중앙 처리 유닛(CPU), 마이크로 프로세싱 유닛(MPU) 또는 다른 회로 중 하나 이상을 포함할 수 있으며, 별도의 컴퓨터들 또는 별도의 컴퓨터 프로세서들의 네트워크를 포함할 수 있다. 컴퓨터 실행가능한 지시들은, 예컨대, 네트워크 또는 저장 매체로부터 컴퓨터에 제공될 수 있다. 저장 매체는, 예컨대, 하디 디스크, 랜덤 액세스 메모리(RAM), 리드 온리 메모리(ROM), 분산형 연산 시스템들의 스토리지, (콤팩트 디스크(CD), 디지털 다용도 디스크(DVD) 또는 블루-레이 디스크(BD)TM와 같은) 광학 디스크, 플래시 메모리 디바이스, 메모리 카드 등 중 하나 이상을 포함할 수 있다.
예시적 실시예들을 참조하여 본 발명을 설명하였으나, 본 발명은 개시된 예시적 실시예들로 한정되지 않음을 이해하여야 한다. 다음의 특허청구범위는 그러한 변형들과 등가의 구조들 및 기능들을 모두 포함하도록 최광의로 해석되어야 한다.

Claims (14)

  1. 적어도 애플리케이션 제어 유닛과 시스템 제어 유닛을 포함하는 화상 처리 장치이며,
    상기 애플리케이션 제어 유닛은,
    애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고 상기 클래스를 로딩하도록 구성된 제어 유닛을 포함하고,
    상기 시스템 제어 유닛은,
    상기 클래스를 로딩하고, 생성될 오브젝트에 사용될 메모리를 확보하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 확보된 상기 메모리에 기록함과 함께 상기 오브젝트를 생성하도록 구성된 오브젝트 생성 유닛을 포함하고,
    상기 애플리케이션 제어 유닛은,
    상기 기동 요구가 수락된 애플리케이션을 상기 애플리케이션을 기동하는 데 사용된 메모리와 연관짓고, 연관된 애플리케이션과 메모리를 관리하도록 구성된 메모리 관리 유닛을 더 포함하고,
    상기 시스템 제어 유닛은 복수의 애플리케이션을 하나의 애플리케이션으로서 처리하고, 상기 오브젝트 생성 유닛에 의해 복수의 오브젝트가 생성되는 경우에, 각 오브젝트는 사용된 대응하는 애플리케이션과 연관되는, 화상 처리 장치.
  2. 제1항에 있어서,
    상기 제어 유닛은 상기 애플리케이션 정보를 삭제하는 코드를 판독된 상기 클래스 파일에 더 추가하도록 구성된, 화상 처리 장치.
  3. 삭제
  4. 제1항에 있어서,
    복수의 애플리케이션이 연대하여 동작하는 경우, 상기 애플리케이션 정보는 스택 구조를 갖는, 화상 처리 장치.
  5. 제1항에 있어서,
    상기 애플리케이션 정보와 해당 애플리케이션이 사용가능한 메모리 크기를 결부하여 정의한 테이블과;
    오브젝트를 생성하기 위한 메모리가 상기 오브젝트 생성 유닛에 의해 확보되었을 때, 상기 메모리 관리 유닛에 의해 관리되는 상기 애플리케이션 정보에 대응하는 애플리케이션이 사용하고 있는 메모리 크기와 상기 확보된 메모리의 크기의 합계가 대응하는 상기 사용가능한 메모리 크기를 초과하는지의 여부를 판정하도록 구성된 판정 유닛과;
    상기 판정 유닛에 의해 상기 합계가 상기 사용가능한 메모리 크기를 초과했다고 판정되면, 메모리 오류를 생성하도록 구성된 제한 유닛을 더 포함하는, 화상 처리 장치.
  6. 적어도 애플리케이션 제어 유닛과 시스템 제어 유닛을 포함하는 화상 처리 장치이며,
    상기 애플리케이션 제어 유닛은,
    애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 클래스를 로딩하도록 구성된 제어 유닛을 포함하고,
    상기 시스템 제어 유닛은,
    상기 클래스를 로딩하고, 생성될 오브젝트에 사용될 파일 크기를 확보하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 확보된 상기 파일 크기와 함께 디스크 사용량으로서 기록함과 함께 상기 오브젝트를 생성하도록 구성된 오브젝트 생성 유닛을 포함하고,
    상기 애플리케이션 제어 유닛은,
    상기 기동 요구가 수락된 애플리케이션을 상기 애플리케이션을 기동하기 위해 사용된 디스크와 연관짓고, 연관된 애플리케이션과 디스크를 관리하도록 구성된 디스크 관리 유닛을 더 포함하고,
    상기 시스템 제어 유닛은 복수의 애플리케이션을 하나의 애플리케이션으로서 처리하고, 상기 오브젝트 생성 유닛에 의해 복수의 오브젝트가 생성되는 경우에, 각 오브젝트는 사용된 대응하는 애플리케이션과 연관되는, 화상 처리 장치.
  7. 제6항에 있어서,
    상기 제어 유닛은 상기 애플리케이션 정보를 삭제하는 코드를 판독된 상기 클래스 파일에 더 추가하도록 구성된, 화상 처리 장치.
  8. 삭제
  9. 제6항에 있어서,
    복수의 애플리케이션이 연대하여 동작하는 경우, 상기 애플리케이션 정보는 스택 구조를 갖는, 화상 처리 장치.
  10. 제6항에 있어서,
    상기 애플리케이션 정보와 해당 애플리케이션이 사용가능한 디스크 사용량을 결부하여 정의한 테이블과;
    오브젝트를 생성하기 위한 파일 크기가 상기 오브젝트 생성 유닛에 의해 확보되었을 때, 상기 디스크 관리 유닛에 의해 관리되는 상기 애플리케이션 정보에 대응하는 애플리케이션이 사용하고 있는 디스크 사용량과 확보된 상기 파일 크기의 합계가 대응하는 상기 사용가능한 디스크 사용량을 초과하는지의 여부를 판정하도록 구성된 판정 유닛과;
    상기 판정 유닛에 의해 상기 합계가 상기 사용가능한 디스크 사용량을 초과했다고 판정되면, 디스크 오류를 생성하도록 구성된 제한 유닛을 더 포함하는, 화상 처리 장치.
  11. 적어도 애플리케이션 제어 유닛과 시스템 제어 유닛을 포함하는 화상 처리 장치를 제어하는 방법이며,
    상기 애플리케이션 제어 유닛에서, 애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 클래스를 로딩하는 단계,
    상기 시스템 제어 유닛에서, 상기 클래스를 로딩하고, 생성될 오브젝트에 사용될 메모리를 확보하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 확보된 상기 메모리에 기록함과 함께 상기 오브젝트를 생성하는 단계, 및
    상기 애플리케이션 제어 유닛에서, 상기 기동 요구가 수락된 애플리케이션을 상기 애플리케이션을 기동하는 데 사용된 메모리와 연관짓고, 연관된 애플리케이션과 메모리를 관리하는 단계를 포함하고,
    상기 시스템 제어 유닛은 복수의 애플리케이션을 하나의 애플리케이션으로서 처리하고, 상기 시스템 제어 유닛에 의해 복수의 오브젝트가 생성되는 경우에, 각 오브젝트는 사용된 대응하는 애플리케이션과 연관되는, 화상 처리 장치의 제어 방법.
  12. 적어도 애플리케이션 제어 유닛과 시스템 제어 유닛을 포함하는 화상 처리 장치를 제어하는 방법이며,
    상기 애플리케이션 제어 유닛에서, 애플리케이션에 대한 기동 요구에 응답하여, 상기 애플리케이션의 클래스의 클래스 파일을 판독하고, 상기 클래스를 로딩하는 단계,
    상기 시스템 제어 유닛에서, 상기 클래스를 로딩하고, 생성될 오브젝트에 사용될 파일 크기를 확보하고, 상기 애플리케이션을 나타내는 애플리케이션 정보를 확보된 상기 파일 크기와 함께 디스크 사용량으로서 기록함과 함께 상기 오브젝트를 생성하는 단계, 및
    상기 애플리케이션 제어 유닛에서, 상기 기동 요구가 수락된 애플리케이션을 상기 애플리케이션을 기동하기 위해 사용된 디스크와 연관짓고, 연관된 애플리케이션과 디스크를 관리하는 단계를 포함하고,
    상기 시스템 제어 유닛은 복수의 애플리케이션을 하나의 애플리케이션으로서 처리하고, 상기 시스템 제어 유닛에 의해 복수의 오브젝트가 생성되는 경우에, 각 오브젝트는 사용된 대응하는 애플리케이션과 연관되는, 화상 처리 장치의 제어 방법.
  13. 제11항에 따른 화상 처리 장치의 제어 방법의 단계를 컴퓨터가 실행하도록 하는 컴퓨터 프로그램을 저장한 컴퓨터-판독가능한 저장 매체.
  14. 제12항에 따른 화상 처리 장치의 제어 방법의 단계를 컴퓨터가 실행하도록 하는 컴퓨터 프로그램을 저장한 컴퓨터-판독가능한 저장 매체.
KR1020140068234A 2013-06-06 2014-06-05 화상 처리 장치, 그 제어 방법 및 저장 매체 KR101702708B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPJP-P-2013-120103 2013-06-06
JP2013120103A JP6223001B2 (ja) 2013-06-06 2013-06-06 画像処理装置、その制御方法、及びプログラム

Publications (2)

Publication Number Publication Date
KR20140143336A KR20140143336A (ko) 2014-12-16
KR101702708B1 true KR101702708B1 (ko) 2017-02-06

Family

ID=52006648

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020140068234A KR101702708B1 (ko) 2013-06-06 2014-06-05 화상 처리 장치, 그 제어 방법 및 저장 매체

Country Status (4)

Country Link
US (1) US9542228B2 (ko)
JP (1) JP6223001B2 (ko)
KR (1) KR101702708B1 (ko)
CN (1) CN104243743B (ko)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9286085B2 (en) * 2014-06-27 2016-03-15 International Business Machines Corporation Correlating class loader objects across execution environments
US9720810B2 (en) * 2014-12-09 2017-08-01 Google Inc. Device cloud monitoring and stability
US9361140B1 (en) * 2014-12-11 2016-06-07 International Business Machines Corporation Isolating applications in server environment
JP5867633B1 (ja) * 2015-01-21 2016-02-24 日本電気株式会社 情報処理装置、制御方法及びプログラム
JP2017004114A (ja) * 2015-06-05 2017-01-05 キヤノン株式会社 画像形成装置及びアプリケーションの削除方法
JP6597000B2 (ja) 2015-07-10 2019-10-30 ブラザー工業株式会社 画像処理装置
JP6570364B2 (ja) * 2015-08-05 2019-09-04 キヤノン株式会社 画像形成装置及びその制御方法
CN106598679B (zh) * 2016-12-21 2020-07-31 北京奇虎科技有限公司 一种加载图片资源的方法及装置
CN106598614B (zh) * 2016-12-21 2020-12-25 北京奇虎科技有限公司 一种回收图片资源的方法及装置
US10992834B2 (en) 2018-05-17 2021-04-27 Canon Kabushiki Kaisha Image processing apparatus, method for controlling the same, and computer-readable storage medium
CN111400035A (zh) * 2020-03-04 2020-07-10 杭州海康威视***技术有限公司 一种显存分配方法、装置、电子设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784553A (en) 1996-01-16 1998-07-21 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs
US20010001328A1 (en) 1998-10-16 2001-05-17 Chikara Yoshida Link apparatus and virtual machine
US20040199908A1 (en) 2003-04-01 2004-10-07 Takehiro Yoshida Program linking program, program product, program linking device, terminal device, and program linking method
JP2005269439A (ja) 2004-03-19 2005-09-29 Ricoh Co Ltd 画像形成装置、情報処理方法、情報処理プログラム、及び記録媒体

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000163176A (ja) 1998-11-25 2000-06-16 Canon Inc 周辺機器及び周辺機器制御方法及び周辺機器制御システム及び周辺機器制御プログラムを記憶した記憶媒体
JP2001166969A (ja) * 1999-12-10 2001-06-22 Toshiba Corp プログラム動作情報表示システム及びプログラムを記録したコンピュータ読み取り可能な記録媒体
US20070162475A1 (en) * 2005-12-30 2007-07-12 Intel Corporation Method and apparatus for hardware-based dynamic escape detection in managed run-time environments
JP2008123211A (ja) * 2006-11-10 2008-05-29 Canon Inc リソース監視装置及びリソース監視方法
JP5157537B2 (ja) * 2008-03-06 2013-03-06 日本電気株式会社 メモリ管理装置、システム、方法、及び、プログラム
CN101354660B (zh) 2008-09-12 2013-07-24 北京中星微电子有限公司 嵌入式软件程序的运行方法、装置及其***
JP2011242890A (ja) * 2010-05-14 2011-12-01 Hitachi Ltd リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置
JP2012221147A (ja) * 2011-04-07 2012-11-12 Hitachi Ltd 計算機及びリソース管理方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784553A (en) 1996-01-16 1998-07-21 Parasoft Corporation Method and system for generating a computer program test suite using dynamic symbolic execution of JAVA programs
US20010001328A1 (en) 1998-10-16 2001-05-17 Chikara Yoshida Link apparatus and virtual machine
US20040199908A1 (en) 2003-04-01 2004-10-07 Takehiro Yoshida Program linking program, program product, program linking device, terminal device, and program linking method
JP2005269439A (ja) 2004-03-19 2005-09-29 Ricoh Co Ltd 画像形成装置、情報処理方法、情報処理プログラム、及び記録媒体

Also Published As

Publication number Publication date
KR20140143336A (ko) 2014-12-16
US20140366034A1 (en) 2014-12-11
JP2014239302A (ja) 2014-12-18
JP6223001B2 (ja) 2017-11-01
CN104243743B (zh) 2017-12-05
US9542228B2 (en) 2017-01-10
CN104243743A (zh) 2014-12-24

Similar Documents

Publication Publication Date Title
KR101702708B1 (ko) 화상 처리 장치, 그 제어 방법 및 저장 매체
EP2765525B1 (en) Apparatus, non-transitory computer readable information recording medium and information recording method
US20130169987A1 (en) Information processing apparatus, information processing method, and computer-readable storage medium
US9007641B2 (en) Information processing apparatus, control method, and storage medium
JP2005505034A (ja) アプリケーション展開のためのスマートディレクトリに関する方法及び装置
CN107783766B (zh) 对应用程序的文件进行清理的方法和装置
US10459775B2 (en) Information processing apparatus, method, and medium
KR20060100915A (ko) 소프트웨어 인증 시스템, 소프트웨어 인증 방법 및소프트웨어 인증 프로그램을 기록한 컴퓨터 판독 가능한기록 매체
US11140291B2 (en) Information processing apparatus, control method thereof, and storage medium
US8250103B2 (en) Image log management device, image log management method, image log management program
CN103581481A (zh) 作业历史管理***、图像形成装置及其控制方法
JP5398270B2 (ja) 管理装置、ログ処理方法及びプログラム
US8860982B2 (en) Image forming apparatus, installation method and uninstallation method
JP5381059B2 (ja) 機器、ログ記録制御方法、及びプログラム
JP4636029B2 (ja) 画像形成装置及びプログラム
CN114398102A (zh) 一种应用程序包生成方法、装置、编译服务器及计算机可读存储介质
CN109325347B (zh) 一种跳跃性病毒的查杀方法、***、装置及可读存储介质
Woods et al. Functional Access to Forensic Disk Images in a Web Service.
US20230036834A1 (en) Information processing system, apparatus, and storage medium having combinational and non-combinational applications
US20230074397A1 (en) Information processing system, information processing apparatus, and storage medium
JP2006285961A (ja) 情報処理装置及び情報処理方法
US10528335B2 (en) Image forming apparatus capable of executing extension application, method of controlling same, and storage medium
JP2017103521A (ja) 情報処理装置及びその制御方法、プログラム
JP3022837B2 (ja) サービス機能提供装置および提供方法
JP5577915B2 (ja) プログラム取得制御システム、プログラム取得制御方法、及びプログラム取得制御用プログラム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
FPAY Annual fee payment

Payment date: 20200114

Year of fee payment: 4