日本ソフトウェア科学会第 41 回大会 (2024 年度) 講演論文集

最新比較評価向け M-Closure の再実装
廣田 陽紀

八杉 昌宏

平石 拓

高水準プログラミング言語の実装におけるマシン独立な低水準言語として C 言語を使いたいことがある．ごみ集めなどの高水準サービスの実現には実行スタック中の存命の変数の値にアクセスする必要があり，そのような合法的実
行スタックアクセスのための言語機構として計算状態操作機構が八杉らにより提案されている．計算状態操作機構として GNU C コンパイラ（GCC）がサポートする入れ子関数（から生成されるクロージャ）が利用可能なことから，
クロージャ生成コストを削減した M-closure が提案され，GCC 3.4.6 および GCC 4.6.3 の改造により実装されてきた．本研究では GCC 13 系列など最新の GCC の改造により M-closure を再実装し，L-closure などその他の計
算状態操作機構あるいは GCC 改造によらない変換ベースの実装との比較研究を可能とする．

では，関数呼び出し中に呼び出されたほうの関数は，1 はじめに実行スタック深くに眠る呼び出し元の存命の変数の値様々な計算機（マシン）について優れたコード生成にアクセスするとしても，実行スタックに直接（非合器を実装するのは手間がかかる作業である．このた法的に）アクセスするべきではない．

め，高水準プログラミング言語の実装においては，あ

合法的実行スタックアクセスのための言語機構としる程度，移植性が良くマシン独立な低水準言語としてて計算状態操作機構 [3] [10] [4] [7] [6] [5] が提案されてC 言語を使いたいことがある．高水準言語から C 言いる．計算状態操作機構を備えた拡張 C 言語（など）語への翻訳系，あるいは C 言語による高水準言語イをマシン独立な低水準言語として用いるのである．

ンタプリタのみを開発するのである．

C プログラムをコンパイルして得られる機械語プ
ログラムの多くは，実行スタックを使う．

本研究では，計算状態操作機構のうち，“M-closure”に着目する．従来は “closure” [10] [11] [7] と称していたが，用語が一般的過ぎた点を解消したいことと，別

高水準言語に備わっている高水準実行時サービス

途提案されている “L-closure” [10] [3] [11] との区別をの中には，ごみ集め，負荷分散のようにその効率良い

より明確にしたいことから，最近の研究 [6] [5] と同様サポートのためには実行スタックの内容を見たり変に “M-closure” という用語を用いることとする．

更したりする必要があるものがある．しかし C 言語

計 算 状 態 操 作 機 構 と し て GNU C コ ン パ イ ラ（GCC）が サ ポ ー ト す る 入 れ 子 関 数（ か ら 生 成 さM-Closures for the Latest Comparative Evaluation,
Re-implemented
Haruki Hirota, 九州工業大学大学院情報工学府, Graduate
School of Computer Science and Systems Engineering, Kyushu Institute of Technology.
Masahiro Yasugi, 九州工業大学大学院情報工学研究院,
Dept. of Computer Science and Networks, Kyushu
Institute of Technology.
Tasuku Hiraishi, 京都橘大学工学部情報工学科, Dept.
of Information and Computer Science, Faculty ofEngineering, Kyoto Tachibana University.

れるクロージャ） [1] が利用可能である．
（間接的に）
呼び出された入れ子関数は親関数の変数に合法的にアクセス可能となる．

M-closure は，GCC のクロージャ生成に伴うコストを削減しており，GCC 3.4.6 の改造 [10] およびGCC 4.6.3 の改造 [11] により実装されてきた．また，本格的な変換を S 式の変形として実現した形のM-closure [7] も実装されている．M-closure は，後述する L-closure [10] [3] [11] のように積極的に生成・通常のトップレベルの関数との相互運用性はないとす

維持コストを削減しない分，呼び出しコストが低く，る．L-closure は，その生成コストや維持コストを積

また変換に基づく L-closure の実装 [3] [11] とは異な極的に削減するという方針を採用しており，呼び出しり遅延判定コスト [7] を要しないという特徴がある．

コストは犠牲にしてよいとしている．

本研究の貢献は，GCC 13 系列など最新の GCC の改造により M-closure を再実装し，L-closure [10] [3] [11]2. 1. 1. 3 M-Closure
M-closure は L-closure における lightweight のなどその他の計算状態操作機構 [1] [6] [5] あるいは代わりに closure と書くこととし，各種コストにつGCC 改造によらない変換ベースの実装 [7] との比較

いて L-closure より中庸的な機構とする．

研究を可能とすることである．

2. 1. 2 持続型例外処理機構

本稿の構成は以下の通りである．2 章では，計算状

別形態の計算状態操作機構として提案されている

態操作機構の仕様・分類を述べ，その利用例について

持続型例外処理機構 [5] は，非局所脱出することなく述べる．3 章では GCC 3.4.6，GCC 4.6.3 の改造に例外ハンドラを呼び出せるとしたもので，ポインタで

よる M-closure の既存実装について述べ，4 章で最新はなく動的スコープに基づくためより安全である．

バージョンにおける M-closure の再実装について述

2. 1. 3 ラムダ式

べる．5 章では今後の展望について述べる．

C++言語のラムダ式は入れ子関数に似た形態の計算
状態操作機構として利用できる．ラムダ式の値（クロー2 計算状態操作機構ジャ）を渡すには，auto を用いるか std::function

2. 1 仕様・分類

クラステンプレートを用いることが多い．

2. 1. 1 入れ子関数の形態
2. 1. 1. 1 GCC 拡張の入れ子関数

2. 2 計算状態操作機構の利用例

GCC では，C への拡張として入れ子関数（nested

2. 2. 1 並列言語 Tascell や HOPE

function） [1] が使える．GCC の入れ子関数は通常

並列言語 Tascell [2] は，ワークスティールに基づのトップレベルの関数と異なり，以下の g のように，

く負荷分散を提供する．Tascell ワーカは，タスク生

void f(int a){ void g(){ a++; } h(g); }成を要求されない限り，自身の実行スタックを用いて親関数 f の中に入れ子に書かれていて，親関数の a

逐次計算を行う．要求されたら，計算状態操作機構をのような lexical スコープの変数の値に合法的にアク利用することで一時的バックトラックを行い，最古のセスできる．また，（h やその先から）間接的に呼び出

タスク生成可能状態を復元することで，期待値としてせ，関数ポインタとしても通常のトップレベルの関数より大きなタスクを生成する．

との相互運用性が確保されている．

HOPE [8] は階層的計算省略に基づく耐障害並列実

GCC の実装で用いられる「トランポリン」とは，行モデルであり，既存の並列実行モデルが「複数ワー静的リンクとして必要な環境をセットしてから入れ子カで仕事を分担」に基づくのとは全く逆に，耐障害

関数本体のコードへジャンプする数命令の命令列であ性のための完全冗長実行からの階層的計算省略に基り，スタック上に動的に生成される．ただし，データづく．どの HOPE ワーカも分割統治における全範囲／命令キャッシュのフラッシュや実行スタックを命令（同一プログラム内の全計算）を異なる順序で担当し実行可能とするためなどの高い生成コストを要する．

つつ，実行時に他ワーカから結果を得た部分の計算は2. 1. 1. 2 L-Closure

省略する．高速化のため，HOPE 言語の実装においL-closure は軽量 lexical closure であり，ては，複数の実行モードを設けて結果の送信や確認

void f(int a){を行うかを判断しており，遅延された実行モードの動void lightweight g(){ a++; } h(g); }のように GCC の入れ子関数とは別の「型」として，的切替（に伴う実行スタック中の結果などへのアクセス）に計算状態操作機構を利用している．

2. 2. 2 JALKD/XC と JAKLD/SC
L-closure（や M-closure）で実装した Scheme イン
タプリタ JAKLD/XC [9] では，計算状態操作機構

3. 1. 2 型検査
tree 表現上での型検査の際に M-closure 型を通常の関数型と区別するように改造していた．

をコピー型ごみ集めや一級継続のキャプチャに用い3. 1. 3 RTLている．SC 言語（S 式ベース C 言語）に入れ子関

GCC 3.4.6 の tree 表現から RTL 表現への展開を数を備えさせた拡張 SC 言語 SC-NF で再実装した

M-closure に対応させるため，通常の関数呼び出しとJAKLD/SC [7] では，標準 C 言語への変換に基づくは別の M-closure 呼び出しを行えるようにするととSC-NF の L-closure モデルや M-closure モデルによもに，GCC のトランポリンの代わりに M-closure をる実装も利用可能となっている．

設置できるように改造していた．

2. 2. 3 Tascell++

前者については，一見，関数呼び出しのように見

Tascell [2] にインスパイアされた C++プログラミえる場合でも，tree 表現される呼び出し対象の型

ングによる新しいワークスティールフレームワークとが M-closure 型である場合は，呼び出し準備としてして Tascell++ [6] が提案されている．計算状態操作

M-closure へのポインタ（従来の関数ポインタに相機構としてのラムダ式の値の受け取りの効率化のた

当）に関して，M-closure の 2 ワード目から静的リンめ，std::function クラステンプレートに基づく型

ク（GCC においては static_chain）を取り出しての代わりに，型消去技法よるカスタマイズされた仮想特定のレジスタにセットするような RTL 命令と，1関数と派生クラステンプレートが用いられている．

ワード目から呼び出し対象を関数ポインタとして取り出す RTL 命令を生成する．関数ポインタで呼び出

3 M-Closure の既存実装

せる関数は，特定のレジスタで静的リンクを受け取る

3. 1 GCC 3.4.6

ことで，外側の関数の局所変数などにアクセス可能と2007 年頃に GCC 3.4.6 改造により L-Closure を実なる．tree 表現における入れ子関数から外側の関数

装する際，M-closure についても実装していた [10]．

の変数へのアクセスは RTL 表現では静的リンクを介

GCC 3.4.6 では，Yacc 上位互換の Bison により生成したアクセスに修正される．

された構文解析器が使われている．C プログラムを

後者については，関数ポインタと静的リンクが埋め構文解析した結果得られる構文木（の主なノード）は込まれたトランポリンの代わりに，その 2 ワードを

tree という型で表現されている．tree 表現上の最適単に設置する（RTL 命令を生成する）だけである．

化はインライン展開や定数畳み込み程度であり，tree

GCC 3.4.6 改造の時点では，M-closure よりも L-

表現から RTL（regiter transfer language）表現に展

closure [10] に注目しており，再利用性や実行性能を開（expand）された後に RTL 表現上で様々な最適化高めるために，RTL 表現の事実上の拡張（実際にはが行われる．RTL 表現上でレジスタ割り当てが行わ

拡張なしで特殊なパターンの利用）を含め，はるかにれた後，アセンブリ言語のコードが生成される．

複雑な改造が行われていた．

3. 1. 1 構文解析

3. 1. 4 コード生成

GCC 3.4.6 の構文解析を M-closure に対応させる

L-closure についてはアセンブリコード生成部分

ため，Bison の入力ファイルに生成規則を追加するよも拡張・改造する必要があったのに対し，M-closure

うな形で構文の簡単な拡張を行うとともに，関数型のについては RTL 表現への展開までで完結しており，

tree 表現を拡張し，M-closure 型であることも表現でコード生成部分の改造は必要がなかった．

きるように改造していた．ただし，C 言語の構文における関数型は関数呼び出しの形を逆に読む形をして

3. 2 GCC 4.6.3

いるため，構文解析中の形の上だけの関数呼び出しの2012 年 頃 の GCC 4.6.3 改 造 で は M-closure にtree 表現にも M-closure であることが付加される．

つ い て の み 実 装 し て い た [11]．GCC 4 系 列 で はc-parser.c として書かれた構文解析器が使われるよ

必要はなかった．

うになった．C プログラムを構文解析した結果得られGENERIC から GIMPLE への変換後，入れ子関る構文木（の主なノード）は tree という型以外に，数がアクセスする変数を構造体のフィールドに置き換構造体も適材適所で併用されるようになった．GCC 4

えるような変換などが施されるが，この部分は修正の系列から標準的な tree 表現は GENERIC と呼ばれる必要がなかった．ただし，入れ子関数自体のアクセスようになり，RTL 表現への展開前に GIMPLE と呼ばについては，構造体のトランポリン型フィールドに置れる中間表現が用いられるようになった．GENERIC

き換えるような変換などが施される．これらの置きから GIMPLE への変換後，入れ子関数がアクセスす

換えは，GCC 3.4.6 の RTL とは異なり，GCC 4.6.3

る変数を構造体のフィールドに置き換えるような変では GIMPLE においてビルトイン関数も利用して行換などが施される．さらに，high GIMPLE から low

われる．

GIMPLE への低水準化が行われた後，low GIMPLE

構 造 体 の ト ラ ン ポ リ ン 型 フィー ル ド に 関 す る

表現上で様々な最適化が行われる．low GIMPLE 表

M-closure 対 応 と し て は ，ト ラ ン ポ リ ン 型 フィー

現から RTL 表現への展開（expand）は，tree 表現を

ル ド の代わ りに M-closure 型フィールドと なるよ

介しての展開も併用して行われる．RTL 表現上でもう に ，参照 時に__builtin_adjust_trampoline 関

様々な最適化が行われ，RTL 表現上でレジスタ割り

数 の 代 わ り に 調 整 な し と な る よ う に ，初 期 化 時当てが行われた後，アセンブリコードが生成される．

に__builtin_init_trampoline 関 数 の 代 わ り に ，

3. 2. 1 構文解析と GENERIC__builtin_init_closure 関数を用いるように改造

M-closure の構文は GCC 3.4.6 の改造のときと同していた．

じ設計とし，GCC 4.6.3 では手書きの構文解析器

high GIMPLE から low GIMPLE への低水準化や

c-parser.c を改造していた．M-closure 用に追加さlow GIMPLE 表現上で様々な最適化に対するこれられるべき生成規則に対しても生成規則右辺の共通プレの改造の影響はなかった．

フィックス部分の構文解析はそのままであり，丸カッ3. 2. 3 RTL とビルトイン関数

コなら関数型，角カッコなら配列型とするような場合

GCC 4.6.3 での low GIMPLE 表現から RTL 表現

分けのところに，M-closure のキーワード（closureへの展開（expand）は，tree 表現を介しての展開も

あるいはピリオドも可）の場合を加える程度であっ

併用して行われており，GCC 3.4.6 における tree 表

た．また，構文解析の上だけの構造体に M-closure で

現から RTL への展開（expand）と共通する部分があることが付加されるように改造していた．

多くみられた．例えば，一見，関数呼び出しのよう

GENERIC と呼ばれるようになった tree 表現につに見える場合でも，tree 表現される呼び出し対象のいては，関数型の tree 表現を拡張し，M-closure 型で型が M-closure 型である場合は，呼び出し準備としあることも表現できるように改造していたのは GCCて M-closure へのポインタに関して，M-closure の 2

3.4.6 の場合と同様である．tree 表現上での型検査にワード目から静的リンクを取り出して特定のレジスついても GCC 3.4.6 の場合と同様である．

タにセットするような RTL 命令と，1 ワード目から

3. 2. 2 GIMPLE

呼び出し対象を関数ポインタとして取り出す RTL 命

GCC 4.6.3 では GCC 3.4.6 にはなかった GIMPLE

令を生成する．ただし GCC 4.6.3 では，特定のレジという GENERIC よりもシンプルな命令の中間表現

スタの番号が関数定義以外に関数型からも得られるが用いられるようになったが，型を表す tree 表現はようにするための軽微な改造を要した．

GIMPLE でも GENERIC の表現が用いられている

GCC 4.6.3 で の RTL 表 現 へ の 展 開 時 に ，ため，M-closure 型のための GIMPLE 独自の拡張は__builtin_init_closure 関数なども展開されるよ必要なかった．GENERIC から GIMPLE への変換

うに改造した．関数ポインタと静的リンクが埋め込ま（gimplify）についても M-closure 用の独自の修正のれたトランポリン（命令列）の代わりに，その 2 ワー

ドを単に設置する（RTL 命令を生成する）だけなの型であるか確認するところでは，相違点 3 点目の検査

は，GCC 3.4.6 と同様である．

の対象となるようにし，本実装の開発効率を高めた．

GCC 4.6.3 でも M-closure については RTL 生成までで完結しており，コード生成部分は（レジスタ番号を得る部分を除き）改造する必要がなかった．

4. 1. 3 GIMPLE（140 行）
GCC 13.3 において，トランポリンと descriptor（相違点 2 点目）のどちらを利用するかは，ソース
言語を単位として決定すべきとされており，特に，

4 M-Closure の再実装

Ada コンパイラ向けの descriptor の利用が想定され

4. 1 GCC 13.3ている．つまり，C コンパイラとして用いるときは2024 年現在において，GCC 13.3 改造による M-

descriptor の利用が想定されていない．

closure の再実装を行った．改造パッチの行数を小節名に付す．

GCC 13.3 に お け る 構 造 体 の ト ラ ン ポ リ ン
型 フィー ル ド に 関 す る M-closure 対 応 と し て

4. 1. 1 GCC 4.6.3 との違い

は ，ト ラ ン ポ リ ン 型 フィー ル ド の 代 わ り にGCC 13.3 を C コンパイラとしてみたとき，2012

M-closure 型 フィー ル ド と な る よ う に ，参 照 時

年の GCC 4.6.3 との相違点はそれほど多くない．以に__builtin_adjust_trampoline 関 数 の 代 わ り

下に主要な相違点を整理する．

に__builtin_adjust_closure 関数を用いるように，• 1 点目として，GCC 4.6.3 ではコンパイラが C

初期化時に__builtin_init_trampoline 関数の代わ

言語で記述されていたのに対し，GCC 13.3 では

りに，__builtin_init_closure 関数を用いるよう

C++言語で記述されている点がある．

により統一的に改造した．これは，descriptor に関す• 2 点目として，トランポリンに代わり得るもの

る場合が GCC 13.3 では加わっており，それと統一として descriptor と呼ばれる仕組みが特に Ada

的となるように M-closure に関する場合を加えたた

コンパイラ向けに準備されている点がある．de-

めである．

scriptor は静的リンクと入れ子関数本体のペアを

4. 1. 4 RTL とビルトイン関数（149 行）用いる点で M-closure と同様であるが，関数ア

GCC 13.3 での low GIMPLE 表現から RTL 表現

ドレスの未使用ビットを見て通常の関数ポインタへの展開（expand）は，GCC 4.6.3 と共通する部分であるか descriptor であるかを判別することがが多くみられた．GCC 13.2 では「関数定義または関考えられている．

数型」を扱えるようになった部分（相違点 4 点目）が• 3 点目として，tree 表現上の操作で動的なデー
タ型検査が追加可能となっている点がある．

• 4 点目として，「関数定義または関数型」を扱えるようになった部分が増えている点がある．

増えており，その扱いのための軽微な改造が不要となった．

GCC 13.3 で の RTL 表 現 へ の 展 開 時 に ，__builtin_adjust_closure 関数なども展開される

4. 1. 2 構文解析と GENERIC（546 行）

ように改造した．GCC 13.3 でも M-closure について

M-closure の構文は GCC 3.4.6，GCC 4.6.3 の改は RTL 生成までで完結しており，コード生成部分は造のときと同じ設計としつつ，closure というキー

改造する必要がなかった．

ワードが GCC の外部ライブラリのソースプログラムで使われたりするようにもなっていたため，mclosure

4. 2 移植性というキーワードに変更した．

GCC 13.3 改造における M-closure 実装は，RTL

GCC 13.3 の構文解析器は c-parser.cc という生成までで完結しており，改造前の GCC 13.3 が入C++プログラムに変わっているものの，GENERIC

れ子関数を含めて動作可能な環境では基本，動作可能の拡張や型検査を含め，GCC 4.6.3 を構成する C プロ

な移植性を持つといえる．

グラムの改造とほぼ同様の改造となった．M-closure2024 年現在，改造前の GCC 13.3 がそのままでは動作可能でない環境としては，Apple Silicon のmacOS（Darwin）環境がある．macOS では Xcode
で Clang コンパイラが利用可能であるが，GCC の入

準言語の実装に用いるべき機構の評価に適用できる．
謝辞 本研究の一部は JSPS 科研費 JP21K19774 な
らびに JP22K11984 の助成を受けたものです．

れ子関数拡張はサポートされてない．Apple Silicon
向けの GCC 13.3 が Homebrew からパッケージで提参 考 文 献供されているものの，GCC 13.3 ソースに対して Iain

[ 1 ] Breuel, T. M.: Lexical Closure for C++, In Proceedings of the USENIX C++ Conference, 1988,
pp. 293–304.
[ 2 ] Hiraishi, T., Yasugi, M., Umatani, S., andYuasa, T.: Backtracking-based Load Balancing,
Proceedings of the 14th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP 2009), February 2009, pp. 55–
64.
[ 3 ] Hiraishi, T., Yasugi, M., and Yuasa, T.: A
Transformation-Based Implementation of Lightweight
Nested Functions, IPSJ Digital Courier, Vol. 2(2006),
pp. 262–279. (IPSJ Transactions on Programming,Vol. 47, No. SIG 6 (PRO 29), pp. 50–67, 2006).
[ 4 ] Tazuke, M., Yasugi, M., Hiraishi, T., andUmatani, S.: Reducing Invocation Costs of LClosures, IPSJ Trans. Programming, Vol. 6,
No. 2(2013), pp. 13–32. (in Japanese).
[ 5 ] Yasugi, M., Emoto, K., and Hiraishi, T.: Designing Restartable Exception Handling Mechanisms for Implementing Eﬃcient and Safe Highlevel Languages, Journal of Information Processing,Vol. 32(2024), pp. 436–450.
[ 6 ] Yasugi, M., Hiraishi, T., and Takeuchi, C.:
Portable Implementations of Work Stealing, Proceedings of International Conference on High Performance Computing in Asia-Paciﬁc Region (HPCAsia 2024), January 2024, pp. 12–22.
[ 7 ] Yasugi, M., Ikeuchi, R., Hiraishi, T., andKomiya, T.: Evaluating Portable Mechanisms for
Legitimate Execution Stack Access with a Scheme
Interpreter in an Extended SC Language, Journalof Information Processing, Vol. 27(2019), pp. 177–
189.
[ 8 ] Yasugi, M., Muraoka, D., Hiraishi, T., Umatani,S., and Emoto, K.: HOPE: A Parallel Execution
Model Based on Hierarchical Omission, Proceedingsof the 48th International Conference on Parallel
Processing (ICPP 2019), August 2019, pp. 77:1–
77:11.
[ 9 ] 八杉昌宏, 小島啓史, 小宮常康, 平石拓, 馬谷誠二, 湯淺太一: L-Closure を用いた真に末尾再帰的な Scheme
インタプリタ, 情報処理学会論文誌 プログラミング,
Vol. 3, No. 5(2010), pp. 1–17.
[10] 八杉昌宏, 平石拓, 篠原丈成, 湯淺太一: L-Closure：
高性能・高信頼プログラミング言語の実装向け言語
機構, 情報処理学会論文誌：プログラミング, Vol. 49,
No. SIG 1 (PRO 35)(2008), pp. 63–83.
[11] 田附正充, 八杉昌宏, 平石拓, 馬谷誠二: L-Closureの呼び出しコストの削減, 情報処理学会論文誌 プログ
ラミング, Vol. 6, No. 2(2013), pp. 13–32.

Sandoe 氏によるパッチが用いられている．その目的の 1 つは，Apple Silicon の Darwin 環境では実行ス
タックを実行可能にすることが禁じられており，トラ
ンポリンの本体を実行スタックではなくヒープに設置することである．

Iain Sandoe 氏のパッチ適用後の GCC 13.3 ソースにさらに本研究の M-closure パッチを当てたところ，ヒープ設置のトランポリンによる条件分岐やインデントの違いで，2 箇所のみ手動でパッチを当てることになったが，ビルドに成功している．また少し話は変わるが，調査の過程で GCC 14.2 ソースに対してもパッチを当ててみたところ，手動でバッチを当てるのは数箇所程度で済みそうである．

4. 3 動作確認
GCC 13.3 改 造 に よ る M-closure 実 装 は ，Intel
Xeon Gold の Ubuntu 20.04 LTS 環境，AMD EPYCの CentOS 7.4 環 境 ，Apple M2 Ultra の macOS

Sonoma 14.6.1 (Darwin 23.6.0) において，M-closureの間接呼び出しを含むプログラムで動作確認した．

5 今後の展望：比較研究へ
今後の展望の 1 つに，M-closure 間の比較研究がある．改造済 GCC-4.6.3 と改造済 GCC-13.3 の比較だ
けでなく，SC-NF プログラムから M-closure モデル
によって本格的に変換された C プログラムを GCC

13.3 でコンパイルした場合と，本研究で再実装した
M-closure（改造済 GCC 13.3 でコンパイルした場合）の比較という「対等に最新の」比較もある．

2 つ目として，L-closure などその他の計算状態
操作機構との比較においても，本研究で再実装した

M-closure を安定した基準的なものとして用いていく．
これらの比較評価は 2. 2 節で利用例として示した

Tascell [2]，HOPE [8]，JAKLD/SC [7] などの高水