Hi!
hi again,
It looks like i forgot to add some code needed by some other changes, can
you try the attached patch and see if it works. You'll need to run
developers/autogen.sh because theres a configure.in change.
Applying the patch seems to have solved the problem.. :)
Thanks a lot!
sorry
Hi alexander,
--- Alexander Popov [EMAIL PROTECTED] wrote:
Hi
When I try to recompile the java sources I get the
following error:
[/software/jdk/KAFFE/CVS-current/libraries/javalib]#
make Klasses
/bin/sh ./rebuildLib
Compiling classes ...
Classpath: -classpath
I'll put some dumps in kaffe/kaffevm/baseClasses.c and I'll tell you
what exactly happens later today...
Dalibor Topic wrote:
Hi alexander,
--- Alexander Popov [EMAIL PROTECTED] wrote:
Hi
When I try to recompile the java sources I get the
following error:
Sorry Dalibor, my mistake...
KAFFE_VERSION in java/lang/Cloneable.java is really the reason and
should be changed as follows:
int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0;
should be replaced with:
int KAFFE_VERSION = 1 * 100 + 6 * 1 + 0;
I'm attaching a patch for that ( should be applied in
Using latest CVS code of the intended release branch, I managed to
cross-compile the desktop Kaffe for Familiar 0.5.2 release... Using the
standard toolchain for now.
Unfortunately Kaffe's build-scripts aren't very cross-compile considerate
right now, so this took mroe than little of testing and
I'm constantly getting NullPointerException when trying to call
java.lang.String.valueOf(Object obj)...
I'm using the current CVS and linux/x86 (glibc-2.2.4/linux-2.4.16)
Any hints?
Regards,
--
Alexander Popov
Team Leader RTOSJVM
ProSyst Bulgaria
[EMAIL PROTECTED]
[EMAIL PROTECTED]
mobile:
Has anyone here been successful with Kaffe communicating to MySQL via
JDBC? Any reccomended drivers?
Thanks,
Chris
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Oops. My fault. I'll look at it once more...
Cheers,
- Jim
On Wed, 2002-06-05 at 06:37, Alexander Popov wrote:
Sorry Dalibor, my mistake...
KAFFE_VERSION in java/lang/Cloneable.java is really the reason and
should be changed as follows:
int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0;
Godmar wrote:
The string with the dead char array should at this point already be
scheduled for destruction. So one possible way would be to take the
gc_lock and block on intern() if the mustfree is not empty.
That seems like it might work...
A quick hack would be to destroy all strings
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: jim 02/06/05 12:27:23
Modified files:
libraries/javalib: Klasses.jar
Log message:
Regen Klasses.jar (to take care of java.lang.Cloneable version number change
___
kaffe
Hmmm... actually, we could pretty easily have two mustfree lists. One
for objects with destroy methods, and one for all the other objects.
That would accomplish the ordering without too much magic required in
finishGC.
Its not pretty, though.
Not excessively so. This might
Perhaps the intern'd string table should be walked, but only the
char[] objects referenced from it should be marked (not the Strings).
You could mark objects meant to be destroy()ed like objects meant to be
finalized...
I don't think this would work because the char[] could be
I think there was some effort to split these two locks in the
past... there must have been a good reason for that I don't know
if the increased contention for the lock would make any difference (or
the potential recursive acquires)
Not that it would be very relevant in
Another possible less intrusive idea:
Why not just hold the string intern lock while working off the
must-free list. Take it before working off the list, release
it afterwards.
I think we run into the same problem as before though, we can't take the
lock before RESUMEWORLD() because it
14 matches
Mail list logo
