From: Godmar Back (gback@cs.utah.edu)
Date: Fri Jan 29 1999 - 12:14:03 EST
Edouard,
the reason we switched from setjmp to sigsetjmp was because
setjmp would do a system call to save the signal mask every time a
thread switch occurred on FreeBSD.
However, sigsetjmp allowed us to disable that behavior by setting
the second arg to false.
Posix does not specify whether setjmp saves the state or not, but
sigsetjmp has that special flag, that's why we used it.
If the situation on SVR4 is such that the normal setjmp is indeed
what we want, namely a thread switch that does not save the signal
state, then by all means we should keep using setjmp there and not
muck with the context stuff, which as I understand it is more of
an internal implementation detail of their hybrid user mode thread
implementation anyway.
So if setjmp worked for you before, then let's #define SETJMP setjmp
or some such and include "md.h" and define it differently.
If you want to get the context stuff to work, fine. It appears to me
though that on your system, the plain setjmp may be faster --- but
only you'll know for sure.
- Godmar
>
> Godmar,
>
> > which solution do you prefer:
> > switching to the *context functions or using #ifdef for sigsetjmp
> > or setjmp? In the latter case, we'd probably define a machine-dependent
> > macro SETJMP or some such.
> I'm trying with CONTEXT_INITIALIZE(JTID) and CONTEXT_SWITCH()
> macros.
>
> CONTEXT_SWITCH(LAST, CURRENT) \
> swapcontext(&(LAST)->env, &(CURRENT)->env)
>
> CONTEXT_INITIALIZE(JTID) do { \
> jthread *jtid = (JTDI); \
> ucontext_t *uc = &jtid->env; \
> sigaltstack(NULL, NULL); \
> getcontext(uc); \
> uc->uc_stack.ss_sp = jtid->stackBase; \
> uc->uc_stack.ss_size = jtid->stackEnd - jtid->stackBase; \
> uc->uc_stack.ss_flags = 0; \
> makecontext(uc, start_this_sucker_on_a_new_frame, 0); \
> } while(0)
>
> jthread_create() became:
> #if defined( CONTEXT_INITALIZE )
> CONTEXT_INITIALIZE(jtid)
> #else
> if (sigsetjmp(jtid->end, false) == 0)
> ...
>
> #endif
> resumeThread(jtid);
>
> I need an other macro for the type of jtid->env
> but as it's the same for me, I try without that.
>
>
> But it fail :(
>
> Edouard.
> > Hmmm, did that break Solaris 5.x too?
> I don't know
> >
> > - Godmar
> >
> > >
> > > Hi,
> > >
> > > for SVR4 with getcontext(), makecontext() and swapcontext()
> > >
> > > #include <ucontext.h>
> > >
> > > ucontext_t newCtx;
> > >
> > > /* retreive current context */
> > > getcontext(&newCtx);
> > >
> > > /* setup new stack */
> > > newCtx.uc_stack.ss_size = stack size;
> > > newCtx.uc_stack.ss_sp = ALLOC(stack size);
> > > newCtx.uc_stack.ss_flags = 0;
> > >
> > > /* reinitialize context with new stack and more */
> > > makecontext(&newCtx, func, 0);
> > >
> > > ...
> > >
> > > /* context switch */
> > > swapcontext(&lastThread->context, ¤tJThread->context);
> > >
> > >
> > > That all.
> > >
> > > Hope this help,
> > > Edouard.
> > >
> > > > -----Original Message-----
> > > > From: Parmelan, Edouard
> > > > Sent: Friday, January 29, 1999 2:37 PM
> > > > To: 'Godmar Back'
> > > > Cc: 'kaffe-core@rufus.w3.org'
> > > > Subject: RE: sigsetjmp & sigaction survey
> > > >
> > > > Godmar,
> > > >
> > > > I just test new jthread with sigsetjmp/siglongjmp and
> > > > it fail on NCR MP-RAS :(
> > > >
> > > > 1. SP_OFFSET is not the same for jmp_buf and sigjmp_buf
> > > > 2. sigsetjmp and siglongjmp are in fact getcontext() and
> > > > setcontext(). These two system calls use an ucontext_t
> > > > as parameter.
> > > >
> > > > I change SP_OFFSET to point to ucontext->mc_ucontext.greg[SP],
> > > > the STACK_COPY don't SEGV, good. But reschedule() fails with
> > > > the assert (lastThread == currentJThread), not good :(
> > > >
> > > > It seems that changing the value of SP in an ucontext don't
> > > > work :(
> > > >
> > > > I think that jthread_create() should use an helper function
> > > > (aka in assembler language) that changes the stack, calls sigsetjmp()
> > > > in that new stack, and finaly restores the original stack.
> > > >
> > > > With this behavior, jthread don't need any more the glue of SP_OFFSET
> > > > as the sigjmpbuf will save the context of the new stack.
> > > >
> > > >
> > > > Bad news for my last message from NCR :(
> > > >
> > > > Remember, don't send comments to address @...France.NCR.COM,
> > > > I'll leaving my job at NCR France in about three hours :)
> > > >
> > > > Edouard.
> > > >
> > > > > -----Original Message-----
> > > > > From: Parmelan, Edouard
> > > > > Sent: Thursday, January 28, 1999 7:09 PM
> > > > > To: 'kaffe@rufus.w3.org'
> > > > > Subject: RE: sigsetjmp & sigaction survey
> > > > >
> > > > > Godmar,
> > > > >
> > > > > > Two questions:
> > > > > >
> > > > > > 1. Is anybody using kaffe on a system that does not have
> > > sigsetjmp/siglongjmp?
> > > > > NCR MP-RAS have sigsetjmp/siglongjmp
> > > > > >
> > > > > > 2. Is anybody using kaffe on a system that does not support
> sigaction?
> > > > > NCR MP-RAS have sigaction
> > > > >
> > > > > > The reason I'm asking is because Pat wrote an optimized version of
> > > > > > jthreads that uses sigsetjmp and avoids saving the signal state in
> > > many
> > > > > > cases where we switch threads. On FreeBSD, this cuts thread
> switching
> > >
> > > > > > time from 1400 to 450 cycles, and we may be able to go down to 180
> > > cycles,
> > > > > > as measured from Java.
> > > > > Magic :)
> > > > >
> > > > > > Now why we would optimize thread switching when the rest of kaffe
> > > > > > still sucks so much, don't ask. The answer is: research.
> > > > > The answer is: better kaffe
> > > > >
> > > > > Edouard.
> > >
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:53 EDT