1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
What is mig-alloc-reform?
1. A massive simplification of the memory management in Tcl core.
a. removal of the Tcl stack, each BC allocates its own stacklet
b. TclStackAlloc is gone, replaced with ckalloc; goodbye to sometimes
hard sync problems
c. removal of the allocCache slot in struct Interp
d. retirement of the (unused) Tcl allocator USE_TCLALLOC; replacement
with a single-thread special case of zippy
e. unify all allocator options in a single file tclAlloc.c
d. exploit fast TSD via __thread where available (autoconferry still
missing, enable by hand with -DHAVE_FAST_TSD)
f. small improvements in zippy's memory usage:
. try to split blocks in the shared cache before allocating new
ones from the system
. use the same bucket for Tcl_Objs and smallest allocs
2. New allocator options
a. purify build (but stop using them, see below). This is suitable to
use with a preloaded malloc replacement
b. (~NEW) native build: call to sys malloc, but maintain zippy's
Tcl_Obj caches (per thread, if threads enabled). Can be switched to
run as a purify build via an env var at startup. This is suitable to
use with a preloaded malloc replacement. The threaded variant is new.
c. zippy build
d. (NEW) multi build: this is a build that can function as any of the
other three. Per default it runs as zippy, but can be switched to
native or purify via an env var at startup. May or may not be used
for deployment, but it will definitely be very useful for
development: no need to recompile in order to valgrind, just set an
env var!
How do you use it? Options are:
1. Don't pay any attention to it, build as always. You will get the same
allocator as before
2. Select the build you want with compiler flags
-DTCL_ALLOCATOR=(aNATIVE|aPURIFY|aZIPPY|aMULTI)
3. Select behaviour at startup: native can be switched to purify, multi
can be switched to any of the others. Define the env var
TCL_ALLOCATOR when starting up and you're good to go
** PERFORMANCE NOTES **
* do enable HAVE_FAST_TSD on threaded build where available! Without
that it is probably slower than before. Note that __thread is not
available on macosx, but the "slow" version should be quite fast there
(or so they say)
* not measured, but: purify, native and zippy builds should be just as
fast as before. The obj-alloc macros have been removed while
developing. It is not certain that they provide a speedup, this will
be measured and acted accordingly
* multi build should be a only a tad slower, may even be suitable as
default build on all platforms
* zippy stats not enabled by default, -DZIPPY_STATS switches them on
** TO DO LIST **
* DEFINITELY
- test like crazy
- timings: versus older version (in unthreaded, fast-tsd and slow-tsd
builds). Determine if the obj-alloc macros should be reenabled
- autoconferry to auto-detect HAVE_FAST_TSD
- autoconferry to choose allocator flags? Keep USE_THREAD_ALLOC and
USE_TCLALLOC for back compat with external build scripts only (and
set them too!), but set also the new variants
TCL_ALLOCATOR=(aNATIVE|aPURIFY|aZIPPY|aMULTI)
- Makefile.in and autoconferry changes in windows, mac
- choose allocators from the command line instead of env vars?
- verify interaction with memdebug (should be 'none', but ...)
* MAYBE
- build zippy as malloc-replacement, compile always aNATIVE and
preload alternatives
|
