Rob Sayre has posted a good explanation of the Value representation for 32-bit, titled "Mozilla's New JavaScript Value Representation", available at:
http://evilpie.github.io/sayrer-fatval-backup/cache.aspx.htm Since Values are encoded in the NaN-space of doubles, the value boxing scheme does not permit for more available payload and type bits than the current restriction provides. JSVAL_PAYLOAD_MASK enforces this restriction. Solaris isn't a supported platform, so it's unlikely that we'll sacrifice the performance gained by this Value representation for its sake. Is there anything that can be done on the Solaris side to restrict the available memory to only the lower 47 bits of the address space? Sean ----- Original Message ----- From: "Игорь Пашев" <[email protected]> To: [email protected] Sent: Wednesday, October 9, 2013 12:35:12 AM Subject: [JS-internals] JS engine crashes on solaris/amd64 Hi, all. // Please CC me I'm building Firefox for a solaris-based system on amd64 processor, e. i. Firefox is to be an 64-bit application. I've found that during the build xpcshell crashes [1]: js::ObjectImpl::setFlag (this=0x7d7ffbf06040, cx=0x835600, flag_=8, generateShape=js::ObjectImpl::GENERATE_SHAPE) at /home/pashev/packaging/firefox/iceweasel-22.0/js/src/vm/Shape.cpp:1071 warning: Source file is more recent than executable. 1071 if (lastProperty()->getObjectFlags() & flag) (gdb) bt #0 js::ObjectImpl::setFlag (this=0x7d7ffbf06040, cx=0x835600, flag_=8, generateShape=js::ObjectImpl::GENERATE_SHAPE) at /home/pashev/packaging/firefox/iceweasel-22.0/js/src/vm/Shape.cpp:1071 #1 0xfffffd7fcd2ff4d5 in setDelegate (cx=0x835600, this=0x7d7ffbf06040) at ../../../js/src/jsobjinlines.h:820 #2 JSCompartment::getNewType (this=0x835e10, cx=0x835600, clasp=0xfffffd7fcd914820, proto_=..., fun_=0x0) at /home/pashev/packaging/firefox/iceweasel-22.0/js/src/jsinfer.cpp:6278 #3 0xfffffd7fcd2ff832 in JSObject::getNewType (this=<optimized out>, cx=<optimized out>, clasp=<optimized out>, fun=<optimized out>) at /home/pashev/packaging/firefox/iceweasel-22.0/js/src/jsinfer.cpp:6339 .... I've investigated it a bit [2] and found that JSVAL_TO_OBJECT_IMPL() trashes the pointer to stack by applying JSVAL_PAYLOAD_MASK: uint64_t ptrBits = l.asBits & JSVAL_PAYLOAD_MASK; This only matters on amd64, JSVAL_PAYLOAD_MASK is not used on an 32-bit architecture. The value of JSVAL_PAYLOAD_MASK is 0x00007FFFFFFFFFFFLL; it looks like a top of the stack on linux/amd64. But the top of stack on solaris/amd64 is 0xfffffd8000000000 [3]. As a naive effort I've tried to set JSVAL_PAYLOAD_MASK = 0xFFFFFFFFFFFFFFFFLL. Of course it crashed in different place :-) 192 return obj && obj->is<StaticBlockObject>() ? &obj->as<StaticBlockObject>() : NULL; (gdb) bt 6 #0 enclosingBlock (this=<error reading variable: Cannot access memory at address 0x10>) at ../../../js/src/vm/ScopeObject-inl.h:192 #1 js::frontend::FinishPopStatement<js::frontend::ParseContext<js::frontend::FullParseHandler> > (ct=ct@entry=0xfffffd7fffdfd950) at ../../../js/src/frontend/SharedContext-inl.h:92 #2 0xfffffd7fbeb0b760 in js::frontend::PopStatementPC<js::frontend::FullParseHandler> (cx=<optimized out>, pc=0xfffffd7fffdfd950) at /home/pashev/packaging/firefox/iceweasel-24.0/js/src/frontend/Parser.cpp:2669 #3 0xfffffd7fbeb1f987 in js::frontend::Parser<js::frontend::FullParseHandler>::blockStatement (this=this@entry=0xfffffd7fffdfe280) at /home/pashev/packaging/firefox/iceweasel-24.0/js/src/frontend/Parser.cpp:3319 #4 0xfffffd7fbeb1f15f in js::frontend::Parser<js::frontend::FullParseHandler>::statement (this=this@entry=0xfffffd7fffdfe280, canHaveDirectives=false) at /home/pashev/packaging/firefox/iceweasel-24.0/js/src/frontend/Parser.cpp:4785 #5 0xfffffd7fbea9cb6a in js::frontend::CompileScript (cx=cx@entry=0x892830, scopeChain=..., scopeChain@entry=..., evalCaller=..., options=..., chars=chars@entry=0x8ddeb0, length=<optimized out>, source_=source_@entry=0x0, staticLevel=staticLevel@entry=0, extraSct=extraSct@entry=0xfffffd7fffdfea20) at /home/pashev/packaging/firefox/iceweasel-24.0/js/src/frontend/BytecodeCompiler.cpp:271 (More stack frames follow...) (gdb) print obj $1 = (JSObject *) 0xfffb000000000000 (gdb) print *obj Cannot access memory at address 0xfffb000000000000 (gdb) list 187 188 inline StaticBlockObject * 189 StaticBlockObject::enclosingBlock() const 190 { 191 JSObject *obj = getReservedSlot(SCOPE_CHAIN_SLOT).toObjectOrNull(); 192 return obj && obj->is<StaticBlockObject>() ? &obj->as<StaticBlockObject>() : NULL; 193 } 194 195 inline JSObject * 196 StaticBlockObject::enclosingStaticScope() const So I'd like to ask to shed light on why JSVAL_PAYLOAD_MASK exists, how it works, how can I port it on solaris/amd64 or disable it or whatever. [1] http://osdyson.org/issues/145 [2] http://osdyson.org/issues/145#note-2 [3] http://docs.oracle.com/cd/E18752_01/html/816-5138/fcowb.html _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
