Re: Comments on KAFFE GC
Sergio Ruocco wrote: Ivan Canales Cañas wrote: We're a pair of students at UPC (Univeristat Politècnica de Catalunya) that are working in garbage collection. Our goal is to improve a pair of gc's algorithms on kaffe. Nice. Please, let me/us know if you move towards "real-time" GC issues. By now, we're concentring our minds in the study of the actual gc. Do anyone have any documentation (notes, references, ..., o something like You can start from here: http://www.cs.ukc.ac.uk/people/staff/rej/gc.html ...and be sure to read: ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps Regards, Sergio -- __ Dr. Sergio Ruocco MsCS mailto:[EMAIL PROTECTED] Università Statale di Milano-Bicocca http://www.disco.unimib.it DISCo - Software Architecture Lab.http://www.sal.disco.unimib.it phone: ++39 02 6448 7851 cell: ++39 0347 2519828 Hello people, thanks Sergio for the bisurg.ps file. Really we are not decided in what schema we'll work, the idea is to implement one algorithm base in age an other based in time-quotted or 'real-time', and that will be there the user who choose one or the other. The age based has been decided, but the time-quotted based not, Are there anybody that know an algorithm like reference counting whith more or less execution cost and that it not has the cicle problem? Thanks in advise Ivan Canales. Marc Huguet.
Re: [Kaffe] whatever became of my Class.forName() patches?
Mo DeJong writes: I was just looking over the ChangeLog and I noticed that my Class.forName() patches never got added. I seem to remember that there was a problem with one of the changes in the patch. I am going to repost my patch minus the change that was causing problems and see if that is acceptable. Does anyone see any problems with the patch in its current form? I'm committing it now.. Quick question: it appears that kaffe accepts "Ljava/lang/String" even though you'd think a trailing semi-colon is required. Is this what JDK does as well (ie, semi-colon is optional at the end of a string)? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Picking apart JIT
Greetings everyone - I've recently been trying to pick apart the internal workings of Kaffe's JIT (to gain an understanding) and have been having a bit of trouble. My main question is this: which function (in which file) is the highest level in JIT? What is responsible for taking a block of bytecode and converting it to native? I also have a side question. Does Kaffe's JNI utilize JIT to eliminate marshalling? In other words, are the VM and the native call all in the same address space (collocated) ? -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org A witty saying proves nothing. -- Voltaire
Re: your mail
Yes, you can look at the software. All you need to do is get the kaffe "Current snapshot" from www.kaffe.org. The profiler is the JVM. It currenly only works for the i386 JIT system. Look in the config/i386/i386-jit3.def and kaffe/kaffevm/jit3/machine.c for the code. There is also a file in the FAQ that will answer some of the questions on how it works. -Will On Sat, 26 Feb 2000, William E. Cohen wrote: A student and I developed a profiler for Kaffe's JIT system for the x86. It should be in the current version of kaffe. It lists the number of times that each method is called and the accumlated time spent in each method. The instrumentation isn't perfect (it doesn't handle exception or threading), but it will give you some breakdown of the time spent. -Will Cohen Hello, thanks for your answer. Can'I have a look on your soft? I just want to compare the measure I've got with an soft I try to make Richard
Class.forName() patches
Mo,
I've applied the following patches -- which are a modification of yours,
and now four tests are failing:
FAIL: Bean.java
FAIL: BeanBug.java
FAIL: Reflect.java
FAIL: ReflectInvoke.java
Could be my changes but they should be equivalent to yours..
I think the problem may be that kaffe calls classFromSig()
on types that are part of a larger string (and not necessarily
at the end of the string) such as function types.. eg:
"(Ljava/lang/String;II)V"
Please let me know what you want me to do...
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Index: classMethod.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/classMethod.c,v
retrieving revision 1.75
diff -u -r1.75 classMethod.c
--- classMethod.c 2000/01/19 11:04:31 1.75
+++ classMethod.c 2000/02/29 19:10:24
@@ -2287,6 +2287,12 @@
/* Build signature for array type */
if (CLASS_IS_PRIMITIVE (c)) {
+ /* An array of type void is not allowed */
+ if (strcmp(CLASS_CNAME(c), "void") == 0) {
+ postExceptionMessage(einfo, JAVA_LANG(VerifyError),
+ "invalid array of type void");
+ return (0);
+ }
arr_class = CLASS_ARRAY_CACHE(c);
if (arr_class) {
return (arr_class);
Index: itypes.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/itypes.c,v
retrieving revision 1.17
diff -u -r1.17 itypes.c
--- itypes.c1999/11/29 23:44:10 1.17
+++ itypes.c2000/02/29 19:10:24
@@ -136,24 +136,59 @@
const char* start;
const char* end;
+ /* Check for primitive types */
+ switch (**strp) {
+ case 'V':
+ cl = voidClass;
+ break;
+ case 'I':
+ cl = intClass;
+ break;
+ case 'Z':
+ cl = booleanClass;
+ break;
+ case 'S':
+ cl = shortClass;
+ break;
+ case 'B':
+ cl = byteClass;
+ break;
+ case 'C':
+ cl = charClass;
+ break;
+ case 'F':
+ cl = floatClass;
+ break;
+ case 'D':
+ cl = doubleClass;
+ break;
+ case 'J':
+ cl = longClass;
+ break;
+ default:
+ cl = 0;
+ break;
+ }
+ if (cl != 0) {
+ if (*++(*strp) != '\0') {
+ postExceptionMessage(einfo, JAVA_LANG(VerifyError),
+ "extra garbage after primitive type in signature");
+ return (NULL);
+ }
+ return cl;
+ }
+
+ /* Check for non-primitive and array types */
switch (*(*strp)++) {
- case 'V': return (voidClass);
- case 'I': return (intClass);
- case 'Z': return (booleanClass);
- case 'S': return (shortClass);
- case 'B': return (byteClass);
- case 'C': return (charClass);
- case 'F': return (floatClass);
- case 'D': return (doubleClass);
- case 'J': return (longClass);
- case '[': return (lookupArray(classFromSig(strp, loader, einfo),
- einfo));
+ case '[':
+ return lookupArray(classFromSig(strp, loader, einfo), einfo);
+
case 'L':
start = *strp;
- for (end = start; *end != 0 *end != ';'; end++)
+ for (end = start; *end != '\0' *end != ';'; end++)
;
*strp = end;
- if (*end != 0) {
+ if (*end != '\0') {
(*strp)++;
}
utf8 = utf8ConstNew(start, end - start);
@@ -163,10 +198,17 @@
}
cl = loadClass(utf8, loader, einfo);
utf8ConstRelease(utf8);
+ if (cl != 0 CLASS_IS_PRIMITIVE(cl)) {
+ postExceptionMessage(einfo, JAVA_LANG(VerifyError),
+ "primitive type folllows `L' in signature");
+ cl = NULL;
+ }
return(cl);
+
default:
/* malformed signature */
- postException(einfo, JAVA_LANG(VerifyError));
+ postExceptionMessage(einfo, JAVA_LANG(VerifyError),
+ "malformed signature");
return (NULL);
}
}
Trampolines in the Kaffe JIT Compiler
On the Kaffe website, particularly in relation to porting Kaffe to new architectures, it states "that documentation would be welcome here." I have documented the trampoline system of the Kaffe JIT compiler in a document entitled "Trampolines in the Kaffe JIT Compiler." Please see the abstract below. I think this paper will help others who are porting Kaffe to rapidly learn this element of Kaffe's JIT compiler. Abstract: Trampolines are springboards for just-in-time (JIT) compilation. Every time a method is invoked, the caller looks in a dispatch table for the address of the method's native code. If the method has not been translated yet, the dispatch table entry points to the method's trampoline function. When invoked, the trampoline function invokes the translator for the method and fixes up the dispatch table to point to the newly-loaded native code. This paper explains how trampolines work and describes the requirements for implementing trampolines when porting Kaffe. Detailed case studies are given of how the trampoline systems in the SPARC and i386 architectures meet these requirements. The paper is found on my kaffe page in HTML format. http://www.cs.pdx.edu/~sanseri/kaffe/k2.html I would appreciate comments on this document. Please feel free to post a copy of this paper or a link to it on the Kaffe website. Hope it helps. Regards, Samuel Sanseri Computer Science Graduate Research Assistant Portland State University [EMAIL PROTECTED]
Re: Trampolines in the Kaffe JIT Compiler
That's great. I think Tim has someone redesign the kaffe.org website,
and I'm sure this could be included or at least linked to.
Only problem I have is that it describes the old, broken form of
trampolines. The fixed trampolines I put in last year take an additional
parameter for what I call the anchor of the trampoline ("w" or `where'.)
In general, please always date your paper and say to which versions of the
software you're describing the information applies.
- Godmar
On the Kaffe website, particularly in relation to porting Kaffe to new
architectures, it states "that documentation would be welcome here."
I have documented the trampoline system of the Kaffe JIT compiler in a
document entitled "Trampolines in the Kaffe JIT Compiler." Please see
the abstract below. I think this paper will help others who are porting
Kaffe to rapidly learn this element of Kaffe's JIT compiler.
Abstract: Trampolines are springboards for just-in-time (JIT) compilation.
Every time a method is invoked, the caller looks in a dispatch table for
the address of the method's native code. If the method has not been
translated yet, the dispatch table entry points to the method's trampoline
function. When invoked, the trampoline function invokes the translator for
the method and fixes up the dispatch table to point to the newly-loaded
native code. This paper explains how trampolines work and describes the
requirements for implementing trampolines when porting Kaffe. Detailed
case studies are given of how the trampoline systems in the SPARC and i386
architectures meet these requirements.
The paper is found on my kaffe page in HTML format.
http://www.cs.pdx.edu/~sanseri/kaffe/k2.html
I would appreciate comments on this document. Please feel free to post
a copy of this paper or a link to it on the Kaffe website. Hope it helps.
Regards,
Samuel Sanseri
Computer Science Graduate Research Assistant
Portland State University
[EMAIL PROTECTED]
Re: [Kaffe] whatever became of my Class.forName() patches?
On Tue, 29 Feb 2000, Archie Cobbs wrote:
Mo DeJong writes:
I was just looking over the ChangeLog and I noticed that my
Class.forName() patches never got added. I seem to remember
that there was a problem with one of the changes in the patch.
I am going to repost my patch minus the change that was
causing problems and see if that is acceptable. Does anyone
see any problems with the patch in its current form?
I'm committing it now..
Nice catch, that should generate an error too. I added a test case
for this to my forName tests and attached it to this email.
Like so right?
expect("[[Ljava.lang.String", "Exception"); // need ; at the end of class
name
Mo DeJong
Red Hat Inc
Quick question: it appears that kaffe accepts "Ljava/lang/String"
even though you'd think a trailing semi-colon is required.
Is this what JDK does as well (ie, semi-colon is optional at the
end of a string)?
-Archie
public class ArrayForName {
public static void testLoadArray() throws Exception {
// Loading by built-in type ID is not allowed
// int != I
// boolean != Z
// long != J
// float!= F
// double != D
// byte != B
// short!= S
// char != C
// void != V
expect("I", "Exception");
expect("Z", "Exception");
expect("J", "Exception");
expect("F", "Exception");
expect("D", "Exception");
expect("B", "Exception");
expect("S", "Exception");
expect("C", "Exception");
expect("V", "Exception");
// Not possible to load by builtin type name
expect("int", "Exception");
expect("boolean", "Exception");
expect("long","Exception");
expect("float", "Exception");
expect("double", "Exception");
expect("byte","Exception");
expect("short", "Exception");
expect("char","Exception");
expect("void","Exception");
// Test loading an array by built-in type id
// int[]== [I
// int[][] == [[I
// boolean[]== [Z
// boolean[][] == [[Z
// long[] == [J
// long[][] == [[J
// float[] == [F
// float[][]== [[F
// double[] == [D
// double[][] == [[D
// byte[] == [B
// byte[][] == [[B
// short[] == [S
// short[][]== [[S
// char[] == [C
// char[][] == [[C
expect("[I", "int[]");
expect("[[I", "int[][]");
expect("[Z", "boolean[]");
expect("[[Z", "boolean[][]");
expect("[J", "long[]");
expect("[[J", "long[][]");
expect("[F", "float[]");
expect("[[F", "float[][]");
expect("[D", "double[]");
expect("[[D", "double[][]");
expect("[B", "byte[]");
expect("[[B", "byte[][]");
expect("[S", "short[]");
expect("[[S", "short[][]");
expect("[C", "char[]");
expect("[[C", "char[][]");
// Array of type void is not allowed
expect("[V","Exception");
expect("[[V", "Exception");
expect("[[[V", "Exception");
// When loading an array using the built-in
// type id, id must be at end of string
expect("[II", "Exception");
expect("[ZZ", "Exception");
expect("[JJ", "Exception");
expect("[FF", "Exception");
expect("[DD", "Exception");
expect("[BB", "Exception");
expect("[SS", "Exception");
expect("[CC", "Exception");
expect("[ZZ", "Exception");
expect("[C;", "Exception");
expect("[C\0;", "Exception");
// [L + Class + ;
// Primitive Class name is not valid
expect("[Lint;", "Exception");
expect("[Lboolean;", "Exception");
expect("[Llong;","Exception");
expect("[Lfloat;", "Exception");
expect("[Ldouble;", "Exception");
expect("[Lbyte;","Exception");
expect("[Lshort;", "Exception");
expect("[Lchar;","Exception");
expect("[Lvoid;","Exception");
// java.lang.Object[] == [Ljava.lang.Object;
// java.lang.Object[][] == [[Ljava.lang.Object;
// java.lang.String[] == [Ljava.lang.String;
// java.lang.String[][] == [[Ljava.lang.String;
expect("[Ljava.lang.Object;", "java.lang.Object[]");
expect("[[Ljava.lang.Object;", "java.lang.Object[][]");
expect("[Ljava.lang.String;", "java.lang.String[]");
expect("[[Ljava.lang.String;", "java.lang.String[][]");
// L + Class must follow 0-N [ characters
expect("Ljava.lang.Object;",
Re: Class.forName() patches
On Tue, 29 Feb 2000, Archie Cobbs wrote: Mo, I've applied the following patches -- which are a modification of yours, and now four tests are failing: FAIL: Bean.java FAIL: BeanBug.java FAIL: Reflect.java FAIL: ReflectInvoke.java Ugh. Could be my changes but they should be equivalent to yours.. I think the problem may be that kaffe calls classFromSig() on types that are part of a larger string (and not necessarily at the end of the string) such as function types.. eg: Godmar emailed me to say that he was working on some improvements to my patch that would fix things once and for all. We should wait for his improved patches and add them instead of my original patch. I was unaware of this so I thought my original patch had been lost in the shuffle. Thanks Mo Dejong Red Hat Inc. "(Ljava/lang/String;II)V" Please let me know what you want me to do... -Archie
Re: [Kaffe] whatever became of my Class.forName() patches?
Mo DeJong writes:
Nice catch, that should generate an error too. I added a test case
for this to my forName tests and attached it to this email.
Like so right?
expect("[[Ljava.lang.String", "Exception"); // need ; at the end of class
name
OK, I've checked in ArrayForName.java as a new test (that currently
fails) and will wait for Godmar to fix it by checking in his changes
later...
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Re: Trampolines in the Kaffe JIT Compiler
Thanks for the feedback. I have added the last-update date and version
number of Kaffe to the document. This document was released today and
was intended to describe Kaffe release 1.0.5. I would like to make this
paper up-to-date, but I have not seen the anchor mentioned. Could you
give me a code location (and example architecture if this part of the
trampoline is architecture-dependent) for where to get started?
Also, I believe the case studies in the document are accurate at least to
the last release 1.0.5 of SPARC and i386. Does this mean that the code for
SPARC and i386 is broken, or am I misunderstanding something? If still
broken, how severe is this? Would it be worth fixing on SPARC and/or
i386? Thanks again.
Samuel
That's great. I think Tim has someone redesign the kaffe.org website,
and I'm sure this could be included or at least linked to.
Only problem I have is that it describes the old, broken form of
trampolines. The fixed trampolines I put in last year take an additional
parameter for what I call the anchor of the trampoline ("w" or `where'.)
In general, please always date your paper and say to which versions of the
software you're describing the information applies.
- Godmar
On the Kaffe website, particularly in relation to porting Kaffe to new
architectures, it states "that documentation would be welcome here."
I have documented the trampoline system of the Kaffe JIT compiler in a
document entitled "Trampolines in the Kaffe JIT Compiler." Please see
the abstract below. I think this paper will help others who are porting
Kaffe to rapidly learn this element of Kaffe's JIT compiler.
Abstract: Trampolines are springboards for just-in-time (JIT) compilation.
Every time a method is invoked, the caller looks in a dispatch table for
the address of the method's native code. If the method has not been
translated yet, the dispatch table entry points to the method's trampoline
function. When invoked, the trampoline function invokes the translator for
the method and fixes up the dispatch table to point to the newly-loaded
native code. This paper explains how trampolines work and describes the
requirements for implementing trampolines when porting Kaffe. Detailed
case studies are given of how the trampoline systems in the SPARC and i386
architectures meet these requirements.
The paper is found on my kaffe page in HTML format.
http://www.cs.pdx.edu/~sanseri/kaffe/k2.html
I would appreciate comments on this document. Please feel free to post
a copy of this paper or a link to it on the Kaffe website. Hope it helps.
Regards,
Samuel Sanseri
Computer Science Graduate Research Assistant
Portland State University
[EMAIL PROTECTED]
java.io.OutputStreamWriter: too small buffer
I posted this bug report through http://www.kaffe.org/cgi-bin/kaffe,
but it did not reach [EMAIL PROTECTED]
because kaffe.novare.net said "550 [EMAIL PROTECTED]
... Relaying denied."
I do not know whether this report was accepted by
the Kaffe Bug Tracking System, so I would like to send it to
this mailing list again.
From: [EMAIL PROTECTED]
Date: Tue, 29 Feb 2000 03:05:11 -0600
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: java.io.OutputStreamWriter: too small buffer
Full_Name: Ito Kazumitsu
Version: kaffe-1.0.5 (snap)
OS: Linux 2.0.38
Submission from: (NULL) (210.225.95.3)
The output buffer of java.io.OutputStreamWriter is too small to
safely run XT, the XSLT processor. The following error occurs
when processing a XML document containing Japanese characters:
## o = 1017 ## oe = 1024## o = 1020 ## oe = 1024## o = 1023
## oe = 1024java.lang.ArrayIndexOutOfBoundsException
at kaffe.io.CharToByteUTF8.convert(CharToByteUTF8.java:37)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:79)
at com.jclark.xsl.sax.HTMLOutputHandler.flushBuf(HTMLOutputHandler.java:721)
at com.jclark.xsl.sax.HTMLOutputHandler.endDocument(HTMLOutputHandler.java:732)
at com.jclark.xsl.sax.ResultBase.end(ResultBase.java:line unknown, pc
0x8390dc5)
at com.jclark.xsl.tr.SheetImpl.process(SheetImpl.java:line unknown, pc
0x83dccc7)
at com.jclark.xsl.sax.XSLProcessorImpl.parse(XSLProcessorImpl.java:line
unknown, pc 0x8394bc4)
at com.jclark.xsl.sax.Driver.transform(Driver.java:line unknown, pc
0x81f8c60)
at com.jclark.xsl.sax.Driver.transformFile(Driver.java:line unknown, pc
0x81f5517)
at com.jclark.xsl.sax.Driver.main(Driver.java:line unknown, pc
0x81e54c3)
where CharToByteUTF8.java is patched for debugging as follows:
==
$ diff -c ~/kaffe/kaffe-snap/libraries/javalib/kaffe/io/CharToByteUTF8.java
kaffe/io/CharToByteUTF8.java
*** /home/ito/kaffe/kaffe-snap/libraries/javalib/kaffe/io/CharToByteUTF8.java
Sun Oct 10 05:09:48 1999
--- kaffe/io/CharToByteUTF8.javaTue Feb 29 17:13:37 2000
***
*** 22,27
--- 22,29
int ie = fpos + flen;
for (; i ie o oe; i++) {
+ System.err.print("## o = " + o +"\t");
+ System.err.print("## oe = " + oe + "\t");
char chr = from[i];
if (chr = '\u0001' chr = '\u007F') {
to[o++] = (byte)chr;
==
And enlarging the buffer, that is, applying the following
patch to OutputStreamWriter.java helps solve this problem
although this is nothing but a workaround.
==
diff -c ~/kaffe/kaffe-snap/libraries/javalib/java/io/OutputStreamWriter.java
java/io/OutputStreamWriter.java
*** /home/ito/kaffe/kaffe-snap/libraries/javalib/java/io/OutputStreamWriter.javFri
Aug 13 10:56:01 1999
--- java/io/OutputStreamWriter.java Tue Feb 29 17:58:37 2000
***
*** 15,21
public class OutputStreamWriter
extends Writer
{
! private final static int BUFDEFAULT = 1024;
private final static int MINMARGIN = 32;
private OutputStream strm;
private CharToByteConverter encoding;
--- 15,22
public class OutputStreamWriter
extends Writer
{
! //private final static int BUFDEFAULT = 1024;
! private final static int BUFDEFAULT = 8*1024;
private final static int MINMARGIN = 32;
private OutputStream strm;
private CharToByteConverter encoding;
==
Re: Trampolines in the Kaffe JIT Compiler
Thanks for the feedback. I have added the last-update date and version number of Kaffe to the document. This document was released today and was intended to describe Kaffe release 1.0.5. I would like to make this paper up-to-date, but I have not seen the anchor mentioned. Could you give me a code location (and example architecture if this part of the trampoline is architecture-dependent) for where to get started? Also, I believe the case studies in the document are accurate at least to the last release 1.0.5 of SPARC and i386. Does this mean that the code for SPARC and i386 is broken, or am I misunderstanding something? If still broken, how severe is this? Would it be worth fixing on SPARC and/or i386? Thanks again. What's broken is 1.0b5. For the changes, see for instance: cvs diff -r1.70 -r1.73 classMethod.c They're labeled in the changelog as gcj related changes, but it's also a big bug fix/cleanup for trampolines. The main problem was that the old trampoline could have only one anchor. That is, once you jump thru it, there was only one position you could patch/update. As a result, if you had inherited methods to which two dtable entry referred, only one would get patched. The other would go through the trampoline every time. The solution is to create a trampoline for each location in which we store a pointer to the method in question. This also works nicely for the interface dispatch tables, btw. Anchor, btw, is my own lingo for the third, the "where" parameter in FILL_TRAMPOLINE. I think if you just look at the code, you'll see immediately what I mean. - Godmar
RE: Kaffe and Mozilla/OJI
Hi Dan, We agree that Kaffe and Mozilla are ready for this. Any development you can do towards that goal would be greatly appreciated. Although our in-house resources here at Transvirtual are stretched to the limit at present, please know that we will offer as much support as we can. Cheers, == [EMAIL PROTECTED] 800.828.3022 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan McGuirk Sent: Monday, February 28, 2000 3:53 PM To: [EMAIL PROTECTED] Subject: Kaffe and Mozilla/OJI Is anyone working on turning kaffe into a plugin that will work with Mozilla (using the OJI interface)? It seems to me that both kaffe and Mozilla are now in a state where this should be possible. Are there any technical or legal (license conflict, etc.) reasons why it would not be? If there are no major obstacles, I wouldn't mind putting some effort into getting this to work.
