Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (117)
games submitted by our members
Games in WIP (563)
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  
  JOGL and GC  (Read 1625 times)
0 Members and 1 Guest are viewing this topic.
Offline zingbat

Senior Member




Java games rock!


« Posted 2005-02-09 13:34:56 »

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 ?
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2005-02-09 17:15:24 »

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.
Offline zingbat

Senior Member




Java games rock!


« Reply #2 - Posted 2005-02-10 12:40:05 »

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 ?


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

JGO Coder




Java games rock!


« Reply #3 - Posted 2005-02-10 16:42:44 »

Quote
If i run the demo in full screen do we think the constant gc will be eleminated ?


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.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #4 - Posted 2005-02-14 01:19:59 »

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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline princec

JGO Kernel


Medals: 380
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2005-02-14 08:17:08 »

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 Smiley

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #6 - Posted 2005-02-14 17:17:34 »

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.)
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.

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

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

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

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

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

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (103 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
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!