Change 27406: Two more TODOs for those with C knowledge.

[nwc10+ (Nicholas Clark)]

Change 27406 by ***@entropy on 2006/03/07 19:31:49

Two more TODOs for those with C knowledge.

Affected files ...

... //depot/perl/pod/perltodo.pod#132 edit

Differences ...

==== //depot/perl/pod/perltodo.pod#132 (text) ====
Index: perl/pod/perltodo.pod
--- perl/pod/perltodo.pod#131~27404~ 2006-03-07 11:23:14.000000000 -0800
+++ perl/pod/perltodo.pod 2006-03-07 11:31:49.000000000 -0800
@@ -372,6 +372,31 @@
might want to determine what ops I<really> are the most commonly used. And in
turn suggest evictions and promotions to achieve a better F<pp_hot.c>.

+=head2 Shrink struct context
+
+In F<cop.h>, we have
+
+ struct context {
+ U32 cx_type; /* what kind of context this is */
+ union {
+ struct block cx_blk;
+ struct subst cx_subst;
+ } cx_u;
+ };
+
+There are less than 256 values for C<cx_type>, and the constituent parts
+C<struct block> and C<struct subst> both contain some C<U8> and C<U16> fields,
+so it should be possible to move them to the first word, and share space with
+a C<U8> C<cx_type>, saving 1 word.
+
+=head2 Allocate OPs from arenas
+
+Currently all new OP structures are individually malloc()ed and free()d.
+All C<malloc> 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.
+



End of Patch.

[Dave Mitchell]

Post by nwc10+ (Nicholas Clark)
+=head2 Allocate OPs from arenas

Erm, isn't the code already there, if PL_OP_SLAB_ALLOC is defined?

[Nicholas Clark]

Post by Dave Mitchell

Post by nwc10+ (Nicholas Clark)
+=head2 Allocate OPs from arenas

Erm, isn't the code already there, if PL_OP_SLAB_ALLOC is defined?

Er. I thought. I'd not looked at that.

And then, no, that's not what I was thinking about. It seems to allocate all
kinds of ops from a big slab of memory, and has fairly complex routines to
knock it down into chunks of the correct size. I was thinking of how the SV
body arena code works, which has 1 slap per type, and maintains a free list
for each type, which makes freeing and reallocation much simpler, and
allocation a bit simpler than the slab code.

Nicholas Clark

[Nicholas Clark]

Post by Nicholas Clark

Post by Dave Mitchell

Post by nwc10+ (Nicholas Clark)
+=head2 Allocate OPs from arenas

Erm, isn't the code already there, if PL_OP_SLAB_ALLOC is defined?

Er. I thought. I'd not looked at that.
And then, no, that's not what I was thinking about. It seems to allocate all
kinds of ops from a big slab of memory, and has fairly complex routines to
knock it down into chunks of the correct size. I was thinking of how the SV
body arena code works, which has 1 slap per type, and maintains a free list
for each type, which makes freeing and reallocation much simpler, and
allocation a bit simpler than the slab code.
Nicholas Clark

If I got you right, youre thinking of arena_roots for UNOPs, BINOPs,
PMOPs, COPs etc, from which OP-trees are built. This sounds bad from a
cache proximity standpoint, despite the relative simplicity vs the
OP_SLAB_ALLOC stuff.

Yes, I was thinking that.

OP_SLAB_ALLOC is not the default currently, and I doubt anyone is really
using it in production. Given how it never re-uses memory until it frees the
slab, I suspect it also uses more memory than the current (default) malloc()/
free() implementation, because I suspect it's unlikely that all ops in a slab
get freed.

Nicholas Clark