NIO Buffer questions.

[Salter, Thomas A]

Thanks for your fast response.

In response to your questions.
1. Yes, this is a part of a porting effort, but we're also hoping to implement an installable File System extension that would not be part of java.nio.
2. So with a phantom reference, I'd need to associate my physical buffer with the reference so that I'd know which BB was GC'd when the reference appears on the reference queue.  Then I could have my native code free the physical buffer.
3. There's no problem with way buffers are used in java.nio.file.  I was just trying to understand and determine how hard I should try to follow that pattern rather than just using the more obvious JNI calls.  It hadn't occurred to me that GetStringChars was always making a copy of string buffer - I should have looked at the code sooner.

Tom


From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
Sent: Tuesday, August 21, 2012 9:52 AM
To: Salter, Thomas A
Cc: nio-discuss at openjdk.java.net
Subject: Re: NIO Buffer questions.

On 21/08/2012 14:25, Salter, Thomas A wrote:
I've been exploring java.nio.Buffer and have some questions about why things were done the way they were.


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?
This is by design, buffers are not an extensible abstraction. Is the "48-bit things" related to porting, in which case I would think that you could put your implementation in java.nio as package-private classes.



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?
You'll need to use a weak or phantom reference to know when the ByteBuffer is GC'ed.



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?
Is this a problem? The main rational is to keep the native code to a minimum and also to avoid a malloc/free per call that involves a path name. It does have an optimization for cases where you are doing lots of operations on the same file name but that isn't as significant.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/610305aa/attachment.html