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

Memory leak proof every C program

flak.tedunangst.com

Post reply on HN
Print view View original

131–140 of 175 posts

Re: Memory leak proof every C program

#131

Post by Too »

junon wrote: post #85
tombert wrote: post #80

Earlier quoted context omitted.

I had a friend who worked for one of the big Market Makers, and he told me that they would indeed turn the GC off, but what they'd do is just pre-allocate everything into bigass arrays before-hand, and have incrementers to simulate the "new" keyword. They might do this in something more or less like a threadlocal to avoid having to deal with locks or race conditions or anything like that.

This is called bump or arena allocation, depending on how you want to define it.

Sometimes also referred to as Object pools.

Re: Memory leak proof every C program

#132

Post by kitd »

h0l0cube wrote: post #126
zlsa wrote: post #109

Earlier quoted context omitted.

Related: the Ariane 5 rocket failed on its maiden flight because it reused code from its predecessor, which made an assumption that didn't apply to the higher-performance Ariane 5. https://en.wikipedia.org/wiki/Ariane_flight_V88

Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.

IIRC it was the higher acceleration value of Ariane5 that the old code wasn't expecting that caused the problem. Some fuzz testing could have worked, I suppose.

Re: Memory leak proof every C program

#134

Post by skrebbel »

tonyedgecombe wrote: post #49
skrebbel wrote: post #42

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.

Are you saying PHP creates a new process for each request?

Depends on the setup, but even when it doesn't, it mallocs a huge chunk of memory at the start, lets the script run, allocate away and never free anything. Then, when the script is done, it frees the whole chunk in one fell swoop.

So for some definition of “process” it holds regardless - it’s just not always a real OS process.

They added GC at some point to allow scripts to run longer (eg for websocket servers) but even then last I checked you had to manually enable it.

Re: Memory leak proof every C program

#135

Post by subtra3t »

toasterlovin wrote: post #68
zanderwohl wrote: post #35

Earlier quoted context omitted.

The Zig compiler does this on purpose in some cases, iirc. Free can be a waste of time if the program is going to die in half a second from now.

Yeah, I first came across this strategy as a performance optimization in something Jared Sumner wrote about Bun (which is written in Zig).

Link to devblog article/tweet?

Re: Memory leak proof every C program

#136

Post by IshKebab »

voxl wrote: post #123
IshKebab wrote: post #28

Earlier quoted context omitted.

Uhm... woosh! You know this isn't serious right?

Why isn't it serious? I can imagine a smart pointer that actually accomplished the stated goal. So the joke is that they took a good idea and made a rubbish solution?

I dunno how people are missing the point so much.

Traditionally memory is considered "leaked" if it is still allocated but nothing point to it; i.e. there's no way to navigate to the allocation anymore.

He has made a joke "solution" by simply permanently storing a second pointer to all allocations so that by this definition they never technically leak. You can still always navigate to ever allocation so no allocation has leaked.

Of course it's not a real solution because it doesn't actually change the memory characteristics of a leaky program; it just hides the leak. In other words the technical description of the leak above isn't really the thing we care about.

Seems like almost nobody here got that.

Re: Memory leak proof every C program

#137

Post by LtWorf »

tetromino_ wrote: post #64
HideousKojima wrote: post #51

Earlier quoted context omitted.

Or the missile firmware where the missile is going to explode before they run out of memory: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Using warhead explosion as garbage collector might seem like a clever hack, but all it takes is an upgrade by a different team (say, adding a new engine, or longer-range sensors, or repurposing a surface-to-air missile for a surface-to-surface role), and suddenly your guidance software runs out of memory before it explodes, and your missile falls onto an an elementary school or hospital.

> and your missile falls onto an an elementary school or hospital.

Then you just say terrorists were hiding inside…

Re: Memory leak proof every C program

#138

Post by LtWorf »

HideousKojima wrote: post #77
tetromino_ wrote: post #64

Earlier quoted context omitted.

Using warhead explosion as garbage collector might seem like a clever hack, but all it takes is an upgrade by a different team (say, adding a new engine, or longer-range sensors, or repurposing a surface-to-air missile for a surface-to-surface role), and suddenly your guidance software runs out of memory before it explodes, and your missile falls onto an an elementary school or hospital.

You can probably double the ram (or more) again by then.

Assuming you know you have to do it.

Re: Memory leak proof every C program

#139

Post by erik_seaberg »

tombert wrote: post #80
rco8786 wrote: post #41

Earlier quoted context omitted.

Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.

I had a friend who worked for one of the big Market Makers, and he told me that they would indeed turn the GC off, but what they'd do is just pre-allocate everything into bigass arrays before-hand, and have incrementers to simulate the "new" keyword. They might do this in something more or less like a threadlocal to avoid having to deal with locks or race conditions or anything like that.

This is like going back to malloc and free but using array indices rather than pointers, and each type has a fixed-size heap. We did it in one Microsoft service because the very first .NET releases had slow GCs.

Re: Memory leak proof every C program

#140

Post by erik_seaberg »

linkdd wrote: post #26
klyrs wrote: post #7

Earlier quoted context omitted.

In the not-rare case where you're writing a library, or wrapping a utility, the last programmer's exhilaration is your pain.

If you're writing a library, you're not writing a program. If you write a C library, it is a good practice to leave the allocations to the library user, or at least provide a way to override the library's allocator. Allowing your user to write a free-less *program*.

Code gets reused unless you take steps to prevent it. Once upon a time, someone submitting a change to the self-driving car project unknowingly broke Google’s web search engine. Someone else decided that was insane, and that’s why Bazel rules now let you limit who can depend on you in a monorepo.
Post reply on HN