[Gc] Scanning the System Stack

Boehm, Hans hans.boehm at hp.com
Mon Apr 5 16:53:14 PDT 2004

It's not clear that it's very meaningful to ask for the stack pointer without
suspending the target thread.  If the target is not stopped, its stack pointer
may be completely different by the time you get the answer back.  And you wouldn't
see s consistent state of the stack for tracing, and hence might lose

Of course you have a lot more alternatives if you can teach the target thread to

I don't think there is a pthreads call for retrieving the sp value.  You
might also be able to use ptrace.  I haven't looked into it.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Okehee Goh
> Sent: Friday, April 02, 2004 1:18 PM
> To: 'C. Scott Ananian'; 'Andrew Begel'
> Cc: wlight at weatherlight.com; gc at napali.hpl.hp.com
> Subject: RE: [Gc] Scanning the System Stack
>  I looked at linux_threads.c using pthreads.
>  I noticed that the thread initiating GC sends SIGSUSPEND to all other
> threads. A signal handler for that associated with threads 
> receiving the
> signal actually checks a stack top (by calling GC_approx_sp()) and
> records that as thread->stack_ptr into GC_thread tables. Here, the
> thread initiating GC are blocked by calling sem_wait() to 
> wait until the
> threads receiving the signal finishes the work.
>  I'm wondering whether there is another way to get a stack 
> top w/o being
> blocked? Is sending a signal only way to get it in pthreads?
>  Regards,
>  Okehee
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com]
> On Behalf Of C. Scott Ananian
> Sent: Tuesday, March 30, 2004 7:42 AM
> To: Andrew Begel
> Cc: wlight at weatherlight.com; gc at napali.hpl.hp.com
> Subject: Re: [Gc] Scanning the System Stack
> On Tue, 30 Mar 2004, Andrew Begel wrote:
> > With pthread-based threaded execution, each stack start 
> could be at a
> > completely unknown location, specifiable at 
> pthread_create(), but not 
> > retrievable afterwards. Without this information (except on MacOSX)
> you 
> > can't scan the stack because you don't know where it starts.
> Not quite.  The way the BDW collector does this "portably" is by
> wrapping the pthread_create() call so that it first invokes a BDW
> method, which
> *then* turns around and calls your thread start method.  The 
> BDW method
> knows that there's nothing "important" on the stack yet, so it just
> looks at its own stack pointer at that instance and uses that 
> as "start
> of stack".  To find your own stack pointer quasi-portably:
> void *approx_sp() { int a; return &a; }
> The original poster also asked about registers. The collector must
> seemingly ensure that all caller-save registers have found 
> their way to
> the stack before gc starts.  There's no "portable" way to do 
> this (that
> I know of); there's some OS-dependent code which usually finds the
> registers somewhere in the thread structure after the thread has been
> stopped.  You probably want to look at the source files which 
> start with
> "pthread" and in particular at the function GC_push_all_stacks().  A
> clear example of pushing registers is in the 
> aix_irix_threads.c version
> of GC_push_all_stacks().  Note also that there is a function called
> 'GC_save_regs_in_stack()' for some architectures.
> If it turns out to matter, I'm looking at version 6.2 of the BDW
> collector.
> Hope this helps!
>  --scott
> non-violent protest operation SDI General Morwenstow Milosevic AES 
> MI5 Seattle Waco, Texas East Timor affinity group Kojarena Columbia 
>                          ( https://cscott.net/ )
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 

Gc mailing list
Gc at linux.hpl.hp.com

More information about the Gc mailing list