I designed it for allocating thousands of small objects (1..8192 bytes), but with apropriate tweaks (it's easy to tweak), it can handle millions of objects too. With minimum possible overhead on alloc/free.?
I'm thinking of using it as memmanager for objects in ATC

Has a debug proc to see how many pages (and objects in them) are allocated, detecting memory leaks is a snap.
Also, you can free all allocated data in one call - just in case there are leaks, and just in case Windows doesn't handle them.

Compiled as a .lib with an .inc for the exported procs, also included an example app.

Download it from here (end of the thread)
Posted on 2005-03-10 14:35:03 by Ultrano
Great stuff.  :)
I have a couple of questions.  Do you have some benchmark results?  It would be great if I could see some numbers.  Another question:  Is it thread-safe?  I cannot find thread-safety idioms in the code.  If you have it coded, would you tell me which part of the code deals with thread issues?
Posted on 2005-03-10 17:41:55 by Starless
I forgot to mention that it's not thread-safe ^^", and I'll make it safe sometime today. And I haven't made benchmarks for the same reason - I've got lots of work right now
Posted on 2005-03-11 03:06:12 by Ultrano
Posted an updated (MJB04) archive at the link mentioned in the first post, SmallAlloc is now thread-safe. Haven't made benchmarks, but mostly because I know that when SmallAlloc is used apropriately, it will outperform any other memory manager :) . Just don't expect it to be very fast if you allocate one object and then release it before allocating another object of the same siz - the page it had reserved will be released to save memory. Homer told me he will make the benchmarking ^^
Posted on 2005-03-11 10:42:06 by Ultrano
Hi there, would you provide some link or information in memory managers ;) if you have a paper or some like that :D. I have finded some info on internet ;), but a primer guide should be usefull :D.

By the way, thnx for the source, Im watching it :D.
Posted on 2005-03-11 20:15:26 by rea
WOW HeapAlloc beats me
Homer reported SmAlloc is slow but probably because of using VirtualAlloc. I modified SmallAlloc to use HeapAlloc for the large chunks, and lost a few percent of performance (instead of the expected becoming ten times faster). This happens for 20000 or above objects, till then both functions (SmAlloc and HeapAlloc) are equally fast.
When the objects become 1,000,000 , SmAlloc becomes .. 30 times slower ^^" . So long for the trust in me ^^".

At least this proves now that I've used the best memory manager till now - HeapXXX ^^. This is a lot of relief for me.

But despite its performance, SmAlloc is useful for two things:
- takes much less memory than HeapXXX when the objects are tiny (because HeapXXX aligns new objects to 16 bytes, + adds several dwords before the object). If I allocate 1,000,000 RECT objects with SmAlloc, I get 16,125,000 byte system memory (only 125,000 bytes extra). If I use HeapAlloc, it's 32,000,000 bytes (I think), which is 16,000,000 bytes extra.
- is very useful for debugging - you can see quickly how many objects of what size are currently allocated.

Today's lesson's learnt - no need for custom memmanagers, and I should not make unverified statements ^^"

rea: I haven't read any info on memmanagers, maybe that's why I failed with the performance of this one ^^. I only have been toying with HeapAlloc of win98SE.
Posted on 2005-03-12 02:19:18 by Ultrano
I believe smAlloc is still a viable container for object enlistment, and an efficient paging manager in general. I would like to see it wrapped as an oop object unto itself, that it may be instanced as a generic paged object management system, rather than its more limited use as a single instance of a universal memory manager.
It might mean that page memory use can be streamlined via an internal objectsize field, but at the very least it would solve my day to day worries with management of large arrays of objects where I need to be able to enumerate them by pointer etc..
Posted on 2005-03-22 05:48:35 by Homer
Hmm making a macro to create a template of fixed-sized objects (like C++'s vector <TemplateType> ) is possible .. and I see good uses of it. I think I'll make it when I have time, now I have more than a dozen other requests . Job first, then FIFO. :)
Now that my own wish to continue making commercial games is acknowledged, I'll have even more things on my mind ^^"
Posted on 2005-03-22 10:22:23 by Ultrano
Hello, Mir. Ultrano:

ask you some questions for MemManager.

I'v used the follow codes, but the problem has been still there.
invoke GlobalAlloc,GPTR,128d
mov lpMacbuf,eax
invoke GlobalFree,lpMacbuf
invoke GlobalAlloc,GMEM_MOVEABLE or GMEM_ZEROINIT,128d
mov? hMemory1,eax
invoke GlobalLock,hMemory1
mov lpMacbuf, eax
invoke GlobalUnlock,hMemory1
invoke GlobalFree,lpMacbuf
invoke SmAlloc,128d
mov lpMacbuf, eax
invoke SmFree,lpMacbuf

if you have a leisure time. please check the code ( I send it you with a email. )?
the code needs 44MB memory to run first.
the problem is:
1. sometimes the lv_13.exe is running ok, sometimes the lv_13.exe crashed.
2. when the lv_13.exe ran, the process id (will be run) in the system become very large.
3. used the "invoke SmFree,lpMacbuf", but the code can't free memory( Knew from a memory Monitor soft). when second click button "get list", the lv_13.exe must be crashed.?

Posted on 2005-04-26 02:52:07 by dcskm4200
First problem:
invoke SmAlloc,65535d
And at another place you allocate too big arrays. And you allocate a lot of string-like objects, which in the readme.txt I warned is a "no-no". The link between HeapAlloc and SmAlloc is not perfect - if you code very uncarefully, you can get to this situation:
(do NOT do this: )
1) Allocate a small ( < 30kB) object, whose size is new to SmallAlloc:  mov pSomeArray,$invoke (SmAlloc,30000)
2) Free that object:  invoke SmFree,pSomeArray
3) Now, since this object is the only one in a whole 64kB page, that page has been released and SmallAlloc doesn't know it anymore.
4) Free that object: invoke SmFree,pSomeArray . (This is a bug of the coder, not in SmallAlloc)
5) SmallAlloc will see this object is not in any of the available pages, so will think this is a Heap object. And will internally do: invoke HeapFree,pSomeArray
6) BUT since HeapFree reads 4 to 12 bytes before the array, and that page is no longer readable, it will cause a GPF

This can be fixed by adding Try/Catch protection macros in SmallAlloc, but overall this is not a bug in SmallAlloc :).
Try using a wrapper to allocation functions, that counts how many objects you've allocated (and released), and see in the end how much memory you've leaked.

Also, I noticed you don't use the stack for quickly getting 128 bytes. Instead, you should use:
local buffer[128]:byte
it costs 0 extra cycles, the buffer[] is probably already in cache, and you save hundreds to thousands of cycles for allocation and release of such objects.
Posted on 2005-04-26 10:02:47 by Ultrano
Hey. Ultrano

thanks you for guiding me a lot.

Actually, I'm not been thought a coder. I'm a win32asm fan. I'm only studying the win32asm for wasting my leisure time. I didn't understand how use your SmAlloc. I'll study your SmAlloc more carefully.

I'll modify the Lv_13.bat according to the method that you teached me. if I am been blocked by some problems, I hope you guide me again.

thanks again.
Posted on 2005-04-26 11:09:28 by dcskm4200

if I am been blocked by some problems, I hope you guide me again.

You're welcome, this board's sole reason for existing is helping each other in solving win32asm-related problems ;)
Posted on 2005-04-26 13:13:13 by Ultrano
Hey. Ultrano

a lot of small buffers made the memory was being at fragment status. However I used which memory API. after all Multithreads ret. at the time, the system free memory sizes is not becoming more. when closed lv_13.exe, the system free memory sizes is becoming more.

I didn't understand why the code " invoke GlobalFree,lpNamebuf... " can't worked in Arp_IP2MAC Multithreads.

adding Try/Catch protection macros in SmallAlloc
Try using a wrapper to allocation functions

i hope you give me a example for using the above.

Posted on 2005-04-27 08:39:38 by dcskm4200
Just use HeapAlloc/HeapFree and you'll be perfectly OK.

SmallAlloc was something EvilHomer2k and I needed - to spawn dozens of thousands of fixed-sized objects that will take as little extra space as necessary, and that will perform outstandingly in some specific occasions. I needed SmallAlloc since my previous internal memmanager could manage only 1 type of structures, and I need reusability of code for big projects.

So, I repeat: use HeapAlloc/HeapFree. SmallAlloc is not an universal memmanager :)
Posted on 2005-04-27 09:22:06 by Ultrano
Hey. Ultrano
Thanks you for help.
the problems is still there with using HeapAlloc/HeapFree. 

Posted on 2005-04-27 10:28:36 by dcskm4200
Just to attach the SmallAlloc.zip file here (by request). SmAlloc can't crash in the scenario I noted on above anymore :) .
Posted on 2006-08-07 04:53:05 by Ultrano
thanks you for sharing the new SmallAlloc.
great work!

your SmallAlloc works fine .
there is some problems in multi thread.
if i set =unknow, everytime the code is ok.

now, sometimes it is ok, sometimes it is crashed.

best regards

thanks specially for you still have remembered the question since long times passed
Posted on 2006-08-07 09:01:48 by dcskm4200
Imho, HEAP_NO_SERIALIZE means "I'm looking for trouble".
Please shift general discussion on HeapAlloc into another thread.
Posted on 2006-08-07 16:09:45 by Ultrano
First of all, it'a good code Ultrano and thanks.
May I suggest some thing ? I think it will be better if it destroys freed memory. For example; fill memory with 0xCCCCCCCC before free chuks(or release). It helps us to find out accessing already free memory errors.
(OK I coudn't express my self :) )
Posted on 2006-08-07 16:51:41 by Dite
To fill the memory that is about to be free, with 0CCh, at line 401 add this code:

; trace "found in chunk %d as ID=%d",lpChunk,ObjEntryID

push edi
mov ecx,.SmAllocChunk.ObjSize
mov edi,lpObject
mov al,0CCh
rep stosb
pop edi
;------[ check if this EntryID is really not free ! ]---------\
;mov ebx,lpChunk

(3 lines added to further pinpoint the code-location I mean)

Although I have used this memory-filling with 0xCC several times with MSVC++  (debug Configuration), I never found it any near being vital for debugging.
Posted on 2006-08-07 18:34:33 by Ultrano