JP2010108076A - ソースコード変換方法、サーバシステム、およびサーバプログラム - Google Patents

Abstract

【課題】ソースコードに対して、ＨＴＴＰリクエストのStringクラスへの変換処理におけるオーバーヘッドを削減したソースコードに、プログラマが作成したソースコードを自動変換する方法、サーバシステム、およびサーバプログラムを提供すること。
【解決手段】コンピュータを用いて、プログラムのソースコードをコード変換する方法を提供する。コード変換する方法は、文字列を保持する文字列型変数s=new String(b,“UTF-8”）を特定するステップと（ステップＳ２１０）、前記文字列型変数を、前記文字列を格納するバッファへの参照を保持する参照文字列型変数s=new String(bb)に変換するステップ（ステップＳ２２０）と、前記文字列型変数を前記参照文字列型変数に型変換した前記ソースコードを格納するステップと、を含む。
【選択図】図２

Description

本発明は、ソースコード変換方法に関する。特に、ＨＴＴＰリクエストを文字列型変数に変換する際のオーバーヘッドを削減したソースコードに変換する方法に関する。

従来、文字列を表現するために、Ｇｒｏｏｖｙ等のスクリプト開発環境、または、Ｊａｖａ（登録商標）、およびＣ＃（登録商標）等のいわゆる高級言語を用いるプログラム開発環境ではStringクラスが用意されている。このStringクラスには、以下の２つの特徴がある。
特徴１）Stringクラスは、多言語をサポートするために、文字列の表現にＵｎｉｃｏｄｅ文字を用い、また、文字コードのエンコーディングにＵＴＦ−１６を用いる。
特徴２）Stringクラスは、Ｉｍｍｕｔａｂｌｅオブジェクトを生成するクラスである。Ｉｍｍｕｔａｂｌｅとは、不変という意味であり、Ｉｍｍｕｔａｂｌｅ（不変）オブジェクトは、生成後に状態を変更することはできない。なお、以降、Ｊａｖａ、Ｃ＃については（登録商標）の注記を省略する。

Stringクラスは、ＪａｖａやＣ＃で書かれたプログラムによって構築されるＷｅｂサーバにて、クライアントから受信したＨＴＴＰリクエストを解析するために用いることができる。具体的には、ＨＴＴＰプロトコルに基づいてクライアントから受信したＨＴＴＰリクエストを、ＪａｖａやＣ＃で書かれたプログラムによって構築されるＷｅｂサーバが、受信したＨＴＴＰリクエストをStringクラスに変換し、メッセージを解析する。図１１を用いて、Ｊａｖａで書かれたＷｅｂサーバにおける、ＨＴＴＰリクエストをStringクラスに変換する処理について説明する。

図１１は、従来技術に係る、ＨＴＴＰリクエストのStringクラスへの変換処理を示す概要図である。白抜き矢印は、ＨＴＴＰリクエストの流れ、および処理の流れを表している。この変換処理は、変換処理を備えたＷｅｂサーバが、ＨＴＴＰリクエストを受信したことに応じて、処理が開始する。まず、クライアントから受信したＨＴＴＰリクエストは、一般的に、ｋｅｒｎｅｌからByteBufferオブジェクトbb１に読み込まれる。ByteBufferオブジェクトbb１は、ByteBufferクラス（Ｊａｖａ言語においては、java.nio.ByteBuffer）から変数名ｂｂとして生成されたByteBufferオブジェクトである。ＨＴＴＰリクエストは文字列をパーセントエンコーディングしたＵＴＦ−８であるので、ByteBufferオブジェクトbb１に読み込まれたＨＴＴＰリクエストはＵＴＦ−８であり、図１１に示すように１文字につき１バイト消費する。図１１において、便宜上、ByteBufferオブジェクトbb１に読み込まれたＨＴＴＰリクエストはＵＴＦ−８の文字コードではなく、文字で表わす。

次に、ByteBufferオブジェクトbb１に格納されたＨＴＴＰリクエストは、ＵＴＦ−８にエンコーディングされたbyte[]配列として、Stringクラスのコンストラクタに、渡される。このコンストラクタは、String(bb.array(),“UTF-8”)で表される。コンストラクタ内で、byte[]配列のＨＴＴＰリクエストは、ＵＴＦ−８からＵＴＦ−１６へ変換される。ＵＴＦ−１６へ変換されたＨＴＴＰリクエストはコピーされ、このコピーをchar[]配列４に変換しStringオブジェクトs２に格納される。Stringオブジェクトs２は、Stringクラス（Ｊａｖａ言語においては、java.lang.String）から変数名ｓとして生成されたStringオブジェクトである。char[]配列４はＵＴＦ−１６であるので、図１１に示すように１文字につき２バイト消費する。このようにして、Ｗｅｂサーバが受信したＨＴＴＰリクエストは、Stringクラスに変換される。

ところで、ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）等により動的コンテンツを生成する際の処理において、多言語に対応するために、ＪＳＰ内のテキストはＵＴＦ−１６に変換されている。そのため、ＨＴＴＰリクエストのStringクラスへの変換処理において、ＨＴＴＰリクエストをＵＴＦ−８からＵＴＦ−１６へ変換するのと同じように、ＪＳＰの実行に際して、ＪＳＰ内のテキストをＵＴＦ−１６からＵＴＦ−８へ変換している。ＪＳＰの実行に際して、ＪＳＰ内のテキストをＵＴＦ−１６からＵＴＦ−８へ変換することはオーバーヘッドとなっており、そのオーバーヘッドを削減する方法が開示されている（特許文献１）。

特開２００５−３３２１４６号公報

上述したＨＴＴＰリクエストのStringクラスへの変換処理の中には、以下の３つのオーバーヘッドが存在するという課題がある。

課題ａ）ByteBufferオブジェクトに格納されているＨＴＴＰリクエストのコピーによる、オーバーヘッドがある。Stringクラスから生成されるオブジェクトが「不変」であることを確実に保証するため、ByteBufferオブジェクトbbに格納されたＨＴＴＰリクエストは常に、コピーされ、コピーされたＨＴＴＰリクエストがchar[]配列に変換されてStringオブジェクトsに格納されるからである。

課題ｂ）ＨＴＴＰリクエストのＵＴＦ−８からＵＴＦ−１６へのエンコード変換による、オーバーヘッドがある。ＨＴＴＰリクエストは文字列をパーセントエンコーディングしたＵＴＦ−８である。一方、Stringクラスは多言語をサポートするために、文字コードのエンコーディングにＵＴＦ−１６を用いる。そのため、ＨＴＴＰリクエストのＵＴＦ−８からＵＴＦ−１６へのエンコード変換が必要であるからである。

課題ｃ）Stringオブジェクトにおいて文字列をＵＴＦ−１６として保持することによる、オーバーヘッドがある。ＨＴＴＰリクエストの多くはＡＳＣＩＩ文字（０ｘ００−０ｘ７ｆ）であるため、Stringオブジェクトに文字列をＵＴＦ−１６として格納することは、不要にメモリ消費する場合が多いためである。

ＨＴＴＰリクエストのStringクラスへの変換処理には、これら３つのオーバーヘッドが存在する。特許文献１には、ＪＳＰ内のテキストをＵＴＦ−１６からＵＴＦ−８へ変換することによるオーバーヘッドを削減する方法が記載されている。しかし、それでは、ＨＴＴＰリクエストのStringクラスへの変換処理における、課題ｂ）のオーバーヘッドしか削減することができない。

本発明は、ソースコードに対して、ＨＴＴＰリクエストのStringクラスへの変換処理におけるオーバーヘッドを削減したソースコードに自動変換する方法、サーバシステム、およびサーバプログラムを提供することを目的とする。

本発明は、上記課題に鑑み、以下のような解決手段を提供する。なお、本願明細書に記載の用語「サーバ装置」とは、文字列の受信に応答して、文字列に記述されている情報に応じて処理を行う装置であって、例えば、文字列がＨＴＴＰリスエスである場合には、サーバ装置はＷｅｂサーバである。

本発明は、プログラムの文字列操作におけるオーバーヘッドを削減するために、ソースコードを変換する方法を提供する。具体的には、文字列を直接的に保持する文字列型変数を、文字列を格納するバッファを参照することにより、間接的に文字列を保持参照文字列型変数に型変換したソースコードに変換する方法、およびサーバシステム、およびサーバプログラムを提供する。

本発明の１つの態様によると、コンピュータを用いて、プログラムのソースコードをコード変換する方法を提供する。コード変換する方法は、文字列を保持する文字列型変数を特定するステップと、特定した前記文字列型変数を、前記文字列を格納するバッファへの参照を保持する参照文字列型変数に型変換するステップと、前記文字列型変数を前記参照文字列型変数に型変換した前記ソースコードを格納するステップと、を含む。

本態様によると、文字列を保持する文字列型変数は、文字列を格納するバッファへの参照を保持する参照文字列型変数に型変換したソースコードに変換される。それにより、文字列型変数は、文字列に変わって参照（ポインタ）を保持することにより、文字列を格納するバッファから文字列型変数に文字列をコピーすることが無くなる。その結果、オーバーヘッドが削減される。

ここで、文字列型変数とは、文字を保持する変数であり、例えば、Ｊａｖａ言語においてはjava.lang.Stringクラス、Ｃ＃言語ではStringクラスである。バッファとは、プログラムが実行されている際に、データ、ここでは文字列を一時的に保存しておく記憶領域をいう。

また、本態様は、型変換するステップが、更に、バッファが「不変（Ｉｍｍｕｔａｂｌｅ）」であるか否かを判定するステップを含む。それにより、文字列型変数が「不変」であるという特徴を、型変換した参照文字列型変数も持つことができる。その結果、文字列型変数に文字列を保持しなくとも、「不変」という特徴は保たれ、オーバーヘッドが削減される。

本発明は、既存の技術と組み合わせることができ、そのように組み合わせた技術もまた、本発明の技術範囲に含まれる。更に、本発明の技法は、ソースコード変換方法の諸段階を、ＦＰＧＡ（現場でプログラム可能なゲートアレイ）、ＡＳＩＣ（特定用途向け集積回路）、これらと同等のハードウェアロジック素子、プログラム可能な集積回路、またはこれらの組み合わせが記憶し得るプログラムの形態、すなわちプログラム製品として提供し得る。具体的には、データ入出力、データバス、メモリバス、システムバス等を備えるカスタムＬＳＩ（大規模集積回路）の形態として、本発明に係るソースコード変換方法の実行手段、デバイス、組み込み装置等を提供でき、そのように集積回路に記憶されたプログラム製品の形態も、本発明の技術範囲に含まれる。

本発明によれば、ソースコードに対して、ＨＴＴＰリクエストのStringクラスへの変換処理におけるオーバーヘッドを削減したソースコードに自動変換する方法、サーバシステム、およびサーバプログラムを提供することができる。また、オーバーヘッドを削減したソースコードにより、ＨＴＴＰリクエストのStringクラスへの変換処理に要する時間を短縮することができる。

以下、本発明の実施形態について図を参照しながら説明する。これらはあくまでも一例であって、本発明の技術的範囲はこれらに限られるものではない。以下、文字列がＨＴＴＰリクエストである場合について説明する。なお、文字列は、ＨＴＴＰリクエストに限らず、文字列型変数に変換されるものであって、ＵＳ−ＡＳＣＩＩ文字の文字列であればよい。

本発明の一実施形態においては、ユーザが書いた任意のプログラム中に記述された、ＨＴＴＰリクエストをStringクラスに変換する処理（以下、簡略化のため変換処理とする）記述を含むソースコードを、本発明における課題であるａ）、ｂ）、ｃ）、３つのオーバーヘッドを削減したソースコードに自動的に変換する。具体的には、変換処理における３つのオーバーヘッドを削減したソースコードに変換するために、String(java.nio.ByteBuffer bb)を新設したStringクラスのコンストラクタを用いたソースコードに変換可能な条件を満たしているか判断する。判断した結果、条件を満たしている場合には、プログラマが作成したプログラムのソースコードに対して、String(java.nio.ByteBuffer bb)を新設したStringクラス（参照文字列型変数）のコンストラクタを用いたソースコードに変換する。

最初に、String(java.nio.ByteBuffer bb)について説明する。String(java.nio.ByteBuffer bb)は、Stringクラスのコンストラクタに新設される。このStringクラスは、従来のStringクラスとは異なり、次のような特徴を持つ。なお、以下区別するために、コンストラクタにString(java.nio.ByteBuffer bb)が新設されたコンストラクタを、String(ByteBuffer)コンストラクタとする。

特徴１）ByteBufferオブジェクトbb（バッファ）にＡＳＣＩＩ文字のみが含まれている場合は、Stringオブジェクトsの文字列保持を、Stringオブジェクトs内に文字列を保持せず、ByteBufferオブジェクトbbへのポインタを保持することで実現する。
特徴２）StringオブジェクトsがByteBufferオブジェクトbbへのポインタを保持している場合、Stringクラスのメソッドを経由して文字を取り出す際には、ポインタが指すByteBufferオブジェクトbbから必要な８ビット文字を読み出して、上位８ビットに００を付加してcharに変換して値を返す。詳細な処理については、後述する。
特徴３）StringオブジェクトsがByteBufferオブジェクトbbへのポインタを保持している場合、ＡＳＣＩＩ文字について保持している文字列とByteBufferオブジェクトbbに保持している文字列とは、いずれもＵＴＦ−８であって、同一エンコーディングである。そのため、従来、Stringオブジェクトsから文字列をbyte[]配列として取得する際に行っていた、String.getBytes(“UTF-8”)を用いたエンコーディング変換は行わない。

ＨＴＴＰリクエストは文字列をパーセントエンコーディングしたＵＴＦ−８であるので、ByteBufferオブジェクトbbに格納されたＨＴＴＰリクエストは必ずＵＳ−ＡＳＣＩＩ文字である。その事実を利用して、String(ByteBuffer)コンストラクタを用いることによって、Stringオブジェクトsを生成する際のＵＴＦ−８からＵＴＦ−１６への変換を無くすことができ、本発明における課題であるｂ）のオーバーヘッドを削減できる。また、String(ByteBuffer)コンストラクタを用いることによって、入力されたByteBufferオブジェクトbbへのポインタをStringオブジェクトsが保持することができる。その結果、ＵＴＦ−１６を用いて文字列を保存することを無くすことができるので、課題ｃ）で挙げたオーバーヘッドが削減できる。

上述したString(ByteBuffer)コンストラクタを用いることができるソースコードには条件がある。そのため、プログラマが作成したソースコードが、String(ByteBuffer)コンストラクタを用いたソースコードに変換可能であるか確認する必要がある。変更可能であるためには、ByteBufferオブジェクトbbに、ＨＴＴＰリクエストが書き込まれた後、ByteBufferオブジェクトbbの内容が変更されないこと、すなわち、ByteBufferオブジェクトbbが「不変」であることが条件である。この条件を満たすか否かは、以下の２つの方法で行うことができる。

方法１）コンパイラ・ツールによる構文解析を行う。解析のアルゴリズムについては、後述する。
方法２）プログラマが、アノテーション等によって、明示的に保証する。

ＨＴＴＰリクエストが格納されたByteBufferオブジェクトbbがStringオブジェクトsが使用される区間で、ByteBufferオブジェクトbbが「不変」であることが上述した２つの方法により、保証できた場合のみ、String(ByteBuffer)コンストラクタを用いてStringオブジェクトsを生成するソースコードへと、自動的に変換する。なお、上述した２つの方法のうち少なくとも１つにて、ByteBufferオブジェクトbbが「不変」であることが保証されればよい。

上記方法にて、ByteBufferオブジェクトbbが「不変」であることを保証することにより、Stringクラスが「不変」であることが保証される。その結果、Stringクラスから生成されるオブジェクトが「不変」であることを保証するためのStringクラスのインスタンス内のchar[]配列へのコピーの必要が無くすことができるので、課題ａ）で挙げたオーバーヘッドを削減できる。

ByteBufferオブジェクトbbが「不変」であることが保証されているソースコードに、コンストラクタにString(java.nio.ByteBuffer bb)が新設されたStringクラスを用いてStringオブジェクトsを生成することにより、課題ａ）ｂ）ｃ）で挙げたオーバーヘッドを削減することができる。

図１は、本発明の一実施形態に係る、ＨＴＴＰリクエストのStringクラスへの変換処理を示す概要図である。なお、図１に示す変換処理は、上述したString(ByteBuffer)コンストラクタを用いたソースコードによる変換処理である。白抜き矢印は、ＨＴＴＰリクエストの流れ、および処理の流れを表している。変換処理は、変換処理を備えたＷｅｂサーバが、ＨＴＴＰリクエストを受信したことに応じて、処理が開始する。まず、クライアントから受信したＨＴＴＰリクエストは、ｋｅｒｎｅｌからByteBufferオブジェクトbb１に読み込まれる。この処理は、図１１に示す従来技術と同様である。

次に、ByteBufferオブジェクトbb１は、StringクラスのString(ByteBuffer)コンストラクタに渡される。String(ByteBuffer)コンストラクタにて作成されたStringオブジェクトsは、ByteBufferオブジェクトbb１へのポインタ３を格納する。このようにすることで、ＨＴＴＰリクエストは、ＵＴＦ−８からＵＴＦ−１６へ変換されず、Stringオブジェクトs内のchar[]配列へのコピーもされず、StringオブジェクトsにＵＴＦ−１６としてＨＴＴＰリクエストを保持することもない。すなわち、本発明における課題であるａ）ｂ）ｃ）３つのオーバーヘッドの課題を解決することができる。

次に、図１にて概要図を示した変換処理を、フローチャートを用いて説明する。最初に、図１１にて概要図を示した、従来技術に係る変換処理のフローチャートについて説明する。図１２は、従来技術に係る、ＨＴＴＰリクエストのStringクラスへの変換処理のフローチャートである。
Ｓ１０：Ｗｅｂサーバがクライアントから受信したＨＴＴＰリクエストは、ＷｅｂサーバのｋｅｒｎｅｌからByteBufferオブジェクトbbに読み込まれる。
Ｓ２０：ByteBufferオブジェクトbbの内容をbyte[]配列として返すbb.array()を実行し、ByteBufferオブジェクトbbに格納されたＨＴＴＰリクエストをbyte[]配列に変換する。

Ｓ３０：ステップＳ２０でbyte[]配列に変換されたＨＴＴＰリクエストと、エンコードしたい形式としてのＵＴＦ−８とを引数として、Stringクラスのコンストラクタを呼び出す。
Ｓ４０：ステップＳ３０で呼び出されたStringクラスのコンストラクタにて、byte[]配列に変換されたByteBufferオブジェクトbbのＨＴＴＰリクエストをＵＴＦ−８からＵＴＦ−１６へ変換する。
Ｓ５０：ステップＳ４０でＵＴＦ−１６へ変換されたＨＴＴＰリクエストはコピーされ、このコピーをchar[]配列に変換し、Stringオブジェクトsに保持する。

次いで、本発明の一実施形態に係る変換処理のフローチャートを示す。図２は、本発明の一実施形態に係る、ＨＴＴＰリクエストのStringクラスへの変換処理のフローチャートである。
Ｓ１００：ＨＴＴＰリクエストを、ＷｅｂサーバのｋｅｒｎｅｌからByteBufferオブジェクトbbに読み込む。本処理は、図１２のステップＳ１０と同じである。
Ｓ１１０：ByteBufferオブジェクトbbを引数として、StringクラスのString(ByteBuffer)コンストラクタを呼び出す。
Ｓ１２０：ByteBufferオブジェクトbbに格納されているＨＴＴＰリクエストが、ＡＳＣＩＩ文字のみであるか判断する。判断結果がＹＥＳの場合には、ステップＳ１３０へ処理を移す。一方、判断結果がＮＯの場合には、図１のステップＳ２０に処理を移し、図１２に示す従来技術に係る変換処理を行う。
Ｓ１３０：ByteBufferオブジェクトbbへのポインタを取得し、Stringオブジェクトsに保持する。

続いて、プログラマが作成した、図１１、１２に示す従来技術に係る変換処理の記述が含まれているソースコードを、図１、２に示す本発明の一実施形態に係る変換処理の記述を含むソースコードに自動的に変換するアルゴリズムについて説明する。プログラマが作成したソースコードを、図１、２に示す変換処理の記述を含むソースコードに変換することにより、課題ａ）ｂ）ｃ）で挙げたオーバーヘッドを削減したソースコードとなる。

図３は、本発明の一実施形態に係る、オーバーヘッドを削減するソースコードに変換するアルゴリズムを示すフローチャートである。本アルゴリズムは、プログラマが書いたソースコード内にＨＴＴＰリクエストを保持するByteBufferオブジェクトbbを指定する記述がある場合に、下記の通りに動作する。ByteBufferオブジェクトbbの指定方法としては、プログラム中に記述する、外部から設定ファイルで与える等の方法がある。本アルゴリズムは、コンパイラが備え、コンパイラにより実行される。本アルゴリズムにより作成された、オーバーヘッドを削減するソースコードは、ハードディスク等の記憶手段に格納される。なお、オーバーヘッドを削減するソースコードではなく、オーバーヘッドを削減するソースコードがコンパイラによってコンパイルされた結果生成されるオブジェクトコード（コンピュータ上で実行可能な形式)を記憶手段に格納してもよい。

Ｓ２００：ByteBufferオブジェクトbbが、「不変」であることを保証するための条件を満たしているか判断する。ByteBufferオブジェクトbbが「不変」であることを保証するための条件を満たしていない場合には、処理は終了し、満たしている場合には、ステップＳ２１０へ処理を移す。ByteBufferオブジェクトbbが「不変」であることを保証するための条件については後述する。上述したように、本発明の一実施形態において、ＨＴＴＰリクエストは、Stringオブジェクトs内に、ＨＴＴＰリクエストを格納しているByteBufferオブジェクトbbへのポインタを保持することにより参照できる。そのため、Stringクラスが「不変」であるという条件を満たすためには、ByteBufferオブジェクトbbが「不変」でなければならないからである。

Ｓ２１０：bb.array()の戻り値(bとする)と、エンコードしたい形式としてのＵＴＦ−８を引数として、ＵＴＦ−１６に変換後の文字列を格納するStringオブジェクトを代入する変数（ｓとする）を代入先とした「ｓ=new String(b,“UTF-8”)」という代入文が検知できたか判断する。ここで、変数ｓは、Stringオブジェクトであり、上述しているStringオブジェクトsと同じである。代入文が検知できた場合には、ステップＳ２２０へ処理は移り、検知できなかった場合には処理は終了する。

Ｓ２２０：ステップＳ２１０で検知した「s=new String(b,"UTF-8")」の直後に、「s=new String(bb)」という代入文を生成する。
Ｓ２３０：ステップＳ２１０で検知した「s=new String(b,"UTF-8")」を削除する。
Ｓ２４０：ステップＳ２３０で削除した「s=new String(b,"UTF-8")」の引数のうち、プログラム中で使用されていない変数に関する代入文を削除する。

ByteBufferオブジェクトbbが「不変」であることを保証するための条件について説明する。ここでは、ByteBufferオブジェクトbbが「不変」であることを保証するための方法のうち、方法１）のコンパイラ・ツールにより解析を行う方法における条件について説明する。コンパイラ・ツールは、ユーザによってプログラム中に記述された、ＨＴＴＰリクエストが格納されるByteBufferオブジェクトbbについて、メソッド中でByteBufferオブジェクトbbの値が生成されてから使用されなくなるまでの範囲において、以下の５つの条件の全てを満たしているかどうか解析する。

この５つの条件全てが満たされていれば、ByteBufferオブジェクトbbにSocketChannel.read()によって値（ＨＴＴＰリクエスト）が書き込まれてから使用が終了するまで値が書き換えられることがない。そのため、Stringオブジェクトsの中で、コンストラクタに渡されたByteBufferオブジェクトbbへのポインタを保持し続けることによって、Stringオブジェクトに文字列を保持しなくとも、Stringオブジェクトの「不変」は保証される。

条件１）ByteBufferオブジェクトbbがインスタンス変数、または、クラス変数に代入されていない。
条件２）ByteBufferオブジェクトbbがメソッドの返値となっていない。
条件３）ByteBufferオブジェクトbbが、SocketChannel.read(ByteBuffer)メソッド以外の、メソッド呼び出しの引数、となっていない。
条件４）ByteBufferオブジェクトbbが、SocketChannel.read(ByteBuffer)で参照された後、左辺に現れない。
条件５）ByteBufferオブジェクトbbが、SocketChannel.read(ByteBuffer)で参照された後、bb.put()、bb.put*()メソッドが呼ばれていない。

条件４）に示す、ByteBufferオブジェクトbbが左辺に現れないとは、ByteBufferオブジェクトbbの内容が書き換えられないということを示している。なお、ByteBufferオブジェクトbbが左辺に現れた場合、その直前までを解析対象としてもよい。また、条件５）に示す、bb.put*()とは、bb.putChar(int index,char value)等のputから始まるメソッドを意味する。bb.put()、bb.put*()メソッドが呼ばれていないとは、すなわち、ByteBufferオブジェクトbbの内容を書き換えるメソッドが呼ばれておらず、ByteBufferオブジェクトbbの内容が書き換えられないということを示している。

なお、ByteBufferオブジェクトbbがＯｂｊｅｃｔ Ｐｏｏｌｉｎｇを利用している場合、ByteBufferオブジェクトbbをＰｏｏｌから取り出すメソッドが呼ばれてからＰｏｏｌに返却するメソッドが呼ばれるまでの範囲が解析対象となる。この２つのメソッドは、プログラムで使われているＯｂｊｅｃｔ Ｐｏｏｌｉｎｇの仕様より、コンパイラ・ツールはｋｎｏｗｎであるとする。ここで、Ｏｂｊｅｃｔ Ｐｏｏｌｉｎｇとは、生成したオブジェクトをプール（Ｐｏｏｌ）に蓄積しておき、必要になった際にプールからオブジェクトを取り出して利用し、不要になった際にはオブジェクトをプールに戻すことである。Ｏｂｊｅｃｔ Ｐｏｏｌｉｎｇを用いることは、利用する度にオブジェクトを生成する方法に比べ、速度が速いという利点がある。

また、ByteBufferオブジェクトbbがＯｂｊｅｃｔ Ｐｏｏｌｉｎｇを利用している場合、上記の条件１）から条件５）によるソースコードの静的解析だけではStringオブジェクトの「不変」を保証できないので、Stringオブジェクトと共有されているByteBufferクラスへの書き込みがあった場合に、内容を保持するByteBufferオブジェクトを新規に作成するＣｏｐｙ−Ｏｎ−Ｗｒｉｔｅメカニズムを導入して、Stringオブジェクトの「不変」を保証する。ただし、Ｃｏｐｙ−Ｏｎ−Ｗｒｉｔｅメカニズムを導入して、Stringオブジェクトの「不変」を保証する必要があるのは、Stringオブジェクトが使用される区間内に、ByteBufferオブジェクトbbがプールに戻される場合である。

ここで、Ｃｏｐｙ−Ｏｎ−Ｗｒｉｔｅメカニズムとは、オブジェクトの複製を要求された際には、コピーをした振りをして、とりあえず原本をそのまま参照させ、原本またはコピーのどちらかに書き込みが行われようとした際に、それを検出し、その時点で初めて新たな空き領域を探して割り当て、コピーを実行する技術である。

図３に示したフローチャートを用いて、コード変換するサーバシステムにおける各手段について説明する。特定手段は、図３のステップＳ２１０処理、すなわち、ソースコードからStringオブジェクトを代入する変数（ｓ）を代入先とした「ｓ=new String(b,“UTF-8”)」という代入文を検知する処理を行う。変換手段は、図３のステップＳ２２０およびＳ２３０の処理、すなわち、特定手段にて検知した代入文「ｓ=new String(b,“UTF-8”)」を、代入文「s=new String(bb)」に変換する。格納手段は、変換手段にて、代入文「s=new String(bb)」に変換されたソースコードを、ハードディスク等の記憶手段に格納する。

ここで、コンストラクタにString(java.nio.ByteBuffer bb)を新設したStringクラスの特徴の１つである、StringオブジェクトsがByteBufferオブジェクトbbへのポインタを保持している場合の、Stringクラスのメソッドを経由して文字を取り出す処理について説明する。図４は、本発明の一実施形態に係る、ByteBufferオブジェクトbbへポインタを保持するStringオブジェクトsにおける、文字取得処理のフローチャートである。

Ｓ３００：StringオブジェクトsにByteBufferオブジェクトbbへのポインタが保持されているか判断する。ポインタが保持されている場合には、処理をステップＳ３１０へ移し、保持されていない場合には、Stringオブジェクトs内にchar[]配列が保持されているので、char[]配列を取得し、戻り値として返す。
Ｓ３１０：Stringオブジェクトsに保持されているポインタが示すByteBufferオブジェクトbbから、必要な８ビット文字を読み出す。
Ｓ３２０：ステップＳ３１０にて読み出した８ビット文字の上位８ビットに００を付加して、char[]配列に変換する。
Ｓ３３０：戻り値として、ステップＳ３２０にて変換されたchar[]配列を返す。

このようにして、StringオブジェクトsがByteBufferオブジェクトbbへのポインタを保持している場合において、ByteBufferオブジェクトbbから文字を取り出すことができる。

図５は、本発明の一実施形態に係るStringクラスの実装を示す図である。図５を用いて、本発明の実装の詳細について説明する。まず、コンストラクタにString(java.nio.ByteBuffer bb)が新設されたStringクラスの例を、Java言語のjava.lang.Stringクラスを用いて示す。図５では、java.lang.Stringクラスの内部で使われるフィールドと、代表的なメソッドとして文字列を設定するjava.lang.Stringクラスのコンストラクタ（String(ByteBuffer)コンストラクタ）、java.lang.Stringの文字列から１文字取り出すcharAt()メソッド、用意したbyte[]配列にjava.lang.Stringの文字列をコピーするgetBytes()メソッド、を示す。

String(ByteBuffer)コンストラクタ１０では、入力されたByteBufferオブジェクトbbが指す文字列を検査し、もし０ｘ８０以上の文字が含まれていた場合には通常のＵＴＦ−１６表現で文字列を保持する。それ以外の場合は、入力されたByteBufferオブジェクトbbを保持する。charAt()メソッド１１では、ByteBufferオブジェクトbbがそのまま保持されていた場合、ByteBufferオブジェクトbbから必要な８ビット文字を読み出して、上位８ビットに００を付加してcharに変換して値を返す。getBytes()メソッド１２では、ByteBufferオブジェクトbbがそのまま保持されていた場合、ByteBufferオブジェクトbbが指す文字列はＵＴＦ−８であるので、そのままbyte[]配列にコピーする。

次に、Ｃｏｐｙ−Ｏｎ−Ｗｒｉｔｅについて、Ｊａｖａ言語のjava.nio.ByteBufferクラスの例を用いて説明する。ByteBufferオブジェクトが保持するバッファの内容を変更するメソッドが呼ばれたときにＣｏｐｙ−ｏｎ−ｗｒｉｔｅが必要であるかどうかを示す、SoftReferenceクラスのsrefフィールドを、ByteBufferクラスに追加する。ここで、バッファとは、プログラムが実行されている際のデータのやり取り時に、処理速度や転送速度の差を補うためにデータを一時的に保存しておく記憶領域のことをいう。

まず、String(ByteBuffer bb,int,int)の中で、byte[]配列でデータを保持すると決定した場合、bb.duplicate()した値をvalue１３として、Stringクラスに保存する。そして、そのvalue１３を参照する新しいソフト参照（SoftReference）を作成し、bb.srefに代入する。ByteBufferオブジェクトが保持するバッファの内容が変更されると、このbb.srefを利用してＣｏｐｙ−ｏｎ−ｗｒｉｔｅが必要であるかどうか判断する。具体的には、ByteBufferオブジェクトが保持するバッファの内容を変更するメソッド（例えばput()メソッド等）で以下の処理を行う。

１）bb.sref＝ｎｕｌｌであれば、StringオブジェクトはByteBufferオブジェクトが保持するバッファの内容を参照していないので、通常の処理を行う。
２）bb.sref.get()＝ｎｕｌｌであれば、すでにStringオブジェクトはガベージコレクション（ｇａｒｂａｇｅ ｃｏｌｌｅｃｔｉｏｎ；ＧＣ）されているので、通常の処理を行う。ここで、ガベージコレクション（ＧＣ）とは、プログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である。
３）bb.sref.get()！＝ｎｕｌｌであれば、新しいバッファを確保してこれまでのバッファの内容をコピーする。

図６は、本発明の一実施形態に係る、ByteBufferオブジェクトが保持するバッファの内容が変更される前に、StringがＧＣされた場合のＣｏｐｙ−ｏｎ−ｗｒｉｔｅの動作概要を示す図である。図６（ａ）は、ByteBufferオブジェクトとバッファとの関係図を示す。String(ByteBuffer bb)の中で、byte[]配列でデータを保持する場合には、ByteBufferオブジェクトbb１００が参照するバッファ２００の内容を、文字列の値として使用する。ここで、バッファ２００は、ｋｅｒｎｅｌからByteBufferオブジェクトbb１００に読み込まれたデータを保持するために、ByteBufferオブジェクトbb１００が内部的に使用するbyte[]配列である。

図６（ｂ）は、バッファ２００の内容を参照するStringオブジェクトの関係図を示す。String(ByteBuffer bb)の中で、バッファ２００の内容を参照するために、bb.duplicate()した値を、Stringオブジェクトsに保存する。そして、bb.duplicate()した値を参照するSoftReference１１０を作成し、bb.srefに代入する。具体的には、ByteBufferオブジェクトbb１００をｓｈａｌｌｏｗ ｃｏｐｙし、ByteBufferオブジェクトｓ_ｂｂ１０１を作成し、Stringオブジェクトs１２０にByteBufferオブジェクトｓ_ｂｂ１０１を参照させる。それにより、Stringオブジェクトs１２０は、ByteBufferオブジェクトｓ_ｂｂ１０１が参照するバッファ２００の内容を文字列の値として使用することができる。Stringオブジェクトs１２０に、ByteBufferオブジェクトｓ_ｂｂ１０１を参照させた後、ByteBufferオブジェクトｓ_ｂｂ１０１を参照するSoftReference１１０を作成する。SoftReference１１０により、ByteBufferオブジェクトbb１００とByteBufferオブジェクトｓ_ｂｂ１０１とを関連付けることができる。

図６（ｃ）は、Stringオブジェクトs１２０が変更される前に、Stringオブジェクトs１２０がＧＣされた場合の関係図である。Stringオブジェクトs１２０がＧＣされると、SoftReference１１０の持つ値がｎｕｌｌになる。このとき、バッファ２００はStringオブジェクトs１２０から参照されていないので、バッファ２００の内容を変更することができる。

図７は、本発明の一実施形態に係る、StringオブジェクトがＧＣされる前に、バッファの内容が変更された場合のＣｏｐｙ−ｏｎ−ｗｒｉｔｅの動作概要を示す図である。図７（ａ）、（ｂ）は図６と同様である。図７（ｃ）は、Stringオブジェクトs１２０がＧＣされる前に、バッファ２００の内容が変更された場合の関係図である。SoftReference１１０の持つ値がｎｕｌｌでない場合には、Stringオブジェクトs１２０がＧＣされていないため、バッファ２００の内容を変更してしまうと、Stringオブジェクトs１２０の「不変」が保たれなくなる。そこで、Ｃｏｐｙ−Ｏｎ−Ｗｒｉｔｅのメカニズムを用いて、バッファ２００の内容がコピーされる。コピーされたバッファ２０１をByteBufferオブジェクトbb１００が保持し、ByteBufferオブジェクトｓ_ｂｂ１０１とのSoftReference１１０が消滅する。このようにして、Stringクラスの「不変」が保持される。

最後に、本発明の一実施形態の適用例について述べる。図８に、簡単なサーバソースコードの例を示す。図８に示した簡単なサーバソースコードの処理について説明する。８０番ポートからByteBufferオブジェクトbbにＨＴＴＰリクエストのデータを読み込むと処置が開始する。まず、ByteBufferオブジェクトbbに読み込まれたＨＴＴＰリクエストを、ＵＴＦ−８からＵＴＦ−１６へ変換し、ＵＴＦ−１６に変換されたＨＴＴＰリクエストを保持するStringオブジェクトsを生成する。次に、生成されたStringオブジェクトsが保持するＵＴＦ−１６に変換されたＨＴＴＰリクエストのパーセントエンコーディングをデコードする。最後に、デコードされたＨＴＴＰリクエストを、標準出力に書き出し、処理を終了する。

まず、プログラマが、「ByteBuffer bb=ByteBuffer.allocateDirect(8192);」のByteBufferオブジェクトbbを指定している記述を見つける。次にByteBufferオブジェクトbbが書き換えられることがないか上述した条件を満たすかチェックを行う。図８に示されたソースコード内のByteBufferオブジェクトbbは、bb.array()メソッドしか呼んでいない、インスタンス変数・クラス変数に代入されていない、SocketChannel.read()メソッドでのみ引数となっている、メソッドの返値となっていない、のでbbがSocketChannel.read()メソッドで値が書き込まれてからは値が書き換えられることがない。従って、bbを本発明の一実施形態に係る新設のString(ByteBuffer)コンストラクタに渡すことができるので、サーバソースコードを本発明における課題であるａ）ｂ）ｃ）３つのオーバーヘッドを削減するソースコードに変換することができる。

図８に示したサーバソースコードは、図３に示したアルゴリズムに従って、図９のように書き換えることができ、変換処理におけるａ）、ｂ）、ｃ）のオーバーヘッドを削減できる。なお、Ｊａｖａ言語の仕様を満たすためにString(ByteBuffer)コンストラクタは非ｐｕｂｌｉｃとしているので、実際にはリフレクション等を用いて、String(ByteBuffer)コンストラクタを呼び出す必要がある。

本発明は、プログラムがStringとして表現するバッファの内容が１バイトで表現できるもののみであったときに、本発明の一実施形態に係る変換処理を行い、その他の場合は従来技術に係る変換処理を行うものである。このため、パーセントエンコーディングで表現できないデータがあった場合には、従来技術で変換処理が行われる。もし、パーセントエンコーディングで表現できないＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）として正しくない文字（例えば０ｘｆｆ）がユーザが指定したＨＴＴＰリクエストが格納されたバッファに存在した場合には、図５に示すように、String(ByteBuffer bb,int start,int length)メソッドの「value=StringCoding.decode(bb.array(),start,length);」が実行され、従来技術に係る変換処理でStringオブジェクトが生成され、バッファの内容を失うことなく本発明を適用しない結果と同じStringオブジェクトが得られる。

また、ＰＯＳＴコマンド等によって、ＨＴＴＰメッセージにメッセージボディ（ｒｆｃ２６１６）が存在した場合も、例えばユーザが指定したＨＴＴＰリクエストが格納されたバッファに０ｘｆｆが存在した場合には、図５に示すように、String(ByteBufferbb,int start,int length)メソッドの「value=StringCoding.decode(bb.array(),start,length);」が実行され、従来技術に係る変換処理でStringオブジェクトが生成され、バッファの内容を失うことなく本発明を適用しない結果と同じStringオブジェクトが得られる。

図１０は、本発明の一実施形態に係る、オーバーヘッドを削減するソースコードに変換するサーバ装置のハードウェア構成を示す図である。図１０においては、オーバーヘッドを削減するソースコードに変換する装置を情報処理装置１０００とし、そのハードウェア構成を例示する。以下は、コンピュータを典型とする情報処理装置として全般的な構成を説明するが、その環境に応じて必要最小限な構成を選択できることはいうまでもない。

情報処理装置１０００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、パラレルポート１０８０、ＵＳＢポート１０９０、グラフィック・コントローラ１０２０、ＶＲＡＭ１０２４、音声プロセッサ１０３０、Ｉ／Ｏコントローラ１０７０、ならびにキーボードおよびマウス・アダプタ１１００等の入力手段を備える。Ｉ／Ｏコントローラ１０７０には、フレキシブル・ディスク（ＦＤ）ドライブ１０７２、ハードディスク１０７４、光ディスク・ドライブ１０７６、半導体メモリ１０７８等の記憶手段を接続することができる。

音声プロセッサ１０３０には、マイクロホン１０３６、増幅回路１０３２、およびスピーカ１０３４が接続される。また、グラフィック・コントローラ１０２０には、表示装置１０２２が接続されている。

ＢＩＯＳ１０６０は、情報処理装置１０００の起動時にＣＰＵ１０１０が実行するブートプログラムや、情報処理装置１０００のハードウェアに依存するプログラム等を格納する。ＦＤ（フレキシブル・ディスク）ドライブ１０７２は、フレキシブル・ディスク１０７１からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハードディスク１０７４に提供する。図１０には、情報処理装置１０００の内部にハードディスク１０７４が含まれる例を示したが、バスライン１００５またはＩ／Ｏコントローラ１０７０に外部機器接続用インタフェース（図示せず）を接続し、情報処理装置１０００の外部にハードディスクを接続または増設してもよい。

光ディスク・ドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この際は各ドライブに対応した光ディスク１０７７を使用する必要がある。光ディスク・ドライブ１０７６は光ディスク１０７７からプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハードディスク１０７４に提供することもできる。

情報処理装置１０００に提供されるコンピュータプログラムは、フレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカード等の記録媒体に格納されて利用者によって提供される。このコンピュータプログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、または通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、情報処理装置１０００にインストールされ実行される。コンピュータプログラムが情報処理装置に働きかけて行わせる動作は、既に説明した装置における動作と同一であるので省略する。

前述のコンピュータプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としてはフレキシブル・ディスク１０７１、光ディスク１０７７、またはメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープ媒体を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハードディスクまたは光ディスク・ライブラリ等の記憶装置を記録媒体として使用し、通信回線を介してコンピュータプログラムを情報処理装置１０００に提供してもよい。

以上の例は、情報処理装置１０００について主に説明したが、コンピュータに、情報処理装置で説明した機能を有するプログラムをインストールして、そのコンピュータを情報処理装置として動作させることにより上記で説明した情報処理装置と同様な機能を実現することができる。

本装置は、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアの組み合わせによる実施では、所定のプログラムを有するコンピュータ・システムでの実施が典型的な例として挙げられる。係る場合、該所定のプログラムが該コンピュータ・システムにロードされ実行されることにより、該プログラムは、コンピュータ・システムに本発明に係る処理を実行させる。このプログラムは、任意の言語、コード、または表記によって表現可能な命令群から構成される。そのような命令群は、システムが特定の機能を直接実行すること、または（１）他の言語、コード、もしくは表記への変換、（２）他の媒体への複製、のいずれか一方もしくは双方が行われた後に、実行することを可能にするものである。もちろん、本発明は、そのようなプログラム自体のみならず、プログラムを記録した媒体を含むプログラム製品もその範囲に含むものである。本発明の機能を実行するためのプログラムは、フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク装置、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ可読媒体に格納することができる。係るプログラムは、コンピュータ可読媒体への格納のために、通信回線で接続する他のコンピュータ・システムからダウンロードしたり、他の媒体から複製したりすることができる。また、係るプログラムは、圧縮し、または複数に分割して、単一または複数の記録媒体に格納することもできる。

以上、本発明を実施形態に則して説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態または実施例に記載されたものに限定されるものではない。

本発明の一実施形態に係る、ＨＴＴＰリクエストのStringクラスへの変換処理を示す概要図である。 本発明の一実施形態に係る、ＨＴＴＰリクエストのStringクラスへの変換処理のフローチャートである。 本発明の一実施形態に係る、オーバーヘッドを削減するソースコードに変換するアルゴリズムを示すフローチャートである。 本発明の一実施形態に係る、ByteBufferオブジェクトbbへポインタを保持するStringオブジェクトsにおける、文字取得処理のフローチャートである。 本発明の一実施形態に係る、Stringクラスの実装を示す図である。 本発明の一実施形態に係る、ByteBufferオブジェクトが保持するバッファの内容が変更される前に、StringがＧＣされた場合のＣｏｐｙ−Ｏｎ−Ｗｒｉｔｅの動作概要を示す図である。 本発明の一実施形態に係る、StringオブジェクトがＧＣされる前に、バッファの内容が変更された場合のＣｏｐｙ−Ｏｎ−Ｗｒｉｔｅの動作概要を示す図である。 サーバプログラム例を示す図である。 オーバーヘッドを削減するソースコードに変換されたサーバプログラム例を示す図である。 本発明の一実施形態に係る、オーバーヘッドを削減するソースコードに変換するサーバ装置のハードウェア構成を示す図である。 従来技術に係る、ＨＴＴＰリクエストのStringクラスへの変換処理を示す概要図である。 従来技術に係る、ＨＴＴＰリクエストのStringクラスへの変換処理のフローチャートである。

符号の説明

１ ByteBufferオブジェクトbb
２ Stringオブジェクトs
３ ポインタ
４ char[]配列

Claims (9)

1. コンピュータを用いて、プログラムのソースコードをコード変換する方法であって、
   文字列を保持する文字列型変数を特定するステップと、
   特定した前記文字列型変数を、前記文字列を格納するバッファへの参照を保持する参照文字列型変数に型変換するステップと、
   前記文字列型変数を前記参照文字列型変数に型変換した前記ソースコードを格納するステップと、
   を含む、コード変換する方法。
2. 前記型変換するステップは、更に、前記バッファが不変であるか否かを判定するステップを含む、請求項１に記載の方法。
3. 前記判定するステップは、コンパイラが、前記ソースコードに対し構文解析をして得られた情報に基づいて、判定する、請求項２に記載の方法。
4. 前記型変換するステップは、更に、
   前記判定が真である場合は、前記参照文字列型変数への型変換を実行し、
   さもなければ前記参照文字列型変数への型変換を実行しない、請求項２に記載の方法。
5. 参照文字列型変数は、前記文字列がＡＳＣＩＩ文字列である場合には、前記文字列を格納するバッファへの参照を保持し、
   さもなければ、前記文字列を保持する、請求項１に記載の方法。
6. 前記文字列が、ＨＴＴＰリクエストである請求項１に記載の方法。
7. サーバ装置を用いて、文字列の受信に応答して受信した前記文字列の表現を変更するプログラムのソースコードを、コード変換するサーバプログラムであって、
   コンピュータが
   前記文字列を保持する文字列型変数を特定するステップと、
   特定した前記文字列型変数を、前記文字列を格納するバッファへの参照を保持する参照文字列型変数に型変換するステップと、
   前記文字列型変数を前記参照文字列型変数に型変換した前記ソースコードを格納するステップと、
   を実行する、サーバプログラム。
8. 文字列の受信に応答して、受信した前記文字列の表現を変更するプログラムのソースコードを、コード変換するサーバシステムであって、
   前記文字列を保持する文字列型変数を特定する特定手段と、
   特定した前記文字列型変数を、前記文字列を格納するバッファへの参照を保持する参照文字列型変数に型変換する変換手段と、
   前記文字列型変数を前記参照文字列型変数に型変換した前記ソースコードを格納する格納手段と、
   を含む、サーバシステム。
9. サーバ装置を用いて、ＨＴＴＰリクエストの受信に応答して、受信した前記ＨＴＴＰリクエストの表現を変更するプログラムのソースコードを、コード変換するサーバプログラムであって、
   コンピュータが
   前記ＨＴＴＰリクエストを保持する文字列型変数を特定するステップと、
   特定した前記文字列型変数を、前記ＨＴＴＰリクエストを格納するバッファへの参照を保持する参照文字列型変数に型変換するステップと、
   前記文字列型変数を前記参照文字列型変数に型変換した前記ソースコードを格納するステップと、を含み、
   更に、前記バッファが不変であるか否かを判定するステップを含み、
   前記判定が真である場合は、前記参照文字列型変数への型変換を実行し、
   さもなければ前記参照文字列型変数への型変換を実行せず、
   前記参照文字列型変数は、前記ＨＴＴＰリクエストがＡＳＣＩＩ文字列でない場合には、前記ＨＴＴＰリクエストを保持する、サーバプログラム。

Images