get rid of stack check prolog

193 views
Skip to first unread message

Shawn Landden

unread,
Apr 27, 2015, 9:17:11 AM4/27/15
to golan...@googlegroups.com
couldn't we eliminate the contiguous stack prologue if we instead had maintained a table of stack canary pages and then added a SIGSEGV handler that could call __morestack()?

Dave Cheney

unread,
Apr 27, 2015, 9:20:21 AM4/27/15
to golan...@googlegroups.com
Possibly, that is how the JVM does it, but the stack check prolog is also used for preemption (sort of like a safe point), and in general usage the stack check is predictable by the cpu, so effectively free.

Dmitry Vyukov

unread,
Apr 27, 2015, 9:46:50 AM4/27/15
to Dave Cheney, golang-nuts
In fact current stack split check is against static branch prediction
rules of modern CPUs (i.e. "forward branch is not taken").
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Dave Cheney

unread,
Apr 27, 2015, 9:47:41 AM4/27/15
to Dmitry Vyukov, golang-nuts
Whups. That sounds like something that should be fixed.

Shawn Landden

unread,
Apr 27, 2015, 4:55:30 PM4/27/15
to golan...@googlegroups.com

On Monday, April 27, 2015 at 6:20:21 AM UTC-7, Dave Cheney wrote:
Possibly, that is how the JVM does it, but the stack check prolog is also used for preemption (sort of like a safe point), and in general usage the stack check is predictable by the cpu, so effectively free.
 Considering that we always schedule on a potentially blocking operation do we really need this level of preemption? We can always force using at least 2 kernel threads even on 1-cpu systems so that even an intense inner-loop wont prevent the kernel from scheduling other threads. I mean with the thread model we are using we can never do priorities.

Ian Lance Taylor

unread,
Apr 27, 2015, 5:32:48 PM4/27/15
to Shawn Landden, golang-nuts
On Mon, Apr 27, 2015 at 1:55 PM, Shawn Landden <shawnl...@gmail.com> wrote:
>
> On Monday, April 27, 2015 at 6:20:21 AM UTC-7, Dave Cheney wrote:
>>
>> Possibly, that is how the JVM does it, but the stack check prolog is also
>> used for preemption (sort of like a safe point), and in general usage the
>> stack check is predictable by the cpu, so effectively free.
>
> Considering that we always schedule on a potentially blocking operation do
> we really need this level of preemption?

It measurably reduces the length of time that the GC has to wait for
all threads to acknowledge a phase change. This is because it is no
longer necessary to wait for the goroutine to make a potentially
blocking operation, it is only necessary to wait for the goroutine to
make a function call. Even that is not perfect, of course, and there
has been discussion off and on of checking for preemption in backward
branches in possibly long-running or infinite loops.

Ian

Ian Lance Taylor

unread,
Apr 27, 2015, 5:33:12 PM4/27/15
to Dave Cheney, Dmitry Vyukov, golang-nuts
On Mon, Apr 27, 2015 at 6:47 AM, Dave Cheney <da...@cheney.net> wrote:
> Whups. That sounds like something that should be fixed.

Yes. It should be easy to fix. Gccgo gets it right. Want to open an issue?

Ian

Dave Cheney

unread,
Apr 27, 2015, 5:37:46 PM4/27/15
to golan...@googlegroups.com, da...@cheney.net, dvy...@google.com


On Tuesday, 28 April 2015 07:33:12 UTC+10, Ian Lance Taylor wrote:
On Mon, Apr 27, 2015 at 6:47 AM, Dave Cheney <da...@cheney.net> wrote:
> Whups. That sounds like something that should be fixed.

Yes.  It should be easy to fix.  Gccgo gets it right.  Want to open an issue?

Reply all
Reply to author
Forward
0 new messages