Or the old story of the junior engineer who finds a memory leak in a missile’s guidance system and the senior engineer says the memory leak is fine as long as you don’t run out of memory before the missile completes its mission.
Or the old story of the junior engineer who finds a memory leak in a missile’s guidance system and the senior engineer says the memory leak is fine as long as you don’t run out of memory before the missile completes its mission.
https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
_________
From: k...@rational.com (Kent Mitchell)
Subject: Re: Does memory leak?
Date: 1995/03/31
Norman H. Cohen (nco...@watson.ibm.com) wrote:
: The only programs I know of with deliberate memory leaks are those whose
: executions are short enough, and whose target machines have enough
: virtual memory space, that running out of memory is not a concern.
: (This class of programs includes many student programming exercises and
: some simple applets and utilities; it includes few if any embedded or
: safety-critical programs.)
This sparked an interesting memory for me. I was once working with a
customer who was producing on-board software for a missile. In my analysis
of the code, I pointed out that they had a number of problems with storage
leaks. Imagine my surprise when the customers chief software engineer said
"Of course it leaks". He went on to point out that 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. They added this much
additional memory to the hardware to "support" the leaks. Since the missile
will explode when it hits its target or at the end of its flight, the
ultimate in garbage collection is performed without programmer intervention.
--
Kent Mitchell | One possible reason that things aren't
Technical Consultant | going according to plan is .....
Rational Software Corporation | that there never was a plan!
When the point of the product is to kill someone, you can't just stochastically measure shit like this. If the device is ever out of control before it ceases operations, you're looking at Geneva Convention level offenses.
Even software designed to save lives can't get away with this sort of thing.
It just drops?
https://www.scienceabc.com/innovation/why-do-some-missiles-e...
Apparently it will "hijack" more memory and attempt to reconstruct it's orders.
But, real world, I would say that data corruption would occur and outside of chemical/physics, it will just drop and lockup.
May have a failsafe to detonate, but that is a fun question indeed.
If you think getting a license is the way to fix quality issues, I have a bridge to sell you.
That's a joke. Russia is intentionally bombing Ukrainian civilians, you think they're going to have a single War Crimes charge put against them? How many civilians did the US unintentionally kill across Afghanistan and Iraq, hundreds of thousands? See any charges there either?
I don't know how I could possibly get one but I'd love to read an independent comparison of this sort of behaviour between US operations and Russian ones. My belief is that the US aims not to kill civilians but is often careless and nets a lot of collateral damage, whereas Russia doesn't care at all and will happily bomb schools if it thinks there's a target in there. But of course I mostly read Western media and writing so my view is potentially very biased.
This sort of analysis is completely normal in software. E.g. in safety critical software you often analyse maximum possible stack depth to check that your stack is big enough (one of the reasons why recursive code is sometimes disallowed). This is exactly the same class of analysis.
People have been writing HFT systems in GC languages (Java, OCaml) for a while, and as you mentioned, you need to know when to pause/unpause/prevent collection in the critical section.
This [1] is an excerpt from a talk with Dave Lauer [1], who has done it in Java - it took his system ~40 μs from receiving data to producing market order, and he explains in great detail what amount of work the system had to do. And this was >10 years ago.
(from my experience anyway in writing critical-path allocation-free C# with Unity).
That's his point. It's like saying humans can walk over a lake, as long as it's dry season and the lake is now 10 inches deep.
You can use garbage collected languages as long as you don't collect. (!?!?!)
I'm even more hardline. IMO everything time or life-critical should have static memory allocation, period.
Their problem was that when they operated their device it was indeed a single device, but later became many more. If they paid for the extra licenses they didn't need it would be ripping off the government; if they failed to pay for the extra license at some point they would be in breach of their contract with the government as all these unlicensed devices were released.
It rapidly became obvious that their application was a MIRV and that they weren't really going to change but had asked us to talk with them as part of their process of negotiating a deal with their current supplier.
It's hard to imagine really worrying about your license agreements if there actually were a global thermonuclear war.
The surprising thing here is that it is considered worth it with those limitations.
My hope/guess is that because of the GC hype there wasn't any good alternatives.
With the alternatives gaining maturity now I'd hope that that decision wouldn't be made today (when starting from a clean slate).
These people make decisions based on Excel spreadsheets that are not properly documented. I wouldn't trust their judgement, despite the fact they managed not to crash the global financial system too frequently.
It shouldn't be that surprising. Languages like Java and C# are perfectly sensible languages for writing the vast majority of a lot of trading systems. So it's eminently reasonable to use them, or equivalent, and deal with the bits that are GC-phobic as special cases.
I've worked with/on trading systems written is mainstream languages including C++, Java, C# and Python, as well as less mainstream such as APL and Smalltalk. I can safely say that there are way more critical concerns than whether or not it uses a GC.
>GC just increases your energy bill and helps heat up the planet.
Were C++ compilation times that use 100% of my PC taken into consideration?
And not just for final binary, but also the compilations that happen everyday for development purpose too
How? GC does its work in large batches once in a while, whereas for example Arc (the only serious alternative to what GC brings, which is the ability to have arbitrary graphs of objects) does its work much more frequently, with additional effort expended on atomic operations in a multithreaded environment, and with additional memory writes to boot. Somehow I doubt that GC "just increases your energy bill".
In retrospect I think I should have put more effort into breaking the feature factory culture than the discipline culture. It's hard to get clean if your drug of choice is ready at hand.