JP2005531066A - ソフトウェア・アトマイゼーション用のビュー - Google Patents

Abstract

ソフトウェア・アトマイゼーション用のビューは新たまたは仮想データベースを作成するために、アトム・データベース内の既存のアトムをランタイム変換する。ビューはアトム・データベースに記憶されているコードおよびデータ・アトムを共用し、かつメモリに読み込まれているコードおよびデータ・アトムを共用する。ビューは新たなアトムの挿入、既存のアトムの修正、または既存のデータの削除を含む、アトム・データベースに適用可能な１組の変換オペレーションである。変換オペレーションはディスク上に新たなアトム・データベースを作成するために実際に施し得、またはディスク上に実際のアトム・データベースを実際に作成する必要なく、ランタイムで仮想アトム・データベースを作成するために仮想的に施すこともできる。既存のアトムの修正はアトム・バイト、またはアトム・リファレンス、またはアトムの属性の変更を含む多様な方法で実行可能である。

Description

関連出願
本出願は参照により本明細書に全体が組み込まれている、２００２年６月２１日に出願された米国特許出願第１０／１７８、８９８号の継続出願である。

発明の背景
一般にコンピュータ・ソフトウェアはインタープリタ型言語システムまたはコンパイラ型言語システム用に作成される。インタープリタ型言語システムは高レベル・プログラム・ステートメントを実行可能な形式に翻訳し、実行前に高レベル・ステートメントを完全に翻訳する（すなわちコンパイルする）のではなく、一度に１つのステートメントを実行する。ベーシック、ＬＩＳＰ、およびＡＰＬはインタープリタ型言語として広く実施されている。コンパイラ型言語は高レベル・プログラム・ステートメントを実行前に中間のオブジェクトコード・フォーマットに翻訳する。コンパイラ型言語システムでは、プログラム・ステートメントはソースコード・プログラミング言語（例えばＣ、Ｃ＋＋）で書き込まれる。ソース・コードはコンピュータによって直接実行できない高レベル、もしくはアセンブリ言語で書き込まれた人間に読み取り可能なプログラム・ステートメントを含んでいる。ソース・コードは１組の構文および意味規則に従うことによって、ソース・コードをオブジェクト・コード（例えばＯＢＪファイル）へと変換するコンパイラによって処理される。次にオブジェクト・コードは実行可能なコンピュータ・プログラム（例えばＥＸＥファイル）を作成するためにリンカーを用いて互いにリンクされる。

実行可能なコンピュータ・プログラムはディスクに記憶された状態と、コンピュータ・メモリへとロードされた場合の双方でサイズが極めて大きいことが可能である。ダイナミック・リンク・ライブラリ（“ＤＬＬ”）は主要な実行可能コンピュータ・プログラムから分離された実行可能ルーチンおよびデータを記憶する機構を備えている。実行可能ルーチンは実行可能コンピュータ・プログラムが必要とする必要時にロードされることができる。ＤＬＬはルーチンまたはデータが利用される場合にメモリだけを使用することによってスペースを節約する。ＤＤＬはさらに、実行可能コンピュータ・プログラムから分離され、また他のＤＤＬから分離されたコンピュータ・コードおよびデータの編成および管理をも行う。それによってプログラマーは、コンピュータ・プログラムまたはその他のいずれかのＤＬＬを呼び出すオペレーションに影響を及ぼすことなく、また呼び出しプログラムまたはその他のいずれかのＤＬＬの再コンパイルを必要とせずに、ＤＬＬ内のあるルーチンだけを修正、または改良することが可能になる。その上、ＤＬＬは複数のコンピュータ・プログラム間で共用可能である。ＤＬＬ自体は極めて大きく、多重に実行可能なルーチンであり、ＤＬＬはそのモノリシックな性質のためダウンロード、更新、およびローディングに関して極めて粒状（グラニュラー）であるとは言えない。

大規模ＤＬＬまたはその他のコード／データの更新に関連する転送時間を最小限にする技術が存在する。差分検出アルゴリズム（例えばｒｓｙｎｃ）を利用したファイル転送プロトコルは転送時間を短縮することができる。これらのアルゴリズムはソース・ファイルおよびターゲット・ファイルをデータ・ブロックへと整理し、ブロックを分析し、ソース・ファイルとターゲット・ファイルとで同一ではないブロックだけを転送する。

通信媒体を介して、およびディスクからメモリまでの双方のコードおよびデータの転送時間を短縮するために圧縮を利用できる。実行可能コード用の圧縮を実施する実行可能なコード・サイズに特に敏感な組み込みプロセッサ・システムが実装されてきた。コードの圧縮された「ワイヤ」表現を利用できるが、実行前にコードを復元しなければならない。別の技術は圧縮されたコードを直接実行する（例えば「バイト符号化ＲＩＳＣ」または「ＢＲＩＳＣ」仮想機械）。

Ｃｕｒｌ^ＴＭ言語はレイアウト、スクリプト、およびプログラミング能力を１つの統合された環境に結合する。この完全機能言語をクライアント側の実行と対にすることによって、Ｃｕｒｌ^ＴＭ技術はウエブを介して迅速で、効率がよく機能性が高いアプリケーションを提供し、クライアントとサーバーとが連携できる対話型のウエブ・サービス能力を可能にする。Ｃｕｒｌ^ＴＭコンテンツはＣｕｒｌ^ＴＭプラグインおよびＣｕｒｌ^ＴＭランタイム環境で強化されたウエブ・ブラウザを用いて表示される。Ｃｕｒｌ^ＴＭランタイム環境は、ほぼ同僚のコードとデータからコンパイルされるので多くのランタイム環境とは異種である。Ｃｕｒｌ^ＴＭは多数のＤＬＬを使用して実現される。

発明の概要
大規模な実行可能プログラムおよび／または共用ライブラリ（ＤＬＬ）を備えたシステムにはディスクに記憶される際、並びにメモリにロードされる際に容量の問題がある。その上、これらのシステムの更新／パッチには、出荷時に拡張された大域幅が必要であり、コードおよび／またはデータの複数のほぼ同じコピーがクライアント側に記憶される結果になることが多い。このことが特に当てはまるのは、コンピュータ・システムが増加するさまざまな新レリースを経て進化し、ユーザーは複数のレリースに対応するサポートを同時に必要とするからである。

アトム・データベースのビューは新たな、または仮想データベースを作成するために、アトム・データベース内の既存のアトムをランタイム変換することによってこれらの問題に解決策をもたらす。ビューはアトム・データベースに記憶されているコードおよびデータ・アトムを共用し、ならびにメモリに読み込まれているコードおよびデータ・アトムを共用する。アトムとは永続識別子、コード／データ・バイト、および他のアトムへのリファレンスを含む細粒度のアドレス指定可能なコードまたはデータのユニットである。本特許出願は、教示内容全体が参照により本明細書に組み込まれている、２００２年６月３日にＭａｔｈｅｗ Ｊ．ＨｏｓｔｅｔｔｅｒおよびＢｅｎｊａｍｉｎ Ｒ．Ｈａｒｒｉｓｏｎによって出願された係属米国特許出願第１０／１６１、９６４号“Ｓｏｆｔｗａｒｅ Ａｔｏｍｉｚａｔｉｏｎ”の関連出願である。

ビューは新たなアトムの挿入、既存のアトムの修正、または既存のデータの削除を含む、アトム・データベースに適用可能な１組の変換オペレーションである。修正も削除もされないアトム用には再利用オペレーションが絶対的である。変換オペレーションはディスク上に新たなアトム・データベースを作成するために実際に施すこともでき、またはディスク上に実際のアトム・データベースを実際に作成する必要なく、ランタイムで仮想アトム・データベースを作成するために仮想的に施すこともできる。既存のアトムの修正はアトムバイト、またはアトムリファレンス、またはアトムの属性の変更を含む多様な方法で実行することができる。ビューは必要なら、アトム・データベースを適切に修正するために破壊的にさえ適用可能である。

様々な種類のビュー変換には様々な利点と欠点がある。仮想アトム・データベースを作成するためにビューを仮想的に適応すればアトムを記憶するために要するスペースは少なくなるが、アトムがロードされるごとに変換オペレーションが行われるのでランタイムで遅くなる。利点は変換情報が保持され、様々なビュー間でアトムを共用するために利用できることである。新たなアトム・データベースを作成するためにビューを実際に適応すればより大きいディスクのスペースが必要であるが、変換オペレーションがすでに適用されているのでランタイムでより迅速になる。それによって、変換されたアトムを直接ロードすることができるが、様々なビュー間でアトムを共用する能力は失われる。アトム・データベースを共用できない場合でも、異なるアトム・データベースのコピーで各実行可能を実行することができる。既存のアトム・データベースに上書きするためにビューを実際に適用すればディスクのスペースは節減され、ランタイムでより迅速になるが、変換がなされてしまうと、変換情報は失われ、したがってもはやアトム・データベースを異なるビュー間で共用できない。あらゆる状況に最適な単一のオプションはない。特定の性能基準を満たすために最良の全般的解決策を選択するためには、それぞれのコンピュータ・プログラム環境が様々なビュー・オプションの利点と欠点のバランスをとらなければならない。

マッピング・テーブルは、唯一のオペレーションが修正オペレーションであり、またこれらの修正オペレーションは既存のアトムのアトム・バイトおよびアトム・リファレンスを別のアトムのアトム・バイトおよびアトム・リファレンスと置き換えることしかできない（置換オペレーションとして知られている）簡単なビュー形式である。これは同じアトムｉｄを保持しつつ、（実際に、または仮想的に）既存のアトムを完全に別のアトムと置き換えるために利用できる。それによって古いアトムへのアトム・リファレンスを有するかもしれない他のいずれかのアトムは、代わりに置き換えたアトムを「自動的に」参照することができるようになる。マッピング・テーブルは既存のアトムを別のアトムと置き換えるので、これらのテーブルはあるアトム・バイトを英語から日本語に翻訳すること、またはあるアトム・リファレンスをレイジーからイーガー（ｆｒｏｍ ｌａｚｙ ｔｏ ｅａｇｅｒ）へと変更することのような関心ある修正オペレーションを随意に実行することができる。

アトム・データベースのビューを作成する方法は、１組の変換オペレーションを規定し、この１組の変換オペレーションをアトム・データベースに適用することを含んでいる。ランタイムで変換オペレーションが仮想的に行われた場合は、
仮想アトム・データベースが作成され、変換オペレーションが実際に行われた場合は新たなアトム・データベースが作成される。アトム・データベースはアトムを記憶し、アトムは永続的に割り当てられているアトム識別子、コンピュータ・コードおよび／またはデータ、および他のアトムへのリファレンスを含んでいる。新たなアトム・データベースはアトム・データベースから分離したファイルに記憶することができ、またはオリジナルのアトム・データベースと置き換えることができる。変換オペレーションは新たなアトムを挿入する挿入オペレーション、既存のアトムを修正する修正オペレーション、および／または既存のアトムを削除する削除オペレーションを含んでいる。

ビューは多様な方法でアトム・データベースのアトムを共用するために利用できる。単一のビューおよびアトム・データベースを第１の実行可能なプログラムおよび第２の実行可能なプログラムと関連付けることによって、アトム・データベース内のアトムを共用するために単一のビューを利用できる。アトム・データベースは仮想アトム・データベースを作成するためにビューを利用してランタイムで仮想的に変換される。仮想アトム・データベースからのアトムは次に第１の実行可能なプログラムおよび第２の実行可能なプログラムによってロードされ、それによって第１の実行可能なプログラムと第２の実行可能なプログラムとでアトムを共用する。アトムが第１の実行可能なプログラムによってアクセス可能な第１メモリ・バッファにロードされ、アトムが第２の実行可能なプログラムによってアクセス可能な第２メモリ・バッファにロードされる場合はディスク上での共用がなされる。アトムが第１の実行可能なプログラムと第２の実行可能なプログラムの双方によってアクセス可能なメモリ・バッファにロードされる場合は、メモリ内での共用がなされる。

第１のビューおよびアトム・データベースを第１の実行可能なプログラムに関連付け、第２のビューおよびアトム・データベースを第２の実行可能なプログラムと関連付けることによって、アトム・データベース内のアトムを共用するために複数のビューを利用できる。アトム・データベースは、第１の仮想アトム・データベースおよび第２の仮想アトム・データベースを作成するために第１のビューおよび第２のビューを利用してランタイムで仮想的に変換される。仮想アトム・データベースからのアトムは第１のビューを利用して第１の実行可能なプログラムによって、また第２のビューを利用して第２の実行可能なプログラムによってロードされ、それによって第１の実行可能なプログラムと第２の実行可能なプログラムとでアトムを共用する。アトムが第１のビューを利用して第１の実行可能なプログラムによってアクセス可能な第１メモリ・バッファにロードされ、アトムが第２のビューを利用して第２の実行可能なプログラムによってアクセス可能な第２メモリ・バッファにロードされる場合はディスク上での共用がなされる。いずれのビューによっても影響されないアトム（すなわち未修正のアトム）の場合、アトムが第１のビューを利用した第１の実行可能なプログラムと、第２のビューを利用した第２の実行可能なプログラムの双方によってアクセス可能なメモリ・バッファにロードされる場合は、メモリ内での共用がなされる。

ビューは多くの目的のために利用できる。変換オペレーションは性能をカスタマイズするためにアトムが実行するコンピュータ・ハードウェアおよび／またはソフトウェア・システムの最適化機能に基づいて規定可能である。変換オペレーションは、カスタマイズされた機能セットと共にレリースされるように、アトムによって提供されるある種の機能へのアクセスを制限するために規定される。

アトムはさらにアトム特性を備え、アトム変換オペレーションはアトム特性を変更することができる。例えば、デバッグ情報を修正することによってコード・アトムを変換することができる。

ビューの上にビューを付与するために仮想アトム・データベースに１組の変換オペレーションを行うことができる。

マッピング・テーブルは、１組の変換オペレーションが第１のアトムを第２のアトムと置き換える修正オペレーションだけを含む簡単なビューである。置換オペレーションは簡単であるが、全てのリファレンスを一方のアトムから他方のアトムへと効率的に変更する強力な機構である。

ビューを含む１組のアトム変換オペレーションはプログラマーによって手動的に作成可能であり、または処理工程によって自動的に生成可能である。第１アトム・データベースから第２アトム・データベースへと変換するための１組のアトム変換オペレーションを作成する方法は標準アトム共用アルゴリズム、第１アトム・データベース、および第２アトム・データベースを利用した標準化を含んでおり、第１アトム・データベースおよび第２アトム・データベースは各々、永続的に割り当てられているアトム識別子、コンピュータ・コードおよび／またはデータ、および他のアトムへのリファレンスを含むアトムを記憶する。第１アトム・データベースと第２アトム・データベースのアトムの間の１組のゴール・マージが特定される。^＊ゴール・マージを援助する第１アトム・データベースと第２アトム・データベースとの間の１組のアシスト・マージが特定される。１組のアシスト・マージ内の最良のマージを選択し、選択された最良のマージをコミットし、１組のゴール・マージを更新し、１組のアシスト・マージを更新する工程は、１組のゴール・マージが空いていない間に反復される。

再利用マージではない、またはコミットされた再利用マージで援助しなかった各々のコミットされたマージはアンドゥされる。一意的に互換性があるマージが作成された場合は、一意的に互換性があるマージをゴール・マージに追加し、一意的に互換性があるマージの１つに無限の重みを割り当て、１組のアシスト・マージが特定される工程に進む。残りの同型化（ｉｓｏｍｏｒｐｈｉｓｍ）を特定するため、第１データベースと第２データベースとを利用して修正されたアトム共用アルゴリズムが適用される。一意的に互換性があるマージが作成された場合は、一意的に互換性があるマージをゴール・マージに追加し、一意的に互換性があるマージの１つに無限の重みを割り当て、１組のアシスト・マージが特定される工程に進む。互換性があるいずれかのマージが作成された場合は、重みが最大の互換性があるマージをコミットし、コミットされた互換性があるマージに無限の重みを割り当て、コミットされた互換性があるマージを１組のゴール・マージに追加し、１組のアシスト・マージが特定される工程に進む。コミットされたマージは修正／置換マージ、挿入マージおよび／または策上マージを含むことができる。これらのマージはビュー内での実際の変換オペレーションである。

レリースにおよんでコードとデータとを共用することでディスク記憶とメモリの利用の双方が省かれる。レリースにおよんでコードとデータとを共用できることによってさらに、別個のレリースを保持し、レリース間の「ラッパー」インターフェースの手動的な作成をしなくてもすむ。ラッパーの目的は新規コードの後方互換性バージョンを生成することで、コードの古いバージョンをもはやクライアント側で保持する必要がないようにすることである。ラッパーと、は各々が基本的に同一の大量のコードを含むプログラムの複数バージョンの間接費を回避する試みである。プログラム・バージョン間でのコードおよびデータの自動的な共用を可能にすることによるソフトウェア・アトマイゼーション用のビューによってラッパーの必要性がなくなり、ソフトウェア・プログラム・バージョンの設計時により多くの構成上の自由度が可能になる。

発明の詳細な説明
以下に本発明の好適な実施形態を説明する。好適な実施形態はＣｕｒｌ^ＴＭ言語、スクリプト、および非Ｃｕｒｌ^ＴＭプログラムで書き込まれたソフトウェアを処理するために、アトム化されたＣｕｒｌ^ＴＭランタイムの適宜の部分を実行するＣｕｒｌ^ＴＭランタイム環境を実装するコンピュータ・プログラムをアトム化するのに適している。

図１は本発明の実施形態が実装されているコンピュータ・システムの略図である。クライアント・コンピュータ５０およびサーバー・コンピュータ６０はコンピュータ・プログラムをアトム化し、アトム化されたコンピュータ・プログラムを実行するための処理、記憶、および入力／出力デバイスを備えている。クライアント・コンピュータ５０はさらに通信ネットワーク７０を介して、他のクライアント・コンピュータ５０およびサーバー・コンピュータ６０を含む他のコンピュータ・デバイスにもリンクされることが可能である。通信ネットワーク７０は互いに通信するために現在ＴＣＰ／ＩＰプロトコル・スイートを使用しているインターネット、世界規模のコンピュータ・コレクション、ネットワーク、およびゲートウェイの一部であってよい。インターネットはデータおよびメッセージを転送する数千もの商業、政府、教育、およびその他のコンピュータ・ネットワークからなる主要ノード、またはホスト・コンピュータ間の高速データ通信線の学区ボーンをもたらすものである。本発明の別の実施形態では、コンピュータ・プログラムのアトム化、およびアトム化されたコンピュータ・プログラムの実行のための処理、記憶、および入力／出力デバイスを自立型コンピュータ上に実装することができる。

図２は図１のコンピュータ・システム内のコンピュータの内部構造（例えば５０、６０）の略図である。各コンピュータはシステム・バス２００を含んでおり、
バスとはコンピュータの構成部品間でのデータ転送用に使用される１組のハードウェア線である。バス２００は基本的に、素子間での情報の転送を可能にするコンピュータ・システムの異なる素子（例えばプロセッサ、ディスク記憶装置、メモリ、入力／出力ポート、ネットワーク・ポートなど）を接続する共用電線管である。システム・バス２００には様々な入力および出力デバイス（例えばディスプレー、プリンタ、スピーカーなど）をコンピュータに接続するためのＩ／Ｏデバイス・インターフェース２０２が接続されている。ネットワーク・インターフェース２０６によってコンピュータをネットワーク（例えばネットワーク７０）に接続された様々な他のデバイスに接続可能である。メモリ２０８は本発明の実施形態を実装するために利用されるコンピュータ・ソフトウェア命令（例えばアトム・エクストラクタ・プログラム１５０およびアトム管理プログラム１６０）およびデータ構造（例えばアトム・データベース１２０）用の揮発性記憶装置を備えている。ディスク記憶装置２１０は本発明の実施形態を実装するために利用されるコンピュータ・ソフトウェア命令（例えばアトム・エクストラクタ・プログラム１５０およびアトム管理プログラム１６０）およびデータ構造（例えばアトム・データベース１２０）用の不揮発性記憶装置を備えている。

中央プロセッサ・ユニット２０４もシステム・バス７００に接続され、コンピュータ命令（例えばアトム・エクストラクタ・プログラム１５０およびアトム管理プログラム１６０）を実行し、ひいてはコンピュータをアトム化し、アトム化されたコンピュータを実行することを可能にする。

図３はランタイムで出力をディスプレーするコンピュータ・プログラムを作成し、ロードするための従来の工程を示している。ソース・コード１０２はソース・コード・プログラミング言語（例えばＣ、Ｃ＋＋）を用いてコンピュータ・プログラマーによって作成される。コンパイラ１０４はソース・コードを処理し、オブジェクト・コード１０６のファイルを作成する。リンカー・セクション１０９を作成するためにリンカー１０８を用いて１つ以上のオブジェクト・コード１０６ファイルがリンクされる。リンカー・セクション１０９は結合されて実行可能コード１１０が作成される。実行可能コード１１０は自立型の実行可能プログラム（例えばＥＸＥファイル）として、または共用されるコード・ライブラリ（例えばＤＬＬファイル）としてリンクされることができる。実行可能コード１１０はランタイム・ディスプレー１１４を作成するために実行用のローダ１１２によってメモリへとロードされる。

図４はランタイムで出力をディスプレーするアトム化されたコンピュータ・プログラムを作成し、ロードするためのソフトウェア・アトム化工程を示している。従来の工程と同様に、ソース・コード１０２はソース・コード・プログラミング言語（例えばＣ、Ｃ＋＋）を用いてコンピュータ・プログラマーによって作成される。コンパイラ１０４はソース・コードを処理し、オブジェクト・コード１０６のファイルを作成する。ソース・コード１０２が通常の態様でオブジェクト・コード１０６のファイルへとコンパイルされた後、アトム・エクストラクタ１５０はオブジェクト・コード１０６を処理してアトム１３０を特定する。細粒度の、個々にアドレス指定可能なアトム１３０がアトム・データベース１２０に入れられ、各アトム１３０は一意的なアトムｉｄ１３２を受け取る。細粒度のアトム１３０は任意の整数バイトのコードおよびデータを定義する。コードおよびデータへのリファレンスはアトムｉｄリファレンスへと変換される。例えば、コード内でのプロシージャ・コールはそれらのアトムｉｄ１３２を介して他のアトム１３０の起動へと転換される。データ・リファレンスもそれらのアトムｉｄ１３２を介してデータ・アトム・リファレンスに変換される。

アトム・エクストラクタ１５０はオブジェクト・コード・ファイル１０６を無視して、コードからアトム１３０を作成する。オブジェクト・コード１０６からアトム１３０を抽出するために必要な情報は、プロシージャをロードし、呼び出し、読み出し専用データを最適化するために従来のローダは同じ情報を必要とするという事実によって、既にオブジェクト・ファイル内に組み込まれている。オブジェクト・コード・ファイル１０６から複数のデータ・アトムを抽出するために必要な情報は様々なデータ量の分離を必要としている。分離はある種の従来のコンパイラ（例えばｇｃｃ）によって自動的に、またはソース・コード（例えばコンパイラ指令）内にデータ量を直接マーキングするプログラマーによって明示的に行うことができる。ランタイムでアトム管理プログラム１６０はアトム・データベース１２０からアトム１３０にアクセスし、実行のためにこれらをメモリにロードする。ロードされたアトム１３０は次に、ランタイム・ディスプレー１１４、または実行時にこれらがそのためにプログラムされる他のいずれかの結果を作成することができる。アトム管理プログラム１６０は静的コード分析または動的プロファイリングに基づいてアトム１３０をロードする最適な順序を決定することができる。オブジェクト・コード・ファイル１０６内に別個のセクションを作成するためにコンパイラに依存することによって、アトム化工程を自動化することができ、手動的な分解および分析の必要がなくなる。コンパイラを使用することはコードおよびデータの別個のセクションを作成する１つのオプションであるが、その代わりに、アトム１３０を作成するためにソース・ファイルを処理するため他のプログラムを使用することもできる。

図５はアトム抽出工程を示している。ステップ３０２で、コンピュータ・プログラムのコードおよび／またはデータがオブジェクト・コードのフォーマットで受信される。ステップ３０４で、コンピュータ・プログラムのコードおよび／またはデータ情報がコンピュータ・プログラム・コードおよび／またはデータからオブジェクト・コードのフォーマットで抽出される。ステップ３０６で、コンピュータ・プログラムのコードおよび／またはデータ・リファレンス情報がコンピュータ・プログラム・コードおよび／またはデータからオブジェクト・コードのフォーマットで抽出される。ステップ３０８で、アトム識別子を使用するためにコンピュータ・プログラム・コードおよび／またはデータのリファレンス情報が修正される。最後にステップ３１０で、アトム識別子、コンピュータ・プログラム・コードおよび／またはデータ情報、およびコンピュータ・プログラム・コードおよび／またはデータ・リファレンス情報を含むコンピュータ・プログラム・コードおよび／またはデータ情報がアトム内に記憶される。

図６ａはアトム、アトム・データベース、ビュー、および仮想アトム・データベースの略図である。コンセプトとしては、アトム・データベース１２０はアトム１３０の向きを持ったグラフであると見なすことができる。アトム・バイト１３４（ノード）はアトムｉｄ１３２（ノードｉｄ）によって識別され、アトム・リファレンス１３６（エッジ）によってリンクされる。アトム・データベース１２０はアトム１３０を記憶する。各アトム１３０は一意的アトムｉｄ１３２によって識別される。各アトム１３０ごとのコードおよび／またはデータはアトム・バイト１３４として表される。アトム１３０はアトム・バイト１３４およびアトム・リファレンス内のコードおよび／またはデータを含めて圧縮される。ある環境では、復元はディスクの読み出し時間よりも速く、圧縮・復元工程によってパフォーマンスが著しく向上し、同時にメモリおよびディスクの記憶スペースが小さくてすむ。アトム（例えばアトム１４１、１４２、１４３、１４４）を記憶するアトム・データベース１２０は変換オペレーションを利用して、アトム（例えばアトム１４１、１４２、１４３、１４４，１４５）を記憶する仮想アトム・データベース１２１へと仮想的に変換されることができる。挿入オペレーションはアトム１４６を追加し、置換オペレーションはアトム１４３をアトム１４５に置き換える（その結果アトム１４４はその時点でアトム１４５になる）。ビュー１２２を介してアトム・データベース１２０にアクセスする（すなわち仮想アトム・データベース１２１にアクセスする）プログラム（例えば実行可能プルグラム１５８）はアトム１４４にアクセスしてアトム１４５を呼び出し、これに対してアトム・データベース１２０に直接アクセスする実行可能プログラム１５６はアトム１４４にアクセスしてアトム１４３を呼び出す。このようにして、（例えば１４１、１４２のような）同一のアトムのコピーを記憶しておく必要なく、アトム・ソフトウェアの複数のバージョン／レリースを保持することができる。

アトム１３０は永続的アトムｉｄ１３２（識別子）によって一意的に識別されるコード断片、またはコード要素である。コード・アトム１３０は典型的にはソース言語（例えばＣ／Ｃ＋＋） 級のプロシージャである。データ・アトム１３０はデータ要素であり、任意のサイズのものでよい。アトム１３０は必要時にメモリ（例えば読み出し専用コード・バッファ１７０、読み出し専用データ・バッファ１８０、読み出し−書き込みデータ・バッファ１９０のような）メモリに引き込まれ、もはや必要ではなくなると入れ換え可能である。アトムｉｄ１３２の性質が永続的であることにより、あるアトム１３０が既に存在することが判定され、永続的アトムｉｄ１３２によって識別されることによって、エンジニアは既存のレリースに基づいて新規にレリースすることが可能である。それによって既存のレリースからのデルタに基づいて増分的なレリースがなされる。

アトム・データベース１２０内のアトム１３０は（例えばコード、データ、リファレンス、および／または特性を更新するために）所望のプログラミング変更に影響するように修正可能である。修正オペレーションの１つの重要なサブセットは、アトム１３０がディスク上で、および／またはメモリ内で共用するためにビュー１２２を使用して別のアトム１３０と置き換えられる置換オペレーションである。アトムの置き換えによってアトム１３０を参照するコードおよび／またはデータは、参照されたアトムが異なるアトム１３０と置き換えられ、またはそれに更新された場合に不変のままに留まることができる。ビュー１２２はリファレンスを１つのアトムｉｄ１３２から別のアトムｉｄ１３２に変換することができる。ビュー１２２はさらに、アトム１３０の別のデータ、リファレンス、および／または特性に影響を及ぼす変換オペレーションをも含むことができる。

複数のビュー１２２をアトム・データベース１２０上に画成して、実行可能なプログラム１５６が様々な態様でアトム１３０を共用できるようにすることが可能である。このようにして、アトム化のためにビューを利用する実行可能プルグラム１５６をアトム・データベース１２０の特定のビュー１２２に対して実行可能であろう。例えば、実行指令線「ＭｙＡｐｐｌｉｃａｔｉｏｎ．ｅｘｅ‐ｄＡＴＯＭ．ＤＢ‐ｖ１．１」を介してビュー１２２およびアトム・データベース１３０を実行可能プログラム１５６と関連付けることが可能である。実行可能なプログラム１５６「ＭｙＡｐｐｌｉｃａｔｉｏｎ．ｅｘｅ」は、ビュー・ファイル「１．１」内に画成されたビュー１２２を利用して作成されたビュー・バージョン「１．１」で画成されたアトム１３０にアクセスするため、アトム・ローダ（例えばアトム管理プログラム１６０）を呼び出すためのスタブを含むことができる。

ビュー１２２の変換オペレーションの生成には１つのアトム・データベース１２０から別のアトム・データベース１２０へのアトム１３０の設定差を作成することが含まれる。アトム１３０は様々なビュー１２２間で共用可能であるので、単一のアトム・データベース１２０を利用して製品の複数のレリース／バージョンを保持することができる。

新レリースのコンピュータ・ソフトウェアを、変換オペレーションを含むビュー１２２内に符号化することができる。変換オペレーションは２つの物理的アトム・データベース１２０間、または仮想データベース１２１と物理的アトム・データベース１２０間、または一対の仮想アトム・データベース１２１間の差を規定することができる。このようにしてソフトウェアのレリースは、先行するソフトウェアのレリースをベースにすることができる。

図６ｂはアトム、アトム・データベース、ビュー、および仮想アトム・データベースの略図である。ビュー１２２はアトム・データベース１２０を新たなアトム・データベース１２０に変換することができる。図６ａに記載されている実施例では、アトムがアクセスされ、メモリにロードされた際にアトム・リファレンス、データおよび／または特性を変換することによって、変換によって仮想アトム・データベース１２１が作成された。新たな物理的アトム・データベースを作成するためにこれと同じ工程を利用することができる。このようにして、変換オペレーションは一度しか行われる必要がなく、変換されたアトム１３０の像で別個の新たなアトム・データベース１２３が作成される。別個の新たなアトム・データベース１２３は（修正も削除もされずに）再利用されるアトム・データベース１２０から全てのアトム１３０のコピーを記憶し、挿入オペレーションの結果挿入された全ての新規アトム１３０を記憶し、かつ修正オペレーションの結果修正されたアトム１３０を記憶する。別個の新たなアトム・データベース１２３はアトム・データベース１２０を更新する非破壊的な方法をもたらす。

図６ｃはアトム、アトム・データベース、ビュー、および上書きされた新規アトム・データベースの略図である。ビュー１２２はアトム・データベース１２０を新たなアトム・データベース１２０に変換することができる。新たなアトム・データベース１２０は（図６ａに示すような）仮想アトム・データベース１２１であってもよく、または（図６ｂに示すような）別個の新たなアトム・データベース１２３であってもよい。新たなアトム・データベース１２０はさらに、既存のアトム・データベース１２０に上書きして、上書きされたアトム・データベース１２３を作成することもできる。別個の新規アトム・データベースの場合と同様に、変換オペレーションは一度しか行われる必要がなく、変換されたアトム１３０の像で別個の新たなアトム・データベース１２３が作成される。上書きされた新たなアトム・データベース１２３は（修正も削除もされずに）再利用されるアトム・データベース１２０から全てのアトム１３０のコピーを保持し、挿入オペレーションの結果挿入された全ての新規アトム１３０を記憶し、かつ置換オペレーションの結果置換されたアトム１３０を記憶する。未使用のアトムを上書きされたアトム・データベース１２３から除去するために削除オペレーションを行うことができる。上書きされた新たなアトム・データベース１２３はアトム・データベース１２０を更新する破壊的な方法をもたらす。

図７ａは単一のビューを利用し、ディスク上のアトムを共用する複数の実行可能プログラムの略図である。ランタイムで、本発明の実施形態は共用されたライブラリ（すなわちＤＬＬ）用の従来の機構を回避し、その代わりに、例えばメモリの４Ｋブロックの代わりにアトムの粒状性でロードするより効率的なアトム機構を利用する。アトム管理プログラム１６０は必要に応じてアトム・データベース１２０からアトム１３０をロードする。アトム管理プログラム１６０はメモリを割り当て、その後バッファ内のアトム（例えばアトム１４１）を管理する。アトム・エクストラクタ１５０はメモリ内の、既存のアトム１３０を探し、既にロードされていなければアトム・データベース１２０からこれらをロードするアトム管理プログラム１６０用にアトム１３０を介して間接的にされる以前に修正されたプロシージャ・コールを有している。

バッファ管理は限定されたメモリの利用、交換およびスラッシングの縮減、および立ち上げ時間の短縮を含む幾つかの利点をもたらす。限定されたメモリの利用によってメモリの利用はいずれかの特定のサイズに限定される。例えば、コード・アトム１３０用に正確に８ＭＢのメモリを規定でき、新たなアトム１３０が必要になると古いアトム１３０を交換可能であろう。本発明の実施形態によって、メモリの利用を制限することにより交換およびスラッシングが縮減され、したがってメモリの過度の利用を管理するためにプログラムはそのメモリ管理機構を使用する必要がない。プログラムのメモリ管理は汎用であり、特定のニーズ用に調整されたものではないので、本来効率は低い。必要なコードを正確にロードすることによって、また他のコードは単に共用のライブラリ内に「隣接」しているという理由だけでメモリの消費は縮減される。アトム管理プログラム１６０は立ち上がり時間を短縮する。アトム管理プログラム１６０は第１のアトム１３０をロードし、実行する。新たなアトム１３０が必要になると、それらがロードされ、実行される。したがって、コードはコード全体がメモリにロードされるまで待機しなくとも適正に動作する。本発明の実施形態は、（未だ転送されていない場合があるアトム１３０の利用可能性により制限されて）ダウンロードが完了する前に、ダウンロードされているコード・アトム１３０の実行を開始する。

アトム管理プログラム１６０は下記の３つの種類のバッファを管理する。すなわち、読み出し専用コード・バッファ（例えば１７６、１７８）、データ定数用に利用可能な読み出し専用データ・バッファ（例えば１８６、１８８）、および大域的データ用に利用可能な読み出し−書き込みデータ・バッファ（例えば１９６、１９８）である。読み出しー書き込みデータは任意のサイズのものでよく、またアトム・データベース１２０から再ロードされることができなくてもよいので、そのサイズは制限されなくてもよく、したがってそれを管理するためにプログラムの仮想メモリ・システムをその管理用に使用してもよい。

アトム１３０を一度に１つだけロードするのは、関連するものと判定できた場合にワーキングセット・アトム１３０を同時にロードするよりも効率が低い。どのアトム１３０が「ワーキング・グループ」を形成しているかを判定するためにワーキングセット・チューナーが使用される。ワーキングセット・チューナーはアトム化された環境向けの情報を収集するようにされている。情報の収集がなされると、アトム１３０の相互の関係を示すアトム・データベース１２０内の指令のような情報を利用する機構が使用される。本発明の実施形態は特定のロード順序に適合するようにアトム１３０を並べ替える能力を備えている。

アトム管理プログラムの読み出し専用コード・バッファ１７６、１７８の管理によって、ロードのある程度の最適化がなされる。１つのアトム１３０が他のアトム１３０へのプロシージャ・コールを行う場合、この呼び出しは一般にアトム管理プログラム１６０を介したスタブを用いて間接的に行われる。ターゲット・アトム１３０への直接的なジャンプ（「リンク・スナッピング」）を行うために呼び出し元のコードのメモリ内の画像が修正されると、プロシージャ・コールはより迅速になる。しかし、一旦リンクがスナップされると、アトム管理プログラム１６０はリンクの無効化を伴わずにターゲット・アトム１３０を移動またはスワップアウトすることができない。頻繁に呼び出されるアトム１３０の場合は、これは価値ある交換条件であることがある。どのアトム１３０がダイレクトコールにふさわしいかを判定するために、またアトム１３０をメモリ内のロックするためにアトム管理プログラム１６０によってツールが使用される。リンク・スナッピングのための分析は、コード／データをメモリ内にロックダウンすることによってランタイムで、またランタイムでスタブを使用しないことをあるアトム・リファレンス１３６にマークすることによってコンパイル・タイムに実施されることができる。アトム・データベースのビュー１２２とスタブ／リンク・スナッピングとを組み合わせることによって、システムの特性を所望のパフォーマンス基準に適合させる多くのオプションが与えられる。

複数の実行可能プログラム１５６、１５８はコードおよび／またはデータを共用するために同じ仮想アトム・データベース１２１（または新規アトム・データベース１２３）にアクセスすることができる。例えば、実行可能プログラム１５６はコード・アトム１４１をも呼び出す。コード・アトム１４１のコピーがディスクから読み出され、各プログラムの読み出し専用メモリ・バッファ１７６、１７８へとロードされる。次に、ロードされたコード・アトム１４１を実行可能プログラム１５６、１５８が直接呼び出す。このようにして、複数の異なる実行可能プログラム１５６、１５８は、場合によっては異なる製品および／または異なる製品バージョンから、アトム・データベース１２０に記憶されているディスク上のアトム１３０（例えばアトム１４１）を共用する。

図７ｂは単一のビューを利用し、ディスク上およびメモリ内のアトムを共用する複数の実行可能プログラムの略図である。この実施例では、複数の実行可能プログラム１５６、１５８がバッファ（例えば読み出し専用コード・バッファ１７０、および読み出し専用データ・バッファ１８０）を共用する。第１の実行可能プログラム（例えば実行可能プログラム１５６）がアトム１４１を呼び出すと、アトム管理プログラム１６０はアトム１４１を読み出し専用コード・バッファ１７０へとロードする。後続の実行可能プログラム（例えば実行可能プログラム１５８）がアトム１４１を呼び出すと、アトム管理プログラム１６０はそのアトム１４１が既にロードされたことを判定することができる。このようにして、複数の異なる実行可能プログラム１５６、１５８はアトム・データベース１２０内に記憶されているメモリ内のコード・アトム１３０（例えばアトム１４１）を共用し、複数の実行可能プログラム間でアトムを同時に再利用する。読み出し専用コード・バッファ１７０を共用する実行可能プログラムのある種の制約は、例えば共用されるコード・アトムでスナップされることはできないリンクを付与する。１つのビュー１２２だけしか利用されていないのでアトム１４４を共用することができるため、付加的な共用も可能である。したがって、双方の実行可能プログラム１５６、１５８共同じビュー１２２を利用でき、修正されたアトム１４４のコピーを共用することができる。

図７ｃは複数のビューを利用し、ディスク上のアトムを共用する複数の実行可能プログラムの略図である。この実施例では、複数の実行可能プログラム１５６、１５８が各々独自のバッファ（例えば読み出し専用コード・バッファ１７６、１７８、読み出し専用データ・バッファ１８６、１８８、および読み出し−書き込みコード・バッファ１９６、１９８）を有している。その上、各実行可能プログラム１５６、１５８は下にあるアトム・データベース１２０の異なるビュー１２２、１２５を利用して、異なる仮想アトム・データベース１２１、１２４にアクセスする。ビュー１２２は仮想データベース１２１を作成し、その内部でコード・アトム１４１はコード・アトム１４２を呼び出し、それが１４４を呼び出す。ビュー１２５は仮想データベース１２４を作成し、その内部でコード・アトム１４１はコード・アトム１４２を呼び出し、それが１４５を呼び出す。実行可能プログラム１５６、１５８がコード・アトム１４１を呼び出すと、これらは仮想アトム・データベース（すなわち仮想アトム・データベース１２１、１２４）を作成するためにそれぞれのビュー（すなわちビュー１２２、１２５）を介してアトム・データベース１２０にアクセスする。次に、実行可能プログラム１５６、１５８はアトム１４１のコピーをそれぞれのバッファ（例えば読み出し専用コード・バッファ１７６、１７８）へとロードすることによってアトム１４１のディスク・コピーを共用することができる。実行可能プログラム１５６のロードされたコード・アトム１４１が実行されると、これはコード・アトム１４２にアクセスし、これは実行可能プログラム１５６の読み出し専用コード・バッファ１７６へとロードされる。コード・アトム１４２は未修正のままに読み出し専用コード・バッファ１７６へとロードされる。実行可能プログラム１５８のロードされたコード・アトム１４１が実行されると、これはコード・アトム１４２にアクセスし、これは実行可能プログラム１５８の読み出し専用コード・バッファ１７８へとロードされる。コード・アトム１４２はビュー１２５内で規定されたようにリファレンスが変換されたアトム・データベース１２０からロードされる。このようにして、１００％のコード・アトム１４１が共用され、極めて高比率のコード・アトム１４２が共用されることが可能である。コード・アトム１４２用には全てのコード・バイトが共用され、単一のリファレンスだけが変更されるので、ほとんどのリファレンスが共用される。コード・アトム１４２がロードされる際の差分は、各実行可能プログラム１５６、１５８がアトム１３０にアクセスするために異なるビュー１２２，１２５を利用しているからである。このようにして、複数の異なる実行可能プログラム１５６、１５８は異なるビュー１２２、１２５によって規定された他のアトム１３０を修正しつつ、アトム・データベース１２０内に記憶されたディスクからの幾つかのコード・アトム１３０（例えばアトム１４１）を共用する。

図７ｄは複数のビューを利用し、ディスク上およびメモリ内のアトムを共用する複数の実行可能プログラムの略図である。この実施例では、複数の実行可能プログラム１５６、１５８が独自のバッファ（例えば読み出し専用コード・バッファ１７６、１７８、読み出し専用データ・バッファ１８６、１８８、および読み出し−書き込みデータ・バッファ１９６、１９８）を保持するとともに、バッファ（例えば読み出し専用コード・バッファ１７０、および読み出し専用データ・バッファ１８０）を共用している。その上、各実行可能プログラム１５６、１５８は異なるビュー１２２、１２５を利用して異なる仮想アトム・データベース１２１、１２４にアクセスする。ビュー１２２は仮想データベース１２１を作成し、その内部でコード・アトム１４１はコード・アトム１４２を呼び出し、それが１４４を呼び出す。ビュー１２５は仮想データベース１２４を作成し、その内部でコード・アトム１４１はコード・アトム１４２を呼び出し、それが１４５を呼び出す。ビュー１２５を仮想データベース１２１に適用することによって仮想データベース１２４を作成してもよく、その場合は変換オペレーションはアトム１４３を１４５と置き換えているであろう。実行可能プログラム１５６、１５８がコード・アトム１４１を呼び出すと、これらは仮想アトム・データベース（例えば仮想アトム・データベース１２１、１２４）を作成するためにそれぞれのビュー（例えばビュー１２２、１２５）を介してアトム・データベース１２０にアクセスする。各仮想アトム・データベース１２１および１２４は実際に、下にある同じ物理的アトム・データベース１２０を共用してもよい。次に、実行可能プログラム１５６、１５８はコピーを共用された読み出し専用コード・バッファ１７０へとロードすることによってアトム１４１のディスク・コピーとメモリ・コピーとを共用することができる。実行可能プログラム１５６がコード・アトム１４２をロードすると、これは読み出し専用コード・バッファ１７６へとロードされる。実行可能プログラム１５８がコード・アトム１４２をロードすると、これは読み出し専用コード・バッファ１７８へとロードされる。実行可能プログラム１５６および実行可能プログラム１５８はコード・アトム１４２を完全に共用することはできないが、ディスクを共用することができ、これは他の呼び出し元によって利用されるように共用された読み出し専用コード・バッファ１７０へとロードされることができる。ローディングの差は、各実行可能プログラム１５６、１５８がアトム１３０にアクセスするために異なるビュー１２２、１２５を利用し、したがって異なる変換が適用されることによるものである。このようにして、複数の異なる実行可能プログラム１５６、１５８は異なるビュー１２２、１２５によって規定された他のアトムを置換しつつ、アトム・データベース１２０内に記憶されたディスクから、およびメモリ内の幾つかのコード・アトム１３０（例えばアトム１４１）を共用する。

図８はアトム管理工程を示している。ステップ３２１でターゲットであるアトムのために必要な何らかの変換を施すために、ビュー１２２にアクセスされる。変換にはアトム・リファレンス、アトム・データベースロム・コード／データ（バイト）および／またはアトム特性の修正を含めることができる。ステップ３２２で、アトム管理工程はアトム・データベースからアトム識別子、コンピュータ・プログラム・コード、および／またはデータ情報、およびコンピュータ・プログラム・コードおよび／またはデータ・リファレンス情報を含むアトムをメモリへとロードすることによってアトム化されたコンピュータ・プログラム・コードを管理する。次にステップ３２４で、コンピュータ・プログラム・コードおよび／またはデータ・リファレンス情報が修正されて、アトム識別子およびオフセットがメモリ・アドレスと置き換えられるようにされる。

図９はアトム・データベースのデータ構造の略図である。アトム・データベース１２０はアトム１３０を記憶する。アトム１３０はコンパイルされたプロシージャまたは文字列定数のような単一のデータに対応する。アトム１３０は必要時にアトム・データベース１２０からメモリへとロードされる。それによってメモリのフットプリントが縮小され、ディスクＩ／Ｏが縮減される。アトム・データベース１２０はアトムｉｄ１３２の値（整数）からアトム１３０へとマッピングされる。アトムｉｄ１３２はアトム１３０を識別する３１ビットの整数をして表すことができる。アトム１３０は任意の順序でロードされることが可能である。アトム１３０をメモリにロードするために必要なスペースを節減し、Ｉ／Ｏを最小限にするため、アトム・データベース１２０のディスク上の表示が最適化される。アトム・データベース１２０はさらにアトムｉｄ１３２の値から記号およびデバッグ情報のような該当するアトム１３０に関連する情報へのマッピングをも行う。アトム・データベース１２０は各々が可変サイズの幾つかの別個のセクションを備えた１つのファイルであり、セクションはＤＢ見出し３５０とアトム−マップ３６０とを含んでいる。様々な実施形態で、アトム−マップ３６０はボデー−アトム−マップ、記号−アトム−マップ、カテゴリー−アトム−マップ、および記述−アトム−マップを含むことができる。ｄｂ見出し３５０が最初に来るが、他のマップ・セクションの順序、位置および数は随意である。ＤＢ見出し３５０は各々の他のセクションごとのファイル・オフセットを含んでいる。

ＤＢ見出し３５０はデータベース・ファイル内のまったく最初の事象である。これはマジック−ナンバー、バージョン−ナンバー、ｃｐｕの種類、ｏｓの種類、ボデー−アトム−マップ−オフセット、記号−アトム−マップ−オフセット、カテゴリー−アトム−マップ−オフセット、および記述−アトム−マップ−オフセットを含む他のセクションのファイルと位置に関するある種の大域的な情報である。

マジック・ナンバーはこのファイルをアトム・データベース１２０として定義し、さらにファイル内の他の全てのマルチバイト数の並び順をも定義する。データベースがリトルエンディアン・バイト順で記憶されている場合は、マジック・ナンバーはこれらの４つのバイト：０ｘＤ７ ０ｘ１５ ０ｘＦＦ ０ｘ３１からなっている。ビッグエンディアン・ファイルの場合は、バイトは逆になる：０ｘ３１ ０ｘＦＦ ０ｘ１５ ０ｘＤ７。このバイト・シーケンスには特定の意味はない。データベース・ファイルは常に、そのコードを含んでいるプロセッサの固有の並び順（バイト順）に記憶される。それによって、ランタイムでの無駄が多いバイト交換の必要がなくなる。しかし、マジック・ナンバーは並び順を明確に特定するので、クロス−プラットフォーム・ツールがアトム・データベース１２０を操作できる。

バージョン・ナンバーはデータベースによって用いられるファイル・フォーマットのバージョンを示す。

ＣＰＵの種類はデータベースがそのために作成されたＣＰＵの種類（例えばＰｅｎｔｉｕｍ（登録商標）、ＰｏｗｅｒＰＣなど）を示す。

ＯＳの種類はこのデータベースがそのために作成されたＯＳの種類（例えばＷｉｎ３２、Ｌｉｎｕｘ、ＭａｃＯＳ Ｘなど）を示す。

ボデー−アトム−マップ−オフセットはファイルの始端に対する、ボデー−アトム−マップ・セクションが始まるファイル・オフセットである。

記号−アトム−マップ−オフセットはファイルの始端に対する、記号−アトム−マップ・セクションが始まるファイル・オフセットである。

カテゴリー−アトム−マップ−オフセットはファイルの始端に対する、カテゴリー−アトム−マップ・セクションが始まるファイル・オフセットである。

記述−アトム−マップ−オフセットはファイルの始端に対する、記述−アトム−マップ・セクションが始まるファイル・オフセットである。

図１０はアトム・マップ見出しデータ構造の略図である。アトム−マップ３６０はアトム−マップ見出し３７０とアトム−マップ−アレイ３８０とを含んでいる。アトム−マップ３６０はアトムｉｄ１３２を、そのアトムｉｄ１３２に関連する何らかの情報を見出すことができるファイル・オフセットへとマッピングする。アトム−マップ３６０の表示は任意の組のアトムｉｄ１３２にも有効であるが、これは連続的なアトムｉｄ１３２の範囲向けに最適化され、したがって例えば、アトムｉｄ１３２用のアトム−マップ３６０｛１２、２３、２４、２１６｝はアトムｉｄ１３２｛１０、１１、１２、１３｝の場合よりも多くのスペースをとる。アトム−マップ３６０のセクションはデフォールト−アトム−シーケンス−デルタ３７２、アトム−オフセット−シーケンス−アレイ−サイズ３７４、アトム−オフセット−シーケンス−アレイ−オフセット３７６、およびアトム−マップ−データ−オフセット３７８を含むアトム−マップ見出し３７０から始まる。

デフォールト−アトム−シーケンス−デルタ３７２の欄は連続するアトムｉｄ１３２に対応するデータ用のファイル・オフセットのシーケンスを含むアトム−マップ３６０で使用可能である。これらのシーケンスはスペースを節約するためにアトム−マップ３６０内で「デルタ符号化」される。デルタ符号化は数列を連続する対偶間の差として記憶する技術である。多くのシーケンスでは、デルタは小さく、多くの符号化方式がゼロに近い数をよりコンパクトに記憶することができるので、デルタ・シーケンスはオリジナルのシーケンスよりも少ないスペースしかとらない場合が多い。例えば、｛１０００、１０１１、１０１２、１０１３、１０１５、１０１６｝のデルタ符号化バージョンは｛１０００、１、１、１、２、１｝に見えよう。デルタは通常は小さい正の整数であるが、良好に選択された定数、すなわちデフォールト−アトム−シーケンス−デルタ３７２をそれぞれのデルタから減算することによってさらにゼロに近づけることができる。例えば、オリジナルの数列が｛１０００、１０５０、１１０４、１１６５、１２０２｝であったものと想定してみる。このシーケンスをデルタ符号化すると｛１０００、５０、５４、６１、３７｝が生ずる。デフォールト−アトム−シーケンス−デルタ３７２が５０に等しいものとすると、このシーケンスはさらに｛１０００、０、４、１１、−１３｝へと調整されよう。最後の数はゼロにより近いので、シーケンスをよりコンパクトに符号化できる。ホフマン符号化または演算符号化法を適用することも可能である。

アトム−オフセット−シーケンス−アレイ−サイズ３７４はアトム−マップ３６０のシーケンス・アレイ内のエントリ数である。

アトム−オフセット−シーケンス−アレイ−オフセット３７６はデータベース・ファイル内のアトム−マップ３６０のセクションの始端に対する、アトム−マップ３６０のシーケンス・アレイのファイル・オフセットである。

アトム−マップ−データ−オフセット３７８はアトム・データベース１２０のファイル内のアトム−マップ３６０のセクションの始端に対する、アトム−マップ３６０用のデータが始まるファイル・オフセットである。

アトム−マップ３６０（例えばボデー−アトム−マップ、記号−アトム−マップ、カテゴリー−アトム−マップ、および記述−アトム−マップ）はアトム−マップ−アレイ３８０を含んでいる。各アトム−マップ−アレイ３８０の要素はファイル・オフセットの圧縮されたシーケンス（すなわちアトム−オフセット−シーケンス３９０）へのリファレンスである。各アトム−オフセット−シーケンス３９０は連続するアトムｉｄ１３２の群に属する情報用の圧縮されたファイル・オフセットを含んでいる。

図１１はアトム・マップ・アレイ・データ構造の略図である。アトム−マップ−アレイ３８０は最初のｉｄ３８２、シーケンス−サイズ３８４、およびシーケンス−オフセット３８６の要素からなっている。シーケンス−サイズ３８４はアトム−オフセット−シーケンス３９０内のアトム１３０の数である。シーケンス内のアトム１３０は最初のｉｄ３８２から始まる連続的なアトムｉｄ１３２を有している。シーケンス−オフセット３８６は、アトム・データベース１２０のファイルのアトム−マップ３６０のセクションの始端に対する、アトム−オフセット−シーケンス３９０へのファイル・オフセットである。アトム−マップ−アレイ３８０は各シーケンス内の最初のアトム１３０のアトムｉｄ１３２によって分類される。それによって、２分探索を行うことによりアトムｉｄ１３２を、これを含むシーケンスへとマッピングすることが可能になる。次にこれを含むシーケンスを走査すると、所望のアトム１３０用のファイル・オフセットが生ずる。

図１２はアトム・オフセット・シーケンス・データ構造の略図である。アトム−オフセット−シーケンス３９０は最初のアトム−ファイル−オフセット３９２とデルタ符号化ファイル・オフセット３９４とを含むファイル・オフセットのデルタ符号化されたアレイである。各ファイル・オフセットはアトム−マップ−データ−オフセット３７８に追加され、その結果がアトム−マップ３６０のセクションの始端に対して解釈される。１つの長いシーケンスは、それがシーケンス当たりの固定されたオーバーヘッドをアトム化するので、同数のファイル・オフセットを含む、より小さい２つのシーケンスよりも小さいスペースしかとらない。しかし、シーケンスが長いほど探索にかかる時間が長くなる。したがって、アトム−マップ３６０は典型的には、長さ、ひいては探索時間に適宜の制約を設けるために、厳密に必要であるよりも多いシーケンスへと分解される。しかし、シーケンスのサイズには定められた制限はない。

最初のアトム−ファイル−オフセット３９２はシーケンス内の最初のアトム１３０のファイル・オフセットである。シーケンスの残りの部分はこの値から始まる一連のデルタである。

デルタ符号化ファイル−オフセット−アレイ３９４は、連続的なアトムｉｄ１３２を見出すことができるファイル・オフセットのシーケンスを符号化するバイトのブロックである。

シーケンスを符号化するため、エンコーダはファイル・オフセットのシーケンスから開始する。これらはアトム−マップ−データ−オフセット３７８に追加される予定のバイト・オフセットを表す。例えば、オリジナルのファイル・オフセットの数列が｛１０００、１０５０、１１０４、１１６５、１６４５、７６０｝であったものと想定してみる。アトム１３０は必ずしもファイル内の順序ではないことに留意されたい。最初に、シーケンスがデルタ符号化されて｛１０００、５０、５４、６１、４８０、−８８５｝が生ずる。デフォールト−アトム−シーケンス−デルタ３７２が５０に等しいものとすると、このシーケンスはさらに｛１０００、０、４、１１、４３０、−９３５｝へと調整されよう。最後に、（最初のアトム−ファイル−オフセット３９２内に記憶されている最初の数の後の）シーケンス内の各々の数はサイズ可変整数として符号化される。符号化によってバイト・シーケンス｛０ｘ００ ０ｘ０４ ０ｘ０Ｂ ０ｘ８３ ０ｘ２Ｅ ０ｘＦ８ ０ｘ５９｝を生ずる。幾つかの整数はより小さい値用により少ないバイトをとるサイズ可変符号化法を用いて記憶される。符号付きの整数は７ビット値のシーケンスとして符号化される。数値は、データベースの全体的な並び順に関わりなくビッグエンディアン・バイト順（最上位バイトが最初）に記憶される。各バイトのハイビットはそれ以上のいずれかのバイトが続くか否かを示す特別のフラグである。最初のバイトの７番目のバイト（数値データの最上位ビット）は符号拡張される。符号がない整数は７ビット値のシーケンスとして符号化される。数値はデータベースの全体的な並び順に関わりなくビッグエンディアン・バイト順（最上位バイトが最初）に記憶される。各バイトのハイビットはそれ以上のいずれかのバイトが続くか否かを示す特別のフラグである。結果として生ずる数値は符号拡張される。

アトム−マップ３６０は特定の種類の情報をアトムｉｄ１３２に関連付けるために使用される。例えば、アトム−マップ３６０をコード／データ・ボデー情報、記号情報、カテゴリー情報、および記述情報用に使用可能である。

ボデー−アトム−マップは、通常のアトムの場合は、結合して最終的な通常アトム・ボデーを形成することができるアトム・リファレンス１３６およびアトム・バイト１３４に関する圧縮された情報を含み、特定目的のアトムの場合は、特定目的のアトムの各々の特殊型に適する情報を含む、そのアトムｉｄ１３２をロードするために必要な情報のブロックへと各アトムｉｄ１３２をマッピングする。

ブロックの最初のバイトは１組のアトム−フラグ３９６を符号化するために使用される。アトム−フラグ３９６の３つの下位ビットの値が特定目的の識別子（例えば「７」の値を示す３つのオン・ビット）を含んでいない場合は、アトム１３０は通常のアトムであり、そうではない場合にはアトム１３０は特定目的のアトムである。通常のアトム・ボデーのローディング速度を高めるため、アトム１３０用のアトム・リファレンス１３６とアトム・バイト１３４の双方ともアトム・データベース１２０のファイルに連続して記憶される。アトム・データベース１２０のサイズを小さく保つため、ひいてはこれをロードできる速度を高めるため、通常のアトム・ボデー用のアトム・リファレンス１３６およびアトム・バイト１３４は多様な態様で圧縮される。

図１３は符号化されたアトム・データ構造の略図である。通常のアトム用の情報ブロックは、アトム−フラグ３９６、アトム−ナンバー情報３９７、符号化されたアトム−リファレンス３９８、および符号化された未処理アトム−バイト３９９からなっている。

アトム−フラグ３９６はアトム圧縮の種類を特定するフラグ・バイトの様々なビットを使用する。本発明の実施形態は複数の圧縮方法をサポートする。アトム−フラグ３９６のバイトの他のビットはアトムをどのバッファにロードすべきか（すなわち読み出し専用コード・バッファ、読み出し専用データ・バッファ、読み出し−書き込みデータ・バッファ）を特定する。さらに別のビットはロードされる際にアトム１３０が必要とするアラインメントの定数を２とした対数を定義する。（例えばこれらのビット内に記憶された「３」の値によって、アトム１３０はロードされるとｍｏｄ８バイトで位置合わせされよう。）
アトム−ナンバー情報３９７は符号化されたアトム−リファレンス３９８のブロック内に幾つのリファレンスが現れるか、および符号化された未処理アトム−バイト３９９のブロックから幾つの未処理バイトが抽出されるかに関する情報を含むバイト・ブロックである。このエントリはリファレンスの数および抽出すべき未処理バイト数の双方を決定する。概念的なアトム・バイト１３４およびアトム・リファレンス１３６は符号化されたアトム−リファレンス３９８および符号化されたアトム未処理バイト３９９としてそれぞれ符号化される。

図１４は符号化されたアトム・リファレンス・データ構造の略図である。各々の符号化されたアトム−リファレンス３９８はこのアトム１３０から別のアトム１３０への参照を記述するバイト・ブロックである。例えば、アトム１３０が別のアトム１３０によって表される別のプロシージャを呼び出すプロシージャを表している場合、別のアトム１３０は符号化されたアトム−リファレンス３９８内に記述されよう。符号化されたアトム−リファレンス３９８のこのアレイはアトム管理プログラム１６０によって、アトムをロードする際にアトム１３０を互いにリンクするために使用される。

アトム−ナンバー情報３９７は符号化されたアトム−リファレンス３９８によって符号化されるアトム・リファレンスの数である。

符号化された各アトム−リファレンス３９８はアトム−リファレンス−タイプ４０２、ソース−オフセット−デルタ４０４、Ｄｅｓｔ−オフセット４０６、およびデストネーション−アトムｉｄ４０８を含んでいる。

アトム−リファレンス−タイプ４０２はあるアトム１３０から他のアトム１３０への異なる種類のリファレンスを定義する。全ての種類が全てのプラットフォームによって使用されるわけではない。妥当なアトム−リファレンス−タイプ４０２はイーガー−アブソリュート−３２、イーガー−リラティブ−３２、レイジー−アブソリュート−コード−３２、レイジー−リラティブ−コード−３２およびレイジー−アブソリュート−３２を含んでいる。

イーガー−アブソリュート−３２によってアトム管理プログラム１６０は参照されたアトム１３０を即座にロードし、それに対する絶対的なアドレスを記憶する。

イーガー−リラティブ−３２はイーガー−アブソリュート−３２と同類であるが、イーガー−リラティブ−３２は参照されたアトム１３０への相対的なオフセットを記憶する。相対的なオフセットはリファレンスの始端から測定される。

レイジー−アブソリュート−コード−３２はコードを含むアトム１３０への絶対的なアドレス（例えば３２ビット）を定義する。これが「レイジー」（緩慢）であるのは、参照されたアトム１３０はそれが最初に呼び出されるまで実際にはロードされないからである。アトム管理プログラム１６０は参照されたアトム１３０が呼び出されて初めてこれを緩慢にロードするコード・スタブを指し示すようにリファレンスをセットアップすることによって遅延されたローディングを管理する。

レイジー−リラティブ−コード−３２はレイジー−アブソリュート−コード−３２と同類であるが、レイジー−リラティブ−コード−３２はリファレンスに対する相対的なオフセットを記憶する。相対的なオフセットはリファレンスの始端から測定される。

データのレイジーな、すなわち需要に応じたローディングは、参照されたデータ・アトムがランタイムで実際にアクセスされるまでロードされないように、コードのレイジーなローディングによって暗黙的に、または参照用アトム識別子を符号化することによって明示的に行われる。データを参照するコードのローディングは呼び出されるまで遅延可能であるので、コードが参照するデータは同様に遅延され、データのレイジーなローディングを暗黙的に行う。明示的なレイジー・データは典型的には、レイジーにロードされるデータを（例えばコンパイラ指令を用いて）マークするためにプログラマーによるサポートを必要とする。１実施形態では、明示的なレイジー・データは、参照するアトム識別子を２倍し、参照するアトム識別子を１だけ増分してレイジー・データ・アトム識別子を生成する特定の符号化アルゴリズムを利用して参照される。

レイジー−アブソリュート−３２は別のアトム１３０への絶対的な（例えば３２ビットの）アドレスを定義する。これは参照されるアトム１３０が実際に明示的にロードされない点で「レイジー」である。むしろ、アトム管理プログラム１６０は符号化されたアドレス（２^＊参照されたアトムｉｄ）＋１を記憶することによってこのリファレンスをリンクする。符号化されたこのアドレスは常に奇数であることに留意されたい。ジャンプ・スタブを利用可能なレイジーコード・リファレンスとは異なり、レイジー・データ・リファレンスはアトム管理プログラム１６０が実行中のプログラムからの協力を必要とする。ポインタの値が奇数であることをチェックし、それらがレイジー・データ・リファレンスであることを認識する必要がある。次に、アトム管理プログラム１６０へとコールバックすることによって所望のアトム１３０にロードする必要があり、典型的には炉ふぁ連ステップに最終アドレスを上書きするであろう。もちろん、レイジーにロードされたデータが偶数のアラインメントを有することが判明していなければならず、さもなければこのようなポインタの向けの奇数値が曖昧になる。

ソース−オフセット−デルタ４０４はリファレンスが現れるアトム１３０へのバイト数を特定する。この値は先行のリファレンスの終りからのデルタとして表される。全く最初のリファレンスは、ソース・オフセット０で終わる先行リファレンスがあたかも存在するかのように符号化される。リファレンスは常にそれらのソース・オフセットによって分類されて記憶されるので、このアレイ内のデルタは常に負ではない。例えば、アトム１３０がバイト・オフセット０、４、８、１２、２０で４バイトのリファレンスを有している場合は、これらのリファレンス用のソース・オフセット・デルタ欄は０、０、０、０、４として符号化されよう。

Ｄｅｓｔ−オフセット４０６は、リファレンスが指し示す参照された（Ｄｅｓｔ）アトム１３０へのバイト数のオフセットを符号化する。

Ｄｅｓｔ−アトム・ｉｄ４０８はこのリファレンスが指し示すアトム１３０用のアトムｉｄ１３２である。

符号化された未処理アトム−バイト３９９はアトム１３０用のアトム・バイト１３４を表すバイト・ブロックであり、他のアトム１３０へのいずれかのリファレンスを保持するスペースが必要であり、残りの未処理バイトはアトム圧縮の種類によって定められる態様で圧縮される。未処理バイトを作成するためにアトム・バイト内のリファレンスを除去することができるが、それは符号化されたリファレンス情報が（リファレンスがどこで作成されたかを特定する）ソース・オフセット、（ターゲット・アトムを特定する）デストネーションｉｄ、および（リファレンスが指し示すターゲット・アトムへのバイト数を特定する）Ｄｅｓｔ−オフセットを含んでいるからである。例えば、アトム・バイト１３４がＣ文字列の定数を表す場合は、このアレイは、場合によっては圧縮された状態で文字列内の文字のシーケンスを保持するであろう。そうではなく、アトム・バイト１３４が４つのデータ・バイトからなり、その後に別のアトム１３０への４バイトのリファレンスが続き、その後にさらに８つのデータ・バイトが続く場合は、符号化された未処理アトム−バイト３９９は、場合によっては圧縮された状態でちょうど１２バイトのデータを含むであろう。４バイトのリファレンスがローディング中に所定位置に「継ぎ合わされ」、完全にロードされたアトム・バイト１３４が１６バイトを占めるようにする。

特定目的のアトムは（例えば「７」の値に設定された下位の３ビットのような）特定目的の識別子を含むアトム−フラグ３９６によって定義される。アトム−フラグ３９６の残りのビットは、特定目的のアトムがｄｌｌ−ｒｅｆ−アトムであるのか、ｄｌｌ−アトムであるのかを特定する。

Ｄｌｌ−ｒｅｆ−アトムは３つの欄を備えている。すなわち、アトム−フラグ、ｄｌｌ−アトム−ｉｄおよびｄｌｌ−記号である。Ｄｌｌ−ｒｅｆ−アトムは（ｐｒｉｎｔｆ（）のようなライブラリ機能用のアトム１３０のような）外部ＤＬＬ内の記号に対応している。これらのアトム１３０はそのＤＬＬで参照するための一対のＤＬＬおよび記号として表される。Ｄｌｌ−アトム−ｉｄはｄｌｌ−記号を参照するＤＬＬを特定するｄｌｌ−アトムのｉｄを特定する。Ｄｌｌ−記号はどの記号をＤＬＬ内で参照するかを特定する。

Ｄｌｌ−アトムはアトム−フラグ欄とｄｌｌ−パス−ネーム欄とを備えている。Ｄｌｌ−アトムはｄｌｌ−ｒｅｆ−アトムに関連し、ｄｌｌ−ｒｅｆ−アトムが記号を参照するＤＬＬを特定する。Ｄｌｌ−パス・ネームはｄｌｏｐｅｎ、ＬｏａｄＬｉｂｒａｒｙ、またはこれと同等の機能に送るのに適するパス・ネームを特定する。これはＣ文字列（０で終わるバイトのシーケンス）として記憶される。

記号−アトム−マップはアトムｉｄ１３２をテキスト記号にマッピングし、それによって関連するアトム１３０は名前によってアクセスされることができる。記号はユーザーに便利な態様でアトム１３０を参照するのに有用である。例えば、アトム１３０を５７のアトム識別値で参照する場合、プログラマーにとっては（例えば）５７」のような）アトム識別値によるよりも（例えば「ｐｒｉｎｔｆ」のような）名前で参照するほうが簡単である。

カテゴリー−アトム−マップは定まった意味論を持たない、アトムｉｄ１３２からテキスト・カテゴリーへのアトム−マップ３６０である。カテゴリー−アトム−マップによって開発者はアトムを特定のカテゴリーに分類することが可能になる。別の例では、文字列アトム１３０を識別し、国際化のため、およびその他の多くの目的のためにアトム１３０を識別するため、アトム１３０にタグを付すためにカテゴリーを利用することができる。

記述−アトム−マップは定まった意味論を持たない、アトムｉｄ１３２からテキスト記述へのアトム−マップ３６０である。記述−アトム−マップは、アトム準拠のシステムを開発／デバッグする場合に、開発者にとって有用なデバッグ情報ヲ記憶するために利用することができる。

アトム・リファレンスの種類はリファレンス利用のプロファイリングに基づいて、静的または動的に変更可能である。アトム・リファレンス１３６は一般に、実際のアトム・バイト１３４のローディングをランタイムで実際に必要になるまで遅延するために、デフォールトで「レイジー」になる。「イーガー」リファレンスによって、呼び出しアトム１３０がロードされると、参照されたデータ／コードはそれが実際に必要であるか否かに関わらずロードされる。ランタイムで所定のアトム１３０内で実行されたランタイムのコード・パスは、アトム１３０内の全ての命令を実行しないことが多い。呼び出されない、または参照されないアトム１３０のローディングはメモリと処理資源の無駄になることがある。

コード用のレイジーなリファレンスを解消することには、参照されたアトム１３０が最初に呼び出された時点でこれをレイジーにロードするコード・スタブを指し示すことが含まれる。データ用のレイジーなリファレンスを解消することには、参照されたアトムｉｄを（２^＊参照されたアトムｉｄ）＋１として記憶することが含まれる。

一旦レイジー・コード・リファレンスが実行／アクセスされると、コード・スタブを使用するという遠回りを避けるために最適化を行うことができる。最適化にはロードされたアトムを直接参照するために参照コードを「バックパッチ」することが含まれる。バックパッチはスタブを使用する代わりにメモリ内のコード・アトム１３０に直接ジャンプするものである。バックパッチは最初の実際の呼び出し元に関して実行可能であり、さらに、参照されたアトム１３０が実際に呼び出された場合にその時点でそこに直接ジャンプすることが可能であるように、ロードされるどのアトム１３０にも適用可能である。コード・スタブは、バックパッチが行われなかったいずれかのアトムが利用するようにメモリ内に残しておくことができる。本発明の実施形態はコード・アトム１３０とデータ・アトム１３０とのリファレンスにタグが付されて、アトム・レベルで特定のローディング・アクション（例えばレイジーまたはイーガー）を行うことを提案する。

図１５は６つのコード・プロシージャと３通のデータ要素のシステム例の略図である。この実施例ではプロシージャＰ１はプロシージャＰ２およびＰ３を呼び出し、プロシージャＰ１はさらにデータ要素Ｄ１にアクセスし、これはデータ要素Ｄ２にアクセスする。プロシージャＰ２はプロシージャＰ４にアクセスし、これはデータ要素Ｄ３にアクセスする。プロシージャＰ３はデータ要素Ｄ１にアクセスし、プロシージャＰ５を呼び出す。本発明の実施形態によれば、各コード・プロシージャ｛Ｐ１、Ｐ２、Ｐ３、Ｐ４、Ｐ５、Ｐ６｝は個々にアドレス指定可能な単一のアトムとして定義される。同様に、各データ要素｛Ｄ１、Ｄ２、Ｄ３｝は個々にアドレス指定可能な単一のアトムとして定義される。ランタイムでＰ１がロードされると、Ｄ１が即座にロードされ、それによってＤ２がロードされる。Ｐ２およびＰ３へのリファレンスがレイジーである場合は、Ｐ２およびＰ３用にスタブが作成され、それによってプロシージャのコードの実際のローディングは、それらが実際に呼び出される場合、その時点まで延期されることができる。通常の実行パス中にある種のコード・プロシージャ（例えばエラー・ハンドラ）が呼び出されないことが充分に可能である。この場合、ローディングを遅延させることによって処理工程とメモリが節約される。コードのレイジーなローディング（例えばＰ２）に基づくデータ（例えばＤ３）の暗黙的なレイジー・ローディングによってプロセッサとメモリの双方が節約される。

データ要素に同様の能力を付与するためにデータ・アトム・リファレンスを符号化することができる。データの明示的なレイジー・ローディングによってさらに一層の節約がなされる。（例えばＤ３のローディングはＰ２がロードされた後でも遅延させることができる。）
参照されたアトムのアトム識別子を修正することによって、アトム管理プログラム１６０はデータ要素／アトムが実際に参照されるまでそのローディングを遅延させることができる。コード・アトムの場合と同様に、（例えばエラー・メッセージのような）あるデータ・アトムが通常の実行パス中に参照されないことは充分あり得る。データ・アトムのレイジーな／遅延されたローディングも処理工程とメモリを節約する。

（例えばＬｉｎｕｘ ＤＬＬのような）従来のシステムはコード・スタブを備えるが、これらのシステムは可能な全てのリファレンス用のスタブを立ち上がり時に構成する。これに対して、本発明の実施形態はロードされたアトム１３０によって実際に参照される各アトム１３０用のスタブだけを構成する。図１３を参照すると、Ｐ１のローディングによってＰ２およびＰ３用のスタブは作成されるがＰ４用のスタブは作成されない。従来のシステムは典型的には立ち上がり時に全てのデータ要素をロードする。例えば、従来のシステムでは、Ｄ１、Ｄ２、およびＤ３は立ち上がり時に全てロードされる。これに対して、本発明の実施形態はＤ２がロードされる場合、またはＤ３が実際に利用される場合だけＤ３をロードするだけである。ローディングに関連してデータおよびコードを同様に扱うフレキシビリティによって、パフォーマンスの多くの向上が得られる。これはデータとコードの比率が比較的大きいシステムに特に当てはまる。

ビューを利用して、システムの実施例はＰ５の置き換えである新たなプロシージャＰ６を含むことができる。ビューはＰ５へのリファレンスをＰ６へのリファレンスと置き換えるローディングおよび参照オペレーション用に適用可能であるので、既存のシステムを変更する必要がない。

図１６ａはデータ・アトム１３０の略図である。データ・アトム１３０はそれらのアトムｉｄ１３２、アトム・バイト１３４、およびアトム・リファレンス１３６を例示するために概念的に示されている。（図１５のＤ１に類似する）データ・アトム１６００１はデータの２つのアイテム（アトム・バイト１３４）、すなわち人名（例えば“Ｍａｒｙ Ｓｍｉｔｈ”）およびＭａｒｙの年齢（例えば４７）へのリファレンス（ポインタ）を含んでいる。リファレンス（アトム・リファレンス１３６）はアトム１６００２へのリファレンスである。（図１５のＤ２に類似する）アトム１６００２は“Ｍａｒｙ Ｓｍｉｔｈ”とうい文字列を表すデータ・アトム１３０（アトム・バイト１３２）であり、アトム１６００２は他のどのアトムをも参照しない。

図１６ｂはコード・アトム１３０の例の略図である。コード・アトム１３０はそれらのアトムｉｄ１３２、アトム・バイト１３４、およびアトム・リファレンス１３６を例示するために概念的に示されている。（図１５のＰ５に類似する）コード・アトム１５０００は人名と年齢をプリントするｐｒｉｎｔ＿ｐｅｒｓｏｎ（）プロシージャ用の実行可能なコードを表す。（図５のＰ３に類似する）コード・アトム１６０００はＭａｒｙの名前と年齢をプリントするｐｒｉｎｔ＿ｐｅｒｓｏｎ（）プロシージャを呼び出すプロシージャを表す。コード・アトム１６０００はデータ・アトム１６００１を参照することによってＭａｒｙについてのデータを参照し、コード・アトム１５０００、ｐｒｉｎｔ＿ｐｅｒｓｏｎ（）への参照を介してｐｒｉｎｔ＿ｐｅｒｓｏｎ（）機能を呼び出す。したがって、アトム１６０００によって表されるアトムは２つのアトム・リファレンス１３６、すなわちアトム１５０００（ｐｒｉｎｔ＿ｐｅｒｓｏｎ（）プロシージャ用のコード・アトム）へのコード・アトム・リファレンス１３６と、アトム１６００１（Ｍａｒｙのデータ用のデータ・アトム）へのデータ・アトム・リファレンス１３６とを含んでいる。

図１６ｃは置き換えられたコード・アトムの例の略図である。コード・アトム１７０００はアトム・データベース１２０に追加され、ｐｒｉｎｔ＿ｐｅｒｓｏｎ（）プロシージャの更新バージョン（アトム１５０００）を表す。ｐｒｉｎｔ＿ｐｅｒｓｏｎ（）を呼び出す実行可能プログラムはこの時点で、実行可能プログラムがコード・アトム１７０００を参照してアトム１５０００へのリファレンスを修正するビューで実行されたか否かに基づいて、古いｐｒｉｎｔ＿ｐｅｒｓｏｎ（）プロシージャ（アトムｉｄ１５０００）または新たなｐｒｉｎｔ＿ｐｅｒｓｏｎ（）プロシージャ（アトム１７０００）のいずれかをよびだすことができる。このようにして、既存のプロシージャを別の呼び出し元用に依然として所定位置に残しつつ、実行可能プログラムが既存のプロシージャの更新バージョンを呼び出すことができるようにするため、ビューを適用することができる。

図１７ａはアトム・データベース差分処理工程の略図である。アトム・データベース差分処理工程５００は２つのアトム・データベース、すなわち第１アトム・データベース５１０と第２アトム・データベース５２０とを取り出し、パッチ・ファイルとして記憶可能なビュー１２２を作成する。ビュー１２２は１つのアトム・データベースを他のアトム・データベースに仮想的に、または物理的に変換するために利用可能である。アトム・データベース差分処理工程５００の目標の１つは、ビュー１２２のサイズを最小限にして、効率的に記憶され、分散されることを可能にすることである。

各アトム１３０は（例えばプロシージャ用の実行可能コード、または文字列定数の文字のような）バイト・ブロックからなる「ボディー」（アトム・ボデー１３４）、プラス他のアトム１３０へのゼロ以上のリファレンス（アトム・リファレンス１３６）からなっている。各リファレンスはボデー内のある特定のオフセット位置にある。例えば、プロシージャへの呼び出し命令２０バイトは典型的にはオフセット２０の位置、またはその近傍に呼び出されたプロシージャ用のアトム１３０へのリファレンスを含んでいるであろう。

アトム・データベース１２０はエッジにラベルが付された、向きを持ったグラフを符号化し、各アトム１３０はノードであり、各アトム・リファレンス１３６はエッジである。パッチ・ファイルの作成には、第１アトム・データベース５１０と第２アトム・データベース５２０とで共通であるサブグラフを特定し、これらのノードを出荷せずに、再度パッチ・ファイル内で再利用することが含まれる。残念ながら、高品質のパッチの作成には同一構造のサブグラフを特定する以上のことが必要である。実際には、サブグラフは１つか２つの相違点を除けば同一構造である場合が多い。その相違は例えば、１つのプロシージャは変更されるが、それを呼び出す全てのプロシージャは不変のままに留まる場合に生じる。１つの相違のために全部を断念するのではなく、サブグラフ用に大部分のアトムを再利用したい。

パッチ・ファイルは結果として生じるグラフを第２アトム・データベース５２０と同一構造にする第１アトム・データベース５１０への変換シーケンスを符号化する。正しい変換のセットを特定することはアトム・データベース差分処理工程５００の一部である。アトム・データベース差分処理工程５００は第２アトム・データベース５２０内の各アトムを、各々が異なる種類のグラフ変換である３つのカテゴリーの１つに分類する。この分類のベクトルはパッチ・ファイルを作成するために必要な全ての情報を含んでいる。再利用の分類は、第１アトム・データベース５１０内のアトム１３０を再利用でき、したがってこれを差分処理セットに加える必要がないものと判定する。これは最良の場合である。置換の分類は、おそらくは他のアトム１３０が再利用のカテゴリーに入ることができるように、第１アトム・データベース５１０内のアトム１３０と新たなアトム１３０とを置き換える必要があるものと判定する。このアトム１３０用のバイトはパッチ・ファイル内に現れる。挿入の分類は、この新たなアトム１３０は第１アトム・データベース１２０内のどのアトム１３０とも全く共通点がなく、したがってそれを追加する必要があるものと判定する。このアトム１３０用のバイトはパッチ・ファイル内に現れる。パッチ・ファイルは置換を記述する情報を含む必要がないので、挿入はやや置換よりベターであると思われる。削除オペレーションはオプションであるが、それはパッチが損失なく実施された後、余剰のアトム１３０を残したままにできるからである。この工程はパッチを適用する際にディスク上のアトム１３０を実際に置き換える必要がない。何故ならば、パッチ後のインストールの観点から見た場合、代わりに新たなアトム１３０を使用すべき場合に、古いアトム１３０へのリファレンスを修正するために変換オペレーションを利用できるからである。

ここで図１７ｂを参照すると、この場合は各大文字｛Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ｝はアトム１３０のコンテンツを示している。２つのアトムは、それらが同じ大文字を有していれば、その場合に限って同じボデーを有する。主要な接尾辞“”は、ノードが新たなグラフ内にあることを示している。このグラフ用の最適な変換シーケンスは、再利用（Ｃ、Ｃ’）、置換（Ｄ、Ｅ’）、再利用（Ｂ、Ｂ’）、および挿入（Ａ‘）である。削除（Ｆ）変換はオプションである。

留意すべき重要事項は、置換（Ｄ、Ｅ’）の変換オペレーションは再利用（Ｂ、Ｂ’）の変換オペレーションを可能にするために決定的に重要であることである。ＢおよびＢ’で示されているアトムが等しくなるように変換されると、ＢとＢ’とが等しくなる。このアルゴリズムは、できるだけ多くの再利用マージを可能にするためにグラフを変換しようとして多くの時間を費やす。変換によってＢおよびＣが古いグラフから再利用可能にされたので、これらはパッチ・ファイルで出荷される必要はない。

ここで図１７ｃを参照すると、同様に見えるが実際にはより複雑な実施例が示されている。エッジが順に並べられ、したがって２つのグラフは自明に同一構造ではないことに留意されたい。この実施例では、下記の選択がなされなければならない。ＸとＹを再利用するか、またはＡを再利用する。双方ともうまくいく。 ＸとＹを再利用するためには、（Ｘ、Ｘ’）を再利用し、（Ｙ、Ｙ’）を再利用し、（Ａ、Ａ’）を置換する。Ａを再利用するためには、（Ｘ、Ｙ’）を置換し、（Ｙ、Ｘ’）を置換し、（Ａ、Ａ’）を再利用する。正しい解答はＸ、ＹおよびＡの大きさによる。ＡがＸおよびＹと比較して小さければ、最初の回答がベターである。Ａが比較的大きければ、第２の回答がベターである。

再利用のマージを最大限にする１組のグラフ変換を選択するには貪欲アルゴリズムが利用される。このアルゴリズムは最適な結果を生ずることは保証されていないが、グラフがかなり類似している場合は良好な結果を生ずる。２つのアトム１３０、すなわち１つは（古い）第１アトム・データベース５１０からのアトム、もう１つは（新たな）第２アトム・データベース５２０からのアトムは、差分処理アルゴリズムが互いにマッピングした場合に「マージ」されたものと定義される。２つのアトム１３０がマージされた後、それらはそれ以降は等しいものとして扱われる。「マージ」という名詞はマージされる予定の一対のアトム１３０を表している。「コミットされたマージ」とは、実際に実施されたマージである。差分処理アルゴリズムが完了すると、コミットされた各マージは再利用マージまたは置換マージのいずれかに分類される。マージされずに留まっているアトム１３０は挿入マージに分類される。２つのアトム（古いアトムと新しいアトム）は、結局は依然として再利用マージと共にマージされるならば「互換性がある」。具体的には、
１） アトム１３０は相互以外にはどのアトム１３０ともマージしていない。
２） アトム１３０は同一のボデーを有している。
３） アトム１３０はそれが参照するアトム１３０を無視して一対の同一のリファレンスを有している。言い換えると、リファレンスは同じオフセット、種類などを有している。
４） 参照された全てのアトム１３０が互いに対偶でマージし、または全くマージしていない。言い換えると、このマージを再利用できなくするマージはコミットされていない。
５） 「それ自体」へのリファレンスは２つのアトム内に対偶で勢揃いされなければならない。
６） アトム１３０は内部矛盾するマージ要求を有していない。この状態は例えば、古いアトムがアトムＸを２回参照し、新たなアトムがアトムＡとＢとを参照した場合に生ずる。再利用マージになるには、ＸはＡとＢの双方とマージしなければならず、それは不可能である。

２つのアトム１３０（古いアトムと新たなアトム）は、互いに「互換性があり」、他のアトム１３０とは互換性がない場合に「一意的な互換性」がある。マージの「重み」はその重要度の表示である。重みは、アトム１３０が再利用マージとのマージに成功しない場合にパッチ・ファイルに追加されるバイトの推定数に等しい。これは必然的にバイトでのアトムのディスク表現である。

差分処理アルゴリズムの概要には下記のステップが含まれる。
１） 古いｄｂと新たなｄｂを標準化する。
２） 「ゴール」マージのセットＧＭを特定する。
３） ＧＭを補助するマージのセットＡＭを特定する。
４） ＧＭが空いていない間に、
ａ） ＡＭ内の最良のマージを選択および適用する。

ｂ） ＧＭを更新する。

ｃ） ＡＭを更新する。
５）再利用マージになるようにも、コミットされた再利用マージで補助されるようにも調整されない、コミットされた各マージをアンドゥする。一意的な互換性があるマージが出現した場合は、それらの全てをＧＭに追加し、１つの無限重みを与え、ステップ３）に進む。
６） 残りの同一構造を探索するために、古いｄｂと新たなｄｂとの間に修正された共用アルゴリズムを適用する。一意的な互換性があるマージが出現した場合は、それらの全てをＧＭに追加し、１つの無限重みを与え、ステップ３）に進む。
７） いずれかの互換性があるマージが存在する場合は、１つの無限重みを与え、ステップ３）に進む。

古いｄｂと新たなｄｂの標準化には、各データベース内の同一構造のサブグラフを潰すために互いに独立して、古いｄｂと新たなｄｂとにわたって標準のアトム共用アルゴリズムを実行することが含まれる。それによってデータベースは標準化され、アトムが複数回マージされる必要があるほとんどの場合がなくなる。

ＧＭの特定では、「ゴール・マージ」のセットは、それ以外の場合に曖昧なアトムの海にある幾つかの「固定点」を確定することによって、２つのグラフを勢揃いする試みを含んでいる。これらによって、その時点から他のマージングを決定できる出発点が得られる。ＧＭは常に、未だ公式の再利用マージになっていない、一意的な互換性がある全てのマージのセットに等しい。アトムのボデー、並びにそれらのリファレンスの構造をハッシュするハッシュ・テーブルでな意的に互換性があるマージを発見する。アルゴリズムの進展とともに、マージはＧＭに追加され、残りのグラフが変換されるとＧＭから除去される。ＧＭの要素は「ゴール・マージ」と呼ばれる。このアルゴリズムはそれまでに生じた全ての再利用を発見しようとはしないことに留意されたい。それらの数が極度に多い場合がよくある。最悪の場合は、生じる可能性がある再利用マージの総数がグラフのサイズの約二乗にも達する。

ＡＭの特定では、「アシスト・マージ」のセットは、ゴール・マージ用に再利用になることが分かりつつ進行し、参照された全てのマージは対偶でマージされなければならない。これらの対偶のマージは「アシスト・マージ」と呼ばれ、これら全てのセットがＡＭである．したがってＡＭはＧＭの純然たる関数である。ＧＭの要素がＡＭ内にも現れてもよい。これは、ゴール・マージが別のゴール・マージを補助する場合に出現する。

「明確な」マージを適用する場合、あるアトムを他のアトムでマージすることの欠点は、これらのアトムがもはや別のいずれかのアトムと自由にマージされないことにある。しかし、１つだけの他のアトムが潜在的なマージの相手（またはその逆）である場合は、その欠点は消えてしまう。このようなマージをコミットすることの利点は、それによって残りのマージ候補のスコアがより正確になることが助長されることである。この段階中に、このような「明確な」全てのマージが特定され、適用される。各アトムは最終的にゴール・マージ、アシスト・マージ、またはその双方になる。潜在的なマージが１つ以上あるか否かを判定することは重要なので、（ｎ乗倍になることがある）可能な全てのマージを例示する必要はない。むしろ、マージをカウントすることができ、また、可能性がある第２のマージ相手が発見された場合は処理工程を停止することができる。潜在的なゴール・マージの数は、定義によれば、互換性があるアトムの数と同数である。これはハッシュ・テーブルを用いて容易に計算される。

アトムＸ用の潜在的なアシスト・マージの計算はさらに複雑である。これはＸの全ての親を通して反復することによって行われる。各親ごとに、その親が互換性を有する他のアトムを吟味する。これらはそれぞれが潜在的なゴール・マージを表している。それぞれの潜在的なゴール・マージごとに、正常な再利用マージにするために、Ｘがそれとマージされる類似のアトムをノートしておく。このような各アトムはＸ用の潜在的なアシスト・マージである。これらのアトムをカウントすることで、Ｘがその一部となり得るアシスト・マージ候補の数が明らかになる。

ＧＭが空いていない間、各ボール・マージ（古いマージ、新たなマージ）を実際の再利用マージへと転換することを試みる。前述したように、それには古いアトムと新たなアトムとによって参照された全てのアトムを対偶でマージすることが必要である。メイン・ループは（後述する）最高の「スコア」とのマージを特定し、そのマージを貪欲にコミットし、ＧＭが空になるまでその工程を繰り返す。負のスコアを有するマージは、それらが最高のスコアを有していれば理論的にはコミットされることができるが（それが実際に起こる場合を構築することは不可能ではないとしても困難であろう）、そのスコアが負の無限大に等しいマージは明らかに無視される。

各マージは、そのマージをコミットすることがパッチ・ファイルのサイズをどの程度縮小するかを（極めて大雑把に）見積もる「スコア」を有している。アシスト・マージとゴール・マージの双方ともスコアを有している。スコアの計算が比較的局部的な処理工程であることは重要である。各マージがグラフ全体のスコアの変更を要求するならば、アルゴリズムの動作は緩慢すぎて実際的ではなくなる。マージがアシスト・マージではなく、またそのアシスト・マージの全てがコミットしたゴール・マージではないならば、そのスコアは負の無限大である。そうではない場合は、そのスコアはゴール・マージによってそれにかけられる「圧力」の関数である。

各ゴール・マージはそれが依存する全てのコミットされないアシスト・マージ、ならびにそれ自体に均等に圧力をかける。圧力は「それ自体」へのリファレンスを除いて、ゴール・マージの重みをコミットされないアシスト・マージで除算することによって計算される。

そこで、少数のリファレンスを有する極めて大きいアトムがそのアシスト・マージに大量の圧力をかけ、多数のリファレンスを有するアトムはそのアシスト・マージに比較的小さい圧力をかけて、マージ当たりの利点が少ないことを示す。このような公式であるので、より多くのアシスト・マージがコミットすると、残りのマージ候補への圧力は高まり、それらに対して「ジョブを終了する」ように促す。

マージに対する全ての圧力の合計はＰと呼ばれる。アシスト・マージＭのスコアは、そのＰの値からＭと相互排他的な他のアシスト・マージ用の全てのＰの最大値を減算した値に等しい。例えば、アトム（Ｘ、Ｙ）をマージすることはアトム（Ｘ、Ｚ）をマージできないことを意味する。何故ならば、Ｘは一度だけしかマージできないからである。（Ｘ、Ｚ）をマージすることによって得られるものが多い場合は、（Ｘ、Ｙ）のマージを防止するためにこれにペナルティを課すことが適当である。

多数のマージが可能な場合に、それらが全く起こり得ないので異常なペナルティを課すことを避けるため、「合計」の代わりに「最大」が用いられる。上記の実施例では、（Ｘ、Ｙ）によって妨げられる各々のマージはＸまたはＹのいずれかを含んでいなければならないので、仮に数千ものマージが理論上妨げられたとしても（例えば（Ｘ、Ａ）、（Ｘ、Ｂ）、（Ｘ、Ｃ）…）、これらのマージのうち多くても２つのマージしか同時に起こり得ないであろう（１つのマージはＸを含み、もう１つのマージはＹを含む）。したがって、数千もの防止されたマージにペナルティを課すことは厳しすぎよう。

ゴール・マージは、それらのスコアが通常は負の無限大であるにせよ、それ自体に圧力をかけることに留意されたい。その理由は、ゴール・マージと相互排他的なアシスト・マージはそれを防止するためにペナルティが課せられるからである。

２つのアトムをマージすることによって、以下の３つが変化することがある。すなわち、ＧＭ、ＡＭ、またはＡＭおよびＧＭ内のマージのスコアである。ゴール・マージがコミットされた再利用マージになれば、明らかにゴール・マージのセットは変化する。そうなると、マージは完全に終了しているのでＧＭから除去される。ゴール・マージをコミットするだけではこれをＧＭから除去するのに充分ではない。何故ならば、そのアシスト・マージに圧力を加えて、それが実際に再利用マージになるようにする必要が依然としてあるからである。マージがコミットされると、各アトムは一回しかマージできないので、これらのアトムを含む他のマージは不可能になる。それによって、この時点で不可能なマージに依存していたいずれかのゴール・マージは再利用マージになる可能性が全くなくなり、したがってこれらはゴール・マージであることを止め、ＧＭから除去される。マージはさらに、互換性があるマージを一意的に互換性があるマージへと転換することによって、新たなゴール・マージを作成してもよい。例えば、古いｄｂと新たなｄｂの各々に１０のアトムがあり、その全てが互いに互換性を有しているものと想定する。どの対偶が良好なマージを呈するかに関する完璧なガイドはないので、処理工程は１００（１０＊１０）の全てのゴール・マージを作成はしない。しかし、マージがこれらのアトムによって参照されたアトム内で出現する場合は、これらのアトムの急激な対偶が一意的な互換性を有するようになることがある。何故ならば、古いｄｂ内の所定のアトムにとって、双方とも同じボデーを有し、そのマージされたリファレンス（単数または複数）の全てが依然として潜在的に勢揃いするアトムは１つしかないからである。

以前にはゴール・マージであると見なされなかった２つの互換的なアトムを互いにマージすると、その時点でこれらは一意的な互換性を有するので新たなゴール・マージが生成される。それらをマージするようにコミットした以降にそのことを調べる方法の１つは、それらが参照するアトムに圧力を加えることによって、同様にそのマージを再利用マージにしようとする処理工程である。

ＡＭはＧＭの単純な関数であるので、ＧＭに対する変更はＡＭに影響する。意味論的にはそれは、ＧＭが変化するごとにＡＭがあたかもスクラッチから再計算されるかのようである。実際には、ＡＭは増分的に更新される。

マージのスコアは上記の買う式に従ってマージによって影響される。意味論的には、全てのマージ候補のスコアがあたかもスクラッチから再計算されるかのようである。実際には、アトム・グラフ内のマージに「近い」アトムのスコアだけが更新されればよい。

コミットされたマージが再利用マージでもなく、再利用可能でもない場合は、それはアンドゥされる必要がある。それは次の２つの理由による。第１に、マージの置き換えは挿入よりもやや高くつくからである。第２に、マージをアンドゥすると含まれているアトムが異なるマージ用に適するようになり、それにはある種の再利用マージを可能にする必要があることがあるからである。アンドゥ・ステップの後に、コミットされていない、一意的な互換性があるいずれかのマージが現れた場合は、それらの全てをＢＭに追加し、メイン・ループを再試行する。しかし、ループを再開始する前に、少なくともそのマージがコミットされた再利用マージになることを確実にするため、新たなゴール・マージに最大の重みの無限重みを付与する。それによってアルゴリズムは絶えずアンドゥし、永久にマージを再適用せずに最終的に終了することが保証される。

アトム・システムはデータベース内の全ての同一構造のアトムを潰すことができる汎用の共用アルゴリズムである。課題は本質的に「ＦＳＭ還元」（ＦＭＳ ｒｅｄｕｃｔｉｏｎ）の課題と同じである。２つのグラフ間の差異を計算するという課題は、双方のアルゴリズムとも同一構造を探求しているので、同一構造のアトムの共用に関するものである。古いｄｂと新しいｄｂとで修正された共用アルゴリズムを実行することは、他のパスによって失われた同一構造を探す優れたバックストップである。この修正された共用アルゴリズムは下記のいくつかの点で標準型の共用アルゴリズムと異なっている。１）アトムはデータベース内ではなく、データベース間だけで共用され得る。２）変わりやすいデータのような通常は共用できないアトムでも、共用され得る。また、３）各アトムは一回だけしか共用され得ない。共用ステップの跡で、コミットされない、一意的な互換性があるマージが現れると、最も重いゴール・マージの無限重みを付与した後、先行ステップと同様にメイン・ループを再試行する。

互換性があるいずれかのマージがなお存在する場合は、最大の重みを有する１つをコミットし、それに無限重みを付与し、それをＧＭに加え、メイン・ループを再試行する。代替実施形態では、各アトムに関連する、人間が読み取れる記述を吟味し、マージのガイドとしてそれを利用するというオプションがある。この「不正」（ｃｈｅａｔｉｎｇ）はうまくいくことが多いが、プロシージャは改名されたが、それ以外は不変のままである場合は失敗する。

本は発明を好適な実施形態を参照して図示し、説明してきたが、添付の特許請求の範囲に含まれる範囲から逸脱することなく、形態と細部を多様に変更してもよいことが当業者には理解されよう。

具体的には、複数の個別セクションを有するアトム・データベース１２０が記載されてきたが、本発明の教示内容がなくてもアトム１３０の様々な利用を示すセクションを追加したり、除去することができることが当業者には容易に理解されよう。その上、実際のディスク符号化方式は本発明の教示内容の範囲で変更可能である。

本発明の実施形態はＣｕｒｌ^ＴＭランタイムで実現するのに適しているが、開示内容で本発明をＣｕｒｌ^ＴＭランタイムで限定するものは全くない。本発明の実施形態はどのソフトウェア・プログラムにも適用可能である。

本発明の上記の、およびその他の目的、特徴、および利点は、異なる図面を通して同様の参照符号が同一の部品を表す添付図面に図示された、本発明の公的な実施形態から明らかにされる。図面は縮尺どうりではなく、むしろ本発明の原理を示す際に強調がなされている。
図１は本発明の実施形態が実装されるコンピュータ・システムの略図である。 図２は図１のコンピュータ・システムの内部構造の略図である。 図３はランタイムで出力をディスプレーするためにコンピュータ・プログラムを作成し、ロードするための従来の工程を示す図である。 図４はランタイムで出力をディスプレーするためにアトム化されたコンピュータ・プログラムを作成し、ロードするためのソフトウェア・アトマイゼーションの工程を示す図である。 図５はアトム抽出工程を示す図である。 図６ａはアトム、アトム・データベース、ビュー、および仮想アトム・データベースの図である。 図６ｂはアトム、アトム・データベース、ビュー、および別個の新規アトム・データベースの図である。 図６ｃはアトム、アトム・データベース、ビュー、および上書きされた新規アトム・データベースの図である。 図７ａは単一のビューを利用し、ディスク上のアトムを共用する複数の実施可能プログラムの略図である。 図７ｂは単一のビューを利用し、ディスク上およびメモリ内のアトムを共用する複数の実施可能プログラムの略図である。 図７ｃは複数のビューを利用し、ディスク上のアトムを共用する複数の実施可能プログラムの略図である。 図７ｄは複数のビューを利用し、ディスク上およびメモリ内のアトムを共用する複数の実施可能プログラムの略図である。 図８はアトム管理工程を示す図である。 図９はアトム・データベースのデータ構造の略図である。 図１０はアトム・マップ見出しデータ構造の略図である。 図１１はアトム・マップ・アレイのデータ構造の略図である。 図１２はアトム・オフセット・シーケンスのデータ構造の略図である。 図１３は符号化されたアトム・データ構造の略図である。 図１４は符号化されたアトム・リファレンス・データ構造の略図である。 図１５は６つのコード・プロシージャと３つのデータ要素のシステム例の略図である。 図１６ａはデータ・アトムの例の略図である。 図１６ｂはコード・アトムの例の略図である。 図１６ｃは置き換えられたコード・アトムの略図である。 図１７ａはアトム・データベース差分処理工程の略図である。 図１７ｂは古いアトム・データベースと新たなアトム・データベースとを表すグラフの略図である。 図１７ｃは代替の、古いアトム・データベースと新たなアトム・データベースとを表すグラフの略図である。

Claims (24)

1. アトム・データベースのビューを作成する方法であって、
   １組の変換オペレーションを規定する工程と、
   該変換オペレーションがランタイムで仮想的に適用された場合には、仮想データベースが作成され、該変換オペレーションが実際に適用された場合には、新たなアトム・データベースが作成されるように、１組の変換オペレーションを該アトム・データベースに適用する工程と、を含み、
   該アトムは、
   永続的に割り当てられたアトム識別子と、
   コンピュータ・コードおよび/またはデータと、
   他のアトムへのリファレンスと、を含む方法。
2. 前記新たなアトム・データベースは前記アトム・データベースから分離したファイルに記憶される請求項１に記載の方法。
3. オリジナルの前記アトム・データベースに前記新たなアトム・データベースを置き換える請求項１に記載の方法。
4. 前記変換オペレーションは、
   新たなアトムを挿入する挿入オペレーションを含む請求項１に記載の方法。
5. 前記変換オペレーションは、
   既存のアトムを修正する修正オペレーションを含む請求項１に記載の方法。
6. 前記変換オペレーションは、
   既存のアトムを削除する削除オペレーションを含む請求項１に記載の方法。
7. 前記ビューおよび前記アトム・データベースを第１の実行可能プログラムおよび第２の実行可能プログラムに関連付ける工程と、
   該ビューを利用して、前記アトム・データベースをランタイムで仮想的に変換して、仮想アトム・データベースを作成する工程と、
   第１の実行可能プログラムおよび第２の実行可能プログラムによって該仮想アトム・データベースからアトムをロードすることによって、該第１の実行可能プログラムと該第２の実行可能プログラムとで該アトムを共用する工程と、をさらに含む請求項１に記載の方法。
8. 前記アトムは前記第１の実行可能プログラムによってアクセス可能な第１メモリ・バッファへとロードされ、前記アトムは前記第２の実行可能プログラムによってアクセス可能な第２メモリ・バッファへとロードされる請求項７に記載の方法。
9. 前記アトムは前記第１の実行可能プログラムと前記の双方によってアクセス可能なメモリ・バッファへとロードされる請求項７に記載の方法。
10. 第１のビューおよび前記アトム・データベースを第１の実行可能プログラムに関連付け、第２のビューおよび前記アトム・データベースを第２の実行可能プログラムに関連付ける工程と、
    該第１のビューを利用して、該第１の実行可能プログラムによって、また該第２のビューを利用して、該第２の実行可能プログラムによって、該アトム・データベースからアトムをロードすることによって、該第１の実行可能プログラムと該第２の実行可能プログラムとで該アトムを共用する工程と、をさらに含む請求項１に記載の方法。
11. 前記アトムは前記第１の実行可能プログラムによってアクセス可能な第１メモリ・バッファへとロードされ、前記アトムは前記第２の実行可能プログラムによってアクセス可能な第２メモリ・バッファへとロードされる請求項１０に記載の方法。
12. 前記アトムは前記第１のビューを利用して前記第１の実行可能プログラムと、前記前記第２のビューを利用して前記第２の実行可能プログラムとの双方によってアクセス可能なメモリ・バッファへとロードされる請求項１０に記載の方法。
13. 前記変換オペレーションは前記アトムが動作するコンピュータ・ハードウェアおよび/またはソフトウェア・システムの最適化機能に基づいて規定される請求項１に記載の方法。
14. 前記変換オペレーションは前記アトムによって付与されるある機能へのアクセスを制限するために規定される請求項１に記載の方法。
15. 前記アトムはさらにアトム特性を備え、前記アトム変換オペレーションは該アトム特性を変化させる請求項１に記載の方法。
16. 前記１組の変換オペレーションは第１のアトムを第２のアトムに置き換えて、マッピング・テーブルが作成される修正オペレーションだけを含む請求項１に記載の方法。
17. 前記１組の変換オペレーションは仮想アトム・データベースに適用される請求項１に記載の方法。
18. 第１アトム・データベースと第２アトム・データベースへと変換するためのアトム変換オペレーションを生成する方法であって、
    a）標準型のアトム共用アルゴリズムを利用して、第１アトム・データベースと第２アトム・データベースとを標準化する工程であって、該第１アトム・データベースと該第２アトム・データベースとは各々、
    永続的に割り当てられたアトム識別子と、
    コンピュータ・コードおよび/またはデータと、
    他のアトムへのリファレンスと、を記憶する工程と、
    b）該第１アトム・データベースのアトムと該第２アトム・データベースのアトムとの間の１組のゴール・マージを特定する工程と、
    c）該第１アトム・データベースのアトムと該第２アトム・データベースのアトムとの間の該ゴール・マージを補助する１組のアシスト・マージを特定する工程と、
    d）１組のゴール・マージが空いていない間に、
    i）１組のアシスト・マージ内の最良のマージを選択する工程と、
    ii）該選択された最良のマージをコミットする工程と、
    iii）該１組のゴール・マージを更新する工程と、
    iv）該１組のアシスト・マージを更新する工程と、を反復する工程と、
    e）再利用マージではない、またはコミットされた再利用マージに関連がなかった各々のコミットされたマージをアンドゥする工程と、
    f）一意的な互換性があるマージが作成されたか否かを判定し、該一意的な互換性があるマージを該ゴール・マージに追加し、該一意的な互換性があるマージの１つに無限重みを割り当て、ステップc）に移る工程と、
    g）残された同一構造を特定するために、該第１アトム・データベースと該第２アトム・データベースとを利用して修正されたアトム共用アルゴリズムを適用する工程と、
    h）一意的な互換性があるマージが作成されたか否かを判定し、該一意的な互換性があるマージを該ゴール・マージに追加し、該一意的な互換性があるマージの１つに無限重みを割り当て、ステップc）に移る工程と、
    i）いずれかの互換性があるマージが作成されたか否かを判定し、最大の重みを有する該互換性があるマージをコミットし、該コミットされた互換性があるマージに無限の重みを割り当て、該コミットされた互換性があるマージを１組のゴール・マージに追加し、ステップc）に移る工程と、を含む方法。
19. 前記コミットされたマージの少なくとも１つは置換マージである請求項１８に記載の方法。
20. 前記コミットされたマージの少なくとも１つは挿入マージである請求項１８に記載の方法。
21. 前記コミットされたマージの少なくとも１つは削除マージである請求項１８に記載の方法。
22. アトム・データベースのビューを作成する装置であって、
    １組の変換オペレーションと、
    該変換オペレーションがランタイムで仮想的に適用された場合には、仮想データベースが作成され、該変換オペレーションが実際に適用された場合には、新たなアトム・データベースが作成されるように、１組の変換オペレーションを該アトム・データベースに適用するプロセッサと、を含み、
    該アトムは、
    永続的に割り当てられたアトム識別子と、
    コンピュータ・コードおよび/またはデータと、
    他のアトムへのリファレンスと、を含む装置。
23. アトム・データベースのビューを作成する装置であって、
    １組の変換オペレーションを規定する手段と、
    該変換オペレーションがランタイムで仮想的に適用された場合には、仮想データベースが作成され、該変換オペレーションが実際に適用された場合には、新たなアトム・データベースが作成されるように、１組の変換オペレーションを該アトム・データベースに適用する手段と、を含み、
    該アトムは、
    永続的に割り当てられたアトム識別子と、
    コンピュータ・コードおよび/またはデータと、
    他のアトムへのリファレンスと、を含む装置。
24. コンピュータ・プログラム製品であって、
    アトム・データベースのビューを作成するためのコンピュータが使用可能な媒体と、
    該コンピュータが使用可能な媒体上に組み込まれた１組のコンピュータ・プログラム命令であって、
    １組の変換オペレーションを規定し、かつ、
    該変換オペレーションがランタイムで仮想的に適用された場合には、仮想データベースが作成され、該変換オペレーションが実際に適用された場合には、新たなアトム・データベースが作成されるように、１組の変換オペレーションを該アトム・データベースに適用する命令と、を備え、
    該アトムは、
    永続的に割り当てられたアトム識別子と、
    コンピュータ・コードおよび/またはデータと、
    他のアトムへのリファレンスと、を含むコンピュータ・プログラム製品。

Images