TM: Treat undefined and null as separate types?

RESOLVED WONTFIX

Status

()

enhancement
RESOLVED WONTFIX
11 years ago
8 years ago

People

(Reporter: gal, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

No description provided.
Severity: normal → enhancement
The latest patch in bug 465460 separate null from object tracing typemap-type, successfully AFAICT. To keep this bug useful we could morph it to be about undefined, although I'm not sure there's much win in separating undefined from boolean typemap-type.

/be
From the point of view of comparisons, making |undefined| its own type isn't particularly critical.  It NaNifies and stringifies simply, and while relational comparisons with |NaN| are a little touchier, it's not that bad, plus such comparisons are going to be rare in real-world code.  |null|'s problem is that it unnecessarily drags in valueOf and toString wherever it goes, so it's not at all simple -- a whole different kettle of fish from |undefined|.  A type for |undefined| would be nice but not important.

Andreas threw out the suggestion of giving each type its own |undefined| value to allow staying on traces longer for variables that start out unassigned, and the like, but I'm guessing the necessary undefined-checking at many junctures makes it a non-starter.
(In reply to comment #2)
> From the point of view of comparisons, making |undefined| its own type isn't
> particularly critical.

I think it does add an extra `cmp eax,1` when we take the |false| branch after a comparison (that is, xt guards require an extra LIR_eq instruction).  But you're probably right, it's not a big deal.

What if it's just error-prone?  IIRC, we've had bugs where the culprit was |undefined| posing as a boolean.

> Andreas threw out the suggestion of giving each type its own |undefined| value
> to allow staying on traces longer for variables that start out unassigned, and
> the like, but I'm guessing the necessary undefined-checking at many junctures
> makes it a non-starter.

I agree.
We've had bugs, sure, but it doesn't feel like it's been such a large quantity that it's important to take steps to make it go away, absent other reasons to do so, given that it does come at even further cost in representable integer-space.
That the JSVAL_IS_* macros doing the right in this respect helps avoid many such problems.  Bug 463243 would further ameliorate this concern (*nudge*, Brendan ;-) ).

This isn't to say that being able to segregate |undefined| wouldn't be nice, but it doesn't provide quite the gains of segregating |null|, in my view.
Obsolete with the removal of tracejit.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.