5 ms·
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 you
by usefulcomment 14y ago
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".
- qznc 14y agoIn 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.