[webkit-dev] JavaScriptCore Conservative Garbage Collector

[Maciej Stachowiak]

On Jun 9, 2005, at 1:35 PM, Justin Haygood wrote:

> I want to know pretty much what the reason behind each of these  
> are, so I can better implement it using another also portable  
> threading library (NSPR):
>
> markCurrentThreadConservatively()
> markOtherThreadConservatively(Thread *thread)
>
> What does mark conversatively mean? NSPR doesn't have a way to  
> access the stack objects of each thread, so I'm in a bit of a bind.  
> The NSPR threading library does have pretty much everything else a  
> threading library needs, and is very clean.

Hi Justin,

Besides Darin's comments, I'll add the following:

All you really need to get a JavaScriptCore that works with WebCore  
is markCurrentThreadConservatively(). All the logic for marking other  
threads could be left out. The reason is that WebCore uses  
JavaScriptCore in a completely single-threaded way. The reason we  
take care of marking objects pointed to from other threads is that on  
Mac OS X, other pieces of the system use JavaScriptCore, sometimes in  
a multithreaded way. In fact, CFNetwork, the http loader library we  
use way down under the covers, uses it to parse PAC files on  
background threads. So we need the collector to be threadsafe. But  
this should not be needed if you only want to use JavaScriptCore from  
WebCore.

So, you could probably #ifdef out all the support for marking other  
threads.

I believe the one non-portable construct you will need to find a way  
to do is how to get the stack base of the main thread (or alternately  
the currently running thread, both should be the same). I know that  
on other platforms such as Linux there is a direct call to do this  
that doesn't involve the threading library. I'm not sure about the  
situation on Windows.

Regards,
Maciej

P.S. I see that you've been doing a lot of work to get stuff building  
and working on Windows. I think it would be great to start getting  
your changes in incrementally. Please send patches for the individual  
issues you've addressed to webkit-changes whenever ready (or point to  
a bug report if you put them in bugzilla).