The problem for me is I cannot do the same trick as mythruna,
cause I have hard variating heap useage, on planetary levels it is up to 1gig or higher in space it is only like 200mb.
A fix for float buffers has been checked into SVN.
This might be the explanation for the different ram values
http://download.java.net/jdk8/docs/technotes/guides/io/enhancements.html
@EmpirePhoenix That might very well be the answer I was looking for (thxs) and they seem to have solved it in Java 7, (we use Java 6 atm).
Although I still think that creating a lot of garbage is not such a good idea in the first place. Maybe using a ByteBufferPool is better solution?
I suggested a similar approach, create a maximum size buffer and only use slice for the subbuffers, and mark the used space as occupied, (and vice versa when freeing them) this way arts of the buffers could be force freed wthout interuption of the GC, (while still having the gc for not that problematic buffers useable, by using a own ReferenceQuee to release the slcied buffer on grbagecollection) since usually only very few parts of the code churns buffers trough. I will try to provide a signature identicall implementation for this soon.
Yeah that should also work. I am looking forward to your implementation!
Theres no way we can use “buffers” for the actual issues we have in the engine with this. See most direct buffers in jme are either textures or meshes. And depending on their size the buffer has to be dimensioned. Thats why a new buffer needs to be created when a mesh is changed sizewise or combined with another mesh. So unless the jme base classes like Image and Mesh change how they handle their data, all of this will not help with assets direct memory issues.