JP2000514944A

JP2000514944A - オブジェクト指向プログラミング言語のためのハードウェア加速器

Info

Publication number: JP2000514944A
Application number: JP10548207A
Authority: JP
Inventors: トーマスシーポフ; ジョンシゲトミナミ; リョウコヤマ
Original assignee: アイレディーコーポレイション
Priority date: 1997-05-08
Filing date: 1998-04-30
Publication date: 2000-11-07
Also published as: WO1998050852A1; AU734115B2; US20020078115A1; EP0980544A1; KR20010020250A; AU7364898A; US6983357B2; CA2287413A1; CN1266512A

Abstract

(57)【要約】オブジェクト指向型プログラミング言語を加速するための方法と装置が、ハードウェアゲートレベルで提供される。Ｊａｖａ追従型の実施例では、Ｊａｖａアプリケーション・フレームワークは、ハードウェア中で実行される。Ｊａｖａ．ＡＷＴアプリケーション・フレームワーク、Ｊａｖａ．ＮＥＴアプリケーション・フレームワーク、Ｊａｖａ．ＩＯアプリケーション・フレームワークが、本発明の好適実施例でサポートされている。アプリケーション・フレームワーク・クラスは、共通メモリのライブラリとして記憶される。Ｊａｖａプログラムにより実行されて、サポートされるアプリケーション・フレームワーク・クラスのインスタンスとメソッドは、ハードウェアオブジェクト管理システムへオフロードされる。ソフトウェアスタブが、ハードウェアオブジェクト管理システムと中央演算処理ユニットの間のインターフェースとして提供される。更なるアプリケーション・フレームワークは、ソフトウェアスタブを変更又は置き換えることによってサポートしてもよい。ハードウェアオブジェクト管理システムの要求は、アプリケーション・フレームワーク専用型ハードウェア加速器によって実行される。アプリケーション・フレームワーク・クラスは、必要に応じ共通メモリから検索され、実行された命令は、中央演算処理ユニットによりアクセスできる共通メモリに記憶される。サポートされないアプリケーション・フレームワーク命令の中央演算処理ユニットによる処理は、ハードウェア加速器がハードウェアオブジェクト管理システムの要求を実行している間も、継続される。

Description

【発明の詳細な説明】オブジェクト指向プログラミング言語のためのハードウェア加速器発明の背景発明の分野本発明はオブジェクト指向プログラミング言語に関する。更に特定すると、本発明はオブジェクト指向プログラミング言語のためのハードウェア加速器に関する。先行技術の説明オブジェクト指向プログラミング（ＯＯＰ）は、「オブジェクト」の概念をベースとしたプログラミング言語と手法のクラスに関する名前である。オブジェクトは、プログラム中で特定の役割を持つ自己充足型コンポーネントである。ＯＯＰ言語には、Ｃ＋＋、サン・マイクロシステムズ社が開発したＪａｖａ言語等がある。説明の目的上、以下に述べるＯＯＰ言語をＪａｖａとする。ＯＯＰはオブジェクトのクラスを定義する。「クラス」は、一つのオブジェクト又は共通の構造と挙動を共有するオブジェクトのセットのためのプロトタイプである。オブジェクトは「インスタンス」とも呼ばれ、あるクラスを特別に表現したものである。クラスの各インスタンスは特定の属性で区別される。これらの属性は「インスタンス変数」で定義される。これらのインスタンス変数のタイプと名前はクラス中で定義される。しかしインスタンス変数の値はオブジェクト内でセットされ又変更される。クラスの挙動は、クラスのインスタンスがどう作動するかを決定する。クラスの挙動は、クラスと関係するルーチンのセットで決定され、ルーチンを「メソッド」と呼ぶ。オブジェクト上のオペレーションはメソッドを用いて実行される。メソッドは特定クラスのインスタンス全てに共通である。クラスは階層状に配列されている。階層中の各クラスは、自分の上に「スーパークラス」と呼ばれるクラスを、自分の下に「サブクラス」と呼ばれるクラスを、階層中で有していてもよい。サブクラスは属性と挙動をスーパークラスから「継承」する。従ってサブクラスば、スーパークラスで定義された挙動を再定義する必要はないが、メソッドと変数をスーパークラスから継承することは可能である。ＯＯＰ中の手順呼出は、伝達メッセージの形式で記述される。メッセージはメソッドに名前をつけるが、他の引数を随意的に含んでいてもよい。メッセージがオブジェクトに送られると、要求されたオペレーションを特定のオブジェクト上でどう実行するかを決めるために、名前付きのメソッドを求めてオブジェクトのクラスが探索される。オブジェクトのクラスにメソッドが定義されてない場合、オブジェクトのスーパークラスが探索される。この探索手順は、メソッドの定義が見つかるか又は探索すべき高位のスーパークラスがなくなるまで、クラス階層上方に向かって続けられる。手順呼出用の引数の配列は、呼出規約で決められる。呼出規約は、引数を移動する責任を誰が負うかを決めるのと同様に、引数をスタック上へ押し上げるか又はレジスタ中に入れる特定の順序を決める。アプリケーションがオペレーティングシステムと他のサービスにアクセスするための呼出規約又はインターフェースは、アプリケーションプログラミングインターフェース（ＡＰＩ）と呼ばれる。Ｊａｖａの場合、中心的なＪａｖａＡＰＩは、Ｊａｖａに追従すると考えられるプラットフォームのために、サポートする必要のある最小限の機能のセットを定義する。Ｊａｖａは、アプリケーションと呼ばれる独立プログラムと、アプレットと呼ばれる従属プログラムとをサポートする。Ｊａｖａアプレットは、電子通信網経由で送信され、受信装置上に提供されたアプリケーションで実行されるプログラムである。こうした電子通信網の例には、インタネット、本文ではイントラネットと呼ぶローカルエリアネットワークシステム等がある。受信装置には、コンピュータ、パーソナルデータ補助装置、インタネット接続可能電話等がある。ここでは説明の都合上、Ｊａｖａアプレットがインタネット経由で、ワールドワイドウェブ（Ｗｅｂ）ページ中のディスプレイ用に受信コンピュータへ送信されるものとする。Ｊａｖａアプリケーションは独立型プログラムであり、受信コンピュータ上に提供されるＷｅｂブラウザのようなアプリケーションで実行されることを必要としない。Ｊａｖａは、Ｊａｖａに追従する任意のコンピュータシステム上で作動可能なプラットフォーム独立型言語である。Ｊａｖａ開発環境にはＪａｖａコンパイラとＪａｖａインタプリタが含まれている。ＪａｖａコンパイラはＪａｖａプログラムからバイトコードを生成する。Ｊａｖａバイトコードはマシン命令であるがプラットフォーム専用ではない。プラットフォーム専用バイトコードインタプリタを使い、Ｊａｖａプログラムを実行する。本バイトコードインタプリタをＪａｖａ仮想マシンと呼ぶ。アプレットの場合、バイトコードインタプリタはＪａｖａにより作動可能にされるＷｅｂブラウザに組み込まれている。Ｊａｖａ仮想マシンとそのサポートコードを併せて、Ｊａｖａランタイムシステムと呼ぶ。Ｊａｖａ仮想マシンは、バイトコード命令セット、レジスタのセット、メソッドを記憶するためのエリア、スタック、不要情報収集ヒープを含んでいる。Ｊａｖａ仮想マシンレジスタは、マシン状態を表すデータを一時的に保持する。レジスタは、マシンの作動に影響を与え、各バイトコードが実行された後に更新される。メソッドエリアは、Ｊａｖａシステム中のメソッドの大部分を実行するＪａｖａバイトコードを記憶する。スタックは、バイトコードとメソッドの両者にパラメータを供給し、その結果を受信するのに使われる。スタックフレームはメソッド呼出、メソッドの実行環境、メソッドのオペランドスタックのためのローカル変数を含んでいる。ヒープはメモリロケーションであり、新たに作成されるインスタンスはそのメモリロケーションから割り当てられる。インスタンスはＪａｖａ中で自動的に「不要情報収集」される。不要情報コレクタは、作成された各インスタンスを追跡し、インスタンスへの最後の参照が消滅した後にインスタンスを記憶したメモリを解放するために設計された、プログラム機能である。Ｊａｖａの場合、異なるプログラムでの繰り返し再使用が見込まれるオブジェクト／クラスは「クラスライブラリ」として記憶される。多くの関連する問題を解決するためアブストラクトデザインを具体化したクラスのセットは、フレームワークとして知られている。Ｊａｖａクラスライブラリに記憶される中心的アプリケーションフレームワークには、Ｊａｖａ．Ｌａｎｇ、Ｊａｖａ．Ｕｔｉｌ、Ｊａｖａ．Ａｐｐｌｅｔ、Ｊａｖａ．ＩＯ、Ｊａｖａ．ＮＥＴ、Ｊａｖａ．ＡＷＴ等がある。Ｊａｖａ．Ｕｔｉｌがユーティリティクラスとシンプルコレクションクラスを含む一方、Ｊａｖａ．Ｌａｎｇは言語自身にデータタイプとシステム能力を付け加えるクラスを含んでいる。Ｊａｖａ．ＡｐｐｌｅｔはＪａｖａアプレットを実行するクラスを含んでいる。Ｊａｖａ．ＩＯは、ストリームへの書込／ストリームから読み取りのための入出力クラスを含んでいる。Ｊａｖａ．ＩＯはファイルを処理するための入出力クラスも含んでいる。Ｊａｖａ．ＮＥＴはネットワーキング支援のためのクラスを含んでいる。こうしたクラスには、例えばＴＣＰ／ＩＰのような標準的なＷｅｂプロトコルに従ってファイルを接続・検索するクラスと、ＵＮＩＸアプリケーションで使われるようなソケットを作成するためのクラス等がある。Ｊａｖａアブストラクトウィンドウ用ツールキット（Ｊａｖａ．ＡＷＴ）は、グラフィカルユーザインターフェース（ＧＵＩ）ベースのアプレットとアプリケーションを生成するためのクラスと挙動を提供する。Ｊａｖａ．ＡＷＴは例えば、スクリーン、クリエイトウィンドウ、ボタン、メニューバー、スライダーバー、及び他のユーザインターフェースエレメントを描画するために使うことができる。Ｊａｖａ．ＡＷＴは又、マウスクリックとキーボードのようなユーザ入力を管理するためにも使うことができる。オブジェクト指向のソフトウェアフレームワークは一般に、コンピュータのランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、仮想メモリ（ＶＭ）を使って実行される。Ｊａｖａアプリケーション又はアプレットが例えばコンピュータ上で開始される時、実行される最初のオペレーションの内の一つはＧＵＩの作成である。しかしソフトウェアベースの装置が使われているので、コンピュータのＯＳ処理能力のかなりの部分が、ＧＵＩの実際の生成・表示のために必要となることがある。従つてＧＵＩエレメントがディスプレイ装置上に表示されている間、ＯＳによる他の命令の処理が驚くほど遅くなることがある。更に、ディスプレイが更新されている間にマウス又はキーボーのイベントが生成されると、Ｊａｖａランタイムは、更新イベントが生成されると同時にシステムが未処理のマウス及びキーボーのイベントを処理しようとする、一種の膠着状態に入り込んでしまう。結果的にランタイムシステムは正当な時間枠内で全イベントに追従・処理することができない。エンドユーザには、プログラムが更なる命令と入力を外見上拒否し、作動停止しているように見える。Ｊａｖａはマルチプロセス／マルチスレッドのシステムである。従ってＪａｖａは複数のプログラム又はプロセスをサポートし、各々を自身のアドレススペース内で同時に実行する。スレッドとは、これらプロセスの内の一つの中で実行されるコードのシーケンスである。従って、Ｊａｖａのプログラミング環境とランタイムシステムの両者はマルチスレッド構造を有する。Ｊａｖａのようなマルチスレッドプログラムの場合、Ｊａｖａプログラムを実行する単一スレッドは、例えばウィンドウが描かれるまでにブロックされてもよい。更に前記単一スレッドに従属する他のどのスレッドもブロックされることがあり得る。ブロッキングにより、例えば通信網経由の情報を制限・遅延することがあり得る。こうしたブロッキングは、実行を再開する前にタスクが完了するのをＪａｖａスレッドが待機する能力として定義される。組込環境の一部としてのＪａｖａプログラムを作動すること、例えば、インタネット接続可能電話のような装置上でＪａｖａのアプリケーションとアプレットを作動することはしばしば望ましいことである。しかしＪａｖａコードと高速Ｊａｖａｓバイトコードプロセッサの場合、装置をＪａｖａに追従させる必要がある。これは装置の製作コストと稼動コストをかなり押し上げることになる。従って、性能を落とした方法と装置を提供することが有利である。こうした方法と装置により、組込及びデスクトップの両環境下でオブジェクト指向プログラムの効率的に使うことを可能になるのであれば、更に有利である。発明の概要本発明は、オブジェクト指向プログラミング言語を加速するための方法と装置を提供する。本発明の好適実施例は、Ｊａｖａに追従するプロセッサをＪａｖａプログラミング言語と標準的Ｊａｖａオブジェクトベースフレームワークと共に使うように構成されている。しかし本発明の代替実施例は、任意のオブジェクト指向プログラミング言語と共に使うように適合化されている。本発明の代替実施例は又、アップルコンピュータの「オープンステップ」フレームワークやマイクロソフトのオブジェクトベースＡＦＣライブラリのような他のオブジェクトベースフレームワークと共に使うようにも適合化されている。本発明は、一つ又はそれ以上のＪａｖａアプリケーションフレームワークを実行する機能を含んでいるハードウェア加速器を提供する。本発明の本好適実施例の場合、加速器はアプリケーション専用の集積回路（ＡＳＩＣ）の一部として構成される。加速器は、インスタンスに割り当てられた数値状態のみならず、インスタンスも管理するハードウェアオブジェクト管理システムを含んでいる。本発明の好適実施例は、Ｊａｖａアブストラクトウィンドウ用ツールキット（ＡＷＴ）、ＪａｖａＮＥＴ、Ｊａｖａ入出力アプリケーションフレームワークを実行する。本発明は、必要なら追加Ｊａｖａフレームワークもサポートする。Ｊａｖａランタイムシステムは、ハードウェアオブジェクト管理システムとソフトウェアオブジェクト管理システムの両者を管理する。ソフトウェアオブジェクト管理システムは、ソフトウェアのみ又はソフトウェア及びハードウェアの両方のいずれの中でも実行可能である。Ｊａｖａプログラムで実行されてサポートされるＪａｖａアプリケーションフレームワーククラスのインスタンスとメソッドは、ハードウェアオブジェクト管理システムへオフロードされる。こうして、本発明の好適実施例の中央演算装置（ＣＰＵ）は、ハードウェアオブジェクト管理システムがＪａｖａ．ＡＷＴとＪａｖａ．ＮＥＴの要求を管理している間も、命令処理を続けることができる。本発明ではアプリケーションフレームワーククラスを、共通メモリ中のライブラリとして記憶する。しかしサポートされるアプリケーションフレームワークは個別に管理される。要求は特定アプリケーションフレームワークのハードウェア制御装置に配分され、共通メモリへのアクセスが必要に応じて行われる。ソフトウェアスタブは、ハードウェアオブジェクト管理システムとＣＰＵの間のインターフェースとして提供される。ソフトウェアスタブは、互換性のある任意のＯＯＰ言語と共に本発明を使えるようにするために、修正又は置き換えることができる。ハードウェアオブジェクト管理システムは、オブジェクト要求を受信・記憶するための入出力要求待ち行列を含んでいる。タスクプロセッサがオブジェクト用のメモリを割り当てると、要求は待ち行列から除かれる。能動オブジェクトリストは、Ｊａｖａ仮想マシン中にある基準カウント数をインスタンスに対して追跡する。インスタンスに対する基準カウントの数が零になると、Ｊａｖａ不要情報コレクタはオブジェクトを記憶するメモリを割り当てから外す。本発明の本好適実施例のＪａｖａ．ＡＷＴハードウェア装置はウィンドウ用／ビューシステムとレンダリングエンジンを含んでいる。グラフィックＪａｖａプログラムは、ネストされたコンテナとコンポーネントから成る階層として構造化されている。コンテナは、仮想オブジェクト被呼出コンポーネントのコレクションを管理する。コンポーネントは、メニューバー、ボタン、編集可能テキストエリア、テキストフィールドのような画面上に表示される視覚機能を表す。コンテナ自身は互いの内部で階層状にネストされてもよく、又別のコンテナと親＜−＞子関係を維持してもよい。特定アプリケーションに対して、コンテナビューが、ウィンドウ（ＡＷＴ．Ｆｒａｍｅ）オブジェクトで表されたビュー階層の一番上に存在する。ＡＷＴ．Ｆｒａｍｅは、特定プラットフォーム（例えば、ウィンドウズ又はソラリス）に固有なウィンドウを定義する。更にコンテナは、他のコンポーネントを含むことができる専用ケースでのコンポーネントと考えることもできる。これは機能上、コンテナクラスがコンポーネントのサブクラスであるためである。パネルはアプリケーション又はアプレット内の画面上に表示できるコンテナである。フレームは（タイトルとメニューバーを有する）ウィンドウであるが、更にコンポーネント／コンテナオブジェクトの別のタイプでもある。全クラスが有する共通のクラス挙動により、クラスは様々な特性を共有し一体となれる。Ｊａｖａ．ＡＷＴハードウェア装置は、メッセージングを最適化しコンテナ表示効率を上げることにより、種々のコンポーネントオブジェクトバリエーション間のこれら共通機能に影響を与える。コンテナは、他のコンテナを含んだ他のコンポーネントを含むことができるＪａｖａ．ＡＷＴコンポーネントである。パネルはアプレットのような、画面上に表示可能なコンテナである。フレームは、タイトル、メニューバーのような特徴を有するウィンドウである。ウインドウ用／ビューシステムは、フレームとコンポーネントを作成し更にレンダリングエンジンへデータを伝えるための汎用グラフィックコントローラと、フレームを菅理するためのウィンドウマネジャと、フレーム内のコンテナ階層を管理するためのレイアウトマネジャと、コンテナ内のコンポーネント階層を管理するためのコンポーネントマネジャを含んでいる。Ｊａｖａ．ＮＥＴハードウェア装置はウィンドウ用／ビューシステムと接続エンジンを含んでいる。ウィンドウ用／ビューシステムは、Ｊａｖａ．ＮＥＴフレームワークの同等物のためのマイクロコードを有するネットワークコントローラを含んでいる。ネットワーク照会機構は、ＤＮＳ検索を実行し結果をネットワークコントローラに報告し、ソケットマネジャは、アプリケーションが使っているソケットを管理し、ストリームマネジャは、通信網プロトコルでサポートされるリンクを通じて入出力データを往復させる。従って本発明は、サポートされたアプリケーションフレームワークの命令を共同処理することにより、ブロッキングを減らすためのハードウェア装置を提供する。こうして、Ｊａｖａ処理が加速される。図面の簡単な説明図１は、本発明によるハードウェア加速器１０の構造概略を示すブロック図である。図２は、本発明によるＪａｖａ加速器のブロック概略図である。図３は、本発明によるオブジェクトの例示及び削除を行った後のオブジェクトリストを示す表である。図４は、本発明による内部コンポーネントインスタンスへのコンテナ連結リストを示すブロック図である。図５は、本発明による能動オブジェクトリストを示すブロック図である。図６は、本発明によるハードウェア加速器の内部機能のブロック図である。図７は、図６に示したＪａｖａＡＷＴ加速器の更に詳しいブロック図である。図８は、本発明を使用して幾つかのスレッドを全て同時に使うＪＶＭを示すブロック図である。図９は、ＡＷＴ表示オブジェクトが本発明によるハードウェア中で処理されている仮想セッションの図である。図１０は、本発明でサポートされるＪａｖａアブストラクトウィンドウ用ツールキットオブジェクトを示すブロック図である。図１１は、本発明によるＪａｖａアブストラクトウィンドウ用ツールキットハードウェア装置の機能ブロック図である。図１２は、本発明によるウィンドウ用システムの機能ブロック図である。図１３は、本発明によるレンダリングエンジンでサポートされるコンポーネントを示す表である。図１４は、本発明による連鎖プロセスの一例を示す概略図である。図１５は、図１３のレンダリングエンジンのグラフセクションでサポートされるレンダリングのタイプを示す表である。図１６は、Ｊａｖａ．ＡＷＴ加速器の「命令」実行とオブジェクト管理を示すブロック図である。図１７は、本発明によるＡＷＴセクション中に組み込まれた機能を説明する。図１８は、本発明によるＪａｖａアブストラクトウィンドウ用ツールキットのウィンドウ／コンテナ／ビューのインスタンス階層の例のブロック図である。図１９は、本発明によりサポートされるＪａｖａ．ネットオブジェクトのブロック図である。図２０は、本発明によるＪａｖａＮｅｔ加速器の機能ブロック図である。図２１は、本発明によるＮＥＴセクション中に組み込まれた機能を説明する。発明の詳細な説明本発明はオブジェクト指向プログラミング言語を加速するための方法と装置を提供する。本発明の好適実施例は、サン・マイクロシステムズ社が開発したＪａｖａプログラミング言語と、Ｊａｖａアプリケーションプログラムインターフェースと共に使われることに対して最適化されている。しかし本発明は、オブジェクト指向スタイルで書かれたプログラム用のＣ＋＋又はＣのような任意のオブジェクト指向プログラミング言語と共に使うことに対しても容易に適合化される。従って、以下の記述は例の説明が目的としており、発明の範囲を限定するものではない。同様に、Ｊａｖａ加速器に相互接続される装置は、異なるアプリケーションフレームワーク又はサン・マイクロシステムズ社のＪａｖａＡＰＩＳに接続されていないアプリケーションフレームワークのセットを使用していてもよい。本発明の好適実施例は、インタネット経由のデータ送信で使うのに適合している一方で、本発明は他の広範囲の通信網やローカルエリアネットワークに等しく適用可能である。更に、好適実施例がデスクトップ計算機で使われる一方、本発明は、ネットワークサーバ、パーソナルデータ補助装置、ファックスマシン、インタネット接続可能電話を始めとする他のデバイスと使うこともできる。以下に述べるディスプレイ画面とＧＵＩ構成は、本発明の本好適実施例に従って提供される。しかし当業者は、こうしたディスプレイ画面とＧＵＩが本発明の代替実施例の要件を満たすよう容易に変更されることを認識するであろう。従って以下の記述は例の説明が目的であり、発明の範囲を限定するものではない。図１は、本発明によるハードウェア加速器１０の構造概略を示すブロック図である。コンピュータのＣＰＵ（不図示）上で実行されるＪａｖａ仮想マシン１６は、コンピュータシステム上で実行されるＪａｖａアプリケーション１２のためのバイトコードインタプリタである。Ｊａｖａアプレット１４のために、バイトコードインタプリタがＪａｖａで作動可能にされるウェブブラウザ中に組み込まれている。ハードウェアオブジェクト管理Ｊａｖａ加速器のメモリ４００（図２参照）はオブジェクト記述子とパラメータを保持するように予め設計されている。このオブジェクトスペースは全て大きさが同じであるが、各々のフォーマットはスペースに割り当てられるオブジェクトのタイプに左右される。各オブジェクト記述子の開始部分には、特定オブジェクトが使われているか否かを示す状態バイトが存在する。開始時、デジグネータはフリーな状態にあるとして表示される。次にソフトウェアは以下のステップを使いオブジェクト作成を開始する。・最初の命令又はタスクが、ＡＷＴコマンドレジスタ４０７又はＮＥＴコマンドレジスタ４１３へ発せられる。・次にコマンドは、ＡＷＴコマンドデコーダ４０８又はＮＥＴコマンドデコーダ４１４でデコードされる。・一旦、作られるべきオブジェクトのタイプが決まると、次の利用可能なオブジェクトＩＤが、フリーオブジェクトロケータ４０３から取得され、他の状態情報と共に返却ＦＩＦＯ４０５又は４１２経由でレジスタに送り返され、ＡＷＴデータレジスタ４０６又はＮＥＴデータレジスタ４１０経由でシステムのプロセッサへ折り返し出て行く。・一旦、フリーオブジェクトロケータがオブジェクトＩＤをシステムに送り返すと、フリーオブジェクトロケータは次のフリーオブジェクトスペース用の利用可能なメモリ４００のポーリングを開始する。・利用可能なメモリを見つかると、フリーオブジェクトロケータは次のオブジェクト作成命令に備えて本オブジェクトスペースのＩＤを記憶する・フリーオブジェクトロケータが全メモリを探しても利用可能なオブジェクトスペースを見つからない場合、アウトオブメモリ状態の情報がシステムに返却される。・システムが、既に作成済みの特定オブジェクトへのアクセスを望む場合、システムは先のオブジェクトＩＤと共にタスクを、ＡＷＴコマンドレジスタ４０７又はＮＥＴコマンドレジスタ４１３へ伝える。オブジェクトＩＤとタスクは構文解析されデコードされ、ＩＤはオブジェクトＩＤレゾルバ４０２に伝えられる。次にこのブロックでは、オブジェクトＩＤは、メモリブロック４００中の特定オブジェクトスペースへアクセスするのに使うことのできるメモリアドレスに翻訳される。・オブジェクト削除の要求をシステムが受信すると、オブジェクトＩＤと共に適当な命令がコマンドレジスタに伝えられる。タスクとＩＤがデコードされて構文解析され、ＩＤがオブジェクトレゾルバに伝えられる。次にＪａｖａ加速器が作動し、メモリ中の先の特定オブジェクトスペースにある「使用中状態ビット」を取り払い、これにより本スペースは次のオブジェ作成命令のためのフリーオブジェクトロケータ用に使えるようになる。フリーオブジェクトロケータがアウトオブメモリ状態の情報を既に報告している場合、新たに自由になったオブジェクトＩＤがフリーオブジェクトロケータに直接記憶され、これによりロケータは全メモリ中でロケーションを探し廻らなくて済む。・フリーオブジェクトロケータは、次の「ｎ」個のフリーオブジェクトＩＤを記憶する能力を有する。これは個々のオブジェクトスペースのサイズが小さいインスタンスで使われ、次に複数のオブジェクトが、連結された「ｎ」個のオブジェクトスペースを利用する。この場合、第一オブジェクトスペースは、続きのオブジェクト記述子が何処に記憶されているかを示すリンクフィールドを含んでいる。この状態が「ｎ−１」番目のスペースまで、連続する各オブジェクトスペースで続き、この「ｎ−１」番目のスペースには「ｎ番目」のオブジェクトスペースへのリンクが含まれている。この構成の下では、フリーオブジェクトロケータは開始オブジェクトスペースのＩＤを、オブジェクト作成命令に応じて折り返し報告する。又、作成されるべきオブジェクトのタイプが複数のオブジェクトスペースを必要とするように決まると、フリーオブジェクトロケータは、充分なフリーオブジェクトスペースが利用できる場合には開始ＩＤを折り返し報告するだけである。他の場合はアウトオブメモリ状態の情報が返却される。この場合のオブジェクトスペースは連続した順番でなくともよく、ランダムに連結されていてもよい。フリーオブジェクトロケータは、作成されるべき最大のオブジェクトに必要なオブジェクトスペースの最大数を「ｎ」とし、「ｎ」個のフリーオブジェクトＩＤを記憶できなければならないハードウェアにより提供されるオブジェクトＩＤは、長さが任意のビット数である。ハードウェアオブジェクトマネジャは、オブジェクトＩＤがホストシステムにより提供されハードウェアにより返却されない状況でも作動する。この場合、最初に提供されるオブジェクトＩＤは、ベースリファレンスレジスタに記憶され、第一フリーオブジェクトロケーションに関係付けられる。連続する各オブジェクト要求は、リファレンスレジスタと比較されるＩＤを有する。両者のオフセットが、メモリ中の実際のオブジェクトロケーションを決定する。特定レコードが既に使用中である場合、次のフリーオブジェクトロケーションが使用される。予め定義されたリファレンスフィールドは、どれだけのオフセットが関係しているかを示す各オブジェクトレコードと共に含まれている。オフセットはモジューロ法で実行され、オフセットが割当られたメモリスペースよりも大きい時には、メモリロケーションが最初の位置へ再び戻るようになっている。このシステムは、システムにより提供されるオブジェクトＩＤがハードウェアオブジェクトＩＤよりも大きなビット数である状況でも作動する。図３は複数のオブジェクトが例示・削除された後にヒープがどう見えるかを示す。削除されたオブジェクト＃５は今は自由に再び使えることに注目されたい。コンテナオブジェクトはコンポーネントからなる連結リストの実質上先頭であることに注目されたい。本リストはオブジェクト値が０になった時に終る。何故なら、オブジェクト＃０は存在せず、オブジェクト＃０に対する如何なるリファレンスも無効だからである。他のタイプのオブジェクトはこれと同じ機能を発揮してもよい。インスタンスのボタンオブジェクトは、３０バイトを超えてもよいストリングオブジェクトを同様に参照する。この場合のボタンオブジェクトはストリングオブジェクトを指し示し、このストリングオブジェクトは長さ３０バイトの各オブジェクトを有する別のストリングオブジェクトを順次指し示すことになる。これは組合せオブジェクトエントリリストがどう機能するかを示すものである。図４はコンテナの連結リストと内部コンポーネントインスタンスとの関係を系統的に示している。同じリストを図４に間接的に示す。能動オブジェクトリスト上のオブジェクト図５は、本発明による能動オブジェクトリストを示すブロック図である。能動オブジェクトリストは最大で３０バイトブロックまでのリストを含み、各ブロックはオブジェクトの特定タイプの能動インスタンスを表す。オブジェクトの各タイプはオブジェクトに関係した構造を有している。例示されたオブジェクトは全て、オブジェクトのタイプと、ランタイムシステムのメソッドセレクタと、オブジェクトが属するフレームワークとを記述するフラッグを含んでいる。ボーダレイアウトインスタンスは更に、コンポーネントのセットをレイアウトするためにインスタンスを使うコンテナに対するポインタと、東西南北にあるコンポーネントに対する可能なオブジェクトリファレンスと、コンポーネントを描く時にコンポーネント間に残すべきスペース（画素）を決定する値を含んでいる。コンテナオブジェクトは、囲まれるコンポーネントの数と、コンテナの継承インスタンス値を保持するコンポーネントオブジェクトに対するリファレンスと、コンポーネントオブジェクトの連結リスト中の第一コンテナオブジェクトに対するリファレンスとを含んでいる。コンポーネントオブジェクトは「タイプ」値を含み、この値は同オブジェクトがボタンを描いたり或いはボタン、スライダー、テキストフィールド、又は他のタイプのウィジェットからのイベントを処理することがあるか否かを表す。オブジェクトは又、コンテナ中で利用できる次のコンポーネントへのリンクも含んでいる。本発明の場合、オブジェクト（図５参照）は小ブロックで処理される。オブジェクトはサイズとフットプリントの点からすると常に同じに見える。或るインスタンスを別のインスタンスから能動オブジェクトリスト上で区別するものは、データ構造又はインスタンス変数である。インスタンスは単純でも複雑でもよい。インスタンスは８、１６、３２ビットの整数又は単一ビットのブーリアン値を含んでいてもよい。インスタンスは他のオブジェクトに対するオブジェクトリファレンスＩＤも含んでいてよい。コンテナオブジェクトの場合を取り上げる。コンテナオブジェクトを求める要求が入出力要求待ち行列に加えられた後、ＪＥｘｐｒｅｓｓが本要求に応じ、コンテナインスタンスに関係する変数を記憶するため、固定サイズブロックのメモリを作成する。複数のコンポーネントオブジェクトが作成された後、このオブジェクトはコンテナに加えられてもよい。コンテナに割り当てられたオブジェクトを管理するためにレイアウトマネジャが割り当てられる場合、この手順が相応に行われる。コンテナ＜−＞ボーダレイアウトの関係がある場合、５つの可能なコンポーネントをコンテナに直接加えてもよい。次にボーダレイアウトオブジェクトは、５つ（東西南北と中央）のコンポーネントの内の最大値に対する所定リファレンスが与えられ、同オブジェクトは将来時点でこれらのオブジェクトをどう描いて更新するかを知ることになる。能動オブジェクトリストは、最大で３０バイトブロックまでのリストを含み、各ブロックはオブジェクトの特定タイプの能動インスタンスを表している。オブジェクトの各タイプは、以下の３つのオブジェクトインスタンス図に示されているように、オブジェクトに関係する構造を有している。例示される全オブジェクトは、オブジェクトのタイプと、ランタイムシステムのメソッドセレクタと、オブジェクトが属するフレームワークを記述するフラッグを含んでいる。ボーダレイアウトインスタンスは更に、コンポーネントのセットをレイアウトするためにインスタンスを使うコンテナに対するポインタと、東西南北にあるコンポーネントに対する可能なオブジェクトリファレンスと、コンポーネントを描く時にコンポーネント間に残すべきスペース（画素）を決定する値を含んでいる。コンテナオブジェクトは、囲まれるコンポーネントの数と、コンテナの継承インスタンス値を保持するコンポーネントオブジェクトに対するリファレンスと、コンポーネントオブジェクトの連結リスト中の第一コンテナオブジェクトに対するリファレンスとを含んでいる。コンポーネントオブジェクトは「タイプ」値を含んでおり、この値は同オブジェクトがボタンを描いたり、又はボタン、スライダー、テキストフィールド、又は他のタイプのウィジェットからのイベントを処理することがあるか否かを表している。オブジェクトは又、コンテナ中で利用できる次のコンポーネントへのリンクも含んでいる。これらオブジェクトの定義はフレームワークが管理するＣ構造に直接マップされる。（これらは、将来変化し最適化される予備的なストラクトであることに注目されたい。） typedef struct ir_descriptor_//オブジェクトの最初の３バイト {jbyte frame work Type;_//フレームワークのタイプを指定(Java.AWT，NET，IF C,etc) jbyte objectType;_//オブジェクトのタイプを指定(Frame，Event，Container， etc) jbyte methodType;_//オブジェクトメソッドを指定(-paint( )，etc) jbyte inUse;_//レコードが使用中か否かを見つける }desc; typedef struct ir_container_//注意：各コンテナはコンポーネント構造を参照すること {desc_objDsec; jshort_ncomponents;_//コンテナ中に存在するコンポーネントの数 Rect_insets; ＿//レイアウトマネジャは５つのデフォルトの一つが可能 jbyte_layoutType;_//本コンテナに使われるレイアウトのタイプを表す jint_layoutObj;_//レイアウトのインスタンスに対するインデックスを指定 _jint_inheritedCompObj;_//コンポーネントのサブクラスなのでこれが必要＿//コンポーネント構造に対するインデックス /////////フレームオブジェクト従属変数 _jboolean_isResizable;_//フレームオブジェクトと共に使われる _jbyte_cursorType;_//フレームオブジェクトと共に使われるカーソル０−１３ _unsigned short menuBarObj;_//メニューバーはしばしばフレームオブジェクトに取り付けられる //////// int firstComponentNode; }Container，Dialog，Frame，Window;//便宜上、複数の名前を割り当てる //A Window=Frame=Dialog=Container as far asの関係が成立する //JExpressが関係する。 typedef struct ir_component {desc_objDsec; jbyte peerObjType; //これがコンポーネントの真のオブジェクト値である //例えばボタン、ラベル、テキストフィールド等 _unsigned short x; _unsigned short y; _unsigned short width; _unsigned short height; _unsigned short parentObj;_//コンテナオブジェクトに対するインデックス _unsigned short fontObj;_//本コンポーネントが使っているフォントを記述するオブジェクトに対するインデックス _unsigned short foregroundColorObj;_//前景色オブジェクトに対するインデックス _unsigned short backgroundColorObj;_//背景色オブジェクトに対するインデックス unsigned short cursorObj;_//カーソルオブジェクトに対するインデックス _unsigned short stringObj;_//ストリングを含むオブジェクトに対するリファレンス //コンポーネント中で適当に実行される（０であってもよい） _jboolean visible;_// _jboolean enabled;_// _jboolean valid;_// //Dimension minSize;_//コンポーネントの最小許容サイズを含む //Dimension prefSize;_//コンポーネントの好適サイズを含む _jint nextComponentNode;_//コンテナ中の次の既知コンポーネントにインデックス｝Canvas，Component;_//カンバスはペイント( )メソッドを有するコンポーネントである。 typedef struct ir_borderlayout {desc objDesc; jshort hgap; jshort vgap; jshort container;_//関係するコンテナのアレイに対するインデックス jshort northComponent;_//指し示すコンポネントのアレイに対するインデックス jshort southComponent; jshort westComponent; jshort eastComponent; jshort centerComponent; ｝BorderLayout; typedef struct ir_flowlayout { desc objDesc; jshort hgap; jshort vgap; jshort align; ｝FlowLayout; typedef struct ir_gridlayout { desc objDesc; unsigned short hgap; unsigned short vgap; unsigned short rows; unsigned short cols; ｝GridLayout; typedef struct ir_wgraphics { desc objDesc; unsigned short x，y; unsigned short width height; unsigned short foregroundColorObj;_//前景色オブジェクトに対するインデックス unsigned short xoffset，yoffset;_// Rect clipRect;_//Wgraphicsによりセットされる：Clip( )を変更する｝WGraphics; 種々のコンセプトここに概要を述べたオブジェクト定義は（ここで定義されてないものも合わせて）、インスタンスを作成し唯一のインスタンス値を保守するために使われる。これらのデータ構造を使わない場合、アクティブオブジェクトリストの３０バイトのブロックは意味を持たない。これらのオブジェクト構造は、特定のオブジェクトインスタンス内の値を識別し、設定し、そしてその値にアクセスするために使用される。ランタイムシステムは、オブジェクトインスタンスの集合を使用して、所定のデータセットにとって意味のあるメソッドを実行する。あるオブジェクトにとってのディスクリプタストラクトのメソッドディスクリプタは、そのオブジェクトが低級なフレームバッファ装置に送信されるような仕様であってもよい。スマート・フレームバッファが、次にそのストラクトを引き受け、（サイズ直しや描き直し等の）コマンドを意味の通る方法で翻訳することになる。このとき、グラフィック及びコンポーネントオブジェクトは、それらのストラクトをスマート・フレームバッファに既に送信している。Ｊａｖａランタイムシステム１８には、Ｊａｖａ仮想マシンがそのサポートコードと共に含まれている。Ｊａｖａランタイムシステムは、例示とメソッド呼出の構文解析をする。本発明の好適実施例の場合、Ｊａｖａランタイムシステムは、２つのインスタンスマネジャー、即ちハードウェアオブジェクト管理システム２２とソフトウェアオブジェクト管理システム２０を管理する。しかし、本発明の代替実施例のＪａｖａランタイムシステムは、３つ以上のインスタンスマネジャーを管理する。ハードウェアオブジェクト管理システムは、Ｊａｖａアプリケーション・フレームワークをサポートするための機能を保有している。本発明の本好適実施例のハードウェアオブジェクト管理システムは、Ｊａｖａアブストラクトウインドウ用ツールキット（ＡＷＴ）２６とＪａｖａネット２４アプリケーション・フレームワークを実行する。Ｊａｖａ入力／出力アプリケーション・フレームワーク（図示せず）もまた、Ｊａｖａネット機能をサポートするために実行される。ハードウェアオブジェクト管理システムは、必要に応じ更なるＪａｖａフレームワークのサポートに容易に順応できる。従って本発明は、ＣＰＵに対し加速器の役目をするＪａｖａアプリケーション・フレームワーク・ハードウェア装置を提供する。ハードウェアオブジェクト管理システムは、インスタンスだけでなくインスタンスに割り当てられた値の状態も菅理する。本発明の本好適実施例のハードウェアオブジェクト管理システムは、もっぱらゲートに備えられているが、外付きランダムアクセスメモリ（ＲＡＭ）を有することができる。この実施例のハードウェアオブジェクト管理システムは、アプリケーション専用型集積回路（ＡＳＩＣ）の一部として構築されている。本発明の好適実施例をゲートレベルの装置及びＡＳＩＣに関連づけて論じてはいるが、本発明の実際の装置は当業者の選択の問題と考えられることを認識されたい。ソフトウェアオブジェクト管理システムは、もっぱらソフトウェア中に装備することができる。しかし、本発明の代替実施例のソフトウェアオブジェクト管理システムは、ソフトウェアとハードウェア両方のコンポーネントを使って実行される。ソフトウェアオブジェクト管理システムの一例は、コンピュータシステムのメモリマネジャーである。Ｊａｖａプログラムにより実行されてサポートされるＪａｖａアプリケーション・フレームワーク・クラスのインスタンスとメソッドは、ハードウェアオブジェクト管理システムへオフロードされる。こうして本発明の好適実施例では、ハードウェアオブジェクト管理システムがＪａｖａ．ＡＷＴとＪａｖａ．ＮＥＴの要求を管理している間も、ＣＰＵは命令処理を続けることができる。ハードウェア実行型Ｊａｖａアプリケーション・フレームワーク・クラスのインスタンスとメソッドがＪａｖａプログラムにより実行される時は必ず、インスタンスとメソッドは、ハードウェアオブジェクト管理システムへオフロードされることになる。このように本発明の好適実施例では、ハードウェアオブジェクト管理システムは、Ｊａｖａ仮想マシン上で実行中のスレッドの、Ｊａｖａ．ＡＷＴとＪａｖａ．ＮＥＴの要求を管理する。こうして、ハードウェアオブジェクト管理システムがＪａｖａ．ＡＷＴとＪａｖａ．ＮＥＴの要求を管理している間、オフロードされたインスタンスとメソッドに依存しない命令とスレッドを処理し続けるのに、ＣＰＵを利用することが可能となる。異なるプログラムで繰り返し再使用が見込まれるアプリケーション・フレームワーク・クラスは、Ｊａｖａクラスライブラリ３２（図１）に記憶される。このようなクラスには、Ｊａｖａ．ＡＷＴ３４、Ｊａｖａ．ＮＥＴ３６、Ｊａｖａ．Ｌａｎｇ４２、Ｊａｖａ．ＩＯ３８、及びＪａｖａ．Ｕｔｉ１４４等のアプリケーション・フレームワークが含まれてもよい。アプリケーション・フレームワーク・クラスは、共通メモリのライブラリとして記憶される。しかし、サポートされるアプリケーション・フレームワークは、個別に管理される。ある要求が、特定のアプリケーション・フレームワーク用のハードウェアコントローラに配分されると、共通メモリが必要に応じアクセスされる。ソケット接続の確立のようなネットワーク・オペレーションを行うためのクラスと挙動は、Ｊａｖａ．ＮＥＴ加速器２４により実行される。Ｊａｖａ．ＮＥＴ加速器は、ネットワークＴＣＰ／ＩＰスタック２８に対するインターフェースを提供される。Ｊａｖａ．ＮＥＴ加速器は、Ｊａｖａ．ＮＥＴ３６ネットワーキング用オブジェクトとＪａｖａ．ＩＯ３８入力／出力関連オブジェクト両方のハードウェア装置を含んでいる。これは、ネットワーク作りは必然的にデータの入力と出力を意味しているからである。両フレームワークをハードウェアに組み入れることにより、冗長なソフトウェアコーディングを相当減らすことができる。Ｊａｖａ．ＮＥＴ加速器の一実行例では、ソケット接続中に入出力されるデータを処理するために、Ｊａｖａ．ＩＯハードウェア装置が使われている。Ｊａｖａ．ＮＥＴ加速器では、Ｊａｂａ．ＮＥＴとＪａｖａ．ＩＯのアプリケーション・フレームワーク・クラスは継承を通じて結合される。このように、一つのフレームワークのクラスは、別のフレームワークの機能を継承し、それに付け加えることができる。Ｊａｖａ．ＡＷＴ加速器は、クラス、即ちアブストラクトウインドウ用ツールキットのメソッド（いわゆる、挙動）を実行する。Ｊａｖａアブストラクトウインドウ用ツールキット（Ｊａｖａ．ＡＷＴ）は、グラフィカル・ユーザー・インターフェース（ＧＵＩ）ベースのアプレット及びアプリケーションを作成するためのクラスと挙動を提供する。このようなクラスには、Ｊａｖａ．ＡＷＴクラス３２及び、例えば２次元レンダリングエンジン４０等の関連レンダリングツールが含まれる。Ｊａｖａ．ＡＷＴ加速器は、ウインドウ、ボタン、メニューバー、スライダーバーや他のユーザーインターフェースエレメントを画面に描くために使うことができ、またマウスクリックやキーストロークようなユーザー入力を管理するためにも使うことができる。こうしてＪａｖａ．ＡＷＴ加速器には、コンピュータディスプレイ、フレームバッファ、キーボード、及びマウスのような機器３０に対するインターフェースが提供される。構造概観図６及び図７は、本発明の構造概観のブロック図である。Ｊａｖａ．ＡＷＴ２６（図７により詳しく図示）とＪａｖａ．ＩＯ（図示せず）のような、サポートされるアプリケーション・フレームワークは、ＡＳＩＣにキャストされて加速器を形成する。以下の説明に当たり、Ｊａｖａ．ＮＥＴ加速器は、Ｊａｖａ．ＩＯの入力／出力関連オブジェクトを含むものと仮定する。本発明の実施例では、ハードウェアオブジェクト管理システム２２もＡＳＩＣにキャストされ、インスタンスとそのインスタンスに割り当てられた値の状態を管理する。例えばハードウェアオブジェクト管理システムは、ボタンが押されたかどうかを追跡するためにデータを記憶する。ハードウェアオブジェクト管理システムは又、そのボタンは特定ウインドウの一部であるというような、オブジェクト間の関係を指示するデータも記憶する。この情報は、共通メモリに記憶される。ソフトウェアスタブは、Ｊａｖａ仮想マシンを稼働するＣＰＵと各加速器の間のインターフェースとして提供される。このようにＪａｖａ．ＮＥＴ加速器は、関係づけられたＪａｖａ．ＮＥＴソフトウェアスタブ５２とＪａｖａ．ＩＯソフトウェアスタブ５４を有するが、一方Ｊａｖａ．ＡＷＴ加速器は、関係づけられたＪａｖａ．ＡＷＴソフトウェアスタブ５０を有する。本発明のハードウェアコンポーネントをカバーするソフトウェアスタブは、本発明を互換性のある任意のＯＯＰ言語と使えるようにするために、修正又は置き換えることができる。図２（先に説明済み）は、本発明によるハードウェア加速器６０の内部機能のブロック図である。レジスタインターフェース６４（４０６、４０７、４０９、４１０、４１３、４１５）は、ホストＣＰＵ６２と本発明との間の入出力転送を全て指揮し同期させるために提供される。Ｊａｖａ追従ホストＣＰＵは、Ｊａｖａ仮想マシンを、例えば読み出し専用メモリ（ＲＯＭ）保管庫８８から作動させる。物理的トランスポート９４を介して本発明に送信されるＪａｖａアプレット又はアプリケーションは、次に物理的トランスポートインターフェース８６を介してホストＣＰＵへと向けられる。ＡＷＴコマンドディコーダ４０８とＮＥＴコマンドディコーダ４１４は、２進法入力情報を２進法で表現された出力エレメントへ変換するために使用される。アプレット又はアプリケーションは、バイトコードとしてメモリ４００に記憶される。このアプレット又はアプリケーションを表示するために、ＧＵＩを作成しなければならない。このように、Ｊａｖａプログラムが最初にメモリから実行されると、ＲＯＭに保存されている機能ライブラリに対して、ＧＵＩ表示の生成を指示する呼び出しが行われる。このような呼び出しは、ハードウェアオブジェクト管理システム４０２、４０３とソフトウェアスタブという手段で、適切なＪａｖａアプリケーション・フレームワーク・加速器に向けられる。例えば、Ｊａｖａ．ＡＷＴウインドウに対する要求がある時、Ｊａｖａ．ＡＷＴ加速器はウインドウオブジェクトを作成する。次にグラフィックコマンド・ジェネレータ８０は、グラフィックコントローラ８２に命じてウィンドウをディスプレイ５００上で実際に描画させるよう、要請される。Ｊａｖａ．ＮＥＴ加速器は、Ｅメール及びウェブブラウザ・アプリケーションエンジン７４を含むことができる。このように例えば、本発明を使用してＪＰＥＧ又はＧＩＦ画像をインターネットからダウンロードできる。画像は次に、ネットワークＴＣＰ／ＩＰスタック７６を介しＪＰＥＧ／ＧＩＦディコーダ７８に、そしてその次にはフレームバッファマネジャー８４に管理されているフレームバッファ９２に向けられる。このように本発明はハードウェア装置を使い、ネットワーク接続からダウンロードされたグラフィック画像の表示を加速する。メモリコントローラ／アービトレータ４０１は、ホストＣＰＵと共通の主メモリ４００の間のインターフェースとしての役目を果たす。メモリコントローラ／アービトレータは、本発明の様々なコンポーネントの間にシステムメモリを割り当てて管理する。このメモリ管理には、メモリを例えばＪａｖａ．ＡＷＴ加速器に割り当てることやＣＰＵに本発明によって作成されたオブジェクトのメモリロケーションを提供すること等が含まれる。図８は、本発明による、Ｊａｖａ仮想マシン／ランタイムのマルチスレッド型オペレーションのブロック図である。Ｊａｖａはマルチスレッド構造を有しているので、Ｊａｖａ仮想マシン１６及びＪａｖａランタイム１８上で実行されるＪａｖａアプレット１２若しくはアプリケーション１４を、同時に実行中の複数のスレッド１００、１０２、１０４、１０６の形態とすることができる。サポートされるＪａｖａアプリケーション・フレームワークのクラス又はメソッドを保有するスレッドは、ハードウェアオブジェクト管理システムを介して本発明に方向決めされる。このように本発明の好適実施例のハードウェアオブジェクト管理システムは、Ｊａｖａ仮想マシン上で実行されるスレッドの、Ｊａｖａ．ＡＷＴ２６とＪａｖａ．ＮＥＴ２４の要求を管理する。従って、ハードウェアオブジェクト管理システムがＪａｖａ．ＡＷＴとＪａｖａ．ＮＥＴの要求を管理する一方で、ＣＰＵは、これに依存しないスレッドと命令の処理を継続することができる。図９は、本発明によるハードウェアオブジェクト管理システムの図である。本発明は、Ｊａｖａ．ＡＷＴとＪａｖａ．ＮＥＴの要求がＪａｖａ仮想マシン上で実行されるスレッドで作り出されると、それらを管理する。オブジェクトは、専用のバッファに割り当てられたり、割り当てられなかったりする。ハードウェアオブジェクト管理システムには、オブジェクト要求を受信して記憶するための入力／出力要求待ち行列１０８が含まれる。このような要求には、コンテナ１０を作成せよ、ボーダーレイアウト１１２を作成せよ、パネル１１４を作成せよ、ラベル１１６を作成せよ、テキストフィールド１１８を作成せよ、ボタン１２０を作成せよ、が含まれることもある。タスクプロセッサ１５０が、例えば、新しいコンテナオブジェクト１５２を作成するなどして、オブジェクトにメモリを割り当てるとき、そのオブジェクトは待ち行列からはずされる。能動オブジェクトリスト１２２は、インスタンスのリスト１２４を記憶している。使用中のフラッグ１４０が、あるインスタンスに対するＪａｖａ仮想マシン中の基準カウント数を表示するために提供される。インスタンスに対する基準カウント数がゼロ１４２である時、オブジェクトを記憶しているメモリは、Ｊａｖａ不要情報コレクタ（図示せず）により収集される。能動オブジェクトリストは又、特定のインスタンスが使用中でないこと１２８も表示する。オブジェクトの状態は状態リスト１４４に記憶される。状態には、オブジェクトが使用中１４６であること、又はそのオブジェクトを記憶しているメモリが割り当てられなかったこと１４８を示す表示も含むことができる。図１０は、本発明によりサポートされるＪａｖａアブストラクトウインドウ用ツールキット・オブジェクトを示すブロック図である。ＡＷＴエキスプレス・フレームワークは、ソフトウェアベースのＪａｖａ．ＡＷＴスタブに対するインターフェースとなる。ＡＷＴエキスプレス・フレームワーク１５４自身は、２つの部分に分割されてもよい。「低級装置」は、根本的なＪａｖａコマンドを我々の表示に変換するために不可欠であり、マウス／ペン／キーボード／イベントの制御だけでなくウインドウやビュー階層の更新もできる。「高級装置」は、根本的にＡＷＴの残りのものに関して特性を付加し、このような特性をＵＩエレメント（ボタン、テキストエリア、及びテキストフィールド）にとってのマクロ化されたペインティングとして組み入れる。Ｊａｖａ仮想マシンは、コマンドのセット（タスク）１５６、１５８を使い、データを本発明に送信したり本発明から受信したりする。Ｊａｖａのプログラム言語は、最初は低級オブジェクトに頼る。従って低級レジスタ１５８は、Ｊａｖａ装置に不可欠なオブジェクトを含んでいる。本発明の一実施例では、低級装置のみが装備されている。この実施例は、サイズとメモリの要件が大幅に減っており、組込型システムでの使用に有利である。低級機能には、初歩的なウインドウ制御、画像レンダリング、フォント制御、及びイベント処理が含まれる。本発明の好適実施例によりサポートされる低級オブジェクトには、 ColorModel２１０、 Component２１２、 Container２１４、 CropImageFilter２１６、 DirectColorModel２１８、 Event２２０、 Font２２２、 FontMetrics２２４、 Frame２２６、 Graphics２２８、 GridBagConstraints２３０、 Image２３２、 ImageFiter２３４、 IndexColorModel２３６、 MenuComponent２３８、 PixelGrabber２４０、 RGBImageFilter２４２、が含まれる。高級レジスタ１５６は、随意的にハードウェアに装備できる二次的機能を提供する。このような高級機能には、標準ＧＵＩウィジェットオブジェクト、ＧＵＩレイアウト挙動オブジェクト、及びメディア制御オブジェクトが含まれる。本発明の好適実施例によりサポートされる高級オブジェクトには、 BorderLayer１６０、 Button１６２、 Canvas１６４、 CardLayout１６６、 Checkbox１６８、 CheckboxGroup１７０、 CheckboxMenuItem１７２、 Choice１７４、 Dialog１７６、 FlowLayout１７８、 GridBagLayout１８０、 GridLayout１８２、 Label１８４、 List１８６、 MediaTracker１８８、 Menu１９０、 MenuBar１９２、 MenuItem１９４、 Polygon１９６、 Rectangle１９８、 Scrollbar２００、 TextArea２０２、 TextComponent２０４、 Textfield２０６、 Window２０８、が含まれる。本発明はハードウェアの全アプリケーション・フレームワークを表しているので、本発明により相当な数のコードが必要性でなくなる。例えば、ＯＯＰアプリケーション・フレームワークの一部は、カスタム・アプリケーションで使うのに利用できる一方、その別の部分はアプリケーション・フレームワークが専用に使うように隠されている。しかしハードウェア装置では、このようなフレームワーク部分を隠すことは必要ではない。冗長なコーディングを排除し、ハードウェア・ゲートアレー内でタスクを起動させるソフトウェアスタブに公然とアクセスできる機能のみを、装備することの方がより有用である。このように本発明では、Ｊａｖａアプリケーション・フレームワークの多数のオブジェクトとクラスを排除することに努力が払われている。排除されるクラスの一例は、サン・マイクロシステムズ社のＪａｖａ．ＮＥＴSocketInputStream クラスである。このクラスは、Ｊａｖａ．ＩＯ．からFileInputStreamを継承しているが、最小量の機能しかオリジナルのベースクラスに付加されていない。こうして本発明では、機能を著しく失うことなく、このような冗長なクラスを排除できる。図１１は、本発明による、Ｊａｖａアブストラクトウインドウ用ツールキットのハードウェア装置の機能ブロック図である。Ｊａｖａ．ＡＷＴアプリケーション・フレームワークのインスタンスとメソッドを含むスレッドが、Ｊａｖａ仮想マシン１６から、Ｊａｖａ．ＡＷＴソフトウェアスタブ５０を介しハードウェアオブジェクト管理システム２２へオフロードされる。レジスタインターフェース６４は、ホストＣＰＵ６２とハードウェアオブジェクト管理システムの間の全入出力転送を指揮して同期させる。オブジェクト要求は、受信されると、入力／出力要求待ち行列１０８で処理待ちの状態で記憶される。タスクプロセッサ１５０はここで、各要求をハードウェアＡＷＴ加速器２５０に向ける。この加速器は、ウインドウ用／ビューシステム２５２とレンダリングエンジン２６０を含んでいる。ウインドウ用／ビューシステムは、本発明によって生成されるフレーム管理用のウインドウマネジャー２５４を含んでいる。レイアウトマネジャー２５６は、各フレーム内のコンテナの階層を管理し、一方コンポーネントマネジャー２５８は、各コンテナ内のコンポーネントを管理する。ウインドウ用／ビューシステムはまた、フレームとコンポーネントを作成するための、又データをレンダリングエンジンに伝えるための汎用グラフィックコントローラ８２も含んでいる。Ｊａｖａ．ＡＷＴアプリケーション・フレームワークのハードウェア同等物にとってのマイクロコードは、汎用グラフィックコントローラ中で実行される。オブジェクト／メソッド要求が作られ、ウインドウ用／ビューシステムの他のコンポーネント及びレンダリングエンジンにより適切に実行される。レンダリングエンジン２６０は、画像レンダラー２６２、多角形レンダラー２６４、及びフオントレンダラー２６６等のレンダリング用ツールを用いて、要求されたオブジェクトを作成する。レンダリングエンジン付きで含まれるレンダリングツールのタイプは、サポートされるアプリケーション・フレームワークの特定の要求に従い、様々なものが考えられるということを、当業者は容易に理解するであろう。画像レンダラー２６２は、画像データを受信して圧縮解凍を行う。その画像は次に、ディスプレイの所定コンポーネント内で表示される。多角形レンダラー２６４は、ベクトルベースの画像を表示するための加速器を提供する。弧、線、楕円、多角形、長方形の描画向け等に事前に定義された描画タイプがサポートされることになる。フォントレンダラー２６６は、テキストを表示するための要求を管理する。ウインドウサーバとオブジェクト実行ウインドウサーバ／ウインドウ用システム（図１２参照）は、Ｊａｖａ仮想マシンから最も遠い地点に在る。オブジェクト実行機構（即ちランタイム）から送信されるコマンドを頼りとしているため、ウインドウサーバ／ウインドウ用システムはソフトウェア層からコマンドを直接は決して受信しない。そうしたものなので、ウインドウサーバは、ソフトウェアレベルからの直接的なインターフェースを有していない。これは、ＪａｖａがＰＣ上で作動する方法にほぼ等しい。ピアオブジェクトは通常、ランタイムの外部でリソースをコンパイルするＪａｖａプロセッサからの要求をマップするために作成される。このことはウインドウズ’９５／ＮＴ又は他の最新式ＯＳにとって、標準的なウインドウ用システムのＣコードかアッセンブリコードの何れかに呼び出しを行うことを意味する。このように、これらのオペレーティングシステムで使用されるコンパイルされたコードは、システムレベルウインドウ用の要求を行うために必要なプリミティブを生成する。ウインドウは画面上で管理され、標準的なボタン、スライダー、及び他のＯＳベースのＵＩウィジェットは、コーディングを簡素化するため、性能を上げるため、そしてホストＯＳ自身のインターフェースに整合するユーザーインターフェースを提供するためにしばしば利用される。サン・マイクロシステムズ社のＪＤＫでは、これはピアインターフェースを使って呼び出され、Ｊａｖａオブジェクトとコンパイルされた固有コードとの間の機能をマップするソフトウェアベースのクラススタブのセットを採用している。本発明は、ピアという観念を漠然と使用している。しかし、ピア装置は、ゲートレベルの装置に全面的に提供され、他のＡＳＩＣベースの機能（即ちハードコード型Ｊａｖａオブジェクト）からのみアクセス可能である。こうすることは多くの点で意味がある。第１に、ピアベースの描画型は、レジスタ定義レベルで容易に交換することができ、カスタム又は多数のＵＩ装置の作成を可能にする。第２に、ＡＳＩＣＳのピアを、適切なハードウェアの異なるセクションに適切に区分することができる。これがハードウェアとソフトウェアの間の違いである。ソフトウェアでは、論理的な機能上のグループ分けが構築されるが、他方ＡＳＩＣＳでは、効率性とゲートカウント低減を目指して構築される。ソフトウェアでは、オブジェクトベースの機能性を、規律正しいやり方で論理的にグループ分けする。ビューベースオブジェクトの全ては、１つの場所．．．１つのフレームワークへとほとんど入っていく。ハードウェアでは、物事を分割する必要がある。オブジェクト表現をＵＩオブジェクト毎にウインドウサーバで構築することもできよう。しかし、これは効率的でもなく必要でもないことが判明している。必要性の点から見ると、できるなら、最小ゲートカウントのためには優雅さを犠牲にすべきで、そうすると図１２のシナリオはより魅力的な設計になるといえる。ウインドウ用システムの本装置では、標準的なＪａｖａ「ピア」オブジェクトに匹敵するオブジェクトはほんの数個しかない点に注意されたい。それらオブジェクトは、機能がより要約されたセットをサポートするので、ソフトウェア専用Ｊａｖａ装置でのピアとはかなり異なる。ソフトウェア装置は、ＵＩオブジェクト毎（例えば、ボタン、スライダー、テキストコンポーネント等）に１つのピアを割り当てるが、本発明では、コンポーネント関係描画の全要求を扱う単一コンポーネントピアを採用している。どのようにレンダリングエンジンが働くかレンダリングエンジン５１１は、ここで、実際の描画コードの全てをカプセル化して、フレームインスタンス５１２、グラフィックインスタンス５１３、コンポーネントインスタンス５１４、ストリングインスタンス５１５を翻訳するためのレンダラー／ハンドラーを提供する。レンダリングエンジンは、通常これらのインスタンスに、メモリリファレンスによるか又は固定サイズのデータストリーム（３０バイト）を経由してかのどちらかによってアクセスされる。インスタンスは、コマンドバイトを保有しており、オブジェクトに対してどの方法を実行すべきかをレンダリングエンジンに命令する。レンダリングエンジンはインスタンスを受信すると、まず送信中のオブジェクトのタイプをサポートされる４つのオブジェクトのタイプの内の一つにデコードする。オブジエクトタイプが一旦分かると、特定オブジェクトタイプ用のデコーダーまでリファレンスが伝えられる。実行方法（例えばcomponent:paint( )）が確定すると、その方法が実行される。レンダリング・コンポーネント・インスタンス Component:paint( )につき、オブジェクトは、表示されるべきコンポーネントのタイプを見分けるために更に照会を受ける。現時点でレンダリングエンジンのコンポーネントセクションは、図１３に示す画面ベースウィジェットのタイプをどうレンダーするのかを知っている。一旦、レンダリングエンジンが、自身が描くコンポーネントのタイプに気づくと、インスタンスは、ウィジェットの位置や寸法等の情報について問い合わせを受ける。次にコンポーネントは、ディスプレイ上にレンダーされる。オブジェクトはかなり小さいので、コンポーネントインスタンス内でストリングを伝送することは不可能である。本発明の場合がそうであるが、固定サイズのインスタンスは３０バイトであり、これはストリング自身のサイズより小さいものである。このため、ストリング又はストリングに対する最少リファレンスが、実際のコンポーネントを送る前に、レンダリングエンジンに送られる。ストリングはレンダリングエンジンにより蓄積される。ストリング情報を保有する固定バイトオブジェクトに対するストリーム又はリファレンスが、普通はレンダリングエンジンに送られる。このストリングに、別のストリングを保有する別の固定ブロックが続いてもよい。後続の送信は、コンポーネントインスタンスが到着するまで、ストリングの最後尾に連鎖して続く。一旦、コンポーネントが到着すると、ため込まれたストリングはコンポーネントに関連づけられ、次にそのコンポーネントはそのストリングを付けてレンダーされる。連鎖は、非常に大きなストリングを有するテキストフィールドの場合、特に必要である。最終的なＡＳＩＣ形態では、連鎖処理（図１４参照）は、連鎖型ストリング自身の代わりに、レンダーされるストリングを保有する固定ブロックに対する累積されたポインターから成ることに留意されたい。こうしたことが必要な理由は、コンポーネントによっては、従来型のＪａｖａ上では３２キロバイト又はそれより大きいかもしれないテキストエリアのような非常に大型のテキストコンテンツを有してもよいからである。テキストエリアは本質的にはテキストエディタオブジェクトである。本発明の縮小バージョンでは、小型メモリフットプリント付きのデバイス上での効率的使用を保証するために、許容されるテキスト文字の最大数を任意に指定できるであろう。一旦、コンポーネントがそのストリングと共にレンダーされると、ストリング自身は、次のストリング／コンポーネントの組み合わせに備えて、零に設定される。グラフィックインスタンスのレンダリンググラフィックインスタンスは、コンポーネントインスタンスとは異なる。グラフィックインスタンスは、低級プリミティブを描くことに責任を負い、そこではコンポーネントはこれを駆動させるか、又は編集可能なテキストエリアのようなものを描くために、線、充填エリア、及びテキストを始めとして、何百というプリミティブさえも駆動させる。グラフィックオブジェクトは、一般型のプリミティブ描画をサポートする。図１５に示すレンダリングの型は、レンダリングエンジンのグラフィックオブジェクトでサポートされる。レンダリングエンジンのグラフィックピア装置は、幾分複雑ではあるが、実際にはコンポーネントピアよりもはるかに単純である。グラフィックは、非常に低級な描画を供給するが、他方コンポーネントは通常、先のパラグラフで説明したように、グラフィック描画動作のセットを単一のマクロへと組み合わせる。レンダリング・フレーム・インスタンスフレームは、フレームが行うことから見ると、比較的簡単である。これはある種のフレームピア装置であり、ウインドウを特定タイプのスクリーン上に描く。ウインドウディスプレイのタイプは、装置次第で変わるので、多様性タイプをサポートしてもよく、レンダリングエンジンの場合は全面的にこのタイプのものである。一般的にフレームは、タイトルバー、アイコン画像、及びカーソルタイプをフレームに組み入れている。フレームは、コンポーネントとグラフィックがするのと同じやり方で動作するが、フレームが保有するＵＩの裏に描かれる。フレームは、標準Ｊａｖａ装置のコンテナの一タイプである。しかし、これはフレームピアのようなものなので、他の何れのオブジェクトとも直接的な関係を持たない。レンダリングエンジンに限ればウインドウは、特定のセットの線等を描くマクロ付きの特別オブジェクトにすぎない。フレームは、コンポーネントがこのレベルで動作するのに非常に似たやり方で行動する。図１６は、本発明による、ＪａｖａＡＷＴ加速器オブジェクト管理を示すブロック図である。オブジェクト要求は、実行エンジン２７０の入力／出力要求待ち行列１０８に並んで、処理の順番待ちの状態となる。１つのオブジェクトが作動すると、そのオブジェクトは能動オブジェクトリスト１２２に加えられる。図１６では、入力／出力要求待ち行列の最初のオブジェクト要求は、フレームオブジェクト２７２を作成することである。フレームオブジェクトが作成されると、それは能動オブジェクトリスト２７４に加えられる。次のオブジェクト要求２７６は、イベントオブジェクトを作成するというものであるが、この要求が次に入力／出力要求待ち行列の一番上に移動する。イベントオブジェクトが作成されると、それはまた能動オブジェクトリストに加えられる。オブジェクトは、オブジェクトＪａｖａ仮想マシン不要情報コレクタの基準カウントがゼロに下がるまで、アクティブのままである（図９参照）。更にオブジェクトは、必要に応じ、お互いに対するリファレンスを保有することもある。例えば、ウインドウの中の関係、ウインドウ内のボタン、及びボタン上に表示されるテキストが、こうしたリファレンスにより表示される。図１７は本発明による、ＪａｖａＡＷＴ加速器ウインドウ／ビューシステム２５２内の機能を説明したものである。Ｊａｖａ．ＡＷＴアプリケーション・フレームワークのハードウェア同等物用のマイクロコードが、汎用グラフィックコントローラ８２で実行される。本発明の好適実施例の場合、汎用グラフィックコントローラが実行する機能には、以下が含まれる。フレーム（即ちウインドウ）を作成すること、コンポーネント（即ち画面）を作成すること、画像データを画像レンダラーに渡すこと、テキストをフォントレンダラーに渡すこと、形を多角形レンダラーに渡すこと、フレームとコンポーネント向けに選択（焦点）を準備すること、フレームとコンポーネントをディスプレイから物理的に削除すること、ペイント方法が画面に呼ばれた時にオブジェクト階層を横断すること、フレームとコンポーネントのチェーンを介して、マウスとキーボードのイペントを「渡す」ことで、それらを操作すること、ウインドウマネジャー２５４が実行する機能には、以下が含まれる。多角形レンダラーの多角形描画を使用してウインドウを描くこと、ウインドウが重なるようにウインドウを管理すること、イベントが起きたフレームを確定して、フレーム更新が必要かもしれないことを適切なレイアウト管理インスタンスに通知すること、各フレーム内のコンテナ階層を監督すること、ウインドウ／ビューシステムにも、レイアウトマネジャー２５６とコンポーネントマネジャー２５８が含まれている。レイアウトマネジャーはフレームに属して（フレームによって照会され）、以下の機能を果たすフレームの範囲内でコンテナ階層を管理すること、イベントが起きたコンテナを確定して、必要ならコンテナに更新の指示を出すこと、コンポーネントマネジャーが実行する機能には、以下が含まれている。コンテナの範囲内でコンポーネント階層を管理すること、イベントが起きるコンポーネントを確定して、必要ならコンポーネントに更新するよう指示を出すこと、図１８は本発明による、Ｊａｖａアブストラクトウインドウ用ツールキット、即ちウインドウ／コンテナ／ビューインスタンス階層２９０の１例のブロック図である。フレーム２９２は、１つ又はそれ以上のコンテナ２９４、２９６を保有できる。そして各コンテナは、１つ又はそれ以上の、タイプの異なるコンポーネントを保有できる。図１９は、本発明によりサポートされるＪａｖａＮＥＴオブジェクトのブロック図である。ユーザーが、事前に実在しているコンポーネントを：Ｒｅａｄｙ．ＮＥＴ／ＩＯフレームワーク１５４から集めることにより、Ｊａｖａ．ＮＥＴとＪａｖａ．ＩＯフレームワークのオブジェクトとメソッドを作成することができるように、オーサリングツールを提供してもよい。本発明の好適実施例でサポートされるＪａｖａ．ＮＥＴクラス３２０には、 DatagramPacket３２４、 DatagramSocket３２６、 HttpURLConnection３２８、 InetAddress３３０、 MulticastSocket３３２、 ServerSocket３３４、 Socket３３６、 SocketImpl３３８、 URL３４０、 URLConnection３４２、 URLEncoder３４４、 URLStreamHandler３２６、が含まれる。本発明の好適実施例でサポートされるＪａｖａ．ＩＯクラス３２２には、 BufferInputStream３４８、 BufferOutputStream３５０、 ByteArreyOutputStream３５２、 DataInputStream３５４、 DataOutputStream３５６、 LineInputStream３５８、 PrintStream３６０、 <Generalized Method>３６２、 <Generalized Functionalities>３６４、が含まれる。多数の冗長なサポートオブジェクトは、ネットワキーング機能の損失を起こすことなく、Ｊａｖａ．ＮＥＴ加速器から排除されている。図２０は、本発明によるＪａｖａ．ＮＥＴ加速器の機能ブロック図である。Ｊａｖａ．ＮＥＴアプリケーション・フレームワークのインスタンスとメソッドを含むスレッドは、Ｊａｖａ仮想マシン１６からＪａｖａ．ＮＥＴソフトウェアスタブ５２を通じてハードウェアオブジェクト管理システム２２へと、オフロードされる。レジスタインターフェース６４は、ホストＣＰＵとハードウェア管理システムの間の全入力／出力転送を指揮して同期させる。Ｊａｖａ．ＮＥＴオブジェクト要求は受信されると、入力／出力要求待ち行列１０８に処理順番待ちのまま記憶される。タスクプロセッサ１５０は次に、各リクエストをハードウェアＮＥＴ加速器３７０に向ける。加速器は、ネットワーキングシステム３７２と接続エンジン３８２を含んでいる。接続エンジンは要求を実行し、例えばＩＰ３８４、ＴＣＰ／ＩＰ３８６、及びＵＤＰ３８８等のネットワークプロトコルを使って、ネットワーク接続を確立させ、保守し、又は終結させる。Ｊａｖａ．ＮＥＴ加速器用のマイクロコードは、ネットワークコントローラ３７４で実行される。ウインドウ用／ビューシステムも、ネットワーク照会機構３７６、ソケットマネジャー３７８、及びストリームマネジャー３８０を含んでいる。図２１は、本発明による、Ｊａｖａ．ＮＥＴ加速器のウインドウ用／ビューシステム３７２内の機能を説明したものである。ネットワークコントローラ３７４の機能には、ＤＮＳ照会を合図すること、ソケット作成を合図し、多数のソケットを同時に作成させること、ネットワーク入力／出力を指揮すること、ソケットの閉鎖を合図すること、ＴＣＰとＵＤＰプロトコルを通してアブストラクション層として働くこと、が含まれる。ネットワークコントローラは、同期又は非同期のいずれでも作動できる。ネットワーク照会機構３７６は、ＤＮＳルックアップを実行し、その結果をネットワークコントローラに報告する。ソケットマネジャー３７８は、アプリケーションが使っているソケットを管理する。この菅理には、ソケット接続の開閉が含まれる。ソケットマネジャーはまた、イベントが起きたコンテナを確定して、必要ならコンテナに更新するよう通知する。要求の起きた時、ソケット状態はネットワークコントローラに転送される。ストリームマネジャー３８０は、文字／ストリームに基づく入力と出力を、ＴＣＰ／ＩＰ又はＵＤＰリンク上で往復させる。ストリームマネジャーは、アプリケーションの使用毎に異なる入力／出力ストリームの選択枝を提供する。更に、要求の起きた時、ストリームマネジャーは、バッファをネットワークコントローラに転送する。ここでは好適実施例を参照しながら発明について説明したが、当業者には、本発明の精神と範囲を逸脱することなく、他のアプリケーションをここに述べたものに代えることもできるということが容易に理解できるであろう。例えば本発明の好適実施例では、任意の数のサポートされるアプリケーション・フレームワークに対して、１つのハードウェアオブジェクト管理システムだけがＡＳＩＣ上で必要である。しかし、代替実施例では多数のハードウェアオブジェクト管理システムが提供される。例えばＡＳＩＣ等の分離型アプリケーション・フレームワークが、サポートされるアプリケーション・フレームワークそれぞれに提供されることもあり、その場合には各ハードウェアコンポーネントは、専用のハードウェアオブジェクト管理システムを持つことになる。本発明は、コンピュータシステムの一部として形成されてもよく、又ＰＣＩカード等の挿入可能なデバイスの一部として形成されてもよい。当業者は、よく知られているプログラミング用技術と装置を使用して、本発明に必要とされるハードウェアとソフトウェアを、容易に構築することができるであろう。よって、本発明は、以下の請求項目によってのみ限定されるべきである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＵ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＣＡ，ＣＮ，ＣＵ，ＣＺ，ＥＥ，ＧＥ，ＧＷ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＰ，ＫＲ，ＬＣ，ＬＫ，ＬＲ，ＬＴ，ＬＶ，ＭＧ，ＭＫ，ＭＮ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＲ，ＴＴ，ＵＡ，ＵＺ，ＶＮ，ＹＵ (72)発明者コヤマリョウアメリカ合衆国カリフォルニア州 94301 パロアルトホーソーン 343 【要約の続き】フレームワーク専用型ハードウェア加速器によって実行される。アプリケーション・フレームワーク・クラスは、必要に応じ共通メモリから検索され、実行された命令は、中央演算処理ユニットによりアクセスできる共通メモリに記憶される。サポートされないアプリケーション・フレームワーク命令の中央演算処理ユニットによる処理は、ハードウェア加速器がハードウェアオブジェクト管理システムの要求を実行している間も、継続される。

Claims

【特許請求の範囲】１．オブジェクト指向型プログラミング言語を実行するプロセッサを加速するための装置において、前記オブジェクト指向型プログラミング言語の少なくとも１つのアプリケーション・フレームワークを実行するためのハードウェア加速器と、前記ハードウェア加速器を前記プロセッサにインターフェースするためのソフトウェアスタブとから成ることを特徴とする装置。２．前記オブジェクト指向型プログラミング言語がＪａｖａであることを特徴とする、上記請求項１に記載の装置。３．前記アプリケーション・フレームワークのインスタンスと前記インスタンスに割り当てられた値の状態を管理するためのハードウェアオブジェクト管理システムを更に含んでいることを特徴とする、上記請求項１に記載の装置。４．前記ハードウェア加速器が、前記命令を受信して、各命令を実行待ちの状態にしたままシーケンシャルに記憶するための入力／出力要求待ち行列と、前記命令を処理するためのタスクプロセッサと、あるインスタンスに対する基準カウント数を追跡するための、そして使用中でないインスタンスを割り振らないための能動オブジェクトリストとから成ることを特徴とする、上記請求項１に記載の装置。５．前記ハードウェ加速器が、Ｊａｖａ．ＡＷＴアプリケーション・フレームワークを実行することを特徴とする、上記請求項１に記載の装置。６．ウインドウ用／ビューシステムと、レンダリングエンジンとを更に含むことを特徴とする、上記請求項５に記載の装置。７．前記ウインドウ用／ビューシステムが、フレームとコンポーネントを作成するための、そしてデータを前記レンダリングエンジンに伝達するための、汎用グラフィックコントローラと、前記フレームを管理するためのウインドウマネジャーと、前記フレーム内でコンテナ階層を管理するためのレイアウトマネジャーと、前記コンテナ内でコンポーネント階層を管理するためのコンポーネントマネジャーとから成ることを特徴とする、上記請求項６に記載の装置。８．前記ハードウェア加速器が、Ｊａｖａ．ＮＥＴとＪａｖａ．ＩＯのアプリケーション・フレームワークを装備することを特徴とする、上記請求項１に記載の装置。９．ウインドウ用／ビューシステムと、接続エンジンとを更に含むことを特徴とする、上記請求項８に記載の装置。 10．前記ウインドウ用／ビューシステムが、前記ハードウェアオブジェクト管理システムに応答するネットワークコントローラであって、前記ネットワークコントローラはＪａｖａ．ＮＥＴフレームワークの同等物にとってのマイクロコードを実行し、前記ネットワークコントローラは前記接続エンジンにサポートされるプロトコルを通じてアブストラクト層として働く、そのようなネットワークコントローラと、ＤＮＳルックアップを実行するための、そして前記ネットワークコントローラに結果を報告するためのネットワーク照会機構と、アプリケーションが使っているソケットを管理するためのソケットマネジャーと、入力／出力データを、前記プロトコルによりサポートされるリンクを介して往復させるためのストリームマネジャーとから成ることを特徴とする、上記請求項９に記載の装置。 11．前記ハードウェア加速器が、アプリケーション専用型集積回路の一部として形成されていることを特徴とする、上記請求項１に記載の装置。 12．Ｊａｖａプログラミング言語を実行するプロセッサを加速させるための装置において、少なくとも１つのＪａｖａアプリケーション・フレームワークを実行するためのハードウェア加速器と、アプリケーション・フレームワークのインスタンスと前記インスタンスに割り当てられた値の状態を管理するためのハードウェアオブジェクト管理システムであって、前記ハードウェアオブジェクト管理システムは、前記命令を受信して、各命令を実行待ちの状態にしたまま記憶するための入力／出力要求待ち行列と、前記命令を処理するためのプロセッサと、あるインスタンスに対する基準カウント数を追跡するための、そして使用中でないインスタンスを割り振らないための能動オブジェクトリストとから成る、そのようなハードウェアオブジェクト管理システムと、前記ハードウェアオブジェクト管理システムを前記プロセッサにインターフェースするためのソフトウェアスタブとから成ることを特徴とする装置。 13．前記ハードウェア加速器が、Ｊａｖａ．ＡＷＴアプリケーション・フレームワークを実行することを特徴とする、上記請求項１２に記載の装置。 14．ウインドウ用／ビューシステムと、レンダリングエンジンとを更に含むことを特徴とする、上記請求項１３に記載の装置。 15．前記ウインドウ用／ビューシステムが、フレームとコンポーネントを作成するための、そしてデータを前記レンダリングエンジンに伝達するための汎用グラフィックコントローラと、前記フレームを管理するためのウインドウマネジャーと、前記フレーム内でコンテナ階層を管理するためのレイアウトマネジャーと、前記コンテナ内でコンポーネント階層を管理するためのコンポーネントマネジャーとから成ることを特徴とする、上記請求項１４に記載の装置。 16．前記ハードウェア加速器が、Ｊａｖａ．ＮＥＴとＪａｖａ．ＩＯのアプリケーション・フレームワークを実行することを特徴とする、上記請求項１２に記載の装置。 17．ウインドウ用／ビューシステムと、接続エンジンとを更に含むことを特徴とする、上記請求項１６に記載の装置。 18．前記ウインドウ用／ビューシステムが、前記ハードウェアオブジェクト管理システムに応答するネットワークコントローラであって、前記ネットワークコントローラはＪａｖａ．ＮＥＴフレームワークの同等物にとってのマイクロコードを実行し、前記ネットワークコントローラは前記接続エンジンにサポートされるプロトコルを通じてアブストラクト層として働く、そのようなネットワークコントローラと、ＤＮＳルックアップを実行するための、そして前記ネットワークコントローラに結果を報告するためのネットワーク照会機構と、アプリケーションが使っているソケットを管理するためのソケットマネジャーと、入力／出力データを、前記プロトコルによりサポートされるリンクを介して往復させるためのストリームマネジャーとから成ることを特徴とする、上記請求項１７に記載の装置。 19．前記ハードウェア加速器が、アプリケーション専用型集積回路の一部として形成されていることを特徴とする、上記請求項１２に記載の装置。 20．オブジェクト指向型プログラミング言語を実行するプロセッサを加速するための方法において、前記オブジェクト指向型アプリケーション・フレームワークの少なくとも１つのアプリケーション・フレームワークをハードウェア加速器により実行する段階と、前記ハードウェア加速器を前記プロセッサにソフトウェアスタブによりインターフェースする段階とから成ることを特徴とする方法。 21．前記オブジェクト指向型プログラミング言語が、Ｊａｖａであることを特徴とする、上記請求項２０に記載の方法。 22．前記アプリケーション・フレームワークのインスタンスと、前記インスタンスに割り当てられた値の状態を、ハードウェアオブジェクト管理システムを使って管理する段階を更に含んでいることを特徴とする、上記請求項２０に記載の方法。 23．少なくとも１つのアプリケーション・フレームワークを実行する前記段階が、前記命今を受信して、各命令を実行待ちの状態にしたまま入力／出力要求待ち行列にシーケンシャルに記憶する段階と、前記命令をタスクプロセッサで処理する段階と、あるインスタンスに対する基準カウント数を追跡し、使われてないインスタンスを能動オブジェクトリストにより割り振らない段階とから成ることを特徴とする、上記請求項２０に記載の方法。 24．前記ハードウェア加速器が、Ｊａｖａ．ＡＷＴアプリケーション・フレームワークを実行することを特徴とする、上記請求項２０に記載の方法。 25．ウインドウとビューをウインドウ用／ビューシステムで作成して表示する段階と、前記ウインドウとビューを、レンダリングエンジンでディスプレイ上に描く段階とを更に含むことを特徴とする、上記請求項２４に記載の方法。 26．フレームとコンポーネントを作成するための、そしてデータを前記レンダリングエンジンに伝達するための、汎用グラフィックコントローラを提供する段階と、前記フレームを管理するためのウインドウマネジャーを提供する段階と、前記フレーム内でコンテナ階層を管理するためのレイアウトマネジャーを提供する段階と、前記コンテナ内でコンポーネント階層を管理するためのコンポーネントマネジャーを提供する段階とを更に含むことを特徴とする、上記請求項２５に記載の方法。 27．前記ハードウェア加速器が、Ｊａｖａ．ＮＥＴとＪａｖａ．ＩＯのアプリケーション・フレームワークを実行することを特徴とする、上記請求項２０に記載の方法。 28．ウインドウ用／ビューシステムにより、ウインドウとビューを作成して表示する段階と、接続エンジンを使ってネットワーク接続を管理する段階とを更に含むことを特徴とする、上記請求項２７に記載の方法。 29．前記ハードウェアオブジェクト管理システムに応答するネットワークコントローラであって、前記ネットワークコントローラはＪａｖａ．ＮＥＴフレームワークの同等物にとってのマイクロコードを実行し、前記ネットワークコントローラは前記接続エンジンにサポートされるプロトコルを通じてアブストラクト層として働く、そのようなネットワークコントローラを提供する段階と、ＤＮＳルックアップを実行するための、そして前記ネットワークコントローラに結果を報告するためのネットワーク照会機構を提供する段階と、前記アプリケーションが使っているソケットをソケットマネジャーで管理する段階と、入力／出力データを、前記プロトコルによりサポートされるリンクを介してストリームマネジャーで往復させる段階とを更に含むことを特徴とする、上記請求項２８に記載の方法。 30．前記ハードウェア加速器が、アプリケーション専用型集積回路の一部として形成されていることを特徴とする、上記請求項２０に記載の方法。 31．前記ハードウェアオブジェクト管理システムが、オブジェクトＩＤを呼び出し用システムに折り返し提供し、前記オブジェクトＩＤが可変ビット長でもよいことを特徴とする、上記請求項２２に記載の方法。 32．前記ハードウェアオブジェクト管理システムが前記オブジェクト識別オブジェクトを識別するために呼び出し用システムからオブジェクトＩＤを受け入れることができ、更に、ベースオブジェクトＩＤをベースリファレンスレジスタに記憶し、前記ベースオブジェクトＩＤをフリーオブジェクトロケーションと関連づける段階と、前記オブジェクトＩＤを或るオブジェクトロケーションに関連づけるために、他のオブジェクトＩＤ全部について前記ベースリファレンスレジスタを参照する段階とを含むことを特徴とする、上記請求項２２に記載の方法。