[gs-code-review] Bug 688602 requires a fundamental change to the memory management.

[Leonardo]

Developers,

Please review comments 6,7 in
http://bugs.ghostscript.com/show_bug.cgi?id=688602

Here I copy them for convenience, with fixing some spelling
and dropping obsolete parts.




------- Additional Comment #6 From leonardo 2006-04-03 03:18 ------- 
I agree that from revision 5980 the document renders slowly. But before
revision 5980 the algorithm was simply incorrect.

Now we understand better why 'invisible' save levels were introduced for. 
The
purpose is exactly to save time from restoring 'l_new' flags during 
'restore'.
Therefore the 3d paragraph of the 5980 log message is not quite correct : 
the
mentioned comment does document the assumption done (rather in some 
inaccurate
way), and the code corresponds to it, but the assumption appears incorrect.

The 1st paragraph of the 5980 log message correctly documents the problem :
"the memory manager left it unreleased until a further 'restore' does that.
However that instance pointed to a gx_path instance with a bigger 'save' 
level.
So when the garbager was invoked, the gs_show_enum instance had a 'path' 
field
pointed to a structure, which was already released by a 'restore'.".


------- Additional Comment #7 From leonardo 2006-04-03 03:35 ------- 
Well, here is a solution, which I'd like to discuss before trying to 
implement.

1. When a 'ref' array is allocated, add 'alloc_change_t' elements for
each 'ref' element. This stores addresses of related 'l_new' flags into
the 'changes' list.

2. After (1) the function save_set_new simplifies : all that it needs is to
call save_set_new_changes.

3. Before (2) 'invisible' save levels encapsulate newly allocated 'ref'
elements, which need to scan for restoring 'l_new' marks. After (2) they
encapsulation isn't useful.

4. To restrict the time for restoring 'l_new" marks, we'll restrict
save_set_new_changes with a reasonable part of the list. Here we can 
implement
same logic as before revision 5980 : count restored marks and restrict the
scanning when the counter is too big (see max_repeated_scan in the old 
code).

5. Now we suggest to do (1), drop 'invisible' levels, and improve
save_set_new_changes as explained in (4) (probably with adding a new field 
into
gs_ref_memory_t, which points to 'stopping' element of the 'changes' list.
The consequences are :

A. Some longer 'changes' list due to inserting new elements for each newly
allocated 'ref' element. (Possible optimization : add 'length' field into
alloc_change_t for representing 'ref' arrays with a single alloc_change_t
instance; The 'length' field may be packed into 'offset' using values 
<= -3 ).

B. Some smaller memory consumption due to not introducing extra 'inner' 
chunks
with 'invisible' save levels. Leo.