Hi Ralph,
alloca is a stupid workaround for forcing Windows to call its own chkstk (check stack or something) function. Windows allows the stack growing only in page sizes, usually 4k. So if you allocate, lets say 64k stack, chkstk goes down and touches all 4k pages one by one, and Windows happly extends the stack for the function. However, this is a waste of CPU work if the stack has already grown, but still you cannot detect it other than touching the pages all the time...
I.e:
void f() { char array[65536]; }
for (i = 0; i < 10000; ++i) f();
Compare its speed on Linux and Windows. You will surprise.
Regarding your other question: alloca is still necessary, if you create a regular expressions which contains thousands of capturing brackets and some other constructs, since their last value is stored on the real machine stack.
However, you can replace the alloca to "char array[SLJIT_MAX_LOCAL_SIZE]" which forces the maximum amount of allocatable stack for the JIT, 64K now (unfortunately this slows things down a bit). Or call chkstk somehow (I know it has a different name under MinGW than VisualC++). Or during the program initialization, call a function which allocates the total allowed stack space, which makes chkstk unnecessary.
Regards,
Zoltan
Ralf Junker <ralfjunker@???> írta:
>I am using PCRE in an environment where alloca() is not available.>
Unfortunately, JIT calls alloca() in sljitNativeX86_common.c, line 446.>
>
As far as I understand, this call makes sure that enough stack space is>
available. I experimented and found that alloca() is not necessary for>
all pattern matches. I removed the alloca() call and JIT ran fine on>
X86_32 but not on X86_64. However, if I provide a custom stack with>
pcre_assign_jit_stack(), it runs well on both architectures even with>
alloca() removed.>
>
Questions:>
>
* Is alloca() really not needed if a custom stack is provided?>
>
* Would it be possible to replace alloca() with simple malloc() / free()?>
>
Ralf>
>
-- >
## List details at
https://lists.exim.org/mailman/listinfo/pcre-dev >
