[kaffe] Re: Re: Re: Re: Re: Kaffe GC performance, Boehm GC issues

[Kiyo Inaba]

Dalibor Topic wrote:
>Kiyo Inaba wrote:
>> I found it can be extended until major classpath resync on Jan of
>> 2007 if I revert the mod for 'kaffe/kaffevm/baseClasses.c'. The change
>> made in 'baseClasses.c' (v 1.76) is reorder the invocation of
>> initialization (initializeSecurity and initThreads). I have no clear
>> idea whether this reorder is really needed or not, but I guess this
>> modification should be reverted.
>
>It was needed to make Classpath's java.util.zip implementation work. The
>commit was
>
>2006-08-09  Dalibor Topic  <robilad at kaffe.org>
...
>Basically, during the initialization of security code, the Classpath zip
>implementation ends up triggering use of thread local variables, and
>that requires that the threading system is already initialized for it to
>work.

I noticed this log, just after I sent the previous mail. And your
explanation is understandable.

>> On the other hand, snap 060803 can not be compiled on arm/linux because
>> of 'pthread_support.o' does not contain any external symbols and linking
>> reports several 'undefined symbol' errors. I guess this is because of
>> some (tricky) 'ifdef' in boehm gc package, but I did not found a way
>> to fix. Others tackling this is very welcome.
>
>My current results with boehm-gc are a bit across the map (i386-linux,
>boehm-gc 6.8, different compilers, CVS head).

This report is very interesting for me.

I tested boehm with three systems.
1) i386, gcc version 3.2 20020903, Red Hat Linux 8.0 3.2-7
2) i386, gcc version 3.2.3 20030502, FC5
3) i386, gcc version 4.1.1 20060525, FC5

If I use CVS head, and boehm-gc 6.8, they all fail. Testing HWA generates
nothing :-< Could you guess any reason why it happens?

And also, are there any hint why 'undefined symbols' occurs on arm/linux?

Kiyo