It's somewhat incomplete without a discussion of how one actually gets the memory allocate to a program.
Memory Allocation
61–70 of 182 posts
Re: Memory Allocation
#62Love the dog. A bit like the “Cool Bear” asides in Amos’s articles (fasterthanli.me), a chance to pause & consolidate.
Don't tell Amos, but Cool Bear is the inspiration for Haskie, my little husky companion.
Re: Memory Allocation
#63While I do like the article, I wish it simply used multiple images and/or animated gifs (instead of javascript) for the pictorials. It would make the site much more accessible and clear in the event you didn't realize you had to click forward.
The accessibility of this technique is something that greatly worries me. I try and be quite thoughtful about things like colour palette. I'm not sure how to achieve the level of interactivity I want while still being accessible to screen readers, without writing two completely separate articles with and without JavaScript.
Definitely open to ideas.
Re: Memory Allocation
#64Thanks. Well written and presented.
Re: Memory Allocation
#65It's somewhat incomplete without a discussion of how one actually gets the memory allocate to a program.
Could you elaborate on what you mean?
Re: Memory Allocation
#66Oh, if only I had this in college! This is a fantastic explanation.
Re: Memory Allocation
#67Thank you for this, this is helpful. I wrote a JIT compiler and I didn't bother calling free much, I just let the operating system free up all allocated memory. I got into this situation often: return_struct = do_something(mystruct); return_struct->inner_struct = malloc(sizeof(struct my_inner_struct)); Now, who owns inner_struct? Who is responsible for freeing it? Do I free it when I assign to it? I feel this ownersh…
> You have to be extra careful when memory is managed by a different language runtime.
While it would be nice to have next to no overhead for FFI, it's not always tractable. That's why you have to serialize across boundaries, the same as if you're serializing across processes or the network. At least in a single virtual memory space you can have a caller allocate a buffer and the callee fill it, with the caller being responsible for deserializing and freeing later. That gets you pretty far, and is relatively safe.
The alternative is to be callee managed, and for the callee to return things by handle and not necessarily by pointer, but that is also fraught.
Re: Memory Allocation
#68Oh, if only I had this in college! This is a fantastic explanation.
[1] is not very far from that. IMHO, [1] it is better.
Re: Memory Allocation
#69Glad there are always talent people and great guide like him/this exist! Great people and guides will help tremendous learners along the way, timeless, priceless.
Re: Memory Allocation
#70All credit goes to my wonderful friend Sam Who: https://twitter.com/samwhoo He recently published a similar guide on load balancing that is equally intuitive and insightful: https://samwho.dev/load-balancing/ I can't wait to see what he puts out next!
https://news.ycombinator.com/item?id=35588797
We never missed good things lol!