high memory consumption in JOGL

Hi!

Lots of StructAccessor instances are created when I use JOGL 2, especially the GLCanvas. Is there a way of solving this issue? Will it be fixed or will I be forced to switch to NEWT?

On Friday, December 24, 2010 16:03:20 gouessej [via jogamp] wrote:
>
> Hi!
>
> Lots of StructAccessor instances are created when I use JOGL 2, especially
> the GLCanvas. Is there a way of solving this issue? Will it be fixed or will
> I be forced to switch to NEWT?

Can you pls provide more details ?

Of course we are interested to increase stability and reduce 'flying objects'
even for AWT, which is no more the primary target.

~Sven

Hi!

I ported a viewer from JOGL 1.1.1 to JOGL 2. This viewer is used to display simple meshes that use a few static VBOs. The switch to JOGL 2.0 has significantly increased the memory consumption and jvisualvm shows that a lot of StructAccessor instances are used even for the same direct nio buffers which is completely useless.

AWT is no more the primary target but using GLCanvas is easier to port existing 3D engines to JOGL 2. I will never convince Josh to switch to JOGL 2 with such an high memory consumption. Of course, I will investigate by myself but let me know any information about this class.

Edit.: the problem comes from JAWT drawing surfaces

On Saturday, January 01, 2011 16:29:32 gouessej [via jogamp] wrote:
sure, I will check AWT/GLCanvas with jvisualvm
and try to remove any of those temp objects.

hopefully one of the simple gears unit tests will make
such odd behavior visible.

as you might know, we already fought temp objects lately,
so such a regression as you described is for sure not welcome :)

~Sven

So I'm almost done with my relocation, and keen to get busy with my game and some JOGL2 again :)
Having spent quite some years working with java performance and memory analysis I can highly recommend the YourKit tool.  
http://www.yourkit.com/
They also have an open source license for free!  and a 30day eval for the rest of us.
Peter
PS happy new year

Look at JAWT.getJAWT().getDrawingSurface(). Any method that needs a StructAccessor instance should use the same one for a particular NIO buffer. Using a cache would be quite dirty.

Hi!

At first, I did a pull request some weeks ago concerning the TextRenderer, it would be fine if it was in the release candidate as it reduces the memory use.

Secondly, I set the properties sun.awt.noerasebackground to true, sun.java2d.noddraw to True and sun.java2d.opengl to True, Java2D.checkActive() still throws a GLException, please could you at least use the same instance rather than throwing a new one each time?

Finally, lots of StructAccessor instances are created even when I display only some text and a compass. After a few minutes, 700 MB are used.

Ok I have solved my problem of GLException by using the flags earlier.

In JAWT_JNI.c, I see that Java_com_jogamp_nativewindow_impl_jawt_JAWT_GetDrawingSurface0__Ljava_nio_ByteBuffer_2Ljava_lang_Object_2 creates a new NIO buffer each time whereas it is totally useless. A JAWT_DrawingSurface instance should contain a single NIO buffer as a class member and reuses it instead of creating a new direct buffer at each call.

I don't reproduce this problem with the demos, I have to investigate a bit more.

When I profile the "Text Flow" demo without my fixes on the TextRenderer, lots of StandardGlyphVector instances are created:


I have compared the memory consumption of a dummy org.eclipse.ui.part.ViewPart containing a GLCanvas using JOGL 2.0 that draws a rotating pyramid and TUER pre-beta version using JOGL 1.1.1a (that draws a lot of things, indoor, outdoor, an animated model, some weapons). The difference is huge. Whereas the memory consumption of TUER is low and quite stable (the number of StructAccessor instances is stable, it occupies about 20 KB of memory), the memory consumption of this ViewPart is huge, StructAccessor instances occupies several MB. I don't know why the high memory consumption is higher when addind an internal frame.

To conclude, JOGL 2.0 consumes more memory than JOGL 1.1.1 especially when mixing AWT components with a GLCanvas. I will provide a simple example tomorrow. It is clearly a regression.

Hi!

The guilty is:
glCanvas.setAutoSwapBufferMode(false);

Disabling the auto swap buffer mode increases hugely the memory consumption. I will write a bug report about this bug tomorrow.

Hi!

I have written my bug report:
https://jogamp.org/bugzilla/show_bug.cgi?id=455

I have provided a nice test case that uses my "workarounds" to avoid breaking the debug pipeline of JOGL 2, to avoid StackOverflowError under Linux (https://bugs.eclipse.org/bugs/show_bug.cgi?id=171432) and that displays the meshes correctly without any artifact when disabling the auto swap buffer mode under Windows. I hope it will be useful and I highly encourage you to reuse this piece of code in your own Eclipse RCP applications rather than the buggy OpenGL canvas of SWT. This source code has been tested on several platforms including Linux (Red Hat and CentOS) 32 bits, Linux 64 bits, Windows 32 bits (NT, XP, Vista and 7) and Windows 64 bits.

Wade's tutorials are fine, I don't need to write my own tutorial but I might write an article about that in my blog if some people want more explanations about my code.

Is the workaround for bug 171432 still needed? From reading the bug page, it sounds like it's fixed in AWT in Java 6u23 and beyond.

Some people negociated to backport the fix done in Java 1.7 in Java 1.6. In my humble opinion, this workaround is still needed as some people still uses IcedTea and some other JVM that does not contain this "recent" fix.

The other fixes are almost mandatory when you mix AWT, Swing and SWT especially when you want to use the debug pipeline.

Have you noticed that when you use several SWT Composite instances with the embedded style, on some platforms, it does not work, the last Composite instance is not displayed?

I would appreciate an expanded explanation.  I am working around some of the bugginess of the SWT GLCanvas and would appreciate a description on how you avoided using it.

There are currently some issues with SWT and JOGL 2 that you may be hitting (for example, see https://jogamp.org/bugzilla/show_bug.cgi?id=452). The last autobuild of JOGL 2 that works correctly with SWT on Windows is b244, and even that build is not OK on some platforms. Sven seems to be working on the code in the areas of the bug, so hopefully we'll have a fix soon.

One thing you might try is testing your code with JOGL 1.1.1a to see if it works that way. If it does, you'll know it's a JOGL 2 problem, not an SWT problem.

If you have some failing SWT JOGL 2 code, just snip it out and post it here, and I'll turn it into a test case and bug report for you.

Did you look at my source code? I put a lot of comments and it works really good :) What is not clear for you? This example is quite complete and shows how to use the JOGL 2.0 GLCanvas with SWT.