Limo's replacement for Ernie's Alloc() and Free() PLEASE TEST.

[hutch--]

A few weeks ago Limodriver did some research and debugging work on Ernie's old COM base Alloc() and Free() procedures to solve a number of problems that he found with the original code. Limo has since gone missing but in the meantime Michael Webster has designed a test piece to put the repaired procedures through a number of tests to see how reliable they were.

I have attached Michael's test piece in the hope that some of our members could run the test code to verify it and particularly if anyone has enough experience in COM programming that they could have a look at the code design.

[attachment deleted by admin]

[u]

:S why call every time IMalloc (adding overhead of call/lea/ret in 99.9(9)% of the cases) ?
:) Why not something like:

Code Select Expand


_Alloc proc PUBLIC uses ecx edx dwSize
@@:
mov eax,Alloc_pIMalloc
.if eax
push dwSize
push eax
mov eax,[eax]
call dword ptr [eax+12]
ret
.endif
invoke CoGetMalloc,1,addr Alloc_pIMalloc
jmp @B
_Alloc endp


[MichaelW]

I was assuming that the overhead would not be significant. Now that I test it I get about 4 cycles for the call/lea/ret, about 400 cycles for a minimal allocation, about 180 cycles for a minimal reallocation, and higher cycle counts as the allocation size increases, and to a lesser extent as the reallocation size increases.

[dsouza123]

Attached the two dump files and a screen capture of the run.

screen capture

Code Select Expand


heap busy entries    : 48
heap allocated total : 1046406

press any key to start...

allocations          : 4518308
reallocations up     : 4518308
reallocations down   : 4518308
allocation frees     : 4518308
maximum allocation   : 4194304
minimum allocation   : 1
minimum alignment    : 8
errors               : 0

press any key to stop...

heap busy entries    : 48
heap allocated total : 8386182

press any key to exit...

[attachment deleted by admin]

[zooba]

The function names seem somewhat inconsistent. Why not prefix them all with COM (ie COMAlloc/COMRealloc/COMFree). AFAIK these aren't used by the standard Windows libraries.
Otherwise, looks good :thumbu

Cheers,

Zooba :U

[hutch--]

The general drift of Limo fixing Ernie's old code was that it could be used in exactly the same place without breaking existing applications that use it.

[zooba]

The general drift of Limo fixing Ernie's old code was that it could be used in exactly the same place without breaking existing applications that use it.

Fair enough, though you can do that easily with an EQU and encourage new uses of the code to use more consistent names.

Just my opinion. I'm quite keen on consistency within libraries and I'm not afraid of breaking backwards compatibility. Then again, I've never written a widely used library, so perhaps this is simply lack of 'real-world' experience :wink

Cheers,

Zooba :U

[vid]

why use COM for this? why not good old plain API?

I really can't understand following piece of code, could someone explain it please?

Code Select Expand

@@: invoke  CoGetMalloc, 1, ecx
    or      eax, eax
    jz      IMalloc

shouldn't it have been more like this? (2 fixes)

Code Select Expand


@@: invoke CoGetMalloc, 1, ecx
or eax, eax
jnz @b

this is still not a good idea, but it least has some sense...

by the way, are you sure CoGetMalloc increments reference counter?

[hutch--]

I personally agree and don't use COM to allocate and free memory, especially as the API system has more methods that are more ajustable than the COM system. Ernie Murphy designed this method years ago and Limo recently fixed it and it is in place so that anyone who had previously used it would not end up with broken code or different design code than their original code had used.