B4J Question Avoiding memory leaks

j_o_h_n

Active Member
Licensed User
tl,dr Is it only datatypes with Close or Release methods that I need to worry about in terms of causing a memory leak?

If I declare a HttpJob inside a sub then I must use release at the end in order to not have a memory leak
Similarly for resultsets I must use the close method
I don't need to do anything like that for primitive datatypes because they only use space on the stack which will be reclaimed automatically I think.
Strings can be treated like primitives because of some clever stuff under the hood I guess
But stuff like Maps, Lists, JSONGenerators, JSONParsers they don't have close or release methods
Maps and lists do have clear methods but I don't know if this has any effect, in this context.
 

sfsameer

Well-Known Member
Licensed User
Longtime User
tl,dr Is it only datatypes with Close or Release methods that I need to worry about in terms of causing a memory leak?

If I declare a HttpJob inside a sub then I must use release at the end in order to not have a memory leak
Similarly for resultsets I must use the close method
I don't need to do anything like that for primitive datatypes because they only use space on the stack which will be reclaimed automatically I think.
Strings can be treated like primitives because of some clever stuff under the hood I guess
But stuff like Maps, Lists, JSONGenerators, JSONParsers they don't have close or release methods
Maps and lists do have clear methods but I don't know if this has any effect, in this context.
1- Timers
It's okay to have 1000 timers in your project but it's not okay to make the timers interval too low (Ex: 5ms or 10ms)
Also you need to make sure that they are working async without effecting the UI which would also cause memory leak

2- Images
Loading too many images without giving the time for the Android-IOS-PC (OS) to call the garbage collector is also a no-no , so try to avoid loading images in a large loop

3- Endless loops
Endless loops are just bad, for example looping inside a map and inside it you are looping inside a list and within you are also looping in a list items
just avoid multiple loops within 1 loop.

Other than the above i think you are good to go, the memory management is always handled by the OS but sometimes there are "developer mistakes" which can lead to postpone the garbage collection and that would cause a memory exception/leak

:)
 
Upvote 0

Erel

B4X founder
Staff member
Licensed User
Longtime User
Java has a garbage collector that destroys objects and reclaims the memory when they go out of scope and no references to them exist. So you don't need to worry about memory management at all.
This is mostly correct. There are ways to create memory leaks, for example if you keep adding bitmaps to a list.
As a general rule, don't be bothered about it unless you actually see an out of memory error.
 
Upvote 0

j_o_h_n

Active Member
Licensed User
1- Timers
It's okay to have 1000 timers in your project but it's not okay to make the timers interval too low (Ex: 5ms or 10ms)
Also you need to make sure that they are working async without effecting the UI which would also cause memory leak

2- Images
Loading too many images without giving the time for the Android-IOS-PC (OS) to call the garbage collector is also a no-no , so try to avoid loading images in a large loop

3- Endless loops
Endless loops are just bad, for example looping inside a map and inside it you are looping inside a list and within you are also looping in a list items
just avoid multiple loops within 1 loop.

Other than the above i think you are good to go, the memory management is always handled by the OS but sometimes there are "developer mistakes" which can lead to postpone the garbage collection and that would cause a memory exception/leak

:)
Thank you. I am not so concerned now that I understand that the GC will pretty much cover me even if I overlook something but can I ask about the 3 examples you put
up in your post. Is the essential problem with those that they might cause the usage of memory to get ahead of the GC's ability to clean up or is there something else?
 
Upvote 0

sfsameer

Well-Known Member
Licensed User
Longtime User
Thank you. I am not so concerned now that I understand that the GC will pretty much cover me even if I overlook something but can I ask about the 3 examples you put
up in your post. Is the essential problem with those that they might cause the usage of memory to get ahead of the GC's ability to clean up or is there something else?
The GC will clean them up eventually but just make sure you give GC time to do that.
when you are in a loop you postpone the GC to work.
so make sure you don't over loop, over load images and over use the timers
:)
 
Upvote 0
Top