-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeroen Frijters wrote:
> Casey Marshall wrote:
>> Tom Tromey wrote:
>>> It seems to me that this is an area we haven't handled very
>> well: this
>>> isn't really a "VM" thing per se -- the code could very well be
>>> written in pure java -- but rather a platform thing.
>>>
>>> I agree that adding special cases in File just makes the code uglier
>>> and uglier. But, we could delegate to a pure java "platform" class,
>>> with instances for "posixy", Windows, Windows CE, etc, and share the
>>> code across all VMs.
>>>
>>> We do something vaguely similar to this in libgcj (though in the
>>> specific case of File we put the platform stuff in native code).
>>>
>> FWIW I agree. Some of us were chatting about this on IRC, and not only
>> are these "VM" interfaces more often than not platform interfaces (or
>> with some things, all they rely on is JNI and standard C), but they do
>> lead to performance hits (witness our direct ByteBuffer).
>>
>> I think putting some design thought into this is a good idea, because
>> right now I don't think we have any clear idea about what the scope or
>> purpose of VM/platform interfaces are. Right now, it looks like it's
>> just an ad-hoc catch-all for anything that can't be done in
>> pure Java -- you slap a VM class on it, and hack up the core class.
>
> I disagree. In most cases the VM decides what platforms to support and
> how to do this, so it does make some sense to move this stuff into the
> VM interface. This combined with the fact that native methods are very
> inconvenient for some VMs (like IKVM), we decided to add this extra
> indirection layer where the VM can decide to do things differently.
>
OK. But I could argue back that VMs for whom native methods don't work
are broken as far a Java goes. I think you're saying that because
platform details, like how files and sockets work, are easier for you to
implement "in the VM layer," that they're necessarily VM-specific, and
not platform-specific. I couldn't disagree more with that.
There's also no rule saying that you have to use Classpath's version of
a class in your VM/system. If we can set things up such that as long as
you implement these classes *to the Java specification,* everything
works, you can have whatever implementation suits your system, and just
load that class first.
> I realise that for gcj people it may look like there is a significant
> difference between (e.g.) VMFile and VMThread, but other VMs replace
> both these classes.
>
Yeah, if I were writing a VM for Windows, I'd re-implement both. But,
VMThread would necessarily be tied to the VM's internals; VMFile would
be tied to how Windows handles files, having little to do with the VM
itself.
> BTW, if there are specific cases (like ByteBuffer you mention), I'm more
> than willing to discuss alternatives to find a better alternative to
> suites everyone. I think that in many cases the VM interface design
> suffers from the fact that not enough VM implementers participate in the
> design.
>
ByteBuffer (and Channels and Selectors -- that is, things that are
basically created with factory methods and service providers) are a
little different, because we can, e.g., control what version we use at
runtime with system properties. So posixy systems can return a fast,
native implementation, and other systems can return their own
implementation.
If we keep the VM* interface thing, I think a better design is to stop
passing the core class to a static VM method, with the native state
inside the core class, and just make these VM classes instance classes,
with the native state associated with the instance.
An example I'm thinking of is VMPlainSocketImpl. PlainSocketImpl has an
int field for the native file descriptor (and that makes just plain no
sense, either way), and passes itself to VMPlainSocketImpl methods,
which rips the descriptor integer out of that instance. I think it's
better to make VMPlainSocketImpl an instance class, and keep the native
state in that instance; in our default implementation, this would be an
integer file descriptor, and we'd have method pairs like so in the VM class:
public void vmMethod(args...) throws IOException
{
vmMethod(native_fd, args...);
}
private static native void vmMethod(int native_fd, args...) throws...
So the *interface* for the VM class is the public instance method, and
is the only one a VM writer needs to implement. Our default
implementation then just implements the function in the obvious, fast
way for POSIX. Maybe you can explain why passing an object to a static
method makes more sense than that (I can't see how; all it adds is a
litany of JNI calls to *every* method call).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBROLRteRILCRAfKHCAQK1dAf/W2jQgbJ1h3Ru9+z3unRfAylRMp308vpk
Dj5DCYfxHzQUnoYN4Dd+VeCmxrenaTxzj+WBcbeJZC1E5PW775q3WhKUOLgsrJ/z
SbeSq6VGarUYx+GQ3apTy0vrPtB+apcMY2scPJ21iyiGrK+9AsQ+S6b1CHDUk/K1
hcoxc7GxaHtYFulkyb8DDgYb+PybBRVfvDiEHQjKUM4B+VvIBWm6savpal2E0Uts
0dGS//6ZIBGCvxZNrx7/vgSArm98ji3SIxZdxt2eIFBCX46KhHZGKJ2JkX4nOTM4
bn5Kpqbv9KJyYo2SQ7CeyKpQf0QO9520PE33x7qe1iAC7Cw709reCQ==
=XbBm
-----END PGP SIGNATURE-----
