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 > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
