Re: Fragmentation was RE: [GD-General] Compile times
Brought to you by:
vexxed72
From: brian h. <bri...@py...> - 2002-12-18 06:24:13
|
> but the only empirical study I'm aware of suggests that if malloc > doesn't suck, then fragmentation is not a problem. I'll read that paper, but let's just say I'm confident I can contrive a scenario where address space fragmentation will still cause problems. Sure, it's contrived -- but if I can imagine it, I'm pretty sure it can happen as well =) > took all kinds of measures to avoid it. In Munch's Oddysee we pretty > much just let it rip (STL and all), with a general-purpose custom > allocator, and didn't run into significant problems. It's entirely possible for fragmentation to be a non-issue. Hell, languages like Objective-C and even C++ pretty much make their livings assuming you're not going to stress about it. "alloc() long and prosper". But did Munch's Oddysee have any "cheats" in it that made fragmentation less dangerous? For example, level changes where a lot of data was purged simultaneously? If you free up a lot of stuff at once, this will let the heap manager coalesce huge chunks of memory. But if your run-time allocation patterns both preclude large numbers of references being freed simultaneously and also force weird big/small allocations, then I still believe it's a problem. > Which scared the > crap out of me at the time, but I'm wondering if being afraid of > fragmentation is unfounded nowadays. I think this depends ENTIRELY on the application. I don't think there's a blanket rule that can be assumed on this. For what it's worth, completely random data here. Simple test Win32 app on Win2K SP3: first stack variable: 0x0012fb30 WinMain: 0x00401262 192MB static variable: 0x00584234 first malloc address: 0x11466840 I take from the above that it partitions memory as stack/code/static data/heap. If you allocate yourself a very large stack, then it limits your available address space as well (any ideas why they don't put the stack at 2GB and grow down? I guess if you exceed your stack it will automatically generate an exception with the current scheme, vs. watching for "top of heap"). Not sure what any of that means, but thought it was interesting anyway in some form =) -Hook |