Memory Leak in my Cinematics Based application

Given all of the symptoms of lists growing and slowdown that you see, I’m going to go out on a limb and guess that you are somehow adding the same events to the list multiple times. Since the events are time-based, having 100 of the same one in the list won’t look wrong it will just do 100x the amount of work. Also, if you try removing it then it will only remove the first one.



This should be pretty easy to check, though.

oh yes yes I know, that was why in the beginning of this thread I was asking Nehon how to properly remove them, so it actually works better if you don’t remove them as removing affects my fps and animation (creates hiccup). I wrote a method that removes the events (synrchonized) in OnStop() wheneever an animation is done and it removes them but slows down everything.



Regardless, if I remove them , I get some memory improvement (again on behalf of the fps performance) but still I suspect a leak.

This should be pretty easy to check, though.


no I added a getter for the event size in cinematic and the size grows and shrinks (when debugging it the events gets deleted).

However, like I mentined to @nehon who added the removeCinematicEvent method for us (and I thank him for that):

the boolean of the remove method is false as the cinematicEvent does not successfully get removed from keyframe (only occasionally) but only from the Cinematic’s cinematicEvent.

As taken from Joshua bloch:

If a stack grows and then shrinks, the objects that were popped off the stack will not be garbage collected, even if the program using the stack has no more references to them. This is because the stack maintains obsolete references to these objects


Maybe this is your issue? idk i haven't read the thread properly
@garnaout said:
oh yes yes I know, that was why in the beginning of this thread I was asking Nehon how to properly remove them,, so it actually works better if you don't remove them as removing affects my fps and animation (creates hiccup). I wrote a method that removes the events (synrchonized) in OnStop() wheneever an animation is done and it removes them but slows down everything.

Regardless, if I remove them , I get some memory improvement (again on behalf of the fps performance) but still I suspect a leak.


Pretend like synchronized costs the same as 40 method calls. And that's only if you use it from one thread. In general, using the "synchronized" keyword is a sign of a developer how understands too little about threading to be using threads. There is a reason the java.util.concurrent package exists. Anyway, I no longer think this is your problem and I think you completely didn't read my last post.

If you have 300,000 events in the cinematics list are you actually adding 300,000 events? 300,000 events will be slow regardless of what you do.

But more importantly, if you add the same event instance over and over again then you will get exactly the behavior you describe. Your frame rate will get slower and slower and your memory will grow and grow. Everything will look like it is doing the right thing because "Move object A from P1 to P2" run 1000 times will just be doing extra work but still visually look the same. But you only need to "Move object A from P1 to P2" once per frame. And calling remove() with that instance will only remove the first one... so there would still be 999 of them running.

It is a simple thing to check, though... and easy to fix. Basic debugging would sort this out. Just see if the event already exists before adding it or something.

If you really do have 300,000 real events then you should abandon cinematics and go with a custom approach since it was not designed to do this. If you can afford it then you might also consider hiring a developer on contract to just implement this for you. It seems like it is a fairly straight forward problem that has taken a very long time (and a lot of community support) without much progress.
1 Like
@garnaout said:
even if I set it to null and wait for quite some time?

Yes, the GC will collect objects when it needs to. If it doesn't need to collect garbage it doesn't do it, no matter if you wait until the sun explodes :) And even if memory gets tight it doesn't mean it collects the "oldest" objects, it will collect whatever is easiest to collect and that is determined totally different depending on the actual GC algorithm.
You can try to force a full GC but unless you know the exact algorithm you will never know what is expected to be GCd. There are good reasons the general recommendation is to stay away from finalizers :)
1 Like
If it doesn’t need to collect garbage it doesn’t do it, no matter if you wait until the sun explodes

but the memory is reaching 6-7 gb.....anyways I won't worry about that as an issue then, thanks for the info, I didn't know...

@pspeed, I already checked and I am definitely not adding redundant events, I wish I was, that would have been the easiest fix.

If you have 300,000 events in the cinematics list are you actually adding 300,000 events? 300,000 events will be slow regardless of what you do.

but why? if I am consuming them when the events are completed, why would it be a problem? I am not adding them at the same time but throughout a long duration of time. The 300,000 events aren't happening at the same time. I have at most 100 events overlapping , not more.
garnaout said:
but the memory is reaching 6-7 gb.....anyways I won't worry about that as an issue then, thanks for the info, I didn't know...

Try allocating less memory to the application, like -Xmx1G and see if you run into out of memory exceptions and/or you might see your objects being garbage collected. Sometimes it is even better for performance to lower max heap size to make the GC run more regularly than build up until it has to collect several Gigs in one go. But only sometimes and depending on the algorithm and a lot of other parameters, so basically, you don't know until you try :)
1 Like
@garnaout said:
but the memory is reaching 6-7 gb.....


How do you know this?

@garnaout said:
@pspeed, I already checked and I am definitely not adding redundant events, I wish I was, that would have been the easiest fix.

but why? if I am consuming them when the events are completed, why would it be a problem? I am not adding them at the same time but throughout a long duration of time. The 300,000 events aren't happening at the same time. I have at most 100 events overlapping , not more.


You said the list had 300,000 elements in it. That means that 300,000 elements are added to it and not ever removed. Unless you meant something else. But I can't really guess what that would be.

And I think cinematics was not really meant to be used to stream 300,000+ read in animation events. It was written to be used for… cinematics.

1 Like
How do you know this?


Resource Monitor

You said the list had 300,000 elements in it. That means that 300,000 elements are added to it and not ever removed. Unless you meant something else. But I can’t really guess what that would be.


that was the main question at the beginning of the thread. The dilemma is that if I remove (which mean the list would shrink and grow fluctuating around 20k) I'll lose performance >>>> fps drops dramatically and if I don't delete it reaches 300k and more and was wondering if it is okay for it to grow that large.

The other point was that the memory keeps increasing with the animation even if I remove elements from the list (grows at a slower rate but still grows)
@garnaout said:
Resource Monitor


This will not separate direct memory from heap memory. It's all one giant bundle. You can display the heap memory pretty easily in the app, though.

@garnaout said:
that was the main question at the beginning of the thread. The dilemma is that if I remove (which mean the list would shrink and grow fluctuating around 20k) I'll lose performance >>>> fps drops dramatically and if I don't delete it reaches 300k and more and was wondering if it is okay for it to grow that large.


And I already said don't remove them all at once. If you remove 1000 items then of course it will slow down. Anyway, this is exactly the point where I say that cinematics was not designed for this sort of streaming. It was designed for cinematics... where the whole thing is in memory and you can run forwards and backwards, etc..

@garnaout said:
The other point was that the memory keeps increasing with the animation even if I remove elements from the list (grows at a slower rate but still grows)


You said the list still had 300,000 elements in it after you were removing items, I thought. Anyway, if you learn how to use the memory profiler then you should be able to find who is holding onto this extra memory. And at any rate, the resource monitor is lying to you anyway. Java will grab all kinds of memory but that doesn't mean it's using it.
and I already said don’t remove them all at once. If you remove 1000 items then of course it will slow down. Anyway, this is exactly the point where I say that cinematics was not designed for this sort of streaming. It was designed for cinematics… where the whole thing is in memory and you can run forwards and backwards, etc..


I don't remove them at once, I consume them. Whenever any event is finished I remove it at once inside the onStop() in the actual event track. As far as cinematics not being designed for it, I know that but I came too far to sswitch to something else. I'm better off forking it accordingly rather than switching to something else.


You said the list still had 300,000 elements in it after you were removing items, I thought. Anyway, if you learn how to use the memory profiler then you should be able to find who is holding onto this extra memory. And at any rate, the resource monitor is lying to you anyway. Java will grab all kinds of memory but that doesn’t mean it’s using it.


I put some snapshots from the netbeans profiler and I really couldn't pinpoint the issue, I get something like Long class or Float class is consuming most of the memory, even when I took a snapshot , It pointed me to classes that looked just fine (I commented most of the code in them) - its a bit misleading.
@garnaout said:
I put some snapshots from the netbeans profiler and I really couldn't pinpoint the issue, I get something like Long class or Float class is consuming most of the memory, even when I took a snapshot , It pointed me to classes that looked just fine (I commented most of the code in them) - its a bit misleading.


Unfortunately, going through someone else's profiler dumps starts to sound like real work. And I try not to do extra real work unless I'm getting paid.

The individual floats are meaningless unless you know what is holding them. And anyway, if you don't have a guess as to how much heap memory is being consumed then it might be meaningless. All of the memory could be being consumed by direct memory in which case profiling heap memory isn't going to give you good answers.

ok one more thing and i’m done… for testing purposes, I’ve setup a button that once clicks set all the classes used to null only making sure that the jME (the simpleApplication main class) is still running. I set cinematics to null, nifty to null, the class I use to load the trace file to null, pretty much everything, just in an attempt to release the memory. It’s not working (not releaseing the memory). So please can anyone validate this statement?



Does that mean that the memory is being held somewhere in the main class? or the gc does not have to release the memory EVEN though it’s more than 2GB and the classes are set to null ready to be garbage collected?



again sorry to have bothered all of you with this topic, it’s a learning process, and I did learn a lot from you so thanks again.

The garbage collector collects only what it needs to when it needs to. It’s “magic” and very much a law unto itself.



You can try manually triggering it but I give no promises as to the effectiveness of the results…



Really GC is a general java issue though, you need to read up on it elsewhere and then when you understand it come back with jME3 specific GC issues.







P.S. Things like running threads might have a reference to things, even if you nulled everything yourself.

1 Like

I think ur right. i’ll do that… thanks a lot

I reduced my direct memory and it seems that the garbage collector is doing what’s supposed to do… so my final conclusion is that there is no memory leak