Discussing all that is quite interesting. What do you guys would think about making something like ByteBuffers but also make them implement AutoCloseable. That way you kind of could create code like the following.
try (Buffer buffer = Buffer.allocateNative(...)) {
// ...
}
Alternatively you obviously would be able to call Autocloseable::close yourself and the Finalizer could be used as last resort if it wasn’t cleanly closed. WDYT?
try (Buffer buffer = Buffer.allocateNative(...)) {
someQueueBeingUsedByAnotherThread.add(buffer);
)
...
segfault!
Cas 
Or
Buffer buffer = ByteBuffer.allocateDirect();
...
someQueueBeingUsedByAnotherThread.add(buffer);
...
buffer = null;
...
System.gc(); // or just wait for one
...
segfault ... ?? ... maybe!
Sorry, give me fail-fast any day!
EDIT: That’s assuming some queue in another thread is passing to native code. Either scenario it’s easy enough to protect against segfaults from within Java code.
Well but the same would happen with a free method called 
For lots of use cases it still would make it convenient and for others they can call close on their own whenever they think it will be best.
Any advice why ppl here need dynamic realtime buffer allocate direct?
I don’t get it 
I always think direct buffer in java use for oprimization in closed library,
or for sending data to 3d party dll. (even in this case you can use let say one 10mb buffer and flip it)
For everything else you can use Heap memory.
It could also be preallocated and retrieved from a pool, but then you don’t want to free it but return it to the pool, therefore different use case.
[quote=“Icecore,post:66,topic:55436”]
This discussion is interesting outside of actual allocations. For example, glMapBuffer returns a pointer (managed by the OpenGL driver) and you need to wrap it in a ByteBuffer in order to safely access it. Or it could be a callback the gives you a char pointer and you need to decode it to a String.
The Vulkan API (and other low-level graphics APIs too) will be heavy on structs, versus the tons of functions we have in OpenGL. That means you’ll be doing many more (small) allocations, not only heavy allocations for texture/vertex data. The smaller the allocations, the more important becomes the associated overhead.
How so? Why can’t I just allocate a big buffer and treat it the way I want to? Isn’t that exactly what the point of Vulkan is? To get rid of the difference between VBOs, IBOs, etc and just have data?
[quote=“theagentd,post:69,topic:55436”]
Again, you’re thinking about rendering data, but I’m talking about the API itself. From what we know so far, Vulkan will be very similar to Mantle:
Mantle Programming Guide and API Reference
See the Data Structures section under Chapter XVIII - Mantle API Reference. There are 90 different struct types in there.
Even for rendering data and big buffers, having the confidence that escape analysis can work nicely with ByteBuffers may help you write cleaner code (versus using flyweights for example).
I fully understand what you talking about.
IMO: But its Api using problem, not java itself,
If you recive String pointer and need Java String – Api (library) can return
(String pointer objects)
with function – returnFullString, or its part
or directly on call return String.
*same with glbuffer (array) – good concept return object that wrap buffer(pointer) that have ready functions
with all usable enums – not pointer on buffer and (go google what opengl enum send with this buffer)
Its many cases its not java front-end problem) – final user want receive ready for use object, not pointer or buffer.
What’s wrong with flyweights? How would you use it with ByteBuffer instances? Do you mean that using closeable byte buffers would help to write cleaner code than when slicing a buffer under the hood?
This structural design pattern can still be used correctly in higher level code:
It’s an excellent solution to me. Good job noctarius However, why do you need to introduce a new method (Buffer.allocateNative(…))? Lol AutoCloseable.close() will probably do what DirectByteBuffer.free() does in Apache Harmony or encapsulate the un-smart code I’d have to write to find the DirectByteBuffer and release its native memory.
Icecore, imagine that you must use some old code not written in Java to generate the content of an image. You can create a direct NIO buffer, pass it to the native code, let it fill this buffer, get it in your Java code and copy the content of this buffer into a java.awt.image.DataBufferByte of a BufferedImage for example.
The problem is still that ByteBuffers (most probably) will stay 32bits forever, therefore a new API would be necessary to go 64bits. It was more about the AutoCloseable idea than the allocation method itself.
I assume that I’ll have to look at the Project Panama. I hope that it will provide a similar API.
Do you plan to make this change in the current API or only in the new one? Would the close() method do nothing on heap byte buffers?
HA! HA! You’re fired: https://sourcemaking.com/design_patterns/singleton/java/1
Looked through this site. I like the pictures…can’t decide which is my favorite:
I don’t understand what is wrong with my previous post.
I’m making fun of the web-site you linked…not you.
I can’t do it myself since I’m not (yet) an OpenJDK contributor. It is quite a bit more complicated to become one, however I am one of the representatives for Hazelcast inside the JCP. That said there is a high chance I’ll look into extensions or new APIs for those buffer / panama solutions. So far there is nothing yet submitted as a JSR, therefore it is hard to follow up what Oracle’s macgyvering internally.
XD
Exactly ^^
hm need try DataBufferByte thanks.
Hi
This is how I solve this problem for now, it’s robust and fast, it works with OpenJDK, Oracle Java, Android, Apache Harmony, GNU Classpath, … but you have to remove some syntactic sugar to make it work with Java < 1.7:
http://sourceforge.net/p/tuer/code/HEAD/tree/pre_beta/engine/misc/DeallocationHelper.java
noctarius, sun.nio.ch.Util has a static free() method…