What Happens When Native Memory Space Pointed By java.nio.ByteBuffer Is Deleted

[res7cxbi]

Say that i have a piece of native memory that i've wrapped with
java.nio.ByteBuffer via JNI. What happens when i delete that memory
space that java.nio.ByteBuffer points to? Does anything weird happens
with the ByteBuffer?

 

[castillo.bryan]

If you try to access it or assign to it you may (probably will) get
core dumps.

You shouldn't use that ByteBuffer anymore. I had thought about setting
the length of a buffer to -1 after freeing it and having all of my code
check the length when the ByteBuffer is passed into a JNI function. I
never did that though.

I ended up wrapping all of my native ByteBuffers in another object I
called ManagedBuffer, which had finalize overriden, in case the users
of the library forgot to delete resources. (However, I still had issues
since each native byte buffer had about 50mb+ of memory. Since that
memory was allocated by malloc, that amount of memory didn't trigger
the garbage collector as often as I would have liked it to have run.)

 

[res7cxbi]

That's what i thought
Because i have a large native array that will crash the JVM if i tried
to use ordinary JNI functions to wrap it in a jbyteArray and passing it
to java. (That has happened) So i used a ByteBuffer to directly
reference to that native array so i could avoid doing all that copying
crap

I have successfully done this ByteBuffer thing without any jvm crashes


Then i just thought of this. Maybe i should wrap my ByteBuffer as well
so that i don't accidently access it when i delete the native array
that i don't need anymore.

thanks for answering

 

[Thomas Hawtin]

I ended up wrapping all of my native ByteBuffers in another object I
called ManagedBuffer, which had finalize overriden, in case the users
of the library forgot to delete resources. (However, I still had issues
since each native byte buffer had about 50mb+ of memory. Since that
memory was allocated by malloc, that amount of memory didn't trigger
the garbage collector as often as I would have liked it to have run.)

NIO itself does slightly better than a standard finaliser using
sun.misc.Cleaner. (Phantom)References that extend Cleaner get executed
from the ReferenceHandler thread, rather than queueing for a reference
queue (such as the the finaliser queue). If there is a finaliser that
references the buffer then, even with resurrection, the resource will
not be cleared until there is no way at all to access it.

If NIO can't allocate enough memory from a direct buffer, it will call
System.gc to try to get others to finish reclamation.

Tom Hawtin

 

[castillo.bryan]

NIO itself does slightly better than a standard finaliser using
sun.misc.Cleaner. (Phantom)References that extend Cleaner get executed
from the ReferenceHandler thread, rather than queueing for a reference
queue (such as the the finaliser queue). If there is a finaliser that
references the buffer then, even with resurrection, the resource will
not be cleared until there is no way at all to access it.

If NIO can't allocate enough memory from a direct buffer, it will call
System.gc to try to get others to finish reclamation.

The problem I was having though, had to do with the fact that the
memory was being allocated by JNI code calling malloc. Since the code
was not allocating memory through NIO, that didn't happen. Thats nice
to know though, I didn't realize NIO did that for creating native byte
buffers.

 

[castillo.bryan]

That's what i thought
Because i have a large native array that will crash the JVM if i tried
to use ordinary JNI functions to wrap it in a jbyteArray and passing it
to java. (That has happened) So i used a ByteBuffer to directly
reference to that native array so i could avoid doing all that copying
crap

I have successfully done this ByteBuffer thing without any jvm crashes


Then i just thought of this. Maybe i should wrap my ByteBuffer as well
so that i don't accidently access it when i delete the native array
that i don't need anymore.

thanks for answering

Just a clarification: I was talking about code where allocation is
done from code outside the JVM, not creating a direct byte buffer via
the allocateDirect method.