[kaffe] Porting of Kaffe

[Nathan Carl Summers]

On Tue, 2 Sep 2003, Timothy Stack wrote:

> >
> > I am part of a team porting Kaffe to a Cray.  I would like to find someone
> > who has an understanding of why the locks were implemented with hidden stack
> > variable (the "where" in _lockMutex).  It is causing great consternation in
> > light of the Cray stack.
>
> Can you explain whats unique about the cray stack or give a pointer?

Unicos starts by allocating a relatively small stack. Every function that
uses the stack has a preamble that checks to see if the stack is large
enough, and if it is not, it calls a function with the enigmatic name of
$STKOFEN.  $STKOFEN first tries to increase the size of the stack to the
required amount, but if this is not possible (because the memory after the
stack is already allocated) it will allocate another block (using what is
essentially malloc).  A structure at the end of each stack segment
contains an offset that can be used to find the previous segment, so the
stack is essentially a linked list.  $STKOFEN also manipulates the call
stack so that the function that caused a new block to be allocated will
return to a deallocation routine, which after deallocating jumps to the
true return address.

> > It also seems rather hostile to someone trying to
> > use a mutex, since it is not documented very well.  I have changed locks to
> > use a structure within locks itself and tracking the TID of the lock holder.
> > Is there someone that could comment on this approach?
>
> Can you elaborate on this?  The latte project, an offshoot of kaffe, have
> a superior lightweight lock implementation, rolling those in might be
> better.
>
> > We are also finding that the debug code is not very friendly on an MP.  The
> > movement of data to the debug buffer is not protected by a mutex and, thus,
> > becomes a difficult tool.  Is there anyone that has ported Kaffe to an MP?
>
> dunno, but, I would imagine there are many many race conditions.

Truly kaffe has never been run on an SMP box before?  That's surprising.

> Can you use the user-level threading implementation instead of native
> threads, atleast for now?

There are two problems with that that I see:
1) the user-level threads make even more use of carnal knowledge of the
stack.  Since the cray stack is nothing like the stack that code assumes,
porting will be fun.

2) the stock cray longjmp frees any stack segments allocated by the calls
in-between the setjmp call and longjmp, and is therefore not usable for
the setjmp/longjmp threading trick.  There is a replacement setjmp/longjmp
implementation floating around, but it never deallocates stace segments,
causing them to be leaked, and causes data corruption for some reason.

Rockwalrus