From: Nicholas Clark Date: Thu, 17 Apr 2008 15:15:48 +0000 (+0000) Subject: Expand "repack the optree" and add "store the current PAD", which was X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=057163d74a157c94a888de9b58451591c3760f6b;p=p5sagit%2Fp5-mst-13.2.git Expand "repack the optree" and add "store the current PAD", which was something Dave and I talked about 2 weeks ago. p4raw-id: //depot/perl@33708 --- diff --git a/pod/perltodo.pod b/pod/perltodo.pod index 3f15939..7aa819d 100644 --- a/pod/perltodo.pod +++ b/pod/perltodo.pod @@ -883,16 +883,41 @@ See also L. =head2 Investigate PADTMP hash pessimisation The peephole optimier converts constants used for hash key lookups to shared -hash key scalars. Under ithreads, something is undoing this work. See +hash key scalars. Under ithreads, something is undoing this work. See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html +=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 wrt cache-line -filling. The slab allocator could be reused for this purpose. - -http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html +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 +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. +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. + +See http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html + +Note that running this copy, and then freeing all the old location ops would +cause their slabs to be freed, which would eliminate possible memory wastage if +the previous suggestion is implemented, and we swap slabs more frequently. =head2 optimize tail-calls