Does MEMFREE need to be called if the Memory Block is an existing variable?

[EricE]

Does _MEMFREE have to be called if the memory block is an already existing variable?
Consider the following program, the variable x is already DIM as an INTEGER.
Does _MEMFREE have to be called to release the Memory Block?
In this program the variable x still exists after _MEMFREE is called.
So what actually is the memory block released in this program?

Another way of asking the question.
If we have the following:

DIM m AS _MEM
DIM x AS INTEGER

Is any new memory allocated when we write the following?

m=_MEM(x)

Code: QB64: [Select]

1. DIM m AS _MEM
2. DIM x AS INTEGER
3.  
4. m = _MEM(x)
5.  
6. _MEMPUT m, m.OFFSET, 1 AS INTEGER
7.  
8. _MEMFREE m
9.  
10. PRINT x
11.  

[SMcNeill]

There's a few bytes allocated to hold the mem type information with each DIM m AS _MEM statement, but no new memory is allocated anywhere unless _MEMNEW is used. 

M = _MEM(X) basically just gives you a pointer to X, so you don't have to obsess quite so much about making certain to use _MEMFREE.

M =_MEMNEW(8) -- now this allocates new memory for M each time it's called, so don't forget your_MEMFREE with it.

[EricE]

Hi Steve,
Thank you for your reply.
I wrote this program to see what happens if _MEMFREE is not called.
It is currently running on my PC and I am going to leave it going while I look go to WalMart to look for supplies.
Windows task manager says it is using 59.1MB of memory. Will check what it is using when I return home.

Code: QB64: [Select]

1. i& = 1
2. WHILE i&
3.  
4.     IF i& MOD 1000 = 0 THEN PRINT i&
5.     MemSub
6.     i& = i& + 1
7.  
8. WEND
9. SUB MemSub
10.     ' Very large array, 100,000,000 elements, each element 8 bytes in size.
11.     DIM a(10000000) AS _INTEGER64
12.     DIM mema AS _MEM
13.  
14.     mema = _MEM(a)
15.     ' do something with array
16.     _MEMFILL mema, mema.OFFSET, mema.SIZE, &HFFFFFFFFFFFFFFFF AS LONG
17.  
18. END SUB

[SMcNeill]

It shouldn't do anything.  When the sub exits, your array is freed and so is the mem block, automatically.  ;)

[EricE]

Just checked the program now at 9:35am, it has been running since about 8:18am, so for 1 hour, 17 minutes, output counter is at 2816000, and the Task Manager memory usage is at 30.7MB!
The drop is probably due to Windows management.
I will continue to let it run.

EDIT to add:
I let the program run for some hours, no memory leaks were observed. In fact memory usage appeared to go down!
This really was a benign test since the program really wasn't expected to not release memory.

[EricE]

On the QB64 wiki page for the  MEM (function)
http://www.qb64.org/wiki/MEM_(function)
this example is given:

Code: QB64: [Select]

1. DIM SHARED m(3) AS _MEM
2. DIM SHARED Saved(3)
3.  
4. m(1) = _MEM(x)
5. m(2) = _MEM(y)
6. m(3) = _MEM(z)
7.  
8. x = 3: y = 5: z = 8
9. PRINT x, y, z
10. Save x, y, z
11. x = 30: y = 50: z = 80
12. PRINT x, y, z
13.  
14. RestoreIt
15. PRINT x, y, z
16.  
17. _MEMFREE m(1)
18. _MEMFREE m(2)
19. _MEMFREE m(3)
20. END
21.  
22. SUB Save (n1, n2, n3)
23. Saved(1) = n1
24. Saved(2) = n2
25. Saved(3) = n3
26. END SUB
27.  
28. SUB RestoreIt
29. _MEMPUT m(1), m(1).OFFSET, Saved(1)
30. _MEMPUT m(2), m(2).OFFSET, Saved(2)
31. _MEMPUT m(3), m(3).OFFSET, Saved(3)
32. END SUB  

Can we say definitely that the three _MEMFREE calls are not necessary in terms of freeing up memory?
The compiler has already allocated memory for the variables x, y, and z, and these variables continue to persist after the calls to the _MEMFREE function, so their memory blocks have not been freed.

[EricE]

Streve wrote:

There's a few bytes allocated to hold the mem type information with each DIM m AS _MEM statement, but no new memory is allocated anywhere unless _MEMNEW is used.

So how much memory do _MEM types take up?

This program uses LEN to find out.

Code: QB64: [Select]

1. DIM ofset AS _OFFSET
2. DIM m AS _MEM
3.  
4. $IF 32BIT THEN
5.     PRINT "32-BIT VALUES"
6. $END IF
7.  
8. $IF 64BIT THEN
9.     PRINT "64-BIT VALUES"
10. $END IF
11.  
12. PRINT
13. PRINT "LEN(_OFFSET) = ", LEN(ofset)
14. PRINT "LEN(_MEM)    = ", LEN(m)
15.  

Running this program using the QB64 32-bit and 64-bit compilers gives the following data:

32-BIT VALUES

• LEN(_OFFSET) =  4
• LEN(_MEM)      = 32

64-BIT VALUES

• LEN(_OFFSET) =  8
• LEN(_MEM)      = 52

[SMcNeill]

If you're really curious, you can see what a mem_block structure contains behind the scenes in common.cpp:

Code: C++: [Select]

1.  
2.   struct mem_block{
3.         ptrszint offset;
4.         ptrszint size;
5.         int64 lock_id;//64-bit key, must be present at lock's offset or memory region is invalid
6.         ptrszint lock_offset;//pointer to lock
7.         ptrszint type;
8.         /*
9.             memorytype (4 bytes, but only the first used, for flags):
10.             1 integer values
11.             2 unsigned (set in conjunction with integer)
12.             4 floating point values
13.             8 char string(s) 'element-size is the memory size of 1 string
14.         */
15.         ptrszint elementsize;
16.         int32 image;
17.     };

ptrszint is 4 bytes on 32-bit systems, 8 bytes on 64-bit systems to hold offset/pointer values.
int32 is basically a LONG, at 4 bytes.
int64 is an INTEGER64, and 8 bytes.

Which, when totaled up, gives you the 32 or 52 which you found totaled up with LEN() in your test code.  ;)

[EricE]

Now that is very interesting!
A look under the QB64 hood.
Thank you Steve.