Front page | perl.perl5.porters |
Postings from April 2012
["bulk 88", thanks for diagnosing that the problem on Win32 is with the realloc() when creating new mortals. This is useful knowledge.] On Mon, Apr 23, 2012 at 10:08:18AM +0100, Dave Mitchell wrote: > On Sun, Apr 22, 2012 at 04:04:12PM +0200, demerphq wrote: > > This is a known issue, windows realloc did/does not extend segments. > > It always copies. IIRC we (nicholas) did a patch to SvGROW to > > ameliorate this. Maybe growing the stack by 10% each time would reduce > > it. This is the underlying Win32 runtime realloc that has this wonderful "feature" of always copying? Or something layered on top of it? > Since 5.005_03, the tmps stack has been grown in chunks of 128 up to 512, > then in chunks of 512 after that. Given that the perl "malloc" for ithreads & fork emulation already ends up returning pointers "incompatible" with the system malloc thanks to the tracking header, would it be sensible to investigate defaulting Win32 to using perl's malloc.c? (With -DPERL_SBRK_VIA_MALLOC so that the win32 system malloc supplies the "raw" memory that malloc.c partitions) It seems crazy to have to keep putting in place work arounds for what is a solved problem. Nicholas Clark PS I looked to see whether it would be viable to replace the contiguous mortal stack into chunks. It seems that a little too much of the core assumes that it is a stack to make this easy. And dammit, why are we pandering to crap code? This is makework.Thread Previous | Thread Next