I was testing jogl the other day with several examples including one the easiest NeHe tutorials and the more complex examples provided by the jogl project and i noticed that most of the time the gc is collecting something like 1Mb of garbage per second. Now this isn’t that terrible since it only takes something like 0.1% of CPU time in my computer wich is a slower PC.
My question is should there be any GC being done at all ? Where does an api like jogl will require to allocate new objects ?
The objects are very likely coming from the application itself. JOGL does currently allocate a few objects per frame when making the OpenGL context current and freeing it, but it is definitely possible to reduce object allocation in an application’s main loop to nearly zero. If you can point to one or more of the JOGL demos that makes lots of garbage then feel free to file a low-priority bug on it with the JOGL Issue Tracker.
Its not really a bug. What puzles me is that there is a constant activivity from the garbage collector and im trying to indentify from where it comes.
This is the code i ran:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=05
The results:
java -verbose:gc -Xconcgc -cp .;jogl.jar Lesson05
[GC 3968K->587K(16320K), 0.0568377 secs]
[GC 4555K->808K(16320K), 0.0175341 secs]
[GC 4776K->808K(16320K), 0.0018226 secs]
[GC 4776K->808K(16320K), 0.0014963 secs]
[GC 4776K->809K(16320K), 0.0015315 secs]
[GC 4777K->809K(16320K), 0.0015161 secs]
Each log happens with an interval of ~ 16s. This time i measured the time more precisely and its more like 4000k /16 = 250kb a sec.
With incremental gc:
java -verbose:gc -Xincgc -cp .;jogl.jar Lesson05
[GC 3968K->587K(16320K), 0.0559940 secs]
[GC 4555K->806K(16320K), 0.0181464 secs]
[GC 4774K->806K(16320K), 0.0018332 secs]
[GC 4774K->806K(16320K), 0.0015231 secs]
[GC 4774K->807K(16320K), 0.0015290 secs]
[GC 4775K->807K(16320K), 0.0014812 secs]
Same results with incgc
If i run the demo in full screen do we think the constant gc will be eleminated ?
[quote]If i run the demo in full screen do we think the constant gc will be eleminated ?
[/quote]
I don’t think that will have any effect. If you want to track down where the garbage is coming from you should use one of the many Java memory profilers out there. hprof ships with the JDK; there are many others.
We did a lot of investigation into this a while ago. We spent about a week profiling the internal code paths of JOGL in search of memory leaks etc. A lot of this garbage is coming from some code that is creating and destroying NIOBuffers somewhere deep in the rendering code. We gave a heap of details to Ken about this probably 3-4 months ago now. At the time he claimed it was something in AWT’s internals that was beyond his control.
There is also a second set of garbage generating calls that is directly created by JOGL. Memory is a bit fuzzy right now, but it was a command pair and some other class that it was creating for every render cycle. Ken claimed that this was absolutely necessary for the implementation. I didn’t (and still don’t) agree with that prognosis, but you can assume that there will always be some garbage generated by the core of JOGL.
That’s the only two items we could trace down to JOGL code. They’re relatively minor in the grand scheme of things. All the rest were our code in one form or another and these tiny objects were not causing GC stutters. The NIOBuffer allocate and destroy is of concern for purely performance reasons - that’s native memory needing to be malloc/free every frame that just really does not need to be. If this was eliminated, we could get better performance.
Creating native NIO buffers on a frame-by-frame basis is a disaster for a Java application, as they are not collected in a timely fashion and can end up causing your app to thrash into swapspace.
Cas 
The NIO buffers being allocated in JOGL’s internals do not have backing store associated with them that needs to be freed; they are created to be able to view C data structures from Java and these structures are freed by calls back down to C code, not by the GC. They also do not cause any Reference objects to be enqueued, so they are cleaned up (very quickly) by the young generation scavenger. (Mithrandir, if you have data indicating otherwise, please email me directly.)