This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FileDescriptor suggestion [Was: FYI: Patch: java nio file locking]


Michael Koch wrote:
I dont know how much possible this really is at first look. Note that java.net and socket stuff of java.nio are also using
FileDescriptor.

And SocketImpl has an actual protected fd field, which prohibits lazily allocating FileDescriptor at least for SocketImpl.

 public FileDescriptor getFD ()
 {
   return FileDescriptor.get(channel);
 }

This has to be native code, otherwise we would get access violations or compile time errors (depending on compiler)

Another problem I overlooked is garbage collecting FileDescriptors, which is difficuly when they're in a linked list. Duh. One could solve that using some kind of weak references, but that add more overhead than is justified.

So lets keep it simple:  Just add fields for FileDescriptor in
the classes that need them.  FileDescriptor is simple wrapper
around a FileChannel, and has no native methods:

public class java.io.FileDescriptor
{
  FileChannel channel;
  ...;
}

public class FileInputStream
{
  FileChannel channel;
  FileDescriptor fd;
  public getChannel () { return channel; }
  public getFD ()
  {
    synchronized (this)
      {
        if (fd == null)  fd = new FileDescriptor(channel);
        return fd;
      }
  }
}


I more and more I think the idea from Anthony Green for
PlatformDescriptor gets more needed then ever. FileDescriptor would be
very minimal and all the platform dependant stuff would go into a
platform specific class.

But why not use FileChannel for this? I.e.:


public class java.io.FileDescriptor
{
  FileChannel channel;
  ...;
}

public abstract class java.nio,channels.FileChannel { ... }

public abstract class gnu.java.nio.channels.FileChannelImpl
  extends java.nio,channels.FileChannel { ... }

public abstract class gnu.java.nio.channels.FileChannelPosix
  extends gnu.java.nio.channels.FileChannelImpl
{
  int fd;
  ...
}

public abstract class gnu.java.nio.channels.FileChannelWin32
  extends gnu.java.nio.channels.FileChannelImpl
{
  RawRata fd;
  ...
}

Thus FileChannelImpl is just another word for PlatformFileDescriptor,
except that it happens to extend FileChannel.  Thus we avoid the
overhead of having to have a separate PlatformFileDescriptor object.
(The memory overhead doesn't matter, but it does require extra
indirections we may want to minimize.)

The currently implementation has FileChannelImpl be a wrapper for
FileDescriptor, and FileChannelImpl overations indirect to
operations on FileDescriptor.  I'm suggesting we do the opposite,
since there are so few public operations in FileDescriptor, but
there are a lot in FileChannel, so we get better performance
and simplicity having FileDesciptors operations indirect to
operations on FileChannel.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]