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

Does memory leak? (1995)

groups.google.com

Post reply on HN
Print view View original

61–70 of 289 posts

Re: Does memory leak? (1995)

#61

Post by derefr »

thaumasiotes wrote: post #43
eru wrote: post #11

Earlier quoted context omitted.

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.

I mean, 'cat' does something so simple (apply the identity function to the input) that it has no need to be reusable because there's no point using it in the first place. If you have input, processing it with cat just means you wasted your time to produce something you already had.

The point of cat(1), short for concatenate, is to feed a pipeline multiple concatenated files as input, whereas shell stdin redirection only allows you to feed a shell a single file as input.

This is actually highly flexible, since cat(1) recognizes the “-“ argument to mean stdin, and so you can `cat a - b` in the middle of a pipeline to “wrap” the output of the previous stage in the contents of files a and b (which could contain e.g. a header and footer to assemble a valid SQL COPY statement from a CSV stream.)

Re: Does memory leak? (1995)

#62

Post by willvarfar »

wbhart wrote: post #46

Missiles don't always hit their intended target. They can go off course, potentially be hacked, fall into the wrong hands, be sold to mass murderers, fail to explode, accidentally fall out of planes (even nuclear bombs have historically done this), miss their targets, encounter countermeasures, etc. Nobody is claiming that this was done for reasons of good software design. It's perfectly reasonable to suspect it was…

A simple bump allocator with no reclaim is fairly common in embedded code.

Garbage collection makes the performance of the code much less deterministic.

A lot of embedded loops running on embedded in-order cpus without an operating system use cycle count as a timing mechanism etc.

Re: Does memory leak? (1995)

#63

Post by mopsi »

GordonS wrote: post #42

A bit OT, but I wonder how I'd feel if I was offered a job working on software for missiles. I'm sure the technical challenge would be immensely interesting, and I could tell myself that I cared more about accuracy and correctness than other potential hires... but from a moral standpoint, I don't think I could bring myself to do it. I realise of course that the military uses all sorts of software, including line of b…

> I'm sure the technical challenge would be immensely interesting, and I could tell myself that I cared more about accuracy and correctness than other potential hires... but from a moral standpoint, I don't think I could bring myself to do it.

Why? The more precise missiles are, the better. If no-one agreed to build missile guidance systems, we'd still have carpet bombing and artillery with 100m accuracy.

Re: Does memory leak? (1995)

#65

Post by clSTophEjUdRanu »

geophile wrote: post #51

The problem, of course, is that the chief software engineer doesn't appear to be have any understanding of what is causing the leaks, and whether the safety margin is adequate. Maybe there is some obscure and untested code path in which leaking would be much faster than anticipated. To be sure, it is a unique environment, in which you know for a fact that your software does not need to run beyond a certain point in t…

Freeing memory isn't free, it takes time. Maybe it's not worth the time hit and they know exactly where it is leaking memory.

Re: Does memory leak? (1995)

#66

Post by zozbot234 »

blattimwind wrote: post #48
Out_of_Characte wrote: post #37

What an interesting concept. Good programmers always consider certain behaviours to be wrong. Memory 'leaks' being one of them. But this real application of purposefully not managing memory is also an interesting thought exercise. However counter intuitive, a memory leak in this case might be the most optimal solution in this problem space. I just never thought I would have to think of an object's lifetime in such a…

Cleaning up memory is an antipattern for many tools , especially of the EVA/IPO model (input-process-output). For example, cp(1) in preserve hard links mode has to keep track of things in a table; cleaning it up at the end of the operation is a waste of time. Someone "fixed" the leak to make valgrind happy and by doing so introduced a performance regression. Another example might be a compiler; it's pointless to deal…

"Throwing away" a bunch of address space also happens when freeing up an arena allocation, and that happens in user space. This means that you might sometimes be OK with not managing individual sub-allocations within the arena, for essentially the same reason: it might be pointless work given your constraints.

Re: Does memory leak? (1995)

#67

Post by berns »

daenz wrote: post #22
DagAgren wrote: post #10

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

Missiles are also used for defense to intercept threats.

Thank you. I hadn't thought of that possibility. Now I can join the others in discussing the optimal memory management strategy for missile controllers.

Re: Does memory leak? (1995)

#68

Post by derefr »

Erlang has a parameter called initial_heap_size. Each new actor-process in Erlang gets its own isolated heap, for which it does its own garbage-collection on its own execution thread. This initial_heap_size parameter determines how large each newly-spawned actor’s heap will be.

Why would you tune it? Because, if you set it high enough, then for all your short-lived actors, memory allocation will become a no-op (= bump allocation), and the actor will never experience enough memory-pressure to trigger a garbage-collection pass, before the actor exits and the entire process heap can be deallocated as a block. The actor will just “leak” memory onto its heap, and then exit, never having had to spend time accounting for it.

This is also done in many video games, where there is a per-frame temporaries heap that has its free pointer reset at the start of each frame. Rather than individually garbage-collecting these values, they can all just be invalidated at once at the end of the frame.

The usual name for such “heaps you pre-allocate to a capacity you’ve tuned to ensure you will never run out of, and then deallocate as a whole later on” is a memory arena. See https://en.wikipedia.org/wiki/Region-based_memory_management for more examples of memory arenas.

Re: Does memory leak? (1995)

#70

Post by b34r »

I like the pragmatism. One thing that comes to mind though is stuff gets repurposed for unintended use cases often... as long as these caveats are well documented it’s ok but imagine if they were hidden and the missiles were used in space or perhaps as static warheads on a long timer.
Post reply on HN