 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006What Happens When Native Memory Space Pointed By java.nio.ByteBuffer Is Deleted
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? 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.) 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 > That's what i thought > Because i have a large native array that will crash the JVM if i tried [quoted text clipped - 11 lines] > > 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. > 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  SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ > > I ended up wrapping all of my native ByteBuffers in another object I > > called ManagedBuffer, which had finalize overriden, in case the users [quoted text clipped - 12 lines] > 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. > Tom Hawtin > -- > Unemployed English Java programmer > http://jroller.com/page/tackline/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.