classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: VMFile confusion


From: David Holmes
Subject: RE: VMFile confusion
Date: Mon, 26 Apr 2004 11:44:31 +1000

David P. Grove wrote:
> And if your VM is sufficiently weird enough (Jikes RVM with m-n
> threading), then you might actually want to do something
> different about files.  We used to have our own version of
> FileDescriptor and do non-blocking I/O with hooks back into our
> threading layer instead of using the default classpath
> implementation.

OVM does a similar "weird" thing. We have to redirect every "native" method
to some library-glue that knows how to handle it correctly. Some simple
things like getting a file length or checking existence of a file may be
redirected back to an actual native method, but all actual I/O goes into the
VM before emerging as some kind of native interaction.

I'm quite happy with VMxxx for these classes - and much prefer this to
PlatformXXX (because our VMxxx classes are NOT platform specific), and
NativeXXX is incorrect because it is not native for us. The fact that all
JNI-supporting VMs may be able to share the same native code doesn't mean
that the choice of being native in the first place in not VM-specific.

Making a method native is a choice - and that choice is up to the VM. Let
the VMxxx methods have a default native implementation, but lets keeps those
native declarations in the VMxxx file.

If every "native" method were actually defined in a VMxxx class we wouldn't
need our initial redirection of native methods to the library-glue code, we
would just write the right code in VMxxx.

David Holmes





reply via email to

[Prev in Thread] Current Thread [Next in Thread]