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.
