2014-01-10 Mark Hahnenberg Copying should be generational https://bugs.webkit.org/show_bug.cgi?id=126555 Reviewed by Geoffrey Garen. This patch adds support for copying to our generational collector. Eden collections always trigger copying. Full collections use our normal fragmentation-based heuristics. The way this works is that the CopiedSpace now has the notion of an old generation set of CopiedBlocks and a new generation of CopiedBlocks. During each mutator cycle new CopiedSpace allocations reside in the new generation. When a collection occurs, those blocks are moved to the old generation. One key thing to remember is that both new and old generation objects in the MarkedSpace can refer to old or new generation allocations in CopiedSpace. This is why we must fire write barriers when assigning to an old (MarkedSpace) object's Butterfly. * heap/CopiedAllocator.h: (JSC::CopiedAllocator::tryAllocateDuringCopying): * heap/CopiedBlock.h: (JSC::CopiedBlock::CopiedBlock): (JSC::CopiedBlock::didEvacuateBytes): (JSC::CopiedBlock::isOld): (JSC::CopiedBlock::didPromote): * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): (JSC::CopiedBlock::reportLiveBytesDuringCopying): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::CopiedSpace): (JSC::CopiedSpace::~CopiedSpace): (JSC::CopiedSpace::init): (JSC::CopiedSpace::tryAllocateOversize): (JSC::CopiedSpace::tryReallocateOversize): (JSC::CopiedSpace::doneFillingBlock): (JSC::CopiedSpace::didStartFullCollection): (JSC::CopiedSpace::doneCopying): (JSC::CopiedSpace::size): (JSC::CopiedSpace::capacity): (JSC::CopiedSpace::isPagedOut): * heap/CopiedSpace.h: (JSC::CopiedSpace::CopiedGeneration::CopiedGeneration): * heap/CopiedSpaceInlines.h: (JSC::CopiedSpace::contains): (JSC::CopiedSpace::recycleEvacuatedBlock): (JSC::CopiedSpace::allocateBlock): (JSC::CopiedSpace::startedCopying): * heap/CopyVisitor.cpp: (JSC::CopyVisitor::copyFromShared): * heap/CopyVisitorInlines.h: (JSC::CopyVisitor::allocateNewSpace): (JSC::CopyVisitor::allocateNewSpaceSlow): * heap/GCThreadSharedData.cpp: (JSC::GCThreadSharedData::didStartCopying): * heap/Heap.cpp: (JSC::Heap::copyBackingStores): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::copyLater): * heap/TinyBloomFilter.h: (JSC::TinyBloomFilter::add): 2014-01-14 Mark Lam ASSERTION FAILED: !hasError() in JSC::Parser::createSavePoint(). https://bugs.webkit.org/show_bug.cgi?id=126990. Reviewed by Geoffrey Garen. * parser/Parser.cpp: (JSC::Parser::parseConstDeclarationList): - We were missing an error check after attempting to parse an initializer expression. This is now fixed. 2014-01-14 Joseph Pecoraro Web Inspector: For Remote Inspection link WebProcess's to their parent UIProcess https://bugs.webkit.org/show_bug.cgi?id=126995 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::listingForDebuggable): For each WebView, list the parent process. Listing the parent per WebView is already supported back when we supported processes that could host WebViews for multiple applications. * inspector/remote/RemoteInspectorConstants.h: Add a separate key for the bundle identifier, separate from application identifier. * inspector/remote/RemoteInspectorDebuggable.cpp: (Inspector::RemoteInspectorDebuggable::info): * inspector/remote/RemoteInspectorDebuggable.h: (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo): (Inspector::RemoteInspectorDebuggableInfo::hasParentProcess): If a RemoteInspectorDebuggable has a non-zero parent process identifier it is a proxy for the parent process. 2014-01-14 Brian J. Burg Add ENABLE(WEB_REPLAY) feature flag to the build system https://bugs.webkit.org/show_bug.cgi?id=126949 Reviewed by Joseph Pecoraro. * Configurations/FeatureDefines.xcconfig: 2014-01-14 Peter Molnar [EFL] FTL buildfix, add missing includes https://bugs.webkit.org/show_bug.cgi?id=126641 Reviewed by Csaba Osztrogonác. * ftl/FTLOSREntry.cpp: * ftl/FTLOSRExitCompiler.cpp: 2014-01-14 Joseph Pecoraro Web Inspector: RemoteInspector::updateDebuggable may miss a push https://bugs.webkit.org/show_bug.cgi?id=126965 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::updateDebuggable): Always push an update. If a debuggable went from allowed to not allowed, we would have missed pushing an update. 2014-01-13 Mark Hahnenberg Performance regression on dromaeo due to generational marking https://bugs.webkit.org/show_bug.cgi?id=126901 Reviewed by Oliver Hunt. We were seeing some performance regression with ENABLE_GGC == 0, so this patch ifdefs out more things to get rid of the additional overhead. * heap/Heap.cpp: (JSC::Heap::markRoots): (JSC::Heap::writeBarrier): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::clearMarks): (JSC::MarkedBlock::clearMarksWithCollectionType): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::resetAllocators): * heap/MarkedSpace.h: (JSC::MarkedSpace::didAllocateInBlock): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::reportExtraMemoryUsage): 2014-01-13 Brian Burg Web Inspector: protocol generator should support integer-typed declarations https://bugs.webkit.org/show_bug.cgi?id=126828 Reviewed by Joseph Pecoraro. Add new binding classes for parameter/ad-hoc and normal integer type declarations. * inspector/scripts/CodeGeneratorInspector.py: (TypeBindings.create_type_declaration_): (TypeBindings.create_type_declaration_.PlainInteger): (TypeBindings.create_type_declaration_.PlainInteger.resolve_inner): (TypeBindings.create_type_declaration_.PlainInteger.request_user_runtime_cast): (TypeBindings.create_type_declaration_.PlainInteger.request_internal_runtime_cast): (TypeBindings.create_type_declaration_.PlainInteger.get_code_generator): (TypeBindings.create_type_declaration_.PlainInteger.get_validator_call_text): (TypeBindings.create_type_declaration_.PlainInteger.reduce_to_raw_type): (TypeBindings.create_type_declaration_.PlainInteger.get_type_model): (TypeBindings.create_type_declaration_.PlainInteger.get_setter_value_expression_pattern): (TypeBindings.create_type_declaration_.PlainInteger.get_array_item_c_type_text): (TypeBindings.create_type_declaration_.TypedefInteger): (TypeBindings.create_type_declaration_.TypedefInteger.resolve_inner): (TypeBindings.create_type_declaration_.TypedefInteger.request_user_runtime_cast): (TypeBindings.create_type_declaration_.TypedefInteger.request_internal_runtime_cast): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.generate_type_builder): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.generate_type_builder.int): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.register_use): (TypeBindings.create_type_declaration_.TypedefInteger.get_code_generator.CodeGenerator.get_generate_pass_id): (TypeBindings.create_type_declaration_.TypedefInteger.get_validator_call_text): (TypeBindings.create_type_declaration_.TypedefInteger.reduce_to_raw_type): (TypeBindings.create_type_declaration_.TypedefInteger.get_type_model): (TypeBindings.create_type_declaration_.TypedefInteger.get_setter_value_expression_pattern): (TypeBindings.create_type_declaration_.TypedefInteger.get_array_item_c_type_text): 2014-01-13 Zalan Bujtas Enable SUBPIXEL_LAYOUT on Mac Reviewed by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2014-01-13 Zan Dobersek Unreviewed. Changes in r161686 are exposing a bug in GCC where the global .cfi_startproc directive is not inserted early enough into the generated assembler code when building in debug mode, causing compilation failures on ports using the GCC compilers. To work around the problem, only utilize the OFFLINE_ASM_* macros that use .cfi_ directives when compiling with Clang. * llint/LowLevelInterpreter.cpp: 2014-01-12 Commit Queue Unreviewed, rolling out r161840. http://trac.webkit.org/changeset/161840 https://bugs.webkit.org/show_bug.cgi?id=126870 Caused jsscore and layout test failures (Requested by smfr on #webkit). * API/JSValueRef.cpp: (JSValueMakeFromJSONString): * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): * inspector/InspectorValues.cpp: * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): * runtime/Identifier.h: (JSC::Identifier::characters): * runtime/JSStringBuilder.h: (JSC::JSStringBuilder::append): 2014-01-12 Darin Adler Add deprecatedCharacters as a synonym for characters and convert most call sites https://bugs.webkit.org/show_bug.cgi?id=126858 Reviewed by Anders Carlsson. * API/JSStringRef.cpp: (JSStringGetCharactersPtr): (JSStringGetUTF8CString): (JSStringIsEqual): * API/JSStringRefCF.cpp: (JSStringCopyCFString): * API/OpaqueJSString.h: (OpaqueJSString::characters): (OpaqueJSString::deprecatedCharacters): (OpaqueJSString::length): (OpaqueJSString::OpaqueJSString): * inspector/InspectorValues.cpp: (Inspector::InspectorValue::parseJSON): * runtime/JSGlobalObjectFunctions.cpp: (JSC::parseInt): * runtime/StringPrototype.cpp: (JSC::localeCompare): (JSC::stringProtoFuncFontsize): (JSC::stringProtoFuncLink): Use deprecatedCharacters instead of characters. 2014-01-12 Darin Adler Reduce use of String::characters https://bugs.webkit.org/show_bug.cgi?id=126854 Reviewed by Sam Weinig. * API/JSValueRef.cpp: (JSValueMakeFromJSONString): Use characters16 instead of characters for 16-bit case. Had to remove length check because an empty string could be either 8 bit or 16 bit. Don't need a null string check before calling is8Bit because JSStringRef can't hold a null string. * bindings/ScriptValue.cpp: (Deprecated::jsToInspectorValue): Use the existing string here instead of creating a new one by calling characters and length on the old string. I think this may be left over from when string types were not the same in JavaScriptCore and WebCore. Also rewrite the property names loop to use modern for syntax and fewer locals. * inspector/InspectorValues.cpp: (Inspector::escapeChar): Changed to use appendLiteral instead of hard-coding string lengths. Moved handling of "<" and ">" in here instead of at the call site. (Inspector::doubleQuoteString): Simplify the code so there is no use of characters and length. This is still an inefficient way of doing this job and could use a rethink. * runtime/DatePrototype.cpp: (JSC::formatLocaleDate): Use RetainPtr, createCFString, and the conversion from CFStringRef to WTF::String to remove a lot of unneeded code. * runtime/Identifier.h: Removed unneeded Identifier::characters function. * runtime/JSStringBuilder.h: (JSC::JSStringBuilder::append): Use characters16 instead of characters function here, since we have already checked is8Bit above. 2014-01-12 Andy Estes [iOS] Enable the JSC Objective-C API Rubber-stamped by Simon Fraser. * API/JSBase.h: 2014-01-12 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.am: Add inline-and-minify-stylesheets-and-scripts.py to EXTRA_DIST and fix InjectedScriptSource.h generation rule. * GNUmakefile.list.am: Move InjectedScriptSource.h to built_nosources to make sure it's not disted. 2014-01-11 Anders Carlsson Try again to fix the build. * inspector/InspectorAgentRegistry.cpp: * inspector/InspectorAgentRegistry.h: 2014-01-11 Anders Carlsson Try to prevent the Vector copy constructor from being instantiated. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::InspectorAgentRegistry): * inspector/InspectorAgentRegistry.h: 2014-01-11 Anders Carlsson Try something else. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::~InspectorAgentRegistry): * inspector/InspectorAgentRegistry.h: 2014-01-11 Dean Jackson [JSC] Revise typed array implementations to match ECMAScript and WebGL Specification https://bugs.webkit.org/show_bug.cgi?id=126754 Reviewed by Filip Pizlo. The ECMAScript specification forbids calling the typed array constructors without using "new". Change the call data to return none so we throw and exception in these cases. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::getCallData): 2014-01-11 Anders Carlsson Try to fix the build by introducing a constructor. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::InspectorAgentRegistry): * inspector/InspectorAgentRegistry.h: 2014-01-11 Anders Carlsson * inspector/InspectorAgentRegistry.h: Remove an unused function. 2014-01-11 Anders Carlsson InspectorAgentRegistry should use std::unique_ptr https://bugs.webkit.org/show_bug.cgi?id=126826 Reviewed by Sam Weinig. * inspector/InspectorAgentRegistry.cpp: (Inspector::InspectorAgentRegistry::append): * inspector/InspectorAgentRegistry.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): * inspector/agents/InspectorAgent.h: 2014-01-10 Joseph Pecoraro Web Inspector: Push InspectorAgent down into JSC, give JSC an InspectorController https://bugs.webkit.org/show_bug.cgi?id=126763 Reviewed by Timothy Hatcher. Introduce JSGlobalObjectInspectorController. This is the InspectorController for a JSContext. It is created by the JSGlobalObject Remote Inspector Debuggable when a remote frontend connects, and is destroyed when the remote frontend disconnects of the JSGlobalObject is destroyed. * inspector/JSGlobalObjectInspectorController.h: Added. * inspector/JSGlobalObjectInspectorController.cpp: Added. (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController): (Inspector::JSGlobalObjectInspectorController::connectFrontend): (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): (Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend): (Inspector::JSGlobalObjectInspectorController::functionCallHandler): (Inspector::JSGlobalObjectInspectorController::evaluateHandler): Create/destory agents, create/destroy dispatches, implement InspectorEnvironment. * runtime/JSGlobalObjectDebuggable.h: * runtime/JSGlobalObjectDebuggable.cpp: (JSC::JSGlobalObjectDebuggable::~JSGlobalObjectDebuggable): (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::disconnect): (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): Forward actions to the InspectorController object. * inspector/agents/InspectorAgent.h: Renamed from Source/WebCore/inspector/InspectorAgent.h. * inspector/agents/InspectorAgent.cpp: Renamed from Source/WebCore/inspector/InspectorAgent.cpp. (Inspector::InspectorAgent::InspectorAgent): (Inspector::InspectorAgent::~InspectorAgent): (Inspector::InspectorAgent::didCreateFrontendAndBackend): (Inspector::InspectorAgent::inspect): (Inspector::InspectorAgent::evaluateForTestInFrontend): Implement InspectorAgent in JavaScriptCore in namespace Inspector. * JavaScriptCore.xcodeproj/project.pbxproj: * CMakeLists.txt: * ChangeLog: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/copy-files.cmd: Add files and new inspector/agents subdirectory. 2014-01-10 Commit Queue Unreviewed, rolling out r161702. http://trac.webkit.org/changeset/161702 https://bugs.webkit.org/show_bug.cgi?id=126803 Broke multiple tests (Requested by ap on #webkit). * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::getCallData): 2014-01-10 David Kilzer Clean up architectures in xcconfig files Reviewed by Andy Estes. * Configurations/Base.xcconfig: * Configurations/JavaScriptCore.xcconfig: Remove armv6, ppc. * Configurations/ToolExecutable.xcconfig: Sort. - Add new arch. 2014-01-10 Dean Jackson [JSC] Revise typed array implementations to match ECMAScript and WebGL Specification https://bugs.webkit.org/show_bug.cgi?id=126754 Reviewed by Filip Pizlo. The ECMAScript specification forbids calling the typed array constructors without using "new". Change the call data to return none so we throw and exception in these cases. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::JSGenericTypedArrayViewConstructor::getCallData): 2014-01-10 Benjamin Poulain Remove the BlackBerry port from trunk https://bugs.webkit.org/show_bug.cgi?id=126715 Reviewed by Anders Carlsson. * assembler/ARMAssembler.h: (JSC::ARMAssembler::cacheFlush): * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::replaceWithJump): (JSC::ARMv7Assembler::maxJumpReplacementSize): (JSC::ARMv7Assembler::cacheFlush): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch): * heap/MachineStackMarker.cpp: (JSC::getPlatformThreadRegisters): (JSC::otherThreadStackPointer): (JSC::freePlatformThreadRegisters): * jit/ExecutableAllocator.h: 2014-01-10 Joseph Pecoraro Web Inspector: Remove unimplemented or static ScriptDebugServer features https://bugs.webkit.org/show_bug.cgi?id=126784 Reviewed by Timothy Hatcher. * inspector/protocol/Debugger.json: 2014-01-10 Michael Saboff REGRESSION(C stack work): stack traces no longer work in CrashTracer, lldb, and other tools https://bugs.webkit.org/show_bug.cgi?id=126764 Reviewed by Geoffrey Garen. Updated callToJavaScript and cllToNativeFunction to properly replicate the caller's return PC and frame pointer in the sentinel frame. For X86-64, added .cfi_ directives to create eh_frame info for all LLInt symbols so that the various unwinding code understands that we are using a separate JS stack referenced by BP and at what offsets in that frame the prior PC (register 16) and prior BP (register 6) can be found. These two changes are sufficient for stack tracing to work for Mac OSX. * llint/LowLevelInterpreter.cpp: * llint/LowLevelInterpreter64.asm: 2014-01-10 Tamas Gergely [EFL][JSC] Enable udis86 disassembler on efl. https://bugs.webkit.org/show_bug.cgi?id=125502 Reviewed by Michael Saboff. Enable udis86 disassembler on efl and fix build warnings. * CMakeLists.txt: Add udis86 disassembler source files. * disassembler/udis86/udis86_decode.c: (decode_modrm_rm): Build warning fixes. * disassembler/udis86/udis86_syn-att.c: (gen_operand): Build warning fixes. * disassembler/udis86/udis86_syn-intel.c: (gen_operand): Build warning fixes. * disassembler/udis86/udis86_types.h: Correct FMT64 for uint64_t. 2014-01-09 Benjamin Poulain Remove the BlackBerry files outside WebCore https://bugs.webkit.org/show_bug.cgi?id=126715 Reviewed by Anders Carlsson. * PlatformBlackBerry.cmake: Removed. * runtime/GCActivityCallbackBlackBerry.cpp: Removed. * shell/PlatformBlackBerry.cmake: Removed. 2014-01-10 Geoffrey Garen Removed Blackberry #ifdefs and platform code from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=126757 Reviewed by Sam Weinig. * PlatformBlackBerry.cmake: Removed. * heap/HeapTimer.cpp: * heap/HeapTimer.h: * heap/IncrementalSweeper.cpp: * heap/IncrementalSweeper.h: * jsc.cpp: (main): * runtime/GCActivityCallbackBlackBerry.cpp: Removed. * runtime/MemoryStatistics.cpp: (JSC::globalMemoryStatistics): 2014-01-07 Mark Hahnenberg Marking should be generational https://bugs.webkit.org/show_bug.cgi?id=126552 Reviewed by Geoffrey Garen. Re-marking the same objects over and over is a waste of effort. This patch implements the sticky mark bit algorithm (along with our already-present write barriers) to reduce overhead during garbage collection caused by rescanning objects. There are now two collection modes, EdenCollection and FullCollection. EdenCollections only visit new objects or objects that were added to the remembered set by a write barrier. FullCollections are normal collections that visit all objects regardless of their generation. In this patch EdenCollections do not do anything in CopiedSpace. This will be fixed in https://bugs.webkit.org/show_bug.cgi?id=126555. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitAggregate): * bytecode/CodeBlock.h: (JSC::CodeBlockSet::mark): * dfg/DFGOperations.cpp: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::add): (JSC::CodeBlockSet::traceMarked): (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks): * heap/CodeBlockSet.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::didStartFullCollection): * heap/CopiedSpace.h: (JSC::CopiedSpace::heap): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::didAbandon): (JSC::Heap::markRoots): (JSC::Heap::copyBackingStores): (JSC::Heap::addToRememberedSet): (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::didAllocate): (JSC::Heap::writeBarrier): * heap/Heap.h: (JSC::Heap::isInRememberedSet): (JSC::Heap::operationInProgress): (JSC::Heap::shouldCollect): (JSC::Heap::isCollecting): (JSC::Heap::isWriteBarrierEnabled): (JSC::Heap::writeBarrier): * heap/HeapOperation.h: * heap/MarkStack.cpp: (JSC::MarkStackArray::~MarkStackArray): (JSC::MarkStackArray::clear): (JSC::MarkStackArray::fillVector): * heap/MarkStack.h: * heap/MarkedAllocator.cpp: (JSC::isListPagedOut): (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): (JSC::MarkedAllocator::reset): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::MarkedAllocator): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::clearMarks): (JSC::MarkedBlock::clearRememberedSet): (JSC::MarkedBlock::clearMarksWithCollectionType): (JSC::MarkedBlock::lastChanceToFinalize): * heap/MarkedBlock.h: Changed atomSize to 16 bytes because we have no objects smaller than 16 bytes. This is also to pay for the additional Bitmap for the remembered set. (JSC::MarkedBlock::didConsumeEmptyFreeList): (JSC::MarkedBlock::setRemembered): (JSC::MarkedBlock::clearRemembered): (JSC::MarkedBlock::atomicClearRemembered): (JSC::MarkedBlock::isRemembered): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): (JSC::VerifyMarked::operator()): (JSC::MarkedSpace::clearMarks): * heap/MarkedSpace.h: (JSC::ClearMarks::operator()): (JSC::ClearRememberedSet::operator()): (JSC::MarkedSpace::didAllocateInBlock): (JSC::MarkedSpace::clearRememberedSet): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::~SlotVisitor): (JSC::SlotVisitor::clearMarkStack): * heap/SlotVisitor.h: (JSC::SlotVisitor::markStack): (JSC::SlotVisitor::sharedData): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::unconditionallyAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryUsage): (JSC::SlotVisitor::heap): * jit/Repatch.cpp: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): * runtime/JSPropertyNameIterator.h: (JSC::StructureRareData::setEnumerationCache): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::setObjectToStringValue): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): 2014-01-09 Joseph Pecoraro Unreviewed Windows build fix for r161563. Copy all scripts, some may not be .py. * JavaScriptCore.vcxproj/copy-files.cmd: 2014-01-09 Filip Pizlo AI for CreateArguments should pass through non-SpecEmpty input values https://bugs.webkit.org/show_bug.cgi?id=126709 Reviewed by Mark Hahnenberg. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * tests/stress/use-arguments-as-object-pointer.js: Added. (foo): 2014-01-09 Mark Hahnenberg Constructors for Objective-C classes do not work properly with instanceof https://bugs.webkit.org/show_bug.cgi?id=126670 Reviewed by Oliver Hunt. This bug is due to the fact that the JS constructors created for Objective-C classes via the JSC API inherit from JSCallbackObject, which overrides hasInstance with its own customHasInstance. JSCallbackObject::customHasInstance only checks the JSClassRefs for hasInstance callbacks. If it doesn't find any callbacks, it returns false. This patch adds a hasInstance callback to constructors created for Objective-C wrapper classes. * API/JSWrapperMap.mm: (constructorHasInstance): (constructorWithCustomBrand): (allocateConstructorForCustomClass): * API/tests/testapi.mm: 2014-01-09 Joseph Pecoraro Web Inspector: Move InjectedScript classes into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=126598 Reviewed by Timothy Hatcher. Part 5: Move InjectedScript classes into JavaScriptCore There are pieces of logic that WebCore wants to hook into in the InjectedScript execution (e.g. for CommandLineAPIModule and InspectorInstrumentation). Create hooks for those in a base class called InspectorEnvironment. For now, the InspectorControllers (Page, JSGlobalObject, Worker) will be the InspectorEnvironments and provide answers to its hooks. * inspector/InspectorEnvironment.h: Added. New hooks needed by WebCore in various places. Mostly stubbed in JavaScriptCore. * inspector/InjectedScript.cpp: Renamed from Source/WebCore/inspector/InjectedScript.cpp. * inspector/InjectedScript.h: Added. * inspector/InjectedScriptBase.cpp: Renamed from Source/WebCore/inspector/InjectedScriptBase.cpp. * inspector/InjectedScriptBase.h: Renamed from Source/WebCore/inspector/InjectedScriptBase.h. * inspector/InjectedScriptModule.cpp: Renamed from Source/WebCore/inspector/InjectedScriptModule.cpp. * inspector/InjectedScriptModule.h: Renamed from Source/WebCore/inspector/InjectedScriptModule.h. Cleanup the style of these files (nullptr, formatting, whitespace, etc). Use the InspectorEnvironments call/evaluate function for ScriptFunctionCalls and checking access * inspector/InjectedScriptManager.cpp: Renamed from Source/WebCore/inspector/InjectedScriptManager.cpp. * inspector/InjectedScriptManager.h: Renamed from Source/WebCore/inspector/InjectedScriptManager.h. Take an InspectorEnvironment with multiple hooks, instead of a single hook function. * inspector/InjectedScriptHost.cpp: Added. * inspector/InjectedScriptHost.h: Added. * inspector/JSInjectedScriptHost.cpp: Renamed from Source/WebCore/bindings/js/JSInjectedScriptHostCustom.cpp. * inspector/JSInjectedScriptHost.h: Added. * inspector/JSInjectedScriptHostPrototype.cpp: Added. * inspector/JSInjectedScriptHostPrototype.h: Added. Implementation of InjectedScriptHost which is passed into the script (InjectedScriptSource.js) that we inject into the page. This is mostly copied from the original autogenerated code, then simplified and cleaned up. InjectedScriptHost can be subclasses to provide specialized implementations of isHTMLAllCollection and type for Web/DOM types unknown to a pure JS context. Part 4: Move all inspector scripts into JavaScriptCore and update generators. For OS X be sure to export the scripts as if they are private headers. * GNUmakefile.am: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/scripts/cssmin.py: Renamed from Source/WebCore/inspector/Scripts/cssmin.py. * inspector/scripts/inline-and-minify-stylesheets-and-scripts.py: Renamed from Source/WebCore/inspector/Scripts/inline-and-minify-stylesheets-and-scripts.py. * inspector/scripts/jsmin.py: Renamed from Source/WebCore/inspector/Scripts/jsmin.py. * inspector/scripts/xxd.pl: Renamed from Source/WebCore/inspector/xxd.pl. Part 3: Update CodeGeneratorInspector to avoid inlining virtual destructors. This avoids build errors about duplicate exported virtual inlined methods are included from multiple places. Just put empty destructors in the implementation file instead of inlined. * inspector/scripts/CodeGeneratorInspector.py: (Generator): (Generator.go): * inspector/scripts/CodeGeneratorInspectorStrings.py: Part 2: Move InjectedScriptSource and generation into JavaScriptCore. Move InjectedScriptSource.js and derived sources generation. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/InjectedScriptSource.js: Renamed from Source/WebCore/inspector/InjectedScriptSource.js. 2014-01-09 Balazs Kilvady Regression: failing RegExp tests on 32 bit architectures. https://bugs.webkit.org/show_bug.cgi?id=126699 Reviewed by Michael Saboff. Fix setRegExpConstructor functions for 32 bit architectures. * runtime/RegExpConstructor.cpp: (JSC::setRegExpConstructorInput): (JSC::setRegExpConstructorMultiline): 2014-01-09 Commit Queue Unreviewed, rolling out r161540. http://trac.webkit.org/changeset/161540 https://bugs.webkit.org/show_bug.cgi?id=126704 Caused assertion failures on multiple tests (Requested by ap on #webkit). * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitAggregate): * bytecode/CodeBlock.h: (JSC::CodeBlockSet::mark): * dfg/DFGOperations.cpp: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::add): (JSC::CodeBlockSet::traceMarked): * heap/CodeBlockSet.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): * heap/CopiedSpace.cpp: * heap/CopiedSpace.h: * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::didAbandon): (JSC::Heap::markRoots): (JSC::Heap::copyBackingStores): (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::didAllocate): * heap/Heap.h: (JSC::Heap::shouldCollect): (JSC::Heap::isCollecting): (JSC::Heap::isWriteBarrierEnabled): (JSC::Heap::writeBarrier): * heap/HeapOperation.h: * heap/MarkStack.cpp: (JSC::MarkStackArray::~MarkStackArray): * heap/MarkStack.h: * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::reset): * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: (JSC::MarkedBlock::lastChanceToFinalize): (JSC::MarkedBlock::didConsumeEmptyFreeList): (JSC::MarkedBlock::clearMarks): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): * heap/MarkedSpace.h: (JSC::ClearMarks::operator()): (JSC::MarkedSpace::clearMarks): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::~SlotVisitor): * heap/SlotVisitor.h: (JSC::SlotVisitor::sharedData): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryUsage): * jit/Repatch.cpp: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): * runtime/JSPropertyNameIterator.h: (JSC::StructureRareData::setEnumerationCache): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::setObjectToStringValue): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): 2014-01-09 Andreas Kling Shrink WatchpointSet. Reorder the members of WatchpointSet, shrinking it by 8 bytes. 767 kB progression on Membuster3. Reviewed by Antti Koivisto. * bytecode/Watchpoint.h: 2014-01-08 Mark Hahnenberg Reverting accidental GC logging * heap/Heap.cpp: 2014-01-07 Mark Hahnenberg Marking should be generational https://bugs.webkit.org/show_bug.cgi?id=126552 Reviewed by Geoffrey Garen. Re-marking the same objects over and over is a waste of effort. This patch implements the sticky mark bit algorithm (along with our already-present write barriers) to reduce overhead during garbage collection caused by rescanning objects. There are now two collection modes, EdenCollection and FullCollection. EdenCollections only visit new objects or objects that were added to the remembered set by a write barrier. FullCollections are normal collections that visit all objects regardless of their generation. In this patch EdenCollections do not do anything in CopiedSpace. This will be fixed in https://bugs.webkit.org/show_bug.cgi?id=126555. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitAggregate): * bytecode/CodeBlock.h: (JSC::CodeBlockSet::mark): * dfg/DFGOperations.cpp: * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::add): (JSC::CodeBlockSet::traceMarked): (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks): * heap/CodeBlockSet.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): * heap/CopiedSpace.cpp: (JSC::CopiedSpace::didStartFullCollection): * heap/CopiedSpace.h: (JSC::CopiedSpace::heap): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::didAbandon): (JSC::Heap::markRoots): (JSC::Heap::copyBackingStores): (JSC::Heap::addToRememberedSet): (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::didAllocate): (JSC::Heap::writeBarrier): * heap/Heap.h: (JSC::Heap::isInRememberedSet): (JSC::Heap::operationInProgress): (JSC::Heap::shouldCollect): (JSC::Heap::isCollecting): (JSC::Heap::isWriteBarrierEnabled): (JSC::Heap::writeBarrier): * heap/HeapOperation.h: * heap/MarkStack.cpp: (JSC::MarkStackArray::~MarkStackArray): (JSC::MarkStackArray::clear): (JSC::MarkStackArray::fillVector): * heap/MarkStack.h: * heap/MarkedAllocator.cpp: (JSC::isListPagedOut): (JSC::MarkedAllocator::isPagedOut): (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::addBlock): (JSC::MarkedAllocator::removeBlock): (JSC::MarkedAllocator::reset): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::MarkedAllocator): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::clearMarks): (JSC::MarkedBlock::clearRememberedSet): (JSC::MarkedBlock::clearMarksWithCollectionType): (JSC::MarkedBlock::lastChanceToFinalize): * heap/MarkedBlock.h: Changed atomSize to 16 bytes because we have no objects smaller than 16 bytes. This is also to pay for the additional Bitmap for the remembered set. (JSC::MarkedBlock::didConsumeEmptyFreeList): (JSC::MarkedBlock::setRemembered): (JSC::MarkedBlock::clearRemembered): (JSC::MarkedBlock::atomicClearRemembered): (JSC::MarkedBlock::isRemembered): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::~MarkedSpace): (JSC::MarkedSpace::resetAllocators): (JSC::MarkedSpace::visitWeakSets): (JSC::MarkedSpace::reapWeakSets): (JSC::VerifyMarked::operator()): (JSC::MarkedSpace::clearMarks): * heap/MarkedSpace.h: (JSC::ClearMarks::operator()): (JSC::ClearRememberedSet::operator()): (JSC::MarkedSpace::didAllocateInBlock): (JSC::MarkedSpace::clearRememberedSet): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::~SlotVisitor): (JSC::SlotVisitor::clearMarkStack): * heap/SlotVisitor.h: (JSC::SlotVisitor::markStack): (JSC::SlotVisitor::sharedData): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::unconditionallyAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryUsage): (JSC::SlotVisitor::heap): * jit/Repatch.cpp: * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::visitChildren): * runtime/JSPropertyNameIterator.h: (JSC::StructureRareData::setEnumerationCache): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureRareDataInlines.h: (JSC::StructureRareData::setPreviousID): (JSC::StructureRareData::setObjectToStringValue): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): 2014-01-08 Sam Weinig [JS] Should be able to create a promise by calling the Promise constructor as a function https://bugs.webkit.org/show_bug.cgi?id=126561 Reviewed by Geoffrey Garen. * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructor::getCallData): Add support for calling the Promise constructor as a function (e.g. var p = Promise(...), note the missing "new"). 2014-01-08 Dániel Bátyai [EFL] Make FTL buildable https://bugs.webkit.org/show_bug.cgi?id=125777 Reviewed by Csaba Osztrogonác. * CMakeLists.txt: * ftl/FTLOSREntry.cpp: * ftl/FTLOSRExitCompiler.cpp: * llvm/library/config_llvm.h: 2014-01-08 Zan Dobersek [Automake] Scripts for generated build targets do not necessarily produce their output https://bugs.webkit.org/show_bug.cgi?id=126378 Reviewed by Carlos Garcia Campos. * GNUmakefile.am: Touch the build targets that are generated through helper scripts that don't assure the output is generated every time the script is invoked, most commonly due to unchanged input. This assures the build targets are up-to-date and can't be older that their dependencies, which would result in constant regeneration at every build. 2014-01-07 Filip Pizlo DFG fixup phase should be responsible for inserting ValueToInt32's as needed and it should use Phantom to keep the original values alive in case of OSR exit https://bugs.webkit.org/show_bug.cgi?id=126600 Reviewed by Michael Saboff. This fixes an embarrassing OSR exit liveness bug. It also simplifies the code. We were already using FixupPhase as the place where conversion nodes get inserted. ValueToInt32 was the only exception to that rule, and that was one of the reasons why we had this bug. Henceforth ValueToInt32 is only inserted by FixupPhase, and only when it is necessary: we have a BitOp that will want a ToInt32 conversion and the operand is not predicted to already be an int32. If FixupPhase inserts any ValueToInt32's then the BitOp will no longer appear to use the original operand, which will make OSR exit think that the original operand is dead. We work around this they way we always do: insert a Phantom on the original operands right after the BitOp. This ensures that any OSR exit in any of the ValueToInt32's or in the BitOp itself will have values for the original inputs. * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsic): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixIntEdge): (JSC::DFG::FixupPhase::fixBinaryIntEdges): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * tests/stress/bit-op-value-to-int32-input-liveness.js: Added. (foo): 2014-01-07 Mark Hahnenberg Repatch write barrier slow path call doesn't align the stack in the presence of saved registers https://bugs.webkit.org/show_bug.cgi?id=126093 Reviewed by Geoffrey Garen. * jit/Repatch.cpp: Reworked the stack alignment code for calling out to C code on the write barrier slow path. We need to properly account for the number of reused registers that were saved to the stack, so we have to pass the ScratchRegisterAllocator around. (JSC::storeToWriteBarrierBuffer): (JSC::writeBarrier): (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): * jit/ScratchRegisterAllocator.h: Previously the ScratchRegisterAllocator only knew whether or not it had reused registers, but not how many. In order to correctly align the stack for calls to C slow paths for the write barriers in inline caches we need to know how the stack is aligned. So now ScratchRegisterAllocator tracks how many registers it has reused. (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator): (JSC::ScratchRegisterAllocator::allocateScratch): (JSC::ScratchRegisterAllocator::didReuseRegisters): (JSC::ScratchRegisterAllocator::numberOfReusedRegisters): (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing): (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping): * llint/LowLevelInterpreter64.asm: Random typo fix. 2014-01-07 Mark Lam r161364 caused JSC tests regression on non-DFG builds (e.g. C Loop and Windows). https://bugs.webkit.org/show_bug.cgi?id=126589. Reviewed by Filip Pizlo. After the removal of ENABLE(VALUE_PROFILER), the LLINT is now expecting the relevant opcode operands to point to ValueProfiler data structures and will write profiling data into them. Hence, we need to allocate these data structures even though the profiling data won't be used in non-DFG builds. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): 2014-01-07 Filip Pizlo ASSERT in compileArithNegate on pdfjs https://bugs.webkit.org/show_bug.cgi?id=126584 Reviewed by Mark Hahnenberg. Check negative zero when we should check it, not when we shouldn't check it. :-/ * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithNegate): 2014-01-07 Gabor Rapcsanyi pushFinallyContext saves wrong m_labelScopes size https://bugs.webkit.org/show_bug.cgi?id=124529 Remove free label scopes before saving finally context. Reviewed by Geoffrey Garen. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::pushFinallyContext): 2014-01-06 Mark Hahnenberg Heap::collect shouldn't be responsible for sweeping https://bugs.webkit.org/show_bug.cgi?id=126556 Reviewed by Geoffrey Garen. Sweeping happens at an awkward time during collection due to the fact that destructors can cause arbitrary reentry into the VM. This patch separates collecting and sweeping, and delays sweeping until after collection has completely finished. * heap/Heap.cpp: (JSC::Heap::collectAllGarbage): (JSC::Heap::collect): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweep): * runtime/GCActivityCallback.cpp: (JSC::DefaultGCActivityCallback::doWork): 2014-01-07 Mark Rowe Remove the legacy WebKit availability macros They're no longer used. Reviewed by Ryosuke Niwa. * API/WebKitAvailability.h: 2014-01-07 Filip Pizlo SetLocal for a FlushedArguments should not claim that the dataFormat is DataFormatJS https://bugs.webkit.org/show_bug.cgi?id=126563 Reviewed by Gavin Barraclough. This was a rookie arguments simplification mistake: the SetLocal needs to record the fact that although it set JSValue(), OSR should think it set Arguments. DataFormatArguments conveys this, and dataFormatFor(FlushFormat) will do the right thing. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * tests/stress/phantom-arguments-set-local-then-exit-in-same-block.js: Added. (foo): 2014-01-06 Filip Pizlo Make the different flavors of integer arithmetic more explicit, and don't rely on (possibly stale) results of the backwards propagator to decide integer arithmetic semantics https://bugs.webkit.org/show_bug.cgi?id=125519 Reviewed by Geoffrey Garen. Adds the Arith::Mode enum to arithmetic nodes, which makes it explicit what sorts of checks and overflows the node should do. Previously this would be deduced from backwards analysis results. This also makes "unchecked" variants really mean that you want the int32 wrapped result, so ArithIMul is now done in terms of ArithMul(Unchecked). That means that the constant folder needs to compute exactly the result implied by ArithMode, instead of just folding the double result. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArithMode.cpp: Added. (WTF::printInternal): * dfg/DFGArithMode.h: Added. (JSC::DFG::doesOverflow): (JSC::DFG::shouldCheckOverflow): (JSC::DFG::shouldCheckNegativeZero): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::pureCSE): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::Node): (JSC::DFG::Node::hasArithMode): (JSC::DFG::Node::arithMode): (JSC::DFG::Node::setArithMode): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): (JSC::DFG::SpeculativeJIT::compileAdd): (JSC::DFG::SpeculativeJIT::compileArithSub): (JSC::DFG::SpeculativeJIT::compileArithNegate): (JSC::DFG::SpeculativeJIT::compileArithMul): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArithMod): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileAddSub): (JSC::FTL::LowerDFGToLLVM::compileArithMul): (JSC::FTL::LowerDFGToLLVM::compileArithDivMod): (JSC::FTL::LowerDFGToLLVM::compileArithNegate): (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): 2014-01-06 Mark Hahnenberg Add write barriers to the LLInt https://bugs.webkit.org/show_bug.cgi?id=126527 Reviewed by Filip Pizlo. This patch takes a similar approach to how write barriers work in the baseline JIT. We execute the write barrier at the beginning of the opcode so we don't have to worry about saving and restoring live registers across write barrier slow path calls to C code. * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_write_barrier_slow): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * offlineasm/arm64.rb: * offlineasm/instructions.rb: * offlineasm/x86.rb: 2014-01-05 Sam Weinig [JS] Implement Promise.all() https://bugs.webkit.org/show_bug.cgi?id=126510 Reviewed by Gavin Barraclough. Add Promise.all() implementation and factor out performing resolves and rejects on deferreds to share a bit of code. Also moves the abruptRejection helper to JSPromiseDeferred so it can be used in JSPromiseFunctions. * runtime/CommonIdentifiers.h: * runtime/JSPromiseConstructor.cpp: (JSC::JSPromiseConstructorFuncCast): (JSC::JSPromiseConstructorFuncResolve): (JSC::JSPromiseConstructorFuncReject): (JSC::JSPromiseConstructorFuncAll): * runtime/JSPromiseDeferred.cpp: (JSC::updateDeferredFromPotentialThenable): (JSC::performDeferredResolve): (JSC::performDeferredReject): (JSC::abruptRejection): * runtime/JSPromiseDeferred.h: * runtime/JSPromiseFunctions.cpp: (JSC::promiseAllCountdownFunction): (JSC::createPromiseAllCountdownFunction): * runtime/JSPromiseFunctions.h: * runtime/JSPromiseReaction.cpp: (JSC::ExecutePromiseReactionMicrotask::run): 2014-01-06 Filip Pizlo Get rid of ENABLE(VALUE_PROFILER). It's on all the time now. Rubber stamped by Mark Hahnenberg. * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFor): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpValueProfiling): (JSC::CodeBlock::dumpArrayProfiling): (JSC::CodeBlock::dumpRareCaseProfile): (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::setNumParameters): (JSC::CodeBlock::shrinkToFit): (JSC::CodeBlock::shouldOptimizeNow): * bytecode/CodeBlock.h: (JSC::CodeBlock::valueProfileForBytecodeOffset): * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForChain): (JSC::GetByIdStatus::computeFor): * bytecode/LazyOperandValueProfile.cpp: * bytecode/LazyOperandValueProfile.h: * bytecode/PutByIdStatus.cpp: (JSC::PutByIdStatus::computeFor): * bytecode/ValueProfile.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::newArrayProfile): (JSC::BytecodeGenerator::newArrayAllocationProfile): (JSC::BytecodeGenerator::emitProfiledOpcode): * jit/GPRInfo.h: * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::privateCompileSlowCases): (JSC::JIT::privateCompile): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::compileBinaryArithOp): (JSC::JIT::emit_op_mul): (JSC::JIT::emit_op_div): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitBinaryDoubleOp): (JSC::JIT::emit_op_mul): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emit_op_div): * jit/JITCall.cpp: (JSC::JIT::emitPutCallResult): * jit/JITCall32_64.cpp: (JSC::JIT::emitPutCallResult): * jit/JITInlines.h: (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile): (JSC::JIT::emitValueProfilingSite): (JSC::JIT::emitArrayProfilingSiteForBytecodeIndex): (JSC::JIT::emitArrayProfileStoreToHoleSpecialCase): (JSC::JIT::emitArrayProfileOutOfBoundsSpecialCase): (JSC::arrayProfileSaw): (JSC::JIT::chooseArrayMode): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_get_argument_by_val): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_get_argument_by_val): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_from_scope): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitSlow_op_get_by_val): (JSC::JIT::emit_op_get_by_id): (JSC::JIT::emit_op_get_from_scope): * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): * runtime/CommonSlowPaths.cpp: 2014-01-06 Filip Pizlo LLInt shouldn't check for ENABLE(JIT). Rubber stamped by Mark Hahnenberg. * llint/LLIntCommon.h: * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::entryOSR): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: 2014-01-06 Filip Pizlo LLInt shouldnt check for ENABLE(JAVASCRIPT_DEBUGGER). Rubber stamped by Mark Hahnenberg. * debugger/Debugger.h: (JSC::Debugger::Debugger): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: 2014-01-05 Sam Weinig [JS] Implement Promise.race() https://bugs.webkit.org/show_bug.cgi?id=126506 Reviewed by Oliver Hunt. * runtime/CommonIdentifiers.h: Add identifier for "cast". * runtime/JSPromiseConstructor.cpp: (JSC::abruptRejection): Helper for the RejectIfAbrupt abstract operation. (JSC::JSPromiseConstructorFuncRace): Add implementation of Promise.race() 2014-01-05 Martin Robinson [GTK] [CMake] Ensure that the autotools build and the CMake install the same files https://bugs.webkit.org/show_bug.cgi?id=116379 Reviewed by Gustavo Noronha Silva. * PlatformGTK.cmake: Install API headers, gir files, and the pkg-config file. 2014-01-04 Yusuke Suzuki Use Compiler macros instead of raw "final" and "override" https://bugs.webkit.org/show_bug.cgi?id=126490 Reviewed by Sam Weinig. * runtime/JSPromiseReaction.cpp: 2014-01-04 Martin Robinson [GTK] [CMake] Improve the way we locate gobject-introspection https://bugs.webkit.org/show_bug.cgi?id=126452 Reviewed by Philippe Normand. * PlatformGTK.cmake: Use the new introspection variables. 2014-01-04 Zan Dobersek Explicitly use the std:: nested name specifier when using std::pair, std::make_pair https://bugs.webkit.org/show_bug.cgi?id=126439 Reviewed by Andreas Kling. Instead of relying on std::pair and std::make_pair symbols being present in the current scope through the pair and make_pair symbols, the std:: specifier should be used explicitly. * bytecode/Opcode.cpp: (JSC::compareOpcodePairIndices): (JSC::OpcodeStats::~OpcodeStats): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeBinaryNode): * parser/Parser.cpp: (JSC::Parser::parseIfStatement): * runtime/Structure.cpp: (JSC::StructureTransitionTable::contains): (JSC::StructureTransitionTable::get): (JSC::StructureTransitionTable::add): 2014-01-03 David Farler [super dealloc] missing in Source/JavaScriptCore/API/tests/testapi.mm, fails to build with -Werror,-Wobjc-missing-super-calls https://bugs.webkit.org/show_bug.cgi?id=126454 Reviewed by Geoffrey Garen. * API/tests/testapi.mm: (-[TextXYZ dealloc]): add [super dealloc] (-[EvilAllocationObject dealloc]): add [super dealloc] 2014-01-02 Carlos Garcia Campos REGRESSION(r160304): [GTK] Disable libtool fast install https://bugs.webkit.org/show_bug.cgi?id=126381 Reviewed by Martin Robinson. Remove -no-fast-install ld flag since fast install is now disabled globally. * GNUmakefile.am: 2014-01-02 Sam Weinig Update Promises to the https://github.com/domenic/promises-unwrapping spec https://bugs.webkit.org/show_bug.cgi?id=120954 Reviewed by Filip Pizlo. Update Promises to the revised spec. Notable changes: - JSPromiseResolver is gone. - TaskContext has been renamed Microtask and now has a virtual run() function. - Instead of using custom InternalFunction subclasses, JSFunctions are used with PrivateName properties for internal slots. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CallFrame.h: (JSC::ExecState::promiseConstructorTable): * runtime/CommonIdentifiers.cpp: (JSC::CommonIdentifiers::CommonIdentifiers): * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): (JSC::JSGlobalObject::visitChildren): (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseConstructor): (JSC::JSGlobalObject::promisePrototype): (JSC::JSGlobalObject::promiseStructure): * runtime/JSPromise.cpp: (JSC::JSPromise::create): (JSC::JSPromise::JSPromise): (JSC::JSPromise::finishCreation): (JSC::JSPromise::visitChildren): (JSC::JSPromise::reject): (JSC::JSPromise::resolve): (JSC::JSPromise::appendResolveReaction): (JSC::JSPromise::appendRejectReaction): (JSC::triggerPromiseReactions): * runtime/JSPromise.h: (JSC::JSPromise::status): (JSC::JSPromise::result): (JSC::JSPromise::constructor): * runtime/JSPromiseCallback.cpp: Removed. * runtime/JSPromiseCallback.h: Removed. * runtime/JSPromiseConstructor.cpp: (JSC::constructPromise): (JSC::JSPromiseConstructor::getCallData): (JSC::JSPromiseConstructorFuncCast): (JSC::JSPromiseConstructorFuncResolve): (JSC::JSPromiseConstructorFuncReject): * runtime/JSPromiseConstructor.h: * runtime/JSPromiseDeferred.cpp: Added. (JSC::JSPromiseDeferred::create): (JSC::JSPromiseDeferred::JSPromiseDeferred): (JSC::JSPromiseDeferred::finishCreation): (JSC::JSPromiseDeferred::visitChildren): (JSC::createJSPromiseDeferredFromConstructor): (JSC::updateDeferredFromPotentialThenable): * runtime/JSPromiseDeferred.h: Added. (JSC::JSPromiseDeferred::createStructure): (JSC::JSPromiseDeferred::promise): (JSC::JSPromiseDeferred::resolve): (JSC::JSPromiseDeferred::reject): * runtime/JSPromiseFunctions.cpp: Added. (JSC::deferredConstructionFunction): (JSC::createDeferredConstructionFunction): (JSC::identifyFunction): (JSC::createIdentifyFunction): (JSC::promiseAllCountdownFunction): (JSC::createPromiseAllCountdownFunction): (JSC::promiseResolutionHandlerFunction): (JSC::createPromiseResolutionHandlerFunction): (JSC::rejectPromiseFunction): (JSC::createRejectPromiseFunction): (JSC::resolvePromiseFunction): (JSC::createResolvePromiseFunction): (JSC::throwerFunction): (JSC::createThrowerFunction): * runtime/JSPromiseFunctions.h: Added. * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototypeFuncThen): (JSC::JSPromisePrototypeFuncCatch): * runtime/JSPromiseReaction.cpp: Added. (JSC::createExecutePromiseReactionMicroTask): (JSC::ExecutePromiseReactionMicroTask::run): (JSC::JSPromiseReaction::create): (JSC::JSPromiseReaction::JSPromiseReaction): (JSC::JSPromiseReaction::finishCreation): (JSC::JSPromiseReaction::visitChildren): * runtime/JSPromiseReaction.h: Added. (JSC::JSPromiseReaction::createStructure): (JSC::JSPromiseReaction::deferred): (JSC::JSPromiseReaction::handler): * runtime/JSPromiseResolver.cpp: Removed. * runtime/JSPromiseResolver.h: Removed. * runtime/JSPromiseResolverConstructor.cpp: Removed. * runtime/JSPromiseResolverConstructor.h: Removed. * runtime/JSPromiseResolverPrototype.cpp: Removed. * runtime/JSPromiseResolverPrototype.h: Removed. * runtime/Microtask.h: Added. * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: 2014-01-02 Mark Hahnenberg Add support for StoreBarrier and friends to the FTL https://bugs.webkit.org/show_bug.cgi?id=126040 Reviewed by Filip Pizlo. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileStoreBarrier): (JSC::FTL::LowerDFGToLLVM::compileConditionalStoreBarrier): (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): (JSC::FTL::LowerDFGToLLVM::loadMarkByte): (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier): * heap/Heap.cpp: (JSC::Heap::Heap): * heap/Heap.h: (JSC::Heap::writeBarrierBuffer): 2014-01-02 Mark Hahnenberg Storing new CopiedSpace memory into a JSObject should fire a write barrier https://bugs.webkit.org/show_bug.cgi?id=126025 Reviewed by Filip Pizlo. Technically this is creating a pointer between a (potentially) old generation object and a young generation chunk of memory, thus there needs to be a barrier. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * heap/CopyWriteBarrier.h: Added. This class functions similarly to the WriteBarrier class. It acts as a proxy for pointers to CopiedSpace. Assignments to the field cause a write barrier to fire for the object that is the owner of the CopiedSpace memory. This is to ensure during nursery collections that objects with new backing stores are visited, even if they are old generation objects. (JSC::CopyWriteBarrier::CopyWriteBarrier): (JSC::CopyWriteBarrier::operator!): (JSC::CopyWriteBarrier::operator UnspecifiedBoolType*): (JSC::CopyWriteBarrier::get): (JSC::CopyWriteBarrier::operator*): (JSC::CopyWriteBarrier::operator->): (JSC::CopyWriteBarrier::set): (JSC::CopyWriteBarrier::setWithoutWriteBarrier): (JSC::CopyWriteBarrier::clear): * heap/Heap.h: * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): (JSC::JSArray::shiftCountWithArrayStorage): (JSC::JSArray::unshiftCountWithArrayStorage): * runtime/JSCell.h: (JSC::JSCell::unvalidatedStructure): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::slowDownAndWasteMemory): * runtime/JSObject.cpp: (JSC::JSObject::copyButterfly): (JSC::JSObject::getOwnPropertySlotByIndex): (JSC::JSObject::putByIndex): (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists): (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::createArrayStorage): (JSC::JSObject::deletePropertyByIndex): (JSC::JSObject::getOwnPropertyNames): (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes): (JSC::JSObject::countElements): (JSC::JSObject::increaseVectorLength): (JSC::JSObject::ensureLengthSlow): * runtime/JSObject.h: (JSC::JSObject::butterfly): (JSC::JSObject::setStructureAndButterfly): (JSC::JSObject::setButterflyWithoutChangingStructure): (JSC::JSObject::JSObject): (JSC::JSObject::putDirectInternal): (JSC::JSObject::putDirectWithoutTransition): * runtime/MapData.cpp: (JSC::MapData::ensureSpaceForAppend): * runtime/Structure.cpp: (JSC::Structure::materializePropertyMap): 2013-12-23 Oliver Hunt Refactor PutPropertySlot to be aware of custom properties https://bugs.webkit.org/show_bug.cgi?id=126187 Reviewed by Antti Koivisto. Refactor PutPropertySlot, making the constructor take the thisValue used as a target. This results in a wide range of boilerplate changes to pass the new parameter. * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setCustomProperty): (JSC::PutPropertySlot::thisValue): (JSC::PutPropertySlot::isCacheable): 2014-01-01 Filip Pizlo Rationalize DFG DCE https://bugs.webkit.org/show_bug.cgi?id=125523 Reviewed by Mark Hahnenberg. Adds the ability to DCE more things. It's now the case that if a node is completely pure, we clear NodeMustGenerate and the node becomes a DCE candidate. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::cleanVariables): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: (JSC::DFG::Graph::clobbersWorld): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAdd): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileValueAdd): 2014-01-02 Benjamin Poulain Attempt to fix the build of WebCore's code generator on CMake based system https://bugs.webkit.org/show_bug.cgi?id=126271 Reviewed by Sam Weinig. * CMakeLists.txt: 2013-12-30 Commit Queue Unreviewed, rolling out r161157, r161158, r161160, r161161, r161163, and r161165. http://trac.webkit.org/changeset/161157 http://trac.webkit.org/changeset/161158 http://trac.webkit.org/changeset/161160 http://trac.webkit.org/changeset/161161 http://trac.webkit.org/changeset/161163 http://trac.webkit.org/changeset/161165 https://bugs.webkit.org/show_bug.cgi?id=126332 Broke WebKit2 on Mountain Lion (Requested by ap on #webkit). * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForRelativeTimeWhileHoldingLock): (JSC::BlockAllocator::waitForRelativeTime): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2013-12-30 Anders Carlsson Fix build. * heap/BlockAllocator.h: 2013-12-30 Anders Carlsson Stop using ThreadCondition in BlockAllocator https://bugs.webkit.org/show_bug.cgi?id=126313 Reviewed by Sam Weinig. * heap/BlockAllocator.cpp: (JSC::BlockAllocator::~BlockAllocator): (JSC::BlockAllocator::waitForDuration): (JSC::BlockAllocator::blockFreeingThreadMain): * heap/BlockAllocator.h: (JSC::BlockAllocator::deallocate): 2013-12-30 Anders Carlsson Stop using ThreadCondition in jsc.cpp https://bugs.webkit.org/show_bug.cgi?id=126311 Reviewed by Sam Weinig. * jsc.cpp: (timeoutThreadMain): (main): 2013-12-30 Anders Carlsson Replace WTF::ThreadingOnce with std::call_once https://bugs.webkit.org/show_bug.cgi?id=126215 Reviewed by Sam Weinig. * dfg/DFGWorklist.cpp: (JSC::DFG::globalWorklist): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-30 Martin Robinson [CMake] [GTK] Add support for GObject introspection https://bugs.webkit.org/show_bug.cgi?id=126162 Reviewed by Daniel Bates. * PlatformGTK.cmake: Add the GIR targets. 2013-12-28 Filip Pizlo Get rid of DFG forward exiting https://bugs.webkit.org/show_bug.cgi?id=125531 Reviewed by Oliver Hunt. This finally gets rid of forward exiting. Forward exiting was always a fragile concept since it involved the compiler trying to figure out how to "roll forward" the execution from some DFG node to the next bytecode index. It was always easy to find counterexamples where it broke, and it has always served as an obstacle to adding compiler improvements - the latest being http://webkit.org/b/125523, which tried to make DCE work for more things. This change finishes the work of removing forward exiting. A lot of forward exiting was already removed in some other bugs, but SetLocal still did forward exits. SetLocal is in many ways the hardest to remove, since the forward exiting of SetLocal also implied that any conversion nodes inserted before the SetLocal would then also be marked as forward-exiting. Hence SetLocal's forward-exiting made a bunch of other things also forward-exiting, and this was always a source of weirdo bugs. SetLocal must be able to exit in case it performs a hoisted type speculation. Nodes inserted just before SetLocal must also be able to exit - for example type check hoisting may insert a CheckStructure, or fixup phase may insert something like Int32ToDouble. But if any of those nodes tried to backward exit, then this could lead to the reexecution of a side-effecting operation, for example: a: Call(...) b: SetLocal(@a, r1) For a long time it seemed like SetLocal *had* to exit forward because of this. But this change side-steps the problem by changing the ByteCodeParser to always emit a kind of "two-phase commit" for stores to local variables. Now when the ByteCodeParser wishes to store to a local, it first emits a MovHint and then enqueues a SetLocal. The SetLocal isn't actually emitted until the beginning of the next bytecode instruction (which the exception of op_enter and op_ret, which emit theirs immediately since it's always safe to reexecute those bytecode instructions and since deferring SetLocals would be weird there - op_enter has many SetLocals and op_ret is a set followed by a jump in case of inlining, so we'd have to emit the SetLocal "after" the jump and that would be awkward). This means that the above IR snippet would look something like: a: Call(..., bc#42) b: MovHint(@a, r1, bc#42) c: SetLocal(@a, r1, bc#47) Where the SetLocal exits "backwards" but appears at the beginning of the next bytecode instruction. This means that by the time we get to that SetLocal, the OSR exit analysis already knows that r1 is associated with @a, and it means that the SetLocal or anything hoisted above it can exit backwards as normal. This change also means that the "forward rewiring" can be killed. Previously, we might have inserted a conversion node on SetLocal and then the SetLocal died (i.e. turned into a MovHint) and the conversion node either died completely or had its lifetime truncated to be less than the actual value's bytecode lifetime. This no longer happens since conversion nodes are only inserted at SetLocals. More precisely, this change introduces two laws that we were basically already following anyway: 1) A MovHint's child should never be changed except if all other uses of that child are also replaced. Specifically, this prohibits insertion of conversion nodes at MovHints. 2) Anytime any child is replaced with something else, and all other uses aren't also replaced, we must insert a Phantom use of the original child. This is a slight compile-time regression but has no effect on code-gen. It unlocks a bunch of optimization opportunities so I think it's worth it. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpAssumingJITType): * bytecode/CodeBlock.h: (JSC::CodeBlock::instructionCount): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGArrayifySlowPathGenerator.h: (JSC::DFG::ArrayifySlowPathGenerator::ArrayifySlowPathGenerator): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::setDirect): (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::eliminate): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGCommon.h: * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDCEPhase.cpp: (JSC::DFG::DCEPhase::run): (JSC::DFG::DCEPhase::fixupBlock): (JSC::DFG::DCEPhase::cleanVariables): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixEdge): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): * dfg/DFGLICMPhase.cpp: (JSC::DFG::LICMPhase::run): (JSC::DFG::LICMPhase::attemptHoist): * dfg/DFGMinifiedNode.cpp: (JSC::DFG::MinifiedNode::fromNode): * dfg/DFGMinifiedNode.h: (JSC::DFG::belongsInMinifiedGraph): (JSC::DFG::MinifiedNode::constantNumber): (JSC::DFG::MinifiedNode::weakConstant): * dfg/DFGNode.cpp: (JSC::DFG::Node::hasVariableAccessData): * dfg/DFGNode.h: (JSC::DFG::Node::convertToPhantom): (JSC::DFG::Node::convertToPhantomUnchecked): (JSC::DFG::Node::convertToIdentity): (JSC::DFG::Node::containsMovHint): (JSC::DFG::Node::hasUnlinkedLocal): (JSC::DFG::Node::willHaveCodeGenOrOSR): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGNodeFlags.h: * dfg/DFGNodeType.h: * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: (JSC::DFG::OSRAvailabilityAnalysisPhase::run): * dfg/DFGOSREntrypointCreationPhase.cpp: (JSC::DFG::OSREntrypointCreationPhase::run): * dfg/DFGOSRExit.cpp: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitBase.cpp: * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::doDoubleVoting): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::emitInvalidationPoint): (JSC::DFG::SpeculativeJIT::typeCheck): (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkArgumentTypes): (JSC::DFG::SpeculativeJIT::compileInt32ToDouble): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch): (JSC::DFG::SpeculativeJIT::needsTypeCheck): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks): (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validateCPS): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetArgument): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::compileMovHint): (JSC::FTL::LowerDFGToLLVM::compileZombieHint): (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble): (JSC::FTL::LowerDFGToLLVM::speculate): (JSC::FTL::LowerDFGToLLVM::typeCheck): (JSC::FTL::LowerDFGToLLVM::appendTypeCheck): (JSC::FTL::LowerDFGToLLVM::appendOSRExit): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): * ftl/FTLOSRExit.cpp: * ftl/FTLOSRExit.h: * tests/stress/dead-int32-to-double.js: Added. (foo): * tests/stress/dead-uint32-to-number.js: Added. (foo): 2013-12-25 Commit Queue Unreviewed, rolling out r161033 and r161074. http://trac.webkit.org/changeset/161033 http://trac.webkit.org/changeset/161074 https://bugs.webkit.org/show_bug.cgi?id=126240 Oliver says that a rollout would be better (Requested by ap on #webkit). * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setNewProperty): (JSC::PutPropertySlot::isCacheable): 2013-12-25 Filip Pizlo DFG PhantomArguments shouldn't rely on a dead Phi graph https://bugs.webkit.org/show_bug.cgi?id=126218 Reviewed by Oliver Hunt. This change dramatically rationalizes our handling of PhantomArguments (i.e. speculative elision of arguments object allocation). It's now the case that if we decide that we can elide arguments allocation, we just turn the arguments-creating node into a PhantomArguments and mark all locals that it's stored to as being arguments aliases. Being an arguments alias and being a PhantomArguments means basically the same thing: in DFG execution you have the empty value, on OSR exit an arguments object is allocated in your place, and all operations that use the value now just refer directly to the actual arguments in the call frame header (or the arguments we know that we passed to the call, in case of inlining). This means that we no longer have arguments simplification creating a dead Phi graph that then has to be interpreted by the OSR exit logic. That sort of never made any sense. This means that PhantomArguments now has a clear story in SSA: basically SSA just gets rid of the "locals" but everything else is the same. Finally, this means that we can more easily get rid of forward exiting. As I was working on the code to get rid of forward exiting, I realized that I'd have to carefully preserve the special meanings of MovHint and SetLocal in the case of PhantomArguments. It was really bizarre: even the semantics of MovHint were tied to our specific treatment of PhantomArguments. After this change this is no longer the case. One of the really cool things about this change is that arguments reification now just becomes a special kind of FlushFormat. This further unifies things: it means that a MovHint(PhantomArguments) and a SetLocal(PhantomArguments) both have the same meaning, since both of them dictate that the way we recover the local on exit is by reifying arguments. Previously, the SetLocal(PhantomArguments) case needed some special handling to accomplish this. A downside of this approach is that we will now emit code to store the empty value into aliased arguments variables, and we will even emit code to load that empty value as well. As far as I can tell this doesn't cost anything, since PhantomArguments are most profitable in cases where it allows us to simplify control flow and kill the arguments locals entirely. Of course, this isn't an issue in SSA form since SSA form also eliminates the locals. * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): (JSC::DFG::ArgumentsSimplificationPhase::detypeArgumentsReferencingPhantomChild): * dfg/DFGFlushFormat.cpp: (WTF::printInternal): * dfg/DFGFlushFormat.h: (JSC::DFG::resultFor): (JSC::DFG::useKindFor): (JSC::DFG::dataFormatFor): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGValueSource.h: (JSC::DFG::ValueSource::ValueSource): (JSC::DFG::ValueSource::forFlushFormat): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::flushFormat): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::buildExitArguments): 2013-12-23 Oliver Hunt Refactor PutPropertySlot to be aware of custom properties https://bugs.webkit.org/show_bug.cgi?id=126187 Reviewed by msaboff. Refactor PutPropertySlot, making the constructor take the thisValue used as a target. This results in a wide range of boilerplate changes to pass the new parameter. * API/JSObjectRef.cpp: (JSObjectSetProperty): * dfg/DFGOperations.cpp: (JSC::DFG::operationPutByValInternal): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JITOperations.cpp: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * runtime/Arguments.cpp: (JSC::Arguments::putByIndex): * runtime/ArrayPrototype.cpp: (JSC::putProperty): (JSC::arrayProtoFuncPush): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSCell.cpp: (JSC::JSCell::putByIndex): * runtime/JSFunction.cpp: (JSC::JSFunction::put): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::putByIndex): * runtime/JSONObject.cpp: (JSC::Walker::walk): * runtime/JSObject.cpp: (JSC::JSObject::putByIndex): (JSC::JSObject::putDirectNonIndexAccessor): (JSC::JSObject::deleteProperty): * runtime/JSObject.h: (JSC::JSObject::putDirect): * runtime/Lookup.h: (JSC::putEntry): (JSC::lookupPut): * runtime/PutPropertySlot.h: (JSC::PutPropertySlot::PutPropertySlot): (JSC::PutPropertySlot::setCustomProperty): (JSC::PutPropertySlot::thisValue): (JSC::PutPropertySlot::isCacheable): 2013-12-23 Benjamin Poulain Add class matching to the Selector Code Generator https://bugs.webkit.org/show_bug.cgi?id=126176 Reviewed by Antti Koivisto and Oliver Hunt. Add test and branch based on BaseIndex addressing for x86_64. Fast loops are needed to compete with clang on tight loops. * assembler/MacroAssembler.h: * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::branch64): (JSC::MacroAssemblerX86_64::branchPtr): * assembler/X86Assembler.h: (JSC::X86Assembler::cmpq_rm): 2013-12-23 Oliver Hunt Update custom setter implementations to perform type checks https://bugs.webkit.org/show_bug.cgi?id=126171 Reviewed by Daniel Bates. Modify the setter function signature to take encoded values as we're changing the setter usage everywhere anyway. * runtime/Lookup.h: (JSC::putEntry): 2013-12-23 Lucas Forschler Update copyright strings Reviewed by Dan Bernstein. * Info.plist: * JavaScriptCore.vcxproj/JavaScriptCore.resources/Info.plist: 2013-12-23 Zan Dobersek [GTK] Clean up compiler optimizations flags for libWTF, libJSC https://bugs.webkit.org/show_bug.cgi?id=126157 Reviewed by Gustavo Noronha Silva. * GNUmakefile.am: Remove the -fstrict-aliasing and -O3 compiler flags for libWTF.la. -O3 gets overridden by -O2 that's listed in CXXFLAGS (or -O0 in case of debug builds) and -fstrict-aliasing is enabled when -O2 is used (and shouldn't be enabled in debug builds anyway). 2013-12-22 Martin Robinson [CMake] Fix typo from r160812 https://bugs.webkit.org/show_bug.cgi?id=126145 Reviewed by Gustavo Noronha Silva. * CMakeLists.txt: Fix typo when detecting the type of library. 2013-12-22 Martin Robinson [GTK][CMake] libtool-compatible soversion calculation https://bugs.webkit.org/show_bug.cgi?id=125511 Reviewed by Gustavo Noronha Silva. * CMakeLists.txt: Use the POPULATE_LIBRARY_VERSION macro and the library-specific version information. 2013-12-23 Gustavo Noronha Silva [GTK] [CMake] Generate pkg-config files https://bugs.webkit.org/show_bug.cgi?id=125685 Reviewed by Martin Robinson. * PlatformGTK.cmake: Added. Generate javascriptcoregtk-3.0.pc. 2013-12-22 Benjamin Poulain Create a skeleton for CSS Selector code generation https://bugs.webkit.org/show_bug.cgi?id=126044 Reviewed by Antti Koivisto and Gavin Barraclough. * assembler/LinkBuffer.h: Add a new owner UID for code compiled for CSS. Export the symbols needed to link code from WebCore. 2013-12-19 Mark Hahnenberg Clean up DFG write barriers https://bugs.webkit.org/show_bug.cgi?id=126047 Reviewed by Filip Pizlo. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Use the register allocator to determine which registers need saving instead of saving every single one of them. (JSC::DFG::SpeculativeJIT::osrWriteBarrier): We don't need to save live register state because the write barriers during OSR execute when there are no live registers. Also we don't need to use pushes to pad the stack pointer for pokes on x86; we can just use an add. (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT.h: * jit/Repatch.cpp: (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): * runtime/VM.h: Get rid of writeBarrierRegisterBuffer since it's no longer used. 2013-12-20 Balazs Kilvady [MIPS] Missing MacroAssemblerMIPS::branchTest8(ResultCondition, BaseIndex, TrustedImm32) https://bugs.webkit.org/show_bug.cgi?id=126062 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::branchTest8): 2013-12-20 Julien Brianceau [sh4] Add missing implementation in MacroAssembler to fix build. https://bugs.webkit.org/show_bug.cgi?id=126063 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::branchTest8): 2013-12-20 Julien Brianceau [arm] Add missing implementation in MacroAssembler to fix CPU(ARM_TRADITIONAL) build. https://bugs.webkit.org/show_bug.cgi?id=126064 Reviewed by Mark Hahnenberg. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::branchTest8): 2013-12-19 Joseph Pecoraro Web Inspector: Add InspectorFrontendHost.debuggableType to let the frontend know it's backend is JavaScript or Web https://bugs.webkit.org/show_bug.cgi?id=126016 Reviewed by Timothy Hatcher. * inspector/remote/RemoteInspector.mm: (Inspector::RemoteInspector::listingForDebuggable): * inspector/remote/RemoteInspectorConstants.h: Include a debuggable type identifier in the debuggable listing, so the remote frontend can know if it is debugging a Web Page or JS Context. 2013-12-19 Benjamin Poulain Add an utility class to simplify generating function calls https://bugs.webkit.org/show_bug.cgi?id=125972 Reviewed by Geoffrey Garen. Split branchTest32 in two functions: test32AndSetFlags and branchOnFlags. This is done to allow code where the flags are set, multiple operation that do not modify the flags occur, then the flags are used. This is used for function calls to test the return value while discarding the return register. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::test32AndSetFlags): (JSC::MacroAssemblerX86Common::branchOnFlags): (JSC::MacroAssemblerX86Common::branchTest32): 2013-12-19 Mark Hahnenberg Put write barriers in the right places in the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=125975 Reviewed by Filip Pizlo. * jit/JIT.cpp: (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITInlines.h: (JSC::JIT::callOperation): (JSC::JIT::emitArrayProfilingSite): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_enter): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_enter): (JSC::JIT::emitSlow_op_enter): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitPutGlobalProperty): (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_init_global_const): (JSC::JIT::checkMarkWord): (JSC::JIT::emitWriteBarrier): (JSC::JIT::privateCompilePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitGenericContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::emit_op_put_by_id): (JSC::JIT::emitSlow_op_put_by_id): (JSC::JIT::emitPutGlobalProperty): (JSC::JIT::emitPutGlobalVar): (JSC::JIT::emitPutClosureVar): (JSC::JIT::emit_op_init_global_const): * jit/Repatch.cpp: (JSC::emitPutReplaceStub): (JSC::emitPutTransitionStub): (JSC::repatchPutByID): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-12-19 Brent Fulgham Implement ArrayBuffer.isView https://bugs.webkit.org/show_bug.cgi?id=126004 Reviewed by Filip Pizlo. Test coverage in webgl/1.0.2/resources/webgl_test_files/conformance/typedarrays/array-unit-tests.html * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): Add 'isView' to object constructor. (JSC::arrayBufferFuncIsView): New method. 2013-12-19 Mark Lam Fix broken C loop LLINT build. https://bugs.webkit.org/show_bug.cgi?id=126024. Reviewed by Oliver Hunt. * runtime/VM.h: 2013-12-18 Mark Hahnenberg DelayedReleaseScope is in the wrong place https://bugs.webkit.org/show_bug.cgi?id=125876 Reviewed by Geoffrey Garen. The DelayedReleaseScope needs to be around the free list sweeping in MarkedAllocator::tryAllocateHelper. This location gives us a good safe point between getting ready to allocate (i.e. identifying a non-empty free list) and doing the actual allocation (popping the free list). * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::tryAllocateHelper): (JSC::MarkedAllocator::allocateSlowCase): (JSC::MarkedAllocator::addBlock): * runtime/JSCellInlines.h: (JSC::allocateCell): 2013-12-18 Gustavo Noronha Silva [GTK][CMake] make libjavascriptcoregtk a public shared library again https://bugs.webkit.org/show_bug.cgi?id=125512 Reviewed by Martin Robinson. * CMakeLists.txt: use target type instead of SHARED_CORE to decide whether JavaScriptCore is a shared library, since it's always shared for GTK+ regardless of SHARED_CORE. 2013-12-18 Benjamin Poulain Add a simple stack abstraction for x86_64 https://bugs.webkit.org/show_bug.cgi?id=125908 Reviewed by Geoffrey Garen. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::addPtrNoFlags): Add an explicit abstraction for the "lea" instruction. This is needed by the experimental JIT to have add and substract without changing the flags. This is useful for function calls to test the return value, restore the registers, then branch on the flags from the return value. 2013-12-18 Mark Hahnenberg DFG should have a separate StoreBarrier node https://bugs.webkit.org/show_bug.cgi?id=125530 Reviewed by Filip Pizlo. This is in preparation for GenGC. We use a separate StoreBarrier node instead of making them implicitly part of other nodes so that it's easier to run analyses on them, e.g. for the StoreBarrierElisionPhase. They are inserted during the fixup phase. Initially they do not generate any code. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractHeap.h: * dfg/DFGAbstractInterpreter.h: (JSC::DFG::AbstractInterpreter::isKnownNotCell): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberizeForAllocation): (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): Whenever we insert new nodes that require StoreBarriers, we have to add those new StoreBarriers too. It's important to note that AllocatePropertyStorage and ReallocatePropertyStorage nodes require their StoreBarriers to come after them since they allocate first, which could cause a GC, and then store the resulting buffer into their JSCell, which requires the barrier. If we ever require that write barriers occur before stores, we'll have to split these nodes into AllocatePropertyStorage + StoreBarrier + PutPropertyStorage. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::insertStoreBarrier): * dfg/DFGNode.h: (JSC::DFG::Node::isStoreBarrier): * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): (JSC::DFG::SpeculativeJIT::genericWriteBarrier): The fast path write barrier check. It loads the byte that contains the mark bit of the object. (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): If the fast path check fails we try to store the cell in the WriteBarrierBuffer so as to avoid frequently flushing all registers in order to make a C call. (JSC::DFG::SpeculativeJIT::writeBarrier): (JSC::DFG::SpeculativeJIT::osrWriteBarrier): More barebones version of the write barrier to be executed during an OSR exit into baseline code. We must do this so that the baseline JIT object and array profiles are properly cleared during GC. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::cachedPutById): (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::writeBarrier): * dfg/DFGStoreBarrierElisionPhase.cpp: Added. New DFG phase that does block-local elision of redundant StoreBarriers. Every time a StoreBarrier on a particular object is executed, a bit is set indicating that that object doesn't need any more StoreBarriers. (JSC::DFG::StoreBarrierElisionPhase::StoreBarrierElisionPhase): (JSC::DFG::StoreBarrierElisionPhase::couldCauseGC): Nodes that could cause a GC reset the bits for all of the objects known in the current block. (JSC::DFG::StoreBarrierElisionPhase::allocatesFreshObject): A node that creates a new object automatically sets the bit for that object since if a GC occurred as the result of that object's allocation then that object would not need a barrier since it would be guaranteed to be a young generation object until the next GC point. (JSC::DFG::StoreBarrierElisionPhase::noticeFreshObject): (JSC::DFG::StoreBarrierElisionPhase::getBaseOfStore): (JSC::DFG::StoreBarrierElisionPhase::shouldBeElided): (JSC::DFG::StoreBarrierElisionPhase::elideBarrier): (JSC::DFG::StoreBarrierElisionPhase::handleNode): (JSC::DFG::StoreBarrierElisionPhase::handleBlock): (JSC::DFG::StoreBarrierElisionPhase::run): (JSC::DFG::performStoreBarrierElision): * dfg/DFGStoreBarrierElisionPhase.h: Added. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::flushWriteBarrierBuffer): * heap/Heap.h: (JSC::Heap::writeBarrier): * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfMarks): * heap/WriteBarrierBuffer.cpp: Added. The WriteBarrierBuffer buffers a set of JSCells that are awaiting a pending WriteBarrier. This buffer is used by the DFG to avoid the overhead of calling out to C repeatedly to invoke a write barrier on a single JSCell. Instead the DFG has inline code to fill the WriteBarrier buffer until its full, and then to call out to C to flush it. The WriteBarrierBuffer will also be flushed prior to each EdenCollection. (JSC::WriteBarrierBuffer::WriteBarrierBuffer): (JSC::WriteBarrierBuffer::~WriteBarrierBuffer): (JSC::WriteBarrierBuffer::flush): (JSC::WriteBarrierBuffer::reset): (JSC::WriteBarrierBuffer::add): * heap/WriteBarrierBuffer.h: Added. (JSC::WriteBarrierBuffer::currentIndexOffset): (JSC::WriteBarrierBuffer::capacityOffset): (JSC::WriteBarrierBuffer::bufferOffset): * jit/JITOperations.cpp: * jit/JITOperations.h: * runtime/VM.h: 2013-12-18 Carlos Garcia Campos Unreviewed. Fix make distcheck. * GNUmakefile.am: 2013-12-17 Julien Brianceau Fix armv7 and sh4 builds. https://bugs.webkit.org/show_bug.cgi?id=125848 Reviewed by Csaba Osztrogonác. * assembler/ARMv7Assembler.h: Include limits.h for INT_MIN. * assembler/SH4Assembler.h: Include limits.h for INT_MIN. 2013-12-16 Oliver Hunt Avoid indirect function calls for custom getters https://bugs.webkit.org/show_bug.cgi?id=125821 Reviewed by Mark Hahnenberg. Rather than invoking a helper function to perform an indirect call through a function pointer, just have the JIT call the function directly. Unfortunately this only works in JSVALUE64 at the moment as there is not an obvious way to pass two EncodedJSValues uniformly over the various effected JITs. * jit/CCallHelpers.h: (JSC::CCallHelpers::setupArguments): * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryBuildGetByIDList): 2013-12-16 Joseph Pecoraro Fix some whitespace issues in inspector code https://bugs.webkit.org/show_bug.cgi?id=125814 Reviewed by Darin Adler. * inspector/protocol/Debugger.json: * inspector/protocol/Runtime.json: * inspector/scripts/CodeGeneratorInspector.py: (Generator.process_command): 2013-12-16 Mark Hahnenberg Add some missing functions to MacroAssembler https://bugs.webkit.org/show_bug.cgi?id=125809 Reviewed by Oliver Hunt. * assembler/AbstractMacroAssembler.h: * assembler/AssemblerBuffer.h: * assembler/LinkBuffer.cpp: * assembler/MacroAssembler.h: (JSC::MacroAssembler::storePtr): (JSC::MacroAssembler::andPtr): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::and64): (JSC::MacroAssemblerARM64::branchTest8): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branchTest8): * assembler/X86Assembler.h: 2013-12-16 Brent Fulgham [Win] Remove dead code after conversion to VS2013 https://bugs.webkit.org/show_bug.cgi?id=125795 Reviewed by Darin Adler. * API/tests/testapi.c: Remove local nan implementation 2013-12-16 Oliver Hunt Cache getters and custom accessors on the prototype chain https://bugs.webkit.org/show_bug.cgi?id=125602 Reviewed by Michael Saboff. Support caching of custom getters and accessors on the prototype chain. This is relatively trivial and just requires a little work compared to the direct access mode as we're under more register pressure. * bytecode/StructureStubInfo.h: Removed the unsued initGetByIdProto as it was confusing to still have it present. * jit/Repatch.cpp: (JSC::generateProtoChainAccessStub): (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): 2013-12-16 Mark Lam Change slow path result to take a void* instead of a ExecState*. https://bugs.webkit.org/show_bug.cgi?id=125802. Reviewed by Filip Pizlo. This is in preparation for C Stack OSR entry work that is coming soon. In the OSR entry case, we'll be returning a topOfFrame pointer value instead of the ExecState*. * offlineasm/cloop.rb: * runtime/CommonSlowPaths.h: (JSC::encodeResult): (JSC::decodeResult): 2013-12-16 Alex Christensen Fixed Win64 build on VS2013. https://bugs.webkit.org/show_bug.cgi?id=125753 Reviewed by Brent Fulgham. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Added correct PlatformToolset for 64-bit builds. 2013-12-16 Peter Szanka Delete RVCT related code parts. https://bugs.webkit.org/show_bug.cgi?id=125626 Reviewed by Darin Adler. * assembler/ARMAssembler.cpp: * assembler/ARMAssembler.h: (JSC::ARMAssembler::cacheFlush): * assembler/MacroAssemblerARM.cpp: (JSC::isVFPPresent): * jit/JITStubsARM.h: * jit/JITStubsARMv7.h: 2013-12-15 Ryosuke Niwa REGRESSION: 2x regression on Dromaeo DOM query tests https://bugs.webkit.org/show_bug.cgi?id=125377 Reviewed by Filip Pizlo. The bug was caused by JSC not JIT'ing property access on "document" due to its type info having HasImpureGetOwnPropertySlot flag. Fixed the bug by new type info flag NewImpurePropertyFiresWatchpoints, which allows the baseline JIT to generate byte code for access properties on an object with named properties (a.k.a. custom name getter) in DOM. When a new named property appears on the object, VM is notified via VM::addImpureProperty and fires StructureStubClearingWatchpoint added during the repatch. * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeFromLLInt): Take the slow path if we have any object with impure properties in the prototype chain. (JSC::GetByIdStatus::computeForChain): Ditto. * jit/Repatch.cpp: (JSC::repatchByIdSelfAccess): Throw away the byte code when a new impure property is added on any object in the prototype chain via StructureStubClearingWatchpoint. (JSC::generateProtoChainAccessStub): Ditto. (JSC::tryCacheGetByID): (JSC::tryBuildGetByIDList): (JSC::tryRepatchIn): Ditto. * runtime/JSTypeInfo.h: Added NewImpurePropertyFiresWatchpoints. (JSC::TypeInfo::newImpurePropertyFiresWatchpoints): Added. * runtime/Operations.h: (JSC::normalizePrototypeChainForChainAccess): Don't exit early if VM will be notified of new impure property even if the object had impure properties. * runtime/Structure.h: (JSC::Structure::takesSlowPathInDFGForImpureProperty): Added. Wraps hasImpureGetOwnPropertySlot and asserts that newImpurePropertyFiresWatchpoints is true whenever hasImpureGetOwnPropertySlot is true. * runtime/VM.cpp: (JSC::VM::registerWatchpointForImpureProperty): Added. (JSC::VM::addImpureProperty): Added. HTMLDocument calls it to notify JSC of a new impure property. * runtime/VM.h: 2013-12-15 Andy Estes [iOS] Upstream changes to FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=125742 Reviewed by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: 2013-12-14 Filip Pizlo FTL should *really* know when things are flushed https://bugs.webkit.org/show_bug.cgi?id=125747 Reviewed by Sam Weinig. Fix more codegen badness. This makes V8v7's crypto am3() function run faster in the FTL than in DFG. This means that even if we just compile those functions in V8v7 that don't make calls, the FTL gives us a 2% speed-up over the DFG. That's pretty good considering that we have still more optimizations to fix and we can make calls work. * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * ftl/FTLCompile.cpp: (JSC::FTL::fixFunctionBasedOnStackMaps): 2013-12-14 Andy Estes Unify FeatureDefines.xcconfig https://bugs.webkit.org/show_bug.cgi?id=125741 Rubber-stamped by Dan Bernstein. * Configurations/FeatureDefines.xcconfig: Enable ENABLE_MEDIA_SOURCE. 2013-12-14 Mark Rowe Build fix after r160557. r160557 added the first generated header to JavaScriptCore that needs to be installed in to the framework wrapper. Sadly JavaScriptCore's Derived Sources target was not set to generate headers when invoked as part of the installhdrs action. This resulted in the build failing due to Xcode being unable to find the header file to install. The fix for this is to configure the Derived Sources target to use JavaScriptCore.xcconfig, which sets INSTALLHDRS_SCRIPT_PHASE to YES and allows Xcode to generate derived sources during the installhdrs action. Enabling INSTALLHDRS_SCRIPT_PHASE required tweaking the Generate Derived Sources script build phase to skip running code related to offlineasm that depends on JSCLLIntOffsetExtractor having been compiled, which isn't the case at installhdrs time. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-13 Joseph Pecoraro Some Set and Map prototype functions have incorrect function lengths https://bugs.webkit.org/show_bug.cgi?id=125732 Reviewed by Oliver Hunt. * runtime/MapPrototype.cpp: (JSC::MapPrototype::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2013-12-13 Joseph Pecoraro Web Inspector: Move Inspector and Debugger protocol domains into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=125707 Reviewed by Timothy Hatcher. * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * inspector/protocol/Debugger.json: Renamed from Source/WebCore/inspector/protocol/Debugger.json. * inspector/protocol/GenericTypes.json: Added. * inspector/protocol/InspectorDomain.json: Renamed from Source/WebCore/inspector/protocol/InspectorDomain.json. Add new files to inspector generation. * inspector/scripts/CodeGeneratorInspector.py: (Generator.go): Only build TypeBuilder output if the domain only has types. Avoid backend/frontend dispatchers and backend commands. (TypeBindings.create_type_declaration_.EnumBinding.get_setter_value_expression_pattern): (format_setter_value_expression): (Generator.process_command): (Generator.generate_send_method): * inspector/scripts/CodeGeneratorInspectorStrings.py: Export and name the get{JS,Web}EnumConstant function. 2013-12-11 Filip Pizlo Get rid of forward exit on UInt32ToNumber by adding an op_unsigned bytecode instruction https://bugs.webkit.org/show_bug.cgi?id=125553 Reviewed by Oliver Hunt. UInt32ToNumber was a super complicated node because it had to do a speculation, but it would do it after we already had computed the urshift. It couldn't just back to the beginning of the urshift because the inputs to the urshift weren't necessarily live anymore. We couldn't jump forward to the beginning of the next instruction because the result of the urshift was not yet unsigned-converted. For a while we solved this by forward-exiting in UInt32ToNumber. But that's really gross and I want to get rid of all forward exits. They cause a lot of bugs. We could also have turned UInt32ToNumber to a backwards exit by forcing the inputs to the urshift to be live. I figure that this might be a bit too extreme. So, I just created a new place that we can exit to: I split op_urshift into op_urshift followed by op_unsigned. op_unsigned is an "unsigned cast" along the lines of what UInt32ToNumber does. This allows me to get rid of all of the nastyness in the DFG for forward exiting in UInt32ToNumber. This patch enables massive code carnage in the DFG and FTL, and brings us closer to eliminating one of the DFG's most confusing concepts. On the flipside, it does make the bytecode slightly more complex (one new instruction). This is a profitable trade. We want the DFG and FTL to trend towards simplicity, since they are both currently too complicated. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/ValueRecovery.cpp: (JSC::ValueRecovery::dumpInContext): * bytecode/ValueRecovery.h: (JSC::ValueRecovery::gpr): * bytecompiler/NodesCodegen.cpp: (JSC::BinaryOpNode::emitBytecode): (JSC::emitReadModifyAssignment): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::toInt32): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGNodeType.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileMovHint): (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild1): (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild2): * ftl/FTLFormattedValue.h: (JSC::FTL::int32Value): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber): * ftl/FTLValueFormat.cpp: (JSC::FTL::reboxAccordingToFormat): (WTF::printInternal): * ftl/FTLValueFormat.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_urshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emitSlow_op_unsigned): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitRightShift): (JSC::JIT::emitRightShiftSlowCase): (JSC::JIT::emit_op_unsigned): (JSC::JIT::emitSlow_op_unsigned): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2013-12-13 Mark Hahnenberg LLInt should not conditionally branch to to labels outside of its function https://bugs.webkit.org/show_bug.cgi?id=125713 Reviewed by Geoffrey Garen. Conditional branches are insufficient for jumping to out-of-function labels. The fix is to use an unconditional jmp to the label combined with a conditional branch around the jmp. * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: 2013-12-13 Joseph Pecoraro [GTK] Remove Warnings in building about duplicate INSPECTOR variables https://bugs.webkit.org/show_bug.cgi?id=125710 Reviewed by Tim Horton. * GNUmakefile.am: 2013-12-13 Joseph Pecoraro Cleanup CodeGeneratorInspectorStrings a bit https://bugs.webkit.org/show_bug.cgi?id=125705 Reviewed by Timothy Hatcher. * inspector/scripts/CodeGeneratorInspectorStrings.py: Use ${foo} variable syntax and add an ASCIILiteral. 2013-12-13 Brent Fulgham [Win] Unreviewed build fix after r160563 * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Missed the Debug target in my last patch. 2013-12-13 Brent Fulgham [Win] Unreviewed build fix after r160548 * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj: Specify that we are using the vs12_xp target for Makefile-based projects. * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Ditto * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Ditto. 2013-12-13 Joseph Pecoraro Make inspector folder groups smarter in JavaScriptCore.xcodeproj https://bugs.webkit.org/show_bug.cgi?id=125663 Reviewed by Darin Adler. * JavaScriptCore.xcodeproj/project.pbxproj: 2013-12-13 Joseph Pecoraro Web Inspector: Add Inspector Code Generation to JavaScriptCore for Runtime Domain https://bugs.webkit.org/show_bug.cgi?id=125595 Reviewed by Timothy Hatcher. - Move CodeGeneration scripts from WebCore into JavaScriptCore/inspector/scripts - For ports that build WebKit frameworks separately, export the scripts as PrivateHeaders - Update CodeGeneratorInspector.py in a few ways: - output dynamic filenames, so JavaScriptCore generates InspectorJSFoo.* and WebCore generates InspectorWebFoo.* - take in more then one protocol JSON file. The first contains domains to generate, the others are dependencies that are generated elsewhere that we can depend on for Types. - Add DerivedSources build step to generate the Inspector Interfaces * CMakeLists.txt: * DerivedSources.make: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.xcodeproj/project.pbxproj: Add scripts and code generation. * inspector/protocol/Runtime.json: Renamed from Source/WebCore/inspector/protocol/Runtime.json. Move protocol file into JavaScriptCore so its types will be generated in JavaScriptCore. * inspector/scripts/CodeGeneratorInspector.py: Renamed from Source/WebCore/inspector/CodeGeneratorInspector.py. Updates to the script as listed above. * inspector/scripts/CodeGeneratorInspectorStrings.py: Renamed from Source/WebCore/inspector/CodeGeneratorInspectorStrings.py. * inspector/scripts/generate-combined-inspector-json.py: Renamed from Source/WebCore/inspector/Scripts/generate-combined-inspector-json.py. Moved from WebCore into JavaScriptCore for code generation. 2013-12-13 Peter Szanka Delete INTEL C compiler related code parts. https://bugs.webkit.org/show_bug.cgi?id=125625 Reviewed by Darin Adler. * jsc.cpp: * testRegExp.cpp: 2013-12-13 Brent Fulgham [Win] Switch WebKit solution to Visual Studio 2013 https://bugs.webkit.org/show_bug.cgi?id=125192 Reviewed by Anders Carlsson. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Update for VS2013 * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Ditto * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Ditto * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto 2013-12-12 Joseph Pecoraro Add a few more ASCIILiterals https://bugs.webkit.org/show_bug.cgi?id=125662 Reviewed by Darin Adler. * inspector/InspectorBackendDispatcher.cpp: (Inspector::InspectorBackendDispatcher::dispatch): 2013-12-12 Joseph Pecoraro Test new JSContext name APIs https://bugs.webkit.org/show_bug.cgi?id=125607 Reviewed by Darin Adler. * API/JSContext.h: * API/JSContextRef.h: Fix whitespace issues. * API/tests/testapi.c: (globalContextNameTest): (main): * API/tests/testapi.mm: Add tests for JSContext set/get name APIs. 2013-12-11 Filip Pizlo ARM64: Hang running pdfjs test, suspect DFG generated code for "in" https://bugs.webkit.org/show_bug.cgi?id=124727 Reviewed by Michael Saboff. Get rid of In's hackish use of StructureStubInfo. Previously it was using hotPathBegin, and it was the only IC that used that field, which was wasteful. Moreover, it used it to store two separate locations: the label for patching the jump and the label right after the jump. The code was relying on those two being the same label, which is true on X86 and some other platforms, but it isn't true on ARM64. This gets rid of hotPathBegin and makes In express those two locations as offsets from the callReturnLocation, which is analogous to what the other IC's do. This fixes a bug where any successful In patching would result in a trivially infinite loop - and hence a hang - on ARM64. * bytecode/StructureStubInfo.h: * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::InRecord::InRecord): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIn): * jit/JITInlineCacheGenerator.cpp: (JSC::JITByIdGenerator::finalize): * jit/Repatch.cpp: (JSC::replaceWithJump): (JSC::patchJumpToGetByIdStub): (JSC::tryCachePutByID): (JSC::tryBuildPutByIdList): (JSC::tryRepatchIn): (JSC::resetGetByID): (JSC::resetPutByID): (JSC::resetIn): 2013-12-11 Joseph Pecoraro Web Inspector: Push More Inspector Required Classes Down into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=125324 Reviewed by Timothy Hatcher. * CMakeLists.txt: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: * JavaScriptCore.vcxproj/copy-files.cmd: * JavaScriptCore.xcodeproj/project.pbxproj: * bindings/ScriptFunctionCall.cpp: Renamed from Source/WebCore/bindings/js/ScriptFunctionCall.cpp. * bindings/ScriptFunctionCall.h: Renamed from Source/WebCore/bindings/js/ScriptFunctionCall.h. * bindings/ScriptObject.cpp: Copied from Source/WebCore/inspector/WorkerConsoleAgent.cpp. * bindings/ScriptObject.h: Renamed from Source/WebCore/inspector/InspectorBaseAgent.h. * bindings/ScriptValue.cpp: Renamed from Source/WebCore/bindings/js/ScriptValue.cpp. * bindings/ScriptValue.h: Renamed from Source/WebCore/bindings/js/ScriptValue.h. * inspector/InspectorAgentBase.h: Copied from Source/WebCore/inspector/InspectorAgentRegistry.h. * inspector/InspectorAgentRegistry.cpp: Renamed from Source/WebCore/inspector/InspectorAgentRegistry.cpp. * inspector/InspectorBackendDispatcher.h: Renamed from Source/WebCore/inspector/InspectorBackendDispatcher.h. (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): (Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): * inspector/InspectorValues.cpp: Renamed from Source/WebCore/inspector/InspectorValues.cpp. * inspector/InspectorValues.h: Renamed from Source/WebCore/inspector/InspectorValues.h. 2013-12-11 Laszlo Vidacs Store SHA1 hash in std::array https://bugs.webkit.org/show_bug.cgi?id=125446 Reviewed by Darin Adler. Change Vector to std::array and use typedef. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): 2013-12-11 Mark Rowe Modernize the JavaScriptCore API headers This consists of three main changes: 1) Converting the return type of initializer methods to instancetype. 2) Declaring properties rather than getters and setters. 3) Tagging C API methods with information about their memory management semantics. Changing the declarations from getters and setters to properties also required updating the headerdoc in a number of places. Reviewed by Anders Carlsson. * API/JSContext.h: * API/JSContext.mm: * API/JSManagedValue.h: * API/JSManagedValue.mm: * API/JSStringRefCF.h: * API/JSValue.h: * API/JSVirtualMachine.h: * API/JSVirtualMachine.mm: 2013-12-11 Mark Rowe Move JavaScriptCore off the legacy WebKit availability macros The legacy WebKit availability macros are verbose, confusing, and provide no benefit over using the system availability macros directly. The original vision was that they'd serve a cross-platform purpose but that never came to be. Map from WebKit version to OS X version based on the mapping in WebKitAvailability.h. All iOS versions are specified as 7.0 as that is when the JavaScriptCore C API was made public. Part of . Reviewed by Anders Carlsson. * API/JSBasePrivate.h: * API/JSContextRef.h: * API/JSContextRefPrivate.h: * API/JSObjectRef.h: * API/JSValueRef.h: 2013-12-10 Filip Pizlo Get rid of forward exit on DoubleAsInt32 https://bugs.webkit.org/show_bug.cgi?id=125552 Reviewed by Oliver Hunt. The forward exit was just there so that we wouldn't have to keep the inputs alive up to the DoubleAsInt32. That's dumb. Forward exits are a complicated piece of machinery and we shouldn't have it just for a bit of liveness micro-optimization. Also add a bunch of machinery to test this case on X86. * assembler/AbstractMacroAssembler.h: (JSC::optimizeForARMv7s): (JSC::optimizeForARM64): (JSC::optimizeForX86): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32): * runtime/Options.h: * tests/stress/double-as-int32.js: Added. (foo): (test): 2013-12-10 Filip Pizlo Simplify CSE's treatment of NodeRelevantToOSR https://bugs.webkit.org/show_bug.cgi?id=125538 Reviewed by Oliver Hunt. Make the NodeRelevantToOSR thing obvious: if there is any MovHint on a node then the node is relevant to OSR. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::performNodeCSE): (JSC::DFG::CSEPhase::performBlockCSE): 2013-12-10 Filip Pizlo Get rid of forward exit in GetByVal on Uint32Array https://bugs.webkit.org/show_bug.cgi?id=125543 Reviewed by Oliver Hunt. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): 2013-12-10 Balazs Kilvady [MIPS] Redundant instructions in code generated from offlineasm. https://bugs.webkit.org/show_bug.cgi?id=125528 Reviewed by Michael Saboff. Optimize lowering of offlineasm BaseIndex Addresses. * offlineasm/mips.rb: 2013-12-10 Oliver Hunt Reduce the mass templatizing of the JS parser https://bugs.webkit.org/show_bug.cgi?id=125535 Reviewed by Michael Saboff. The various caches we have now have removed the need for many of the template vs. regular parameters. This patch converts those template parameters to regular parameters and updates the call sites. This reduces the code size of the parser by around 15%. * parser/ASTBuilder.h: (JSC::ASTBuilder::createGetterOrSetterProperty): (JSC::ASTBuilder::createProperty): * parser/Parser.cpp: (JSC::::parseInner): (JSC::::parseSourceElements): (JSC::::parseVarDeclarationList): (JSC::::createBindingPattern): (JSC::::tryParseDeconstructionPatternExpression): (JSC::::parseDeconstructionPattern): (JSC::::parseSwitchClauses): (JSC::::parseSwitchDefaultClause): (JSC::::parseBlockStatement): (JSC::::parseFormalParameters): (JSC::::parseFunctionInfo): (JSC::::parseFunctionDeclaration): (JSC::::parseProperty): (JSC::::parseObjectLiteral): (JSC::::parseStrictObjectLiteral): (JSC::::parseMemberExpression): * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::createGetterOrSetterProperty): 2013-12-10 Mark Hahnenberg ASSERT !heap.vm()->isInitializingObject() when finishing DFG compilation at beginning of GC https://bugs.webkit.org/show_bug.cgi?id=125472 Reviewed by Geoff Garen. This patch makes it look like it's okay to allocate so that the DFG plan finalization stuff can do what it needs to do. We already expected that we might do allocation during plan finalization and we increased the deferral depth to handle this, but we need to fix this other ASSERT stuff too. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::collect): * heap/Heap.h: * heap/RecursiveAllocationScope.h: Added. (JSC::RecursiveAllocationScope::RecursiveAllocationScope): (JSC::RecursiveAllocationScope::~RecursiveAllocationScope): * runtime/VM.h: 2013-12-09 Filip Pizlo Impose and enforce some basic rules of sanity for where Phi functions are allowed to occur and where their (optional) corresponding MovHints can be https://bugs.webkit.org/show_bug.cgi?id=125480 Reviewed by Geoffrey Garen. Previously, if you wanted to insert some speculation right after where a value was produced, you'd get super confused if that value was produced by a Phi node. You can't necessarily insert speculations after a Phi node because Phi nodes appear in this special sequence of Phis and MovHints that establish the OSR exit state for a block. So, you'd probably want to search for the next place where it's safe to insert things. We already do this "search for beginning of next bytecode instruction" search by looking at the next node that has a different CodeOrigin. But this would be hard for a Phi because those Phis and MovHints have basically random CodeOrigins and they can all have different CodeOrigins. This change imposes some sanity for this situation: - Phis must have unset CodeOrigins. - In each basic block, all nodes that have unset CodeOrigins must come before all nodes that have set CodeOrigins. This all ends up working out just great because prior to this change we didn't have a use for unset CodeOrigins. I think it's appropriate to make "unset CodeOrigin" mean that we're in the prologue of a basic block. It's interesting what this means for block merging, which we don't yet do in SSA. Consider merging the edge A->B. One possibility is that the block merger is now required to clean up Phi/Upsilons, and reascribe the MovHints to have the CodeOrigin of the A's block terminal. But an answer that might be better is that the originless nodes at the top of the B are just given the origin of the terminal and we keep the Phis. That would require changing the above rules. We'll see how it goes, and what we end up picking... Overall, this special-things-at-the-top rule is analogous to what other SSA-based compilers do. For example, LLVM has rules mandating that Phis appear at the top of a block. * bytecode/CodeOrigin.cpp: (JSC::CodeOrigin::dump): * dfg/DFGOSRExitBase.h: (JSC::DFG::OSRExitBase::OSRExitBase): * dfg/DFGSSAConversionPhase.cpp: (JSC::DFG::SSAConversionPhase::run): * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): (JSC::DFG::Validate::validateSSA): 2013-12-08 Filip Pizlo Reveal array bounds checks in DFG IR https://bugs.webkit.org/show_bug.cgi?id=125253 Reviewed by Oliver Hunt and Mark Hahnenberg. In SSA mode, this reveals array bounds checks and the load of array length in DFG IR, making this a candidate for LICM. This also fixes a long-standing performance bug where the JSObject slow paths would always create contiguous storage, rather than type-specialized storage, when doing a "storage creating" storage, like: var o = {}; o[0] = 42; * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/ExitKind.cpp: (JSC::exitKindToString): (JSC::exitKindIsCountable): * bytecode/ExitKind.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGArrayMode.cpp: (JSC::DFG::permitsBoundsCheckLowering): (JSC::DFG::ArrayMode::permitsBoundsCheckLowering): * dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::lengthNeedsStorage): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSSALoweringPhase.cpp: Added. (JSC::DFG::SSALoweringPhase::SSALoweringPhase): (JSC::DFG::SSALoweringPhase::run): (JSC::DFG::SSALoweringPhase::handleNode): (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): (JSC::DFG::performSSALowering): * dfg/DFGSSALoweringPhase.h: Added. * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileDoublePutByVal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileCheckInBounds): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds): * runtime/JSObject.cpp: (JSC::JSObject::convertUndecidedForValue): (JSC::JSObject::createInitialForValueAndSet): (JSC::JSObject::putByIndexBeyondVectorLength): (JSC::JSObject::putDirectIndexBeyondVectorLength): * runtime/JSObject.h: * tests/stress/float32array-out-of-bounds.js: Added. (make): (foo): (test): * tests/stress/int32-object-out-of-bounds.js: Added. (make): (foo): (test): * tests/stress/int32-out-of-bounds.js: Added. (foo): (test): 2013-12-09 Sam Weinig Replace use of WTF::FixedArray with std::array https://bugs.webkit.org/show_bug.cgi?id=125475 Reviewed by Anders Carlsson. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::dump): * bytecode/Opcode.cpp: (JSC::OpcodeStats::~OpcodeStats): * dfg/DFGCSEPhase.cpp: * ftl/FTLAbstractHeap.h: * heap/MarkedSpace.h: * parser/ParserArena.h: * runtime/CodeCache.h: * runtime/DateInstanceCache.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::reset): * runtime/JSGlobalObject.h: * runtime/JSString.h: * runtime/LiteralParser.h: * runtime/NumericStrings.h: * runtime/RegExpCache.h: * runtime/SmallStrings.h: 2013-12-09 Joseph Pecoraro Remove miscellaneous unnecessary build statements https://bugs.webkit.org/show_bug.cgi?id=125466 Reviewed by Darin Adler. * DerivedSources.make: * JavaScriptCore.vcxproj/build-generated-files.sh: * JavaScriptCore.xcodeproj/project.pbxproj: * make-generated-sources.sh: 2013-12-08 Filip Pizlo CSE should work in SSA https://bugs.webkit.org/show_bug.cgi?id=125430 Reviewed by Oliver Hunt and Mark Hahnenberg. * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::run): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): 2013-12-09 Joseph Pecoraro Remove docs/make-bytecode-docs.pl https://bugs.webkit.org/show_bug.cgi?id=125462 This sript is very old and no longer outputs useful data since the op code definitions have moved from Interpreter.cpp. Reviewed by Darin Adler. * DerivedSources.make: * docs/make-bytecode-docs.pl: Removed. 2013-12-09 Julien Brianceau Fix sh4 LLINT build. https://bugs.webkit.org/show_bug.cgi?id=125454 Reviewed by Michael Saboff. In LLINT, sh4 backend implementation didn't handle properly conditional jumps using a LabelReference instance. This patch fixes it through sh4LowerMisplacedLabels phase. Also, to avoid the need of a 4th temporary gpr, this phase is triggered later in getModifiedListSH4. * offlineasm/sh4.rb: 2013-12-08 Filip Pizlo Add the notion of ConstantStoragePointer to DFG IR https://bugs.webkit.org/show_bug.cgi?id=125395 Reviewed by Oliver Hunt. This pushes more typed array folding into StrengthReductionPhase, and enables CSE on storage pointers. Previously, you might have separate nodes for the same storage pointer and this would cause some bad register pressure in the DFG. Note that this was really a theoretical problem and not, to my knowledge a practical one - so this patch is basically just a clean-up. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::constantStoragePointerCSE): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::convertToConstantStoragePointer): (JSC::DFG::Node::hasStoragePointer): (JSC::DFG::Node::storagePointer): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileConstantStoragePointer): (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): 2013-12-08 Filip Pizlo FTL should support UntypedUse versions of Compare nodes https://bugs.webkit.org/show_bug.cgi?id=125426 Reviewed by Oliver Hunt. This adds UntypedUse versions of all comparisons except CompareStrictEq, which is sufficiently different that I thought I'd do it in another patch. This also extends our ability to abstract over comparison kind and removes a bunch of copy-paste code. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileCompareEq): (JSC::FTL::LowerDFGToLLVM::compileCompareLess): (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq): (JSC::FTL::LowerDFGToLLVM::compileCompareGreater): (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq): (JSC::FTL::LowerDFGToLLVM::compare): (JSC::FTL::LowerDFGToLLVM::nonSpeculativeCompare): * ftl/FTLOutput.h: (JSC::FTL::Output::icmp): (JSC::FTL::Output::equal): (JSC::FTL::Output::notEqual): (JSC::FTL::Output::above): (JSC::FTL::Output::aboveOrEqual): (JSC::FTL::Output::below): (JSC::FTL::Output::belowOrEqual): (JSC::FTL::Output::greaterThan): (JSC::FTL::Output::greaterThanOrEqual): (JSC::FTL::Output::lessThan): (JSC::FTL::Output::lessThanOrEqual): (JSC::FTL::Output::fcmp): (JSC::FTL::Output::doubleEqual): (JSC::FTL::Output::doubleNotEqualOrUnordered): (JSC::FTL::Output::doubleLessThan): (JSC::FTL::Output::doubleLessThanOrEqual): (JSC::FTL::Output::doubleGreaterThan): (JSC::FTL::Output::doubleGreaterThanOrEqual): (JSC::FTL::Output::doubleEqualOrUnordered): (JSC::FTL::Output::doubleNotEqual): (JSC::FTL::Output::doubleLessThanOrUnordered): (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrUnordered): (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): * tests/stress/untyped-equality.js: Added. (foo): * tests/stress/untyped-less-than.js: Added. (foo): 2013-12-07 Filip Pizlo Fold typedArray.length if typedArray is constant https://bugs.webkit.org/show_bug.cgi?id=125252 Reviewed by Sam Weinig. This was meant to be easy. The problem is that there was no good place for putting the folding of typedArray.length to a constant. You can't quite do it in the bytecode parser because at that point you don't yet know if typedArray is really a typed array. You can't do it as part of constant folding because the folder assumes that it can opportunistically forward-flow a constant value without changing the IR; this doesn't work since we need to first change the IR to register a desired watchpoint and only after that can we introduce that constant. We could have done it in Fixup but that would have been awkward since Fixup's code for turning a GetById of "length" into GetArrayLength is already somewhat complex. We could have done it in CSE but CSE is already fairly gnarly and will probably get rewritten. So I introduced a new phase, called StrengthReduction. This phase should have any transformations that don't requite CFA or CSE and that it would be weird to put into those other phases. I also took the opportunity to refactor some of the other folding code. This also adds a test, but the test couldn't quite be a LayoutTests/js/regress so I introduced the notion of JavaScriptCore/tests/stress. The goal of this patch isn't really to improve performance or anything like that. It adds an optimization for completeness, and in doing so it unlocks a bunch of new possibilities. The one that I'm most excited about is revealing array length checks in DFG IR, which will allow for array bounds check hoisting and elimination. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): (JSC::DFG::Graph::tryGetFoldableViewForChild1): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::hasTypedArray): (JSC::DFG::Node::typedArray): * dfg/DFGNodeType.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStrengthReductionPhase.cpp: Added. (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase): (JSC::DFG::StrengthReductionPhase::run): (JSC::DFG::StrengthReductionPhase::handleNode): (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant): (JSC::DFG::performStrengthReduction): * dfg/DFGStrengthReductionPhase.h: Added. * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): * jsc.cpp: (GlobalObject::finishCreation): (functionTransferArrayBuffer): * runtime/ArrayBufferView.h: * tests/stress: Added. * tests/stress/fold-typed-array-properties.js: Added. (foo): 2013-12-07 [email protected] [Win][64-bit] Hitting breakpoint assembler instruction in callToJavaScript. https://bugs.webkit.org/show_bug.cgi?id=125382 Reviewed by Michael Saboff. The WinCairo results from run-javascriptcore-tests are the same as the WinCairo 32-bits results, when removing these breakpoints. * jit/JITStubsMSVC64.asm: Remove breakpoint instructions. 2013-12-06 Filip Pizlo FTL should support all of Branch/LogicalNot https://bugs.webkit.org/show_bug.cgi?id=125370 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::boolify): 2013-12-06 Roger Fong and Brent Fulgham [Win] Support compiling with VS2013 https://bugs.webkit.org/show_bug.cgi?id=125353 Reviewed by Anders Carlsson. * API/tests/testapi.c: Use C99 defines if available. * jit/JITOperations.cpp: Don't attempt to define C linkage when returning a C++ object. 2013-12-06 Filip Pizlo FTL should support generic ByVal accesses https://bugs.webkit.org/show_bug.cgi?id=125368 Reviewed by Mark Hahnenberg. * dfg/DFGGraph.h: (JSC::DFG::Graph::isStrictModeFor): (JSC::DFG::Graph::ecmaModeFor): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): 2013-12-06 Filip Pizlo FTL should support hole/OOB array accesses https://bugs.webkit.org/show_bug.cgi?id=118077 Reviewed by Oliver Hunt and Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::baseIndex): 2013-12-06 Michael Saboff Split sizing of VarArgs frames from loading arguments for the frame https://bugs.webkit.org/show_bug.cgi?id=125331 Reviewed by Filip Pizlo. Split loadVarargs into sizeAndAllocFrameForVarargs() and loadVarargs() in preparation for moving onto the C stack. sizeAndAllocFrameForVarargs() will compute the size of the callee frame and allocate it, while loadVarargs() actually loads the argument values. As part of moving onto the C stack, sizeAndAllocFrameForVarargs() will be changed to a function that just computes the size. The caller will use that size to allocate the new frame on the stack before calling loadVargs() and actually making the call. * interpreter/Interpreter.cpp: (JSC::sizeAndAllocFrameForVarargs): (JSC::loadVarargs): * interpreter/Interpreter.h: * jit/JIT.h: * jit/JITCall.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITCall32_64.cpp: (JSC::JIT::compileLoadVarargs): * jit/JITInlines.h: (JSC::JIT::callOperation): * jit/JITOperations.cpp: * jit/JITOperations.h: * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LLIntSlowPaths.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/VM.h: 2013-12-06 Filip Pizlo FTL should support all of ValueToInt32 https://bugs.webkit.org/show_bug.cgi?id=125283 Reviewed by Mark Hahnenberg. * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileValueToInt32): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::lowCell): (JSC::FTL::LowerDFGToLLVM::isCell): 2013-12-06 Filip Pizlo FTL shouldn't have a doubleToUInt32 path https://bugs.webkit.org/show_bug.cgi?id=125360 Reviewed by Mark Hahnenberg. This code existed because I incorrectly thought it was necessary. It's now basically dead. * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compilePutByVal): 2013-12-06 Laszlo Vidacs Define SHA1 hash size in SHA1.h and use it at various places. https://bugs.webkit.org/show_bug.cgi?id=125345 Reviewed by Darin Adler. Use SHA1::hashSize instead of local variables. * bytecode/CodeBlockHash.cpp: (JSC::CodeBlockHash::CodeBlockHash): use SHA1::hashSize 2013-12-05 Michael Saboff REGRESSION(r160213): Crash in js/dom/JSON-parse.html https://bugs.webkit.org/show_bug.cgi?id=125335 Reviewed by Mark Lam. Changed _llint_op_catch to materialize the VM via the scope chain instead of the CodeBlock. CallFrames always have a scope chain, but may have a null CodeBlock. * llint/LowLevelInterpreter32_64.asm: (_llint_op_catch): * llint/LowLevelInterpreter64.asm: (_llint_op_catch): 2013-12-05 Michael Saboff JSC: Simplify interface between throw and catch handler https://bugs.webkit.org/show_bug.cgi?id=125328 Reviewed by Geoffrey Garen. Simplified the throw - catch interface. The throw side is only responsible for jumping to the appropriate op_catch handler or returnFromJavaScript for uncaught exceptions. The handler uses the exception values like VM.callFrameForThrow as appropriate and no longer relies on the throw side putting anything in registers. * jit/CCallHelpers.h: (JSC::CCallHelpers::jumpToExceptionHandler): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_catch): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_catch): * llint/LowLevelInterpreter32_64.asm: (_llint_op_catch): (_llint_throw_from_slow_path_trampoline): * llint/LowLevelInterpreter64.asm: (_llint_op_catch): (_llint_throw_from_slow_path_trampoline): 2013-12-04 Oliver Hunt Refactor static getter function prototype to include thisValue in addition to the base object https://bugs.webkit.org/show_bug.cgi?id=124461 Reviewed by Geoffrey Garen. Add thisValue parameter to static getter prototype, and switch from JSValue to EncodedJSValue for parameters and return value. Currently none of the static getters use the thisValue, but separating out the refactoring will prevent future changes from getting lost in the noise of refactoring. This means that this patch does not result in any change in behaviour. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::asCallbackObject): (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::asRegExpConstructor): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::asRegExpObject): (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-04 Filip Pizlo FTL should use cvttsd2si directly for double-to-int32 conversions https://bugs.webkit.org/show_bug.cgi?id=125275 Reviewed by Michael Saboff. Wow. This was an ordeal. Using cvttsd2si was actually easy, but I learned, and sometimes even fixed, some interesting things: - The llvm.x86.sse2.cvttsd2si intrinsic can actually result in LLVM emitting a vcvttsd2si. I guess the intrinsic doesn't actually imply the instruction. - That whole thing about branchTruncateDoubleToUint32? Yeah we don't need that. It's better to use branchTruncateDoubleToInt32 instead. It has the right semantics for all of its callers (err, its one-and-only caller), and it's more likely to take fast path. This patch kills branchTruncateDoubleToUint32. - "a[i] = v; v = a[i]". Does this change v? OK, assume that 'a[i]' is a pure-ish operation - like an array access with 'i' being an integer index and we're not having a bad time. Now does this change v? CSE assumes that it doesn't. That's wrong. If 'a' is a typed array - the most sensible and pure kind of array - then this can be a truncating cast. For example 'v' could be a double and 'a' could be an integer array. - "v1 = a[i]; v2 = a[i]". Is v1 === v2 assuming that 'a[i]' is pure-ish? The answer is no. You could have a different arrayMode in each access. I know this sounds weird, but with concurrent JIT that might happen. This patch adds tests for all of this stuff, except for the first issue (it's weird but probably doesn't matter) and the last issue (it's too much of a freakshow). * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerX86Common.h: * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::getByValLoadElimination): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): * ftl/FTLAbbreviations.h: (JSC::FTL::vectorType): (JSC::FTL::getUndef): (JSC::FTL::buildInsertElement): * ftl/FTLIntrinsicRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::doubleToInt32): (JSC::FTL::LowerDFGToLLVM::doubleToUInt32): (JSC::FTL::LowerDFGToLLVM::sensibleDoubleToInt32): * ftl/FTLOutput.h: (JSC::FTL::Output::insertElement): (JSC::FTL::Output::hasSensibleDoubleToInt): (JSC::FTL::Output::sensibleDoubleToInt): 2013-12-05 Commit Queue Unreviewed, rolling out r160133. http://trac.webkit.org/changeset/160133 https://bugs.webkit.org/show_bug.cgi?id=125325 broke bindings tests on all the bots (Requested by thorton on #webkit). * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-05 Mark Lam Make the C Loop LLINT work with callToJavaScript. https://bugs.webkit.org/show_bug.cgi?id=125294. Reviewed by Michael Saboff. 1. Changed the C Loop LLINT to dispatch to an Executable via its JITCode instance which is consistent with how the ASM LLINT works. 2. Changed CLoop::execute() to take an Opcode instead of an OpcodeID. This makes it play nice with the use of JITCode for dispatching. 3. Introduce a callToJavaScript and callToNativeFunction for the C Loop LLINT. These will call JSStack::pushFrame() and popFrame() to setup and teardown the CallFrame. 4. Also introduced a C Loop returnFromJavaScript which is just a replacement for ctiOpThrowNotCaught which had the same function. 5. Remove a lot of #if ENABLE(LLINT_C_LOOP) code now that the dispatch mechanism is consistent. This patch has been tested with both configurations of COMPUTED_GOTOs on and off. * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::call): (JSC::CachedCall::setArgument): * interpreter/CallFrameClosure.h: (JSC::CallFrameClosure::setThis): (JSC::CallFrameClosure::setArgument): (JSC::CallFrameClosure::resetCallFrame): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::pushFrame): * interpreter/ProtoCallFrame.h: (JSC::ProtoCallFrame::scope): (JSC::ProtoCallFrame::callee): (JSC::ProtoCallFrame::thisValue): (JSC::ProtoCallFrame::argument): (JSC::ProtoCallFrame::setArgument): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITExceptions.cpp: (JSC::genericUnwind): * llint/LLIntCLoop.cpp: (JSC::LLInt::CLoop::initialize): * llint/LLIntCLoop.h: * llint/LLIntEntrypoint.cpp: (JSC::LLInt::setFunctionEntrypoint): (JSC::LLInt::setEvalEntrypoint): (JSC::LLInt::setProgramEntrypoint): - Inverted the check for vm.canUseJIT(). This allows the JIT case to be #if'd out nicely when building the C Loop LLINT. * llint/LLIntOpcode.h: * llint/LLIntThunks.cpp: (JSC::doCallToJavaScript): (JSC::executeJS): (JSC::callToJavaScript): (JSC::executeNative): (JSC::callToNativeFunction): * llint/LLIntThunks.h: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): * runtime/Executable.h: (JSC::ExecutableBase::offsetOfNumParametersFor): (JSC::ExecutableBase::hostCodeEntryFor): (JSC::ExecutableBase::jsCodeEntryFor): (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor): (JSC::NativeExecutable::create): (JSC::NativeExecutable::finishCreation): (JSC::ProgramExecutable::generatedJITCode): * runtime/JSArray.cpp: (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): * runtime/VM.cpp: (JSC::VM::getHostFunction): 2013-12-05 Laszlo Vidacs Fix JavaScriptCore build if cloop is enabled after r160094 https://bugs.webkit.org/show_bug.cgi?id=125292 Reviewed by Michael Saboff. Move ProtoCallFrame outside the JIT guard. * jit/JITCode.h: 2013-12-04 Filip Pizlo Fold constant typed arrays https://bugs.webkit.org/show_bug.cgi?id=125205 Reviewed by Oliver Hunt and Mark Hahnenberg. If by some other mechanism we have a typed array access on a compile-time constant typed array pointer, then fold: - Array bounds checks. Specifically, fold the load of length. - Loading the vector. This needs to install a watchpoint on the array itself because of the possibility of neutering. Neutering is ridiculous. We do this without bloating the size of ArrayBuffer or JSArrayBufferView in the common case (i.e. the case where you allocated an array that didn't end up becoming a compile-time constant). To install the watchpoint, we slowDownAndWasteMemory and then create an incoming reference to the ArrayBuffer, where that incoming reference is from a watchpoint object. The ArrayBuffer already knows about such incoming references and can fire the watchpoints that way. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGDesiredWatchpoints.cpp: (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add): (JSC::DFG::DesiredWatchpoints::addLazily): * dfg/DFGDesiredWatchpoints.h: (JSC::DFG::GenericSetAdaptor::add): (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated): (JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated): (JSC::DFG::GenericDesiredWatchpoints::reallyAdd): (JSC::DFG::GenericDesiredWatchpoints::areStillValid): (JSC::DFG::GenericDesiredWatchpoints::isStillValid): (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isStillValid): (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState): (JSC::DFG::DesiredWatchpoints::isValidOrMixed): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetFoldableView): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds): (JSC::DFG::SpeculativeJIT::emitTypedArrayBoundsCheck): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray): (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray): (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage): (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): * dfg/DFGSpeculativeJIT.h: * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): (JSC::DFG::WatchpointCollectionPhase::addLazily): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage): (JSC::FTL::LowerDFGToLLVM::compileGetByVal): (JSC::FTL::LowerDFGToLLVM::compilePutByVal): (JSC::FTL::LowerDFGToLLVM::typedArrayLength): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::transfer): * runtime/ArrayBufferNeuteringWatchpoint.cpp: Added. (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::~ArrayBufferNeuteringWatchpoint): (JSC::ArrayBufferNeuteringWatchpoint::finishCreation): (JSC::ArrayBufferNeuteringWatchpoint::destroy): (JSC::ArrayBufferNeuteringWatchpoint::create): (JSC::ArrayBufferNeuteringWatchpoint::createStructure): * runtime/ArrayBufferNeuteringWatchpoint.h: Added. (JSC::ArrayBufferNeuteringWatchpoint::set): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2013-12-04 Commit Queue Unreviewed, rolling out r160116. http://trac.webkit.org/changeset/160116 https://bugs.webkit.org/show_bug.cgi?id=125264 Change doesn't work as intended. See bug comments for details. (Requested by bfulgham on #webkit). * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-04 Oliver Hunt Refactor static getter function prototype to include thisValue in addition to the base object https://bugs.webkit.org/show_bug.cgi?id=124461 Reviewed by Geoffrey Garen. Add thisValue parameter to static getter prototype, and switch from JSValue to EncodedJSValue for parameters and return value. Currently none of the static getters use the thisValue, but separating out the refactoring will prevent future changes from getting lost in the noise of refactoring. This means that this patch does not result in any change in behaviour. * API/JSCallbackObject.h: * API/JSCallbackObjectFunctions.h: (JSC::::asCallbackObject): (JSC::::staticFunctionGetter): (JSC::::callbackGetter): * jit/JITOperations.cpp: * runtime/JSActivation.cpp: (JSC::JSActivation::argumentsGetter): * runtime/JSActivation.h: * runtime/JSFunction.cpp: (JSC::JSFunction::argumentsGetter): (JSC::JSFunction::callerGetter): (JSC::JSFunction::lengthGetter): (JSC::JSFunction::nameGetter): * runtime/JSFunction.h: * runtime/JSObject.h: (JSC::PropertySlot::getValue): * runtime/NumberConstructor.cpp: (JSC::numberConstructorNaNValue): (JSC::numberConstructorNegInfinity): (JSC::numberConstructorPosInfinity): (JSC::numberConstructorMaxValue): (JSC::numberConstructorMinValue): * runtime/PropertySlot.h: * runtime/RegExpConstructor.cpp: (JSC::asRegExpConstructor): (JSC::regExpConstructorDollar1): (JSC::regExpConstructorDollar2): (JSC::regExpConstructorDollar3): (JSC::regExpConstructorDollar4): (JSC::regExpConstructorDollar5): (JSC::regExpConstructorDollar6): (JSC::regExpConstructorDollar7): (JSC::regExpConstructorDollar8): (JSC::regExpConstructorDollar9): (JSC::regExpConstructorInput): (JSC::regExpConstructorMultiline): (JSC::regExpConstructorLastMatch): (JSC::regExpConstructorLastParen): (JSC::regExpConstructorLeftContext): (JSC::regExpConstructorRightContext): * runtime/RegExpObject.cpp: (JSC::asRegExpObject): (JSC::regExpObjectGlobal): (JSC::regExpObjectIgnoreCase): (JSC::regExpObjectMultiline): (JSC::regExpObjectSource): 2013-12-04 Daniel Bates [iOS] Enable Objective-C ARC when building JSC tools for iOS simulator https://bugs.webkit.org/show_bug.cgi?id=125170 Reviewed by Geoffrey Garen. * API/tests/testapi.mm: * Configurations/ToolExecutable.xcconfig: 2013-12-04 [email protected] Use ThreadingOnce class to encapsulate pthread_once functionality. https://bugs.webkit.org/show_bug.cgi?id=125228 Reviewed by Brent Fulgham. * runtime/InitializeThreading.cpp: (JSC::initializeThreading): 2013-12-04 Mark Lam Remove unneeded semicolons. https://bugs.webkit.org/show_bug.cgi?id=125083. Rubber-stamped by Filip Pizlo. * debugger/Debugger.h: (JSC::Debugger::detach): (JSC::Debugger::sourceParsed): (JSC::Debugger::exception): (JSC::Debugger::atStatement): (JSC::Debugger::callEvent): (JSC::Debugger::returnEvent): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didExecuteProgram): (JSC::Debugger::didReachBreakpoint): 2013-12-04 Andy Estes [iOS] Build projects with $(ARCHS_STANDARD_32_64_BIT) https://bugs.webkit.org/show_bug.cgi?id=125236 Reviewed by Sam Weinig. $(ARCHS_STANDARD_32_64_BIT) is what we want for both device and simulator builds. * Configurations/DebugRelease.xcconfig: 2013-12-03 Filip Pizlo Infer constant closure variables https://bugs.webkit.org/show_bug.cgi?id=124630 Reviewed by Geoffrey Garen. Captured variables that are assigned once (not counting op_enter's Undefined initialization) and that are contained within a function that has thus far only been entered once are now constant folded. It's pretty awesome. This involves a watchpoint on the assignment to variables and a watchpoint on entry into the function. The former is reused from global variable constant inference and the latter is reused from one-time closure inference. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): * bytecode/Instruction.h: (JSC::Instruction::Instruction): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedInstruction::UnlinkedInstruction): * bytecode/VariableWatchpointSet.h: (JSC::VariableWatchpointSet::invalidate): * bytecode/Watchpoint.h: (JSC::WatchpointSet::invalidate): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitInitLazyRegister): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::emitNewFunctionInternal): (JSC::BytecodeGenerator::createArgumentsIfNecessary): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::addVar): (JSC::BytecodeGenerator::watchableVariable): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::inferredConstant): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetActivation): (JSC::DFG::Graph::tryGetRegisters): * dfg/DFGGraph.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_captured_mov): (JSC::JIT::emit_op_new_captured_func): (JSC::JIT::emitSlow_op_captured_mov): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_mov): (JSC::JIT::emit_op_captured_mov): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/ConstantMode.h: Added. * runtime/JSGlobalObject.h: * runtime/JSScope.cpp: (JSC::abstractAccess): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::prepareToWatch): 2013-12-04 Brent Fulgham [Win] Unreviewed project file gardening. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Remove deleted files from project. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Put files in proper directory folders to match the directory structure of the source code. 2013-12-04 Joseph Pecoraro Unreviewed Windows Build Fix attempt after r160099. * JavaScriptCore.vcxproj/copy-files.cmd: 2013-12-04 Julien Brianceau REGRESSION (r160094): Fix lots of crashes for sh4 architecture. https://bugs.webkit.org/show_bug.cgi?id=125227 Reviewed by Michael Saboff. * llint/LowLevelInterpreter32_64.asm: Do not use t4 and t5 as they match a0 and a1. * offlineasm/registers.rb: Add t7, t8 and t9 in register list for sh4 port. * offlineasm/sh4.rb: Rearrange RegisterID list and add the missing ones. 2013-12-03 Joseph Pecoraro Web Inspector: Push Remote Inspector debugging connection management into JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=124613 Reviewed by Timothy Hatcher. Move the ENABLE(REMOTE_INSPECTOR) remote debugger connection management into JavaScriptCore (originally from WebKit/mac). Include enhancements: * allow for different types of remote debuggable targets, eventually at least a JSContext, WebView, WKView. * allow debuggables to be registered and debugged on any thread. Unlike WebViews, JSContexts may be run entirely off of the main thread. * move the remote connection (XPC connection) itself off of the main thread, it doesn't need to be on the main thread. Make JSContext @class and JavaScriptCore::JSContextRef "JavaScript" Remote Debuggables. * inspector/remote/RemoteInspectorDebuggable.h: Added. * inspector/remote/RemoteInspectorDebuggable.cpp: Added. (Inspector::RemoteInspectorDebuggable::RemoteInspectorDebuggable): (Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable): (Inspector::RemoteInspectorDebuggable::init): (Inspector::RemoteInspectorDebuggable::update): (Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed): (Inspector::RemoteInspectorDebuggable::info): RemoteInspectorDebuggable defines a debuggable target. As long as something creates a debuggable and is set to allow remote inspection it will be listed in remote debuggers. For the different types of debuggables (JavaScript and Web) there is different basic information that may be listed. * inspector/InspectorFrontendChannel.h: Added. (Inspector::InspectorFrontendChannel::~InspectorFrontendChannel): The only thing a debuggable needs for remote debugging is an InspectorFrontendChannel a way to send messages to a remote frontend. This class provides that method, and is vended to the RemoteInspectorDebuggable when a remote connection is setup. * inspector/remote/RemoteInspector.h: Added. * inspector/remote/RemoteInspector.mm: Added. Singleton, created at least when the first Debuggable is created. This class manages the list of debuggables, any connection to a remote debugger proxy (XPC service "com.apple.webinspector"). (Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable): (Inspector::RemoteInspector::shared): (Inspector::RemoteInspector::RemoteInspector): (Inspector::RemoteInspector::nextAvailableIdentifier): (Inspector::RemoteInspector::registerDebuggable): (Inspector::RemoteInspector::unregisterDebuggable): (Inspector::RemoteInspector::updateDebuggable): Debuggable management. When debuggables are added, removed, or updated we stash a copy of the debuggable information and push an update to debuggers. Stashing a copy of the information in the RemoteInspector is a thread safe way to avoid walking over all debuggables to gather the information when it is needed. (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::stop): Runtime API to enable / disable the feature. (Inspector::RemoteInspector::listingForDebuggable): (Inspector::RemoteInspector::pushListingNow): (Inspector::RemoteInspector::pushListingSoon): Pushing a listing to remote debuggers. (Inspector::RemoteInspector::sendMessageToRemoteFrontend): (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): (Inspector::RemoteInspector::xpcConnectionReceivedMessage): (Inspector::RemoteInspector::xpcConnectionFailed): (Inspector::RemoteInspector::xpcConnectionUnhandledMessage): XPC setup, send, and receive handling. (Inspector::RemoteInspector::updateHasActiveDebugSession): Applications being debugged may want to know when a debug session is active. This provides that notification. (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedDidCloseMessage): (Inspector::RemoteInspector::receivedGetListingMessage): (Inspector::RemoteInspector::receivedIndicateMessage): (Inspector::RemoteInspector::receivedConnectionDiedMessage): Dispatching incoming remote debugging protocol messages. These are wrapping above the inspector protocol messages. * inspector/remote/RemoteInspectorConstants.h: Added. Protocol messages and dictionary keys inside the messages. (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo): * inspector/remote/RemoteInspectorDebuggableConnection.h: Added. * inspector/remote/RemoteInspectorDebuggableConnection.mm: Added. This is a connection between the RemoteInspector singleton and a RemoteInspectorDebuggable. (Inspector::RemoteInspectorDebuggableConnection::RemoteInspectorDebuggableConnection): (Inspector::RemoteInspectorDebuggableConnection::~RemoteInspectorDebuggableConnection): Allow for dispatching messages on JavaScript debuggables on a dispatch_queue instead of the main queue. (Inspector::RemoteInspectorDebuggableConnection::destination): (Inspector::RemoteInspectorDebuggableConnection::connectionIdentifier): Needed in the remote debugging protocol to identify the remote debugger. (Inspector::RemoteInspectorDebuggableConnection::dispatchSyncOnDebuggable): (Inspector::RemoteInspectorDebuggableConnection::dispatchAsyncOnDebuggable): (Inspector::RemoteInspectorDebuggableConnection::setup): (Inspector::RemoteInspectorDebuggableConnection::closeFromDebuggable): (Inspector::RemoteInspectorDebuggableConnection::close): (Inspector::RemoteInspectorDebuggableConnection::sendMessageToBackend): (Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend): The connection is a thin channel between the two sides that can be closed from either side, so there is some logic around multi-threaded access. * inspector/remote/RemoteInspectorXPCConnection.h: Added. (Inspector::RemoteInspectorXPCConnection::Client::~Client): * inspector/remote/RemoteInspectorXPCConnection.mm: Added. (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::~RemoteInspectorXPCConnection): (Inspector::RemoteInspectorXPCConnection::close): (Inspector::RemoteInspectorXPCConnection::deserializeMessage): (Inspector::RemoteInspectorXPCConnection::handleEvent): (Inspector::RemoteInspectorXPCConnection::sendMessage): This is a connection between the RemoteInspector singleton and an XPC service named "com.apple.webinspector". This handles serialization of the dictionary messages to and from the service. The receiving is done on a non-main queue. * API/JSContext.h: * API/JSContext.mm: (-[JSContext name]): (-[JSContext setName:]): ObjC API to enable/disable JSContext remote inspection and give a name. * API/JSContextRef.h: * API/JSContextRef.cpp: (JSGlobalContextGetName): (JSGlobalContextSetName): C API to give a JSContext a name. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::setName): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::name): Shared handling of the APIs above. * runtime/JSGlobalObjectDebuggable.cpp: Added. (JSC::JSGlobalObjectDebuggable::JSGlobalObjectDebuggable): (JSC::JSGlobalObjectDebuggable::name): (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::disconnect): (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend): * runtime/JSGlobalObjectDebuggable.h: Added. Stub for the actual remote debugging implementation. We will push down the appropriate WebCore/inspector peices suitable for debugging just a JavaScript context. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * GNUmakefile.am: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Update build files. 2013-12-04 Michael Saboff Move the setting up of callee's callFrame from pushFrame to callToJavaScript thunk https://bugs.webkit.org/show_bug.cgi?id=123999 Reviewed by Filip Pizlo. Changed LLInt and/or JIT enabled ports to allocate the stack frame in the callToJavaScript stub. Added an additional stub, callToNativeFunction that allocates a stack frame in a similar way for calling native entry points that take a single ExecState* argument. These stubs are implemented using common macros in LowLevelInterpreter{32_64,64}.asm. There are also Windows X86 and X86-64 versions in the corresponding JitStubsXX.h. The stubs allocate and create a sentinel frame, then create the callee's frame, populating the header and arguments from the passed in ProtoCallFrame*. It is assumed that the caller of either stub does a check for enough stack space via JSStack::entryCheck(). For ports using the C-Loop interpreter, the prior method for allocating stack frame and invoking functions is used, namely with JSStack::pushFrame() and ::popFrame(). Made spelling changes "sentinal" -> "sentinel". * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/CachedCall.h: (JSC::CachedCall::CachedCall): (JSC::CachedCall::setThis): (JSC::CachedCall::setArgument): * interpreter/CallFrameClosure.h: (JSC::CallFrameClosure::resetCallFrame): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): * interpreter/Interpreter.h: * interpreter/JSStack.h: * interpreter/JSStackInlines.h: (JSC::JSStack::entryCheck): (JSC::JSStack::pushFrame): (JSC::JSStack::popFrame): * interpreter/ProtoCallFrame.cpp: Added. (JSC::ProtoCallFrame::init): * interpreter/ProtoCallFrame.h: Added. (JSC::ProtoCallFrame::codeBlock): (JSC::ProtoCallFrame::setCodeBlock): (JSC::ProtoCallFrame::setScope): (JSC::ProtoCallFrame::setCallee): (JSC::ProtoCallFrame::argumentCountIncludingThis): (JSC::ProtoCallFrame::argumentCount): (JSC::ProtoCallFrame::setArgumentCountIncludingThis): (JSC::ProtoCallFrame::setPaddedArgsCount): (JSC::ProtoCallFrame::clearCurrentVPC): (JSC::ProtoCallFrame::setThisValue): (JSC::ProtoCallFrame::setArgument): * jit/JITCode.cpp: (JSC::JITCode::execute): * jit/JITCode.h: * jit/JITOperations.cpp: * jit/JITStubs.h: * jit/JITStubsMSVC64.asm: * jit/JITStubsX86.h: * llint/LLIntOffsetsExtractor.cpp: * llint/LLIntThunks.h: * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/ArgList.h: (JSC::ArgList::data): * runtime/JSArray.cpp: (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): * runtime/StringPrototype.cpp: (JSC::replaceUsingRegExpSearch): 2013-12-04 László Langó Remove stdio.h from JSC files. https://bugs.webkit.org/show_bug.cgi?id=125220 Reviewed by Michael Saboff. * interpreter/VMInspector.cpp: * jit/JITArithmetic.cpp: * jit/JITArithmetic32_64.cpp: * jit/JITCall.cpp: * jit/JITCall32_64.cpp: * jit/JITPropertyAccess.cpp: * jit/JITPropertyAccess32_64.cpp: * runtime/Completion.cpp: * runtime/IndexingType.cpp: * runtime/Lookup.h: * runtime/Operations.cpp: * runtime/Options.cpp: * runtime/RegExp.cpp: 2013-12-04 László Langó Avoid to add zero offset in BaseIndex. https://bugs.webkit.org/show_bug.cgi?id=125215 Reviewed by Michael Saboff. When using cloop do not generate offsets additions for BaseIndex if the offset is zero. * offlineasm/cloop.rb: 2013-12-04 Peter Molnar Fix !ENABLE(JAVASCRIPT_DEBUGGER) build. https://bugs.webkit.org/show_bug.cgi?id=125083 Reviewed by Mark Lam. * debugger/Debugger.cpp: * debugger/Debugger.h: (JSC::Debugger::Debugger): (JSC::Debugger::needsOpDebugCallbacks): (JSC::Debugger::needsExceptionCallbacks): (JSC::Debugger::detach): (JSC::Debugger::sourceParsed): (JSC::Debugger::exception): (JSC::Debugger::atStatement): (JSC::Debugger::callEvent): (JSC::Debugger::returnEvent): (JSC::Debugger::willExecuteProgram): (JSC::Debugger::didExecuteProgram): (JSC::Debugger::didReachBreakpoint): * debugger/DebuggerPrimitives.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_debug): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emit_op_debug): * llint/LLIntOfflineAsmConfig.h: * llint/LowLevelInterpreter.asm: 2013-12-03 Mark Lam testapi test crashes on Windows in WTF::Vector::size(). https://bugs.webkit.org/show_bug.cgi?id=121972. Reviewed by Brent Fulgham. * interpreter/JSStack.cpp: (JSC::JSStack::~JSStack): - Reverting the change from r160004 since it's better to fix OSAllocatorWin to be consistent with OSAllocatorPosix. 2013-12-03 Mark Lam Fix LLINT_C_LOOP build for Win64. https://bugs.webkit.org/show_bug.cgi?id=125186. Reviewed by Michael Saboff. * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * jit/JITOperationsMSVC64.cpp: Added. (JSC::getHostCallReturnValueWithExecState): - Win64 will build JITStubMSVC64.asm even when !ENABLE(JIT). This results in a linkage error due to a missing getHostCallReturnValueWithExecState(). So, we add a stub getHostCallReturnValueWithExecState() here to satisfy that linkage. This function will never be called. The alternative to providing such a stub is to make the MSVC project recognize if the JIT is enabled or not, and exclude JITStubMSVC64.asm if it's not enabled. We don't currently set ENABLE(JIT) via the MSVC project and the work to do that is too much trouble for what we're trying to achieve here. So, we're opting for this simpler workaround instead. * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter.cpp: (JSC::CLoop::execute): - Don't build callToJavaScript if we're building the C loop. Otherwise, the C loop won't build if !ENABLE(COMPUTE_GOTO_OPCODES). 2013-12-03 Michael Saboff ARM64: Crash in JIT code due to improper reuse of cached memory temp register https://bugs.webkit.org/show_bug.cgi?id=125181 Reviewed by Geoffrey Garen. Changed load8() and load() to invalidate the memory temp CachedTempRegister when the destination of an absolute load is the memory temp register since the source address is also the memory temp register. Change branch{8,32,64} of an AbsoluteAddress with a register to use the dataTempRegister as the destinate of the absolute load to reduce the chance that we need to invalidate the memory temp register cache. In the process, found and fixed an outright bug in branch8() where we'd load into the data temp register and then compare and branch on the memory temp register. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::load8): (JSC::MacroAssemblerARM64::branch32): (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::branch8): (JSC::MacroAssemblerARM64::load): 2013-12-03 Michael Saboff jit/JITArithmetic.cpp doesn't build for non-X86 ports https://bugs.webkit.org/show_bug.cgi?id=125185 Rubber stamped by Mark Hahnenberg. Removed unused declarations and related UNUSED_PARAM(). * jit/JITArithmetic.cpp: (JSC::JIT::emit_op_mod): 2013-12-03 Filip Pizlo ObjectAllocationProfile is racy and the DFG should be cool with that https://bugs.webkit.org/show_bug.cgi?id=125172 Reviewed by Mark Hahnenberg. We would previously sometimes get a null Structure because checking if the profile is non-null and loading the structure from it were two separate operations. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGAbstractValue.cpp: (JSC::DFG::AbstractValue::setFuturePossibleStructure): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * runtime/JSFunction.h: (JSC::JSFunction::allocationProfile): (JSC::JSFunction::allocationStructure): 2013-12-03 [email protected] testapi test crashes on Windows in WTF::Vector::size() https://bugs.webkit.org/show_bug.cgi?id=121972 Reviewed by Michael Saboff. The reason for the crash is that the wrong memory block is decommitted. This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed. In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero. If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block, if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash. * interpreter/JSStack.cpp: (JSC::JSStack::~JSStack): Don't decommit memory if nothing has been committed. 2013-12-03 László Langó Guard JIT include. https://bugs.webkit.org/show_bug.cgi?id=125063 Reviewed by Filip Pizlo. * llint/LLIntThunks.cpp: 2013-12-03 Julien Brianceau Merge mips and arm/sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions. https://bugs.webkit.org/show_bug.cgi?id=125067 Reviewed by Michael Saboff. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): 2013-12-02 Mark Lam Build failure when disabling JIT, YARR_JIT, and ASSEMBLER. https://bugs.webkit.org/show_bug.cgi?id=123809. Reviewed by Geoffrey Garen. Also fixed build when disabling the DISASSEMBLER. Added some needed #if's and some comments. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassembly): * dfg/DFGDisassembler.cpp: * dfg/DFGDisassembler.h: (JSC::DFG::Disassembler::Disassembler): (JSC::DFG::Disassembler::setStartOfCode): (JSC::DFG::Disassembler::setForBlockIndex): (JSC::DFG::Disassembler::setForNode): (JSC::DFG::Disassembler::setEndOfMainPath): (JSC::DFG::Disassembler::setEndOfCode): (JSC::DFG::Disassembler::dump): (JSC::DFG::Disassembler::reportToProfiler): * disassembler/Disassembler.cpp: * disassembler/X86Disassembler.cpp: * jit/FPRInfo.h: * jit/GPRInfo.h: * jit/JITDisassembler.cpp: * jit/JITDisassembler.h: (JSC::JITDisassembler::JITDisassembler): (JSC::JITDisassembler::setStartOfCode): (JSC::JITDisassembler::setForBytecodeMainPath): (JSC::JITDisassembler::setForBytecodeSlowPath): (JSC::JITDisassembler::setEndOfSlowPath): (JSC::JITDisassembler::setEndOfCode): (JSC::JITDisassembler::dump): (JSC::JITDisassembler::reportToProfiler): 2013-12-02 Filip Pizlo Baseline JIT calls to CommonSlowPaths shouldn't restore the last result https://bugs.webkit.org/show_bug.cgi?id=125107 Reviewed by Mark Hahnenberg. Just killing dead code. * jit/JITArithmetic.cpp: (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitSlow_op_rshift): (JSC::JIT::emitSlow_op_urshift): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_mod): (JSC::JIT::emit_op_mod): (JSC::JIT::compileBinaryArithOpSlowCase): (JSC::JIT::emitSlow_op_div): * jit/JITArithmetic32_64.cpp: (JSC::JIT::emitSlow_op_negate): (JSC::JIT::emitSlow_op_lshift): (JSC::JIT::emitRightShiftSlowCase): (JSC::JIT::emitSlow_op_bitand): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_inc): (JSC::JIT::emitSlow_op_dec): (JSC::JIT::emitSlow_op_add): (JSC::JIT::emitSlow_op_sub): (JSC::JIT::emitSlow_op_mul): (JSC::JIT::emitSlow_op_div): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_strcat): (JSC::JIT::emitSlow_op_get_callee): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_bitxor): (JSC::JIT::emitSlow_op_bitor): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): * jit/JITOpcodes32_64.cpp: (JSC::JIT::emitSlow_op_to_primitive): (JSC::JIT::emitSlow_op_not): (JSC::JIT::emitSlow_op_stricteq): (JSC::JIT::emitSlow_op_nstricteq): (JSC::JIT::emitSlow_op_to_number): (JSC::JIT::emitSlow_op_get_callee): (JSC::JIT::emitSlow_op_create_this): (JSC::JIT::emitSlow_op_to_this): 2013-12-01 Filip Pizlo Stores to local captured variables should be intercepted https://bugs.webkit.org/show_bug.cgi?id=124883 Reviewed by Mark Hahnenberg. Previously, in bytecode, you could assign to a captured variable just as you would assign to any other kind of variable. This complicates closure variable constant inference because we don't have any place where we can intercept stores to captured variables in the LLInt. This patch institutes a policy that only certain instructions can store to captured variables. If you interpret those instructions and you are required to notifyWrite() then you need to check if the relevant variable is captured. Those instructions are tracked in CodeBlock.cpp's VerifyCapturedDef. The main one is simply op_captured_mov. In the future, we'll probably modify those instructions to have a pointer directly to the VariableWatchpointSet; but for now we just introduce the captured instructions as placeholders. In order to validate that the placeholders are inserted correctly, this patch improves the CodeBlock validation to be able to inspect every def in the bytecode. To do that, this patch refactors the liveness analysis' use/def calculator to be reusable; it now takes a functor for each use or def. In the process of refactoring the liveness analysis, I noticed that op_enter was claiming to def all callee registers. That's wrong; it only defs the non-temporary variables. Making that change revealed preexisting bugs in the liveness analysis, since now the validator would pick up cases where the bytecode claimed to use a temporary and the def calculator never noticed the definition (or the converse - where the bytecode was actually not using a temporary but the liveness analysis thought that it was a use). This patch fixes a few of those bugs. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::stepOverInstruction): * bytecode/BytecodeUseDef.h: Added. (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::isCaptured): (JSC::CodeBlock::validate): * bytecode/CodeBlock.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::resolveCallee): (JSC::BytecodeGenerator::emitMove): (JSC::BytecodeGenerator::isCaptured): (JSC::BytecodeGenerator::local): (JSC::BytecodeGenerator::constLocal): (JSC::BytecodeGenerator::emitNewFunction): (JSC::BytecodeGenerator::emitLazyNewFunction): (JSC::BytecodeGenerator::emitNewFunctionInternal): * bytecompiler/BytecodeGenerator.h: (JSC::Local::Local): (JSC::Local::isCaptured): (JSC::Local::captureMode): (JSC::BytecodeGenerator::captureMode): (JSC::BytecodeGenerator::emitNode): (JSC::BytecodeGenerator::pushOptimisedForIn): * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): (JSC::ReadModifyResolveNode::emitBytecode): (JSC::AssignResolveNode::emitBytecode): (JSC::ConstDeclNode::emitCodeSingle): (JSC::ForInNode::emitBytecode): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/SymbolTable.h: (JSC::SymbolTable::isCaptured): 2013-12-02 Filip Pizlo Instead of watchpointing activation allocation, we should watchpoint entry into functions that have captured variables https://bugs.webkit.org/show_bug.cgi?id=125052 Reviewed by Mark Hahnenberg. This makes us watch function entry rather than activation creation. We only incur the costs of doing so for functions that have captured variables, and only on the first two entries into the function. This means that closure variable constant inference will naturally work even for local uses of the captured variable, like: (function(){ var blah = 42; ... // stuff function () { ... blah /* we can fold this to 42 */ } ... blah // we can also fold this to 42. })(); Previously, only the nested use would have been foldable. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/Watchpoint.h: (JSC::WatchpointSet::touch): (JSC::InlineWatchpointSet::touch): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasSymbolTable): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_touch_entry): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/JSActivation.h: (JSC::JSActivation::create): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: 2013-12-02 Nick Diego Yamane [JSC] Get rid of some unused parameters in LLIntSlowPaths.cpp macros https://bugs.webkit.org/show_bug.cgi?id=125075 Reviewed by Michael Saboff. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::handleHostCall): added UNUSED_PARAM(pc). (JSC::LLInt::setUpCall): Doesn't pass 'pc' to LLINT_CALL macros. (JSC::LLInt::LLINT_SLOW_PATH_DECL): Ditto. 2013-12-02 László Langó Remove stdio.h from JSC files. https://bugs.webkit.org/show_bug.cgi?id=125066 Reviewed by Michael Saboff. Remove stdio.h, when it is not necessary to be included. * bytecode/CodeBlock.cpp: * bytecode/StructureSet.h: * profiler/LegacyProfiler.cpp: * profiler/Profile.cpp: * profiler/ProfileNode.cpp: * yarr/YarrInterpreter.cpp: 2013-12-02 László Langó Unused include files when building without JIT. https://bugs.webkit.org/show_bug.cgi?id=125062 Reviewed by Michael Saboff. We should organize the includes, and guard JIT methods in ValueRecovery. * bytecode/ValueRecovery.cpp: Guard include files. * bytecode/ValueRecovery.h: Guard JIT methods. 2013-12-02 Balazs Kilvady [MIPS] Small stack frame causes regressions. https://bugs.webkit.org/show_bug.cgi?id=124945 Reviewed by Michael Saboff. Fix stack space for LLInt on MIPS. * llint/LowLevelInterpreter32_64.asm: 2013-12-02 Brian J. Burg jsc: implement a native readFile function https://bugs.webkit.org/show_bug.cgi?id=125059 Reviewed by Filip Pizlo. This adds a native readFile() function to jsc, used to slurp an entire file into a JavaScript string. * jsc.cpp: (GlobalObject::finishCreation): Add readFile() to globals. (functionReadFile): Added. 2013-12-02 László Langó JSC does not build if OPCODE_STATS is enabled. https://bugs.webkit.org/show_bug.cgi?id=125011 Reviewed by Filip Pizlo. * bytecode/Opcode.cpp: 2013-11-29 Filip Pizlo Finally remove those DFG_ENABLE things https://bugs.webkit.org/show_bug.cgi?id=125025 Rubber stamped by Sam Weinig. This removes a bunch of unused and untested insanity. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::tallyFrequentExitSites): * dfg/DFGArgumentsSimplificationPhase.cpp: (JSC::DFG::ArgumentsSimplificationPhase::run): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation): (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::makeDivSafe): (JSC::DFG::ByteCodeParser::handleCall): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::parseBlock): (JSC::DFG::ByteCodeParser::linkBlock): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parseCodeBlock): (JSC::DFG::ByteCodeParser::parse): (JSC::DFG::parse): * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::convertToJump): (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::endIndexForPureCSE): (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren): (JSC::DFG::CSEPhase::setReplacement): (JSC::DFG::CSEPhase::eliminate): (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGCommon.h: (JSC::DFG::verboseCompilationEnabled): (JSC::DFG::logCompilationChanges): (JSC::DFG::shouldDumpGraphAtEachPhase): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::injectInt32ToDoubleNode): * dfg/DFGInPlaceAbstractState.cpp: (JSC::DFG::InPlaceAbstractState::initialize): (JSC::DFG::InPlaceAbstractState::endBasicBlock): (JSC::DFG::InPlaceAbstractState::mergeStateAtTail): (JSC::DFG::InPlaceAbstractState::mergeToSuccessors): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compileBody): (JSC::DFG::JITCompiler::link): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGPredictionInjectionPhase.cpp: (JSC::DFG::PredictionInjectionPhase::run): * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::run): (JSC::DFG::PredictionPropagationPhase::propagate): (JSC::DFG::PredictionPropagationPhase::propagateForward): (JSC::DFG::PredictionPropagationPhase::propagateBackward): (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::use): * dfg/DFGSlowPathGenerator.h: (JSC::DFG::SlowPathGenerator::generate): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution): (JSC::DFG::SpeculativeJIT::runSlowPathGenerators): (JSC::DFG::SpeculativeJIT::dump): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): (JSC::DFG::SpeculativeJIT::fillSpeculateDouble): (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGVariableEventStream.cpp: (JSC::DFG::VariableEventStream::reconstruct): * dfg/DFGVariableEventStream.h: (JSC::DFG::VariableEventStream::appendAndLog): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * jit/JIT.cpp: (JSC::JIT::privateCompile): 2013-11-29 Filip Pizlo FTL IC should nop-fill to make up the difference between the actual IC size and the requested patchpoint size https://bugs.webkit.org/show_bug.cgi?id=124960 Reviewed by Sam Weinig. * assembler/LinkBuffer.h: (JSC::LinkBuffer::size): * assembler/X86Assembler.h: (JSC::X86Assembler::fillNops): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpHeader): * ftl/FTLCompile.cpp: (JSC::FTL::generateICFastPath): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::dumpHeader): 2013-11-29 Julien Brianceau Use moveDoubleToInts in SpecializedThunkJIT::returnDouble for non-X86 JSVALUE32_64 ports. https://bugs.webkit.org/show_bug.cgi?id=124936 Reviewed by Zoltan Herczeg. The moveDoubleToInts implementations in ARM, MIPS and SH4 macro assemblers do not clobber src FPRegister and are likely to be more efficient than the current generic implementation using the stack. * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::returnDouble): 2013-11-29 Julien Brianceau Merge arm and sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions. https://bugs.webkit.org/show_bug.cgi?id=124892 Reviewed by Zoltan Herczeg. * assembler/MacroAssemblerSH4.h: (JSC::MacroAssemblerSH4::call): Pick a scratch register instead of getting it as a parameter. The sh4 port was the only one to have this call(Address, RegisterID) prototype. * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): Use argumentGPRx and merge arm and sh4 paths. * jit/ThunkGenerators.cpp: (JSC::nativeForGenerator): Use argumentGPRx and merge arm and sh4 paths. 2013-11-28 Nadav Rotem Revert the X86 assembler peephole changes https://bugs.webkit.org/show_bug.cgi?id=124988 Reviewed by Csaba Osztrogonác. * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (JSC::MacroAssemblerX86::add64): (JSC::MacroAssemblerX86::or32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::or32): (JSC::MacroAssemblerX86Common::branchAdd32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::or32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::or64): (JSC::MacroAssemblerX86_64::xor64): 2013-11-28 Antti Koivisto Remove feature: CSS variables https://bugs.webkit.org/show_bug.cgi?id=114119 Reviewed by Andreas Kling. * Configurations/FeatureDefines.xcconfig: 2013-11-28 Peter Gal Typo fix after r159834 to fix 32 bit builds. Reviewed by Csaba Osztrogonác. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2013-11-27 Nadav Rotem Add a bunch of early exits and local optimizations to the x86 assembler. https://bugs.webkit.org/show_bug.cgi?id=124904 Reviewed by Filip Pizlo. * assembler/MacroAssemblerX86.h: (JSC::MacroAssemblerX86::add32): (JSC::MacroAssemblerX86::add64): (JSC::MacroAssemblerX86::or32): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::add32): (JSC::MacroAssemblerX86Common::or32): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::add32): (JSC::MacroAssemblerX86_64::or32): (JSC::MacroAssemblerX86_64::add64): (JSC::MacroAssemblerX86_64::or64): (JSC::MacroAssemblerX86_64::xor64): 2013-11-27 Filip Pizlo Infer one-time scopes https://bugs.webkit.org/show_bug.cgi?id=124812 Reviewed by Oliver Hunt. This detects JSActivations that are created only once. The JSActivation pointer is then baked into the machine code. This takes advantage of the one-time scope inference to reduce the number of indirections needed to get to a closure variable in case where the scope is only allocated once. This isn't really a speed-up since in the common case the total number of instruction bytes needed to load the scope from the stack is about equal to the number of instruction bytes needed to materialize the absolute address of a scoped variable. But, this is a necessary prerequisite to https://bugs.webkit.org/show_bug.cgi?id=124630, so it's probably a good idea anyway. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::dumpBytecode): (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::finalizeUnconditionally): * bytecode/Instruction.h: * bytecode/Opcode.h: (JSC::padOpcodeName): * bytecode/Watchpoint.h: (JSC::WatchpointSet::notifyWrite): (JSC::InlineWatchpointSet::notifyWrite): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitResolveScope): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::scopedVarLoadElimination): (JSC::DFG::CSEPhase::scopedVarStoreElimination): (JSC::DFG::CSEPhase::getLocalLoadElimination): (JSC::DFG::CSEPhase::setLocalStoreElimination): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::tryGetRegisters): * dfg/DFGGraph.h: * dfg/DFGNode.h: (JSC::DFG::Node::varNumber): (JSC::DFG::Node::hasSymbolTable): (JSC::DFG::Node::symbolTable): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSActivation.h: (JSC::JSActivation::create): * runtime/JSScope.cpp: (JSC::abstractAccess): (JSC::JSScope::abstractResolve): * runtime/JSScope.h: (JSC::ResolveOp::ResolveOp): * runtime/JSVariableObject.h: (JSC::JSVariableObject::registers): * runtime/SymbolTable.cpp: (JSC::SymbolTable::SymbolTable): * runtime/SymbolTable.h: 2013-11-27 Filip Pizlo Finally fix some obvious Bartlett bugs https://bugs.webkit.org/show_bug.cgi?id=124951 Reviewed by Mark Hahnenberg. Sanitize the stack (i.e. zero parts of it known to be dead) at three key points: - GC. - At beginning of OSR entry. - Just as we finish preparing OSR entry. This clears those slots on the stack that could have been live in baseline but that are known to be dead in DFG. This is as much as a 2x speed-up on splay if you run it in certain modes, and run it for a long enough interval. It appears to fix all instances of the dreaded exponential heap growth that splay gets into when some stale pointer stays around. This doesn't have much of an effect on real-world programs. This bug has only ever manifested in splay and for that reason we thus far opted against fixing it. But splay is, for what it's worth, the premiere GC stress test in JavaScript - so making sure we can run it without pathologies - even when you tweak its configuration - is probably fairly important. * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: * heap/Heap.cpp: (JSC::Heap::markRoots): * interpreter/JSStack.cpp: (JSC::JSStack::JSStack): (JSC::JSStack::sanitizeStack): * interpreter/JSStack.h: 2013-11-26 Filip Pizlo Do bytecode validation as part of testing https://bugs.webkit.org/show_bug.cgi?id=124913 Reviewed by Oliver Hunt. Also fix some small bugs in the bytecode liveness analysis that I found by doing this validation thingy. * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::isValidRegisterForLiveness): (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::validate): (JSC::CodeBlock::beginValidationDidFail): (JSC::CodeBlock::endValidationDidFail): * bytecode/CodeBlock.h: * runtime/Executable.cpp: (JSC::ScriptExecutable::prepareForExecutionImpl): * runtime/Options.h: 2013-11-27 Andreas Kling Structure::m_staticFunctionReified should be a single bit. Shave 8 bytes off of JSC::Structure by jamming m_staticFunctionReified into the bitfield just above. Reviewed by Antti Koivisto. 2013-11-27 Andreas Kling JSActivation constructor should use NotNull placement new. Knock a null check outta the storage initialization loop. Reviewed by Antti Koivisto. 2013-11-26 Filip Pizlo Restructure global variable constant inference so that it could work for any kind of symbol table variable https://bugs.webkit.org/show_bug.cgi?id=124760 Reviewed by Oliver Hunt. This changes the way global variable constant inference works so that it can be reused for closure variable constant inference. Some of the premises that originally motivated this patch are somewhat wrong, but it led to some simplifications anyway and I suspect that we'll be able to fix those premises in the future. The main point of this patch is to make it easy to reuse global variable constant inference for closure variable constant inference, and this will be possible provided we can also either (a) infer one-shot closures (easy) or (b) infer closure variables that are always assigned prior to first use. One of the things that this patch is meant to enable is constant inference for closure variables that may be part of a multi-shot closure. Closure variables may be instantiated multiple times, like: function foo() { var WIDTH = 45; function bar() { ... use WIDTH ... } ... } Even if foo() is called many times and WIDTH is assigned to multiple times, that doesn't change the fact that it's a constant. The goal of closure variable constant inference is to catch any case where a closure variable has been assigned at least once and its value has never changed. This patch doesn't implement that, but it does change global variable constant inference to have most of the powers needed to do that. Note that most likely we will use this functionality only to implement constant inference for one-shot closures, but the resulting machinery is still simpler than what we had before. This involves three changes: - The watchpoint object now contains the inferred value. This involves creating a new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object for closure variables. - Writing to a variable that is watchpointed still involves these three states that we proceed through monotonically (Uninitialized->Initialized->Invalidated) but now, the Initialized->Invalidated state transition only happens if we change the variable's value, rather than store to the variable. Repeatedly storing the same value won't change the variable's state. - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer need fancy fencing to get a consistent view of the watchpoint in the JIT. The state of the VariableWatchpointSet for the purposes of constant folding is entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is JSValue() then you cannot fold (either because the set is uninitialized or because it's invalidated - doesn't matter which); on the other hand if the value is anything other than JSValue() then you can fold, and that's the value you fold to. Simple! This also changes the way that DFG IR deals with variable watchpoints. It's now oblivious to global variables. You install a watchpoint using VariableWatchpoint and you notify write using NotifyWrite. Easy! Note that this will requires some more tweaks because of the fact that op_enter will store Undefined into every captured variable. Hence it won't even work for one-shot closures. One-shot closures are easily fixed by introducing another state (so we'll have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will require static analysis. One-shot closures are clearly a higher priority. * GNUmakefile.list.am: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/Instruction.h: * bytecode/VariableWatchpointSet.h: Added. (JSC::VariableWatchpointSet::VariableWatchpointSet): (JSC::VariableWatchpointSet::~VariableWatchpointSet): (JSC::VariableWatchpointSet::inferredValue): (JSC::VariableWatchpointSet::notifyWrite): (JSC::VariableWatchpointSet::invalidate): (JSC::VariableWatchpointSet::finalizeUnconditionally): (JSC::VariableWatchpointSet::addressOfInferredValue): * bytecode/Watchpoint.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCSEPhase.cpp: (JSC::DFG::CSEPhase::performNodeCSE): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGNode.h: (JSC::DFG::Node::hasRegisterPointer): (JSC::DFG::Node::hasVariableWatchpointSet): (JSC::DFG::Node::variableWatchpointSet): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::handle): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileNode): (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::emitPutGlobalVar): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitNotifyWrite): (JSC::JIT::emitPutGlobalVar): * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::addGlobalVar): (JSC::JSGlobalObject::addFunction): * runtime/JSGlobalObject.h: * runtime/JSScope.h: (JSC::ResolveOp::ResolveOp): * runtime/JSSymbolTableObject.h: (JSC::symbolTablePut): (JSC::symbolTablePutWithAttributes): * runtime/SymbolTable.cpp: (JSC::SymbolTableEntry::inferredValue): (JSC::SymbolTableEntry::prepareToWatch): (JSC::SymbolTableEntry::addWatchpoint): (JSC::SymbolTableEntry::notifyWriteSlow): (JSC::SymbolTable::visitChildren): (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): * runtime/SymbolTable.h: (JSC::SymbolTableEntry::watchpointSet): (JSC::SymbolTableEntry::notifyWrite): 2013-11-24 Filip Pizlo Create a new SymbolTable every time code is loaded so that the watchpoints don't get reused https://bugs.webkit.org/show_bug.cgi?id=124824 Reviewed by Oliver Hunt. This helps with one shot closure inference as well as closure variable constant inference, since without this, if code was reloaded from the cache then we would think that the first run was actually an Nth run. This would cause us to think that the watchpoint(s) should all be invalidated. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::stronglyVisitStrongReferences): * bytecode/CodeBlock.h: (JSC::CodeBlock::symbolTable): * runtime/Executable.cpp: (JSC::FunctionExecutable::symbolTable): * runtime/Executable.h: * runtime/SymbolTable.cpp: (JSC::SymbolTable::clone): * runtime/SymbolTable.h: 2013-11-26 Oliver Hunt Crash in JSC::ASTBuilder::Expression JSC::Parser<:lexer char> >::parseUnaryExpression<:astbuilder>(JSC::ASTBuilder&) https://bugs.webkit.org/show_bug.cgi?id=124886 Reviewed by Sam Weinig. Make sure the error macros propagate an existing error before trying to create a new error message. We need to do this as the parser state may not be safe for any specific error message if we are already unwinding due to an error. * parser/Parser.cpp: 2013-11-26 Nadav Rotem