JP5818695B2 - コード変換方法、プログラム及びシステム - Google Patents

Description

この発明は、１つのプログラミング言語で書かれたコードを、別のプログラミング言語のコードに変換する技法に関し、より詳しくは、変換後のコードのディスパッチ、すなわち、オペレーティングシステムに実行させることの高速化と安定化に関するものである。

プログラミング言語において、総称型(generics)の実装には、型具体化(reification)を基本とするものと、型消去(erasure)を基本とするものがある。そこで、型具体化とは、総称型を型パラメータの値に特化した専用の型にコンパイルする手法である。これを採用する代表的な言語としてC++やX10がある。なお、X10の特徴や言語仕様等については、http://x10-lang.org/などを参照されたい。

型消去とは、総称型を型パラメータを取り除いた共通の型にコンパイルする手法である。これを採用する代表的な言語はJava(R)やScalaである。型消去では型パラメータは、コンパイル時にチェックされた後取り除かれるため、実行時に型パラメータの値を参照することができない。したがって型パラメータの実行時の値(実行時型情報)に依存するディスパッチ等の機能を実装することが出来ず、記述力は型具体化のサブセットである。したがって型具体化に基づく総称型を採用する言語を、型消去に基づくJava(R)の総称型に変換するには、何らかの形で実行時型情報を表現する必要がある。

ディスパッチに関しては、通常のメソッドについては、型情報をメソッド名にエンコードする名前修飾(name mangling)手法が用いられる。これはJava(R)のディスパッチが使えるため、高速なディスパッチが可能である。また変換対象メソッドの引数の型だけで変換結果が決まるため、他の変更の影響を受けない安定な変換が可能である。

一方、コンストラクタは、名前を自由に変えることができないため、型情報をコンストラクタの引数にエンコードする引数修飾(parameter mangling)手法が用いられる。

従来より、X10のソースコードをJava(R)のソースコードあるいはバイトコードに変換してコンパイルすることが行われている。このとき従来技術では、X10で、変換対象コンストラクタの、同じクラスのコンストラクタ間の実装順序(0番目,1番目,…)を、通常コンストラクタの引数に現れない型の多次元配列の次元数にエンコードし、その型のダミー引数を追加している。これはJava(R)のディスパッチが使えるため高速なディスパッチが可能である。しかしながらコンストラクタの実装順序という相対的な値に基づくため、同じクラスの他のコンストラクタの追加・削除により変換結果が変わる不安定性がある。これはコンパイル済ライブラリをバイナリ形式で提供したり、X10コンパイラが生成したJava(R)コードを呼び出す外部(非X10)Javaコードを記述したりする際に問題となる。

クラスのコンストラクタの処理に関して、下記のような従来技術が知られている。

特開平９−１９０３４９号公報は、プログラムの実行速度を向上させるために、Ｃ＋＋で記述されたソースプログラムの最適化が可能なクラスを決定し、そのクラスのメンバ関数を中間表現に翻訳した後、Ｃ＋＋で記述されたコード生成ルーチンを生成し、生成されたコード生成ルーチンをコンストラクタに埋め込み、全てのクラスの最適化が終了したか否かを判別し、終了したと判別した場合は処理を完了することを開示する。

２０００−２５０７５５号公報は、アプリケーションソースファイルを解析して、適応クラスを識別するための所定のキーワードを検出し、適応クラスが適応ソフトウェアメソッドを含み、適応クラスの第１のインスタンスを生成するときに、適応ソフトウェアメソッドの多数のインプリメンテーションの１つを動的に選択するセレクタを生成させる第１の命令セットをアプリケーションソースファイルに挿入することによって、適応クラスのコンストラクタを拡張することを開示する。

しかし、これらの従来技術は、型具体化を基本とするプログラミング言語で書かれたコードを、型消去を採用するプログラミング言語のコードに変換した際のディスパッチの不安定さに対する解決を与えるものではない。

WebSphere(R) eXtreme Scale (ftp://public.dhe.ibm.com/software/webserver/appserv/library/v71/711_prog_pdf.pdf) では、コンストラクタの定義順(0から始まる連続の整数)と等しい数のダミー引数を追加する引数修飾の技法が採用されている。しかし、その技法においては、コンストラクタの定義順は相対値であり、他のコンストラクタの追加順序により変わりうるため、安定なディスパッチが出来ないという問題がある。また、複数のダミー引数を用いるのはスタックを無駄にし効率が悪い。

また、既存のX10では、コンストラクタの定義順(0から始まる連続の整数)と等しい次元の多次元配列型のダミー引数を追加する引数修飾技法が採用されている。この場合、コンストラクタの定義順は相対値であり、他のコンストラクタの追加・削除により変わりえるため、やはり安定なディスパッチが出来ないという問題がある。

さらに、X10における別の既存技法として、実行時型情報を引数として渡し、その値に基づきセルフ・ディスパッチする技法があるが、この場合、ＪＶＭのディスパッチが使えないので、ディスパッチが遅くなる。

特開平９−１９０３４９号公報 ２０００−２５０７５５号公報

http://x10-lang.org/ ftp://public.dhe.ibm.com/software/webserver/appserv/library/v71/711_prog_pdf.pdf

従って、この発明の目的は、型具体化を基本とするプログラミング言語で書かれたコードを、型消去を採用するプログラミング言語のコードに変換した結果のコードのディスパッチの高速性と安定性を達成する技法を提供することにある。

この発明は、上記課題を解決するためになされたものであり、型具体化を基本とする第１のプログラミング言語の通常メソッドの名前修飾(name mangling)のためのサフィックスを名前とする合成(synthetic)クラスを追加し、コンストラクタ定義に合成クラスの型のダミー引数を追加し、コンストラクタ呼び出しにダミー引数の型に適合する適当な値（通常はnull）を追加して、型消去を採用する第２のプログラミング言語のコードに変換する機能をもつプログラムによって実現される。

型具体化を基本とする第１のプログラミング言語とは好適にはX10であり、型消去を採用する第２のプログラミング言語とは好適にはJava(R)である。

この発明によれば、ダミー引数の型に実行時情報をエンコードすることにより、Java(R)のような型消去を採用する言語処理系の高速なディスパッチ機構を有利に利用することができる。

また、名前修飾のためのサフィックスを名前とする合成クラスは、個々のメソッドを他のメソッドとは無関係に修飾(mangling)することを可能ならしめ、もって安定なディスパッチを実現する。

本発明を実施するためのコンピュータ・システムのハードウェアの一例のブロック図を示す図である。 本発明を実施するための一実施例に係る機能構成のブロック図を示す図である。 本発明の処理のフローチャートを示す図である。

以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。

図１を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図１において、システム・バス１０２には、ＣＰＵ１０４と、主記憶（ＲＡＭ）１０６と、ハードディスク・ドライブ（ＨＤＤ）１０８と、キーボード１１０と、マウス１１２と、ディスプレイ１１４が接続されている。ＣＰＵ１０４は、好適には、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のPentium(商標)4、インテル社のCore(商標) 2 DUO、AMD社のAthlon(商標)などを使用することができる。主記憶１０６は、好適には、２ＧＢ以上の容量、より好ましくは、４ＧＢ以上の容量をもつものである。

ハードディスク・ドライブ１０８には、オペレーティング・システムが、格納されている。オペレーティング・システムは、Linux（商標）、マイクロソフト社のWindows(商標) 7、Windows XP(商標)、Windows(商標)2003サーバ、アップルコンピュータのMac OS(商標)などの、ＣＰＵ１０４に適合する任意のものでよい。

ハードディスク・ドライブ１０８にはまた好適には、Apacheなどの、Ｗｅｂサーバとしてシステムを動作させるためのプログラムが保存され、システムの起動時に、主記憶１０６にロードされる。

ハードディスク・ドライブ１０８にはさらに、Java(R)仮想マシン（ＪＶＭ）を実現するためのJava(R) Runtime Environmentプログラムが保存され、システムの起動時に、主記憶１０６にロードされる。

ハードディスク・ドライブ１０８にはさらに、図２に関連して後述するX10のソースコード２０２、X10のソースコードの構文解析ルーチン２０４、Java(R)コード生成ルーチン２０８、Java(R)コンパイラ２１２、Java(R)コンパイラ２１２によって利用される、Java(R)用X10ランタイム・モジュール２１４などが、保存されている。これらのルーチンは、好適にはJava(R)で書かれて、Java(R)バイトコードとして保存され、ＪＶＭ２１８上で動作する。

キーボード１１０及びマウス１１２は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ１１４に表示されたアイコン、タスクバー、テキストボックスなどのグラフィック・オブジェクトを操作するために使用される。

ディスプレイ１１４は、これには限定されないが、好適には、１０２４×７６８以上の解像度をもち、３２ビットtrue colorのＬＣＤモニタである。ＬＣＤモニタは、図示しないが、コンパイルすべきX10ソースコードのファイルを選択したり、キーボード１１０やマウス１１２を使ってコンパイル操作をするためのメニューなどを表示するために使用される。

通信インターフェース１１６は、好適には、イーサネット(R)プロトコルにより、ネットワークと接続されている。通信インターフェース１１６は、クライアント・コンピュータ（図示しない）からApacheが提供する機能により、ＴＣＰ／ＩＰなどの通信プロトコルに従い、処理リクエストを受け取り、あるいは処理結果を、クライアント・コンピュータ（図示しない）に返す。

図２は、本発明を実施するための一実施例に係る機能構成のブロック図を示す図である。構文解析ルーチン２０４は、X10のソースコード２０２を読んで、X10抽象構文木２０６に変換する。X10の言語仕様については、http://x10-lang.org/などを参照されたい。また、ソースコードから抽象構文木を作成する技法については、Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman, "Compilers: Principles, Techniques, and Tools",Addision Wesley Publishing Company, 1986、あるいは、Andrew W. Appel, "Modern Compiler Implementation", Cambridge University Press, 1998などに記載されており、発明の要旨ではないので、ここでは説明を省略する。ここで抽象構文木のノードに含まれる内容で注目されるのは、X10のソースコードにおけるコンストラクタ定義、及びコンストラクタ呼び出しである。

生成されたX10抽象構文木２０６は、好適には、ハードディスク・ドライブ１０８に保存される。Java(R)コード生成ルーチン２０８は、本発明の機能を実装するものであり、X10抽象構文木２０６のデータを読み取り、Java(R)ソースコード２１０を生成する。Java(R)コード生成ルーチン２０８の、本発明に関連する機能については、図３のフローチャートを参照して、後で詳細に説明する。

Java(R)コード生成ルーチン２０８によって生成されたJava(R)ソースコード２１０は、好適には、ハードディスク・ドライブ１０８に保存され、Java(R)コンパイラ２１２が、Java(R)用X10ランタイム・ルーチン２１４を参照しつつ、Java(R)バイトコード２１６を生成する。Java(R)バイトコード２１６は、好適には主記憶１０６にロードされるが、ハードディスク・ドライブ１０８に保存されてもよい。生成されたJava(R)バイトコード２１６は、JVM２１８上で実行される。

次に、Java(R)コード生成ルーチン２０８の、本発明に関連する機能について、図３のフローチャートを参照して説明する。図３において、Java(R)コード生成ルーチン２０８は、ステップ３０２で、X10抽象構文木の最初のノードを訪問する。

ステップ３０４で、Java(R)コード生成ルーチン２０８は、訪問したノードが、コンストラクタ定義かどうか判断する。

下記は、X10ソースコードの例の一部を示す。
class C[T, U] {
def this(a:U) {} // ctor id = 0
def this() {} // ctor id = -1
def this(a:Any) {} // ctor id = -1
def this(a:T) {} // ctor id = 1
}
new C[String,Double](12.3);
new C[String,Double](“abc”);

ここでコンストラクタ定義のノードとは、def this ...に対応するノードである。Java(R)コード生成ルーチン２０８は、コンストラクタ定義であると判断すると、ステップ３０６で、修飾(mangling)を要するかどうか判断する。修飾を要するとは、注目するメソッドの引数が型パラメータを持つということである。修飾を要するなら、Java(R)コード生成ルーチン２０８は、ステップ３０８で名前修飾のためのサフィックスを得る。ここでサフィックスとは、例えば__0C$$Uのような値である。

Java(R)コード生成ルーチン２０８は、ステップ３１０で、サフィックスと同じ名前の合成クラスを生成する。これは例えば、下記のようなものである。
abstract static class __0C$$U {}

Java(R)コード生成ルーチン２０８は、ステップ３１２で、合成クラスの型のダミー引数をもつコンストラクタを生成する。これは例えば、下記のようなステートメントである。
C(Type T, Type U, U a, __0C$$U dummy) {}

ステップ３０６に戻って、Java(R)コード生成ルーチン２０８は、修飾を要さないと判断すると、ステップ３１４で単にコンストラクタを生成する。

ステップ３０４に戻って、コンストラクタ定義でないと判断すると、Java(R)コード生成ルーチン２０８は、ステップ３１６で、コンストラクタ呼び出しかどうか判断する。ここで、コンストラクタ呼び出しとは、上記のX10のソースコードでは、下記のようなステートメントである。
new C[String,Double](12.3);

コンストラクタ呼び出しであると判断すると、Java(R)コード生成ルーチン２０８は、ステップ３１８で、修飾を要するかどうか判断する。Java(R)コード生成ルーチン２０８は、修飾を要すると判断すると、ステップ３２０で、合成クラスの型のダミー引数をもつnewを含むステートメントを生成する。ここで、合成クラスの型のダミー引数をもつnewを含むステートメントとは、例えば以下のようなステートメントである。
new C<String,Double>(Types.STRING, Types.DOUBLE, 12.3, (C.__0C$$U) null);

一方、ステップ３１８で、修飾を要さらないと判断すると、Java(R)コード生成ルーチン２０８はステップ３２２で単にnewを含むステートメントを生成する。

ステップ３１６で、コンストラクタ呼び出しでないなら、単にステップ３１８、３２０あるいは３２２をスキップする。

こうして処理はステップ３２４に至り、そこで、Java(R)コード生成ルーチン２０８は、すべてのノードを訪問したかどうか判断する。なお、ステップ３２４に至るまでに、Java(R)コード生成ルーチン２０８は本発明に直接関係ない様々の処理を含むが、ここでは便宜上説明を省略する。

ステップ３２４で、Java(R)コード生成ルーチン２０８がすべてのノードを訪問したと判断すると、処理を終了する。

ステップ３２４で、すべてのノードをまだ訪問していないと判断すると、Java(R)コード生成ルーチン２０８はステップ３２６で次のノードを訪問して、ステップ３０４に戻る。

次に、具体的なX10ソースコードの変換例を示す。上記のX10ソースコードを再掲する。
class C[T, U] {
def this(a:U) {} // ctor id = 0
def this() {} // ctor id = -1
def this(a:Any) {} // ctor id = -1
def this(a:T) {} // ctor id = 1
}
new C[String,Double](12.3);
new C[String,Double](“abc”);

従来技術では、このソースコードが、次のようなJava(R)コードに変換される。
class C<T, U> {
C(Type T, Type U, U a, Class dummy) {}
C(Type T, Type U) {}
C(Type T, Type U, Object a) {}
C(Type T, Type U, T a, Class[] dummy) {}
}
new C<String,Double>(Types.STRING, Types.DOUBLE, 12.3, (Class) null);
new C<String,Double>(Types.STRING, Types.DOUBLE, “abc”, (Class[]) null);

この場合、コンストラクタの定義順は相対値であり、他のコンストラクタの追加・削除により変わりえるため、やはり安定なディスパッチが出来ないという問題が生じた。

一方、この発明によれば、次のようなJava(R)コードに変換される。
class C<T, U> {
abstract static class __0C$$U {}
abstract static class __0C$$T {}
C(Type T, Type U, U a, __0C$$U dummy) {}
C(Type T, Type U) {}
C(Type T, Type U, Object a) {}
C(Type T, Type U, T a, __0C$$T dummy) {}
}
new C<String,Double>(Types.STRING, Types.DOUBLE, 12.3, (C.__0C$$U) null);
new C<String,Double>(Types.STRING, Types.DOUBLE, “abc”, (C.__0C$$T) null);

このような技術によれば、個々のメソッドを他のメソッドとは無関係に修飾できるので、安定な修飾が可能となる。

以上、X10のソースコードを、Java(R)のソースコードに変換する処理の実施例を説明してきたが、本発明はこの特定の実施例に限定されず、様々な変形例を考えることができる。例えば、X10のソースコードを、一旦Java(R)のソースコードに変換することなく、直接Java(R)のバイトコードに変換してもよい。

また、ソース言語はX10に限らず、静的型付け言語のうち型具体化に基づく総称型をサポートする任意のプログラミング言語でよく、そのような条件を満たすプログラミング言語として、C++、C#がある。

さらに、ターゲットの言語は、Java(R)に限らず、Scalaなど、型消去に基づく総称型をサポートする任意のプログラミング言語を使用することができる。

１０４・・・ＣＰＵ
１０６・・・主記憶
１０８・・・ハードディスク・ドライブ
２０４・・・構文解析ルーチン
２０６・・・Javaコード生成ルーチン

Claims (15)

1. コンピュータの処理により、第１のプログラミング言語のソースコードを、第２のプログラミング言語のコードに変換する方法であって、
   前記第１のプログラミング言語のソースコードを用意するステップと、
   前記第１のプログラミング言語のソースコードを走査して、該ソースコードにおける通常メソッドの名前修飾のためのサフィックスを名前とする合成クラスを追加するステップと、
   コンストラクタ定義に前記合成クラスの型のダミー引数を追加するステップと、
   コンストラクタ呼び出しに前記ダミー引数の型に適合する適当な値を追加するステップと、
   前記追加した結果に基づき、前記第２のプログラミング言語のコードに変換して生成するステップを有する、
   方法。
2. 前記第１のプログラミング言語が型具体化を基本とするプログラミング言語であり、前記第２のプログラミング言語が型消去を採用するプログラミング言語である、請求項１に記載の方法。
3. 前記第１のプログラミング言語がX10であり、前記第２のプログラミング言語がJavaであり、前記第２のプログラミング言語のコードがJavaバイトコードである、請求項２に記載の方法。
4. 前記第１のプログラミング言語がX10であり、前記第２のプログラミング言語がJavaであり、前記第２のプログラミング言語のコードがJavaソースコードである、請求項１に記載の方法。
5. 前記ダミー引数の型に適合する適当な値がnullである、請求項１に記載の方法。
6. コンピュータの処理により、第１のプログラミング言語のソースコードを、第２のプログラミング言語のコードに変換するプログラムであって、
   前記コンピュータに、
   前記第１のプログラミング言語のソースコードを用意するステップと、
   前記第１のプログラミング言語のソースコードを走査して、該ソースコードにおける通常メソッドの名前修飾のためのサフィックスを名前とする合成クラスを追加するステップと、
   コンストラクタ定義に前記合成クラスの型のダミー引数を追加するステップと、
   コンストラクタ呼び出しに前記ダミー引数の型に適合する適当な値を追加するステップと、
   前記追加した結果に基づき、前記第２のプログラミング言語のコードに変換して生成するステップを実行させる、
   プログラム。
7. 前記第１のプログラミング言語が型具体化を基本とするプログラミング言語であり、前記第２のプログラミング言語が型消去を採用するプログラミング言語である、請求項６に記載のプログラム。
8. 前記第１のプログラミング言語がX10であり、前記第２のプログラミング言語がJavaであり、前記第２のプログラミング言語のコードがJavaバイトコードである、請求項７に記載のプログラム。
9. 前記第１のプログラミング言語がX10であり、前記第２のプログラミング言語がJavaであり、前記第２のプログラミング言語のコードがJavaソースコードである、請求項６に記載のプログラム。
10. 前記ダミー引数の型に適合する適当な値がnullである、請求項６に記載のプログラム。
11. コンピュータの処理により、第１のプログラミング言語のソースコードを、第２のプログラミング言語のコードに変換するシステムであって、
    前記第１のプログラミング言語のソースコードを用意する手段と、
    前記第１のプログラミング言語のソースコードを走査して、該ソースコードにおける通常メソッドの名前修飾のためのサフィックスを名前とする合成クラスを追加する手段と、
    コンストラクタ定義に前記合成クラスの型のダミー引数を追加する手段と、
    コンストラクタ呼び出しに前記ダミー引数の型に適合する適当な値を追加する手段と、
    前記追加した結果に基づき、前記第２のプログラミング言語のコードに変換して生成する手段を有する、
    システム。
12. 前記第１のプログラミング言語が型具体化を基本とするプログラミング言語であり、前記第２のプログラミング言語が型消去を採用するプログラミング言語である、請求項１１に記載のシステム。
13. 前記第１のプログラミング言語がX10であり、前記第２のプログラミング言語がJavaであり、前記第２のプログラミング言語のコードがJavaバイトコードである、請求項１２に記載のシステム。
14. 前記第１のプログラミング言語がX10であり、前記第２のプログラミング言語がJavaであり、前記第２のプログラミング言語のコードがJavaソースコードである、請求項１１に記載のシステム。
15. 前記ダミー引数の型に適合する適当な値がnullである、請求項１１に記載のシステム。

Images