6 ms·
This whole post is nonsense, but there's one point in particular I think that GC advocates don't understand about managing memory. He writes, "Consider: you nee
by joeld42 11y ago
This whole post is nonsense, but there's one point in particular I think that GC advocates don't understand about managing memory. He writes, "Consider: you need to hand out chunks of memory of any size, one at a time, with no advance warning of usage patterns; and then you need to be able to free arbitrary chunks at arbitrary times."
This is entirely wrong. Sure this is true if you're writing a general purpose programming language, but if you're writing an app or a game or a tool, you know the usage patterns because you are building them. You don't need to free things at "arbitrary" times, you free chunks at times when it is appropriate for your problem. You know more about your memory allocation patterns than any general purpose GC could ever know, and so you can write code to fit those better.
In a GC language, often you don't care about where and when the memory comes from, but sometimes you do, and when you do, you're stuck.
- qznc 11y agoYou can put a manual allocator on top of a runtime GC, just like you put it on top of malloc. It is Java where you are stuck. Not GC languages in general.
- efaref 11y agoManual deallocators are more interesting. PJSIP[1] has an interesting approach to this. SIP messages have lots of strings associated with them, are usually relatively short-lived, and typically you'll want to modify these strings or attach new ones. PJSIP does this by hanging a string arena off of each SIP message object. As you add strings to the SIP message, these get appended to the arena, which is grown automatically as and when it needs to be. If you delete a string, it just sticks around in the arena unused. Arena space can also be shared, e.g. if you copy a substring from one SIP header to another, it'll just be referred to twice using a pointer and length. Finally, when you free the SIP message, it just frees the entire arena in one go. [1] http://www.pjsip.org/ http://www.pjsip.org/
- PDoyle 11y agoYes, that kind of "transaction-based" memory management is beautiful in applications where it's appropriate: just leak memory until you're done with the current task, and free it in one chunk. That's hard to beat for performance and simplicity.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- PDoyle 11y agoCheck the title of the article. I'm comparing GC verus malloc+free specifically.