I've noticed others posit various ideas on using #undef as a sort of manual 
GC in pov SDL, and was wondering if there is any documentation reflecting 
what it would be effective with generally, if even there IS a general use 
condition, or if it is only efficacious on a per situation basis.

Does pov perform GC on your code effectively (based on #undef docs, it looks 
like it does not), or do you need to explicitly call GC for certian 
scenarios?

For instance, would it be appropriate to call #undef on seperately #declared 
arrays used in a positioning macro after it has reached #end, instead of 
allowing pov to GC after parsing of the entire file completes?

ian

Post a reply to this message

[GDS|Entropy] <gds### [at] hotmailcom> wrote:
> Does pov perform GC on your code effectively (based on #undef docs, it looks 
> like it does not), or do you need to explicitly call GC for certian 
> scenarios?

  I'm not sure the term "garbage collection" can be applied to the SDL at
all. There's no way to "leak memory", in other words, allocate memory and
then drop all reference to it without ever freeing it.

  Each identifier name corresponds to some object in memory (not talking
about POV-Ray objects here). You can't have multiple references to the
same object, nor can you "drop" all references to some object and leave
the object unreachable.

  It may be possible to explicitly free memory with #undef (I have to admit
I don't know what #undef does internally), but that's not really related to
"garbage collection", which is the act of collecting all memory to which
there is no references anylonger.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   It may be possible to explicitly free memory with #undef (I have to admit
> I don't know what #undef does internally), but that's not really related to
> "garbage collection", which is the act of collecting all memory to which
> there is no references anylonger.

As a matter of fact, that's just a modern flavor of what garbage collection
actually describes.

More generally, garbage collection is any act of re-organizing data on a heap in
order to improve various aspects heap performance, most notably (a) total memory
available for allocation, (b) maximum memory available for a single allocation,
(c) performance of memory allocation, and (d) performance of future garbage
collection acts.

Re-claiming "memory to which there is no reference any longer" is only the most
popular aspect of all these, probably because with most programming languages
it is the only aspect on which the programmer has any influence. Everything
else is happening behind the scenes.

Also note that "memory to which there is no reference any longer" is a
misleading description: Even the garbage collector cannot re-claim memory to
which there is no reference any longer. That's the stuff memory leaks are made
of.

A more precise description would be "collecting memory which is no longer
*needed* for the purpose it was allocated for". Some languages require the
programmer to think about and explicitly make known to the GC when a previously
allocated memory block is no longer needed (see free() in C, or dispose in C++),
only some will use reference counters to (attempt to) automatically detect this.

So when invoking #undef, if POV would free() (or disposes) the memory holding
the related object, garbage collection would indeed be triggered.

Post a reply to this message

Just stepped through the code, so I can now give a definite answer:

* POV does indeed release memory occupied by any #define'd thing the very moment
it is #undef'd (rested for a #define'd mesh2; I presume the same holds true for
#local's, and other types of data).

* After parsing and before rendering, POV implicitly #undef's everything.

* Re-#define'ing a thing implicitly #undef's the old content, too.

Note that this is true even for objects that have been "invoked" someplace; this
is possible because such "invocations" actually create a copy. (Some "bulk"
objects like meshes share data between copies, but lifetime of this shared data
is governed by a reference counter.)

So the benefits of #undef I see are as follows:

- Improve parsing speed by keeping the identifier table small (might be an issue
if the number of identifiers significantly exceeds about a hundred, at which
time the 257-entry hash table will start to get "saturated")

- Keep memory footprint as low as possible during parsing

- Avoid potential pitfalls when different parts of the scene file happen to use
the same identifier

I think these apply mainly to macro suites: You never know how many other
memory-hungry, identifier-rich macro suites may be used alongside yours in a
scene file; for instance, any non-#local variable used to temporarily hold an
array to resize it should be #undef'd immediately after use, and any non-#local
variable holding a building block for a complex CSG should be #undef'd as soon
as the complete object is assembled.

On the other hand, especially for macro suites, even better than using #undef is
using #local wherever possible.

For an actual scene file, I think the cases where use of #undef will save your
day are rather scarce. E.g. If you do a lot of array resizing, you'll probably
re-use the same temporary variable anyway, or even use a macro to do the job.

Post a reply to this message