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

In C, how do you know if the dynamic allocation succeeded?

lemire.me

Post reply on HN
Print view View original

171–180 of 198 posts

Re: In C, how do you know if the dynamic allocation succeeded?

#171

Post by Hendrikto »

lokedhs wrote: post #157
pcwalton wrote: post #69

Earlier quoted context omitted.

> wouldn't you just account the COW pages against the parent until they are copied? That's what Linux does. But how do you return ENOMEM when the copy does happen and now the system is out of memory? Memory writes don't return error codes. The best you could do is send a signal, which is exactly what the OOM killer does.

That's why you ensure you have enough swap to cover the worst case scenario. You as swap not because you need to actually use it, but on order to be able to guarantee there is enough memory available if the worst case scenario happens. In normal circumstances, swap should never really be utilised.

> You as swap not because you need to actually use it […] In normal circumstances, swap should never really be utilised.

Swap is actually there so anonymous pages can be evicted, and is often used long before there is memory contention, during normal operation.

Not having swap means that only file-backed pages can be evicted. During memory contention, this can cause thrashing. During "normal" operation, it degrades performance.

Swap only being used when memory runs out, as kind of "emergency RAM", is a very widespread misunderstanding.

Re: In C, how do you know if the dynamic allocation succeeded?

#172

Post by asgeir »

agumonkey wrote: post #167
davidw wrote: post #14

This is why some embedded systems don't do malloc (IIRC...been a while since I've read much about those).

I'd love to see how people design software with fully static memory (and limited one at that)

You can find a number of technical deep-dives for classic video game consoles where people have had do deal with very limited resources.

This video springs to mind as one example: https://www.youtube.com/watch?v=tfAnxaWiSeE

Re: In C, how do you know if the dynamic allocation succeeded?

#173

Post by KronisLV »

kaba0 wrote: post #147
KronisLV wrote: post #145

Earlier quoted context omitted.

> At work we have microservices crashing 20 times a week but SLOs are not affected since traffic is routed to surviving pods. This probably makes a lot of people have strong negative emotions, but at the same time i feel that you're not wrong and it's the only way to deal with the modern web dev, where clients/business push for features instead of quality, versus something like kernel/system software development, whe…

> Knowing why that happens would be nice, of course, but no one actually has the time to address those. More than likely bad user code. Perhaps even race conditions. But in case of the JVM, with flight recorder and other forms of logging you could find out the problem with quite a good chance. Which version of the JVM do you use?

> ...you could find out the problem with quite a good chance.

It's not that it's impossible to do so due to technical limitations. Even without JFR, there's still VisualVM and any number of APM solutions, like JavaMelody, Apache Skywalking, Stagemonitor etc.

It's rather a problem of telling the clients/business:

  Hey, look, for the next X days/weeks i won't be developing any new features or tending to your user stories, but instead will attempt to track down this persistent, yet somewhat hard to reproduce problem. 
  And because of limitations in place that pertain to accessing production environments, this process will likely take much longer than it otherwise should, especially in case of blocking synchronous communications when asking for production logs or heap dumps, which are sometimes wrongly exported after the server restart, which makes them meaningless.
  Alternatively, i will spend a similar amount of time attempting to first get the application instrumented and then we'll run into similar challenges regarding the access permissions for those, before returning to the aforementioned attempts to debug and solve the application issues, because adding instrumentation doesn't magically solve those.
Depending on the environment that you work in, this proposition might either be accepted, you might also find yourself fighting an uphill battle, or people might just look at you like you have two heads and without having proper backing support of the other engineers you'll find yourself for critiqued both for wasting the time on debugging with no guarantees of actual payoff in the end, as well as the application quite possibly still not working.

I'm actually in the middle of implementing an APM solution to hopefully give better insights into how the application works, but in many of the environments out there this will be a Catch 22: https://www.merriam-webster.com/dictionary/catch-22

So, if you have control over the application from day one instead of being onboarded into a maintenance project with SRE not having been a concern throughout its development, consider building for failure - treat it as a "when?" question instead of "whether?" and do what you can to mitigate the actual user impact even when components may fail.

Horizontal scaling is one way to achieve that, and a pretty decent one, as long as you don't attempt to scale your single source of truth.

Re: In C, how do you know if the dynamic allocation succeeded?

#174

Post by astrobe_ »

jimbob45 wrote: post #28
andi999 wrote: post #7

This has nothing to do with C. The problem/feature is with the systemcall that does the allocation, and any language has to use it.

Is your issue that the system call doesn't return enough diagnostic information? If so, how would you have done it differently? I'm asking out of curiosity, not out of a reflexive instinct to defend C (which has many problems).

The first thing that comes to mind is a "reliable" (that won't overcommit) memory allocation syscall, but one might fear that it will abused (everyone wants the best stuff even if they might not use it after all). The second thing that comes to mind is to able to probe a (virtual) address (address range) within your addressing space, to check if it's actually there without doing weird stuff, and eventually just wait until it becomes available. But at this point maybe you could just use file-backed mmap for big data (effectively managing your own swap space)?

Re: In C, how do you know if the dynamic allocation succeeded?

#175

Post by lmilcin »

tsimionescu wrote: post #131
lmilcin wrote: post #37

Earlier quoted context omitted.

Yeah. And the issue is that the actual problem happens sometime later when the application actually tries to use that memory. So you replaced an error that is relatively simple to handle with something that is impossible to handle reliably. So the operating system very much doesn't like to admit it doesn't have physical memory to back the area you are trying to use. Now it does not have a simple way to signal this to…

Interestingly, Linux's OOMKiller actually gives you (the sysadmin or system designer) more control over what happens when the system is low on memory than disabling overcommit. In a system without overcommit, every process is taking memory out of the shared pool, until some random process is the unlucky one that can't allocate more. In a happy case, that unlucky process also has some data that it can let go of. But t…

It is a tradeoff.

With overcommit disabled, the program will fail in a more predictable way. Moreover, if it allocates the memory successfully nothing bad can happen to it later. So you have the option to allocate the memory right at the startup of your program and be sure it is not going to fail later.

With overcommit enabled you technically have more memory to work with. You could say that if the program has to fail anyway, then it might be better if it fails later at a higher memory usage.

Re: In C, how do you know if the dynamic allocation succeeded?

#176

Post by lmilcin »

foobarian wrote: post #112
floxy wrote: post #24

Earlier quoted context omitted.

Don't leave us hanging. The "obvious" answer would seem to be "yes" because of swap. But if everyone gets that wrong...

It's a vague question though. What kind of OS? What kind of runtime? Does "allocate" mean call malloc() and get non-null return value?

If you can point all that stuff out I will already be a little happier as an interviewer. Most people just say "no".

Re: In C, how do you know if the dynamic allocation succeeded?

#177

Post by dezgeg »

rurban wrote: post #153
kibwen wrote: post #21

Earlier quoted context omitted.

The answer is that you kind of can't. You're at the mercy of the OS to give you accurate information, and malloc as an interface isn't set up to distinguish between virtual memory and "actual" memory. We could imagine a separate interface that would allow the OS to communicate this distinction (or hacks like you allude to), but I don't know of any standard approach.

libsigsegv. Used to catch out of memory errors to start a major GC.

Hmm, I don't think that one would help with OOM killer termination either.

Re: In C, how do you know if the dynamic allocation succeeded?

#178

Post by agumonkey »

asgeir wrote: post #172
agumonkey wrote: post #167

Earlier quoted context omitted.

I'd love to see how people design software with fully static memory (and limited one at that)

You can find a number of technical deep-dives for classic video game consoles where people have had do deal with very limited resources. This video springs to mind as one example: https://www.youtube.com/watch?v=tfAnxaWiSeE

cool, I should dig about that sub topic too.

Re: In C, how do you know if the dynamic allocation succeeded?

#179

Post by EdSchouten »

atfzl wrote: post #158

This made be curious to check the real and virtual memory of some processes on my laptop (MacBook Air M1). The real memory size of Safari is ~160MB but virtual memory size is 392GB which doesn't look right. I checked other processes and all the processes have similar virtual memory size which is around ~390GB. I wonder if this is a bug in Activity Monitor or the virtual memory allocations really are this big for each…

That’s likely because of the dyld shared cache.

Re: In C, how do you know if the dynamic allocation succeeded?

#180

Post by Const-me »

bscphil wrote: post #138
dahart wrote: post #124

Earlier quoted context omitted.

But this feature is also why malloc on Windows can take a long time to return - seconds or more if you malloc too much. I recently bumped into this problem on the GPU. Since GPU memory in the Windows Display Driver Model requires it to be backed by the host machine’s virtual memory, a malloc on the GPU when running low on space can end up searching & even defragging virtual memory to satisfy the request. Crazy! Just…

> Since GPU memory in the Windows Display Driver Model requires it to be backed by the host machine’s virtual memory Wow, this seems really unintuitive to me, especially on a OS that doesn't overcommit. Is it as unintuitive as it sounds, or is there a good reason for this?

> is there a good reason for this?

Multitasking.

User can easily alt+tab into another program which also uses GPU. When many processes are using GPU concurrently, it's possible their combined VRAM use exceeds the amount of physical memory available on the GPU.

Post reply on HN