To make sure that jsval present on the native stack are not used outside a request and that the conservative GC always scan them it would be useful to assert that js::Value is constructed/destructed only when a request is active on the current thread.

The ctors take no cx param, nor should they -- and getting TLS is costly. This may be too much for DEBUG. /be

Also, Gregor actually had me remove the only constructor recently because it technically causes JSObject to have a constructor (fslots) which Gregor wants to put in a union (which, infuriatingly enough, C++ does not allow if JSObject has a constructor).

(In reply to comment #1) > The ctors take no cx param, nor should they -- and getting TLS is costly. This > may be too much for DEBUG. My plan is to use __thread on platforms where it works and is fast. For other cases a global counter with atomic ++/-- representing the request count could be used. This is not ideal, but should help FF code base. (In reply to comment #2) > Also, Gregor actually had me remove the only constructor recently because it > technically causes JSObject to have a constructor (fslots) which Gregor wants > to put in a union (which, infuriatingly enough, C++ does not allow if JSObject > has a constructor). To support js::Value with a constructor a union can use jsval and hide the fact with access macros.

This was set as beta2+, but after beta2 was already finished, so moving to beta3+ Sayrer: you may wish to re-triage, not sure if this is going to make the Monday Aug 2 code freeze.

Looks like a speculative stability improvement to me, not a hard blocker.