Inquiry on immutabillity of objects and how they affect memory

Dear Team,

Please find below queries that I have;

  • does immutable objects increase memory footprint in an application?
  • how will immutable objects be released from memory without being disposed from application level?
  • are immutable objects released from memory after application stops or when processing is ongoing?

When programming in .net environment, i usually had to dispose objects after use so as to release them from memory and improve performance of the system. In Scala when declaring an object as val makes it difficult to set it to null, so that makes me think that the memory will be filled up especially when processing high volumes of transactions.

  • does immutable objects increase memory footprint in an application?

It can, but not necessarily. It depends on your particular application.
The opposite can also happen. Between adding a node to a linked list and creating a new array, copying old items to it, and then disposing the old array, which is more memory? The mutable array.

  • how will immutable objects be released from memory without being disposed from application level?

The same way mutable objects are released, which is by the garbage collector.

  • are immutable objects released from memory after application stops or when processing is ongoing?

Immutable objects are released from memory when there are no references to them, the same as for mutable objects.

1 Like

The garbage collector is responsible for the second two bullets. Anything that is made and used in a local scope will become unreachable once that local scope has closed. The “setting to null” really should be a special case situation for things like references in long-lived data structures that might keep references longer than they are needed.

The first bullet is the more interesting one, and with so many things in software development, it turns out that the answer isn’t straightforward. It depends a lot on how things are done in your software. To understand why consider the situation where you have a class that has a collection in it that it uses to store values. At times the clients of this class need to get the collection for the purposes of reading the values. However, for a variety of reasons, you don’t want the clients to be able to change the values as it will potentially break invariants in the class. If the collection is mutable, the “get” method will have to return a defensive copy. If it is immutable, that copy isn’t needed.

So while being mutable might allow the class to use less memory on modification, it almost certainly causes it to use more memory, due to defensive copying, on other calls that need to provide access to the data. This same type of thing occurs in many other situations, like when passing collections into other code that shouldn’t change it. So the bottom line is that you often don’t know in advance whether a well-coded system will use more memory using mutable collections or immutable collections. The true answer requires knowing information about the usage. You rarely know how much defensive copying will cost relative to the memory usage from immutability, especially since immutable data structures are generally optimized to not consume too much memory on change.

So if the decision is just based on memory, it is a toss-up. However, being immutable also has advantages for being able to cleanly reason about your code, not to mention the issue of race conditions if your code is multithreaded. For that reason, you should generally prefer immutability and only go to mutable structures when you have clear evidence that it will provide benefits.

1 Like

@shawjef3, @MarkCLewis Thanks so much for your detailed explanation. I have learnt so much from the valuable information you shared. I will now confidently use immutable objects without any worry of causing memory issues especially when processing high volume transactions through akka streams.