Live data from Hacker News

Memory Allocation

samwho.dev

171–180 of 182 posts

Re: Memory Allocation

#171
post #162
post #58

> Others will return what's called a "null pointer", a special pointer that will crash your program if you try to read or write the memory it points to. This is not strictly true, it depends on the environment you're using. Some older operating systems and some modern embedded systems have memory mapped at the zero address.

If we’re gonna be pedantic, isn’t memory mapping itself an optional property? Ie you can have a pointer to 0x00..00 refer to the actual physical bytes at that address, without any mapping, no?

You may be thinking of a different kind of memory mapping. I believe spatter is thinking of memory-mapped hardware.

Re: Memory Allocation

#172
post #162
post #58

> Others will return what's called a "null pointer", a special pointer that will crash your program if you try to read or write the memory it points to. This is not strictly true, it depends on the environment you're using. Some older operating systems and some modern embedded systems have memory mapped at the zero address.

If we’re gonna be pedantic, isn’t memory mapping itself an optional property? Ie you can have a pointer to 0x00..00 refer to the actual physical bytes at that address, without any mapping, no?

Sure, there can be physical memory at address zero, there can be virtual memory at address zero. (Most modern operating systems and programming tools place a deathtrap for misbehaving code there instead.) There can be no physical memory at address 0 at all, though it is uncommon, and other gaps in addresses. RAM can technically start elsewhere, and lower part of memory can be taken by ROM or other hardware. (For example, see how authors of breadboard computers reason about the choice of system memory layouts and address line operation.) NULL value itself can be different from zero. Therefore, C standard defines nothing about null pointer dereferencing.

On the other hand, most people expect the usual layout that grows from zero upwards. CPU designers are people, too, and make similar assumptions about layout and operation of memory (if they have to), which then affect systems that use their processors. Also, with all its compatibility, C still presumed certain class of hardware. It was not invented as a language for every microprocessor and microcontroller and each odd memory model, the microcontroller evolution was instead affected by alignment with coding in C.

This ugly hack (using the same object to hold the address value that can be operated on, and its own validity information) might be the most well known.

Re: Memory Allocation

#173

Earlier quoted context omitted.

So basically garbage collection via just terminating and letting the OS handle it?

Yes, this is what Ur/Web does albeit this is limited to Web Server requests. I'd argue all programs could be short lived and memory management becomes a matter of sizing program's scope/role to the amount of memory you can greedily consume. Certainly many sorting program (for e.g.) can leak until they terminate. Then, cheap instantiation and communication between programs.

That's no different than writing a traditional program and using big arena allocators for everything instead of individual allocations, except it's more complicated for no apparent reason.

Re: Memory Allocation

#174
post #169
post #14

Earlier quoted context omitted.

Really appreciate you taking the time to write this, thank you. I tried a couple of different ways to introduce the stack and the heap but it always felt like it made the post too long and complicated. In the end I decided to take a pure, idealistic view of memory in order to focus on the algorithms used to pack allocations effectively. You can see some of my abandoned efforts as HTML comments in the post :D Introduc…

Is it really necessary to use hexadecimal at all in the article? Decimal works just fine for pointers, it's just not conventionally used.

I went back and forth on this and decided in the end that it makes sense to use hex for 2 reasons:

1. It's what people are going to be exposed to in any material outside of this post. 2. Within this post, it helps distinguish between pointers and sizes/values.

Re: Memory Allocation

#175
post #147

Earlier quoted context omitted.

I think it's a nice little example for "Explorable Explanations", a term coined by Bret Victor in his eponymous essay[1] from 2011. [1]: http://worrydream.com/ExplorableExplanations/

I've been admiring this trend since I started seeing these kinds of essays posted here, and felt motivated to start collecting them in a curated list[0]. Happy to accept new entries or volunteers to help maintain it! [0] https://github.com/BHSPitMonkey/awesome-explanations

Would you be open to suggestions? Off the top of my head, there's Explorable Explanations from https://ncase.me and, while not as educational, The Space Elevator on https://neal.fun

Re: Memory Allocation

#176

When writing C, I tend to avoid calling malloc and free directly. * https://github.com/DaveJarvis/mandelbrot/blob/master/memory.... I then apply this same principle of "opening" and "closing" structures throughout the application. Generally, I can quickly verify that the calls are balanced: * https://github.com/DaveJarvis/mandelbrot/blob/master/threads... What's nice about this pattern is that the underlying implemen…

Interesting.

As a very minor point, calling free(NULL) is well-defined and safe so there is no need for the if-statement in memory_close(). This is very clearly stated in the manual page [1] for instance:

If ptr is a null pointer, no action shall occur.

[1]: https://man7.org/linux/man-pages/man3/free.3p.html

Re: Memory Allocation

#178
It would have been nice if I had seen this article before refactoring a Java project into a C project, where learning memory allocation rules in order to use C was a painful process for me :(

Re: Memory Allocation

#179

Earlier quoted context omitted.

I've been admiring this trend since I started seeing these kinds of essays posted here, and felt motivated to start collecting them in a curated list[0]. Happy to accept new entries or volunteers to help maintain it! [0] https://github.com/BHSPitMonkey/awesome-explanations

Would you be open to suggestions? Off the top of my head, there's Explorable Explanations from https://ncase.me and, while not as educational, The Space Elevator on https://neal.fun

Definitely, Issues or PRs would be splendid. Though, I've had a hard time finding similar essay-like deep dives that fit this pattern on https://explorabl.es (I see a lot of what seem to be just an individual specialized simulation, games, or traditional e-learning courses), and the Space Elevator page feels like more of an interactive visualization in my opinion (though still very cool)

Re: Memory Allocation

#180
post #176

When writing C, I tend to avoid calling malloc and free directly. * https://github.com/DaveJarvis/mandelbrot/blob/master/memory.... I then apply this same principle of "opening" and "closing" structures throughout the application. Generally, I can quickly verify that the calls are balanced: * https://github.com/DaveJarvis/mandelbrot/blob/master/threads... What's nice about this pattern is that the underlying implemen…

Interesting. As a very minor point, calling free(NULL) is well-defined and safe so there is no need for the if-statement in memory_close(). This is very clearly stated in the manual page [1] for instance: If ptr is a null pointer, no action shall occur. [1]: https://man7.org/linux/man-pages/man3/free.3p.html

> calling free(NULL) is well-defined and safe

Probably showing my age. SunOS 4, PalmOS, and 3BSD reputedly crashed. (There were also double free exploits back in 1996.)

This further illustrates my point, though: Removing the NULL check is a single conditional to remove, as opposed to littering the free + guard everywhere. In effect, by isolating duplicated pieces of logic, it keeps possibilities open.

Post reply on HN