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.
