Thread stack pointers

[David Daney]

Delvin Defoe wrote:
> Does this mean if I define sigaction act, set the handler as follows,
> // for stack processing
> act.sa_handler = _otf_process_stack;
> sigemptyset(&act.sa_mask);
> act.sa_flags = 0;
> 
> signal the thread in the following manner
>  if (tkill(m->_tid,i+1) == -1)
>      fprintf (stderr, "***** tikll failed for thread  %d \n. *****", 
> m->_tid);
> 
> define the sa_handler function accordingly
> 
> _otf_process_stack (int signo)
> 
> the stack top for the thread that receives the signal can be give by
> something like
> stack_top = &signo + sizeOf(pointer)?
> 

That is essentially correct.  You don't have to add sizeof(pointer) as 
the signal handler has no references to any java objects.  All of the 
valid references on the stack will be quite a bit above the stack frame 
of the signal handler.  The signal handler is just a convenient lower 
bound.  If you want the real value you could extract it from the saved 
machine state in the signal handler's siginfo structure, but that makes 
the code very machine dependent.

> 
> 
> Thanks,
> 
> Sorry about my previous imcomplete post.
> 
> Delvin
> On 3/21/07, David Daney <ddaney@avtrex.com> wrote:
>> Delvin Defoe wrote:
>> > Hi:
>> >
>> > I am implementing a multi-thread, multiprocessor garbage collection
>> > system for Java in gcc.  In the runtime system I need to determine the
>> > stack base and stack top pointers for each mutator in order to scan
>> > the stack for each mutator for pointers to live heap objects.   Any
>> > idea how I can determine or compute these pointers?
>> >
>> Generic answer:
>> How about doing the same thing boehm-gc does?
>>
>> For linux, you would have each thread is register with the GC when it is
>> started.  In this registration function you find the address of
>> something on the stack of that thread, then look in /proc/self/maps to
>> see what memory range contains that address.  That range will be your
>> stack bounds.
>>
>> To find the stack top, send a signal to a thread, and then the stack top
>> will be slightly above the address of an automatic variable of the
>> signal handler function.
>>
>> David Daney
>>
> 
>