another Kaffe project idea
Here's a relatively small Kaffe project that could be added to the projects page: Clean up Kaffe's command line. - Put some of the funkier options behind '-X'. - Support classpath and "bootclasspath" as separate concepts. (Supporting more levels of classpath than Sun's VM might be nice: so that the core stuff is on one classpath and less-core-relevant things like java.util.prefs or other Classpath libraries are findable, still separate from app-level classpath.) - Make it easy to add new -X options. - Accept (and probably ignore) some newer common options (like the silly -client and -server). - Make sure the never-used, hardly-documented ~/.kafferc works or is completely gone. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] "Forty-Two." -- Deep Thought
fix for new rt.jar stuff
Kaffe fails to build for me (and it failed to build in all the nightly
tests last night). It seems that the new rt.jar layout assumed Kaffe
was being built in its source tree.
The attached patch fixes the problem for me, but I so distrust
automake et. al. that I won't claim this is correct, or be the one to
commit this patch without an okay from someone
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
${HOME} is where the .emacs is.
RCS file: /cvs/kaffe/kaffe/libraries/javalib/Makefile.am,v
retrieving revision 1.58
diff -u -b -c -r1.58 Makefile.am
*** Makefile.am 2 Apr 2002 04:52:06 - 1.58
--- Makefile.am 3 Apr 2002 07:20:45 -
***
*** 933,938
rm -f $(srcdir)/$(CLASSFILE)
cp $(LIBDIR)/$(CLASSFILE) $(srcdir)/$(CLASSFILE)
! rt.jar: Klasses.jar
! cp Klasses.jar rt.jar
--- 933,938
rm -f $(srcdir)/$(CLASSFILE)
cp $(LIBDIR)/$(CLASSFILE) $(srcdir)/$(CLASSFILE)
! rt.jar: $(srcdir)/Klasses.jar
! cp $(srcdir)/Klasses.jar rt.jar
Re: Kaffe CVS: kaffe tullman
Cool. I updated the documentation page on the website to link to it as well. Cheers, - Jim On Tue, 2002-04-02 at 13:23, Kaffe CVS wrote: > > > CVSROOT: /cvs/kaffe > Module name: kaffe > Changes by: tullman 02/04/02 13:23:39 > > Added files: > FAQ: FAQ.debugging > > Log message: > first stab at documenting what/how/where for debugging Kaffe >
Kaffe CVS: kaffe tullman
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: tullman 02/04/02 13:23:39 Added files: FAQ: FAQ.debugging Log message: first stab at documenting what/how/where for debugging Kaffe
RE: Bug with Current KJC Compiler
> Under the new KJC (from their website), it works a bit better: > > Administrator@BFULGHAM1 ~/java > $ javac PlusPlusTest.java > assertion "!INTS_DISABLED()" failed: file "exception.c", line 386 > Aborted (core dumped) > > I'm not sure which is worse -- however the second case > indicates an issue with the JVM so might be of more interest > to us as time passes. > Actually, it seems to be related to time. If I run in verbose mode, everything builds just fine... Administrator@BFULGHAM1 ~/java $ javac OldTest.java assertion "!INTS_DISABLED()" failed: file "exception.c", line 386 Aborted (core dumped) Administrator@BFULGHAM1 ~/java $ javac -v OldTest.java [ start compilation in verbose mode ] [ parsed OldTest.java in 344 ms ] [ checked interfaces in 273 ms ] [ checked body of OldTest.java in 188 ms ] [ optimized and generated OldTest in 187 ms ] [ compilation ended ] -Brent
Re: java.util.prefs
Le mar 02/04/2002 à 01:06, Mark Wielaard a écrit : > The bit about XML exports is precisely the part that is not implemented > yet :) As I am searching for such a "medium size project", I will try to have a look on it :-) > I have CCed Mark Anderson who has recently tried to use the package in > his own project. I can also forward his remarks about the current > implementation and the bugs he found. Yes, please do ! It might be that I could solve some of them while working on the XML exports... > Cheers, > > Mark Frederic
Bug with Current KJC Compiler
The version of KJC that ships in Kaffe right now has a bug with the ++ operator when
used with instance variables. Here's a sample program that highlights the problem (at
least under a Cygwin build):
public class PlusPlusTest
{
private int count = 0;
public PlusPlusTest() {
for (int i = 1; i < 5; ++i) {
//count++; // This works
++count;// This fails
}
}
public static void main(String[] argv) {
PlusPlusTest ppt = new PlusPlusTest();
System.out.println("Test Key: " + new Integer(ppt.count).toString());
}
}
An attempt to compile results in:
-1 / -2
10: N/A putfield
0: 1 aload_0
1: 0 invokespecial
2: 1 aload_0
3: 0 invokespecial
4: 1 iconst_1
5: 0 istore_1
6: 0 goto
7: 1 aload_0
8: 2 iconst_1
9: 1 iadd
10: N/A putfield
11: N/A iinc
12: 1 iload_1
13: 2 iconst_5
14: 0 if_icmplt
15: N/A return
0: 1 aload_0
1: 0 invokespecial
2: 1 aload_0
3: 0 invokespecial
4: 1 iconst_1
5: 0 istore_1
6: 0 goto
7: 1 aload_0
8: 2 iconst_1
9: 1 iadd
10: N/A putfield
11: N/A iinc
12: 1 iload_1
13: 2 iconst_5
14: 0 if_icmplt
15: N/A return
0: 1 aload_0
1: 0 invokespecial
2: 1 aload_0
3: 0 invokespecial
4: 1 iconst_1
5: 0 istore_1
6: 0 goto
7: 1 aload_0
8: 2 iconst_1
9: 1 iadd
10: N/A putfield
11: N/A iinc
12: 1 iload_1
13: 2 iconst_5
14: 0 if_icmplt
15: N/A return
GenCode failure in source class: PlusPlusTest
at.dms.classfile.ClassFileFormatException: stack underflow
at
at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:122)
at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95)
at at.dms.classfile.JumpInstruction.check(JumpInstruction.java:147)
at
at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:133)
at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95)
at at.dms.classfile.JumpInstruction.check(JumpInstruction.java:147)
at
at.dms.classfile.InstructionHandle.checkInstruction(InstructionHandle.java:133)
at at.dms.classfile.CodeEnv.checkExecutionPath(CodeEnv.java:95)
at at.dms.classfile.CodeEnv.checkExecutionPaths(CodeEnv.java:73)
at at.dms.classfile.CodeEnv.check(CodeEnv.java:47)
at at.dms.classfile.CodeInfo.resolveConstants(CodeInfo.java:289)
at at.dms.classfile.AttributeList.resolveConstants(AttributeList.java:237)
at at.dms.classfile.MethodInfo.resolveConstants(MethodInfo.java:221)
at at.dms.classfile.ClassInfo.resolveConstants(ClassInfo.java:467)
at at.dms.classfile.ClassInfo.write(ClassInfo.java:360)
at at.dms.classfile.ClassInfo.write(ClassInfo.java:436)
at at.dms.kjc.CSourceClass.genCode(CSourceClass.java:235)
at at.dms.kjc.Main.genCode(Main.java:222)
at at.dms.kjc.Main.run(Main.java:174)
at at.dms.kjc.Main.compile(Main.java:68)
at at.dms.kjc.Main.main(Main.java:59)
error:stack underflow
This happens under both Kaffe and the Sun JVM, so seems to indicate a bug in the
actual KJC compiler code.
Under the new KJC (from their website), it works a bit better:
Administrator@BFULGHAM1 ~/java
$ javac PlusPlusTest.java
assertion "!INTS_DISABLED()" failed: file "exception.c", line 386
Aborted (core dumped)
I'm not sure which is worse -- however the second case indicates an issue with the JVM
so might be of more interest to us as time passes.
Thanks,
-Brent
Re: digest version
When Daniel Veillard gets back from a conference next week, I'm hoping that we can move the lists from his server to the new kaffe.org server. I'll probably use the mailman package to run the mailing list, and it has that option. Cheers, - Jim - Original Message - From: "Mark and Janice Juszczec" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 02, 2002 5:32 AM Subject: digest version > > > Hi folks > > Is there a digest delivery option? > > Mark > > > > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > >
digest version
Hi folks Is there a digest delivery option? Mark _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Re: Rewriting byte codes
On Mon, Apr 01, 2002 at 09:35:13AM +0200, Erik Corry wrote: > > On Sun, Mar 31, 2002 at 03:40:48PM -0800, Jim Pick wrote: >> >> Erik Corry wrote: >>> What would be needed at a minimum would >>> be: >>> >>> * Split local variables that can be either reference or non-reference >>> into two. (The alternative is to keep track of when they are what). >> >> What do the other VMs with non-conservative GC do? > > Hotspot splits them, but any VM needs to keep track of the stack. I just had a neat idea: Allocate on both sides of the local variable pointer. Then you can use negative offsets on instructions that use references and positive offsets on instructions that use nonreferences. All your references are collected on one side of the local variable pointer. You don't have to allocate twice as much space either if you compact the local variables, which is a simple single-pass operation which can never overflow the 256 or the 65536-variable boundaries. The 'local variable map' for an entire method is then just a count of reference local variables. (You have to allocate 64 bits per nonreference local variable though, otherwise it's not single pass, but that's probably a good idea anyway due to alignment issues). You can do something similar with the stack, but it's not quite as neat, since you would probably rather like a single pointer to the top-of-stack, and if you have separate reference and nonreference stacks you need two top-of-stack pointers :-( Also there are polymorphic bytecodes for the stack, like dup and swap, though they could perhaps be replaced by monomorphic versions. -- Erik Corry [EMAIL PROTECTED]
