Size of memory

[Thaddy]

well as long as the allocation is bigger and not smaller I would not worry too much.
Except for the irrecoverable memory leaks you cause by not storing the pointer...

[BrunoK]

The size returned by MemSize is the size of the contiguous memory allocated by GetMem.

In practice, heap.inc allocates by blocks that have a start address compatible with the ABI and generally in size multiples of 8  or 16. (That would have to be checked ...).

This fact is used, for example, in heaptrc to determine if a reallocation fits in the currently allocated block thus avoid a ReallocMem.
The ansistring manager also use this information to determine if a string result might be put back (example Str1 := Str1 + Str2; wehre Str1 is an existing string) at the same location without needing any reallocation/copy-move.
In a TList, if you query the List field for its size, it is very likely that it may be much bigger than what the .Capacity might suggest.

In short, you can use all the memory block returned up to its MemSize

[Thaddy]

In short, you can use all the memory block returned up to its MemSize

No, you can't: the block + slack is taken, but if you go beyond the requested size you will get a memory overrun. Again, this depends on the memorymanager.
As a rule of thumb you can only use the space you requested.

[BrunoK]

No, you can't: the block + slack is taken, but if you go beyond the requested size you will get a memory overrun. Again, this depends on the memorymanager.
As a rule of thumb you can only use the space you requested.

That is simply wrong. You have the sources, look at them.

Heap.inc returns the available memory effectively allocated to the pointer during the getmem. That size is fully available for use.

Illustrate you pretensions with a non buggy program that would show the contrary.

Debug FPC to look how / what it does in .\rtl\inc\astrings.inc in the fpc_AnsiStr_SetLength compilerproc, search word memsize.

Actualy, for a getmem the Size of the allocation is at memory offset of returned Pointer - SizeOf(Pointer).

[MarkMLl]

Illustrate you pretensions with a non buggy program that would show the contrary.

I certainly wouldn't put it as strongly as that, but I'm /very/ concerned that a respected member of the community has posted results that are apparently at odds with everybody else.

MarkMLl

[ASerge]

Also, what is the difference between MemSize and SysMemSize? I can not find anything about that in the documentation?
I can not find anything about SysFreememSize too, what it does?

The memory management system in FPC is flexible. By default, it is used global variable MemoryManager from System (heap.inc). Here is a simplified definition:

Code: Pascal  [Select][+][-]

1. const
2.   MemoryManager: TMemoryManager = (
3.     NeedLock: false;  // Obsolete
4.     GetMem: @SysGetMem;
5.     FreeMem: @SysFreeMem;
6.     FreeMemSize: @SysFreeMemSize;
7.     AllocMem: @SysAllocMem;
8.     ReAllocMem: @SysReAllocMem;
9.     MemSize: @SysMemSize;
10.     InitThread: nil;
11.     DoneThread: nil;
12.     RelocateHeap: nil;
13.     GetHeapStatus: @SysGetHeapStatus;
14.     GetFPCHeapStatus: @SysGetFPCHeapStatus;
15.   );

All calls to GetMem, FreeMem, etc. are mapped to method calls of this entry.
You can also call the SysXXX versions directly, for example, if you make your own memory manager, but in general this is not recommended.

[jamie]

I think there should be some docs attached to this function, it obviously was not intended for user code.

But I can give you an example of a failure, if Somewhere in a tight loop of adjusting memory to a pointer, and you decide to use this function to retrieve the current size, and then decide to fill that buffer with the size reported, I can see where this would leak into somewhere else.

  I haven't look deeply but it's obvious there is a pointer size variable either at the start or end of the block so the FreeMem would know how much to free. I mean, the info for the current size of the pointer allocated must come from somewhere, and it's obvious its part of the complete block of memory being reported from MemSize.

  So if the pointer returned is after the Length variable in the block this would mean we could miss use that info and flood memory.

[Thaddy]

Oh, well, try this in loop

Code: Pascal  [Select][+][-]

1. WriteLn(MemSize(GetMem(1024)));

[jamie]

I would very seriously consider looking at the Winapi.inc files for all the widgets, they have use the MemSize without any regards
of this concern.

 Most of them are in the Gradient Fill code, some other parts of the other widgets etc.

[BrunoK]

Illustrate you pretensions with a non buggy program that would show the contrary.

I certainly wouldn't put it as strongly as that, but I'm /very/ concerned that a respected member of the community has posted results that are apparently at odds with everybody else.

MarkMLl

Should be easy for you geniuses to post a simple program that would break if Memory was accessed within the memsize returned  by the call to memsize but larger than the Size specified in getmem.
Respected member or not, prove it.

[jamie]

For me, I would rather not use a function that does not return actual value that it was set for by USER code.

 For example:

   After some iterations of memory sizing in some code, you may want to save the MemSize at the current moment and come back later to again use GetMem via the last size. If this function keeps ramping up the actual size, if that is what it's really doing, then at some point you start to get false values and excessive memory use.

 You could even take a chance of using the reported value to index elsewhere and thus end up in space.


 

[MarkMLl]

Should be easy for you geniuses to post a simple program that would break if Memory was accessed within the memsize returned  by the call to memsize but larger than the Size specified in getmem.
Respected member or not, prove it.

I'm not the one arguing, or posting test results at apparent odds with reality...

MarkMLl

[jamie]

I just found something.

If you use HeapTrc, it works perfectly, if you don't use HeapTrc, it does this..

P.S.

 I did a loop taking the size of the previous and allocating a new one, it stays at 1028, so this means its doing page alignment.

 but that isn't good for the user to expect reading it back to be what it was set for.


P.S#2
  IT appears the memory manager without heapTrc is using whatever chucks of memory that is available, because starting with different values gives you random results, but they are all sufficient to hold the requested data, just not an accurate measure for use in code elsewhere.
     
  This at least needs to be documented to use it for an indicator of memory allocation in user code.

[Zvoni]

Win10-64 Bit --> FPC3.2.2 32 Bit
Result (both)=1028
No "modes" whatsoever (objfpc et al)

EDIT:

I just found something.

If you use HeapTrc, it works perfectly, if you don't use HeapTrc, it does this..

Same with cmem.
Using cmem, it reports 1024 for both

[Thaddy]

I would very seriously consider looking at the Winapi.inc files for all the widgets, they have use the MemSize without any regards
of this concern.

 Most of them are in the Gradient Fill code, some other parts of the other widgets etc.

It is not memsize, it is getmem without storing the pointer...
Your initial code is bad. You can't release that memory.