Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Allocation

samwho.dev

Post reply on HN
Print view View original

161–170 of 182 posts

Re: Memory Allocation

#161

Post by rents »

BHSPitMonkey wrote: post #156
pvorb wrote: 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

This links does not work, typo?

Re: Memory Allocation

#162

Post by klabb3 »

spatter wrote: 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?

Re: Memory Allocation

#163

Post by alex7734 »

vlovich123 wrote: post #141
EvanAnderson wrote: post #124

Earlier quoted context omitted.

In Hyper-V it's fairly easy. You make a virtual serial port ("COMPort"), set the bootloader to enable kernel debugging over serial, then connect to the virtual serial port from the host via a named pipe. https://learn.microsoft.com/en-us/windows-hardware/drivers/d... I haven't tried it with vSphere but I suspect it'd be similar.

Delphi 7 was 2002. Was hyper-v around back then? Or is this just a legacy app still running?

It's a legacy app

Re: Memory Allocation

#164

Post by BHSPitMonkey »

rents wrote: post #161
BHSPitMonkey wrote: post #156

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

This links does not work, typo?

Forgot to make it public. Fixed now!

Re: Memory Allocation

#165

Post by ogurechny »

sylware wrote: post #103
devit wrote: post #47

The article claims that an allocator that splits memory based on allocation size is called a "buddy allocator". That's misleading: an allocator that allocates an area for each size class is usually called a "slab allocator", while a "buddy allocator" is one that when needed subdivides a memory area with a power of two size into two half-sized areas that are "buddies", does so recursively to satisfy allocations, and c…

linux had a bitmap based "buddy allocator" (power of two), now it is not bitmap based anymore (complexity not worth it anymore, performance wise, namely simplicty was restored). Then linux has various slabs(slub/slob/slab), built on top of the "buddy allocator". Userlevel code shoud use non virtual address stable mmap-ed regions (slabs + offsets). Legacy "libc" services were built as virtual address stable services..…

In this case, one should start with implementing -Xmx switch, then gradually adding the rest.

Re: Memory Allocation

#167

Post by [deleted] »

derefr wrote: post #149
AshamedCaptain wrote: post #118

Earlier quoted context omitted.

> Until Windows 95, everything was just happening in one shared address space, in real mode. In fact, it was only in Windows 3.1 where user applications stopped running in ring 0! Windows 3.0 and predecessors runs in processor which had no concept of "ring 0", so that should not be surprising at all... > Your application wasn't even a "process" per se I think this is a bit of a "modernistic", "win32y" view of the def…

> you can launch multiple instances of a module, each of them can allocate memory separately I don't think this is true, though? You're not getting separate processes ; you're just getting separate hInstances . Which don't map cleanly to a process-like abstraction. Consider: while you can (in theory) spawn multiple copies of a Win16 executable, with each spawn getting its own hInstance and therefore its own locals he…

[deleted]

Re: Memory Allocation

#168

Post by xigoi »

alberth wrote: post #60

While 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.

An animated gif would be annoying since you can't pause it to look at it carefully.

While I also hate the overuse of JavaScript, this is exactly how it's meant to be used – adding small bits of interactivity to documents.

Re: Memory Allocation

#169

Post by xigoi »

samwho wrote: post #14
ModernMech wrote: post #13

This is wonderful! I'm definitely going to be sharing this with my students (college sophomores studying CS). If I were to make some suggestions, based on how I know they would receive this: - I would make explicit reference to heap and stack. Students who are learning this material are learning about the heap/stack dichotomy, and I think it would really improve the exposition to make clear that not all memory is all…

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.

Re: Memory Allocation

#170

Post by secondcoming »

jacobsenscott wrote: post #137
secondcoming wrote: post #26

Earlier quoted context omitted.

> Now, who owns inner_struct? return_struct does since it is the only thing that knows the address. > Who is responsible for freeing it? return_struct is, unless you hand that responsibility over to something else. > Do I free it when I assign to it? Yes, unless you want leaks. > I think if we could visualise memory as cars on a road, we would see obvious traffic jams. That visualisation is helpful for threads, where…

A struct can't own something - it isn't a class with a destructor or anything. So it isn't quite so obvious. There are only two lines of code here, but the implication is a function is running that code and then returning `return_struct`, which might get passed around to more functions, and even returned further up the call stack. Somewhere there needs to be code that knows "hey - nobody else is using return_struct,…

The implementor of return_struct provides a destroy() function, and because you’re in C land, the programmer knows when to call it.
Post reply on HN