8 ms·

Does memory leak? (1995)

503 points by rot25 7y ago

ggambetta 7y ago
Of course it's also expected to crash, especially the hardware :)
- Igelau 7y ago
  Remote execution? It was the top requested feature!
tyingq 7y ago
Until the cruise missile shop down the hall decides to reuse your controller.
- DmitryOlshansky 7y ago
  Indeed. I think one of big problems in software development is that nobody measures the half-life of our assumptions. That is the amount of time it takes for half of the original assumptions to no longer hold. In my limited experience assumptions half-life in software could be easily as low as around one year. Meaning that in 5 years only 1/32 of original architecture would make sense if we do not evolve it.
- gameswithgo 7y ago
  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 platforms, the actual hardware, is always evolving, such that reusing code some years later can become sub-optimal for that reason alone.
  - eru 7y ago
    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.
    - thaumasiotes 7y ago
      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.
      - derefr 7y ago
        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.)
        thaumasiotes 7y ago
        But that is a case where you have several filenames and you want to concatenate the files. The work you're using cat to do is to locate and read the files based on the filename. If you already have the data stream(s), cat does nothing for you; you have to choose the order you want to read them in, but that's also true when you invoke cat. This is the conceptual difference between pipeline | cat # does nothing and pipeline | xargs cat # leverages cat's ability to open files Opening files isn't really something I think of cat as doing in its capacity as cat. It's something all the command line utilities do equally.
        7y ago
- chapium 7y ago
  Just add the explode modifier to your classes and you should be good.
- stefan_ 7y ago
  Remember when the CIA contracted with Netezza to improve their predator drone targeting, who then went and reverse-engineered some software from their ex business partner IISI and shipped that? IISi’s lawyers claimed on September 7, 2010 that “Netezza secretly reverse engineered IISi’s Geospatial product by, inter alia, modifying the internal installation programs of the product and using dummy programs to access its binary code [ … ] to create what Netezza’s own personnel reffered to internally as a “hack” version of Geospatial that would run, albeit very imperfectly, on Netezza’s new TwinFin machine [ … ] Netezza then delivered this “hack” version of Geospatial to a U.S. Government customer (the Central Intelligence Agency) [ … ] According to Netezza’s records, the CIA accepted this “hack” of Geospatial on October 23, 2009, and put it into operation at that time.” Reality is always more absurd, government agencies remain inept and corrupt even when shrouded in secrecy to cover up their missteps, and by the way, Kubernetes now flies on the F16.
raverbashing 7y ago
And that's a common mentality in hardware manufacturers as opposed to software developers (you just need to see how many survived) (Not saying that the manufacturer was necessarily wrong in this case and doubling the memory might have added a tiny manufacturing cost to something that was much more expensive)
crawshaw 7y ago
This is an example of garbage collection being more CPU efficient than manual memory management. It has limited application, but there is a more common variant: let process exit clean up the heap. You can use an efficient bump allocator for `malloc` and make `free` a no-op.
- acqq 7y ago
  There was also a variant of it with the hard drives: building Windows produced a huge amount of object files, so the trick used was to use a whole hard disk (or a partition) for that. Before the next rebuild, deleting all the files would took far more time than a "quick" reformatting of the whole hard disk, so the later was used. (I am unable to find a link that talks about that, however). In general, throwing away at once the set of the things together with the structures that maintain it is always faster than throwing away every item one by one while maintaining the consistency of the structures, in spite of the knowledge that all that is not needed at the end. An example of arenas in C: "Fast Allocation and Deallocation of Memory Based on Object Lifetimes", Hanson, 1988: ftp://ftp.cs.princeton.edu/techreports/1988/191.pdf
  - GordonS 7y ago
    That's quite a clever solution, I doubt I would have thought of that! Windows has always been my daily drivers, and I really do like it. But I wish deleting lots of files would be much, much faster. You've got time to make a cup of coffee if you need to delete a node_modules folder...
    - acqq 7y ago
      > I wish deleting lots of files would be much, much faster. You've got time to make a cup of coffee if you need to delete a node_modules folder The example I gave was for the old times when people had much less RAM and the disks had to move physical heads to access different areas. Now with the SSDs you shouldn't be able to experience it that bad (at least when using lower level approaches). How do you start that action? Do you use GUI? Are the files "deleted" to the recycle bin? The fastest way is to do it is "low level" i.e. without moving the files to the recycle bin, and without some GUI that is in any way suboptimal (I have almost never used Windows Explorer so I don't know if it has some additional inefficiencies). https://superuser.com/questions/19762/mass-deleting-files-in-windows/289399#289399 https://superuser.com/questions/19762/mass-deleting-files-in...
mojuba 7y ago
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.
- chapium 7y ago
  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.
  - barrkel 7y ago
    Killing a process is much safer than killing a thread, and the OS does cleanup. It's not great for maximizing performance but it's not 100s of milliseconds either, forking doesn't take long; what is slow is scripting languages loading their runtimes, but you can fork after that's loaded. If hardware is cheaper than opportunity cost of adding new features (rather than debugging leaks) it makes sense.
    - clarry 7y ago
      I measured less than half a millisecond to fork, print time, and wait for child to exit. http://paste.dy.fi/NEs/plain http://paste.dy.fi/NEs/plain So forking alone doesn't cap performance too much; one or two cores could handle >1000 requests per second (billions per month).
  - rgacote 7y ago
    The (web) world used to be synchronous. Traditional Apache spawns a number of threads and then keeps each thread around for x number or requests, after which the thread is killed and a new one spawned. Incredibly useful feature when you're on limited hardware and want to ensure you don't memory leak yourself out of existence. Modern Apache has newer options (and of course nginx has traditionally been entirely async on multiple threads).
DagAgren 7y ago
What a cute story about writing software to kill people by shredding them with shrapnel.
- swalsh 7y ago
  What if the bomb is landing on someone who intends to kill you?
  - pietrovismara 7y ago
    Have you watched Minority Report? What could go wrong with preemptively punishing crimes!
    - colonCapitalDee 7y ago
      This is a strawman. Nobody uses missiles for law enforcement, the very idea is ridiculous. Presumably the > person who intends to kill you in this context is a terrorist hiding a cave somewhere, or a certain Iranian general. Now, it's definitely debatable if those striking those targets is morally correct (and I usually don't believe that it is), but it's silly to equate a military strike with the type of law enforcement seen in Minority Report.
      - DagAgren 7y ago
        A "terrorist hiding in a cave" is the actual strawman here.
        colonCapitalDee 7y ago
        Uhh who do you think missiles are usually launched at?
        DagAgren 7y ago
        People going about their lives just like you and me, surrounded by other people, mostly. They may be terrorists, but that does not make their daily lives much different to ours.
simias 7y ago
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.
- ptero 7y ago
  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.
  - H8crilA 7y ago
    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 mlock() all of the data in RAM. 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.
    - bathtub365 7y ago
      What’s your rationale for picking an order of magnitude instead of, say, double?
      - lonelappde 7y ago
MrBuddyCasino 7y ago
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.
- ajuc 7y ago
  It was probably more efficient. Fixing leaks often requires copying instead of passing pointers.
- daenz 7y ago
  "just fixing the leaks" can be a very time consuming process, involving hunting and refactoring (valgrind isn't perfect). It's very possible that just throwing more memory at it with the soft guarantee that the leak won't result in OOM may have been the best business decision for that particular contract. Of course it's not the "right" way to build a thing, but sometimes the job wants the thing now and "good enough."
- qtplatypus 7y ago
  There is the cpu overhead of detecting where the memory goes out of scope and freeing it. So it can be a memory vs cup optimisation
- mantap 7y ago
  It's possible it may have been running on bare metal without an OS. Maybe they didn't want to verify a memory allocator and just treated the whole program as one big arena. I presume by "calculating" they meant "run the program in worst case conditions and see how much memory it uses".
- kelvin0 7y ago
  I feel the same way too, dunno why the down votes? In the absence of all other details it just seems like shoddy work, but of course reality is probably more nuanced ... which is what's missing from the story.
  - 7y ago
kleiba 7y ago
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.
- nneonneo 7y ago
  Why is it hard to calculate? Suppose I maintain lots of complex calculations that require variable amounts of buffered measurements (e.g. the last few seconds, the last few minutes at lower resolution, some extrapolations from measurements under different conditions, etc.). Freeing up the right measurements might be really tricky to get right, and if you free a critical measurement and need it later you’re hosed. On the other hand, you can trivially calculate how many measurements you make per unit time, and multiply that by the size of the measurements to upper-bound your storage needs. Hypothetical example: you sample GPS coordinates 20 times per second, which works out to ~160 bytes/sec, 10000 bytes/min, or around 600KB for a full hour of flight. Easy to calculate - hard to fix.
  - ken 7y ago
    Are you taking into account memory fragmentation? Or the internal malloc data structures? If your record were just 1 byte more, it could easily double the total actual memory usage. Memory usage is discrete, not continuous. It's not as simple as calculating the safety factor on a rope.
    - cozzyd 7y ago
      If you don't free, malloc doesn't need all that overhead
- daenz 7y ago
  >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. Why? I could calculate the average amount of leaking of a program much easier than I could find all the leaks. Calculating just involves performing a typical run under valgrind and seeing how much was never freed. Do that N times and average. Finding the leaks is much more involved.
deleted 7y ago
[deleted]
tjalfi 7y ago
This has come up a couple times ([0][1]) before. [0] https://news.ycombinator.com/item?id=14233542 https://news.ycombinator.com/item?id=14233542 [1] https://news.ycombinator.com/item?id=16483731 https://news.ycombinator.com/item?id=16483731
matsemann 7y ago
I made a project a few years back where I had really no idea what I was doing. [0] I had to read two live analog video feeds fed into two TV-cards, display them properly on an Oculus Rift and then take the head tilting and send back to the cameras mounted on a flying drone. I spent weeks just getting it to work, so my C++ etc was a mess. The first demo I leaked like 100 MB a second or so, but that meant that it would work for about a minute before everything crashed. We could live with that. Just had to restart the software for each person trying, hehe. [0]: https://news.ycombinator.com/item?id=7654141 https://news.ycombinator.com/item?id=7654141
Out_of_Characte 7y ago
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 literal sense. Edit; ofcouse HN reacts pedantic when I claim good programmers always consider memory leaks wrong. Do I really need to specify the obvious every time?
- blattimwind 7y ago
  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 deallocate all your structures manually before calling exit(). 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. The situation is quite different of course if you are libcompiler.
  - zozbot234 7y ago
    "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.
  - saagarjha 7y ago
    > 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.
  - ufo 7y ago
GordonS 7y ago
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 business apps, and indeed several military organisations use the B2B security software that my microISV sells, but I think it's very different to directly working on software for killing machines.
- ezoe 7y ago
  Well, there is a SAM system which is designed to kill missiles, not the humans. That said, I think any software development which involves the government aren't fun at all for all the bureaucracies and inefficiency.
- cushychicken 7y ago
  I recently interviewed, and was offered a job at, Draper Labs in Cambridge MA. The technical work was super interesting. Everyone I spoke to was plainly super sharp, and not morally bankrupt. I fielded similar moral concerns as you, but truthfully, I don't really have much of a personal ethical problem with it. I was a little more concerned at having to explain it to all of my friends, many of whom are substantially more liberal leaning in political views than I am. Perception, and the pay cut I'd have to take from my current work, ended up being the major things that stopped me from taking it.
  - TedDoesntTalk 7y ago
    First time I’ve heard of someone accepting or not accepting a job based on peer perception. Maybe you should re-evaluate who your peers are if they can’t accept you for your career choices?
    - DavidVoid 7y ago
      Or maybe they trust/value their peer's judgement despite the fact that they themselves don't have any strong views on the subject?
32gbsd 7y ago
It is all good until people start to depend on these memory leaks and then you are stuck with a platform that is unsupported.
wbhart 7y ago
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 done for reasons of cost or plain negligence. There's a reason tech workers protest involvement of their firms with the military. It's because all too often arms are not used as a deterrent or as a means of absolute last resort, but because they are used due to faulty intelligence, public or political pressure, as a means of aggression, without regard to collateral damage or otherwise in a careless way. The whole point here is the blase way the technician responded, "of course it leaks". The justification given is not that it was necessary for the design, but that it doesn't matter because it's going to explode at the end of its journey!
- willvarfar 7y ago
  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.
  - wbhart 7y ago
    Right, but that isn't the argument that was being used here, which is my point. The way I read it, the contractor cared only enough to get the design over the line so the customer would sign off on it. Their argument was that you shouldn't care about leaks due to scheduled deconstruction, not because of a technical consideration. There exist options between no reclaim and using a garbage collector which could be considered, depending on the exact technical specifications of the hardware it was running on and the era in which it happened. But retrofitting technical reasoning about why this may have been done is superfluous. The contractor already said why they did it, and the subtext of the original post is that it was flippant and hilarious.
    - 7y ago
andreareina 7y ago
"Git is a really great set of commands and it does things like malloc(); malloc(); malloc(); exit();" https://www.youtube.com/watch?v=dBSHLb1B8sw&t=113 https://www.youtube.com/watch?v=dBSHLb1B8sw&t=113
- jldugger 7y ago
  And that really bit hard when you wanted to start running git webservers. All the lib code was designed to exit upon completion with no GC, and now you're running multiple read queries per second with no free(). oops.
geophile 7y ago
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 time. And in a situation like that, I think it is OK to say that we have enough of some resource to reach that point in time. (It's sort of like admitting that climate change is real, and will end life on earth, but then counting on The Rapture to excuse not caring.) But that's not what's going on here. It sounds like they weren't really sure that there would definitely be enough memory.
- willvarfar 7y ago
  You are reading a lot into a short story. You don’t know that the engineer hasn’t had someone exactly calculate the memory allocations. Static or never-reclaimed allocations are common enough in embedded code.
- clSTophEjUdRanu 7y ago
  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.
- blattimwind 7y ago
  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.
zozbot234 7y ago
(1995) based on the Date: and (plausibly) References: headers in the OP.
lala26in 7y ago
One reason I open HN almost everyday is some top items consistently catch my attention. They are thought provoking. Today's (now) HN I see 3-4 such items. :)
derefr 7y ago
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 https://en.wikipedia.org/wiki/Region-based_memory_management for more examples of memory arenas.
- saagarjha 7y ago
  Note that most general-purpose allocators also keep around internal arenas from which they hand out memory.
  - catblast 7y ago
    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.
    - saagarjha 7y ago
      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".
jakeinspace 7y ago
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.
- bootloop 7y ago
  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.
  - Dylan16807 7y ago
    Whichever ones you allow to run in parallel need to have enough memory to run at the same time, but such a situation might happen quite rarely. In other words, that sounds like a system where dynamic memory management is significantly riskier and harder to test than usual! Why not static allocation, but sharing memory between the greedy chunks of code that can't run parallel to each other? (I assume these chunks exist, because otherwise your worst-case analysis for dynamic memory would be exactly the same as for static, and it wouldn't save you anything.)
    - bootloop 7y ago
      > Why not static allocation, but sharing memory between the greedy chunks of code that can't run parallel to each other? That's what I wanted to say with my comment actually.
  - bdavis__ 7y ago
    when you design the system, you make sure there is enough physical RAM to do the job. Period. the problem space is bounded.
- giu 7y ago
  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)!
b34r 7y ago
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.
FpUser 7y ago
"Since the missile will explode when it hits it's target or at the end of it's flight, the ultimate in garbage collection is performed without programmer intervention." I just can't stop laughing over this "ultimate in garbage collection". What a guy. Btw we dealt a lot with Rational in the 90's. I might have even met him.
kebman 7y ago
The garbage is collected in one huge explosion. And then even more garbage is made, so that's why we don't mind leaks...... xD
simonebrunozzi 7y ago
> the ultimate in garbage collection is performed without programmer intervention. Brilliant.
LucaSas 7y ago
This pops up again from time to time, I think what people should take away from this is that garbage collection is not just what you see in Java and other high level languages. There are a lot of strategies to apply garbage collection and they are often used in low level systems too like per-frame temporary arenas in games or in short lived programs that just allocate and never free.
- asveikau 7y ago
  Once you set a limit like this, though, it's brittle, and your code becomes less maintainable or flexible in the face of change. That is why a general purpose strategy is good to use.
lallysingh 7y ago
Are these Patriots? Didn't they need a power cycle every 24 hours? Is this why?
cryptoscandal 7y ago
yes
MaxBarraclough 7y ago
On such systems the same approach can be taken for a cooling solution. If the chip will fatally overheat in 60 seconds but the device's lifetime is only 45, there's no need for a more elaborate cooling solution. The always-leak approach to memory management can also be used in short-lived application code. The D compiler once used this approach [0] (I'm not sure whether it still does). [0] https://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 https://www.drdobbs.com/cpp/increasing-compiler-speed-by-ove...
lmilcin 7y ago
I once worked on an application which if failed even once meant considerable loss for the company including possible closure. By design, there was no memory management. The memory was only ever allocated at the start and never de-allocated. All algorithms were implemented around the concept of everything being a static buffer of infinite lifetime. It was not possible to spring a memory leak.
- conro1108 7y ago
  This sounds fascinating, could you elaborate any on why a single failure of this application would be so catastrophic?
  - lmilcin 7y ago
    I can't discuss this particular application. But there are whole classes of applications that are also mission critical -- an example might be software driving your car or operating dangerous chemical processes. For automotive industry there are MISRA standards which we used to guide our development process amongst other ideas from NASA and Boeing (yeah, I know... it was some time ago)
- voldacar 7y ago
  How did this work exactly? the program just never had to work on data greater than a certain statically known size? or did it process anything larger than that in chunks instead of mallocing a buffer of the necessary size?
  - lmilcin 7y ago
    Not necessarily. What this means, is you need to have a limit for every data structure in the application and have a strategy on how to either prevent the limit to ever be hit or how to deal when the limit is excercised. Imagine a simple example of a webapp and number of user sessions. Instead of the app throwing random errors or slowing down drastically, you could have a hard limit on the number of active sessions. Whenever the app tries to allocate (find a slot) for a user session but it can't (all objects are already used), it will just throw an error. This ensures that the application will always work correctly once you log in -- you will not experience a slowdown because too many users logged in. Now, you also need to figure out what to do with users that received an error when trying to log in. They might receive an error and be told to log in later, they might be put on hold by UI and logged in automatically later or they might be redirected by loadbalancer to another server (maybe even started on demand). When you start doing this for every aspect of application you get into situation where your application never really gets out of its design parameters and it is one of the important aspect to get an ultra stable operation.
djsumdog 7y ago
My undergraduate mentor took a co-op position one year in Huntsville, Alabama. He told me about 6 processor missile guidance systems that cost tens of thousands of dollars ... all to guide a missile to where it gets blown up.
zdw 7y ago
Another "works because it's in a missile and only has to run for as short time" story: Electronics components for trajectory tracking and guidance for a particular missile weren't running fast enough, namely the older CPU that the software was targeting. The solution to this was to overclock the CPU by double, and redirect a tiny amount of the liquid oxygen that happened also to be used in the propellent system to cool down the electronics. This apparently worked fine - by the time the missile ran out of LOX and the electronics burned themselves out, it was going so fast on a ballistic trajectory that it couldn't be reasonably steered anyway. The telemetry for the self destruct was on a different system that wasn't overclocked, in case of problems with the missile.

503 points by rot25 7y ago

ggambetta 7y ago

Of course it's also expected to crash, especially the hardware :)

Igelau 7y ago
Remote execution? It was the top requested feature!

tyingq 7y ago

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

DmitryOlshansky 7y ago
Indeed. I think one of big problems in software development is that nobody measures the half-life of our assumptions. That is the amount of time it takes for half of the original assumptions to no longer hold. In my limited experience assumptions half-life in software could be easily as low as around one year. Meaning that in 5 years only 1/32 of original architecture would make sense if we do not evolve it.
gameswithgo 7y ago
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 platforms, the actual hardware, is always evolving, such that reusing code some years later can become sub-optimal for that reason alone.
- eru 7y ago
  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.
  - thaumasiotes 7y ago
    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.
    - derefr 7y ago
      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.)
      - thaumasiotes 7y ago
        But that is a case where you have several filenames and you want to concatenate the files. The work you're using cat to do is to locate and read the files based on the filename. If you already have the data stream(s), cat does nothing for you; you have to choose the order you want to read them in, but that's also true when you invoke cat. This is the conceptual difference between pipeline | cat # does nothing and pipeline | xargs cat # leverages cat's ability to open files Opening files isn't really something I think of cat as doing in its capacity as cat. It's something all the command line utilities do equally.
        7y ago
chapium 7y ago
Just add the explode modifier to your classes and you should be good.
stefan_ 7y ago
Remember when the CIA contracted with Netezza to improve their predator drone targeting, who then went and reverse-engineered some software from their ex business partner IISI and shipped that? IISi’s lawyers claimed on September 7, 2010 that “Netezza secretly reverse engineered IISi’s Geospatial product by, inter alia, modifying the internal installation programs of the product and using dummy programs to access its binary code [ … ] to create what Netezza’s own personnel reffered to internally as a “hack” version of Geospatial that would run, albeit very imperfectly, on Netezza’s new TwinFin machine [ … ] Netezza then delivered this “hack” version of Geospatial to a U.S. Government customer (the Central Intelligence Agency) [ … ] According to Netezza’s records, the CIA accepted this “hack” of Geospatial on October 23, 2009, and put it into operation at that time.” Reality is always more absurd, government agencies remain inept and corrupt even when shrouded in secrecy to cover up their missteps, and by the way, Kubernetes now flies on the F16.

raverbashing 7y ago

And that's a common mentality in hardware manufacturers as opposed to software developers (you just need to see how many survived) (Not saying that the manufacturer was necessarily wrong in this case and doubling the memory might have added a tiny manufacturing cost to something that was much more expensive)

crawshaw 7y ago

This is an example of garbage collection being more CPU efficient than manual memory management. It has limited application, but there is a more common variant: let process exit clean up the heap. You can use an efficient bump allocator for `malloc` and make `free` a no-op.

acqq 7y ago
There was also a variant of it with the hard drives: building Windows produced a huge amount of object files, so the trick used was to use a whole hard disk (or a partition) for that. Before the next rebuild, deleting all the files would took far more time than a "quick" reformatting of the whole hard disk, so the later was used. (I am unable to find a link that talks about that, however). In general, throwing away at once the set of the things together with the structures that maintain it is always faster than throwing away every item one by one while maintaining the consistency of the structures, in spite of the knowledge that all that is not needed at the end. An example of arenas in C: "Fast Allocation and Deallocation of Memory Based on Object Lifetimes", Hanson, 1988: ftp://ftp.cs.princeton.edu/techreports/1988/191.pdf
- GordonS 7y ago
  That's quite a clever solution, I doubt I would have thought of that! Windows has always been my daily drivers, and I really do like it. But I wish deleting lots of files would be much, much faster. You've got time to make a cup of coffee if you need to delete a node_modules folder...
  - acqq 7y ago
    > I wish deleting lots of files would be much, much faster. You've got time to make a cup of coffee if you need to delete a node_modules folder The example I gave was for the old times when people had much less RAM and the disks had to move physical heads to access different areas. Now with the SSDs you shouldn't be able to experience it that bad (at least when using lower level approaches). How do you start that action? Do you use GUI? Are the files "deleted" to the recycle bin? The fastest way is to do it is "low level" i.e. without moving the files to the recycle bin, and without some GUI that is in any way suboptimal (I have almost never used Windows Explorer so I don't know if it has some additional inefficiencies). https://superuser.com/questions/19762/mass-deleting-files-in-windows/289399#289399 https://superuser.com/questions/19762/mass-deleting-files-in...

mojuba 7y ago

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.

chapium 7y ago
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.
- barrkel 7y ago
  Killing a process is much safer than killing a thread, and the OS does cleanup. It's not great for maximizing performance but it's not 100s of milliseconds either, forking doesn't take long; what is slow is scripting languages loading their runtimes, but you can fork after that's loaded. If hardware is cheaper than opportunity cost of adding new features (rather than debugging leaks) it makes sense.
  - clarry 7y ago
    I measured less than half a millisecond to fork, print time, and wait for child to exit. http://paste.dy.fi/NEs/plain http://paste.dy.fi/NEs/plain So forking alone doesn't cap performance too much; one or two cores could handle >1000 requests per second (billions per month).
- rgacote 7y ago
  The (web) world used to be synchronous. Traditional Apache spawns a number of threads and then keeps each thread around for x number or requests, after which the thread is killed and a new one spawned. Incredibly useful feature when you're on limited hardware and want to ensure you don't memory leak yourself out of existence. Modern Apache has newer options (and of course nginx has traditionally been entirely async on multiple threads).

DagAgren 7y ago

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

swalsh 7y ago
What if the bomb is landing on someone who intends to kill you?
- pietrovismara 7y ago
  Have you watched Minority Report? What could go wrong with preemptively punishing crimes!
  - colonCapitalDee 7y ago
    This is a strawman. Nobody uses missiles for law enforcement, the very idea is ridiculous. Presumably the > person who intends to kill you in this context is a terrorist hiding a cave somewhere, or a certain Iranian general. Now, it's definitely debatable if those striking those targets is morally correct (and I usually don't believe that it is), but it's silly to equate a military strike with the type of law enforcement seen in Minority Report.
    - DagAgren 7y ago
      A "terrorist hiding in a cave" is the actual strawman here.
      - colonCapitalDee 7y ago
        Uhh who do you think missiles are usually launched at?
        DagAgren 7y ago
        People going about their lives just like you and me, surrounded by other people, mostly. They may be terrorists, but that does not make their daily lives much different to ours.

simias 7y ago

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.

ptero 7y ago
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.
- H8crilA 7y ago
  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 mlock() all of the data in RAM. 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.
  - bathtub365 7y ago
    What’s your rationale for picking an order of magnitude instead of, say, double?
    - lonelappde 7y ago

MrBuddyCasino 7y ago

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.

ajuc 7y ago
It was probably more efficient. Fixing leaks often requires copying instead of passing pointers.
daenz 7y ago
"just fixing the leaks" can be a very time consuming process, involving hunting and refactoring (valgrind isn't perfect). It's very possible that just throwing more memory at it with the soft guarantee that the leak won't result in OOM may have been the best business decision for that particular contract. Of course it's not the "right" way to build a thing, but sometimes the job wants the thing now and "good enough."
qtplatypus 7y ago
There is the cpu overhead of detecting where the memory goes out of scope and freeing it. So it can be a memory vs cup optimisation
mantap 7y ago
It's possible it may have been running on bare metal without an OS. Maybe they didn't want to verify a memory allocator and just treated the whole program as one big arena. I presume by "calculating" they meant "run the program in worst case conditions and see how much memory it uses".
kelvin0 7y ago
I feel the same way too, dunno why the down votes? In the absence of all other details it just seems like shoddy work, but of course reality is probably more nuanced ... which is what's missing from the story.
- 7y ago

kleiba 7y ago

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.

nneonneo 7y ago
Why is it hard to calculate? Suppose I maintain lots of complex calculations that require variable amounts of buffered measurements (e.g. the last few seconds, the last few minutes at lower resolution, some extrapolations from measurements under different conditions, etc.). Freeing up the right measurements might be really tricky to get right, and if you free a critical measurement and need it later you’re hosed. On the other hand, you can trivially calculate how many measurements you make per unit time, and multiply that by the size of the measurements to upper-bound your storage needs. Hypothetical example: you sample GPS coordinates 20 times per second, which works out to ~160 bytes/sec, 10000 bytes/min, or around 600KB for a full hour of flight. Easy to calculate - hard to fix.
- ken 7y ago
  Are you taking into account memory fragmentation? Or the internal malloc data structures? If your record were just 1 byte more, it could easily double the total actual memory usage. Memory usage is discrete, not continuous. It's not as simple as calculating the safety factor on a rope.
  - cozzyd 7y ago
    If you don't free, malloc doesn't need all that overhead
daenz 7y ago
>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. Why? I could calculate the average amount of leaking of a program much easier than I could find all the leaks. Calculating just involves performing a typical run under valgrind and seeing how much was never freed. Do that N times and average. Finding the leaks is much more involved.

deleted 7y ago

[deleted]

tjalfi 7y ago

This has come up a couple times ([0][1]) before. [0] https://news.ycombinator.com/item?id=14233542 https://news.ycombinator.com/item?id=14233542 [1] https://news.ycombinator.com/item?id=16483731 https://news.ycombinator.com/item?id=16483731

matsemann 7y ago

I made a project a few years back where I had really no idea what I was doing. [0] I had to read two live analog video feeds fed into two TV-cards, display them properly on an Oculus Rift and then take the head tilting and send back to the cameras mounted on a flying drone. I spent weeks just getting it to work, so my C++ etc was a mess. The first demo I leaked like 100 MB a second or so, but that meant that it would work for about a minute before everything crashed. We could live with that. Just had to restart the software for each person trying, hehe. [0]: https://news.ycombinator.com/item?id=7654141 https://news.ycombinator.com/item?id=7654141

Out_of_Characte 7y ago

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 literal sense. Edit; ofcouse HN reacts pedantic when I claim good programmers always consider memory leaks wrong. Do I really need to specify the obvious every time?

blattimwind 7y ago
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 deallocate all your structures manually before calling exit(). 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. The situation is quite different of course if you are libcompiler.
- zozbot234 7y ago
  "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.
- saagarjha 7y ago
  > 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.
- ufo 7y ago

GordonS 7y ago

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 business apps, and indeed several military organisations use the B2B security software that my microISV sells, but I think it's very different to directly working on software for killing machines.

ezoe 7y ago
Well, there is a SAM system which is designed to kill missiles, not the humans. That said, I think any software development which involves the government aren't fun at all for all the bureaucracies and inefficiency.
cushychicken 7y ago
I recently interviewed, and was offered a job at, Draper Labs in Cambridge MA. The technical work was super interesting. Everyone I spoke to was plainly super sharp, and not morally bankrupt. I fielded similar moral concerns as you, but truthfully, I don't really have much of a personal ethical problem with it. I was a little more concerned at having to explain it to all of my friends, many of whom are substantially more liberal leaning in political views than I am. Perception, and the pay cut I'd have to take from my current work, ended up being the major things that stopped me from taking it.
- TedDoesntTalk 7y ago
  First time I’ve heard of someone accepting or not accepting a job based on peer perception. Maybe you should re-evaluate who your peers are if they can’t accept you for your career choices?
  - DavidVoid 7y ago
    Or maybe they trust/value their peer's judgement despite the fact that they themselves don't have any strong views on the subject?

32gbsd 7y ago

It is all good until people start to depend on these memory leaks and then you are stuck with a platform that is unsupported.

wbhart 7y ago

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 done for reasons of cost or plain negligence. There's a reason tech workers protest involvement of their firms with the military. It's because all too often arms are not used as a deterrent or as a means of absolute last resort, but because they are used due to faulty intelligence, public or political pressure, as a means of aggression, without regard to collateral damage or otherwise in a careless way. The whole point here is the blase way the technician responded, "of course it leaks". The justification given is not that it was necessary for the design, but that it doesn't matter because it's going to explode at the end of its journey!

willvarfar 7y ago
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.
- wbhart 7y ago
  Right, but that isn't the argument that was being used here, which is my point. The way I read it, the contractor cared only enough to get the design over the line so the customer would sign off on it. Their argument was that you shouldn't care about leaks due to scheduled deconstruction, not because of a technical consideration. There exist options between no reclaim and using a garbage collector which could be considered, depending on the exact technical specifications of the hardware it was running on and the era in which it happened. But retrofitting technical reasoning about why this may have been done is superfluous. The contractor already said why they did it, and the subtext of the original post is that it was flippant and hilarious.
  - 7y ago

andreareina 7y ago

"Git is a really great set of commands and it does things like malloc(); malloc(); malloc(); exit();" https://www.youtube.com/watch?v=dBSHLb1B8sw&t=113 https://www.youtube.com/watch?v=dBSHLb1B8sw&t=113

jldugger 7y ago
And that really bit hard when you wanted to start running git webservers. All the lib code was designed to exit upon completion with no GC, and now you're running multiple read queries per second with no free(). oops.

geophile 7y ago

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 time. And in a situation like that, I think it is OK to say that we have enough of some resource to reach that point in time. (It's sort of like admitting that climate change is real, and will end life on earth, but then counting on The Rapture to excuse not caring.) But that's not what's going on here. It sounds like they weren't really sure that there would definitely be enough memory.

willvarfar 7y ago
You are reading a lot into a short story. You don’t know that the engineer hasn’t had someone exactly calculate the memory allocations. Static or never-reclaimed allocations are common enough in embedded code.
clSTophEjUdRanu 7y ago
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.
blattimwind 7y ago
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.

zozbot234 7y ago

(1995) based on the Date: and (plausibly) References: headers in the OP.

lala26in 7y ago

One reason I open HN almost everyday is some top items consistently catch my attention. They are thought provoking. Today's (now) HN I see 3-4 such items. :)

derefr 7y ago

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 https://en.wikipedia.org/wiki/Region-based_memory_management for more examples of memory arenas.

saagarjha 7y ago
Note that most general-purpose allocators also keep around internal arenas from which they hand out memory.
- catblast 7y ago
  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.
  - saagarjha 7y ago
    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".

jakeinspace 7y ago

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.

bootloop 7y ago
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.
- Dylan16807 7y ago
  Whichever ones you allow to run in parallel need to have enough memory to run at the same time, but such a situation might happen quite rarely. In other words, that sounds like a system where dynamic memory management is significantly riskier and harder to test than usual! Why not static allocation, but sharing memory between the greedy chunks of code that can't run parallel to each other? (I assume these chunks exist, because otherwise your worst-case analysis for dynamic memory would be exactly the same as for static, and it wouldn't save you anything.)
  - bootloop 7y ago
    > Why not static allocation, but sharing memory between the greedy chunks of code that can't run parallel to each other? That's what I wanted to say with my comment actually.
- bdavis__ 7y ago
  when you design the system, you make sure there is enough physical RAM to do the job. Period. the problem space is bounded.
giu 7y ago
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)!

b34r 7y ago

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.

FpUser 7y ago

"Since the missile will explode when it hits it's target or at the end of it's flight, the ultimate in garbage collection is performed without programmer intervention." I just can't stop laughing over this "ultimate in garbage collection". What a guy. Btw we dealt a lot with Rational in the 90's. I might have even met him.

kebman 7y ago

The garbage is collected in one huge explosion. And then even more garbage is made, so that's why we don't mind leaks...... xD

simonebrunozzi 7y ago

> the ultimate in garbage collection is performed without programmer intervention. Brilliant.

LucaSas 7y ago

This pops up again from time to time, I think what people should take away from this is that garbage collection is not just what you see in Java and other high level languages. There are a lot of strategies to apply garbage collection and they are often used in low level systems too like per-frame temporary arenas in games or in short lived programs that just allocate and never free.

asveikau 7y ago
Once you set a limit like this, though, it's brittle, and your code becomes less maintainable or flexible in the face of change. That is why a general purpose strategy is good to use.

lallysingh 7y ago

Are these Patriots? Didn't they need a power cycle every 24 hours? Is this why?

cryptoscandal 7y ago

yes

MaxBarraclough 7y ago

On such systems the same approach can be taken for a cooling solution. If the chip will fatally overheat in 60 seconds but the device's lifetime is only 45, there's no need for a more elaborate cooling solution. The always-leak approach to memory management can also be used in short-lived application code. The D compiler once used this approach [0] (I'm not sure whether it still does). [0] https://www.drdobbs.com/cpp/increasing-compiler-speed-by-over-75/240158941 https://www.drdobbs.com/cpp/increasing-compiler-speed-by-ove...

lmilcin 7y ago

I once worked on an application which if failed even once meant considerable loss for the company including possible closure. By design, there was no memory management. The memory was only ever allocated at the start and never de-allocated. All algorithms were implemented around the concept of everything being a static buffer of infinite lifetime. It was not possible to spring a memory leak.

conro1108 7y ago
This sounds fascinating, could you elaborate any on why a single failure of this application would be so catastrophic?
- lmilcin 7y ago
  I can't discuss this particular application. But there are whole classes of applications that are also mission critical -- an example might be software driving your car or operating dangerous chemical processes. For automotive industry there are MISRA standards which we used to guide our development process amongst other ideas from NASA and Boeing (yeah, I know... it was some time ago)
voldacar 7y ago
How did this work exactly? the program just never had to work on data greater than a certain statically known size? or did it process anything larger than that in chunks instead of mallocing a buffer of the necessary size?
- lmilcin 7y ago
  Not necessarily. What this means, is you need to have a limit for every data structure in the application and have a strategy on how to either prevent the limit to ever be hit or how to deal when the limit is excercised. Imagine a simple example of a webapp and number of user sessions. Instead of the app throwing random errors or slowing down drastically, you could have a hard limit on the number of active sessions. Whenever the app tries to allocate (find a slot) for a user session but it can't (all objects are already used), it will just throw an error. This ensures that the application will always work correctly once you log in -- you will not experience a slowdown because too many users logged in. Now, you also need to figure out what to do with users that received an error when trying to log in. They might receive an error and be told to log in later, they might be put on hold by UI and logged in automatically later or they might be redirected by loadbalancer to another server (maybe even started on demand). When you start doing this for every aspect of application you get into situation where your application never really gets out of its design parameters and it is one of the important aspect to get an ultra stable operation.

djsumdog 7y ago

My undergraduate mentor took a co-op position one year in Huntsville, Alabama. He told me about 6 processor missile guidance systems that cost tens of thousands of dollars ... all to guide a missile to where it gets blown up.

zdw 7y ago

Another "works because it's in a missile and only has to run for as short time" story: Electronics components for trajectory tracking and guidance for a particular missile weren't running fast enough, namely the older CPU that the software was targeting. The solution to this was to overclock the CPU by double, and redirect a tiny amount of the liquid oxygen that happened also to be used in the propellent system to cool down the electronics. This apparently worked fine - by the time the missile ran out of LOX and the electronics burned themselves out, it was going so fast on a ballistic trajectory that it couldn't be reasonably steered anyway. The telemetry for the self destruct was on a different system that wasn't overclocked, in case of problems with the missile.