Hacker News Reader

Comment by usefulcomment | Hacker News Reader

> The deep call stack problem exists in any kind of parallelism.

Consider an event-based server that returns to an event loop whenever it makes a blocking call. At any point in time, most of the active requests will have a call stack depth of zero, and the rest will have just the frames since they were last unblocked. Contrast that with a threaded server where a request occupies a single, deeper stack for its lifetime.

Or consider an actor-based system where an actor has just a few responsibilities and communicates with other actors with messages. Contrast with a threaded system where the server's submodules have to communicate with function calls.

I don't see how stack depth matters much, though. There are way more important considerations.

View on HN

> I don't see how stack depth matters much, though.

You knew someone would say it so I will: it matters on RAM-constrained systems. I'm currently working on a CPU with 384K flash (a lot) and 48K RAM (not quite enough).

Many systems in this class use preemptive multi-tasking OSes in a shared, non-virtual memory space. The question how to pre-allocate stack space is tricky. One non-traditional model is to use run-to-completion threads without stack switching so the problem reduces to estimating your overall worst-case stack usage.

Another popular model is main-loop + interrupt handlers. In a lot of ways that's more like an actor model.

Fair enough, I can see how it matters on low memory systems. The article says it's even worse than just stack memory, too, as the live stack frames screw up your dead object detection for up to 25% extra memory overhead.

My thoughts were:

1) As we enter the massively multicore era, there will be much bigger fish to fry than a little memory overhead. Clock speeds have topped out while transistor counts are still growing exponentially. Exponential means soon application programmers will be tasked with keeping 100s, then 1000s of cores busy. It's gonna be a giant challenge for PL guys, systems guys, and app guys to make that happen. If an improved concurrency model can get us there, then 25% memory overhead one way or the other will be relatively insignificant.

2) The object liveness issue is an implementation detail of one particular VM. There's nothing but CPU cost preventing VM writers from being a little more clever and marking objects unreachable if they are only referenced by dead local vars in otherwise live stack frames. I don't know enough about it to know whether the CPU cost would be prohibitive, but the issue seems more nuanced than just "threads => deep stacks => +25% mem".

In my opinion the number of cores is kind of a red hering. The actually hard problem is about memory access. A 1000 core system is either NUMA with potentially very big latencies or cache-incoherent. The NUMA approach offers backwards compatibility, but dropping cache-coherence provides more flexibility since the memory partitioning can be changed dynamically.

Also, segmented stacks (http://llvm.org/releases/3.0/docs/SegmentedStacks.html). GCC already supports it.

Reply on news.ycombinator.com