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

Discussion in 'Java' started by res7cxbi@verizon.net, Jan 1, 2006.

  1. Guest

    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?
    , Jan 1, 2006
    #1
    1. Advertising

  2. Guest

    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.)
    , Jan 2, 2006
    #2
    1. Advertising

  3. Guest

    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
    , Jan 2, 2006
    #3
  4. Re: What Happens When Native Memory Space Pointed By java.nio.ByteBufferIs Deleted

    wrote:
    >
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jan 2, 2006
    #4
  5. Guest

    Thomas Hawtin wrote:
    > wrote:
    > >
    > > 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.
    >


    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/
    , Jan 2, 2006
    #5
  6. Guest

    wrote:
    > 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.
    , Jan 2, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeff Silvis
    Replies:
    1
    Views:
    773
    Paul Lutus
    Sep 16, 2004
  2. Michael B Allen

    [nio] Mutliple Messages in ByteBuffer

    Michael B Allen, Dec 13, 2004, in forum: Java
    Replies:
    1
    Views:
    407
    Esmond Pitt
    Dec 13, 2004
  3. Remon van Vliet

    nio ByteBuffer filling

    Remon van Vliet, May 19, 2005, in forum: Java
    Replies:
    3
    Views:
    2,212
    John C. Bollinger
    May 19, 2005
  4. Replies:
    2
    Views:
    1,447
  5. Replies:
    0
    Views:
    426
Loading...

Share This Page