On Wed, Sep 16, 2015 at 1:18 AM, Anders Oleson wrote:
>
> How difficult is it to modify the prologs that get generated? I think
> I found the code that does that in i386.c and i386.md, but it is
> pretty cryptic to me. Any pointers? I know exactly what I want the
> assembler to look like. If so I
...
>> Summary:
>> prolog overhead, no call to __morestack : < 1 clock
>> stock call to __morestack (hot): > 4000 clocks
>> without signal blocking: < 60 clocks
>> potential best case: < 6 clocks
>
> This sounds great.
The data structure I was experimenting with ended up to be not very
dif
> It's not so much allowing signal handlers to be split stack. It's handling
> the case of a signal occurring while the stack is being split. That is not
> so very unlikely, and it will crash your program, as you get a SIGSEGV while
> trying to handle whatever signal just arrived.
I see. In w
> I can tell you a lot about the Go stack-copy implementation, I worked on a
> lot of it.
Thanks! Keith. I appreciate the insight.
> The big advantage is that you only have to copy once (amortized). The stack
> grows as big as you need it and then you don't need to do any more work from
> the
On Sat, Sep 12, 2015 at 11:38 PM, Anders Oleson wrote:
>
> From examining the __morestack code, I found that the sigprocmask
> system call is being called (twice?!) per __morestack, even when it
> should just need to switch to the next allocated segment. I did read
> the reason for that change: to
I can tell you a lot about the Go stack-copy implementation, I worked
on a lot of it. The big drawback is that you need to ensure that you
have accurate stack maps for all frames on the stack. This is
something we can do in Go with some work but would be more problematic
for C. Most of that work
I have been experimenting with -fsplit-stack, in particular related to
performance issues I have read about in rust and go relative to a "hot
split" where a function call in a tight loop continuously crosses a
split. Originally I was interested as an analogy to approximate
performance issues with o
