Am 21.09.2014 13:57, schrieb Mark Morgan Lloyd:
Marco van de Voort wrote:
Basically you only need an own heapmanager that allocates all
allocations
in-order from a 16MB block, and mark and release procedures that
call that
heapmanager and are declared in some unit preloaded wiht -Fa?
The main issue is that dynamic memory is used by the Prolog
implementation in several different ways. The first way is that as
rules are being entered, they go into memory and usually stay there.
The second way is that as queries are evaluated a lot of temporary
stuff (variable bindings etc.) is put into memory, this is all
thrown away on completion. The third way is that during query
evaluation, rules could potentially be added/deleted/changed which
shouldn't be thrown away.
How does this work in TP? Mark/release would remove all variables,
not just
the temprary ones. Or are the persistent and temporary orders not
mixed, and
is only the temporary part under mark/release?
In the current code, it doesn't attempt to change the rules. So
according to discussion with the author a few years ago, provided that
there was enough memory to evaluate the query everything could be
thrown away once the results were returned. However it's been written
with garbage collection which kicks in when available heap drops below
a certain amount (this in itself is problematic on the general case),
and which is intimately aware of TP's heap structure.
I have a library done for other projects which supports
memory management routines, where the memory allocations
may belong to different classes of memory, and then you are able
to free all memory belonging to one class with one single call.
That is, there are calls similar to C-malloc, calloc, realloc and free,
but a class identifier is added to every call. And there is one additional
freeall() call to free the entire memory class.
The routines outperform the normal ANSI C functions on certain systems.
although they put a layer of management on top of the normal ANSI C
functions
(because many calls to allocate little areas of memory result to one
call of
the ANSI C function to allocate a large area and some internal
management ...
I used this approach to make my XML parser faster than others ... and the
freeall() call at the end of the parsing makes XML parsing safe; the working
storage of the parser is freed, but the resulting DOM tree, for example
- if you use DOM - ,
is not ... it resides in a different memory class).
This is written in C, but it should of course be callable from FP as well;
there are no architecture dependencies. It runs on Windows, OS/2, Linux
and even on z/Arch mainframes (so does the XML parser).
Please contact me offline, if you are interested. Maybe you could use it
with your PROLOG project, if you are able to "classify" the memory
allocations
in the PROLOG code.
Kind regards
Bernd
_______________________________________________
fpc-other maillist - fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
