Re: KJC and GNU Classpath
Geoff Berry wrote: > Vincent GAY-PARA <[EMAIL PROTECTED]> writes: > > > Hi, > > > > At DMS we tried to compile GNU Classpath with KJC > > (http://www.dms.at/kjc) and we encoutered some problems. > > > > ObjectInputStream: > > == > > problem with an expression (java/io/ObjectInputStream.java:1188: > > Variable "value" cannot be initialized by a value of type "int" [JLS > > 4.5.4]) > > Which compiler do you use ??? > > please rewrite: > > char value = default_initialize ? 0 : this.realInputStream.readChar > > (); > > as: > > char value = default_initialize ? (char)0 : > > this.realInputStream.readChar (); > > > > see also: java/io/ObjectInputStream.java:1223: Variable "value" cannot > > be initialized by a value of type "int" [JLS 4.5.4] > > > I believe this is a compiler error, not an error in the code. `value' > is not being initialized with a value of type int, but with a value of > type char. JLS 15.24: > > The type of a conditional expression is determined as follows: > > ... > > Otherwise, if the second and third operands have numeric type, > then there are several cases: > > ... > > If one of the operands is of type T where T is byte, short, or > char, and the other operand is a constant expression of type > int whose value is representable in type T, then the type of > the conditional expression is T. You're right. I've corrected KJC accordingly. My test case was: short s = aCondition ? 0 : 1; // compile time error but the following is valid: short s = aCondition ? 0 : (short)1; Sorry for the inconvenience. Vincent for DMS > > > ... > > -- > Geoff Berry
Re: KJC and GNU Classpath
On Dec 28, Brian Jones wrote: > Vincent GAY-PARA <[EMAIL PROTECTED]> writes: > > > Hi, > > > > At DMS we tried to compile GNU Classpath with KJC > > (http://www.dms.at/kjc) and we encoutered some problems. > > > WeakHashMap: > > > > java/util/WeakHashMap.java:336: Cannot access field "queue" it is in an > > other package and not a class member [JLS 15.10] > > This is a problem with how WeakBucket is setup I believe. It doesn't > make much sense to me why we would call the super constructor with a > package private data member that isn't even initialized in > java/lang/ref/Reference.java except in this same constructor. There > is also the problem mentioned above of queue being in another > package. I think Jochen Hoenicke should look at this. The queue meant here is WeakHashMap.queue, not Reference.queue. Okay, that is a name conflict, but since Reference.queue is private it shouldn't be visible in java.util. jikes and javac don't have problems with this. I may change this, but IMHO this is also a bug in kjc. BTW the conflicts in AbstractList are serious, jikes doesn't compile subList() correctly. Jochen
Re: KJC and GNU Classpath
Vincent GAY-PARA <[EMAIL PROTECTED]> writes: > This bug is already fixed. We'll try to make a new release available on our > CVS tomorrow. The line above should now work. Just wanted to report that kjc-suite/msggen does not seem to exist or at least I cannot check it out. Brian -- Brian Jones <[EMAIL PROTECTED]>
Re: KJC and GNU Classpath
Brian Jones <[EMAIL PROTECTED]> writes: > Vincent GAY-PARA <[EMAIL PROTECTED]> writes: > > > This bug is already fixed. We'll try to make a new release available on our > > CVS tomorrow. The line above should now work. > > Just wanted to report that kjc-suite/msggen does not seem to exist or > at least I cannot check it out. And now to let you know that after trying an update on the msggen directory and not getting anything I sent this and now if I do an update on kjc-suite I get about twice as many files as the first time I did a checkout. Weird, but anyway the msggen problem is gone. Apparently I now need a com.ibm.math package for kjc-suite/xtype/. Going to go try finding this. Sorry for any confusion. Brian -- Brian Jones <[EMAIL PROTECTED]>
Re: Ideas for faster classes
This is an answer to an old mail from Artur, but this has never changed since March. On Mar 2, Artur Biesiadowski wrote: > Here are few of my ideas about how some classes can be made a lot > faster. Maybe I'll implement them, but if not I would like to share > them. > > java.lang.Character > I was already talking about it - work directly on array, without > CharAttr creation (it is already done in my version) and create > compression tables more loosely - do not compress blocks that are too > short (like 2-5 lengths) - they should be merged with surrounding > explicit info (for better preformance in findBlock) I made a change that does this. It also uses Strings to get the initial data, instead of using various java.io classes. I think it might be bad if the static constructor of a basic class like java.lang.Character uses too many other classes (this might lead to bootstrapping problems). The strings are created by a perl script. See: http://www.informatik.uni-oldenburg.de/~delwi/classpath/ Artur: You should test it for performance. It is probably slower if many different methods are called on the same character (since I don't have a cached CharAttr), but faster if they are called on similar characters (characters in the same block). I think the normal case is that someone parses a string or a file and invokes a few different methods on many different (but often similar) characters. > [a nice java.util.Hashtable idea] > java.lang.BitSet > It might be interesting to implement BitSet to use array of ints instead > of array of longs. Of course sun have created API of bitset heavily > based on their internal representation - but only serialization and > hashcode computation would require hackery. Such BitSet would work a lot > faster on 32-bit CPUs. I wonder if it would be possible/reasonable to > distribute two versions - and place one that will work faster for target > machine (of course both of them would work on every platform). I already did this at that time, but never checked it in. Artur reported that it gave a good speedup for 32-bit CPUs. One problem with this file is that it needs a kind of preprocessor to differ between 32-bit and 64-bit CPUs. I used some perl code that automatically comments out one part of the file. Jochen
Re: Ideas for faster classes
"Jochen Hoenicke" <[EMAIL PROTECTED]> writes: > > java.lang.BitSet > > It might be interesting to implement BitSet to use array of ints instead > > of array of longs. Of course sun have created API of bitset heavily > > based on their internal representation - but only serialization and > > hashcode computation would require hackery. Such BitSet would work a lot > > faster on 32-bit CPUs. I wonder if it would be possible/reasonable to > > distribute two versions - and place one that will work faster for target > > machine (of course both of them would work on every platform). > > I already did this at that time, but never checked it in. Artur > reported that it gave a good speedup for 32-bit CPUs. > > One problem with this file is that it needs a kind of preprocessor to > differ between 32-bit and 64-bit CPUs. I used some perl code that > automatically comments out one part of the file. > > Jochen A possible configure solution is to place both files into CVS with different names denoting 32bit/64bit and at configure time create a symbolic link from the appropriate file to BitSet.java. In classpath/lib/standard.omit put the two files for 32bit/64bit in the list to be omitted (BitSet will still be picked up). See AC_LINK_FILES in configure.in for an example of doing the link. Although not my concern at the moment this method should do file/directory copies on platforms not supporting symbolic linking and if it doesn't it can be fixed to do just that. I'm in the middle of heavily hacking lib/Makefile.am so you might want to go ahead and do this yourself. Brian -- Brian Jones <[EMAIL PROTECTED]>
update 12/30/99
Tonight I committed my work from today on the compile process. For those interested read on. I added support for kjc and have tested it to see that at least for me it doesn't work. I just did an update to sync to CVS and maybe that will fix it but I don't know. It complains about a lot of exceptions which supposedly need to be declared. I configured as such... /configure --with-japhar --with-java=/usr/local/kaffe/bin/kaffe --with-javah=/usr/local/java/bin/javah --with-classlib=/usr/local/kaffe/share/kaffe/Klasses.jar:/usr/local/kaffe/share/kaffe/rmi.jar:/usr/local/kaffe/share/kaffe/tools.jar --with-kjc=/home/cbj/classes Normally kjc is picked up automagically from Kaffe (--with-kaffe), but in this case I needed to use the latest instead of what was shipped with Kaffe (and I needed to compile for Japhar). If we fully supported Kaffe and if Kaffe (kaffeh) completely worked this would be reduced to ./configure --with-kaffe. I'm having some small compile errors using Jikes, it may be my fault. The compile with Sun's javac may also come close to working but I haven't tried it. I also removed the warning about no such file this/that for the includes in lib/Makefile.am. Oh and a note for Aaron, .deps directories are deleted automatically in the native/* directories that matter on make clean. Enjoy, Brian -- Brian Jones <[EMAIL PROTECTED]>
Re: Success Compiling Latest Classpath!
"Aaron M. Renn" <[EMAIL PROTECTED]> writes: > Brian Jones ([EMAIL PROTECTED]) wrote: > > > -- Needed to mkdir vm/current and include, run autoheader without errors. > > > > > > -- Oops, as it turns out, we are supposed to symlink to vm/current > > >during the build process. I deleted the dir and hand crancked the link. > > > > Okay, configure should have done the symlink for you, some sort of problem? > > If the link doesn't already exist, autoheader bombs, and you need to run > autoheader before configure. Okay, I'll switch that Makefile back to some sort of if Japhar, else if Kaffe, else type statement which won't bomb. I don't know of a way to let autoheader deal with a symlink created a configure time. > > > -- Two compile errors in the GTK peers. These are bugs that need to be > > >fixed. The error text is below: > > > > I compiled earlier today without the problems you mention. Could it > > be javah in 1.1.5 is messed up? I'm using 1.1.7B. > > Could be. I'll look into it. > > > > For the record, my configure command was: > > > > > > ./configure --with-japhar --with-java=/usr/local/jdk1.1.5/bin/java \ > > >--with-javah=/usr/local/jdk1.1.5/bin/javah --with-jikes \ > > >--enable-maintainer-mode --with-classlib=/usr/local/jdk1.1.5/lib/classes.zip > > > > > > Now I'm off to see what happens when I type "make install" :-) > > > > Been playing with that today. I don't know if you did your get after > > my last commit or not but you might want to try again just to see > > those changes to where we install which in your case might be > > something like /usr/local/japhar/lib/classpath, > > /usr/local/japhar/share/classpath/glibj.zip. I haven't tried yet so I > > may have made a mistake. > > make install worked great, and I've got Japhar working with the latest > Classpath from CVS. The only problem I had was the the library names > we use don't seem to work with Japhar even though Toshok claims they > should. I had to create symlinks to the libjaphar_%s.so format to make > it work. Otherwise, A-OK. Chris is apparently going to look into this today. Brian -- Brian Jones <[EMAIL PROTECTED]>
Re: Ahhh....Success!
On Dec 29, Chris Toshok wrote:
> "Aaron M. Renn" wrote:
>
> > Brian Jones ([EMAIL PROTECTED]) wrote:
> > > I may have changed a couple of lib names today without changing the
> > > load in the .java file to match. My mistake. I'll fix it tomorrow.
> >
> > Our Java files should be loading names like "javanet". Now this maps
> > to a native library name. In Japhar, supposedly either libjavanet.so
> > or libjaphar_javanet.so work, but I've only ever gotten the latter to
> > do so. I wonder if we are hardcoding a library name someplace in our
> > native code.
>
> oh, you know what this might be? Jochen fixed a bug in MapDLLName (or
> whatever that method is) that gives you the name of the .so to load. that
> can only return one name, and it returns libjaphar_%s.so. hmm.. i'll take
> a look at this tomorrow.
This was necessary for the jdk1.2 classloader which checks if a
library exists (via File.exists) before even calling the native method
to load the lib. So for jdk1.2 MapDLLName must even return an
existing file name. This problem is because most of the loading
process is done in java in jdk1.2, so japhar cannot manipulate it.
The 1.2 API, where the classloader (which could be a custom class
loader) finds a library and not java.lang.Runtime, makes it really
hard to stay with the current multiple name scheme
(lib{japhar_,}%s.*). I would propose the following algorithm:
System.mapLibraryName returns "lib%s.so", to load custom JNI libs via
custom ClassLoaders just the same way it does under sun's jdk.
The bootstrap's ClassLoader.findLibrary should then first try to
locate libjaphar_%s.*, and if it doesn't succeed lib%s.*. Sadly, that
means that japhar doesn't work with the jdk-1.2 java.lang.ClassLoader.
Jochen
