How release gpu memory of unused mesh or textrues - not loaded by assetManager? lose all references ?
Yes.
They will be automatically reclaiming during garbage collection - losing the Java object will trigger cleanup in the OpenGL context.
(I had that question myself some time ago.)
thx
Just be aware that if you have small Java objects connected to large native objects you can end up with running out of space. Make sure your various heap sizes are set up correctly. (For most cases the default settings are fine, its only if you poke them or you run into this problem that you need to worry about this).
What do you mean when you say ‘losing’ and object, @toolforger (or anyone else if they can answer)
If I have a global object in my main class, how can I ‘lose’ it?
He means removing all references to it - making it eligible for garbage collection.
Direct allocated nio buffers are automatically deleted when no references to buffer ?
I found:
https://code.google.com/p/jmonkeyengine/source/browse/branches/3.0final/engine/src/core/com/jme3/util/BufferUtils.java
Can I manually release memory from textures and meshes, not waiting for gc ?
@Mararok said: Direct allocated nio buffers are automatically deleted when no references to buffer ? I found: https://code.google.com/p/jmonkeyengine/source/browse/branches/3.0final/engine/src/core/com/jme3/util/BufferUtils.javaCan I manually release memory from textures and meshes, not waiting for gc ?
You can… but you had better be real sure that the renderer is done with them or you could do very bad things, to include crashing your app or for poorly written drivers, crashing the whole OS.
I’d say if you need to ask, you’re not deep enough into manual memory management to do that without risking horrible problems. It’s really, really, really easy to forget a use and releasing some object too early; garbage collection is there for a reason.
And as pspeed wrote, bad things will happen if you run into that problem, but there’s worse: Fixing such problem isn’t easy, you have to check each and ever point in the software where that buffer might be cached, including in code that you didn’t write (say, some third-party jar might cache a reference to that buffer you thought you could release).
Don’t do this, unless you have established with 100% certainty that you absolutely must, and even then, look for other solutions first.
And if you still want to do it, be sure to bring tons of experience with keeping track of objects, and can wield the debugger and jvisualvm without even thinking.
@toolforger said: I'd say if you need to ask, you're not deep enough into manual memory management to do that without risking horrible problems. It's really, really, really easy to forget a use and releasing some object too early;
I know, I programming in c + + - smart pointer is my friend 
Ah, I see the smart pointer phenomenon isn’t dead yet.
I have seen claims that typical modern software spends 10-20% of its time in malloc, free, and reference count updates. Might seem outlandish but isn’t actually, modern clibs do a huge amount of bookkeeping to fight heap fragmentation.
It would still be interesting to see whether profiling runs can actually back that claim.