Buffer caching, the technique that never goes away.
GC does not mean your memory management is solved. It means that your memory management works well enough for development and sometimes for undemanding tasks. That said, generational GC can be like mediocre buffer caching "for free." But this still doesn't make all explicit buffer caching go away.
Given that buffer caching is "the techique that never goes away," why isn't some facility for handling this built into the runtimes of languages with GC? You could tell the GC that this particular type of object needs to be cached, with a cache of this size and growth policy, and then programmers never have to write and debug code that does this.
EDIT: Another way to think abut this: because GC is designed to be universal and foolproof, it's easy to get GC into a corner case where its behavior is very suboptimal. In the case of "memory pressure" you can think of this as the GC having to scan the graph of references way more often than it really needs to. However, the optimization techniques for many of these are fairly generic. What if optimization techniques could be built into languages and runtimes, then instrumentation could be used to empirically determine what optimizations are actually needed, then these could be simply "switched on" for particular classes or types.
That shouldn't usually require any explicit support from the runtime; it can exist as library code (and does - for instance Apache Commons: http://commons.apache.org/proper/commons-pool/ ).
> That shouldn't usually require any explicit support from the runtime; it can exist as library code
Well, of course. People writing their own logically implies that such can exist as library code. But if you build in support from the runtime, then it might be possible to squeeze out a bit more performance. For example, perhaps it's possible to tell the GC that certain objects don't have to be considered as roots. (And to the extent that this is possible with current libraries, it's because there is support built into the runtime.)
EDIT: Also, having these mechanisms as library code probably opens up more opportunities for introducing implementation errors.
Generic buffer caching support looks an awful lot like generational GC. It's faster when you hand-roll it because you know how you're going to use the buffers and which buffers are going to be reused.
I'm proposing something that's not quite as foolproof and automatic as generational GC, but more optimal and a lot quicker and safer than hand-rolling. Also something for which profiling is enough to "know how you're going to use the buffers and which buffers are going to be reused."
So basically, take something that's a programming problem and reduce it to "profile, then throw some switches."
If you do everything correctly, not too much. But you can't assume the former. Also, having the thing baked into the language/runtime will encourage use. It's along the lines of what happens with refactoring facilities that aren't part of the browser/editor/ide. They stay "that esoteric thing over there" and don't get used that much.
Is the Go GC Collector not good enough so you have to resort to this?
Would be good if you had the option (like in Java) to specify heap min and max sizes - and if set to the same value your heap would never resize.
GC does not mean your memory management is solved. It means that your memory management works well enough for development and sometimes for undemanding tasks. That said, generational GC can be like mediocre buffer caching "for free." But this still doesn't make all explicit buffer caching go away.
Given that buffer caching is "the techique that never goes away," why isn't some facility for handling this built into the runtimes of languages with GC? You could tell the GC that this particular type of object needs to be cached, with a cache of this size and growth policy, and then programmers never have to write and debug code that does this.
EDIT: Another way to think abut this: because GC is designed to be universal and foolproof, it's easy to get GC into a corner case where its behavior is very suboptimal. In the case of "memory pressure" you can think of this as the GC having to scan the graph of references way more often than it really needs to. However, the optimization techniques for many of these are fairly generic. What if optimization techniques could be built into languages and runtimes, then instrumentation could be used to empirically determine what optimizations are actually needed, then these could be simply "switched on" for particular classes or types.