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 !). 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. * 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). * autoconf code is a lot clearer if we can isolate the portions of code to be replaced. 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). Cheers, Guilhem.
