Devotd Github
새 소식RAG/검색

graphersal/graphersal — Gremlin 평가기 스택 프레임 축소

graphersal/graphersal의 최신 커밋이 정규식 링크 때문에 커진 GQL 평가기 재귀 프레임을 별도 함수로 분리해 debug 빌드 스택 오버플로를 막았다.

저장소 정보graphersal/graphersal ↗

graphersal/graphersal의 최신 커밋이 정규식 링크 때문에 커진 GQL 평가기 재귀 프레임을 별도 함수로 분리해 debug 빌드 스택 오버플로를 막았다.

GitHub 설명: In-memory graph database and Gremlin traversal engine in Rust: browser playground, CLI, MCP server for AI agents, durable store, Python bindings.

스타
★ 15
포크
0
언어
Rust
라이선스
Apache-2.0
최신 릴리스
v0.1.1
원문 보기 ↗GitHub에서 보기 ↗

graphersal/graphersal은 Rust로 만든 인메모리 그래프 데이터베이스이자 Gremlin 순회 엔진이다. 브라우저 플레이그라운드와 CLI, AI 에이전트용 MCP 서버, 파이썬 바인딩을 함께 담고 있다. 2026년 11월 3일 커밋 9de2d54가 GQL 평가기의 스택 사용량 문제를 고쳤다. 소스는 https://github.com/graphersal/graphersal/commit/9de2d54 다.

`=~` 정규식 매칭 링크가 재귀적으로 내려가는 compile_chain과 eval_chain에 분기를 하나씩 늘렸고, 최적화되지 않은 빌드에서는 분기마다 임시값용 스택 슬롯이 남는다. 그 결과 중첩 한 단계마다 스택이 약 540바이트씩 자라, 깊게 중첩된 식을 검사하는 deep_expressions_evaluate_without_overflow 테스트가 Windows CI의 debug 빌드에서 512 KiB로 설정된 스레드 스택을 넘겨 스택 오버플로가 발생했다.

커밋은 드물게 쓰이는 링크(`=~`, `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 한 환경의 측정값이고, 최적화 빌드에서 같은 증상이 나타났는지는 기록되어 있지 않다. 변경은 crates/graphersal/src/gql/eval.rs 한 파일의 79줄(56줄 추가, 23줄 삭제)이며 GQL의 쿼리 의미는 그대로여서 사용자에게 보이는 기능 변화는 없다. 즉 공개된 근거는 debug 빌드의 스택 사용량뿐이어서 릴리스 빌드 성능에 미칠 영향은 판단하기 이르다.