Add ordering of "global" variables to TODO

[perl5.git] / pod / perltodo.pod

diff --git a/pod/perltodo.pod b/pod/perltodo.pod
index 771740e..4fec644 100644 (file)
--- a/pod/perltodo.pod
+++ b/pod/perltodo.pod
@@ -256,11 +256,70 @@ such that it's trivial for the Pumpking to flag "this is an official release"
 when making a tarball, yet leave the default source saying "I'm not the
 official release".
 
 when making a tarball, yet leave the default source saying "I'm not the
 official release".
 

+=head2 Ordering of "global" variables.
+
+F<thrdvar.h> and F<intrpvarh> define the "global" variables that need to be
+per-thread under ithreads, where the variables are actually elements in a
+structure. As C dictates, the variables must be laid out in order of
+declaration. There is a comment
+C</* Important ones in the first cache line (if alignment is done right) */>
+which implies that at some point in the past the ordering was carefully chosen
+(at least in part). However, it's clear that the ordering is less than perfect,
+as currently there are things such as 7 C<bool>s in a row, then something
+typically requiring 4 byte alignment, and then an odd C<bool> later on.
+(C<bool>s are typically defined as C<char>s). So it would be good for someone
+to review the ordering of the variables, to see how much alignment padding can
+be removed.
+

 =head2 bincompat functions
 
 There are lots of functions which are retained for binary compatibility.
 Clean these up. Move them to mathom.c, and don't compile for blead?
 
 =head2 bincompat functions
 
 There are lots of functions which are retained for binary compatibility.
 Clean these up. Move them to mathom.c, and don't compile for blead?
 

+=head2 am I hot or not?
+
+The idea of F<pp_hot.c> is that it contains the I<hot> ops, the ops that are
+most commonly used. The idea is that by grouping them, their object code will
+be adjacent in the executable, so they have a greater chance of already being
+in the CPU cache (or swapped in) due to being near another op already in use.
+
+Except that it's not clear if these really are the most commonly used ops. So
+anyone feeling like exercising their skill with coverage and profiling tools
+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 emulate the per-thread memory pool on Unix
+
+For Windows, ithreads allocates memory for each thread from a separate pool,
+which it discards at thread exit. It also checks that memory is free()d to
+the correct pool. Neither check is done on Unix, so code developed there won't
+be subject to such strictures, so can harbour bugs that only show up when the
+code reaches Windows.
+
+It would be good to be able to optionally emulate the Window pool system on
+Unix, to let developers who only have access to Unix, or want to use
+Unix-specific debugging tools, check for these problems. To do this would
+involve figuring out how the C<PerlMem_*> macros wrap C<malloc()> access, and
+providing a layer that records/checks the identity of the thread making the
+call, and recording all the memory allocated by each thread via this API so
+that it can be summarily free()d at thread exit. One implementation idea
+would be to increase the size of allocation, and store the C<my_perl> pointer
+(to identify the thread) at the start, along with pointers to make a linked
+list of blocks for this thread. To avoid alignment problems it would be
+necessary to do something like
+
+  union memory_header_padded {
+    struct memory_header {
+      void *thread_id;   /* For my_perl */
+      void *next;        /* Pointer to next block for this thread */
+    } data;
+    long double padding; /* whatever type has maximal alignment constraint */
+  };
+
+
+although C<long double> might not be the only type to add to the padding
+union.
+