From 2723c0fb189e0e7ba1d917fdb4a00e30bf979b62 Mon Sep 17 00:00:00 2001 From: Father Chrysostomos Date: Thu, 12 Jul 2012 12:40:32 -0700 Subject: [PATCH] todo.pod: Clean up entries related to op slabs Note about storing the current pad with the ops: If each slab belongs to a CV (which is the case), then we would only ever walk the slab to free its ops when the CV itself is freed. When that happens, the pad is about to freed anyway, so freeing pad entries for each op is unnec- essary, and has probably always been so. Note that cv_undef actually sets PL_comppad and PL_curpad to null before freeing ops, to avoid having to have them point at the right pad, and probably also to avoid the unnecessary overhead of tracking which pad entries are available for reuse. --- Porting/todo.pod | 33 +++------------------------------ 1 file changed, 3 insertions(+), 30 deletions(-) diff --git a/Porting/todo.pod b/Porting/todo.pod index 27ccded..e1a057a 100644 --- a/Porting/todo.pod +++ b/Porting/todo.pod @@ -438,19 +438,6 @@ suggest evictions and promotions to achieve a better F. One piece of Perl code that might make a good testbed is F. -=head2 Allocate OPs from arenas - -Currently all new OP structures are individually malloc()ed and free()d. -All C implementations have space overheads, and are now as fast as -custom allocates so it would both use less memory and less CPU to allocate -the various OP structures from arenas. The SV arena code can probably be -re-used for this. - -Note that Configuring perl with C<-Accflags=-DPL_OP_SLAB_ALLOC> will use -Perl_Slab_alloc() to pack optrees into a contiguous block, which is -probably superior to the use of OP arenas, esp. from a cache locality -standpoint. See L. - =head2 Improve win32/wince.c Currently, numerous functions look virtually, if not completely, @@ -1009,29 +996,15 @@ implement per-thread working directories: Win32 already does this. See also L. -=head2 Store the current pad in the OP slab allocator - -=for clarification -I hope that I got that "current pad" part correct - -Currently we leak ops in various cases of parse failure. I suggested that we -could solve this by always using the op slab allocator, and walking it to -free ops. Dave comments that as some ops are already freed during optree -creation one would have to mark which ops are freed, and not double free them -when walking the slab. He notes that one problem with this is that for some ops -you have to know which pad was current at the time of allocation, which does -change. I suggested storing a pointer to the current pad in the memory allocated -for the slab, and swapping to a new slab each time the pad changes. Dave thinks -that this would work. - =head2 repack the optree Repacking the optree after execution order is determined could allow removal of NULL ops, and optimal ordering of OPs with respect to cache-line -filling. The slab allocator could be reused for this purpose. I think that +filling. I think that the best way to do this is to make it an optional step just before the completed optree is attached to anything else, and to use the slab allocator -unchanged, so that freeing ops is identical whether or not this step runs. +unchanged--but allocate a single slab the right size, avoiding partial +slabs--, so that freeing ops is identical whether or not this step runs. Note that the slab allocator allocates ops downwards in memory, so one would have to actually "allocate" the ops in reverse-execution order to get them contiguous in memory in execution order. -- 1.8.3.1