JP2008217786A - コンピューティング環境内のメモリ管理方法、メモリ管理システム及びコンピュータ・プログラム - Google Patents

Abstract

【課題】コンピューティング環境内でメモリを管理するためのシステム及び方法を提供する。
【解決手段】
この方法は、コンピューティング環境内で実行されるアプリケーションのための第１のタスクに関連する第１のオブジェクトを一意的に識別するステップを含む。前記第１のオブジェクトには、第１のメモリ領域が割り振られる。また、この方法は、前記第１のタスクに関連する第１の実行コンテキストに従って、前記第１のタスクのための第１の実行スコープを決定するステップを含む。前記第１のコンテキストは、前記実行環境階層内の前記第１のタスクのための第１の予測存続時間を定義する。さらに、この方法は、前記第１の実行コンテキストをモニタすることに応答して、前記第１のタスクの実行スコープの変化を決定するステップと、前記第１のタスクがもはや前記第１の実行スコープ中で実行されないと決定することに応答して、前記第１のメモリ領域の割り振りを解除するステップとを含む。
【選択図】図３

Description

本発明は、コンピューティング環境内のメモリ管理に係り、さらに詳細に説明すれば、コンピューティング環境内で実行されるタスクに対し、当該タスクの実行スコープに基づいてメモリ空間を決定論的に割り振り及び割り振り解除するシステム及び方法に係る。

コンピューティング環境内のメモリ管理は、特定のメモリ管理方式に従って、実行可能な論理コード（すなわち、ソフトウェア・プログラム）をロードするためのコンピュータ・メモリの部分を予約したり、その後の再使用に備えてメモリを解放することを必要とする。一般に、メモリを予約するプロセスを、論理オブジェクトに対するメモリ空間の「割り振り」（allocating）と称し、メモリを解放するプロセスを、メモリ空間の「割り振り解除」（deallocating）と称する。

割り振り解除方式は、使用するプログラミング言語のタイプに依存して、「ガーベジ・コレクション」プロセスを含むことがある。「ガーベジ」とは、プログラムの適切な実行にもはや必要とされない、論理オブジェクトに割り振られたメモリ空間を意味する。一般に、かかるガーベジ・オブジェクトが集められると、対応するメモリ空間の割り振りが解除される。

従来技術では、手動的及び自動的なメモリ管理方式が実装されている。手動方式では、プログラマは、未使用オブジェクトに関連するメモリ空間を識別し且つその割り振りを解除するための命令を、論理コード内にアクティブに挿入しなければならない。自動方式は、プログラミング言語のレベルでのみ使用され、システムのメモリが少なくなっていることを検出する場合に限り、ガーベジ・コレクション・サイクルを開始させる。

しかし、これらの２つの方式は、ウェブ・サーバと１つ以上のクライアント・マシンの間で確立される多数のセッションをサポートする、インターネット・ベースのアプリケーション（すなわち、ウェブ・アプリケーション）のようなメモリ集約的なソフトウェア・アプリケーションでは、最適の結果を提供しない。例えば、ウェブ・セッション中に１つ以上のクライアントからウェブ・サーバに発信される複数の要求にサービスを提供するために複数のサーブレットが利用される場合には、メモリ管理は、一段と厄介で且つ複雑なものとなる。

一般に、セッション中にメモリが論理オブジェクトに割り振られる場合、この論理オブジェクトに対応するタスクが当該セッションの全長にわたってアクティブ状態又は非アクティブ状態の何れにあるかに拘わらず、メモリは、当該セッションが終了するまで割り振られたままに留まる。複雑なウェブ・アプリケーションは、各セッション中に多数の論理タスク及びサーブレットの実行をサポート及び必要とすることがある。もし、各セッションの終わりまで又はメモリが不十分な状態でシステムが稼働するようになるまで、ガーベジ・コレクション・プロセスが遅延されるならば、ウェブ・サーバは速やかにメモリを使い果たし且つ回復不能になることがあるので、ウェブ・サーバの性能が悪影響を受けることになろう。

従って、当分野では、前述の欠点を克服することができるメモリ管理方法及びシステムが要請されている。

本発明は、コンピューティング環境内のアクティブ・タスクのための１つ以上の実行スコープ（execution scope）を定義することにより、コンピューティング環境内のメモリ管理を容易にするシステム及び対応する方法に向けられる。

本明細書では、本発明の特定の側面、利点及び新規な機能を簡潔に説明する。しかし、本発明の特定の実施形態では、かかる利点の全てが達成されるとは限らないことに留意されたい。従って、本発明は、本明細書で教示又は示唆されている全ての利点を達成することなく、そのうちの１つの利点又は１群の利点を達成するように実施することができる。

第１の実施形態に従って、コンピューティング環境内のメモリ管理方法が提供される。この方法は、コンピューティング環境内で実行されるアプリケーションのための第１のタスクに関連する第１のオブジェクトを一意的に識別するステップを含む。前記第１のオブジェクトには、第１のメモリ領域が割り振られる。また、この方法は、前記第１のタスクに関連する第１の実行コンテキストに従って、前記第１のタスクのための第１の実行スコープを決定するステップを含む。前記第１のコンテキストは、実行環境階層内の前記第１のタスクのための第１の予測存続時間を定義する。さらに、この方法は、前記第１の実行コンテキストをモニタすることに応答して、前記第１のタスクの実行スコープの変化を決定するステップと、前記第１のタスクがもはや前記第１の実行スコープ中で実行されないと決定することに応答して、前記第１のメモリ領域の割り振りを解除するステップとを含む。

第２の実施形態に従って、コンピューティング環境内のメモリ管理システムが提供される。このシステムは、コンピューティング環境内で実行されるアプリケーションのための第１のタスクに関連する第１のオブジェクトを一意的に識別する論理装置を備える。前記第１のオブジェクトには、第１のメモリ領域が割り振られる。また、このシステムは、前記第１のタスクに関連する第１の実行コンテキストに従って、前記第１のタスクのための第１の実行スコープを決定する論理装置を備える。 前記第１のコンテキストは、実行環境階層内の前記第１のタスクのための第１の予測存続時間を定義する。さらに、このシステムは、前記第１の実行コンテキストをモニタすることに応答して、前記第１のタスクの実行スコープの変化を決定する論理装置と、前記第１のタスクがもはや前記第１の実行スコープ中で実行されないと決定することに応答して、前記第１のメモリ領域の割り振りを解除する論理装置とをさらに備える。

第３の実施形態では、前記方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラムが提供される。

本発明は、多数の論理タスク及びサブタスクが実行されるアプリケーション環境内のメモリ管理を容易にするシステム及び対応する方法に向けられる。メモリ管理方法は、１つ以上のタスク及びサブタスクのための種々の実行スコープ（例えば、セッション・スコープ、タスク／サブタスク・スコープ及び現在のスコープ）を定義し且つモニタするように実装される。その結果、前記タスクに関連するオブジェクトは、前記定義された実行スコープに従って、メモリから除去されるようになる。

以下では、本発明の種々の実施形態を十分に説明するために、多数の詳細事項を記述する。発明の特定の実施形態は、かかる詳細事項を用いることなく、又はその幾つかの変形版を用いて、実施することができる。或る場合には、本発明の他の側面を不明瞭にしないように、特定の機能を必要以上に詳細に記述しないことにする。各要素又は各機能に関連する記述の詳細度は、１つの機能が他の機能に比べてより新規又は重要であることを意味するものと解釈すべきではない。

例えば、以下では、ウェブ・ベースの環境内で実行されるサーブレットに適用可能なものとして、本発明の特定の側面を開示する。しかし、かかるアプリケーションは、一例に過ぎないので、本発明の範囲は、かかる実施形態に限定されるものと解釈すべきではない。代替実施形態では、本明細書に開示したシステム及び方法を、任意のコンピューティング環境内でメモリを管理するために適用することができる。

図１は、サーバ・システム（以下「サーバ」と略記）１１０が通信ネットワーク（以下「ネットワーク」と略記）１３０を介してクライアント・システム（以下「クライアント」と略記）１２０と通信関係にある、代表的なコンピューティング環境を示す。この実施形態では、ネットワーク１３０は、サーバ１１０及びクライアント１２０を含む多数のコンピューティング・システムが互いに通信するように相互に接続される、インターネット（すなわち、ワールド・ワイド・ウェブ（ＷＷＷ））上に実装される。しかし、代替実施形態では、実装に依存して、ネットワーク１３０を、ローカル、リモート又は分散フレームワークに従って構築することができる。

好ましくは、サーバ１１０は、ウェブ・サーバであり、クライアント１２０は、ネットワーク１３０を介してサーバ１１０に要求を発信するためのクライアント・ソフトウェア環境１２５を有するコンピュータである。図示のように、サーバ１１０のサーバ・ソフトウェア環境１１５は、クライアント１２０によって発信された要求に応答するように構成される。ネットワーク１３０上の要求及び応答の交換は、クライアント１２０の要求にサービスを提供するためにサーバ１１０とクライアント１２０の間で確立される、１つ以上のセッションのコンテキスト内で行われる。

発信された要求には、サーバ・ソフトウェア環境１１５内で実行中のアプリケーション１５０によってサービスを提供することができる。アプリケーション１５０は、例えばウェブ・ベースの環境内に持続する論理コード（例えば、Ｊａｖａ（登録商標）アプレット、Ｊａｖａ（登録商標）サーブレット又は他の機能的に同等のモジュール）とすることができる。すなわち、セッション中に受け取られた第１の要求に応答してアプリケーション１５０が一旦呼び出されると、アプリケーション１５０は、当該セッションの残りの間に発信される１つ以上の後続の要求を実行するためにメモリ内でアクティブに留まるのが好ましい。

このように、アプリケーション１５０がメモリ内に持続すると、クライアント１２０の要求に対し有効に応答することができる。従って、要求が実行された後にサーバ１１０の実行環境から除去されるような他のアプリケーション（例えば、コモン・ゲートウェイ・インタフェース（ＣＧＩ）プログラム）とは対照的に、メモリ内に持続するアプリケーション１５０は、要求にサービスを提供する度に必要とされるような設定及び解放手順に関連する遅延時間を回避することができるという点で有利である。

次に、図１及び図２を参照して説明する。実施形態では、アプリケーション１５０は、例えば、クライアント１２０から発信される１つ以上の要求に応答して、サーバ１１０によって起動される（Ｓ２１０）。アプリケーション１５０は、クライアントの数又は発信される要求の数に依存して、１つ以上のセッションを管理することができる（Ｓ２２０）。各セッション中、アプリケーション１５０は、図１に示す１つ以上のタスク及びサブタスク（例えば、タスク１〜３、サブタスク１〜６等）を開くように実行することができる。

これらのタスク及びサブタスクは、例えば、クライアント要求にサービスを提供するように構成されるサーブレット、Ｊａｖａ（登録商標）サーバ・ページ（ＪＳＰ）又は他のプログラミング・アプリケーション（例えば、アプリケーション・プログラム・インタフェース（ＡＰＩ））によって実行又は管理される、１つ以上の動作に関連する。図示のように、或るタスク（例えば、タスク２）は、同じセッション中に開くことができる、１つ以上のサブタスク（例えば、サブタスク３〜５）を有することがある。また、各サブタスクも、１つ以上の他のサブタスクを有することがある。

各タスク又はサブタスクは、一旦開かれると、メモリ空間が割り振られる少なくとも１つの論理オブジェクトに関連付けられる。各オブジェクトは、そのタスク又はサブタスクのための関連する動作を行うように実行される。各セッション中、実装に依存して、種々の管理方式を使用することにより、各タスク／サブタスク及びこれに関連する割り振り済みのメモリ空間を管理することができる。例えば、或る論理モジュール（例えば、セッション・マネージャＡＰＩ）を使用することにより、各タスク／サブタスクに関連するセッション・オブジェクトを追加又は除去することができる。

セッション・マネージャは、例えば要求にサービスを提供するために新しいタスク／サブタスクがアプリケーション１５０によって開かれるか否かを決定する（Ｓ２３０）。新しいタスク／サブタスクが開かれる場合、セッション・マネージャは、実行階層内でタスク及び関連するサブタスクを追跡するために、データ構造（例えば、記述子ファイル）をモニタ又は編集する。好ましくは、セッション・マネージャは、タスクの実行スコープに従って、アプリケーション１５０によって開かれる各タスクに対し、一意的な識別子を割り当てる。この一意的な識別子は、以下で詳述するように、タスク・タイプを定義するとともに、各タスク／サブタスクを分類するために使用することができる。

記述子ファイルは、各タスク・タイプの記述を定義する、エクステンシブル・マークアップ言語（ＸＭＬ）のようなプログラミング言語の構文を含む。例えば、記述子ファイルの要素は、各タスクの構成要素を定義することができる。定義された各タスク・タイプごとに、デフォルトの特定構成要素を、タスク・タイプの定義内でタスクの初期デフォルト構成要素として識別することができる。従って、開発者は、ユーザが行うことができる１組のタスクを定義することにより、各タスク・タイプごとに、１つ以上の特定構成要素（例えば、代替のＪＳＰページ）を定義することができる。

新しいタスク／サブタスクが開かれる場合、或る論理モジュール（例えば、スコープ・マネージャＡＰＩ）を使用して、当該新しいタスク／サブタスクの実行スコープを決定する（Ｓ２４０）。実施形態では、スコープ・マネージャを使用することにより、各タスク／サブタスクに関連し且つセッション中に共有されるオブジェクトをモニタする。従って、スコープ・マネージャは、セッション・オブジェクトの生成（すなわち、割り振り）及び除去（すなわち、割り振り解除）を管理するとともに、当該セッションへのオブジェクトの追加又は当該セッションからのオブジェクトの除去を要求する能力をサポートする。

次に、図３を参照して説明する。スコープ・マネージャは、セッション中に開かれたタスク／サブタスクのための許可された実行スコープも定義するように実装される（Ｓ３１０）。すなわち、スコープ・マネージャは、現在のアプリケーション・フローに関して各タスクに対応する１つ以上のオブジェクトの存続時間粒度（lifetime granularity）を指定するとともに、当該オブジェクトの許可された実行スコープを更新するように実装される。許可された実行スコープを定義すると（すなわち、セッション中のタスク／サブタスクのための多層の存続時間粒度を定義すると）、サーバ１１０のメモリ空間が臨界的に低いしきい値に達する前に、そして当該タスク／サブタスクに対応する１つ以上のオブジェクトがその内部に持続するような当該セッションが終了する前に、種々の実行コンテキスト又はレベルで当該オブジェクトに割り振られたメモリ空間を解放する可能性に備えることができる。

スコープ・マネージャは、例えば、タスク／サブタスクがセッションに追加される時点において、当該タスク／サブタスクのための許可された実行スコープ及び当該タスク／サブタスクに対応するオブジェクトを定義する。実行スコープは、次の３つのスコープ又はコンテキストに従って定義することができる。
（１）アプリケーション・コンテキスト
（２）タスク／サブタスク・コンテキスト
（３）現在のコンテキスト
しかし、実装に依存して、他のコンテキスト又は基準を指定できることに留意されたい。但し、本明細書の記述を簡潔にするため、以下では、前述の３つの実行コンテキストに基づいて説明する。

アプリケーション・コンテキストでは、アプリケーション１５０に関連するオブジェクトは、当該セッションの間アクティブに維持される。すなわち、アプリケーション１５０の動作を制御する対応するオブジェクトは、当該セッションが終了するまで、実行環境から除去されない。アプリケーション・コンテキストは、種々のタスク／サブタスク間で共有され且つ潜在的に更新される状態情報のための実行スコープを定義するために使用することができる。例えば、サーバ上の定義されたノード及びスケジュールを概説するサーバ状態構造は、多数のタスク、コンピュータ、アプリケーション、ノード・グループ及びスケジュールから更新することができ、当該セッションの存続時間にわたって持続することが好ましい。

タスク／サブタスク・コンテキストでは、開かれたタスク／サブタスクに関連するオブジェクトは、当該タスク／サブタスクの実行期間（すなわち、当該タスク／サブタスクが発信された要求に応答するためにアクティブである間）にわたって維持される。例えば、IBM Tivoli Storage Manager（ＩＴＳＭ）のノード・グループ・タスクでは、ＩＴＳＭサーバに対して定義されたノード・グループに関する関係情報、現在の状態及びタスク構成要素のための情報データ（例えば、当該ノード・グループ・タスクで起動されたウィザード、ノートブック及びフォーム）は、対応するタスクの終了まで維持される。

現在のコンテキストでは、アクティブなタスク／サブタスクに関連するオブジェクトは、その時点でアクティブなタスク／サブタスクの構成要素の期間にわたって維持される。例えば、ＩＴＳＭのノード・グループ・タスクでは、特定のコンピュータ又はアプリケーションのノートブックがユーザに表示される前に、当該コンピュータ又はアプリケーションが選択される場合、ファイル空間テーブル・データが当該ノートブックに関連することがある。かかるシナリオでは、現在のコンテキストは、例えば、一意的なＪＳＰページに関連する。

そのため、スコープ・マネージャは、予め定義された実行コンテキストに従って、セッション中の各タスク／サブタスクのための実行スコープをモニタする（Ｓ３２０）。当該タスク／サブタスクが許可された実行スコープ中に実行を完了した場合（Ｓ３３０）、スコープ・マネージャは、実行環境から当該タスク／サブタスクに関連するオブジェクトを除去する（Ｓ３４０）。また、セッションが終了する場合（Ｓ３５０）、セッション・マネージャは、アプリケーションに関係する全て又は一部のセッション・オブジェクトを除去する（Ｓ３６０）。

以下では、Ｊａｖａ（登録商標）オブジェクト・クラスに従って実装された代表的なスコープ・マネージャのインタフェースを開示する。しかし、開示された主題を異なるプログラミング言語で実装したり、修正することが可能であるので、本発明の範囲は、この実施形態に限定されるものと解釈すべきではない。
public class DsmScopeManager
{
public static final byte COMP_SCOPE;
public static final byte TASK_SCOPE;
public static final byte CCT_SCOPE;
public static final void add (byte scope, String scopeID, Object value, HttpSession session);
public static final void add (byte scope, final Object[][]attrs, HttpSession session);
public static final void addPersistent (String scopeID, Object value, byte scope, HttpSession session);
public static final void makePersistent (String scopeID, byte scope, HttpSession session);
public static final HashSet getScopeAttrSet (byte scope, HttpSession session);
public static final void cleanUp (byte scope, HttpSession session);
public static final void cleanUpTask (WccContext, wccContext, HttpSession session);
…
}

以下で説明する代表的なフレームワークは、スコープ・マネージャの機能性をサポートする。このフレームワークは、アプリケーション１５０の実行時フローを管理するソフトウェア・アプリケーションであって、好ましくは、アプリケーション、タスク及びタスク特有の構成要素を検出するようにウェブ・コンテナ内で実装される。さらに、このフレームワークは、ユーザ・フローの状態及びオブジェクトの実行スコープを検出することに加えて、適切なメモリ管理及びオブジェクトのクリーンアップ方式を決定することを支援する。

実施形態では、このフレームワークは、アプリケーション・フローを検出し且つアクティブ・タスク及びそれらの関連する構成要素をモニタするために使用される、１組の関連するクラスから成る。このフレームワークを使用すると、現在アクティブなタスク、現在ユーザに表示されているタスク、各タスクのための現在アクティブな構成要素、及びそれらの構成要素がユーザに表示されていたフローを、モニタ及び決定することができる。

特定のクラス（例えば、DsmTasksFactoryクラス）は、適切なタスク及び関連する構成要素を識別するために実装することができる。実施形態では、かかるクラスは、例えば、singletonクラスとして実装される。singletonクラスは、単一のインスタンスがそのために作成されるクラスである。

好ましくは、前記クラスは、所与のＤＳＭタスク・タイプをサポートするための情報を提供し、入力として、例えば、各ＤＳＭタスク・タイプを記述するＸＭＬアプリケーション記述子ファイルを取る。かかるＸＭＬファイルの要素は、或るタスクを起動するのに必要な予め定義された情報項目を提供し、また可能であれば、タスク特有の構成要素がマップされるネストされた構成要素（例えば、タスクのＪＳＰページ及び代替的なＪＳＰページ）を起動するのに必要な予め定義された情報項目を提供することができる。

実施形態では、メソッド・インタフェースは、タスク・スコープの属性セットアップに対するアクセスをサポートする。コントローラ（例えば、DsmTaskController）クラスは、タスクに関係するイベントを処理する役割を有し、アプリケーション１５０内の各タスクの論理タスク及び内容の生成及び管理をサポートすることができる。このコントローラは、１つ以上のタスクを活動化、非活動化又は終了するというような、特定のタスク・イベントを管理する役割を、或るアプリケーション・モジュール（例えば、タスク・イベント・リスナ）に委任する。

従って、このフレームワークは、或るセッションにおけるセットアップ、ステータス、実行階層、１つ以上のタスクのスコープ及び関係するイベントをモニタし且つこれらを制御する。従って、実施形態では、このフレームワークは、タスク・ビューを含むタスク・フレーム（例えば、ＪＳＰ）を作成し、そして好ましくは、タスク・ヘルプのようなタスク特有の他の特性を識別する。或る処理モジュールは、応答を生成し、これをユーザのブラウザに送信してアプリケーション・ユーザ・インタフェースの所与のタスク・セクションを表示するか、又は当該タスクが既に存在する場合にはそのセクションを更新する。

タスク／サブタスクが完了する時点では、これに関連するスコープ属性がクリーンアップされ、セッション実行環境から除去される。また、スコープ・コンテキストを追跡する、フレームワークが作成したオブジェクト構造も、これを無視することが好ましい。実施形態では、或るクラス（例えば、DsmConsoleContext）を定義し、これをサポート用フレームワークの観点から見たアプリケーション１５０の状態に関する情報から構成する。前記クラスは、現在のアプリケーション・セッションの存続時間にわたって持続すべきセッション・スコープ名を全て蓄積する。

実施形態では、或るサーブレット又はポートレット・パッケージは、セッション中に資源を管理するのを支援するためのインタフェース及びクラス（例えば、HttpSessionBindingListener インタフェース及び HttpSessionBindingEvent クラス）を提供する。例えば、或るオブジェクト（例えば、DsmConsoleContext オブジェクト）は、或るセッション（例えば、HttpSession）に関連付ける（例えば、バウンドする）ことができる。この関連付けを通して、このフレームワークは、セッションの終了を検出し、その結果、対応するオブジェクトを実行環境から除去することができる。

実施形態では、或る定義されたコンテキスト・クラス（例えば、DsmConsoleContext）は、前記セッション（例えば、HttpSession）に対する参照を有し、その逆も同様である。この定義されたコンテキスト・クラスが前記セッションから分離（例えば、アンバウンド）される場合、前記セッションと前記コンテキストの間の２重の参照が除去される。この２重の参照は、前記セッション又は前記コンテキストの何れかが利用可能であれば、このフレームワークが前記セッションにアクセスすることを可能にする。

他のコンテキスト・クラス（例えば、WccContext クラス）は、タスク・ナビゲーション及び属性スコープの現在の状態をモニタするために実装することができる。このクラスは、種々の実行スコープ中に現在表示されている又はアクティブなタスクをモニタするとともに、例えば、受信された要求に応答して、オン・デマンドで作成又は削除される対応するオブジェクト・インスタンス（例えば、DsmTask インスタンス）を追跡する。

実施形態に従って、アプリケーション１５０が起動される場合、或るデフォルト・タスクが作成され、現在表示されているタスクを表すものと仮定される。或るオブジェクト・クラス（例えば、DsmTask クラス）は、或るタスクのための属性メモリ管理情報を定義し、好ましくは、当該タスクのための一意的な識別子及び当該タスクの存続時間にわたってセッション・スコープ中に維持される１組の持続属性に関係する情報を保持する。種々の実行スコープ中に或るタスクのために追加情報が蓄積されると、前記オブジェクト・クラス（例えば、DsmTask クラス）は、当該タスクの構成要素の表示フローをモニタする。そのため、現在のタスク構成要素は、このクラスによってモニタされる。

幾つかの実施形態では、或るタスクが最初に開かれる場合、対応するタスク・タイプのための記述子ファイルで定義されるように、当該タスクの主構成要素が現在のコンテキストを表すものと仮定される。このフレームワークは、或るイベントに基づいて所与のタスク・タイプが表示することができる、主要なビュー・ページ及びゼロ以上の代替的ビュー（例えば、ＪＳＰページ）の定義を提供することが好ましい。実施形態では、主要なページは、デフォルトで表示される。

１つ以上の実施形態に従って、他のコンテキスト・クラス（例えば、DsmContextSwitch クラス）は、予め定義されたイベントに応答して、表示された現在のコンテキストを切り替えるか、又はアプリケーション・コンソールの内容を変更するために使用することができる。例えば、ブラウザ・ビューは、最初にメディア・コピーのテーブルを示すページを表示することができる。このテーブルによってサポートされるアクションは、ユーザが、例えば、ウィザードを使用してメディア・グループを作成することを可能にする。

実施形態では、サーバ１１０は、例えば、第１のコンテキストから第２のコンテキストに切り替えるためのメディア・グループ作成要求に応答して、前記テーブル・ページを置換するためにメディア・グループ・フォームを作成する。これらの２つのコンテキスト間で引き渡される任意の情報は、属性として当該セッション中に置くことができる。かかる属性は、例えば、新しく起動される構成要素の存続時間にわたって、初期セットアップ又はナビゲーション・ガイダンスを定義するために必要である。かかる属性は、例えば、自己完結型オブジェクト・インスタンス（例えば、DsmComponentContext クラス・インスタンス）内に蓄積することができる。このフレームワークが起動中の構成要素へのスイッチバックを検出する場合、最小の粒度レベルを有する属性を当該セッションの実行環境から除去することが好ましい。

異なる実施形態では、本発明は、完全なハードウェア、完全なソフトウェア又はハードウェア及びソフトウェア要素の両方の組み合わせのうち、何れかの形態で実装することができる。例えば、クライアント１２０及びサーバ１１０が構成することができる制御されたコンピューティング・システム環境は、本発明のシステムが意図する結果を達成するプロセスを実施するように実行される、ソフトウェア・コードとハードウェア構成要素の組み合わせの形態で提供することができる。

図４及び図５は、実施形態に従ったコンピューティング・システム環境を構成する、ハードウェア環境１１１０及びソフトウェア環境１１２０を示す。ハードウェア環境１１１０は、ソフトウェアのための実行環境を提供する各装置から成り、当該ソフトウェアは、以下で説明するハードウェアのための実行命令を提供する。

以下、図示のハードウェア要素上で実行されるソフトウェア要素を、特定の論理的／機能的関係の観点から説明する。しかし、ソフトウェアの形態で実装される各方法は、例えば、構成済みのプログラム式プロセッサ、ＡＳＩＣ（特定用途向けＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）及びＤＳＰ（デジタル信号プロセッサ））を使用することにより、ハードウェアの形態でも実装できることに留意されたい。

ソフトウェア環境１１２０は、主として、システム・ソフトウェア１１２１及びアプリケーション・ソフト１１２２に分割される。システム・ソフトウェア１１２１は、ハードウェアに対しどのように機能し且つ情報をどのように処理するかを命令する、オペレーティング・システム（ＯＳ）及び情報管理システムのような制御プログラムから成る。

推奨実施形態では、アプリケーション１５０は、クライアント１２０によって発信された１つ以上の要求にサービスを提供するために１つ以上のハードウェア環境上で実行される、アプリケーション・ソフト１１２２として実装される。アプリケーション・ソフト１１２２は、プログラム・コード、データ構造、ファームウェア、常駐ソフトウェア、マイクロコード等から構成することができる。

代替実施形態では、本発明は、コンピュータ又は任意の命令実行システムに関連して又はこれらによって使用するためのプログラム・コードを提供する、コンピュータ使用可能媒体又はコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム製品として実装することができる。この記載の目的上、コンピュータ使用可能媒体又はコンピュータ可読媒体は、コンピュータ又は任意の命令実行システムに関連して又はこれらによって使用するためのプログラムを保持し、格納し、通信し、伝送し、移送することができる、任意の装置とすることができる。

コンピュータ可読媒体は、電子、磁気、光学、電磁気、赤外線又は半導体システム（装置）又は伝送媒体とすることができる。コンピュータ可読媒体の例には、半導体又は固体メモリ、磁気テープ、取り外し可能なフレキシブル・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛体磁気ディスク及び光ディスク等がある。光ディスクの例には、読み取り専用のＣＤ−ＲＯＭ、読み書き可能なＣＤ−Ｒ／Ｗ及びＤＶＤがある。

図４を参照して説明すると、アプリケーション・ソフト１１２２は、システム・バス１１００を介して１つ以上のメモリ要素に結合されたプロセッサ１１０１を含むハードウェア環境１１１０のようなデータ処理システム上で実行される、コンピュータ可読コードの形態を有するコンピュータ・ソフトウェアとして実装することができる。これらのメモリ要素は、例えば、ローカル・メモリ１１０２、記憶媒体１１０６及びキャッシュ・メモリ１１０４を含むことができる。プロセッサ１１０１は、記憶媒体１１０６からローカル・メモリ１１０２に、実行可能コードをロードする。キャッシュ・メモリ１１０４は、コードが実行のために記憶媒体１１０６からロードされる回数を減少させるために、一時的記憶装置を提供する。

ユーザ・インタフェース装置１１０５（例えば、キーボード、ポインティング装置等）及び表示スクリーン１１０７は、当該コンピューティング・システムに対し直接的に、又はＩ／Ｏコントローラ１１０３を通して、結合することができる。また、ネットワーク・アダプタのような通信インタフェース・ユニット１１０８を当該コンピューティング・システムに結合すると、当該データ処理システムは、私設又は公衆ネットワークを通して、他のデータ処理システム又はリモートのプリンタ若しくは記憶装置と通信することができる。ネットワーク・アダプタの代表的なタイプには、有線又は無線のモデム及びイーサネット（登録商標）カードがある。

１つ以上の実施形態では、ハードウェア環境１１１０は、前述の全ての構成要素を含むとは限らないし、又は追加の機能性又はユーティリィティのために他の構成要素を含むことができる。例えば、ハードウェア環境１１１０は、ラップトップ・コンピュータとすることができるし、或いは組み込みシステム内に実装された他のポータブル計算装置（例えば、セット・トップ・ボックス、パーソナル・データ・アシスタント（ＰＤＡ）、移動通信ユニット、又は情報処理能力やデータ記憶及び通信能力を有する他の同様のハードウェア・プラットフォーム）とすることができる。

当該システムの幾つかの実施形態では、通信インタフェース１１０８は、プログラム・コードを含む種々のタイプの情報を表すデジタル・データ・ストリームを搬送する、電気信号、電磁気信号又は光信号の送受信を行うことにより、他のシステムと通信する。かかる通信は、リモートのネットワーク（例えば、インターネット）を介して、又は搬送波の伝送を介して、確立することができる。

図５を参照して説明すると、アプリケーション・ソフト１１２２は、記憶媒体１１０６からローカル・メモリ１１０２にロードされた後、システム・ソフトウェア１１２１の上部で実行される、１つ以上のコンピュータ・プログラムを含むことができる。クライアント−サーバ・アーキテクチャでは、アプリケーション・ソフト１１２２は、クライアント・ソフトウェア及びサーバ・ソフトウェアを含むことができる。例えば、本発明の実施形態では、クライアント・ソフトウェアは、コンピューティング・システム１００上で実行され、サーバ・ソフトウェアは、サーバ・システム（図示せず）上で実行される。

また、ソフトウェア環境１１２０は、ローカル又はリモートのコンピューティング・ネットワークを介して、利用可能なデータにアクセスするためのブラウザ・ソフトウェア１１２６を含むことができる。さらに、ソフトウェア環境１１２０は、ユーザ・コマンド及びデータを受け取るための、ユーザ・インタフェース１１２４（例えば、グラフィカル・ユーザ・インタフェースＧＵＩ（ＧＵＩ））を含むことができる。前述のハードウェア及びソフトウェア・アーキテクチャ並びに環境は、例示の目的に沿ったものであることに留意されたい。本発明の１つ以上の実施形態は、任意のタイプのシステム・アーキテクチャ又は処理環境に基づいて実装することができる。

また、前述の論理コード、プログラム、モジュール、プロセス、方法、及び各方法のそれぞれのステップが実施される順序は、単に例示であるに過ぎないことを理解されたい。本明細書において別段の記載がない限り、これらのステップは、実装に依存して、任意の順序で又は並列に実施することができる。さらに、前述の論理コードは、特定のプログラミング言語に限定されないのであり、これを分散式、非分散式又はマルチプロセッシング環境内の１つ以上のプロセッサ上で実行する１つ以上のモジュールから構成することができる。

従って、請求項の精神及び範囲内で修正及び変更を施すことにより、本発明を実施できることを理解されたい。本発明に関する記述は、網羅的であること及び開示された形態それ自体に本発明を限定することを意図するものではない。本明細書に開示された実施形態に関するこれら及び他の種々の改変及びその組み合わせは、その均等物を含めて、請求項の記載によって定義される本発明の範囲内にある。

サーバ・システムが通信ネットワークを介してクライアント・システムと通信関係にあるウェブ・サーバのための、実施形態に従った代表的なソフトウェア環境を示す図である。 図１のクライアント・システムとサーバ・システムの間で確立される通信セッションにおける１つ以上のタスクの実行スコープを決定するための、実施形態に従った代表的な方法のフローチャートである。 定義された実行スコープを有する１つ以上のオブジェクトに割り振られたメモリ領域を管理するための、実施形態に従った代表的な方法のフローチャートである。 本発明のシステムが動作することができるハードウェア環境のブロック図である。 本発明のシステムが動作することができるソフトウェアの環境のブロック図である。

Claims (19)

1. コンピューティング環境内のメモリ管理方法であって、
   コンピューティング環境内で実行されるアプリケーションのための第１のタスクに関連する第１のオブジェクトを一意的に識別するステップを含み、
   前記第１のオブジェクトには、第１のメモリ領域が割り振られ、
   前記第１のタスクに関連する第１の実行コンテキストに従って、前記第１のタスクのための第１の実行スコープを決定するステップを含み、
   前記第１のコンテキストは、実行環境階層内の前記第１のタスクのための第１の予測存続時間を定義し、
   前記第１の実行コンテキストをモニタすることに応答して、前記第１のタスクの実行スコープの変化を決定するステップと、
   前記第１のタスクがもはや前記第１の実行スコープ中で実行されないと決定することに応答して、前記第１のメモリ領域の割り振りを解除するステップとを含む方法。
2. 前記第１のタスクのサブタスクである、第２のタスクに関連する第２のオブジェクトを一意的に識別するステップを含み、
   前記第２のオブジェクトには、第２のメモリ領域が割り振られ、
   前記第２のタスクに関連する第２の実行コンテキストに従って、前記第２のタスクのための第２の実行スコープを決定するステップを含み、
   前記第２のコンテキストは、前記第１のタスクに関する前記実行環境階層内の前記第２のタスクのための第２の予測存続時間を定義し、
   前記第２の実行コンテキストをモニタすることに応答して、前記第２のタスクの実行スコープの変化を決定するステップと、
   前記第２のタスクがもはや前記第２の実行スコープ中で実行されないと決定することに応答して、前記第２のメモリ領域の割り振りを解除するステップとをさらに含む、請求項１に記載の方法。
3. 前記第２のタスクのサブタスクである、第３のタスクに関連する第３のオブジェクトを一意的に識別するステップを含み、
   前記第３のオブジェクトには、第３のメモリ領域が割り振られ、
   前記第３のタスクがもはや要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第３のメモリ領域の割り振りを解除するステップをさらに含む、請求項２に記載の方法。
4. 前記第３のタスクがもはや要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第２の実行コンテキストが終了される、請求項３に記載の方法。
5. 前記第２のタスクがもはや要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第１の実行コンテキストが終了される、請求項２に記載の方法。
6. 前記第２のタスクのどのサブタスクも要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第２の実行コンテキストが終了される、請求項２に記載の方法。
7. 前記第１のタスクがサーバ・システムとクライアント・システムの間で確立されるセッション中に実行され、前記セッションが終了されると決定することに応答して、前記第１の実行コンテキストが終了される、請求項１に記載の方法。
8. 前記第１のタスクないし第３のタスクが、通信ネットワークを介してサーバ・システムとクライアント・システムの間で確立されるセッション中に実行される、請求項３に記載の方法。
9. 前記通信ネットワークがインターネットを含む、請求項８に記載の方法。
10. 前記セッションが終了したと決定することに応答して、前記第１のメモリ領域ないし第３のメモリ領域が割り振り解除される、請求項８に記載の方法。
11. コンピューティング環境内のメモリ管理システムであって、
    コンピューティング環境内で実行されるアプリケーションのための第１のタスクに関連する第１のオブジェクトを一意的に識別する論理装置を備え、
    前記第１のオブジェクトには、第１のメモリ領域が割り振られ、
    前記第１のタスクに関連する第１の実行コンテキストに従って、前記第１のタスクのための第１の実行スコープを決定する論理装置を備え、
    前記第１のコンテキストは、実行環境階層内の前記第１のタスクのための第１の予測存続時間を定義し、
    前記第１の実行コンテキストをモニタすることに応答して、前記第１のタスクの実行スコープの変化を決定する論理装置と、
    前記第１のタスクがもはや前記第１の実行スコープ中で実行されないと決定することに応答して、前記第１のメモリ領域の割り振りを解除する論理装置とをさらに備える、システム。
12. 前記第１のタスクのサブタスクである、第２のタスクに関連する第２のオブジェクトを一意的に識別する論理装置を備え、
    前記第２のオブジェクトには、第２のメモリ領域が割り振られ、
    前記第２のタスクに関連する第２の実行コンテキストに従って、前記第２のタスクのための第２の実行スコープを決定する論理装置を備え、
    前記第２のコンテキストは、前記第１のタスクに関する前記第２のタスクのための第２の予測存続時間を定義し、
    前記第２の実行コンテキストをモニタすることに応答して、前記第２のタスクの実行スコープの変化を決定する論理装置と、
    前記第２のタスクがもはや前記第２の実行スコープ中で実行されないと決定することに応答して、前記第２のメモリ領域の割り振りを解除する論理装置とをさらに備える、請求項１１に記載のシステム。
13. 前記第２のタスクのサブタスクである、第３のタスクに関連する第３のオブジェクトを一意的に識別する論理装置を備え、
    前記第３のオブジェクトには、第３のメモリ領域が割り振られ、
    前記第３のタスクがもはや要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第３のメモリ領域の割り振りを解除する論理装置をさらに備える、請求項１２に記載のシステム。
14. 前記第３のタスクがもはや要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第２の実行コンテキストが終了される、請求項１３に記載のシステム。
15. 前記第２のタスクがもはや要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第１の実行コンテキストが終了される、請求項１２に記載のシステム。
16. 前記第２のタスクのどのサブタスクも要求に対するサービスをアクティブに提供しないと決定することに応答して、前記第２の実行コンテキストが終了される、請求項１２に記載のシステム。
17. 前記第１のタスクがサーバ・システムとクライアント・システムの間で確立されるセッション中に実行され、前記セッションが終了されると決定することに応答して、前記第１の実行コンテキストが終了される、請求項１１に記載のシステム。
18. 前記第１のタスクないし第３のタスクが、通信ネットワークを介してサーバ・システムとクライアント・システムの間で確立されるセッション中に実行される、請求項１３に記載のシステム。
19. 請求項１乃至１０の何れか１項に記載の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。

Images