コンピュータの処理によりスタック割当ての可否を判定するステップを実行する方法であって、前記コンピュータが、オブジェクトを生成しているメソッドフレーム内で、当該オブジェクトをエスケープする可能性がある第1の命令と、前記第1の命令によるオブジェクトのエスケープ状態を解消する第2の命令が呼ばれていることと、前記オブジェクトが第1の命令によってエスケープ状態となり、第2の命令によりエスケープ状態でなくなった場合、エスケープ状態でなくなった時点で当該オブジェクトがエスケープしたスレッド以外のスレッドにエスケープしていないことと、前記第1の命令が第2の命令の前で呼ばれることと、及び前記メソッドフレーム内で、前記第1の命令内で前記オブジェクトがエスケープしているかどうかに拘らず、前記第1の命令以外でエスケープしていないことに応答して、前記オブジェクトをスタック割当てするステップを実行する、コンピュータの動作制御方法。前記第2の命令によってキャンセルされない、オブジェクトのエスケープを発生させる可能性のある第3の命令があることを検出することに応答して、当該第1の命令が呼ばれた後、第2の命令が呼ばれる前に、第3の命令が呼ばれた場合に、スタックに割り当てたオブジェクトをヒープに割り当てしなおすステップをさらに有する、請求項1に記載の方法。前記コンピュータが、ForkJoinフレームワークで動作し、前記第1の命令がforkであり、前記第2の命令がjoinである、請求項2に記載の方法。前記第3の命令は、タスクオブジェクトをワークスティーリングのキューに挿入する際にのみ使用するメソッド及び、タスクオブジェクトをワークスティーリングのキューに挿入する後、タスクの終了を待機する際にのみ使用するメソッド以外である、請求項2に記載の方法。前記ステップが、JavaVMによって実行される、請求項2に記載の方法。前記ステップが、JITコンパイラによって生成されたコードによって実行される、請求項2に記載の方法。コンピュータの処理によりスタック割当ての可否を判定するステップを実行するプログラムであって、前記コンピュータに、オブジェクトを生成しているメソッドフレーム内で、当該オブジェクトをエスケープする可能性がある第1の命令と、前記第1の命令によるオブジェクトのエスケープ状態を解消する第2の命令が呼ばれていることと、前記オブジェクトが第1の命令によってエスケープ状態となり、第2の命令によりエスケープ状態でなくなった場合、エスケープ状態でなくなった時点で当該オブジェクトがエスケープしたスレッド以外のスレッドにエスケープしていないことと、前記第1の命令が第2の命令の前で呼ばれることと、及び前記メソッドフレーム内で、前記第1の命令内で前記オブジェクトがエスケープしているかどうかに拘らず、前記第1の命令以外でエスケープしていないことに応答して、前記オブジェクトをスタック割当てするステップを実行させる、プログラム。前記第2の命令によってキャンセルされない、オブジェクトのエスケープを発生させる可能性のある第3の命令があることを検出することに応答して、当該第1の命令が呼ばれた後、第2の命令が呼ばれる前に、第3の命令が呼ばれた場合に、スタックに割り当てたオブジェクトをヒープに割り当てしなおすステップをさらに有する、請求項7に記載のプログラム。前記コンピュータが、ForkJoinフレームワークで動作し、前記第1の命令がforkであり、前記第2の命令がjoinである、請求項8に記載のプログラム。前記第3の命令は、タスクオブジェクトをワークスティーリングのキューに挿入する際にのみ使用するメソッド及び、タスクオブジェクトをワークスティーリングのキューに挿入する後、タスクの終了を待機する際にのみ使用するメソッド以外である、請求項8に記載のプログラム。前記ステップが、JavaVMによって実行される、請求項8に記載のプログラム。前記ステップが、JITコンパイラによって生成されたコードによって実行される、請求項8に記載のプログラム。コンピュータの処理によりスタック割当ての可否を判定するステップを実行するシステムであって、オブジェクトを生成しているメソッドフレーム内で、当該オブジェクトをエスケープする可能性がある第1の命令と、前記第1の命令によるオブジェクトのエスケープ状態を解消する第2の命令が呼ばれていることと、前記オブジェクトが第1の命令によってエスケープ状態となり、第2の命令によりエスケープ状態でなくなった場合、エスケープ状態でなくなった時点で当該オブジェクトがエスケープしたスレッド以外のスレッドにエスケープしていないことと、前記第1の命令が第2の命令の前で呼ばれることと、及び前記メソッドフレーム内で、前記第1の命令内で前記オブジェクトがエスケープしているかどうかに拘らず、前記第1の命令以外でエスケープしていないことに応答して、前記オブジェクトをスタック割当てする手段を有する、システム。前記第2の命令によってキャンセルされない、オブジェクトのエスケープを発生させる可能性のある第3の命令があることを検出することに応答して、当該第1の命令が呼ばれた後、第2の命令が呼ばれる前に、第3の命令が呼ばれた場合に、スタックに割り当てたオブジェクトをヒープに割り当てしなおす手段をさらに有する、請求項13に記載のシステム。前記コンピュータが、ForkJoinフレームワークで動作し、前記第1の命令がforkであり、前記第2の命令がjoinである、請求項14に記載のシステム。前記第3の命令は、タスクオブジェクトをワークスティーリングのキューに挿入する際にのみ使用するメソッド及び、タスクオブジェクトをワークスティーリングのキューに挿入する後、タスクの終了を待機する際にのみ使用するメソッド以外である、請求項14に記載のシステム。前記各手段が、JavaVMによって実行される、請求項14に記載のシステム。前記各手段が、JITコンパイラによって生成されたコードを含む、請求項14に記載のシステム。従って、この発明の目的は、ForkJoinのフレームワークにおいて、生成されるタスクオブジェクトに対し、forkやjoinの処理があった際に、スタック割当可能な場合を適切に見極める処理を提供することにある。本発明によれば、ForkJoinのフレームワークにおいて、次のような判断をする処理が実装される。-タスクオブジェクトをワークスティーリングのキューに入れる処理では、エスケープしないものとみなす。この処理とは例えば、forkにより行われるものである。-キューに入れたタスクオブジェクトの終了を待機する処理では、エスケープしないものとみなす。この処理とは例えば、joinにより行われるものである。-上記以外でタスクオブジェクトがエスケープする場合は、エスケープしないものとみなす。さらに本発明に従う処理は、タスクオブジェクトの実行中に、タスクオブジェクトがエスケープしていないかどうかを解析する。そして、この解析において、エスケープしないと解析されたタスクオブジェクトを生成したフレーム内で、タスクオブジェクトをワークスティーリングのキューに入れる処理の後に、タスクオブジェクトの終了を待機する処理を必ず行っている場合、そのタスクオブジェクトを、スタックに配置する。本願発明の知見によれば、タスクオブジェクトがforkメソッドの実行中、あるいはjoinメソッドの実行中にエスケープしたとしても、joinの処理が終了した時点で、他のWorkerがタスクオブジェクトにアクセスしないことが保障される場合があることが分かった。説明を補足すると、タスクオブジェクトに対するjoinの処理は、任意のWorkerがタスクオブジェクトのタスクを終了し終わった時点で終了する。つまり、任意のWorkerがタスクオブジェクトのタスクを処理中に、タスクオブジェクトをエスケープしない限り、joinの処理後もエスケープしていない状態となる。すなわち、当該の条件では、従来、タスクオブジェクトをスタック割当てできないと見なされていたところ、本願発明の知見に従うと、安全にタスクオブジェクトをスタック割当てできると判断してよいことになる。この発明によれば、従来ではタスクオブジェクトをスタック割当てできないと見なされていた場合でも、実際には安全にタスクオブジェクトをスタック割当てできるという場合を見出すことができ、これによって、ガベージコレクションや、オブジェクトをヒープ割当てするコストが減少するので、結果的に、コンピュータシステムの処理速度を向上することができるという効果が得られる。以下、図面に従って、本発明の実施例を説明する。これらの実施例は、本発明の好適な態様を説明するためのものであり、発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断わらない限り、同一符号は、同一の対象を指すものとする。図1を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータハードウェアのブロック図が示されている。図1において、システムバス102には、CPU104と、主記憶RAM106と、ハードディスクドライブHDD108と、キーボード110と、マウス112と、ディスプレイ114が接続されている。CPU104は、好適には、32ビットまたは64ビットのアーキテクチャに基づくものであり、例えば、インテル社のPentium4、インテル社のCore2DUO、Xeon、AMD社のAthlonなどを使用することができる。主記憶106は、好適には、2GB以上の容量、より好ましくは、4GB以上の容量をもつものである。ハードディスクドライブ108には、オペレーティングシステム202図2が、格納されている。オペレーティングシステムは、Linux商標、マイクロソフト社のWindows7、WindowsXP、Windows2003サーバ、アップルコンピュータのMacOSなどの、CPU104に適合する任意のものでよい。ハードディスクドライブ108にはまた、好適にはApacheなどの、Webサーバとしてシステムを動作させるためのプログラムが保存され、システムの起動時に、主記憶106にロードされる。ハードディスクドライブ108にはさらに、Java仮想マシンJVM204図2を実現するためのJavaRuntimeEnvironmentプログラムが保存され、システムの起動時に、主記憶106にロードされる。JVM204は、本発明に係るヒープオブジェクト化の機能を実装する。ハードディスクドライブ108にはさらに、アプリケーションプログラムのバイトコード206図2が保存されている。キーボード110及びマウス112は、オペレーティングシステム202が提供するグラフィックユーザインターフェースに従い、ディスプレイ114に表示されたアイコン、タスクバー、ウインドウなどのグラフィックオブジェクトを操作するために使用される。ディスプレイ114は、これには限定されないが、好適には、1024×768以上の解像度をもち、32ビットtruecolorのLCDモニタである。ディスプレイ114は、アプリケーションプログラムの挙動を必要に応じて表示するために使用される。通信インターフェース116は、好適には、イーサネットプロトコルにより、ネットワークと接続されている。通信インターフェース116は、クライアントコンピュータ図示しないからApacheが提供する機能により、TCP/IPなどの通信プロトコルに従い、処理リクエストを受け取り、あるいは処理結果を、クライアントコンピュータ図示しないに返す。図2は、ソフトウェアのレイヤを示す図である。図2において、最下層は、オペレーティングシステム202である。オペレーティングシステム202の上では、オペレーティングシステム202に適合するJVM204が動作する。オペレーティングシステム202は、システムの起動時に、主記憶106に、スタック領域と、ヒープ領域を確保する。スタック領域では、アプリケーションにおいて、関数がコールされる度に、スタックフレームがスタック領域に積まれ、関数がリターンすると、そのスタックフレームが、削除される。JVM204上では、アプリケーション206のバイトコードが動作する。アプリケーション206が動作する間に、JVM204はシステムの状態を監視し、スタックのサイズ圧縮、あるいはワークスティーリングの処理を行い、所定の基準に従い、エスケープ解析を行って、特定の条件を満たす場合に、タスクオブジェクトを、スタックに割り当てる。本発明の特徴は、エスケープ解析の結果に基づき、タスクオブジェクトを、スタックに割り当ててよいかどうかを判断する、判断ルーチンの基準を与える機能にある。この実施例では、そのような判断ルーチンは、JVM204に含まれている。本発明のエスケープ解析の判断ルーチンの基準について説明する前に、従来技術におけるForkJoinフレームワークの振る舞いについて説明する。本発明は、これには限定されないが、科学技術計算のアプリケーションプログラムに適用することで、特に大きい効果を奏する。このとき、下記のような、ワークスティーリングを実装した並列実行プログラムを実行するものとする。これは、フィボナッチ数列の計算Fibの例である。classFibextendsForkJoinTaskIntegerrFibthisrrprotectedbooleanexecifreturntrueFibf1newFibFibf2newFibf1forkf2forkf2joinf1joinrf1rf2rreturntruevoidmainpoolinvoke図3は、Workerが、コードにおけるf1forkによって、タスクをforkする際、タスクをWorkerのキューに入れる様子を示す図である。すなわち、メインスレッドがFibをグローバルのキューに入れる。次にWorker1が、グローバルのキューからFibを取得する。次にWorker1が、Fibのexecを実行し、タスクFibをWorker1のキューに入れる。図4は、Workerが、コードにおけるf2forkによって、新たなタスクをforkする際、タスクをキュー内の前回入れたタスクの次の場所に入れる様子を示す図である。すなわち、Worker1が、Fibのexecを実行し、タスクFibをWorker1のキューに入れる。FibはFibの次に配置される。図5は、Workerが、f2joinによって、最後の入れたタスクのjoinを呼び出した際、そのタスクがキューに残っていれば、そのタスクのexecを実行する様子を示す図である。すなわち、Worker1がFibのjoinを実行し、タスクFibの終了を待つ。その際、Fibは自身のキューに残っているため、キューからFibを取り出し、execを実行する。図6は、他Workerがアイドルになった場合、タスクがキューされているタスクがキューされているWorkerから、タスクをスティールする様子を示す図である。すなわち、アイドルなWorker2が、Worker1のキューからFibをスティールし、execを実行する。図7は、Workerがjoinを呼び出したタスクがキューにない場合は、そのタスクが終了するまでWorkerが待機する示す図である。すなわち、Worker1が、Worker2にスティールされたFibのjoin、すなわちf1joinを呼び出し、Worker2がFibのexecを終了するまで待機する。このような従来技術におけるForkJoinフレームワークの挙動から、本願発明者は、次のことを見出した。joinが終了した時点では、タスクはキューから削除されている。joinが終了した時点で、スティールしたWorkerは、タスクの参照をもっていない場合がある。このとき、exec内でthisがエスケープしていない。そこで、fork、join内でのエスケープは無視し、exec内でエスケープしているかどうかを、エスケープ解析内で解析するようにした。そして、以下の条件が満たされる場合、タスクオブジェクトへのjoinが終了した時点で、タスクオブジェクトへの参照が、他スレッドに存在しないと言えることが分った。-タスクオブジェクトを生成するメソッドフレーム内で、fork、joinメソッドが呼ばれている。-上記メソッドフレーム内で、上記タスクオブジェクトが、fork、join以外でエスケープしていない。-上記タスクオブジェクトのexecメソッド内で、thisが他のスレッドにエスケープしていない。本発明に従うJVM204は、これらの条件を満たしている場合、タスクオブジェクトはエスケープしていないものとみなし、スタックに割り当てる。次に、図8のフローチャートを参照して、JVM204が、エスケープ解析の結果に基づき、タスクオブジェクトを、スタックまたはヒープに割り当てる処理を説明する。図8において、ステップ802で、JVM204は、生成したタスクオブジェクトをワークスティーリングのキューに挿入しているかどうかを判断する。そして、もしそうでないなら、ステップ810に進んで、タスクをヒープ上に生成する。ステップ802で、JVM204が、生成したタスクオブジェクトをワークスティーリングのキューに挿入していると判断したなら、JVM204はステップ804で、ワークスティーリングのキューに挿入後、タスクの終了を必ず待機しているかどうか判断する。そして、もしそうでないなら、ステップ810に進んで、タスクをヒープ上に生成する。ステップ804で、JVM204が、ワークスティーリングのキューに挿入後、タスクの終了を必ず待機していると判断したなら、JVM204はステップ806で、ワークスティーリングのキューへの挿入、タスクの終了待機以外に、生成したタスクオブジェクトがエスケープしているかどうかを判断する。そして、もしそうなら、ステップ810に進んで、タスクをヒープ上に生成する。ステップ806で、JVM204が、ワークスティーリングのキューへの挿入、タスクの終了待機以外に、生成したタスクオブジェクトがエスケープしていないと判断したなら、JVM204はステップ808で、生成したタスクオブジェクトのタスク処理中に、そのタスクオブジェクトがエスケープしているかどうかを判断し、もしそうなら、ステップ810に進んで、タスクをヒープ上に生成し、もしそうでないなら、ステップ812に進んで、タスクをスタック上に生成する。次に図9のフローチャートを参照して、JVM204が、ワークスティーリングのキュー内のタスクオブジェクトを取得するメソッドを実行する時の挙動の例を説明する。すなわち、ステップ902で、JVM204は、実行しようとするメソッドが、生成したタスクオブジェクトをワークスティーリングのキューに挿入する歳にのみ使用するメソッドかどうか判断し、もしそうでないなら、ステップ906に進んで、取得したタスクオブジェクトがスタック上に配置されている場合、ヒープに移動する処理を行う。ステップ902で、JVM204が、実行しようとするメソッドが、生成したタスクオブジェクトをワークスティーリングのキューに挿入する歳にのみ使用するメソッドであると判断したなら、ステップ904に進んで、ワークスティーリングのキューに挿入後、タスクの終了を待機する際のみに使用するメソッドかどうかを判断する。もしそうでないなら、ステップ906に進んで、取得したタスクオブジェクトがスタック上に配置されている場合、ヒープに移動する処理を行う。一方、もしそうなら、ステップ908で特に何もしない。図10は、図3~図7で示した従来技術の例に、本発明を適用した結果を示す図である。すなわち、この例では、本発明に従うエスケープ解析の結果、FibとFibが、ヒープでなく、スタックに割り当てられる。この例では、Worker2は、Worker1のスタックに割り当てられたオブジェクトを直接触ることになる。なお、JVMではなく、図8及び図9を実装するコードをJITコンパイラにより生成することにより、本発明を実施してもよい。さらに、エスケープ解析とそれに基づくスタック割当て処理は、JVMなどの仮想マシン環境でなく、オペレーティングシステムが直接実行するようにしてもよい。以上、本発明を、ForkJoinフレームワークにおけるfork、joinの呼び出しに関連して説明してきたが、本発明はこれには限定されず、より一般的に、タスクをオブジェクトとしてあらわしており、タスクをバックグラウンドで処理する命令と、タスクの処理終了まで待機する命令とをもち、タスクの実行後は、処理系内でタスクへの参照を持たない任意の処理系に適用可能である。このような処理系の例として、これには限定されないが、例えば、並列分散プログラミング用の処理系であるX10がある。