From 1bf1084f2b10c3b47fd1a588d85d21ed0eb41d0c Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 27 Jun 2017 06:07:23 +0000 Subject: webkitgtk-2.16.5 --- Source/JavaScriptCore/ChangeLog | 16275 -------------------------------------- 1 file changed, 16275 deletions(-) delete mode 100644 Source/JavaScriptCore/ChangeLog (limited to 'Source/JavaScriptCore/ChangeLog') diff --git a/Source/JavaScriptCore/ChangeLog b/Source/JavaScriptCore/ChangeLog deleted file mode 100644 index 84874e29c..000000000 --- a/Source/JavaScriptCore/ChangeLog +++ /dev/null @@ -1,16275 +0,0 @@ -2016-03-12 Tomas Popela - - [CLoop] - Fix CLoop on the 32-bit Big-Endians - https://bugs.webkit.org/show_bug.cgi?id=137020 - - Reviewed by Mark Lam. - - * llint/LowLevelInterpreter.asm: - * llint/LowLevelInterpreter32_64.asm: - -2016-03-12 Tomas Popela - - LLINT op_put_to_scope and op_get_from_scope should use loadpFromInstruction to get operand from instruction - https://bugs.webkit.org/show_bug.cgi?id=132333 - - Unreviewed. - - When loading operand variable from instruction in - _llint_op_get_from_scope and _llint_op_put_to_scope use - loadpFromInstruction instead of loadisFromInstruction. Also when - saving the operand in LLIntSlowPaths.cpp use the same way as in - CodeBlock.cpp. - - * llint/LLIntSlowPaths.cpp: - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2016-03-10 Carlos Garcia Campos - - Fix the build in Windows. - - Reviewed by Alberto Garcia. - - * interpreter/JSStack.cpp: - (JSC::commitSize): - -2015-12-07 Alberto Garcia - - Crashes on PPC64 due to mprotect() on address not aligned to the page size - https://bugs.webkit.org/show_bug.cgi?id=130237 - - Reviewed by Mark Lam. - - Make sure that commitSize is at least as big as the page size. - - * interpreter/JSStack.cpp: - (JSC::commitSize): - (JSC::JSStack::JSStack): - (JSC::JSStack::growSlowCase): - * interpreter/JSStack.h: - -2014-04-09 Mark Lam - - Ensure that LLINT accessing of the ProtoCallFrame is big endian friendly. - - - Reviewed by Mark Hahnenberg. - - Change ProtoCallFrame::paddedArgCount to be of type uint32_t. The argCount - that it pads is of type int anyway. It doesn't need to be 64 bit. This - also makes it work with the LLINT which is loading it with a loadi - instruction. - - We should add the PayLoadOffset to ProtoCallFrame::argCountAndCodeOriginValue - when loading the argCount. - - * interpreter/ProtoCallFrame.h: - (JSC::ProtoCallFrame::setPaddedArgCount): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2015-01-12 Geoffrey Garen - - Out of bounds read in IdentifierArena::makeIdentifier - https://bugs.webkit.org/show_bug.cgi?id=140376 - - Patch by Alexey Proskuryakov. - - Reviewed and ChangeLogged by Geoffrey Garen. - - No test, since this is a small past-the-end read, which is very - difficult to turn into a reproducible failing test -- and existing tests - crash reliably using ASan. - - * parser/ParserArena.h: - (JSC::IdentifierArena::makeIdentifier): - (JSC::IdentifierArena::makeIdentifierLCharFromUChar): Check for a - zero-length string input, like we do in the literal parser, since it is - not valid to dereference characters in a zero-length string. - - A zero-length string is allowed in JavaScript -- for example, "". - -2015-04-24 Matthew Mirman - - Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined - https://bugs.webkit.org/show_bug.cgi?id=141865 - rdar://problem/19927273 - - Reviewed by Filip Pizlo. - - * runtime/JSGlobalObjectFunctions.cpp: - (JSC::globalFuncProtoGetter): - (JSC::globalFuncProtoSetter): - -2015-04-17 Milan Crha - - [GTK][Stable] Missing implementation of callToJavaScript/callToNativeFunction with msys/mingw32 - https://bugs.webkit.org/show_bug.cgi?id=132856 - - * jit/JITStubsX86.h: - -2015-01-06 Philip Chimento - - webkit-gtk 2.3.3 fails to build on OS X - Conflicting type "Fixed" - https://bugs.webkit.org/show_bug.cgi?id=126433 - - Don't include CoreFoundation.h when building the GTK port. - - * Source/JavaScriptCore/API/WebKitAvailability.h: Add - !defined(BUILDING_GTK__) to defined(__APPLE__). - -2015-03-09 Mark Lam - - 8-bit version of weakCompareAndSwap() can cause an infinite loop. - https://webkit.org/b/142513> - - Reviewed by Filip Pizlo. - - Added a test that exercises the 8-bit CAS from multiple threads. The threads - will contend to set bits in a large array of bytes using the CAS function. - - * API/tests/CompareAndSwapTest.cpp: Added. - (Bitmap::Bitmap): - (Bitmap::numBits): - (Bitmap::clearAll): - (Bitmap::concurrentTestAndSet): - (setBitThreadFunc): - (testCompareAndSwap): - * API/tests/testapi.c: - (main): - * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: - * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - -2014-12-04 Oliver Hunt - - Serialization of MapData object provides unsafe access to internal types - https://bugs.webkit.org/show_bug.cgi?id=138653 - - Reviewed by Geoffrey Garen. - - Converting these ASSERTs into RELEASE_ASSERTs, as it is now obvious - that despite trying hard to be safe in all cases it's simply to easy - to use an iterator in an unsafe state. - - * runtime/MapData.h: - (JSC::MapData::const_iterator::key): - (JSC::MapData::const_iterator::value): - -2014-10-27 Mark Lam - - Crash when attempting to perform array iteration on a non-array with numeric keys not initialized. - - - Reviewed by Geoffrey Garen. - - The arrayIteratorNextThunkGenerator() thunk was not checking for the case where - the butterfly may be NULL. This was the source of the crash, and is now fixed. - - In addition, it is also not checking for the case where a property named "length" - may have been set on the iterated object. The thunk only checks the butterfly's - publicLength for its iteration operation. Array objects will work fine with this - because it always updates its butterfly's publicLength when its length changes. - In the case of iterable non-Array objects, the "length" property will require a - look up outside of the scope of this thunk. The fix is simply to limit the fast - case checks in this thunk to Array objects. - - * jit/ThunkGenerators.cpp: - (JSC::arrayIteratorNextThunkGenerator): - -2014-10-22 Byungseon Shin - - String(new Date(Mar 30 2014 01:00:00)) is wrong in CET - https://bugs.webkit.org/show_bug.cgi?id=130967 - - Reviewed by Mark Lam. - - By definition of calculateLocalTimeOffset, input time should be UTC time. - But there are many cases when input time is based on local time. - So, it gives erroneous results while calculating offset of DST boundary time. - By adding a argument to distinguish UTC and local time, we can get the correct offset. - - * JavaScriptCore.order: - * runtime/DateConstructor.cpp: - (JSC::constructDate): - (JSC::callDate): - (JSC::dateUTC): - * runtime/DateInstance.cpp: - (JSC::DateInstance::calculateGregorianDateTime): - (JSC::DateInstance::calculateGregorianDateTimeUTC): - * runtime/DatePrototype.cpp: - (JSC::setNewValueFromTimeArgs): - (JSC::setNewValueFromDateArgs): - (JSC::dateProtoFuncSetMilliSeconds): - (JSC::dateProtoFuncSetUTCMilliseconds): - (JSC::dateProtoFuncSetSeconds): - (JSC::dateProtoFuncSetUTCSeconds): - (JSC::dateProtoFuncSetMinutes): - (JSC::dateProtoFuncSetUTCMinutes): - (JSC::dateProtoFuncSetHours): - (JSC::dateProtoFuncSetUTCHours): - (JSC::dateProtoFuncSetDate): - (JSC::dateProtoFuncSetUTCDate): - (JSC::dateProtoFuncSetMonth): - (JSC::dateProtoFuncSetUTCMonth): - (JSC::dateProtoFuncSetFullYear): - (JSC::dateProtoFuncSetUTCFullYear): - (JSC::dateProtoFuncSetYear): - * runtime/JSDateMath.cpp: - (JSC::localTimeOffset): - (JSC::gregorianDateTimeToMS): - (JSC::msToGregorianDateTime): - (JSC::parseDateFromNullTerminatedCharacters): - * runtime/JSDateMath.h: - * runtime/VM.h: - (JSC::LocalTimeOffsetCache::LocalTimeOffsetCache): - (JSC::LocalTimeOffsetCache::reset): - Passing TimeType argument to distingush UTC time and local time. - -2014-08-19 Magnus Granberg - - TEXTREL in libjavascriptcoregtk-1.0.so.0.11.0 on x86 (or i586) - https://bugs.webkit.org/show_bug.cgi?id=70610 - - Reviewed by Darin Adler. - - Setup %ebx so we can use the plt. - - * jit/ThunkGenerators.cpp: - -2014-10-06 Philip Chimento - - webkit-gtk fails to link JavaScriptCore, missing symbols add_history and readline - https://bugs.webkit.org/show_bug.cgi?id=127059 - - Reviewed by Carlos Garcia Campos. - - * GNUmakefile.am: add -ledit to jsc link args on OS_DARWIN. - -2014-04-15 Filip Pizlo - - Unreviewed, add the obvious thing that marks MakeRope as exiting since it can exit. - - * dfg/DFGAbstractInterpreterInlines.h: - (JSC::DFG::AbstractInterpreter::executeEffects): - -2014-08-18 Diego Pino Garcia - - Completed iterator can be revived by adding more than one new entry to the target object - https://bugs.webkit.org/show_bug.cgi?id=129993 - - Reviewed by Oliver Hunt. - - When iterator reaches end, finish iterator. - - * runtime/JSMapIterator.h: - (JSC::JSMapIterator::finish): - * runtime/JSSetIterator.h: - (JSC::JSSetIterator::finish): - * runtime/MapData.h: - (JSC::MapData::const_iterator::finish): set index of iterator to max - Int32. - * runtime/MapIteratorPrototype.cpp: - (JSC::MapIteratorPrototypeFuncNext): - * runtime/SetIteratorPrototype.cpp: - (JSC::SetIteratorPrototypeFuncNext): - -2014-07-04 Carlos Garcia Campos - - [GTK] [Stable] Crash while playing a video - https://bugs.webkit.org/show_bug.cgi?id=133940 - - Unreviewed. Rolling out r160688. - - * jit/CCallHelpers.h: - * jit/Repatch.cpp: - (JSC::generateProtoChainAccessStub): - (JSC::tryBuildGetByIDList): - -2014-05-19 Mark Lam - - operationOptimize() should defer the GC for a while. - - - Reviewed by Filip Pizlo. - - Currently, operationOptimize() only defers the GC until its end. As a result, - a GC may be triggered just before we return from operationOptimize(), and it may - jettison the optimize codeBlock that we're planning to OSR enter into when we - return from this function. This is because the OSR entry on-ramp code hasn't - been executed yet, and hence, there is not yet a reference to this new codeBlock - from the stack, and there won't be until we've had a chance to return out of - operationOptimize() to run the OSR entry on-ramp code. - - This issue is now fixed by using DeferGCForAWhile instead of DeferGC. This - ensures that the GC will be deferred until after the OSR entry on-ramp can be - executed. - - * jit/JITOperations.cpp: - -2014-05-09 Alberto Garcia - - jsmin.py license header confusing, mentions non-free license - https://bugs.webkit.org/show_bug.cgi?id=123665 - - Reviewed by Darin Adler. - - Pull the most recent version from upstream, which has a clear - license. - - * inspector/scripts/jsmin.py: - -2014-04-19 Filip Pizlo - - Make it easier to check if an integer sum would overflow - https://bugs.webkit.org/show_bug.cgi?id=131900 - - Reviewed by Darin Adler. - - * dfg/DFGOperations.cpp: - * runtime/Operations.h: - (JSC::jsString): - -2014-04-19 Filip Pizlo - - Address some feedback on https://bugs.webkit.org/show_bug.cgi?id=130684. - - * dfg/DFGOperations.cpp: - * runtime/JSString.h: - (JSC::JSRopeString::RopeBuilder::append): - -2014-04-15 Filip Pizlo - - compileMakeRope does not emit necessary bounds checks - https://bugs.webkit.org/show_bug.cgi?id=130684 - - - Reviewed by Oliver Hunt. - - Add string length bounds checks in a bunch of places. We should never allow a string - to have a length greater than 2^31-1 because it's not clear that the language has - semantics for it and because there is code that assumes that this cannot happen. - - Also add a bunch of tests to that effect to cover the various ways in which this was - previously allowed to happen. - - * dfg/DFGOperations.cpp: - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileMakeRope): - * ftl/FTLLowerDFGToLLVM.cpp: - (JSC::FTL::LowerDFGToLLVM::compileMakeRope): - * runtime/JSString.cpp: - (JSC::JSRopeString::RopeBuilder::expand): - * runtime/JSString.h: - (JSC::JSString::create): - (JSC::JSRopeString::RopeBuilder::append): - (JSC::JSRopeString::RopeBuilder::release): - (JSC::JSRopeString::append): - * runtime/Operations.h: - (JSC::jsString): - (JSC::jsStringFromRegisterArray): - (JSC::jsStringFromArguments): - * runtime/StringPrototype.cpp: - (JSC::stringProtoFuncIndexOf): - (JSC::stringProtoFuncSlice): - (JSC::stringProtoFuncSubstring): - (JSC::stringProtoFuncToLowerCase): - * tests/stress/make-large-string-jit-strcat.js: Added. - (foo): - * tests/stress/make-large-string-jit.js: Added. - (foo): - * tests/stress/make-large-string-strcat.js: Added. - * tests/stress/make-large-string.js: Added. - -2014-03-12 Mark Lam - - Update type of local vars to match the type of String length. - - - Reviewed by Geoffrey Garen. - - * runtime/JSStringJoiner.cpp: - (JSC::JSStringJoiner::join): - -2014-02-01 Michael Saboff - - REGRESSION (r163027?): CrashTracer: [USER] com.apple.WebKit.WebContent.Development at com.apple.JavaScriptCore: JSC::ArrayProfile::computeUpdatedPrediction + 4 - https://bugs.webkit.org/show_bug.cgi?id=128037 - - Reviewed by Mark Lam. - - op_call_varargs ops now needs an ArrayProfile since DFG inlines these since - change set r162739. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitCallVarargs): - -2014-01-30 Zan Dobersek - - [GTK] Only disable -ftree-dce optimization when compiling with GCC - https://bugs.webkit.org/show_bug.cgi?id=127911 - - Reviewed by Carlos Garcia Campos. - - * GNUmakefile.am: Only disable the -ftree-dce optimization when using the GCC compiler. - Some Clang versions/configurations don't support the flag. - -2014-01-30 Zan Dobersek - - [GTK] Disable optimizations for JSC that turned out malignant after jsCStack branch merge - https://bugs.webkit.org/show_bug.cgi?id=127909 - - Reviewed by Carlos Garcia Campos. - - * GNUmakefile.am: Disable the -fomit-frame-pointer optimization to achieve proper register usage - in operationCallEval. Disable the -ftree-dce optimization since it is causing additional failures - when using GCC 4.8, possibly due to a bug in the compiler itself. - -2014-01-29 Csaba Osztrogonác - - Remove ENABLE(JAVASCRIPT_DEBUGGER) leftovers - https://bugs.webkit.org/show_bug.cgi?id=127845 - - Reviewed by Joseph Pecoraro. - - * Configurations/FeatureDefines.xcconfig: - -2014-01-29 Csaba Osztrogonác - - Remove ENABLE(JAVASCRIPT_DEBUGGER) guards - https://bugs.webkit.org/show_bug.cgi?id=127840 - - Reviewed by Mark Lam. - - * inspector/scripts/CodeGeneratorInspector.py: - -2014-01-28 Commit Queue - - Unreviewed, rolling out r162987. - http://trac.webkit.org/changeset/162987 - https://bugs.webkit.org/show_bug.cgi?id=127825 - - Broke Mountain Lion build (Requested by andersca on #webkit). - - * inspector/InjectedScriptSource.js: - (.): - * runtime/JSObject.cpp: - (JSC::JSObject::getOwnPropertyDescriptor): - * runtime/PropertyDescriptor.cpp: - * runtime/PropertyDescriptor.h: - * runtime/PropertySlot.h: - -2014-01-28 Oliver Hunt - - Make DOM attributes appear to be faux accessor properties - https://bugs.webkit.org/show_bug.cgi?id=127797 - - Reviewed by Michael Saboff. - - Add flag so we can identify which properties should have the old - custom property semantics vs. the new faux accessors. Update the - inspector protocol accordingly. - - These faux accessors produce descriptors with "get" and "set" - properties, but both values are undefined so can't be used - directly. A few custom properties actually require their - existing magical behaviour, so we now have a flag to - distinguish the expected output. - - * inspector/InjectedScriptSource.js: - (.): - * runtime/JSObject.cpp: - (JSC::JSObject::getOwnPropertyDescriptor): - * runtime/PropertyDescriptor.cpp: - (JSC::PropertyDescriptor::setCustomDescriptor): - * runtime/PropertyDescriptor.h: - * runtime/PropertySlot.h: - -2014-01-28 Mark Lam - - Remove some unneeded debugger code. - https://bugs.webkit.org/show_bug.cgi?id=127805. - - Reviewed by Oliver Hunt. - - JSC will now always support the debugger. Hence, the #if ENABLE(JAVASCRIPT_DEBUGGER) - checks can be removed. - - DebuggerCallFrame::callFrame() is also unused and will be removed. - - * debugger/Breakpoint.h: - * debugger/Debugger.cpp: - * debugger/DebuggerCallFrame.h: - * inspector/InjectedScript.cpp: - (Inspector::InjectedScript::wrapCallFrames): - * inspector/InjectedScript.h: - * inspector/JSGlobalObjectScriptDebugServer.cpp: - * inspector/JSGlobalObjectScriptDebugServer.h: - * inspector/JSJavaScriptCallFrame.cpp: - * inspector/JSJavaScriptCallFrame.h: - * inspector/JSJavaScriptCallFramePrototype.cpp: - * inspector/JSJavaScriptCallFramePrototype.h: - * inspector/JavaScriptCallFrame.cpp: - * inspector/JavaScriptCallFrame.h: - * inspector/ScriptDebugListener.h: - * inspector/ScriptDebugServer.cpp: - * inspector/ScriptDebugServer.h: - * inspector/agents/InspectorDebuggerAgent.cpp: - * inspector/agents/InspectorDebuggerAgent.h: - * inspector/agents/InspectorRuntimeAgent.cpp: - (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent): - (Inspector::setPauseOnExceptionsState): - (Inspector::InspectorRuntimeAgent::evaluate): - (Inspector::InspectorRuntimeAgent::callFunctionOn): - (Inspector::InspectorRuntimeAgent::getProperties): - * inspector/agents/InspectorRuntimeAgent.h: - -2014-01-28 Geoffrey Garen - - REGRESSION: JavascriptCore crash during OS Installation (due to - Heap::m_operationInProgress ASSERT vs DelayedReleaseScope) - https://bugs.webkit.org/show_bug.cgi?id=127793 - - Reviewed by Mark Hahnenberg. - - This was a mistaken ASSERT. - - * API/tests/testapi.mm: - (-[EvilAllocationObject doEvilThingsWithContext:]): Added a test to verify - that GC from a DelayedReleaseScope doesn't crash. - - * heap/DelayedReleaseScope.h: - (JSC::DelayedReleaseScope::~DelayedReleaseScope): Our contract is that - it is valid to do anything while running a DelayedReleaseScope -dealloc - method, so the Heap must be ready for new allocations and collections. - - Change the Heap's operationInProgress value to NoOperation while running - -dealloc methods, so that it doesn't ASSERT in the face of new allocations - and collections. - - * heap/Heap.h: Made DelayedReleaseScope a friend because exposing a setter - for m_operationInProgress seemed like the worse of the two options for - encapsulation: we don't really want arbitrary clients to set the Heap's - m_operationInProgress. - -2014-01-28 Mark Lam - - Jettison DFG code when neither breakpoints or the profiler are active. - - - Reviewed by Geoffrey Garen. - - We need to jettison the DFG CodeBlocks under the following circumstances: - 1. When adding breakpoints to a CodeBlock, jettison it if it is a DFG CodeBlock. - 2. When enabling stepping mode in a CodeBlock, jettison it if it a DFG CodeBlock. - 3. When settign the enabled profiler in the VM, we need to jettison all DFG - CodeBlocks. - - Instead of emitting speculation checks, the DFG code will now treat Breakpoint, - ProfileWillCall, and ProfileDidCall as no-ops similar to a Phantom node. We - still need to track these nodes so that they match the corresponding opcodes - in the baseline JIT when we jettison and OSR exit. Without them, we would OSR - exit to the wrong location in the baseline JIT code. - - In DFGDriver's compileImpl() and DFGPlan's finalizeWithoutNotifyingCallback() - we fail the compilation effort with a CompilationInvalidated result. This allows - the DFG compiler to re-attampt the compilation of the function after some time - if it is hot. The CompilationInvalidated result is supposed to cause the DFG - to exercise an exponential back off before re-attempting compilation again - (see runtime/CompilationResult.h). - - This patch improves the Octane score from ~2950 to ~3067. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::addBreakpoint): - (JSC::CodeBlock::setSteppingMode): - * bytecode/CodeBlock.h: - * debugger/Debugger.h: - * dfg/DFGAbstractInterpreterInlines.h: - (JSC::DFG::AbstractInterpreter::executeEffects): - * dfg/DFGClobberize.h: - (JSC::DFG::clobberize): - * dfg/DFGDriver.cpp: - (JSC::DFG::compileImpl): - * dfg/DFGPlan.cpp: - (JSC::DFG::Plan::finalizeWithoutNotifyingCallback): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * profiler/LegacyProfiler.cpp: - (JSC::LegacyProfiler::startProfiling): - (JSC::LegacyProfiler::stopProfiling): - * runtime/VM.cpp: - (JSC::VM::VM): - (JSC::SetEnabledProfilerFunctor::operator()): - (JSC::VM::setEnabledProfiler): - * runtime/VM.h: - (JSC::VM::enabledProfiler): - -2014-01-27 Joseph Pecoraro - - -[JSContext evaluteScript:] calls JSEvaluteScript with startingLineNumber 0, later interpreted as a oneBasedInt - https://bugs.webkit.org/show_bug.cgi?id=127648 - - Reviewed by Geoffrey Garen. - - The actual bug being fixed here is that the line number for - scripts evaluated via the JSC APIs is now sane. However, - there is no good infrastructure in place right now to test that. - - * API/tests/testapi.c: - (main): - * API/tests/testapi.mm: - (testObjectiveCAPI): - Add tests for exception line numbers and handling of bad - startingLineNumbers in public APIs. These tests were already - passing, I just add them to make sure they are not regressed - in the future. - - * API/JSBase.cpp: - (JSEvaluateScript): - (JSCheckScriptSyntax): - * API/JSBase.h: - * API/JSObjectRef.cpp: - (JSObjectMakeFunction): - * API/JSObjectRef.h: - * API/JSScriptRef.cpp: - * API/JSScriptRefPrivate.h: - * API/JSStringRef.h: - - Clarify documentation that startingLineNumber is 1 based and clamped. - - Add clamping in the implementation to put sane values into JSC::SourceProvider. - - * inspector/agents/InspectorDebuggerAgent.cpp: - (Inspector::InspectorDebuggerAgent::didParseSource): - Remove the FIXME now that the SourceProvider is giving us expected values. - -2014-01-27 Joseph Pecoraro - - Web Inspector: CRASH when debugger closes remote inspecting JSContext - https://bugs.webkit.org/show_bug.cgi?id=127738 - - Reviewed by Timothy Hatcher. - - RemoteInspectorXPCConnection could be accessed in a background dispatch - queue, while being deallocated on the main thread when a connection - was suddenly terminated. - - Make RemoteInspectorXPCConnection a ThreadSafeRefCounted object. Always - keep the connection object ref'd until the main thread calls close() - and removes its reference. At that point we can close the connection, - queue, and deref safely on the background queue. - - * inspector/remote/RemoteInspector.h: - * inspector/remote/RemoteInspector.mm: - (Inspector::RemoteInspector::setupXPCConnectionIfNeeded): - (Inspector::RemoteInspector::xpcConnectionFailed): - For simplicity RemoteInspectorXPCConnections's don't have any threading - primatives to prevent client callbacks after they are closed. RemoteInspector - does, so it just ignores possible callbacks from connections it no longer - cares about. - - * inspector/remote/RemoteInspectorXPCConnection.h: - * inspector/remote/RemoteInspectorXPCConnection.mm: - (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): - (Inspector::RemoteInspectorXPCConnection::~RemoteInspectorXPCConnection): - (Inspector::RemoteInspectorXPCConnection::close): - Keep the connection alive as long as the queue it can be used on - is alive. Clean up everything on the queue when close() is called. - - (Inspector::RemoteInspectorXPCConnection::handleEvent): - Checking if closed here is not thread safe so it is meaningless. - Remove the check. - - (Inspector::RemoteInspectorXPCConnection::sendMessage): - Bail based on the m_closed state. - -2014-01-27 Joseph Pecoraro - - JavaScriptCore: Enable -Wimplicit-fallthrough and add FALLTHROUGH annotation where needed - https://bugs.webkit.org/show_bug.cgi?id=127647 - - Reviewed by Anders Carlsson. - - Explicitly annotate switch case fallthroughs in JavaScriptCore and - enable warnings for unannotated fallthroughs. - - * dfg/DFGArithMode.h: - (doesOverflow): - Only insert FALLTHROUGH in release builds. In debug builds, the - FALLTHROUGH would be unreachable (due to the ASSERT_NOT_REACHED) - and would through a warning. - - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal): - (JSC::DFG::SpeculativeJIT::fillSpeculateInt52): - Due to the templatized nature of this function, a fallthrough - in one of the template expansions would be unreachable. Disable - the warning for this function. - - * Configurations/Base.xcconfig: - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * dfg/DFGCFGSimplificationPhase.cpp: - (JSC::DFG::CFGSimplificationPhase::run): - * dfg/DFGValidate.cpp: - (JSC::DFG::Validate::validateCPS): - * parser/Lexer.cpp: - (JSC::Lexer::lex): - * parser/Parser.cpp: - (JSC::Parser::parseStatement): - (JSC::Parser::parseProperty): - * runtime/JSArray.cpp: - (JSC::JSArray::push): - * runtime/JSONObject.cpp: - (JSC::Walker::walk): - * runtime/JSObject.cpp: - (JSC::JSObject::putByIndex): - (JSC::JSObject::putByIndexBeyondVectorLength): - * runtime/JSObject.h: - (JSC::JSObject::setIndexQuickly): - (JSC::JSObject::initializeIndex): - * runtime/LiteralParser.cpp: - (JSC::LiteralParser::parse): - * yarr/YarrInterpreter.cpp: - (JSC::Yarr::Interpreter::backtrackParenthesesOnceBegin): - (JSC::Yarr::Interpreter::backtrackParenthesesOnceEnd): - * yarr/YarrParser.h: - (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter): - (JSC::Yarr::Parser::CharacterClassParserDelegate::atomBuiltInCharacterClass): - (JSC::Yarr::Parser::parseEscape): - (JSC::Yarr::Parser::parseTokens): - -2014-01-27 Andy Estes - - Scrub WebKit API headers of WTF macros - https://bugs.webkit.org/show_bug.cgi?id=127706 - - Reviewed by David Kilzer. - - * Configurations/FeatureDefines.xcconfig: Added ENABLE_INSPECTOR. - -2014-01-27 Mark Lam - - Remove unused CodeBlock::createActivation(). - - - Reviewed by Filip Pizlo. - - * bytecode/CodeBlock.cpp: - * bytecode/CodeBlock.h: - -2014-01-26 Andreas Kling - - JSC: Pack unlinked instructions harder. - - - Store UnlinkedCodeBlock's instructions in a variable-length stream - to reduce memory usage. Compression rate ends up around 60-61%. - - The format is very simple. Every instruction starts with a 1 byte - opcode. It's followed by an opcode-dependent number of argument - values, each encoded separately for maximum packing. There are - 7 packed value formats: - - 5-bit positive integer - 5-bit negative integer - 13-bit positive integer - 13-bit positive integer - 5-bit constant register index - 13-bit constant register index - 32-bit value (fallback) - - 27.5 MB progression on Membuster3. (~2% of total memory.) - - Reviewed by Filip Pizlo. - - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/UnlinkedInstructionStream.h: Added. - (JSC::UnlinkedInstructionStream::count): - (JSC::UnlinkedInstructionStream::Reader::atEnd): - * bytecode/UnlinkedInstructionStream.cpp: Added. - (JSC::UnlinkedInstructionStream::Reader::Reader): - (JSC::UnlinkedInstructionStream::Reader::read8): - (JSC::UnlinkedInstructionStream::Reader::read32): - (JSC::UnlinkedInstructionStream::Reader::next): - (JSC::append8): - (JSC::append32): - (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream): - (JSC::UnlinkedInstructionStream::unpackForDebugging): - * bytecompiler/BytecodeGenerator.cpp: - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecode/UnlinkedCodeBlock.cpp: - (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset): - (JSC::dumpLineColumnEntry): - (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): - (JSC::UnlinkedCodeBlock::setInstructions): - (JSC::UnlinkedCodeBlock::instructions): - * bytecode/UnlinkedCodeBlock.h: - (JSC::BytecodeGenerator::generate): - -2014-01-26 Joseph Pecoraro - - Web Inspector: Move InspectorDebuggerAgent into JavaScriptCore - https://bugs.webkit.org/show_bug.cgi?id=127629 - - Rubber-stamped by Sam Weinig. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - - Add new files to the build. - - Also, since non REMOTE_INSPECTOR ports cannot yet connect to a - JSGlobalObject for inspection remove those files as they don't - need to be built. - - * inspector/EventLoop.cpp: Added. - (Inspector::EventLoop::cycle): - * inspector/EventLoop.h: Added. - (Inspector::EventLoop::EventLoop): - (Inspector::EventLoop::ended): - Add a JavaScriptCore version of EventLoop. This is currently only - used by the Mac port for JSGlobalObject remote inspection. Keep - the WebCore/platform version alive because for the Mac port it does - slightly different things involving AppKit. - - * inspector/JSGlobalObjectInspectorController.cpp: - (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): - Create DebuggerAgent and hook up ScriptDebugServer where needed. - - * inspector/JSGlobalObjectScriptDebugServer.cpp: Added. - (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer): - (Inspector::JSGlobalObjectScriptDebugServer::addListener): - (Inspector::JSGlobalObjectScriptDebugServer::removeListener): - (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions): - (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused): - * inspector/JSGlobalObjectScriptDebugServer.h: Added. - Simple implementation of ScriptDebugServer with a JSGlobalObject. - - * inspector/agents/InspectorDebuggerAgent.cpp: Renamed from Source/WebCore/inspector/InspectorDebuggerAgent.cpp. - * inspector/agents/InspectorDebuggerAgent.h: Renamed from Source/WebCore/inspector/InspectorDebuggerAgent.h. - Copied from WebCore. A few methods need to be made virtual so that Web implementations - can override and extend the funcitonality. E.g. sourceMapURLForScript and enable/disable. - - * inspector/agents/JSGlobalObjectDebuggerAgent.cpp: Added. - * inspector/agents/JSGlobalObjectDebuggerAgent.h: Added. - (Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent): - (Inspector::JSGlobalObjectDebuggerAgent::startListeningScriptDebugServer): - (Inspector::JSGlobalObjectDebuggerAgent::stopListeningScriptDebugServer): - (Inspector::JSGlobalObjectDebuggerAgent::injectedScriptForEval): - Simple implementation of DebuggerAGent with a JSGlobalObject. - -2014-01-25 Mark Lam - - Gardening: fix build breakage from previous commit. - - Not reviewed. - - * profiler/ProfileNode.cpp: - (JSC::ProfileNode::debugPrintData): - - Removed obsolete references to "visible" timers. - -2014-01-25 Timothy Hatcher - - Remove dead code from the JSC profiler. - - https://bugs.webkit.org/show_bug.cgi?id=127643 - - Reviewed by Mark Lam. - - * profiler/Profile.cpp: - * profiler/Profile.h: - * profiler/ProfileGenerator.cpp: - (JSC::ProfileGenerator::stopProfiling): - * profiler/ProfileNode.cpp: - (JSC::ProfileNode::ProfileNode): - (JSC::ProfileNode::stopProfiling): - (JSC::ProfileNode::endAndRecordCall): - (JSC::ProfileNode::debugPrintData): - (JSC::ProfileNode::debugPrintDataSampleStyle): - * profiler/ProfileNode.h: - (JSC::ProfileNode::totalTime): - (JSC::ProfileNode::setTotalTime): - (JSC::ProfileNode::selfTime): - (JSC::ProfileNode::setSelfTime): - (JSC::ProfileNode::totalPercent): - (JSC::ProfileNode::selfPercent): - Remove support for things like focus and exclude. The Inspector does those in JS now. - -2014-01-25 Sam Weinig - - Remove unused support for DRAGGABLE_REGION - https://bugs.webkit.org/show_bug.cgi?id=127642 - - Reviewed by Simon Fraser. - - * Configurations/FeatureDefines.xcconfig: - -2014-01-25 Darin Adler - - Try to fix Mac build. - - * runtime/DatePrototype.cpp: Put the include of inside - a conditional since we don't have that header in our Mac build configuration. - -2014-01-25 Darin Adler - - Call deprecatedCharacters instead of characters at more call sites - https://bugs.webkit.org/show_bug.cgi?id=127631 - - Reviewed by Sam Weinig. - - * API/JSValueRef.cpp: - (JSValueMakeFromJSONString): - * API/OpaqueJSString.cpp: - (OpaqueJSString::~OpaqueJSString): - * bindings/ScriptValue.cpp: - (Deprecated::jsToInspectorValue): - * inspector/ContentSearchUtilities.cpp: - (Inspector::ContentSearchUtilities::createSearchRegexSource): - * inspector/InspectorValues.cpp: - * runtime/Identifier.h: - (JSC::Identifier::deprecatedCharacters): - * runtime/JSStringBuilder.h: - (JSC::JSStringBuilder::append): - Use the new name. - -2014-01-25 Darin Adler - - Get rid of ICU_UNICODE and WCHAR_UNICODE remnants - https://bugs.webkit.org/show_bug.cgi?id=127623 - - Reviewed by Anders Carlsson. - - * runtime/DatePrototype.cpp: Removed USE(ICU_UNICODE) checks, since that's always true now. - -2014-01-25 Darin Adler - - [Mac] Rewrite locale-specific date formatting code to remove strange string creation - https://bugs.webkit.org/show_bug.cgi?id=127624 - - Reviewed by Anders Carlsson. - - * runtime/DatePrototype.cpp: - (JSC::formatLocaleDate): Use some smart pointers and conversion operators we already - have to do the formatting in a more straightforward way. - -2014-01-25 Anders Carlsson - - Remove atomicIncrement/atomicDecrement - https://bugs.webkit.org/show_bug.cgi?id=127625 - - Reviewed by Andreas Kling. - - Replace atomicIncrement/atomicDecrement with std::atomic. - - * bytecode/Watchpoint.h: - * ftl/FTLLowerDFGToLLVM.cpp: - (JSC::FTL::LowerDFGToLLVM::lower): - * profiler/ProfilerDatabase.cpp: - (JSC::Profiler::Database::Database): - (JSC::Profiler::Database::addDatabaseToAtExit): - -2014-01-24 Joseph Pecoraro - - Web Inspector: Move InspectorRuntimeAgent into JavaScriptCore - https://bugs.webkit.org/show_bug.cgi?id=127605 - - Reviewed by Timothy Hatcher. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - Add new files to the build. - - * inspector/agents/InspectorRuntimeAgent.h: Renamed from Source/WebCore/inspector/InspectorRuntimeAgent.h. - * inspector/agents/InspectorRuntimeAgent.cpp: Renamed from Source/WebCore/inspector/InspectorRuntimeAgent.cpp. - (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent): - (Inspector::InspectorRuntimeAgent::parse): - (Inspector::InspectorRuntimeAgent::evaluate): - (Inspector::InspectorRuntimeAgent::callFunctionOn): - (Inspector::InspectorRuntimeAgent::getProperties): - - Move the agent into JavaScriptCore. - - Modernize and cleanup. - - Make globalVM a pure virtual function for subclasses to implement. - - * inspector/agents/JSGlobalObjectRuntimeAgent.h: Added. - * inspector/agents/JSGlobalObjectRuntimeAgent.cpp: Added. - (Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent): - (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend): - (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend): - (Inspector::JSGlobalObjectRuntimeAgent::globalVM): - (Inspector::JSGlobalObjectRuntimeAgent::injectedScriptForEval): - Straightforward JSGlobalObject implementation. - - * inspector/JSGlobalObjectInspectorController.cpp: - (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController): - Add a runtime agent when inspecting a JSContext! - -2014-01-23 Joseph Pecoraro - - Move JavaScriptCallFrame and ScriptDebugServer into JavaScriptCore for inspector - https://bugs.webkit.org/show_bug.cgi?id=127543 - - Reviewed by Geoffrey Garen. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - Add new files. - - * inspector/ScriptDebugListener.h: - Extract WebCore knowledge from ScriptDebugServer. This will - eventually be made to work outside of WebCore. - - * inspector/ScriptDebugServer.h: Renamed from Source/WebCore/bindings/js/ScriptDebugServer.h. - * inspector/ScriptDebugServer.cpp: Renamed from Source/WebCore/bindings/js/ScriptDebugServer.cpp. - (Inspector::ScriptDebugServer::evaluateBreakpointAction): - (Inspector::ScriptDebugServer::dispatchDidPause): - (Inspector::ScriptDebugServer::dispatchBreakpointActionLog): - (Inspector::ScriptDebugServer::dispatchBreakpointActionSound): - (Inspector::ScriptDebugServer::sourceParsed): - (Inspector::ScriptDebugServer::dispatchFunctionToListeners): - (Inspector::ScriptDebugServer::handlePause): - Modernize code, and call the new ScriptDebugListener callbacks where appropriate. - - * inspector/JSJavaScriptCallFrame.cpp: Renamed from Source/WebCore/bindings/js/JSJavaScriptCallFrameCustom.cpp. - (Inspector::JSJavaScriptCallFrame::JSJavaScriptCallFrame): - (Inspector::JSJavaScriptCallFrame::finishCreation): - (Inspector::JSJavaScriptCallFrame::createPrototype): - (Inspector::JSJavaScriptCallFrame::destroy): - (Inspector::JSJavaScriptCallFrame::releaseImpl): - (Inspector::JSJavaScriptCallFrame::~JSJavaScriptCallFrame): - (Inspector::JSJavaScriptCallFrame::evaluate): - (Inspector::JSJavaScriptCallFrame::scopeType): - (Inspector::JSJavaScriptCallFrame::caller): - (Inspector::JSJavaScriptCallFrame::sourceID): - (Inspector::JSJavaScriptCallFrame::line): - (Inspector::JSJavaScriptCallFrame::column): - (Inspector::JSJavaScriptCallFrame::functionName): - (Inspector::JSJavaScriptCallFrame::scopeChain): - (Inspector::JSJavaScriptCallFrame::thisObject): - (Inspector::JSJavaScriptCallFrame::type): - (Inspector::toJS): - (Inspector::toJSJavaScriptCallFrame): - * inspector/JSJavaScriptCallFrame.h: Added. - (Inspector::JSJavaScriptCallFrame::createStructure): - (Inspector::JSJavaScriptCallFrame::create): - (Inspector::JSJavaScriptCallFrame::impl): - * inspector/JSJavaScriptCallFramePrototype.cpp: Added. - (Inspector::JSJavaScriptCallFramePrototype::finishCreation): - (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluate): - (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): - (Inspector::jsJavaScriptCallFrameAttributeCaller): - (Inspector::jsJavaScriptCallFrameAttributeSourceID): - (Inspector::jsJavaScriptCallFrameAttributeLine): - (Inspector::jsJavaScriptCallFrameAttributeColumn): - (Inspector::jsJavaScriptCallFrameAttributeFunctionName): - (Inspector::jsJavaScriptCallFrameAttributeScopeChain): - (Inspector::jsJavaScriptCallFrameAttributeThisObject): - (Inspector::jsJavaScriptCallFrameAttributeType): - (Inspector::jsJavaScriptCallFrameConstantGLOBAL_SCOPE): - (Inspector::jsJavaScriptCallFrameConstantLOCAL_SCOPE): - (Inspector::jsJavaScriptCallFrameConstantWITH_SCOPE): - (Inspector::jsJavaScriptCallFrameConstantCLOSURE_SCOPE): - (Inspector::jsJavaScriptCallFrameConstantCATCH_SCOPE): - * inspector/JSJavaScriptCallFramePrototype.h: Added. - (Inspector::JSJavaScriptCallFramePrototype::create): - (Inspector::JSJavaScriptCallFramePrototype::createStructure): - (Inspector::JSJavaScriptCallFramePrototype::JSJavaScriptCallFramePrototype): - * inspector/JavaScriptCallFrame.cpp: Renamed from Source/WebCore/bindings/js/JavaScriptCallFrame.cpp. - (Inspector::JavaScriptCallFrame::caller): - * inspector/JavaScriptCallFrame.h: Renamed from Source/WebCore/bindings/js/JavaScriptCallFrame.h. - Port of JavaScriptCallFrame.idl to a set of native JS classes. - -2014-01-24 Mark Lam - - DebuggerCallFrame::evaluateWithCallFrame() should not execute a null executable. - - - Reviewed by Oliver Hunt. - - In DebuggerCallFrame::evaluateWithCallFrame(), if the script string that - is passed in is bad, it will fail to create an Executable i.e. - EvalExecutable::create() returns a null pointer. However, - DebuggerCallFrame::evaluateWithCallFrame() was just clearing the - exception and proceeded to execute the null pointer as an Executable. - A crash ensues. - - Now, if an exception is detected while creating the Executable, we - abort instead. - - * debugger/DebuggerCallFrame.cpp: - (JSC::DebuggerCallFrame::evaluateWithCallFrame): - -2014-01-24 Oliver Hunt - - Put functions need to take a base object and a this value, and perform type checks on |this| - https://bugs.webkit.org/show_bug.cgi?id=127594 - - Reviewed by Geoffrey Garen. - - Change the signature for static setter functions, and update uses - - * create_hash_table: - * runtime/Lookup.h: - (JSC::putEntry): - * runtime/PutPropertySlot.h: - * runtime/RegExpConstructor.cpp: - (JSC::setRegExpConstructorInput): - (JSC::setRegExpConstructorMultiline): - -2014-01-24 Oliver Hunt - - Generic JSObject::put should handle static properties in the classinfo hierarchy - https://bugs.webkit.org/show_bug.cgi?id=127523 - - Reviewed by Geoffrey Garen. - - This patch makes JSObject::put correctly call static setters - defined by the ClassInfo. - - To make this not clobber performance, the ClassInfo HashTable - now includes a flag to indicate that it contains setters. This - required updating the lut generator so that it tracked (and emitted) - this. - - The rest of the change was making a number of the methods take - a VM rather than an ExecState*, so that Structure could set the - getter/setter flags during construction (if necessary). - - This also means most objects do not need to perform a lookupPut - manually anymore, so most custom ::put's are no longer needed. - DOMWindow is the only exception as it has interesting security - related semantics. - - * create_hash_table: - * interpreter/CallFrame.h: - (JSC::ExecState::arrayConstructorTable): - (JSC::ExecState::arrayPrototypeTable): - (JSC::ExecState::booleanPrototypeTable): - (JSC::ExecState::dataViewTable): - (JSC::ExecState::dateTable): - (JSC::ExecState::dateConstructorTable): - (JSC::ExecState::errorPrototypeTable): - (JSC::ExecState::globalObjectTable): - (JSC::ExecState::jsonTable): - (JSC::ExecState::numberConstructorTable): - (JSC::ExecState::numberPrototypeTable): - (JSC::ExecState::objectConstructorTable): - (JSC::ExecState::privateNamePrototypeTable): - (JSC::ExecState::regExpTable): - (JSC::ExecState::regExpConstructorTable): - (JSC::ExecState::regExpPrototypeTable): - (JSC::ExecState::stringConstructorTable): - (JSC::ExecState::promisePrototypeTable): - (JSC::ExecState::promiseConstructorTable): - * runtime/ArrayConstructor.cpp: - (JSC::ArrayConstructor::getOwnPropertySlot): - * runtime/ArrayPrototype.cpp: - (JSC::ArrayPrototype::getOwnPropertySlot): - * runtime/BooleanPrototype.cpp: - (JSC::BooleanPrototype::getOwnPropertySlot): - * runtime/ClassInfo.h: - (JSC::ClassInfo::propHashTable): - * runtime/DateConstructor.cpp: - (JSC::DateConstructor::getOwnPropertySlot): - * runtime/DatePrototype.cpp: - (JSC::DatePrototype::getOwnPropertySlot): - * runtime/ErrorPrototype.cpp: - (JSC::ErrorPrototype::getOwnPropertySlot): - * runtime/JSDataViewPrototype.cpp: - (JSC::JSDataViewPrototype::getOwnPropertySlot): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::getOwnPropertySlot): - * runtime/JSONObject.cpp: - (JSC::JSONObject::getOwnPropertySlot): - * runtime/JSObject.cpp: - (JSC::JSObject::put): - (JSC::JSObject::deleteProperty): - * runtime/JSPromiseConstructor.cpp: - (JSC::JSPromiseConstructor::getOwnPropertySlot): - * runtime/JSPromisePrototype.cpp: - (JSC::JSPromisePrototype::getOwnPropertySlot): - * runtime/Lookup.h: - (JSC::HashTable::copy): - (JSC::putEntry): - (JSC::lookupPut): - * runtime/NamePrototype.cpp: - (JSC::NamePrototype::getOwnPropertySlot): - * runtime/NumberConstructor.cpp: - (JSC::NumberConstructor::getOwnPropertySlot): - * runtime/NumberConstructor.h: - * runtime/NumberPrototype.cpp: - (JSC::NumberPrototype::getOwnPropertySlot): - * runtime/ObjectConstructor.cpp: - (JSC::ObjectConstructor::getOwnPropertySlot): - * runtime/RegExpConstructor.cpp: - (JSC::RegExpConstructor::getOwnPropertySlot): - * runtime/RegExpConstructor.h: - * runtime/RegExpObject.cpp: - (JSC::RegExpObject::getOwnPropertySlot): - (JSC::RegExpObject::put): - * runtime/RegExpPrototype.cpp: - (JSC::RegExpPrototype::getOwnPropertySlot): - * runtime/StringConstructor.cpp: - (JSC::StringConstructor::getOwnPropertySlot): - * runtime/Structure.cpp: - (JSC::Structure::Structure): - (JSC::Structure::freezeTransition): - (JSC::ClassInfo::hasStaticSetterOrReadonlyProperties): - -2014-01-24 Commit Queue - - Unreviewed, rolling out r162713. - http://trac.webkit.org/changeset/162713 - https://bugs.webkit.org/show_bug.cgi?id=127593 - - broke media/network-no-source-const-shadow (Requested by - thorton on #webkit). - - * create_hash_table: - * interpreter/CallFrame.h: - (JSC::ExecState::arrayConstructorTable): - (JSC::ExecState::arrayPrototypeTable): - (JSC::ExecState::booleanPrototypeTable): - (JSC::ExecState::dataViewTable): - (JSC::ExecState::dateTable): - (JSC::ExecState::dateConstructorTable): - (JSC::ExecState::errorPrototypeTable): - (JSC::ExecState::globalObjectTable): - (JSC::ExecState::jsonTable): - (JSC::ExecState::numberConstructorTable): - (JSC::ExecState::numberPrototypeTable): - (JSC::ExecState::objectConstructorTable): - (JSC::ExecState::privateNamePrototypeTable): - (JSC::ExecState::regExpTable): - (JSC::ExecState::regExpConstructorTable): - (JSC::ExecState::regExpPrototypeTable): - (JSC::ExecState::stringConstructorTable): - (JSC::ExecState::promisePrototypeTable): - (JSC::ExecState::promiseConstructorTable): - * runtime/ArrayConstructor.cpp: - (JSC::ArrayConstructor::getOwnPropertySlot): - * runtime/ArrayPrototype.cpp: - (JSC::ArrayPrototype::getOwnPropertySlot): - * runtime/BooleanPrototype.cpp: - (JSC::BooleanPrototype::getOwnPropertySlot): - * runtime/ClassInfo.h: - (JSC::ClassInfo::propHashTable): - * runtime/DateConstructor.cpp: - (JSC::DateConstructor::getOwnPropertySlot): - * runtime/DatePrototype.cpp: - (JSC::DatePrototype::getOwnPropertySlot): - * runtime/ErrorPrototype.cpp: - (JSC::ErrorPrototype::getOwnPropertySlot): - * runtime/JSDataViewPrototype.cpp: - (JSC::JSDataViewPrototype::getOwnPropertySlot): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::getOwnPropertySlot): - * runtime/JSONObject.cpp: - (JSC::JSONObject::getOwnPropertySlot): - * runtime/JSObject.cpp: - (JSC::JSObject::put): - (JSC::JSObject::deleteProperty): - * runtime/JSPromiseConstructor.cpp: - (JSC::JSPromiseConstructor::getOwnPropertySlot): - * runtime/JSPromisePrototype.cpp: - (JSC::JSPromisePrototype::getOwnPropertySlot): - * runtime/Lookup.h: - (JSC::HashTable::copy): - (JSC::putEntry): - (JSC::lookupPut): - * runtime/NamePrototype.cpp: - (JSC::NamePrototype::getOwnPropertySlot): - * runtime/NumberConstructor.cpp: - (JSC::NumberConstructor::getOwnPropertySlot): - (JSC::NumberConstructor::put): - * runtime/NumberConstructor.h: - * runtime/NumberPrototype.cpp: - (JSC::NumberPrototype::getOwnPropertySlot): - * runtime/ObjectConstructor.cpp: - (JSC::ObjectConstructor::getOwnPropertySlot): - * runtime/RegExpConstructor.cpp: - (JSC::RegExpConstructor::getOwnPropertySlot): - (JSC::RegExpConstructor::put): - * runtime/RegExpConstructor.h: - * runtime/RegExpObject.cpp: - (JSC::RegExpObject::getOwnPropertySlot): - (JSC::RegExpObject::put): - * runtime/RegExpPrototype.cpp: - (JSC::RegExpPrototype::getOwnPropertySlot): - * runtime/StringConstructor.cpp: - (JSC::StringConstructor::getOwnPropertySlot): - * runtime/Structure.cpp: - (JSC::Structure::Structure): - (JSC::Structure::freezeTransition): - -2014-01-24 Mark Lam - - ASSERT(!m_markedSpace.m_currentDelayedReleaseScope) reloading page in inspector. - - - Reviewed by Mark Hahnenberg. - - 1. We should not enter a HeapIterationScope when we iterate the CodeBlocks. - Apparently, iterating the CodeBlocks does not count as heap iteration. - - 2. If we're detaching the debugger due to the JSGlobalObject destructing, - then we don't need to clear the debugger requests in the associated - CodeBlocks. The JSGlobalObject destructing would mean that those - CodeBlocks would be destructing too, and it may not be safe to access - them anyway at this point. - - The assertion failure is because we had entered a HeapIterationScope - while the JSGlobalObject is destructing, which in turn means that GC - sweeping is in progress. It's not legal to iterate the heap while the GC - is sweeping. Once we fixed the above 2 issues, we will no longer have - the conditions that manifests this assertion failure. - - * debugger/Debugger.cpp: - (JSC::Debugger::detach): - (JSC::Debugger::setSteppingMode): - (JSC::Debugger::toggleBreakpoint): - (JSC::Debugger::clearBreakpoints): - (JSC::Debugger::clearDebuggerRequests): - * debugger/Debugger.h: - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::~JSGlobalObject): - -2014-01-24 Brent Fulgham - - [Win] Convert some NMake files to MSBuild project files - https://bugs.webkit.org/show_bug.cgi?id=127579 - - Reviewed by Tim Horton. - - * JavaScriptCore.vcxproj/JavaScriptCore.make: Removed. - * JavaScriptCore.vcxproj/JavaScriptCore.proj: Added. - -2014-01-24 Mark Lam - - Fixed a bad assertion in CodeBlock::removeBreakpoint(). - - - Reviewed by Joseph Pecoraro. - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::removeBreakpoint): - -2014-01-24 Joseph Pecoraro - - fast/profiler tests ASSERTing after moving recompileAllJSFunctions off a timer - https://bugs.webkit.org/show_bug.cgi?id=127566 - - Reviewed by Oliver Hunt. - - Make the VM handle recompilation as soon as possible after it is requested. - - * debugger/Debugger.cpp: - (JSC::Debugger::recompileAllJSFunctions): - When in a JavaScript stack, mark for recompilation when possible. - - * runtime/VMEntryScope.h: - (JSC::VMEntryScope::setRecompilationNeeded): - * runtime/VMEntryScope.cpp: - (JSC::VMEntryScope::VMEntryScope): - (JSC::VMEntryScope::~VMEntryScope): - Handle recompilation when the top VMEntryScope is popped. - Pass the needs recompilation flag up the stack if needed. - -2014-01-24 Oliver Hunt - - Generic JSObject::put should handle static properties in the classinfo hierarchy - https://bugs.webkit.org/show_bug.cgi?id=127523 - - Reviewed by Geoffrey Garen. - - This patch makes JSObject::put correctly call static setters - defined by the ClassInfo. - - To make this not clobber performance, the ClassInfo HashTable - now includes a flag to indicate that it contains setters. This - required updating the lut generator so that it tracked (and emitted) - this. - - The rest of the change was making a number of the methods take - a VM rather than an ExecState*, so that Structure could set the - getter/setter flags during construction (if necessary). - - This also means most objects do not need to perform a lookupPut - manually anymore, so most custom ::put's are no longer needed. - DOMWindow is the only exception as it has interesting security - related semantics. - - * create_hash_table: - * interpreter/CallFrame.h: - (JSC::ExecState::arrayConstructorTable): - (JSC::ExecState::arrayPrototypeTable): - (JSC::ExecState::booleanPrototypeTable): - (JSC::ExecState::dataViewTable): - (JSC::ExecState::dateTable): - (JSC::ExecState::dateConstructorTable): - (JSC::ExecState::errorPrototypeTable): - (JSC::ExecState::globalObjectTable): - (JSC::ExecState::jsonTable): - (JSC::ExecState::numberConstructorTable): - (JSC::ExecState::numberPrototypeTable): - (JSC::ExecState::objectConstructorTable): - (JSC::ExecState::privateNamePrototypeTable): - (JSC::ExecState::regExpTable): - (JSC::ExecState::regExpConstructorTable): - (JSC::ExecState::regExpPrototypeTable): - (JSC::ExecState::stringConstructorTable): - (JSC::ExecState::promisePrototypeTable): - (JSC::ExecState::promiseConstructorTable): - * runtime/ArrayConstructor.cpp: - (JSC::ArrayConstructor::getOwnPropertySlot): - * runtime/ArrayPrototype.cpp: - (JSC::ArrayPrototype::getOwnPropertySlot): - * runtime/BooleanPrototype.cpp: - (JSC::BooleanPrototype::getOwnPropertySlot): - * runtime/ClassInfo.h: - (JSC::ClassInfo::propHashTable): - * runtime/DateConstructor.cpp: - (JSC::DateConstructor::getOwnPropertySlot): - * runtime/DatePrototype.cpp: - (JSC::DatePrototype::getOwnPropertySlot): - * runtime/ErrorPrototype.cpp: - (JSC::ErrorPrototype::getOwnPropertySlot): - * runtime/JSDataViewPrototype.cpp: - (JSC::JSDataViewPrototype::getOwnPropertySlot): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::getOwnPropertySlot): - * runtime/JSONObject.cpp: - (JSC::JSONObject::getOwnPropertySlot): - * runtime/JSObject.cpp: - (JSC::JSObject::put): - (JSC::JSObject::deleteProperty): - * runtime/JSPromiseConstructor.cpp: - (JSC::JSPromiseConstructor::getOwnPropertySlot): - * runtime/JSPromisePrototype.cpp: - (JSC::JSPromisePrototype::getOwnPropertySlot): - * runtime/Lookup.h: - (JSC::HashTable::copy): - (JSC::putEntry): - (JSC::lookupPut): - * runtime/NamePrototype.cpp: - (JSC::NamePrototype::getOwnPropertySlot): - * runtime/NumberConstructor.cpp: - (JSC::NumberConstructor::getOwnPropertySlot): - * runtime/NumberConstructor.h: - * runtime/NumberPrototype.cpp: - (JSC::NumberPrototype::getOwnPropertySlot): - * runtime/ObjectConstructor.cpp: - (JSC::ObjectConstructor::getOwnPropertySlot): - * runtime/RegExpConstructor.cpp: - (JSC::RegExpConstructor::getOwnPropertySlot): - * runtime/RegExpConstructor.h: - * runtime/RegExpObject.cpp: - (JSC::RegExpObject::getOwnPropertySlot): - (JSC::RegExpObject::put): - * runtime/RegExpPrototype.cpp: - (JSC::RegExpPrototype::getOwnPropertySlot): - * runtime/StringConstructor.cpp: - (JSC::StringConstructor::getOwnPropertySlot): - * runtime/Structure.cpp: - (JSC::Structure::Structure): - (JSC::Structure::freezeTransition): - (JSC::ClassInfo::hasStaticSetterOrReadonlyProperties): - -2014-01-24 Mark Lam - - Skip op_profiler callbacks if !VM::m_enabledProfiler. - https://bugs.webkit.org/show_bug.cgi?id=127567. - - Reviewed by Geoffrey Garen. - - The profiler may not be always active (recording). When it's not active - (as in VM::m_enabledProfiler is null), then we might as well skip the - op_profiler callbacks. The callbacks themselves were already previously - gated by a VM::enabledProfiler() check. So, this change does not change - any profiler behavior. - - For the DFG, we'll turn the op_profiler handling into speculation checks - and OSR exit to the baseline JIT if the profiler becomes active. - - This brings the Octane score up to ~3000 from ~2840. - - * dfg/DFGAbstractInterpreterInlines.h: - (JSC::DFG::AbstractInterpreter::executeEffects): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGClobberize.h: - (JSC::DFG::clobberize): - * dfg/DFGNodeType.h: - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_profile_will_call): - (JSC::JIT::emit_op_profile_did_call): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_profile_will_call): - (JSC::JIT::emit_op_profile_did_call): - * llint/LowLevelInterpreter.asm: - * runtime/VM.h: - (JSC::VM::enabledProfilerAddress): - -2014-01-24 Mark Lam - - Removing the need for Debugger* and m_shouldPause op_debug check. - - - Reviewed by Geoffrey Garen. - - This patch replaces the checking of the Debugger::m_shouldPause flag - with a procedure to set a SteppingMode flag on all CodeBlocks under - the management of the debugger. This simplifies the op_debug checking - logic in all the execution engines. - - * bytecode/CodeBlock.cpp: - * bytecode/CodeBlock.h: - (JSC::CodeBlock::hasDebuggerRequests): - (JSC::CodeBlock::debuggerRequestsAddress): - (JSC::CodeBlock::setSteppingMode): - (JSC::CodeBlock::clearDebuggerRequests): - - CodeBlock::m_debuggerRequests is a union of m_numBreakpoints and the - new m_steppingMode. The debugger can add/remove breakpoints to the - CodeBlock as well as set the stepping mode. By having - m_debuggerRequests as a union of the 2 bit fields, the op_debug code - can now check if any of the 2 requests made on the CodeBlock is still - in effect just by testing a single int. - - * debugger/Debugger.cpp: - (JSC::Debugger::Debugger): - (JSC::Debugger::detach): - - This was bug from before where I forgot to clear the CodeBlock - breakpoints before detaching. We now take care of it by clearing all - debugger requests made to the CodeBlock. - - (JSC::Debugger::SetSteppingModeFunctor::SetSteppingModeFunctor): - (JSC::Debugger::SetSteppingModeFunctor::operator()): - (JSC::Debugger::setSteppingMode): - (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::ClearCodeBlockDebuggerRequestsFunctor): - (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::operator()): - (JSC::Debugger::clearBreakpoints): - - (JSC::Debugger::ClearDebuggerRequestsFunctor::ClearDebuggerRequestsFunctor): - (JSC::Debugger::ClearDebuggerRequestsFunctor::operator()): - (JSC::Debugger::clearDebuggerRequests): - - We need a distinct clearDebuggerRequests() from clearBreakpoints() - because: - 1. When we detach a globalObject, we only want to clear the debugger - requests in CodeBlocks from that global. - 2. Clearing the debugger requests in the CodeBlocks is not the same - as clearing the breakpoints. The breakpoints are still in effect - for the next time a globalObject is attached, or for other - globalObjects that are still attached. - - (JSC::Debugger::setPauseOnNextStatement): - (JSC::Debugger::breakProgram): - (JSC::Debugger::stepIntoStatement): - (JSC::Debugger::updateCallFrameAndPauseIfNeeded): - (JSC::Debugger::pauseIfNeeded): - (JSC::Debugger::exception): - (JSC::Debugger::willExecuteProgram): - (JSC::Debugger::didReachBreakpoint): - * debugger/Debugger.h: - - We're always going to support the debugger. So, there's no longer - a need to check ENABLE(JAVASCRIPT_DEBUGGER). Removed the unneeded code. - - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::debug): - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_debug): - * llint/LowLevelInterpreter.asm: - * runtime/JSGlobalObject.h: - (JSC::JSGlobalObject::setDebugger): - -2014-01-24 Michael Saboff - - ARM Offline assembler temporary register allocator has duplicate register when building fat binaries - https://bugs.webkit.org/show_bug.cgi?id=127545 - - Reviewed by Mark Lam. - - Eliminate the conditional addition of r11/r7 from getModifiedListARMCommon as the - .concat will add the new register to ARM_EXTRA_GPRS. If getModifiedListARMCommon is - invoked a second time, there will be a second r11 or r7, which messes things up. - Instead, r6 was added to ARM_EXTRA_GPRS. r6 is currently an unused register. - - * offlineasm/arm.rb: - -2014-01-23 Joseph Pecoraro - - Move ContentSearchUtils, ScriptBreakpoint, and ScriptDebugListener into JavaScriptCore for inspector - https://bugs.webkit.org/show_bug.cgi?id=127537 - - Reviewed by Timothy Hatcher. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - * inspector/ContentSearchUtilities.cpp: Renamed from Source/WebCore/inspector/ContentSearchUtils.cpp. - (Inspector::ContentSearchUtilities::createSearchRegexSource): - (Inspector::ContentSearchUtilities::sizetExtractor): - (Inspector::ContentSearchUtilities::textPositionFromOffset): - (Inspector::ContentSearchUtilities::getRegularExpressionMatchesByLines): - (Inspector::ContentSearchUtilities::lineEndings): - (Inspector::ContentSearchUtilities::buildObjectForSearchMatch): - (Inspector::ContentSearchUtilities::createSearchRegex): - (Inspector::ContentSearchUtilities::countRegularExpressionMatches): - (Inspector::ContentSearchUtilities::searchInTextByLines): - (Inspector::ContentSearchUtilities::scriptCommentPattern): - (Inspector::ContentSearchUtilities::stylesheetCommentPattern): - (Inspector::ContentSearchUtilities::findMagicComment): - (Inspector::ContentSearchUtilities::findScriptSourceURL): - (Inspector::ContentSearchUtilities::findScriptSourceMapURL): - (Inspector::ContentSearchUtilities::findStylesheetSourceMapURL): - * inspector/ContentSearchUtilities.h: Renamed from Source/WebCore/inspector/ContentSearchUtils.h. - * inspector/ScriptBreakpoint.h: Renamed from Source/WebCore/inspector/ScriptBreakpoint.h. - (Inspector::ScriptBreakpointAction::ScriptBreakpointAction): - (Inspector::ScriptBreakpoint::ScriptBreakpoint): - * inspector/ScriptDebugListener.h: Renamed from Source/WebCore/inspector/ScriptDebugListener.h. - (Inspector::ScriptDebugListener::Script::Script): - (Inspector::ScriptDebugListener::~ScriptDebugListener): - * runtime/RegExp.cpp: - (JSC::RegExp::match): - -2014-01-23 Joseph Pecoraro - - Move RegularExpression into JavaScriptCore for inspector - https://bugs.webkit.org/show_bug.cgi?id=127526 - - Reviewed by Geoffrey Garen. - - Move RegularExpression into JavaScriptCore/yarr so it can - be used later on by JavaScriptCore/inspector. Convert to - the JSC::Yarr namespace. - - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - * yarr/RegularExpression.cpp: Renamed from Source/WebCore/platform/text/RegularExpression.cpp. - (JSC::Yarr::RegularExpression::Private::create): - (JSC::Yarr::RegularExpression::Private::Private): - (JSC::Yarr::RegularExpression::Private::compile): - (JSC::Yarr::RegularExpression::RegularExpression): - (JSC::Yarr::RegularExpression::~RegularExpression): - (JSC::Yarr::RegularExpression::operator=): - (JSC::Yarr::RegularExpression::match): - (JSC::Yarr::RegularExpression::searchRev): - (JSC::Yarr::RegularExpression::matchedLength): - (JSC::Yarr::replace): - (JSC::Yarr::RegularExpression::isValid): - * yarr/RegularExpression.h: Renamed from Source/WebCore/platform/text/RegularExpression.h. - -2014-01-23 Joseph Pecoraro - - Web Inspector: Remove recompileAllJSFunctions timer in ScriptDebugServer - https://bugs.webkit.org/show_bug.cgi?id=127409 - - Reviewed by Geoffrey Garen. - - * inspector/InspectorAgentBase.h: - When disconnecting agents, provide a InspectorDisconnectReason for - the disconnection. It could be that an inspector frontend is just - disconnecting or that the inspected object is going away entirely - and we can avoid doing some work. - - * runtime/JSGlobalObjectDebuggable.h: - * runtime/JSGlobalObjectDebuggable.cpp: - (JSC::JSGlobalObjectDebuggable::~JSGlobalObjectDebuggable): - (JSC::JSGlobalObjectDebuggable::disconnect): - (JSC::JSGlobalObjectDebuggable::disconnectInternal): - Pass different reasons for the different disconnects. - - * inspector/InspectorAgentRegistry.cpp: - (Inspector::InspectorAgentRegistry::willDestroyFrontendAndBackend): - * inspector/InspectorAgentRegistry.h: - * inspector/JSGlobalObjectInspectorController.cpp: - (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): - * inspector/JSGlobalObjectInspectorController.h: - * inspector/agents/InspectorAgent.cpp: - (Inspector::InspectorAgent::willDestroyFrontendAndBackend): - * inspector/agents/InspectorAgent.h: - Pass InspectorDisconnectReason around where needed. - -2014-01-23 Mark Lam - - Enable DFG for the Debugger and Profiler. - - - Reviewed by Geoffrey Garen. - - In this patch, we implement DFG op_debug as a series of 3 checks: - 1. Check if the debugger pointer is non-null. This is needed in case - the debugger has been detached but the DFG code is still running - on the stack. - 2. Check if Debugger::m_shouldPause is true. - 3. Check if CodeBlock::m_numBreakpoints is non-zero. - - These are the same 3 checks done in the LLINT and baselineJIT. But unlike - the LLINT and baselineJIT, these DFG checks are implemented as - speculationChecks. If the check fails, we OSR exit to the baselineJIT and - let it do the work of servicing the op_debug callback. - - Stepping through code in the debugger would work the same way. The top - function being debugged has to be a LLINT or baselineJIT function because - we would have OSR exited if there is a breakpoint in that function. When - we step out of that function to its caller, we expect that the caller will - call back to the debugger at the next op_debug. If the caller function is - a DFG function, the op_debug site will fail its speculation check on - Debugger::m_shouldPause and deopt into a baselineJIT function. Execution - continues from there as usual, and the debugger gets its callback. - - For the profile, op_profile_will_call and op_profile_did_call are - implemented as simple runtime calls to service the profiler. - - With this patch, Octane performance with the WebInspector open jump from - ~2000 to ~2500 (25% progression). - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::numBreakpointsAddress): - * bytecode/ExitKind.cpp: - (JSC::exitKindToString): - * bytecode/ExitKind.h: - * debugger/Debugger.cpp: - (JSC::Debugger::toggleBreakpoint): - - removed an obsolete assertion. The debugger can now handle DFG - CodeBlocks too. - * debugger/Debugger.h: - * dfg/DFGAbstractInterpreterInlines.h: - (JSC::DFG::AbstractInterpreter::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/DFGNodeType.h: - * dfg/DFGPredictionPropagationPhase.cpp: - (JSC::DFG::PredictionPropagationPhase::propagate): - * dfg/DFGSafeToExecute.h: - (JSC::DFG::safeToExecute): - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::callOperation): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * runtime/JSGlobalObject.h: - (JSC::JSGlobalObject::debuggerAddress): - -2014-01-23 Max Vujovic - - Remove CSS Custom Filters code and tests - https://bugs.webkit.org/show_bug.cgi?id=127382 - - Reviewed by Simon Fraser. - - * Configurations/FeatureDefines.xcconfig: - -2014-01-22 Brent Fulgham - - [Win] Update project and solution files for 64-bit builds. - https://bugs.webkit.org/show_bug.cgi?id=127457 - - Reviewed by Eric Carlson. - - * JavaScriptCore.vcxproj/JavaScriptCore.submit.sln: Add 64-bit target. - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Update for VS2013 - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Add missing - file from project view. - * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Update for VS2013 - * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Ditto - * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Ditto - -2014-01-22 Mark Lam - - Poor man's fast breakpoints for a 2.3x debugger speedup. - - - Reviewed by Geoffrey Garen. - - Previously we gained back some performance (run at baseline JIT speeds) - when the WebInspector is opened provided no breakpoints are set. This - was achieved by simply skipping all op_debug callbacks to the debugger - if no breakpoints are set. If any breakpoints are set, the debugger will - set a m_needsOpDebugCallbacks flag which causes the callbacks to be - called, and we don't get the baseline JIT speeds anymore. - - With this patch, we will now track the number of breakpoints set in the - CodeBlock that they are set in. The LLINT and baseline JIT code will - check CodeBlock::m_numBreakpoints to determine if the op_debug callbacks - need to be called. With this, we will only enable op_debug callbacks for - CodeBlocks that need it i.e. those with breakpoints set in them. - - Debugger::m_needsOpDebugCallbacks is now obsoleted. The LLINT and baseline - JIT code still needs to check Debugger::m_shouldPause to determine if the - debugger is in stepping mode and hence, needs op_debug callbacks enabled - for everything until the debugger "continues" the run and exit stepping - mode. - - Also in this patch, I fixed a regression in DOM breakpoints which relies - Debugger::breakProgram() to pause the debugger. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::dumpBytecode): - - Missed accounting for op_debug's new hasBreakpointFlag operand here when - it was added. - (JSC::CodeBlock::CodeBlock): - (JSC::CodeBlock::hasOpDebugForLineAndColumn): - - This is needed in Debugger::toggleBreakpoint() to determine if a - breakpoint falls within a CodeBlock or not. Simply checking the bounds - of the CodeBlock is insufficient. For example, let's say we have the - following JS code: - - // begin global scope - function f1() { - function f2() { - ... // set breakpoint here. - } - } - // end global scope - - Using the CodeBlock bounds alone, the breakpoint above will to appear - to be in the global program CodeBlock, and the CodeBlocks for function - f1() and f2(). With CodeBlock::hasOpDebugForLineAndColumn() we can - rule out the global program CodeBlock and f1(), and only apply the - breakpoint to f2(0 where it belongs. - - CodeBlock::hasOpDebugForLineAndColumn() works by iterating over all - the opcodes in the CodeBlock to look for op_debug's. For each op_debug, - it calls CodeBlock::expressionRangeForBytecodeOffset() to do a binary - seach to get the line and column info for that op_debug. This is a - N * log(N) algorithm. However, a quick hands on test using the - WebInspector (with this patch applied) to exercise setting, breaking - on, and clearing breakpoints, as well as stepping through some code - shows no noticeable degradation of the user experience compared to the - baseline without this patch. - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::numBreakpoints): - (JSC::CodeBlock::numBreakpointsOffset): - (JSC::CodeBlock::addBreakpoint): - (JSC::CodeBlock::removeBreakpoint): - (JSC::CodeBlock::clearAllBreakpoints): - * debugger/Breakpoint.h: - - defined Breakpoint::unspecifiedColumn so that we can explicitly indicate - when the WebInspector was setting a line breakpoint and did not provide - a column value. CodeBlock::hasOpDebugForLineAndColumn() needs this - information in order to loosen its matching criteria for op_debug - bytecodes for the specified breakpoint line and column values provided - by the debugger. - - Previously, we just hijack a 0 value column as an unspecified column. - However, the WebInspector operates on 0-based ints for column values. - Hence, 0 should be a valid column value and should not be hijacked to - mean an unspecified column. - - * debugger/Debugger.cpp: - (JSC::Debugger::Debugger): - - added tracking of the VM that the debugger is used with. This is - needed by Debugger::breakProgram(). - - The VM pointer is attained from the first JSGlobalObject that the debugger - attaches to. When the debugger detaches from the last JSGlobalObject, it - will nullify its VM pointer to allow a new one to be set on the next - attach. - - We were always only using each debugger instance with one VM. This change - makes it explicit with an assert to ensure that all globalObjects that - the debugger attaches to beongs to the same VM. - - (JSC::Debugger::attach): - (JSC::Debugger::detach): - (JSC::Debugger::setShouldPause): - - (JSC::Debugger::registerCodeBlock): - (JSC::Debugger::unregisterCodeBlock): - - registerCodeBlock() is responsible for applying pre-existing breakpoints - to new CodeBlocks being installed. Similarly, unregisterCodeBlock() - clears the breakpoints. - - (JSC::Debugger::toggleBreakpoint): - - This is the workhorse function that checks if a breakpoint falls within - a CodeBlock or not. If it does, then it can either enable or disable - said breakpoint in the CodeBlock. In the current implementation, - enabling/disabling the breakpoint simply means incrementing/decrementing - the CodeBlock's m_numBreakpoints. - - (JSC::Debugger::applyBreakpoints): - - (JSC::Debugger::ToggleBreakpointFunctor::ToggleBreakpointFunctor): - (JSC::Debugger::ToggleBreakpointFunctor::operator()): - (JSC::Debugger::toggleBreakpoint): - - Iterates all relevant CodeBlocks and apply the specified breakpoint - if appropriate. This is called when a new breakpoint is being defined - by the WebInspector and needs to be applied to an already installed - CodeBlock. - - (JSC::Debugger::setBreakpoint): - (JSC::Debugger::removeBreakpoint): - (JSC::Debugger::hasBreakpoint): - (JSC::Debugger::ClearBreakpointsFunctor::ClearBreakpointsFunctor): - (JSC::Debugger::ClearBreakpointsFunctor::operator()): - (JSC::Debugger::clearBreakpoints): - - (JSC::Debugger::breakProgram): - - Fixed a regression that broke DOM breakpoints. The issue is that with - the skipping of op_debug callbacks, we don't always have an updated - m_currentCallFrame. Normally, m_currentCallFrame is provided as arg - in the op_debug callback. In this case, we can get the CallFrame* from - m_vm->topCallFrame. - - (JSC::Debugger::updateCallFrameAndPauseIfNeeded): - (JSC::Debugger::pauseIfNeeded): - (JSC::Debugger::willExecuteProgram): - * debugger/Debugger.h: - (JSC::Debugger::Debugger): - (JSC::Debugger::shouldPause): - - * heap/CodeBlockSet.h: - (JSC::CodeBlockSet::iterate): - * heap/Heap.h: - (JSC::Heap::forEachCodeBlock): - - Added utility to iterate all CodeBlocks in the heap / VM. - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::debug): - - * jit/JITOpcodes.cpp: - (JSC::JIT::emit_op_debug): - * jit/JITOpcodes32_64.cpp: - (JSC::JIT::emit_op_debug): - * llint/LowLevelInterpreter.asm: - - These now checks CodeBlock::m_numBreakpoints and Debugger::m_shouldPause - instead of Debugger::m_needsOpDebugCallbacks. - - * runtime/Executable.cpp: - (JSC::ScriptExecutable::installCode): - -2014-01-22 Myles C. Maxfield - - Remove CSS3_TEXT_DECORATION define - https://bugs.webkit.org/show_bug.cgi?id=127333 - - This is required for unprefixing the text-decoration-* CSS properties. - - Reviewed by Simon Fraser. - - * Configurations/FeatureDefines.xcconfig: - -2014-01-22 Alexey Proskuryakov - - Update JS whitespace definition for changes in Unicode 6.3 - https://bugs.webkit.org/show_bug.cgi?id=127450 - - - Reviewed by Oliver Hunt. - - Covered by existing tests when running against a Unicode back-end that supports - Unicode 6.3 or higher. - - * runtime/JSGlobalObjectFunctions.cpp: (JSC::isStrWhiteSpace): Explicitly allow - U+180E MONGOLIAN VOWEL SEPARATOR, because we need to keep recognizing all characters - that used to be whitespace. - -2014-01-21 Mark Hahnenberg - - Registers used in writeBarrierOnOperand can cause clobbering on some platforms - https://bugs.webkit.org/show_bug.cgi?id=127357 - - Reviewed by Filip Pizlo. - - Some platforms use t0 and t1 for their first two arguments, so using those to load the - cell for the write barrier is a bad idea because it will get clobbered. - - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - -2014-01-21 Mark Rowe - - Mac production build fix. - - Move the shell script build phase to copy jsc into JavaScriptCore.framework - out of the jsc target and in to the All target so that it's not run during - production builds. Xcode appears to the parent directories of paths referenced - in the Output Files of the build phase, which leads to problems when the - SYMROOT for the JavaScriptCore framework and the jsc executables are later merged. - - I've also fixed the path to the Resources folder in the script while I'm here. - On iOS the framework bundle is shallow so the correct destination is Resources/ - rather than Versions/A/Resources. This is handled by tweaking the - JAVASCRIPTCORE_RESOURCES_DIR configuration setting to be relative rather than - a complete path so we can reuse it in the script. The references in JSC.xcconfig - and ToolExecutable.xcconfig are updated to prepend JAVASCRIPTCORE_FRAMEWORKS_DIR - to preserve their former values. - - * Configurations/Base.xcconfig: - * Configurations/JSC.xcconfig: - * Configurations/ToolExecutable.xcconfig: - * JavaScriptCore.xcodeproj/project.pbxproj: - -2014-01-19 Andreas Kling - - JSC Parser: Shrink BindingNode. - - - The "divot" and "end" source locations are always identical for - BindingNodes, so store only "start" and "end" instead. - - 1.19 MB progression on Membuster3. - - Reviewed by Geoff Garen. - - * bytecompiler/NodesCodegen.cpp: - (JSC::BindingNode::bindValue): - * parser/ASTBuilder.h: - (JSC::ASTBuilder::createBindingLocation): - * parser/NodeConstructors.h: - (JSC::BindingNode::create): - (JSC::BindingNode::BindingNode): - * parser/Nodes.h: - (JSC::BindingNode::divotStart): - (JSC::BindingNode::divotEnd): - * parser/Parser.cpp: - (JSC::Parser::createBindingPattern): - * parser/SyntaxChecker.h: - (JSC::SyntaxChecker::operatorStackPop): - -2014-01-20 Filip Pizlo - - op_captured_mov and op_new_captured_func in UnlinkedCodeBlocks should use the IdentifierMap instead of the strings directly - https://bugs.webkit.org/show_bug.cgi?id=127311 - - - Reviewed by Andreas Kling. - - This makes UnlinkedCodeBlocks use 32-bit instruction streams again. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecode/UnlinkedCodeBlock.h: - (JSC::UnlinkedInstruction::UnlinkedInstruction): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::addVar): - (JSC::BytecodeGenerator::emitInitLazyRegister): - (JSC::BytecodeGenerator::createArgumentsIfNecessary): - * bytecompiler/BytecodeGenerator.h: - (JSC::BytecodeGenerator::watchableVariable): - (JSC::BytecodeGenerator::hasWatchableVariable): - -2014-01-20 Mark Lam - - Removing CodeBlock::opDebugBytecodeOffsetForLineAndColumn() and friends. - - - Reviewed by Geoffrey Garen. - - We're changing plans and will be going with CodeBlock level breakpoints - instead of bytecode level breakpoints. As a result, we no longer need - the services of CodeBlock::opDebugBytecodeOffsetForLineAndColumn() (and - friends). This patch will remove that unused code. - - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/CodeBlock.cpp: - * bytecode/CodeBlock.h: - * bytecode/LineColumnInfo.h: Removed. - * bytecode/UnlinkedCodeBlock.cpp: - (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): - * bytecode/UnlinkedCodeBlock.h: - -2014-01-20 Mark Hahnenberg - - CodeBlockSet::traceMarked doesn't need to visit the ownerExecutable - https://bugs.webkit.org/show_bug.cgi?id=127301 - - Reviewed by Oliver Hunt. - - We used to just call CodeBlock::visitAggregate, but now we call visitChildren - on the ownerExecutable, which is unnecessary. - - * heap/CodeBlockSet.cpp: - (JSC::CodeBlockSet::traceMarked): - -2014-01-20 Anders Carlsson - - Fix build. - - * heap/BlockAllocator.h: - -2014-01-20 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): - -2014-01-19 Anders Carlsson - - Convert GCThreadSharedData over to STL threading primitives - https://bugs.webkit.org/show_bug.cgi?id=127256 - - Reviewed by Andreas Kling. - - * heap/GCThread.cpp: - (JSC::GCThread::waitForNextPhase): - (JSC::GCThread::gcThreadMain): - * heap/GCThreadSharedData.cpp: - (JSC::GCThreadSharedData::GCThreadSharedData): - (JSC::GCThreadSharedData::~GCThreadSharedData): - (JSC::GCThreadSharedData::startNextPhase): - (JSC::GCThreadSharedData::endCurrentPhase): - (JSC::GCThreadSharedData::didStartMarking): - (JSC::GCThreadSharedData::didFinishMarking): - * heap/GCThreadSharedData.h: - * heap/SlotVisitor.cpp: - (JSC::SlotVisitor::donateKnownParallel): - (JSC::SlotVisitor::drainFromShared): - -2014-01-18 Andreas Kling - - CodeBlock: Size m_callLinkInfos and m_byValInfos to fit earlier. - - - Reviewed by Anders Carlsson. - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::setNumberOfByValInfos): - (JSC::CodeBlock::setNumberOfCallLinkInfos): - - Use resizeToFit() instead of grow() for these vectors, since - we know the final size here. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::shrinkToFit): - - No need to shrink here anymore. We were not even shrinking - m_byValInfo before! - -2014-01-18 Andreas Kling - - CodeBlock: Size m_function{Exprs,Decls} to fit from creation. - - - Reviewed by Anders Carlsson. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - - Use resizeToFit() instead of grow() for m_functionExprs and - m_functionDecls since we know they will never change size. - - (JSC::CodeBlock::shrinkToFit): - - No need to shrink them here anymore. - -2014-01-18 Andreas Kling - - Remove unused CodeBlock::m_additionalIdentifiers member. - - - Reviewed by Anders Carlsson. - - * bytecode/CodeBlock.h: - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - (JSC::CodeBlock::shrinkToFit): - - Remove m_additionalIdentifiers, nothing uses it. - -2014-01-18 Andreas Kling - - Remove two unused CodeBlock functions. - - - Kill copyPostParseDataFrom() and copyPostParseDataFromAlternative() - since they are not used. - - Reviewed by Anders Carlsson. - - * bytecode/CodeBlock.cpp: - * bytecode/CodeBlock.h: - -2014-01-18 Andreas Kling - - CodeBlock: Size m_exceptionHandlers to fit from creation. - - - Avoid allocation churn for CodeBlock::m_exceptionHandlers. - - Reviewed by Anders Carlsson. - - * bytecode/CodeBlock.h: - - Removed unused CodeBlock::allocateHandlers() function. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - - Use resizeToFit() instead of grow() for m_exceptionHandlers - since we know it's never going to change size. - - (JSC::CodeBlock::shrinkToFit): - - No need to shrink m_exceptionHandlers here since it's already - the perfect size. - -2014-01-18 Mark Lam - - Add a hasBreakpointFlag arg to the op_debug bytecode. - https://bugs.webkit.org/show_bug.cgi?id=127230. - - Reviewed by Geoffrey Garen. - - This is in anticipation of upcoming changes to support bytecode level - breakpoints. This patch adds the flag to the op_debug bytecode and - initializes it, but does not use it yet. - - * bytecode/Opcode.h: - (JSC::padOpcodeName): - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitDebugHook): - * llint/LowLevelInterpreter.asm: - -2014-01-18 Alberto Garcia - - JavaScriptCore uses PLATFORM(MAC) when it means OS(DARWIN) - https://bugs.webkit.org/show_bug.cgi?id=99683 - - Reviewed by Anders Carlsson. - - * jit/ThunkGenerators.cpp: - * tools/CodeProfile.cpp: - (JSC::symbolName): - (JSC::CodeProfile::sample): - -2014-01-18 Anders Carlsson - - Remove ENABLE_THREADED_HTML_PARSER defines everywhere - https://bugs.webkit.org/show_bug.cgi?id=127225 - - Reviewed by Andreas Kling. - - This concludes the removal of over 8.8 million lines of threaded parser code. - - * Configurations/FeatureDefines.xcconfig: - -2014-01-18 Mark Lam - - Adding UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn().. - https://bugs.webkit.org/show_bug.cgi?id=127127. - - Reviewed by Geoffrey Garen. - - In order to implement bytecode level breakpoints, we need a mechanism - for computing the best fit op_debug bytecode offset for any valid given - line and column value in the source. The "best fit" op_debug bytecode - in this case is defined below in the comment for - UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn(). - - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::opDebugBytecodeOffsetForLineAndColumn): - - Convert the line and column to unlinked line and column values and - pass them to UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn() - to do the real work. - - * bytecode/CodeBlock.h: - * bytecode/LineColumnInfo.h: Added. - (JSC::LineColumnInfo::operator <): - (JSC::LineColumnInfo::LineColumnPair::LineColumnPair): - (JSC::LineColumnInfo::operator ==): - (JSC::LineColumnInfo::operator !=): - (JSC::LineColumnInfo::operator <=): - (JSC::LineColumnInfo::operator >): - (JSC::LineColumnInfo::operator >=): - * bytecode/LineInfo.h: Removed. - - * bytecode/UnlinkedCodeBlock.cpp: - (JSC::UnlinkedCodeBlock::decodeExpressionRangeLineAndColumn): - - Factored this out of expressionRangeForBytecodeOffset() so that it can - be called from multiple places. - (JSC::dumpLineColumnEntry): - (JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo): - (JSC::UnlinkedCodeBlock::dumpOpDebugLineColumnInfoList): - - Some dumpers for debugging use only. - (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset): - (JSC::UnlinkedCodeBlock::opDebugBytecodeOffsetForLineAndColumn): - - Finds the earliest op_debug bytecode whose line and column matches the - specified line and column values. If an exact match is not found, then - finds the nearest op_debug bytecode that precedes the specified line - and column values. If there are more than one op_debug at that preceding - line and column value, then the earliest of those op_debug bytecodes will - be be selected. The offset of the selected bytecode will be returned. - - We want the earliest one because when we have multiple op_debug bytecodes - that map to a given line and column, a debugger user would expect to break - on the first one and step through the rest thereafter if needed. - - (JSC::compareLineColumnInfo): - (JSC::UnlinkedCodeBlock::opDebugLineColumnInfoList): - - Creates the sorted opDebugLineColumnInfoList on demand. This list is - stored in the UnlinkedCodeBlock's rareData. - * bytecode/UnlinkedCodeBlock.h: - -2014-01-18 Zan Dobersek - - Inspector scripts are not compatible with Python v3 - https://bugs.webkit.org/show_bug.cgi?id=127128 - - Reviewed by Benjamin Poulain. - - * inspector/scripts/generate-combined-inspector-json.py: Turn print statements into print function calls. - * inspector/scripts/jsmin.py: Try importing the StringIO class from the StringIO module (which will work for - Python v2) or, on import error, import the class from the io module (which will work for Python v3). - -2014-01-17 Anders Carlsson - - String::is8Bit() crashes if m_impl is null, handle this. - - * API/OpaqueJSString.h: - (OpaqueJSString::OpaqueJSString): - -2014-01-17 Anders Carlsson - - Try to fix the Windows build. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::~OpaqueJSString): - (OpaqueJSString::characters): - * API/OpaqueJSString.h: - (OpaqueJSString::OpaqueJSString): - -2014-01-17 Anders Carlsson - - Get rid of OpaqueJSString::deprecatedCharacters() - https://bugs.webkit.org/show_bug.cgi?id=127161 - - Reviewed by Sam Weinig. - - Handle OpaqueJSString::m_string being either 8-bit or 16-bit and add extra - code paths for the 8-bit cases. - - Unfortunately, JSStringGetCharactersPtr is still expected to return a 16-bit character pointer. - Handle this by storing a separate 16-bit string and initializing it on demand when JSStringGetCharactersPtr - is called and the backing string is 8-bit. - - This has the nice side effect of making JSStringGetCharactersPtr thread-safe when it wasn't before. - (In theory, someone could have a JSStringRef backed by an 8-bit string and call JSStringGetCharactersPtr on it - causing an unsafe upconversion to a 16-bit string). - - * API/JSStringRef.cpp: - (JSStringGetCharactersPtr): - Call OpaqueJSString::characters. - - (JSStringGetUTF8CString): - Add a code path that handles 8-bit strings. - - (JSStringIsEqual): - Call OpaqueJSString::equal. - - * API/JSStringRefCF.cpp: - (JSStringCreateWithCFString): - Reformat the code to use an early return instead of putting most of the code inside the body of an if statement. - - (JSStringCopyCFString): - Create an 8-bit CFStringRef if possible. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::create): - Use nullptr. - - (OpaqueJSString::~OpaqueJSString): - Free m_characters. - - (OpaqueJSString::characters): - Do the up-conversion and store the result in m_characters. - - (OpaqueJSString::equal): - New helper function. - - * API/OpaqueJSString.h: - (OpaqueJSString::is8Bit): - New function that returns whether a string is 8-bit or not. - - (OpaqueJSString::characters8): - (OpaqueJSString::characters16): - Add getters. - -2014-01-17 Peter Molnar - - Remove workaround for compilers not supporting deleted functions - https://bugs.webkit.org/show_bug.cgi?id=127166 - - Reviewed by Andreas Kling. - - * inspector/InspectorAgentRegistry.h: - -2014-01-17 Commit Queue - - Unreviewed, rolling out r162185, r162186, and r162187. - http://trac.webkit.org/changeset/162185 - http://trac.webkit.org/changeset/162186 - http://trac.webkit.org/changeset/162187 - https://bugs.webkit.org/show_bug.cgi?id=127164 - - Broke JSStringCreateWithCharactersNoCopy, as evidenced by a - JSC API test (Requested by ap on #webkit). - - * API/JSStringRef.cpp: - (JSStringGetCharactersPtr): - (JSStringGetUTF8CString): - (JSStringIsEqual): - * API/JSStringRefCF.cpp: - (JSStringCreateWithCFString): - (JSStringCopyCFString): - * API/OpaqueJSString.cpp: - (OpaqueJSString::create): - (OpaqueJSString::identifier): - * API/OpaqueJSString.h: - (OpaqueJSString::create): - (OpaqueJSString::characters): - (OpaqueJSString::deprecatedCharacters): - (OpaqueJSString::OpaqueJSString): - -2014-01-16 Anders Carlsson - - Export OpaqueJSString destructor. - - * API/OpaqueJSString.h: - -2014-01-16 Anders Carlsson - - Build fix. - - * API/OpaqueJSString.h: - -2014-01-16 Anders Carlsson - - Get rid of OpaqueJSString::deprecatedCharacters() - https://bugs.webkit.org/show_bug.cgi?id=127161 - - Reviewed by Sam Weinig. - - Handle OpaqueJSString::m_string being either 8-bit or 16-bit and add extra - code paths for the 8-bit cases. - - Unfortunately, JSStringGetCharactersPtr is still expected to return a 16-bit character pointer. - Handle this by storing a separate 16-bit string and initializing it on demand when JSStringGetCharactersPtr - is called. This has the nice side effect of making JSStringGetCharactersPtr thread-safe when it wasn't before. - (In theory, someone could have a JSStringRef backed by an 8-bit string and call JSStringGetCharactersPtr on it - causing an unsafe upconversion to a 16-bit string). - - * API/JSStringRef.cpp: - (JSStringGetCharactersPtr): - Call OpaqueJSString::characters. - - (JSStringGetUTF8CString): - Add a code path that handles 8-bit strings. - - (JSStringIsEqual): - Call OpaqueJSString::equal. - - * API/JSStringRefCF.cpp: - (JSStringCreateWithCFString): - Reformat the code to use an early return instead of putting most of the code inside the body of an if statement. - - (JSStringCopyCFString): - Create an 8-bit CFStringRef if possible. - - * API/OpaqueJSString.cpp: - (OpaqueJSString::create): - Use nullptr. - - (OpaqueJSString::~OpaqueJSString): - Free m_characters. - - (OpaqueJSString::characters): - Do the up-conversion and store the result in m_characters. - - (OpaqueJSString::equal): - New helper function. - - * API/OpaqueJSString.h: - (OpaqueJSString::is8Bit): - New function that returns whether a string is 8-bit or not. - - (OpaqueJSString::characters8): - (OpaqueJSString::characters16): - Add getters. - -2014-01-16 Anders Carlsson - - Change all uses of FINAL to final now that all our compilers support it - https://bugs.webkit.org/show_bug.cgi?id=127142 - - Reviewed by Benjamin Poulain. - - * inspector/JSGlobalObjectInspectorController.h: - * inspector/agents/InspectorAgent.h: - * inspector/remote/RemoteInspector.h: - * inspector/remote/RemoteInspectorDebuggableConnection.h: - * inspector/scripts/CodeGeneratorInspector.py: - (Generator.go): - * runtime/JSGlobalObjectDebuggable.h: - * runtime/JSPromiseReaction.cpp: - -2014-01-16 Oliver Hunt - - throwing an objc object (or general binding object) triggers an assertion - https://bugs.webkit.org/show_bug.cgi?id=127146 - - Reviewed by Alexey Proskuryakov. - - This is simply a bogus assertion as we can't guarantee a bindings object - won't intercept assignment to .stack - - * interpreter/Interpreter.cpp: - (JSC::Interpreter::unwind): - -2014-01-16 Peter Molnar - - Remove workaround for compilers not supporting explicit override control - https://bugs.webkit.org/show_bug.cgi?id=127111 - - Reviewed by Anders Carlsson. - - Now all compilers support explicit override control, this workaround can be removed. - - * API/JSAPIWrapperObject.mm: - * API/JSCallbackObject.h: - * API/JSManagedValue.mm: - * API/JSScriptRef.cpp: - * bytecode/CodeBlock.h: - * bytecode/CodeBlockJettisoningWatchpoint.h: - * bytecode/ProfiledCodeBlockJettisoningWatchpoint.h: - * bytecode/StructureStubClearingWatchpoint.h: - * dfg/DFGArrayifySlowPathGenerator.h: - * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: - * dfg/DFGFailedFinalizer.h: - * dfg/DFGJITCode.h: - * dfg/DFGJITFinalizer.h: - * dfg/DFGSaneStringGetByValSlowPathGenerator.h: - * dfg/DFGSlowPathGenerator.h: - * dfg/DFGSpeculativeJIT64.cpp: - * heap/Heap.h: - * heap/IncrementalSweeper.h: - * heap/SuperRegion.h: - * inspector/InspectorValues.h: - * inspector/JSGlobalObjectInspectorController.h: - * inspector/agents/InspectorAgent.h: - * inspector/remote/RemoteInspector.h: - * inspector/remote/RemoteInspectorDebuggableConnection.h: - * inspector/scripts/CodeGeneratorInspector.py: - (Generator.go): - * jit/ClosureCallStubRoutine.h: - * jit/ExecutableAllocatorFixedVMPool.cpp: - * jit/GCAwareJITStubRoutine.h: - * jit/JITCode.h: - * jit/JITToDFGDeferredCompilationCallback.h: - * parser/Nodes.h: - * parser/SourceProvider.h: - * runtime/DataView.h: - * runtime/GCActivityCallback.h: - * runtime/GenericTypedArrayView.h: - * runtime/JSGlobalObjectDebuggable.h: - * runtime/JSPromiseReaction.cpp: - * runtime/RegExpCache.h: - * runtime/SimpleTypedArrayController.h: - * runtime/SymbolTable.h: - * runtime/WeakMapData.h: - -2014-01-15 Joseph Pecoraro - - [iOS] Clean up REMOTE_INSPECTOR code in OpenSource after the iOS merge - https://bugs.webkit.org/show_bug.cgi?id=127069 - - Reviewed by Timothy Hatcher. - - * JavaScriptCore.xcodeproj/project.pbxproj: - Export XPCConnection because it is needed by RemoteInspector.h. - - * inspector/remote/RemoteInspectorXPCConnection.h: - * inspector/remote/RemoteInspector.h: - * inspector/remote/RemoteInspector.mm: - (Inspector::RemoteInspector::startDisabled): - (Inspector::RemoteInspector::shared): - Allow RemoteInspector singleton to start disabled. - -2014-01-15 Brian Burg - - Web Inspector: capture probe samples on the backend - https://bugs.webkit.org/show_bug.cgi?id=126668 - - Reviewed by Joseph Pecoraro. - - Add the 'probe' breakpoint action to the protocol. Change the setBreakpoint - commands to return a list of assigned breakpoint action identifiers - Add a type for breakpoint action identifiers. Add an event for sending - captured probe samples to the inspector frontend. - - * inspector/protocol/Debugger.json: - -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 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 peavo@outlook.com - - [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 peavo@outlook.com - - 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 peavo@outlook.com - - 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-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 >::parseUnaryExpression(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 - - Optimize away OR with zero - a common ASM.js pattern. - https://bugs.webkit.org/show_bug.cgi?id=124869 - - Reviewed by Filip Pizlo. - - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - -2013-11-25 Julien Brianceau - - [arm][mips] Fix crash in dfg-arrayify-elimination layout jsc test. - https://bugs.webkit.org/show_bug.cgi?id=124839 - - Reviewed by Michael Saboff. - - In ARM EABI and MIPS, 64-bit values have to be aligned on stack too. - - * jit/CCallHelpers.h: - (JSC::CCallHelpers::setupArgumentsWithExecState): - * jit/JITInlines.h: - (JSC::JIT::callOperation): Add missing EABI_32BIT_DUMMY_ARG. - -2013-11-23 Filip Pizlo - - Fix more fallout from failed attempts at div/mod DFG strength reductions - https://bugs.webkit.org/show_bug.cgi?id=124813 - - Reviewed by Geoffrey Garen. - - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::compileArithMod): - -2013-11-22 Mark Hahnenberg - - JSC Obj-C API should have real documentation - https://bugs.webkit.org/show_bug.cgi?id=124805 - - Reviewed by Geoffrey Garen. - - Massaging the header comments into proper headerdocs. - - * API/JSContext.h: - * API/JSExport.h: - * API/JSManagedValue.h: - * API/JSValue.h: - * API/JSVirtualMachine.h: - -2013-11-22 Filip Pizlo - - CodeBlock::m_numCalleeRegisters shouldn't also mean frame size, frame size needed for exit, or any other unrelated things - https://bugs.webkit.org/show_bug.cgi?id=124793 - - Reviewed by Mark Hahnenberg. - - Now m_numCalleeRegisters always refers to the number of locals that the attached - bytecode uses. It never means anything else. - - For frame size, we now have it lazily computed from m_numCalleeRegisters for the - baseline engines and we have it stored in DFG::CommonData for the optimizing JITs. - - For frame-size-needed-at-exit, we store that in DFG::CommonData, too. - - The code no longer implies that there is any arithmetic relationship between - m_numCalleeRegisters and frameSize. Previously it implied that the latter is greater - than the former. - - The code no longer implies that there is any arithmetic relationship between the - frame Size and the frame-size-needed-at-exit. Previously it implied that the latter - is greater that the former. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::frameRegisterCount): - * bytecode/CodeBlock.h: - * dfg/DFGCommonData.h: - (JSC::DFG::CommonData::CommonData): - (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit): - * dfg/DFGGraph.cpp: - (JSC::DFG::Graph::frameRegisterCount): - (JSC::DFG::Graph::requiredRegisterCountForExit): - (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): - * dfg/DFGGraph.h: - * dfg/DFGJITCompiler.cpp: - (JSC::DFG::JITCompiler::link): - (JSC::DFG::JITCompiler::compileFunction): - * dfg/DFGOSREntry.cpp: - (JSC::DFG::prepareOSREntry): - * dfg/DFGSpeculativeJIT.cpp: - (JSC::DFG::SpeculativeJIT::SpeculativeJIT): - * dfg/DFGVirtualRegisterAllocationPhase.cpp: - (JSC::DFG::VirtualRegisterAllocationPhase::run): - * ftl/FTLLink.cpp: - (JSC::FTL::link): - * ftl/FTLLowerDFGToLLVM.cpp: - (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct): - * ftl/FTLOSREntry.cpp: - (JSC::FTL::prepareOSREntry): - * interpreter/CallFrame.cpp: - (JSC::CallFrame::frameExtentInternal): - * interpreter/JSStackInlines.h: - (JSC::JSStack::pushFrame): - * jit/JIT.h: - (JSC::JIT::frameRegisterCountFor): - * jit/JITOperations.cpp: - * llint/LLIntEntrypoint.cpp: - (JSC::LLInt::frameRegisterCountFor): - * llint/LLIntEntrypoint.h: - -2013-11-21 Filip Pizlo - - Combine SymbolTable and SharedSymbolTable - https://bugs.webkit.org/show_bug.cgi?id=124761 - - Reviewed by Geoffrey Garen. - - SymbolTable was never used directly; we now always used SharedSymbolTable. So, this - gets rid of SymbolTable and renames SharedSymbolTable to SymbolTable. - - * bytecode/CodeBlock.h: - (JSC::CodeBlock::symbolTable): - * bytecode/UnlinkedCodeBlock.h: - (JSC::UnlinkedFunctionExecutable::symbolTable): - (JSC::UnlinkedCodeBlock::symbolTable): - (JSC::UnlinkedCodeBlock::finishCreation): - * bytecompiler/BytecodeGenerator.h: - (JSC::BytecodeGenerator::symbolTable): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGStackLayoutPhase.cpp: - (JSC::DFG::StackLayoutPhase::run): - * jit/AssemblyHelpers.h: - (JSC::AssemblyHelpers::symbolTableFor): - * runtime/Arguments.h: - (JSC::Arguments::finishCreation): - * runtime/Executable.h: - (JSC::FunctionExecutable::symbolTable): - * runtime/JSActivation.h: - (JSC::JSActivation::create): - (JSC::JSActivation::JSActivation): - (JSC::JSActivation::registersOffset): - (JSC::JSActivation::allocationSize): - * runtime/JSSymbolTableObject.h: - (JSC::JSSymbolTableObject::symbolTable): - (JSC::JSSymbolTableObject::JSSymbolTableObject): - (JSC::JSSymbolTableObject::finishCreation): - * runtime/JSVariableObject.h: - (JSC::JSVariableObject::JSVariableObject): - * runtime/SymbolTable.cpp: - (JSC::SymbolTable::destroy): - (JSC::SymbolTable::SymbolTable): - * runtime/SymbolTable.h: - (JSC::SymbolTable::create): - (JSC::SymbolTable::createStructure): - * runtime/VM.cpp: - (JSC::VM::VM): - * runtime/VM.h: - -2013-11-22 Mark Lam - - Remove residual references to "dynamicGlobalObject". - https://bugs.webkit.org/show_bug.cgi?id=124787. - - Reviewed by Filip Pizlo. - - * JavaScriptCore.order: - * interpreter/CallFrame.h: - -2013-11-22 Mark Lam - - Ensure that arity fixups honor stack alignment requirements. - https://bugs.webkit.org/show_bug.cgi?id=124756. - - Reviewed by Geoffrey Garen. - - The LLINT and all the JITs rely on CommonSlowPaths::arityCheckFor() to - compute the arg count adjustment for the arity fixup. We take advantage - of this choke point and introduce the stack alignment padding there in - the guise of additional args. - - The only cost of this approach is that the padding will also be - initialized to undefined values as if they were args. Since arity fixups - are considered a slow path that is rarely taken, this cost is not a - concern. - - * runtime/CommonSlowPaths.h: - (JSC::CommonSlowPaths::arityCheckFor): - * runtime/VM.h: - (JSC::VM::isSafeToRecurse): - -2013-11-21 Filip Pizlo - - BytecodeGenerator should align the stack according to native conventions - https://bugs.webkit.org/show_bug.cgi?id=124735 - - Reviewed by Mark Lam. - - Rolling this back in because it actually fixed fast/dom/gc-attribute-node.html, but - our infrastructure misleads peole into thinking that fixing a test constitutes - breaking it. - - * bytecompiler/BytecodeGenerator.h: - (JSC::CallArguments::registerOffset): - (JSC::CallArguments::argumentCountIncludingThis): - * bytecompiler/NodesCodegen.cpp: - (JSC::CallArguments::CallArguments): - -2013-11-21 Filip Pizlo - - Get rid of CodeBlock::dumpStatistics() - https://bugs.webkit.org/show_bug.cgi?id=124762 - - Reviewed by Mark Hahnenberg. - - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - (JSC::CodeBlock::~CodeBlock): - * bytecode/CodeBlock.h: - -2013-11-22 Commit Queue - - Unreviewed, rolling out r159652. - http://trac.webkit.org/changeset/159652 - https://bugs.webkit.org/show_bug.cgi?id=124778 - - broke fast/dom/gc-attribute-node.html (Requested by ap on - #webkit). - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::emitCall): - (JSC::BytecodeGenerator::emitConstruct): - * bytecompiler/BytecodeGenerator.h: - (JSC::CallArguments::registerOffset): - (JSC::CallArguments::argumentCountIncludingThis): - * bytecompiler/NodesCodegen.cpp: - (JSC::CallArguments::CallArguments): - (JSC::CallArguments::newArgument): - -2013-11-21 Filip Pizlo - - Fix a typo (requriements->requirements). - - * runtime/StackAlignment.h: - -2013-11-21 Mark Lam - - CodeBlock::m_numCalleeRegisters need to honor native stack alignment. - https://bugs.webkit.org/show_bug.cgi?id=124754. - - Reviewed by Filip Pizlo. - - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::newRegister): - * dfg/DFGVirtualRegisterAllocationPhase.cpp: - (JSC::DFG::VirtualRegisterAllocationPhase::run): - -2013-11-21 Mark Rowe - - Stop overriding VALID_ARCHS. - - All modern versions of Xcode set it appropriately for our needs. - - Reviewed by Alexey Proskuryakov. - - * Configurations/Base.xcconfig: - -2013-11-21 Mark Rowe - - Fix an error in a few Xcode configuration setting files. - - Reviewed by Alexey Proskuryakov. - - * Configurations/Base.xcconfig: - -2013-11-21 Michael Saboff - - ARM64: Implement push/pop equivalents in LLInt - https://bugs.webkit.org/show_bug.cgi?id=124721 - - Reviewed by Filip Pizlo. - - Added pushLRAndFP and popLRAndFP that push and pop the link register and frame pointer register. - These ops emit code just like what the compiler emits in the prologue and epilogue. Also changed - pushCalleeSaves and popCalleeSaves to use the same store pair and load pair instructions to do - the actually pushing and popping. Finally changed the implementation of push and pop to raise - an exception since we don't have (or need) a single register push or pop. - - * llint/LowLevelInterpreter64.asm: - * offlineasm/arm64.rb: - * offlineasm/instructions.rb: - -2013-11-21 Michael Saboff - - JSC: Removed unused opcodes from offline assembler - https://bugs.webkit.org/show_bug.cgi?id=124749 - - Reviewed by Mark Hahnenberg. - - Removed the unused, X86 only peekq and pokeq. - - * offlineasm/instructions.rb: - * offlineasm/x86.rb: - -2013-11-21 Michael Saboff - - REGRESSION(159395) Fix branch8(…, AbsoluteAddress, …) in ARM64 MacroAssembler - https://bugs.webkit.org/show_bug.cgi?id=124688 - - Reviewed by Geoffrey Garen. - - Changed handling of the address for the load8() in the branch8(AbsoluteAddress) to be like - the rest of the branchXX(AbsoluteAddress) fucntions. - - * assembler/MacroAssemblerARM64.h: - (JSC::MacroAssemblerARM64::branch8): - -2013-11-21 Filip Pizlo - - BytecodeGenerator should align the stack according to native conventions - https://bugs.webkit.org/show_bug.cgi?id=124735 - - Reviewed by Mark Lam. - - * bytecompiler/BytecodeGenerator.h: - (JSC::CallArguments::registerOffset): - (JSC::CallArguments::argumentCountIncludingThis): - * bytecompiler/NodesCodegen.cpp: - (JSC::CallArguments::CallArguments): - -2013-11-21 Filip Pizlo - - Unreviewed, preemptive build fix. - - * runtime/StackAlignment.h: - (JSC::stackAlignmentBytes): - (JSC::stackAlignmentRegisters): - -2013-11-21 Filip Pizlo - - JSC should know what the stack alignment conventions are - https://bugs.webkit.org/show_bug.cgi?id=124736 - - Reviewed by Mark Lam. - - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.xcodeproj/project.pbxproj: - * runtime/StackAlignment.h: Added. - (JSC::stackAlignmentBytes): - (JSC::stackAlignmentRegisters): - -2013-11-21 Balazs Kilvady - - [MIPS] Build fails since r159545. - https://bugs.webkit.org/show_bug.cgi?id=124716 - - Reviewed by Michael Saboff. - - Add missing implementations in MacroAssembler and LLInt for MIPS. - - * assembler/MIPSAssembler.h: - (JSC::MIPSAssembler::sync): - * assembler/MacroAssemblerMIPS.h: - (JSC::MacroAssemblerMIPS::store8): - (JSC::MacroAssemblerMIPS::memoryFence): - * offlineasm/mips.rb: - -2013-11-21 Julien Brianceau - - Fix sh4 build after r159545. - https://bugs.webkit.org/show_bug.cgi?id=124713 - - Reviewed by Michael Saboff. - - Add missing implementations in macro assembler and LLINT for sh4. - - * assembler/MacroAssemblerSH4.h: - (JSC::MacroAssemblerSH4::load8): - (JSC::MacroAssemblerSH4::store8): - (JSC::MacroAssemblerSH4::memoryFence): - * assembler/SH4Assembler.h: - (JSC::SH4Assembler::synco): - * offlineasm/sh4.rb: Handle "memfence" opcode. - -2013-11-20 Mark Lam - - Introducing VMEntryScope to update the VM stack limit. - https://bugs.webkit.org/show_bug.cgi?id=124634. - - Reviewed by Geoffrey Garen. - - 1. Introduced USE(SEPARATE_C_AND_JS_STACK) (defined in Platform.h). - Currently, it is hardcoded to use separate C and JS stacks. Once we - switch to using the C stack for JS frames, we'll need to fix this to - only be enabled when ENABLE(LLINT_C_LOOP). - - 2. Stack limits are now tracked in the VM. - - Logically, there are 2 stack limits: - a. m_stackLimit for the native C stack, and - b. m_jsStackLimit for the JS stack. - - If USE(SEPARATE_C_AND_JS_STACK), then the 2 limits are the same - value, and are implemented as 2 fields in a union. - - 3. The VM native stackLimit is set as follows: - a. Initially, the VM sets it to the limit of the stack of the thread that - instantiated the VM. This allows the parser and bytecode generator to - run before we enter the VM to execute JS code. - - b. Upon entry into the VM to execute JS code (via one of the - Interpreter::execute...() functions), we instantiate a VMEntryScope - that sets the VM's stackLimit to the limit of the current thread's - stack. The VMEntryScope will automatically restore the previous - entryScope and stack limit upon destruction. - - If USE(SEPARATE_C_AND_JS_STACK), the JSStack's methods will set the VM's - jsStackLimit whenever it grows or shrinks. - - 4. The VM now provides a isSafeToRecurse() function that compares the - current stack pointer against its native stackLimit. This subsumes and - obsoletes the VMStackBounds class. - - 5. The VMEntryScope class also subsumes DynamicGlobalObjectScope for - tracking the JSGlobalObject that we last entered the VM with. - - 6. Renamed dynamicGlobalObject() to vmEntryGlobalObject() since that is - the value that the function retrieves. - - 7. Changed JIT and LLINT code to do stack checks against the jsStackLimit - in the VM class instead of the JSStack. - - * API/JSBase.cpp: - (JSEvaluateScript): - (JSCheckScriptSyntax): - * API/JSContextRef.cpp: - (JSGlobalContextRetain): - (JSGlobalContextRelease): - * CMakeLists.txt: - * GNUmakefile.list.am: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: - * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: - * JavaScriptCore.xcodeproj/project.pbxproj: - * bytecompiler/BytecodeGenerator.cpp: - (JSC::BytecodeGenerator::BytecodeGenerator): - * bytecompiler/BytecodeGenerator.h: - (JSC::BytecodeGenerator::emitNode): - (JSC::BytecodeGenerator::emitNodeInConditionContext): - * debugger/Debugger.cpp: - (JSC::Debugger::detach): - (JSC::Debugger::recompileAllJSFunctions): - (JSC::Debugger::pauseIfNeeded): - * debugger/DebuggerCallFrame.cpp: - (JSC::DebuggerCallFrame::vmEntryGlobalObject): - * debugger/DebuggerCallFrame.h: - * dfg/DFGJITCompiler.cpp: - (JSC::DFG::JITCompiler::compileFunction): - * dfg/DFGOSREntry.cpp: - * ftl/FTLLink.cpp: - (JSC::FTL::link): - * ftl/FTLOSREntry.cpp: - * heap/Heap.cpp: - (JSC::Heap::lastChanceToFinalize): - (JSC::Heap::deleteAllCompiledCode): - * interpreter/CachedCall.h: - (JSC::CachedCall::CachedCall): - * interpreter/CallFrame.cpp: - (JSC::CallFrame::vmEntryGlobalObject): - * interpreter/CallFrame.h: - * interpreter/Interpreter.cpp: - (JSC::unwindCallFrame): - (JSC::Interpreter::unwind): - (JSC::Interpreter::execute): - (JSC::Interpreter::executeCall): - (JSC::Interpreter::executeConstruct): - (JSC::Interpreter::prepareForRepeatCall): - (JSC::Interpreter::debug): - * interpreter/JSStack.cpp: - (JSC::JSStack::JSStack): - (JSC::JSStack::growSlowCase): - * interpreter/JSStack.h: - * interpreter/JSStackInlines.h: - (JSC::JSStack::shrink): - (JSC::JSStack::grow): - - Moved these inlined functions here from JSStack.h. It reduces some - #include dependencies of JSSTack.h which had previously resulted - in some EWS bots' unhappiness with this patch. - (JSC::JSStack::updateStackLimit): - * jit/JIT.cpp: - (JSC::JIT::privateCompile): - * jit/JITCall.cpp: - (JSC::JIT::compileLoadVarargs): - * jit/JITCall32_64.cpp: - (JSC::JIT::compileLoadVarargs): - * jit/JITOperations.cpp: - * llint/LLIntSlowPaths.cpp: - * llint/LowLevelInterpreter.asm: - * parser/Parser.cpp: - (JSC::::Parser): - * parser/Parser.h: - (JSC::Parser::canRecurse): - * runtime/CommonSlowPaths.h: - * runtime/Completion.cpp: - (JSC::evaluate): - * runtime/FunctionConstructor.cpp: - (JSC::constructFunctionSkippingEvalEnabledCheck): - * runtime/JSGlobalObject.cpp: - * runtime/JSGlobalObject.h: - * runtime/StringRecursionChecker.h: - (JSC::StringRecursionChecker::performCheck): - * runtime/VM.cpp: - (JSC::VM::VM): - (JSC::VM::releaseExecutableMemory): - (JSC::VM::throwException): - * runtime/VM.h: - (JSC::VM::addressOfJSStackLimit): - (JSC::VM::jsStackLimit): - (JSC::VM::setJSStackLimit): - (JSC::VM::stackLimit): - (JSC::VM::setStackLimit): - (JSC::VM::isSafeToRecurse): - * runtime/VMEntryScope.cpp: Added. - (JSC::VMEntryScope::VMEntryScope): - (JSC::VMEntryScope::~VMEntryScope): - (JSC::VMEntryScope::requiredCapacity): - * runtime/VMEntryScope.h: Added. - (JSC::VMEntryScope::globalObject): - * runtime/VMStackBounds.h: Removed. - -2013-11-20 Michael Saboff - - [Win] JavaScript JIT crash (with DFG enabled). - https://bugs.webkit.org/show_bug.cgi?id=124675 - - Reviewed by Geoffrey Garen. - - Similar to the change in r159427, changed linkClosureCall to use regT0/regT1 (payload/tag) for the callee. - linkForThunkGenerator already expected the callee in regT0/regT1, but changed the comment to reflect that. - - * jit/Repatch.cpp: - (JSC::linkClosureCall): - * jit/ThunkGenerators.cpp: - (JSC::linkForThunkGenerator): - -2013-11-20 Michael Saboff - - ARMv7: Crash due to use after free of AssemblerBuffer - https://bugs.webkit.org/show_bug.cgi?id=124611 - - Reviewed by Geoffrey Garen. - - Changed JITFinalizer constructor to take a MacroAssemblerCodePtr instead of a Label. - In finalizeFunction(), we use that value instead of calculating it from the label. - - * assembler/MacroAssembler.cpp: - * dfg/DFGJITFinalizer.cpp: - (JSC::DFG::JITFinalizer::JITFinalizer): - (JSC::DFG::JITFinalizer::finalizeFunction): - * dfg/DFGJITFinalizer.h: - -2013-11-20 Julien Brianceau - - Fix CPU(ARM_TRADITIONAL) build after r159545. - https://bugs.webkit.org/show_bug.cgi?id=124649 - - Reviewed by Michael Saboff. - - Add missing memoryFence, load8 and store8 implementations in macro assembler. - - * assembler/ARMAssembler.h: - (JSC::ARMAssembler::dmbSY): - * assembler/MacroAssemblerARM.h: - (JSC::MacroAssemblerARM::load8): - (JSC::MacroAssemblerARM::store8): - (JSC::MacroAssemblerARM::memoryFence): - -2013-11-20 Julien Brianceau - - [armv7][arm64] Speculative build fix after r159545. - https://bugs.webkit.org/show_bug.cgi?id=124646 - - Reviewed by Filip Pizlo. - - * assembler/ARMv7Assembler.h: - * assembler/MacroAssemblerARM64.h: - (JSC::MacroAssemblerARM64::memoryFence): - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::memoryFence): - -2013-11-19 Ryosuke Niwa - - Enable HTMLTemplateElement on Mac port - https://bugs.webkit.org/show_bug.cgi?id=124637 - - Reviewed by Tim Horton. - - * Configurations/FeatureDefines.xcconfig: - -2013-11-19 Filip Pizlo - - Unreviewed, remove completely bogus assertion. - - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::addFunction): - -2013-11-19 Filip Pizlo - - Unreviewed, debug build fix. - - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::addFunction): - -2013-11-19 Filip Pizlo - - Infer constant global variables - https://bugs.webkit.org/show_bug.cgi?id=124464 - - Reviewed by Sam Weinig. - - All global variables that are candidates for watchpoint-based constant inference (i.e. - not 'const' variables) will now have WatchpointSet's associated with them and those - are used to drive the inference by tracking three states of each variable: - - Uninitialized: the variable's value is Undefined and the WatchpointSet state is - ClearWatchpoint. - - Initialized: the variable's value was set to something (could even be explicitly set - to Undefined) and the WatchpointSet state is IsWatching. - - Invalidated: the variable's value was set to something else (could even be the same - thing as before but the point is that a put operation did execute again) and the - WatchpointSet is IsInvalidated. - - If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is - IsWatching, then the current value of the variable can be folded in place of the get, - and a watchpoint on the variable can be registered. - - We handle race conditions between the mutator and compiler by mandating that: - - - The mutator changes the WatchpointSet state after executing the put. - - - There is no opportunity to install code or call functions between when the mutator - executes a put and changes the WatchpointSet state. - - - The compiler checks the WatchpointSet state prior to reading the value. - - The concrete algorithm used by the mutator is: - - 1. Store the new value into the variable. - --- Execute a store-store fence. - 2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes - IsInvalidated); the IsWatching->IsInvalidated transition may end up firing - watchpoints. - - The concrete algorithm that the compiler uses is: - - 1. Load the state. If it's *not* IsWatching, then give up on constant inference. - --- Execute a load-load fence. - 2. Load the value of the variable and use that for folding, while also registering - a DesiredWatchpoint. The various parts of this step can be done in any order. - - The desired watchpoint registration will fail if the watchpoint set is already - invalidated. Now consider the following interesting interleavings: - - Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store - operation, and the variable is folded. The fencing ensures that C2 sees the value - stored in M1 - i.e. we fold on the value that will actually be watchpointed. If - before the compilation is installed the mutator executes another store then we - will be sure that it will be a complete sequence of M1+M2 since compilations get - installed at safepoints and never "in the middle" of a put_to_scope. Hence that - compilation installation will be invalidated. If the M1+M2 sequence happens after - the code is installed, then the code will be invalidated by triggering a jettison. - - Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is - a sensible outcome since if the compiler read the variable's value, it would have - seen Undefined. - - Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold. - Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold. - Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold. - Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold. - - IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold. - - IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired - watchpoint, and that watchpoint will get invalidated before the code is installed. - - IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated. - IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated. - IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated. - IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated. - - Note that this kind of reasoning shows why having the mutator first bump the state and - then store the new value would be wrong. If we had done that (M1 = bump state, M2 = - execute put) then we could have the following deadly interleavings: - - Uninitialized->M1->C1->C2->M2: - Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the - compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the - watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a - value other than Undefined, and you're toast. - - You could fix this sort of thing by making the Desired Watchpoints machinery more - sophisticated, for example having it track the value that was folded; if the global - variable's value was later found to be different then we could invalidate the - compilation. You could also fix it by having the compiler also check that the value of - the variable is not Undefined before folding. While those all sound great, I decided - to instead just use the right interleaving since that results in less code and feels - more intuitive. - - This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic. - It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is - because 3d-cube takes global variable assignment slow paths very often. Note that this - 3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is - also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue - (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due - to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the - slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS - programming often leads to global-var-based idioms and those variables tend to be - assigned once, leading to excellent constant folding opportunities in an optimizing - JIT. This is very evident in the speed-ups on JSRegress. - - * assembler/ARM64Assembler.h: - (JSC::ARM64Assembler::dmbSY): - * assembler/ARMv7Assembler.h: - (JSC::ARMv7Assembler::dmbSY): - * assembler/MacroAssemblerARM64.h: - (JSC::MacroAssemblerARM64::memfence): - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::load8): - (JSC::MacroAssemblerARMv7::memfence): - * assembler/MacroAssemblerX86.h: - (JSC::MacroAssemblerX86::load8): - (JSC::MacroAssemblerX86::store8): - * assembler/MacroAssemblerX86Common.h: - (JSC::MacroAssemblerX86Common::getUnusedRegister): - (JSC::MacroAssemblerX86Common::store8): - (JSC::MacroAssemblerX86Common::memoryFence): - * assembler/MacroAssemblerX86_64.h: - (JSC::MacroAssemblerX86_64::load8): - (JSC::MacroAssemblerX86_64::store8): - * assembler/X86Assembler.h: - (JSC::X86Assembler::movb_rm): - (JSC::X86Assembler::movzbl_mr): - (JSC::X86Assembler::mfence): - (JSC::X86Assembler::X86InstructionFormatter::threeByteOp): - (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8): - * bytecode/CodeBlock.cpp: - (JSC::CodeBlock::CodeBlock): - * bytecode/Watchpoint.cpp: - (JSC::WatchpointSet::WatchpointSet): - (JSC::WatchpointSet::add): - (JSC::WatchpointSet::notifyWriteSlow): - * bytecode/Watchpoint.h: - (JSC::WatchpointSet::state): - (JSC::WatchpointSet::isStillValid): - (JSC::WatchpointSet::addressOfSetIsNotEmpty): - * dfg/DFGAbstractInterpreterInlines.h: - (JSC::DFG::::executeEffects): - * dfg/DFGByteCodeParser.cpp: - (JSC::DFG::ByteCodeParser::getJSConstantForValue): - (JSC::DFG::ByteCodeParser::getJSConstant): - (JSC::DFG::ByteCodeParser::parseBlock): - * dfg/DFGClobberize.h: - (JSC::DFG::clobberize): - * dfg/DFGFixupPhase.cpp: - (JSC::DFG::FixupPhase::fixupNode): - * dfg/DFGNode.h: - (JSC::DFG::Node::isStronglyProvedConstantIn): - (JSC::DFG::Node::hasIdentifierNumberForCheck): - (JSC::DFG::Node::hasRegisterPointer): - * dfg/DFGNodeFlags.h: - * 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::compileNotifyPutGlobalVar): - * dfg/DFGSpeculativeJIT.h: - (JSC::DFG::SpeculativeJIT::callOperation): - * dfg/DFGSpeculativeJIT32_64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * dfg/DFGSpeculativeJIT64.cpp: - (JSC::DFG::SpeculativeJIT::compile): - * ftl/FTLAbbreviatedTypes.h: - * ftl/FTLAbbreviations.h: - (JSC::FTL::buildFence): - * ftl/FTLCapabilities.cpp: - (JSC::FTL::canCompile): - * ftl/FTLIntrinsicRepository.h: - * ftl/FTLLowerDFGToLLVM.cpp: - (JSC::FTL::LowerDFGToLLVM::compileNode): - (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar): - * ftl/FTLOutput.h: - (JSC::FTL::Output::fence): - * jit/JIT.h: - * jit/JITOperations.h: - * jit/JITPropertyAccess.cpp: - (JSC::JIT::emitPutGlobalVar): - (JSC::JIT::emit_op_put_to_scope): - (JSC::JIT::emitSlow_op_put_to_scope): - * jit/JITPropertyAccess32_64.cpp: - (JSC::JIT::emitPutGlobalVar): - (JSC::JIT::emit_op_put_to_scope): - (JSC::JIT::emitSlow_op_put_to_scope): - * llint/LowLevelInterpreter32_64.asm: - * llint/LowLevelInterpreter64.asm: - * llvm/LLVMAPIFunctions.h: - * offlineasm/arm.rb: - * offlineasm/arm64.rb: - * offlineasm/cloop.rb: - * offlineasm/instructions.rb: - * offlineasm/x86.rb: - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::addGlobalVar): - (JSC::JSGlobalObject::addFunction): - * runtime/JSGlobalObject.h: - (JSC::JSGlobalObject::addVar): - (JSC::JSGlobalObject::addConst): - * runtime/JSScope.cpp: - (JSC::abstractAccess): - * runtime/JSSymbolTableObject.h: - (JSC::symbolTablePut): - (JSC::symbolTablePutWithAttributes): - * runtime/SymbolTable.cpp: - (JSC::SymbolTableEntry::couldBeWatched): - (JSC::SymbolTableEntry::prepareToWatch): - (JSC::SymbolTableEntry::notifyWriteSlow): - * runtime/SymbolTable.h: - -2013-11-19 Michael Saboff - - REGRESSION(158384) ARMv7 point checks too restrictive for native calls to traditional ARM code - https://bugs.webkit.org/show_bug.cgi?id=124612 - - Reviewed by Geoffrey Garen. - - Removed ASSERT checks (i.e. lower bit set) for ARM Thumb2 destination addresses related to - calls since we are calling native ARM traditional functions like sin() and cos(). - - * assembler/ARMv7Assembler.h: - (JSC::ARMv7Assembler::linkCall): - (JSC::ARMv7Assembler::relinkCall): - * assembler/MacroAssemblerCodeRef.h: - -2013-11-19 Commit Queue - - Unreviewed, rolling out r159459. - http://trac.webkit.org/changeset/159459 - https://bugs.webkit.org/show_bug.cgi?id=124616 - - tons of assertions on launch (Requested by thorton on - #webkit). - - * API/JSContext.mm: - (-[JSContext setException:]): - (-[JSContext wrapperForObjCObject:]): - (-[JSContext wrapperForJSObject:]): - * API/JSContextRef.cpp: - (JSContextGroupRelease): - (JSGlobalContextRelease): - * API/JSManagedValue.mm: - (-[JSManagedValue initWithValue:]): - (-[JSManagedValue value]): - * API/JSObjectRef.cpp: - (JSObjectIsFunction): - (JSObjectCopyPropertyNames): - * API/JSValue.mm: - (containerValueToObject): - * API/JSWrapperMap.mm: - (tryUnwrapObjcObject): - -2013-11-19 Filip Pizlo - - Rename WatchpointSet::notifyWrite() should be renamed to WatchpointSet::fireAll() - https://bugs.webkit.org/show_bug.cgi?id=124609 - - Rubber stamped by Mark Lam. - - notifyWrite() is a thing that SymbolTable does. WatchpointSet uses that terminology - because it was original designed to match exactly SymbolTable's semantics. But now - it's a confusing term. - - * bytecode/Watchpoint.cpp: - (JSC::WatchpointSet::fireAllSlow): - * bytecode/Watchpoint.h: - (JSC::WatchpointSet::fireAll): - (JSC::InlineWatchpointSet::fireAll): - * interpreter/Interpreter.cpp: - (JSC::Interpreter::execute): - * runtime/JSFunction.cpp: - (JSC::JSFunction::put): - (JSC::JSFunction::defineOwnProperty): - * runtime/JSGlobalObject.cpp: - (JSC::JSGlobalObject::haveABadTime): - * runtime/Structure.h: - (JSC::Structure::notifyTransitionFromThisStructure): - * runtime/SymbolTable.cpp: - (JSC::SymbolTableEntry::notifyWriteSlow): - -2013-11-18 Michael Saboff - - REGRESSION (r159395): Error compiling for ARMv7 - https://bugs.webkit.org/show_bug.cgi?id=124552 - - Reviewed by Geoffrey Garen. - - Fixed the implementation of branch8(RelationalCondition cond, AbsoluteAddress address, TrustedImm32 right) - to materialize and use address similar to other ARMv7 branchXX() functions. - - * assembler/MacroAssemblerARMv7.h: - (JSC::MacroAssemblerARMv7::branch8): - -2013-11-19 Mark Lam - - Add tracking of endColumn for Executables. - https://bugs.webkit.org/show_bug.cgi?id=124245. - - Reviewed by Geoffrey Garen. - - 1. Fixed computation of columns to take into account the startColumn from -