Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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  
  some Garbage Collection and LWJGL memory managment questions  (Read 2619 times)
0 Members and 1 Guest are viewing this topic.
Offline Simba Productions

Senior Newbie

Medals: 1

« Posted 2013-09-01 06:55:14 »

Hi i have a couple questions in regards to the stuff i mentioned in the title.

Question 1:

First if i do something like

int vboID = GL15.glGenBuffers();
vboID = GL15.glGenBuffers();

would it create a memory leak?

Question 2:

I've heard a couple times that if you set big objects (such as large floatbuffers) to null after you are done using them it can speed up the java GC is this true?

and lastly,
Question 3:

in some of my lazy test code i don't delete my VBOs, VAOs, Textures, etc. at the end of the program. Ive always assumed that the OS would handle the memory deallocation like it would on regular non-openGL CPU based programs. Does the OS or the actual graphics card handle this? Or could this lead to potential problems. If it does handle it, then why bother deleting everything at the end of a program?

I know that's a lot of questions, if you happen to know any answers they would be appreciated Smiley

thanks in advance
Offline Magn919

Junior Devvie

Medals: 6
Exp: 5 years

« Reply #1 - Posted 2013-09-01 14:41:23 »

Answer 1.
Yes it does create a memory leak, but depending on how often you do this, it should not really be to much a problem.
Still you shouldn't do it, its better to just reuse the old buffer id, by uploading new data, such as with a vbo, you just call glbuffer with the new data.
Otherwise you should at least remove them, using the appropriate gl remove calls, before letting go of the id, because the GC wont save you here.

Answer 2.
Null'ing the buffer wont make the GC any faster, buffers are like any other java objects flagged "to be removed" when there are no more references to it, however if you still need the object that holds the buffer for a while, just not the buffer itself, you should null the buffer, so that the GC may clean up the buffer, without having to wait.

Answer 3.
Generally the OS will handle that for you, but you should still clean up after yourself, its better to do so, rather than rely on somebody else to do it, i'd say not doing it is like having the main method throw an exception, because you are to lazy to catch it yourself in a try...catch block.

For every new problem, a new source of solutions has come to exist.
Offline ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

« Reply #2 - Posted 2013-09-07 07:09:11 »

For Question 3, I would disagree with Magn919 and say not to waste your time cleaning up everything at the end of the program. All OS's will do the cleanup for you anyway, so there is no point to waste CPU time on that.

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

JGO Kernel

Medals: 138
Projects: 3

You think about my Avatar right now!

« Reply #3 - Posted 2013-09-07 08:08:21 »

The idea behind deleting those vbos and textures and whatever, is simply hat you free memory, when you don't need it anymore. This can also be in the middle of your program. Just clean up your resources when you don't need them anymore.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline Redocdam

Senior Devvie

Medals: 18

« Reply #4 - Posted 2013-09-07 08:09:17 »

To further confuse the #3 answer: In my experience, both are right.

From a released application stand point, you shouldn't have any worries if you're not cleaning up after yourself.
During development however, you can shoot yourself in a sensitive body part.

I think my best example for this was working with Transform feedback buffers. I was getting different results based on how long I would wait before restarting the application.
The punch line being I was somehow picking up the handle to those buffers before the OS had cleared them out. When I waited long enough, the buffers would clear and things behaved as expected.

My opinion on the matter:
If you've built your graphics objects so they're easy to handle/unload, then do so. A clean home is a happy home.
If things just aren't that friendly, then f-it. A clean home is the first sign of a serial killer.
Offline Simba Productions

Senior Newbie

Medals: 1

« Reply #5 - Posted 2013-09-07 15:47:49 »

Haha the reason I asked the third question was because I was far into my game and realized I forgot to give all the objects a delete function since then I have taken the time to add them to avoid weird errors that redocam mentioned thanks for all the information guys
Pages: [1]
  ignore  |  Print  

EgonOlsen (45 views)
2018-06-10 19:43:48

EgonOlsen (25 views)
2018-06-10 19:43:44

EgonOlsen (47 views)
2018-06-10 19:43:20

DesertCoockie (202 views)
2018-05-13 18:23:11

nelsongames (127 views)
2018-04-24 18:15:36

nelsongames (126 views)
2018-04-24 18:14:32

ivj94 (867 views)
2018-03-24 14:47:39

ivj94 (128 views)
2018-03-24 14:46:31

ivj94 (771 views)
2018-03-24 14:43:53

Solater (143 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!