LÖVE

Posted: **Mon May 05, 2014 1:44 am**

Thanks everyone for the help, I wasn't expecting such an amazing response time!
I was just worried because I usually program in C++ and I handle my own garbage collection, I guess that caused some trust issues when moving to easier, more user friendly languages like Lua.

Azhukar wrote:If you have a leak of few mb per second in your code it is not caused by the 2 lines you provided.
Code: Select all
for i=1,10000 do
	love.graphics.setColor(255, 255, 255, 255)
	love.graphics.rectangle("fill", 10, 10, 100, 100)
end
Some things that can cause higher memory upkeep:

Userdata - creating new userdata every frame. This includes image objects among other things.

Tables - all inaccessible tables are eventually collected, if you create a lot of them per frame it can add up and the garbage collector will spend a lot of time keeping up and you will notice higher memory upkeep.

Note neither of these are leaks since the garbage collector takes care of most dumbassery you throw at it, including memory islands. In case you're working with love.physics or other framework modules it is possible to make the collector cry and hide things inside userdata objects which it will not clean up, such as the setUserData() method in some physics objects.

Unless your program crashes due to insufficient memory over time, it's likely your code just produces a lot garbage on the side.

Anyway I see what you mean by the garbage collector letting memory usage pile up before clearing it all,
I let the program run a bit (and using collectgarbage( 'collect' ) after every draw cycle) and it never went over a specific amount of MB of RAM.

I am using userData in the love physics module so I might be misusing it probably, are there any basic house keeping tips I should know about with using them? How are they any different from storing a table as a member inside any other table?

Posted: **Mon May 05, 2014 2:34 am**

OnlyFails wrote:I am using userData in the love physics module so I might be misusing it probably, are there any basic house keeping tips I should know about with using them?

Set userdata to nil before destroying an object. You need to explicitly pass it nil otherwise it will error.

OnlyFails wrote:How are they any different from storing a table as a member inside any other table?

I don't know the inner workings but I do know that tables assigned as userdata of destroyed objects will not get collected. You can test this out by using weak tables to keep a weak reference to your userdata table, then calling collect garbage after the object with userdata is destroyed.

Posted: **Mon May 05, 2014 3:57 am**

The reference to the userdata of a Fixture or Body is removed when that Fixture or Body is garbage collected. Once that happens, the (no longer) referenced user data is free to be garbage collected itself if there are no other Lua-side references to it (although, like all garbage collection in Lua, it may take some time.)

Posted: **Mon May 05, 2014 7:20 am**

Also, for those of you expecting it gets collected right after nilling it: it doesn't.
For those expecting it to get collected after nilling and calling collectgarbage: it doesn't.
Lua's garbage collector is such that it requires two complete runs before userdata is collected, after the first run its destructor get called (so typically most memory gets freed then), and it becomes unreachable, after the second run it gets destroyed itself.
Note though, that due to the way memory allocation works, it's very hard to see this happen accurately, and if memory usage is low, you might not see it drop at all.

Posted: **Tue May 06, 2014 1:00 am**

Azhukar wrote:
OnlyFails wrote:I am using userData in the love physics module so I might be misusing it probably, are there any basic house keeping tips I should know about with using them?
Set userdata to nil before destroying an object. You need to explicitly pass it nil otherwise it will error.

OnlyFails wrote:How are they any different from storing a table as a member inside any other table?
I don't know the inner workings but I do know that tables assigned as userdata of destroyed objects will not get collected. You can test this out by using weak tables to keep a weak reference to your userdata table, then calling collect garbage after the object with userdata is destroyed.

Really great information here! Thanks for the help Azhukar

Posted: **Tue May 06, 2014 3:07 am**

Azhukar wrote: Set userdata to nil before destroying an object. You need to explicitly pass it nil otherwise it will error.

Not my experience with deleting images created from userdata!
Can repeatedly recreate an image from the same (slightly modified) userdata.

LÖVE

[Solved] Memory Leak in only two lines

Re: Memory Leak in only two lines

Re: Memory Leak in only two lines

Re: Memory Leak in only two lines

Re: Memory Leak in only two lines

Re: Memory Leak in only two lines

Re: Memory Leak in only two lines