Deallocating memory after going out of scope

1 
address[] memory path = new address[](0);
for (uint i = 0; i < manyTimes, i++) {
   address[] memory newPath = foo(i);
   path = compare(path, newPath) ? newPath : path;
}

Do the compiler deallocates the newPath after every loop iteration?
By deallocation i mean possibility to write to this memory block, i.e. do the compiler write newPath on the same place on the next iteration, or is it allocate a new memory block for it?

2

It definitely deallocates it at the end of the scope (the end of the loop, in this case).

You (the developer) is not supposed to care about the compiler’s internal implementation of the memory-management scheme (i.e., you can and should remain oblivious to that as part of your implementation considerations).

Unrelated to any of your questions, but there are probably better ways to implement the above.

For example, assuming that the compare function compares the contents of the input arrays, you may as well just do path = foo(i).

Or alternatively, the foo function can simply take path as an additional input and update its elements.

Or alternatively, the foo function can simply conduct the comparison internally and return the original path or the new path according to the result.

1 Like
3

[/quote]
It definitely deallocates it at the end of the scope (the end of the loop, in this case).
[/quote]
Isn’t memory allocated for dynamic arrays managed by the programmer? and the deallocating of memory is not done automatically at the end of the scope.

4

No, it seems its not deallocating.

pragma solidity ^0.8.19;

import "hardhat/console.sol";

contract TestMemory {

    function test() external view {
        printMemory();
        uint[] memory t;
        for (uint i = 0; i < 20; i++) {
            t = new uint[](2);
        }
        printMemory();
    }
    
    function printMemory() public view {

        uint pointer;

        assembly {
            let firstFreeMemoryPointer := mload(0x40)
            pointer := firstFreeMemoryPointer
        }

        console.log(pointer);
    }
}

Calling test() function with different loop values shows that the allocated memory increases proportionally to iterations number.

So yes, i must care about compiler implementation, because in the other case transaction gas will jump skyrocket.

5

I find it hard to believe that the compiler does not deallocate memory correctly.
I can’t quite see how deployed byte-code would work correctly in the long term.
Incorrect memory-management would pretty quickly render this entire ecosystem useless.
Yet, it’s been working in a pretty robust manner for about 6-7 years AFAIK.

1 Like
6

It is, but as far as I read, this user is concerned with the fact that the deallocation part is not something to count on as being executed correctly.

In other words, this user suspects that the byte-code generated by the compiler is not something to be trusted as far as memory deallocation goes.

I disagree, of course, as explained in my two other responses (above)…

1 Like
7

Oh, you’re right. There’s indeed no need to worry. Thank you so much for your response. You’re really kind.

1 Like