Why use Z_malloc?

[chippo]

On a busy modern Linux desktop, with a combined paging, swap, buffer cache memory system there will often be no free memory. But thats OK, 'cos if you ask for some, some other things will get shuffled out of the way (provided there's swap space left) and your request will succeed. I assume it's similar under windows.

With legacy, when starting the game, it often bombs for me due to memory shortage. But thats OK, the attempt to run it has started the shuffling process, and if I just hit up-arrow enter, it always works the second time.

I assumed that this was because the z_malloc system was designed to run on dos4gw (which had neither a buffer cache nor swap) and no-one had got around to modernizing it.

But looking through docs/features.html I see under 'Other new features':
- Autoexpanding Zone Memory system. Never run out of memory, until you REALLY run out of memory.

If we were going to do any work on the memory management in legacy, why not replace that whole z_malloc system with the C++ built-in 'new'?

Ciao,
chip-ho

[Graf_Zahl]

The zone memory is a completely obsolete system and if it wouldn't be such a large amount of work should be dumped for good. Using the system's standard heap is certainly preferable. The only 'advantage' the zone heap provides now is that you don't need to care about memory leaks. Flushing the entire heap after each level will free all of it anyway.

[Ajapted]

If we were going to do any work on the memory management in legacy, why not replace that whole z_malloc system with the C++ built-in 'new'?
Don't underestimated the amount of work this would take, it really is a huge task (speaking from experience, we have removed about half of the zone stuff in EDGE).

One big difficulty is all the PU_CACHE allocations. They don't have corresponding Z_Free calls, because the zone code handles this memory (can re-use it when needed). Adding delete in the right places is a real pain, you may need to create a new caching system for that stuff. Plus there is code that changes the PU tags...

Lastly, I recommend you don't do what we did and replace the zone incrementally, do it in one fell swoop, because keeping track of what has been allocated with the zone and what has been allocated with new and making sure the pointers are freed the right way is definitely not fun :)

[smite-meister]

We're actually halfway through this process in Legacy 2.0. Currently the Z_* funcs are just wrappers for malloc/free (plus the void **user functionality). Most memory is freed explicitly, but there are some PU_CACHE remaining (and we leak memory like hell :))

Fixing the PU_CACHE stuff isn't that hard though, just remove its definition from z_zone.h and fix all resulting compilation errors with code that also frees the memory afterwards.'

Oh yeah, valgrind with --leak-check=full will be helpful too.

[Graf_Zahl]

Don't underestimated the amount of work this would take, it really is a huge task (speaking from experience, we have removed about half of the zone stuff in EDGE).


Tell me about it. ;)

I had first hand experience with this when I ported FraggleScript to work with GZDoom. That code was leaking memory like hell and didn't care about proper memory tracking at all. I still don't know how I managed to plug all the leaks in it...

[OldGrump]

Cool !
i'm glad to see that Doom Legacy isn't dead
and that someone is working on z_malloc (which is adjustable if you have a PC with windows) but not otherwise, a.f.a.i.k. otherwise no other way to give DoomLegacy
more memory to play with

JB

[MR_ROCKET]

Checking the SVN from time to time will give you a good idea that L2 is anything but dead heh.
What would have made you think otherwise?

[Planky]

I don't know, the lack of development for the past 5 years?

(until now of course)

[MR_ROCKET]

Well this (http://forums.newdoom.com/showpost.php?p=483610&postcount=43) was back in September 2006 Planky.
But yeah more so now than before then I suppose, if we'r both talking about L2 that is. ;)

[smite-meister]

I don't know, the lack of development for the past 5 years?
(until now of course)
Not entirely accurate. We've been working on Legacy2 slowly but surely for the last 4 years or so, it's just that now the improvements are becoming apparent.
http://doomlegacy.svn.sourceforge.net/viewvc/doomlegacy/legacy/?view=log