Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  VBO's and GC  (Read 1789 times)
0 Members and 1 Guest are viewing this topic.
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Posted 2005-08-06 02:45:50 »

Hi all,
I didn't know where to post this, but since im using LWJGL...i might as well post it here.
I can see a serious memory leak regarding VBOs and the GC. When a Geometry class gets isolated and hence GC'ed, and that geometry class is tied with VBO's (i.e. has a VBO id), the required calls to free up the VBO and delete the buffer from VRAM/wherever else wont be called and the VBO id will be lost for ever...Hence, on a lot of scene switching, on alot of the scenegraphs out there, with VBO's enabled...the memory goes up, the fps goes down because the driver may not change new VBO's for old ones and move the new ones in system ram hence on every render call, the gfx has to fetch the data through the system bus in the system ram. And the same problem applies to Texture id's too...

So my question is, does anyone know of a reliable way to delete the VBO's when the Geometry class gets GC'ed? Are finalisers good enough to do this? From my understanding...they arent

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline anarchotron

Junior Member




...precious bodily fluids.


« Reply #1 - Posted 2005-08-06 03:09:41 »

Why are VBOs more of a problem than any other allocated resouce (GL texture objects for instance)?

Also, why do you say that the finalizer is not a good solution?  I'm just curious.

Being a C++ coder by day, I tend to write code to manage pretty much everything I create (Don't laugh Smiley), but I can see why just putting the cleanup in finalize() would be useful.

Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #2 - Posted 2005-08-06 11:19:14 »

Quote
Why are VBOs more of a problem than any other allocated resouce (GL texture objects for instance)?
They arent, i just used VBO's as an example...

Quote
Also, why do you say that the finalizer is not a good solution?  I'm just curious.
Its my understanding that they might not be called on all JVM's. I am targetting 1.5, not sure if the finalisers situation has improved in that...

If finalize doesnt get called in >1.5,, or if a new cleanup method hasn't been created, then this is a very serious bug in game programming with an OGL pipeling using java....

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom
« Reply #3 - Posted 2005-08-06 11:49:17 »

Hence, on a lot of scene switching, on alot of the scenegraphs out there, with VBO's enabled...the memory goes up, the fps goes down because the driver may not change new VBO's for old ones and move the new ones in system ram hence on every render call, the gfx has to fetch the data through the system bus in the system ram. And the same problem applies to Texture id's too...

This is not what happens. The old ones is moved to system ram and the new ones is uploaded to the gfx card. The opengl driver does this behind the scenes. That is why some games uploads all the texture at startup. The driver manages what needs to be in system and gfxcard memory. All the game have to do is make sure all the textures will fit in system ram, and that it don't use more than the gfx card can hold from frame to frame.

Ofcourse, you will run out of system ram eventually if you have a memroy leak.

I can see a serious memory leak regarding VBOs and the GC. When a Geometry class gets isolated and hence GC'ed, and that geometry class is tied with VBO's (i.e. has a VBO id), the required calls to free up the VBO and delete the buffer from VRAM/wherever else wont be called and the VBO id will be lost for ever

It is the programmers job to make sure there is no memory leak. It is a bug on your part if you loos all references to an object containing the texture/vbo id. One solution would be to delete the id when the object is removed from the graph. I'm sure it's more complicated than that, but it has to be dealt with. Using the finalizer is one lazy way of dealing with it. It will work but there are a couple of traps. First it may take a long time before it is called depending on the gc. Also your relying on the java heap gc to delete system resources wich is not good. Finally you can not call opengl from the finalizer thread. The finalizer have to tell the gl thread to delete.

In the end you just have to make sure you clean up your own mess.

Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #4 - Posted 2005-08-06 12:07:59 »

Quote
This is not what happens. The old ones is moved to system ram and the new ones is uploaded to the gfx card. The opengl driver does this behind the scenes. That is why some games uploads all the texture at startup. The driver manages what needs to be in system and gfxcard memory. All the game have to do is make sure all the textures will fit in system ram, and that it don't use more than the gfx card can hold from frame to frame.

Ofcourse, you will run out of system ram eventually if you have a memroy leak.
That depends on how good the driver is...

Quote
One solution would be to delete the id when the object is removed from the graph. I'm sure it's more complicated than that, but it has to be dealt with
Thats one poor way of doing it. Its also as slow as a donkey without a carrot and it will probably cause a pause when the new VBO's are created. (I am buffering the deleted VBO's, but if there arent any available that are readily available, then creation is the only way...)

Quote
Also your relying on the java heap gc to delete system resources wich is not good. Finally you can not call opengl from the finalizer thread. The finalizer have to tell the gl thread to delete.
Yes, i know, but at least this guarantees when the object is collected, its resources are freed, If the user makes a mistake and hasn't kept the reference  so its resources are freed from our managers...but I suppose that is their fault.


Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2005-08-06 12:25:53 »

I've not come across any better way than the finalizer to do precisely this yet (for all native resources). Unfortunately the finalizer executes in the wrong thread as well, so it's even more fiddly as you have to create a destruction callback runnable in some GL "event queue" and process any you find in there in your main thread every frame.

The other problem is that the GC has no idea of exactly how much native resource you're actually wasting so objects tend not to get GCed until it's waaaay too late. A GLTexture object might only take up 128 bytes in the Java heap but point to an 8MB texture on the card. Chances are it won't get collected for a long, long time as the heap just won't fill up.

I have been looking into ReferenceQueues to deal with the problem but I've not cracked it yet.

Cas Smiley

Offline chaosdeathfish

Junior Member


Projects: 1



« Reply #6 - Posted 2005-08-06 21:51:45 »

I have been looking into ReferenceQueues to deal with the problem but I've not cracked it yet.

References only get cleaned up and put into ReferenceQueues during garbage collection, the same as finalizers. But with references you don't have access to the object any more, so it's even more difficult than with finalizers.
Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2005-08-07 12:16:17 »

That's why I've stopped that line of enquiry Tongue

What I actually need to write is... a complete GC of my own to take care of native resources. Yikes!

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #8 - Posted 2005-08-08 04:29:42 »

Isn't this the same issue that lead to the Java 2D disposer thread that was mentioned recently in that GC thread?  How did they do it ?

Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2005-08-08 09:30:28 »

They did it in completely the wrong way, that's how they did it, and caused much grief. What is needed is a pure Java GC algorithm that can be plugged in to any kind of resource. That'd be nice. So you could effectively set up a few collectors to collect different kinds of things in different ways, give 'em some threads, and let them loose.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #10 - Posted 2005-08-16 02:42:05 »

What is needed is a pure Java GC algorithm that can be plugged in to any kind of resource. That'd be nice. So you could effectively set up a few collectors to collect different kinds of things in different ways, give 'em some threads, and let them loose.

Interesting, I wonder if something could be done with annotations to mark classes as "belonging" to a particular collector.  You would proably need to manage separate heaps for each plugable collector or something, but it is an interesting idea.

Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2005-08-16 10:37:08 »

I'd just like a pure Java GC with a fairly simple collector which I can manage my own objects in. Not, take note, Java heap objects, which the Java heap GCs already handle perfectly well. I would just like to be able to manage the invisible native bit separately using some nice tried-and-tested GC algorithim. Because such objects are created and destroyed far, far, far more slowly than Java objects this GC doesn't need to be remotely clever or even particularly fast.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (43 views)
2014-09-23 14:38:19

radar3301 (25 views)
2014-09-21 23:33:17

BurntPizza (62 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (37 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!