-
ggaren@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=98603 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateBasicJSObject): Use JSObject::allocationSize() for a little more flexibility. We still pass it a constant inline capacity because the JIT doesn't have a strategy for selecting a size class based on non-constant capacity yet. "INLINE_STORAGE_CAPACITY" is a marker for code that makes static assumptions about object size. * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateBasicJSObject): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: Ditto for the rest of our many execution engines. * runtime/JSObject.h: (JSC::JSObject::allocationSize): (JSC::JSFinalObject::finishCreation): (JSC::JSFinalObject::create): New helper function for computing object size dynamically, since we plan to have objects of different sizes. (JSC::JSFinalObject::JSFinalObject): Note that our m_inlineStorage used to auto-generate an implicit C++ constructor with default null initialization. This memory is not observed in its uninitialized state, and our LLInt and JIT allocators do not initialize it, so I did not add any explicit code to do so, now that the implicit code is gone. (JSC::JSObject::offsetOfInlineStorage): Changed the math here to match inlineStorageUnsafe(), since we can rely on an explicit data member anymore. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131093 268f45cc-cd09-0410-ab3c-d52691b4dbfc
ac950c47