Re: Mintlibs memory managing?

[Torsten Scherer <itschere@TechFak.Uni-Bielefeld.DE>]

Tamminen Eero writes:

> W (a primitive mono window system) uses Mxalloc. Author's comments
> on the W docs state that MiNTLib free doesn't release the memory
> back to MiNT. I'd like some clarification to that. Does it depend
> on the order of memory allocation / deallocation ie. when I free B in

 I don't know in what chunks MiNTLib allocates memory from TOS/MiNT, but
certainly you can't give it back until all of the minor and self administered
chunks are free. AFAIK there was simply a bug that prevented MiNTLib from
giving back memory to MiNT at all - even if everything in it was free. But
this is a year ago and I think was quickly patched short after this. Point
is that MiNT contrary to TOS allows an arbitrary number of M(x)allocs, so
I thought: Why bother?

> Should I allocate / deallocate in last-alloc -> first-free order to have
> maximum memory available for the OS all the time?

 In general: No. Both MiNT and MiNTLib are able to merge successive areas.
MiNTLib simply didn't give it back, that was the problem. What happens if
another process grasps the memory while you're freeing it piece by piece
is that you get fragmented memory, but there's nothing to do against this
under MiNT except having a real lot of it.

> That wouldn't help with W which can't know the size nor lifetime of
> a window backup, but for W applications it might matter quite a lot...

 Since in fact the server itself handles the window backup it knows about
these, but it can't know if it's a wise idea to not freeing it to avoid
memory fragmentation if a client died - and from W1R1 on there's no way the
server might miss a dying client.

 Problem was: Assume a window with a bitmap backup. Good. Now this client
dies, but the bitmap memory wasn't given back to MiNT. It's quite likely
that the server will reuse that memory later on for smaller bitmaps or
other things, but all in all it ends up with holding more memory than it
must.

 Funny, even yesterday I got the time and spirit to do some work at it
again after having done nothing for almost a year - probably because I'm
mainly using Linux68k by now. But I may happen to release W1R2 soon.
I'll announce it here on mint@aaue when it's done.

> What kind of limits MiNT and MiNTLib have for the number of allocated
> blocks?

 None, I guess.

> Which can handle better numerous very small blocks (like structures)?
> MiNTLib I would guess, what's it's overhead?

 Yep. Shouldn't be very much. Try to write a program to check it! :)

> Btw. Can I set how much free RAM GCC should leave the OS at minimum
> by setting GCC's stacksize to a negative value? Eg. would the following
> leave at least 256K free RAM for the OS:
> 	fixstk -256k cc1
> ?

 Don't know.

ciao,
TeSche
--
Torsten Scherer (Schiller, TeSche...), itschere@techfak.uni-bielefeld.de
Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...