tor, 17 06 2010 kl. 22:14 +0200, skrev Peter Stuge:
ron minnich wrote:
What if we just agree that host machines have a lot of RAM, romcc is not a long-running program, and life will be easier if nothing gets freed. How much RAM are we talking about?
Reasonable. You could at least try it. Use LD_PRELOAD and make free() a no-op :-)
Yes, I would be interested in how much RAM is being used.
(you'd be surprised how often I have to point out to people that doing lots of work to free memory before calling exit() has no effect on the system free memory -- "You mean the system can somehow free the process memory when the process exits?" -- I'm not kidding!)
It's lovely. I worked on a project where the application implemented it's own memory allocator. When starting, the program would allocate *all* available memory in the system, and then split that up into small parts as the program progressed. The boss was convinced that the operating system could not be trusted to do memory management. They're still in business, I expect still running the same code.
They should make there software in to payloads for coreboot ;D
Stefan Reinauer wrote:
What if we just agree that host machines have a lot of RAM, romcc is not a long-running program, and life will be easier if nothing gets freed.
Then we should also switch to Visual C++ in order to stay compliant. ;-)
He-he.. But depending on the resource use I would be okey with making an exception for romcc.
//Peter