graphersal/graphersal は Rust で書かれたインメモリグラフデータベース兼 Gremlin トラバーサルエンジンだ。ブラウザのプレイグラウンドと CLI、AI エージェント向けの MCP サーバー、Python バインディングを同居させている。2026 年 11 月 3 日のコミット 9de2d54 が GQL 評価器のスタック使用量の問題を修正した。ソースは https://github.com/graphersal/graphersal/commit/9de2d54 である。
`=~` の正規表現マッチリンクが再帰的に下へ進む compile_chain と eval_chain に分岐を 1 つずつ増やし、最適化されていないビルドでは分岐ごとに一時値用のスタックスロットが残る。その結果、ネストが 1 段深くなるごとにスタックが約 540 バイトずつ増え、深くネストされた式を検証する deep_expressions_evaluate_without_overflow テストが、Windows CI の debug ビルドで 512 KiB に設定されたスレッドスタックを超えてスタックオーバーフローを 발생させた。
このコミットは、 trist XPS の使用頻度が低いリンク（`=~`、`IS LABELED`、`IS SOURCE / DESTINATION OF`、スライス）を compile_rare_link と rare_link に分離し、それぞれ独立したフレームでコンパイルおよび評価するように変更した。コミットメッセージが示す macOS debug の計測値では、そのテストのスタック使用量は 450 KiB だった。`=~` を入れる前は 452 KiB、`=~` を入れたときは 484 KiB であり、ネストされたサブスクリプトのケースは 386 KiB、修正前は 401 KiB だった。
ただし、この数値は macOS debug の 1 つの環境での計測値であり、最適化ビルドでも同じ症状が発生したかどうかは記録されていない。変更は crates/graphersal/src/gql/eval.rs の 1 ファイルにおける 79 行（56 行追加、23 行削除）であり、GQL のクエリ意味はそのままなのでユーザーから見える機能変化はない。つまり公開されている根拠は debug ビルドでのスタック使用量だけ，因而、リリースビルド性能への影響は判断が早い。