JP2013514569A

JP2013514569A - 静的に型付けされたクラスベースのオブジェクト指向ソフトウェアのノンブロッキング動的更新の方法、コンピュータ・プログラム製品、およびシステム

Info

Publication number: JP2013514569A
Application number: JP2012543561A
Authority: JP
Inventors: グレゲルセン、アランローンダール; ラスムセン、ミケル; ヨルゲンセン、ボノアレゴール
Original assignee: Syddansk Universitet
Current assignee: Syddansk Universitet
Priority date: 2009-12-18
Filing date: 2010-11-16
Publication date: 2013-04-25
Also published as: US9015659B2; US20110283256A1; US20140189672A1; WO2011072970A1; EP2513787A1; CN102725730A; US8707287B2

Abstract

本発明の下で、アクティブに動作するコンピュータ・システム内の仮想マシン上でバイトコードとして実行する静的に型付けされたクラスベースのオブジェクト指向ソフトウェアのノンブロッキング動的更新の方法、コンピュータ・プログラム製品、およびシステムが提供される。既存の１つまたは複数のモジュール（バイトコード表現の形でのアプリケーション・リソースおよびクラス定義の識別可能なコレクション）からインスタンス化されたオブジェクトのセットは、アクティブに動作するコンピュータ・システム内の仮想マシン上での実行の準備ができている。アクティブに動作する仮想マシンに既にロードされたモジュールに対応する１つまたは複数のモジュールの新しいバージョンが、動作中のソフトウェアを更新するために仮想マシンに動的にロードされる。ロードされたモジュール内のクラス定義は、あるクラスの以前のバージョンのオブジェクトと新しいバージョンのオブジェクトとの間の透過的状態転送および共有されるオブジェクト・アイデンティティを可能にするバイトコードを挿入することによって、動的更新のために準備される。ソフトウェア更新の場合に、更新されるクラスの以前のバージョンからインスタンス化されたオブジェクトは、その将来の対応するオブジェクトへリダイレクトする潜在能力を有する未初期化サロゲートオブジェクトになる。対応するオブジェクトは、宣言するクラス・メンバの最初のアクセス時にレイジイに作成される。オブジェクトおよびクラスの挙動のレイジイ・リダイレクションに加えて、ノンブロッキング動的更新が、レイジイ移植によって達成される。

Description

本発明は、コンピュータ・システム上でアクティブに動作しているソフトウェアのプログラミング・コードを、再始動またはソフトウェアのランタイム状態を失わせることを必要とせずに、現在のバージョンから新しいバージョンに動的に更新することに関する。より具体的には、本発明は、言語のコンパイラが、ＪＡＶＡ（登録商標）プログラミング言語で記述されたソフトウェアによって実施されるように動的にロードされ仮想マシン上で実行されるバイトコード・ベースのクラス定義の形の実行可能オブジェクト・コードを作る、静的に型付けされたクラスベースのオブジェクト指向プログラミング言語で記述されたアクティブに動作しているソフトウェアの状態と機能性との両方を動的に更新することを可能にすることに関する。本発明を用いると、アクティブに動作しているソフトウェア・システムは、動的更新工程の結果としてソフトウェアのプログラミング・コードに対する変更が即座に実現されるので、これらの変更が行われる前の標準的な停止、再展開、および再始動方式を経験する必要がもはやなくなる。

多数の重要なアプリケーションのために非常に信頼性のあるコンピュータ・システム上で動作する高可用性コンピュータ・アプリケーションが存在する。これらのシステムおよびプログラムは、通常、毎日２４時間、毎週７日間動作し、処理への割込みは、顧客サービスおよびいくつかの状況で安全性に関する深刻な影響を有するおそれがある。たとえば、インターネットおよびワールド・ワイド・ウェブを介する電子商取引の出現は、ｅコマース・ウェブサイトが取引を処理するために常に使用可能であることを必要とする。他の例は、クレジット・カード取引処理アプリケーション、航空交通管制アプリケーションなどを含む。

そのようなミッション・クリティカル・アプリケーション用のソフトウェアは、開発環境上で「オフラインで」機能強化されるので、そのような機能強化されたソフトウェアを生産環境に「オンラインで」展開しまたはリフレッシュすることが必要になる。そのような機能強化を展開する、前の形は、状態データを保存し、シャットダウンするかクリティカル・アプリケーションの可用性を他の形で損ない、新しいソフトウェアをインストールし、アプリケーションを再始動するか他の形で完全に使用可能にし、その後、ソフトウェアの前の状態を復元することを必要とした。この点で、アプリケーションは、既存のデータを用いて機能強化されたコードを実行しているはずである。

システムのシャットダウンまたは、システムの手動静止などの他の性能に影響するイベントによって、サービスは途絶される。サービス途絶を避けるために、ソフトウェア更新は、しばしば、セキュリティおよび安全性を危険にさらすリスクを伴って、できる限り遅延される。したがって、システムのシャットダウンまたは割込みを必要とせずに、アクティブに動作しているシステム内のソフトウェアの１つまたは複数のモジュールに変更（機能強化および／または保守）を適用する必要が存在する。さらに、アクティブに動作しているシステム内でそのようなモジュールを追加しまたは削除する必要が存在する。

増加する種類のミッション・クリティカル・アプリケーションが、静的に型付けされたクラスベースのオブジェクト指向プログラミング言語で記述されるので、そのようなアプリケーションの個々のモジュール内でクラスを動的に更新するという特定の課題に対処する必要がある。

動作中のシステム上で、静的に型付けされたクラスベースのオブジェクト指向プログラミング言語で記述されたモジュールを更新する時には、更新は、変更されるクラスの前のインスタンスから状態情報を保存し、これらのクラスの新しいインスタンスにこの情報を提供する必要がある。さらに、クラスのセットの更新が原子的に行われることを保証する必要が存在する。というのは、そうでなければ、更新が、クラスの以前のバージョンと新しいバージョンとの型の変化に起因するバイナリ非互換性を引き起こす可能性があり、これが、ランタイム障害を引き起こし、システム全体を停止させるからである。

広く受け入れられた静的に型付けされたクラスベースのオブジェクト指向プログラミング言語ＪＡＶＡ（登録商標）は、ドミトリーブ（Ｄｍｉｔｒｉｅｖ）の提案したクラス再ロード機能の実装［５］（非特許文献１）を介する、クラスの動的再定義のあるサポートを有する。再定義は、メソッド本体、定数プール、および属性のプログラミング・コードを変更することができる。しかし、クラス再定義は、フィールドもしくはメソッドの追加、除去、もしくは名前の変更、メソッドのシグネチャの変更、修飾子の変更、または継承階層の変更を行ってはならない。これらの制限は、あるクラスの後続バージョンの間のバイナリ非互換性問題を避けるために課せられる。実際には、これらの制限は、ＪＡＶＡ（登録商標）での現在のクラス再定義能力を、大規模で寿命の長いミッション・クリティカル・アプリケーションに必要なほとんどの動的更新をサポートするのに不適切なものにする。

［６］（非特許文献２）で、マラバーバ（Ｍａｌａｂａｒｂａ）らは、新しい動的クラスローダを有する変更されたＪＡＶＡ（登録商標）仮想マシンに基づいて、アクティブに動作しているソフトウェア内に現在存在する他のクラスが変更されるクラスの一部に依存しない限り、Ｊａｖａクラスに対するすべての変更を可能にする方法ＤｙｎａｍｉｃＪａｖａＣｌａｓｓｅｓを開示している。更新されるクラスにこれらの制限を課すことによって、この方法は、動的に型安全になる。たとえば、他のクラスがあるフィールドまたはメソッドに依存しない場合に、そのフィールドまたはメソッドを除去してもよい。同様に、あるクラスの型に対する変更が、そのクラスに依存するクラスの型違反を引き起こさない限り、その変更を行うことができる。この新しい動的クラスローダは、型違反を引き起こすクラスの過渡的ロードをサポートしないので、この方法は、一時に単一のクラスの動的更新に制限され、これは、非トリビアルなソフトウェア更新について変更スコープを制限するためものである。さらに、この方法は、競争状態が発生するのを防ぐために、マルチスレッド・アプリケーションのクラスを更新する間に、すべてのアクティブ・スレッドをブロックしなければならない。このスレッドのブロックは、ソフトウェア更新が行われる時のアプリケーション実行における望ましくない動揺を引き起こす。

［７］（非特許文献３）で、スブラマニアン（Ｓｕｂｒａｍａｎｉａｎ）らは、変更されたＪＡＶＡ（登録商標）仮想マシンに基づいて、開発者がクラス階層内のどこにでもフィールドおよびメソッドを追加し、削除し、置換することを可能にする方法ＪＶＯＬＶＥを開示している。ＪＶＯＬＶＥは、ＶＭクラスローディング、ジャストインタイム・コンパイル、スケジューリング、リターン・バリア（ｒｅｔｕｒｎｂａｒｒｉｅｒ）、オンスタック置換、およびガーベジ・コレクションに追加し、調整することによってこれらの更新を実装する。新しいフィールドを初期化し、既存フィールドを更新するために、ＪＶＯＬＶＥは、クラス・トランスフォーマ関数およびオブジェクト・トランスフォーマ関数を適用し、前者はスタティック・フィールド用であり、後者はオブジェクト・インスタンス・フィールド用である。クラス・トランスフォーマ関数およびオブジェクト・トランスフォーマ関数は、いわゆる更新準備ツール（ＵｐｄａｔｅＰｒｅｐａｒａｔｉｏｎＴｏｏｌ）によって更新ごとに準備され、この更新準備ツールは、更新されるクラスの以前のバージョンと新しいバージョンとの間の差を調べる。ＪＶＯＬＶＥは、ガーベジ・コレクション（ＧＣ）およびスレッド・スケジューリングを実行して安全であるＶＭセーフ・
ポイントで、実行中のスレッドを停止させる。ＪＶＯＬＶＥは、ガーベジ・コレクタおよびＪＩＴコンパイラを利用して、変更されるクラスに関連するコードおよびデータを更新する。ＪＶＯＬＶＥは、ヒープ全体のＧＣを開始して、更新されるクラスの既存オブジェクト・インスタンスを見つけ、提供されるオブジェクト・トランスフォーマを使用して新しいバージョンを初期化する。ＪＶＯＬＶＥは、すべての変更されるメソッド実装について、既存のコンパイル済みコードを無効化し、新しいバイトコードをインストールする。アプリケーションが実行を再開する時に、これらのメソッドは、次に呼び出される時にＪＩＴコンパイルされる。ＪＶｏｌｖｅは、更新を行える前に、ソフトウェアが静止の状態に達することを必要とする、すなわち、すべてのアプリケーション・スレッドが、ＶＭセーフ・ポイントで停止されなければならない。更新工程は、ヒープ全体のガーベジ・コレクションの持続時間中にアプリケーションが一時停止することを要求するｓｔｏｐ−ｔｈｅ−ｗｏｒｌｄガーベジ・コレクションベースの手法を使用する。ＶＭセーフ・ポイントでのアプリケーション・スレッドのこの同期化されたブロックは、予測不能な時間期間にわたるサービス途絶を引き起こす。

［８］（非特許文献４）で、グスタフソン（Ｇｕｓｔａｖｓｏｎ）は、プログラムが動作している間にクラスを更新する能力を用いてＪＡＶＡ（登録商標）仮想マシンを拡張する方法ＪＤｒｕｍｓを開示している。動作中のプログラム内の事前に存在するインスタンスを有するクラスを更新するために、ＪＤｒｕｍｓは、すべてのそのようなオブジェクトを、更新仕様に従って新しいクラスのオブジェクトに変換する。更新仕様は、更新を開始する時に、更新されるクラスと一緒に提供されなければならない。同様に、更新されるクラスのスタティック・データについて更新仕様を指定することが可能である。更新仕様は、ＪＡＶＡ（登録商標）ソースコード内で、更新されるクラスごとに１つのいわゆるＣＯＮＶＥＲＳＩＯＮＣＬＡＳＳ内で定義される。ｃｏｎｖｅｒｓｉｏｎｃｌａｓｓは、変換をどのように実行しなければならないのかを定義するメソッドを含む。ＪＤｒｕｍｓは、クラスの継承階層の動的変更をサポートしない。

［３］（非特許文献５）で、オルソ（Ｏｒｓｏ）らは、オブジェクト・ラッパを介するインダイレクションを使用するホットスワップ技法に基づいて、動作中のＪＡＶＡ（登録商標）アプリケーションからのクラスの置換、追加、および除去を可能にする方法ＤＵＳＣ（ＤｙｎａｍｉｃＵｐｄａｔｉｎｇｔｈｒｏｕｇｈＳｗａｐｐｉｎｇｏｆＣｌａｓｓｅｓ）を開示している。ＤＵＳＣは、まず、オブジェクト・ラッパを導入するためにクラス・リネーミングおよびコード書換を適用し、その後、ランタイムにクラスをスワップすることによるクラス更新を実行することによって、動的更新を可能にする。この方法は、アプリケーション・プログラミングに複数の制限を課す、すなわち、アプリケーション内のクラスは、更新されるクラスのｐｕｂｌｉｃフィールドまたはｐｒｏｔｅｃｔｅｄフィールドに直接にアクセスすることを許可されず、リフレクションは、更新されるクラスのどれにもおよび更新されるクラスのコンポーネントのどれにも適用されず（リフレクションの形として、ｊａｖａ．ｌａｎｇ．Ｃｌａｓｓのメソッドなど、特定のクラスに関する情報を点検するすべてのメソッドをも含む）、更新されるクラスの新しいバージョンは、そのクラスの前のバージョンによって提供されるものと同一のインターフェースを提供し、更新されるクラスは、ネイティブ・メソッドを含んではならず、更新されるクラスのメソッドは、更新中に実行されていない（すなわち、そのクラスのメソッドは、スタック上にない）。開発者は、ＤＵＳＣを使用して動的に更新可能なアプリケーションをプログラムする時に、これらの制限のすべてを考慮に入れなければならない。

［９］（非特許文献６）で、ビアレク（Ｂｉａｌｅｋ）らは、ＪＡＶＡ（登録商標）アプリケーションのパーティショニングに基づく、これらのパーティションを更新可能ユニットにする方法を開示している。アプリケーションのパーティションは、パーティションが含むクラスをカプセル化し、明示的な提供されるインターフェースおよび要求されるイ
ンターフェースを有し、パーティションをコンポーネントに似たものにする。新しいパーティションの実装の提供されるインターフェースは、少なくとも、更新が拒否されない場合に、前のバージョンの提供されるインターフェースを含まなければならない。したがって、この方法は、提供されるインターフェースからのパブリック・メンバの除去をサポートしない。パーティショニングに関する情報は、開発者によって提供されることまたはソースコードから自動的に抽出されることのいずれかとすることができる。開示される方法は、バージョン・アダプタを使用することによってメソッド、フィールド、およびコンストラクタを追加し、メソッド署名を変更することを可能にする。各パーティションは、状態転送関数を提供する。パーティションの状態転送関数は、古いパーティションのオブジェクトの状態の、それに対応する新しいバージョンへのマッピングを含む。アプリケーション・プログラマは、これらのバージョン・アダプタおよび状態転送関数を記述することを要求される。あるパーティションが更新される時に、そのパーティションへのすべてのアクセスがブロックされる。更新が終了した後に、パーティションは、アンロックされ、アプリケーションは、更新されたパーティションのオブジェクトの新しいバージョンを使用してその通常実行を継続することができる。

［１０］（非特許文献７）で、ヒャルムティソン（Ｈｊａｌｍｔｙｓｓｏｎ）およびグレイ（Ｇｒａｙ）は、実行中のＣ＋＋プログラムのクラスレベルでのランタイム更新を可能にする方法、ＤｙｎａｍｉｃＣ＋＋ｃｌａｓｓｅｓを開示している。この方法は、ダイナミックリンキング・インターフェースにまたがるプログラムレベル抽象化の保存をむずかしくする、Ｃ＋＋が動的にロード可能なモジュールの作成を直接にはサポートしないという問題に対処する。ＤｙｎａｍｉｃＣ＋＋Ｃｌａｓｓｅｓは、一般的なＣ＋＋特徴を活用し、ほとんどの現代のコンパイラを用いてコンパイルできるプロキシ手法に基づく。プロキシ手法は、既存クラスのバージョン更新ならびに新しいクラスの導入をサポートする。それを行うために、メイン・プログラムは、新しい実装と通信する（そのメソッドを呼び出す）ことができなければならない。したがって、各実装は、コンパイル時にメイン・プログラムに既知のインターフェースを有しなければならない。各新しい実装は、既存クラスを更新する（新しいバージョン）か、既知のインターフェースを使用する新しいクラスを導入する（新しい型）かのいずれかを行う。この制限に起因して、この方法は、メソッドの更新だけに制限される。

［１１］（非特許文献８）で、スタネック（Ｓｔａｎｅｋ）らは、Ｃ＋＋クラスを動的に更新することを可能にする方法、ＤｙｎａｍｉｃａｌｌｙＥｖｏｌｖａｂｌｅＣ＋＋Ｃｌａｓｓｅｓを開示している。クラスの追加、除去、更新、マージ、および分割を含む。クラスの動的なマージおよび分割は、状態変換機能を使用して可能にされる。アプリケーションをＤｙｎａｍｉｃａｌｌｙＥｖｏｌｖａｂｌｅＣ＋＋Ｃｌａｓｓｅｓと一緒に使用するためには、アプリケーションのある準備が必要である。この準備は、（ａ）ＤｙｎａｍｉｃａｌｌｙＥｖｏｌｖａｂｌｅＣ＋＋Ｃｌａｓｓｅｓの基礎になるフレームワークによって提供されるスマート・ポインタおよびコンテナ・テンプレートを使用してアプリケーションを記述することと、（ｂ）フレームワークによって定義される共通ＡＰＩをクラスごとに実装することと、（ｃ）インスタンス作成およびデストラクションのためのファクトリ・メソッドを実装することと、（ｄ）各クラスを別々のダイナミック・リンク・ライブラリにコンパイルすることと、（ｅ）ダイナミック・クラス・ライブラリのそれぞれをフレームワークのクラス・レジストリに登録することとからなる。基礎になるフレームワークは、更新の状態変換の後にオブジェクト参照を記憶するために、Ｃ＋＋テンプレートとして実装されたスマート・ポインタに基づく。提示されたように、この方法は、マルチスレッド・アプリケーションでの競争状態の下で安全な状態変換が無視されるので、シングル・スレッド・アプリケーションだけに適用される。

［１２］（非特許文献９）で、チェン（Ｃｈｅｎ）らは、古いバージョンおよび新しい
バージョンを並列に動作させることによってマルチスレッド・ソフトウェアを動的に更新することを可能にする方法ＰＯＬＵＳを開示している。ＰＯＬＵＳは、アプリケーション・データの古いバージョンと新しいバージョンとの両方の同時共存を可能にすることによって並列実行を達成し、更新されるデータのいずれかのバージョンへの書込アクセスがある時に必ずある状態同期化関数を呼び出すことによってバージョンの間のコヒーレンスを維持し、ＰＯＬＵＳは、オペレーティング・システムによって提供されるデバッギングＡＰＩ（たとえば、ＵＮＩＸ（登録商標）のｐｔｒａｃｅおよびＷＩＮＤＯＷＳ（登録商標）のＤｅｂｕｇＡｃｔｉｖｅＰｒｏｃｅｓｓ）を使用して更新工程中にデータのいずれかのバージョンを書込保護する。この同期化手法は、マルチスレッド・ソフトウェアで複数のスレッドがデータの異なるバージョンに同時にアクセスする時の一貫性を保証する。並列実行は、古いバージョンのアクティブ・スレッドがなくなるや否や、終了する。その時から、オリジナル関数のプロローグに間接ジャンプ命令を挿入するのにバイナリ書換を使用して、すべての関数呼出が、古いバージョンから新しいバージョンにリダイレクトされる。ＰＯＬＵＳは、Ｃプログラミング言語のような命令型（手続き型）プログラミング言語の動的更新のために設計されている。したがって、ＰＯＬＵＳは、クラスベースのオブジェクト指向プログラミング言語に適用可能ではない。

（特許文献１）に、外部ソースを使用して、ユーザ・アプリケーションのデータ空間内の可変データの最小単位を動的に更新することを可能にする方法およびサービスが開示されている。アプリケーションＧＵＩは、データ・ユニットを選択し、ブローカ・トピックにリンクすることを可能にする動的更新ユーティリティ（ｄｙｎａｍｉｃｕｐｄａｔｅ
ｕｔｉｌｉｔｙ、ＤＵＵ）を用いて機能強化される。本発明は、アクティブ状態を失わずにアクティブに実行中のソフトウェアのプログラミング・コードを動的に更新することに対処するが、（特許文献１）は、データ値の動的更新という異なる問題に対処する。

（特許文献２）は、アクティブに動作中のコンピュータ・システム内でソフトウェア・モジュールを動的にリフレッシュする方法、コンピュータ・システム製品、およびシステムを開示している。既存の１つまたは複数のモジュール（実行可能コードの認識可能なユニット）は、アクティブ・コンピュータ・システム内での実行の準備ができている。機能において既存モジュールに対応する新しいモジュールが、既存モジュールを更新するためにコンピュータ・システム・メモリにロードされる。新しいモジュールは、既存モジュールによって現在使用されつつあり、他の点で実行を引き継ぐ準備ができている対応する状態データをポイントすることによって、実行の準備をされる。呼出点からのアクセスまたは呼出参照を既存モジュールから新しいモジュールに切り替えるために、比較的短い瞬間の間に排他的にリフレッシュする工程のために実行に対してロックが保持される。ロックは、今や開放され、既存データを用いる新しいモジュールの実行を可能にし、したがって、モジュールの更新またはリフレッシュを達成する。最後に、前のすなわち「古い」モジュールが、メモリから除去される。本発明は、静的に型付けされたクラスベースのオブジェクト指向プログラミング言語で記述されたアクティブに動作するソフトウェアのノンブロッキング動的更新を可能にするが、（特許文献２）の方法は、手続き型言語で記述されたソフトウェアのブロッキング動的更新に制限される。

米国特許第７５３００７７号米国特許第６６２９３１５号

ドミトリーブ（Ｄｍｉｔｒｉｅｖ）Ｍ．：ＳａｆｅＥｖｏｌｕｔｉｏｎｏｆＬａｒｇｅａｎｄＬｏｎｇ−ＬｉｖｅｄＪａｖａＡｐｐｌｉｃａｔｉｏｎｓ、ＰｈＤｔｈｅｓｉｓ、ＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｉｎｇＳｃｉｅｎｃｅ、ＵｎｉｖｅｒｓｉｔｙｏｆＧｌａｓｇｏｗ、ＧｌａｓｇｏｗＧ１２８ＱＱ、Ｓｃｏｔｌａｎｄ、２００１．マラバーバ（Ｍａｌａｂａｒｂａ）Ｓ．、パンデイ（Ｐａｎｄｅｙ）Ｒ．、グラッグ（Ｇｒａｇｇ）Ｊ．、バール（Ｂａｒｒ）Ｅ．、ａｎｄバーンズ（Ｂａｒｎｅｓ）Ｆ．：ＲｕｎｔｉｍｅＳｕｐｐｏｒｔｆｏｒＴｙｐｅ−ＳａｆｅＤｙｎａｍｉｃＪａｖａＣｌａｓｓｅｓ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆＥＣＯＯＰ’００、ＬｅｃｔｕｒｅＮｏｔｅｓｉｎＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅ、Ｖｏｌ．１８５０、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、（２０００）、ｐｐ．３３７−３６１．スブラマニアン（Ｓｕｂｒａｍａｎｉａｎ）Ｓ．、ヒックス（Ｈｉｃｋｓ）Ｍ．、マッキンレイ（ＭｃＫｉｎｌｅｙ）Ｋ．：ＤｙｎａｍｉｃＳｏｆｔｗａｒｅＵｐｄａｔｅｓ：ＡＶＭ−ｃｅｎｔｒｉｃＡｐｐｒｏａｃｈ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅ２００９ＡＣＭＳＩＧＰＬＡＮｃｏｎｆｅｒｅｎｃｅｏｎＰｒｏｇｒａｍｍｉｎｇｌａｎｇｕａｇｅｄｅｓｉｇｎａｎｄｉｍｐｌｅｍｅｎｔａｔｉｏｎ、ＡＣＭＳＩＧＰＬＡＮＮｏｔｉｃｅｓ、Ｖｏｌｕｍｅ４４、Ｉｓｓｕｅ６、Ｍａｙ２００９、ｐｐ．１〜１２．グスタフソン（Ｇｕｓｔａｖｓｏｎ），Ｊ．：ＤｙｎａｍｉｃＵｐｄａｔｉｎｇｏｆＣｏｍｐｕｔｅｒＰｒｏｇｒａｍｓ − ＰｒｏｐｏｓｅｄＩｍｐｒｏｖｅｍｅｎｔｓｔｏｔｈｅＪＤｒｕｍｓＵｐｄａｔｉｎｇＳｙｓｔｅｍ、Ｒｉｓｅｐｕｂｌｉｃａｔｉｏｎｓ、２００５．オルソ（Ｏｒｓｏ）Ａ．、ラオ（Ｒａｏ）Ａ．、ハロルド（Ｈａｒｒｏｌｄ）Ｍ．Ｊ．：ＡＴｅｃｈｎｉｑｕｅｆｏｒＤｙｎａｍｉｃＵｐｄａｔｉｎｇｏｆＪａｖａＳｏｆｔｗａｒｅ、Ｉｎ：ｐｒｏｃｅｅｄｉｎｇｓｏｆＩＣＳＭ’０２、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙ、２００２、ｐｐ．６４９−６５８．ビアレク（Ｂｉａｌｅｋ），Ｒ．、ジュル（Ｊｕｌ），Ｅ．、Ｊ．−Ｇ．シュナイダ（Ｓｃｈｎｅｉｄｅｒ），Ｊ．−Ｇ．、ジン（Ｊｉｎ），Ｙ．：ＰａｒｔｉｔｉｏｎｉｎｇｏｆＪａｖａａｐｐｌｉｃａｔｉｏｎｓｔｏｓｕｐｐｏｒｔｄｙｎａｍｉｃｕｐｄａｔｅｓ、ＩｎｐｒｏｃｅｅｄｉｎｇｓｏｆＡＰＳＥＣ’０４、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙＰｒｅｓｓ、ｐｐ．６１６−６２３．ヒャルムティソン（Ｈｊａｌｍｔｙｓｓｏｎ）Ｇ．、グレイ（Ｇｒａｙ）Ｒ．：ＤｙｎａｍｉｃＣ＋＋ｃｌａｓｓｅｓ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅＵＳＥＮＩＸ１９９８ＡｎｎｕａｌＴｅｃｈｎｉｃａｌＣｏｎｆｅｒｅｎｃｅ、ｐａｇｅｓ６５−７６、ＵＳＥＮＩＸＡｓｓｏｃｉａｔｉｏｎ、Ｊｕｎｅ１５−１９１９９８．スタネック（Ｓｔａｎｅｋ）Ｊ．、コタリ（Ｋｏｔｈａｒｉ）Ｓ．、ヌイェン（Ｎｇｕｙｅｎ）Ｔ．Ｎ．、クルズニエラ（Ｃｒｕｚ−Ｎｅｉｒａ）Ｃ．２００６．ＯｎｌｉｎｅＳｏｆｔｗａｒｅＭａｉｎｔｅｎａｎｃｅｆｏｒＭｉｓｓｉｏｎ−ＣｒｉｔｉｃａｌＳｙｓｔｅｍｓ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆＩＣＳＭ’０６、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙ、２００６、ｐｐ．９３−１０３．チェン（Ｃｈｅｎ）Ｈ．、ユウ（Ｙｕ）Ｊ．、チェン（Ｃｈｅｎ）Ｒ．、ザン（Ｚａｎｇ）Ｂ．、イェウ（Ｙｅｗ）Ｐ．：ＰＯＬＵＳ：ＡＰｏｗｅｒｆｕｌＬｉｖｅＵｐｄａｔｉｎｇＳｙｓｔｅｍ、ＩｎＰｒｏｃｅｅｄｉｎｇｓＩＣＳＥ’０７、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙ、２００７、ｐｐ．２７１−２８１．

前述を考慮すると、ソフトウェアまたはソフトウェアを実行するコンピュータを再始動することを必要とせず、ソフトウェアに対する更新を実行した結果としてソフトウェアのランタイム状態を失わない、静的に型付けされたクラスベースのオブジェクト指向ソフトウェアの透過的ノンブロッキング動的更新のシステム、方法、およびプログラム製品の必要が存在する。

本発明の実施形態は、バイトコードにコンパイルされ、アクティブに動作するデスクトップ機、サーバ、メインフレーム、または組込みコンピューティング・デバイス上のプラットフォーム独立仮想マシン内で実行される、静的に型付けされたクラスベースのオブジェクト指向ソフトウェアのノンブロッキング動的更新のシステム、方法、およびプログラム製品を提供する。具体的には、本発明の下で、ソフトウェアのプログラミング・コードのバージョンの間の変更を有効にするためにソフトウェアを再始動する必要を回避するために、ソフトウェアのクラス定義の異なるバージョンのバイトコードは、仮想マシンにロードされる時に一連の変換を受ける。これらの変換は、アクティブに動作しているコンピュータ・システムに存在するクラスの前のバージョンのすべてのライブ・オブジェクトの、オブジェクトがクラスの前のバージョンからインスタンス化された後に動的にロードされたクラスの新しいバージョンの対応するオブジェクトのサロゲートオブジェクトへのランタイム・スイッチングを可能にし、オブジェクト・アイデンティティおよびクラス型代入可能性は、オブジェクトおよびクラスのサロゲート（Ｓｕｒｒｏｇａｔｅ）とその共存するバージョンとの間で共有される。本発明は、まず、更新されたサブクラスによって定義される拡張された挙動および／またはオーバーライドされた挙動が更新される仮想マシン固有ブートストラップ・クラスの以前のバージョンの既にインスタンス化されたオブジェクトについて実現されるようにするために、ブートストラップ・クラスにバイトコードをインジェクトすることによって、ブートストラップ・クラスのアプリケーション・サブクラスに対する将来の更新のためにブートストラップ・クラスを準備するために、ブートストラップ・クラスのプリブート・バイトコード変換を実行することによって動作する。次に、本発明は、変換されたブートストラップ・クラスがアプリケーション・インスタンスの仮想マシン・ブートストラップ・クラスの新しいセットを構成するアプリケーション・インスタンスを実行することによって進行する。実行中に、本発明は、仮想マシンにロードされるすべてのクラスのバイトコードのローディングをインターセプトし、クラスローディングが開始された後に、本発明は、連続するフェーズで、対応する共存するオブジェクトおよびクラスの共有されるオブジェクト・アイデンティティおよびクラス型アイデンティティを可能にするためにクラスのバイトコードを変換する。ロードされるクラスのカテゴリに応じて、本発明は、異なる変換を実行する、すなわち、システム・クラスのバイトコードが、それから派生するアプリケーション・サブクラスの将来の更新のためにシステム・クラスを準備するために変換され、これは、更新されたサブクラスによって定義される拡張された挙動および／またはオーバーライドされた挙動が更新されたサブクラスの以前のバージョンの既にインスタンス化されたオブジェクトについて実現されるようにするためにシステム・クラスにバイトコードをインジェクトすることによって達成され、アプリケーション・クラスのバイトコードが、アプリケーション・クラスへのバイトコードのインジェクトによって、アプリケーション・クラスを更新対応にするために変換され、これによって、アイデンティティおよび状態がノンブロッキングな形で自動的に転送される将来の対応するオブジェクトおよびクラスのサロゲートクラスおよびオブジェクトになるためにアプリケーション・クラスおよびそのインスタンスのランタイム・スイッチングを可能にする。最後に、ソフトウェア更新の場合に、ソフトウェア更新は、現在動作しているシステムと新しいバージョンとの間の差を構成するクラス定義の変更セットのバイトコードを含み、本発明は、新しいクラス定義の将来オンデマンド・インスタンス化される対応するオブジェクトの未初期化サロゲートになるために変更セット内のクラスからイ
ンスタンス化された現在ライブのオブジェクトの挙動を透過的にスイッチングすることによって、アクティブに動作しているコンピュータ・システムのノンブロッキング・ソフトウェア更新を実行する。

この実施形態の変形形態では、ライブ・オブジェクトのオブジェクト・アイデンティティおよび状態は、クラスのより後のバージョンのオブジェクトの新しい対応するバージョンへの動的ソフトウェア更新の後の最初の使用時に対にされ、バイトコードの変換は、まず、更新されたクラス・バージョンの新しい未初期化対応オブジェクトをコンストラクトすることと、その後、対応するオブジェクトの一意アイデンティティｉｄをコンストラクトし、オブジェクトの将来の機能強化されたアイデンティティ検査がその特定のバージョンに関わりなく対応するオブジェクトについて真をもたらすことを保証することと、最後に、クラス更新の後の最初の使用時にオブジェクトの以前の対応するバージョンから状態を移植することとを含む。

さらなる変形形態では、バイトコードの変換は、未初期化対応するオブジェクトのコンストラクションをトリガしたサロゲートオブジェクトにとって新規の状態の部分を初期化する自動的に生成されたバイトコード・メソッドをアプリケーション・クラスに挿入する。

さらなる変形形態では、バイトコードの変換は、別々のクラスローダを用いて更新されたクラスをロードすることであって、したがって、同一のクラスを表す複数の型は仮想マシンにロードされる、ロードすることと、言語によって定義される動的クラス型動作を実行するクラス内のバイトコードを、動的クラス検査動作のオペランドが同一の型名前空間を共有する対応するバージョンによって置換される動的クラス型検査を実行するバイトコードによって置換することとによって、同一のクラスの異なるバージョンを表す複数のクラスが共存できることを保証する。

さらなる変形形態では、バイトコードの変換は、メソッド呼出しのフォワーディングが、オブジェクトを、そのメンバへのすべてのアクセスを同一のクラスのより新しいバージョンの新しい対応するオブジェクトにフォワードするサロゲートに変換することを保証する。これは、まず、複数の対応するオブジェクトのいずれかを参照するクライアントが必ずそれ自体のクラスローダの到達可能な型から代入可能な型を有するオブジェクトを見るようにクラスのバイトコードを変換することによって達成される。これは、仮想マシン・バイトコード命令「ｉｎｓｔａｎｃｅｏｆ」を、「ｉｎｓｔａｎｃｅｏｆ」命令の右辺オペランドの型名前空間に従う特定の対応するオブジェクト表現に対する「ｉｎｓｔａｎｃｅｏｆ」検査を実行するバイトコードによって置換することと、その後、「ＣＨＥＣＫＣＡＳＴ」と同等の仮想マシン・バイトコード命令を、「ＣＨＥＣＫＣＡＳＴ」命令の右辺オペランドの型名前空間に従う特定の対応するオブジェクト表現に対して「ＣＨＥＣＫＣＡＳＴ」命令を実行するバイトコードによって置換することとを含み、最後に、クラスおよびクラスの前にロードされたバージョンのオブジェクトの、すべての将来の要求を対応する新しいクラスおよびオブジェクトにリダイレクトするサロゲートへのランタイム・スイッチングを実行し、新しい対応する表現から入手される可能な値は、サロゲートメンバの呼出し側の型名前空間に従うサロゲート表現によって置換され、リダイレクト工程を制御する挿入されるバイトコードは、サロゲートメンバの呼出し側によって与えられたパラメータを、リダイレクト工程の受取り側の型名前空間に従う対応する表現によって置換する。

さらなる変形形態では、バイトコードの変換は、サロゲートオブジェクトから対応する新しいオブジェクトへのメソッド呼出の仮想マシン表現のキャッシングによって、効率的なフォワーディングを保証する。

さらなる変形形態では、バイトコード変換は、アイデンティティについてオブジェクトを比較する仮想マシン・バイトコード命令を、同一の型名前空間に属する対応するオブジェクト・バージョンを使用してアイデンティティ検査を実行するバイトコードによって置換することによって、同一のクラスの異なるバージョンのライブ・オブジェクトの間の共有されるオブジェクト・アイデンティティを可能にする。

さらなる変形形態では、状態は、宣言されたフィールドあたり１つの生成されるＧＥＴメソッド内および宣言されたフィールドあたり１つの生成されるＳＥＴメソッド内のフィールドアクセスをラップする、アプリケーション・クラス内のバイトコードを生成することによって、同一のクラスの異なるバージョンからインスタンス化された複数の対応するオブジェクトの間で共有される。これによって、同一のオブジェクトを表す対応するオブジェクトのセット内のどのオブジェクト・バージョンが現在個々の共有されるフィールド値を保持するのかを記憶する。ＧＥＴメソッドは、サロゲートオブジェクト上で呼び出される時に、フィールド読取要求がサロゲートオブジェクトの最新の対応するバージョンにフォワードされることを保証し、最新の対応するオブジェクトから入手されるフィールド値は、サロゲートオブジェクトの型名前空間のフィールド値に変換され、これは、フィールド値が最新の対応するオブジェクト内に現在存在しない場合に、フィールド値が、対応するオブジェクト内で検索され、まず最新の対応するオブジェクトの型名前空間に変換することによって転送されることを保証し、それを行うことは、フィールド値が最新の対応するオブジェクト内に存在する場合に、フィールド値が、その間に更新がなかった場合に読み取られ、返されることを保証する、すなわち、生成されるフィールド・ＧＥＴメソッドを宣言するクラスの更新が、フィールド値が読み取られた後に発生する場合に、読取要求をサロゲートオブジェクトの最新の対応するバージョンにフォワードすることを保証し、最新の対応するオブジェクトから入手されるフィールド値は、今のサロゲートオブジェクトの型名前空間のフィールド値に変換される。同様に、ＳＥＴメソッドに挿入されるアルゴリズムは、サロゲートオブジェクト上で呼び出される時に、フィールド書込要求が、サロゲートオブジェクトの最新の対応するバージョンにフォワードすることを保証し、最新の対応するオブジェクトにフォワードされるフィールド値は、最新の対応するオブジェクトの型名前空間のフィールド値に変換され、これによって、フィールド値が最新の対応するオブジェクト内に現在存在しない場合に、フィールド値が書込まれ、フィールド値を前に保持した対応するオブジェクトが、見つけられ、前の状態をクリアするように要求されることを保証する。これは、フィールド値が最新の対応するオブジェクト内に存在する場合に、フィールド値が、その間に更新がなかった場合に書込まれ、生成されるフィールド・ＳＥＴメソッドを宣言するクラスの更新が、フィールド値が書込まれた後に発生する場合に、読取要求をサロゲートオブジェクトの最新の対応するバージョンにフォワードすることを保証し、最新の対応するオブジェクトにフォワードされるフィールド値は、最新の対応するオブジェクトの型名前空間のフィールド値に変換される。

さらなる変形形態では、バイトコードの変換は、前のバージョンから最新の対応するオブジェクトへの状態の転送が、対応するオブジェクトによって共有される一時的ロック機構の下で実行されることを保証する。

さらなる変形形態では、バイトコードの変換は、前の対応するバージョン内の状態のクリアが、対応するオブジェクトによって共有される一時的ロック機構の下で実行されることを保証する。

さらなる変形形態では、バイトコードの変換は、共通同期化オブジェクトを使用して、オブジェクトおよびそのサロゲートオブジェクトのグループへのスレッドに関する同期化されたアクセスを保証する。バイトコードの変換は、２つのステップすなわち、組込み同
期化アクセス修飾子を、メソッドの始めにＭＯＮＩＴＯＲＥＮＴＥＲ同等命令を挿入し、メソッドのすべての出口点にＭＯＮＩＴＯＲＥＸＩＴ同等命令を挿入するバイトコードによって置換することであって、それに基づいて同期化されるオブジェクトは、対応するオブジェクトおよびクラスについて同一である、置換することと、言語によって定義される同期化を実行する動作を、それに基づいて同期化されるオブジェクトを対応するオブジェクトについて同一である一意に識別可能なオブジェクトによって交換するバイトコードによって置換することとを含む。

さらなる変形形態では、バイトコードの変換は、アプリケーション・クラス内の各メソッドの始めに、サロゲートオブジェクトが使用可能なクラスの最も新しいバージョンからインスタンス化された対応するオブジェクトへフォワードすることを自動的に適合させることを保証するバイトコードを挿入することを含む。

さらなる変形形態では、バイトコードの変換は、オブジェクトへのアクセスが、ランタイムにメソッド本体の定義を置換することによってフォワードされることを保証する。
さらなる変形形態では、バイトコードの変換は、ライブ・オブジェクトが、スイッチ中にオブジェクト内でコードを現在実行しているスレッドを全くブロックせずにサロゲートオブジェクトに動的にスイッチされることを保証する。

さらなる変形形態では、バイトコードの変換は、サロゲートオブジェクトが、状態およびアイデンティティを共有し、オンデマンド・コンストラクトされる対応オブジェクトが、クラスの最も新しいバージョンからインスタンス化されることを保証する。

さらなる変形形態では、バイトコードの変換は、サロゲートオブジェクトが、クラスの最も新しいバージョンからインスタンス化されたオンデマンド・コンストラクトされた対応オブジェクトと状態を共有することを保証する。

さらなる変形形態では、バイトコードの変換は、サロゲートオブジェクトが、クラスの最も新しいバージョンからインスタンス化されたオンデマンド・コンストラクトされた対応オブジェクトとアイデンティティを共有することを保証する。

さらなる変形形態では、バイトコードの変換は、サロゲートオブジェクトのクライアントが、サロゲートオブジェクトのクラスの型への１つまたは複数の参照を保持するが、使用可能な最も新しい対応クラス・バージョンへのサロゲートメンバのフォワーディングを介してクラスの最も新しいバージョンのメソッド本体を使用することを保証する。

さらなる変形形態では、バイトコードの変換は、宣言するクラス内の関連する生成されたＧＥＴメソッドを呼び出すバイトコードによって直接にオブジェクト状態を読み取るためにすべてのリフレクション的機構を置換することを含む。

さらなる変形形態では、バイトコードの変換は、宣言するクラス内の関連する生成されたＳＥＴメソッドを呼び出すバイトコードによって直接にオブジェクト状態を書込むためにすべてのリフレクション的機構を置換することを含む。

さらなる変形形態では、バイトコードの変換は、クラスの以前のバージョンが仮想マシンに前にロードされている場合にクラス初期化メソッド内のオリジナル・コードが実行されないことを保証するために、クラス初期化メソッドの始めにバイトコードを挿入することを含む。

さらなる変形形態では、バイトコードの変換は、コンストラクションが宣言するコンス
トラクタのサブクラスのサロゲートインスタンスに対して発生する場合に、コンストラクタが、オリジナル・コードを実行せず、コンストラクタ呼出をクラスの最も新しいバージョンの対応するオブジェクトにリダイレクトしないことを保証するために、オブジェクト・コンストラクタの始めにバイトコードを挿入することを含む。

さらなる変形形態では、バイトコードの変換は、ファイナライゼーションがサロゲートオブジェクトに対して発生する場合に、ファイナライザが、オリジナル・コードを実行せず、ファイナライズ呼出を最も新しい対応するオブジェクトにリダイレクトしないことを保証するために、オブジェクト・ファイナライザの始めにバイトコードを挿入することを含む。

さらなる変形形態では、バイトコードの変換は、作成されるクローンが、クローンを作成されるオブジェクトのすべての対応するオブジェクトによって共有される状態と同等の状態を含むことを保証するバイトコードによって、言語によって定義されるクローン作成のオカレンスを置換することを含む。

さらなる変形形態では、バイトコードの変換は、最新の対応するオブジェクトによってシリアル化されるオブジェクトを置換するバイトコードによってオブジェクト・シリアル化のオカレンスを置換することを含み、挿入されるバイトコードは、共有されるオブジェクト状態が、シリアル化の処理を継続する前に最新の対応するオブジェクトに転送されることを保証する。

さらなる変形形態では、バイトコードの変換は、まず、置換される配列読取動作によって入手される値を呼出し側クラスの型名前空間の値に変換することと、その後、置換される配列書込動作で使用される値を最新の対応する配列オブジェクト型名前空間の値に変換することとによって、配列にアクセスする命令を、アクセス要求を最新の対応する配列オブジェクトにリダイレクトするバイトコードによって置換することを含む。

さらなる変形形態では、バイトコードの変換は、動的にロードされたクラスの新しいバージョンの型情報が、クラスの前にロードされたバージョンの継承階層とは異なる継承階層を示すことを可能にする。

さらなる変形形態では、バイトコードの変換は、動的にロードされたクラスの新しいバージョンの型情報が、クラスの前にロードされたバージョンのインターフェースとは異なるインターフェースを示すことを可能にする。

さらなる変形形態では、バイトコードの変換は、動的にロードされたクラスの新しいバージョンのメソッド宣言が、クラスの前にロードされたバージョンのメソッド宣言とは異なることを可能にする。

さらなる変形形態では、バイトコードの変換は、動的にロードされたクラスの新しいバージョンのフィールド宣言が、クラスの前にロードされたバージョンのフィールド宣言とは異なることを可能にする。

実施形態による他の方法、システム、および／またはコンピュータ・プログラム製品は、次の図面および詳細な説明を再検討する時に当業者に明白になるであろう。すべてのそのような追加の方法、コンピュータ・プログラム製品、および／またはシステムが、この説明に含まれ、本発明の範囲に含まれ、添付の特許請求の範囲によって保護されることが、意図されている。

上で短く説明した本発明のより特定の説明を、添付図面に示された本発明の特定の実施形態を参照することによって伝える。これらの図面は、本発明の１つまたは複数の通常の実施形態を示すのみであり、したがって、本発明の範囲を限定するものと解釈してはならない。次の図面に関して、同様の符号は、図面の組全体を通じて同一の要素を表す。

本発明を実践できる、デスクトップ機、ワークステーション、サーバ、メインフレーム・コンピュータ、組込みコンピューティング・デバイスなどとすることができる包括的なコンピューティング・デバイスを示すブロック図。システム内のモジュールがその依存性に従ってリンクされる、例のシステム・スナップショット。インプレース・プロキシフィケーション（Ｉｎ−ＰｌａｃｅＰｒｏｘｉｆｉｃａｔｉｏｎ）技法の概念的概要を示す図。用いられるコンポーネントの成功の更新の後のモジュール・バインディングの例を示す図。更新されたモジュール依存性を用いてリンクするためにクライアントの動的更新を実行した後のモジュール・バインディングの例を示す図。本発明のブートストラッピング・フェーズを実行するために行われる高水準ステップを示すフローを示す図。コンピュータ・プログラム内のアクティブに動作しているモジュールの動的更新を実行するために行われる高水準ステップを示すフローを示す図。仮想マシンにロードされる直前にクラスのバイトコードを変換するために行われる高水準ステップを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。本発明の実施態様でクラスに対して行われる詳細なバイトコード変換ならびに変更されたバイトコードが本発明を使用するシステムの実行中にどのように振る舞うのかを示すフローを示す図。

上で示したように、本発明は、アクティブに動作しているデスクトップ機、サーバ、メインフレーム、または組込みコンピューティング・デバイス上の仮想マシン内で実行される、静的に型付けされたクラスベースのオブジェクト指向ソフトウェアのノンブロッキング動的更新のシステム、方法、およびプログラム製品を提供する。具体的には、本発明は、クラス定義のバイトコードを動的に更新することを可能にする、クラス定義のバイトコードに対する変換を実行することによって、動的更新を提供する。クラスの更新は、モジュールの粒度レベルで行われる。前の動作しているバージョンとのモジュールＡＰＩ互換性を破壊しない変更は、モジュール自体を超える影響を有しない。バイナリ互換性ルールに違反する変更［２］は、すべての動作する依存物に関する新しいＡＰＩ互換モジュール・バージョンをも含むように更新セットを拡張する。更新中の変更は、動作しているソフトウェアの異なるバージョンでの更新されるクラス定義およびその共存する依存物の型安全を保証しながら、メソッド本体の変更、メソッドの追加／除去、コンストラクタの追加／除去、フィールドの追加／除去、クラスの追加／除去、インターフェースの変更、スーパークラスの置換、実装されるインターフェースの追加／除去、および透過的オブジェクト状態移植（ｔｒａｎｓｐａｒｅｎｔｏｂｊｅｃｔｓｔａｔｅｍｉｇｒａｔｉｏｎ）を含むことができる。

一般に、この手法は、クラスのレベルでのコードと状態との両方の予期されない動的なソフトウェア進化をサポートする。ＡＰＩ進化に関する一般に受け入れられたガイドラインに基づいて、本発明の手法は、システムを停止する前に状態をシリアル化し、再展開されたシステムを再始動した後に逆シリアル化する方式から派生したステートフル更新の同一のセットを可能にする。

本明細書で使用される時に、用語「モジュール」または「ソフトウェア・モジュール」は、長期記憶媒体（ディスク・ドライブ、ＣＤ−ＲＯＭ、テープなどであるがこれらに限定されない）から独立にロード可能な１つのコンピュータ・コードを意味する。本発明の文脈では、「モジュール」は、バイトコード表現の形のクラス定義および補足のアプリケーション・リソースの識別可能なコレクションを暗示する。さらに、モジュールは、外部の世界すなわち依存モジュールがそこからパブリック・メンバに到達できる、明確に定義されたＡＰＩを有する。モジュールは、他のコンポーネントに対する依存性を明示的に宣言する。

本明細書で使用される時に、用語「変更セット」は、バイナリ非互換性を避けるために一緒に原子的に再定義されなければならないクラス定義のセットを意味する。
本明細書で使用される時に、用語「型名前空間」は、オブジェクト、クラス、またはモジュールのうちの１つである、特定のコンテキストから到達可能な型を意味する。到達可能な型は、所与のコンテキスト内から直接にロードできる型によって与えられる。

図１は、本発明を実践できる、ワークステーションなどのコンピューティング・デバイスのブロック図である。図１の環境は、関連する周辺デバイスを含む、パーソナル・コンピュータ、ワークステーション、企業メインフレーム・コンピュータ、サーバ、ラップトップ機、ハンドヘルド・コンピュータ、情報機器など、単一の代表的なコンピューティング・デバイス１００を含む。コンピューティング・デバイス１００は、マイクロプロセッサ１０２または同等の処理能力と、既知の技法に従ってマイクロプロセッサ１０２とコンピューティング・デバイス１００のコンポーネントとの間で接続し、その間の通信を可能にするバス１０４とを含む。いくつかのコンピューティング・デバイスで、その中に組み込まれた複数のプロセッサがある場合があることに留意されたい。

マイクロプロセッサ１０２は、バス１０４を介してストレージ１０６と通信する。ランダム・アクセス・メモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、フラッシュ・メモリ、その他などのメモリ１０８は、直接にアクセス可能であるが、ハード・ディスクなどの二次記憶デバイス１１０およびフロッピー（登録商標）・ディスケット・ドライブ、ＣＤ
ＲＯＭドライブ、テープ・ストレージ、その他などのリムーバブル・ストレージ・デバイス１１２は、当技術分野で既知であり、習慣的であるように、追加のインターフェース・ハードウェアおよびソフトウェアを用いてアクセス可能である。リムーバブル・ストレージ・デバイス１１２は、ディスケット、ＣＤ、テープ・リールもしくはテープ・カートリッジ、ソリッド・ステート・ストレージ、その他など、コンピュータ使用可能データを保持し、コンピュータ使用可能媒体の形である、適当なタイプのリムーバブル媒体１１４を関連付けられる。コンピューティング・デバイス１００が、複数のメモリ（たとえば、ＲＡＭおよびＲＯＭ）、二次記憶デバイス、およびリムーバブル・ストレージ・デバイス（たとえば、フロッピー（登録商標）・ドライブおよびＣＤＲＯＭドライブ）を有することができることに留意されたい。

コンピューティング・デバイス１００は、通常、キーボード１１８、マウスまたは他のポインティング・デバイス１２０、ディスプレイ１２２（ＣＲＴモニタ、ＬＣＤスクリーン、その他など）、プリンタ１２４、または接触感知スクリーン、ディジタル化された入力パッドその他などの任意の他のユーザ・インターフェース・デバイスなどの１つまたは複数のインターフェース・デバイスにバス１０４を介してマイクロプロセッサ１０２を接続するユーザ・インターフェース・アダプタ１１６を含む。コンピューティング・デバイス１００が、ユーザ・インターフェース・デバイスとの必要な接続を行うために複数のユーザ・インターフェース・アダプタを使用することができることに留意されたい。

コンピューティング・デバイス１００は、電話モデム、ケーブル・モデム、無線モデム、ＩＳＤＮアダプタ、ＤＬＳアダプタ、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ、または他の通信チャネルなどの通信アダプタ１２６を介して他のコンピューティング・デバイス、コンピュータ、ワークステーションなどまたはそのネットワークと通信することもできる。これは、コンピューティング・デバイスに、ネットワーク１２８（ＬＡＮ、広域ネットワーク（ＷＡＮ）、インターネットなど）、他のネットワークまたはコンピュータにアクセスするのに使用できる電話回線１３０、セル電話網などの無線ネットワーク１３２、および他の通信機構ヘの直接アクセスを与える。コンピューティング・デバイス１００が、必要な通信接続を行うために複数の通信アダプタ（たとえば、電話モデム・カードおよびセルラ・ディジタル・パケット・データ（ＣＤＰＤ））を使用することが
できることに留意されたい。コンピューティング・デバイス１００を、ＬＡＮまたはＷＡＮ内の他のコンピューティング・デバイスに関連付けることができ、あるいは、コンピューティング・デバイスを、別のコンピュータとのクライアント／サーバ配置内のクライアントまたはサーバとすることなどができる。これらの構成のすべてならびに適当な通信ハードウェアおよび通信ソフトウェアが、当技術分野で既知である。

コンピューティング・デバイス１００は、オペレーティング・システム・ソフトウェア１３４、ミドルウェア・ソフトウェア１３６、およびアプリケーション・ソフトウェア１３８など、ソフトウェアを動作させる機能を提供する。そのようなソフトウェアが、タスクを実行し、このコンピューティング・デバイスおよび他のコンピューティング・デバイス上のさまざまなソフトウェア・コンポーネントと通信できることに留意されたい。

当業者によって理解されるように、本明細書で説明されるものなどのコンピュータ・プログラム（オペレーティング・システム・ソフトウェア１３４、ミドルウェア・ソフトウェア１３６、および／またはアプリケーション・ソフトウェア１３８を含む）は、通常、プログラム・コードを含むか格納する１つまたは複数のコンピュータ使用可能媒体を有するコンピュータ・プログラム製品の一部として配布される。したがって、本明細書で使用される時に、「媒体」または「コンピュータ使用可能媒体」は、コンピュータ・メモリ（ＲＡＭおよび／またはＲＯＭ）、ディスケット、テープ、コンパクト・ディスク、集積回路、プログラマブル論理アレイ（ＰＬＡ）、通信回路を介するリモート伝送、セルラ・ネットワークなどの無線ネットワークを介するリモート伝送、または適当なアダプタ・インターフェースを有するもしくは有しないコンピュータによって使用可能な任意の他の媒体を含むことができる。コンピュータ使用可能媒体の例が、ＣＤＲｏｍ、ディスケット、ハード・ドライブ、および類似物などの触知できる物理媒体ならびにプログラムが電子的に配布される時の、有線または無線のいずれを介するものであれ、搬送波信号などの他の触知できない物理媒体を含むが、これに限定されないことに留意されたい。また、米国カリフォルニア州マウンテン・ビューのＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ社から入手可能なＪＡＶＡ（登録商標）技術による「サーブレット」または「アプレット」がコンピュータ・プログラム製品と考えられることに留意されたい。

使用可能にする命令を、ディスケットまたはテープ「に書込み」、集積回路またはＰＬＡ「内に格納し」、通信回路または無線ネットワーク「を介して搬送する」ことができるが、本明細書で説明される本発明において、コンピュータ使用可能媒体が、命令を「担持する」と呼ばれ、あるいは、命令（またはソフトウェア）が、媒体「上に」あると呼ばれることを了解されたい。したがって、媒体「上で実施される」ソフトウェアまたは命令は、命令またはソフトウェアをコンピュータ使用可能媒体に関連付けることができる上記およびすべての同等の形を含むことが意図されている。

単純さのために、用語「コンピュータ・プログラム製品」は、１つのコンピュータ・システム（または複数の協力するシステム）が上で識別された発明に従って動作することを可能にするために任意の形のソフトウェアまたは命令を担持しまたはその上で実施された、上で定義されたコンピュータ使用可能媒体を指すのに使用される。

同様に、本発明がその上で実施されるコンピュータ・ハードウェアが、一緒に動作する、実質的に独立に動作する、またはネットワークを介して分散された１つまたは複数のプロセッサを含み、さらに、本発明を実行するのに必要な命令および計算を格納するメモリを含むことを了解されたい。

当業者は、本発明によるシステムを、当業者に既知のさまざまな異なる形で作成できることを認めるであろう。たとえば、図１に示された汎用コンピューティング・デバイスを
、本明細書が後で説明するようにコンピューティング・デバイスが機能するようにするために、適当なソフトウェアを用いて構成することができる。さらに、ディスクリート電子コンポーネントを使用して、その機能のすべてまたは一部を実施するシステムを作成することができる。最後に、適当なソフトウェアを実行する複数のコンピューティング・デバイスまたはディスクリート電子コンポーネントの組合せを、類似する形で使用できることに留意されたい。本質的に、ハードウェアは、本発明を構成する機能要素を実行するように構成される（ソフトウェアによる、カスタム設計されるなどのいずれであれ）。

図２を参照すると、複数のコンポーネント２０６から作られる例のシステム・セットアップを示す図。当初に、２０２によって示されるように、時刻ｔ＝０のシステムは、２０８内のクラスが２０６内のクラスを使用できるという事実を反映する、システム内のコンポーネントの通常のバインディングを示す。ランタイムに、これらのバインディングは、動作するシステム内のクラスローダによって維持される。本発明は、仮想マシンによって実行される現代のプログラミング言語での通常のクラスローダ・セットアップの知識に基づく。通常、すべてのモジュールは、そのモジュールによって明示的に宣言されたクラスおよびリソースをロードする責任だけを負う別個のクラスローダに割り当てられる。モジュール依存性２０４で宣言されたクラスのクラスロードは、関連するクラスローダを見つけることからなり、そのクラスローダにクラスロードを委譲する。これの広く適用されている方式は、各クラスの一意表現をもたらし、この表現は、異なるモジュールの間の型共有を単純にする。しかし、モジュールによって定義されたクラスの動的置換の文脈では、モジュールはそのモジュール依存性の新しいバージョンで宣言されたクラスにどのようにして到達するのかという疑問が生じる。クラス再ロードの組込みサポートがなければ、新しいクラスローダを、置換されるコンポーネント２１２のそれぞれに割り当てなければならない。仮想マシンの観点からは、これによって、別個の型の新しいセットが作成される。

ここで２１０を参照すると、置換されたモジュールとの新しいクラスローダの関連付けは、クライアント・モジュールが更新されたモジュールの以前のバージョンに静的にバインドされる時には問題がある。明瞭にするために、２１６によって宣言されたクラスが、２１４によって宣言されたクラスＡを使用する場合に、２１４の更新は、新しい型Ａを作成し、この型Ａは、オリジナルの型Ａと代入互換ではない。したがって、２１６に関連付けするクラスローダにモジュール２１２に委譲させるためにクラスローディング委譲方式を動的に変更する試みは、成功しない。一例として、クライアント・クラスが既に新しい型を使用するモジュール２１６内のクラスにリンクされているケースは、クラスキャスト例外およびリンケージ・エラーをもたらす。それでも本発明は、図１に示されたセットアップからの問題を解決する動的更新フレームワークを提供する。さらに、本発明は、バージョン・バリアから発するすべての型関連問題［１］を成功して処理し、バージョン・バリアにまたがるモジュール通信がたとえばＪＡＶＡ（登録商標）プログラミング言語の現在のセマンティクス内でシームレスに発生し得ることを伴う。

技術的説明の理解を容易にするために、次の表記が、本明細書の残り全体に適用される。ターゲット・コンポーネントは、動作するコンポーネントの最新バージョンを表す。コンポーネントの連続する更新では、ターゲット以外のコンポーネントのすべてを指すのに、用語以前のコンポーネントを使用する。更新時に、それぞれ更新の前および更新の後のターゲット・コンポーネントに言及する時に、用語現在のターゲットおよび新しいターゲットを使用する。用語中間コンポーネントは、ターゲット・コンポーネントとある以前のコンポーネントとの間の特定のコンポーネント・バージョンを指すのに使用される。一例として、コンポーネントＡの４つのバージョン、Ａ１、Ａ２、Ａ３、およびＡ４を検討されたい。この場合には、Ａ４がターゲットであり、他のすべては、以前のコンポーネントである。コンポーネントＡ２およびＡ３は、Ａ１に関する中間であり、Ａ３は、Ａ２に関
する中間である。さらに、コンポーネントは、（所与の説明に適当である場合に）２１４および２１６によって既に使用されている形Ａ（ｎ）で表される更新の時刻に関連する。タイミングは、更新の間の時間差が変化する場合であっても、必ず等距離の実数の線形シーケンスとして表される。さらに、同一の当初に展開されたコンポーネントの２つのバージョンを表す２つのコンポーネントは、対応コンポーネントとして言及される。これらの時間関連用語に加えて、コンポーネント・プラットフォーム自体の上に構築されるすべてのユーザ固有コンポーネントは、更新可能コンポーネントと言われる。更新可能システムのクラスレベルでは、更新可能コンポーネント内で宣言されたクラスを記述するのに、用語更新可能クラスを使用する。

本発明によって開示される動的更新手法の基本的概念は、インプレース・プロキシフィケーション技法である。これは、以前のコンポーネントとターゲットとの間の接着剤（ｇｌｕｅ）である。インプレース・プロキシフィケーション機構は、２つのコンポーネント・バージョンの間のインダイレクションを導入するという問題に対する新規の解決策を提供する。既存のインダイレクション機構が、古いコンポーネントの回りで古いバージョンから新しいバージョンへ呼出しをリダイレクトするためのコードを置く包括的ラッパー概念［４］の変形形態を採用する場合に、インプレース・プロキシフィケーション機構は、古いコンポーネントのコード内でより新しいバージョンへのインダイレクションのレベルを提供するのに、インプレース生成されたコードを使用する。したがって、リダイレクションは、外側から内側へ移動され、これは、包括的ラッパー概念に基づく既存手法が直面する複数の問題を解決する。主なアイデアは、コンポーネントのコードの内部でプロキシ挙動を可能にするためにコンポーネントレベル・スイッチを生成することである。

ここで、図３を参照すると、３０４に入ってくる要求が３０８によって示されるコンポーネントＡＰＩによってどのようにインターセプトされ、３１０にフォワードされるのかの図。このフォワーディングは、３１０内の新しい別個の名前空間の作成に起因して生じるバージョン・バリアをまたぐので、直接通信を介して発生することができない。その理由から、以前のコンポーネントからターゲットへ通信するのにリフレクション的技法を使用する。しかし、リフレクションは、フォワードされるメソッド呼出の仮引数型と戻り型が以前のコンポーネントによって知られている型と非互換である場合があるので、当面の問題に対する完全な解決策を提供しない。一般に、下で説明する前提条件が、成功のフォワーディングのために、更新可能なクラス内で宣言されるメソッドに適用される。

すべての更新可能なクラスは、ターゲット・クラスについて知る必要がある。したがって、本発明を実施する現在の例のシステムは、すべてのアプリケーション・クラスがロードされる直前に、そのクラス内で型ｊａｖａ．ｌａｎｇ．Ｃｌａｓｓのスタティック・フィールドを生成する。このフィールドは、宣言するコンポーネントのすべての更新の後の最初の使用時にセットされる。

図４を参照すると、コンポーネント更新が４０２に、およびその後に４０４に適用された後の例のシステム・スナップショットを示すこと。このケースで正しいＴａｒｇｅｔメソッドを見つけることは、更新可能な仮引数型が、必ずしも呼び出すメソッド内の型と型互換ではないので、問題がある。したがって、型がＴａｒｇｅｔメソッドの仮型と一致するようにするために、正しい型をルックアップしなければならない。ここで、コンポーネントＤで宣言されたあるメソッド、たとえばｍが、仮引数型としてコンポーネントＥ型クラスを使用する場合に、この型は、ターゲット・コンポーネントＥすなわち４０６の名前空間に従わない。したがって、４０２の名前空間内の型が、このメソッドをルックアップするのに使用されなければならない。起点に関わりなく正しい型バージョンを入手する唯一の穏当なオプションは、既知のクラスローダのみに委譲するターゲット・クラスの関連するクラスローダを尋ねることである。メソッド呼出が生じるたびにクラスのクラスロー
ダを尋ねることは、許容できないオーバーヘッドを導入する。それは、各メソッド呼出内の更新可能な仮引数型ごとにクラスローディング・アルゴリズムを実行することを強制する。これは、本発明が、既にルックアップされたメソッドを、宣言するクラス内で直接にキャッシングする理由である。さらに、本発明は、更新可能なコンポーネントごとに、既にロードされたクラスのキャッシュを維持する。

スタティック・メソッドの場合に、ターゲット・クラスおよびメソッドは、メソッド・フォワーディングをサポートするのに十分である。しかし、インスタンスメソッド呼出では、メソッドは、呼出がフォワードされなければならないオブジェクトを判定しなければならない。このターゲット・オブジェクトへの参照は、特殊なマーカ型のコードによって生成されたインスタンス・フィールドによって、更新可能クラスのすべてのインスタンス内に保持される。バイトコード変換によって、マーカ型は、すべての更新可能クラスによって実装される。我々は、用語ターゲット情報を用いて、上で述べたターゲットのすべてすなわちターゲット・コンポーネント、クラス、メソッド、およびオブジェクトについて示す。しかし、この用語は、スタティック・メソッドのコンテキストでターゲット情報がターゲット・コンポーネント、クラス、およびメソッドだけからなると言う意味で、文脈依存である。

Ｔａｒｇｅｔメソッドをフォワードすべき正しいパラメータを見つけることは、正しい場所にあるターゲット・オブジェクトを判定することと同一である。パラメータは、バージョンに関わりなくシステム内の同一のエンティティを表さなければならない。したがって、Ｔａｒｇｅｔメソッドに配送される実際のパラメータを、どの型がターゲット・クラスによって理解されるのかに従って、インプレース・プロキシとターゲット・オブジェクトとの組合せとすることができる。

ここで、図５を参照すると、５０２の動的更新の後で５０４の動的更新の後のモジュール・バインディングの例のスナップショットを示すこと。メソッド本体の進化に加えて、本発明は、クラス・インターフェースおよび型階層の動的進化をも可能にする。ＡＰＩクラスの型に影響する変更は、クライアントの更新の時にクライアント・コンポーネントに直接に可視になる。これは、クライアント・コンポーネントの新しいバージョン５０８に関連するクラスローダに、そのクラスローディングをそのコンポーネント依存性のターゲット・コンポーネント５０６に直接に委譲させることによって達成される。

図５に示されたセットアップは、総合性能に関する本発明のもう１つの非常に重要なプロパティをも明らかにする。明らかに、前述の前提条件に従うＡＰＩメソッドのフォワーディングは、比較的大きい性能ペナルティを提示する。これは、主に導入されるリフレクション的挙動によって引き起こされる。しかし、クライアントが更新されたコンポーネントＡＰＩに対してコンパイルされ、その後に新しいターゲット・コンポーネントに動的にバインドされた後には、これらの呼出は、やはり、Ｔａｒｇｅｔメソッドに対して直接に発生する。したがって、メソッド呼出速度は、更新の前の速度に戻る。

前のセクションのインプレース・プロキシフィケーション技法は、クラスローダ境界にまたがる通信を可能にするが、それ自体ではプログラム一貫性を維持しない。上で説明したように、正しい実行フローをサポートするために処理される必要がある、フォワーディングに関わる型関連の問題がある。フレームワークは、特定のターゲット・コンポーネント内のすべてのライブ・オブジェクトが、すべての対応する以前のコンポーネント内で０個または１個のいずれかのオブジェクトによって表されることを保証しなければならない。０個は、対応するオブジェクトがオンデマンドで作成されるのみであるからである。たとえば、ターゲット・コンポーネント内の普通のコンストラクタの実行は、その点での以前のバージョンの他のオブジェクトのどれの作成をもトリガしない。ターゲット・オブジ
ェクトがインプレース・プロキシ法を介して返される場合に限って、対応するオブジェクトがコンストラクトされ、その場所に返される。この対応するオブジェクトは、すべての将来のメソッド呼出を、そのオブジェクトがそれから作成されたターゲット・オブジェクトにフォワードするように事前に構成される。正しいオブジェクトが必ず返されることを保証するために、本発明は、その中でオブジェクトがそのライブ表現に従って対にされるレジストリを提供する。本発明は、コレスポンダンス・ハンドリング（ＣｏｒｒｅｓｐｏｎｄｅｎｃｅＨａｎｄｌｉｎｇ）と命名された技法によって、オブジェクトの複数の表現の間の対応を処理する。

更新時に、更新されるコンポーネントのすべてのクラスおよびオブジェクトの挙動は、更新されるコンポーネントのランタイム・スイッチを変更することによって、インプレース・プロキシになる。最初の使用時に、インジェクトされたインプレース・プロキシ・コードは、新しいターゲット・コンポーネントによって宣言されたクラス定義からの対応する未初期化オブジェクトのコンストラクションをトリガし、これらの対を適当な対応するマップに追加する。さらに、これは、新しいターゲット・コンポーネントの対応する表現をポイントするようにセットされたターゲット・オブジェクトおよびクラス・フィールドの初期化をトリガする。この点で、未初期化オブジェクトは、以前のオブジェクトの状態が新しいターゲット・オブジェクトに移植されなかったことを示す。状態移植は、個々のフィールドの最初の使用時に、レイジイに発生する。

上で述べたシナリオは、対応するオブジェクトが、動作するシステム内に既に存在するオブジェクトについてどのように作成され、処理されるのかを説明する。クライアントは、更新が行われた後に、以前のコンポーネントのオブジェクトを作成し続けることができる。この場合に、コンストラクタは、メソッド呼出と同様に、ターゲット・コンポーネント内の対応するコンストラクタにフォワードする。これは、原理的には２つのコンストラクタを実行するが、ユーザ記述のコンストラクタ本体は、ターゲット・コンストラクタ内でのみ動作する。さらに、そのようなオブジェクト・コンストラクションから生じる２つの対応するオブジェクトは、上述のコレスポンダンス・ハンドリングに従ってマッピングされる。

もう１つの重要な問題は、コンポーネント境界にまたがるすべてのメソッド呼出が、インプレース・プロキシを介するインダイレクションの１つのレベルだけを通過することを保証することである。あるコンポーネントが２回更新され、そのオブジェクトがインプレース・プロキシフィケーション工程を２回通過すると仮定する。すると、第１バージョンのクライアントがメソッドを呼び出す時に、その呼出は、ターゲット・コンポーネント内のオブジェクトに達するために中間コンポーネントを通過する。１レベルのインダイレクションを保証するために、インプレース・プロキシ・クラスは、その最後の既知のターゲット・コンポーネントへの静的フォワード参照を維持する。最終的に、このターゲットは、更新され、そのランタイム・コンポーネント・スイッチは、その宣言されたクラス内でフォワーディングを可能にするために変更される。これは、最初のコンポーネントによって保持されるフォワード参照に、中間コンポーネントをポイントさせるが、これは望ましくない。したがって、ターゲット・コンポーネントの現在の知識の単純な検査は、新しいターゲット・コンポーネントがインストール済みであることを示し、フォワード参照は、フォワーディングの直前にアプリケーション・スレッド自体によって更新される。さらに、このメタ情報更新は、コレスポンダンス・ハンドリングにも反映される。

状態移植は、動的更新の中心である。一般に、状態移植技法は、１）透過的状態移植および２）プログラマによって影響される状態移植というカテゴリのうちの１つに含まれる。本発明は、透過的状態移植に基づく。我々の意見では、透過的状態移植は、明示的に記述されたバージョン・アダプタまたは状態転送関数を必要としないので、プログラマによ
って影響される状態移植より好ましい。バージョン・アダプタおよび状態転送関数の記述は、多くのタイプの更新に不必要な、労力集中型のタスクである。本発明は、以前のコンポーネントのフィールド値を自動的かつ透過的にターゲット・コンポーネントに転送する機構を使用する。

この機構は、状態移植をオンデマンドでレイジイに実行する。状態は、フィールドの最初のアクセス時にアプリケーション・スレッドによって以前のコンポーネントからターゲット・コンポーネントに移植される。この手法は、特殊なロックが不要なので、標準的な同期化セマンティクスを保存する。したがって、スレッドが一時的に停止されないので、デッドロックは問題にならない。

更新の後に、すべての入ってくる要求は、新しいターゲット・コンポーネント内で終り、最終的に、状態を以前のバージョンから転送させる。これを達成するために、本手法は、フィールド読取およびフィールド書込を処理する特殊なアクセス・メソッドを作成する。基本的なアイデアは、状態が存在するかどうかを反映するブール値をすべてのフィールドについて維持することである。クラス・ローディグおよび標準コンストラクタ呼出の際に、これらのフィールドには偽がセットされる（デフォルト初期化）。この場合に、偽は、いずれかの状態が最初に初期バージョンにあるので、状態が存在することを反映する。新しいターゲット・クラスおよび以前のオブジェクトからコンストラクトされるオブジェクトでは、これらのフィールドに、明示的に真がセットされる。これによって、このフィールドは、状態が存在しないことを、関連するアクセス・メソッドに示す。状態を現在のターゲット・クラスおよびオブジェクトに転送するために、挿入されるアクセス・メソッドは、関連するブール値に偽の値を保持するものを見つけるまで、以前の対応するバージョンをルックアップする。見つけた後に、そのフィールドは、以前のバージョンからターゲットに転送され、ブール値には、それぞれ真および偽がセットされる。この工程は、更新不能型だけが参照によってコピー可能なので、見つかった値の型にも依存する。更新可能型である場合には、コレスポンダンス・ハンドリングは、対応するオブジェクトを突き止めるか作成する。

本発明の重要なプロパティは、クラスでの新しいフィールドの導入をサポートすることである。移植されるオブジェクトの関連するブール値にどのようにして明示的に真がセットされるのかを説明した。これは、新しいフィールド値が当初に実際にターゲット・クラスおよびオブジェクトに格納されるという事実を反映するものではない。その理由から、特殊なゲッター・メソッドが初めて呼び出された後に、そのメソッドは、以前のバージョン内のフィールドを突き止めることを試行することになる。そのメソッドは、この特定のフィールドが追加されたことを発見し、したがって、値が既に存在するかのようにブール・フィールドを訂正する。しかし、新しいフィールドに意味のある値を自動的に代入することはできない。可能なヌルポインタ例外または予期されないデフォルト・プリミティブ値を回避するために、本発明は、プログラマ自身によってクラスレベルで明示的に記述されるフィールド代入の初期化をサポートする。プログラマによって記述されたすべてのクラスレベル代入について、本発明は、すべての以前のオブジェクトから作成される新しいオブジェクトが、プログラマによって代入された値を保持することを保証する。これは、後で詳細に説明するバイトコード分析を介して達成される。

本手法がバイナリ互換変更をどのようにして処理するのかを説明したので、このセクションでは、本手法がバイナリ非互換変更をどのようにして処理するのかを説明する。本手法は、合同でバイナリ互換コンポーネントを構成する更新セットを必要とするオフライン更新方式を模倣する。したがって、この手法は、前のバージョンとのバイナリ互換性を破壊する、コンポーネントＡＰＩの更新をもサポートする。我々は、例として、既存メソッドにパラメータを追加する、周知の単純な例を使用する。
ｐｕｂｌｉｃｖｏｉｄｃｒｅａｔｅＩｎｓｔａｎｃｅ（Ｓｔｒｉｎｇｎａｍｅ，ｉｎｔＩＤ）｛・・・｝
ｐｕｂｌｉｃｖｏｉｄｃｒｅａｔｅＩｎｓｔａｎｃｅ（Ｓｔｒｉｎｇｎａｍｅ，ｉｎｔＩＤ，Ｓｔｒｉｎｇｄｅｓｃｒｉｐｔｉｏｎ）｛・・・｝
ここで、上のメソッドを含むコンポーネントの更新を試みることは、壊されたクライアントをもたらす可能性がある。したがって、静的依存性ベリファイヤが、更新を実行する前に、そのような非互換コンポーネント変更を突き止める。与えられた例では、ベリファイヤは、除去されたＡＰＩメソッドという変更を見つける。その後、ベリファイヤは、クライアント・コンポーネントに対する更新を突き止めることを試み、クライアント・コンポーネントの更新されたセットとの互換性を検査する。ベリファイヤは、非互換性を見つけない場合に、コンポーネントの新しいセットの更新を実行する。そうではない場合には、ベリファイヤは、更新を破棄する。したがって、バイナリ非互換変更の導入は、クライアント・コンポーネントに要件を課すことによって、動作中のシステムの更新能力に影響する。これは、独立に開発されたコンポーネントにおける周知の制限である。コンポーネントのオリジナル・バージョンによってセットアップされた契約を破るために支払うべき代償は、この手法が、関わるプログラマがクライアントの更新にも投資する前にすべての動作中のシステムでの更新を適用できないことである。ＡＰＩ設計者は、この代償を十分に知っている。通常、ＡＰＩ設計者は、バイナリ互換性を維持するために処置を講じる。一例は、ＡＰＩ設計者が、リスティング３でメソッドをオーバーロードし、したがって複数のソースコード反復について古いＡＰＩを維持することである。我々は、この制限が、まさにオフライン更新方式から得られるものであり、更新がどのようにして実行されるのかに無関係であることを強調するものである。バイナリ非互換変更の更新を可能にするよりスマートな機構を導入するすべての試みは、プログラマ透過性を壊す。

図６を参照すると、当初にシステム・スタートアップの前に６０２、動的更新対応プログラム・インスタンスをスタートアップするのに必要なステップの高水準表現を示す流れ図。ステップ６０４では、本発明のユーザは、コンピュータ・プログラムを実行するためのアクションを行い、ここで、本発明が実行されなければならない。ユーザは、ブートストラッピング変換ツールを表す特殊なエージェント・ライブラリを指定する。このツールは、ブートストラップ・クラスすなわち、エージェント・ライブラリをスタートアップするために仮想マシンによって使用されるクラスのバイトコードを変換する責任を負う。この点で、実行制御は、エージェント・ライブラリにハンド・オーバされる６０６。特殊なエージェント・ライブラリは、ステップ６０８で、すべてのロードされるクラスについて仮想マシンに照会することによって、ブートストラップ・クラスのセットを判定する。すべてのロードされるブートストラップ・クラスへの参照を入手し終えて、見つかったブートストラップ・クラスのバイトコードの変換工程が、ステップ９００で行われ、ステップ９００の詳細な説明は、図９．１を参照しながら与えられる。変換工程の後に、特殊なエージェント・ライブラリは、６１０で新しいコンピュータ・プログラム・インスタンスをｓｐａｗｎし、このインスタンスは、本発明のランタイム部分を実行するのに必要なバイトコード変換を実行するのに必要な異なる特殊な変換エージェントに加えて、変換されたブートストラップ・クラスを含む。

図７を参照すると、アクティブに動作しているシステム内のモジュールを動的に更新するために行われるステップを示す流れ図。当初に、７０２で、イベントのフローが、現在動作しているシステム内のモジュールを更新する要求によってトリガされる。動的更新要求の起点は、本発明の特定の実施形態に応じて、本発明と通信できる何にでもすることができる。動的更新工程を開始し終えて、現在動作しているモジュールの最新バージョンを、ステップ７０４で突き止める。その後、動的更新工程は、本発明の特定の実施形態で機能強化されたコンポーネント・システム内に新しいモジュールをインストールする７０６。その後、新たに作成されたコンポーネントが、７０８で、同様に新たに作成された仮想
モジュールに関連付けられる。そのような仮想モジュールは、コンポーネント・システムにインストールされた実際のコンポーネントの特定のバージョンを表す。それらの仮想モジュールは、対応するオブジェクトおよびクラスをオンデマンドでそれ自体の一意の型名前空間から取り出す組込み機構を有するので、対応するモジュール・バージョンの間の糊として機能する。例示すると、３１２のようなインプレース・プロキシ・メソッド呼出では、メソッドのパラメータが３０４の型名前空間に属する場合に、そのパラメータを３１０の対応する型名前空間に変換しなければならない。ここで、３１２の委譲が発生し得る前に、３１０に関連する仮想モジュールは、３０４でインターセプトされたメソッドで与えられるオリジナル・パラメータ値のオブジェクトに対応するオブジェクトについて照会される。そのような対応するオブジェクトが存在する場合には、そのオブジェクトが即座に取り出され、そうでない場合には、上で説明したように未初期化オブジェクトとして作成される。図７に戻って、実際のコンポーネントを仮想モジュールに関連付けた後に、新しい仮想モジュール内のランタイム・スイッチは、当初に、関連するコンポーネントの一意型名前空間内でそれぞれコンストラクトされ、ロードされたオブジェクトおよびクラスが委譲しないことを保証するためにセットアップされる７１０。前にインストールされたモジュールの動的更新が、７１２で行われ、ここで、ランタイム・スイッチは、すべてのオブジェクトおよびクラスを、新たにインストールされたモジュール内の可能な将来の対応する表現のサロゲートにするのに使用される。最後に、７１４で、本発明の特定の実施形態で機能強化されたコンポーネント・システム内の特定の要素のリソースのドメイン固有更新が、実行される。

図８を参照すると、本発明の実施形態の実行中にオンデマンドでクラスを変換するために行われるステップを示す流れ図。当初に、８０２で、クラスロード・イベントが、動作中のシステムを実行する仮想マシンにクラスをロードするためにトリガされる。ステップ８０４では、変換エージェントが、クラスがシステム・クラスまたはアプリケーション・クラスのどちらであるのか判定する。ここで、クラスは、そのクラスローダに関して分類される。アプリケーション・クラスは、基礎になるコンポーネント・システムのコンポーネント・クラスローダによってロードされ、システム・クラスは、システム・クラスローダによってロードされる。それぞれシステム・クラスおよびアプリケーション・クラスを変換する、１４００および１８００に示された高水準工程ステップは、図９．６および図９．１０によって表される、より細粒度の図を参照しながら詳細に示される。同様に、クラスローダに関わりなくシステム内のすべてのクラスに対してさらなるバイトコード変更を実行する、２６００として示された高水準変換ステップは、図９．１６を参照する時に包括的に説明される。すべてのバイトコード変換が完了した後に、変更されたクラスが、８０６で仮想マシンにロードされる。

図９．１を参照すると、ブートストラップ・クラスのバイトコードを変換するために行われるステップを示す流れ図。このフローは、すべてのブートストラップ・クラスのバイトコードを変換するためにブートストラップ工程によってトリガされる９０２。したがって、この流れ図によって示される工程は、すべてのブートストラップ・クラスについて繰り返される。９０４では、ブートストラップ・クラスの中で、本発明のある種のプロパティを満足するために特殊なハンドリングを必要とするクラスが、フィルタ・アウトされる。９０４での判断が真になる場合には、これらの特殊なクラスを変換するために行われるステップは、図９．３でさらに詳細に示される別々の工程（１１００）によって処理される。各非特殊ブートストラップ・クラスについて、バイトコードは、１）９０６でブートストラップ・フィールドに関する情報を保存し、２）メソッドおよびコンストラクタを通って反復して９０８、コードがオブジェクト・ファイナライザである１１００、コンストラクタである１２００、ｐｕｂｌｉｃメソッドまたはｐｒｏｔｅｃｔｅｄメソッドである１３００かどうかに従ってコードを変換することによって変換される。最後に、バイトコード置換および他の特殊バイトコード命令ハンドリングを実行する高水準工程が、２６０
０によって取り込まれ、２６００は、図９．１６を参照しながら詳細に示される。

図９．２は、９００で見つかった特殊なブートストラップ・クラスのバイトコード変換を実行するために行われるステップを示す流れ図である。本発明の例の実施形態は、リフレクション的機構の使用が上で説明したインプレース・プロキシフィケーションおよびコレスポンダンス・ハンドリング・モデルに対応することを保証するために、これらの特殊なクラス内のある種のメソッドのバイトコードを置換する。１００４で、この工程は、変換される特殊なクラスがｊａｖａ．ｌａｎｇ．Ｃｌａｓｓクラスである場合には１００６に分岐する。その後、この工程は、１００８で、ｇｅｔＤｅｃｌａｒｅｄＭｅｔｈｏｄまたはｇｅｔＤｅｃｌａｒｅｄＦｉｅｌｄという名前のメソッドを検索する。これらのメソッドでは、検索されるフィールドまたはメソッドが本発明によって追加されるかどうかを検査するために、バイトコードがメソッドの始めに挿入される１０１４。そうである場合には、１０１６で、ランタイム例外を送出するバイトコードを追加する。１００８に戻って、ｊａｖａ．ｌａｎｇ．Ｃｌａｓｓ内のメソッドが、ｇｅｔＤｅｃｌａｒｅｄＦｉｅｌｄまたはｇｅｔＤｅｃｌａｒｅｄＭｅｔｈｏｄのうちの１つである場合には、この工程は１０１０に分岐し、そうである場合には、１０１２で、それぞれ宣言されたメソッドおよびフィールドのリストに戻る前に、本発明によって追加されたすべてのメソッドまたはフィールドを実行するための特殊なフィルタ・メソッドを呼び出すバイトコードを追加する。もう一度１００４を見ると、「ｎｏ」分岐に従う場合に、この工程は、１０１８でｊａｖａ．ｌａｎｇ．ｒｅｆｌｅｃｔ．Ｆｉｅｌｄクラスを探す。このクラスが見つかる場合には、１０２０で、ｇｅｔＦｉｅｌｄＡｃｃｅｓｓｏｒという名前の特定のメソッドを突き止め、ステップ１０２４で、上で説明したように本発明のフィールドアクセス・モデルに従うカスタムメードのフィールド・アクセッサを返すために、このメソッドの始めにバイトコードを挿入する。同様に、最後の特殊なクラスすなわちｊａｖａ．ｒｅｆｌｅｃｔ．ＲｅｆｌｅｃｔｉｏｎＦａｃｔｏｒｙについて、ステップ１０２２で、特殊なメソッドを突き止め、ここで、ステップ１０２４で、バイトコード変換がメソッドの始めに挿入される。

図９．３を参照すると、ｆｉｎａｌｉｚｅメソッドのオリジナル・コードが特定のオブジェクトの最新バージョンでのみ実行されることを確実にするために必要なステップを示す流れ図。バイトコード変換は、ファイナライザ・メソッドの始めにバイトコードを挿入する１１０２。挿入されるバイトコードは、まず、ｆｉｎａｌｉｚｅメソッドがその上で実行されるオブジェクトが更新対応アプリケーション・クラス内で宣言されているかどうかを検査する１１０４。そうである場合には、挿入されるバイトコードは、上で説明したコレスポンダンス・ハンドリングに従って、そのオブジェクトがオブジェクトの最新バージョンであるかどうかを検査する１１０６。そうである場合には、このｆｉｎａｌｉｚｅメソッドのオリジナル・メソッド本体を実行する１１０８。１１０４に戻って、現在ファイナライズされつつあるオブジェクトが、更新対応アプリケーション・クラスのインスタンスではない場合には、やはりオリジナル・メソッド本体を実行する１１０８。オブジェクトが、ステップ１１０６で最新バージョンではない場合には、変換工程は、オリジナル・メソッド本体を実行せずに即座にリターンするバイトコード１１１０を挿入する。オブジェクト・ファイナライゼーション時にオリジナルのｆｉｎａｌｉｚｅコードを除外する理由は、現在のオブジェクトの最新の対応するオブジェクトが、現在システム内でライブであることである。したがって、ｆｉｎａｌｉｚｅメソッドのクリーン・アップから生じるすべての可能な副作用は、動作中のシステムに対する望まれないセマンティック影響を有する可能性がある。

図９．４を見ると、コンストラクタのオリジナル・コードが特定のオブジェクトの最新バージョンでのみ実行されることを保証するために行われるステップを示す流れ図。バイトコード変換は、コンストラクタの始めにバイトコードを挿入する１２０２。挿入される
バイトコードは、まず、コンストラクタが実行されるオブジェクトが更新対応アプリケーション・クラス内で宣言されているかどうかを検査する１２０４。そうである場合には、挿入されるバイトコードは、上で説明したコレスポンダンス・ハンドリングに従って、そのオブジェクトがオブジェクトの最新バージョンであるかどうかを検査する１２０６。そうである場合には、このコンストラクタのオリジナル・メソッド本体を実行する１２０８。１２０４に戻って、現在コンストラクトされつつあるオブジェクトが、更新対応アプリケーション・クラスのインスタンスではない場合には、オリジナル・コンストラクタを実行する１２０８。オブジェクトが、ステップ１２０６で最新バージョンではない場合には、変換工程は、オリジナル・メソッド本体を実行せずに即座にリターンするバイトコード１２１０を挿入する。この状況は、更新されたクラスのクライアントがそのクラスのオブジェクトをコンストラクトする場合に一般的に発生する。クラス階層内のコンストラクタの必須連鎖は、最初のバイトコード命令がスーパ・コンストラクタへの呼出であることを強制する。したがって、挿入されるバイトコードが、オブジェクトが最新バージョンであるか否かに関して推論できる場合であっても、挿入されるバイトコードがスーパ・コンストラクタ呼出を省略することはできない。したがって、説明される例でスーパ・コンストラクタに入る時には、作成されつつあるオブジェクトは、最新バージョンではなく、インプレース・プロキシフィケートされたサブクラスによって処理されるコンストラクタ委譲をもたらす。

図９．５を参照すると、プログラマが記述したメソッド本体の実行が必ず実行中のオブジェクトの最新バージョンで発生することを確実にするためにメソッドの始めにバイトコードを挿入する１３０２ために行われるステップを示す流れ図。挿入されるバイトコードは、まず、メソッドが実行されるオブジェクトが更新対応アプリケーション・クラス内で宣言されているかどうかを検査する１３０４。そうである場合には、挿入されるバイトコードは、上で説明したコレスポンダンス・ハンドリングに従って、そのオブジェクトがオブジェクトの最新バージョンであるかどうかを検査する１３０６。そうである場合には、オリジナル・メソッド本体を実行する１３０８。１３０４に戻って、現在メソッドを実行しつつあるオブジェクトが、更新対応アプリケーション・クラスのインスタンスではない場合には、オリジナル・メソッド本体を実行する１３０８。オブジェクトが、ステップ１３０６で最新バージョンではない場合には、変換工程は、現在実行中のオブジェクトの最新の対応するバージョンをルックアップする責任を負うメソッドを呼び出すバイトコード１３１０を挿入する。最新の対応するバージョンを入手し終えて、オリジナル・メソッド呼出は、ステップ１３１２で、ターゲット・クラス内の対応するメソッドに委譲される。

図９．６を見ると、システム・クラスが、ロードされる時１０４２にどのように変換されるのかを示す流れ図。システム・クラスを仮想マシンにロードする前に、バイトコードを解析する１４０４。クラスの解析中に、１４０６によって示されているように、２つの特殊なアクセッサ・メソッドが、クラス内の非スタティック・フィールドの読取および書込のために作成される。これらのメソッドの生成の詳細な説明は、それぞれ図９．７（１５００）および図９．８（１６００）を参照する時に与えられる。１４０８は、クラスがｆｉｎａｌクラスとして宣言されているか否か判定する。そうでない場合には、流れはステップ１７００を通って進み、１７００は、１４１０に進む前に、可能な更新対応サブクラスがそれらを利用するために、このクラスの内部でいくつかのヘルパ・メソッドを生成する必要があることを示す。この生成のさらなる説明は、図９．９（１７００）を参照する時に与えられる。１４０８に戻って、クラスがｆｉｎａｌではない場合には、この工程は、１４１０でメソッドおよびコンストラクタを通って反復し、コードがオブジェクト・ファイナライザである１１００（図９．３）、コンストラクタである１２００（図９．４）、ｐｕｂｌｉｃメソッドまたはｐｒｏｔｅｃｔｅｄメソッドである１３００（図９．４）かどうかに従ってコードを変換する。最後に、バイトコード置換および他の特殊バイトコード命令ハンドリングを実行する高水準工程が、２６００（図９．１６）によって取り
込まれる。

図９．７を参照すると、システム・クラス内の非スタティック・フィールドアクセス用のフィールド読取メソッドを生成する１５０２ために行われるステップを示す流れ図である。当初に、１５０４で、生成されるメソッドのスタブを作成する。次に、１５０６で、この工程は、ｆｉｎａｌクラスに基づいて分岐し、ｆｉｎａｌクラスについては、１５０８で、直接にフィールド値を読み取るためのバイトコードが、生成されるメソッドに挿入される。この最適化は、ｆｉｎａｌクラスについてサブクラスが存在し得ないので可能である。したがって、インプレース・プロキシ・オブジェクトを、処理されるシステム・クラスを含むクラス階層から作成することはできず、処理されるシステム・クラス内のフィールドに関する安全な直接フィールドアクセスが保証される。ｆｉｎａｌとして宣言されていないクラスについて、この工程は、フィールドのオーナ・オブジェクトが更新対応であるかどうかを１５１０で検査するために、生成されるメソッドにバイトコードを挿入する。更新対応である場合には、１５１２で、オブジェクトを特殊な更新対応マーカ・インターフェースにキャストする。この特殊なインターフェースは、下で説明するように、バイトコード変換によってすべてのアプリケーションについて実装される。１５１４では、本発明のこの実施形態によって実装される特殊なメソッドを使用して、現在実行中のオブジェクトを「起点オブジェクト」に置換する。起点オブジェクトは、標準コンストラクタを実行することによって作成されるオブジェクトと定義される。したがって、対照的に、本実施形態によって作成されるすべての対応するオブジェクトは、起点オブジェクトではない。フィールドは、１５１６で宣言するクラスの型にキャストし、１５１８でフィールド値を読み取ることによって起点オブジェクトから読み取られ、１５２０でフィールドの型に応じて適当なリターン命令を挿入することによってオリジナルのフィールド読取命令の呼出し側に返される。

図９．８を参照すると、システム・クラス内の非スタティック・フィールドアクセス用のフィールド書込メソッドを生成する１６０２ために行われるステップを示す流れ図。当初に、１６０４で、生成されるメソッドのスタブを作成する。次に、１６０６で、この工程は、ｆｉｎａｌクラスに基づいて分岐し、ｆｉｎａｌクラスについては、１６０８で、直接にフィールド値を書込むためのバイトコードが、生成されるメソッドに挿入される。ｆｉｎａｌとして宣言されていないクラスについて、この工程は、フィールドのオーナ・オブジェクトが更新対応であるかどうかを１６１０で検査するために、生成されるメソッドにバイトコードを挿入する。更新対応である場合には、１６１２で、オブジェクトを特殊な更新対応マーカ・インターフェースにキャストする。１６１４では、この工程は、上で説明した起点オブジェクトへの参照を入手するバイトコードを挿入する。フィールドは、１６１６で宣言するクラスの型にキャストし、１６１８でパラメータからの値を生成されるメソッドにロードし、１６２０でロードされた値を起点オブジェクトに書込むことによって、起点オブジェクトに書込まれる。

図９．９を参照すると、システム・クラス内のある種のヘルパ・メソッドの生成１７０２を示す流れ図。これらのメソッドは、更新対応クラスのクラス階層内において上で説明したようにターゲット情報に関するある種のプロパティを判定するのに使用される再帰的スーパ呼出を終了するためのコンビニエンス・メソッド（ｃｏｎｖｅｎｉｅｎｃｅｍｅｔｈｏｄ）である。ステップ１７０４では、生成工程は、生成されるメソッドが特殊なｉｓＭｅｔｈｏｄＰｒｅｓｅｎｔメソッドであるか否か判定する。そうである場合に、生成されるメソッドに挿入されるバイトコードは、必ず真を返す１７０６。他の生成されるメソッドについて、挿入されるバイトコードは、必ず偽を返す１７０８。

次に図９．１０を参照すると、仮想マシン内において１８０２で開始されるクラスのロードの前に、アプリケーション・クラスのバイトコードを解析し１８０４、変換するため
に行われるステップの高水準の図を示す流れ図。１８０６では、変換工程は、システム内のすべてのアプリケーション・クラスによって実装される前述の更新対応マーカ・インターフェースを挿入する。１８０８は、アプリケーション・クラス内のフィールドごとにフィールド・アクセッサ・メソッドを生成する工程の高水準の図を示し、この生成の詳細な説明は、図９．１１および図９．１２を参照しながら、この説明に続く。ステップ２１００は、このクラスの以前のバージョンに対する更新によって導入されるフィールドを初期化するバイトコードを生成する工程の高水準の図を示す。この工程の詳細な説明は、図９．１３を参照する時に与えられる。変換されるクラスによって宣言されるすべてのメンバ１８１０は、それがｆｉｎａｌｉｚｅメソッドであるのか１８１２、コンストラクタであるのか１８１４、スタティック・イニシャライザ（＜＜ｃｌｉｎｉｔ＞＞）であるのか１８１６、非ｓｔａｔｉｃのｐｕｂｌｉｃメソッドまたはｐｒｏｔｅｃｔｅｄメソッドであるのか１８１８、ｓｔａｔｉｃのｐｕｂｌｉｃメソッドまたはｐｒｏｔｅｃｔｅｄメソッドであるのか１８２０に従って特殊化された変換を受け、これらの各個々の変換は、それぞれ図９．３（１１００）、図９．１４（２２００）、図９．１５（２３００）、図９．１６（２４００）、および図９．１７（２５００）で包括的に説明される。

図９．１１を参照すると、アプリケーション・クラス内のフィールド読取メソッドを生成する１９０２ために行われるステップを示す流れ図である。フィールド読取メソッドに挿入されるバイトコードは、当初に、１９０４で、現在実行中のオブジェクトが最新バージョンであるかどうかを検査する。そうである場合には、１９０６で、フィールド値がオブジェクトのこのバージョンに存在するかどうかを調べるためにさらに検査する。本発明のこの実施形態は、それぞれが宣言するクラスの個々のフィールドについて１９０６で出される質問に対する答えを保持するブール値の配列を関連付ける。状態が存在する場合には、ステップ１９０８で、フィールド値を読み取り、ローカル変数に格納する。検査の後に、宣言するクラスの更新が１９０６と１９１０との間の時間期間に行われたかどうかを調べることが、実行される。そのような更新が行われた場合には、フィールド読取要求は、１９１４に示されているように現在のターゲット・バージョンに委譲され、１９１４は、最初に１９０４で条件を検査する間にオブジェクト・オーナが更新済みであった場合の結果のイベントでもある。１９０６に戻って、フィールド状態の現在のバージョンがオーナ・オブジェクトの対応するバージョンに保持される場合には、状態をその現在位置から移植するメソッドが、１９１６で呼び出される。この呼出は、対応するオブジェクトにまたがって同期化する能力を有して設計された１９１８に示された特殊なロック機構の下で発生する。したがって、フィールド値を読み取り、書込むアルゴリズムは、ロックフリーであり、したがって高速であるが、状態移植工程は、インプレース・プロキシ・オブジェクトから最新の対応するバージョンへ状態を移動している間に特殊なロックを必要とする。

図９．１２に移ると、アプリケーション・クラス内のフィールド書込メソッドを生成する２００２ために行われるステップを示す流れ図。フィールド書込メソッドに挿入されるバイトコードは、当初に、２００４で、現在実行中のオブジェクトが最新バージョンであるかどうかを検査する。そうである場合には、２００６で、フィールド値がオブジェクトのこのバージョンに存在するかどうかを調べるためにさらに検査する。状態が存在する場合には、ステップ２００８で、フィールド値を書込む。その後、宣言するクラスの更新が２００６と２０１０との間の時間期間に行われたかどうかを調べるための検査が、実行される。そのような更新が行われた場合には、フィールド書込要求は、２０１２に示されているように現在のターゲット・バージョンに委譲され、２０１２は、最初に２００４で条件を検査する間にオブジェクト・オーナが更新済みであった場合の結果のイベントでもある。２００６に戻って、フィールド状態の現在のバージョンがオーナ・オブジェクトの対応するバージョンに保持される場合には、２０１４でフィールド値を直接に書込み、２０１６で関連するブール値をそれ相応に更新する。２つの対応するオブジェクトがフィール
ド値の最新バージョンを保持すると明示的に述べる、導入される時間的矛盾を除去するために、フィールド値の前のオーナを突き止め、値自体ならびに関連するブール値をクリアする、特殊な状態クリア・メソッドが、２０１８で呼び出される。現在のオブジェクト・オーナならびに前のオーナのブール値を更新する工程は、２０２０にも示されているように、上で説明したロック機構を必要とする。特定のフィールド値の前のバージョンでの状態を除去する工程は、それ自体では、そのフィールドに対する同時アクセスの正しいセマンティックを保証しない。これが、２０１０および１９１０に示された宣言するクラスの更新が必要かどうか調べるための余分な検査が必要な理由である。

図９．１３を見ると、宣言するクラスの以前のバージョンからコンストラクトされたオブジェクトに、新たに追加されたフィールドのプログラマによって記述されたデフォルト・フィールド値を代入するのに必要なステップを示す流れ図。プログラマによって記述されたフィールド代入と一致するバイトコードを取り込むために、２１０２で、コンストラクタのバイトコードを解析する。解析されるコンストラクタの予備条件は、そのコンストラクタが、宣言するクラス内の別のコンストラクタにコンストラクションを委譲するコンストラクタになることができないことであり、委譲する場合には、クラスレベルのフィールド代入は、コンストラクタのコードに存在しない。ステップ２１０４は、宣言するクラスが仮想マシンにロードされる最初のバージョンであるか否か判定するための検査を含む。この場合に、この工程は、バイトコードを全く生成せずに終了する。というのは、対応する宣言するクラスがロードされていないことを考慮すると、以前のバージョンの対応するオブジェクトが存在し得ないからである。対照的に、解析されるクラスが、対応する以前のクラス・バージョンを有する場合には、この工程は２１０６に進み、２１０６では、必須のスーパ・コンストラクタ呼出を達成するための最初の命令をスキップする。ステップ２１０８では、解析中にバイトコード命令を格納できるバイトコード・ブロックが、宣言される。その後、ステップ２１１０では、バイトコード命令が、コンストラクタ内の次の命令を読み取ることによって開始される。２１１２に示された、このアルゴリズムの第１の停止判断基準は、命令がＰＵＴＦＩＥＬＤであり、したがって、宣言するクラス内のフィールド値への代入であることである。命令がＰＵＴＦＩＥＬＤ命令以外のものである場合には、２１１８でのテストが、現在の命令がクラスレベルで有効であるかどうかを調べるために検査する。クラスレベルで有効な命令とは、フィールド初期化代入の一部としてコンストラクタの外部で使用できる命令である。たとえば、解析されるコンストラクタの第１パラメータのロードは、コンストラクタの外部で行うことができず、したがって、この工程は解析を停止する。その後、この工程は、ステップ２１１６に移動し、２１１６は、停止判断基準が実現される前に見つかったバイトコード・ブロックを用いてメソッドを生成する。２１１８に戻って、命令をクラスレベルで行える場合には、その命令は、現在のバイトコード・ブロックに格納され、２１１０で、次の命令が解析される。２１１２をもう一度見ると、命令がＰＵＴＦＩＥＬＤ命令である場合には、このアルゴリズムは２１１４に分岐し、２１１４は、ＰＵＴＦＩＥＬＤ命令に含まれるフィールド名が既に処理されたかどうかを取り込む。そうである場合には、このアルゴリズムは停止し、ステップ２１１６に進む。フィールド名が新しい場合には、命令は現在のブロックに追加され、かつブロックは格納される。その後、ステップ２１０８で新しいバイトコード・ブロックが開始され、このアルゴリズムは、上で説明したようにステップ２１１０から継続する。

図９．１４は、更新対応アプリケーション・クラス内のコンストラクタのバイトコード変換を示す流れ図である。この変換は、メソッドの始めにバイトコードを挿入する２２０２。挿入されるバイトコードは、２２０４で、宣言するクラスが最新バージョンであるかどうかを検査することによって開始される。そうである場合には、挿入されるバイトコードは、２２０６で、現在コンストラクトされつつあるオブジェクトも最新バージョンであるかどうかを検査する。宣言するクラスが最新のクラス・バージョンである場合であっても、オブジェクトが、更新されるサブクラスのインスタンスである可能性があり、したが
って、ステップ２２０６は必要である。オブジェクトが同様に最新バージョンである場合には、２２０８に示されているように、オリジナル・コンストラクタ本体が実行され、挿入されるバイトコードがないかのようにオブジェクトをコンストラクトする。２２０４および２２０６で行われるテストに戻って、これらのテストのうちの１つが、オブジェクトまたはクラスが最新バージョンではないことをもたらす場合には、フローは、２２１０で継続される。このシナリオでは、挿入されるバイトコードは、コンストラクションが最新クラス・バージョンに委譲されなければならないのかどうか、または任意の可能なサブクラスが、必須スーパ・コンストラクタ呼出からリターンした後に委譲工程を処理するのか否か判定する必要がある。したがって、ステップ２２１０では、作成されつつあるオブジェクトが、サブクラスのインスタンスであるかどうかが検査され、そうである場合には、コンストラクタは、２２１２で即座にリターンされる。委譲工程を、２２１４に来る現在のクラスで実現しなければならない場合には、２２１４で、入手可能な現在のメタ情報が最新であるか否か判断する。そうである場合には、２２１６で委譲が行われ、そうでない場合には、２２１８でターゲット情報を最新にし、その後、２２１６に進む。

次に図９．１５を参照すると、本発明の好ましい実施形態でスタティック・イニシャライザを変換するために行われるステップを示す流れ図である。２３０２に示されているように、バイトコードが、メソッドの始めに挿入される。ステップ２３０４では、特殊なクラス登録工程が、システム内のクラスのコンポーネントに関連する特殊なモジュールへの参照を入手するために挿入される。この参照は、クラスおよびオブジェクトが更新されたかどうかを調べるためにテストするために、例示的実施形態全体を通じて、挿入されるバイトコードによって使用される。ステップ２３０６では、挿入されるバイトコードは、クラスが仮想マシンにロードされる最初のバージョンであるか否か判断する。そうである場合には、クラス・イニシャライザ内のオリジナル・コードを２３０８で実行する。そうではない場合には、このメソッドは、可能な包容力のない副作用を伴うクラス・イニシャライザの再実行を禁ずるために、２３１０で即座にリターンされる。

図９．１６は、更新対応アプリケーション・クラス内のｐｕｂｌｉｃおよびｐｒｏｔｅｃｔｅｄのインスタンスメソッドのバイトコード変換を示す流れ図である。変換は、メソッドの始めにバイトコードを挿入する２４０２。挿入されるバイトコードは、２４０４で実行中のオブジェクトが最新バージョンであるかどうかをテストすることによって開始され、そうである場合には、２４０６でオリジナルのメソッド本体を実行する。実行中のオブジェクトが最新バージョンではない場合には、２４１０でこのメソッドを現在のＴａｒｇｅｔメソッドに成功して委譲するために、２４０８でメタ情報を検査して、メタ情報が最新であるかどうかを調べる。ターゲット・ポインタが最新ではない場合には、フローは２４１２に進み、２４１２で、新しいＴａｒｇｅｔメソッドをルックアップする。２４１４でのテストで、対応するメソッドが動的更新によって除去済みである場合には、挿入されるバイトコードは、メソッドの現在のバージョンの実行にフォール・バックする。そうではない場合には、委譲工程が実行され、その実行フローの詳細な説明は、後で図９．２５（３３００）で示す。

図９．１７は、更新対応アプリケーション・クラス内のｐｕｂｌｉｃおよびｐｒｏｔｅｃｔｅｄのスタティック・メソッドのバイトコード変換を示す流れ図である。変換は、メソッドの始めにバイトコードを挿入する２５０２。挿入されるバイトコードは、２５０４で、宣言するクラスが最新バージョンであるかどうかをテストすることによって開始され、そうである場合には、２５０６に示されているようにオリジナルのメソッド本体を実行する。実行中のオブジェクトが最新バージョンではない場合には、２５１０でこのメソッドを現在のＴａｒｇｅｔメソッドに成功して委譲するために、２５０８でメタ情報を検査して、メタ情報が最新であるかどうかを調べる。ターゲット・ポインタが最新ではない場合には、フローは２５１２に進み、２５１２で、新しいＴａｒｇｅｔメソッドをルックア
ップする。２５１４でのテストで、対応するメソッドが動的更新によって除去済みである場合には、挿入されるバイトコードは、メソッドの現在のバージョンの実行にフォール・バックする。そうではない場合には、委譲工程が実行され、その実行フローの詳細な説明は、後で図９．２５（３３００）で示す。

図９．１８を見ると、上で説明されたように本発明の背後のモデルを保証するために特殊なハンドリングを必要とする命令を取り込むためにクラスの内部のすべてのバイトコード命令を解析する２６０２ことによってシステム内のすべてのクラスで行われるバイトコード変換を示す流れ図。ステップ２６０４は、オブジェクト・アイデンティティ・テストを実行するバイトコード命令を図９．２４（３２００）によって後に詳細に示される特殊なメソッドへの呼出に置換する、これらのバイトコード命令をフィルタ・アウトする。その後、そのメソッドによって返されるブール値が、２６０８でプリミティブ値の単純な比較を挿入することによって検査される。バイトコード命令が、２６１０のテストでメソッド命令である場合には、そのメソッド命令は、２６１２で検査され、さらに２６１２の関連する注釈によって指定されるように、そのメソッドが特殊なメソッドである場合に限って、特殊なハンドラ・メソッドによって置換される。メソッド命令が、ｃｌｏｎｅメソッドへの呼出である場合には、オリジナル・バイトコードは、図９．１９（２７００）を参照する時に与えられる詳細な説明に従って変換される。メソッド命令が、例示的実施形態ではＪＡＶＡ（登録商標）によって例示される基礎になる言語の組込み同期化機構に関連する場合には、これらのバイトコード命令は、図９．２０（２８００）で示される工程に従って変換される。インターセプトされるバイト命令の最後のグループは、２６２２によってテストされる、配列に関連する命令である。ある配列長のすべての配列読取、配列書込、または配列照会は、２６２４によって示されるように、対応するオブジェクトにまたがるアクセスを処理する特殊なメソッド呼出によって置換される。これらの特殊な配列メソッドの実行フローは、図９．２７（３５００）によって詳細に示される。

次に、図９．１９を参照すると、ｃｌｏｎｅメソッド呼出のオカレンスのバイトコードを変換するために行われるステップを示す流れ図。当初に、２７０２で、置換バイトコードは、クローン作成の特殊なハンドリングがクローンを作成されようとしているオブジェクトについて必要であるか否か判定するための検査を挿入する。この検査の実行フローは、後で図９．２６（３４００）によって詳細に示す。２７０４によるテストで、特殊なクローン・サポートが必要である場合には、実行フローは、２７０６に示されているように、クローンを作成されるオブジェクトが最新の状態を含むことを保証するために必須のステップを実行する特殊なメソッドを呼び出す。逆に、特殊なハンドリングが必要ではない場合には、２７０８よって示されるように、オリジナルのｃｌｏｎｅメソッド命令が実行される。

図９．２０を見ると、２８０２によって定義される同期化関連バイトコード命令の置換を示す流れ図。すべての同期化関連命令は、実行中にスタック上に含まれる特定のオブジェクトに対して同期化する。ステップ２８０４では、このオブジェクトは、可能な対応するオブジェクトにまたがって一意のままであるこのオブジェクトの一意表現を返す特殊な同期化メソッドへのパラメータとして与えられる。その後、オリジナル・バイトコード命令が実行される時に、その命令は、その後に、おそらくは異なる対応するオブジェクトを参照する更新されたクラスによってアンロックされ得るオブジェクトに対して同期化する。

図９．２１は、仮想マシンにロードされた更新対応クラスのバイトコード内のフィールドアクセス命令２９０２を変換するために行われるステップを示す流れ図である。命令が、ＧＥＴＳＴＡＴＩＣ命令ではない場合には、変換工程は、２９１４によって示されるように、その命令を、生成されたフィールドアクセス・メソッドへのメソッド呼出に置換す
る。ＧＥＴＳＴＡＴＩＣ命令の場合には、２９０６で、バイトコード命令によって指定されるフィールド・オーナを検査して、それがインターフェースであるかどうかを調べ、そうである場合には、オリジナル・フィールド命令を保存する。すべての他の場合には、ステップ２９０８で、指定されたフィールド・オーナが現在解析されているクラスと等しいかどうかを検査する。そうである場合には、この工程は、２９１０で、フィールドが実際に指定されたクラスで宣言されているかどうかを検査する。そうである場合には、ステップ２９１４で、命令を、生成されたフィールドアクセス・メソッドへの呼出によって置換する。そうではない場合には、変換工程は、ステップ２９１２で、宣言されたフィールド・オーナ・クラスがこのフィールド用の関連する生成されたアクセス・メソッドを有するか否か判定するランタイム検査を実行するバイトコードを挿入する。このメソッドから返された値が真である場合には、２９１４に示されているように、フィールドアクセス・メソッドを呼び出す。その一方で、フィールドアクセス・メソッドが宣言されたフィールド・オーナに存在しない場合には、ステップ２９１６で、フィールド値を取り出すためにオリジナル命令を使用する。

図９．２２を参照すると、他のクラスからブートストラップ・クラスにおいて宣言されたフィールドにアクセスするだけでなく、ブートストラップ・クラスの内部のフィールドアクセス命令のためのバイトコードを変換するのに必要なステップを示す流れ図。３００２のテストで、命令がＧＥＴＦＩＥＬＤである場合には、変換は、要素３０３２の内側に示されたバイトコードを挿入する。当初に、３００４で、挿入されるバイトコードは、特定のフィールドのオーナ・オブジェクトが更新対応であるかどうかを検査する。そうである場合には、３００６で、オブジェクト・オーナの起点バージョン内のブート・フィールドを取り出すために特殊なメソッドを呼び出すことによって、フィールドアクセスが処理される。このブート・フィールド委譲の実行フローは、後で図９．２９（３７００）によって詳細に示される。この特殊なメソッドからオブジェクト型値を取り出した後に、ステップ３００８は、フィールド型がプリミティブであるか否か判定し、そうである場合には、３０１０で、バイトコードは、返されたオブジェクトをそのプリミティブ対応物へｕｎｂｏｘする。そうではない場合には、３０１４で、ＣＨＥＣＫＣＡＳＴ命令を挿入して、オブジェクトをフィールド型にキャストする。３００４に戻って、オブジェクト・オーナが更新対応ではない場合には、挿入されるバイトコードは、３０１２で、オリジナルＧＥＴＦＩＥＬＤ命令を使用して、フィールドを直接に安全に読み取る。オリジナル命令がＰＵＴＦＩＥＬＤである場合には、３０１８に示された挿入されるバイトコードの最初のステップは、スタックにオブジェクト・オーナを置くためにスタックを操作し、したがってこのオブジェクトに対するさらなる検査を実行できるようにすることである。その後、３０２０で、挿入されるバイトコードは、オブジェクト・オーナが更新対応であるかどうかを検査し、そうである場合には、３０２２および３０２４でプリミティブ・フィールド型を扱うのに必要なステップを実行した後に、３０２６でフィールド書込を特殊なメソッドに委譲する。オリジナル・フィールド命令が、フィールドへの静的アクセスである場合には、これらのクラスを動的に更新することが不可能なので、変換は、バイトコードを挿入する必要がない。したがって、スタティック・フィールドの状態は、宣言するブートストラップ・クラス内に一意に配置される。

次に図９．２３を見ると、システム・クラスの内部のフィールド命令を変換するために行われるステップを示す流れ図。３１０２のテストで、フィールドアクセスが、インスタンス・フィールドへのアクセスを試みている場合には、フィールド命令は、ステップ３１０４で、生成される関連するフィールドアクセス・メソッドへの呼出によって置換される。

図９．２４を参照すると、前に述べたインターセプトされる特殊なメソッドおよび動作を処理する３２０２ために行われるステップを示す流れ図。１）オブジェクト・アイデン
ティティ比較３２０４、２）Ｃｌａｓｓ．ｉｓＩｎｓｔａｎｃｅメソッド３２０６、３）ＣＨＥＣＫＣＡＳＴ演算子３２０８、４）ｉｎｓｔａｎｃｅｏｆ演算子３２１０、５）Ｃｌａｓｓ．ｉｓＡｓｓｉｇｎａｂｌｅＦｒｏｍメソッド３２１２の変換されたオカレンスのうちの１つの実行の場合には、本発明の例示的実施形態の実行レイヤは、上で説明した本発明の基礎になるモデルのセマンティクスを達成するために、特殊なアクションを実行する。当初に、ステップ３２１４で、実行レイヤは、対応するインスタンスをルックアップし、その結果、３２１４で、検査または演算の両辺が同一の型名前空間に従うようにする。その後、３２１６で、オリジナル・コードの未変更バージョンがこれらのインスタンスに対して実行される。３２１２に戻って、実行レイヤをトリガした実行がＣｌａｓｓ．ｇｅｔＩｎｔｅｒｆａｃｅｓメソッド呼出である場合には、実行レイヤは、３２１８で、オリジナルｇｅｔＩｎｔｅｒｆａｃｅｓメソッドから入手されたインターフェースのリストに、更新対応アプリケーション・クラスに追加された特殊なインターフェースが存在する場合に、それらの特殊なインターフェースをフィルタ・アウトする。

次に図９．２５を参照すると、実行をインプレース・プロキシ・オブジェクトから最新の対応するバージョンに委譲する３３０２ために行われるステップを示す流れ図。３３０４のテストでコンストラクタ委譲である場合には、実行レイヤのフローは、３３０６で始まり、３３０６は、ターゲット・コンストラクタが更新されたクラスから除去済みであるかどうかを調べるためのサニティ・チェックである。そうである場合には、コンストラクトは、３３４２で、その中で委譲工程が開始されたオリジナル・コードの実行にフォール・バックする。呼出し側オブジェクトがオリジナル・コンストラクタからコンストラクトされた後に、そのオブジェクトは、宣言するクラスのメンバの最初の使用時にインプレース・プロキシになり、新しい未初期化の対応するターゲット・オブジェクトが作成される。ターゲット・コンストラクタがターゲット・クラスに存在する場合には、オリジナル・コンストラクタからのパラメータ値が、３３０８でターゲットの型名前空間に変換される。その後、ステップ３３１０では、ターゲット・コンストラクタが、変換されたパラメータを用いて呼び出され、３３１２では、２つの対応するオブジェクトの間の対応関係がセットアップされる。

入ってくる委譲要求が、３３１４によって示されるようにＴａｒｇｅｔメソッドに対するものである場合には、実行レイヤは、３３１６で、サニティ・チェックを実行して、Ｔａｒｇｅｔメソッドが更新されたクラスに存在するかどうかを調べる。そうである場合には、３３１８で、前に説明したようにパラメータを変換する。そうではない場合には、ステップ３３４２で、オリジナル・メソッドの実行にフォール・バックする。オリジナル・メソッドを実行すること。ステップ３３２０では、変換されたパラメータを使用してメソッドを呼び出し、３３２２のテストでメソッドの戻り型がｖｏｉｄである場合には、この工程は終了する。そうではない場合には、３３２４で、Ｔａｒｇｅｔメソッドから返された値を、呼出し側メソッドの型名前空間に従う対応するオブジェクトに戻って変換する。

インプレース・プロキシ内の生成されたフィールド読取メソッドから来るフィールド・ゲット実行イベント３３２６の場合には、実行レイヤは、やはり、ステップ３３２８で、サニティ・チェックを実行して、フィールドが、およびこれによって関連する生成されたフィールド読取メソッドが、まだターゲット・クラスに存在するかどうかを調べることによって開始する。同一の検査が、ステップ３３３６でフィールド書込メソッド委譲について実行される。Ｔａｒｇｅｔメソッドが存在する場合には、ステップ３３３０で、リフレクション的呼出が発生し、ステップ３３３２で、返されたフィールド値の変換が行われる。フィールド書込委譲について、新しいフィールド値は、まずステップ３３３８で新しいターゲット名前空間に変換され、その後、ステップ３３４０で、対応するメソッドがリフレクション的に呼び出される。

図９．２６を見ると、例示的実施形態の実行レイヤがオブジェクトまたは配列のクローンを作成する、入ってくる要求をどのように処理するのか３４０２を示す流れ図。入ってくる要求が、２７０２によって以前に指定されたｉｓＳｐｅｃｉａｌＣｌｏｎｅＮｅｅｄｅｄの要求である場合には、実行レイヤは、まず、ステップ３４０６で、クローンを作成されるオブジェクトが更新対応であるかどうかを検査する。そうではない場合には、このメソッドは、ステップ３４１２で偽を返し、指定されたオブジェクトのクローンを作成するために特殊なハンドリングが必要ではないことを示す。クローン作成されるオブジェクトが更新対応である場合には、ステップ３４０８で、現在のｃｌｏｎｅ呼出が、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔクラスによって宣言されたネイティブｃｌｏｎｅメソッドによって実行されるかどうかを検査する。この場合には、このメソッドは、ステップ３４１０で真を返し、このオブジェクトのクローンを作成するために特殊なハンドリングが必要であることをシグナリングする。

３４１４でのテストで、入ってくる要求が、上で述べたｉｓＳｐｅｃｉａｌＣｌｏｎｅメソッドからの肯定のフィードバックに対してのみ実行されるｓｐｅｃｉａｌＣｌｏｎｅメソッドの要求である場合、実行レイヤは、ステップ３４１６で、クローンになるための未初期化オブジェクトを作成する。この新たに作成されたオブジェクトに対して、ステップ３４１８で、クラス階層をトラバースして、既存オブジェクトからフィールド値をコピーし、フィールド値がまずその対応するオブジェクトの任意の１つの現在位置に配置されることを保証する。したがって、クローン・オブジェクトは、オリジナル・オブジェクトと同一の状態を含むが、オリジナル・オブジェクトに格納されたメタ状態のいずれをも含まない。

配列クローン作成の場合には、実行レイヤは、まず、３４２０で、オリジナル配列の同一型の新しい空の配列を作成する。その後、３４２２で、配列の現在の要素のすべてを格納する対応する配列をトラバースし、値を新しい配列コンポーネント型の型名前空間に変換する。

次に図９．２７を参照することは、配列アクセスの変更されたオカレンスが実行される時に例の実施形態の実行レイヤ内で行われるステップ３５０２を示す流れ図。実行イベントが、３５０４のテストで配列の長さの照会である場合に、実行レイヤは、まず、ステップ３５０６で、照会される配列の起点配列を突き止める。起点配列は、アプリケーション・コードによって作成された配列の特定のバージョンである。起点配列は、必ず、それ自体の型名前空間内の更新された要素値を保持する。その後、ステップ３５０８で、配列長が、起点配列から取り出される。

３５１０による検査で、変更された配列ロード演算が実行される場合には、実行レイヤは、３５１２で起点配列を取り出し、ステップ３５１４で、オリジナルＡＡＬＯＡＤ命令で与えられたインデックスを使用して起点配列から現在値を得、ステップ３５１６で、その値を、変更されたバイトコードの呼出し側の型名前空間に変換する。

変更された配列ストア演算が実行される場合には、実行レイヤは、３５１８で起点配列を取り出し、３５２０で、オリジナル・バイトコード命令内で使用された値を起点配列の型名前空間に変換し、３５２２で、変換された値を起点配列に格納する。

図９．２８を見ると、オブジェクトのハッシュコードおよびシステム・アイデンティティ・ハッシュコードを取り出すために変更されたバイトコード命令の実行３６０２を処理するために行われる必要なアクションを示す流れ図。３６０４による検査でシステム・アイデンティティ・ハッシュコードの置換バイトコードを実行する場合に、実行レイヤは、３６０６で起点オブジェクトを取り出し、３６０８で起点オブジェクトのオリジナル・ア
イデンティティ・ハッシュコードを返す。ハッシュコード・メソッドの変更されたバージョンが呼び出される場合には、実行レイヤは、３６１０で、まず、現在のオブジェクトに使用される特定のハッシュコード・メソッドが、ｊａｖａ．ｌａｎｇ．Ｏｂｊｅｃｔクラスで宣言されたメソッドのハッシュコード・メソッドであるかどうかを調べる。そうである場合には、フローは、既に説明したステップ３６０６から継続する。ハッシュコード・メソッドが、特定のオブジェクトについてオーバーライドされている場合には、要求は、ステップ３６１２で最新の対応するバージョンに委譲する。したがって、オブジェクトのハッシュコードまたはアイデンティティ・ハッシュコードの要求は、対応するオブジェクトについて必ず同一の結果を返す。

図９．２９を参照すると、ブート・フィールドアクセスを委任するために行われるステップ３７０２を示す流れ図。３７０４による検査で読取ブート・フィールド委譲要求である場合に、実行レイヤは、まず、ステップ３７０６で起点オブジェクトを取り出す。その後、実行レイヤは、ステップ３７０８で、リフレクションを使用して起点オブジェクト内の値を読み取る。ブート書込フィールド委譲要求の場合には、実行レイヤは、まず、ステップ３７１０で起点オブジェクトを取り出す。その後、実行レイヤは、ステップ３７１２で、リフレクションを使用して、与えられた値を起点オブジェクトに書込む。

図９．３０は、オブジェクトの以前のバージョンから最新の対応するバージョンへ状態を転送するのに必要なステップ３８０２を示す流れ図を示す。ステップ３８０４では、実行レイヤは、まず、状態転送をトリガしたオブジェクトに対応するすべてのオブジェクトをルックアップする。突き止められた対応するオブジェクトのリストは、ｐｒｅｖｉｏｕｓＯｂｊｅｃｔｓという名前の変数に格納される。その後、ステップ３８０６で、このリストが、次の要素をｐｒｅｖｉｏｕｓという名前の変数に代入することによってトラバースされる。その後、３８０８では、実行レイヤは、現在の要素（ｐｒｅｖｉｏｕｓ）が状態の現在のバージョンを持ち続けるか否か判定し、そうである場合には、ステップ３８１０で、突き止められたバージョンの値を最新の対応するオブジェクトの型名前空間に変換する。さらに、変換されたフィールドが、最新の対応するバージョンのフィールドに書込まれる。その後、ステップ３８１２で、個々のフィールド値の状態の存在を指定するための関連するブール値が、最新の対応するオブジェクトについてセットされ、ステップ３８１４で、古いフィールド値オーナについてクリアされる。３８０８に戻って、現在のフィールド値が、トラバースされた現在の要素に存在しない場合には、ステップ３８１６で、対応するオブジェクトのリストをもう一度検査して、トラバースすべき要素がまだあるかどうかを調べる。そうである場合には、フローは、ステップ３８０６に再帰的に戻る。さらなる要素が見つからない場合には、実行レイヤは、ステップ３８１８で、指定されたフィールドがクラスの最新バージョンで新たに宣言されなければならないと結論する。したがって、フィールド値は、新たに宣言されたフィールドにデフォルト値を代入するために前に説明したアルゴリズムによって代入される値を含む。

最後に、図９．３１を参照すると、最新バージョンでのフィールド書込が関連するブール値を初めて変更した時に前の対応するオブジェクト内のフィールド値をクリアするために３９０２行われるステップを示す流れ図。ステップ３９０４では、実行レイヤは、まず、やはりｐｒｅｖｉｏｕｓＯｂｊｅｃｔｓに格納される、状態クリアの実行をトリガしたオブジェクトに対応するすべてのオブジェクトをルックアップする。ステップ３９０６では、次の要素をｐｒｅｖｉｏｕｓという名前の変数に代入することによって、このリストをトラバースする。３９０８での検査で、現在の要素が、関連するブール値によって指定されるように状態を保持する場合には、ステップ３９１０で、値ならびにブール・フィールドを、トラバースされた特定の要素についてクリアし、この工程は終了する。前の要素が状態を保持しない場合には、３９１２でのテストで次の要素が存在するならば、その要素を検索する。すべての要素がトラバースされ、それらのどれにおいても状態が見つから
ない場合には、実行レイヤは、ステップ３９１４でフォール・スルーする。というのは、フィールドが新規であり、したがって、フィールド値が、１つの対応するオブジェクトのみで既に一意に配置されるからである。
参考文献
［１］サトウ（Ｓａｔｏ）Ｙ．，チバ（Ｃｈｉｂａ）Ｓ．：Ｌｏｏｓｅｌｙ−ｓｅｐａｒａｔｅｄ ”Ｓｉｓｔｅｒ” ＮａｍｅｓｐａｃｅｓｉｎＪａｖａ、ＩｎｐｒｏｃｅｅｄｉｎｇｓｏｆＥＣＯＯＰ’０５、ＬｅｃｔｕｒｅＮｏｔｅｓｉｎＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅ、Ｖｏｌ．３５８６、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、（２００５）、ｐｐ．４９〜７０．
［２］ドロッソポーロウ（Ｄｒｏｓｓｏｐｏｕｌｏｕ），Ｓ．、ラッグ（Ｗｒａｇｇ），Ｄ．、およびアイゼンバッハ（Ｅｉｓｅｎｂａｃｈ），Ｓ、１９９８、ＷｈａｔｉｓＪａｖａｂｉｎａｒｙＣｏｍｐａｔｉｂｉｌｉｔｙ？、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆＯＯＰＳＬＡ’９８、ＡＣＭｐｒｅｓｓ、１９９８、ｐｐ．３４１〜３６１．
［３］オルソ（Ｏｒｓｏ）Ａ．、ラオ（Ｒａｏ）Ａ．、ハロルド（Ｈａｒｒｏｌｄ）Ｍ．Ｊ．：ＡＴｅｃｈｎｉｑｕｅｆｏｒＤｙｎａｍｉｃＵｐｄａｔｉｎｇｏｆＪａｖａＳｏｆｔｗａｒｅ、Ｉｎ：ｐｒｏｃｅｅｄｉｎｇｓｏｆＩＣＳＭ’０２、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙ、２００２、ｐｐ．６４９〜６５８．
［４］ブチ（Ｂｕｃｈｉ）Ｍ．、ウェック（Ｗｅｃｋ）Ｗ．：ＧｅｎｅｒｉｃＷｒａｐｐｅｒｓ、ＩｎｐｒｏｃｅｅｄｉｎｇｓｏｆＥＣＯＯＰ２０００、ＬｅｃｔｕｒｅＮｏｔｅｓｉｎＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅ、Ｖｏｌ．１８５０、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、（２０００）、ｐｐ．２０１〜２２５．
［５］ドミトリーブ（Ｄｍｉｔｒｉｅｖ）Ｍ．：ＳａｆｅＥｖｏｌｕｔｉｏｎｏｆＬａｒｇｅａｎｄＬｏｎｇ−ＬｉｖｅｄＪａｖａＡｐｐｌｉｃａｔｉｏｎｓ、ＰｈＤｔｈｅｓｉｓ、ＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｉｎｇＳｃｉｅｎｃｅ、ＵｎｉｖｅｒｓｉｔｙｏｆＧｌａｓｇｏｗ、ＧｌａｓｇｏｗＧ１２８ＱＱ、Ｓｃｏｔｌａｎｄ、２００１．
［６］マラバーバ（Ｍａｌａｂａｒｂａ）Ｓ．、パンデイ（Ｐａｎｄｅｙ）Ｒ．、グラッグ（Ｇｒａｇｇ）Ｊ．、バール（Ｂａｒｒ）Ｅ．、ａｎｄバーンズ（Ｂａｒｎｅｓ）Ｆ．：ＲｕｎｔｉｍｅＳｕｐｐｏｒｔｆｏｒＴｙｐｅ−ＳａｆｅＤｙｎａｍｉｃＪａｖａＣｌａｓｓｅｓ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆＥＣＯＯＰ’００、ＬｅｃｔｕｒｅＮｏｔｅｓｉｎＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅ、Ｖｏｌ．１８５０、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ、（２０００）、ｐｐ．３３７〜３６１．
［７］スブラマニアン（Ｓｕｂｒａｍａｎｉａｎ）Ｓ．、ヒックス（Ｈｉｃｋｓ）Ｍ．、マッキンレイ（ＭｃＫｉｎｌｅｙ）Ｋ．：ＤｙｎａｍｉｃＳｏｆｔｗａｒｅＵｐｄａｔｅｓ：ＡＶＭ−ｃｅｎｔｒｉｃＡｐｐｒｏａｃｈ、ＩｎＰｒｏｃｅｅｄｉｎｇｓ
ｏｆｔｈｅ２００９ＡＣＭＳＩＧＰＬＡＮｃｏｎｆｅｒｅｎｃｅｏｎＰｒｏｇｒａｍｍｉｎｇｌａｎｇｕａｇｅｄｅｓｉｇｎａｎｄｉｍｐｌｅｍｅｎｔａｔｉｏｎ、ＡＣＭＳＩＧＰＬＡＮＮｏｔｉｃｅｓ、Ｖｏｌｕｍｅ４４、Ｉｓｓｕｅ６、Ｍａｙ２００９、ｐｐ．１〜１２
［８］グスタフソン（Ｇｕｓｔａｖｓｏｎ），Ｊ．：ＤｙｎａｍｉｃＵｐｄａｔｉｎｇ
ｏｆＣｏｍｐｕｔｅｒＰｒｏｇｒａｍｓ − ＰｒｏｐｏｓｅｄＩｍｐｒｏｖｅｍｅｎｔｓｔｏｔｈｅＪＤｒｕｍｓＵｐｄａｔｉｎｇＳｙｓｔｅｍ、Ｒｉｓｅ
ｐｕｂｌｉｃａｔｉｏｎｓ２００５．
［９］ビアレク（Ｂｉａｌｅｋ），Ｒ．、ジュル（Ｊｕｌ），Ｅ．、Ｊ．−Ｇ．シュナイダ（Ｓｃｈｎｅｉｄｅｒ），Ｊ．−Ｇ．、ジン（Ｊｉｎ），Ｙ．：ＰａｒｔｉｔｉｏｎｉｎｇｏｆＪａｖａａｐｐｌｉｃａｔｉｏｎｓｔｏｓｕｐｐｏｒｔｄｙｎａｍｉｃｕｐｄａｔｅｓ、ＩｎｐｒｏｃｅｅｄｉｎｇｓｏｆＡＰＳＥＣ’０４、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙＰｒｅｓｓ、ｐｐ．６１６〜６２３．
［１０］ヒャルムティソン（Ｈｊａｌｍｔｙｓｓｏｎ）Ｇ．、グレイ（Ｇｒａｙ）Ｒ．：
ＤｙｎａｍｉｃＣ＋＋ｃｌａｓｓｅｓ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅＵＳＥＮＩＸ１９９８ＡｎｎｕａｌＴｅｃｈｎｉｃａｌＣｏｎｆｅｒｅｎｃｅ、ｐａｇｅｓ６５−７６、ＵＳＥＮＩＸＡｓｓｏｃｉａｔｉｏｎ、Ｊｕｎｅ１５−１９１９９８．
［１１］スタネック（Ｓｔａｎｅｋ）Ｊ．、コタリ（Ｋｏｔｈａｒｉ）Ｓ．、ヌイェン（Ｎｇｕｙｅｎ）Ｔ．Ｎ．、クルズニエラ（Ｃｒｕｚ−Ｎｅｉｒａ）Ｃ．２００６．ＯｎｌｉｎｅＳｏｆｔｗａｒｅＭａｉｎｔｅｎａｎｃｅｆｏｒＭｉｓｓｉｏｎ−ＣｒｉｔｉｃａｌＳｙｓｔｅｍｓ、ＩｎＰｒｏｃｅｅｄｉｎｇｓｏｆＩＣＳＭ’０６、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙ２００６、ｐｐ．９３−１０３．
［１２］チェン（Ｃｈｅｎ）Ｈ．、ユウ（Ｙｕ）Ｊ．、チェン（Ｃｈｅｎ）Ｒ．、ザン（Ｚａｎｇ）Ｂ．、イェウ（Ｙｅｗ）Ｐ．：ＰＯＬＵＳ：ＡＰｏｗｅｒｆｕｌＬｉｖｅ
ＵｐｄａｔｉｎｇＳｙｓｔｅｍ、ＩｎＰｒｏｃｅｅｄｉｎｇｓＩＣＳＥ’０７、ＩＥＥＥＣｏｍｐｕｔｅｒＳｏｃｉｅｔｙ２００７、ｐｐ．２７１−２８１．

Claims

アクティブに動作しているコンピュータ・システムに存在するクラスの前のバージョンのすべてのライブ・オブジェクトの、前記オブジェクトが前記クラスの前のバージョンからインスタンス化された後に動的にロードされた前記クラスの新しいバージョンの対応するオブジェクトのサロゲートオブジェクトへの透過的ランタイム・スイッチングの方法であって、オブジェクト・アイデンティティおよびクラス型代入可能性は、オブジェクトおよびクラスのサロゲートとその共存するバージョンとの間で共有され、前記方法は、
ソフトウェア更新を提供することであって、前記ソフトウェア更新は、現在動作しているシステムと前記新しいバージョンとの間の差を構成するクラス定義の変更セットのバイトコードを含む、提供することと；
新しいクラス定義の将来オンデマンド・インスタンス化される対応するオブジェクトの未初期化サロゲートになるために前記変更セット内のクラスからインスタンス化された現在ライブのオブジェクトの挙動を透過的にスイッチングすることによって、前記アクティブに動作しているコンピュータ・システムのノンブロッキング・ソフトウェア更新を実行することと；
更新されたサブクラスによって定義される拡張された挙動とオーバーライドされた挙動とのうちの少なくとも１つが更新されるブートストラップ・クラスの以前のバージョンの既にインスタンス化されたオブジェクトについて実現されるようにするために、前記ブートストラップ・クラスにバイトコードをインジェクトすることによって、前記ブートストラップ・クラスのアプリケーション・サブクラスに対する将来の更新のためにブートストラップ・クラスを準備するために、仮想マシンの固有のブートストラップ・クラスのプリブート・バイトコード変換を実行することと；
前記変換されたブートストラップ・クラスがアプリケーション・インスタンスの仮想マシン・ブートストラップ・クラスの新しいセットを構成するアプリケーション・インスタンスを実行することと；
仮想マシンにロードされるすべてのクラスのバイトコードのローディングをインターセプトすることと；
クラスローディングが開始された後に、連続するフェーズで、
対応する共存するオブジェクトおよびクラスの共有されるオブジェクト・アイデンティティおよびクラス型アイデンティティを可能にするために前記クラスの前記バイトコードを変換することと；
選択肢の間で、更新されたサブクラスによって定義される拡張された挙動とオーバーライドされた挙動とのうちの少なくとも１つが前記更新されたサブクラスの以前のバージョンの既にインスタンス化されたオブジェクトについて実現されるようにするためにシステム・クラスにバイトコードをインジェクトすることによって、前記システム・クラスのアプリケーション・サブクラスの将来の更新のために前記システム・クラスを準備するためにシステム・クラス定義のバイトコードをオンデマンドで変換することと；
アイデンティティおよび状態がノンブロッキングな形で自動的に転送される将来の対応するオブジェクトおよびクラスのサロゲートクラスおよびオブジェクトになるためにアプリケーション・クラスおよびそのインスタンスのランタイム・スイッチングを可能にする、前記アプリケーション・クラス自体へのバイトコードのインジェクトによって、前記アプリケーション・クラスを更新対応にするために前記アプリケーション・クラスのバイトコードを変換することと
を有する、方法。
ライブ・オブジェクトの前記オブジェクト・アイデンティティおよび状態は、前記クラスの、より後のバージョンのオブジェクトの新しい対応するバージョンへの動的ソフトウェア更新の後の最初の使用時に対にされ、前記方法は、
更新されたクラス・バージョンの新しい未初期化対応オブジェクトをコンストラクトす
ることと；
対応するオブジェクトの一意アイデンティティｉｄをコンストラクトし、オブジェクトの将来の機能強化されたアイデンティティ検査がその特定のバージョンに関わりなく対応するオブジェクトについて真をもたらすことを保証することと：
クラス更新の後の最初の使用時にオブジェクトの以前の対応するバージョンから状態を移植することと
を有する、
請求項１に記載の方法。
前記未初期化対応オブジェクトは、オブジェクト状態のうちで前記サロゲートオブジェクトにとって新規の部分を自動的に初期化し、前記方法は、
未初期化対応オブジェクトのコンストラクションをトリガした前記サロゲートオブジェクトにとって新規の前記状態の部分を初期化する生成されたバイトコード・メソッドをアプリケーション・クラスに挿入すること
を有する、
請求項２に記載の方法。
同一のクラスの異なるバージョンを表す複数のクラスは、共存することができ、前記方法は、
別々のクラスローダを用いて更新されたクラスをロードすることであって、したがって、同一のクラスを表す複数の型は前記仮想マシンにロードされる、ロードすることと；
言語によって定義される動的クラス型動作を実行するクラス内のバイトコードを、動的クラス検査動作のオペランドが同一の型名前空間を共有する対応するバージョンによって置換される動的クラス型検査を実行するバイトコードによって置換することと
を有する、
請求項１に記載の方法。
メソッド呼出しのフォワーディングは、オブジェクトを、そのメンバへのすべてのアクセスを同一のクラスのより新しいバージョンの新しい対応するオブジェクトにフォワードするサロゲートに変換し、前記方法は、
複数の対応するオブジェクトのいずれかを参照するクライアントが必ずそれ自体のクラスローダの到達可能な型から代入可能な型を有するオブジェクトを見ることを保証するクラスのバイトコードを変換すること
を有し、
前記変換することは、
仮想マシン・バイトコード命令であるｉｎｓｔａｎｃｅｏｆを、前記ｉｎｓｔａｎｃｅｏｆの命令の右辺オペランドの型名前空間に従う特定の対応するオブジェクト表現に対するｉｎｓｔａｎｃｅｏｆ検査を実行するバイトコードによって置換することと；
ＣＨＥＣＫＣＡＳＴと同等の仮想マシン・バイトコード命令を、前記ＣＨＥＣＫＣＡＳＴの命令の右辺オペランドの型名前空間に従う特定の対応するオブジェクト表現に対して前記ＣＨＥＣＫＣＡＳＴの命令を実行するバイトコードによって置換することと；
クラスおよびクラスの前にロードされたバージョンのオブジェクトを、すべての将来の要求を対応する新しいクラスおよびオブジェクトにリダイレクトするサロゲートにランタイム・スイッチングすることであって、新しい対応する表現から入手される可能な値は、サロゲートメンバの呼出し側の型名前空間に従うサロゲート表現によって置換され、前記リダイレクトする処理を制御する挿入されるバイトコードは、サロゲートメンバの呼出し側によって与えられたパラメータを、前記リダイレクトをする処理の受取り側の型名前空間に従う対応する表現によって置換する、ランタイム・スイッチングすることと
を有する、
請求項１に記載の方法。
サロゲートオブジェクトから対応する新しいオブジェクトへのメソッド呼出の仮想マシン表現のキャッシングは、効率的なフォワーディングを可能にする、
請求項５に記載の方法。
オブジェクト・アイデンティティは、同一のクラスの異なるバージョンのライブ・オブジェクトの間で共有され、前記方法は、
共有されるオブジェクト・アイデンティティを可能にするためにクラスのバイトコードを変換することであって、アイデンティティについてオブジェクトを比較する仮想マシン・バイトコード命令は、同一の型名前空間に属する対応するオブジェクト・バージョンを使用してアイデンティティ検査を実行するバイトコードによって置換される、変換すること
を有する、
請求項１に記載の方法。
状態は、同一のクラスの異なるバージョンからインスタンス化された複数の対応するオブジェクトの間で共有され、前記方法は、
同一のオブジェクトを表す対応するオブジェクトのセット内のどのオブジェクト・バージョンが現在個々の共有されるフィールド値を保持するのかをブックキーピングすることと；
宣言されたインスタンス・フィールドあたり１つの生成されるＧＥＴメソッド内および宣言されたインスタンス・フィールドあたり１つの生成されるＳＥＴメソッド内のフィールドアクセスをラップする、システム・クラス内のバイトコードを生成することと
を有し、
前記ＧＥＴメソッドに挿入されるアルゴリズムは、
サロゲートオブジェクト上で呼び出される時に、標準コンストラクタから当初に作成された前記対応するオブジェクトにフィールド読取要求が委譲されることを、保証することを有し、
前記ＳＥＴメソッドに挿入されるアルゴリズムは、
サロゲートオブジェクト上で呼び出される時に、標準コンストラクタから当初に作成された前記対応するオブジェクトにフィールド読取要求が委譲されることを、保証することを有し、
前記方法はさらに、
標準コンストラクタから当初に作成された前記対応するオブジェクト内のフィールドにアクセスするためにリフレクション的呼出を用いてインスタンス・フィールドにアクセスするためにバイトコード命令を置換する、ブートストラップ・クラス内のバイトコードを生成することと；
宣言されるフィールドあたり１つの生成されるＧＥＴメソッド内および宣言されるフィールドあたり１つの生成されるＳＥＴメソッド内のフィールドアクセスをラップする、アプリケーション・クラス内のバイトコードを生成することと
を有し、
前記ＧＥＴメソッドに挿入されるアルゴリズムは、
サロゲートオブジェクト上で呼び出される時に、前記サロゲートオブジェクトの最新の対応するバージョンにフィールド読取要求がフォワードされることを保証することであって、前記最新の対応するオブジェクトから入手されるフィールド値は、前記サロゲートオブジェクトの型名前空間のフィールド値に変換される、保証することと；
前記フィールド値が前記最新の対応するオブジェクト内に現在存在しない場合に、対応するオブジェクト内で前記フィールド値が検索され、まず前記最新の対応するオブジェクトの型名前空間に変換することによって転送されることを保証することと；
前記フィールド値が前記最新の対応するオブジェクト内に存在する場合に、その間に更
新がなかった場合に前記フィールド値が読み取られ、返されることを保証することと；
フィールドあたり生成される前記ＧＥＴメソッドを宣言するクラスの更新が、前記フィールド値が読み取られた後に発生する場合に、読取要求を前記サロゲートオブジェクトの前記最新の対応するバージョンにフォワードすることを保証することであって、前記最新の対応するオブジェクトから入手される前記フィールド値は、今のサロゲートオブジェクトの型名前空間のフィールド値に変換されることと
を有し、
前記ＳＥＴメソッドに挿入されるアルゴリズムは、
サロゲートオブジェクト上で呼び出される時に、前記サロゲートオブジェクトの前記最新の対応するバージョンにフィールド書込要求がフォワードされることを保証することであって、前記最新の対応するオブジェクトにフォワードされる前記フィールド値は、前記最新の対応するオブジェクトの型名前空間のフィールド値に変換されることと；
前記フィールド値が前記最新の対応するオブジェクト内に現在存在しない場合に、前記フィールド値が書込まれ、前記フィールド値を前に保持した対応するオブジェクトが、見つけられ、前の状態をクリアするように要求されることを保証することと；
前記フィールド値が前記最新の対応するオブジェクト内に存在する場合に、その間に更新がなかった場合に前記フィールド値が書込まれることを保証することと；
フィールドあたり生成される前記ＳＥＴメソッドを宣言するクラスの更新が、前記フィールド値が書込まれた後に発生する場合に、前記読取要求を前記サロゲートオブジェクトの前記最新の対応するバージョンにフォワードすることを保証することであって、前記最新の対応するオブジェクトにフォワードされる前記フィールド値は、前記最新の対応するオブジェクトの型名前空間のフィールド値に変換される、保証することと
を有する、
請求項１に記載の方法。
前のバージョンから前記最新の対応するオブジェクトへの状態の前記転送は、対応するオブジェクトによって共有される一時的ロック機構の下で実行される、
請求項８に記載の方法。
前の対応するバージョン内の状態の前記クリアは、対応するオブジェクトによって共有される一時的ロック機構の下で実行される、
請求項８に記載の方法。
共通同期化オブジェクトは、オブジェクトおよびそのサロゲートオブジェクトのグループへのスレッドに関する同期化されたアクセスを保証し、前記方法は、クラスのバイトコードを変換することを有し、
前記変換することは、
組込み同期化アクセス修飾子をバイトコードによって置換することであって、前記バイトコードは、メソッドの始めにＭＯＮＩＴＯＲＥＮＴＥＲ同等命令を挿入し、オリジナル・メソッド本体内でのキャッチされない例外に起因して発生する出口点を含むメソッドのすべての出口点にＭＯＮＩＴＯＲＥＸＩＴ同等命令を挿入し、それに基づき同期化されるオブジェクトは、対応するオブジェクトおよびクラスについて同一であることと；
言語によって定義される同期化を実行する動作を、バイトコードによって置換することであって、前記バイトコードは、それに基づいて同期化されるオブジェクトを、対応するオブジェクトについて同一である一意に識別可能なオブジェクトによって交換することとを有する、
請求項１に記載の方法。
オブジェクトは、そのメンバへのすべてのアクセスを前記クラスの最も新しいバージョンの対応するオブジェクトにフォワードすることによってサロゲートオブジェクトになり
、前記方法は、
アプリケーション・クラス内の各メソッドの始めに、バイトコードを挿入することであって、前記バイトコードは、サロゲートオブジェクトが使用可能な前記クラスの前記最も新しいバージョンからインスタンス化された前記対応するオブジェクトへの前記フォワードすることを自動的に適合させることを保証する
を有する、
請求項１に記載の方法。
オブジェクトへのアクセスは、ランタイムにメソッド本体の定義を置換することによってフォワードされる、
請求項１２に記載の方法。
ライブ・オブジェクトは、スイッチ中に前記オブジェクト内でコードを現在実行しているスレッドを全くブロックせずにサロゲートオブジェクトに動的にスイッチされる、
請求項１に記載の方法。
サロゲートオブジェクトは、前記クラスの最も新しいバージョンからインスタンス化されるオンデマンド・コンストラクトされる対応オブジェクトとともに、状態およびアイデンティティを共有する、
請求項１に記載の方法。
前記サロゲートオブジェクトは、前記クラスの最も新しいバージョンからインスタンス化されたオンデマンド・コンストラクトされた対応オブジェクトとともに、状態を共有する、
請求項１に記載の方法。
前記サロゲートオブジェクトは、前記クラスの最も新しいバージョンからインスタンス化されたオンデマンド・コンストラクトされた対応オブジェクトとともに、アイデンティティを共有する、
請求項１に記載の方法。
サロゲートオブジェクトのクライアントは、前記サロゲートオブジェクトのクラスの型への１つまたは複数の参照を保持するが、使用可能な最も新しい対応クラス・バージョンへのサロゲートメンバのフォワーディングを介して前記クラスの最も新しいバージョンのメソッド本体を使用する、
請求項１に記載の方法。
クラスのバイトコード変換は、オブジェクト状態を読み取るためにすべてのリフレクション的機構を、宣言するクラス内の関連する生成されたＧＥＴメソッドを呼び出すバイトコードによって直接に置換する、
請求項１に記載の方法。
クラスのバイトコード変換は、オブジェクト状態を書込むためにすべてのリフレクション的機構を、宣言するクラス内の関連する生成されたＳＥＴメソッドを呼び出すバイトコードによって直接に置換する、
請求項１に記載の方法。
アプリケーション・クラスのバイトコード変換は、クラス初期化メソッドの始めにバイトコードを挿入することによって、前記クラスの以前のバージョンが前記仮想マシンに前にロードされている場合にクラス初期化メソッド内のオリジナル・コードが実行されない
ことを保証する、
請求項１に記載の方法。
クラスのバイトコード変換は、オブジェクト・コンストラクタの始めにバイトコードを挿入することによって、コンストラクションが宣言するコンストラクタのサブクラスのサロゲートインスタンスに対して発生する場合に、コンストラクタが、オリジナル・コードを実行せず、コンストラクタ呼出を前記クラスの最も新しいバージョンの前記対応するオブジェクトにリダイレクトしないことを保証する、
請求項１に記載の方法。
クラスの前記バイトコード変換は、オブジェクト・ファイナライザの始めにバイトコードを挿入することによって、ファイナライゼーションがサロゲートオブジェクトに対して発生する場合に、ファイナライザが、オリジナル・コードを実行せず、ファイナライズ呼出を最も新しい対応するオブジェクトにリダイレクトしないことを保証するために、
請求項１に記載の方法。
クラスの前記バイトコード変換は、言語によって定義されるクローン作成のオカレンスをバイトコードによって置換し、前記バイトコードは、作成されるクローンがクローンを作成されるオブジェクトのすべての対応するオブジェクトによって共有される状態と同等の状態を含むことを保証する
請求項１に記載の方法。
クラスの前記バイトコード変換は、オブジェクト・シリアル化のオカレンスをバイトコードによって置換し、前記バイトコードは、シリアル化されるオブジェクトを最新の対応するオブジェクトによって置換し、
前記挿入されるバイトコードは、共有されるオブジェクト状態が、前記シリアル化の処理を継続する前に前記最新の対応するオブジェクトに転送されることを保証する、
請求項１に記載の方法。
クラスの前記バイトコード変換は、配列にアクセスする命令を、アクセス要求を最新の対応する配列オブジェクトにリダイレクトするバイトコードによって置換し、前記方法は、
置換された配列読取動作によって入手される値を、呼出し側クラスの型名前空間の値に変換することと；
置換された配列書込動作で使用される値を、最新の対応する配列オブジェクト型名前空間の値に変換することと
を有する、
請求項１に記載の方法。
動的にロードされたクラスの新しいバージョンの型情報は、前記クラスの前にロードされたバージョンの継承階層とは異なる継承階層を示す、
請求項１に記載の方法。
動的にロードされたクラスの新しいバージョンの型情報は、前記クラスの前にロードされたバージョンのインターフェースとは異なるインターフェースを示す、
請求項１に記載の方法。
動的にロードされたクラスの新しいバージョンのメソッド宣言は、前記クラスの前にロードされたバージョンのメソッド宣言とは異なる、
請求項１に記載の方法。
動的にロードされたクラスの新しいバージョンのフィールド宣言は、前記クラスの前にロードされたバージョンのフィールド宣言とは異なる、
請求項１に記載の方法。
前記クラスは、コンパイル中に静的に型検査される、
請求項１に記載の方法。
クラスは、バイトコードによって表される、
請求項１に記載の方法。
代替ブートクラス・パスを提供せずに前記仮想マシンを始動することは、ブートストラップ・クラスの静的バイトコード変換を開始し、前記方法は、
・既にロードされているブートストラップ・クラスのバイトコードを変換することと；
・結果の変更されたブートストラップ・クラスを代替ブートクラス・パスに格納することと；
・バイトコード変換の完了時にプログラム・コードのさらなる実行をすべて放棄し、効果的にコンピュータ・プログラムを終了させることと
を有する、
請求項１に記載の方法。
代替ブートクラス・パスを伴って前記仮想マシンを始動することは、ブートストラップ・クラスの代替セットを用いて前記仮想マシンのブートを開始する、
請求項１に記載の方法。
代替ブートクラス・パスを提供せずに前記仮想マシンを始動することは、ブートストラップ・クラスの動的バイトコード変換を開始し、前記方法は、
・既にロードされているブートストラップ・クラスのバイトコードを変換することと；
・結果の変更されたブートストラップ・クラスを、代替ブートクラス・パスに格納することと；
・前記仮想マシンの特殊なプログラム・スタートアップ・メソッドを宣言するすべての非ブートストラップ・クラスのバイトコードのロードをインターセプトすることによって、前記特殊なプログラム・スタートアップ・メソッドにハンドリングされるプログラム入力引数をインターセプトするためのバイトコードを挿入することと；
・すべてのプログラム入力引数を提供して新しい仮想マシン・インスタンスを始動することであって、オプションの仮想マシン引数は、前記代替ブートクラス・パスを含む、始動することと；
・前記新しい仮想マシン・インスタンスが終了するのを待ち、アウェイクした後に、プログラム・コードのさらなる実行をすべて放棄し、効果的にコンピュータ・プログラムを終了させることと
を有する、
請求項１に記載の方法。
コンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は、
・コンピュータ使用可能媒体と；
・アクティブに動作するコンピュータ・システム内のソフトウェア・モジュールを動的にリフレッシュするために前記コンピュータ使用可能媒体上で実施された、請求項１乃至３５のいずれか１項のステップを実行するようにコンピュータに指示するコンピュータ可読命令と
を備える、コンピュータ・プログラム製品。
システムであって、前記システムは、クラスがバイトコードによって表される静的に型付けされたクラスベースのオブジェクト指向プログラミング言語で記述されたアクティブに動作するコンピュータ・ソフトウェアのノンブロッキング動的更新を可能にするためにコンピュータ内で実施され、
前記システムは、請求項１乃至３５のいずれか１項のステップを実行する手段からなる、システム。