From: Aron Bartle (abartle++at++de-solutions.com)
Date: 06/14/2000 15:12:42
Hello,
This email is a follow-up to my earlier pfdLoadFile question email "pfdLoadFile crashes when
out-of-memory".
I understand now my problem was caused by memory fragmentation -- due to a geometry paging
implementation based on pfdLoadFile/pfdSaveFile.
As others have noted, repetitively pfdLoad'ing and deleting geometries results in the following
arena behaviour:
* The amount of space in free blocks steadily grows
* The arena grows to its requested size, then crashes with an out-of-memory error
As Angus and others have noted, amallopt can be used to improve the situation by setting M_MXCHK
to a large value and setting M_FREEHD to 1. However, what I am noticing is in my app those
changes just _temporarily_ delay the subsequent exhaustion of the arena and crash.
___
My questions now are:
* Is it possible to improve pfdLoadFile so that fragmentation is not as bad? Maybe by
allocating larger chunks of memory?
* Is there a geometry paging capability in the works for a future release of performer?
* Is it completely ridiculous to expect I can get a paging system to work using pfdLoadFile?
o Maybe making geometry paging happen at a larger granularity would help? (i.e. paging
20 geometries instead of paging 200 geometries).
* (My original question) Is it too much to not crash the application when pfdLoadFile fails
in a memory allocation?
Thanks for your help!
-Aron
-- Aron Bartle, Software Architect abartle++at++vrco.com 757.858.2800
This archive was generated by hypermail 2b29 : Wed Jun 14 2000 - 15:00:17 PDT