Subj : Re: Pairs of 32-bit pointers To : netscape.public.mozilla.jseng From : "Sterling Bates" Date : Sat Dec 13 2003 12:59 pm "Brendan Eich" wrote in message news:3FDB68D2.1020807@meer.net... > It wastes two words where one will do, compared to tagged jsvals as we > have today, so it's not something that we can accept. Space utilization > matters. This would double the size of obj->slots vectors, double the > size of stack frames, and double the size of atom keys, e.g. Actually you wouldn't necessary have to double the size of the vectors. Just use jsval * instead of jsval as the obj->slots value. Then point to variable[1], bumping back a memory slot if you need to access variable[0]. Moving a pointer around is pretty cheap CPU-wise as I understand it. I think the same would work for stack frames as well, but I don't know how atom keys work :-p When I refer to the variable as jsval variable[2], I'm looking at it as a vector. So you're allocating 64 bits in JS_alloc, but you're passing around a reference to variable[1], which is still a jsval. Additionally, you could use arbitrary bits on variable[0] to trim code in other places. For instance: 1. One bit could represent a rooted GC thing. As I understand gc-ing, this would eliminate the need for a gcroots hash on the runtime. User confusion around GCing might improve too :) 2. Both JSVAL_* (bits 1-3) and JSTYPE_* (bits 4-7) values can be stored there, reducing JS_TypeOfValue(...) to a macro. That could speed up function calls. 3. JSString and jsdouble wouldn't need to be special cases, potentially speeding up code where pointer indirection and private slot work might slow things down. (I know that's a nitpick...) Anyway, this all makes sense with my limited understanding :) Thanks for discussing it. Sterling .