本質的に、私はLispイメージが何であるかを知りたいですか? それは Lisp インタプリタと 1 つまたは複数のプログラムを含むメモリのスライスですか、それとも何ですか?
3 に答える
ダンプされたメモリとしての Lisp イメージ
通常、画像はファイルです。これは Lisp システムのメモリのダンプです。これには、Lisp システムのすべての関数 (多くの場合、マシン コードにコンパイルされます)、変数値、シンボルなどが含まれます。これは実行中の Lisp のスナップショットです。
イメージを作成するには、Lisp を起動し、それをしばらく使用してから、イメージをダンプします (これを行う関数の名前は実装によって異なります)。
Lisp イメージの使用
次に Lisp を再起動すると、ダンプされたイメージを使用して、ほぼ以前の状態に戻すことができます。イメージをダンプするとき、ダンプされたイメージが開始されたときに Lisp が何をすべきかを指定することもできます。そうすれば、サーバーに再接続したり、ファイルを再度開いたりすることができます。
このような Lisp システムを開始するには、カーネルとイメージが必要です。場合によっては、Lisp が両方を 1 つのファイルに入れることができるため、実行可能ファイルにはカーネル (いくつかのランタイム機能を含む) と画像データの両方が含まれます。
Lisp マシン (Lisp オペレーティング システムを実行しているコンピュータ) では、一種のブート ローダー (FEP、フロント エンド プロセッサ) がイメージ (「ワールド」と呼ばれる) をメモリにロードしてから、このイメージを起動します。この場合、カーネルはなく、コンピューター上で実行されているのはこの Lisp イメージだけです。この Lisp イメージには、すべての機能 (インタープリター、コンパイラー、メモリ管理、GC、ネットワーク スタック、ドライバーなど) が含まれています。基本的には、単一のファイル内の OS です。
一部の Lisp システムは、イメージをダンプする前にメモリを最適化します。ガベージ コレクションを実行したり、メモリ内のオブジェクトを並べ替えたりする場合があります。
画像を使用する理由
なぜ画像を使用するのでしょうか。物事をロードする時間を節約し、事前に構成された Lisp システムにアプリケーション コードとデータをユーザーに提供できます。保存されたイメージを使用して Common Lisp の実装を開始するのは、通常は高速です。現在のコンピューターでは数ミリ秒です。
Lisp イメージには多くの機能 (コンパイラ、開発環境、多くのデバッグ情報など) が含まれている可能性があるため、サイズは通常数メガバイトです。
Lisp で画像を使用することは、Smalltalk システムが行うことと非常によく似ています。たとえば、Squeak は、Smalltalk コードとデータのイメージ、およびランタイム実行可能ファイルも使用します。実際的な違いがあります: 現在のほとんどの Lisp システムは、コンパイルされたマシン コードを使用します。したがって、このイメージは、異なるプロセッサ アーキテクチャ (x86、x86-64、SPARC、POWER、ARM など) 間、さらにはオペレーティング システム間でも移植できません。
歴史
このような Lisp イメージは、長い間使用されてきました。たとえば、SYSOUT
1967 年からの BBN Lisp の関数は、そのようなイメージを作成しました。SYSIN
開始時にそのような画像を読み取ります。
画像を保存する関数の例
例については、LispWorks の関数save -imageを参照するか、コア イメージの保存に関するSBCLマニュアルを参照してください。
いくつかの言語実装は、現在のコンテキストにある「すべて」を格納するために「イメージ」を使用します。このイメージは、コンパイルのいくつかの抽象化レイヤー (つまり、中間解析レベル、中間バイト コード、ネイティブ op コード) である場合があります。このイメージをロードすると、すべてのソース ファイルをコンパイルするよりもはるかに高速になります。プログラムレベルでは、休止状態機能に非常によく似ています。
たとえば、あなたのlisp実装がイメージを使用する場合、まずあなた(またはコンパイラベンダー)がイメージをブートストラップし、それを保存します。
次に、2 つのオプションがあります。(1) Lisp を呼び出すたびに Lisp ファイルをロードするか、(2) すべての Lisp をロードしてイメージを保存し、このイメージを使用します。
それが役立つことを願っています
一般に、これはlispプロセスのストレージ部分(つまり、すべての「lisp」関数とデータ)ですが、基礎となるlispバイナリの部分はありません。プラス面としては、画像の読み込み時に(基本的に)簿記を行う必要がないため、起動が速くなり、すべてがそこにあります。一方、開いているファイル、ソケット、および何が不足しているのかを意味するため、ある種のチェックポインティングとして画像を保存するには、それを機能させるために少しの実装が必要になります。