Re: [kaffe] GC bug: gcFree: Assertion `!!!"Attempt to explicitly free nonfixed object"' failed
Daniel Bonniot <[EMAIL PROTECTED]> wrote: Hi Daniel, > Here is a reproducible GC bug with kaffe HEAD. It's a regression, as it does > not happen with 1.1.5. > > This happens when compiling two small programs with the Nice compiler's > testsuite. Therefore, you'll need the Nice compiler, precisely the nice.jar > file. I've reproduced with several versions, including 0.9.10 which is in > Debian at the moment. http://nice.sf.net/nice.jar should also do. thanks for the report and the instructions how to reproduce the bug. I've just committed a fix which makes the testsuite succeed. Does anybody remember other occurrences of this assertion failure? It may well happen that they are also solved now. Thanks, Helmer ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Lock patch
Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
Hi,
> I've just finished a functional patch for the locking system. I don't
> know yet how much slower it is. But I've already had some interesting
> results with some private app which was not working previously. If noone
> is against I will commit it on wednesday...
I like the idea of cleaning up the locking subsystem. I also think that
it's a good idea to keep the heavy locks in place after they have been
allocated, since needing a heavy lock because of recursive locking or
contention means that this will happen again in the future.
If I got it right, the new code always allocates a heavy lock even if
there's no contention or recursive locking. Since I think that locking
an object only once by a single thread is likely to happen (think about
methods like ResourceBundle.getBundle() or BufferedInputStream.available()
and synchronized blocks in a method), I'm tempted to suggest a way to
avoid allocating a heavy lock in this case:
void locks_internal_lockMutex(iLock** lkp, iLock *heavyLock)
{
if (!COMPARE_AND_EXCHANGE(lkp, LOCKFREE, KTHREAD(current)()))
slowLockMutex(lkp);
}
void locks_internal_unlockMutex(iLock** lkp)
{
if (!COMPARE_AND_EXCHANGE(lkp, KTHREAD(current)(), LOCKFREE))
slowLockMutex(lkp);
}
If nobody owns the lock, the jthread_t of the current thread is stored in
*lkp (afterwards called thin lock). If the same thread tries to lock the
mutex again, or another thread tries to do so, a heavy lock will be allocated.
Furthermore, getHeavyLock has to be modified as well:
#define IS_HEAVY_LOCK(ptr) (((ptr)&1)==1)
static iLock *getHeavyLock(iLock* volatile *lkp)
{
iLock* lk;
for (;;)
{
lk = *lkp;
if (!IS_HEAVY_LOCK(lk))
{
iLock* new = gc_malloc (sizeof(iLock), KGC_ALLOC_LOCK);
// initialize new
...
lk->in_progress = 0;
// preserve current state of lock
new->holder = lk;
if (lk != LOCKFREE)
new->lockCount = 1;
if (!COMPARE_AND_EXCHANGE(lkp, lk, new|1))
{
gc_free (lk);
continue;
}
}
// clear lowest bit so lk is the real pointer
lk &= ~1;
for (;;)
{
// wait until lk->in_progress is 0
}
return lk;
}
}
If *lkp does not point to a heavy lock, a new one is allocated on the heap.
To preserve the state of the lock when a thin lock is replaced by a heavy
lock, new->holder is initialized with the current value of lk, and lockCount
is set if necessary. Afterwards an attempt is made to install the heavy lock.
If that doesn't work (either because the lock was freed or because another
thread already installed a heavy lock), the heavy lock is freed and we start
again with checking whether *lkp is a heavy lock. Once we got a heavy lock,
we wait for the heavy lock to become usable by the current thread, just like
your code does.
What do you think of this?
Regards,
Helmer
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Character encoder/ClassLoader initialization
Guilhem Lavaux <[EMAIL PROTECTED]> wrote: Hey, > It seems that when we don't use iconv there are some problems in > initializing the EncodingManager. CharToByteConverter.getEncoder needs > ClassLoader.getSystemResource which needs ClassLoader.staticData. > However staticData is not yet initialized because getEncoder is called > while initializing ClassLoader.StaticData.systemClassLoader. Everything > goes to a NPE. > > The initialization loop can be broken either: > > * by removing the dependency on getSystemResource (but I bet it will be > difficult) > * by getting rid of AppClassLoader which is the source of the loop: it > uses URLClassLoader. Note that AppClassLoader did not extend URLClassLoader in the beginning. That was changed because some application wanted to call addURL on the SystemClassLoader (I don't remember which application that was, you'd have to search the archive for details). A third option might be to find out why I don't get the exception in my tree ;) If I undef HAVE_ICONV_H and HAVE_ICONV in CharToByteIconv.c and ByteToCharIconv.c I don't get any exceptions when trying to start kjc, I just see the usual messages from kjc when no input files are given. The only difference between my local tree and HEAD is the merged java.lang.Class implementation from GNU classpath. Regards, Helmer ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] merging java.lang.Class ?
Hi, after merging java.lang.Classloader, I tried merging java.lang.Class and got so far that kaffe passes most of the regression tests. The attached patch is not yet ready to go in (I still have to fix the reflection stuff and do some cleanup), but it is far enough to decide whether we want something like it or not. So far, I've simply changed the order of the fields of struct Hjava_lang_Class to match the order of the variables in classpath's java.lang.Class implementation. That way java.lang.Class and struct Hjava_lang_Class are still interchangeable and we don't have to change large parts of the core. The rest of the merging is just renaming some methods and adapting Kaffe_FindClass so kaffe is still able to find the application classes. Any thoughts? Regards, Helmer class.patch.gz Description: Binary data ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [gump] utf8const.c
Davanum Srinivas <[EMAIL PROTECTED]> wrote: > looks like we need a lock for locking access to utfLockRoot :( > I'd think that the whole utfLockRoot thing is broken (you'd need one utfLockRoot per thread since it's perfectly legal for two threads to work on utf8 constants at the same time). However, I think we could just remove the utfLockRoot thing completely, couldn't we? Even if one of the allocations in utf8const.c triggers a garbage collection, the thread holding the utf8Lock will be resumed before the finaliser starts to free unreachable objects (at least with kaffe-gc). This means that we don't have to drop the lock before doing an allocation, which renders utf8LockRoot useless. Or I just overlooked something ... Regards, Helmer ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Fixlets.
Kaffe CVS <[EMAIL PROTECTED]> wrote: Hi, > * kaffe/kaffevm/systems/unix-pthreads/syscalls.c > (jthreadedAccept): Use the old implementation using select all the > time. It looks like being the only really working way of handling > timeouts. have you checked whether this works with a 2.4.something linux kernel? I think I saw some problems with at least 2.4.18. Regards, Helmer ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Weak references/Class destruction
Guilhem Lavaux <[EMAIL PROTECTED]> wrote: Hi, > Here is a patch which changes the way the classes are destroyed and > implements > weak references for boehm-gc and kaffe-gc. This fixes class concurrent > destruction issues which was bugging boehm-gc (and maybe also kaffe-gc) and > should insure that we do not access already freed memory. If I remember it correctly, the problems with boehm-gc and garbage collecting classes are: a) Suppose class A is the only class implementing interface I. If A becomes unreachable, so does I. In this case however, there's no guarantee that C is destroyed before I. This means that destroyClass has to deal with the fact that I might already have been destroyed when C is destroyed. This gets complicated for the implementors table and the interface dispatch tables because destroyClass has to remove C from some of the structures stored inside I. b) Same thing when a class A and its super class A' become unreachable at the same time. In this case, some of the pointers stored in the vtable (and interface dispatch table) may no longer be valid because A' was already destroyed. The solution for a) is to use weak references. The solution for b) is to use allocation types that are automatically freed by the gc for everything that might be stored in a vtable (or interface dispatch table). Is this correct so far? Regards, Helmer ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] classloader merging
Guilhem Lavaux <[EMAIL PROTECTED]> wrote: Hi, > It looks fine to me. I've made some modifications to makefiles/classlist > so kjc is still able to bootstrap. So when you have committed your patch > I'll commit mine. I've just committed mine, hoping I didn't break too much stuff ;) Regards, Helmer ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] race during thread creation and gc invocation
Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > I think that we may skip the marking of thread and its internals but we > should continue to mark the stack of the thread. So I suggest we move > the call to TwalkThreads at the beginning of liveThreadWalker and do as > you have suggested. Ok, I've checked it in. BTW, what are your plans regarding the boehm-gc integration? I've stumbled across a function pointer called GC_push_other_roots which can be used by the application to push root references the gc can't know about. So it looks like we could use it to traverse the list of running threads using jthread_walkLiveThreads, just like kaffe-gc does. This in turn would mean that we could make boehm-gc use the jthread layer (provided that we find a way to trick boehm-gc into using jthread_suspendall). Have you had a look at this possibility? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (doogie): Various gcc and sparse fixes all over the board.
On Tue, 21 Dec 2004 00:11:20 -0800
Kaffe CVS <[EMAIL PROTECTED]> wrote:
Hi,
> @@ -66,7 +66,7 @@
>
> #if defined(HANDLE_MANIFEST_CLASSPATH)
> static int isEntryInClasspath(const char*);
> -static uint8* getManifestMainAttribute(jarFile*, char*);
> +static uint8* getManifestMainAttribute(jarFile*, const char*);
> static void handleManifestClassPath (classpathEntry *);
> #endif
>
> @@ -134,9 +134,8 @@
> case CP_DIR:
> case CP_ZIPFILE:
> class = newClass();
> - if (class == 0) {
> + if (class == NULL) {
> postOutOfMemory(einfo);
> - KFREE(hand.base);
> return (NULL);
> }
>
> @@ -144,14 +143,13 @@
> class->centry = centry;
> class = readClass(class, &hand, NULL, einfo);
>
> - if (hand.base != 0) {
> + if (hand.base != NULL) {
> #if defined(KAFFE_STATS)
> if (hand.type == CP_ZIPFILE) {
> addToCounter(&jarmem, "vmmem-jar files", 1,
> -(jlong)GCSIZEOF(hand.base));
> }
> #endif
> - KFREE(hand.base);
> }
> return (class);
I think the removal of these two KFREE calls will leak memory, won't it?
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] race during thread creation and gc invocation
On Sat, 11 Dec 2004 21:50:54 +0100 Alexander Boettcher <[EMAIL PROTECTED]> wrote: Hi Alexander, > i have a race condition in thread.c found which (may) causes Kaffe to > hang - for our L4 system it happens. [skipping lame excuses for not responding earlier] thanks for the detailed analysis :) I suspect that this may also be the cause for some of the regression test failures on smp systems. > So, jlThread can not be used in this form, a other pointer would be > necessary in the threadData structure or the gc may not assume that > jlThread is of type VMThread and has to handle it. > > What do you think ? Probably the easiest way would be to simply skip uninitialized threads in liveThreadWalker. To determine whether a thread is properly initialized, we can (ab)use threadData.jniEnv and define a thread as initialized iff threadData.jniEnv is not NULL. The attached patch does exactly that and seems to work on my i386. Could you probably give it a try? Thanks, Helmer Index: kaffe/kaffevm/kaffe-gc/gc-refs.c === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/kaffe-gc/gc-refs.c,v retrieving revision 1.7 diff -u -r1.7 gc-refs.c --- kaffe/kaffevm/kaffe-gc/gc-refs.c19 Dec 2004 06:41:29 - 1.7 +++ kaffe/kaffevm/kaffe-gc/gc-refs.c20 Dec 2004 11:13:37 - @@ -156,6 +156,12 @@ threadData *thread_data = KTHREAD(get_data)(tid); Hjava_lang_VMThread *thread = (Hjava_lang_VMThread *)thread_data->jlThread; + /* if the gc is invoked while a new thread is being + * initialized, we better skip that thread. + */ + if (!THREAD_DATA_INITIALIZED(thread_data)) +return; + KGC_markObject(c, NULL, unhand(thread)->thread); KGC_markObject(c, NULL, thread); Index: kaffe/kaffevm/threadData.h === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/threadData.h,v retrieving revision 1.4 diff -u -r1.4 threadData.h --- kaffe/kaffevm/threadData.h 7 Jul 2004 16:05:13 - 1.4 +++ kaffe/kaffevm/threadData.h 20 Dec 2004 11:13:37 - @@ -38,4 +38,6 @@ int needOnStack; } threadData; +#define THREAD_DATA_INITIALIZED(td) ((td)->jniEnv != NULL) + #endif ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: Trouble running Eclipse 3.0.1 with recent Kaffe snapshot
On Sat, 18 Dec 2004 12:47:46 +0100 Haakon Nilsen <[EMAIL PROTECTED]> wrote: Hi, > !MESSAGE Save Failed > !STACK 0 > java.lang.IllegalAccessError: .fElement >at > org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider$2.getSchedulingRule > (CompilationUnitDocumentProvider.java:957) >at org.eclipse.ui.internal.editors.text.WorkspaceOperationRunner.run > (WorkspaceOperationRunner.java:63) >at org.eclipse.ui.editors.text.TextFileDocumentProvider.executeOperation > (TextFileDocumentProvider.java:440) >at org.eclipse.ui.editors.text.TextFileDocumentProvider.saveDocument > (TextFileDocumentProvider.java:699) >at org.eclipse.ui.texteditor.AbstractTextEditor.performSave > (AbstractTextEditor.java:3536) > ... > > The code completion feature also does not work, but no exceptions either. > The addictive QuickFix feature was also missing for some reason, and when > trying to run a JUnit test, I was told it couldn't find any. I'll have a look at this one first. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] classloader merging
Hi, after passing my last two exams in electrical engineering last week I finally had the time to look at merging the class loader implementation from classpath again (sorry for vanishing again). The attached patch is an updated version (using classpath's cvs from this morning) and also addresses the problem with native libraries. Here's a short summary of the changes: * According to [1], the vm should throw an UnsatisfiedLinkError when a library is to be loaded by two different class loaders. I therefore modified external.c so it keeps track of which class loader is associated with a native library. This also enables us to remove the libraries associated with a class loader when it is finalized. * I've removed java.lang.NativeLibrary and moved all code dealing with native libraries (including code from java.lang.System) into java.lang.Runtime. Moving code from java.lang.System has the advantage that it is another step towards merging java.lang.System from classpath. * I've kept kaffe.lang.PrimordialClassLoader for the moment, but I think we should remove it later on. I hope I didn't forget any files in the patch and would appreciate it if someone could give some feedback about it. If nobody objects, I'll commit it next week. Regards, Helmer [1] http://java.sun.com/docs/books/jni/html/design.html classloader-patch.gz Description: Binary data ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (robilad): Resynced with GNU Classpath: ResourceBundle updated and remerged with Classpath
On Sat, 27 Nov 2004 12:26:06 -0800
Kaffe CVS <[EMAIL PROTECTED]> wrote:
> PatchSet 5496
> Date: 2004/11/27 20:21:42
> Author: robilad
> Branch: HEAD
> Tag: (none)
> Log:
> Resynced with GNU Classpath: ResourceBundle updated and remerged with
> Classpath
>
> 2004-11-27 Dalibor Topic <[EMAIL PROTECTED]>
>
> * libraries/javalib/java/util/ResourceBundle.java:
> Resynced with GNU Classpath. Reverted Helmer's changes from
> 2004-07-11 as they break mauve tests for
> java.util.logging.Logger.
Looks like these tests fail because java.util.logging.Logger doesn't
load the ResourceBundle using the context class loader of the current
thread (as the jdk does, as evidenced by the attached test).
Regards,
Helmer
import java.net.URL;
import java.io.InputStream;
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.util.logging.Logger;
public class BundleLoader extends ClassLoader
{
/*
* assume ResourceBundle calls getResourceAsStream.
*/
public InputStream getResourceAsStream (String name)
{
if (name.equals ("TestBundle.properties"))
{
return new ByteArrayInputStream (new byte[0]);
}
return null;
}
public static void main (String[] args)
{
Thread.currentThread().setContextClassLoader (new BundleLoader ());
try
{
System.out.println (Logger.getLogger ("test", "TestBundle"));
}
catch (Exception _) { _.printStackTrace (); }
}
}
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Turn exception into warning message for ClassLoader.setSigners()
On Sat, 13 Nov 2004 22:01:55 +0100 Mark Wielaard <[EMAIL PROTECTED]> wrote: Hi, > With this Eclipse 2.1 starts again, but is not completely usable, while > printing lots of warning messages... (an alternative would be to > actually implement setSigners() by adopting the GNU Classpath > ClassLoader implementation). I'll have a look at what needs to be shuffled around to use GNU Classpath's ClassLoader implementation. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: kaffe on morphos
On Fri, 05 Nov 1999 12:37:07 + Michael Grunditz <[EMAIL PROTECTED]> wrote: > Hello Helmer > > On 11/03/04, you wrote: > > > On Fri, 29 Oct 2004 19:45:50 + > > Michael Grunditz <[EMAIL PROTECTED]> wrote: > > > >> Hi > >> > >> I have compiled latest kaffe on MorphOS. When I run "java" on a class I > >> get the folowing: > >> > >> Couldn't find or load essential class `java/lang/Class' > >> java.lang.ClassFormatError unknown class file truncated > >> Abort trap > >> > >> > >> any clues ? > > > > Does "latest kaffe" mean cvs HEAD? > > What compiler do you use? > > What options did you pass to configure? > System:MOS_SDK/DevEnv/usr/local/kaffe-1.1.4/kaffe/kaffeh> gcc -v > Reading specs from /gg/lib/gcc-lib/ppc-morphos/2.95.3/specs > gcc version 2.95.3 20020615 (experimental/emm) > System:MOS_SDK/DevEnv/usr/local/kaffe-1.1.4/kaffe/kaffeh> > > latest release 1.1.4 [ would it be possible to give cvs HEAD a try ? ] > configure options: > ./configure --without-alsa --without-esd --enable-pure-java-math > --disable-sound --with-awt=no java.lang.Class is the fourth class that kaffe tries to load (see kaffe/kaffevm/baseClasses.c#initBaseClasses). Loading a class means searching it in the classpath (in findInJar.c), reading its data from the .jar file (in jar.c) and finally parsing the .class file (in readClass.c / constants.c). The above error message means that kaffe was parsing the .class file but could not finish because the file did not contain enough data. To get some debug messages during this process, you can pass the option '-vmdebug READCLASS,CLASSLOOKUP' to kaffe. One possible reason for such an error is a (partially) damaged rt.jar. You can check this by extracting rt.jar and running developers/dumpClass.pl on some of the .class files (like java/lang/Class.class). If that works, you could try to prepend the directory where you extracted rt.jar to kaffe's bootclasspath (using the -Xbootclasspath/p: option). Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Why does Kaffe's register allocator spill slots in theboundary of basic blocks?
On Thu, 4 Nov 2004 01:44:37 +0800 "Bytecode" <[EMAIL PROTECTED]> wrote: > > On Thu, 4 Nov 2004 00:16:20 +0800 > "Bytecode" <[EMAIL PROTECTED]> wrote: > > > > > I'm optimizing the register allocation mechod in kaffe. > > I find that the current register allocator spills "dirty" slots in the > > exit of each basic block by calling function endBlock(). Why? > > Kaffe's register allocator (the one in jit3) does only do global register > allocation for a limited number of local variables. To ensure that > subsequent code can access the elements of the operand stack that are still > valid at the end of a basic block, their slots have to be spilled. Same > thing for local variables that were not assigned a global register. > > - > Now that the elements of the stack are in the registers, we can use the > registers for latter operations directly. There is no need to spii them. > In the entry of each basic block the function startBlock() will invalidate > the relation between all slots and registers. I cannot understand it . If a basic block B has more than one predecessor, you have to make sure that B can access the elements of the operand stack no matter what predecessor was executed before B. jit3 does this by spilling the registers whenever a basic block is left. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ARM Double problems
On Fri, 5 Nov 2004 12:03:13 +0200 (EET) Jari Korva <[EMAIL PROTECTED]> wrote: Hi, > I observed some floating point problems on double data type on my armv5b > box (float works just fine though). The problem seems to be a > double/floating point endianness issue. > > For example this code: System.out.println(0.2); > Outputs: -2.3534382788928255E-185 > > I looked at the problem more carefully and found out that on a C-program > (compiled with -Wlong-long -fsigned-char) 0.2 is stored as follows: > > 3fffc9ff99ff99ff99ff99ff99ff9a > > While it looks like this on Kaffe/intrp > (printed from java_lang_Float_toStringWithPrecision): > > ff99ff99ff99ff9a3fffc9ff99ff99 > > Is this possibly the same/similar problem with floating point formats, > that I observed previously on gcj on armvl5: http://gcc.gnu.org/PR16132 ? config/config-hacks.h defines a macro DOUBLE_ORDER_OPPOSITE which tells kaffe that the word order of doubles is different from the word order of jlongs (it's used in kaffe/kaffevm/fp.c). At the moment this macro is always defined when compiling kaffe for arm. Could you try whether the double problems are solved when this macro is not defined? If so, we should work out some preprocessor or configure magic to detect whether that macro is necessary. Thanks, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Why does Kaffe's register allocator spill slots in the boundary of basic blocks?
On Thu, 4 Nov 2004 00:16:20 +0800 "Bytecode" <[EMAIL PROTECTED]> wrote: > > I'm optimizing the register allocation mechod in kaffe. > I find that the current register allocator spills "dirty" slots in the exit > of each basic block by calling function endBlock(). Why? Kaffe's register allocator (the one in jit3) does only do global register allocation for a limited number of local variables. To ensure that subsequent code can access the elements of the operand stack that are still valid at the end of a basic block, their slots have to be spilled. Same thing for local variables that were not assigned a global register. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe on morphos
On Fri, 29 Oct 2004 19:45:50 + Michael Grunditz <[EMAIL PROTECTED]> wrote: > Hi > > I have compiled latest kaffe on MorphOS. When I run "java" on a class I get > the folowing: > > Couldn't find or load essential class `java/lang/Class' > java.lang.ClassFormatError unknown class file truncated > Abort trap > > > any clues ? Does "latest kaffe" mean cvs HEAD? What compiler do you use? What options did you pass to configure? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe fails to build on ppc with gcc-3.4
On Tue, 02 Nov 2004 14:49:43 +0100 Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > Hi all, > > Here is the build log that fails when trying to build kaffe on ppc with > gcc-3.4 Could you try without the --with-libffi option (kaffe should work on ppc without libffi). Meanwhile, I'll have a look at what is going wrong with libffi on ppc. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (hkraemer): moved handling of thread interruption
On Sun, 31 Oct 2004 08:47:50 -0700 (MST) Timothy Stack <[EMAIL PROTECTED]> wrote: > > > moved handling of thread interruption to jthread layer, > > So, I haven't been paying close attention... But, didn't interruption > used to be in the jthread layer, and then someone moved it up to the java > layer. Why move it back down? The previous code had an interrupted flag in the jthread layer and one in the java layer and I figured it would be a bit cleaner to have just one flag at the jthread layer. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] assert split patch and results
On Mon, 25 Oct 2004 10:29:53 + (UTC) Riccardo <[EMAIL PROTECTED]> wrote: Hi, > now the result is > gmake[6]: Entering directory `/home/multix/kaffe-cvs/netbsd-intrp- > jthread/test/regression' > PASS: HelloWorldApp.class.save > error compiling: > assertion "size != 0" failed: file "../../../../kaffe/kaffe/kaffevm/ > kaffe-gc/gc-incremental.c", line 1037, function "gcMalloc" > TestScript: line 1: 9531 Abort trap (core dumped) /home/ > multix/kaf Could you probably try whether the attached patch fixes something? Thanks, Helmer Index: config/powerpc/common.h === RCS file: /cvs/kaffe/kaffe/config/powerpc/common.h,v retrieving revision 1.7 diff -u -r1.7 common.h --- config/powerpc/common.h 23 Jul 2004 16:50:50 - 1.7 +++ config/powerpc/common.h 25 Oct 2004 11:24:05 - @@ -18,6 +18,12 @@ #define NEED_STACK_ALIGN #define STACK_ALIGN(p) unsigned long)(p)) & 15) ^ (unsigned long)(p)) +/* This define will cause callMethodV and callMethodA to avoid + introducing unused slots after jlongs and jdoubles. */ +#ifndef NO_HOLES +# define NO_HOLES 1 +#endif + #if defined(NEED_sysdepCallMethod) #include "sysdepCallMethod.h" #endif /* defined(NEED_sysdepCallMethod) */ Index: config/powerpc/sysdepCallMethod.h === RCS file: /cvs/kaffe/kaffe/config/powerpc/sysdepCallMethod.h,v retrieving revision 1.5 diff -u -r1.5 sysdepCallMethod.h --- config/powerpc/sysdepCallMethod.h 21 Aug 2004 16:32:43 - 1.5 +++ config/powerpc/sysdepCallMethod.h 25 Oct 2004 11:24:05 - @@ -16,13 +16,6 @@ /* Needed for callMethodInfo declaration */ #include "support.h" -/* This define will cause callMethodV and callMethodA to avoid - introducing unused slots after jlongs and jdoubles. */ -#ifndef NO_HOLES -# define NO_HOLES 1 -#endif - - /* ARG_TYPE is the type of a register used for passing arguments. */ #define ARG_TYPE long ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] x86_64 - Status?
On Wed, 20 Oct 2004 19:46:32 -0700 Eric Anholt <[EMAIL PROTECTED]> wrote: > On Wed, 2004-10-20 at 18:53, Michael Franz wrote: > > What is the status of the x86_64 version of Kaffe? I am running SuSE > > 9.1 on an Athlon 64 and finding that it fails 134 of 144 tests. > > > > How does the x86_64 compare with what Eric Anholt just posted about? > > Is x86_64 not for Athlon 64? > > x86_64 was the old name for amd64. So, yeah, that's what you've got. > > When I emailed, I had only tested with two of my very trivial classes, > and after trying one of my other very trivial classes I got a segfault. > I've tried looking for other warnings along the lines of the > kaffe-methodcalls-external.diff one, but didn't find anything > spectacular. I've got a couple non-critical warning cleanups so far. > Actually, I was concerned about jni.c's DefineClass args not matching > the definition from include/jni.h, but I didn't track down if it > mattered or not. > > Right now I'm running a make check. When that finishes, I'll back out > my backout of dalibor's change that he brought up on IRC as being > questionable, and see how that changes regression output (I expect > unfavorably). You may also want to move the NO_HOLES and PROMOTE_ macros from sysdepCallMethod.h to common.h (these macros are used in support.c, but support.c no longer defines the macros to trigger inclusion of sysdepCallMethod.h). If these are not properly defined, passing arguments to native methods will only work for some types. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe on XScale
On Tue, 12 Oct 2004 11:00:10 +0300 (EEST) Jari Korva <[EMAIL PROTECTED]> wrote: > Hi, > > there was an additional f0 lurking (see below). Because my Assembly is > pretty bad, I just removed it blindly - but it made Kaffe to compile! > > The resulting Kaffe does not quite work though (throws an NPE in > System.initProperties, see bottom of this message). I've just commited a fix so that System.initProperties doesn't crash when setlocale returns NULL. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe on XScale
On Wed, 6 Oct 2004 12:55:19 +0200
Thomas Winkler <[EMAIL PROTECTED]> wrote:
Hi,
> I'm currently trying to compile kaffe for the the intel XScale (ARM, Big
> Endian).
> I tried kaffe 1.1.4 as well as kaffe CVS HEAD (20041006). But I've run into
> problems I could not manage to resolve on my own and I hope that somebody on
> the list is able to help me.
>
> build environment:
> binutils-2.15
> gcc-3.4.0
> glibc-2.3.2
could you probably try whether the attached patch (against CVS HEAD)
makes any difference? GCC might be crashing because kaffe makes use
of fp registers, but your gcc was configured for soft float
BTW, has anybody used libffi on arm for functions that return 64bit
values?
Regards,
Helmer
Index: config/arm/sysdepCallMethod.h
===
RCS file: /cvs/kaffe/kaffe/config/arm/sysdepCallMethod.h,v
retrieving revision 1.5
diff -u -r1.5 sysdepCallMethod.h
--- config/arm/sysdepCallMethod.h 28 Jun 2004 19:05:20 - 1.5
+++ config/arm/sysdepCallMethod.h 9 Oct 2004 12:54:14 -
@@ -39,7 +39,9 @@
register int r1 asm("r1");
register int r2 asm("r2");
register int r3 asm("r3");
+#ifndef __SOFTFP__
register double f0 asm("f0");
+#endif
default:
{
@@ -70,11 +72,20 @@
break;
case 'D':
+#ifdef __SOFTFP__
+ (&call->ret->i)[1] = r1;
+ (&call->ret->i)[0] = r0;
+#else
call->ret->d = (double) f0;
+#endif
break;
case 'F':
+#ifdef __SOFTFP__
+ call->ret->i = r0;
+#else
call->ret->f = (float) f0;
+#endif
break;
case 'J':
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: kjc on m68k/netbsd works.
On Tue, 24 Aug 2004 22:15:38 +0900 (JST) Kiyo Inaba <[EMAIL PROTECTED]> wrote: Hey Kiyo, > In the current implementation, it looks to adjust SP in eprologue. > In eprologue, it first calculate frame size by 'op_addal_ia', with > a label associated with this instruction, based on current FP (the > value for FP is adjusted by caller of eprologue), and then it escapes > register set save area for NEXT method (the method which calls the > method where we are now talking about) by using 'op_subaw_ia'. > > As I said, it is too hard to detect how many registers are used, > and constant SRNR (which is defined as 10 in jit.h) is used to > keep the area for next method. > > If I commented out this 'op_subaw_ia' and trace the behavior of > kjc, I noticed 'a2' register value is changed when it was returned > from 'tryBundle' method of kjc. IMHO, it is not correct to comment out the op_subaw_ia in eprologue. AFAIK, the layout of the stack is something like this (inside a method, but not inside an exception handler): || fp -> || | local variables, | | operand stack| |and temps | || | saved registers | sp -> || || If the op_subaw_ia is commented out, the sp will point above the register save area and instructions like pusharg_x will overwrite the values of saved registers, since they're relative to sp. > I am so sure that, at one time, even with this adjustment, kjc does > not work, and I guess some other fix (maybe done by Helmer) also > contributes to this problem. Do you have any idea what might go wrong in that case? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Forcing sysdepcallmethod (Was: Re: [kaffe] armv5b regression tests)
On Mon, 23 Aug 2004 18:18:54 +0200 Dalibor Topic <[EMAIL PROTECTED]> wrote: > Jari Korva wrote: > > > Third, I'm no longer able to compile cvs head for armv5b. > > kaffe/kaffevm/intrp/methodcalls.c forces sysdepCallMethod, which causes an > > ICE. > > Thanks for spotting that one. Helmer, any idea why methodcall.c forces > the use of kaffe's sysdepcallmethod? Yes, because I broke it Fixing it at the moment. Sorry, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] trampoline handling
On Sun, 08 Aug 2004 11:01:49 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > Helmer Krämer wrote: > > >Hi, > > > > > > Hi Helmer, > > >the attached patch moves the handling of trampolines and method > >calls into engine-specific files, thereby further cleaning up > >the core vm: > > > > > > Great ! :) > The patch and the new behaviour looks fine to me. Glad to read that :) I've also fixed the MethodErrors failure now, so the intrp passes all regression tests when the stack size is increased somewhat. > I like especially the engine_callMethod. This will potentially enable us > to mix jitted and interpreted code by chosing the right callMethod > depending on Method (but that's just an idea). I'm currently thinking about another backend (like intrp_jit) that would transform the bytecode into another intermediate form that can be efficiently interpreted (for suitable definitions of "efficient"), but is also easily translated into assembly. Exactly when a method is translated into assembly would be decided by some sort of heuristics and the structure of the method body. I don't know whether an approach like this makes any sense, but it will take some time, which makes it a perfect hobby ;) > I had written for my engine separation patch a small amount of code to > remove the ifdef in soft.c concerning soft_multianewarray. This uses > sysdepCallMethod that I have chosen at that time to move into its own > include file. Here is the code: > > The code is naturally for the intrp... I'll write a patch if I have some > time. Yeah, it's probably best to move the soft_multianewarray out of soft.c, since every engine seems to have it's own version anyways?!?? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] trampoline handling
Hi, the attached patch moves the handling of trampolines and method calls into engine-specific files, thereby further cleaning up the core vm: Each engine provides a header file called methodcalls, which contains the functions to create trampolines and to call a java method. The former is used solely by classMethod.c, the latter solely by support.c. external.c has been modified not to use the errorstub function whenever the native implementation of a method cannot be found in the libraries. I think this is more correct, since someone might try to invoke a method before and after loading the lib containing the native implementation of it, and using errorstub would mean that invocations would not succeed after the lib had beed loaded. Wrappers for the native implementation are no longer created automagically when invoking native(). Instead, a pointer to the native implementation (or NULL) is returned, which is then processed by the engine. Open Issues: More or less work in progress. The interpreter currently fails some of the regression tests: PropertiesTest fails with a StackOverflowError during compilation, no clue whether that's caused by my patch. MethodErrors fails with a NullPointerException, will have a closer look later today. Still more ifdefs and unnecessary includes of header files left. Comments / flames / whatever as always welcome. Regards, Helmer trampoline.patch.gz Description: Binary data ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] jit3 move_register
Hi,
while having a closer look at the jit3 engine to find out what
broke the m68k backend, I also noticed a few other things that
might help e.g. mipsel.
First of all, move_register() seems to pass wrong values to the
backend's HAVE_move_register_foo:
#if defined(HAVE_move_register_int)
if (reginfo[toreg].type & (Rint|Rsubint)) {
HAVE_move_register_int(toreg, fromreg);
return (1);
}
else
#endif
The values passed to the HAVE_move_register_foo are the indices
for the reginfo array. However, I think it would be correct to
pass the regno field of the register instead:
...
HAVE_move_register_int(reginfo[toreg].regno, reginfo[fromreg].regno);
...
Since these are the same values that are returned by slotRegister().
With the attached patch applied, it should be possible to add a
HAVE_move_register_float to the mipsel backend, which in turn might
save a few spills when allocating a floating point register.
Comments?
Regards,
Helmer
Index: kaffe/kaffevm/jit3/registers.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/jit3/registers.c,v
retrieving revision 1.15
diff -u -r1.15 registers.c
--- kaffe/kaffevm/jit3/registers.c 6 Jul 2004 15:57:15 - 1.15
+++ kaffe/kaffevm/jit3/registers.c 29 Jul 2004 11:55:30 -
@@ -42,7 +42,7 @@
*/
kregs reginfo[] = {
REGISTER_SET
- { /* BAD */ 0, 0, 0, 0, 0, 0 }
+ { /* BAD */ 0, 0, 0, 0, 0, 0, 0 }
};
/**
@@ -210,35 +210,35 @@
{
#if defined(HAVE_move_register_long)
if (reginfo[toreg].type & Rlong) {
- HAVE_move_register_long(toreg, fromreg);
+ HAVE_move_register_long(reginfo[toreg].regno, reginfo[fromreg].regno);
return (1);
}
else
#endif
#if defined(HAVE_move_register_int)
if (reginfo[toreg].type & (Rint|Rsubint)) {
- HAVE_move_register_int(toreg, fromreg);
+ HAVE_move_register_int(reginfo[toreg].regno, reginfo[fromreg].regno);
return (1);
}
else
#endif
#if defined(HAVE_move_register_ref)
if (reginfo[toreg].type & Rref) {
- HAVE_move_register_ref(toreg, fromreg);
+ HAVE_move_register_ref(reginfo[toreg].regno, reginfo[fromreg].regno);
return (1);
}
else
#endif
#if defined(HAVE_move_register_double)
if (reginfo[toreg].type & Rdouble) {
- HAVE_move_register_double(toreg, fromreg);
+ HAVE_move_register_double(reginfo[toreg].regno,
reginfo[fromreg].regno);
return (1);
}
else
#endif
#if defined(HAVE_move_register_float)
if (reginfo[toreg].type & Rfloat) {
- HAVE_move_register_float(toreg, fromreg);
+ HAVE_move_register_float(reginfo[toreg].regno, reginfo[fromreg].regno);
return (1);
}
else
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [bug] Method delegation error with superinterfaces
Benja Fallenstein <[EMAIL PROTECTED]> wrote: Hi again, > Helmer Krämer wrote: > >>The following bug is triggered by the combination of Jikes 1.21 with the > >>current version of Kaffe from CVS. It is not triggered by Jikes + > >>sunjava or by sunjavac + Kaffe... > > > > what jdk version do you use? > > Heh, this had me puzzled for a moment, I was going to say "why, Kaffe, > the newest version from CVS" ;-) > > The sunjava/sunjavac mentioned are from Sun's j2sdk1.4.2_04. > > >>Not sure whether this should be seen as a bug in Kaffe or Jikes -- but > >>since Kaffe aims to run programs that work on Sun's JDK, I guess this > >>should be fixed. I don't understand Kaffe well enough to do it, though. > > > > No problem, will have a look at this. > > Thanks! I've just checked in a fix. Your test case as well as eclipse work, so I think I didn't screw up anything. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: jit3 expert wanted! (again)
On Fri, 23 Jul 2004 17:49:06 +0900 (JST) Kiyo Inaba <[EMAIL PROTECTED]> wrote: Hi again, > And again, the two move instructions at 0x293478 and 0x29347c destroy > the attempt made at 0x293476... > > I think similar modification what Helmer showed may solve this problem, > but I can not figure out where exactly I have to modify. after some more thinking about this, I think we can remove the entire if(), as is done in the attached patch: Before generating code for a bytecode instruction, we check whether or not an exception raised during the execution of that instruction can be caught. Therefore, we can determine the necessary spills (e.g. when invoking a method or before a throw statement) in icode.c and generate them there. Since icode.c already contains the necessary code for this, we can savely remove the if(), since the spills generated in the if are already generated by icode.c. With this patch applied, kaffe still passes the general regression tests as well as the jit specific tests (with some additional tests from myself), so it can't be that bad. No I'm only hoping that this fixes the m68k backend Regards, Helmer jit3.patch Description: Binary data ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Threads & Boehm GC
On Sat, 24 Jul 2004 11:59:40 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > Helmer Krämer wrote: > > >On Sat, 24 Jul 2004 09:38:08 +0200 > >Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > > > >Hi, > > > > > > > >>It seems that the Boehm-GC needs to catch a number of pthread calls. > >>This is not evident to implement in kaffe but I think I can do the > >>following: > >>[...] > >>Any comments ? > >> > >> > > > >why does the gc_pthread_redirects.h thing from boehm not > >work? I mean if kaffevm/gc.h included a header file called > >"gc-impl.h" from kaffevm/kaffe-gc or kaffevm/boehm-gc and > >unix-pthreads/thread-impl.c included kaffevm/gc.h (and thus > >boehm-gc/gc-impl.h), it should work, shouldn't it? > > > > > > > Yes, but I'd like not to have to include any boehm specific includes in > pthreads. > If I do this, the unix-pthreads will be stuck with the boehm-gc once it > is compiled. > > If we want to have a '-Xkaffe-gc' to switch to the standard GC we may > not be able to do so if we chose this way. Note that there will be a lot more problems if we wanted to implement such an option. For example, if you wanted to be able to switch between an incremental and a conservative GC you would have to modify the vm itself so it properly tells the gc whenever a pointer is written (or accept a huge overhead). Therefore, I'd rather select boehm or kaffe at compile time and have -X options only for options specific to the selected implementation. Just because it will be easier. Why would one have to switch between kaffe and boehm at runtime, anyways? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] m68k jit3 (was: jit3 expert wanted!)
On Fri, 23 Jul 2004 10:00:49 +0900 (JST)
Kiyo Inaba <[EMAIL PROTECTED]> wrote:
Hi,
sorry for not replying earlier, I had an exam on Friday.
> I made a patch file to solve some problem on m68k jit3. In this patch
> you can find two modifications. The first one is suggested by Helmer
> not to emit code for spilling unneeded registers. The second one is
> to comment out a function which emits unimplemented code. (Usually,
> 68k machine instruction is so orthogonal, but cmpi inst can not accept
> address registers...)
>
> Even with this patch applied, m68k/netbsd/jit3 does not work properly,
> but now it compiles 396 methods out of 403 needed for HelloWorldApp.
> It is a big improvement compared with 98 methods compiled without this
> patch.
So we're making some progress :)
Do all of the methods that are not compiled correctly contain
exception handlers (or synchronized(foo){} blocks)?
I'm currently trying to figure out what goes wrong in your
second example
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (dalibor): Fixed turning off native AWT backends
On Fri, 23 Jul 2004 19:18:34 -0700 Kaffe CVS <[EMAIL PROTECTED]> wrote: > PatchSet 5005 > Date: 2004/07/24 01:43:27 > Author: dalibor > Branch: HEAD > Tag: (none) > Log: > Fixed turning off native AWT backends > > 2004-07-24 Dalibor Topic <[EMAIL PROTECTED]> > > Fixed disabling of native AWT code. > > * Makefile.am (DIRECTORIES_AFTER_RTJAR): Added explicit support > for AWT directories to ensure that disabling of native > directories works. > > * libraries/clib/awt/Makefile.am: Added handling of COND_KAFFE_X_AWT, > COND_KAFFE_QT_AWT and COND_CLASSPATH_GTK_AWT. > (SUBDIRS) Use conditional cubdirs. > (DIST_SUBDIRS) List all subdirs here. > > * libraries/clib/Makefile.am: Added handling of COND_NATIVE_AWT. I don't think that this combination makes sense. Since we don't want to include all the awt classes in the jar file Klasses.jar.bootstrap (do we?), we have to build the native awt stuff after rt.jar, which is done by adding the directories to DIRECTORIES_AFTER_RTJAR. However, also adding awt to SUBDIRS in javalib/clib will cause the awt stuff to be built before rt.jar, which means that we would have to include the awt classes into Klasses.jar.bootstrap. Therefore, I would like to commit the attached patch. Could you probably try whether it breaks anything? Thanks, Helmer Index: libraries/clib/Makefile.am === RCS file: /cvs/kaffe/kaffe/libraries/clib/Makefile.am,v retrieving revision 1.10 diff -u -r1.10 Makefile.am --- libraries/clib/Makefile.am 24 Jul 2004 01:44:00 - 1.10 +++ libraries/clib/Makefile.am 24 Jul 2004 09:52:05 - @@ -9,19 +9,6 @@ # See the file "license.terms" for information on usage and redistribution # of this file. -# Build libxmlj only desired -if COND_LIBXMLJ -MAYBE_LIBXMLJ = libxmlj -else -MAYBE_LIBXMLJ = -endif - -if COND_NATIVE_AWT -MAYBE_AWT = awt -else -MAYBE_AWT = -endif - -SUBDIRS = native io nio net zip math security management $(MAYBE_LIBXMLJ) $(MAYBE_AWT) +SUBDIRS = native io nio net zip math security management DIST_SUBDIRS = native io nio net zip math libxmlj security management awt sound Index: include/Makefile.am === RCS file: /cvs/kaffe/kaffe/include/Makefile.am,v retrieving revision 1.65 diff -u -r1.65 Makefile.am --- include/Makefile.am 22 Jul 2004 19:03:31 - 1.65 +++ include/Makefile.am 24 Jul 2004 09:52:05 - @@ -105,54 +105,6 @@ INSTALL_JNI_DERIVED_HDRS = NOINSTALL_JNI_DERIVED_HDRS = \ - gnu_java_awt_peer_gtk_GdkFontMetrics.h \ - gnu_java_awt_peer_gtk_GdkGraphics.h \ - gnu_java_awt_peer_gtk_GdkPixbufDecoder.h \ - gnu_java_awt_peer_gtk_GtkButtonPeer.h \ - gnu_java_awt_peer_gtk_GtkCanvasPeer.h \ - gnu_java_awt_peer_gtk_GtkCheckboxGroupPeer.h \ - gnu_java_awt_peer_gtk_GtkCheckboxMenuItemPeer.h \ - gnu_java_awt_peer_gtk_GtkCheckboxPeer.h \ - gnu_java_awt_peer_gtk_GtkChoicePeer.h \ - gnu_java_awt_peer_gtk_GtkClipboard.h \ - gnu_java_awt_peer_gtk_GtkComponentPeer.h \ - gnu_java_awt_peer_gtk_GtkEmbeddedWindowPeer.h \ - gnu_java_awt_peer_gtk_GtkFileDialogPeer.h \ - gnu_java_awt_peer_gtk_GtkFramePeer.h \ - gnu_java_awt_peer_gtk_GtkGenericPeer.h \ - gnu_java_awt_peer_gtk_GtkImagePainter.h \ - gnu_java_awt_peer_gtk_GtkLabelPeer.h \ - gnu_java_awt_peer_gtk_GtkListPeer.h \ - gnu_java_awt_peer_gtk_GtkMainThread.h \ - gnu_java_awt_peer_gtk_GtkMenuBarPeer.h \ - gnu_java_awt_peer_gtk_GtkMenuComponentPeer.h \ - gnu_java_awt_peer_gtk_GtkMenuItemPeer.h \ - gnu_java_awt_peer_gtk_GtkMenuPeer.h \ - gnu_java_awt_peer_gtk_GtkPanelPeer.h \ - gnu_java_awt_peer_gtk_GtkPopupMenuPeer.h \ - gnu_java_awt_peer_gtk_GtkScrollbarPeer.h \ - gnu_java_awt_peer_gtk_GtkScrollPanePeer.h \ - gnu_java_awt_peer_gtk_GtkTextAreaPeer.h \ - gnu_java_awt_peer_gtk_GtkTextComponentPeer.h \ - gnu_java_awt_peer_gtk_GtkTextFieldPeer.h \ - gnu_java_awt_peer_gtk_GtkToolkit.h \ - gnu_java_awt_peer_gtk_GtkWindowPeer.h \ - gnu_java_awt_peer_gtk_GThreadNativeMethodRunner.h \ - gnu_xml_libxmlj_dom_GnomeAttr.h \ - gnu_xml_libxmlj_dom_GnomeDocument.h \ - gnu_xml_libxmlj_dom_GnomeDocumentBuilder.h \ - gnu_xml_libxmlj_dom_GnomeDocumentType.h \ - gnu_xml_libxmlj_dom_GnomeElement.h \ - gnu_xml_libxmlj_dom_GnomeEntity.h \ - gnu_xml_libxmlj_dom_GnomeNamedNodeMap.h \ - gnu_xml_libxmlj_dom_GnomeNode.h \ - gnu_xml_libxmlj_dom_GnomeNodeList.h \ - gnu_xml_libxmlj_dom_GnomeProcessingInstruction.h \ - gnu_xml_libxmlj_dom_MatchingNodeList.h \ - gnu_xml_libxmlj_sax_GnomeLocator.h \ - gnu_xml_libxmlj_sax_GnomeXMLReader.h \ - gnu_xml_libxmlj_transform_LibxsltStylesheet.h \ - gnu_xml_libxmlj_transform_JavaContext.h \
Re: [kaffe] Threads & Boehm GC
On Sat, 24 Jul 2004 09:38:08 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: Hi, > It seems that the Boehm-GC needs to catch a number of pthread calls. > This is not evident to implement in kaffe but I think I can do the > following: > [...] > Any comments ? why does the gc_pthread_redirects.h thing from boehm not work? I mean if kaffevm/gc.h included a header file called "gc-impl.h" from kaffevm/kaffe-gc or kaffevm/boehm-gc and unix-pthreads/thread-impl.c included kaffevm/gc.h (and thus boehm-gc/gc-impl.h), it should work, shouldn't it? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [bug] Method delegation error with superinterfaces
On Mon, 19 Jul 2004 16:59:23 +0200 Benja Fallenstein <[EMAIL PROTECTED]> wrote: Hi, > The following bug is triggered by the combination of Jikes 1.21 with the > current version of Kaffe from CVS. It is not triggered by Jikes + > sunjava or by sunjavac + Kaffe... what jdk version do you use? > With jikes+Kaffe, the following code: > > [ code snipped ] > > I first noticed this bug in a much more complex program, where I would > get NullPointerExceptions when calling any method on the string returned > by toString(). Thanks for tracking this one down. > Not sure whether this should be seen as a bug in Kaffe or Jikes -- but > since Kaffe aims to run programs that work on Sun's JDK, I guess this > should be fixed. I don't understand Kaffe well enough to do it, though. No problem, will have a look at this. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jit3 expert wanted! (Re: m68k/netbsd/jit3 trial)
On Sat, 17 Jul 2004 02:31:35 +0900 (JST) Kiyo Inaba <[EMAIL PROTECTED]> wrote: > I wrote: > >I checkouted your version. And it works (which I mean, the compiled > >version stops at the same place as mine) on m68k/netbsd. > > I continuing to debug jit3 for m68k. And if there are someone > who has some experience to debug jit3, I appreciate to get > some hint... > > The compiled code of 'Runtime/loadLibrary' contains a funny > code segment as below. > > 0x28da14: movel %a4@(8),%d0 > 0x28da18: cmpl %d0,%d4 > 0x28da1a: movel %d0,%fp@(-44) > 0x28da1e: bcsl 0x28da2a > 0x28da24: jsr 0x2b452 ; ! > 0x28da2a: moveal %fp@(-32),%a0 > > Of course this is m68k asm and usual people don't want to read > them, but the core part is simple. At 0x28da1e, it checks a > flag and try to skip next instruction (subroutine call to > 'soft_badarrayindex'). But, on m68k 'move' instruction changes > its flag, and that's why soft_badarrayindex is called :-< In order to check the array index, the jitter uses the cbranch_offset_int instruction. Since the m68k backend doesn't provide this instruction, the jitter uses the following instructions instead: load_offset_int(tmp, src, offs) cmp_int(dst, src, tmp) branch(l, gt) call_soft(soft_badarrayindex) Therefore, %d0 contains the value of the temp slot tmp and the incorrect movel looks like %d0 is spilled onto the stack in order to update the contents of the temp slot on the stack, which is done between the cmp_int and the branch. Since the jitter has to make sure that an exception handler can access the current value of the different slots, it regularly spills the registers of the different slots onto the stack. This is the type of spill that happens between two instructions, just like the one described earlier. However, since temp slots are only used in order to translate a single bytecode instruction, this type of spill is not necessary for temp slots. Therefore I've attached a patch that prevents this type of spill for temp slots. HTH, Helmer Index: kaffe/kaffevm/jit3/machine.c === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/jit3/machine.c,v retrieving revision 1.54 diff -u -r1.54 machine.c --- kaffe/kaffevm/jit3/machine.c17 Jul 2004 07:57:29 - 1.54 +++ kaffe/kaffevm/jit3/machine.c17 Jul 2004 14:28:52 - @@ -838,7 +838,7 @@ * in case its used in a subsequent * basic block. */ - if( t->jflags.ANY ) + if( t->jflags.ANY && (t->u[i].slotu[i].slot, true); ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] ant's fails with kaffe
On Wed, 14 Jul 2004 19:27:48 +0200 Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > Hi, > > this simple build.xml file: > > > > > > > > (debian unstable 1.1.5 branch) > > $ JAVA_HOME=/usr/lib/kaffe ant > Buildfile: build.xml > > time: > > BUILD FAILED > /tmp/build.xml:1: java.util.MissingResourceException: resource not found > > Total time: 0 seconds > > Oups! This means kaffe could no more be used to build ant based package > at the moment! > > Thanks for your time and help. (I don't know if it's debian specific?) Fixed in HEAD (patch from 04/07/11 "small fix ..."), I think. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] IllegalAccessError running CGLib
On Sun, 11 Jul 2004 13:02:06 +0800 Alan Tam <[EMAIL PROTECTED]> wrote: > Excuse me, is this a wrong place to file bugs like this? Yes, I've just checked in a fix, so CVS Head should work fine. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] About KAFFEHOME
On Mon, 12 Jul 2004 09:33:20 +0200 Fabien Renaud <[EMAIL PROTECTED]> wrote: > Helmer Krämer wrote: > > >On Fri, 09 Jul 2004 14:02:58 +0200 > >Fabien Renaud <[EMAIL PROTECTED]> wrote: > > > >Hi, > > > > > > > >>When I cross compiled I had some problems because there is my native > >>dirs in scripts (kaffe, jdb, jar, ...) > >> > >> > > > >What do you mean with "native dirs"? > > > I mean the directories defined in my --prefix, which are not the same on > my ARM machine have you tried passing the directories on your ARM machine to --prefix and using "make install DESTDIR=/path/to/arm/root" to install kaffe? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Fixing mipsel-linux: differences between jit3 and jit1
On Thu, 08 Jul 2004 21:04:41 +0200 Dalibor Topic <[EMAIL PROTECTED]> wrote: Hi, > I've been trying to fix the build on mipsel-linux. It uses jit3. I've > got the LOUT build problem sorted out, the syntax of LOUT and friends > has changed between jit3 and jit1. The next stumbling stone is > prologue_xxC, which does not exist in jit3 funcs.h. So before I blindly > change prologue_xxC to prologue_xxx on mips (and possibly m68k, since it > suffers from same symptoms on netbsd), I'd like to know what the > difference in naming is supposed to mean ;) > > i.e. what is in the name suffix -xxx that xxC doesn;t have, etc. I > couldn't find that documented, unfortunately. I think that funcs.h is somewhat wrong since it directly uses the names from the i386 backend (i.e. prologue_xxx). IMHO it should use the different HAVE_* macros from the jit3-icode.h to declare the functions (so it correctly declares prologue_xxx on i386 but prologue_xxC on mipsel). Furthermore, these declarations should be guarded by #ifdef HAVE_foo ... #endif for optional things like HAVE_mon_enter and HAVE_mon_exit. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -C option breaks on non gnu make
On Fri, 9 Jul 2004 14:40:52 + (UTC) Riccardo <[EMAIL PROTECTED]> wrote: Hi, > I was checking the status of the kaffe make system on non-gnu makes. > Although some makes are known to be very limited, it would be nice if at > least BSD make and some other know unices makes would work. > > It seems that the -C option is not supported by BSD. Here is the debug > output of a make I've just checked in a fix. Thanks, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] About KAFFEHOME
On Fri, 09 Jul 2004 14:02:58 +0200 Fabien Renaud <[EMAIL PROTECTED]> wrote: Hi, > When I cross compiled I had some problems because there is my native > dirs in scripts (kaffe, jdb, jar, ...) What do you mean with "native dirs"? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] [New bug] -Dxxxx=y crashes
On Thu, 08 Jul 2004 00:06:40 +0200 Benja Fallenstein <[EMAIL PROTECTED]> wrote: Hi, > Weird. Anybody have an idea? Anybody who's checked code in recently know > something that may have caused this? Yeah, me. There's a double free in System.initProperties. Will commit a fix. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] make clean
On Wed, 07 Jul 2004 10:53:51 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > Fabien Renaud wrote: > > > Hi ! > > > > The _make clean_ doesn_t work for me. I only have this : > > > make clean > > Making clean in . > > make[1]: Entering directory `/home/commgw/renaud/commbox/kaffe-cvs/kaffe' > > test -z "BUILD_ENVIRONMENT" || rm -f BUILD_ENVIRONMENT > > rm -rf .libs _libs > > rm -f *.lo > > make[1]: Leaving directory `/home/commgw/renaud/commbox/kaffe-cvs/kaffe' > > > > I have to do in all subdirectories do to it myself :( > > Is it me or there is a problem ? > > > > > There is a problem. ;) SUBDIRS is empty. Sorry, will fix this. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: circular linking difficulties
On Tue, 29 Jun 2004 09:16:17 -0400 (EDT)
Rob Gonzalez <[EMAIL PROTECTED]> wrote:
Hi Rob,
sorry for the delay.
> Are you sure that the problem we see there isn't that UnknownElement is in
> the midst of linking when that checkMethodCall() call is made?
More or less. The real problem seems to be that superclasses are brought
to LINKED when the subclass is LOADED. If verification of the superclass
requires the subclass to be LINKED, kaffe will incorrectly throw a
ClassCircularityError.
With the attached path, I can run ant somewhat more successfully (It fails
because isArray(TNULL) doesn't work properly). However, it changes the
way classes are loaded so I might have broken something.
Regards,
Helmer
Index: kaffe/kaffevm/classMethod.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/classMethod.c,v
retrieving revision 1.119
diff -u -r1.119 classMethod.c
--- kaffe/kaffevm/classMethod.c 18 Apr 2004 13:57:26 - 1.119
+++ kaffe/kaffevm/classMethod.c 5 Jul 2004 07:22:46 -
@@ -193,10 +193,33 @@
else
#endif
{
+ uintp idx = (uintp)class->superclass;
+ int tag = CLASS_CONSTANTS(class)->tags[idx];
+
+ if (tag != CONSTANT_Class) {
+ postExceptionMessage(einfo,
+
JAVA_LANG(ClassFormatError),
+"%s (Invalid constant
reference, %d, "
+"expecting class, likely
an internal "
+"error)",
+class->name->data,
+tag);
+ success = false;
+ goto done;
+ }
+
class->superclass =
- getClass((uintp)class->superclass,
-class,
-einfo);
+ loadClass
(WORD2UTF(CLASS_CONSTANTS(class)->data[idx]),
+ class->loader,
+ einfo);
+
+ /* updating the const pool w/o holding a lock is ok,
since no other
+* thread can use this class at this early stage
+*/
+ if (class->superclass != NULL) {
+ CLASS_CONSTANTS(class)->tags[idx] =
CONSTANT_ResolvedClass;
+ CLASS_CONSTANTS(class)->data[idx] =
(ConstSlot)class->superclass;
+ }
}
lockClass(class);
@@ -216,21 +239,26 @@
success = false;
goto done;
}
- /* that's pretty much obsolete. */
- assert(class->superclass->state >= CSTATE_DOING_LINK);
- classMappingLoaded(ce, class);
/* Copy initial field size and gc layout.
* Later, as this class's fields are resolved, they
* are added to the superclass's layout.
*/
CLASS_FSIZE(class) = CLASS_FSIZE(class->superclass);
class->gc_layout = class->superclass->gc_layout;
+
+ /* Mark the class as loaded and set the state to
CSTATE_LOADED_SUPER before
+* processing the superclass to LINKED. That way, we will
process this class
+* to LINKED when it has to be loaded while verifying one of
its superclasses.
+* Since the superclass is already PREPARED, possible
ClassCircularityErrors
+* would've been detected earlier.
+*/
+ classMappingLoaded(ce, class);
+ SET_CLASS_STATE(CSTATE_LOADED_SUPER);
+ if (processClass (class->superclass, CSTATE_LINKED, einfo) ==
false) {
+ success = false;
+ goto done;
+ }
}
- if( class->superclass )
- {
- assert(class->superclass->state >= CSTATE_DOING_LINK);
- }
-
}
DO_CLASS_STATE(CSTATE_VERIFIED) {
@@ -364,7 +392,8 @@
}
[kaffe] Re: circular linking difficulties
On Mon, 28 Jun 2004 17:17:35 -0400 (EDT) [EMAIL PROTECTED] wrote: Hi Rob, > > What puzzles me is that we already have the CSTATE_DOING_LINK phase > > during class loading, which seems to be what you want > [ rest of paragraph deleted ] > > I agree, but it doesn't seem to be working. Kaffe is definitely choking > when a getClassFromSignature call calles loadClass to be called on a class > that is in the process of verification already. I have no idea why the > CSTATE_DOING_LINK isn't working... I'm pretty sure that we'll find out what's going wrong here ;) When running ant 1.6.0, I get the following error: considering method org/apache/tools/ant/Task.getReplacement()Lorg/apache/tools/ant/UnknownElement; verifying method getReplacement [...] blockNum/first pc/changed/stksz = 1 / 7 / 1 / 0 before: locals: 0: (16)org/apache/tools/ant/Task opstack (0): 0: (0)TUNSTABLE 1: (0)TUNSTABLE 2: (0)TUNSTABLE 3: (0)TUNSTABLE about to verify the block... block->startAddr = 7, block->lastAddr = 127, first instruction = 42 [...] pc = 30, opcode = 182 == INVOKEVIRTUAL calling method setProject(Lorg/apache/tools/ant/Project;)V typechecking (16)org/apache/tools/ant/ProjectComponent vs. (4)Lorg/apache/tools/ant/UnknownElement; required receiver type: (16)org/apache/tools/ant/ProjectComponent actual receiver type: (16)NULL error with method invocation, pc = 30, method = setProject(Lorg/apache/tools/ant/Project;)V some problem with a method call...here's the block: locals: 0: (16)org/apache/tools/ant/Task opstack (2): 0: (16)NULL 1: (4)Lorg/apache/tools/ant/Project; 2: (0)TUNSTABLE 3: (0)TUNSTABLE Verify Method 3b: org/apache/tools/ant/Task.getReplacement()Lorg/apache/tools/ant/UnknownElement;: FAILED cleaning up... done Since ProjectComponent is a super class of UnknownElement, the typecheck should succeed. Exactly why this error leads to a ClassCircularityError later on, is another interesting question. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build process
On Mon, 28 Jun 2004 10:45:56 +0200 Arnaud Vandyck <[EMAIL PROTECTED]> wrote: > There also was a discussion with Jim Pick about moving the jni patch to > C doe so rt.jar would be build only on demand and I'll not have to patch > the java code. Any idea about how to achieve this? (add /usr/lib/jni to > the library path) I could add a configure option --with-library-path=/usr/lib/jni (or whatever) that you could use to specify additional directories that are to be added to kaffe's internal library path? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] circular linking difficulties
On Sun, 27 Jun 2004 15:10:22 -0400 (EDT)
[EMAIL PROTECTED] wrote:
Hi,
first a question about the verifier ;)
mergeTypes() contains the following snippet:
mergeSupersets(v, t1, t2);
if (v->supertypes->count == 1) {
*t2 = *TOBJ;
}
else {
t2->tinfo = TINFO_SUPERTYPES;
t2->data.supertypes = v->supertypes;
return true;
}
Is this really correct? If supertypes->count is 1, this means
that both classes have a common superclass and that should be
the result of the merge, shouldn't it?
> Does anybody see a good way to deal with this problem? If it helps, I can
> post a couple Java classes that display the error in the current CVS head
> when it's run with -verifyremote as an option.
What puzzles me is that we already have the CSTATE_DOING_LINK phase
during class loading, which seems to be what you want: In your example,
A's state will be CSTATE_DOING_LINK during verify3(A). If the same
thread that executes verify3(A) tries to load A again before verify3(A)
is finished, A will be treated as if it was CSTATE_LINKED already.
This means that the verify3(B) call executed during verify3(A) will
treat A as if it was already CSTATE_LINKED. Therefore, verify3(B) will
succeed and afterwards also verify3(A). Since this is not working as
expected, I either missed something or something else is going wrong.
[have you tried setting "class->processingThread = THREAD_NATIVE ();"
just after the "SET_CLASS_STATE(CSTATE_DOING_LINK);" in classMethod.c?]
This will also work with user class loaders. When kaffe delegates
loading of a class to a user class loader it always calls loadClass
with resolve set to false. This means that a "correct" class loader
will call defineClass(), but not resolveClass(). Therefore, the
class returned by loadClass() will be PREPARED, but not LINKED or
even COMPLETE. This only fails if the user class loader ignores the
resolve parameter and processes the class to COMPLETE (either by
calling resolveClass directly or by creating an instance of the
class returned by defineClass). This however would mean that the
class loader is not "correct".
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] build process
Hi all,
the attached patch modifies kaffe's build process a little bit,
so that it executes in roughly four steps:
* build kaffeh, libkaffevm, standard libtool -modules and kaffe
executable
* build rt.jar
* build optional libtool -modules (like awt, sound, libxmlj)
[including generation of required headers]
* relink kaffe executable using all libtool -modules
[required for systems that can't dlopen libtool -modules]
Since the jni headers for the optional libtool -modules are
generated after rt.jar has been built, we no longer have to
include classes of optional packages in Klasses.jar.bootstrap.
If nobody has any objections, I'll check it in during next
week.
Regards,
Helmer
Index: configure.ac
===
RCS file: /cvs/kaffe/kaffe/configure.ac,v
retrieving revision 1.37
diff -u -r1.37 configure.ac
--- configure.ac23 Jun 2004 15:36:42 - 1.37
+++ configure.ac27 Jun 2004 17:02:36 -
@@ -1727,8 +1727,11 @@
AC_MSG_ERROR([unable to locate libxml.]))
AM_PATH_XSLT([1.0.24],[CFLAGS="${XSLT_CFLAGS} ${CFLAGS}"]
[CPPFLAGS="${XSLT_CFLAGS} ${CPPFLAGS}"] [LIBS="${XSLT_LIBS} ${LIBS}"] ,
AC_MSG_ERROR([unable to locate libxslt.]))
+LIBXMLJ_LIB="\$(top_builddir)/libraries/clib/libxmlj/libxmlj.la"
else
AC_MSG_ERROR([Not building libxmlj - only available with pthreads.])
+enable_libxmlj="no"
+LIBXMLJ_LIB=""
fi
fi
@@ -1771,12 +1774,8 @@
\$(top_builddir)/libraries/clib/io/libio.la \
\$(top_builddir)/libraries/clib/nio/libnio.la \
\$(top_builddir)/libraries/clib/zip/libzip.la \
-$MATH_LIB \
-$ALSA_LIB \
-$ESD_LIB \
\$(top_builddir)/libraries/clib/management/libmanagement.la \
\$(top_builddir)/libraries/clib/security/libsecurity.la \
-$AWT_LIB \
$JAVA_LIBS \
"
@@ -1785,6 +1784,21 @@
DLOPEN_JAVA_LIBS="$DLOPEN_JAVA_LIBS -dlopen $lib"
done
AC_SUBST(DLOPEN_JAVA_LIBS)
+
+
+OPT_JAVA_LIBS=" \
+$ALSA_LIB \
+$ESD_LIB \
+$LIBXMLJ_LIB \
+$AWT_LIB \
+"
+
+OPT_DLOPEN_JAVA_LIBS=
+for lib in $OPT_JAVA_LIBS; do
+ OPT_DLOPEN_JAVA_LIBS="$OPT_DLOPEN_JAVA_LIBS -dlopen $lib"
+done
+AC_SUBST(OPT_DLOPEN_JAVA_LIBS)
+
if test x"$dynamic_libraries" = x"no"; then
KLIBFLAGS=-static
Index: Makefile.am
===
RCS file: /cvs/kaffe/kaffe/Makefile.am,v
retrieving revision 1.68
diff -u -r1.68 Makefile.am
--- Makefile.am 22 Jun 2004 12:21:27 - 1.68
+++ Makefile.am 27 Jun 2004 17:02:37 -
@@ -14,8 +14,7 @@
AUTOMAKE_OPTIONS = foreign 1.3e
-SUBDIRS = . config include replace libltdl kaffe/kaffevm libraries/clib
libraries/extensions kaffe libraries/javalib tools test po
-
+SUBDIRS =
DIST_SUBDIRS = . config include replace libltdl kaffe libraries tools test po
EXTRA_DIST = \
@@ -171,3 +170,77 @@
# Regenerate HTML docs and copy them to source tree
docs-regen: docs-docbook-html
cp -f target/docs/docbook/*.html $(srcdir)/docs/html
+
+
+#
+# things we need to compile before we can compile rt.jar
+#
+DIRECTORIES_BEFORE_RTJAR = \
+ config \
+ include \
+ replace \
+ libltdl \
+ kaffe/kaffevm \
+ libraries/clib \
+ kaffe
+
+#
+# things we need to compile after we have compiled rt.jar
+#
+DIRECTORIES_AFTER_RTJAR = \
+ tools \
+ test \
+ po \
+ libraries/clib/awt
+
+if COND_LIBXMLJ
+DIRECTORIES_AFTER_RTJAR += libraries/clib/libxmlj
+endif
+
+if COND_SOUND_ALSA
+DIRECTORIES_AFTER_RTJAR += libraries/clib/sound
+else
+if COND_SOUND_ESD
+DIRECTORIES_AFTER_RTJAR += libraries/clib/sound
+endif
+endif
+
+all-local:
+ @list="$(DIRECTORIES_BEFORE_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir all || exit $$? ; \
+ done; \
+ $(MAKE) -C libraries/javalib all || exit $$? ; \
+ list="$(DIRECTORIES_AFTER_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir all || exit $$? ; \
+ done ; \
+ $(MAKE) -C kaffe/kaffe final-executable
+
+install-exec-hook:
+ @list="$(DIRECTORIES_BEFORE_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir install-exec || exit $$? ; \
+ done; \
+ $(MAKE) -C libraries/javalib install-exec || exit $$? ; \
+ list="$(DIRECTORIES_AFTER_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir install-exec || exit $$? ; \
+ done
+
+install-data-hook:
+ @list="$(DIRECTORIES_BEFORE_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir install-data || exit $$? ; \
+ done; \
+ $(MAKE) -C libraries/javalib install-data || exit $$? ; \
+ list="$(DIRECTORIES_AFTER_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir install-data || exit $$? ; \
+ done
+
+uninstall-hook:
+ @list="$(DIRECTORIES_BEFORE_RTJAR)"; for subdir in $$list; do \
+ $(MAKE) -C $$subdir uninstall || exit $$? ; \
+ done; \
+ $(MAKE) -C librarie
Re: [kaffe] StrongARM problems
On Sat, 26 Jun 2004 21:08:32 +0200 Dalibor Topic <[EMAIL PROTECTED]> wrote: > Dalibor Topic wrote: > > Guilhem Lavaux wrote: > > > >> > >>> > >>> Hello, > >> > >> > >> > >> Hi Fabien, > >> > >>> > >>> Me too I cannot compile HEAD, I have the same errors. > >>> > >> > >> Dalibor was on the track for this bug but I don't know what he is > >> doing now about it. But here is the right fix I think... > > > > > > I think the problem comes from libc's internal structure (k-sigcontext) > > and the kernel includes disagreeing on the sigonctext struct's contents. > > libc uses a union of sigcontext structs (v20, v21) to be able to extract > > the 'right' sigcontextinfo from the kernel sigcontext. Of course, as the > > kernel sigcontext does not really have such a union inside the struct, > > things break when we pass sigcontext as a k_sigcontext. > > > > I think the right way to fix that is to find out what sigcontext struct > > looked like on 2.0 kernels for arm, and to check what it looks like on > > current arm kernels, to add a configure.ac check for some struct element > > that's only present in one of them, and to use that to fix our > > sigcontextinfo.h to remove the v2x union ideantifiers to access the > > right struct elements when the above mentioned struct element is present > > or not. > > > > I have to start downloading some kernels, I guess ;) > > done that, and talked on IRC with some debian-arm developers and Kero, > and it seems that noone is using 2.0.x on arm, these days. So in order > to make maintenance easier, I propose to remove the support for that, > and simply make it work with the current kernels. Unfortunately, > handhelds.org seems down, and HP's testdrive seems to have taken offline > their arm machines, so I don't have a box to test on atm. I'll reactivate the xscale at work and have a look at least at the xscale. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Loading stops after 2 classes
On Thu, 24 Jun 2004 13:26:38 +0200 Fabien Renaud <[EMAIL PROTECTED]> wrote: > #include "sigcontextinfo.h" > + > +#define SIGNAL_ARGS(sig, ctx) \ > + int sig, SIGCONTEXT ctx That's not quite correct. On ARM, the first four parameters are passed in registers, and the others are passed on the stack. Since the SIGCONTEXT struct is passed on the stack, the macro should read something like #define SIGNAL_ARGS(sig, ctx) \ int sig, int arm_r2, int arm_r3, int arm_r4, SIGCONTEXT ctx Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (guilhem): Invocation API fixes + Static lock initializer fixes + Kaffe main cleanup.
On Tue, 15 Jun 2004 10:48:07 -0700 Kaffe CVS <[EMAIL PROTECTED]> wrote: Hi, > * kaffe/kaffevm/jni.c > (tryClassForName): New function to be able to catch exceptions. > (Kaffe_FindClass): Initialize a user class loader and use it to load > a class if it has not been found by the default classloader. have you tried modifying ThreadStack.getCallersClassLoader() to return the AppClassLoader singleton when the stack of the thread contains only two or three methods? I think that would be a little simpler and would work for every method that requires a classloader, not just FindClass. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Threaded code and quick instructions for Kaffe
On Tue, 1 Jun 2004 14:08:00 +0800 [EMAIL PROTECTED] wrote: > Hello all, > > After looking up Helmut Eller's Threaded code interpreter patch > [1], I attempt to migrate his patch to Kaffe 1.1.x version, and it > is almost finished, which is attached against kaffe cvs in this mail. Just some random notes: - we should probably check whether somebody wants to compile kaffe without gcc, since that wouldn't work anymore - Is it possible to use kaffe.def instead of threaded_int.def? (or what changes to kaffe.def would that require?) I don't really like the idea of maintaining both, threaded_int.def and kaffe.def and keeping them in sync (the threaded_int.def in your patch doesn't throw IncompatibleClassChangeErrors, for example). Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HEAD not Building javalib
On Sat, 29 May 2004 10:24:22 -0400 Michael Franz <[EMAIL PROTECTED]> wrote: > > On Saturday, May 29, 2004, at 03:36 AM, Alan Eliasen wrote: > > > > > Michael Franz wrote: > >> Hi, > >> > >> For the past week HEAD has not been building on SuSE 9.1 x86. I think > >> it started when I had to upgrade autoconf and automake. Is anyone > >> else > >> having problems with this? The build gets stuck on this line: > >> > >> /bin/sh ./rebuildLib @essential.files > >> Compiling classes from @essential.files using > >> /home/mfranz/development/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx > >> 256M > >> at.dms.kjc.Main > >> > >> There does not seem to be any activity. > > > >For the past week or so, Fedora Core 2 (Linux Kernel 2.6.5) gives a > > segmentation fault at this place, too. I can't build either. The > > build > > failures began at the same time I upgraded from Red Hat 9. Is Linux > > x86 > > broken, or does it have something to do with the kernel? > > > > Maybe there is a connection between some recent change and the fact > that SuSE 9.1 & Fedora Core 2 are both using a 2.6.x kernel. Hmm, on my debian unstable with kernel 2.6.6, libc 2.3.2 and gcc 3.3.3, I can build javalib with both, unix-pthreads and unix-jthreads. Could you probably edit libraries/javalib/rebuildlib.in so it passes -vmdebug INIT on kaffe's commandline ? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] WARNING Bad bytecode! Illegal exception table entry
On Sat, 22 May 2004 11:44:27 +0900
Ito Kazumitsu <[EMAIL PROTECTED]> wrote:
Hi,
> The following program, when compiled with kjc, prints the
> strange message, but runs normally when compiled with Sun's javac.
Compilers are fun, aren't they ?
> [ start of example skipped ]
> private static int foo() {
> int n = 0;
> try {
> if (true) {
> throw new Exception("Test");
> }
> n = 1;
> }
> catch (Exception e) {
> n = 2;
> }
> return n;
> }
> [ rest of example skipped ]
On the one hand, KJC is clever enough to detect that the
condition of the if will always be true, and thus removes
it from the bytecode. On the other hand, KJC is not clever
enough to detect and remove the unreachable statement "n=1"
from the bytecode, as javac does. This means that the end
pc of the exception table entry is an unreachable instruction.
The jitter in turn doesn't translate the exception table of
a method correctly when the end pc is an unreachable insn,
which in turn yields the message you've got.
So I'll have a look at the jitter and someone else might
want to have a look at kjc.
And once again thanks for the nice test cases you come
up with.
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Projects/sub-projects dependancies... Thoughts
On Sat, 15 May 2004 18:32:39 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > There will be a slight performance loss for JIT > though: currently the JIT is putting the pointers to translated methods > directly in the vtable. To be compatible with intrp and other way of > handling methods we must put a pointer to Method. Why do we have to put a pointer to Method into the vtable to be compatible? Have you considered modifying intrp so it stores a pointer to the bytecode in the vtable (and allocates the bytecode so that GC_getObjectBase(address of some bytecode) returns the address of the Method* the bytecode belongs to)? And what happens to xdebugging when the vtable doesn't contain a pointer to the code of the method? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] more kjc fun
Hi, I tried compiling CVS Head with kjc and it stopped with this error: java/awt/font/TextAttribute.java:44: error:Cannot find type "AttributedCharacterIterator/Attribute" I've checked the profile I'm using (allatonce) and it contains the required entry for java.text.AttributedCharacterIterator. However, the inner class "Attribute" kjc complains about does not have a public modifier. So I assume that kjc doesn't make inner classes of interfaces public by default? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] arm-linux and gcc 3.x
Hi all, I've played a little bit with gcc 3.x on arm-linux, trying to get the jit engine working and the results are somewhat promising. However, when I run the patched jitter on a strong arm, it gets a SIGILL and terminates. So I'm wondering if someone else with access to an xscale could give the attached patch a try and report whether they're more successful than me? Patch is against cvs from a couple of minutes ago. Thanks, Helmer arm-patch Description: Binary data
Re: [kaffe] Sockets remain unclosed
On Tue, 6 Apr 2004 20:19:11 +0900 (JST) Ito Kazumitsu <[EMAIL PROTECTED]> wrote: > > In message "[kaffe] Sockets remain unclosed" > on 04/03/17, Ito Kazumitsu <[EMAIL PROTECTED]> writes: > > > Summary: > > > > When you use Jetty with Kaffe, the number of idle sockets > > gradually increases until "too many open files" error may occur. > > The value of Jetty's parameter MaxIdleTimeMs is 1 ms by default, > > so a new socket is created and thrown away in every 10 seconds. > > Setting MaxIdleTimeMs to a reasonable value will slow down the > > the creation of new sockets and you can avoid "too many open files". > > > > That was not a complete solution. Although the creation of new sockets > > can be slowed down, the number of sockets still increases gradually. > > > > I patched java/net/ServerSocket.java to see if this problem can be > > solved. The result is satisfactory. > > Unfortunately, this is not the end of the story. > > With the patch to java/net/ServerSocket.java, Jetty works almost > fine. But the number of open sockets still increases slowly but > steadily and in a long run, "too many open files" error will happen. > > The problem is: > >(1) When accept() is done, two file descriptors are generated. >(2) When the socket is closed, one of the two file descriptors is >closed but the other remains unclosed. > > The problem may be OS-dependent and my OS is Linux 2.4.18-3. Looks like a bug in java.net.Socket java.net.ServerSocket.accept() eventually calls impl.accept (socket.getImpl()), where "socket" is the java.net.Socket instance returned by the accept() call. java.net.Socket.getImpl() however calls impl.create(), which opens the new fd that never gets closed, since all references to it get overwritten in the impl.accept() call. Easiest way to fix this might be something like the attached patch. Regards, Helmer socket-patch Description: Binary data
Re: [kaffe] Re: kaffe on pxa255 runs now
On Tue, 09 Mar 2004 22:18:05 +0100 Holger Schurig <[EMAIL PROTECTED]> wrote: > >> Kaffe on PXA255 runs now, I had to apply the attached patch. > > > > The jit engine ? > > Yes, if I didn't intermingle all of what I did today at work. I recompiled > kaffe several times with different ./configure options ... I thought that the jit engine didn't run on arm when being compiled with gcc 3.x ... Could you probably check by running kaffe -fullversion what engine you're actually using? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe on pxa255 runs now
On Tue, 09 Mar 2004 14:42:29 +0100 Holger Schurig <[EMAIL PROTECTED]> wrote: > Kaffe on PXA255 runs now, I had to apply the attached patch. The jit engine ? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] More mipsel jit3
On Mon, 08 Mar 2004 13:34:13 -0800 Casey Marshall <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I've gone ahead and implemented translations for fcmpg, fcmpl, dcmpg, > and dcmpl using C.cond.fmt. This gets me further in loading Kaffe (now > System.checkPropertyAccess complains that "line.separator" is a > zero-length key). Unfortunately, I am also getting an improper gc_free > call, and thence a SIGSEGV, with jitBasic ControlFlowMethods.class. You might want to remove the boolean_exception() method from the ControlFlowMethods class (or move it to the end of the class). It instantiates a new Throwable Object which causes a whole bunch of methods to be translated and executed. On arm and alpha this lead to a crash while creating a new thread (the deleteHelper of java.io.File). This happens because the java.lang.Thread constructor tries to access the ThreadGroup of the current Thread which isn't created by the jit_stub. The attached patch was an attempt to fix this, but I still got the crash on arm. However if you're able to run the tests with this patch, it's more likely to be a bug in the arm jitter. Regards, Helmer jit_stub.patch Description: Binary data
Re: [kaffe] Debian buildd results
On Fri, 27 Feb 2004 14:03:51 +0100 Arnaud Vandyck <[EMAIL PROTECTED]> wrote: Hi, > hppa: > http://buildd.debian.org/fetch.php?&pkg=kaffe&ver=2%3A1.1.4-1&arch=hppa&stamp=1077799703&file=log&as=raw don't really know what's going wrong here. The file "libraries/clib/math/.deps/BigInteger.Plo" should've been created by the config.status script. Looking at the build log, it seems like the depfiles pass of config.status crashes: " config.status: executing depfiles commands malloc: ../bash/subst.c:2508: assertion botched malloc: block on free list clobbered Stopping myself...config.status: executing default-1 commands " So if config.status crashed just before creating the BigInteger.Plo file, make would correctly complain about a missing file later on. So it looks like we've found some bash stress test ?!?? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Debian buildd results
On Fri, 27 Feb 2004 14:03:51 +0100 Arnaud Vandyck <[EMAIL PROTECTED]> wrote: Hi, > alpha: > http://buildd.debian.org/fetch.php?&pkg=kaffe&ver=2%3A1.1.4-1&arch=alpha&stamp=1077763250&file=log&as=raw this one fails because the alpha backend for the jit engine doesn't properly unwind the stack. I managed to fix that bug but there are other ones (the jitBasic tests are really useful) so some more jit backend hacking is required for this one. If I find the time, I'll have a closer look at it. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Debian buildd results
On Fri, 27 Feb 2004 14:03:51 +0100 Arnaud Vandyck <[EMAIL PROTECTED]> wrote: Hi, > s390: > http://buildd.debian.org/fetch.php?&pkg=kaffe&ver=2%3A1.1.4-1&arch=s390&stamp=1077762964&file=log&as=raw this one looks like a simple typo introduced when sysdepCallMethod was converted into an inline function, so at least s390 should be easy to fix :) Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] issue with https, kaffe 1.1.3, and jessie 0.9.6
On Wed, 04 Feb 2004 16:05:22 -0800 Mark Maxham <[EMAIL PROTECTED]> wrote: > I have a very simple little program: > > I'm running kaffe 1.1.3 on Debian, and I have built the GNU Crypto from > the latest CVS, as well as Jessie, also from the latest CVS. Here's my > little test app: > > [ ... ] > > java -classpath .:/data/workdir/source/gnu-crypto.jar: > /data/workdir/jce/javax-crypto.jar: > /data/workdir/security/javax-security.jar: > /data/jessie-0.9.6/lib/javax-net.jar: > /data/jessie-0.9.6/lib/javax-security-cert.jar: > /data/jessie-0.9.6/lib/org-metastatic-jessie.jar HttpsTest > > I looked in the jessie.jar file and everything looks like it's there to > provide HTTPS, and I get this: > > java.net.MalformedURLException: Protocol handler not found: https > at java.net.URL. (URL.java:430) > at java.net.URL. (URL.java:311) > at HttpsTest.main (HttpsTest.java:17) > > I tried moving the jessie.jar into the BOOTCLASSPATH and got a whole new > raft of exceptions, because jessie wants to load some classes by name. > But to do so, it has to call [some object].class.getClassLoader(). But > if the calling class was loaded by the bootloader, getClassLoader() > returns null. Argh! It's like I'm stuck in a catch-22 here. > > Has anybody else made https work with jessie under kaffe? If so, what's > the trick? Looks like URL.getURLStreamHandler() is using the wrong classloader to load the class of the handler (patch is attached). Should I check it in and file a bug against classpath? Regards, Helmer URL-patch Description: Binary data
Re: [kaffe] Class pool handling
On Fri, 30 Jan 2004 19:46:08 +0100
Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to make ant-1.6.0 work with kaffe and I've stopped on a
> strange problem: it appears that the interface AntMain is loaded twice
> by kaffe. The first time is using the primary class loader, the second
> time using URLClassLoader. This causes the VM to consider the two
> entries concerning AntMain as two interfaces different and so when ant
> tries to cast a class inheriting AntMain there is an exception which is
> raised.
>
> So my question is: could classes be loaded multiple times if we're using
> different class loaders (I haven't yet read completely the JLS) ? If
> it's the case we should modify instanceof (in soft.c). If it's not we
> have to modify loadClass (classMethod.c) to look for any existing entry
> of a class in the pool.
AFAIK, two classes are considered equal iff they have the same
name and the same class loader (JVM spec §5.3). So instanceof
in soft.c is ok. Searching the whole class pool for a class is
also wrong since it would violate the class loader hierarchy.
Digging in my local tree I think this is what's causing the bug
in ant:
Index: libraries/javalib/java/security/SecureClassLoader.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/java/security/SecureClassLoader.java,v
retrieving revision 1.4
diff -u -r1.4 SecureClassLoader.java
--- libraries/javalib/java/security/SecureClassLoader.java 6 Aug 2002 10:45:32
- 1.4
+++ libraries/javalib/java/security/SecureClassLoader.java 30 Jan 2004 20:45:21
-
@@ -21,7 +21,6 @@
}
protected SecureClassLoader() {
- this(SecureClassLoader.class.getClassLoader());
}
Could you try this ?
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: bugwatcher problems
On Mon, 26 Jan 2004 18:37:19 + Ean Schuessler <[EMAIL PROTECTED]> wrote: > As I recall (Dalibor will need to correct me here) forking a process with > pthreads just plain doesn't work. The details escape me at this point other > than the complexities of managing the relationship between the thread and the > forked process hadn't really been worked out. Of course, this is going back > to when I talked to Tim Wilkinson about the problem. For all I know, its > fixed. > > Is it fixed? If not, enabling pthreads will break many, many Ant builds. Yes, it's fixed. I've got a couple of ant scripts myself that use the exec task to run gcc and all of them are running fine. One of the problems that I know of is that pthreads doesn't execute the shutdown hooks when the VM terminates. However, I wanted to commit a partial fix (executing the shutdown hooks only when the VM terminates normally) this weekend (been way too long since my last one ;)). Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Porting KAFFE on XScale PXA255
On Wed, 17 Dec 2003 10:34:04 +0100 Gérard Basler <[EMAIL PROTECTED]> wrote: > Hi all! > > I'm tring to run kaffe on PXA255. But without any luck so far. I've > found a similar post concerning PXA250. > http://www.kaffe.org/pipermail/kaffe/2003-November/044367.html > Does someone know if kaffe works now under PXA250? > I really need a working jvm for that cpu. > I am willing to put some effort in it (debugging with gdb and so on). > Could someone please help me a bit? > I don't know where to start from. > Is it possible to deactivate the JIT? I got 1.1.2 (I guess it was 1.1.2) to run on an PXA250, but haven't tried a newer version yet. You need to compile kaffe with some 2.95.x gcc if you want to use the jit, since newer gcc's use a different calling convention than kaffe's jit (if I remember the details correctly). Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Problem with Jetty
On Thu, 6 Nov 2003 09:06:32 -0800 Jim Pick <[EMAIL PROTECTED]> wrote: Hi, > > > ":" == Syed Mudasir ahmed <[EMAIL PROTECTED]> writes: > > > > :>i am try to set up jetty web server > > :> when i run the following command i get the following > > :> error > > :> --- Error --- > > :> kaffe -jar start.jar etc/demo.xml > > > > Which version of kaffe are you using? > > > > Here on my machine, Jetty-4.2.12 works fine with the CVS > > version of kaffe whose ChangeLog head is: > >2003-10-22 Ito Kazumitsu <[EMAIL PROTECTED]> > > There has been some regression with the latest CVS (x86), Jetty 4.2.9 > starts for me, but it can't find the default webpage: > > http://localhost:8825/jetty/index.html > > I've got this in the logs: > > 09:00:53.872 WARN!! Error 404 while serving error page for 404 > > It worked before - if nobody else gets to it, I'll try to chase it down > in the next few days... the problem is that classpath's gnu.java.net.protocol.file.Connection doesn't override getPermission. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] jboss vs. java.util.zip
Hi all, I tried to find out why it was necessary to modify java.util.zip in order to get jboss to run, and the results were a bit surprising. The exception that is thrown when the patch is not applied is this one: java.io.IOException: Bogus signature: 0x6d783f3c at java.util.zip.ZipInputStream.getNextEntry (ZipInputStream.java:52) at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry (ClassLoaderUtils.java:533) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:245) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:179) at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap (UnifiedLoaderRepository3.java:651) at org.jboss.mx.loading.UnifiedLoaderRepository3.addUnifiedClassLoader (UnifiedLoaderRepository3.java:633) at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader (UnifiedLoaderRepository3.java:572) at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader (UnifiedLoaderRepository3.java:796) at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader (UnifiedLoaderRepository3.java:134) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.deployment.DeploymentInfo.createClassLoaders (DeploymentInfo.java:223) at org.jboss.deployment.MainDeployer.init (MainDeployer.java:688) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:629) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy5.deploy (source file unknown) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:384) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:291) at org.jboss.Main.boot (Main.java:150) at org.jboss.Main$1.run (Main.java:388) at java.lang.Thread.run (Thread.java:310) Inspecting the bogus signature a little bit more, I found out that 0x6d783f3c is " (FileInputStream.java:111) at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator. (ClassLoaderUtils.java:516) at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap (ClassLoaderUtils.java:177) at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap (UnifiedLoaderRepository3.java:651) at org.jboss.mx.loading.UnifiedLoaderRepository3.addUnifiedClassLoader (UnifiedLoaderRepository3.java:633) at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader (UnifiedLoaderRepository3.java:572) at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader (UnifiedLoaderRepository3.java:796) at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader (UnifiedLoaderRepository3.java:134) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.deployment.DeploymentInfo.createClassLoaders (DeploymentInfo.java:223) at org.jboss.deployment.MainDeployer.init (MainDeployer.java:688) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:629) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:589) at java.lang.reflect.Method.invoke0 (Method.java) at java.lang.reflect.Method.invoke (Method.java:255) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy5.deploy (source file unknown) at org.jboss.system.server.ServerImpl.doStart (ServerImpl.java:384) at org.jboss.system.server.ServerImpl.start (ServerImpl.java:291) at org.jboss.Main.boot (Main.java:150) at org.jboss.Main$1.run (Main.java:388) at java.lang.Thread.run (Thread.java:310) inputstream is [EMAIL PROTECTED] So the underlying input stream of the ZipInputStream that throws the IOException is indeed an xml file. No clue why they're doing this, but it means that the exception is not thrown because of some bug in the implementation of kaffe or of classpath. Regards, Helmer ___ kaffe mailing list [EMAI
Re: [kaffe] java.lang.IllegalAccessError
On Sat, 25 Oct 2003 17:07:52 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > Helmer Krämer wrote: > > >On Fri, 24 Oct 2003 20:14:38 +0200 > >Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > > > >Hi Guilhem, hi Ito, > > > > > > > >>>The attached programs cause java.lang.IllegalAccessError, > >>>which partly seemes to have something to do with KJC, > >>>but class files compiled with Sun's javac also cause the > >>>error. > >>> > >>> > >>> > >>Apparently KJC choses to protect the inner class (as usual). I've not > >>really seen a specific restriction about access modifiers concerning > >>inner classes in doc but the JDK's compiler put your sample class in > >>public access (even though you explicitly specified it protected). The > >>best guess I can make is to ignore the access modifier for inner classes > >>in KJC. I'll prepare this for tomorrow. > >> > >> > > > >I don't think that this would be the correct fix (altering > >the access modifiers during compilation doesn't look right > >to me). For a discussion of a similar problem have a look > >at the thread starting at this mail: > > > >http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.10.10010111327040.12800-10%40green.usr.onet > > > >I think the real problem is kaffe's runtime access checking, > >which is why I'm about to check in the following patch: > > > > > Yes, but this doesn't solve the problem concerning JDK. If you > disassemble the code generated > from the classes provided by Ito you may notice that the inner class > doesn't have any protection > although it is protected. But I've made another test with private and > apparently it changes something also > concerning the modifier, so the problem should be more complicated. The problem is that Base$Base1.class contains two different sets of access modifiers that are applicable to Base.Base1 . One set is stored in the 2 bytes following the constant pool, the other one can be extracted from the "InnerClasses" attribute of the constant pool. As far as inner classes are concerned, these two sets don't seem to be identical. The one that is stored outside of the constant pool doesn't seem to resemble the set of modifiers given in the corresponding source file, whereas the one that is stored in the "InnerClasses" attribute does. The difference between jikes, javac and kjc is what they do with the set stored outside of the constant pool. Javac and jikes put the ACC_PUBLIC bit in this set, whereas kjc leaves it alone. As you've said, this set even looks different when the inner class is declared private. However, the interesting question is, which set is to be choosen when verifying accesses between classes at runtime. Kaffe at least drops the one stored outside the constant pool and only works with the one extracted from the "InnerClasses" attribute, which is why kaffe works with my patch applied. So, the question is whether the contents of the set stored outside of the constant pool are specified for inner classes or whether they're unspecified and setting ACC_PUBLIC in it is just a work around for some vm, verifier, whatever, that doesn't extract the access modifiers from the constant pool. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] java.lang.IllegalAccessError
On Fri, 24 Oct 2003 20:14:38 +0200
Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
Hi Guilhem, hi Ito,
> >The attached programs cause java.lang.IllegalAccessError,
> >which partly seemes to have something to do with KJC,
> >but class files compiled with Sun's javac also cause the
> >error.
> >
> Apparently KJC choses to protect the inner class (as usual). I've not
> really seen a specific restriction about access modifiers concerning
> inner classes in doc but the JDK's compiler put your sample class in
> public access (even though you explicitly specified it protected). The
> best guess I can make is to ignore the access modifier for inner classes
> in KJC. I'll prepare this for tomorrow.
I don't think that this would be the correct fix (altering
the access modifiers during compilation doesn't look right
to me). For a discussion of a similar problem have a look
at the thread starting at this mail:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.10.10010111327040.12800-10%40green.usr.onet
I think the real problem is kaffe's runtime access checking,
which is why I'm about to check in the following patch:
Index: kaffe/kaffevm/access.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/access.c,v
retrieving revision 1.3
diff -u -r1.3 access.c
--- kaffe/kaffevm/access.c 22 Sep 2003 15:31:24 - 1.3
+++ kaffe/kaffevm/access.c 25 Oct 2003 08:16:09 -
@@ -116,7 +118,29 @@
{
class_acc = 1;
}
+ else if( (target->this_inner_index >= 0) &&
+(target->accflags & ACC_PROTECTED) )
+ {
+ /* check whether target is non private innerclass of superclass */
+ innerClass *ic = &target->inner_classes[target->this_inner_index];
+
+ if( ic->outer_class )
+ {
+ Hjava_lang_Class *outer;
+ errorInfo einfo;
+ outer = getClass(ic->outer_class, target, &einfo);
+ if( outer != NULL )
+ {
+ class_acc = instanceof(outer, context);
+ }
+ else
+ {
+ discardErrorInfo(&einfo);
+ }
+ }
+ }
+
Kaffe's runtime access checking denies access to
protected inherited inner classes, which is why
we get the IllegalAccessException.
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] new classpath import
On Sat, 11 Oct 2003 21:37:03 +1300 "M.Negovanovic" <[EMAIL PROTECTED]> wrote: > On Thu, Oct 09, 2003 at 10:23:37PM +0200, Dalibor Topic wrote: > > >IndexedPropertyDescriptor.java from classpath > > > > Unfortunately, this one breaks the Bean.java regression test for me. > > Could you look into it? > * test/regression/Bean.java: > Fixed the test. This one: - Property: type class [Ljava.lang.String;, read public java.lang.String[] Bean.getArray(), write public void Bean.setArray(java.lang.String[]), idx read public java.lang.String Bean.getArray(int), idx write public void Bean.setArray(int,java.lang.String) + Property: type class [Ljava.lang.String;, read public java.lang.String[] Bean.getArray(), write public void Bean.setArray(java.lang.String[]), idx read public java.lang.String Bean.getArray(int), idx write public java.lang.String Bean.getArray(int) is definitely wrong. I've never seen an indexed setter method that's called getSomething(). Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: 'mktemp' check in configure (or kaffe shell script does not work)
On Tue, 30 Sep 2003 15:53:33 +0900 (JST) Kiyo Inaba <[EMAIL PROTECTED]> wrote: Hi, > I said, > >As the subject line says, configure.in version 1.200 introduced existence check > >for 'mktemp' command, but it does not change anything for configure script. > >This command is used in 'kaffe' shell script and if we don't have mktemp > >(well, this is the case for me on Solaris) the final 'kaffe' script does > >not work properly if you set debug flag. > > If we don't do anything while configure for missing mktemp, then I think > this check is not needed anyway. Or, of course we can warn the user while > configure for the missing tool (or, just say 'See FAQ.requiredlibrary'). AFAIK, mktemp is used to generate a unique filename which can be used for a small gdb script that's passed via -command to gdb. Why do we have to use mktemp here anyways? I think if someone wants to debug kaffe, they'll be well able to imagine a unique filename and set KAFFE_DEBUG_TEMPFILE accordingly, don't they? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Freenet Re: [kaffe] CVS kaffe (guilhem): NIO+NET classes merging from GNU Classpath + KJC updates.
On Mon, 29 Sep 2003 10:01:32 +0200 Michael Koch <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Montag, 29. September 2003 07:09 schrieb Guilhem Lavaux: > > Dalibor Topic wrote: > > > Kaffe CVS wrote: > > >> PatchSet 4072 Date: 2003/09/28 19:53:51 > > >> Author: guilhem > > >> Branch: HEAD > > >> Tag: (none) Log: > > >> NIO+NET classes merging from GNU Classpath + KJC updates. > > >> > > >> This KJC should fix the past issue. Please report any > > >> misbehaviour (regression tests > > >> work here). > > > > > > In order to test the fresh NIO code, I've tried to run freenet > > > 0.5.2.1 [1] on top of kaffe from CVS. I've got a ton of those: > > > > > > java.lang.NullPointerException > > >at gnu.java.nio.SelectorImpl.deregisterCancelledKeys > > > (SelectorImpl.java:234) > > >at gnu.java.nio.SelectorImpl.select (SelectorImpl.java:146) > > >at gnu.java.nio.SelectorImpl.selectNow (SelectorImpl.java:86) > > >at freenet.transport.AbstractSelectorLoop.mySelect > > > (AbstractSelectorLoop.java:394) > > >at freenet.transport.WriteSelectorLoop.beforeSelect > > > (WriteSelectorLoop.java:255) > > >at freenet.transport.AbstractSelectorLoop.loop > > > (AbstractSelectorLoop.java:505) > > >at freenet.transport.WriteSelectorLoop.run > > > (WriteSelectorLoop.java:617) > > >at java.lang.Thread.run (Thread.java:321) > > > > > > cheers, > > > dalibor topic > > > > Anyway, there are some missing native calls. So it would have > > really astonished if it worked. > > Oops, I thought GCJ only when robilad asked me on IRC about it ... > > Anyway, deregisterCancelledKeys() should not throw a > NullPointerException. Can you debug this and look where exactly the > exception is thrown ? cancelledKeys() in java.nio.channels.spi.AbstractSelector returns null (as in "return null;") in gcj, kaffe and classpath cvs. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] unexpected java.lang.IllegalAccessError
On Sun, 21 Sep 2003 13:12:34 -0600 (MDT)
Timothy Stack <[EMAIL PROTECTED]> wrote:
> >
> > The attached program causes java.lang.IllegalAccessError
> > when run with kaffe (ChangeLog head: 2003-09-13 Dalibor Topic
> > <[EMAIL PROTECTED]>).
> >
> > When run with JDK
>
> Did you run it with '-verify' on? I get something like:
>
> 516 irontown:tmp8/katest> /usr/local/jdk1.3.1/bin/java -verify a.TestA
> Exception in thread "main" java.lang.IllegalAccessError: try to access
> class b/TestBB from class a/TestA
> at a.TestA.main(TestA.java:8)
>
> > or kaffe (ChangeLog head: 2003-08-27 Jim Pick
> > <[EMAIL PROTECTED]>), no such error occus.
> [test case cut...]
>
> Okie, I've had a look and I think its a problem with kjc and not the VM.
> In particular the code generated by kjc for the call to foo() is wrong (i
> think):
>
> invokevirtual b/TestBB/foo()I
>
> Notice that its making the call on TestBB (package-private class) and not
> TestB (public class). Code generated by jikes/javac generates the correct
> call to TestB/foo().
Speaking about kjc - is the project still alive?
I mean at the moment it looks like more and more
people start using kaffe and we're thus running
into several bugs in kjc that can be triggered by
pretty usual java programs (could've been spotted
earlier).
As for the runtime checking stuff: there seems to
be another bug related to inner classes:
[EMAIL PROTECTED]:/tmp/access-test$ cat a/test.java
package a;
public class test
{
protected static class inner
{
public inner (){}
}
}
[EMAIL PROTECTED]:/tmp/access-test$ cat b/test1.java
package b;
import a.test;
public class test1 extends test
{
public void bar ()
{
new inner ();
}
public static void main (String[] args)
{
new test1().bar();
}
}
Looks like access to members of inherited inner
classes is denied (test case was compiled with
jikes 1.18).
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Freeing jit temp data on demand (Was: Re: JavaLayer 0.3.0
On Fri, 19 Sep 2003 11:40:07 -0600 (MDT)
Timothy Stack <[EMAIL PROTECTED]> wrote:
Hi Tim,
> > Okie, I've duplicated the problem, the gc is getting stuck and that eats
> > up all the CPU. In particular it gets stuck in startGC() looping on the
> > finalizer list. I tried backing out helmer's last changes to the GC and
> > it seems to run fine again, but I'm not really sure where the bug is just
> > yet.
>
> okie, the offending diff seems to be in gc-incremental.c:
>
> @@ -639,7 +663,6 @@
> startGC(Collector *gcif)
> {
> gc_unit* unit;
> - gc_unit* nunit;
>
> gcStats.freedmem = 0;
> gcStats.freedobj = 0;
> @@ -663,9 +686,8 @@
> startTiming(&gc_time, "gctime-scan");
>
> /* Walk all objects on the finalizer list */
> - for (unit = gclists[finalise].cnext;
> - unit != &gclists[finalise]; unit = nunit) {
> - nunit = unit->cnext;
> + while (gclists[finalise].cnext != &gclists[finalise]) {
> + unit = gclists[finalise].cnext;
> gcMarkObject(gcif, UTOMEM(unit));
> }
>
>
> Restoring the old version makes things work again, is this important for
> the leak problem you found?
I'll try to get tritonus up and running and will respond
once I can reproduce the problems (tritonus refuses to
play any sound :( ).
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
On Fri, 19 Sep 2003 17:20:05 +0200 Mark Wielaard <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, 2003-09-19 at 16:23, Helmer Krämer wrote: > > Whenever kaffe has to load some class > > using a user defined loader, it invokes the two parameter > > form of loadClass. > > [...] > > The simple and quick fix would be to modify kaffe so > > it calls the loadClass(String) method of a user defined > > class loader instead of the loadClass(String, boolean) > > one. In theory, this should not break existing code since > > loadClass(String) simply calls the other method. I don't > > know whether this is the right way to fix this, though. > > I think this is the correct fix. See: > http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#79448 > > 1 Since JDK release 1.1 the Java virtual machine invokes the > loadClass method of a class loader in order to cause it to load > a class or interface. The argument to loadClass is the name of > the class or interface to be loaded. There is also a > two-argument version of the loadClass method. The second > argument is a boolean that indicates whether the class or > interface is to be linked or not. Only the two-argument version > was supplied in JDK release 1.0.2, and the Java virtual machine > relied on it to link the loaded class or interface. From JDK > release 1.1 onward, the Java virtual machine links the class or > interface directly, without relying on the class loader. > > You should also call the one argument ClassLoader.loadClass(String) > method for Class.forName(), but I cannot quickly find where in the spec > this is defined. Could this probably help with the problem about loading classes during verification, too? One of the problems was that we thought we couldn't predict the state of a class that's returned by a user class loader, but this paragraph seems to define this, doesn't it ? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] loadClass() vs. loadClass()
On Fri, 19 Sep 2003 09:12:44 -0600 (MDT)
Timothy Stack <[EMAIL PROTECTED]> wrote:
Hi,
> > I gave JBoss another try recently and finally got to a
> > point where I really don't know what to do.
> >
> > As you will know, java.lang.ClassLoader contains two
> > different loadClass methods, one that takes a String
> > and a boolean as its parameters and one that takes
> > only a String. Whenever kaffe has to load some class
> > using a user defined loader, it invokes the two parameter
> > form of loadClass.
>
> Looks like this is just wrong, the javadoc says the single parameter one
> should be called...
I'll commit the change to classMethod.c, then.
> > JBOSS however contains a class loader that only overrides
> > the loadClass(String) method, but not the other one.
> > This means that it doesn't work with kaffe at the moment,
> > because some classes will not be found.
>
> Hmm, they should be overriding findClass(), is there any reason why they
> needed to use loadClass()?
Their class loader looks like this:
===8<==
public static Object create(final Class intf,
final ObjectName name,
final MBeanServer server)
{
// make a which delegates to MBeanProxyInstance's cl for it's class resolution
ClassLoader cl = new ClassLoader(intf.getClassLoader())
{
public Class loadClass(final String className) throws ClassNotFoundException
{
try {
return super.loadClass(className);
}
catch (ClassNotFoundException e) {
// only allow loading of MBeanProxyInstance from this loader
if (className.equals(MBeanProxyInstance.class.getName())) {
return
MBeanProxyInstance.class.getClassLoader().loadClass(className);
}
// was some other classname, throw the CNFE
throw e;
}
}
};
return Proxy.newProxyInstance(cl,
new Class[] { MBeanProxyInstance.class, intf },
new MBeanProxyExt(name, server));
}
===>8=
So I think they could as well move the catch block
into a findClass() method.
Regards,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] loadClass() vs. loadClass()
Hi, I gave JBoss another try recently and finally got to a point where I really don't know what to do. As you will know, java.lang.ClassLoader contains two different loadClass methods, one that takes a String and a boolean as its parameters and one that takes only a String. Whenever kaffe has to load some class using a user defined loader, it invokes the two parameter form of loadClass. JBOSS however contains a class loader that only overrides the loadClass(String) method, but not the other one. This means that it doesn't work with kaffe at the moment, because some classes will not be found. The simple and quick fix would be to modify kaffe so it calls the loadClass(String) method of a user defined class loader instead of the loadClass(String, boolean) one. In theory, this should not break existing code since loadClass(String) simply calls the other method. I don't know whether this is the right way to fix this, though. Therefore, I'd like to hear other opinions about this before deciding whether or not to do the change. Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] bug report
On Wed, 3 Sep 2003 18:05:40 +0100
"Thomas Keane" <[EMAIL PROTECTED]> wrote:
> Just tried to do the make check again and this time it died here:
>
> mkdir lib
> /bin/sh ./rebuildLib @essential.files
> Compiling classes from @essential.files using
> //root/kaffe/kaffe/kaffe/kaffe-bin -verbosegc at.dms.kjc.Main
> lt-kaffe-bin: exception.c:307: dispatchException: Assertion
> `!intsDisabled()' failed.
> ./rebuildLib: line 55: 32392 Aborted $JAVAC $VERBOSE
> $JAVAC_FLAGS -d $LIBDIR $CPATH ${1+"$@"}
>
> any ideas?
My experience is that this almost always indicates that
a SIGSEGV, SIGBUS or something similar happened during
garbage collection.
If you have gdb around, it would be cool if you could
try to get a stacktrace and post it:
- Set the environment variables contained in
/root/kaffe/BUILD_ENVIRONMENT, which will
enable you to run (and debug) an uninstalled
copy of kaffe
- afterwards, you should be able to debug the
uninstalled kaffe with something like
'./libtool --mode=execute gdb $JAVA'
(also in /root/kaffe)
- at the gdb prompt, set the command line args to
'at.dms.kjc.Main' and start kaffe
If you don't have gdb around, we'll have to try something
else.
Thanks,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] memory traces from Kaffe
On Mon, 1 Sep 2003 22:52:07 -0700 (PDT) who knows <[EMAIL PROTECTED]> wrote: Hi, > I am working on data memory reference patterns of java > programs. Basically I want to see memory traces of > different Java programs running on Kaffe. > > I modified the file $ROOT/Kaffe/Kaffevm/mem/gc-mem.c > to get the malloc/free trace. > I get the "malloc" value from function > "gc_heap_free(void* mem)" and "free" value from > "gc_heap_free(void* mem)". > And I also pulled out and used Java programs from > JVM98 to test my traces. > > Here is my problem for any java program (jess, check, > etc) that I run I get the similar memory trace. The > sizes of the trace files are different (various from > 300K to 80Mb) but the patterns are same. > > I believe, it should not be like this. Is there anyone > who can tell me what I am doing wrong? sorry, I seem to have mislaid my crystal sphere, so without some source code, i can just guess that you're printing nsz instead of sz? However, gc_heap_malloc and gc_heap_free are probably not the right functions to print the malloc and free traces; these functions don't distinguish between memory that's allocated for the java application itself (say for new objects) and memory that's allocated for vm internal data structures. So if you want to exclude the vm internal data structures from your traces, you'll have to put the creation of the traces into gcMalloc and finishGC. Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] failed resgressions on Solaris
On Fri, 29 Aug 2003 13:12:10 + (UTC) Riccardo <[EMAIL PROTECTED]> wrote: Hi Riccardo, > I was able to build kaffe on Solaris/Sparc and regression testing > yielded 7 failed tests, > > CLTestConc.failSoInterrupt.fail > GCTest.failTestUnlock.fail > NetworkInterfaceTest.fail ThreadState.fail > NoClassDefTest.fail > > I attach those files! thanks for the testing ;) Looking at these tests, it occured to me that both jit and jit3 seem to have a problem with unlocking objects while dispatching an exception ?!?? When kaffe encounters a synchronized method somewhere on the stack while dispatching an exception, the monitor of that method has to be unlocked. In order to do this, kaffe calls unlockMutexIfHeld and passes the fp of the stack frame as the where parameter. However, this only works if the fp of the stack frame has also been passed as the where parameter to lockMutex when the method was called. The problem is, that the jit engine calls lockObject to lock a monitor, which passes anything but definitely not the fp of the synchronized method to lockMutex, which means that these monitors cannot be properly unlocked while dispatching the exception. To solve this, it seems that we would either have to invent a way to retrieve the fp of the current method or we'd have to add something like the HAVE_mon_enter in jit3 i386 to jit and the other architectures ? Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] GNU classpath and AWT
On Thu, 14 Aug 2003 17:50:16 +0100 (BST) James Simmons <[EMAIL PROTECTED]> wrote: Hi James, > > I'm not aware of anybody working on porting the Classpath AWT, although > > I think Dalibor is quite active in moving the other parts of Classpath > > into Kaffe. We've already got several AWTs (X11, Qt, Win32), so another > > one is always welcome, I think. I really haven't played with Kaffe's > > AWTs much yet. > > I have been looking into it. Note the classpath stuff is very different > from the current kaffe AWT implementation. It would break the current AWT > support. So I have to port the current stuff to the Classpath format. This > will take some time. i think porting kaffe's current implementation to the classpath format as you've called it will basically involve creating a set of lightweight peers in some kaffe.awt.whatever package and move all the drawing from the widgets in java.awt into the different peers afterwards? And if so, how would this break the current AWT support? It will be totally different, yes, but we wouldn't loose any of the supported backends, would we? Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] completed bytecode verifier!
On Fri, 8 Aug 2003 10:22:58 -0600 (MDT) Timothy Stack <[EMAIL PROTECTED]> wrote: Hi, > > An idea how to fix this? My guess would be to defer verification > > of the superclass until after the subclass is in state CSTATE_LOADED_SUPER > > (and NMS_LOADED). This could probably be done by creating a special > > getClass() that returns a class that is only CSTATE_PREPARED, > > I don't think this will work with user loaders since getClass() calls > loadClass(), which can call a user loader, which can do whatever it wants. Hmm. I thought that a user loader would either return whatever defineClass() returns (when loadClass is called with resolve==false) or what resolveClass() returns (when loadClass is called with resolve==true). Therefore, I thought that we could indeed predict what's returned by a user loader. So it seems I'm once again missing something? > > but not > > CSTATE_LINKED. The subclass would load the superclass using this special > > getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING) > > and process the superclass to CSTATE_LINKED afterwards. That way, the > > verifier would be able to properly resolve the subclass while verifying > > the superclass, but detection of ClassCircularityErrors should still > > work? > > I think the circularity checking is broken, its just checking to see if > there is a loop in calls to loadClass and not checking that its still > trying to load the super class. For example, in this case CMember would > have finished loading its super (java.lang.Object) so there is no > circularity. > > I'm thinking the fix would involve a new class state and classEntry state > that break up the loading of the super class. I'll try to look at it more > over the weekend... Sounds like you'll have a busy weekend, then ;) Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] completed bytecode verifier!
On Thu, 7 Aug 2003 09:46:31 -0600 (MDT) Timothy Stack <[EMAIL PROTECTED]> wrote: Hi Tim, > > I just committed the bytecode verifier. It's a huge chunk of code and > > it's very likely that there are little bugs lurking around in it...I can't > > even count how many off-by-one errors I had during development. > > make check-TESTS > make[1]: Entering directory `/z/stack/tmp0/kbuild/test/regression' > PASS: HelloWorldApp.class.save > error compiling: > java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; ><> > FAIL: HelloWorldApp.java > error compiling: > java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; ><> > FAIL: TestIntLong.java > error compiling: > java.lang.NoClassDefFoundError: Lat/dms/kjc/KjcSignatureParser; ><> I think I managed to figure out what is going wrong here. Hopefully my explanations will not get too confusing. First of all, you might consider applying the attached patch, since it will give you some better error messages in case some type could not be resolved during verification (do you know why getClassFromSignature throws away the einfo from classFromSig?). If you try running $JAVA at.dms.kjc.CSourceClass afterwards, you will see that kaffe thinks that it has detected a ClassCircularityError. Now comes the confusing part, since I'll try to explain what I think is going on here ;) First of all, CSourceClass is derived from CClass, which is derived from CMember (all in package at.dms.kjc). So when kaffe has to load CSourceClass, that will trigger loading CClass and loading CClass in turn will trigger loading CMember. This will cause kaffe to process CMember to state CSTATE_LINKED, while CSourceClass and CClass are both in the CSTATE_LOADED_SUPER state (and their classMappingState is NMS_LOADING). Processing CMember to CSTATE_LINKED however, includes verifcation of the class CMember (both, verify2 and verify3). But in order to do this, the verifier has to resolve the types CSourceClass and CClass (they are needed for type checking during verification of the getAccessorOwner method). Since the verifier uses loadClass() to resolve the type, the ClassCircularityError is thrown (because classMappingSearch detects that the state is NMS_LOADING and that the current thread is responsible for it). Next problem is that the verifier needs a class that is at least in state >= CSTATE_LOADED_SUPER (otherwise it could not check for inheritance). An idea how to fix this? My guess would be to defer verification of the superclass until after the subclass is in state CSTATE_LOADED_SUPER (and NMS_LOADED). This could probably be done by creating a special getClass() that returns a class that is only CSTATE_PREPARED, but not CSTATE_LINKED. The subclass would load the superclass using this special getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING) and process the superclass to CSTATE_LINKED afterwards. That way, the verifier would be able to properly resolve the subclass while verifying the superclass, but detection of ClassCircularityErrors should still work? Greetings, Helmer emsg-patch Description: Binary data
Re: [kaffe] jvmpi
On Fri, 8 Aug 2003 10:24:35 -0600 (MDT) Timothy Stack <[EMAIL PROTECTED]> wrote: Hi, > > > I've checked in some JVMPI stuff. Its not completely done yet, but its > > > a pretty good start. I'll try and get it finish RSN. Hopefully, i > > > didn't break anything... > > > > thanks! I've tried to build kaffe with jvmpi enabled, but it breaks > > during linking because a function is missing. I've modified the > > Makefile.am to link in libkaffevm, and I thought about exporting the > > missing function, but you seem to use it in jvmpi_kaffe.c with a > > different signature, so I'm not sure how to get JVMPI to build ;) > > Whats the function? part of this might be actually my fault. While moving the engine dependent part of the stacktrace handling into different directories, I also modified the handling of stacktraces themself a little bit, but forgot to check whether jvmpi was affected or not :( To make it short, you don't have to call stackTraceFindMethod() anymore in order to determine the struct _methods* of a stackframe, buildStackTrace() already initializes that field. Sorry, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe 1.1.1 "Development" Release available for download
On Mon, 4 Aug 2003 13:19:12 +0900 (JST) Kiyo Inaba <[EMAIL PROTECTED]> wrote: Hi, > Congratulations for periodical development release for Kaffe. But this > version may not work for cross environment. The reason is it introduces > new check for 'in_port_t' and if it fails it tries to determine > 'in_port_size' by executing a test program. This mod is introduced > to support getaddrinfo replacement (this itself is a good news for > old linux users). > > Any way to solve this problem? you could add the necessary "#define in_port_t int" or whatever is appropriate to config/config.h after running configure. We should probably fix the test so you can specify cache variables for this, though. Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] more kjc problems?
Hi, this morning, I wanted to check whether eclipse is still running with kaffe (rt.jar compiled with kjc). However, I got this exception (eclipse specific stuff skipped): java.lang.NullPointerException at gnu.xml.dom.DomNode.dispatchEvent (DomNode.java:1408) at gnu.xml.dom.DomNode.insertionEvent (DomNode.java:438) at gnu.xml.dom.DomNode.appendChild (DomNode.java:541) at gnu.xml.dom.DomAttr.setNodeValue (DomAttr.java:209) at gnu.xml.dom.DomElement.setAttribute (DomElement.java:235) at gnu.xml.pipeline.DomConsumer$Handler.populateAttributes (DomConsumer.java:668) at gnu.xml.pipeline.DomConsumer$Handler.startElement (DomConsumer.java:604) at gnu.xml.dom.Consumer$Backdoor.startElement (Consumer.java:201) at gnu.xml.aelfred2.SAXDriver.startElement (SAXDriver.java:845) at gnu.xml.aelfred2.XmlParser.parseElement (XmlParser.java:1065) at gnu.xml.aelfred2.XmlParser.parseDocument (XmlParser.java:419) at gnu.xml.aelfred2.XmlParser.doParse (XmlParser.java:170) at gnu.xml.aelfred2.SAXDriver.parse (SAXDriver.java:335) at gnu.xml.aelfred2.XmlReader.parse (XmlReader.java:303) at gnu.xml.dom.JAXPFactory$JAXPBuilder.parse (JAXPFactory.java:186) Funny thing is that the offending line in DomNode.java contains nothing but this: dispatchDataLock = false; Afterwards I recompiled kaffe's rt.jar using jikes and was again able to run eclipse just fine, so I assume that the problem is indeed kjc. Looking at the method I'd say that it seems to be the same Problem we had with the ShutdownHookTest. Guilhem, do have an idea what could be going wrong / where I could start to fix this? Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe hkraemer
On Mon, 28 Jul 2003 10:10:19 +0200 Guilhem Lavaux <[EMAIL PROTECTED]> wrote: > > > > > >* libraries/javalib/java/lang/Throwable.java: Replaced with Classpath > >version. > >* libraries/javalib/java/lang/VMThrowable.java: New class. > >* libraries/javalib/bootstrap.classlist: Add VMThrowable. > >* libraries/javalib/essential.files: Add StackTaceElement and > >VMThrowable. > >* libraries/javalib/Klasses.jar.bootstrap: Regenerated. > > > > > Helmer, could you add VMThrowable.java ? it is missing in the > repository. Thanks. Done. Sorry, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] stacktraces and stuff
Hi, sorry for being pretty silent for the last couple of days, I was pretty packed with other stuff (being a student isn't all that funny at times). The patch I've just commited looks pretty big, but doesn't seem to cause any serious damage. Basically it does just three things: * only one version of dispatchException that works for both, the interpreter and the translator; the previous, seperate versions already were somewhat different * moved the engine specific part of stack traces into some new headers in the directories of the different engines * stack trace creation for the jit and jit3 engines should be a little bit faster now (especially the jit). Will grab some food now and have a look at the StackTraceElement stuff afterwards. Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] jvmpi
On Sat, 26 Jul 2003 11:10:46 -0600 Timothy Stack <[EMAIL PROTECTED]> wrote: Hi, > I've checked in some JVMPI stuff. Its not completely done yet, but its > a pretty good start. I'll try and get it finish RSN. Hopefully, i > didn't break anything... you seem to have missed intrp and jit ;) Will check in fixes for those later today. Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items
On 14 Jul 2003 00:11:14 +0200
Mark Wielaard <[EMAIL PROTECTED]> wrote:
Hi,
> - StackTraceElement stuff ("pure java Throwable"). Mark has some
> code hacked up. It compiles... but crashes in spectacular ways.
> -> Goal log4j (used by either JBOSS or Tomcat) uses XMLized stacktraces
> from StackTraceElements.
i've got a working version of this in my local tree
(jetty for jdk 1.4 was working fine with it), but
somehow didn't get around to commit it :( Could you
probably post a patch of your implementation so I
can fix and commit it?
Greetings,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe CVS: kaffe dalibor
On Tue, 08 Jul 2003 23:47:55 -0700 Kaffe CVS <[EMAIL PROTECTED]> wrote: Hi, > Log message: > 2003-07-09 Dalibor Topic <[EMAIL PROTECTED]> > > * libraries/javalib/bootstrap.classlist: > Added missing files. Removed kaffe.lang.Application. I think we could also delete all the other Application* related stuff in kaffe.lang, couldn't we? Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Eclipse and strange ClassCastException
On Mon, 7 Jul 2003 15:51:08 +0200 Helmer Krämer <[EMAIL PROTECTED]> wrote: Hi again, > Next problem is a failure in System.arraycopy() I've just commited a fix for this one. If I start eclipse with this command line: LD_LIBRARY_PATH=plugins/org.eclipse.swt.gtk_2.1.0/os/linux/x86 ./eclipse -debug -vm /usr/local/kaffe/bin/java it's running for some time, then complains that the workspace layout could not be restored and finally quits with an OutOfMemoryError Greetings, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Eclipse and strange ClassCastException
On 07 Jul 2003 12:39:04 +0200 Mark Wielaard <[EMAIL PROTECTED]> wrote: Hi, > > From what I know about eclipse, I would assume that the > > PlatformClassLoader should not be able to find that class, > > should it? > > Actually it should but it does so in a tricky way and then removes (!) > those classes again from the classloader. > This looks like it might be the same problem that IKVM.NET had: > http://weblog.ikvm.net/PermaLink.aspx/66 hmm. That sure looks a little bit weird, but I think it's ok. And it definitely worked before we implemented the AppClassLoader stuff It finally turned out to be a bug in java.net.URLClassLoader: java.net.URLClassLoader.findClass() tries to find the .class file using findResource(). PlatformClassLoader.findResource() however delegates the call to findResource() to the xmlClassLoader which succeeds in loading that resource, which in turn causes the PlatformClassLoader to succeed in loading that class :( Fix is in CVS. Next problem is a failure in System.arraycopy() Thanks, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
