> 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 c
> >
> > 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 rel
> > > 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
> > > You're right. We can't have strings pending to be destroyed in the
> > > intern table when there's a chance others might try to intern
> > > identical strings. So we must synchronize against the intern lock
> > > somehow, ideally without deadlocking.
> >
> > Perhaps the intern'd string ta
> Godmar wrote:
> > You're right. We can't have strings pending to be destroyed in the
> > intern table when there's a chance others might try to intern
> > identical strings. So we must synchronize against the intern lock
> > somehow, ideally without deadlocking.
>
> Perhaps the intern'd strin
Godmar wrote:
> You're right. We can't have strings pending to be destroyed in the
> intern table when there's a chance others might try to intern
> identical strings. So we must synchronize against the intern lock
> somehow, ideally without deadlocking.
Perhaps the intern'd string table should
Hi there,
For Kaffe 1.0.6. I hit a core dump in running a simple test program. Stepped
it through GDB and it core dumped in initialize the VM.
The call stack looks like this:
#0 soft_fixup_trampoline (meth=0xafca4, where=0xafcb4) at soft.c:553
#1 0xef7629b8 in sparc_do_fixup_trampoline ()
#2 0
--- cfowler <[EMAIL PROTECTED]> wrote:
> Has anyone here been successful with Kaffe
> communicating to MySQL via
> JDBC? Any reccomended drivers?
Does this mean that you are having problems ? ;)
Seriously, which drivers did you try and what kind of
error message did you get?
regards,
dalibor
You're right. We can't have strings pending to be
destroyed in the intern table when there's a chance others might
try to intern identical strings.
So we must synchronize against the intern lock somehow,
ideally without deadlocking.
- Godmar
>
> >
> > Godmar wrote:
> > > The stri
>
> 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
>
> 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
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 ma
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 string
CVSROOT:/cvs/kaffe
Module name:kaffe
Changes by: jim 02/06/05 11:42:13
Modified files:
libraries/javalib: Tag: Release_1_0_7_Branch Klasses.jar
Log message:
Regen Klasses.jar (on branch) - hopefully fixes java.lang.Cloneable version number
issue
_
The version of Cloneable that kaffeh saw during the build process
must match the version of Cloneable kaffe sees during initialization.
If you update Cloneable, you must built a new Klasses.jar first and
then you can recompile the VM using the new version of Klasses.jar
- Godmar
_
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
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
Hi alexander,
--- Alexander Popov <[EMAIL PROTECTED]> wrote:
> 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)
* does current cvs mean trunk or 1.0.7 branch?
* cou
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 RTOS&JVM
ProSyst Bulgaria
[EMAIL PROTECTED]
[EMAIL PROTECTED]
mobile: +
On Wed, 5 Jun 2002, Jukka Santala wrote:
> export PATH=/skiff-2.96/local/bin:/skiff-2.96/local/arm-linux/bin:$PATH
> ../kaffe/configure --with-x
I should note I also tried out various parameters from the debug &
profiling categories, as well as static linking, and none of those
parameters that I
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
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
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:
>>
>>[/software/jdk
I've changed it in Cloneable.java but that didn't fix the problem...
It seem like 101.00 is taken from somewhere else...
in Cloneable I've changed :
int KAFFE_VERSION = 1 * 1 + 1 * 100 + 0
to
int KAFFE_VERSION = 1 * 1 + 6 * 100 + 0
Regards,
Dalibor Topic wrote:
> Hi alexander,
>
>
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
>
/software
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
/software/jdk/KAFFE/CVS-current/libraries/javalib/lib:/darcy/software/jdk/KAFFE/CVS-current/l
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!
>so
I usually strip all the classes that I don't need, this saves me more
than 1MB from the rt.jar, then I remove the librarries that I don't need
and strip all other libs and binaries (from the Binaries I leave only
Kaffe).
Maybe it'll be a good idea to exetnd the power of the configure script
i
28 matches
Mail list logo
