DirectBuffer, deallocation

Question

I allocated a direct buffer:

ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024);

I've read that:

Deallocating Direct Buffer Native Memory in Java for JOGL

but it doesn't answer directly.

To summarize:

GC releases a directbuffer when GC will be launched and a directbuffer wasn't be referenced. In linked post it is written that:

When you know that a direct NIO buffer has become useless for you, you have to release its native memory by using its sun.misc.Cleaner (StaxMan is right) and call clean() (except with Apache Harmony), call free() (with Apache Harmony) or use a better public API to do that (maybe in Java >= 1.9, AutoCleaning that extends AutoCloseable?).

but I didn't see how to explicitly release of memory chunk. Ok, there exists a sun.misc.Cleaner and what?:

Cleaner c = new Cleaner()

What is the purpose of using DirectBuffer instead of Unsafe.allocateMemory.

This solution (in this JEP, still a draft, probably not available in Java 1.9) is very promising, we won't need to use non public APIs.

public long memory(long index) {
    // The scope where the memory region is available
    // Implements AutoClosable but `close` can be called manually as well
    try (Scope scope = new NativeScope()) {
        // Allocate the actual memory area, in this case in the style of a "long-array"
        Pointer<Long> ptr = scope.allocate(
                    NativeLibrary.createLayout(long.class), numElements);

        // Get the reference to a certain element
        Reference<Long> ref = ptr.offset(index).deref();

        // Set a value to this element through the reference
        ref.set(Long.MAX_VALUE);

        // Read the value of an element
        return ref.get();
    }
}

It looks like smartpointers in C++, doesn't it?

Why have you posted a brand new question here instead of asking a question in the comments below my answer? — gouessej, Oct 13 '17 at 11:56
Maybe this helps: https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/util/ReflectionAllocator.java#L125 Unsafe will be a lot harder to use in Java 1.9, I don't advise you to rely on it. The scope benefits of the try with resource, the resource is correctly handled at the end of the block or you can call Scope.close() to release the memory whenever you want. — gouessej, Oct 13 '17 at 12:04
By the way, I remind you that my answer mentions at least three examples to do exactly what you want, including at least two under permissive licences. — gouessej, Oct 13 '17 at 12:07

score 1 · Accepted Answer · answered Oct 08 '17 at 14:20

1

but I didn't see how to explicitly release of memory chunk.

Currently you can't in java because it wouldn't be safe. It could lead to use-after-free bugs. Approaches that would make it safe, e.g. virtual memory manipulation or safepoint gymnastics, are difficult, might cost some performance or may not work on all platforms.

It is not impossible, but requires significant work. See JDK-4724038, its duplicates and linked mailing lists for the proposals that have accumulated over the years.

What is the purpose of using DirectBuffer instead of Unsafe.allocateMemory.

Safe access to stable memory locations that can be passed to native code without copying and without the need for object pinning (something not supported by hotspot).

answered Oct 08 '17 at 14:20

the8472

40,999
5
70
122

It might be considered unsafe and difficult but it's currently possible, I advise you to read anew my answer in the quoted question. Maybe I have misunderstood your answer. – gouessej Oct 13 '17 at 11:55
@gouessej I am aware of those methods, but that doesn't change that it's not possible in *Java*. It is merely possible in some Java implementations using implementation-specific, undocumented internal methods which may not even be available due to reflection restrictions, e.g. imposed by security managers. Relying on implementation-specific behavior brings a lot of pain to the ecosystem, so conflating the spec with the implementation is a bad habit. – the8472 Oct 13 '17 at 18:11
Yes, that's why I expect a smarter solution in the public APIs in Java 1.9 or Java 1.10 but the cleaner has become a Runnable in Java 1.9 which drives the dirty path less painful and in the meantime, being unable to release the native resources is unacceptable. There is no implementation-agnostic solution yet. – gouessej Oct 14 '17 at 12:16

score 1 · Answer 2 · answered Oct 15 '17 at 18:03

You actually can, but the code is weird.

    // unmap the memory mapped buffer (wait gc cleans it up)
    ReferenceQueue rq = new ReferenceQueue();
    PhantomReference<ByteBuffer> ref = new PhantomReference<>(ref_out, rq);
    ref_out = null;
    while(rq.poll() == null) {
        System.gc();
    }

    // all finalizers are finished... only phantom references left.
    PhantomReference<PhantomReference> pref = new PhantomReference<>(ref, rq);
    ref.clear();
    ref = null;
    while(rq.poll() == null) {
        System.gc();
    }
    pref.clear();

Cheers,

D.

DirectBuffer, deallocation

2 Answers2