On Jan 28, 2006, at 7:21 AM, Guilhem Lavaux wrote:
Hi Mark,
Mark Wielaard wrote:
Hi Guilhem,
On Sat, 2006-01-28 at 14:43 +0100, Guilhem Lavaux wrote:
I would like to mention that I am developping/fine tuning the new
native layer for classpath in a separate branch called "NATIVE-
LAYER". If you have some time to give your impressions then fetch
it and look into native/jni/native-lib, native/jni/java-io, ...
the new layer itself is developped in native-lib. The other
libraries are being adjusted currently...
Thanks for doing this on a branch. That makes it less disruptive and
easier for people to choose to test it out before we decide
whether to
incorporate the work on the trunk.
But even for CVS branches you need to send patches to the patches
mailinglist. That way people can follow your work and already read up
and comment on the things they see that they like or dislike. And it
prevents you from having worked on something very hard and then
"suddenly" dropping a big patch. You also need to update the
ChangeLog
file on the branch to show the steps taken in creating the new code.
Please use [native] in the subject when sending patches to the list.
(Sorry to be pedantic about this, but we want CVS to be our shared
development space, not someone personal playground.)
Ok. There was no patch at the moment so I could get to a real
point. Now is nearly the case. Let's begin the patch flood...
And please do send a proper patch for the things you already
checked in
If you didn't create a branch-point cvs tag then the following should
give you the initial diff: cvs diff -Nr classpath-0_20-release native
Ok. I'll send three sets of patches to classpath-patches: one to
remove target layer (obviously), one to add the foundations of the
new layer, and another to show the adaptations to the already
existing classpath's code.
What are the objectives for this branch? How will it be
similar/different from the work that Roman was doing?
I thought to have been already clear about that in the past (and
with no answers !).
Sorry, I meant to reply about what you were proposing, but forgot :-)
What you're working on seems a bit better than the target layer
stuff, in that you have real functions that the compiler/debugger can
tell you about, if there's an error. I don't, however, entirely see
the point of another funcall to wrap the syscalls in. It seems to me
as though efforts like this are trying to re-use the bits of JNI code
that wrap syscalls in the native parts of VM* classes, and not much
else.
In my opinion, time would be better spent:
- Writing utility functions that make JNI easier to deal with.
- Writing concise, portable (in the realm of POSIXy systems, at
least) native implementations of VM* classes that require native
support.
- Optimizing some functions for target systems (e.g., using epoll
on Linux, and kqueue on FreeBSD, etc.).
But on the whole, making library that is concise, easy-to-understand,
and which works efficiently on free platforms. The point is, we want
(at least I want) Classpath not just a *complete* class library, but
also an extremely good one. I think trying to make system details
generic like this accomplishes that.
Let's try to summarise my goal:
* if we want something which is quite portable (but maybe not as
portable as aicas portability layer) we must ensure some level of
abstraction to hide how syscalls are really used. That way if we
have to call different things in the OS (e.g. for more exotic
platforms like windows) or to use the syscalls differently we will
not be completely stuck by tons of autoconf code in the common VM
layer.
It seems like a lot of the argument for this kind of native layer is
"we can port to Windows/some exotic platform," but frankly, I don't
see it. Windows (in my uninformed opinion ;-) is probably wildly
different enough such that writing a win32 `cpio_read' isn't much
less work than writing a win32
`Java_gnu_java_nio_channels_FileChannelImpl_read__.' And since any
port like this is (AFAIK) merely hypothetical, I don't see the value.
* some VMs (like us in kaffe) do like to be able to intercept most
syscalls to ensure that syscall operations are atomic from the
point of view of the threading system. Sometimes you even need to
know when a syscall may block to acknowledge the VM to take wise
decisions for the GC (I don't remember if it was about wait4 at
that time).
That's kind of interesting. Can you explain how this works a little
more, or point me to the code where this happens? And why having the
native-lib shim between JNI and the system helps this?
* autoconf code is a lot clearer if we can isolate the portions of
code to be replaced.
This is true, to a degree. But in many places where APIs hardly
diverge at all, having this separation makes less sense. That is,
having a good system-level event notification mechanism (epoll/
kqueue//dev/poll/select/poll) certainly requires isolation in order
for it to make sense, because each platform is different, but a lot
of what is needed diverges much less, and there's little, if
anything, to isolate.
The native layer I am writing would like to give an answer these
problems. The default code will just be a rough encapsulation of
the native syscalls (though maybe not for recv/send/... which needs
some polling operations). I think that in future we'll need another
configure option for the VM to be able to specify a new adaptative
native layer.
At the moment, I have separated this code in another directory of
the classpath tree (native/jni/native-lib).
I don't mind this proposal, and I think you should go ahead with it.
I still have my own opinions about how to write Classpath's native
library, so I may try my own experiment in another branch (unless, of
course, no-one really agrees with me, in which case I will just stop
critiquing other people's code).
Thanks.
