Source Files
Public Interface
- ckalloc
- attemptckalloc
- ckfree
- ckrealloc
- attemptckrealloc
- Tcl_Alloc
- Tcl_AttemptAlloc
- Tcl_Free
- Tcl_Realloc
- Tcl_AttemptRealloc
- Tcl_DbCkalloc
- Tcl_AttemptDbCkalloc
- Tcl_DbCkfree
- Tcl_DbCkrealloc
- Tcl_AttemptDbCkrealloc
- Tcl_GetMemoryInfo
- Tcl_ValidateAllMemory
- Tcl_DumpActiveMemory
- Tcl_InitMemory
Private Interface
- TclInitAlloc
- TclFinalizeAllocSubsystem
- TclFinalizeMemorySubsystem
- TclpAlloc
- TclpFree
- TclpRealloc
- TclFreeAllocCache
- TclThreadAllocObj
- TclThreadFreeObj
- TclFinalizeThreadAlloc
- TclFinalizeThreadAllocThread
- TclpSysAlloc
- TclpSysFree
- TclpSysRealloc
- TclInitDbCkalloc
- TclDumpMemoryInfo
Directly Depends On Public Interface Of
- Threads
- Panic
- Object System and Fundamental Object Types
- Parsing and Evaluation
- Pathname Management
- Conversions From String
- Filesystem Access
- stdio.h
- ctype.h
- string.h
Directly Depends On Private Interface of
Discussion
This module handles dynamic allocation and free of memory.
The largest defect is that Tcl_Alloc takes an unsigned int argument for the number of bytes to allocate, limiting the allocation size to 4 Gib. An allocator without such a low limitation must be part of Tcl 9.
A surprising feature for many is that Tcl_Alloc panics on an allocation failure. The alternative Tcl_AttemptAlloc exists for those who wish to choose it, but much of Tcl rests on foundations that will be ripped away in any out-of-memory situation.
Many coders behave as if the performance of these memory allocators is a burden to be avoided. The pooling system for Tcl_Obj, and the whole TclStack* scheme of stack-patterned allocation are indications that significant lengths are gone to in order to avoid calls to Tcl_Alloc. An allocation system that behaved acceptably well in the first place might lead to a great deal of code simplification.
As it currently exists, this is not so much a module as it is a collection of alternative modules. There are at least 3 allocation systems here, and each one may be overlaid with memory debugging facilities. The combination you get in Tcl_Alloc is controlled by a set of compiler directives at the time the Tcl_Alloc is compiled. This leads to a significant problem that not all configurations are mutually compatible. This means it's not all that hard to get into a situation where extensions and applications are functionally incompatible because they've been compiled with different directives. This is often described as "memdebug extensions only work in memdebug interps", but the problem may well be more far-reaching than that.
It's a bit of an inelegance that the forms of the routines that support re-configuration into memory debugging forms are the *ck* so that code using the Tcl library is encouraged to call ckalloc rather than Tcl_Alloc.
At least some parts of Tcl's memory management exhibit a high water mark behavior where freed memory is not actually released to the system, but retained by libtcl for later re-allocation. This is a poor fit for those programs that have very large, but very temporary memory demands. It's not clear to me whether that (mis-)behavior originates in this module, but a later wiki editor can revise this into a more definitive statement.
Some branches exploring reforms in this module include
The dependency data above indicates a dependency on many other modules, but that is due to the debugging layer. Separating this module into two parts, one for debugging, the other just for the fundamental operations, the latter depends only on Tcl_Panic and Threads and the system routines for memory management.