←back to thread

597 points pizlonator | 1 comments | | HN request time: 0s | source
Show context
gleenn ◴[] No.45134958[source]
> The only "pause" threads experience is the callback executed in response to the soft handshake, which does work bounded by that thread's stack height.

So this is probably not great for functional/deeply-recursive code I guess?

replies(1): >>45134968 #
pizlonator ◴[] No.45134968[source]
Meh.

The stack scan is really fast. There's not a lot of logic in there. If you max out the stack height limit (megabytes of stack?) then maybe that means milliseconds of work to scan that stack. That's still not bad.

replies(1): >>45134985 #
adastra22 ◴[] No.45134985[source]
That's a very long time. Milliseconds of work is an entire frame update-render cycle in a modern game.
replies(3): >>45135001 #>>45135013 #>>45135161 #
pizlonator ◴[] No.45135001[source]
Would your modern game have a stack that is so deep that it brushes up against the stack height limit?

Probably not. Your game would be inches of stack away from crashing

replies(1): >>45135797 #
debugnik ◴[] No.45135797[source]
You're missing the point, they're giving an example of an entire workload that fits into your technique's worst-case overhead. It's could be the right trade-off and rarely be hit, but that worst-case does sound bad.
replies(4): >>45136238 #>>45136432 #>>45136439 #>>45139327 #
1. pizlonator ◴[] No.45139327{3}[source]
Stacks tend to be small enough that the cost of scanning them is minuscule.

(I’m not trying to BS my way here - I’m explaining the reason why on the fly GC optimization almost never involves doing stuff about the time it takes to scan stack. It’s just not worth it. If it was, we’d be seeing a lot of stacklet type optimizations.)