pacc logo
pacc v0.3: Memory management

Next: , Previous: , Up: Top   [Contents][Index]


20 Memory management

The parsing engine generated by pacc allocates a fair amount of memory. (To parse pacc.pacc itself on a 64-bit architecture, pacc allocates around 3.5MB of memory.) If a memory allocation call fails, the parsing engine writes the message ‘pacc: panic: out of memory’ to stderr and exits non-zero.

When you call pacc_destroy(), all memory allocated by the parsing engine itself is freed.

For any real application, semantic expressions will need to allocate memory to build an AST. Most of the time, pacc only calls the semantic expressions it needs, once the parse is complete. As long as you correctly free the AST you should be fine.

Semantic guards are problematic, though: they are called, along with any expressions needed for variable bindings, during the parse. This may well result in memory being allocated that may not be referenced by the AST that is finally built. Currently there is no way to free such memory. This is a hard problem to solve, since the results calculated while evaluating semantic guards will be reused for the final result if they are needed.

The parsing engine written by pacc uses only realloc() to allocate memory, and free() to free memory. We avoid malloc() by observing that malloc(x) is equivalent to realloc(0, x). The intention is to make it slightly easier to supply your own memory allocator: it need only implement the realloc() and free() interfaces (although of course it must be prepared to accept ‘0’ as the first argument to realloc()).

For example, if you want the parsing engine to use the Boehm garbage collector, include the following in the preamble of your grammar.

#include <gc.h>
#define realloc(x,s) (GC_REALLOC((x),(s)))
#define free(x) ((void)x)

Next: , Previous: , Up: Top   [Contents][Index]

Last updated: 2016-08-03 21:39:50 UTC

News

Porting and packaging

One thing pacc needs is more users. And, perhaps, one way to get more users is to reduce the friction in getting started with pacc. An obvious lubricant is packaging. Read More...

Release relief

Looking at _pacc_coords(), I noticed that it seemed to have the same realloc() bug that I'd just fixed in _pacc_result(). However, the "list of arrays" trick really wasn't going to work here. Read More...

See more news articles

feed