Lifecycle of abstract buffer data

Problems building or running Ardor3D, questions about how to use features, etc.

Lifecycle of abstract buffer data

Postby gouessej » Thu Feb 23, 2012 3:10 pm

Hi

I would like to use the following strategy in TUER:
http://www.java-gaming.org/topics/a-general-approach-for-nio-buffer-pooling/25537/msg/224076/view.html#msg224076

In your humble opinion, is it a good idea? I have already implemented the destruction of direct NIO buffers, I think that it might be a nice addition for Ardor3D because you don't need to keep in memory all models you load since the launch of an application and this is particularily true in games.

@Renanse, maybe all classes that deal with buffers (*BufferData and FloatBufferDataUtil) could be put into a sepatate package, it is only a suggestion.
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Re: Lifecycle of abstract buffer data

Postby gouessej » Fri Feb 24, 2012 3:47 am

Hi

Actually, what I would like to do should be already done in ContextGarbageCollector.doRuntimeCleanup(final Renderer immediateDelete). However, there are 2 problems:
- the implementations of JoglRenderer.deleteVBOs recreates a direct NIO buffer at each call (and such a buffer is page-aligned...)
- the wrapped direct NIO buffer inside AbstractBufferData is not destroyed

Does ContextIdReference<AbstractBufferData<?>>.clear() really destroy the direct NIO buffer in AbstractBufferData?
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Re: Lifecycle of abstract buffer data

Postby gouessej » Fri Feb 24, 2012 6:14 am

According to IBM:
Direct ByteBuffer objects clean up their native buffers automatically but can only do so as part of Java heap GC — so they do not automatically respond to pressure on the native heap. GC occurs only when the Java heap becomes so full it can't service a heap-allocation request or if the Java application explicitly requests it (not recommended because it can cause performance problems).

The pathological case would be that the native heap becomes full and one or more direct ByteBuffers are eligible for GC (and could be freed to make some space on the native heap), but the Java heap is mostly empty so GC doesn't occur.

http://www.ibm.com/developerworks/aix/library/j-nativememory-aix/index.html

I'm almost sure this is the case not only for AIX. I will have to make a small test. I don't know where JVisualVM shows the native heap.
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Re: Lifecycle of abstract buffer data

Postby gouessej » Fri Feb 24, 2012 7:32 am

Actually, the current mechanism in Ardor3D destroys the resources on the Java heap but the destruction of the direct NIO buffer (on the native heap) may occur later. In my humble opinion, when we perform a runtime cleanup at the best opportunity in a game, it would be better if those direct NIO buffers are immediately destroyed and not later while the player expects some responsiveness. I will override the current mechanism and feel free to use my source code.
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Re: Lifecycle of abstract buffer data

Postby renanse » Fri Feb 24, 2012 6:00 pm

Can you give a source code example of the destruction you are looking for?
Gratitude is a mark of a noble soul and a refined character.
User avatar
renanse
Site Admin
 
Posts: 2988
Joined: Tue Oct 28, 2008 6:49 pm
Location: Austin, TX

Re: Lifecycle of abstract buffer data

Postby gouessej » Sat Feb 25, 2012 3:44 am

Hi

renanse wrote:Can you give a source code example of the destruction you are looking for?

Thank you for your attention. This is a short example illustrating what I meant:
http://stackoverflow.com/a/8462690/458157

I would like to perform that on the direct NIO buffer _buffer inside any AbstractBufferData when this one becomes useless. It must not be called before glDeleteBuffers and we should call the method isDirect() to check whether this NIO buffer is really direct. Keep in mind that such a source code cannot be used in an unsigned applet (it requires a privileged access). If you implemented this mechanism, you should drive it optional by using a flag set to false by default.
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Re: Lifecycle of abstract buffer data

Postby renanse » Sun Feb 26, 2012 9:45 pm

We don't actually force destruction anywhere... we clear our reference and the garbage collector cleans things up however it decides best. I'd prefer not to get in the business of second guessing the garbage collector if possible.
Gratitude is a mark of a noble soul and a refined character.
User avatar
renanse
Site Admin
 
Posts: 2988
Joined: Tue Oct 28, 2008 6:49 pm
Location: Austin, TX

Re: Lifecycle of abstract buffer data

Postby gouessej » Mon Feb 27, 2012 5:20 am

renanse wrote:We don't actually force destruction anywhere... we clear our reference and the garbage collector cleans things up however it decides best. I'd prefer not to get in the business of second guessing the garbage collector if possible.

There's an old bug concerning Java not releasing native memory at appropriate time in Java 1.6. I'm not sure but it has been fixed in Java 1.7. I understand your position but could you at least tell me how I could get the reference to _buffer? In the source code, the method of the renderer that deletes the VBO only receives as a parameter an integer (an identifier).

Edit.: why is _identityCache only used when cleaning all VBOs? Is it a bug? Should deleted expired VBOs be removed from this cache? I will have to use some ugly hacky code to use it to do what I want.
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Re: Lifecycle of abstract buffer data

Postby renanse » Wed Feb 29, 2012 9:10 pm

_identityCache uses weakKeys, so it will automatically be removed when there are no more strong references to the AbstractBufferData (which is when the reference queue would get a hold of it.) As for killing the _buffer... You are only given ids because that buffer could potentially be used by multiple contexts and thus have another valid user.
Gratitude is a mark of a noble soul and a refined character.
User avatar
renanse
Site Admin
 
Posts: 2988
Joined: Tue Oct 28, 2008 6:49 pm
Location: Austin, TX

Re: Lifecycle of abstract buffer data

Postby gouessej » Fri Mar 02, 2012 6:07 am

Hi

Thanks for your explanation. glDeleteBuffers already destroys the data store on the GPU. Actually, handleVBODelete is called after gatherGCdIds, gatherGCdIds calls ref.clear() when using multiple contexts or not, this means that Ardor3D triggers the destruction of _buffer.

I will destroy _buffer just before ref.clear(). Then, the garbage collector will see that this nio buffer is already released, there won't be any problem. However, I don't find any clean way to override the default behavior of Ardor3D, I don't want to copy/paste 3 classes. It would be easier for me if all static features were put into separate classes and if I could set my own mechanism so that it is used from the start, for example:
AbstractBufferData.setCleaner(customCleaner);

That's a clever code, I understand it better now. When the context is lost, all VBOs are deleted.
gouessej
regular
 
Posts: 1400
Joined: Fri May 01, 2009 3:26 am
Location: France

Next

Return to HELP!

Who is online

Users browsing this forum: No registered users and 3 guests