next »

[AotFSteven]

Marvin, I know that I had reported this in another thread, and I had hoped that it had been resolved but it doesn't appear to be so.  If you try running the BSPLoaderTest two or more times (each time returning to the Xith3DTestLauncher) you should get an OutOfMemoryError.  I get this when I try to run the BSPLoaderTest a second time.  When I ran the Xith3DTestLauncher and I set the memory to 128 MB using the runtime option

Code:

-Xmx128m

I was able to run the test about 5 or so times before I got the error again.  I had done a little research and was able to come up with this.  This utility, which is included with the jdk, basically analyzes a heap dump file created by the JVM on an OutOfMemoryError.  When jhat is ran against a heap dump file it creates a webserver which can be reached at http://localhost:7000 and it displays all of the objects that were open at the time the heap dump was created.  It also has different ways to display the information.  An easy way to get to create the heap dump file is to add

Code:

-XX:+HeapDumpOnOutOfMemoryError

as a runtime option.  Upon getting the OutOfMemoryError the heap dump file will be created.  Afterwards jhat can be ran using

Code:

jhat -J-Xmx512m <path to heap dump file>

The -J-Xmx512m tells jhat to use up to 512 MB I had to do this because I was getting an OutOfMemoryException when trying to run jhat without that option.

I couldn't really make out much except for the obvious fact that there sure seems to be a lot more stuff than there should be.  On the file with the 128 MB there were 5 instances of BSPLoaderTest which indicates to me that things are not getting completely de-referenced (I'm not sure if that's a word).  I am thinking that at least one major item is remaining referenced which might explain why the garbage collection is apparently not working.  It was also interesting to see that there was about 35 MB being taken up by floats (I think it said class [F) alone which would seem to be from all of the Tuple3F, Vector3F, etc. that are not being removed properly.  EDIT: The 35 MB was when I had the memory allocation set to 128 MB.

I hope that this was helpful and I hope that someone can figure this one out.  I will probably keep looking into the problem some more, but I am hoping that someone will be able to make sense of the report better than I.

EDIT: When pulling up the webpage, if you scroll all the way to the bottom there is a heap histogram which I found pretty useful and informative.

[Marvin Fröhlich]

Just yesterday I discovered, that the most recent changes to the Xith3DTestLauncher were not as unproblematic as I thought. Actually it fell back to a behavior, that I resolved over a year ago: The AWT-input-thread is used to launch the testcase. This MUST NOT be done and will certainly be the reason for the still remaining OutOfMemoryError.

And [F normally indicates float-arrays and I guess, all the geometry is stored in float arrays inside of the nio-buffers. So the scene's geometry itself is not freed, which seems obvious.

Marvin

[AotFSteven]

Just yesterday I discovered, that the most recent changes to the Xith3DTestLauncher were not as unproblematic as I thought. Actually it fell back to a behavior, that I resolved over a year ago: The AWT-input-thread is used to launch the testcase. This MUST NOT be done and will certainly be the reason for the still remaining OutOfMemoryError.

I just want to make sure that I understand, you think that the problem is because the AWT thread is used to create everything like the Canvas before it even gets to the begin which then creates a new thread right?  Does that mean that when creating the test a new thread could be created there to then launch the testcase?    I will try to look into this and post my findings if I can and if you haven't already fixed this by then.

And [F normally indicates float-arrays and I guess, all the geometry is stored in float arrays inside of the nio-buffers. So the scene's geometry itself is not freed, which seems obvious.

That actually makes sense, when I was looking at the data in the report from jhat it was displaying the floats in an array, I just didn't put 2 and 2 together, I guess I was just thinking that those were all of the floats or something like that

[AotFSteven]

Okay, I just put tried running from after the action is captured on the start button through on another thread and I still got the same error.  He is the stack trace in case it is helpful, it should show that all the way from requestStart through to launching the test case it is in a separate thread.

Code:

java.lang.OutOfMemoryError: Java heap space
at net.java.dev.joode.util.Real.<init>(Real.java:39)
at net.java.dev.joode.util.Vector3.<init>(Vector3.java:52)
at net.java.dev.joode.util.Vector3.<init>(Vector3.java:62)
at net.java.dev.joode.geom.Box.<init>(Box.java:44)
at org.xith3d.physics.collision.joode.JoodeBoxCollideable.<init>(JoodeBoxCollideable.java:88)
at org.xith3d.physics.collision.joode.JoodeCollisionEngine.newBox(JoodeCollisionEngine.java:374)
at org.xith3d.physics.collision.CollisionEngine.newBox(CollisionEngine.java:247)
at org.xith3d.physics.collision.CollisionEngine.newBox(CollisionEngine.java:266)
at org.xith3d.physics.collision.CollisionEngine.newBox(CollisionEngine.java:279)
at org.xith3d.loaders.models.impl.bsp.BSPScene.createColliders(BSPScene.java:110)
at org.xith3d.test.loaders.BSPLoaderTest.loadLevel(BSPLoaderTest.java:310)
at org.xith3d.test.loaders.BSPLoaderTest.createSceneGraph(BSPLoaderTest.java:319)
at org.xith3d.test.loaders.BSPLoaderTest.<init>(BSPLoaderTest.java:379)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.xith3d.test.Xith3DTestLauncher.runTest(Xith3DTestLauncher.java:826)
at org.xith3d.test.Xith3DTestLauncher.onStartButtonClicked(Xith3DTestLauncher.java:186)
at org.xith3d.utility.launching.DisplayOptions.requestStart(DisplayOptions.java:292)
at org.xith3d.utility.launching.DisplayOptions.run(DisplayOptions.java:284)
at java.lang.Thread.run(Thread.java:619)

I had set my memory allocation back to the normal (I think its 64 MB) and I was only able to run the BSPLoaderTest once, on the second try it crashed like usual.

[Marvin Fröhlich]

I just want to make sure that I understand, you think that the problem is because the AWT thread is used to create everything like the Canvas before it even gets to the begin which then creates a new thread right?

Yes, that was, what I meant. But the begin() method does not start a new thread for all cases. If RunMode.RUN_IN_SAME_THREAD is used, then the calling thread is used, which means, that everything is running from within the AWT input thread. This also means, that no input events are generated when JOGL_AWT is used.

Does that mean that when creating the test a new thread could be created there to then launch the testcase?    I will try to look into this and post my findings if I can and if you haven't already fixed this by then.

Well, previously I used to run a separate thread, that waits for a testcase to be started (look at the waitForStart() method). And when there is a testcase, that requested to be started, it runs the testcase from within this special thread. Principally I see no problem doing it this way again.

Marvin