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

81–90 of 289 posts

Re: Does memory leak? (1995)

#81

Post by bootloop »

jakeinspace wrote: post #69

As somebody working on embedded software for aerospace, I'm surprised this missile system even had dynamic memory allocation. My entire organization keeps flight-critical code fully statically allocated.

I would imagine it might make sense if you offload some short, less frequent but memory intensive sub-routines (sensors, navigation) to run in parallel to the rest of the system. But I would still avoid having a system wide dynamic memory management and just implement one specifically for that part.

Re: Does memory leak? (1995)

#82

Post by saagarjha »

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…

> The kernel throwing away your address space is infinitely faster than you chasing every pointer you ever created down and then having the kernel throw away your address space.

In this case you normally want to allocate an arena yourself.

Re: Does memory leak? (1995)

#83

Post by saagarjha »

H8crilA wrote: post #26
ptero wrote: post #23

Earlier quoted context omitted.

In a perfect world, yes. But in a hard real time system (and much of missile control will likely be designed as such), timing may be the #1 focus. That is, making sure that events are handled in at most X microseconds or N CPU cycles. In such cases adding GC may open a new can of worms. I agree that in general leaking resources is bad, but sometimes it is good enough by a large margin. Just a guess.

It would be an acceptable solution if the memory supply would vastly outsize the demand, by over an order of magnitude. For example if the program never needed more than 100MiB and you'd install 1GiB or 10GiB. 10GiB is still nothing compared to the cost of the missile, and you get the benefit of truly never worrying about the memory management latency. My favorite trick to optimizing some systems is to see if I can m…

> As long as it's below 1TiB it's a no brainer - 1TiB is very cheap, much cheaper than engineer salaries that would otherwise be wasted on optimizing some database indices.

Until you have ten thousand machines in your cluster…

Re: Does memory leak? (1995)

#84

Post by saagarjha »

mopsi wrote: post #63
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.

People might use them less, though.

Re: Does memory leak? (1995)

#85

Post by giu »

jakeinspace wrote: post #69

As somebody working on embedded software for aerospace, I'm surprised this missile system even had dynamic memory allocation. My entire organization keeps flight-critical code fully statically allocated.

I'm always fascinated about software running on hardware-restricted systems like planes, space shuttles, and so on.

Where can someone (i.e., in my case a software engineer who's working with Kotlin but has used C++ in his past) read more about modern approaches to writing embedded software for such systems?

I'm asking for one because I'm curious by nature and additionally because I simply take the garbage collector for granted nowadays.

Thanks in advance for any pointers (no pun intended)!

Re: Does memory leak? (1995)

#86

Post by catblast »

saagarjha wrote: post #80
derefr wrote: post #68

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 (= bum…

Note that most general-purpose allocators also keep around internal arenas from which they hand out memory.

Not sure how this is related. A general purpose allocator with a plain malloc interface can’t use this to do anything useful wrt lifetime because there is no correlation to lifetime provided by the interface. Internal arenas can be useful to address contention and fragmentation.

Re: Does memory leak? (1995)

#87

Post by saagarjha »

sumanthvepa wrote: post #20
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. Th…

> The problem with the strategy was that it required a lot of CPU and RAM to startup a new process.

It's not really kosher, but why not just keep around a fresh process that they can continually fork new handlers from?

Re: Does memory leak? (1995)

#88

Post by blattimwind »

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…

Actually the story implies the opposite

> they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number.

Re: Does memory leak? (1995)

#89

Post by saagarjha »

catblast wrote: post #86
saagarjha wrote: post #80

Earlier quoted context omitted.

Note that most general-purpose allocators also keep around internal arenas from which they hand out memory.

Not sure how this is related. A general purpose allocator with a plain malloc interface can’t use this to do anything useful wrt lifetime because there is no correlation to lifetime provided by the interface. Internal arenas can be useful to address contention and fragmentation.

I'm pointing out that an arena is more about "a region of memory that you can split up to use later" than "a region of memory that must be allocated and deallocated all at once".

Re: Does memory leak? (1995)

#90

Post by saagarjha »

giu wrote: post #85
jakeinspace wrote: post #69

As somebody working on embedded software for aerospace, I'm surprised this missile system even had dynamic memory allocation. My entire organization keeps flight-critical code fully statically allocated.

I'm always fascinated about software running on hardware-restricted systems like planes, space shuttles, and so on. Where can someone (i.e., in my case a software engineer who's working with Kotlin but has used C++ in his past) read more about modern approaches to writing embedded software for such systems? I'm asking for one because I'm curious by nature and additionally because I simply take the garbage collector f…

Searching for things like "MISRA C" and "real-time computing" will help you get started.
Post reply on HN