Nicholas Clark wrote:
For starters, in glossary.pod I'm failing to find definitions for
"destruction" and "finalisation". One is about cleanup actions on objects/
PMCs that need something actively cleaned up, rendering active objects down
to bare memory, and the other is about reclaiming bare memory for re-use.
1) destruction: low-level object cleanup like free(3) of malloced memory
2) finalisation: high-level, user-visible, overridable, e.g. close DB
connection
For starters, I'm interested in the first one - rendering down active objects
to bare memory, whatever it's called. I'm also not directly interested in
"high priority DOD" for "timely destruction" of hot objects. What I want to
know is
does parrot make any guarantee that all objects will be rendered down to
bare memory before program exit?
Parrot calls the "destroy" vtable function for all PMCs that have marked
themselves with PObj_active_destroy_FLAG, when the object gets recycled
due to GC *or* at program exit.
There is no finalise or finalize vtable function yet. I think that these
two task should be distinct
At interpreter exit perl 5 scans all the active allocated scalars to find
objects, and causes all references to them to be undefined, which will cause
DESTROY to be called on all of them. This will even catch objects trapped in
reference counting loops.
I presume this is the DESTROY {} user hook. That should probably be
called from VTBAE_finali[sz]e before VTABLE_destroy. What about ordering
these calls?
Second question is that optionally perl 5 can run with complete global
destruction. This is primarily intended for embedded interpreters, where
the default implementation (just exit the process to free all memory) is
clearly not an option. Does parrot have any sort of built in ability to
change mode to force all memory ever allocated to be freed up?
parrot --leak-test # or the same:
parrot --destroy-at-end
should free all memory allocated (but doesn't yet).
Nicholas Clark
leo
