Does memory leak? (1995)
groups.google.com
Does memory leak? (1995)
1–10 of 289 posts
Re: Does memory leak? (1995)
#2Of course it's also expected to crash, especially the hardware :)
Re: Does memory leak? (1995)
#3Of course it's also expected to crash, especially the hardware :)
Remote execution? It was the top requested feature!
Re: Does memory leak? (1995)
#4Until the cruise missile shop down the hall decides to reuse your controller.
Re: Does memory leak? (1995)
#5And 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)
Re: Does memory leak? (1995)
#6Until the cruise missile shop down the hall decides to reuse your controller.
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.
Re: Does memory leak? (1995)
#7This 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.
Re: Does memory leak? (1995)
#8One 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.
Re: Does memory leak? (1995)
#9Until 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 platforms, the actual hardware, is always evolving, such that reusing code some years later can become sub-optimal for that reason alone.
Re: Does memory leak? (1995)
#10What a cute story about writing software to kill people by shredding them with shrapnel.