Re: Classpath / GCJ java.io Merge
> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes: [ DataOutputStream ] Aaron> Those shared methods can die, IMO. They don't do much. The Aaron> allocation is an interesting point. Classpath does it to avoid Aaron> doing what gcj does: namely do tons of single byte writes. Aaron> This would be hideously expensive in the JNI world. Is Aaron> allocation still a problem? For me the swaying argument is that if there is a lot of allocation inside the class, the user can't do anything about it. But if there are too many short writes, he can add a buffer. In private mail (Aaron and I have had a conversation about this off-list) I said that the performance of DataInputStream and DataOutputStream probably doesn't matter. But while looking elsewhere today I found that serialization uses these classes. So maybe performance here is important. We could always add a `byte[8]' buffer to these classes. Synchronization isn't that expensive. Or, for DataInputStream, we could just leave it unsynchronized, like libgcj currently does -- I don't know when it would make sense for two threads to read from a DataInputStream. >> For PrintStream it looks like there were conflicting goals. From >> libgcj: Aaron> Hmm. I kinda liked the Classpath approach, assuming it's Aaron> actually a valid implementation strategy, because I'm lazy by Aaron> nature. Yeah, me too. And I dislike duplication. I notice the libgcj implementation routes everything through the print(...,boolean) methods in PrintStream. Presumably this is to make it easier to subclass. I haven't looked to see whether this behavior is specified. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: >> http://gcc.gnu.org/java/libgcj-classpath-compare.html Mark> BTW Tom, when are you going to enable the automatic updater of that Mark> page? It is already a bit out of sync with reality again. I'll try to do it soon. I wanted to get the nightly build stuff set up first (now done) and let it run for a while to iron out any problems (also done). Mark> I recently looked at the char conversion code of libgcj and Mark> although it is nicer then the Classpath one it isn't Mark> optimal. James Clark recently found a bug in it that shows up Mark> when a converter cannot make progress anymore because the output Mark> buffer was full and the input buffer was empty. Yeah, we've run into bugs in this from time to time. There is also PR libgcj/1379 -- the libgcj converters have no way to signal that something has gone wrong. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Hi, On Thu, 2003-02-27 at 04:19, Aaron M. Renn wrote: > Hi. I've been looking at the Classpath / GCJ merge status here: > > http://gcc.gnu.org/java/libgcj-classpath-compare.html BTW Tom, when are you going to enable the automatic updater of that page? It is already a bit out of sync with reality again. > For #2, it seems that the answer is to switch to NIO. I hear that the > Classpath version is not yet functional however. Jesse Rosenstock <[EMAIL PROTECTED]> has been working on this. It should be API complete (in libgcj at least) and he was looking at converting the gnu.gcj.convert iconv support to it so String could use java.nio.charset for getBytes() and such methods. I recently looked at the char conversion code of libgcj and although it is nicer then the Classpath one it isn't optimal. James Clark recently found a bug in it that shows up when a converter cannot make progress anymore because the output buffer was full and the input buffer was empty. You need a way to signal both these conditions. java.nio.charset gives you that support from the start. See thread starting: http://gcc.gnu.org/ml/java-patches/2003-q1/msg00532.html > For #1, I have no idea what has been decided regarding native code. > Last I checked, we still had a JNI/CNI deadlock going on. We have to go for the setup that libgcj uses (delegate actual file access to the package local methods of FileDescriptor). Classpath has a problem with the ownership of the file descriptor. See the description of Jeroen Frijters here (and how I dropped the ball on the issue by saying that I would look into it soon...): http://mail.gnu.org/archive/html/classpath/2002-07/msg00012.html Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: Brian> Between gcj and classpath there is a difference of opinion on Brian> whether to drop into native code (CNI) at every opportunity or Brian> not and I think it has affected the way some things are Brian> handled. There don't seem to be very many places where the goals conflict. But, yeah, there are some. We should be better about identifying these. We can maintain `gcj local' variants of methods and classes that are important to us -- as long as they are clearly marked, they show up nicely on the diff page, and generally don't cause a big problem for merging. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Brian Jones wrote: I'd like to see our I/O implementation handle 64-bit filesystems and all the native libs be 64-bit compatible (i.e. no assuming pointers are ints, file handles are ints, etc.). GCJ uses the "magic" class type gnu.gcj.RawData as essentially a non-GC'd 'void *' pointer. This may not be portable to other VMs directly, but you could have a script convert gnu.gcj.RawData to int or long, depending on the target word size. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Brian Jones wrote: I have noticed that for a good deal of CNI code it is quite straight forward to turn it into C or C++ based JNI instead. There was a Perl script that someone purported to do some of this a while ago. I'm tempted to play with it a bit. That would be great, but surprising. I would think you'd need a fair bit of analysis to convert CNI to JNI. If we could maintain native methods in readable CNI, possibly with some annotations/conventions to ease the script's job, and generate JNI automatically from that, it might solve much of the CNI vs JNI problems. For the hard bits, we could use #ifdef CNI sections. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
"Aaron M. Renn" <[EMAIL PROTECTED]> writes: > One problem is that it is not just the native methods that are different. > I think it would be relatively easy to write a CNI and a JNI version of > the code as there is not a huge amount of native code to write for > IO and networking. The problem is that the entire implementation strategy > of the classes is different. For example, gcj relies heavily on delegating > to OS file access methods in the FileDescriptor class, which Classpath > doesn't use at all. The challenge would seem to be getting agreement > on what native methods need to be written and what their signatures are. Between gcj and classpath there is a difference of opinion on whether to drop into native code (CNI) at every opportunity or not and I think it has affected the way some things are handled. However I think when designing for JNI you do not hinder library performance using CNI but the opposite is not true. I'd like to see our I/O implementation handle 64-bit filesystems and all the native libs be 64-bit compatible (i.e. no assuming pointers are ints, file handles are ints, etc.). -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Tom Tromey <[EMAIL PROTECTED]> writes: > > "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes: > > Aaron> For #1, I have no idea what has been decided regarding native code. > Aaron> Last I checked, we still had a JNI/CNI deadlock going on. > > I'm resigned to the fact that we'll need dual implementations of > certain native code. The Gtk AWT peers I imported into libgcj as-is, > using JNI, but that is a special case. > > This does hamper merging since it is a lot of effort to rewrite the > JNI code. I've never had time, or really much motivation. > I think there's also some question of which approach is preferable. I have noticed that for a good deal of CNI code it is quite straight forward to turn it into C or C++ based JNI instead. There was a Perl script that someone purported to do some of this a while ago. I'm tempted to play with it a bit. -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
Tom Tromey ([EMAIL PROTECTED]) wrote: > Aaron> For #1, I have no idea what has been decided regarding native code. > Aaron> Last I checked, we still had a JNI/CNI deadlock going on. > > I'm resigned to the fact that we'll need dual implementations of > certain native code. The Gtk AWT peers I imported into libgcj as-is, > using JNI, but that is a special case. > > This does hamper merging since it is a lot of effort to rewrite the > JNI code. I've never had time, or really much motivation. > I think there's also some question of which approach is preferable. One problem is that it is not just the native methods that are different. I think it would be relatively easy to write a CNI and a JNI version of the code as there is not a huge amount of native code to write for IO and networking. The problem is that the entire implementation strategy of the classes is different. For example, gcj relies heavily on delegating to OS file access methods in the FileDescriptor class, which Classpath doesn't use at all. The challenge would seem to be getting agreement on what native methods need to be written and what their signatures are. > Aaron> For #2, it seems that the answer is to switch to NIO. I hear > Aaron> that the Classpath version is not yet functional however. > > I think Michael just got the gcj version to work. I think his plan is > at least to merge all the Java code back to Classpath. I'm not sure > if he is planning to write the JNI side or not. I also don't know how > much work that would be. That will have to be addressed, I guess. I just noticed that there are shitloads of native methods in this package. Hopefully except for falling back on iconv, there aren't a huge number of them for charest conversion. > In Classpath, methods in DataOutputStream are used by > RandomAccessFile. So this puts DataOutputStream effectively into > category 1. Also the Classpath implementation allocates in many of > the write methods, which we preferred to avoid in libgcj (especially > when I wrote this code, way back when). Those shared methods can die, IMO. They don't do much. The allocation is an interesting point. Classpath does it to avoid doing what gcj does: namely do tons of single byte writes. This would be hideously expensive in the JNI world. Is allocation still a problem? > For PrintStream it looks like there were conflicting goals. From > libgcj: Hmm. I kinda liked the Classpath approach, assuming it's actually a valid implementation strategy, because I'm lazy by nature. > Also, the libgcj PrintStream knows about charset conversion, so it is > effectively in category 2. > LineNumberReader I don't know. I think I just never found the > motivation to compare the two implementations. They are very > different, so a lot of testing would probably be in order. I'll take a look at this. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Classpath / GCJ java.io Merge
> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes: Aaron> For #1, I have no idea what has been decided regarding native code. Aaron> Last I checked, we still had a JNI/CNI deadlock going on. I'm resigned to the fact that we'll need dual implementations of certain native code. The Gtk AWT peers I imported into libgcj as-is, using JNI, but that is a special case. This does hamper merging since it is a lot of effort to rewrite the JNI code. I've never had time, or really much motivation. I think there's also some question of which approach is preferable. Aaron> For #2, it seems that the answer is to switch to NIO. I hear Aaron> that the Classpath version is not yet functional however. I think Michael just got the gcj version to work. I think his plan is at least to merge all the Java code back to Classpath. I'm not sure if he is planning to write the JNI side or not. I also don't know how much work that would be. Aaron> 3. Random Classes Aaron> - Aaron> DataOutputStream Aaron> LineNumberReader Aaron> PrintStream Aaron> For #3, I'm a bit confused. Does anyone have any background on Aaron> why these classes aren't merged? I poked around the source Aaron> code, and it does not appear obvious. Are the Classpath Aaron> versions seriously broken or something? I remember looking at this a long time ago. In Classpath, methods in DataOutputStream are used by RandomAccessFile. So this puts DataOutputStream effectively into category 1. Also the Classpath implementation allocates in many of the write methods, which we preferred to avoid in libgcj (especially when I wrote this code, way back when). For PrintStream it looks like there were conflicting goals. From libgcj: /* Notice the implementation is quite similar to OutputStreamWriter. * This leads to some minor duplication, because neither inherits * from the other, and we want to maximize performance. */ >From Classpath: * Ok, why is this class deprecated? It could easily have been extended * to support character encodings. In fact, PrintWriter is basically a * superset of this except for the write() methods. So let's do something * tricky here and just redirect calls in this class to a hidden PrintWriter * instance. All the functionality goes there since that is the 'real' * class. The big win of doing this way is that the default character * encoding is done automagicially by the PrintWriter tree! Also, the libgcj PrintStream knows about charset conversion, so it is effectively in category 2. LineNumberReader I don't know. I think I just never found the motivation to compare the two implementations. They are very different, so a lot of testing would probably be in order. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Classpath / GCJ java.io Merge
Hi. I've been looking at the Classpath / GCJ merge status here: http://gcc.gnu.org/java/libgcj-classpath-compare.html specifically, java.io. Of the un-merged classes, I group them as follows: 1. Classes Doing Native I/O --- FileDescriptor File FileInputStream FileOutputStream RandomAccessFile 2. Classes Doing Character Encoding --- InputStreamReader OutputStreamWriter 3. Random Classes - DataOutputStream LineNumberReader PrintStream For #2, it seems that the answer is to switch to NIO. I hear that the Classpath version is not yet functional however. For #1, I have no idea what has been decided regarding native code. Last I checked, we still had a JNI/CNI deadlock going on. For #3, I'm a bit confused. Does anyone have any background on why these classes aren't merged? I poked around the source code, and it does not appear obvious. Are the Classpath versions seriously broken or something? (I already found a few errors that need fixing). I'm thinking about trying to tackle some of the remaining un-merged classes. -- Aaron M. Renn ([EMAIL PROTECTED]) http://www.urbanophile.com/arenn/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
