Does memory leak? (1995) • Hacker News Board

Re: Does memory leak? (1995)

#11

Post by eru » Sat, Feb 22, 2020, 1:49 PM UTC

gameswithgo wrote: post #9

tyingq wrote: post #4

Until the cruise missile shop down the hall decides to reuse your controller.

If all software is built to protect against all possible future anticipated use cases, your software will take longer to make, perform worse, and be more likely to have bugs. If all software is built only to solve the problem at hand, it will take less time to develop, be less likely to have bugs, and perform better. It isn't clear that coding for reuse is going to get you a net win, especially since computing platfo…

There's a middle ground. Eg the classic Unix 'cat' (ignoring all the command line switches) does something really simple and re-usable, so it makes sense to make sure it does the Right Thing in all situations.

Re: Does memory leak? (1995)

#12

Post by swalsh » Sat, Feb 22, 2020, 1:49 PM UTC

DagAgren wrote: post #10

What a cute story about writing software to kill people by shredding them with shrapnel.

What if the bomb is landing on someone who intends to kill you?

Re: Does memory leak? (1995)

#13

Post by simias » Sat, Feb 22, 2020, 1:50 PM UTC

I think it's a bad mindset to leak resources even when it doesn't effectively matter. In non-garbage collected languages especially, because it's important to keep in mind who owns what and for how long. It also makes refactoring easier because leaked resources effectively become some sort of implicit global state you need to keep track of. If a function that was originally called only once at startup is not called repeatedly and it turns out that it leaks some memory every time you know have a problem.

In this case I assume that a massive amount of testing mitigates these issues however.

Re: Does memory leak? (1995)

#14

Post by DoofusOfDeath » Sat, Feb 22, 2020, 1:51 PM UTC

DagAgren wrote: post #10

What a cute story about writing software to kill people by shredding them with shrapnel.

There's a difference between delighting in war vs. accepting it as sometimes the lesser of two evils. I'm okay with discussing the software-engineering considerations needed to support the latter.

Re: Does memory leak? (1995)

#15

Post by MrBuddyCasino » Sat, Feb 22, 2020, 1:51 PM UTC

Why go through the trouble of

a) calculating maximum leakage

b) doubling physical memory

instead of just fixing the leaks? Was it to save cycles? Prevent memory fragmentation? I feel this story misses the details that would make it more than just a cute anecdote.

Re: Does memory leak? (1995)

#16

Post by chapium » Sat, Feb 22, 2020, 1:53 PM UTC

mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

This is clearly not my subject area. Why would we be spawning processes for HTTP requests? This sounds awful for performance.

My best guess is a security guarantee.

Re: Does memory leak? (1995)

#17

Post by kleiba » Sat, Feb 22, 2020, 1:53 PM UTC

Seems a bit unlikely to me. Intuitively, calculating how much memory a program will leak in the worst case should be at least as much effort as fixing the memory leaks. And if you actually calculated (as in, proved) the amount of leaked memory rather than just by empirically measuring it, there's no need to install double the amount of physical memory.

This whole procedure appears to be a bit unbelievable. And we're not even talking about code/system maintainability.

Re: Does memory leak? (1995)

#18

Post by chapium » Sat, Feb 22, 2020, 1:54 PM UTC

tyingq wrote: post #4

Until the cruise missile shop down the hall decides to reuse your controller.

Just add the explode modifier to your classes and you should be good.

Re: Does memory leak? (1995)

#19

Post by ajuc » Sat, Feb 22, 2020, 1:54 PM UTC

MrBuddyCasino wrote: post #15

Why go through the trouble of a) calculating maximum leakage b) doubling physical memory instead of just fixing the leaks? Was it to save cycles? Prevent memory fragmentation? I feel this story misses the details that would make it more than just a cute anecdote.

It was probably more efficient. Fixing leaks often requires copying instead of passing pointers.

Re: Does memory leak? (1995)

#20

Post by sumanthvepa » Sat, Feb 22, 2020, 1:54 PM UTC

mojuba wrote: post #8

One other class of applications that don't really require garbage collection is HTTP request handlers if run as isolated processes. They are usually very short-lived - they can't even live longer than some maximum enforced by the server. For example, PHP takes advantage of this and allows you not to worry about circular references much.

I used to work at Amazon the late 90s and this was the policy they followed. The apache server module written in C would leak so much that the process would have to be killed every 10 requests. The problem with the strategy was that it required a lot of CPU and RAM to startup a new process. Amazons answer was to simply throw hardware at the problem. Growing the company fast was more important than cleaning up RAM. They did get round to resolving the problems a few years later wit better architectures. This to was an example of good engineering trade offs.