We might be missing some null checks at the moment. Go through all uses of JSVAL_IS_PRIMITIVE and double check (and use JSVAL_IS_OBJECT) instead. No known instances so not making this a beta1 blocker. Low threat (result is NULL deref, not random pointer).

Fixed title to be more accurate.

Near the top of jstracer.cpp, we should #undef JSVAL_IS_PRIMITIVE and #define it to JS_STATIC_ASSERT(0) as Andreas did for JSVAL_IS_BOOLEAN. All record-time tests should JSVAL_IS_OBJECT instead, and we need runtime null checks (sigh). Or (better): we fix bug 457363 at least to give null separate type. Having void (or hole) be a pseudo-boolean (booloid, jorendorff coinage ;-) is not as bad as having null inhabit object type, in terms of extra guards (runtime overhead). We have a zero-perf-regression-for-correctly-compiled-code policy, so it seems to me we need to look at fixing the null-inhabits-object-type problem. /be

I am warming up to the separate null type. Looking at code it seems the null case has a very different control flow and we almost never actually trigger a null check. Instead there is an if control-flow explicitly around it, so we will split the trace there anyway. If we do that, we can as well split on the type a bit earlier.

Fixed in checkin for bug 465460?

As summarized, invalid because of the better solution landed in the patch for bug 465460. #undef'ing JSVAL_IS_OBJECT and JSVAL_IS_PRIMITIVE (to redefine those as static asserts of 0) looked like too much trouble (just the latter requires the former). If anyone thinks otherwise, new bug on that. /be