[Gc] RE: NetBSD patch

Boehm, Hans hans.boehm at hp.com
Fri Jul 9 15:52:46 PDT 2004


I don't think you really need RT signals for this.  Those are used primarily
because they're not dedicated to other purposes.  On some platforms we use
non-RT signals (usually SIGXCPU and SIGPWR).

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Jérôme Laban
> Sent: Thursday, July 08, 2004 3:04 PM
> To: gc at napali.hpl.hp.com
> Cc: 'Marc Recht'
> Subject: [Gc] RE: NetBSD patch
> 
> 
>  
> 
> > -----Original Message-----
> > From: Boehm, Hans [mailto:hans.boehm at hp.com] 
> > Sent: jeudi 8 juillet 2004 02:05
> > To: 'Jérôme Laban'
> > Cc: Boehm, Hans
> > Subject: RE: NetBSD patch
> > 
> > Thanks for your effort.
> > 
> > Unfortunately, I think that it will be tricky to get this to 
> > work reliably with pthread_suspend_np.
> > 
> > Sending the signal with the following handshake normally 
> > accomplishes two things:
> > 
> > 1) It arranges for the target thread to be stopped.
> > 
> > 2) It forces the thread's register contents onto the thread 
> > stack, where the collector can see them.
> >
> 
> I have to admit that my knowledge in general GC theory is not 
> very deep. I
> did not see this register issue. This could explain some 
> instability issues
> I have been experiencing, the GC not being able to get the 
> registers values
> and collecting memory that should not be collected.
> 
> > 
> > I'm not sure whether pthread_suspend_np guarantees that the 
> > target is suspended when the function returns.  On some other 
> > platforms it doesn't.  And you can't do a handshake at that point.
> > 
> 
> Indeed. I am not sure about the behavior of NetBSD's pthread 
> implementation
> in this particular case.
> 
> >
> > I suspect that the thread registers end up in kernel space 
> > somewhere.  Thus you may have to retrieve them with ptrace or 
> > the like.
> > 
> 
> Yes, but using ptrace and the like to get these values might 
> be a little
> overkill...
> 
> >
> > Is there a reason to do this rather than using signals?  On 
> > Linux, the signal mechanism isn't terribly slow.  And there 
> > is potential for avoiding it for voluntarily blocked threads, 
> > which typically include most threads in systems with large 
> > numbers of threads.
> > 
> 
> I did this for a simple reason: I could not get the RT 
> Signals to work on
> NetBSD 2.0_Beta, mainly because these are not exposed oustide 
> the kernel. I
> only thought then that only stopping all the threads was the 
> intent by using
> signals; and not retreiving registers content. I think I will 
> try to get the
> RT signals to work instead.
> 
> Thank you for your really fast answer and for the precisions 
> about all this.
> 
> Jerome
> 
> > 
> > Hans
> > 
> > > -----Original Message-----
> > > From: Jérôme Laban [mailto:jlaban at wanadoo.fr]
> > > Sent: Wednesday, July 07, 2004 3:27 PM
> > > To: Hans.Boehm at hp.com
> > > Subject: NetBSD patch
> > > 
> > > 
> > > Hi hans,
> > >  
> > > My name is Jerome Laban and I am currently working on a 
> patch that 
> > > allows the GC to use the native pthread library that can be 
> > found on 
> > > NetBSD 2.0.
> > >  
> > > Compared to the other pthread implementations, this patch 
> is using 
> > > pthread_suspend_np and pthread_resume_np, which allows a "true" 
> > > suspension of the threads, compared to the signal 
> blocking "trick".
> > >  
> > > There are still some areas that are a little fuzzy, mainly 
> > because it 
> > > is relying on beta software. Putting aside this problem, the 
> > > implementation needs extensive testing on that platform, 
> > but I think 
> > > I've isolated the changes to the NetBSD 2.0 platform.
> > > I am using this updated GC on the Mono project 
> > (www.go-mono.com) and I 
> > > experiencing some strange problems that seem to be related to the 
> > > pthread library when used from the GC. I am still not able 
> > to isolated 
> > > them because in simple code these instabilities do not 
> > appear. I will 
> > > also distribute this patch to the NetBSD gurus for further more 
> > > testing.
> > > The patch is attached to this mail.
> > > Thank you for you time.
> > > --
> > > Jérôme Laban
> > > {Epitech.}
> > > http://www.labtech.epitech.net/blogs/jaylee
> > > 
> > 
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list