JP2005301403A

JP2005301403A - プログラム実行装置およびプログラム実行方法

Info

Publication number: JP2005301403A
Application number: JP2004112959A
Authority: JP
Inventors: Tomokazu Kanamaru; 智一金丸; Tetsuro Aoki; 哲朗青木
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2004-04-07
Filing date: 2004-04-07
Publication date: 2005-10-27

Abstract

【課題】同プログラムのバージョンアップなどによって発生する、クラス名の変更を伴わないプログラムの変更には対応できなかった。
【解決手段】バイナリ比較と定数参照の検索を用いることによって、クラスオブジェクトの同一性判定の精度を高め、より効果的にクラスオブジェクトの共有化を達成する。またクラスオブジェクトの記録部の中に排他制御のためのデータ構造を持たせることで、排他ロックのかかるクラスオブジェクト部品群を容易に特定し、簡単な排他制御の実現方法を提供することができる。
【選択図】図１

Description

本発明は、オブジェクト指向プログラムを実行するプログラム実行装置およびプログラム実行方法に関するものであり、特に組み込み向け適用を意図した、省資源化を達成するための実装技術に関するものである。

オブジェクト指向プログラム実行システムの従来の実装技術としては、クラスの識別子が同じクラスオブジェクトを共有化するものとして、特許文献１に示すものが存在していた。

また、排他ロックを掛けているオブジェクトの情報を各プログラムが保持し、プログラム終了時に保持している情報をもとに排他ロックを解除する方式として、特許文献２および特許文献３に示すものが存在していた。

本発明は一部で、オブジェクト指向プログラムの高速化手法に関しても言及する。その代表的な手法として、特許文献４に示すものが存在している。

オブジェクト指向プログラムを実行する代表的なシステムとしては、Ｊａｖａ（Ｒ）が存在する。Ｊａｖａ（Ｒ）は仮想マシンを用いて、クラスファイルと呼ばれる形式のプログラムを実行する。Ｊａｖａ（Ｒ）の実行系の仕様は、その適用先の製品カテゴリに合わせて、家電向けを意図したＪ２ＭＥ、標準的なクライアントＰＣ環境を意図したＪ２ＳＥ、サーバ向け環境を意図したＪ２ＥＥのカテゴリが存在する。

Ｊａｖａ（Ｒ）実行系の仕様が記された代表的な文献として、参照文献１に示すものが存在している。
特開平１１−２３２１０９号公報特開平５−２８９８９２号公報特開平１１−２４９４７号公報米国特許第５３６７６８５号明細書ＴｉｍＬｉｎｄｈｏｌｍａｎｄＦｒａｎｋＹｅｌｌｉｎ："ＴｈｅＪａｖａ（Ｒ）ＶｉｒｔｕａｌＭａｃｈｉｎｅＳｐｅｃｉｆｉｃａｔｉｏｎ"，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ，１９９７，ＩＳＢＮ０−２−１−６３４５２−Ｘ

従来、オブジェクト指向プログラム実行システムでは、省資源性を保持したまま、複数のプログラムを同時に並行実行するプログラム実行系を実現するのは非常に困難であった。

プログラム実行系が使用する資源量は、プログラムを一つだけ実行させる場合と、複数のプログラムを並行に実行させる場合とでは、後者のほうが並行動作させるプログラムと同数倍に近いだけの資源量を備えることが必要になる。また、複数のプログラムを動作させる場合には、一つだけのみ動作させる場合では考えなくても良い、プログラム間の排他制御など、正当な動作を保証するための仕組みを備えることも必要になってくる。

例えば、オブジェクト指向プログラム実行システムの代表的なものとしてＪａｖａ（Ｒ）実行系がある。Ｊａｖａ（Ｒ）実行系の仕様の中でも、家電向けを意図した仮想マシン仕様であるＫＶＭは、省資源性をキープするためにプログラムを同時に一つしか動作させることのできない仕様になっている。

一方で、ＰＣ環境を意図したＪ２ＳＥ、サーバ向け環境を意図したＪ２ＥＥなどのＪａｖａ（Ｒ）実行系の仕様では、複数のプログラムを同時に並行実行できるＪＶＭという仮想マシン仕様が採用されている。しかしこれらの環境ではメモリ資源を潤沢に使用できることが前提となっているため、仮想マシンの仕様は省資源性を重視した仕様にはなっていない。

家電機器上で、ＰＣ環境やサーバ向け環境などと同様に、２つ以上のオブジェクト指向プログラムを動作させる環境を実現しようとすると、可能な限り使用資源を抑える実装技術が重要になる。

本発明では、以下の２つの課題に着目している。

課題１．複数のプログラム間でクラスオブジェクトを共有化することで、効率的に省資源性を保持する。

課題２．複数のプログラム間で必要となる、共有データの排他制御を出来る限り簡単に行う仕組みを提供する。

以下、それぞれの課題に関して説明する。

課題１であるが、同様の発想に基づいた従来技術の代表例として、特許文献１に示すものがあった。

これはＪａｖａ（Ｒ）などオブジェクト指向プログラムの実行系で、２つ以上のプログラムで同一のクラスが用いられていて、これらを同時に実行する場合、ロード後のクラスのデータ（クラスオブジェクト）を共有化し、クラスオブジェクトを記録するための使用メモリ量を削減する、というものである。

しかしながら特許文献１の従来技術においては、複数のプログラムでクラスオブジェクトを共有化させる場合に、クラスの同一性の検証を、パッケージ名やファイル名、クラス名等の文字列識別子のみで行っている。

これにより、クラスのバージョンの違いや、実装の違いに対応できない、という欠点が生じてしまう。Ｊａｖａ（Ｒ）のプログラムはバージョンや実装が異なっていても、パッケージ名やクラス名を同一のものとして扱うことができるため、従来の方法では、異なる動作をするクラスを、誤って同一のものとしてしまう可能性がある。複数のプログラムが同時に実行され、その各プログラムが異なるバージョンのクラスやライブラリを利用するような環境では、クラスの識別子だけに頼らない、より厳密なクラスの同一性検証を行う必要がある。

また従来の方法は、プログラムの最適化については何ら言及を行っていない。プログラムの実行をできるだけ高速に行うために、最適化、すなわちクラスオブジェクトのデータを変換する処理を行うのは一般的な技術である。

例えば特許文献４に示した実装では、実行時に動的なアドレス解決処理を必要とするコードを、参照解決を行った後のコードに変換することによって、実行を高速化する手法が開示されている。また、仮想マシン環境の機種非依存の実行コードを、機種依存のネイティブコードに変換して、コードの実行を高速化するジャストインタイムコンパイラ（ＪＩＴコンパイラ）などの最適化技術は、サーバマシンやＰＣ環境のＪａｖａ（Ｒ）プログラム実行環境では頻繁に使用されている。

しかし複数のプログラムによって共有化されたクラスオブジェクトに対して最適化変換を行う場合の処理に関しては、これまでに特に言及されてこなかった。特にＪＩＴコンパイラなどを用いた場合の最適化変換後のコードは、変換前のデータに比較してサイズが大きくなることが多いため、省資源化技術は重要である。

次に課題２の点についてであるが、まず排他制御に関して簡単に説明する。

動的リンクを行うオブジェクト指向プログラムの実行システム上で複数のプログラムを実行しているとき、２つ以上のプログラムの実行によって、同一のオブジェクトにアクセスが発生する場合がある。

同一オブジェクトに対して、２つ以上の異なる処理が重なって行われた場合、オブジェクトのデータの一貫性に問題が生じ、それぞれのプログラムの実行が正常に行われない危険性がある。このときに必要になるのが排他制御である。あるプログラムが一つのオブジェクトに対してアクセスを行っている最中は、他のプログラムが同一オブジェクトへのアクセスすることを許さない仕組み（排他ロック）を設けることによって、上記の危険を回避することができる。排他制御を実現する一般的な仕組みとしてはセマフォ等が挙げられる。

例えば、Ｊａｖａ（Ｒ）実行系の仕様は、同一プログラムの実行において、スレッド間で発生する排他制御は保証しているものの、異なるプログラムの間での排他制御はサポートされていない。課題１で述べた、複数のプログラムでクラスオブジェクトなどのデータを共有化させようとした場合は、この共有したデータに対しての排他制御が必要になる。

あるプログラムがオブジェクトに対し排他ロックを行っている最中に、何らかの理由でそのプログラムが終了した場合、オブジェクトは排他ロックがされたままの状態が続いてしまい、他のプログラムはそのオブジェクトにアクセス出来なくなってしまうという問題がある。

従来この問題を解決する技術としては大きく２種類のものがあった。一つには、特許文献２に代表されるように、オブジェクトに対して排他ロックが掛けられている時間を計測し、所定時間以上ロックが掛けられているオブジェクトに対しては排他ロックを解除する、というものである。

またもう一つは、特許文献３に代表されるように、確保されている排他ロックの情報をプログラム毎に管理し、プログラム終了時に確保している排他ロックを解除する、というものである。

しかし、特許文献２の技術では、排他ロックの対象となるオブジェクトの監視を行う処理を常時あるいは、一定間隔ごとに実行する必要があるので、本来実行したい計算処理以外の処理が多くなるという課題を有している。

特許文献３の技術では、プログラムが確保している排他ロックを管理するための情報を記憶するための領域を別途、実行しているプログラムごとに用意する必要があるため、本来のプログラムの実行のために必要なデータ以外の記憶量が増大してしまう、という課題を有している。

本発明のプログラム実行装置は、オブジェクト指向プログラムを実行するプログラム実行装置であって、プログラム実行装置は、プログラムをロードし、ロードされたデータであるクラスオブジェクトを生成する、プログラムロード部と、クラスオブジェクトが複数のプログラムから共有される場合に、共有対象となるクラスオブジェクトを記録するクラスオブジェクト管理部と、クラスオブジェクト管理部に記録されたクラスオブジェクトを用いてプログラムを実行する、プログラム実行部と、プログラムロード部がクラスをロードする場合に、クラス管理部に同一の名前をもつ別のクラスが既にロード済であるかどうかを問い合わせるロード済クラス名判定部と、ロード済クラス名判定部が、同一の名前をもつクラスが既にロード済であると判定した場合に、ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとをバイナリ比較し、同一であるクラスオブジェクト部品と、同一でないクラスオブジェクト部品を分ける、クラスオブジェクト同一性比較部と、ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとの間で、クラスオブジェクト同一性比較部が同一であると判定したクラスオブジェクト部品を共有化し、共有クラスオブジェクト管理部に記録する、クラスオブジェクト共有化部とを備えることを特徴とする。

また前記クラスオブジェクト同一性比較部は、前記ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとを比較する際、それぞれのクラスオブジェクトが保持する定数に対する参照を検出し、前記参照が示す定数のデータ内容を比較し、データ内容が同じである場合には、両者は同一のクラスオブジェクト部品であると判定することを特徴とする。

また、クラスオブジェクトの部品を最適化変換する、クラスオブジェクト最適化部と、前記クラスオブジェクト管理部によって共有対象とされた前記クラスオブジェクト部品が、前記クラスオブジェクト最適化部によって最適化変換された場合、最適化変換された後のクラスオブジェクト部品もまた共有対象として、前記クラスオブジェクト管理部に記録する前記最適化コード共有化部を備えることを特徴とする。

本発明のプログラム実行方法は、オブジェクト指向プログラム間での通信において、排他ロックの対象となるインスタンスが渡されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行方法において、前記オブジェクト指向プログラムをロードして生成されるクラスオブジェクト部品は、複数の前記オブジェクト指向プログラムから共有されているかいないか判断可能となる共有フラグを持ち、実行されている前記オブジェクト指向プログラムが、クラスオブジェクト部品に対する排他ロックをかけた状態でプログラムの実行を終了させた場合に、排他ロックの解除を行うクラスオブジェクト部品として、共有フラグが複数の前記オブジェクト指向プログラムから共有されている状態となっているクラスオブジェクト部品を抽出するステップと、前記共有されている状態となっているクラスオブジェクト部品全てに対して、終了させるプログラムの排他ロックを解除するステップとを持つことを特徴とする。

本発明のプログラム実行方法は、オブジェクト指向プログラム間での通信において、排他ロックの対象となるインスタンスが渡されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行方法において、オブジェクト指向プログラムをロードして生成されるクラスオブジェクト部品は、複数の前記オブジェクト指向プログラムから共有されている部品と、複数プログラムから共有されていない部品を、それぞれ管理するクラスオブジェクト部品管理テーブルを持ち、実行されている前記オブジェクト指向プログラムが、前記クラスオブジェクト部品に対する排他ロックをかけた状態で前記オブジェクト指向プログラムの実行を終了させた場合に、前記排他ロックの解除を行うクラスオブジェクト部品として、前記クラスオブジェクト部品管理テーブルから、複数の前記オブジェクト指向プログラムから共有されているクラスオブジェクト部品を抽出するステップと、前記共有されているクラスオブジェクト部品全てに対して、終了させるプログラムの排他ロックを解除するステップとを持つことを特徴とする。

これにより、プログラムのバージョン違いなどパッケージ名やクラス名等が同一であっても実装が異なっている場合、これらのクラスオブジェクトが共有化されないよう、クラスオブジェクトの同一性判定を、バイナリレベルでのデータ比較を行うことによって実現する。これによって、クラスオブジェクト部品の中でも共有化可能な部分と、共有化してはならない部分とを正確に検出することができるようになり、クラスオブジェクトを記録するための使用メモリ量を削減することが可能となる。

また前記クラスオブジェクト同一性比較部は、前記ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとを比較する際、それぞれのクラスオブジェクトが保持する定数に対する参照を検出し、前記参照が示す定数のデータ内容を比較し、データ内容が同じである場合には、両者は同一のクラスオブジェクト部品であると判定することを特徴とするので、クラスオブジェクトの中に含まれる参照値が示す参照先の内容の比較を行うことで、高い精度でのクラスオブジェクトの共有を実現する。

また、クラスオブジェクトの部品を最適化変換する、クラスオブジェクト最適化部と、前記クラスオブジェクト管理部によって共有対象とされた前記クラスオブジェクト部品が、前記クラスオブジェクト最適化部によって最適化変換された場合、最適化変換された後のクラスオブジェクト部品もまた共有対象として、前記クラスオブジェクト管理部に記録する前記最適化コード共有化部を備えるので、クラスオブジェクトの最適化機構と共有化機構を並存させた、より実応用性のプログラム実行装置を得ることができる。

本発明のプログラム実行方法は、オブジェクト指向プログラム間での通信において、排他ロックの対象となるインスタンスが渡されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行方法において、前記オブジェクト指向プログラムをロードして生成されるクラスオブジェクト部品は、複数の前記オブジェクト指向プログラムから共有されているかいないか判断可能となる共有フラグを持ち、実行されている前記オブジェクト指向プログラムが、クラスオブジェクト部品に対する排他ロックをかけた状態でプログラムの実行を終了させた場合に、排他ロックの解除を行うクラスオブジェクト部品として、共有フラグが複数の前記オブジェクト指向プログラムから共有されている状態となっているクラスオブジェクト部品を抽出するステップと、前記共有されている状態となっているクラスオブジェクト部品全てに対して、終了させるプログラムの排他ロックを解除するステップとを持つので、複数プログラムによるクラスオブジェクトの共有時に必要となる、排他制御に要する記憶領域と計算量の負荷を軽減させることができる。

本発明のプログラム実行方法は、オブジェクト指向プログラム間での通信において、排他ロックの対象となるインスタンスが渡されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行方法において、オブジェクト指向プログラムをロードして生成されるクラスオブジェクト部品は、複数の前記オブジェクト指向プログラムから共有されている部品と、複数プログラムから共有されていない部品を、それぞれ管理するクラスオブジェクト部品管理テーブルを持ち、実行されている前記オブジェクト指向プログラムが、前記クラスオブジェクト部品に対する排他ロックをかけた状態で前記オブジェクト指向プログラムの実行を終了させた場合に、前記排他ロックの解除を行うクラスオブジェクト部品として、前記クラスオブジェクト部品管理テーブルから、複数の前記オブジェクト指向プログラムから共有されているクラスオブジェクト部品を抽出するステップと、前記共有されているクラスオブジェクト部品全てに対して、終了させるプログラムの排他ロックを解除するステップとを持つので、複数プログラムによるクラスオブジェクトの共有時に必要となる、排他制御に要する記憶領域と計算量の負荷を軽減させることができる。

（実施の形態１）
図１は、本発明で示す装置の構成の概要を示すものである。本図面を用いて、本発明を実施するための形態を説明する。

本発明の装置は、一つ以上のクラスの集合から構成されるオブジェクト指向プログラム１０を解釈実行するものであり、同時に２つのプログラムを並行実行することが可能なものであるとする。この条件を満たす従来のプログラム実行系としては、Ｊａｖａ（Ｒ）仮想マシンを用いたものがある。以下では適宜、Ｊａｖａ（Ｒ）仮想マシン実行系を例に挙げながら説明を行う。

プログラム１０は、一つ以上のクラスから構成される。Ｊａｖａ（Ｒ）の場合プログラムはクラス単位で、クラスファイルというファイルモジュールに記録され、複数のクラスファイルによってプログラムが構成される。

図２にＪａｖａ（Ｒ）プログラムのクラスファイルのフォーマットを示す。クラスファイルはクラス本体のデータ以外に、そのクラスに含まれるインタフェースやフィールドやメソッドなどさまざまな情報を保持している。フォーマットの詳細は参考文献１に詳述されているためここでは解説を省く。

次に、クラスオブジェクトについて説明する。プログラムロード部２０は、プログラム１０に対して、クラス単位（クラスファイルモジュール毎）にロード処理を行い、クラスオブジェクトを生成する。

Ｊａｖａ（Ｒ）仮想マシンの実行系の場合、このプログラムロード部２０は、従来のＪａｖａ（Ｒ）仮想マシンが備えるクラスローダと同じ構成で実現できる。

クラスオブジェクトは、いくつかの部品（クラスオブジェクト部品）に分けて記録される。それぞれのクラスオブジェクト部品のデータ構造の詳細は特に仕様として規定されてはいないが、ここではＪａｖａ（Ｒ）実行系を元にした実施例として、その相互関係を示したものを図３に示す。

クラス部品１１は、クラス本体の情報を記録する。

インタフェース部品１２は、クラスが保持するインタフェースの情報を記録する。

フィールド部品１３は、クラスが保持するフィールドの情報を記録する。

メソッド部品１４は、クラスが保持するメソッドの情報を記録する。

アトリビュート部品１５は、クラスやインタフェースやフィールドやメソッドが保持する属性のデータを記録する。

定数プール部品１６は、上に挙げた部品が使う定数データを含む。定数データにはプログラム中で用いる数値定数や文字列定数、さらには他の部品の記録アドレスなども含まれる。

これらの部品を、本書類ではまとめてクラスオブジェクト部品と呼ぶことにする。クラスオブジェクト部品は相互に、直接的あるいは、定数プール部品を通じて間接的に、他の部品を参照するための参照値を保持している。

クラスオブジェクト管理部３０では、それぞれのプログラム１０は実行の際に、どのクラスオブジェクトを使用するか、という情報を記録している。プログラム１０とクラスオブジェクト部品との相互関係を示したものを図４に示す。

ここではプログラム管理テーブルというデータ構造を用意している。プログラムはそれぞれプログラム管理テーブル内にエントリを持ち、個々にＩＤやプログラム名などのプログラムに関しての属性値の情報を保持している。その中にはプログラムはどのようなクラスオブジェクト部品によって構成されるか、という情報も含まれている。ここではそれぞれのプログラム管理テーブル内のエントリが、クラスオブジェクト部品のデータに参照を持つことによって、その対応を取っている。

なお、一つのクラスオブジェクト部品が複数のプログラムによって共有される場合、複数のプログラムのエントリから参照されることになる。これは後のクラスオブジェクト共有化部が行う処理の説明の中で後述する。

それぞれのクラスオブジェクト部品は、どのプログラムによって使用されるものであるか、さらに、プログラム実行部７０によって実行中のプログラムに排他資源として占有されているかどうか、という情報を保持している。

図１３および図１４に、クラスオブジェクト部品のデータ構造の実現例を示している。クラスオブジェクト部品は、それぞれ従来のクラスオブジェクト部品が持つデータ（クラスオブジェクト部品データ）以外に、３つあるいは２つの情報を新たに保持している。

使用プログラムは、そのクラスオブジェクト部品はどのプログラムによって使用されているかを示す情報である。具体的には、前述のプログラム管理テーブルに対する参照値や、あるいはプログラム実行装置内でプログラム固有に与えられるＩＤ値を記録するなどして実現することができる。一つのクラスオブジェクト部品が複数のプログラムによって共有される場合、そのクラスオブジェクト部品が持つ使用プログラムの情報は、複数のプログラムを指すことになる。クラスオブジェクト部品が複数のプログラムによって共有される処理過程に関しては、後の実施の形態で後述する。

排他ロック保持プログラムは、プログラムの実行中においてそのクラスオブジェクト部品が排他ロック下にある場合、どのプログラムの実行によって排他資源として保持されている状態であるか、を示した情報である。具体的には、前述のプログラム管理テーブルに対する参照値や、あるいはプログラム固有に与えられるＩＤ値を記録するなどして実現することができる。

排他資源の処理の詳細に関しても、後の実施の形態で後述する。

共有フラグは、共有状態／非共有状態の２値を取る情報である。共有フラグが共有状態になっている場合は、そのクラスオブジェクト部品は２つ以上のプログラムから共有されている状態になっていることを示す。この状態は、クラスオブジェクト管理部のデータ構造によっては、クラスオブジェクト部品のデータ構造の中に含めなくても良い（図１４がその例である）。

また、クラスオブジェクト管理部３０は、ロード処理が行われる際、ロードを行ったクラスのクラス名と、そのロード処理によって生成されたクラスオブジェクト部品との対応を記録しておく。実現例を図示したものを図５に示す。

ここでは、ロード済クラス名記録というテーブル型のデータ構造を用意している（もちろん対応の記録が実現できるのであれば、他のデータ構造であってもよい）。

テーブルのそれぞれのエントリは、ロード処理を行ったクラスのクラス名と、その名前を持つクラスをロードした際に生成されたクラスオブジェクト部品への一つ以上の参照を保持している。

既にロード済クラス名記録のテーブルのエントリの中に同一のクラス名があるが、データ内容が異なっているクラスを新たにロードする際にも、名前が同一であれば、同一のクラス名を持つエントリの中に、新たに生成されたオブジェクト部品への参照を追加していってよい。

プログラム実行部７０の実現によっては、不要になったクラスオブジェクト部品を削除する（アンロード処理を行う）機能を備える場合もある。アンロードによって、有効なクラスオブジェクト部品への参照が一つも持たなくなったエントリは、ロード済クラス名記録の中から削除する。

プログラム実行部７０は、クラスオブジェクト管理部に記録されたクラスオブジェクトを用いて、プログラムを解釈実行する。Ｊａｖａ（Ｒ）仮想マシンの実行系の場合、このプログラム実行部は、従来の仮想マシンのインタプリタ部と同一のもので実現できる。

ロード済みクラス名判定部４０は、プログラムロード部がクラスをロードする場合に、クラス管理部に同一の名前をもつ別のクラスが既にロード済であるかどうかを問い合わせる。

クラスオブジェクト同一性比較部５０は、ロード済クラス名判定部が、同一の名前をもつクラスが既にロード済であると判定した場合に、ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとをバイナリ比較し、同一であるクラスオブジェクト部品と、同一でないクラスオブジェクト部品を分ける。

クラスオブジェクト共有化部６０は、ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとの間で、クラスオブジェクト同一性比較部が同一であると判定したクラスオブジェクト部品を共有化し、クラスオブジェクト管理部３０に記録する。クラスオブジェクトが複数のプログラムによって共有される場合の処理内容、およびその際のデータ構造は、実施例の中で説明する。

クラスオブジェクト最適化部８０は、クラスオブジェクトの部品を最適化変換する。

最適化コードオブジェクト共有化部は、クラスオブジェクト管理部３０によって共有対象とされたクラスオブジェクト部品が、クラスオブジェクト最適化部８０によって最適化変換された場合、最適化変換された後のクラスオブジェクト部品もまた共有対象として、クラスオブジェクト管理部３０に記録する。この場合の最適化後のクラスオブジェクトが複数のプログラムによって共有される場合の処理内容も、後述する実施の形態の中で説明する。

（実施の形態２）
本発明の実施の形態において最も基本的な、ロード処理におけるクラスオブジェクトの共有化の流れについて説明する。

図６は、プログラム実行装置の処理の流れについて説明したものである。

処理６０１によって処理が開始される。Ｊａｖａ（Ｒ）実行系の場合、ロード処理が行われるのは、プログラムが起動された直後である場合と、プログラムの解釈実行中（ダイナミックローディング）に実行系に要求されて行われる場合とがあるが、本処理の流れはどちらの場合でも実施することができる。

処理６０２は、ロード済クラス名判定部４０の行う処理に関するものである。ロード済クラス名判定部４０は、クラスオブジェクト管理部３０に問い合わせて、ロードを行うクラスと同一の名前をもつクラスが、既にクラスオブジェクト管理部３０に読み込まれているかどうかを検査する。この検査は前述のロード済みクラス名記録と、ロード対象のクラス名を比較することで実現することができる。

ここで、読み込まれていない場合、処理は６０３に移行する。処理６０３ではプログラムロード部による、従来と同様のロード処理が行われる。ロードするクラスからクラスオブジェクト部品が生成され、クラスオブジェクト管理部３０に記録される。

ロード済クラス名記録のテーブルには新たなエントリが追加され、生成されたクラスオブジェクト部品に対する参照がエントリの中に記録されることになる。

処理６０２で既に読み込まれている、と判断された場合には、処理は６０４に移行する。

処理６０４、６０５は、クラスオブジェクト同一性比較部５０の行う処理に関するものである。クラスオブジェクト同一性比較部５０は、クラスオブジェクトを一時記録するためのテンポラリの記録領域を保持する。

処理６０４ではまずロード対象のクラスは、クラスオブジェクトとして図３に示したような各部品に変換され、一旦テンポラリの記録領域に記録される。

処理６０５では、テンポラリに記録されたクラスオブジェクトの部品と、クラスオブジェクト管理部３０に記録された、同一の名前をもつクラスに属するクラスオブジェクト部品とで順次、同一性の比較が行われる。

ここで言う同一性とは「バイナリデータとして全く同じものである」ことを意味しており、両方の部品に関してデータの比較が行われ、同一性の判定が下される。

クラスオブジェクト管理部３０に記録されたクラスオブジェクトの部品の中に、テンポラリに記録されたクラスオブジェクトの部品と同一のものが発見された場合は処理６０６を行う。同一性が認められる部品がテンポラリの中に一つも残らなくなるか、またはテンポラリに記録された部品が一つもなくなるかしない限り、処理６０５から処理６０６が繰り返される。

処理６０６、６０７は、クラスオブジェクト共有化部６０の行う処理に関するものである。

処理６０６は、同一性が確認されたクラスオブジェクト部品について、以下のステップの処理を行うことで、共有化を行う。

（１）ステップ１：テンポラリのクラスオブジェクト部品に対して指されていた参照値を、全て、同一性が確認されたクラスオブジェクトを指すものに書き換える。

（２）ステップ２：テンポラリのクラスオブジェクト部品を消去する。

クラスオブジェクト部品の共有化の処理を図示化したものを図７に示す。初期状態である図７（ａ）から、クラスオブジェクト部品（ここでは定数プール部品）の同一性が確認されたとする。図７（ｂ）では、ステップ１として、テンポラリの定数プールを参照していたフィールド部品とメソッド部品の参照値がそれぞれ書き換えられる。図７（ｃ）ではステップ２として、テンポラリの定数プール部品が削除され、クラスオブジェクト管理部３０に共有化された定数プール部品のみが残ることになる。

処理６０７では、同一性が確認されなかったテンポラリに残った全てのクラスオブジェクト部品について、以下のステップの処理を行う。

なお、テンポラリにクラスオブジェクト部品が一つも残っていない、すなわち全ての部品が共有化されてしまった場合は、この処理６０７ではなにもしない。

（１）ステップ１：テンポラリのクラスオブジェクト部品のデータを、クラスオブジェクト管理部に新たにコピーする。

（２）ステップ２：テンポラリのクラスオブジェクト部品に対して指されていた参照値を、全て、クラスオブジェクト管理部３０に新たにコピーされたクラスオブジェクトを指すものに書き換える。

（３）ステップ３：ロード対象であるクラスのクラス名と、同一のクラス名が記録されたエントリを、ロード済クラス名記録の中から発見し、新たにコピーされたクラス部品に対する参照を、エントリの内容として追加記録する。

（４）ステップ４：テンポラリのクラスオブジェクト部品を消去する。

以上が、クラスをロードした際のクラスオブジェクト共有化の処理の流れである。

クラスオブジェクトの部品が、複数のプログラムによって共有化された場合の、プログラムとクラスオブジェクト部品との相互関係を示したものを図８に示す。

ここでは２つのプログラムによって、インタフェース部品、メソッド部品、アトリビュート部品、定数プール部品が共有されており、それぞれのクラスオブジェクトの部品は２つのプログラムのエントリから参照されることになる。

なお、複数のプログラムによって共有化されたクラスオブジェクト部品は、プログラム実行部７０による排他制御の対象になるが、この詳細と実現に関しては別に後述する。

（実施の形態３）
上記実施例における、クラスオブジェクト同一性比較部が行う処理６０５の説明において、比較対照であるクラスオブジェクト部品が「バイナリデータとして全く同じものである」ことを同一性判定の条件と記したが、実際には、バイナリデータとして異なる部分があったとしても同一とみなしても問題のない場合がある。

バイナリデータとして異なる場合でも、同一として判定できる場合の概念を図示化したものを図７に示す。

クラスオブジェクト部品の多くは、定数プールに対する参照を含んでおり、この参照は通常、定数プールに含まれるデータのエントリの位置を指している。

しかし定数プールのデータのエントリの位置は、主にクラスファイルの記録データ順に依存して決定付けられるものである。例え同一のプログラムから生成されたクラスファイルであっても、クラスファイルが生成されるツールや環境に差異があれば記録データ順は異なってしまう可能性がある。このような定数プールのエントリ位置の違いによる差異が発生してしまった場合には、バイナリ比較による方法ではオブジェクトプログラム部品の同一性を検出することができない。

本実施の形態のプログラム実行装置では、エントリの記録位置に関わらず、定数プールに記録されるデータ自体が同一とみなされれば同一のクラスオブジェクト部品であると判定を行うための、同一性検証の機構を提供する。

図１０は、本実施の形態のプログラム実行装置において、クラスオブジェクト同一性比較部の処理の流れについて説明したものである。この処理は図６における処理６０５の判定処理を、本実施の形態のプログラム実行装置の場合について詳細化したものである。

処理１００１、および処理１００２では、同一性の比較対象となっているクラスオブジェクト部品の中から、定数プールに対する参照を行っているデータ部分を検出する。

その後、処理１００３では、処理１００１、および処理１００２で抜き出された参照の部分以外のデータに対してバイナリ比較を行い、処理１００４で同一性の判定を行う。同一でないと判断された場合は、処理１００８に移行し、両クラスオブジェクト部品は同一ではない、という判定を返し、終了する。

処理１００４で同一であると判定された場合は、処理１００５に移行する。処理１００５では、処理１００１および処理１００２で抜き出された参照の部分それぞれについて、参照が示す定数プールのエントリに記録されているデータ内容同士の比較を行い、処理１００６で同一性の判定を行う。同一でないと判断された場合は、処理１００８に移行し、両オブジェクト部品は同一ではない、という判定を返し、終了する。

処理１００６で同一であると判定された場合には、処理１００７に移行し、両クラスオブジェクト部品は同一のものであると判定を行う。

以上の判定処理を行うことで、バイナリ的に全く同一でないクラスオブジェクト部品であっても、意味的に同一のものであるならば、クラスオブジェクト部品を共有化することができる仕組みを実現できる。

（実施の形態４）
上記実施の形態において、プログラム実行装置は、クラスオブジェクト最適化部を備えることがある。

例えばＪａｖａ（Ｒ）仮想マシンは、Ｊａｖａ（Ｒ）プログラムをより高速に解釈実行するために、元のクラスファイルのバイトコードを、最適化されたバイトコード、あるいはＪａｖａ（Ｒ）仮想マシンが搭載される機器のネイティブコードに変換する機構を備えることが一般的である。

バイトコードからネイティブコードに変換することによって、よりプログラムの解釈実行の高速化を実現することができるが、通常ネイティブコードはバイトコードよりもコードサイズが大きくなる傾向があり、必ずしも家電機器など省資源性が重要視される機器に対して適切な仕組みではないが、バイトコードを選択的に変換する、などの解決策を取ることによって省資源性と高速性を両立させることができる。

また最適化変換は、プログラムが解釈実行される前に行われる場合もあれば、プログラムの解釈実行の最中に行われる場合もある。プログラム実行装置が備える最適化の方針によって異なるが、本発明の処理はどちらの場合にも当てはめて適用することができる。

複数のプログラムによって共有化されたクラスオブジェクト部品は意味的に同一であり、クラスオブジェクトの最適化はそのクラスオブジェクトの意味を保存するため、最適化後のクラスオブジェクト部品もまた同じ複数のプログラムによって共有化することができる。

本実施の形態のプログラム実行装置では、最適化されたクラスオブジェクトを共有化する機構を提供する。処理の流れを図１１に示す。

処理１１０１および１１０２は、クラスオブジェクト最適化部が行う処理について示している。クラスオブジェクト最適化部の実現、および最適化クラスオブジェクトの生成方法については、特許文献４や従来のＪＩＴコンパイラにて行われているものと同様であるためここでは言及しない。

処理１１０１では、最適化の対象となるクラスオブジェクト部品が選択される。クラスオブジェクト部品の選択方法はさまざまな方式が考えられるが、解釈実行時におけるクラスオブジェクトの使用頻度のプロファイルを作成し、使用頻度の高いものを優先的に選択する、などの方式が一般に用いられる。他の方法としては、複数のプログラムによって共有されているクラスオブジェクト部品を優先的に選択することにしてもよい。

処理１１０２では、クラスオブジェクトに対して最適化変換を行い、最適化クラスオブジェクトを得る。ここでは得られたクラスオブジェクトもまたクラスオブジェクト部品としてクラスオブジェクト管理部に登録されるものとする。

処理１１０３および１１０４は、クラスオブジェクト共有化部が行う処理について示している。

処理１１０３は、処理１１０１にて選択されたクラスオブジェクト部品が、クラスオブジェクト管理部によって共有化されたものであるかどうかを判定する。これはプログラム管理テーブルとクラスオブジェクト部品との参照関係を検査することによって判定できる。複数のプログラムで共有化されたものであると判断された場合、処理１１０４に移行する。共有化されていない場合には、クラスオブジェクト共有化部は特にこれ以上何も行わず、従来の最適化変換の機構となんら変わらず処理を終了する。

処理１１０４は、最適化クラスオブジェクトを共有化する。最適化クラスオブジェクトを共有化する際の、プログラム管理テーブルとクラスオブジェクトの関係を図示化したものを図１２に示す。

図１２の上図は、クラスオブジェクト最適化部によって、アトリビュート部品から最適化クラスオブジェクトが生成されたことを意味する。最適化されたアトリビュート部品は、プログラムＡおよびプログラムＢによって共有化されているため、図１２の下図では、クラスオブジェクト共有化部によって、最適化クラスオブジェクトもまた共有化されることを図示している。

最適化クラスオブジェクトが共有化された後、元の最適化前のクラスオブジェクトを削除するかそのまま残しておくかはどうかは、クラスオブジェクト最適化部の最適化の方法にも依存する。省資源化の観点からは削除したほうが好ましいが、一旦クラスオブジェクトを最適化すると、それ以降に新たなクラスファイルのロードが発生した場合に同コードの共有化判定が困難になる場合が多いため、最適化前のクラスオブジェクトを残しておいても良い。

以上の処理を行うことで、最適化されたクラスオブジェクト部品を複数のプログラムによって共有化することができる仕組みを実現できる。

（実施の形態５）
次にクラスオブジェクト部品をプログラム間で共有するプログラム実行系における、排他制御の実現方式に関して言及する。以下の説明は、排他制御解除方法の仕組みについて述べたものである。

なお、本実施の形態の排他制御解除方法は、Ｊａｖａ（Ｒ）のように、異なるプログラム間で排他ロックの対象となるインスタンスが通信されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行系にのみ適用されることが前提である。

例えば同じオブジェクト指向プログラムの実行系であっても、Ｃ＋＋のようなポインタ操作により、プログラム間で同一アドレスに書き込まれたデータの受け渡しが自由なプログラム実行系は、本発明の適用の対象外である。

Ｊａｖａ（Ｒ）のようなプログラム実行系では、プログラムが固有に持つ生成するインスタンスについては、別プログラムはそのインスタンスに直接アクセスする手段を持たないため、プログラム間の排他制御の対象とはならない。すなわち、排他ロックの対象となるオブジェクトは、他のプログラムと共有するクラスオブジェクトだけである。

この原理を応用し、クラスオブジェクト部品を記録する、クラスオブジェクト管理部の中に排他制御のためのデータ構造を持たせることで、別途排他制御のための巨大なデータ領域などを必要とせず、排他ロックがかかるクラスオブジェクト部品群を容易に特定し、簡単な排他制御の実現方法を提供することができる。

以下、クラスオブジェクト管理部における、複数のプログラムに共有化されたクラスオブジェクト部品のデータ構造と、それを用いた排他制御の処理に関して説明する。

まずクラスオブジェクト管理部３０に記録されたクラスオブジェクト部品に対して共有フラグを設けることによって、排他制御の処理を実現している。

データ構造を図１３に示す。クラスオブジェクト部品は、従来のクラスオブジェクト部品が持つデータ（クラスオブジェクト部品データ）以外に、３つの情報を新たに保持している。

共有フラグは、共有状態／非共有状態の２値を取る情報である。

共有フラグが共有状態になっている場合は、そのクラスオブジェクト部品は２つ以上のプログラムから共有されている状態になっていることを示す。非共有状態の場合は、そのクラスオブジェクト部品は共有されておらず、一つのプログラムからしか使用されていないことを示す。

クラスがロードされて、クラスオブジェクト管理部３０にクラスオブジェクト部品が記録される場合、この部品は、新たに生成される場合と、既にロードされていたクラスオブジェクト部品と共有される場合との２種類が考えられる。新たに生成される場合にはクラスオブジェクトの共有フラグには非共有状態にセットされ、既にロードされていたクラスオブジェクト部品と共有される場合には、共有フラグは共有状態にセットされる。

使用プログラムは、そのクラスオブジェクト部品はどのプログラムによって使用されているかを示す情報である。具体的には、前述のプログラム管理テーブルに対する参照値や、あるいはプログラム実行装置内でプログラム固有に与えられるＩＤ値を記録するなどして実現することができる。

共有フラグが共有状態になっている場合には、使用プログラムは２つ以上のプログラムを記録する。共有フラグが共有状態になっていない場合には使用プログラムは一つのプログラムのみ記録する。

排他ロック保持プログラムは、プログラムの実行中においてそのクラスオブジェクト部品が排他ロック下にある場合、どのプログラムの実行によって排他資源として保持されている状態であるか、を示した情報である。

具体的には、前述のプログラム管理テーブルに対する参照値や、あるいはプログラム実行装置内でプログラム固有に与えられるＩＤ値を記録するなどして実現することができる。

共有フラグが非共有状態にあるクラスオブジェクト部品は、そもそも排他制御の対象にならないため、この排他ロック保持プログラムの情報は意味を持たない。

図１３のデータ構造を持つクラスオブジェクト部品に対しての、排他制御の流れに関して説明する。

あるプログラムＡの実行によって、共有化されたクラスオブジェクト部品に排他ロックが掛けられた場合の処理を図１５（ａ）に示す。処理１５０１でクラスオブジェクト部品の持つ排他ロック保持プログラムの情報に、プログラムＡを示す情報が書き込まれる処理が行われる。

プログラムの実行が終了した場合、プログラムの占有していた排他制御資源を解放するために行われる処理を図１５（ｂ）に示す。クラスオブジェクト管理部に記録された全てのクラスオブジェクト部品について、処理１５１１から処理１５１５の間の処理が行われる。

処理１５１２では、クラスオブジェクト部品の保持する共有フラグが共有状態であるかを検査する。非共有状態である場合にはこのクラスオブジェクト部品は排他制御の対象外であるためこれ以上の検査を行わず、処理１５１５に移行する。

処理１５１３では、クラスオブジェクト部品が排他ロックの対象になっており、なおかつこのクラスオブジェクト部品を占有しているのが終了したプログラムであるかどうかを、排他ロック保持プログラムの情報を参照して検査する。終了したプログラムによって占有されていない場合は、排他ロック解除の対象外であるためこれ以上の検査を行わず、処理１５１５に移行する。

処理１５１４では、クラスオブジェクト部品は排他ロック解除対象であるとみなして、ロック解除の処理を行う。具体的には排他ロック保持プログラムの情報に記録されている内容を削除する。

以上が、本実施の形態による排他制御の処理手順である。

（実施の形態６）
クラスオブジェクト管理部３０に記録されたクラスオブジェクト部品に対して、複数のプログラムから共有されているものと共有されていないものを管理可能なクラスオブジェクト部品管理テーブルを持つことによって、排他制御の処理を実現している。

データ構造を図１４に示す。クラスオブジェクト管理部３０は、クラスオブジェクト部品への参照を登録する、クラスオブジェクト部品テーブルを保持する。クラスオブジェクト部品テーブルは、複数のプログラムによって共有されたクラスオブジェクト部品への参照を登録する共有クラスオブジェクト部品テーブルと、単一のプログラムによってのみ使用されるクラスオブジェクト部品への参照を登録する非共有クラスオブジェクト部品テーブルの２つを持つ。

クラスがロードされて、クラスオブジェクト管理部３０にクラスオブジェクト部品が記録される場合、この部品は、新たに生成される場合と、既にロードされていたクラスオブジェクト部品と共有される場合との２種類が考えられる。前者の場合には、非共有クラスオブジェクト部品テーブルに、新たに生成されたクラスオブジェクト部品への参照が登録される。後者の場合には、非共有クラスオブジェクト部品テーブルに登録されている共有対象のクラスオブジェクト部品への参照が削除され、あらたに共有クラスオブジェクト部品テーブルに登録される。

クラスオブジェクト部品は、従来のクラスオブジェクト部品が持つデータ（クラスオブジェクト部品データ）以外に、２つの情報を新たに保持している。使用プログラムと、排他ロック保持プログラムであるが、これらの情報の意味は図１３の時と同じであるため、省略する。

図１４のデータ構造を持つクラスオブジェクト部品に対しての、排他制御の流れに関して説明する。

あるプログラムＡの実行によって、共有化されたクラスオブジェクト部品に排他ロックが掛けられた場合の処理を図１６（ａ）に示す。処理１６０１でクラスオブジェクト部品の持つ排他ロック保持プログラムの情報に、プログラムＡを示す情報が書き込まれる処理が行われる。

プログラムの実行が終了した場合、プログラムの占有していた排他制御資源を解放するために行われる処理を図１６（ｂ）に示す。共有クラスオブジェクト部品テーブルに記録された全てのクラスオブジェクト部品について、処理１６１１から処理１５１４の間の処理が行われる。

処理１６１２では、クラスオブジェクト部品が排他ロックの対象になっており、なおかつこのクラスオブジェクト部品を占有しているのが終了したプログラムであるかどうかを、排他ロック保持プログラムの情報を参照して検査する。終了したプログラムによって占有されていない場合は、排他ロック解除の対象外であるためこれ以上の検査を行わず、処理１６１３に移行する。

処理１６１３では、クラスオブジェクト部品は排他ロック解除対象であるとみなして、ロック解除の処理を行う。具体的には排他ロック保持プログラムの情報に記録されている内容を削除する。

以上が、本実施の形態による排他制御の処理手順である。

本発明のプログラム実行装置および排他制御解除方法は、省資源性が重視される家電などの機器において、オブジェクト指向プログラムの実行系を実現しようとする際に有用である。また、ＰＣ分野などでは普通に利用されているクラスオブジェクトの最適化変換機構と、省資源化のための共有化機構とを組み合わせた場合の適用に関しても述べており、より実応用性の高いシステムを実現することができる。

本発明にかかるプログラム実行装置の構成を示す概要図Ｊａｖａ（Ｒ）におけるクラスファイルのフォーマットを示す図クラスオブジェクトの部品の相互関係図プログラムとクラスオブジェクト部品の相互関係図クラス名を記録するテーブルの実現例を示す図本発明の処理の流れ図クラスオブジェクト共有化部による共有化の手順を示す図プログラムと共有化されたクラスオブジェクト部品の相互関係図参照先を考慮に入れたクラスオブジェクト共有化部による同一性判定を示す図クラスオブジェクト同一性比較部の処理内容を示す図クラスオブジェクト最適化部およびクラスオブジェクト共有化部の処理内容を示す図プログラムと最適化クラスオブジェクト部品の相互関係図を示す図共有化されるクラスオブジェクトを記録するデータ構造の一実施例を示す図共有化されるクラスオブジェクトを記録するデータ構造の一実施例を示す図本発明のデータ構造を用いた排他制御の流れを示す図本発明のデータ構造を用いた排他制御の流れを示す図

符号の説明

１０プログラム
２０プログラムロード部
３０クラスオブジェクト管理部
４０ロード済みクラス名判定部
５０クラスオブジェクト同一性比較部
６０クラスオブジェクト共有化部
７０プログラム実行部
８０クラスオブジェクト最適化部
９０最適化クラスオブジェクト共有化部

Claims

オブジェクト指向プログラムを実行するプログラム実行装置であって、
前記プログラム実行装置は、
オブジェクト指向プログラムをロードし、ロードされたデータであるクラスオブジェクトを生成するプログラムロード部と、
前記クラスオブジェクトが複数のオブジェクト指向プログラムから共有される場合に、共有対象となる前記クラスオブジェクトを記録するクラスオブジェクト管理部と、
前記クラスオブジェクト管理部に記録されたクラスオブジェクトを用いてオブジェクト指向プログラムを実行するプログラム実行部と、
前記プログラムロード部がクラスをロードする場合に、前記クラスオブジェクト管理部に同一の名前をもつ別のクラスが既にロード済であるかどうかを問い合わせるロード済クラス名判定部と、
前記ロード済クラス名判定部が、同一の名前をもつクラスが既にロード済であると判定した場合に、前記ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとをバイナリ比較し、同一であるクラスオブジェクト部品と、同一でないクラスオブジェクト部品に分けるクラスオブジェクト同一性比較部と、
前記ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとの間で、前記クラスオブジェクト同一性比較部が同一であると判定したクラスオブジェクト部品を共有化し、前記共有クラスオブジェクト管理部に記録するクラスオブジェクト共有化部とを備えることを特徴とするプログラム実行装置。
前記クラスオブジェクト同一性比較部は、
前記ロードしたクラスのクラスオブジェクトと、同一の名前を持つ別のクラスのクラスオブジェクトとを比較する際、それぞれのクラスオブジェクトが保持する定数に対する参照を検出し、前記参照が示す定数のデータ内容を比較し、データ内容が同じである場合には、両者は同一のクラスオブジェクト部品であると判定することを特徴とする請求項１記載のプログラム実行装置。
クラスオブジェクトの部品を最適化変換する、クラスオブジェクト最適化部と、
前記クラスオブジェクト管理部によって共有対象とされた前記クラスオブジェクト部品が、前記クラスオブジェクト最適化部によって最適化変換された場合、最適化変換された後のクラスオブジェクト部品もまた共有対象として、前記クラスオブジェクト管理部に記録する前記最適化コード共有化部を備えることを特徴とした、請求項１または２に記載のプログラム実行装置。
オブジェクト指向プログラム間での通信において、排他ロックの対象となるインスタンスが渡されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行方法において、
前記オブジェクト指向プログラムをロードして生成されるクラスオブジェクト部品は、複数の前記オブジェクト指向プログラムから共有されているかいないか判断可能となる共有フラグを持ち、
実行されている前記オブジェクト指向プログラムが、クラスオブジェクト部品に対する排他ロックをかけた状態でプログラムの実行を終了させた場合に、排他ロックの解除を行うクラスオブジェクト部品として、共有フラグが複数の前記オブジェクト指向プログラムから共有されている状態となっているクラスオブジェクト部品を抽出するステップと、前記共有されている状態となっているクラスオブジェクト部品全てに対して、終了させるプログラムの排他ロックを解除するステップとを持つことを特徴とするプログラム実行方法。
オブジェクト指向プログラム間での通信において、排他ロックの対象となるインスタンスが渡されることのない、動的リンクを行うオブジェクト指向プログラムを実行するプログラム実行方法において、
オブジェクト指向プログラムをロードして生成されるクラスオブジェクト部品は、複数の前記オブジェクト指向プログラムから共有されている部品と、複数プログラムから共有されていない部品を、それぞれ管理するクラスオブジェクト部品管理テーブルを持ち、
実行されている前記オブジェクト指向プログラムが、前記クラスオブジェクト部品に対する排他ロックをかけた状態で前記オブジェクト指向プログラムの実行を終了させた場合に、前記排他ロックの解除を行うクラスオブジェクト部品として、前記クラスオブジェクト部品管理テーブルから、複数の前記オブジェクト指向プログラムから共有されているクラスオブジェクト部品を抽出するステップと、前記共有されているクラスオブジェクト部品全てに対して、終了させるプログラムの排他ロックを解除するステップとを持つことを特徴とするプログラム実行方法。