NIO Buffer questions.
Salter, Thomas A
Thomas.Salter at unisys.com
Tue Aug 21 07:15:04 PDT 2012
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 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:image001.gif at 01CD7F85.D53BDAE0]
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/0d61d337/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2511 bytes
Desc: image001.gif
Url : http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/0d61d337/image001-0001.gif
More information about the nio-discuss
mailing list