[Gc] RE: NetBSD patch

Jérôme Laban jlaban at wanadoo.fr
Thu Jul 8 15:03:30 PDT 2004


 

> -----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
> > 
> 



More information about the Gc mailing list