JavaScriptCore Conservative Garbage Collector
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.
On Jun 9, 2005, at 1:35 PM, Justin Haygood wrote:
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.
Marking conservatively means marking every object that is pointed to by any value on the stack (or in registers). What "conservative" refers to here is that a value on the stack might look like a pointer, but actually be a value of another type that just happens to look like a pointer, or even uninitialized data. Thus an object that's actually garbage might not get collected, hence the collector is "conservative" in keeping it alive. You'll need a threading library that does give a way to find the stack of each thread, so you may not be able to use NSPR. -- Darin
On Jun 9, 2005, at 8:45 PM, Darin Adler wrote:
On Jun 9, 2005, at 1:35 PM, Justin Haygood wrote:
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.
Marking conservatively means marking every object that is pointed to by any value on the stack (or in registers). What "conservative" refers to here is that a value on the stack might look like a pointer, but actually be a value of another type that just happens to look like a pointer, or even uninitialized data. Thus an object that's actually garbage might not get collected, hence the collector is "conservative" in keeping it alive.
The Wikipedia page <http://en.wikipedia.org/wiki/Garbage_collection_% 28computer_science%29> mentions this. Look for "partly conservative" in the page. Some super-great things about the conservative garbage collector are that it eliminates: the need for smart pointer wrappers for JavaScript objects, the need for a few flags that every object used to have (besides the mark bit), ambiguity about when to use smart pointer wrappers and when not to, and most if not all subtle rules about how to use the JavaScript object pointers properly. It made the library faster when we first switched to it, largely because of the time not spent doing ref and deref all the time. And it will make things even faster when we take further advantage of simplifications it made possible. We can get much better performance for code that doesn't involve wrappers. C++ compilers don't do so great at optimizing when there are objects that have a single pointer in them -- the fact that the this pointer is a pointer to that pointer tends to make them not generate code that's as good as simple pointer manipulation. -- Darin
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).
On Jun 9, 2005, at 10:28 PM, Maciej Stachowiak wrote:
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).
Actually I cited the wrong list here, webkit-reviews is the place to send patches. Webkit-changes is the place to find out about commits as they go in. Ignore the man behind the curtain. Regards, Maciej
participants (3)
-
Darin Adler
-
Justin Haygood
-
Maciej Stachowiak