NIO Buffer questions.

[Ariel Weisberg]

Hi,

Sorry, I overlooked that you were allocating the memory natively and
that the JNI DBB wrappers don't take ownership. I took an alternative
approach to reference queues in that scenario.

When I have to push data from native code to Java via DBBs I also
included the pointer as a long and then use an explicit JNI method to
free the memory (or return it to a pool) as well as a finalizer as
backup. The finalizer logs when the explicit free is not performed so
that I don't end up relying on finalization/GC. I always pass the DBBs
around in a container that contains the finalizer and pointer as a
long.

If the ByteBuffer is never stored outside the container it is safe,
even from double frees since you can zero out the pointer on release.
You can also have the getter for the raw DBB throw if the pointer is
zeroed. You can have different container implementations that release
the memory back to different locations which can be handy.

 Plus, I’m not fond of relying on undocumented implementation details.

If you think that is gross you should see what it takes to use
posix_fadvise or open a file with O_DIRECT.
:-)

Regards,
Ariel

On Tue, Aug 21, 2012, at 10:15 AM, Salter, Thomas A wrote:

Thanks, but this seems to be the opposite of what I need.  I would need
to install my own cleaner to know when the BB was GC’d.  Plus, I’m not
fond of relying on undocumented implementation details.



From: Ariel Weisberg [mailto:ariel at weisberg.ws]
Sent: Tuesday, August 21, 2012 9:44 AM
To: Salter, Thomas A; nio-discuss at openjdk.java.net
Subject: Re: NIO Buffer questions.


Hi,


I'll only address #2.
See [1]http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase
/hbase/0.92.1/org/apache/hadoop/hbase/util/DirectMemoryUtils.java

You can manage the lifecycle of the buffers yourself even though it is
not what was intended. You don't need to manage the lifecycle since GC
should free the DBB for you.


Ariel


On Tue, Aug 21, 2012, at 09:25 AM, Salter, Thomas A wrote:

I’ve been exploring java.nio.Buffer and have some questions about why
things were done the way they were.


1.      I have an application where I thought it would be appropriate
to implement my own Buffer class, basically to deal with a series of
48-bit things.  Unfortunately ByteBuffer is not extendable for fairly
obvious reasons given its implementation, but java.nio.Buffer is also
not extendable – it’s public, but its constructor is package-private
instead of protected. In order to implement a buffer-like class I need
to duplicate all the position-related functions rather than inherit
them.  Is there a reason for this?

2.      The JNI function, NewDirectByteBuffer, lets native code
allocate a direct buffer and pass it to Java code, but there doesn’t
seem to be any way to manage the lifetime of the buffer.  This would
seem to mean NewDirectByteBuffer can only be used in tightly controlled
situations  by private Java code that closely cooperates with the
native code.  There’s no way for the native code to know when the
ByteBuffer it allocates is released by Java.  Am I missing something?

3.      The implementation of java.nio.file in sun.nio.fs uses native
buffers not just for large I/O buffers but also for passing file names
from Java to native code.  It seems to be trading off copying strings
in Java code vs. making JNI calls from native code.  What’s the
rationales behind this?




Tom Salter  |  Software Engineer  |  Java & Middleware Development

Unisys  |  2476 Swedesford Road  |  Malvern, PA  19355   |
610-648-2568 |  N385-2568

                                     cid:image002.gif at 01CBD419.9CAC0060

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY MATERIAL and is thus for use only by the intended
recipient. If you received this in error, please contact the sender and
delete the e-mail and its attachments from all computers.




  Email had 1 attachment:
  * image001.gif
      3k (image/gif)


  Email had 1 attachment:
  * image001.gif
      3k (image/gif)

References

1. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.92.1/org/apache/hadoop/hbase/util/DirectMemoryUtils.java
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/0ce5b342/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2511 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/0ce5b342/image001-0001.gif