# Deallocating memory after going out of scope

**URL:** <https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943>\
**Category:** Uncategorized\
**Created:** [October 26, 2023, 6:55am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943 "2023-10-26T06:55:26Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![todesstille](https://avatars.discourse-cdn.com/v4/letter/t/ac91a4/32.png) [@todesstille](https://forum.soliditylang.org/u/todesstille)\
**Post date:** [October 26, 2023, 6:55am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/1 "2023-10-26T06:55:26Z")

</div>

```auto
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?

---

<div class="post-metadata">

**Author:** ![barakman](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/barakman/32/830_2.png) [@barakman](https://forum.soliditylang.org/u/barakman)\
**Post date:** [October 26, 2023, 7:24am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/2 "2023-10-26T07:24:41Z")

</div>

> [@todesstille](#):
>
> Do the compiler deallocates the newPath after every loop iteration?

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

> [@todesstille](#):
>
> 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?

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.

---

<div class="post-metadata">

**Author:** ![Charels](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/charels/32/1080_2.png) [@Charels](https://forum.soliditylang.org/u/Charels)\
**Post date:** [October 26, 2023, 8:20am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/3 "2023-10-26T08:20:06Z")

</div>

[/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.

---

<div class="post-metadata">

**Author:** ![todesstille](https://avatars.discourse-cdn.com/v4/letter/t/ac91a4/32.png) [@todesstille](https://forum.soliditylang.org/u/todesstille)\
**Post date:** [October 26, 2023, 8:22am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/4 "2023-10-26T08:22:45Z")

</div>

> [@barakman](#):
>
> It definitely deallocates it at the end of the scope (the end of the loop, in this case).

No, it seems its not deallocating.

```auto
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.

---

<div class="post-metadata">

**Author:** ![barakman](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/barakman/32/830_2.png) [@barakman](https://forum.soliditylang.org/u/barakman)\
**Post date:** [October 26, 2023, 9:11am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/5 "2023-10-26T09:11:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![barakman](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/barakman/32/830_2.png) [@barakman](https://forum.soliditylang.org/u/barakman)\
**Post date:** [October 26, 2023, 9:16am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/6 "2023-10-26T09:16:41Z")

</div>

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)…

---

<div class="post-metadata">

**Author:** ![Charels](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/charels/32/1080_2.png) [@Charels](https://forum.soliditylang.org/u/Charels)\
**Post date:** [October 30, 2023, 8:14am UTC](https://forum.soliditylang.org/t/deallocating-memory-after-going-out-of-scope/1943/7 "2023-10-30T08:14:51Z")

</div>

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