flat assembler
Message board for the users of flat assembler.

Index > Windows > What is the best way to organize dynamic structures in memor

Author
Thread Post new topic Reply to topic
ProMiNick



Joined: 24 Mar 2012
Posts: 802
Location: Russian Federation, Sochi
ProMiNick 14 Jun 2015, 19:39
Hello fasm society.
Sorry for my english (I think russian and write as i think).

What is the best way to organize complex dynamic structures in memory?
Heap or some kind of memory reserve and memory alloc?
What advantages?
And what limitations are for each kind of memory organization?

For fasm as i see used memreserve/alloc, but for fresh and fasm g used heap.

And I will be granted if you describe memory organization in other OSes: presense of method,advantage and limitations.

Very big thanks.
Post 14 Jun 2015, 19:39
View user's profile Send private message Send e-mail Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria
JohnFound 15 Jun 2015, 03:52
Never use Global/LocalAlloc family of functions - they are Win3.11 heritage. In the newer Windows, they are implemented on HeapAlloc family, so why to call one more API layer?

Use HeapAlloc for variables that are needed immediately and will be freed, rather than resized/moved in memory.

Use VirtualAlloc family of functions for bigger blocks of memory, allocated/increased on pages.

For example, for the OSes, not having heap manager API, FreshLib has its own heap manager implementation and this heap manager in Windows uses VirtualAllocate in order to allocate needed big memory blocks, that are later allocated on smaller chunks by the heap manager. See the code: Win32/heapmgr.asm

At the end, don't forget about memory mapped files - they are also way for memory management.
Post 15 Jun 2015, 03:52
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 671
vivik 07 Nov 2016, 11:38
Can somebody confirm the "never use GlobalAlloc" thing? Because I noticied fasm doesn't use HeapAlloc too, and keeping an extra handler as a global variable is problematic for me.

What is the recommended size of allocations if I'm planning to do my own memory management? Chunks of 4096 bytes?

Is the data I can request with GlobalAlloc limited in any way? There is a SizeOfHeapReserve field in the PE header, does it matter anything anymore?

This link https://msdn.microsoft.com/en-us/library/windows/desktop/aa366533(v=vs.85).aspx mentions that
>Starting with 32-bit Windows, GlobalAlloc and LocalAlloc are implemented as wrapper functions that call HeapAlloc using a handle to the process's default heap. Therefore, GlobalAlloc and LocalAlloc have greater overhead than HeapAlloc.
But how big this overhead is, I wonder.
Post 07 Nov 2016, 11:38
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 07 Nov 2016, 12:10
vivik wrote:
But how big this overhead is, I wonder.
That depends upon your application. A good way to find out is to test it both ways in your app and see how much difference it makes.
vivik wrote:
Can somebody confirm the "never use GlobalAlloc" thing?
I'm not a big fan of those absolute proclamations. If it suits your application then use it. Each app has different requirements so saying "never" do something is, at best, overstated.


Last edited by revolution on 07 Nov 2016, 13:30; edited 1 time in total
Post 07 Nov 2016, 12:10
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 671
vivik 07 Nov 2016, 13:19
It's possible that fasm uses GlobalAlloc because it's used very very rarely by fasm anyway.
Post 07 Nov 2016, 13:19
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 07 Nov 2016, 13:32
Memory allocation in fasm is an insignificant portion of the runtime. It makes no sense to even worry about it unless it suddenly doesn't work for some reason.
Post 07 Nov 2016, 13:32
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1635
Location: Toronto, Canada
AsmGuru62 07 Nov 2016, 15:48
GlobalAlloc() is the one to use to copy stuff into Clipboard.
Other than that - just use HeapAlloc() for small blocks and VirtualAlloc() for large ones.
Post 07 Nov 2016, 15:48
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 07 Nov 2016, 21:23
AsmGuru62 wrote:
... just use HeapAlloc() for small blocks and VirtualAlloc() for large ones.
Why? Once again an absolute proclamation. Without knowing the usage within the app, or even what the app does how can we know what to suggest?

Here is my suggestion;

If you need good control over memory alignment and the access permissions (i.e. read/write/execute) then use Virtual* functions.

If you want flexibility over allocation/deallocation/compacting and prefer to keep your code less complex then use Heap* functions.

Otherwise feel free to ignore the above and use whatever is easiest for you. Because for most apps the memory allocation is not going to be a significant issue. And until it clearly becomes an issue don't worry about it. The OS will do the right thing in almost all cases no matter which function(s) you use.
Post 07 Nov 2016, 21:23
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 671
vivik 16 Nov 2016, 09:32
Ok, as I understood it:
if you are ok with getting 64KiB (actually only 4KiB, but still the whole 64KiB are reserved) of memory every time you ask for memory, use Virtual*. You will even get control over access permission flags as a bonus.
if you need something smaller and don't want to write your own memory manager, use Heap*/Global*, but you'll have to deal with memory fragmentation, but who cares about that.


Last edited by vivik on 16 Nov 2016, 09:44; edited 1 time in total
Post 16 Nov 2016, 09:32
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 671
vivik 16 Nov 2016, 09:42
I once heard an advice about placing data you frequently use close to each other, because this way it will fit in the cpu cache nicer or something. Can somebody link me to more info about that?
Post 16 Nov 2016, 09:42
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 16 Nov 2016, 10:30
vivik wrote:
I once heard an advice about placing data you frequently use close to each other, because this way it will fit in the cpu cache nicer or something. Can somebody link me to more info about that?
I'm not sure what you heard. But I imagine it would only matter on the smallest scales (i.e. within a single cache line) any larger structure will not make any difference because of the content addressing hardware (unless you strike the rare problem of aliasing, in which case you should probably read up about it because it is quite a complex issue).
Post 16 Nov 2016, 10:30
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.