high memory consumption in JOGL

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

high memory consumption in JOGL

gouessej
Administrator
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?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

Sven Gothel
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
This post was updated on .
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
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

Sven Gothel
Administrator
On Saturday, January 01, 2011 16:29:32 gouessej [via jogamp] wrote:

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

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
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

BrickFarmer
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



Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
In reply to this post by Sven Gothel
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
In reply to this post by Sven Gothel
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
In reply to this post by Sven Gothel
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
This post was updated on .
In reply to this post by Sven Gothel
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
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.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

Wade Walker
Administrator
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.
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
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?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

Steve Darnell
In reply to this post by gouessej
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.
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

Wade Walker
Administrator
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.
Reply | Threaded
Open this post in threaded view
|

Re: high memory consumption in JOGL

gouessej
Administrator
In reply to this post by Steve Darnell
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.
Julien Gouesse | Personal blog | Website