Status: Accepted
Owner: ----
New issue 2847 by [email protected]: Convert parser into push/pull parser
http://code.google.com/p/lilypond/issues/detail?id=2847
Using
%define api.push-pull both
would create both push and pull parsers with the current interface. It may
be that one can only make use of the push parser and will have to take the
pull parser implementation (then based on the push parser) and modify it
appropriately.
A push parser keeps its inner state not on the call stack, but rather in a
separate data structure on the heap. This includes the semantic value
stack which would need to get included in garbage collection manually,
calling scm_gc_mark on all its values (meaning that the parser object would
likely be part of the Lily_parser structure). This means accessing the
internals of the parser object, making the code depend on the Bison version
compiling it.
The advantage is that only the active areas of the parser stack will then
be actually marked during garbage collection which is both more efficient
than conservative marking of the call stack (containing the whole
_prospective_ area used as a stack) as well as not prone to marking lots of
stale stack entries. While LilyPond exits the parser for garbage
collection between independent jobs of one run, it does not do so while
reading large input files.
Not relying on the stack marking conservative collection also means that
things won't go horribly wrong in case the stack-based initial stack is too
small and the parser decides to relocate it to the heap.
