Re:The D Garbage Collector
by nickpsecurity on Tuesday March 21, 2017 @12:29AM
(#13919885)
Well, there's the moderate in the discussion! Many good points made on each side but that's a great point. There's been software like JX operating system that varied GC's on a per-component basis. There was also software such as Oberon work that mixed no-GC components with GC'd OS and tools. Exploring options that aren't all latency or throughput GC... including ability to eliminate GC effect in that... might lead to new paths that are exciting.
Outside this sub-field, another one that offers evidence of your opinion is static analysis vs dynamic checks. Full, memory safety for C programs originally required crazy overhead (300+% sometimes) with checks on all the things that could happen. Then, people started mixing static analysis with dynamic checks and clever architectures to reduce that overhead. They'd often use static analysis to determine when they could eliminate checks. I can see something similar happening with GC's where an analysis helps avoid bad operations. We already have a taste of it with Rust where we get some safety without GC.
Outside this sub-field, another one that offers evidence of your opinion is static analysis vs dynamic checks. Full, memory safety for C programs originally required crazy overhead (300+% sometimes) with checks on all the things that could happen. Then, people started mixing static analysis with dynamic checks and clever architectures to reduce that overhead. They'd often use static analysis to determine when they could eliminate checks. I can see something similar happening with GC's where an analysis helps avoid bad operations. We already have a taste of it with Rust where we get some safety without GC.