| ▲ | What is malloc doing, anyway?(benmandrew.com) |
| 73 points by benmandrew 4 hours ago | 13 comments |
| |
|
| ▲ | assumed_throwaw 2 hours ago | parent | next [-] |
| Tangential, but the complexity and over-head of the malloc abstraction is precisely what made me very intrigued by "stack-only" languages, such a recently published Goose. There is something very elegant and exciting about the idea of (almost) completely getting rid of it. Just as modern programming languages have developed good ergonomics that replaces a garbage collector, the same could hopefully be done to replace heap-allocated memory. |
| |
| ▲ | smashspectacle 33 minutes ago | parent | next [-] | | This is actually what first drew me to zig. Most people talk about error handling, but the explicit allocator handling and making choosing an allocator a deliberate consideration has pushed me to better coding habits in general. I don't think it is possible or practical to completely abandon heap-allocated memory, but explicitly choosing between allocation types and styles that most precisely fit a job has great potential for meeting that spirit. | |
| ▲ | jacquesm 35 minutes ago | parent | prev | next [-] | | Most stack oriented languages also have a heap. | |
| ▲ | nialv7 2 hours ago | parent | prev [-] | | the stack is just a bump allocator. the unique thing about stack-only languages is lifetime management, not really how they allocate. | | |
| ▲ | saagarjha an hour ago | parent [-] | | A stack only language that called into malloc to service allocations would not be very interesting. |
|
|
|
| ▲ | wpmaven an hour ago | parent | prev | next [-] |
| I found this one very well explained time ago, for those looking for more details: https://sploitfun.wordpress.com/2015/02/10/understanding-gli... |
| |
|
| ▲ | TZubiri an hour ago | parent | prev | next [-] |
| like many C functions you must remember that C is not low level, you won’t learn how memory is allocated by inspecting malloc() anymore than you would learn how characters are printed to the screen by reading printf() or how a file is written by reading write(). you will only learn about the thin or heavy wrapper that C is responsible for, the real magic is happening in the kernel and the device firmware |
| |
| ▲ | foobarian 27 minutes ago | parent | next [-] | | Disagree, I found malloc source useful, and writing a toy allocator especially useful because you learn about the brk() syscall which is a great breadcrumb into kernel land and a great bridge to connect the memory mapping lessons from computer architecture with application code. | | |
| ▲ | stevekemp 13 minutes ago | parent [-] | | Depending on how low-level you're going, you don't even need to call brk. My toy stop/copy GC and allocation routines just have this: %define HEAP_SIZE (4 * 1024 * 1024 * 1024)
.section bss
;;
;; Two heaps so we can flip-flop between them
;;
heap_a:
resb HEAP_SIZE
heap_a_end:
heap_b:
resb HEAP_SIZE
heap_b_end:
Of course there are other syscalls involved in my compiler/runtime, but for memory allocations the static area sufficed for me. |
| |
| ▲ | Someone 33 minutes ago | parent | prev [-] | | Malloc needs the kernel to obtain memory, but in any reasonable implementation (you do not want to make a syscall for every malloc and free) is mostly user space, and studying that will tell you a lot about how your malloc works. |
|
|
| ▲ | amelius 2 hours ago | parent | prev [-] |
| If the DRAM scarcity continues, not much. |
| |
| ▲ | xnickb an hour ago | parent [-] | | It's a consumer market scarcity. Since you're supposed to run everything on rented hardware, own nothing and be happy, I'd expect the malloc to be the right place to invest into once it is IPO. |
|
