--- /dev/null
+2015-07-20 Matthew Hanson <matthew_hanson@apple.com>
+
+ Merge r186819. rdar://problem/21729083
+
+ 2015-07-14 Matthew Mirman <mmirman@apple.com>
+
+ Repatch. Makes compileArithSub in the DFG ensure that the constant is an int32.
+ https://bugs.webkit.org/show_bug.cgi?id=146910
+ rdar://problem/21729083
+
+ Reviewed by Filip Pizlo.
+
+ Also fixes the debug build problem where all edges are assumed to
+ have UntypedUse before the fixup phase.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithSub):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateEdgeWithDoubleResultIfNecessary):
+ * tests/stress/arith-add-with-constants.js: Added some tests for this case.
+ (arithAdd42WrittenAsInteger):
+ (testArithAdd42WrittenAsInteger):
+ (arithSub42WrittenAsDouble):
+ (testArithSub42WrittenAsDouble):
+ (doubleConstant):
+ (testDoubleConstant): Added test for the case of +0.0 and Math.min(0.0)
+ (arithAdd42WrittenAsDouble): Deleted.
+ (testArithAdd42WrittenAsDouble): Deleted.
+
+2015-07-20 Matthew Hanson <matthew_hanson@apple.com>
+
+ Merge r187028. rdar://problem/21869970
+
+ 2015-07-18 Filip Pizlo <fpizlo@apple.com>
+
+ REGRESSION(186691): OSR entry is broken on loop headers that have no live variables
+ https://bugs.webkit.org/show_bug.cgi?id=147074
+ rdar://problem/21869970
+
+ Reviewed by Michael Saboff.
+
+ The OSR entry must-handle block/value widening introduced in r186691 would cause the
+ CFA to reexecute if it caused any live local variables to change value. But this fails
+ if the must-handle block has no live local variables, and the entry block otherwise
+ appears to be unreachable.
+
+ This fixes the bug by having the change detection include whether the block hadn't been
+ visited in addition to whether any local variable values got widened.
+
+ This is a ~4% speed-up on SunSpider in browser.
+
+ * dfg/DFGCFAPhase.cpp:
+ (JSC::DFG::CFAPhase::run):
+
+2015-07-16 Matthew Hanson <matthew_hanson@apple.com>
+
+ Merge r186920. rdar://problem/21764196
+
+ 2015-07-16 Mark Lam <mark.lam@apple.com>
+
+ RegExp::match() should set m_state to ByteCode if compilation fails.
+ https://bugs.webkit.org/show_bug.cgi?id=147023
+
+ Reviewed by Michael Saboff.
+
+ A RegExp has a YarrCodeBlock that has 4 MacroAssemblerCodeRefs for compiled code.
+ If one of these compilations succeeds, RegExp::m_state will be set to JITCode.
+ Subsequently, if RegExp tries to compile another one of these but fails, m_state
+ will be left untouched i.e. it still says JITCode. As a result, when
+ RegExp::match() later tries to execute the non-existant compiled code, it will
+ crash.
+
+ The fix is to downgrade m_state to ByteCode if RegExp ever fails to compile.
+ This failure should be rare. We'll do the minimal work here to fix the issue and
+ keep an eye on the perf bots. If perf regresses, we can do some optimization work then.
+
+ This issue is difficult to test for since it either requires a low memory condition
+ to trigger a failed RegExp compilation at the right moment, or for the RegExp to
+ succeed compilation in the MatchedOnly mode but fail in IncludeSubpatterns mode.
+ Instead, I manually tested it by instrumenting RegExp::compile() to fail once in every
+ 10 compilation attempts.
+
+ * runtime/RegExp.cpp:
+ (JSC::RegExp::compile):
+ (JSC::RegExp::compileMatchOnly):
+
+2015-07-15 Lucas Forschler <lforschler@apple.com>
+
+ Merge r186826
+
+ 2015-07-14 Anders Carlsson <andersca@apple.com>
+
+ Assertions.h should include ExportMacros.h
+ https://bugs.webkit.org/show_bug.cgi?id=146948
+
+ Reviewed by Tim Horton.
+
+ Remove now unneeded WTF_EXPORT_PRIVATE define.
+
+ * API/JSBase.h:
+
+2015-07-13 Babak Shafiei <bshafiei@apple.com>
+
+ Merge r186777.
+
+ 2015-07-13 Anders Carlsson <andersca@apple.com>
+
+ Apps linked with a deployment target of iOS 7.x or earlier crash when using modern WebKit API
+ https://bugs.webkit.org/show_bug.cgi?id=146913
+ rdar://problem/21789252
+
+ Reviewed by Dan Bernstein.
+
+ Make a top-level symlink from /System/Library/PrivateFrameworks/JavaScriptCore.framework to
+ /System/Library/Frameworks/JavaScriptCore.framework.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-07-12 Babak Shafiei <bshafiei@apple.com>
+
+ Merge r186702.
+
+ 2015-07-10 Filip Pizlo <fpizlo@apple.com>
+
+ AI folding of IsObjectOrNull is broken for non-object types that may be null
+ https://bugs.webkit.org/show_bug.cgi?id=146867
+
+ Reviewed by Ryosuke Niwa.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Fix the bug and add some text describing what is going on.
+ * tests/stress/misc-is-object-or-null.js: Added. Test for the bug.
+ (foo):
+ * tests/stress/other-is-object-or-null.js: Added. Test for a bug I almost introduced.
+ (foo):
+
+2015-07-12 Babak Shafiei <bshafiei@apple.com>
+
+ Merge r186691.
+
+ 2015-07-04 Filip Pizlo <fpizlo@apple.com>
+
+ DFG fragile frozen values are fundamentally broken
+ https://bugs.webkit.org/show_bug.cgi?id=146602
+
+ Reviewed by Mark Lam.
+
+ This change gets rid of the FragileValue value strength, because it was fundamentally
+ broken.
+
+ FragileValue was a value known to the compiler but not tracked by the GC in any way -
+ it wasn't marked and it wasn't weak. This was used to support AI bootstrap for OSR
+ must-handle values. The philosophy was that if the compiler did use the value for
+ optimization, it would have been strengthened to a weak value (or maybe even a strong
+ value, though we probably won't do that). But this was too much of a pipe dream. I've
+ found at least one case where the compiler did use the value, but never strengthened
+ it: it would happen if the value ended up in an OSR entry data expected value. Then if
+ we GCed, we might have killed the value, but OSR entry would still try to use it for
+ validation. That might have sort of just worked, but it's clearly shady.
+
+ The reason why we made must-handle values fragile and not weak is that most of the time
+ the values disappear from the abstract state: they are LUBed to a non-constant. If we
+ kept them around as weak, we'd have too many cases of the GC killing the code because
+ it thought that the value was somehow meaningful to the code when it was only used as a
+ temporary artifact of optimization.
+
+ So, it's true that it's very important for must-handle values not to automatically be
+ weak or strong. It's also true that the values are necessary for AI bootstrap because
+ we need to know what values OSR entry will require. But we shouldn't accomplish these
+ goals by having the compiler hold onto what are essentially dangling pointers.
+
+ This implements a better solution: instead of having InPlaceAbstractState bootstrap the
+ AI with must-handle values at the beginning, we now widen the valuesAtHead of the
+ must-handle block after AI converges. This widening is done in CFAPhase. This allows us
+ to see if the must-handle values are necessary at all. In most cases, the widening
+ takes a non-constant abstract value and simply amends something to its type based on
+ the type of the must-handle value, and so the must-handle value never actually shows up
+ in either the IR or any abstract value. In the unlikely event that the value at head is
+ bottom, we freeze the must-handle value. This change removes FragileValue, and this
+ freezing uses WeakValue as the strength. That makes sense: since the abstract value was
+ bottom, the must-handle value becomes integral to the IR and so it makes no sense for
+ the GC to keep the resulting CodeBlock alive if that must-handle value dies. This will
+ sometimes happen for example if you have a very long-running loop whose pre-header
+ allocates some object, but that pre-header appears to always exit to the optimizing JIT
+ because it was only profiled once in the LLInt and that profiling appears insufficient
+ to the DFG. In that case, we'll effectively constant-fold the references to the object
+ inside the loop, which is both efficient (yay constant folding!) and necessary
+ (otherwise we wouldn't know what the type of the variable should have been).
+
+ Testing and debugging this is complicated. So, this adds some new capabilities:
+
+ - DFG IR dumps also dump all of the FrozenValues that point to the heap along with
+ their strengths, so that it's easy to see what GC objects the DFG feels are necessary
+ for the compilation.
+
+ - DFG OSR entry preparation prints out the OSR entry data structures, so that it's easy
+ to see what GC pointers (and other things) are used for OSR entry validation. The
+ printouts are quite detailed, and should also help other kinds of OSR entry
+ debugging.
+
+ - DFG::Plan now validates whether all of the GC pointers planted in the various JITCode
+ data structures are also properly registered as either weak or strong pointers in the
+ CodeBlock. This validation check previously failed due to fragile values ending up in
+ the OSR entry data structures, both in the newly added test (dead-osr-entry-value.js)
+ and in some pre-existing tests (like earley-boyer and 3d-raytrace).
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::stronglyVisitStrongReferences):
+ * bytecode/CodeOrigin.cpp:
+ (JSC::InlineCallFrame::visitAggregate):
+ * bytecode/Operands.h:
+ (JSC::Operands::operand):
+ (JSC::Operands::hasOperand):
+ * bytecode/StructureSet.cpp:
+ (JSC::StructureSet::dump):
+ (JSC::StructureSet::validateReferences):
+ * bytecode/StructureSet.h:
+ * bytecode/TrackedReferences.cpp: Added.
+ (JSC::TrackedReferences::TrackedReferences):
+ (JSC::TrackedReferences::~TrackedReferences):
+ (JSC::TrackedReferences::add):
+ (JSC::TrackedReferences::check):
+ (JSC::TrackedReferences::dump):
+ * bytecode/TrackedReferences.h: Added.
+ * dfg/DFGAbstractValue.cpp:
+ (JSC::DFG::AbstractValue::observeTransitions):
+ (JSC::DFG::AbstractValue::set):
+ (JSC::DFG::AbstractValue::fixTypeForRepresentation):
+ (JSC::DFG::AbstractValue::mergeOSREntryValue):
+ (JSC::DFG::AbstractValue::filter):
+ (JSC::DFG::AbstractValue::dumpInContext):
+ (JSC::DFG::AbstractValue::validateReferences):
+ (JSC::DFG::AbstractValue::setOSREntryValue): Deleted.
+ * dfg/DFGAbstractValue.h:
+ (JSC::DFG::AbstractValue::fullTop):
+ (JSC::DFG::AbstractValue::merge):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
+ * dfg/DFGCFAPhase.cpp:
+ (JSC::DFG::CFAPhase::run):
+ * dfg/DFGCommonData.cpp:
+ (JSC::DFG::CommonData::invalidate):
+ (JSC::DFG::CommonData::validateReferences):
+ * dfg/DFGCommonData.h:
+ (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
+ * dfg/DFGFrozenValue.h:
+ (JSC::DFG::FrozenValue::FrozenValue):
+ (JSC::DFG::FrozenValue::strengthenTo):
+ (JSC::DFG::FrozenValue::pointsToHeap):
+ (JSC::DFG::FrozenValue::strength):
+ (JSC::DFG::FrozenValue::freeze):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::Graph):
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::registerFrozenValues):
+ (JSC::DFG::Graph::visitChildren):
+ (JSC::DFG::Graph::freeze):
+ (JSC::DFG::Graph::freezeStrong):
+ (JSC::DFG::Graph::freezeFragile): Deleted.
+ * dfg/DFGGraph.h:
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::initialize):
+ * dfg/DFGJITCode.cpp:
+ (JSC::DFG::JITCode::setOptimizationThresholdBasedOnCompilationResult):
+ (JSC::DFG::JITCode::validateReferences):
+ * dfg/DFGJITCode.h:
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::addressOfDoubleConstant):
+ (JSC::DFG::JITCompiler::noticeOSREntry):
+ * dfg/DFGJITCompiler.h:
+ (JSC::DFG::JITCompiler::branchStructurePtr):
+ (JSC::DFG::JITCompiler::jitCode):
+ (JSC::DFG::JITCompiler::noticeOSREntry): Deleted.
+ * dfg/DFGMinifiedGraph.cpp: Added.
+ (JSC::DFG::MinifiedGraph::prepareAndShrink):
+ (JSC::DFG::MinifiedGraph::validateReferences):
+ * dfg/DFGMinifiedGraph.h:
+ (JSC::DFG::MinifiedGraph::append):
+ (JSC::DFG::MinifiedGraph::prepareAndShrink): Deleted.
+ * dfg/DFGOSREntry.cpp:
+ (JSC::DFG::OSREntryData::dumpInContext):
+ (JSC::DFG::OSREntryData::dump):
+ (JSC::DFG::prepareOSREntry):
+ * dfg/DFGOSREntry.h:
+ (JSC::DFG::getOSREntryDataBytecodeIndex):
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::linkOSREntries):
+ (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
+ * dfg/DFGStructureAbstractValue.cpp:
+ (JSC::DFG::StructureAbstractValue::dump):
+ (JSC::DFG::StructureAbstractValue::validateReferences):
+ * dfg/DFGStructureAbstractValue.h:
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validate):
+ * dfg/DFGValueStrength.cpp:
+ (WTF::printInternal):
+ * dfg/DFGValueStrength.h:
+ (JSC::DFG::merge):
+ * ftl/FTLExitPropertyValue.cpp:
+ (JSC::FTL::ExitPropertyValue::dump):
+ (JSC::FTL::ExitPropertyValue::validateReferences):
+ * ftl/FTLExitPropertyValue.h:
+ * ftl/FTLExitTimeObjectMaterialization.cpp:
+ (JSC::FTL::ExitTimeObjectMaterialization::dump):
+ (JSC::FTL::ExitTimeObjectMaterialization::validateReferences):
+ * ftl/FTLExitTimeObjectMaterialization.h:
+ * ftl/FTLExitValue.cpp:
+ (JSC::FTL::ExitValue::dump):
+ (JSC::FTL::ExitValue::validateReferences):
+ * ftl/FTLExitValue.h:
+ * ftl/FTLJITCode.cpp:
+ (JSC::FTL::JITCode::dfgCommon):
+ (JSC::FTL::JITCode::validateReferences):
+ * ftl/FTLJITCode.h:
+ (JSC::FTL::JITCode::handles):
+ (JSC::FTL::JITCode::dataSections):
+ * ftl/FTLOSRExit.cpp:
+ (JSC::FTL::OSRExit::codeLocationForRepatch):
+ (JSC::FTL::OSRExit::validateReferences):
+ * ftl/FTLOSRExit.h:
+ (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
+ * jit/JITCode.cpp:
+ (JSC::JITCode::typeName):
+ (JSC::JITCode::validateReferences):
+ (JSC::JITCode::execute):
+ * jit/JITCode.h:
+ (JSC::JITCode::start):
+ * tests/stress/dead-osr-entry-value.js: Added.
+ (foo):
+
+2015-07-10 Matthew Hanson <matthew_hanson@apple.com>
+
+ Disable non-shipping features.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-07-09 Mark Lam <mark.lam@apple.com>
+
+ SymbolTable::entryFor() should do a bounds check before indexing into the localToEntry vector.
+ https://bugs.webkit.org/show_bug.cgi?id=146807
+
+ Reviewed by Filip Pizlo.
+
+ When we capture an argument by name and we use "arguments", we put all of the
+ arguments into the scope. But destructured arguments are put into the scope
+ anonymously i.e. the SymbolTable knows that the scope offset is in use via
+ SymbolTable::m_maxScopeOffset, but that ScopeOffset won't appear in
+ SymbolTable::m_map.
+
+ The SymbolTable's m_localToEntry vector is synthesized from its m_map, and will
+ have a size which is based on the largest ScopeOffset in the m_map. If we have a
+ scenario where the anonymous argument is at a higher ScopeOffset than all the
+ named arguments, then the m_localsToEntry vector will not have an entry for it
+ i.e. the m_localsToEntry vector will have a size that is <= the ScopeOffset of
+ the anonymous argument.
+
+ Hence, SymbolTable::entryFor() should ensure that the requested ScopeOffset is
+ within the bounds of the m_localToEntry vector before indexing into it.
+
+ * runtime/SymbolTable.cpp:
+ (JSC::SymbolTable::entryFor):
+
+2015-07-09 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (r180248): Repro Crash: com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::createRangeError + 20
+ https://bugs.webkit.org/show_bug.cgi?id=146767
+
+ Reviewed by Geoffrey Garen.
+
+ If the stack check fails at the top most frame, we must use that frame to
+ generate the exception. Reverted the code to always use the current frame to
+ throw an out of stack exception.
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+
+2015-07-03 Filip Pizlo <fpizlo@apple.com>
+
+ OSR exit fuzzing should allow us to select a static exit site
+ https://bugs.webkit.org/show_bug.cgi?id=146601
+
+ Reviewed by Geoffrey Garen.
+
+ The original implementation of the fuzzer allows us to trigger an exit based on its index
+ in the dynamic sequence of exit sites encountered. But there are usually millions of
+ dynamically encountered exit sites, even if the program only has thousands of static exit
+ sites. That means that we would at best be able to do a random sampling of exits, and
+ those would be biased to the hottest exit sites.
+
+ This change allows us to also select exit sites based on their index in the static
+ sequence of exit sites that the compiler compiled. Then, once that static exit site is
+ selected, we can select which dynamic exit at that exit site we should trigger. Since the
+ number of static exit sites is usually smallish (it's bounded by program size), we can do
+ an exhaustive search over all exit sites in most programs.
+
+ * dfg/DFGOSRExitFuzz.cpp:
+ (JSC::numberOfStaticOSRExitFuzzChecks):
+ (JSC::numberOfOSRExitFuzzChecks):
+ * dfg/DFGOSRExitFuzz.h:
+ (JSC::DFG::doOSRExitFuzzing):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
+ * jsc.cpp:
+ (jscmain):
+ * runtime/Options.h:
+ * runtime/TestRunnerUtils.h:
+
+2015-07-08 Joseph Pecoraro <pecoraro@apple.com>
+
+ Fix grammar issue in TypeError attempting to change an unconfigurable property
+ https://bugs.webkit.org/show_bug.cgi?id=146774
+
+ Reviewed by Brent Fulgham.
+
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::defineOwnProperty):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::defineOwnNonIndexProperty):
+ * runtime/StringObject.cpp:
+ (JSC::StringObject::defineOwnProperty):
+
+2015-07-06 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove the unused HeapBlock.h
+ https://bugs.webkit.org/show_bug.cgi?id=146580
+
+ Reviewed by Andreas Kling.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * heap/CopiedBlock.h:
+ * heap/CopiedSpace.h:
+ * heap/CopiedSpaceInlines.h:
+ * heap/HandleBlock.h:
+ * heap/HeapBlock.h: Removed.
+ * heap/MarkedBlock.h:
+
+2015-07-06 Saam barati <saambarati1@gmail.com>
+
+ JSC's parser should follow the ES6 spec with respect to parsing Declarations
+ https://bugs.webkit.org/show_bug.cgi?id=146621
+
+ Reviewed by Mark Lam.
+
+ There were a few locations where JSC would allow declaration statements
+ in incorrect ways. JSC didn't distinguish between 'Statement' and
+ 'StatementListItem' grammar productions. The relevant grammar is here:
+ http://www.ecma-international.org/ecma-262/6.0/index.html#sec-statements
+
+ From the ECMA Script 6.0 spec:
+ 1. Section 13.6 The if Statement (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-if-statement)
+ says that IfStatements only takes Statements for the "then-else" clauses, not StatementListItems.
+ (Same with 'while/for/do-while' loop bodies).
+ 2. Section 13 ECMAScript Language: Statements and Declarations
+ (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-statements-and-declarations)
+ defines the syntax of Statements, and they do not include ClassDeclarations and LexicalDeclarations
+ (const, let, see 13.3.1 Let and Const Declarations).
+ Declarations can only be in the “then-else” clauses when embedded in a StatementListItem in a BlockStatement (see 13.2).
+
+ Hence, the following style of declarations are no longer allowed:
+ 'if/for/while (condition) const x = 40;'
+ 'if/for/while (condition) class C { }'
+
+ Instead, we mandate such declaration constructs are within a StatementList
+ (which is the production that JSC's Parser::parseSourceElements function parses):
+ 'if/for/while (condition) { const x = 40; }'
+ 'if/for/while (condition) { class C { } }'
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseSourceElements):
+ (JSC::Parser<LexerType>::parseStatementListItem):
+ (JSC::Parser<LexerType>::parseVarDeclaration):
+ (JSC::Parser<LexerType>::parseStatement):
+ (JSC::Parser<LexerType>::parseExpressionStatement):
+ * parser/Parser.h:
+ (JSC::Parser::getLabel):
+
+2015-07-06 Alex Christensen <achristensen@webkit.org>
+
+ Unreviewed debug build fix after r186358.
+
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::fastConcatWith):
+ Pass vm parameter to fastConcatType.
+
+2015-07-06 Ryosuke Niwa <rniwa@webkit.org>
+
+ Array.concat should be fast for integer or double arrays
+ https://bugs.webkit.org/show_bug.cgi?id=146260
+
+ Reviewed by Darin Adler.
+
+ Added a fast path to Array.prototype.concat. When concatenating two Int32, Double, or Contiguous
+ arrays, simply memcopy the arrays into a new uninitialized buffer.
+
+ This improves huffman encoding in CompressionBench by 3.7x on a Mid 2014 MacBookPro.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncConcat):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::fastConcatWith): Added.
+ * runtime/JSArray.h:
+ (JSC::JSArray::fastConcatType): Added. Returns the resultant array's indexing type if we can use
+ the fact path. Returns NonArray otherwise.
+
+2015-07-06 Youenn Fablet <youenn.fablet@crf.canon.fr>
+
+ [Streams API] Remove ReadableStream custom constructor
+ https://bugs.webkit.org/show_bug.cgi?id=146547
+
+ Reviewed by Darin Adler.
+
+ Adding helper function to throw range errors.
+
+ * runtime/Error.h:
+ (JSC::throwRangeError):
+ (JSC::throwVMRangeError):
+
+2015-07-05 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement the latest Promise spec in JS
+ https://bugs.webkit.org/show_bug.cgi?id=146229
+
+ Reviewed by Sam Weinig.
+
+ Updated the Promise implementation to meet to the ES6 spec.
+ This patch
+ 1. Implement ES6 Promise and related abstract operations in builtins JS
+ 2. Expose @enqueueJob private function to JS world to post the microtask
+
+ Updated implementation has one-on-one correspondence to the ES6 spec description.
+ And keep the JSPromiseDeferred because it is the interface used from the WebCore.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * builtins/Array.prototype.js:
+ (reduce):
+ (reduceRight):
+ (every):
+ (forEach):
+ (filter):
+ (map):
+ (some):
+ (fill):
+ (find):
+ (findIndex):
+ (includes):
+ (copyWithin):
+ ToInteger / ToLength are renamed to toInteger and toLength.
+ * builtins/ArrayConstructor.js:
+ (from):
+ ToInteger / ToLength are renamed to toInteger and toLength.
+ * builtins/GlobalObject.js:
+ (toInteger):
+ (toLength):
+ (isObject):
+ (ToInteger): Deleted.
+ (ToLength): Deleted.
+ ToInteger / ToLength are renamed to toInteger and toLength.
+ Add new abstract operation, isObject.
+ * builtins/Operations.Promise.js: Added.
+ (isPromise):
+ (newPromiseReaction):
+ (newPromiseDeferred):
+ (newPromiseCapability.executor):
+ (newPromiseCapability):
+ (triggerPromiseReactions):
+ (rejectPromise):
+ (fulfillPromise):
+ (createResolvingFunctions.resolve):
+ (createResolvingFunctions.reject):
+ (createResolvingFunctions):
+ (promiseReactionJob):
+ (promiseResolveThenableJob):
+ (initializePromise):
+ Added Promise related abstract operations.
+ * builtins/Promise.prototype.js:
+ (catch):
+ (.onFulfilled):
+ (.onRejected):
+ (then):
+ Promise#then implementation in JS.
+ * builtins/PromiseConstructor.js: Added.
+ (all.newResolveElement):
+ (all):
+ (race):
+ (reject):
+ (resolve):
+ Promise static functions implementations in JS.
+ * builtins/StringConstructor.js:
+ (raw):
+ ToInteger / ToLength are renamed to toInteger and toLength.
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::getInternalProperties):
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::enqueueJob):
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::initializePromiseFunction):
+ (JSC::JSGlobalObject::newPromiseDeferredFunction):
+ * runtime/JSJob.cpp: Renamed from Source/JavaScriptCore/runtime/JSPromiseReaction.h.
+ (JSC::createJSJob):
+ (JSC::JSJobMicrotask::run):
+ * runtime/JSJob.h: Renamed from Source/JavaScriptCore/runtime/JSPromiseFunctions.h.
+ * runtime/JSPromise.cpp:
+ (JSC::JSPromise::create):
+ (JSC::JSPromise::JSPromise):
+ (JSC::JSPromise::finishCreation):
+ (JSC::JSPromise::result):
+ (JSC::JSPromise::destroy): Deleted.
+ (JSC::JSPromise::visitChildren): Deleted.
+ (JSC::JSPromise::reject): Deleted.
+ (JSC::JSPromise::resolve): Deleted.
+ (JSC::JSPromise::appendResolveReaction): Deleted.
+ (JSC::JSPromise::appendRejectReaction): Deleted.
+ (JSC::triggerPromiseReactions): Deleted.
+ * runtime/JSPromise.h:
+ (JSC::JSPromise::status): Deleted.
+ (JSC::JSPromise::result): Deleted.
+ (JSC::JSPromise::constructor): Deleted.
+ * runtime/JSPromiseConstructor.cpp:
+ (JSC::constructPromise):
+ (JSC::JSPromiseConstructorFuncResolve): Deleted.
+ (JSC::JSPromiseConstructorFuncReject): Deleted.
+ (JSC::performPromiseRaceLoop): Deleted.
+ (JSC::JSPromiseConstructorFuncRace): Deleted.
+ (JSC::performPromiseAll): Deleted.
+ (JSC::JSPromiseConstructorFuncAll): Deleted.
+ * runtime/JSPromiseDeferred.cpp:
+ (JSC::JSPromiseDeferred::create):
+ (JSC::createJSPromiseDeferredFromConstructor): Deleted.
+ (JSC::updateDeferredFromPotentialThenable): Deleted.
+ (JSC::performDeferredResolve): Deleted.
+ (JSC::performDeferredReject): Deleted.
+ (JSC::abruptRejection): Deleted.
+ * runtime/JSPromiseDeferred.h:
+ * runtime/JSPromiseFunctions.cpp: Removed.
+ (JSC::deferredConstructionFunction): Deleted.
+ (JSC::createDeferredConstructionFunction): Deleted.
+ (JSC::identifyFunction): Deleted.
+ (JSC::createIdentifyFunction): Deleted.
+ (JSC::promiseAllCountdownFunction): Deleted.
+ (JSC::createPromiseAllCountdownFunction): Deleted.
+ (JSC::promiseResolutionHandlerFunction): Deleted.
+ (JSC::createPromiseResolutionHandlerFunction): Deleted.
+ (JSC::rejectPromiseFunction): Deleted.
+ (JSC::createRejectPromiseFunction): Deleted.
+ (JSC::resolvePromiseFunction): Deleted.
+ (JSC::createResolvePromiseFunction): Deleted.
+ (JSC::throwerFunction): Deleted.
+ (JSC::createThrowerFunction): Deleted.
+ * runtime/JSPromisePrototype.cpp:
+ (JSC::JSPromisePrototypeFuncThen): Deleted.
+ * runtime/JSPromiseReaction.cpp: Removed.
+ (JSC::createExecutePromiseReactionMicrotask): Deleted.
+ (JSC::ExecutePromiseReactionMicrotask::run): Deleted.
+ (JSC::JSPromiseReaction::create): Deleted.
+ (JSC::JSPromiseReaction::JSPromiseReaction): Deleted.
+ (JSC::JSPromiseReaction::finishCreation): Deleted.
+ (JSC::JSPromiseReaction::visitChildren): Deleted.
+ * runtime/VM.cpp:
+ (JSC::VM::VM): Deleted.
+ * runtime/VM.h:
+
+2015-07-04 Chris Dumez <cdumez@apple.com>
+
+ Drop RefPtr::clear() method
+ https://bugs.webkit.org/show_bug.cgi?id=146556
+
+ Reviewed by Brady Eidson.
+
+ Drop RefPtr::clear() method in favor of "= nullptr;" pattern.
+
+2015-07-03 Dan Bernstein <mitz@apple.com>
+
+ Just give up on -Wunreachable-code in JavaScriptCore.
+
+ * Configurations/Base.xcconfig:
+ * llint/LowLevelInterpreter.cpp:
+ (JSC::CLoop::execute):
+
+2015-07-03 Dan Bernstein <mitz@apple.com>
+
+ Fixed the LLINT CLoop build.
+
+ * llint/LowLevelInterpreter.cpp:
+ (JSC::CLoop::execute):
+
+2015-07-03 Dan Bernstein <mitz@apple.com>
+
+ [Xcode] Update some build settings as recommended by Xcode 7
+ https://bugs.webkit.org/show_bug.cgi?id=146597
+
+ Reviewed by Sam Weinig.
+
+ * Configurations/Base.xcconfig: Enabled CLANG_WARN_UNREACHABLE_CODE and
+ GCC_NO_COMMON_BLOCKS. Removed GCC_MODEL_TUNING.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Updated LastUpgradeCheck.
+
+ * dfg/DFGGraph.h: Tweaked the definition of DFG_CRASH to suppress unreachable code warnings.
+
+2015-07-03 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Relax builtin JS restriction about try-catch
+ https://bugs.webkit.org/show_bug.cgi?id=146555
+
+ Reviewed by Sam Weinig.
+
+ When retrieving the captured variables from the full activated scope,
+ it swapped the given vector with the stored declared variables vector.
+ This is because retrieving the captured variables are executed in the
+ last sequence of the parser, so declared variables are no longer used.
+ However, in builtins functions case, after retrieving the captured
+ variables, we check the variables by using declared variables vector.
+ So at that time, the declared variables vector becomes empty and it
+ raises assertion failures when the builtins function contains the full
+ activated scope. try-catch's catch scope requires the upper scope full
+ activated, so JS code in the builtins cannot use the try-catch.
+
+ This patch relaxes this restriction. When retrieving the captured
+ variables from the scope, just copy to the given vector.
+
+ * parser/Parser.h:
+ (JSC::Scope::getCapturedVariables):
+
+2015-07-02 Filip Pizlo <fpizlo@apple.com>
+
+ DFG and FTL should have an OSR exit fuzzer
+ https://bugs.webkit.org/show_bug.cgi?id=146562
+
+ Reviewed by Benjamin Poulain.
+
+ Adds a basic OSR exit fuzzer to JSC. This isn't hooked into any test harnesses yet, but I
+ spot-checked it on v8-earley-boyer.js and so far found no bugs. I'd like to figure out how
+ to harness this after I land it.
+
+ Since it's turned off by default, it should have no effect on behavior.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGOSRExitFuzz.cpp: Added.
+ (JSC::numberOfOSRExitFuzzChecks):
+ * dfg/DFGOSRExitFuzz.h: Added.
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
+ (JSC::DFG::SpeculativeJIT::emitOSRExitFuzzCheck):
+ (JSC::DFG::SpeculativeJIT::speculationCheck):
+ * dfg/DFGSpeculativeJIT.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
+ * jsc.cpp:
+ (jscmain):
+ * runtime/Options.h:
+ * runtime/TestRunnerUtils.h:
+
+2015-07-02 Saam barati <saambarati1@gmail.com>
+
+ Rename "Deconstruction" to "Destructuring" throughout JSC
+ https://bugs.webkit.org/show_bug.cgi?id=146100
+
+ Reviewed by Mark Lam.
+
+ It is good to use the same naming conventions as the ES6
+ spec because it is the de facto way of speaking about these
+ language features. This also has the benefit of improving JSC's
+ hackability because it improves code readability for newcomers
+ to JSC or newcomers to this part of the code base.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::initializeNextParameter):
+ (JSC::BytecodeGenerator::visibleNameForParameter):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::registerFor):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ForInNode::tryGetBoundLocal):
+ (JSC::ForInNode::emitLoopHeader):
+ (JSC::ForOfNode::emitBytecode):
+ (JSC::ClassExprNode::emitBytecode):
+ (JSC::DestructuringAssignmentNode::emitBytecode):
+ (JSC::DestructuringPatternNode::~DestructuringPatternNode):
+ (JSC::ArrayPatternNode::collectBoundIdentifiers):
+ (JSC::DeconstructingAssignmentNode::emitBytecode): Deleted.
+ (JSC::DeconstructionPatternNode::~DeconstructionPatternNode): Deleted.
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createElementList):
+ (JSC::ASTBuilder::createFormalParameterList):
+ (JSC::ASTBuilder::createClause):
+ (JSC::ASTBuilder::createClauseList):
+ (JSC::ASTBuilder::createForInLoop):
+ (JSC::ASTBuilder::createForOfLoop):
+ (JSC::ASTBuilder::isBindingNode):
+ (JSC::ASTBuilder::isResolve):
+ (JSC::ASTBuilder::createDestructuringAssignment):
+ (JSC::ASTBuilder::createArrayPattern):
+ (JSC::ASTBuilder::appendArrayPatternSkipEntry):
+ (JSC::ASTBuilder::appendArrayPatternEntry):
+ (JSC::ASTBuilder::appendArrayPatternRestEntry):
+ (JSC::ASTBuilder::createObjectPattern):
+ (JSC::ASTBuilder::appendObjectPatternEntry):
+ (JSC::ASTBuilder::createDeconstructingAssignment): Deleted.
+ * parser/NodeConstructors.h:
+ (JSC::TryNode::TryNode):
+ (JSC::ParameterNode::ParameterNode):
+ (JSC::ForOfNode::ForOfNode):
+ (JSC::DestructuringPatternNode::DestructuringPatternNode):
+ (JSC::ArrayPatternNode::ArrayPatternNode):
+ (JSC::ArrayPatternNode::create):
+ (JSC::ObjectPatternNode::ObjectPatternNode):
+ (JSC::BindingNode::create):
+ (JSC::BindingNode::BindingNode):
+ (JSC::DestructuringAssignmentNode::DestructuringAssignmentNode):
+ (JSC::DeconstructionPatternNode::DeconstructionPatternNode): Deleted.
+ (JSC::DeconstructingAssignmentNode::DeconstructingAssignmentNode): Deleted.
+ * parser/Nodes.cpp:
+ (JSC::FunctionParameters::create):
+ * parser/Nodes.h:
+ (JSC::ExpressionNode::isResolveNode):
+ (JSC::ExpressionNode::isBracketAccessorNode):
+ (JSC::ExpressionNode::isDotAccessorNode):
+ (JSC::ExpressionNode::isDestructuringNode):
+ (JSC::ExpressionNode::isFuncExprNode):
+ (JSC::ExpressionNode::isCommaNode):
+ (JSC::ExpressionNode::isSimpleArray):
+ (JSC::ParameterNode::pattern):
+ (JSC::ParameterNode::nextParam):
+ (JSC::FunctionParameters::size):
+ (JSC::FunctionParameters::at):
+ (JSC::FunctionParameters::patterns):
+ (JSC::DestructuringPatternNode::isBindingNode):
+ (JSC::DestructuringPatternNode::emitDirectBinding):
+ (JSC::ArrayPatternNode::appendIndex):
+ (JSC::ObjectPatternNode::appendEntry):
+ (JSC::BindingNode::boundProperty):
+ (JSC::DestructuringAssignmentNode::bindings):
+ (JSC::ExpressionNode::isDeconstructionNode): Deleted.
+ (JSC::DeconstructionPatternNode::isBindingNode): Deleted.
+ (JSC::DeconstructionPatternNode::emitDirectBinding): Deleted.
+ (JSC::DeconstructingAssignmentNode::bindings): Deleted.
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseVarDeclaration):
+ (JSC::Parser<LexerType>::parseWhileStatement):
+ (JSC::Parser<LexerType>::parseVarDeclarationList):
+ (JSC::Parser<LexerType>::createBindingPattern):
+ (JSC::Parser<LexerType>::tryParseDestructuringPatternExpression):
+ (JSC::Parser<LexerType>::parseDestructuringPattern):
+ (JSC::Parser<LexerType>::parseDefaultValueForDestructuringPattern):
+ (JSC::Parser<LexerType>::parseForStatement):
+ (JSC::Parser<LexerType>::parseFormalParameters):
+ (JSC::Parser<LexerType>::parseFunctionParameters):
+ (JSC::Parser<LexerType>::parseAssignmentExpression):
+ (JSC::Parser<LexerType>::tryParseDeconstructionPatternExpression): Deleted.
+ (JSC::Parser<LexerType>::parseDeconstructionPattern): Deleted.
+ (JSC::Parser<LexerType>::parseDefaultValueForDeconstructionPattern): Deleted.
+ * parser/Parser.h:
+ (JSC::isEvalNode):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createPropertyList):
+ (JSC::SyntaxChecker::createElementList):
+ (JSC::SyntaxChecker::createFormalParameterList):
+ (JSC::SyntaxChecker::createClause):
+ (JSC::SyntaxChecker::createClauseList):
+ (JSC::SyntaxChecker::operatorStackPop):
+ * tests/stress/reserved-word-with-escape.js:
+ * tests/stress/rest-elements.js:
+
+2015-07-02 Mark Lam <mark.lam@apple.com>
+
+ Build fix for Win EWS bot.
+ https://bugs.webkit.org/show_bug.cgi?id=146551
+
+ Not reviewed.
+
+ * tools/JSDollarVMPrototype.cpp:
+ (JSC::functionCrash):
+
+2015-07-02 Dan Bernstein <mitz@apple.com>
+
+ <rdar://problem/21429613> [iOS] Stop making symlinks from PrivateFrameworks to Frameworks
+ https://bugs.webkit.org/show_bug.cgi?id=146542
+
+ Reviewed by Sam Weinig.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Removed the build phase that makes the symlink.
+
+2015-07-01 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Aggregate profile call information on the backend to drastically reduce profile sizes
+ https://bugs.webkit.org/show_bug.cgi?id=146536
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Timeline.json:
+ Change a CPUProfile from sending a required "calls" param to sending a required
+ "callInfo" param which includes aggregated information about the calls.
+
+2015-06-30 Filip Pizlo <fpizlo@apple.com>
+
+ DFG::freezeFragile should register the frozen value's structure
+ https://bugs.webkit.org/show_bug.cgi?id=136055
+ rdar://problem/21042120
+
+ Reviewed by Mark Lam and Geoffrey Garen.
+
+ This fixes weird concurrency bugs where the constant folding phase tries to convert
+ something to a constant but then crashes because the constant's structure wasn't
+ registered. The AI was registering the structure of any value it saw, but constant folding
+ wasn't - and that's fine so long as there ain't no concurrency.
+
+ The best fix is to just make it impossible to introduce a constant into the IR without
+ registering its structure. That's what this change does. This is not only a great
+ concurrency fix - it also makes the compiler somewhat easier to hack on because it's one
+ less case of structure registering that you have to remember about.
+
+ * dfg/DFGAbstractValue.cpp:
+ (JSC::DFG::AbstractValue::setOSREntryValue): No need to register.
+ (JSC::DFG::AbstractValue::set): We still call register, but just to get the watchpoint state.
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::freezeFragile): Register the structure.
+ * dfg/DFGStructureRegistrationPhase.cpp:
+ (JSC::DFG::StructureRegistrationPhase::run): Assert that these are all registered.
+
+2015-07-01 Matthew Mirman <mmirman@apple.com>
+
+ Unreviewed, rolling out r185889
+ https://bugs.webkit.org/show_bug.cgi?id=146528
+ rdar://problem/21573959
+
+ Patch breaks chromeexperiments.com
+
+ Reverted changeset:
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/InjectedScriptSource.js:
+ (.):
+ * runtime/JSBoundSlotBaseFunction.cpp: Removed.
+ * runtime/JSBoundSlotBaseFunction.h: Removed.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init): Deleted.
+ (JSC::JSGlobalObject::visitChildren): Deleted.
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::getOwnPropertyDescriptor):
+ (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
+ * runtime/VM.cpp:
+ (JSC::VM::VM): Deleted.
+ * runtime/VM.h:
+
+2015-07-01 Dean Jackson <dino@apple.com>
+
+ Disable the experimental WebGL2 implementation
+ https://bugs.webkit.org/show_bug.cgi?id=146526
+ <rdar://problem/21641235>
+
+ Reviewed by Myles Maxfield.
+
+ Add (and disable) an ENABLE_WEBGL2 flag.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-07-01 Matthew Daiter <mdaiter@apple.com>
+
+ Enable MEDIA_STREAM flag
+ https://bugs.webkit.org/show_bug.cgi?id=145947
+ <rdar://problem/21365829>
+
+ Reviewed by Eric Carlson.
+
+ * Configurations/FeatureDefines.xcconfig: Added MEDIA_STREAM flag
+
+2015-06-30 Andy VanWagoner <thetalecrafter@gmail.com>
+
+ Implement ECMAScript Internationalization API
+ https://bugs.webkit.org/show_bug.cgi?id=90906
+
+ Reviewed by Benjamin Poulain.
+
+ * CMakeLists.txt: add IntlObject.cpp
+ * Configurations/FeatureDefines.xcconfig: add ENABLE_INTL flag
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: add IntlObject
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: add IntlObject
+ * JavaScriptCore.xcodeproj/project.pbxproj: add IntlObject
+ * runtime/CommonIdentifiers.h: add "Intl" name
+ * runtime/IntlObject.cpp: Added.
+ (JSC::IntlObject::IntlObject):
+ (JSC::IntlObject::create):
+ (JSC::IntlObject::finishCreation):
+ (JSC::IntlObject::createStructure):
+ * runtime/IntlObject.h: Added.
+ * runtime/JSGlobalObject.cpp: Add global Intl
+ (JSC::JSGlobalObject::init):
+
+2015-06-30 Basile Clement <basile_clement@apple.com>
+
+ Allow object allocation sinking through GetScope, GetExecutable and SkipScope nodes
+ https://bugs.webkit.org/show_bug.cgi?id=146431
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::isFunctionAllocation):
+ (JSC::DFG::Node::isPhantomFunctionAllocation):
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPromoteHeapAccess.h:
+ (JSC::DFG::promoteHeapAccess):
+
+2015-06-30 Matt Baker <mattbaker@apple.com>
+
+ Web Inspector: Reduce rendering frames "Other" time by instrumenting compositing
+ https://bugs.webkit.org/show_bug.cgi?id=146168
+
+ Reviewed by Brian Burg.
+
+ * inspector/protocol/Timeline.json:
+ New timeline record type for compositing events.
+
+2015-06-29 Dean Jackson <dino@apple.com>
+
+ Temporarily disable PICTURE_SIZES
+ https://bugs.webkit.org/show_bug.cgi?id=146435
+ <rdar://problem/21087013>
+
+ Reviewed by Tim Horton.
+
+ Temporarily disable PICTURE_SIZES because it causes problems with out
+ of date <picture> polyfills.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-06-29 Youenn Fablet <youenn.fablet@crf.canon.fr>
+
+ Binding generator should allow using JSC::Value for "any" parameter in lieu of ScriptValue
+ https://bugs.webkit.org/show_bug.cgi?id=146403
+
+ Reviewed by Darin Adler.
+
+ * bindings/ScriptValue.h: Added implicit conversion to JSC::JSValue.
+
+2015-06-28 Aleksandr Skachkov <gskachkov@gmail.com>
+
+ [ES6] Implement ES6 arrow function syntax. No Line terminator between function parameters and =>
+ https://bugs.webkit.org/show_bug.cgi?id=146394
+
+ Reviewed by Yusuke Suzuki.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+
+2015-06-27 Darin Adler <darin@apple.com>
+
+ Make converting JSString to StringView idiomatically safe
+ https://bugs.webkit.org/show_bug.cgi?id=146387
+
+ Reviewed by Anders Carlsson.
+
+ * jsc.cpp:
+ (functionPrint): Add explicit call to SafeView::get, needed since there
+ is no StringView temporary.
+ (functionDebug): Ditto.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::holesMustForwardToPrototype): Refactored into helper function.
+ (JSC::join): Refactored so that StringView is a function argument, making
+ the lifetime simpler.
+ (JSC::arrayProtoFuncJoin): Ditto.
+ (JSC::arrayProtoFuncReverse): Use new holesMustForwardToPrototype helper.
+
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::encode): Add explicit call to SafeView::get.
+
+ * runtime/JSString.h: Moved declarations of functions to the top of the
+ file instead of mixing them in with the function definitions. Changed
+ return type of the view function to return a JSString::SafeView so that
+ the JSString's lifetime will last as long as the StringView does in
+ typical coding idioms.
+ (JSC::JSString::getIndex): Use unsafeView so we can index into the
+ view; could also have used view.get but here in this class this seems fine.
+ (JSC::JSRopeString::unsafeView): Renamed existing view function to this.
+ (JSC::JSString::unsafeView): Ditto.
+ (JSC::JSString::SafeView::SafeView): Contains reference to an ExecState
+ and a JSString. The ExecState is needed to create the StringView, and the
+ JSString needs to be kept alive as long as the StringView is.
+ (JSC::JSString::SafeView::operator StringView): Call unsafeView.
+ (JSC::JSString::SafeView::get): Convenience for when we want to call
+ StringView member functions.
+ (JSC::JSString::view): Added. Returns a SafeView.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncIndexOf): Add explicit call to SafeView::get.
+
+2015-06-26 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove ARMv7Assembler.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=146340
+
+ Reviewed by Filip Pizlo.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * assembler/ARMv7Assembler.cpp: Removed.
+
+2015-06-26 Csaba Osztrogonác <ossy@webkit.org>
+
+ Fix the !ENABLE(ES6_ARROWFUNCTION_SYNTAX) build after r185989
+ https://bugs.webkit.org/show_bug.cgi?id=146344
+
+ Reviewed by Yusuke Suzuki.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseSourceElements):
+
+2015-06-26 Aleksandr Skachkov <gskachkov@gmail.com>
+
+ [ES6] Implement ES6 arrow function syntax. Parser of arrow function with execution as common function.
+ https://bugs.webkit.org/show_bug.cgi?id=144955
+
+ Reviewed by Yusuke Suzuki.
+
+ Added support of ES6 arrow function. Changes were made according to following spec http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax. Patch does not include any arrow function specific behavior e.g. lexical bind this, arguments and etc.
+ This patch implements the simplest cases of arrow function declaration:
+ parameters () => 10 + 20
+ parameter x => x + 20
+ parameters (x, y) => x + y
+ function with block x => { return x*10; }
+
+ Not implemented:
+ bind of the this, arguments, super and etc.
+ exception in case of trying to use 'new' with arrow function
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createFunctionExpr):
+ (JSC::ASTBuilder::createArrowFunctionExpr):
+ (JSC::ASTBuilder::createGetterOrSetterProperty):
+ (JSC::ASTBuilder::createFuncDeclStatement):
+ * parser/Lexer.cpp:
+ (JSC::Lexer<T>::setTokenPosition):
+ (JSC::Lexer<T>::lex):
+ * parser/Lexer.h:
+ (JSC::Lexer::lastTokenLocation):
+ (JSC::Lexer::setTerminator):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner):
+ (JSC::Parser<LexerType>::parseSourceElements):
+ (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBody):
+ (JSC::Parser<LexerType>::parseSwitchClauses):
+ (JSC::Parser<LexerType>::parseSwitchDefaultClause):
+ (JSC::Parser<LexerType>::parseBlockStatement):
+ (JSC::Parser<LexerType>::parseFunctionBody):
+ (JSC::stringForFunctionMode):
+ (JSC::Parser<LexerType>::parseFunctionParameters):
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseClass):
+ (JSC::Parser<LexerType>::parseAssignmentExpression):
+ (JSC::Parser<LexerType>::parsePropertyMethod):
+ (JSC::Parser<LexerType>::parseGetterSetter):
+ (JSC::Parser<LexerType>::parseArrowFunctionExpression):
+ * parser/Parser.h:
+ (JSC::Parser::locationBeforeLastToken):
+ (JSC::Parser::isEndOfArrowFunction):
+ (JSC::Parser::isArrowFunctionParamters):
+ (JSC::Parser::setEndOfStatement):
+ * parser/ParserFunctionInfo.h:
+ * parser/ParserTokens.h:
+ * parser/SourceCode.h:
+ (JSC::SourceCode::subArrowExpression):
+ * parser/SourceProviderCacheItem.h:
+ (JSC::SourceProviderCacheItem::endFunctionToken):
+ (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createArrowFunctionExpr):
+ (JSC::SyntaxChecker::setFunctionNameStart):
+
+2015-06-25 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Support rest element in destructuring assignments
+ https://bugs.webkit.org/show_bug.cgi?id=146206
+
+ Reviewed by Oliver Hunt.
+
+ This patch enables rest element (...rest) in array binding patterns.
+ It generates array from the iterables.
+ In variable declarations and parameters, `[...identifier]` form is only allowed,
+ while expressions can take `[...[...rest]]` pattern.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::emitIteratorNext):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ArrayPatternNode::bindValue):
+ (JSC::ArrayPatternNode::toString):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::appendArrayPatternSkipEntry):
+ (JSC::ASTBuilder::appendArrayPatternEntry):
+ (JSC::ASTBuilder::appendArrayPatternRestEntry):
+ * parser/Nodes.h:
+ (JSC::ArrayPatternNode::appendIndex):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseDeconstructionPattern):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::operatorStackPop):
+ * tests/stress/rest-elements.js: Added.
+ (shouldBe):
+ (shouldThrow):
+
+2015-06-25 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r185956.
+ https://bugs.webkit.org/show_bug.cgi?id=146321
+
+ Causes massive crashes on test bots (Requested by bfulgham on
+ #webkit).
+
+ Reverted changeset:
+
+ "Enabling MEDIA_STREAM"
+ https://bugs.webkit.org/show_bug.cgi?id=145947
+ http://trac.webkit.org/changeset/185956
+
+2015-06-25 Michael Saboff <msaboff@apple.com>
+
+ Minor fix to idx bounds check after 185954
+
+ Rubber Stamped by Ryosuke Niwa.
+
+ Changed "idx > 1" to "idx > 0" in two places.
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::functionCallBase):
+
+2015-06-25 Keith Miller <keith_miller@apple.com>
+
+ Address Sanitizer does not play well with memcpy in JSC::MachineThreads::tryCopyOtherThreadStack.
+ https://bugs.webkit.org/show_bug.cgi?id=146297
+
+ Reviewed by Filip Pizlo.
+
+ Since we cannot blacklist the system memcpy we must use our own naive implementation,
+ copyMemory. This is not a significant performance loss as tryCopyOtherThreadStack is
+ only called as part of an O(heapsize) operation. As the heap is generally much larger
+ than the stack the performance hit is minimal.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::copyMemory):
+ (JSC::MachineThreads::tryCopyOtherThreadStack):
+ (JSC::asanUnsafeMemcpy): Deleted.
+
+2015-06-25 Matthew Daiter <mdaiter@apple.com>
+
+ Enabling MEDIA_STREAM
+ https://bugs.webkit.org/show_bug.cgi?id=145947
+ <rdar://problem/21365829>
+
+ Reviewed by Brent Fulgham.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-06-25 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (r181889): basspro.com hangs on load under JSC::ErrorInstance::finishCreation(JSC::ExecState*, JSC::VM&, WTF::String const&, bool) + 2801 (JavaScriptCore + 3560689)
+ https://bugs.webkit.org/show_bug.cgi?id=146298
+
+ Reviewed by Mark Lam.
+
+ We were underflowing in ExceptionHelpers.cpp::functionCallBase() with a right to left
+ string index. Added checks that idx stays within the string. Also added a termination
+ condition when idx is 0.
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::functionCallBase):
+
+2015-06-24 Chris Dumez <cdumez@apple.com>
+
+ Unreviewed, speculative build fix after r185942.
+
+ Add missing include for StrongInlines.h.
+
+ * runtime/ArrayPrototype.cpp:
+
+2015-06-24 Darin Adler <darin@apple.com>
+
+ Optimize Array.join and Array.reverse for high speed array types
+ https://bugs.webkit.org/show_bug.cgi?id=146275
+
+ Reviewed by Mark Lam.
+
+ This seems to yield another 17% speed improvement in the array
+ test from the Peacekeeper benchmark.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::isHole): Added. Helper to check for holes.
+ (JSC::containsHole): Ditto.
+ (JSC::arrayProtoFuncJoin): Added special cases for the various types
+ of arrays that could be in a butterfly.
+ (JSC::arrayProtoFuncReverse): Ditto.
+
+ * runtime/JSStringJoiner.h: Made appendEmptyString public so we can
+ call it from the new parts of Array.join.
+
+2015-06-24 Filip Pizlo <fpizlo@apple.com>
+
+ DFG::SpeculativeJIT shouldn't use filter==Contradiction when it meant isClear
+ https://bugs.webkit.org/show_bug.cgi?id=146291
+ rdar://problem/21435366
+
+ Reviewed by Michael Saboff.
+
+ The filter() method returns Contradiction only when a value *becomes* clear. This is
+ necessary for supporting the convention that non-JSValue nodes have a bottom proved
+ type. (We should fix that convention eventually, but for now let's just be consistent
+ about it.)
+
+ * dfg/DFGFiltrationResult.h: Document the issue.
+ * dfg/DFGSpeculativeJIT32_64.cpp: Work around the issue.
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
+ * dfg/DFGSpeculativeJIT64.cpp: Work around the issue.
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
+
+2015-06-24 Michael Saboff <msaboff@apple.com>
+
+ Crash on gog.com due to PolymorphicCallNode's having stale references to CallLinkInfo
+ https://bugs.webkit.org/show_bug.cgi?id=146285
+
+ Reviewed by Filip Pizlo.
+
+ CallLinkInfo's contain a RefPtr to a PolymorphicCallStubRoutine, named stub, which contains
+ a collection of PolymorphicCallNode. Those PolymorphicCallNodes have a reference back to the
+ CallLinkInfo. When a CallLinkInfo replaces or clears "stub", the ref count of the
+ PolymorphicCallStubRoutine is decremented as expected, but since it inherits from
+ GCAwareJITStubRoutine, it isn't actually deleted until GC. In the mean time, the original
+ CallLinkInfo can go away. If PolymorphicCallNode::unlink() is called at that point,
+ it will try to unlink a now deleted CallLinkInfo and crash as a result.
+
+ The fix is to clear the CallLinkInfo references from any PolymorphicCallNode objects when
+ when we set a new stub or clear an existing stub for a CallLinkInfo. This is done by
+ calling PolymorphicCallNode::clearCallNodesFor() on the old stub.
+
+ The prior code would only call clearCallNodesFor() from the CallLinkInfo destructor.
+ This only took care of the last PolymorphicCallStubRoutine held in the CallLinkInfo.
+ Any prior PolymorphicCallStubRoutine would still have a, now bad, reference to the CallLinkInfo.
+
+ In the process I refactored CallLinkInfo from a struct to a class with proper accessors and
+ made all the data elements private.
+
+ * bytecode/CallLinkInfo.cpp:
+ (JSC::CallLinkInfo::clearStub): Updated to call PolymorphicCallStubRoutine::clearCallNodesFor()
+ to clear the back references to this CallLinkInfo.
+ * bytecode/CallLinkInfo.h:
+ (JSC::CallLinkInfo::~CallLinkInfo): Moved clearCallNodesFor() call to clearStub().
+ (JSC::CallLinkInfo::setStub): Clear any prior stub before changing to the new stub.
+
+2015-06-24 Michael Saboff <msaboff@apple.com>
+
+ Refactor CallLinkInfo from a struct to a class
+ https://bugs.webkit.org/show_bug.cgi?id=146292
+
+ Rubber stamped by Filip Pizlo.
+
+ Refactored CallLinkInfo from a struct to a class with proper accessors and made all the
+ data elements private.
+
+ Done in preparation for fixing https://bugs.webkit.org/show_bug.cgi?id=146285.
+
+ * bytecode/CallLinkInfo.cpp:
+ (JSC::CallLinkInfo::clearStub):
+ (JSC::CallLinkInfo::unlink):
+ (JSC::CallLinkInfo::visitWeak):
+ * bytecode/CallLinkInfo.h:
+ (JSC::CallLinkInfo::callTypeFor):
+ (JSC::CallLinkInfo::CallLinkInfo):
+ (JSC::CallLinkInfo::~CallLinkInfo):
+ (JSC::CallLinkInfo::specializationKindFor):
+ (JSC::CallLinkInfo::specializationKind):
+ (JSC::CallLinkInfo::isLinked):
+ (JSC::CallLinkInfo::setUpCall):
+ (JSC::CallLinkInfo::setCallLocations):
+ (JSC::CallLinkInfo::setUpCallFromFTL):
+ (JSC::CallLinkInfo::callReturnLocation):
+ (JSC::CallLinkInfo::hotPathBegin):
+ (JSC::CallLinkInfo::hotPathOther):
+ (JSC::CallLinkInfo::setCallee):
+ (JSC::CallLinkInfo::clearCallee):
+ (JSC::CallLinkInfo::callee):
+ (JSC::CallLinkInfo::setLastSeenCallee):
+ (JSC::CallLinkInfo::clearLastSeenCallee):
+ (JSC::CallLinkInfo::lastSeenCallee):
+ (JSC::CallLinkInfo::haveLastSeenCallee):
+ (JSC::CallLinkInfo::setStub):
+ (JSC::CallLinkInfo::stub):
+ (JSC::CallLinkInfo::seenOnce):
+ (JSC::CallLinkInfo::clearSeen):
+ (JSC::CallLinkInfo::setSeen):
+ (JSC::CallLinkInfo::hasSeenClosure):
+ (JSC::CallLinkInfo::setHasSeenClosure):
+ (JSC::CallLinkInfo::clearedByGC):
+ (JSC::CallLinkInfo::setCallType):
+ (JSC::CallLinkInfo::callType):
+ (JSC::CallLinkInfo::addressOfMaxNumArguments):
+ (JSC::CallLinkInfo::maxNumArguments):
+ (JSC::CallLinkInfo::offsetOfSlowPathCount):
+ (JSC::CallLinkInfo::setCalleeGPR):
+ (JSC::CallLinkInfo::calleeGPR):
+ (JSC::CallLinkInfo::slowPathCount):
+ (JSC::CallLinkInfo::setCodeOrigin):
+ (JSC::CallLinkInfo::codeOrigin):
+ (JSC::getCallLinkInfoCodeOrigin):
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeFor):
+ (JSC::CallLinkStatus::computeFromCallLinkInfo):
+ (JSC::CallLinkStatus::computeDFGStatuses):
+ * bytecode/CallLinkStatus.h:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::printCallOp):
+ (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::link):
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::reifyInlinedCallFrames):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * ftl/FTLJSCallBase.cpp:
+ (JSC::FTL::JSCallBase::link):
+ * jit/AccessorCallJITStubRoutine.h:
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+ * jit/JIT.h:
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ (JSC::JIT::compileOpCall):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ (JSC::JIT::compileOpCall):
+ * jit/JITOperations.cpp:
+ * jit/PolymorphicCallStubRoutine.cpp:
+ (JSC::PolymorphicCallNode::unlink):
+ (JSC::PolymorphicCallNode::clearCallLinkInfo):
+ * jit/PolymorphicCallStubRoutine.h:
+ * jit/Repatch.cpp:
+ (JSC::generateByIdStub):
+ (JSC::linkSlowFor):
+ (JSC::linkFor):
+ (JSC::revertCall):
+ (JSC::unlinkFor):
+ (JSC::linkPolymorphicCall):
+ * jit/ThunkGenerators.cpp:
+ (JSC::virtualForThunkGenerator):
+
+2015-06-24 Doug Russell <d_russell@apple.com>
+
+ Bug 146177 - AX: AXObjectCache should try to use an unignored accessibilityObject
+ when posting a selection notification when on the border between two accessibilityObjects
+ https://bugs.webkit.org/show_bug.cgi?id=146177
+
+ Add an adopt() function to simplify JSRetainPtr<JSStringRef> { Adopt, string } to adopt(string).
+
+ Reviewed by Darin Adler.
+
+ * API/JSRetainPtr.h:
+ (adopt):
+
+2015-06-24 Keith Miller <keith_miller@apple.com>
+
+ Strict Equality on objects should only check that one of the two sides is an object.
+ https://bugs.webkit.org/show_bug.cgi?id=145992
+
+ This patch adds a new optimization for checking strict equality on objects.
+ If we speculate that a strict equality comparison has an object on one side
+ we only need to type check that side. Equality is then determined by a pointer
+ comparison between the two values (although in the 32-bit case we must also check
+ that the other side is a cell). Once LICM hoists type checks out of a loop we
+ can be cleverer about how we choose the operand we type check if both are
+ speculated to be objects.
+
+ For testing I added the addressOf function, which returns the address
+ of a Cell to the runtime.
+
+ Reviewed by Mark Lam.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileStrictEq):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectStrictEquality):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compileObjectStrictEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectStrictEquality):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
+ * jsc.cpp:
+ (GlobalObject::finishCreation):
+ (functionAddressOf):
+ * tests/stress/equality-type-checking.js: Added.
+ (Foo):
+ (checkStrictEq):
+ (checkStrictEqOther):
+
+2015-06-24 Mark Lam <mark.lam@apple.com>
+
+ Fixed assertion in JSStringJoiner::join() (regression from r185899).
+
+ Not reviewed.
+
+ JSStringJoiner did not account for the case where the array being joined can
+ have null or undefined elements. As a result, its size may be less than
+ its initially reserved capacity (which was estimated based on the array length).
+
+ * runtime/JSStringJoiner.cpp:
+ (JSC::JSStringJoiner::join):
+
+2015-06-24 Darin Adler <darin@apple.com>
+
+ Fix Array.concat with RuntimeArray (regression from my last patch)
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncConcat): Use getLength instead of JSArray::length.
+
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::defineOwnProperty): Added comment about use of
+ JSArray::length here that is incorrect (in a really non-obvious way).
+ (JSC::JSArray::fillArgList): Ditto.
+ (JSC::JSArray::copyToArguments): Ditto.
+
+ * runtime/JSArray.h: Added a comment explaining that it is not always
+ safe to use JSArray::length.
+
+2015-06-23 Mark Lam <mark.lam@apple.com>
+
+ Gardening: Fixing 2 bad asserts from r185889.
+ https://bugs.webkit.org/show_bug.cgi?id=140575
+
+ Not reviewed.
+
+ * runtime/JSBoundSlotBaseFunction.cpp:
+ (JSC::JSBoundSlotBaseFunction::finishCreation):
+
+2015-06-23 Dan Bernstein <mitz@apple.com>
+
+ Fixed iOS production builds.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-06-22 Darin Adler <darin@apple.com>
+
+ Make Array.join work directly on substrings without reifying them
+ https://bugs.webkit.org/show_bug.cgi?id=146191
+
+ Reviewed by Andreas Kling.
+
+ Besides the Array.join change, this has other optimizations based on
+ profiling the Peacekeeper array benchmark.
+
+ I measured a 14% speed improvement in the Peacekeeper array benchmark.
+
+ Still a lot of low hanging fruit in that test because so many of functions
+ on the array prototype are not optimizing for simple cases. For example,
+ the reverse function does individual get and put calls even when the array
+ is entirely made up of integers in contiguous storage.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::getProperty): Use tryGetIndexQuickly first before getPropertySlot.
+ (JSC::argumentClampedIndexFromStartOrEnd): Marked inline.
+ (JSC::shift): Use the getProperty helper in this file instead of using
+ getPropertySlot. Use putByIndexInline instead of calling putByIndex directly.
+ In both cases this can yield a faster code path.
+ (JSC::unshift): Ditto.
+ (JSC::arrayProtoFuncToString): Updated to use the new JSStringJoiner
+ interface. Changed local variable name to thisArray since it's not a
+ JSObject*. Changed loop index to i instead of k.
+ (JSC::arrayProtoFuncToLocaleString): Updated to use the new JSStringJoiner
+ interface. Renamed thisObj to thisObject. Added a missing exception check
+ after the toLocaleString function is called, but before toString is called
+ the result of that function.
+ (JSC::arrayProtoFuncJoin): Updated to use the new JSStringJointer interface.
+ Added a missing exception check after calling toString on the separator
+ but before calling get to get the first element in the array-like object
+ being joined. Changed loop index to i instead of k. Added missing exception
+ check after calling toString on each string from the array before calling
+ get for the next element.
+ (JSC::arrayProtoFuncConcat): Use JSArray::length instead of using the
+ getLength function.
+ (JSC::arrayProtoFuncReverse): Ditto. Also use putByIndexInline.
+ (JSC::arrayProtoFuncShift): Ditto.
+ (JSC::arrayProtoFuncSplice): Use getIndex instead of get, which includes some
+ additional optimizations.
+ (JSC::getOrHole): Deleted. Unused function.
+ (JSC::arrayProtoFuncUnShift): Use putByIndexInline.
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::errorDescriptionForValue): Removed the duplicate copy of the the logic
+ from JSValue::toString.
+
+ * runtime/JSCJSValue.cpp:
+ (JSC::JSValue::toStringSlowCase): Improved the performance when converting a
+ small integer to a single character string.
+ (JSC::JSValue::toWTFStringSlowCase): Moved the contents of the
+ inlineJSValueNotStringtoString function here.
+ * runtime/JSCJSValue.h: Removed no longer used toWTFStringInline and fixed
+ a comment with a typo.
+
+ * runtime/JSObject.h:
+ (JSC::JSObject::putByIndexInline): Marked ALWAYS_INLINE because this was not
+ getting inlined at some call sites.
+ (JSC::JSObject::indexingData): Deleted. Unused function.
+ (JSC::JSObject::currentIndexingData): Deleted. Unused function.
+ (JSC::JSObject::getHolyIndexQuickly): Deleted. Unused function.
+ (JSC::JSObject::relevantLength): Deleted. Unused function.
+ (JSC::JSObject::currentRelevantLength): Deleted. Unused function.
+
+ * runtime/JSString.h: Added the StringViewWithUnderlyingString struct and
+ the viewWithUnderlyingString function. Removed the inlineJSValueNotStringtoString
+ and toWTFStringInline functions.
+
+ * runtime/JSStringJoiner.cpp:
+ (JSC::appendStringToData): Changed this to be a template instead of writing
+ it out, since StringView::getCharactersWithUpconvert does almsot exactly what
+ this function was trying to do.
+ (JSC::joinStrings): Rewrote this to use StringView.
+ (JSC::JSStringJoiner::joinedLength): Added. Factored out from the join function.
+ (JSC::JSStringJoiner::join): Rewrote to make it a bit simpler. Added an assertion
+ that we entirely filled capacity, since we are now reserving capacity and using
+ uncheckedAppend. Use String instead of RefPtr<StringImpl> because there was no
+ particular value to using the impl directly.
+
+ * runtime/JSStringJoiner.h: Changed the interface to the class to use StringView.
+ Also changed this class so it now has the responsibility to convert each JSValue
+ into a string. This let us share more code between toString and join, and also
+ lets us use the new viewWithUnderlyingString function, which could be confusing at
+ all the call sites, but is easier to understand here.
+
+2015-06-23 Matthew Mirman <mmirman@apple.com>
+
+ Completes native binding descriptors with native getters and potentially setters.
+ https://bugs.webkit.org/show_bug.cgi?id=140575
+ rdar://problem/19506502
+
+ Reviewed by Mark Lam.
+
+ * CMakeLists.txt: Added JSBoundSlotBaseFunction.cpp
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/InjectedScriptSource.js: Added case for descriptor having a native getter.
+ * runtime/JSBoundSlotBaseFunction.cpp: Added.
+ (JSC::boundSlotBaseFunctionCall):
+ (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
+ Necessary wrapper for custom getters and setters as objects.
+ (JSC::JSBoundSlotBaseFunction::create):
+ (JSC::JSBoundSlotBaseFunction::visitChildren):
+ (JSC::JSBoundSlotBaseFunction::finishCreation):
+ * runtime/JSBoundSlotBaseFunction.h: Added.
+ (JSC::JSBoundSlotBaseFunction::createStructure):
+ (JSC::JSBoundSlotBaseFunction::boundSlotBase):
+ (JSC::JSBoundSlotBaseFunction::customGetterSetter):
+ (JSC::JSBoundSlotBaseFunction::isGetter):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init): Added a globally initialized structure for JSBoundSlotBaseFunction
+ (JSC::JSGlobalObject::visitChildren): visits that structure
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): added a getter for that structure
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::getOwnPropertyDescriptor): extends the case for CustomGetterSetter to
+ actually include GetterSetter as a JSBoundSlotBaseFunction
+ * runtime/VM.cpp: Added initializer for customGetterSetterFunctionMap
+ * runtime/VM.h: Added cache for JSBoundSlotBaseFunction
+
+2015-06-22 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Allow trailing comma in ArrayBindingPattern and ObjectBindingPattern
+ https://bugs.webkit.org/show_bug.cgi?id=146192
+
+ Reviewed by Darin Adler.
+
+ According to the ES6 spec, trailing comma in ArrayBindingPattern and ObjectBindingPattern is allowed.
+ And empty ArrayBindingPattern and ObjectBindingPattern is also allowed.
+
+ This patch allows trailing comma and empty binding patterns.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ArrayPatternNode::bindValue):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseDeconstructionPattern):
+ * tests/stress/trailing-comma-in-patterns.js: Added.
+ (shouldBe):
+ (iterator):
+
+2015-06-20 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Destructuring assignment need to accept iterables
+ https://bugs.webkit.org/show_bug.cgi?id=144111
+
+ Reviewed by Darin Adler.
+
+ This patch makes that destructuring assignments to array binding patterns accept iterables.
+ Previously, it just access the indexed properties.
+ After this patch, it iterates the given value by using ES6 iterator protocol.
+
+ The iteration becomes different from the for-of case.
+ 1. Since there's no break/continue case, finally scope is not necessary.
+ 2. When the error is raised, the close status of the iterator becomes true. So IteratorClose is not called for that.
+ 3. Since the array binding patterns requires a limited count of iterations (if there is no rest(...rest) case), IteratorClose is called when the iteration does not consume the all values of the iterator.
+ 4. Since the array binding patterns requires a specified count of iterations, iterator's next call is skipped when iterator becomes closed.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitIteratorClose):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ArrayPatternNode::bindValue):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::finishArrayPattern):
+ * parser/Nodes.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseDeconstructionPattern):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::operatorStackPop):
+ * tests/stress/destructuring-assignment-accepts-iterables.js: Added.
+ (shouldBe):
+ (shouldThrow):
+ (.set shouldThrow):
+
+2015-06-19 Devin Rousso <drousso@apple.com>
+
+ Web Inspector: Highlight currently edited CSS selector
+ https://bugs.webkit.org/show_bug.cgi?id=145658
+
+ Reviewed by Joseph Pecoraro.
+
+ * inspector/protocol/DOM.json: Added highlightSelector to show highlight over multiple nodes.
+
+2015-06-19 Mark Lam <mark.lam@apple.com>
+
+ Gardening: fix build for EWS bots.
+
+ Not reviewed.
+
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::setLengthWithArrayStorage):
+
+2015-06-19 Michael Saboff <msaboff@apple.com>
+
+ Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::FTL::fixFunctionBasedOnStackMaps + 17225
+ https://bugs.webkit.org/show_bug.cgi?id=146133
+
+ Reviewed by Geoffrey Garen.
+
+ When generating code to put in inline caching areas, if there isn't enough space,
+ then create and link to an out of line area. We connect the inline code to this
+ out of line code area by planting a jump from the inline area to the out of line
+ code and appending a jump at the end of the out of line code bck to the instruction
+ following the inline area. We fill the unused inline area with nops, primarily to
+ ensure the disassembler doesn't get confused.
+
+ * ftl/FTLCompile.cpp:
+ (generateInlineIfPossibleOutOfLineIfNot): New function that determines if there is enough space
+ in the inline code area for the code to link. If so, it links inline, otherwise it links the
+ code out of line and plants appropriate jumps to/from the out of line code.
+ (generateICFastPath):
+ (generateCheckInICFastPath):
+ (fixFunctionBasedOnStackMaps):
+ Use generateInlineIfPossibleOutOfLineIfNot() to link code intended for inline cache space.
+
+ * ftl/FTLJITFinalizer.cpp:
+ (JSC::FTL::JITFinalizer::finalizeFunction):
+ * ftl/FTLJITFinalizer.h:
+ (JSC::FTL::OutOfLineCodeInfo::OutOfLineCodeInfo):
+ Added code to finalize any out of line LinkBuffer created by generateInlineIfPossibleOutOfLineIfNot().
+
+2015-06-19 Geoffrey Garen <ggaren@apple.com>
+
+ WebKit crash while loading nytimes at JavaScriptCore: JSC::ExecutableAllocator::allocate + 276
+ https://bugs.webkit.org/show_bug.cgi?id=146163
+ <rdar://problem/20392986>
+
+ Reviewed by Michael Saboff.
+
+ There's no good way to test this in our test harness because we don't
+ have a way to simulate executable memory pressure, and doing so would
+ cause the cases that still use JITCompilationMustSucceed to crash.
+
+ Instead, I tested by manually forcing all regexp JIT compilation to
+ fail and running the JavaScriptCore tests.
+
+ * yarr/YarrJIT.cpp:
+ (JSC::Yarr::YarrGenerator::compile): Allow compilation to fail. We can
+ fall back to the regexp interpreter if we need to.
+
+2015-06-19 Mark Lam <mark.lam@apple.com>
+
+ Employ explicit operator bool() instead of using the UnspecifiedBoolType workaround.
+ https://bugs.webkit.org/show_bug.cgi?id=146154
+
+ Reviewed by Darin Adler.
+
+ * assembler/MacroAssemblerCodeRef.h:
+ (JSC::MacroAssemblerCodePtr::dataLocation):
+ (JSC::MacroAssemblerCodePtr::operator bool):
+ (JSC::MacroAssemblerCodePtr::operator==):
+ (JSC::MacroAssemblerCodeRef::tryToDisassemble):
+ (JSC::MacroAssemblerCodeRef::operator bool):
+ (JSC::MacroAssemblerCodeRef::dump):
+ (JSC::MacroAssemblerCodePtr::operator UnspecifiedBoolType*): Deleted.
+ (JSC::MacroAssemblerCodeRef::operator UnspecifiedBoolType*): Deleted.
+
+ * bytecode/CodeOrigin.cpp:
+ (JSC::CodeOrigin::isApproximatelyEqualTo):
+ - Fixed a bug here where we were expecting to compare Executable pointers, but
+ ended up comparing a (UnspecifiedBoolType*)1 with another
+ (UnspecifiedBoolType*)1.
+
+ * bytecode/LLIntCallLinkInfo.h:
+ (JSC::LLIntCallLinkInfo::~LLIntCallLinkInfo):
+ (JSC::LLIntCallLinkInfo::isLinked):
+ (JSC::LLIntCallLinkInfo::unlink):
+ * dfg/DFGBlockWorklist.h:
+ (JSC::DFG::BlockWith::BlockWith):
+ (JSC::DFG::BlockWith::operator bool):
+ (JSC::DFG::BlockWithOrder::BlockWithOrder):
+ (JSC::DFG::BlockWithOrder::operator bool):
+ (JSC::DFG::BlockWith::operator UnspecifiedBoolType*): Deleted.
+ (JSC::DFG::BlockWithOrder::operator UnspecifiedBoolType*): Deleted.
+ * dfg/DFGIntegerRangeOptimizationPhase.cpp:
+ * dfg/DFGLazyNode.h:
+ (JSC::DFG::LazyNode::operator!):
+ (JSC::DFG::LazyNode::operator bool):
+ (JSC::DFG::LazyNode::operator UnspecifiedBoolType*): Deleted.
+ * heap/CopyWriteBarrier.h:
+ (JSC::CopyWriteBarrier::operator!):
+ (JSC::CopyWriteBarrier::operator bool):
+ (JSC::CopyWriteBarrier::get):
+ (JSC::CopyWriteBarrier::operator UnspecifiedBoolType*): Deleted.
+ * heap/Handle.h:
+ (JSC::HandleBase::operator!):
+ (JSC::HandleBase::operator bool):
+ (JSC::HandleBase::slot):
+ (JSC::HandleBase::operator UnspecifiedBoolType*): Deleted.
+ * heap/Strong.h:
+ (JSC::Strong::operator!):
+ (JSC::Strong::operator bool):
+ (JSC::Strong::swap):
+ (JSC::Strong::operator UnspecifiedBoolType*): Deleted.
+ * jit/JITWriteBarrier.h:
+ (JSC::JITWriteBarrierBase::operator bool):
+ (JSC::JITWriteBarrierBase::operator!):
+ (JSC::JITWriteBarrierBase::setFlagOnBarrier):
+ (JSC::JITWriteBarrierBase::operator UnspecifiedBoolType*): Deleted.
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::setLengthWithArrayStorage):
+ * runtime/JSCJSValue.h:
+ * runtime/JSCJSValueInlines.h:
+ (JSC::JSValue::JSValue):
+ (JSC::JSValue::operator bool):
+ (JSC::JSValue::operator==):
+ (JSC::JSValue::operator UnspecifiedBoolType*): Deleted.
+ * runtime/JSObject.h:
+ (JSC::JSObject::hasSparseMap):
+ * runtime/PropertyDescriptor.h:
+ (JSC::PropertyDescriptor::writablePresent):
+ (JSC::PropertyDescriptor::enumerablePresent):
+ (JSC::PropertyDescriptor::configurablePresent):
+ (JSC::PropertyDescriptor::setterPresent):
+ (JSC::PropertyDescriptor::getterPresent):
+ * runtime/WriteBarrier.h:
+ (JSC::WriteBarrierBase::slot):
+ (JSC::WriteBarrierBase::operator bool):
+ (JSC::WriteBarrierBase::operator!):
+ (JSC::WriteBarrierBase<Unknown>::tagPointer):
+ (JSC::WriteBarrierBase<Unknown>::payloadPointer):
+ (JSC::WriteBarrierBase<Unknown>::operator bool):
+ (JSC::WriteBarrierBase<Unknown>::operator!):
+ (JSC::WriteBarrierBase::operator UnspecifiedBoolType*): Deleted.
+ (JSC::WriteBarrierBase<Unknown>::operator UnspecifiedBoolType*): Deleted.
+
+2015-06-19 Anders Carlsson <andersca@apple.com>
+
+ Add a JSC symlink in /System/Library/PrivateFrameworks
+ https://bugs.webkit.org/show_bug.cgi?id=146158
+ rdar://problem/21465968
+
+ Reviewed by Dan Bernstein.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-06-19 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Avoid getOwnPropertyNames/Symbols on very large lists
+ https://bugs.webkit.org/show_bug.cgi?id=146141
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.prototype._propertyDescriptors):
+ Avoid calling getOwnPropertyNames/Symbols on very large lists. Instead
+ just generate property descriptors for the first 100 indexes. Note
+ this would behave poorly for sparse arrays with a length > 100, but
+ general support for lists with more than 100 elements is poor. See:
+ <https://webkit.org/b/143589> Web Inspector: Better handling for large collections in Object Trees
+
+2015-06-18 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [DFG] Avoid OSR exit in the middle of string concatenation
+ https://bugs.webkit.org/show_bug.cgi?id=145820
+
+ Reviewed by Filip Pizlo.
+
+ DFG attempt to compile ValueAdd with String type into MakeRope(left, ToString(ToPrimitive(right))).
+
+ So when right is speculated as SpecObject, ToPrimitive(SpecObject) is speculated as SpecString.
+ It leads ToString to become Identity with a speculated type check.
+
+ However, ToPrimitive and ToString are originated from the same bytecode. And ToPrimitive may have
+ an observable side effect when the given parameter is an object (calling object.{toString,valueOf}).
+
+ So when object.toString() returns a number (it is allowed in the ES spec), ToPrimitive performs
+ observable `object.toString()` calling. But ToString is converted into a speculated type check for
+ SpecString and it raises OSR exit. And we exit to the original ValueAdd's bytecode position and
+ it redundantly performs an observable ToPrimitive execution.
+
+ To fix this, this patch avoid fixing up for newly introduced ToString node.
+ Since fix up phase is not iterated repeatedly, by avoiding fixing up when generating the node,
+ we can avoid conversion from ToString to Check.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
+ * tests/stress/toprimitive-speculated-types.js: Added.
+ (shouldBe):
+ (raw):
+ (Counter):
+
+2015-06-18 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: improve generated types for objects passed to backend commands
+ https://bugs.webkit.org/show_bug.cgi?id=146091
+
+ Reviewed by Joseph Pecoraro.
+
+ The main change is that objects passed in will have a type like const T& or const T*,
+ rather than const RefPtr<T>&&. These protocol objects are owned by the generated dispatcher
+ methods and only exist to pass data to backend command implementations. So, there is no
+ reason for callees to add a reference or take ownership of these inputs.
+
+ Some small improvements were made in the code generator to standardize how these
+ expressions are generated for parameters. Optional in parameters are now prefixed with
+ 'opt_in_' to make the generated method signatures and implementations clearer.
+
+ * inspector/InspectorValues.cpp:
+ (Inspector::InspectorArrayBase::get): Add const qualifier.
+ * inspector/InspectorValues.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
+ (Inspector::parseLocation):
+ (Inspector::InspectorDebuggerAgent::setBreakpoint):
+ (Inspector::InspectorDebuggerAgent::continueToLocation):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::callFunctionOn):
+ (Inspector::InspectorRuntimeAgent::saveResult):
+ (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
+ * inspector/agents/InspectorRuntimeAgent.h:
+
+ * inspector/scripts/codegen/cpp_generator.py: Always generate PrimitiveType('array').
+ (CppGenerator.cpp_type_for_unchecked_formal_in_parameter): Alter the type signature
+ for an unchecked input to use pointers or references.
+
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
+ (CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
+ (CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
+ Local variables for optional parameters now have the 'opt_' prefix.
+
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
+ (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
+ (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
+ Local variables for optional parameters now have the 'opt_' prefix.
+ Split parameterName and parameterKey into two separate template variables to avoid mixups.
+
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+
+2015-06-18 Joseph Pecoraro <pecoraro@apple.com>
+
+ Unreviewed. Rollout r185670 as it caused some tests to be flakey.
+
+ * debugger/Debugger.cpp:
+
+2015-06-17 Alex Christensen <achristensen@webkit.org>
+
+ [Content Extensions] Log blocked loads to the WebInspector console
+ https://bugs.webkit.org/show_bug.cgi?id=146089
+
+ Reviewed by Joseph Pecoraro.
+
+ * inspector/ConsoleMessage.cpp:
+ (Inspector::messageSourceValue):
+ * inspector/protocol/Console.json:
+ * runtime/ConsoleTypes.h:
+ Add content blocker message source.
+
+2015-06-18 Saam Barati <saambarati1@gmail.com>
+
+ [ES6] support default values in deconstruction parameter nodes
+ https://bugs.webkit.org/show_bug.cgi?id=142679
+
+ Reviewed by Darin Adler.
+
+ ES6 destructuring allows destructuring properties to assign
+ default values. A link to the spec:
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-destructuring-binding-patterns
+
+ This patch implements default values for all places where deconstruction
+ is allowed besides function parameters. This is because function
+ parameters are parsed in a separate parser arena than the function
+ body itself and ExpresionNode's which are default values for
+ deconstruction parameters will be deallocated by the time we parse the body
+ of the function. I have opened a bug to address this problem:
+ https://bugs.webkit.org/show_bug.cgi?id=145995
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::DeconstructionPatternNode::~DeconstructionPatternNode):
+ (JSC::assignDefaultValueIfUndefined):
+ (JSC::ArrayPatternNode::bindValue):
+ (JSC::ArrayPatternNode::emitDirectBinding):
+ (JSC::ArrayPatternNode::toString):
+ (JSC::ArrayPatternNode::collectBoundIdentifiers):
+ (JSC::ObjectPatternNode::bindValue):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::appendArrayPatternSkipEntry):
+ (JSC::ASTBuilder::appendArrayPatternEntry):
+ (JSC::ASTBuilder::createObjectPattern):
+ (JSC::ASTBuilder::appendObjectPatternEntry):
+ (JSC::ASTBuilder::createBindingLocation):
+ * parser/Nodes.h:
+ (JSC::ArrayPatternNode::appendIndex):
+ (JSC::ObjectPatternNode::appendEntry):
+ (JSC::ObjectPatternNode::Entry::Entry): Deleted.
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseDeconstructionPattern):
+ (JSC::Parser<LexerType>::parseDefaultValueForDeconstructionPattern):
+ (JSC::Parser<LexerType>::parseConstDeclarationList):
+ * parser/Parser.h:
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::operatorStackPop):
+
+2015-06-17 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Do not show JavaScriptCore builtins in inspector
+ https://bugs.webkit.org/show_bug.cgi?id=146049
+
+ Reviewed by Timothy Hatcher.
+
+ * debugger/Debugger.cpp:
+
+2015-06-17 Andreas Kling <akling@apple.com>
+
+ [JSC] jsSubstring() should have a fast path for 0..baseLength "substrings."
+ <https://webkit.org/b/146051>
+
+ Reviewed by Anders Carlsson.
+
+ If asked to make a substring that actually spans the entire base string,
+ have jsSubstring() just return the base instead of allocating a new JSString.
+
+ 3% speed-up on Octane/regexp.
+
+ * runtime/JSString.h:
+ (JSC::jsSubstring):
+
+2015-06-16 Alex Christensen <achristensen@webkit.org>
+
+ 32-bit build fix after r185640.
+
+ * dfg/DFGIntegerRangeOptimizationPhase.cpp:
+ Explicitly cast clamped int64_t to an int.
+
+2015-06-09 Filip Pizlo <fpizlo@apple.com>
+
+ FTL should eliminate array bounds checks in loops
+ https://bugs.webkit.org/show_bug.cgi?id=145768
+
+ Reviewed by Benjamin Poulain.
+
+ This adds a phase that does forward propagation of integer inequalities. This allows us
+ to do the algebraic reasoning we need to eliminate array bounds checks in loops. It
+ also eliminates overflow checks on ArithAdd with a constant.
+
+ The phase's analysis produces results that are powerful enough to do speculative bounds
+ check hoisting, but this phase currently only does elimination. We can implement
+ hoisting later.
+
+ On programs that just loop over an array like:
+
+ for (var i = 0; i < array.length; ++i)
+ thingy += array[i]
+
+ This change is a 60% speed-up.
+
+ This is also a ~3% speed-up on Kraken, and it shows various speed-ups on individual
+ tests in Octane.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGIntegerRangeOptimizationPhase.cpp: Added.
+ (JSC::DFG::performIntegerRangeOptimization):
+ * dfg/DFGIntegerRangeOptimizationPhase.h: Added.
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * tests/stress/add-overflows-after-not-equal.js: Added.
+ * tests/stress/no-abc-skippy-loop.js: Added.
+ * tests/stress/no-abc-skippy-paired-loop.js: Added.
+ * tests/stress/sub-overflows-after-not-equal.js: Added.
+
+2015-06-16 Andreas Kling <akling@apple.com>
+
+ Remove unused template parameter InlineCapacity from SegmentedVector.
+ <https://webkit.org/b/146044>
+
+ Reviewed by Anders Carlsson.
+
+ * bytecode/ArrayProfile.h:
+ * dfg/DFGCommonData.h:
+
+2015-06-16 Michael Saboff <msaboff@apple.com>
+
+ Inlining in the DFG trashes ByteCodeParser::m_currentInstruction for the calling function
+ https://bugs.webkit.org/show_bug.cgi?id=146029
+
+ Reviewed by Benjamin Poulain.
+
+ Save and restore m_currentInstruction around call to ByteCodeParser::inlineCall() as it will
+ use m_currentInstruction during its own parsing. This happens because inlineCall() parses the
+ inlined callee's bytecodes by calling parseCodeBlock() which calls parseBlock() on each block.
+ It is in parseBlock() that we set m_currentInstruction to an instruction before we parse it.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::attemptToInlineCall):
+ (JSC::DFG::ByteCodeParser::parseBlock): Added an ASSERT to catch this issue.
+
+2015-06-16 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, roll out unintended JSC change from https://trac.webkit.org/changeset/185425.
+
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::hasExitSite):
+ (JSC::CodeBlock::exitProfile):
+ (JSC::CodeBlock::numberOfExitSites): Deleted.
+ * bytecode/DFGExitProfile.cpp:
+ (JSC::DFG::ExitProfile::add):
+ * bytecode/DFGExitProfile.h:
+ (JSC::DFG::ExitProfile::hasExitSite):
+ (JSC::DFG::ExitProfile::size): Deleted.
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::inliningCost):
+ * runtime/Options.h:
+
+2015-06-16 Mark Lam <mark.lam@apple.com>
+
+ Use NakedPtr<Exception>& to return exception results.
+ https://bugs.webkit.org/show_bug.cgi?id=145870
+
+ Reviewed by Anders Carlsson and Filip Pizlo.
+
+ Before r185259, calls into the VM takes a JSValue* exception result argument for
+ returning any uncaught exception that may have been thrown while executing JS code.
+ As a result, clients of the VM functions will declare a local JSValue exception
+ result which is automatically initialized to a null value (i.e. the empty value,
+ not the JS null value).
+
+ With r185259, the VM functions were changed to take an Exception*& exception result
+ instead, and the VM functions are responsible for initializing the exception result
+ to null if no exception is thrown.
+
+ This introduces 2 issues:
+
+ 1. the VM functions are vulnerable to modifications that may add early returns
+ before the exception result is nullified. This can result in the exception
+ result being used without initialization.
+
+ 2. Previously, a client could technically use the same exception result for more
+ than one calls into the VM functions. If an earlier call sets it to a thrown
+ value, the thrown value will stick unless a subsequent call throws a different
+ exception.
+
+ With the new Exception*& exception result, the VM functions will always clear
+ the exception result before proceeding. As a result, the client's exception
+ result will be null after the second call even though the first call saw an
+ exception thrown. This is a change in the expected behavior.
+
+ To fix these issues, we'll introduce a NakedPtr smart pointer whose sole purpose
+ is to guarantee that the pointer is initialized. The VM functions will now take
+ a NakedPtr<Exception>& instead of the Exception*&. This ensures that the
+ exception result is initialized.
+
+ The VM functions be also reverted to only set the exception result if a new
+ exception is thrown.
+
+ * API/JSBase.cpp:
+ (JSEvaluateScript):
+ * API/JSScriptRef.cpp:
+ * bindings/ScriptFunctionCall.cpp:
+ (Deprecated::ScriptFunctionCall::call):
+ * bindings/ScriptFunctionCall.h:
+ * debugger/Debugger.cpp:
+ (JSC::Debugger::hasBreakpoint):
+ * debugger/Debugger.h:
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::thisValue):
+ (JSC::DebuggerCallFrame::evaluate):
+ * debugger/DebuggerCallFrame.h:
+ (JSC::DebuggerCallFrame::isValid):
+ * inspector/InjectedScriptManager.cpp:
+ (Inspector::InjectedScriptManager::createInjectedScript):
+ * inspector/InspectorEnvironment.h:
+ * inspector/JSJavaScriptCallFrame.cpp:
+ (Inspector::JSJavaScriptCallFrame::evaluate):
+ * inspector/JavaScriptCallFrame.h:
+ (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
+ (Inspector::JavaScriptCallFrame::thisValue):
+ (Inspector::JavaScriptCallFrame::evaluate):
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::evaluateBreakpointAction):
+ * jsc.cpp:
+ (functionRun):
+ (functionLoad):
+ (runWithScripts):
+ (runInteractive):
+ * runtime/CallData.cpp:
+ (JSC::call):
+ * runtime/CallData.h:
+ * runtime/Completion.cpp:
+ (JSC::checkSyntax):
+ (JSC::evaluate):
+ * runtime/Completion.h:
+ (JSC::evaluate):
+
+2015-06-15 Filip Pizlo <fpizlo@apple.com>
+
+ FTL boolify() UntypedUse is wrong in the masquerades-as-undefined case
+ https://bugs.webkit.org/show_bug.cgi?id=146002
+
+ Reviewed by Darin Adler.
+
+ * ftl/FTLLowerDFGToLLVM.cpp: Put this in an anonymous namespace. We should have done that all along. It makes it easier to add debug code.
+ (JSC::FTL::DFG::LowerDFGToLLVM::boolify): Fix the bug.
+ * tests/stress/logical-not-masquerades.js: Added. This test creates a masquerader so that the watchpoint is invalid. Previously this would fail for the normal object cases.
+ (foo):
+
+2015-06-16 Andreas Kling <akling@apple.com>
+
+ [JSC] Pre-bake final Structure for RegExp matches arrays.
+ <https://webkit.org/b/146006>
+
+ Reviewed by Darin Adler.
+
+ Since we always add the "index" and "input" fields to RegExp matches arrays,
+ cache a finished structure on the global object so we can create these arrays without
+ starting from scratch with a bare array every time.
+
+ 10% progression on Octane/regexp (on my MBP.)
+
+ * runtime/JSArray.h:
+ (JSC::JSArray::create):
+ (JSC::JSArray::tryCreateUninitialized):
+ (JSC::JSArray::createWithButterfly): Factored out JSArray construction into a helper
+ so we can call this from RegExpMatchesArray.cpp.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::regExpMatchesArrayStructure): Add a cached Structure for RegExp
+ subpattern matches arrays.
+
+ * runtime/JSObject.h:
+ (JSC::JSNonFinalObject::finishCreation): Tweak assertion that used to check that
+ JSNonFinalObjects always start out with zero capacity. Since RegExp matches arrays now
+ start out with capacity for 2 properties, that won't work. Change it to check that we
+ don't have inline storage instead, since that should only be used by final objects.
+
+ * runtime/RegExpMatchesArray.h:
+ * runtime/RegExpMatchesArray.cpp:
+ (JSC::tryCreateUninitializedRegExpMatchesArray): Helper to construct a JSArray with
+ the cached Structure and a Butterfly with 2 slots of property storage.
+
+ (JSC::createRegExpMatchesArray):
+ (JSC::createRegExpMatchesArrayStructure): Creates the array Structure that gets cached
+ by the JSGlobalObject.
+
+2015-06-16 Saam Barati <saambarati1@gmail.com>
+
+ LLInt's code path for get_from_scope with case GlobalVarWithVarInjectionChecks has dead code
+ https://bugs.webkit.org/show_bug.cgi?id=144268
+
+ Reviewed by Darin Adler.
+
+ The call to loadVariable(.) both for 32bit and 64bit is unnecessary.
+ It grabs a value that is immediately overwritten by a call to getGlobalVar().
+
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+
+2015-06-14 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Introduce %IteratorPrototype% and drop all XXXIteratorConstructor
+ https://bugs.webkit.org/show_bug.cgi?id=145963
+
+ Reviewed by Darin Adler.
+
+ ES6 iterators inherit %IteratorPrototype%.
+ And these prototype objects of derived iterators don't have @@iterator methods.
+ Instead they use the %IteratorPrototype%[@@iterator] method.
+
+ To encourage inlining in for-of statement, we define this method in JS builtins.
+
+ And these iterator prototype objects don't have any constructor function.
+ This patch drops them (like StringIteratorConstructor).
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * builtins/Iterator.prototype.js: Renamed from Source/JavaScriptCore/runtime/StringIteratorConstructor.cpp.
+ (SymbolIterator):
+ * runtime/ArrayIteratorConstructor.cpp:
+ (JSC::ArrayIteratorConstructor::finishCreation): Deleted.
+ * runtime/ArrayIteratorConstructor.h: Removed.
+ (JSC::ArrayIteratorConstructor::create): Deleted.
+ (JSC::ArrayIteratorConstructor::createStructure): Deleted.
+ (JSC::ArrayIteratorConstructor::ArrayIteratorConstructor): Deleted.
+ * runtime/ArrayIteratorPrototype.cpp:
+ (JSC::ArrayIteratorPrototype::finishCreation):
+ (JSC::arrayIteratorProtoFuncIterator): Deleted.
+ * runtime/IteratorPrototype.cpp: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorConstructor.cpp.
+ (JSC::IteratorPrototype::finishCreation):
+ * runtime/IteratorPrototype.h: Renamed from Source/JavaScriptCore/runtime/SetIteratorConstructor.h.
+ (JSC::IteratorPrototype::create):
+ (JSC::IteratorPrototype::createStructure):
+ (JSC::IteratorPrototype::IteratorPrototype):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::createBuiltinFunction):
+ * runtime/JSFunction.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::iteratorPrototype):
+ * runtime/MapIteratorConstructor.cpp: Removed.
+ (JSC::MapIteratorConstructor::finishCreation): Deleted.
+ * runtime/MapIteratorConstructor.h: Removed.
+ (JSC::MapIteratorConstructor::create): Deleted.
+ (JSC::MapIteratorConstructor::createStructure): Deleted.
+ (JSC::MapIteratorConstructor::MapIteratorConstructor): Deleted.
+ * runtime/MapIteratorPrototype.cpp:
+ (JSC::MapIteratorPrototype::finishCreation): Deleted.
+ (JSC::MapIteratorPrototypeFuncIterator): Deleted.
+ * runtime/SetIteratorConstructor.cpp: Removed.
+ (JSC::SetIteratorConstructor::finishCreation): Deleted.
+ * runtime/SetIteratorConstructor.h:
+ (JSC::SetIteratorConstructor::create): Deleted.
+ (JSC::SetIteratorConstructor::createStructure): Deleted.
+ (JSC::SetIteratorConstructor::SetIteratorConstructor): Deleted.
+ * runtime/SetIteratorPrototype.cpp:
+ (JSC::SetIteratorPrototype::finishCreation): Deleted.
+ (JSC::SetIteratorPrototypeFuncIterator): Deleted.
+ * runtime/StringIteratorConstructor.cpp:
+ (JSC::StringIteratorConstructor::finishCreation): Deleted.
+ * runtime/StringIteratorConstructor.h: Removed.
+ (JSC::StringIteratorConstructor::create): Deleted.
+ (JSC::StringIteratorConstructor::createStructure): Deleted.
+ (JSC::StringIteratorConstructor::StringIteratorConstructor): Deleted.
+ * runtime/StringIteratorPrototype.cpp:
+ (JSC::StringIteratorPrototype::finishCreation):
+ (JSC::stringIteratorPrototypeIterator): Deleted.
+ * tests/stress/iterator-prototype.js: Added.
+ (shouldBe):
+ (inheritIteratorPrototype):
+ (testChain):
+
+2015-06-15 Michael Saboff <msaboff@apple.com>
+
+ JIT bug - fails when inspector closed, works when open
+ https://bugs.webkit.org/show_bug.cgi?id=145243
+
+ Reviewed by Oliver Hunt.
+
+ We need to provide the Arguments object as the base when creating the HeapLocation for
+ GetFromArguments and PutToArguments. Otherwise we endup creating a HeapLocation for
+ any arguments object, not the one we need.
+
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+
+2015-06-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: console.table() with a list of objects no longer works
+ https://bugs.webkit.org/show_bug.cgi?id=145952
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.RemoteObject.prototype._generatePreview):
+ Calling generatePreview again was actually starting with a preview
+ of the current object instead of the sub-value. Go down the other
+ path that correctly generates sub-previews. Leave filtering on the
+ backend unimplemented, which we were already ignoring.
+
+2015-06-13 Youenn Fablet <youenn.fablet@crf.canon.fr>
+
+ [Streams API] ReadableJSStream should handle promises returned by JS source start callback
+ https://bugs.webkit.org/show_bug.cgi?id=145792
+
+ Reviewed by Darin Adler.
+
+ Added support for JSFunction implemented by std::function.
+
+ * runtime/JSFunction.cpp:
+ (JSC::getNativeExecutable): Refactored code to share it with the two JSFunction::create
+ (JSC::JSFunction::create):
+ (JSC::runStdFunction):
+ * runtime/JSFunction.h: Added std::function based JSFunction::create prototype.
+ * runtime.JSPromise.h:
+
+2015-06-12 Gyuyoung Kim <gyuyoung.kim@webkit.org>
+
+ Purge PassRefPtr in JavaScriptCore - 2
+ https://bugs.webkit.org/show_bug.cgi?id=145834
+
+ Reviewed by Darin Adler.
+
+ As a step to remove PassRefPtr, this patch cleans up PassRefPtr as much as possible
+ in JavaScriptCore.
+
+ * API/JSClassRef.cpp:
+ (OpaqueJSClass::create):
+ * API/JSClassRef.h:
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::callerFrame):
+ * debugger/DebuggerCallFrame.h:
+ * dfg/DFGJITCompiler.h:
+ (JSC::DFG::JITCompiler::jitCode):
+ * inspector/ScriptCallStackFactory.cpp:
+ (Inspector::createScriptCallStack):
+ (Inspector::createScriptCallStackForConsole):
+ (Inspector::createScriptCallStackFromException):
+ (Inspector::createScriptArguments):
+ * inspector/ScriptCallStackFactory.h:
+ * jit/ExecutableAllocator.cpp:
+ (JSC::ExecutableAllocator::allocate):
+ * jit/ExecutableAllocator.h:
+ * jit/ExecutableAllocatorFixedVMPool.cpp:
+ (JSC::ExecutableAllocator::allocate):
+ * profiler/LegacyProfiler.cpp:
+ (JSC::LegacyProfiler::stopProfiling):
+ * profiler/LegacyProfiler.h:
+ * runtime/DateInstanceCache.h:
+ * runtime/Executable.cpp:
+ (JSC::ScriptExecutable::newCodeBlockFor):
+ * runtime/Executable.h:
+ * runtime/GenericTypedArrayView.h:
+ * runtime/GenericTypedArrayViewInlines.h:
+ (JSC::GenericTypedArrayView<Adaptor>::create):
+ (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
+
+2015-06-12 Darin Adler <darin@apple.com>
+
+ Fix minor ES6 compliance issue in RegExp.prototype.toString and optimize performance a little
+ https://bugs.webkit.org/show_bug.cgi?id=145935
+
+ Reviewed by Anders Carlsson.
+
+ Test: js/regexp-toString.html
+
+ * runtime/RegExpPrototype.cpp:
+ (JSC::getFlags): Avoid memory allocation for the flags string by returning it in a character
+ buffer instead of constructing a WTF::String for it.
+ (JSC::regExpProtoFuncToString): Require only that the this value be an object; don't require
+ that it is actually a regular expression object. This is covered in the ES6 specification.
+ Also removed comment about the "/(?:)/" trick since that is now the repsonsibility of the
+ getter for the "source" property. Updated to use getFlags so we do one less memory allocation.
+ (JSC::regExpProtoGetterFlags): Chagned to use getFlags instead of the old flagsString.
+
+2015-06-12 Basile Clement <basile_clement@apple.com>
+
+ DFG Object Allocation Sinking should not consider GetClosureVar as escapes
+ https://bugs.webkit.org/show_bug.cgi?id=145904
+
+ Reviewed by Filip Pizlo.
+
+ The object allocation sinking phase is currently able to sink
+ CreateActivation nodes, but will consider any GetClosureVar node as
+ escaping.
+
+ This is not problematic in general as most of the GetClosureVar nodes
+ we would have been able to sink over will have been eliminated by CSE
+ anyway. Still, this is an oversight that we should fix since the
+ machinery is already in place.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPromoteHeapAccess.h:
+ (JSC::DFG::promoteHeapAccess):
+
+2015-06-11 Mark Lam <mark.lam@apple.com>
+
+ WebCore::reportException() needs to be able to accept a raw thrown value in addition to Exception objects.
+ https://bugs.webkit.org/show_bug.cgi?id=145872
+
+ Reviewed by Michael Saboff.
+
+ In r185259, we changed exception handling code inside the VM to work with
+ Exception objects instead of the thrown JSValue. The handling code will get the
+ exception stack trace from the Exception object.
+
+ However, there is some code that cannot be updated to pass the Exception object.
+ An example of this are the ObjC API functions. Those functions are specified to
+ return any thrown exception JSValue in a JSValueRef. Since these APIs are
+ public, we cannot arbitrarily change them to use the Exception object.
+
+ There are client code that calls these APIs and then passes the returned exception
+ JSValue to WebCore::reportException() to be reported. WebCore::reportException()
+ previously relied on the VM::exceptionStackTrace() to provide a cache of the
+ stack trace of the last thrown exception. VM::exceptionStackTrace() no longer
+ exists in the current code.
+
+ To restore this functionality, we will introduce VM::lastException() which
+ caches the last thrown Exception object. With this, if the exception passed to
+ WebCore::reportException() to be reported isn't an Exception object (which has its
+ own stack trace), reportException() can again use the cached exception stack trace
+ which is available from VM::lastException().
+
+ * heap/Heap.cpp:
+ (JSC::Heap::visitException):
+ - visit VM::m_lastException on GCs.
+
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::lastException):
+ (JSC::ExecState::clearLastException):
+ - convenience functions to get and clear the last exception.
+
+ * runtime/Exception.cpp:
+ (JSC::Exception::create):
+ (JSC::Exception::finishCreation):
+ - add support to create an Exception object without capturing the JS stack trace.
+ This is needed for making an Exception object to wrap a thrown value that does
+ not have a stack trace.
+ Currently, this is only used by WebCore::reportException() when there is no
+ Exception object and no last exception available to provide a stack trace.
+
+ * runtime/Exception.h:
+ (JSC::Exception::cast): Deleted. No longer needed.
+
+ * runtime/VM.h:
+ (JSC::VM::clearLastException):
+ (JSC::VM::setException):
+ (JSC::VM::lastException):
+ (JSC::VM::addressOfLastException):
+ - Added support for VM::m_lastException.
+ VM::m_lastException serves to cache the exception stack of the most recently
+ thrown exception like VM::exceptionStackTrace() used to before r185259.
+
+ * runtime/VMEntryScope.cpp:
+ (JSC::VMEntryScope::VMEntryScope):
+ - Clear VM::m_lastException when we re-enter the VM. Exceptions should have been
+ handled before we re-enter the VM anyway. So, this is a good place to release
+ the cached last exception.
+
+ NOTE: this is also where the old code before r185259 clears the last exception
+ stack trace. So, we're just restoring the previous behavior here in terms of
+ the lifecycle of the last exception stack.
+
+2015-06-11 Andreas Kling <akling@apple.com>
+
+ jsSubstring() should support creating substrings from substrings.
+ <https://webkit.org/b/145427>
+
+ Reviewed by Geoffrey Garen
+
+ Tweak jsSubstring() to support base strings that are themselves substrings.
+ They will now share the same grandparent base. This avoids creating a new StringImpl.
+
+ * runtime/JSString.h:
+ (JSC::jsSubstring): Don't force rope resolution here. Instead do that in finishCreation()
+ if the base string is a non-substring rope. Note that resolveRope() is the very last thing
+ called, since it may allocate and the JSRopeString needs to be ready for marking.
+
+ (JSC::JSString::isSubstring): Added a helper to find out if a JSString is
+ a substring. This is just for internal use, so you don't have to cast to
+ JSRopeString for the real substringness flag.
+
+2015-06-11 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r185465.
+ https://bugs.webkit.org/show_bug.cgi?id=145893
+
+ "This patch is breaking 32bit mac build" (Requested by youenn
+ on #webkit).
+
+ Reverted changeset:
+
+ "[Streams API] ReadableJSStream should handle promises
+ returned by JS source start callback"
+ https://bugs.webkit.org/show_bug.cgi?id=145792
+ http://trac.webkit.org/changeset/185465
+
+2015-06-11 Youenn Fablet <youenn.fablet@crf.canon.fr>
+
+ [Streams API] ReadableJSStream should handle promises returned by JS source start callback
+ https://bugs.webkit.org/show_bug.cgi?id=145792
+
+ Reviewed by Darin Adler.
+
+ Added support for JSFunction implemented by std::function.
+
+ * runtime/JSFunction.cpp:
+ (JSC::getNativeExecutable): Refactored code to share it with the two JSFunction::create
+ (JSC::JSFunction::create):
+ (JSC::runStdFunction):
+ * runtime/JSFunction.h: Added std::function based JSFunction::create prototype.
+ * runtime.JSPromise.h:
+
+2015-06-10 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ ASSERTION FAILED: s.length() > 1 on LayoutTests/js/regexp-flags.html
+ https://bugs.webkit.org/show_bug.cgi?id=145599
+
+ Unreviewed, simple follow up patch.
+
+ use jsString instead of jsMakeNontrivialString
+ since the flag string may be trivial (0 or 1 length).
+
+ * runtime/RegExpPrototype.cpp:
+ (JSC::regExpProtoGetterFlags):
+
+2015-06-10 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure
+ https://bugs.webkit.org/show_bug.cgi?id=90678
+
+ Reviewed by Darin Adler.
+
+ After ES6, escaped reserved words in identifiers are prohibited.
+ After parsing Identifier, we should perform `m_buffer16.shrink(0)`.
+
+ * parser/Lexer.cpp:
+ (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
+ * tests/mozilla/ecma_3/Unicode/uc-003.js:
+ (test): Deleted.
+ * tests/stress/reserved-word-with-escape.js: Added.
+ (testSyntax):
+ (testSyntaxError):
+
+2015-06-10 Jordan Harband <ljharb@gmail.com>
+
+ Implement RegExp.prototype.flags
+ https://bugs.webkit.org/show_bug.cgi?id=145599
+
+ Reviewed by Geoffrey Garen.
+ Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-regexp.prototype.flags
+
+ * runtime/CommonIdentifiers.h:
+ * runtime/RegExpPrototype.cpp:
+ (JSC::flagsString):
+ (JSC::regExpProtoFuncToString):
+ (JSC::regExpProtoGetterFlags):
+ * tests/stress/static-getter-in-names.js:
+
+2015-06-10 Filip Pizlo <fpizlo@apple.com>
+
+ DFG ASSERTION FAILED: !iterate() on stress/singleton-scope-then-overwrite.js.ftl-eager
+ https://bugs.webkit.org/show_bug.cgi?id=145853
+
+ Unreviewed, remove the assertion.
+
+ * dfg/DFGCSEPhase.cpp:
+
+2015-06-10 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r185414.
+ https://bugs.webkit.org/show_bug.cgi?id=145844
+
+ broke debug and jsc tests (Requested by alexchristensen on
+ #webkit).
+
+ Reverted changeset:
+
+ "JavaScript: Drop the “escaped reserved words as identifiers”
+ compatibility measure"
+ https://bugs.webkit.org/show_bug.cgi?id=90678
+ http://trac.webkit.org/changeset/185414
+
+2015-06-10 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure
+ https://bugs.webkit.org/show_bug.cgi?id=90678
+
+ Reviewed by Darin Adler.
+
+ After ES6, escaped reserved words in identifiers are prohibited.
+
+ * parser/Lexer.cpp:
+ (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
+ * tests/stress/reserved-word-with-escape.js: Added.
+ (testSyntax):
+ (testSyntaxError):
+
+2015-06-10 Andreas Kling <akling@apple.com>
+
+ [JSC] InlineCallFrame::arguments should be sized-to-fit.
+ <https://webkit.org/b/145782>
+
+ Reviewed by Darin Adler.
+
+ I spotted this Vector<ValueRecovery> looking a bit chubby in Instruments,
+ with 354 kB of memory allocated on cnet.com.
+
+ Use resizeToFit() instead of resize() since we know the final size up front.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
+
+2015-06-09 Chris Dumez <cdumez@apple.com>
+
+ Allow one sync GC per gcTimer interval on critical memory pressure warning
+ https://bugs.webkit.org/show_bug.cgi?id=145773
+
+ Reviewed by Geoffrey Garen.
+
+ On critical memory pressure warning, we were calling GCController::garbageCollectSoon(),
+ which does not offer any guarantee on when the garbage collection will actually take
+ place.
+
+ On critical memory pressure, we need to free up memory as soon as possible to avoid
+ getting killed so this is an issue. Also, the fact that we clear the PageCache on
+ critical memory pressure means a GC would likely be useful, even if the last
+ collection did not free much memory.
+
+ This patch adds a new GCController::garbageCollectNowIfNotDoneRecently() API that allows
+ one synchronous GC per gcTimer interval on critical memory pressure warning. This makes
+ us more responsive to critical memory pressure and avoids doing synchronous GCs too
+ often.
+
+ * heap/FullGCActivityCallback.cpp:
+ (JSC::FullGCActivityCallback::doCollection):
+ * heap/FullGCActivityCallback.h:
+ (JSC::GCActivityCallback::createFullTimer):
+ * heap/GCActivityCallback.h:
+ * heap/Heap.cpp:
+ (JSC::Heap::collectAllGarbageIfNotDoneRecently):
+ * heap/Heap.h:
+
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::doWork): Deleted.
+ * heap/IncrementalSweeper.h:
+
+ Drop fullSweep() API as it no longer seems useful. garbageCollectNow()
+ already does a sweep after the full collection.
+
+2015-06-09 Andreas Kling <akling@apple.com>
+
+ [JSC] CodeBlock::m_constantRegisters should be sized-to-fit.
+ <https://webkit.org/b/145784>
+
+ Reviewed by Darin Adler.
+
+ Spotted this Vector looking chubby on cnet.com, with 1.23 MB of memory
+ allocated below CodeBlock::setConstantRegisters().
+
+ Use resizeToFit() instead since we know the final size up front.
+ Also removed some unused functions that operated on this constants vector
+ and the corresponding one in UnlinkedCodeBlock.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::addOrFindConstant): Deleted.
+ (JSC::CodeBlock::findConstant): Deleted.
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::setConstantRegisters):
+ (JSC::CodeBlock::numberOfConstantRegisters): Deleted.
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::addOrFindConstant): Deleted.
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::numberOfConstantRegisters): Deleted.
+ (JSC::UnlinkedCodeBlock::getConstant): Deleted.
+
+2015-06-09 Andreas Kling <akling@apple.com>
+
+ [JSC] Polymorphic{Get,Put}ByIdList::addAccess() should optimize for size, not speed.
+ <https://webkit.org/b/145786>
+
+ Reviewed by Darin Adler.
+
+ These functions already contained comments saying they optimize for size over speed,
+ but they were using Vector::resize() which adds the usual slack for faster append().
+
+ Switch them over to using Vector::resizeToFit() instead, which makes the Vector
+ allocate a perfectly sized backing store.
+
+ Spotted 670 kB of the GetById ones, and 165 kB of PutById on cnet.com, so these
+ Vectors are definitely worth shrink-wrapping.
+
+ * bytecode/PolymorphicGetByIdList.cpp:
+ (JSC::PolymorphicGetByIdList::addAccess):
+ * bytecode/PolymorphicPutByIdList.cpp:
+ (JSC::PolymorphicPutByIdList::addAccess):
+
+2015-06-09 Andreas Kling <akling@apple.com>
+
+ [JSC] JSPropertyNameEnumerator's property name vector should be sized-to-fit.
+ <https://webkit.org/b/145787>
+
+ Reviewed by Darin Adler.
+
+ Saw 108 kB worth of JSPropertyNameEnumerator backing store Vectors on cnet.com.
+ Use Vector::resizeToFit() since we know the perfect size up front.
+
+ * runtime/JSPropertyNameEnumerator.cpp:
+ (JSC::JSPropertyNameEnumerator::finishCreation):
+
+2015-06-09 Andreas Kling <akling@apple.com>
+
+ FunctionExecutable::isCompiling() is weird and wrong.
+ <https://webkit.org/b/145689>
+
+ Reviewed by Geoffrey Garen.
+
+ Remove FunctionExecutable::isCompiling() and the clearCodeIfNotCompiling() style
+ functions that called it before throwing away code.
+
+ isCompiling() would consider the executable to be "compiling" if it had a CodeBlock
+ but no JITCode. In practice, every executable gets a JITCode at the same time as it
+ gets a CodeBlock, by way of prepareForExecutionImpl().
+
+ * debugger/Debugger.cpp:
+ * heap/Heap.cpp:
+ (JSC::Heap::deleteAllCompiledCode):
+ (JSC::Heap::deleteAllUnlinkedFunctionCode):
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::TypeRecompiler::visit):
+ * runtime/Executable.cpp:
+ (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation):
+ (JSC::FunctionExecutable::clearCodeIfNotCompiling): Deleted.
+ (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilationIfNotCompiling): Deleted.
+ * runtime/Executable.h:
+ * runtime/VM.cpp:
+ (JSC::StackPreservingRecompiler::visit):
+
+2015-06-09 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Introduce getter definition into static hash tables and use it for getters in RegExp.prototype.
+ https://bugs.webkit.org/show_bug.cgi?id=145705
+
+ Reviewed by Darin Adler.
+
+ In this patch, we introduce Accessor type into property tables.
+ With Accessor type, create_hash_table creates a static getter property.
+ This getter property is reified as the same to the static functions.
+
+ In the mean time, we only support getter because `putEntry` and `lookupPut`
+ only work with null setter currently. However, in the spec, there's
+ no need to add static setter properties. So we will add it if it becomes
+ necessary in the future.
+
+ And at the same time, this patch fixes the issue 145738. Before this patch,
+ `putEntry` in `JSObject::deleteProperty` adds `undefined` property if
+ `isValidOffset(...)` is false (deleted). As the result, deleting twice
+ revives the property with `undefined` value.
+
+ If the static functions are reified and the entry is
+ `BuiltinOrFunctionOrAccessor`, there's no need to execute `putEntry` with
+ static hash table entry. They should be handled in the normal structure's
+ looking up because they should be already reified. So added guard for this.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * create_hash_table:
+ * runtime/JSObject.cpp:
+ (JSC::getClassPropertyNames):
+ (JSC::JSObject::put):
+ (JSC::JSObject::deleteProperty):
+ (JSC::JSObject::reifyStaticFunctionsForDelete):
+ * runtime/Lookup.cpp:
+ (JSC::reifyStaticAccessor):
+ (JSC::setUpStaticFunctionSlot):
+ * runtime/Lookup.h:
+ (JSC::HashTableValue::propertyGetter):
+ (JSC::HashTableValue::propertyPutter):
+ (JSC::HashTableValue::accessorGetter):
+ (JSC::HashTableValue::accessorSetter):
+ (JSC::getStaticPropertySlot):
+ (JSC::getStaticValueSlot):
+ (JSC::putEntry):
+ (JSC::reifyStaticProperties):
+ * runtime/PropertySlot.h:
+ * runtime/RegExpObject.cpp:
+ (JSC::RegExpObject::getOwnPropertySlot):
+ (JSC::regExpObjectGlobal): Deleted.
+ (JSC::regExpObjectIgnoreCase): Deleted.
+ (JSC::regExpObjectMultiline): Deleted.
+ (JSC::appendLineTerminatorEscape<LChar>): Deleted.
+ (JSC::appendLineTerminatorEscape<UChar>): Deleted.
+ (JSC::regExpObjectSourceInternal): Deleted.
+ (JSC::regExpObjectSource): Deleted.
+ * runtime/RegExpPrototype.cpp:
+ (JSC::RegExpPrototype::getOwnPropertySlot):
+ (JSC::regExpProtoGetterGlobal):
+ (JSC::regExpProtoGetterIgnoreCase):
+ (JSC::regExpProtoGetterMultiline):
+ (JSC::appendLineTerminatorEscape<LChar>):
+ (JSC::appendLineTerminatorEscape<UChar>):
+ (JSC::regExpProtoGetterSourceInternal):
+ (JSC::regExpProtoGetterSource):
+ * tests/stress/static-function-delete.js: Added.
+ (shouldBe):
+ * tests/stress/static-function-put.js: Added.
+ (shouldBe):
+ * tests/stress/static-getter-delete.js: Added.
+ (shouldBe):
+ (shouldThrow):
+ * tests/stress/static-getter-descriptors.js: Added.
+ (shouldBe):
+ * tests/stress/static-getter-enumeration.js: Added.
+ (shouldBe):
+ * tests/stress/static-getter-get.js: Added.
+ (shouldBe):
+ * tests/stress/static-getter-in-names.js: Added.
+ (shouldBe):
+ * tests/stress/static-getter-names.js: Added.
+ (shouldBe):
+ * tests/stress/static-getter-put.js: Added.
+ (shouldBe):
+ (shouldThrow):
+
+2015-06-09 Andreas Kling <akling@apple.com>
+
+ [JSC] JSString::getIndex() should avoid reifying substrings.
+ <https://webkit.org/b/145803>
+
+ Reviewed by Darin Adler.
+
+ Implement getIndex() using JSString::view(), which cuts it down to a one-liner
+ and also avoids reifying substrings.
+
+ I saw 178 kB of reified substrings below operationGetByVal -> getIndex()
+ on cnet.com, so this should help.
+
+ * runtime/JSString.cpp:
+ (JSC::JSRopeString::getIndexSlowCase): Deleted.
+ * runtime/JSString.h:
+ (JSC::JSString::getIndex):
+
+2015-06-09 Andreas Kling <akling@apple.com>
+
+ [JSC] String.prototype.indexOf() should use StringView.
+ <https://webkit.org/b/145351>
+
+ Reviewed by Darin Adler.
+
+ Use StringView::find() to implement String.prototype.indexOf().
+ This avoids reifying the needle and haystack JSStrings in case they
+ are substrings.
+
+ Reduces malloc memory by ~190 kB on cnet.com.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncIndexOf):
+
+2015-06-09 Csaba Osztrogonác <ossy@webkit.org>
+
+ [cmake] Fix the style issues in cmake project files
+ https://bugs.webkit.org/show_bug.cgi?id=145755
+
+ Reviewed by Darin Adler.
+
+ * CMakeLists.txt:
+
+2015-06-08 Gyuyoung Kim <gyuyoung.kim@webkit.org>
+
+ Purge PassRefPtr in JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=145750
+
+ As a step to purge PassRefPtr, this patch replaces PassRefPtr with Ref or RefPtr.
+
+ Reviewed by Darin Adler.
+
+ * API/JSClassRef.cpp:
+ (OpaqueJSClass::createNoAutomaticPrototype):
+ * API/JSClassRef.h:
+ * API/JSContextRef.cpp:
+ * API/JSScriptRef.cpp:
+ (OpaqueJSScript::create):
+ * API/JSStringRef.cpp:
+ (JSStringCreateWithCharacters):
+ (JSStringCreateWithUTF8CString):
+ * API/OpaqueJSString.cpp:
+ (OpaqueJSString::create):
+ * API/OpaqueJSString.h:
+ (OpaqueJSString::create):
+ * bytecompiler/StaticPropertyAnalysis.h:
+ (JSC::StaticPropertyAnalysis::create):
+ * debugger/DebuggerCallFrame.h:
+ (JSC::DebuggerCallFrame::create):
+ * dfg/DFGToFTLDeferredCompilationCallback.cpp:
+ (JSC::DFG::ToFTLDeferredCompilationCallback::create):
+ * dfg/DFGToFTLDeferredCompilationCallback.h:
+ * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
+ (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
+ (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::create): Deleted.
+ * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
+ * dfg/DFGWorklist.cpp:
+ (JSC::DFG::Worklist::create):
+ (JSC::DFG::ensureGlobalDFGWorklist):
+ (JSC::DFG::ensureGlobalFTLWorklist):
+ * dfg/DFGWorklist.h:
+ * heap/EdenGCActivityCallback.h:
+ (JSC::GCActivityCallback::createEdenTimer):
+ * heap/FullGCActivityCallback.h:
+ (JSC::GCActivityCallback::createFullTimer):
+ * heap/GCActivityCallback.h:
+ * inspector/InjectedScriptHost.h:
+ * inspector/JavaScriptCallFrame.h:
+ (Inspector::JavaScriptCallFrame::create):
+ * inspector/ScriptArguments.cpp:
+ (Inspector::ScriptArguments::create):
+ * inspector/ScriptArguments.h:
+ * jit/JITStubRoutine.h:
+ (JSC::JITStubRoutine::createSelfManagedRoutine):
+ * jit/JITToDFGDeferredCompilationCallback.cpp:
+ (JSC::JITToDFGDeferredCompilationCallback::create):
+ * jit/JITToDFGDeferredCompilationCallback.h:
+ * jsc.cpp:
+ (jscmain):
+ * parser/NodeConstructors.h:
+ (JSC::ArrayPatternNode::create):
+ (JSC::ObjectPatternNode::create):
+ (JSC::BindingNode::create):
+ * parser/Nodes.cpp:
+ (JSC::FunctionParameters::create):
+ * parser/Nodes.h:
+ * parser/SourceProvider.h:
+ (JSC::StringSourceProvider::create):
+ * profiler/Profile.cpp:
+ (JSC::Profile::create):
+ * profiler/Profile.h:
+ * profiler/ProfileGenerator.cpp:
+ (JSC::ProfileGenerator::create):
+ * profiler/ProfileGenerator.h:
+ * profiler/ProfileNode.h:
+ (JSC::ProfileNode::create):
+ * runtime/DataView.cpp:
+ (JSC::DataView::create):
+ * runtime/DataView.h:
+ * runtime/DateInstanceCache.h:
+ (JSC::DateInstanceData::create):
+ * runtime/JSPromiseReaction.cpp:
+ (JSC::createExecutePromiseReactionMicrotask):
+ * runtime/JSPromiseReaction.h:
+ * runtime/PropertyNameArray.h:
+ (JSC::PropertyNameArrayData::create):
+ * runtime/TypeSet.h:
+ (JSC::StructureShape::create):
+ (JSC::TypeSet::create):
+ * runtime/TypedArrayBase.h:
+ (JSC::TypedArrayBase::create):
+ (JSC::TypedArrayBase::createUninitialized):
+ (JSC::TypedArrayBase::subarrayImpl):
+ * runtime/VM.cpp:
+ (JSC::VM::createContextGroup):
+ (JSC::VM::create):
+ (JSC::VM::createLeaked):
+ * runtime/VM.h:
+ * yarr/RegularExpression.cpp:
+ (JSC::Yarr::RegularExpression::Private::create):
+
+2015-06-08 Filip Pizlo <fpizlo@apple.com>
+
+ It should be possible to hoist all constants in DFG SSA
+ https://bugs.webkit.org/show_bug.cgi?id=145769
+
+ Reviewed by Geoffrey Garen.
+
+ It's sometimes somewhat more efficient, and convenient, to have all constants at the
+ top of the root block. We don't require this as an IR invariant because too many phases
+ want to be able to insert constants in weird places. But, this phase will be great for
+ preparing for https://bugs.webkit.org/show_bug.cgi?id=145768.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGConstantHoistingPhase.cpp: Added.
+ (JSC::DFG::performConstantHoisting):
+ * dfg/DFGConstantHoistingPhase.h: Added.
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+
+2015-06-07 Filip Pizlo <fpizlo@apple.com>
+
+ The tiny set magic in StructureSet should be available in WTF
+ https://bugs.webkit.org/show_bug.cgi?id=145722
+
+ Reviewed by Geoffrey Garen.
+
+ I moved the generic logic of small sets of pointers and moved it into WTF. Now,
+ StructureSet is a subclass of TinyPtrSet<Structure*>. There shouldn't be any functional
+ change.
+
+ * bytecode/StructureSet.cpp:
+ (JSC::StructureSet::filter):
+ (JSC::StructureSet::filterArrayModes):
+ (JSC::StructureSet::speculationFromStructures):
+ (JSC::StructureSet::arrayModesFromStructures):
+ (JSC::StructureSet::dumpInContext):
+ (JSC::StructureSet::dump):
+ (JSC::StructureSet::clear): Deleted.
+ (JSC::StructureSet::add): Deleted.
+ (JSC::StructureSet::remove): Deleted.
+ (JSC::StructureSet::contains): Deleted.
+ (JSC::StructureSet::merge): Deleted.
+ (JSC::StructureSet::exclude): Deleted.
+ (JSC::StructureSet::isSubsetOf): Deleted.
+ (JSC::StructureSet::overlaps): Deleted.
+ (JSC::StructureSet::operator==): Deleted.
+ (JSC::StructureSet::addOutOfLine): Deleted.
+ (JSC::StructureSet::containsOutOfLine): Deleted.
+ (JSC::StructureSet::copyFromOutOfLine): Deleted.
+ (JSC::StructureSet::OutOfLineList::create): Deleted.
+ (JSC::StructureSet::OutOfLineList::destroy): Deleted.
+ * bytecode/StructureSet.h:
+ (JSC::StructureSet::onlyStructure):
+ (JSC::StructureSet::StructureSet): Deleted.
+ (JSC::StructureSet::operator=): Deleted.
+ (JSC::StructureSet::~StructureSet): Deleted.
+ (JSC::StructureSet::isEmpty): Deleted.
+ (JSC::StructureSet::genericFilter): Deleted.
+ (JSC::StructureSet::isSupersetOf): Deleted.
+ (JSC::StructureSet::size): Deleted.
+ (JSC::StructureSet::at): Deleted.
+ (JSC::StructureSet::operator[]): Deleted.
+ (JSC::StructureSet::last): Deleted.
+ (JSC::StructureSet::iterator::iterator): Deleted.
+ (JSC::StructureSet::iterator::operator*): Deleted.
+ (JSC::StructureSet::iterator::operator++): Deleted.
+ (JSC::StructureSet::iterator::operator==): Deleted.
+ (JSC::StructureSet::iterator::operator!=): Deleted.
+ (JSC::StructureSet::begin): Deleted.
+ (JSC::StructureSet::end): Deleted.
+ (JSC::StructureSet::ContainsOutOfLine::ContainsOutOfLine): Deleted.
+ (JSC::StructureSet::ContainsOutOfLine::operator()): Deleted.
+ (JSC::StructureSet::copyFrom): Deleted.
+ (JSC::StructureSet::OutOfLineList::list): Deleted.
+ (JSC::StructureSet::OutOfLineList::OutOfLineList): Deleted.
+ (JSC::StructureSet::deleteStructureListIfNecessary): Deleted.
+ (JSC::StructureSet::isThin): Deleted.
+ (JSC::StructureSet::pointer): Deleted.
+ (JSC::StructureSet::singleStructure): Deleted.
+ (JSC::StructureSet::structureList): Deleted.
+ (JSC::StructureSet::set): Deleted.
+ (JSC::StructureSet::setEmpty): Deleted.
+ (JSC::StructureSet::getReservedFlag): Deleted.
+ (JSC::StructureSet::setReservedFlag): Deleted.
+ * dfg/DFGStructureAbstractValue.cpp:
+ (JSC::DFG::StructureAbstractValue::clobber):
+ (JSC::DFG::StructureAbstractValue::filter):
+ (JSC::DFG::StructureAbstractValue::filterSlow):
+ (JSC::DFG::StructureAbstractValue::contains):
+ * dfg/DFGStructureAbstractValue.h:
+ (JSC::DFG::StructureAbstractValue::makeTop):
+
+2015-06-08 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Add the missing setupArgumentsWithExecState functions after r185240
+ https://bugs.webkit.org/show_bug.cgi?id=145754
+
+ Reviewed by Benjamin Poulain.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+
+2015-06-08 Brady Eidson <beidson@apple.com>
+
+ Completely remove all IDB properties/constructors when it is disabled at runtime.
+ rdar://problem/18429374 and https://bugs.webkit.org/show_bug.cgi?id=137034
+
+ Reviewed by Geoffrey Garen.
+
+ * runtime/CommonIdentifiers.h:
+
+2015-06-06 Mark Lam <mark.lam@apple.com>
+
+ Returned Exception* values need to be initialized to nullptr when no exceptions are thrown.
+ https://bugs.webkit.org/show_bug.cgi?id=145720
+
+ Reviewed by Dan Bernstein.
+
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::evaluate):
+
+2015-06-05 Mark Lam <mark.lam@apple.com>
+
+ Subclasses of JSNonFinalObject with gc'able children need to implement visitChildren().
+ https://bugs.webkit.org/show_bug.cgi?id=145709
+
+ Reviewed by Geoffrey Garen.
+
+ * jsc.cpp:
+ (functionSetElementRoot):
+ - The Element class has a member of type Root which extends JSDestructibleObject.
+ It should be stored in a WriteBarrier, and visited by visitChildren().
+
+ * runtime/ClonedArguments.cpp:
+ (JSC::ClonedArguments::materializeSpecialsIfNecessary):
+ (JSC::ClonedArguments::visitChildren):
+ * runtime/ClonedArguments.h:
+ - Add missing visitChildren().
+
+ * tests/stress/cloned-arguments-should-visit-callee-during-gc.js: Added.
+ (makeTransientFunction.transientFunc):
+ (makeTransientFunction):
+
+2015-06-05 Geoffrey Garen <ggaren@apple.com>
+
+ DropAllLocks RELEASE_ASSERT on iOS
+ https://bugs.webkit.org/show_bug.cgi?id=139654
+
+ Reviewed by Mark Lam.
+
+ * runtime/JSLock.cpp:
+ (JSC::JSLock::dropAllLocks): Removed a comment because it duplicated
+ the code beneath it. Removed a FIXME because we can't ASSERT that
+ we're holding the lock. WebKit1 on iOS drops the lock before calling to
+ delegates, not knowing whether it holds the lock or not.
+
+ (JSC::JSLock::DropAllLocks::DropAllLocks): Only ASSERT that we are not
+ GC'ing if we hold the lock. If we do not hold the lock, it is perfectly
+ valid for some other thread, which does hold the lock, to be GC'ing.
+ What is not valid is to drop the lock in the middle of GC, since GC
+ must be atomic.
+
+2015-06-05 Filip Pizlo <fpizlo@apple.com>
+
+ speculateRealNumber() should early exit if you're already a real number, not if you're already a real double.
+
+ Rubber stamped by Mark Lam.
+
+ This was causing: https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r185261%20(5180)/webaudio/note-grain-on-timing-crash-log.txt
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::speculateRealNumber):
+
+2015-06-05 Mark Lam <mark.lam@apple.com>
+
+ finally blocks should not set the exception stack trace when re-throwing the exception.
+ https://bugs.webkit.org/show_bug.cgi?id=145525
+
+ Reviewed by Geoffrey Garen.
+
+ How exceptions presently work:
+ =============================
+ 1. op_throw can throw any JSValue.
+ 2. the VM tries to capture the stack at the throw point and propagate that as needed.
+ 3. finally blocks are implemented using op_catch to catch the thrown value, and throws it again using op_throw.
+
+ What's wrong with how it presently works:
+ ========================================
+ 1. finally's makes for bad exception throw line numbers in the Inspector console.
+
+ The op_throw in finally will throw the value anew i.e. it captures a stack from the re-throw point.
+ As a result, the Inspector sees the finally block as the throw point. The original stack is lost.
+
+ 2. finally's breaks the Inspector's "Breaks on Uncaught Exception"
+
+ This is because finally blocks are indistinguishable from catch blocks. As a result, a try-finally,
+ which should break in the Inspector on the throw, does not because the Inspector thought the
+ exception was "caught".
+
+ 3. finally's yields confusing break points when the Inspector "Breaks on All Exceptions"
+
+ a. In a try-finally scenario, the Inspector breaks 2 times: 1 at the throw, 1 at the finally.
+ b. In a for-of loop (which has synthesized finallys), the Inspector will do another break.
+ Similarly for other cases of JS code which synthesize finallys.
+ c. At VM re-entry boundaries (e.g. js throws & returns to native code, which returns to js),
+ the Inspector will do another break if there's an uncaught exception.
+
+ How this patch fixes the issues:
+ ===============================
+ 1. We introduce an Exception object that wraps the thrown value and the exception stack.
+
+ When throwing an exception, the VM will check if the thrown value is an Exception
+ object or not. If it is not an Exception object, then we must be throwing a new
+ exception. The VM will create an Exception object to wrap the thrown value and
+ capture the current stack for it.
+
+ If the thrown value is already an Exception object, then the requested throw operation
+ must be a re-throw. The VM will not capture a new stack for it.
+
+ 2. op_catch will now populate 2 locals: 1 for the Exception, 1 for the thrown JSValue.
+
+ The VM is aware of the Exception object and uses it for rethrows in finally blocks.
+ JS source code is never aware of the Exception object.
+
+ JS code is aware of the thrown value. If it throws the caught thrown value, that
+ constitutes a new throw, and a new Exception object will be created for it.
+
+ 3. The VM no longer tracks the thrown JSValue and the exception stack. It will only
+ track a m_exception field which is an Exception*.
+
+ 4. The BytecodeGenerator has already been updated in a prior patch to distinguish
+ between Catch, Finally, and SynthesizedFinally blocks. The interpreter runtime will
+ now report to the debugger whether we have a Catch handler, not just any handlers.
+
+ The debugger will use this detail to determine whether to break or not. "Break on
+ uncaught exceptions" will only break if no Catch handler was found.
+
+ This solves the issue of the debugger breaking at finally blocks, and for-of statements.
+
+ 5. The Exception object will also have a flag to indicate whether the debugger has been
+ notified of the Exception being thrown. Once the Interpreter notifies the debugger
+ of the Exception object, it will mark this flag and not repeat the notify the debugger
+ again of the same Exception.
+
+ This solves the issue of the debugger breaking at VM re-entry points due to uncaught
+ exceptions.
+
+ 6. The life-cycle of the captured exception stack trace will now follow the life-cycle
+ of the Exception object.
+
+ Other changes:
+ 7. Change all clients of the VM::exception() to expect an Exception* instead of JSValue.
+
+ 8. Fixed a few bugs where thrown exceptions are not cleared before exiting the VM.
+
+ 9. Also renamed some variables and classes to better describe what they are.
+
+ * API/JSBase.cpp:
+ (JSEvaluateScript):
+ (JSCheckScriptSyntax):
+
+ * API/JSObjectRef.cpp:
+ (handleExceptionIfNeeded):
+ - The functions below all do the same exception check. Added this helper
+ to simplify the code.
+ (JSClassCreate):
+ (JSObjectMakeFunction):
+ (JSObjectMakeArray):
+ (JSObjectMakeDate):
+ (JSObjectMakeError):
+ (JSObjectMakeRegExp):
+ (JSObjectGetProperty):
+ (JSObjectSetProperty):
+ (JSObjectGetPropertyAtIndex):
+ (JSObjectSetPropertyAtIndex):
+ (JSObjectDeleteProperty):
+ (JSObjectCallAsFunction):
+ (JSObjectCallAsConstructor):
+
+ * API/JSScriptRef.cpp:
+ * API/JSValue.mm:
+ (JSContainerConvertor::take):
+ (reportExceptionToInspector):
+
+ * API/JSValueRef.cpp:
+ (handleExceptionIfNeeded):
+ - The functions below all do the same exception check. Added this helper
+ to simplify the code.
+ (evernoteHackNeeded):
+ (JSValueIsEqual):
+ (JSValueIsInstanceOfConstructor):
+ (JSValueCreateJSONString):
+ (JSValueToNumber):
+ (JSValueToStringCopy):
+ (JSValueToObject):
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ - Added new files Exception.h and Exception.cpp.
+
+ * bindings/ScriptFunctionCall.cpp:
+ (Deprecated::ScriptFunctionCall::call):
+ * bindings/ScriptFunctionCall.h:
+
+ * bytecode/BytecodeList.json:
+ - op_catch now had 2 operands: the exception register, and the thrown value register.
+
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ (JSC::CodeBlock::handlerForBytecodeOffset):
+ * bytecode/CodeBlock.h:
+ - handlerForBytecodeOffset() now can look for just Catch handlers only.
+
+ * bytecode/HandlerInfo.h:
+ - Cleaned up some white space I accidentally added in a previous patch.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::pushTry):
+ (JSC::BytecodeGenerator::popTryAndEmitCatch):
+ (JSC::BytecodeGenerator::emitThrowReferenceError):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::emitThrow):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::TryNode::emitBytecode):
+ - Adding support for op_catch's 2 operands.
+
+ * debugger/Debugger.cpp:
+ (JSC::Debugger::hasBreakpoint):
+ (JSC::Debugger::pauseIfNeeded):
+ (JSC::Debugger::exception):
+ * debugger/Debugger.h:
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::thisValue):
+ (JSC::DebuggerCallFrame::evaluate):
+ * debugger/DebuggerCallFrame.h:
+ (JSC::DebuggerCallFrame::isValid):
+ * inspector/InjectedScriptManager.cpp:
+ (Inspector::InjectedScriptManager::createInjectedScript):
+ * inspector/InspectorEnvironment.h:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
+ (Inspector::JSGlobalObjectInspectorController::reportAPIException):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/JSGlobalObjectScriptDebugServer.h:
+ * inspector/JSJavaScriptCallFrame.cpp:
+ (Inspector::JSJavaScriptCallFrame::evaluate):
+ * inspector/JavaScriptCallFrame.h:
+ (Inspector::JavaScriptCallFrame::vmEntryGlobalObject):
+ (Inspector::JavaScriptCallFrame::thisValue):
+ (Inspector::JavaScriptCallFrame::evaluate):
+ * inspector/ScriptCallStackFactory.cpp:
+ (Inspector::extractSourceInformationFromException):
+ (Inspector::createScriptCallStackFromException):
+ * inspector/ScriptCallStackFactory.h:
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::evaluateBreakpointAction):
+ (Inspector::ScriptDebugServer::handleBreakpointHit):
+ (Inspector::ScriptDebugServer::handleExceptionInBreakpointCondition):
+ * inspector/ScriptDebugServer.h:
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::clearException):
+ (JSC::ExecState::exception):
+ (JSC::ExecState::hadException):
+ (JSC::ExecState::atomicStringTable):
+ (JSC::ExecState::propertyNames):
+ (JSC::ExecState::clearSupplementaryExceptionInfo): Deleted.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::unwindCallFrame):
+ (JSC::Interpreter::stackTraceAsString):
+ (JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
+ (JSC::GetCatchHandlerFunctor::operator()):
+ (JSC::Interpreter::unwind):
+ - Added a check for didNotifyInspectorOfThrow() here to prevent duplicate reports
+ of the same Exception to the debugger.
+
+ (JSC::GetExceptionHandlerFunctor::GetExceptionHandlerFunctor): Deleted.
+ (JSC::GetExceptionHandlerFunctor::operator()): Deleted.
+ - Renamed GetExceptionHandlerFunctor to GetCatchHandlerFunctor since the debugger
+ is only interested in knowing whether we have Catch handlers.
+
+ * interpreter/Interpreter.h:
+ (JSC::SuspendExceptionScope::SuspendExceptionScope):
+ (JSC::SuspendExceptionScope::~SuspendExceptionScope):
+ (JSC::Interpreter::sampler):
+ (JSC::ClearExceptionScope::ClearExceptionScope): Deleted.
+ (JSC::ClearExceptionScope::~ClearExceptionScope): Deleted.
+ - Renamed ClearExceptionScope to SuspendExceptionScope because "clear" implies that
+ we're purging the exception. Instead, we're merely suspending any handling of
+ that exception for a period defined by the scope.
+
+ * jit/AssemblyHelpers.cpp:
+ (JSC::AssemblyHelpers::emitExceptionCheck):
+
+ * jit/JITExceptions.cpp:
+ (JSC::genericUnwind):
+ - Removed the exception argument. It is always the value in VM::exception() anyway.
+ genericUnwind() can just get it from the VM, and save everyone some work.
+
+ * jit/JITExceptions.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_catch):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::privateCompileCTINativeCall):
+ (JSC::JIT::emit_op_catch):
+ - Add support for the new op_catch operands.
+
+ * jit/JITOperations.cpp:
+ * jit/ThunkGenerators.cpp:
+ (JSC::nativeForGenerator):
+ * jsc.cpp:
+ (functionRun):
+ (functionLoad):
+ (runWithScripts):
+ (runInteractive):
+ * llint/LLIntOffsetsExtractor.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ - Add support for the new op_catch operands. Also update the code to handle
+ VM::m_exception being an Exception pointer, not a JSValue.
+
+ * parser/NodeConstructors.h:
+ (JSC::TryNode::TryNode):
+ * parser/Nodes.h:
+ * runtime/CallData.cpp:
+ (JSC::call):
+ * runtime/CallData.h:
+
+ * runtime/Completion.cpp:
+ (JSC::evaluate):
+ * runtime/Completion.h:
+ (JSC::evaluate):
+ - Change evaluate() to take a reference to the returned exception value instead
+ of a pointer. In all but 2 or 3 cases, we want the returned exception anyway.
+ Might as well simplify the code by requiring the reference.
+
+ * runtime/Error.h:
+ (JSC::throwVMError):
+ (JSC::throwVMTypeError):
+
+ * runtime/Exception.cpp: Added.
+ (JSC::Exception::create):
+ (JSC::Exception::destroy):
+ (JSC::Exception::createStructure):
+ (JSC::Exception::visitChildren):
+ (JSC::Exception::Exception):
+ (JSC::Exception::~Exception):
+ * runtime/Exception.h: Added.
+ (JSC::Exception::valueOffset):
+ (JSC::Exception::cast):
+ (JSC::Exception::value):
+ (JSC::Exception::stack):
+ (JSC::Exception::didNotifyInspectorOfThrow):
+ (JSC::Exception::setDidNotifyInspectorOfThrow):
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::createTerminatedExecutionException):
+ (JSC::isTerminatedExecutionException):
+ (JSC::createStackOverflowError):
+ * runtime/ExceptionHelpers.h:
+ * runtime/GetterSetter.cpp:
+ (JSC::callGetter):
+ * runtime/IteratorOperations.cpp:
+ (JSC::iteratorClose):
+ * runtime/JSObject.cpp:
+ * runtime/JSPromiseConstructor.cpp:
+ (JSC::constructPromise):
+ * runtime/JSPromiseDeferred.cpp:
+ (JSC::updateDeferredFromPotentialThenable):
+ (JSC::abruptRejection):
+ * runtime/JSPromiseReaction.cpp:
+ (JSC::ExecutePromiseReactionMicrotask::run):
+
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ (JSC::VM::releaseExecutableMemory):
+ (JSC::VM::throwException):
+ (JSC::VM::setStackPointerAtVMEntry):
+ (JSC::VM::getExceptionInfo): Deleted.
+ (JSC::VM::setExceptionInfo): Deleted.
+ (JSC::VM::clearException): Deleted.
+ (JSC::clearExceptionStack): Deleted.
+ * runtime/VM.h:
+ (JSC::VM::targetMachinePCForThrowOffset):
+ (JSC::VM::clearException):
+ (JSC::VM::setException):
+ (JSC::VM::exception):
+ (JSC::VM::addressOfException):
+ (JSC::VM::exceptionStack): Deleted.
+ * runtime/VMEntryScope.cpp:
+ (JSC::VMEntryScope::VMEntryScope):
+ (JSC::VMEntryScope::setEntryScopeDidPopListener):
+
+2015-06-04 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Always track out-of-bounds array access explicitly instead of relying on the slow case
+ https://bugs.webkit.org/show_bug.cgi?id=145673
+
+ Reviewed by Geoffrey Garen.
+
+ Previously, we were deciding to use out-of-bounds speculation based on two informations:
+ -Explicitly detected out-of-bounds accesses tracked on ArrayProfile.
+ -The number of time we took the slow cases in the baseline JIT.
+
+ The heuristic based on slow cases was a little too fragile.
+
+ In some cases, we were running into that limit just because the indexing type changes between
+ two values (typically Int32Array and DoubleArray). Sometimes we were just unlucky on what
+ we used for the inline cache.
+
+ In Kraken, this was hurting us on "audio-beat-detection" and "audio-fft". The array types we see
+ change between Int32 and Double. We run into the slow path a bit but never hit
+ out-of-bounds.
+
+ By the time we compile in DFG, we have stable Double Arrays but we speculate out-of-bounds based
+ on the number of slow cases we took. Because of that, we start boxing the double on GetByVal,
+ using DoubleRep, etc. adding a ton of overhead over otherwise very simple operations.
+
+ WebXPRT was also suffering from this problem but the other way arround: we were missing
+ the out-of-bounds accesses due to changes in indexing types, we were below the threshold
+ of slow-path access, thus we predicted in-bounds accesses for code that was doing plenty
+ of out-of-bands.
+
+
+ This patch fixes the problem by tracking the out-of-bounds access explicitly any time we go
+ into the slow path in baseline JIT. Since we no longer miss any out-of-bounds, we can remove
+ the slow-path heuristic.
+
+ There is new additional special case in the C code regarding out-of-bounds: Arguments access.
+ Mispredicting out-of-bounds accesses on arguments is a disaster for performance, so those are
+ tracked in the way DFG expect it.
+
+
+ There are a few important cases that are still not covered optimally:
+ -PutByVal on Arguments.
+ -Get/Put ByVal on TypedArray.
+ Those are simply not used by DFG in any way. TypedArrays should probably be looked at in the future.
+
+ * bytecode/ArrayProfile.cpp:
+ (JSC::ArrayProfile::computeUpdatedPrediction):
+ The inline-cache repatch cases now update the ArrayProfile information. This has no value in baseline
+ JIT but it helps avoiding one recompile in DFG for the missing ArrayProfile information.
+
+ * bytecode/ArrayProfile.h:
+ (JSC::ArrayProfile::setOutOfBounds):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::getArrayMode):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath): Deleted.
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emitSlow_op_has_indexed_property):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emitSlow_op_has_indexed_property):
+ * jit/JITOperations.cpp:
+ (JSC::canUseFastArgumentAccess):
+ This is not my favorite part of this patch.
+
+ I tried having JSObject::canGetIndexQuickly() handle arguments which would put everything
+ on the generic path. Unfortunately, that code is very performance sensitive and some benchmarks were
+ impacted by over 10%
+
+ I left JSObject::canGetIndexQuickly() alone, and I added the canUseFastArgumentAccess() mirroring
+ how DFG uses out-of-bounds for Arguments.
+
+ (JSC::getByVal):
+ * jit/JITOperations.h:
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitSlow_op_get_by_val):
+ (JSC::JIT::emitSlow_op_put_by_val):
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emitSlow_op_get_by_val):
+ (JSC::JIT::emitSlow_op_put_by_val):
+ * runtime/JSPromiseFunctions.cpp:
+ * tests/stress/get-by-val-out-of-bounds-basics.js: Added.
+ (opaqueGetByValOnInt32ArrayEarlyOutOfBounds):
+ (testInt32ArrayEarlyOutOfBounds):
+ (testIndexingTypeChangesOnInt32Array):
+ (opaqueGetByValOnStringArrayHotOutOfBounds):
+ (testStringArrayHotOutOfBounds):
+ (testIndexingTypeChangesOnStringArray):
+ (opaqueGetByValOnStringAndInt32ArrayHotOutOfBounds):
+ (testStringAndInt32ArrayHotOutOfBounds):
+ (opaqueGetByValOnDoubleArrayHotOutOfBounds):
+ * tests/stress/put-by-val-out-of-bounds-basics.js: Added.
+ (opaquePutByValOnInt32ArrayEarlyOutOfBounds):
+ (testInt32ArrayEarlyOutOfBounds):
+ (opaquePutByValOnStringArrayHotOutOfBounds):
+ (testStringArrayHotOutOfBounds):
+
+2015-06-03 Filip Pizlo <fpizlo@apple.com>
+
+ Simplify unboxing of double JSValues known to be not NaN and not Int32
+ https://bugs.webkit.org/show_bug.cgi?id=145618
+
+ Reviewed by Geoffrey Garen.
+
+ In many cases we know that we most likely loaded a non-NaN double value from the heap.
+ Prior to this patch, we would do two branches before unboxing the double. This patch
+ reduces this to one branch in the common case. Before:
+
+ if (is int32)
+ unbox int32 and convert to double
+ else if (is number)
+ unbox double
+ else
+ exit
+
+ After:
+
+ tmp = unbox double
+ if (tmp == tmp)
+ done
+ else if (is int32)
+ unbox int32 and convert to double
+ else
+ exit
+
+ We only use the new style if we have profiling that tells us that we are unlikely to see
+ either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
+
+ This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
+
+ Rolling this back in after I made DFG::SpeculativeJIT call a new version of unboxDouble()
+ that doesn't assert that the JSValue is a double, since we are intentionally using it
+ before doing the "is a double" test. This wasn't a problem on 32-bit since unboxDouble()
+ does no such assertion on 32-bit.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::observeUseKindOnNode):
+ (JSC::DFG::FixupPhase::fixEdgeRepresentation):
+ (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::shouldSpeculateDouble):
+ (JSC::DFG::Node::shouldSpeculateDoubleReal):
+ (JSC::DFG::Node::shouldSpeculateNumber):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::SafeToExecuteEdge::operator()):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileDoubleRep):
+ (JSC::DFG::SpeculativeJIT::speculateNumber):
+ (JSC::DFG::SpeculativeJIT::speculateRealNumber):
+ (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
+ (JSC::DFG::SpeculativeJIT::speculate):
+ (JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGUseKind.cpp:
+ (WTF::printInternal):
+ * dfg/DFGUseKind.h:
+ (JSC::DFG::typeFilterFor):
+ (JSC::DFG::isNumerical):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
+ (JSC::FTL::LowerDFGToLLVM::boxDouble):
+ (JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
+ (JSC::FTL::LowerDFGToLLVM::speculate):
+ (JSC::FTL::LowerDFGToLLVM::speculateNumber):
+ (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
+ (JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
+ (JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::branchIfNotOther):
+ (JSC::AssemblyHelpers::branchIfInt32):
+ (JSC::AssemblyHelpers::branchIfNotInt32):
+ (JSC::AssemblyHelpers::branchIfNumber):
+
+2015-06-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Class constructor appearing as Object Tree property does not include parameters
+ https://bugs.webkit.org/show_bug.cgi?id=145661
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.prototype._classPreview):
+ (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
+ The string we will return for previews of class constructor functions.
+
+ (InjectedScript.RemoteObject):
+ (InjectedScript.RemoteObject.prototype._describe):
+ No longer return the class name as the description string.
+ Instead return the class name for the RemoteObject.className.
+
+2015-06-04 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r185216.
+ https://bugs.webkit.org/show_bug.cgi?id=145666
+
+ it caused a bunch of debug crashes (Requested by pizlo on
+ #webkit).
+
+ Reverted changeset:
+
+ "Simplify unboxing of double JSValues known to be not NaN and
+ not Int32"
+ https://bugs.webkit.org/show_bug.cgi?id=145618
+ http://trac.webkit.org/changeset/185216
+
+2015-06-03 Filip Pizlo <fpizlo@apple.com>
+
+ Simplify unboxing of double JSValues known to be not NaN and not Int32
+ https://bugs.webkit.org/show_bug.cgi?id=145618
+
+ Reviewed by Geoffrey Garen.
+
+ In many cases we know that we most likely loaded a non-NaN double value from the heap.
+ Prior to this patch, we would do two branches before unboxing the double. This patch
+ reduces this to one branch in the common case. Before:
+
+ if (is int32)
+ unbox int32 and convert to double
+ else if (is number)
+ unbox double
+ else
+ exit
+
+ After:
+
+ tmp = unbox double
+ if (tmp == tmp)
+ done
+ else if (is int32)
+ unbox int32 and convert to double
+ else
+ exit
+
+ We only use the new style if we have profiling that tells us that we are unlikely to see
+ either Int32 or NaN - since we will now exit on NaN and int32 requires an extra branch.
+
+ This is a 8% speed-up on Octane/box2d. On one microbenchmark this is a 25% speed-up.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::observeUseKindOnNode):
+ (JSC::DFG::FixupPhase::fixEdgeRepresentation):
+ (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::shouldSpeculateDouble):
+ (JSC::DFG::Node::shouldSpeculateDoubleReal):
+ (JSC::DFG::Node::shouldSpeculateNumber):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::SafeToExecuteEdge::operator()):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileDoubleRep):
+ (JSC::DFG::SpeculativeJIT::speculateNumber):
+ (JSC::DFG::SpeculativeJIT::speculateRealNumber):
+ (JSC::DFG::SpeculativeJIT::speculateDoubleRepReal):
+ (JSC::DFG::SpeculativeJIT::speculate):
+ (JSC::DFG::SpeculativeJIT::speculateDoubleReal): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGUseKind.cpp:
+ (WTF::printInternal):
+ * dfg/DFGUseKind.h:
+ (JSC::DFG::typeFilterFor):
+ (JSC::DFG::isNumerical):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
+ (JSC::FTL::LowerDFGToLLVM::boxDouble):
+ (JSC::FTL::LowerDFGToLLVM::jsValueToStrictInt52):
+ (JSC::FTL::LowerDFGToLLVM::speculate):
+ (JSC::FTL::LowerDFGToLLVM::speculateNumber):
+ (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
+ (JSC::FTL::LowerDFGToLLVM::speculateDoubleRepReal):
+ (JSC::FTL::LowerDFGToLLVM::jsValueToDouble): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::speculateDoubleReal): Deleted.
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::branchIfNotOther):
+ (JSC::AssemblyHelpers::branchIfInt32):
+ (JSC::AssemblyHelpers::branchIfNotInt32):
+ (JSC::AssemblyHelpers::branchIfNumber):
+
+2015-06-04 Filip Pizlo <fpizlo@apple.com>
+
+ SideState should be a distinct abstract heap from Heap and Stack
+ https://bugs.webkit.org/show_bug.cgi?id=145653
+
+ Reviewed by Geoffrey Garen.
+
+ Before, SideState fit into the hierarchy like so:
+
+ World
+ |
+ +-- Stack
+ |
+ +-- Heap
+ |
+ +-- SideState
+
+ Now we will have:
+
+ World
+ |
+ +-- Stack
+ |
+ +-- Heap
+ |
+ +-- SideState
+
+ This makes it easy to ask if a writing operation wrote to anything that is observable even
+ if we don't exit. SideState is only observable if we exit.
+
+ * dfg/DFGAbstractHeap.h:
+ (JSC::DFG::AbstractHeap::AbstractHeap):
+ (JSC::DFG::AbstractHeap::supertype):
+
+2015-06-04 Chris Dumez <cdumez@apple.com>
+
+ [WK2] Prune more resources from the MemoryCache before process suspension
+ https://bugs.webkit.org/show_bug.cgi?id=145633
+
+ Reviewed by Andreas Kling.
+
+ No longer move protect IncrementalSweeper::fullSweep() behind
+ USE(CF) so we don't need #ifdefs at call sites, similarly to what is
+ done for the rest of the IncrementalSweeper API.
+
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::fullSweep):
+ * heap/IncrementalSweeper.h:
+
+2015-06-01 Filip Pizlo <fpizlo@apple.com>
+
+ CallLinkStatus should return takesSlowPath if the GC often cleared the IC
+ https://bugs.webkit.org/show_bug.cgi?id=145502
+
+ Reviewed by Geoffrey Garen.
+
+ CallLinkInfo now remembers when it has been cleared by GC. This has some safeguards for when
+ a call gets cleared by GC only because we hadn't converted it into a closure call; in that
+ case the GC will just tell us that it should be a closure call. The DFG will not optimize
+ a call that was cleared by GC, and the DFG will always prefer a closure call if the GC told
+ us that the specific callee was dead but the executable wasn't.
+
+ This guards us from some scenarios that came up in Speedometer. It's neutral on the pure JS
+ benchmarks, most likely just because those benchmarks aren't real enough to have interesting
+ GC of code.
+
+ * bytecode/CallLinkInfo.cpp:
+ (JSC::CallLinkInfo::visitWeak):
+ (JSC::CallLinkInfo::dummy):
+ * bytecode/CallLinkInfo.h:
+ (JSC::CallLinkInfo::CallLinkInfo):
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeFromCallLinkInfo):
+
+2015-06-02 Filip Pizlo <fpizlo@apple.com>
+
+ GetById and PutById profiling should be more precise about it takes slow path
+ https://bugs.webkit.org/show_bug.cgi?id=145590
+
+ Reviewed by Geoffrey Garen.
+
+ If a ById access ever takes slow path, we want the DFG and FTL to know this. Previously we
+ were relying on slow path counts, which conflate slow paths taken due to a megamorphic
+ access and slow paths taken due to IC building.
+
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeFor):
+ (JSC::GetByIdStatus::computeForStubInfo):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFor):
+ (JSC::PutByIdStatus::computeForStubInfo):
+ * bytecode/StructureStubInfo.h:
+ (JSC::StructureStubInfo::StructureStubInfo):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileGetById):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+
+2015-06-03 Michael Saboff <msaboff@apple.com>
+
+ Improve test coverage for changes made in 145527
+ https://bugs.webkit.org/show_bug.cgi?id=145578
+
+ Reviewed by Geoffrey Garen.
+
+ Added more complexity to poly-setter-combo.js stress test to create more turmoil in the
+ polymorphic get-by-id / put-by-id with getters and setters to exercise the code change in
+ https://bugs.webkit.org/show_bug.cgi?id=145527. By changing the objects that the main test
+ function sees, we are able to test those paths. Verified with temporary logging code.
+
+ * tests/stress/poly-setter-combo.js:
+ (Cons2):
+ (Cons3):
+ (Cons4):
+ (foo):
+ (test):
+ (runTestWithConstructors):
+
+2015-06-02 Mark Lam <mark.lam@apple.com>
+
+ Gardening: fix broken CLoop build.
+
+ Not reviewed.
+
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeExitSiteData):
+
+2015-06-02 Keith Miller <keith_miller@apple.com>
+
+ JavaScriptCore: JSExport protocol with an NSInteger property converts negative values to 18446744073709552000
+ https://bugs.webkit.org/show_bug.cgi?id=145563
+
+ Reviewed by Darin Adler.
+
+ The Objective-C bindings were improperly converting negative
+ long long/NSIntegers to 18446744073709552000 because they
+ were converted to unsigned numbers.
+
+ * API/ObjcRuntimeExtras.h:
+ (parseObjCType):
+ * API/tests/testapi.mm:
+ (testObjectiveCAPIMain):
+ (checkNegativeNSIntegers):
+ (testObjectiveCAPI):
+
+2015-06-02 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Heap-use-after-free read of size 4 in JavaScriptCore: WTF::StringImpl::isSymbol() (StringImpl.h:496)
+ https://bugs.webkit.org/show_bug.cgi?id=145532
+
+ Reviewed by Geoffrey Garen.
+
+ AtomicStringImpl::lookUp returns AtomicStringImpl*,
+ it doesn't give any ownership to the caller.
+ Originally, this is ok because the ownership is taken
+ by AtomicStringImpl's table (& the register side).
+
+ But if we would like to use this returned AtomicStringImpl*,
+ we should take its ownership immediately.
+ Because if the register side releases its ownership (ref count),
+ it will be destroyed.
+
+ In JSString::toExistingAtomicString, it returns AtomicStringImpl*.
+ But it's not appropriate.
+ If the owner of AtomicStringImpl* is always JSString*, it is ok.
+ But it looks up the table-registered AtomicStringImpl* from
+ the AtomicStringImpl table. So JSString* may not have the ownership
+ of the returned AtomicStringImpl*.
+
+ The failure situation is the following.
+
+ 1. A creates AtomicStringImpl. A has its ownership.
+ And A registers it to AtomicStringImpl table.
+ 2. JSString looks up the AtomicStringImpl from the table.
+ It gets AtomicStringImpl*. And JSString doesn't have its ownership.
+ It returns the raw pointer immediately to the users
+ 3. A is released. There's no owner for AtomicStringImpl*.
+ So it's also destroyed.
+ 4. Use looked up AtomicStringImpl in (2). It becomes use-after-free.
+
+ This patch fixes it by the following changes.
+
+ 1. Change the signature of `AtomicStringImpl* AtomicStringImpl::lookUp(...)`
+ to `RefPtr<AtomicStringImpl> AtomicStringImpl::lookUp(..)`.
+ Use `RefPtr` because it may return `nullptr`.
+ 2. Change the signature of `AtomicStringImpl* JSString::toExistingAtomicString(...)`
+ to `RefPtr<AtomicStringImpl> JSString::toExistingAtomicString(...)`.
+ Using `RefPtr` is the same reason.
+ 3. Receive the result with `RefPtr<AtomicStringImpl>` in the caller side.
+
+ * dfg/DFGOperations.cpp:
+ * jit/JITOperations.cpp:
+ (JSC::getByVal):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::getByVal):
+ * runtime/JSString.cpp:
+ (JSC::JSRopeString::resolveRopeToExistingAtomicString):
+ * runtime/JSString.h:
+ (JSC::JSString::toExistingAtomicString):
+
+2015-05-30 Filip Pizlo <fpizlo@apple.com>
+
+ Any exit from any JIT due to profiling for an inline cache should force all future compilations to be wary
+ https://bugs.webkit.org/show_bug.cgi?id=145496
+
+ Reviewed by Geoffrey Garen.
+
+ This pessimizes compilation a bit, but it reduces the likelihood of exiting from FTL. I
+ couldn't find any convincing reason not to do this, and we know from Speedometer that this
+ change is necessary for weirder code.
+
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeFor):
+ (JSC::CallLinkStatus::computeExitSiteData):
+ (JSC::CallLinkStatus::computeDFGStatuses):
+ * bytecode/CallLinkStatus.h:
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::appendVariant):
+ (JSC::GetByIdStatus::hasExitSite):
+ (JSC::GetByIdStatus::computeFor):
+ * bytecode/GetByIdStatus.h:
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::appendVariant):
+ (JSC::PutByIdStatus::hasExitSite):
+ (JSC::PutByIdStatus::computeFor):
+ * bytecode/PutByIdStatus.h:
+
+2015-05-31 Filip Pizlo <fpizlo@apple.com>
+
+ If a call has ever taken the virtual slow path, make sure that the DFG knows this
+ https://bugs.webkit.org/show_bug.cgi?id=145501
+
+ Reviewed by Geoffrey Garen.
+
+ Now now return higher fidelity information in the case of no polymorphic call stub. If the
+ virtual slow path was ever taken, we note this, and we note either zero or one call variant
+ based on the IC's last callee.
+
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeFromCallLinkInfo):
+ (JSC::CallLinkStatus::computeFor):
+
+2015-06-01 Michael Saboff <msaboff@apple.com>
+
+ Crash in com.apple.WebKit.WebContent at com.apple.JavaScriptCore: JSC::revertCall + 24
+ https://bugs.webkit.org/show_bug.cgi?id=145527
+
+ Reviewed by Filip Pizlo.
+
+ If a CallLinkInfo is GC'ed, we need to notify any PolymorphicCallNode's that reference it.
+ Added plumbling to clear the m_callLinkInfo of a PolymorphicCallNode when that CallLinkInfo
+ is going away.
+
+ * bytecode/CallLinkInfo.h:
+ (JSC::CallLinkInfo::~CallLinkInfo):
+ * jit/PolymorphicCallStubRoutine.cpp:
+ (JSC::PolymorphicCallNode::unlink):
+ (JSC::PolymorphicCallNode::clearCallLinkInfo):
+ (JSC::PolymorphicCallCase::dump):
+ (JSC::PolymorphicCallStubRoutine::edges):
+ (JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
+ (JSC::PolymorphicCallStubRoutine::visitWeak):
+ * jit/PolymorphicCallStubRoutine.h:
+ (JSC::PolymorphicCallNode::hasCallLinkInfo):
+
+2015-06-01 Mark Lam <mark.lam@apple.com>
+
+ Add the ability to tell between Catch and Finally blocks.
+ https://bugs.webkit.org/show_bug.cgi?id=145524
+
+ Reviewed by Michael Saboff.
+
+ ... and also SynthesizedFinally blocks too. A SynthesizedFinally block
+ is a finally block that is synthesized by the bytecode generator but
+ does not actually correspond to any exception handling construct at the
+ JS source code level. An example of this is the "for ... of" statement
+ where it needs to do some "final" clean up before passing on the
+ exception.
+
+ Manually tested by inspecting the bytecode dump of functions with
+ try-catch-finally blocks as well as for of statements which have
+ synthesized finally blocks. The bytecode dumps contains the exception
+ handlers table which has these blocks labelled with their newly added
+ types. No automatic test because this type info is not visible to JS
+ code.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecode/HandlerInfo.h:
+ (JSC::HandlerInfoBase::type):
+ (JSC::HandlerInfoBase::setType):
+ (JSC::HandlerInfoBase::typeName):
+ (JSC::HandlerInfoBase::isCatchHandler):
+ (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
+ (JSC::HandlerInfo::initialize):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+ (JSC::BytecodeGenerator::pushTry):
+ (JSC::BytecodeGenerator::popTryAndEmitCatch):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::emitThrow):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::TryNode::emitBytecode):
+
+2015-05-29 Geoffrey Garen <ggaren@apple.com>
+
+ REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
+ https://bugs.webkit.org/show_bug.cgi?id=145412
+
+ Reviewed by Darin Adler.
+
+ Moar speedup.
+
+ Added a bucket sort for string sorting.
+
+ * builtins/Array.prototype.js:
+ (sort.compactSparse):
+ (sort.compactSlow):
+ (sort.compact): Split out a compaction fast path for dense arrays. Without
+ it, compaction can increase sort time by 2X for simple sorts.
+
+ (sort.bucketSort):
+ (sort.stringSort): Use a bucket sorting algorithm if we know we're sorting
+ strings. This makes average case string sorting O(N) with O(N) additional
+ memory use.
+
+ The worst case bucket sort can require O(M * N) additional
+ space. We avoid this by falling back to merge sort when things are
+ simple or overly duplicative. These are the two cases that accumulate
+ excessive -- and potentially pathological -- bucketing overhead.
+
+2015-06-01 Mark Lam <mark.lam@apple.com>
+
+ HandlerInfo::initialize() should not assume that CodeLocationLabel is available.
+ https://bugs.webkit.org/show_bug.cgi?id=145515
+
+ Reviewed by Csaba Osztrogonác.
+
+ CodeLocationLabel is only defined for ENABLE(ASSEMBLER) builds. r185022's
+ attempt at simplifying code to increase readability failed to take this into
+ account. This patch fixes it.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * bytecode/HandlerInfo.h:
+ (JSC::HandlerInfo::initialize):
+
+2015-05-31 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=145503.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::inliningCost):
+
+2015-05-31 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Drop WeakMap#clear
+ https://bugs.webkit.org/show_bug.cgi?id=145489
+
+ Reviewed by Mark Lam.
+
+ ES6 spec intentionally drops the WeakMap#clear
+ to allow engine to implement WeakMap as a per-object table.
+
+ This patch drops WeakMap.prototype.clear.
+
+ * runtime/WeakMapPrototype.cpp:
+ (JSC::WeakMapPrototype::finishCreation): Deleted.
+ (JSC::protoFuncWeakMapClear): Deleted.
+
+2015-05-31 Jordan Harband <ljharb@gmail.com>
+
+ Array#reduce and reduceRight don't follow ToLength
+ https://bugs.webkit.org/show_bug.cgi?id=145364
+ Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
+
+ Reviewed by Yusuke Suzuki.
+
+ * builtins/Array.prototype.js:
+ (reduce):
+ (reduceRight):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ (JSC::arrayProtoFuncReduce): Deleted.
+ (JSC::arrayProtoFuncReduceRight): Deleted.
+
+2015-05-29 Filip Pizlo <fpizlo@apple.com>
+
+ FTL codegen for MultiGetByOffset and MultiPutByOffset where the structure set is already proved should have an unreachable default case instead of an exit
+ https://bugs.webkit.org/show_bug.cgi?id=145469
+
+ Reviewed by Geoffrey Garen.
+
+ Omitting the speculation on the fail path when the speculation is guaranteed not to be
+ taken hints to LLVM that the default case is impossible. This enables some useful
+ optimizations.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileMultiGetByOffset):
+ (JSC::FTL::LowerDFGToLLVM::compileMultiPutByOffset):
+
+2015-05-29 Mark Lam <mark.lam@apple.com>
+
+ Refactoring HandlerInfo and UnlinkedHandlerInfo.
+ https://bugs.webkit.org/show_bug.cgi?id=145480
+
+ Reviewed by Benjamin Poulain.
+
+ HandlerInfo and UnlinkedHandlerInfo have common parts, but are not currently
+ expressed as 2 unrelated structs that happen to have near identical fields.
+ We can refactor them to better express their relationship. We can also add
+ some convenience functions to make the code that uses them a little more
+ readable.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::handlerForBytecodeOffset):
+ * bytecode/HandlerInfo.h:
+ (JSC::UnlinkedHandlerInfo::UnlinkedHandlerInfo):
+ (JSC::HandlerInfo::initialize):
+ - I chose to include CodeLocationLabel arg even though it is unused by
+ by non-JIT builds. This makes the call site cleaner to read.
+
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedSimpleJumpTable::add):
+ (JSC::UnlinkedInstruction::UnlinkedInstruction):
+ (JSC::UnlinkedCodeBlock::numberOfExceptionHandlers):
+ (JSC::UnlinkedCodeBlock::addExceptionHandler):
+ (JSC::UnlinkedCodeBlock::exceptionHandler):
+ (JSC::UnlinkedCodeBlock::symbolTable):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+
+2015-05-28 Filip Pizlo <fpizlo@apple.com>
+
+ Non-speculative Branch should be fast in the FTL
+ https://bugs.webkit.org/show_bug.cgi?id=145452
+
+ Reviewed by Andreas Kling.
+
+ Inlines the code for convertJSValueToBoolean into the FTL. This also includes some other
+ clean-ups that I found along the way.
+
+ I found this by looking at the hottest functions in DeltaBlue. Despite having so many
+ Branch specializations, apparently there was still a hot one that we missed that was going
+ down the untyped path. It was either Int32 or Other. Maybe we could specialize for that
+ combo, but it makes so much sense to just make all of this nonsense fast.
+
+ * dfg/DFGWatchpointCollectionPhase.cpp:
+ (JSC::DFG::WatchpointCollectionPhase::handle): Need to watch the masquerades watchpoint on UntypedUse: forms of Branch now.
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::boolify): The actual fix.
+ (JSC::FTL::LowerDFGToLLVM::int52ToStrictInt52):
+ (JSC::FTL::LowerDFGToLLVM::isInt32):
+ (JSC::FTL::LowerDFGToLLVM::isNotInt32):
+ (JSC::FTL::LowerDFGToLLVM::unboxInt32):
+ * runtime/JSCellInlines.h:
+ (JSC::JSCell::toBoolean): Symbol is always true.
+ (JSC::JSCell::pureToBoolean): Symbol is always true.
+ * runtime/JSString.cpp:
+ (JSC::JSString::getPrimitiveNumber):
+ (JSC::JSString::toNumber):
+ (JSC::JSString::toBoolean): Deleted. This is a tiny method. It doesn't need to be out-of-line.
+ * runtime/JSString.h:
+ (JSC::JSString::length):
+ (JSC::JSString::toBoolean): This method shouldbe inline.
+ * runtime/Symbol.cpp:
+ (JSC::Symbol::toPrimitive):
+ (JSC::Symbol::getPrimitiveNumber):
+ (JSC::Symbol::toBoolean): Deleted. A Symbol is always true, so we don't need a method for this.
+ * runtime/Symbol.h:
+
+2015-05-29 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r184860.
+ https://bugs.webkit.org/show_bug.cgi?id=145456
+
+ May have caused ~1% Octane regression (Requested by kling on
+ #webkit).
+
+ Reverted changeset:
+
+ "Try to use StringView when comparing JSStrings for equality."
+ https://bugs.webkit.org/show_bug.cgi?id=145379
+ http://trac.webkit.org/changeset/184860
+
+2015-05-28 Michael Saboff <msaboff@apple.com>
+
+ mozilla/js1_5/Array/regress-154338.js test causes ARM 32 bit iOS devices to run out of memory
+ https://bugs.webkit.org/show_bug.cgi?id=145444
+
+ Reviewed by Geoffrey Garen.
+
+ Disabled mozilla/js1_5/Array/regress-154338.js when run on iOS ARM 32 bit devices and
+ the --memory-limited option is passed to run-jsc-stress-tests.
+
+ * tests/mozilla/mozilla-tests.yaml:
+
+2015-05-28 Benjamin Poulain <benjamin@webkit.org>
+
+ [iOS8][ARMv7(s)] Optimized Object.create in 'use strict' context sometimes breaks.
+ https://bugs.webkit.org/show_bug.cgi?id=138038
+
+ Reviewed by Michael Saboff.
+
+ TL;DR: sometimes the baseline JIT could accidentally nuke the tag before calling
+ to C++, making put_by_id behave erratically.
+
+ The bug was that put_by_id would randomly not work correctly in 32bits. It happened
+ in the baseline JIT if we were unlucky enough:
+ -The code get hot enough and the structure is stable so we get a fast path for
+ put_by_id.
+ -We repatch the fast-path branch with a stub generated by
+ emitPutTransitionStubAndGetOldStructure().
+ -In emitPutTransitionStubAndGetOldStructure(), we only preserve the payload of the base
+ register, the tag register is ignored.
+ -emitPutTransitionStubAndGetOldStructure() allocate 2 to 3 registers. Any of those
+ could be the one used for the base's tag before the fast path and the value is trashed.
+ -If we hit one of the failure case, we fallback to the slow path, but we destroyed
+ the tag pointer.
+ -We now have unrelated bits in the tag, the most likely value type is now "double"
+ and we fail the put_by_id because we try to set a property on a number.
+
+ The most obvious solution would be to change emitPutTransitionStubAndGetOldStructure()
+ to preserve the tag register in addition to the value register.
+ I decided against that option because of the added complexity. The DFG does not need
+ that case, so I would have to add branches everywhere to distinguish the cases
+ were we need to preserve the tag or not.
+
+ Instead, I just load the tag back from memory in the slow path. The function in the slow
+ path is several order of magnitude slower than a load, it is not worth eliminating it,
+ especially in baseline JIT.
+
+ I also discovered 4 useless loads in the fast path, so even with my extra load, this patch
+ makes the baseline faster :)
+
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emitSlow_op_put_by_id):
+ (JSC::JIT::emit_op_put_by_id): Deleted.
+ * tests/stress/put-by-id-on-new-object-after-prototype-transition-non-strict.js: Added.
+ (opaqueNewObject):
+ (putValueOnNewObject):
+ * tests/stress/put-by-id-on-new-object-after-prototype-transition-strict.js: Added.
+ (string_appeared_here.opaqueNewObject):
+ (putValueOnNewObject):
+
+2015-05-28 Benjamin Poulain <benjamin@webkit.org>
+
+ [JSC] reduction the iteration count of the DoubleRep stress tests
+
+ Once again, I used big numbers for manual testing and I forgot to fix them before landing.
+
+ * tests/stress/double-rep-with-non-cell.js:
+ * tests/stress/double-rep-with-null.js:
+ * tests/stress/double-rep-with-undefined.js:
+
+2015-05-28 Basile Clement <basile_clement@apple.com>
+
+ Add debug mode assertions for accessors casting JSC::DFG::Node.m_opInfo
+ https://bugs.webkit.org/show_bug.cgi?id=145441
+
+ Reviewed by Filip Pizlo.
+
+ Most accessor functions casting m_opInfo in JSC::DFG::Node are
+ performing debug checks that they are only accessed for node types that
+ should have them. This patch adds similar checks for the accessors that
+ were missing them.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::watchpointSet):
+ (JSC::DFG::Node::storagePointer):
+ (JSC::DFG::Node::multiGetByOffsetData):
+ (JSC::DFG::Node::multiPutByOffsetData):
+ (JSC::DFG::Node::hasTypeLocation):
+ (JSC::DFG::Node::typeLocation):
+ (JSC::DFG::Node::hasBasicBlockLocation):
+ (JSC::DFG::Node::basicBlockLocation):
+
+2015-05-28 Matt Rajca <mrajca@apple.com>
+
+ Add ENABLE_MEDIA_SESSION feature flag (which is off by default).
+ https://bugs.webkit.org/show_bug.cgi?id=145415
+
+ Reviewed by Eric Carlson.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-05-27 Jordan Harband <ljharb@gmail.com>
+
+ Array.of should work with other constructors
+ https://bugs.webkit.org/show_bug.cgi?id=145365
+ Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.of
+ step 4
+
+ Reviewed by Yusuke Suzuki.
+
+ * builtins/ArrayConstructor.js:
+ (of):
+ * runtime/ArrayConstructor.cpp:
+ (JSC::arrayConstructorOf): Deleted.
+
+2015-05-27 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Add undefined->double conversion to DoubleRep
+ https://bugs.webkit.org/show_bug.cgi?id=145293
+
+ Reviewed by Filip Pizlo.
+
+ This patch adds undefined to double conversion to the DoubleRep
+ node for the cases were we speculate "undefined" as part of the types
+ processed.
+
+ The use case is doing math with accidental out-of-bounds access. For example,
+ something like:
+ for (var i = 0; i <= length; ++i)
+ ouptput += array[i];
+
+ would cause us to OSR exit every time i === length.
+
+ When hitting one of those cases, we would already speculate double math,
+ but the DoubleRep node was unable to convert the undefined and would exit.
+
+ With this patch the use kind NotCellUse cover this conversion for DoubleRep.
+ I have been quite conservative so in general we will not find "undefined"
+ until a few recompile but being optimistic seems better since this is a corner case.
+
+ This patch is a 80% progression on WebXPRT's DNA Sequencing test.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::sawUndefined):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::SafeToExecuteEdge::operator()):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileDoubleRep):
+ * dfg/DFGUseKind.cpp:
+ (WTF::printInternal):
+ * dfg/DFGUseKind.h:
+ (JSC::DFG::typeFilterFor):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
+ (JSC::FTL::LowerDFGToLLVM::jsValueToDouble):
+ * tests/stress/double-rep-with-undefined.js: Added.
+ (addArgsNumberAndUndefined):
+ (addArgsInt32AndUndefined):
+ (testFallbackWithDouble):
+ (addArgsDoubleAndUndefined):
+ (testFallbackWithObject.):
+ (testFallbackWithObject):
+ (addArgsOnlyUndefined):
+ (testFallbackWithString):
+
+2015-05-27 Dean Jackson <dino@apple.com>
+
+ img.currentSrc problem in strict mode with old picturefill
+ https://bugs.webkit.org/show_bug.cgi?id=144095
+ <rdar://problem/21087013>
+
+ Reviewed by Simon Fraser.
+
+ Add a PICTURE_SIZES flag.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-05-27 Basile Clement <basile_clement@apple.com>
+
+ LazyNode comparison can return incorrect results when comparing an empty value
+ https://bugs.webkit.org/show_bug.cgi?id=145421
+
+ Reviewed by Geoffrey Garen.
+
+ When comparing a LazyNode to another, we compare the value pointers if
+ we have one, and otherwise compare the nodes.
+ We should be comparing value pointers if the other LazyNode has one as
+ well, otherwise we risk an incoherency when we are a empty LazyNode
+ being compared to a FrozenValue without node.
+
+ Note that this is not a problem in any other case because if we don't
+ have a FrozenValue and we are not an empty LazyNode, we are a
+ non-constant node, and comparing the node pointers is correct.
+
+ * dfg/DFGLazyNode.h:
+ (JSC::DFG::LazyNode::operator==):
+
+2015-05-27 Geoffrey Garen <ggaren@apple.com>
+
+ REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
+ https://bugs.webkit.org/show_bug.cgi?id=145412
+
+ Reviewed by Benjamin Poulain.
+
+ Cache strings when doing a string-converting sort.
+
+ This is a 21% speedup.
+
+ * builtins/Array.prototype.js:
+ (sort.stringComparator): Use subtraction instead of branching because
+ it's slightly faster.
+
+ (sort.comparatorSort):
+ (sort.stringSort):
+ (sort): Add a special case for string sorting to avoid redundant string
+ conversion.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::createBindingPattern): Names can be empty if
+ they are private names.
+
+2015-05-26 Filip Pizlo <fpizlo@apple.com>
+
+ JIT-generated store barrier code should assume the buffer pointer and capacity to be compile-time constants
+ https://bugs.webkit.org/show_bug.cgi?id=145404
+
+ Reviewed by Andreas Kling.
+
+ We never change the capacity of a write barrier buffer. We never repoint the buffer
+ pointer. So, the JIT shouldn't load those from memory; it should take advantage of the
+ fact that these are compile-time constants.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
+ * heap/WriteBarrierBuffer.h:
+ (JSC::WriteBarrierBuffer::currentIndexAddress):
+ (JSC::WriteBarrierBuffer::capacity):
+ (JSC::WriteBarrierBuffer::buffer):
+ (JSC::WriteBarrierBuffer::currentIndexOffset): Deleted.
+ (JSC::WriteBarrierBuffer::capacityOffset): Deleted.
+ (JSC::WriteBarrierBuffer::bufferOffset): Deleted.
+ * jit/Repatch.cpp:
+ (JSC::emitPutTransitionStubAndGetOldStructure):
+
+2015-05-27 Geoffrey Garen <ggaren@apple.com>
+
+ REGRESSION: These sorting idioms used by Peacekeeper and Browsermark are ~20X slower
+ https://bugs.webkit.org/show_bug.cgi?id=145412
+
+ Reviewed by Darin Adler.
+
+ Use @toString instead of the String constructor because calls to the
+ String constructor are never optimized. (See
+ https://bugs.webkit.org/show_bug.cgi?id=144458.)
+
+ This is a ~2X speedup.
+
+ * builtins/Array.prototype.js:
+ (sort.stringComparator):
+
+2015-05-27 Dan Bernstein <mitz@apple.com>
+
+ Remove JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080
+ https://bugs.webkit.org/show_bug.cgi?id=145403
+
+ Reviewed by Anders Carlsson.
+
+ JSC_OBJC_API_AVAILABLE_MAC_OS_X_1080 was used to enable the JavaScriptCore Objective-C API
+ for WebKit and Safari projects building with JavaScriptCore targeting OS X 10.8. We don’t
+ need it anymore.
+
+ * API/JSBase.h:
+ * API/JSContext.h:
+ * API/JSManagedValue.h:
+ * API/JSValue.h:
+ * API/JSVirtualMachine.h:
+ * Configurations/Base.xcconfig:
+ * postprocess-headers.sh:
+
+2015-05-26 Geoffrey Garen <ggaren@apple.com>
+
+ Photo Booth hangs under JSC::MachineThreads::tryCopyOtherThreadStacks
+ https://bugs.webkit.org/show_bug.cgi?id=145395
+
+ Reviewed by Mark Hahnenberg.
+
+ No test case because we already have --threaded mode, which runs lots of
+ parallel GC, but it (and the original in-app test case) can't reproduce
+ this bug.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::tryCopyOtherThreadStacks): Use a lock to prevent
+ two threads from mutually suspending each other.
+
+2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Add Array.prototype.copyWithin to JSC features.json
+ https://bugs.webkit.org/show_bug.cgi?id=145387
+
+ Reviewed by Darin Adler.
+
+ * features.json:
+
+2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Reflect nits for r184863
+ https://bugs.webkit.org/show_bug.cgi?id=145107
+
+ Reviewed by Darin Adler.
+
+ 1. Added the copyright line.
+ 2. Added an optional argument (/*, end */). To do so, fixed generate-js-builtins.
+ 3. Dropped the unnecessary variable `thisValue`.
+ 4. Fix the type error messages. This is also found in StringIterator.prototype.js.
+ 5. Added tests for 0 arguments.
+
+ * builtins/Array.prototype.js:
+ (copyWithin):
+ * builtins/StringIterator.prototype.js:
+ (next):
+ * generate-js-builtins:
+ * tests/stress/array-copywithin.js:
+ * tests/stress/string-iterators.js:
+
+2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Inline @Array / @Object callsites
+ https://bugs.webkit.org/show_bug.cgi?id=145382
+
+ Reviewed by Geoffrey Garen.
+
+ As the same to Array/Object callsite inlining, @Array/@Object also
+ should be inlined in bytecode level.
+ While `new @Object` style is not encouraged in the builtins,
+ `@Array(len)` is already used at least in Array.from code.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
+
+2015-05-26 Andreas Kling <akling@apple.com>
+
+ String.prototype.charCodeAt() should use StringView.
+ <https://webkit.org/b/145353>
+
+ Reviewed by Darin Adler.
+
+ Use JSString::view() in charCodeAt() to avoid reifying the JSString if it's
+ a substring. This avoids StringImpl allocation in some cases and ref churn
+ in all cases.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncCharCodeAt):
+
+2015-05-26 Andreas Kling <akling@apple.com>
+
+ String.prototype.charAt() should use StringView.
+ <https://webkit.org/b/145352>
+
+ Reviewed by Darin Adler.
+
+ Remove the jsSingleCharacterSubstring() function since it's actually completely
+ counter-productive: it could create a single-character string that would retain
+ a much larger string for the duration of its lifetime.
+
+ This made sense before StringImpl learned to put its characters at the tail end
+ of its own allocation. Now that it does, it's far better to just create a new
+ single-character StringImpl.
+
+ With that out of the way, we can make String.prototype.charAt() use StringView
+ to avoid reifying substring JSStrings (and avoid some ref churn too.)
+
+ * runtime/JSString.cpp:
+ (JSC::JSRopeString::getIndexSlowCase):
+ * runtime/JSString.h:
+ (JSC::JSString::getIndex):
+ (JSC::jsSingleCharacterSubstring): Deleted.
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncCharAt):
+ (JSC::stringProtoFuncSplit):
+
+2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement Array.prototype.copyWithin
+ https://bugs.webkit.org/show_bug.cgi?id=145107
+
+ Reviewed by Darin Adler.
+
+ This patch implements ES6 Array.prototype.copyWithin.
+ It is intended to be used for copying the region to the other region
+ in the callee array itself safely (like memmove, not memcpy).
+ This function is proposed in the context of WebGL.
+
+ * builtins/Array.prototype.js:
+ (.maxWithPositives):
+ (.minWithMaybeNegativeZeroAndPositive):
+ (copyWithin):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ * tests/stress/array-copywithin.js: Added.
+ (shouldBe):
+ (shouldBeArray):
+ (shouldThrow):
+ (arrayToObject):
+ (valueOf):
+
+2015-05-26 Dan Bernstein <mitz@apple.com>
+
+ <rdar://problem/21104551> Update build settings
+
+ Reviewed by Anders Carlsson.
+
+ * Configurations/DebugRelease.xcconfig:
+ * Configurations/FeatureDefines.xcconfig:
+ * Configurations/Version.xcconfig:
+
+2015-05-26 Andreas Kling <akling@apple.com>
+
+ Try to use StringView when comparing JSStrings for equality.
+ <https://webkit.org/b/145379>
+
+ Reviewed by Darin Adler.
+
+ Use JSString::view() when sending two JSStrings to WTF::equal()
+ for comparison. This avoids creating new objects in the case where
+ the strings are actually substrings.
+
+ * jit/JITOperations.cpp:
+ * runtime/JSCJSValueInlines.h:
+ (JSC::JSValue::equalSlowCaseInline):
+ (JSC::JSValue::strictEqualSlowCaseInline):
+
+2015-05-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [JSC] Generate put_by_val_direct for indexed identifiers instead of put_by_id with direct postfix
+ https://bugs.webkit.org/show_bug.cgi?id=145360
+
+ Reviewed by Darin Adler.
+
+ JSObject::putDirect only accepts non-indexed properties.
+ So when generating put_by_id (with direct postfix) for indexed property,
+ we should generate put_by_val_direct instead.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitDirectPutById):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::PropertyListNode::emitPutConstantProperty):
+ * tests/stress/put-by-id-direct-should-be-done-for-non-index-property.js: Added.
+
+2015-05-24 Jordan Harband <ljharb@gmail.com>
+
+ Array#findIndex/find should not skip holes
+ https://bugs.webkit.org/show_bug.cgi?id=145361
+ per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.findindex
+ and https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.find
+
+ Reviewed by Yusuke Suzuki.
+
+ * builtins/Array.prototype.js:
+ (find): Deleted.
+ (findIndex): Deleted.
+
+2015-05-24 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: Uncaught exception when using Inspect tool on SVG elements
+ https://bugs.webkit.org/show_bug.cgi?id=145363
+
+ Reviewed by Joseph Pecoraro.
+
+ The injected script failed by chaining a call to String.prototype.trim to the result of
+ SVG*Element.className, which is an SVGAnimatedString and lacks useful methods. So, obtain
+ the class name using Node.getAttribute, which always returns a DOMString.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScriptSource.prototype._getDescription): use getAttribute instead of className.
+
+2015-05-23 Dan Bernstein <mitz@apple.com>
+
+ Remove unused definitions of WEBKIT_VERSION_MIN_REQUIRED
+ https://bugs.webkit.org/show_bug.cgi?id=145345
+
+ Reviewed by Sam Weinig.
+
+ * Configurations/Base.xcconfig: Also changed to use $(inherited).
+
+2015-05-23 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Introduce UniquedStringImpl and SymbolImpl to separate symbolic strings from AtomicStringImpl
+ https://bugs.webkit.org/show_bug.cgi?id=144848
+
+ Reviewed by Darin Adler.
+
+ Use UniquedStringImpl, SymbolImpl and AtomicStringImpl.
+
+ * API/JSCallbackObject.h:
+ * builtins/BuiltinNames.h:
+ (JSC::BuiltinNames::isPrivateName):
+ * bytecode/BytecodeIntrinsicRegistry.h:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * bytecode/ComplexGetStatus.cpp:
+ (JSC::ComplexGetStatus::computeFor):
+ * bytecode/ComplexGetStatus.h:
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeFromLLInt):
+ (JSC::GetByIdStatus::computeFor):
+ (JSC::GetByIdStatus::computeForStubInfo):
+ * bytecode/GetByIdStatus.h:
+ * bytecode/Instruction.h:
+ (JSC::Instruction::Instruction):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFromLLInt):
+ (JSC::PutByIdStatus::computeFor):
+ (JSC::PutByIdStatus::computeForStubInfo):
+ * bytecode/PutByIdStatus.h:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::visibleNameForParameter):
+ (JSC::BytecodeGenerator::hasConstant):
+ (JSC::BytecodeGenerator::addConstant):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::PropertyListNode::emitBytecode):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
+ * dfg/DFGDesiredIdentifiers.cpp:
+ (JSC::DFG::DesiredIdentifiers::addLazily):
+ (JSC::DFG::DesiredIdentifiers::at):
+ (JSC::DFG::DesiredIdentifiers::reallyAdd):
+ * dfg/DFGDesiredIdentifiers.h:
+ (JSC::DFG::DesiredIdentifiers::operator[]):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileIn):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::identifierUID):
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLInlineCacheDescriptor.h:
+ (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
+ (JSC::FTL::InlineCacheDescriptor::uid):
+ (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
+ (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
+ (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compilePutById):
+ (JSC::FTL::LowerDFGToLLVM::compileIn):
+ (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
+ (JSC::FTL::LowerDFGToLLVM::getById):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+ * ftl/FTLSlowPathCall.cpp:
+ (JSC::FTL::callOperation):
+ * ftl/FTLSlowPathCall.h:
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * parser/Nodes.cpp:
+ (JSC::ProgramNode::setClosedVariables):
+ * parser/Nodes.h:
+ (JSC::ScopeNode::captures):
+ (JSC::ScopeNode::setClosedVariables):
+ (JSC::ProgramNode::closedVariables):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner):
+ (JSC::Parser<LexerType>::didFinishParsing):
+ (JSC::Parser<LexerType>::parseContinueStatement):
+ * parser/Parser.h:
+ (JSC::Scope::Scope):
+ (JSC::Scope::pushLabel):
+ (JSC::Scope::getLabel):
+ (JSC::Scope::declareCallee):
+ (JSC::Scope::declareVariable):
+ (JSC::Scope::declareParameter):
+ (JSC::Scope::declareBoundParameter):
+ (JSC::Scope::useVariable):
+ (JSC::Scope::copyCapturedVariablesToVector):
+ (JSC::Parser::closedVariables):
+ (JSC::ScopeLabelInfo::ScopeLabelInfo): Deleted.
+ * parser/SourceProviderCacheItem.h:
+ (JSC::SourceProviderCacheItem::usedVariables):
+ (JSC::SourceProviderCacheItem::writtenVariables):
+ (JSC::SourceProviderCacheItem::create):
+ * runtime/CommonIdentifiers.cpp:
+ (JSC::CommonIdentifiers::isPrivateName):
+ * runtime/CommonIdentifiers.h:
+ * runtime/Identifier.h:
+ (JSC::Identifier::impl):
+ (JSC::Identifier::Identifier):
+ (JSC::parseIndex):
+ (JSC::IdentifierRepHash::hash):
+ * runtime/IdentifierInlines.h:
+ (JSC::Identifier::fromUid):
+ * runtime/IntendedStructureChain.cpp:
+ (JSC::IntendedStructureChain::mayInterceptStoreTo):
+ * runtime/IntendedStructureChain.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/Lookup.h:
+ (JSC::HashTable::entry):
+ * runtime/MapData.h:
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorGetOwnPropertySymbols):
+ * runtime/PrivateName.h:
+ (JSC::PrivateName::PrivateName):
+ (JSC::PrivateName::uid):
+ * runtime/PropertyMapHashTable.h:
+ * runtime/PropertyName.h:
+ (JSC::PropertyName::PropertyName):
+ (JSC::PropertyName::uid):
+ (JSC::PropertyName::publicName):
+ (JSC::parseIndex):
+ * runtime/PropertyNameArray.h:
+ (JSC::PropertyNameArray::addKnownUnique):
+ (JSC::PropertyNameArray::add):
+ * runtime/Structure.cpp:
+ (JSC::StructureTransitionTable::contains):
+ (JSC::StructureTransitionTable::get):
+ (JSC::StructureTransitionTable::add):
+ (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
+ (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
+ (JSC::Structure::getConcurrently):
+ (JSC::Structure::add):
+ (JSC::Structure::remove):
+ (JSC::Structure::toStructureShape):
+ * runtime/Structure.h:
+ (JSC::PropertyMapEntry::PropertyMapEntry):
+ * runtime/StructureInlines.h:
+ (JSC::Structure::getConcurrently):
+ * runtime/StructureTransitionTable.h:
+ (JSC::StructureTransitionTable::Hash::hash):
+ * runtime/Symbol.cpp:
+ (JSC::Symbol::Symbol):
+ * runtime/Symbol.h:
+ * runtime/SymbolConstructor.cpp:
+ (JSC::symbolConstructorFor):
+ (JSC::symbolConstructorKeyFor):
+ * runtime/SymbolTable.cpp:
+ (JSC::SymbolTable::uniqueIDForVariable):
+ (JSC::SymbolTable::globalTypeSetForVariable):
+ * runtime/SymbolTable.h:
+ * runtime/TypeSet.cpp:
+ (JSC::StructureShape::addProperty):
+ (JSC::StructureShape::propertyHash):
+ * runtime/TypeSet.h:
+
+2015-05-21 Filip Pizlo <fpizlo@apple.com>
+
+ Arguments elimination phase mishandles arity check failure in its reduction of LoadVarargs to GetStack/PutStacks
+ https://bugs.webkit.org/show_bug.cgi?id=145298
+
+ Reviewed by Geoffrey Garen.
+
+ * dfg/DFGArgumentsEliminationPhase.cpp: Fix the bug. I restructured the loop to make it more obvious that we're initializing everything that we're supposed to initialize.
+ * dfg/DFGNode.h: Add a comment to clarify something I was confused about while writing this code.
+ * dfg/DFGPutStackSinkingPhase.cpp: Hacking on PutStacks made me think deep thoughts, and I added some FIXMEs.
+ * tests/stress/fold-load-varargs-arity-check-fail-barely.js: Added. This test crashes or fails before this patch.
+ * tests/stress/fold-load-varargs-arity-check-fail.js: Added. This is even more sure to crash or fail.
+ * tests/stress/simplify-varargs-mandatory-minimum-smaller-than-limit.js: Added. Not sure if we had coverage for this case before.
+
+2015-05-22 Basile Clement <basile_clement@apple.com>
+
+ Allow DFGClobberize to return non-node constants that must be later created
+ https://bugs.webkit.org/show_bug.cgi?id=145272
+
+ Reviewed by Filip Pizlo.
+
+ This adds a new LazyNode class in DFG that represents either a Node*,
+ or a FrozenValue* with a way to convert it to a Node* provided a block
+ to insert it into. DFGClobberize is converted to use LazyNode instead
+ of Node* when def()'ing values, which allows to now define the array's
+ length as well as the value of its various fields in NewArray and
+ NewArrayBuffer nodes.
+
+ We also introduce a Vector<uint32_t> in DFG::Graph to collect all the
+ values that can be used as index, in order to avoid def()'ing too many
+ values at once for big NewArrayBuffers.
+
+ HeapLocation had to be updated to use a LazyNode as its index to be
+ able to define array values.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGCSEPhase.cpp:
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ (JSC::DFG::DefMethodClobberize::operator()):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::freezeFragile):
+ * dfg/DFGGraph.h:
+ * dfg/DFGHeapLocation.h:
+ (JSC::DFG::HeapLocation::HeapLocation):
+ (JSC::DFG::HeapLocation::index):
+ (JSC::DFG::HeapLocation::hash):
+ * dfg/DFGLazyNode.cpp: Added.
+ (JSC::DFG::LazyNode::dump):
+ * dfg/DFGLazyNode.h: Added.
+ (JSC::DFG::LazyNode::LazyNode):
+ (JSC::DFG::LazyNode::setNode):
+ (JSC::DFG::LazyNode::isHashTableDeletedValue):
+ (JSC::DFG::LazyNode::isNode):
+ (JSC::DFG::LazyNode::op):
+ (JSC::DFG::LazyNode::asNode):
+ (JSC::DFG::LazyNode::asValue):
+ (JSC::DFG::LazyNode::hash):
+ (JSC::DFG::LazyNode::operator==):
+ (JSC::DFG::LazyNode::operator!=):
+ (JSC::DFG::LazyNode::ensureIsNode):
+ (JSC::DFG::LazyNode::operator->):
+ (JSC::DFG::LazyNode::operator*):
+ (JSC::DFG::LazyNode::operator!):
+ (JSC::DFG::LazyNode::operator UnspecifiedBoolType*):
+ (JSC::DFG::LazyNode::setFrozenValue):
+ * dfg/DFGPreciseLocalClobberize.h:
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
+ * dfg/DFGPutStackSinkingPhase.cpp:
+
+2015-05-22 Andreas Kling <akling@apple.com>
+
+ [JSC] Speed up new array construction in Array.prototype.splice().
+ <https://webkit.org/b/145303>
+
+ Reviewed by Benjamin Poulain.
+
+ Give splice() a fast path just like slice(), for indexing types where the backing
+ store can be memcpy'd. I generalized JSArray::fastSlice() a little bit so it works
+ for this optimization as well.
+
+ 7% progression on Kraken/stanford-crypto-pbkdf2.
+
+ * runtime/JSArray.h:
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::fastSlice): Tweak this to return JSArray*, and don't bother throwing
+ out-of-memory exceptions. Let the caller worry about that.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncSlice): Update for fastSlice() changes.
+ (JSC::arrayProtoFuncSplice): If the object we're splicing out of is a bona fide
+ JSArray, use fastSlice() to create the returned array instead of doing a generic
+ get/put loop.
+
+2015-05-21 Filip Pizlo <fpizlo@apple.com>
+
+ CPS rethreading should really get rid of GetLocals
+ https://bugs.webkit.org/show_bug.cgi?id=145290
+
+ Reviewed by Benjamin Poulain.
+
+ CPS rethreading is intended to get rid of redundant GetLocals. CSE can also do it, but
+ the idea is that you should be able to disable CSE and everything would still work. This
+ fixes a bug in CPS rethreading's GetLocal elimination: we should be calling replaceWith
+ rather than setReplacement, since setReplacement still leaves the original node.
+
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): Fix the bug.
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode): Eliminating GetLocals means that they turn into Check. We should handle Checks that have zero inputs.
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateCPS): Add a validation for what a GetLocal should look like in ThreadedCPS.
+ * tests/stress/get-local-elimination.js: Added.
+ (foo):
+
+2015-05-21 Saam Barati <saambarati1@gmail.com>
+
+ Object allocation sinking phase should explicitly create bottom values for CreateActivation sink candidates and CreateActivation should have SymbolTable as a child node
+ https://bugs.webkit.org/show_bug.cgi?id=145192
+
+ Reviewed by Filip Pizlo.
+
+ When we sink CreateActivation and generate MaterializeCreateActivation
+ in the object allocation sinking phase, we now explictly add PutHints for
+ all variables on the activation setting those variables to their default value
+ (undefined for Function activations and soon to be JS Empty Value for block scope activations).
+ This allows us to remove code that fills FTL fast activation allocations with Undefined.
+
+ This patch also adds the constant SymbolTable as an OpInfo of CreateActivation and MaterializeCreateActivation
+ nodes. This is in preparation for ES6 block scoping which will introduce a new
+ op code that gets lowered to CreateActivation.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasCellOperand):
+ (JSC::DFG::Node::cellOperand):
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
+ (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
+ * dfg/DFGPromotedHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGPromotedHeapLocation.h:
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileCreateActivation):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
+ (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+ * tests/stress/activation-sink-default-value.js: Added.
+ (bar):
+ * tests/stress/activation-sink-osrexit-default-value.js: Added.
+ (foo.set result):
+
+2015-05-21 Per Arne Vollan <peavo@outlook.com>
+
+ MSVC internal compiler error when compiling TemplateRegistryKey class.
+ https://bugs.webkit.org/show_bug.cgi?id=145259
+
+ Reviewed by Alex Christensen.
+
+ MSVC is not able to handle the brace initialization of a class member in this case.
+
+ * runtime/TemplateRegistryKey.h:
+
+2015-05-21 Csaba Osztrogonác <ossy@webkit.org>
+
+ Fix the !ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) build after r184337
+ https://bugs.webkit.org/show_bug.cgi?id=145248
+
+ Reviewed by Yusuke Suzuki.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ * bytecompiler/BytecodeGenerator.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseMemberExpression):
+
+2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: array previews should have a much smaller cap on values
+ https://bugs.webkit.org/show_bug.cgi?id=145195
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.RemoteObject.prototype._generatePreview):
+ Reduce the indexes threshold for previews.
+
+2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Use native Arguments detection instead of using toString
+ https://bugs.webkit.org/show_bug.cgi?id=145235
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.prototype._subtype):
+ Deleted the old string code.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ Replaced with a stricter, more accurate check.
+
+2015-05-20 Andreas Kling <akling@apple.com>
+
+ Remove unused MarkedBlock::m_rememberedSet.
+ <https://webkit.org/b/145224>
+
+ Reviewed by Mark Hahnenberg.
+
+ The MarkedBlock had a copy of the remembered bit for each of its cells,
+ and we were maintaining that bitmap despite no one actually ever consulting it.
+
+ This patch removes MarkedBlock::m_rememberedSet, freeing up 128 bytes in each
+ block and making write barriers a little faster.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::clearRememberedSet):
+ (JSC::Heap::addToRememberedSet):
+ * heap/HeapInlines.h:
+ (JSC::Heap::isRemembered):
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::clearRememberedSet): Deleted.
+ (JSC::MarkedBlock::clearMarksWithCollectionType):
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::setRemembered): Deleted.
+ (JSC::MarkedBlock::clearRemembered): Deleted.
+ (JSC::MarkedBlock::atomicClearRemembered): Deleted.
+ (JSC::MarkedBlock::isRemembered): Deleted.
+ * heap/MarkedSpace.h:
+ (JSC::ClearRememberedSet::operator()): Deleted.
+ (JSC::MarkedSpace::clearRememberedSet): Deleted.
+
+2015-05-20 Andreas Kling <akling@apple.com>
+
+ Eden collections should extend the IncrementalSweeper work list, not replace it.
+ <https://webkit.org/b/145213>
+ <rdar://problem/21002666>
+
+ Reviewed by Geoffrey Garen.
+
+ After an eden collection, the garbage collector was adding all MarkedBlocks containing
+ new objects to the IncrementalSweeper's work list, to make sure they didn't have to
+ wait until the next full collection before getting swept.
+
+ Or at least, that's what it thought it was doing. It turns out that IncrementalSweeper's
+ internal work list is really just a reference to Heap::m_blockSnapshot. I didn't realize
+ this when writing the post-eden sweep code, and instead made eden collections cancel
+ all pending sweeps and *replace* them with the list of blocks with new objects.
+
+ This made it so that rapidly occurring eden collections could prevent large numbers of
+ heap blocks from ever getting swept. This would manifest as accumulation of MarkedBlocks
+ when a system under heavy load was also allocating short lived objects at a high rate.
+ Things would eventually get cleaned up when there was a lull and a full collection was
+ allowed to run its heap sweep to completion.
+
+ Fix this by moving all management of the block snapshot to Heap. snapshotMarkedSpace()
+ now handles eden collections by merging the list of blocks with new objects into the
+ existing block snapshot.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::snapshotMarkedSpace):
+ (JSC::Heap::notifyIncrementalSweeper):
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::startSweeping):
+ (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Deleted.
+ * heap/IncrementalSweeper.h:
+
+2015-05-20 Youenn Fablet <youenn.fablet@crf.canon.fr>
+
+ AudioContext resume/close/suspend should reject promises with a DOM exception in lieu of throwing exceptions
+ https://bugs.webkit.org/show_bug.cgi?id=145064
+
+ Reviewed by Darin Adler.
+
+ Added default message for TypeError.
+
+ * runtime/Error.cpp:
+ (JSC::throwTypeError):
+ * runtime/Error.h:
+
+2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ No LLInt Test Failure: jsc-layout-tests.yaml/js/script-tests/object-literal-duplicate-properties.js.layout-no-llint
+ https://bugs.webkit.org/show_bug.cgi?id=145219
+
+ Reviewed by Mark Lam.
+
+ * jit/JITOperations.cpp:
+ Throw the error we just got, instead of a stack overflow exception.
+ This matches other error handling for callers of prepareForExecution.
+
+2015-05-19 Filip Pizlo <fpizlo@apple.com>
+
+ Add some assertions about the CFG in the loop pre-header creation phase
+ https://bugs.webkit.org/show_bug.cgi?id=145205
+
+ Reviewed by Geoffrey Garen.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::currentNodeOrigin): Add a FIXME.
+ * dfg/DFGLICMPhase.cpp:
+ (JSC::DFG::LICMPhase::run): Add a FIXME.
+ * dfg/DFGLoopPreHeaderCreationPhase.cpp:
+ (JSC::DFG::LoopPreHeaderCreationPhase::run): Add the assertions.
+
+2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Implement Object.setPrototypeOf
+ https://bugs.webkit.org/show_bug.cgi?id=145202
+
+ Reviewed by Darin Adler.
+
+ * runtime/JSGlobalObjectFunctions.h:
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::globalFuncProtoSetter):
+ (JSC::checkProtoSetterAccessAllowed):
+ Extract a helper to share this code between __proto__ setter and setPrototypeOf.
+
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorSetPrototypeOf):
+ Implementation is very similiar to __proto__ setter.
+
+2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Should not allow duplicate basic __proto__ properties in Object Literals
+ https://bugs.webkit.org/show_bug.cgi?id=145138
+
+ Reviewed by Darin Adler.
+
+ Implement ES6 Annex B.3.1, which disallows duplicate basic __proto__
+ properties in object literals. This doesn't affect computed properties,
+ shorthand properties, or getters/setters all of which avoid setting
+ the actual prototype of the object anyway.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::eval):
+ Remove out of date comment. Duplicate property names are allowed
+ now in ES6, they were not in ES5 strict mode.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::getName):
+ (JSC::ASTBuilder::getType):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::getName):
+ Add back getName to get the property name depending on the tree builder.
+ Also tighten up the parameter types.
+
+ * runtime/LiteralParser.cpp:
+ (JSC::LiteralParser<CharType>::parse):
+ In quick JSON literal parsing for eval, we actually need to evaluate
+ the __proto__ property assignment, instead of just building up a list
+ of direct properties. Only do this when not doing a strict JSON parse.
+
+ * parser/Nodes.h:
+ Add "Shorthand" to the list of PropertyNode types to allow it to
+ be distinguished without relying on other information.
+
+ * parser/Parser.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseProperty):
+ Add the Shorthand type when parsing a shorthand property.
+
+ (JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate):
+ (JSC::Parser<LexerType>::parseObjectLiteral):
+ (JSC::Parser<LexerType>::parseStrictObjectLiteral):
+ Check for duplicate __proto__ properties, and throw a SyntaxError
+ if that was the case.
+
+2015-05-20 Csaba Osztrogonác <ossy@webkit.org>
+
+ [JSC] Add missing copyrights and licenses for some scripts
+ https://bugs.webkit.org/show_bug.cgi?id=145044
+
+ Reviewed by Darin Adler.
+
+ * build-symbol-table-index.py:
+ * create-llvm-ir-from-source-file.py:
+ * create-symbol-table-index.py:
+
+2015-05-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Slightly better node previews in arrays
+ https://bugs.webkit.org/show_bug.cgi?id=145188
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.prototype._nodeDescription):
+ (InjectedScript.prototype._nodePreview):
+ Different stringified representations for a basic object description or in a preview.
+
+ (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
+ Use the node preview string representation inside previews.
+
+2015-05-19 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r184613 and r184614.
+ https://bugs.webkit.org/show_bug.cgi?id=145206
+
+ Broke 10 tests :| (Requested by kling on #webkit).
+
+ Reverted changesets:
+
+ "[JSC] Speed up URL encode/decode by using bitmaps instead of
+ strchr()."
+ https://bugs.webkit.org/show_bug.cgi?id=145115
+ http://trac.webkit.org/changeset/184613
+
+ "[JSC] Speed up URL encode/decode by using bitmaps instead of
+ strchr()."
+ https://bugs.webkit.org/show_bug.cgi?id=145115
+ http://trac.webkit.org/changeset/184614
+
+2015-05-19 Andreas Kling <akling@apple.com>
+
+ Give StringView a utf8() API.
+ <https://webkit.org/b/145201>
+
+ Reviewed by Anders Carlsson.
+
+ Use JSString::view() in a few places where we couldn't before due to StringView
+ lacking a utf8() API. This is a minor speed-up on Kraken's crypto subtests,
+ which like to call encode() with substring JSStrings.
+
+ * jsc.cpp:
+ (functionPrint):
+ (functionDebug):
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::encode):
+
+2015-05-19 Andreas Kling <akling@apple.com>
+
+ [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
+ <https://webkit.org/b/145115>
+
+ Incorporate review feedback from Darin, removing some unnecessary zero checks.
+
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::encode):
+ (JSC::decode):
+ (JSC::globalFuncEscape):
+
+2015-05-19 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Move AtomicStringImpl table related operations from AtomicString to AtomicStringImpl
+ https://bugs.webkit.org/show_bug.cgi?id=145109
+
+ Reviewed by Darin Adler.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::nameForRegister):
+ * runtime/Identifier.cpp:
+ (JSC::Identifier::add):
+ (JSC::Identifier::add8):
+ * runtime/Identifier.h:
+ (JSC::Identifier::add):
+ * runtime/IdentifierInlines.h:
+ (JSC::Identifier::Identifier):
+ (JSC::Identifier::add):
+ * runtime/JSString.cpp:
+ (JSC::JSRopeString::resolveRopeToExistingAtomicString):
+ * runtime/JSString.h:
+ (JSC::JSString::toExistingAtomicString):
+ * runtime/SmallStrings.cpp:
+ (JSC::SmallStringsStorage::SmallStringsStorage):
+ * runtime/TypeSet.cpp:
+ (JSC::StructureShape::propertyHash):
+
+2015-05-19 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Improve Preview for NodeList / array like collections
+ https://bugs.webkit.org/show_bug.cgi?id=145177
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ (InjectedScript.RemoteObject.prototype._appendPropertyPreviews):
+ For "array" like object previews skip over non-index properties.
+ We are not marking the object as lossless by choice, but we
+ may return to this decision later.
+
+2015-05-19 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(183787): JIT is enabled for all builds
+ https://bugs.webkit.org/show_bug.cgi?id=145179
+
+ Reviewed by Geoffrey Garen.
+
+ Eliminated the setting of ENABLE_JIT, as wtf/Platform.h has appropriate logic to
+ set it depending on OS and CPU type.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-05-19 Youenn Fablet <youenn.fablet@crf.canon.fr>
+
+ Rename createIterResultObject as createIteratorResultObject
+ https://bugs.webkit.org/show_bug.cgi?id=145116
+
+ Reviewed by Darin Adler.
+
+ Renamed createIterResultObject as createIteratorResultObject.
+ Made this function exportable for future use by streams API.
+
+ * runtime/IteratorOperations.cpp:
+ (JSC::createIteratorResultObject):
+ * runtime/IteratorOperations.h:
+ * runtime/MapIteratorPrototype.cpp:
+ (JSC::MapIteratorPrototypeFuncNext):
+ * runtime/SetIteratorPrototype.cpp:
+ (JSC::SetIteratorPrototypeFuncNext):
+
+2015-05-19 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Array.prototype methods must use ToLength
+ https://bugs.webkit.org/show_bug.cgi?id=144128
+
+ Reviewed by Oliver Hunt.
+
+ Patch by Jordan Harband <ljharb@gmail.com> and Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tolength
+
+ This patch introduces ToLength and ToInteger JS implementation to encourage the DFG/FTL's inlining.
+ These implementations are located in GlobalObject.js.
+ And set to the JSGlobalObject with the private symbols @ToLength and @ToInteger manually.
+
+ * builtins/Array.prototype.js:
+ (every):
+ (forEach):
+ (filter):
+ (map):
+ (some):
+ (fill):
+ (find):
+ (findIndex):
+ (includes):
+ * builtins/ArrayConstructor.js:
+ (from):
+ * builtins/GlobalObject.js: Copied from Source/JavaScriptCore/builtins/StringConstructor.js.
+ (ToInteger):
+ (ToLength):
+ * builtins/StringConstructor.js:
+ (raw):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObjectFunctions.h:
+
+2015-05-19 Mark Lam <mark.lam@apple.com>
+
+ Fix the build of a universal binary with ARMv7k of JavaScriptCore.
+ https://bugs.webkit.org/show_bug.cgi?id=145143
+
+ Reviewed by Geoffrey Garen.
+
+ The offlineasm works in 3 phases:
+
+ Phase 1:
+ Parse the llint asm files for config options and desired offsets.
+ Let's say the offlineasm discovers C unique options and O unique offsets.
+ The offlineasm will then generate a LLIntDesiredOffsets.h file with
+ C x C build configurations, each with a set of O offsets.
+
+ Each of these build configurations is given a unique configuration index number.
+
+ Phase 2:
+ Compile the LLIntDesiredOffsets.h file into a JSCLLIntOffsetsExtractor binary.
+
+ If we're building a fat binary with 2 configurations: armv7, and armv7k,
+ then the fat binary will contain 2 blobs of offsets, one for each of these
+ build configurations.
+
+ Phase 3:
+ Parse the llint asm files and emit asm code using the offsets that are
+ extracted from the JSCLLIntOffsetsExtractor binary for the corresponding
+ configuration index number.
+
+ In the pre-existing code, there are no "if ARMv7k" statements in the llint asm
+ source. As a result, OFFLINE_ASM_ARMv7k is not one of the config options in
+ the set of C unique options.
+
+ For armv7k builds, OFFLINE_ASM_ARMv7 is also true. As a result, for an armv7k
+ target, we will end up building armv7 source. In general, this is fine except:
+
+ 1. armv7k has different alignment requirements from armv7. Hence, their offset
+ values (in JSCLLIntOffsetsExtractor) will be different.
+
+ 2. The offlineasm was never told that it needed to make a different configuration
+ for armv7k builds. Hence, the armv7k build of LLIntDesiredOffsets.h will
+ build the armv7 configuration, and consequently, the armv7k blob of offsets in
+ JSCLLIntOffsetsExtractor will have the same configuration index number as
+ the armv7 blob of offsets.
+
+ In phase 3, when the offlineasm parses the JSCLLIntOffsetsExtractor fat binary
+ looking for the armv7 build's configuration index number, it discovers the
+ armv7k blob which has the same configuration number. As a result, it
+ erroneously thinks the armv7k offsets are appropriate for emitting armv7 code.
+ Needless to say, armv7 code using armv7k offsets will lead to incorrect behavior
+ and all round badness.
+
+ The fix is to add a simple "if ARMv7k" statement to the llint asm files. While
+ the if statement has no body, it does make the offlineasm aware of the need for
+ ARMv7k as a configuration option. As a result, it will generate an armv7k
+ variant configuration in the LLIntDesiredOffsets.h file with its own unique
+ configuration index number. With that, the JSCLLIntOffsetsExtractor fat binary
+ will no longer have duplicate configuration index numbers for the armv7 and
+ armv7k blobs of offsets, and the issue is resolved.
+
+ * llint/LLIntOfflineAsmConfig.h:
+ * llint/LowLevelInterpreter.asm:
+
+2015-05-19 Andreas Kling <akling@apple.com>
+
+ Give JSString a StringView getter and start using it.
+ <https://webkit.org/b/145131>
+
+ Reviewed by Anders Carlsson.
+
+ When JSString is a substring internally, calling value(ExecState*) on it
+ will reify the baseString/start/length tuple into a new StringImpl.
+
+ For clients that only want to look at the characters of a JSString, but
+ don't actually need a reffable StringImpl, adding a light-weight StringView
+ getter lets them avoid constructing anything.
+
+ This patch adds JSString::view(ExecState*) and uses it in a few places.
+ There are many more opportunities to use this API, but let's do a few things
+ at a time.
+
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck):
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::decode):
+ (JSC::parseInt):
+ (JSC::jsToNumber):
+ (JSC::parseFloat):
+ (JSC::globalFuncParseInt):
+ (JSC::globalFuncParseFloat):
+ (JSC::globalFuncEscape):
+ (JSC::globalFuncUnescape):
+ * runtime/JSGlobalObjectFunctions.h:
+ * runtime/JSONObject.cpp:
+ (JSC::JSONProtoFuncParse):
+ * runtime/JSString.cpp:
+ (JSC::JSString::getPrimitiveNumber):
+ (JSC::JSString::toNumber):
+ * runtime/JSString.h:
+ (JSC::JSRopeString::view):
+ (JSC::JSString::view):
+
+2015-05-18 Filip Pizlo <fpizlo@apple.com>
+
+ Better optimize 'if' with ternaries conditional tests.
+ https://bugs.webkit.org/show_bug.cgi?id=144136
+
+ Reviewed by Benjamin Poulain.
+
+ This is the last fix I'll do for this for now. BooleanToNumber(Untyped:) where the input
+ is proved to be either BoolInt32 or Boolean should be optimized to just masking the
+ lowest bit.
+
+ This is another 37% speed-up on JSRegress/slow-ternaries.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
+
+2015-05-18 Benjamin Poulain <bpoulain@apple.com>
+
+ <rdar://problem/21003555> cloberrize() is wrong for ArithRound because it doesn't account for the arith mode
+ https://bugs.webkit.org/show_bug.cgi?id=145147
+
+ Reviewed by Filip Pizlo.
+
+ Really stupid bug: ArithRound nodes with different rounding modes
+ were not distinguished and CSE would happily unify with a node of
+ a different rounding mode.
+
+ DFG::clobberize() already support additional data but I was not using it.
+
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * tests/stress/math-round-arith-rounding-mode.js: Added.
+ (firstCareAboutZeroSecondDoesNot):
+ (firstDoNotCareAboutZeroSecondDoes):
+ (warmup):
+ (verifyNegativeZeroIsPreserved):
+
+2015-05-18 Filip Pizlo <fpizlo@apple.com>
+
+ Add SpecBoolInt32 type that means "I'm an int and I'm either 0 or 1"
+ https://bugs.webkit.org/show_bug.cgi?id=145137
+
+ Reviewed by Benjamin Poulain.
+
+ It's super useful to know if an integer value could be either zero or one. We have an
+ immediate need for this because of Int32|Boolean uses, where knowing that the Int32 is
+ either 0 or 1 means that there is no actual polymorphism if you just look at the low bit
+ (1 behaves like true, 0 behaves like false, and the low bit of 1|true is 1, and the low
+ bit of 0|false is 0).
+
+ We do this by splitting the SpecInt32 type into SpecBoolInt32 and SpecNonBoolInt32. This
+ change doesn't have any effect on behavior, yet. But it does give us the ability to
+ predict and prove when values are SpecBoolInt32; it's just we don't leverage this yet.
+
+ This is perf-neutral.
+
+ * bytecode/SpeculatedType.cpp:
+ (JSC::dumpSpeculation):
+ (JSC::speculationToAbbreviatedString):
+ (JSC::speculationFromValue):
+ * bytecode/SpeculatedType.h:
+ (JSC::isStringOrStringObjectSpeculation):
+ (JSC::isBoolInt32Speculation):
+ (JSC::isInt32Speculation):
+ (JSC::isInt32OrBooleanSpeculation):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2015-05-18 Michael Catanzaro <mcatanzaro@igalia.com>
+
+ [CMake] Ignore warnings in system headers
+ https://bugs.webkit.org/show_bug.cgi?id=144747
+
+ Reviewed by Darin Adler.
+
+ Separate include directories into WebKit project includes and system includes. Suppress all
+ warnings from headers in system include directories using the SYSTEM argument to
+ the include_directories command.
+
+ * CMakeLists.txt:
+ * PlatformGTK.cmake:
+
+2015-05-18 Skachkov Alexandr <gskachkov@gmail.com>
+
+ [ES6] Arrow function syntax. Feature flag for arrow function
+ https://bugs.webkit.org/show_bug.cgi?id=145108
+
+ Reviewed by Ryosuke Niwa.
+
+ Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-05-18 Benjamin Poulain <benjamin@webkit.org>
+
+ [JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
+ https://bugs.webkit.org/show_bug.cgi?id=145092
+
+ Reviewed by Filip Pizlo.
+
+ When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
+ we get the inside loop driving the tierUpCounter and we have very little chance of
+ doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
+ up in the outer loop and OSR Enter there.
+
+ This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.
+
+ To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
+ enter their CheckTierUp regardless of the tier-up counter.
+
+ * bytecode/ExecutionCounter.cpp:
+ (JSC::ExecutionCounter<countingVariant>::setThreshold):
+ This is somewhat unrelated. This assertion is incorrect because it relies on
+ m_counter, which changes on an other thread.
+
+ I have hit it a couple of times with this patch because we are a bit more aggressive
+ on CheckTierUp. What happens is:
+ 1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
+ hasCrossedThreshold(), and it is false.
+ 2) On the main thread, the hot loops keeps running and the counter becomes large
+ enough to cross the threshold.
+ 3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
+ test, setThreshold(), where the assertion is. Since the counter is now large enough,
+ the assertion fails.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+
+ * dfg/DFGJITCode.h:
+ I used a uint8_t instead of a boolean to make the code generation clearer
+ in DFGSpeculativeJIT64.
+
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ This is a bit annoying: we have the NaturalLoops analysis that provides us
+ everything we need to know about loops, but the TierUpCheck are conservative
+ and set on LoopHint.
+
+ To make the two work together, we first find all the CheckTierUp that cannot
+ OSR enter and we keep a list of all the natural loops containing them.
+
+ Then we do a second pass over the LoopHints, get their NaturalLoop, and check
+ if it contains a loop that cannot OSR enter.
+
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGTierUpCheckInjectionPhase.cpp:
+ (JSC::DFG::TierUpCheckInjectionPhase::run):
+ (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
+
+2015-05-18 Filip Pizlo <fpizlo@apple.com>
+
+ Add a Int-or-Boolean speculation to Branch
+ https://bugs.webkit.org/show_bug.cgi?id=145134
+
+ Reviewed by Benjamin Poulain.
+
+ After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
+ int-or-boolean optimization that we already do everywhere else.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+
+2015-05-18 Andreas Kling <akling@apple.com>
+
+ [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
+ <https://webkit.org/b/145115>
+
+ Reviewed by Anders Carlsson.
+
+ We were calling strchr() for every character when doing URL encoding/decoding and it stood out
+ like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
+
+ 5.5% progression on Kraken/stanford-crypto-sha256-iterative.
+
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::makeCharacterBitmap):
+ (JSC::encode):
+ (JSC::decode):
+ (JSC::globalFuncDecodeURI):
+ (JSC::globalFuncDecodeURIComponent):
+ (JSC::globalFuncEncodeURI):
+ (JSC::globalFuncEncodeURIComponent):
+ (JSC::globalFuncEscape):
+
+2015-05-17 Benjamin Poulain <benjamin@webkit.org>
+
+ Do not use fastMallocGoodSize anywhere
+ https://bugs.webkit.org/show_bug.cgi?id=145103
+
+ Reviewed by Michael Saboff.
+
+ * assembler/AssemblerBuffer.h:
+ (JSC::AssemblerData::AssemblerData):
+ (JSC::AssemblerData::grow):
+
+2015-05-17 Benjamin Poulain <benjamin@webkit.org>
+
+ [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
+ https://bugs.webkit.org/show_bug.cgi?id=145102
+
+ Reviewed by Darin Adler.
+
+ In general, the array targeted by Array.toString() or Array.join() are pretty
+ simple. In those simple cases, we spend as much time in StringRecursionChecker
+ as we do on the actual operation.
+
+ The reason for this is the HashSet stringRecursionCheckVisitedObjects used
+ to detect recursion. We are constantly adding and removing objects which
+ dirty buckets and force constant rehash.
+
+ This patch adds a simple shortcut for those simple case: in addition to the HashSet,
+ we keep a pointer to the root object of the recursion.
+ In the vast majority of cases, we no longer touch the HashSet at all.
+
+ This patch is a 12% progression on the overall score of ArrayWeighted.
+
+ * runtime/StringRecursionChecker.h:
+ (JSC::StringRecursionChecker::performCheck):
+ (JSC::StringRecursionChecker::~StringRecursionChecker):
+ * runtime/VM.h:
+
+2015-05-17 Filip Pizlo <fpizlo@apple.com>
+
+ Insert store barriers late so that IR transformations don't have to worry about them
+ https://bugs.webkit.org/show_bug.cgi?id=145015
+
+ Reviewed by Geoffrey Garen.
+
+ We have had three kinds of bugs with store barriers. For the sake of discussion we say
+ that a store barrier is needed when we have something like:
+
+ base.field = value
+
+ - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
+ This might happen if we prove value to be a non-cell even though in the FixupPhase it
+ wasn't predicted non-cell.
+
+ - We sometimes have a barrier in the wrong place after object allocation sinking. We
+ might sink an allocation to just above the store, but that puts it just after the
+ StoreBarrier that FixupPhase inserted.
+
+ - We don't remove redundant barriers across basic blocks.
+
+ This comprehensively fixes these issues by doing store barrier insertion late, and
+ removing the store barrier elision phase. Store barrier insertion uses an epoch-based
+ algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
+ base is in the current GC epoch (i.e. was the last object that we allocated or had a
+ barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
+ always been allocated before base). We do conservative things when merging epoch state
+ between basic blocks, and we only do such inter-block removal in the FTL. FTL also
+ queries AI to determine what type we've proved about value, and avoids barriers when
+ value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
+ the likelihood that this AI-based removal is effective.
+
+ Rolling back in after fixing some debug build test failures.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGBlockMap.h:
+ (JSC::DFG::BlockMap::at):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
+ * dfg/DFGEpoch.h:
+ (JSC::DFG::Epoch::operator<):
+ (JSC::DFG::Epoch::operator>):
+ (JSC::DFG::Epoch::operator<=):
+ (JSC::DFG::Epoch::operator>=):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::speculateForBarrier):
+ (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
+ * dfg/DFGStoreBarrierElisionPhase.h: Removed.
+ * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
+ (JSC::DFG::performFastStoreBarrierInsertion):
+ (JSC::DFG::performGlobalStoreBarrierInsertion):
+ * dfg/DFGStoreBarrierInsertionPhase.h: Added.
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
+ * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
+ * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
+
+2015-05-16 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r184415.
+ https://bugs.webkit.org/show_bug.cgi?id=145096
+
+ Broke several tests (Requested by msaboff on #webkit).
+
+ Reverted changeset:
+
+ "Insert store barriers late so that IR transformations don't
+ have to worry about them"
+ https://bugs.webkit.org/show_bug.cgi?id=145015
+ http://trac.webkit.org/changeset/184415
+
+2015-05-14 Filip Pizlo <fpizlo@apple.com>
+
+ Insert store barriers late so that IR transformations don't have to worry about them
+ https://bugs.webkit.org/show_bug.cgi?id=145015
+
+ Reviewed by Geoffrey Garen.
+
+ We have had three kinds of bugs with store barriers. For the sake of discussion we say
+ that a store barrier is needed when we have something like:
+
+ base.field = value
+
+ - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
+ This might happen if we prove value to be a non-cell even though in the FixupPhase it
+ wasn't predicted non-cell.
+
+ - We sometimes have a barrier in the wrong place after object allocation sinking. We
+ might sink an allocation to just above the store, but that puts it just after the
+ StoreBarrier that FixupPhase inserted.
+
+ - We don't remove redundant barriers across basic blocks.
+
+ This comprehensively fixes these issues by doing store barrier insertion late, and
+ removing the store barrier elision phase. Store barrier insertion uses an epoch-based
+ algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
+ base is in the current GC epoch (i.e. was the last object that we allocated or had a
+ barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
+ always been allocated before base). We do conservative things when merging epoch state
+ between basic blocks, and we only do such inter-block removal in the FTL. FTL also
+ queries AI to determine what type we've proved about value, and avoids barriers when
+ value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
+ the likelihood that this AI-based removal is effective.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGBlockMap.h:
+ (JSC::DFG::BlockMap::at):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
+ * dfg/DFGEpoch.h:
+ (JSC::DFG::Epoch::operator<):
+ (JSC::DFG::Epoch::operator>):
+ (JSC::DFG::Epoch::operator<=):
+ (JSC::DFG::Epoch::operator>=):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::speculateForBarrier):
+ (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
+ * dfg/DFGStoreBarrierElisionPhase.h: Removed.
+ * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
+ (JSC::DFG::performFastStoreBarrierInsertion):
+ (JSC::DFG::performGlobalStoreBarrierInsertion):
+ * dfg/DFGStoreBarrierInsertionPhase.h: Added.
+
+2015-05-15 Benjamin Poulain <bpoulain@apple.com>
+
+ [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
+ https://bugs.webkit.org/show_bug.cgi?id=144976
+
+ Reviewed by Michael Saboff.
+
+ Failing the conversion on zero is pretty dangerous as we discovered on x86.
+
+ This patch does not really impact performance significantly because
+ r184220 removed the zero checks from Kraken. This patch is just to be
+ on the safe side for cases not covered by existing benchmarks.
+
+ * assembler/MacroAssemblerARM64.h:
+ (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
+
+2015-05-15 Sungmann Cho <sungmann.cho@navercorp.com>
+
+ Remove unnecessary forward declarations in PropertyNameArray.h.
+ https://bugs.webkit.org/show_bug.cgi?id=145058
+
+ Reviewed by Andreas Kling.
+
+ No new tests, no behavior change.
+
+ * runtime/PropertyNameArray.h:
+
+2015-05-15 Mark Lam <mark.lam@apple.com>
+
+ JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
+ https://bugs.webkit.org/show_bug.cgi?id=144622
+
+ Reviewed by Geoffrey Garen.
+
+ When setting the array to a new length that is shorter, we now check if it is worth
+ just making a new butterfly instead of clearing out the slots in the old butterfly
+ that resides beyond the new length. If so, we will make a new butterfly instead.
+
+ There is no perf differences in the benchmark results. However, this does benefit
+ the perf of pathological cases where we need to shorten the length of a very large
+ array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js. With this
+ patch, we can expect that test to complete in a short time again.
+
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::setLength):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::reallocateAndShrinkButterfly):
+ - makes a new butterfly with a new shorter length.
+ * runtime/JSObject.h:
+ * tests/mozilla/js1_5/Array/regress-101964.js:
+ - Undo this test change since this patch will prevent us from spending a lot of time
+ clearing a large butterfly.
+
+2015-05-15 Basile Clement <basile_clement@apple.com>
+
+ DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
+ https://bugs.webkit.org/show_bug.cgi?id=145062
+
+ Reviewed by Filip Pizlo.
+
+ We assert in various places (including NodeOrigin::isSet()) that a
+ NodeOrigin's semantic and forExit must be either both set, or both
+ unset. However, LICM'ing a node with unset NodeOrigin would only set
+ forExit, and leave semantic unset. This can for instance happen when a
+ Phi node is constant-folded into a JSConstant, which in turn gets
+ LICM'd.
+
+ This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
+ addition to its forExit if semantic was previously unset.
+
+ It also adds two validators to DFGValidate.cpp:
+ - In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
+ - In CPS form, all nodes must have a set NodeOrigin forExit (this is
+ the CPS counterpart to the SSA validator that checks that all nodes
+ must have a set NodeOrigin except possibly for a continuous chunk of
+ nodes at the top of a block)
+
+ * dfg/DFGLICMPhase.cpp:
+ (JSC::DFG::LICMPhase::attemptHoist):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validate):
+ (JSC::DFG::Validate::validateCPS):
+
+2015-05-15 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, remove an unused declaration.
+
+ * dfg/DFGSpeculativeJIT.h:
+
+2015-05-14 Filip Pizlo <fpizlo@apple.com>
+
+ Remove unused constant-base and constant-value store barrier code in the DFG
+ https://bugs.webkit.org/show_bug.cgi?id=145039
+
+ Reviewed by Andreas Kling.
+
+ Just killing dead code.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
+ (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::writeBarrier):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::writeBarrier):
+
+2015-05-15 Alexandr Skachkov <gskachkov@gmail.com>
+
+ Fix typo in function name parseFunctionParamters -> parseFunctionParameters
+ https://bugs.webkit.org/show_bug.cgi?id=145040
+
+ Reviewed by Mark Lam.
+
+ * parser/Parser.h:
+ * parser/Parser.cpp:
+
+2015-05-14 Filip Pizlo <fpizlo@apple.com>
+
+ Remove StoreBarrierWithNullCheck, nobody ever generates this.
+
+ Rubber stamped by Benjamin Poulain and Michael Saboff.
+
+ If we did bring something like this back in the future, we would just use UntypedUse instead
+ of CellUse to indicate that this is what we want.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::isStoreBarrier):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (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::compileStoreBarrierWithNullCheck): Deleted.
+
+2015-05-14 Filip Pizlo <fpizlo@apple.com>
+
+ PutGlobalVar should reference the global object it's storing into
+ https://bugs.webkit.org/show_bug.cgi?id=145036
+
+ Reviewed by Michael Saboff.
+
+ This makes it easier to reason about store barrier insertion and elimination. This changes
+ the format of PutGlobalVar so that child1 is the global object and child2 is the value.
+ Previously it just had child1, and that was the value.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
+
+2015-05-14 Michael Catanzaro <mcatanzaro@igalia.com>
+
+ [CMake] Error out when ruby is too old
+ https://bugs.webkit.org/show_bug.cgi?id=145014
+
+ Reviewed by Martin Robinson.
+
+ Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
+ CMakeLists.txt instead.
+
+ * CMakeLists.txt:
+
+2015-05-12 Basile Clement <basile_clement@apple.com>
+
+ Enforce options coherency
+ https://bugs.webkit.org/show_bug.cgi?id=144921
+
+ Reviewed by Mark Lam.
+
+ JavaScriptCore should be failing early when the options are set in such
+ a way that we don't have a meaningful way to execute JavaScript, rather
+ than failing for obscure reasons at some point during execution.
+
+ This patch adds a new function that checks whether the options are set
+ in a coherent way, and makes JSC::Options::initialize() crash when the
+ environment enforces incoherent options.
+ Client applications able to add or change additional options are
+ responsible to check for coherency again before starting to actually
+ execute JavaScript, if any additional options have been set. This is
+ implemented for the jsc executable in this patch.
+
+ * jsc.cpp:
+ (CommandLine::parseArguments):
+ * runtime/Options.cpp:
+ (JSC::Options::initialize):
+ (JSC::Options::ensureOptionsAreCoherent): Added.
+ * runtime/Options.h:
+ (JSC::Options::ensureOptionsAreCoherent): Added.
+
+2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
+ https://bugs.webkit.org/show_bug.cgi?id=145019
+
+ Reviewed by Ryosuke Niwa.
+
+ Attempt to fix compile errors in EFL ARM buildbots.
+ By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
+ unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
+
+ * runtime/JSTemplateRegistryKey.cpp:
+ * runtime/TemplateRegistry.cpp:
+
+2015-05-14 Alexandr Skachkov <gskachkov@gmail.com>
+
+ Small refactoring before implementation of the ES6 arrow function.
+ https://bugs.webkit.org/show_bug.cgi?id=144954
+
+ Reviewed by Ryosuke Niwa.
+
+ * parser/Parser.h:
+ * parser/Parser.cpp:
+
+2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
+ https://bugs.webkit.org/show_bug.cgi?id=145013
+
+ Reviewed by Filip Pizlo.
+
+ Fix the regression introduced by r184337.
+
+ 1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
+ JSDestructibleObject::s_info.
+
+ 2. The first register argument of BytecodeGenerator::emitNode
+ should be a referenced register if it is a temporary register.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::TaggedTemplateNode::emitBytecode):
+ * runtime/JSTemplateRegistryKey.cpp:
+
+2015-05-14 Andreas Kling <akling@apple.com>
+
+ String.prototype.split() should create efficient substrings.
+ <https://webkit.org/b/144985>
+ <rdar://problem/20949344>
+
+ Reviewed by Geoffrey Garen.
+
+ Teach split() how to make substring JSStrings instead of relying on StringImpl's
+ substring sharing mechanism. The optimization works by deferring the construction
+ of a StringImpl until the substring's value is actually needed.
+
+ This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
+ Out of ~70000 substrings created by split(), only ~2000 of them get reified.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::jsSubstring):
+ (JSC::splitStringByOneCharacterImpl):
+ (JSC::stringProtoFuncSplit):
+
+2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Change the status of ES6 tagged templates to Done in features.json
+ https://bugs.webkit.org/show_bug.cgi?id=145003
+
+ Reviewed by Benjamin Poulain.
+
+ Now it's implemented in r184337.
+
+ * features.json:
+
+2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Introduce SymbolType into SpeculativeTypes
+ https://bugs.webkit.org/show_bug.cgi?id=142651
+
+ Reviewed by Filip Pizlo.
+
+ Introduce SpecSymbol type into speculative types.
+ Previously symbol type is categorized into SpecCellOther.
+ But SpecCellOther is not intended to be used for such cells.
+
+ This patch just introduces SpecSymbol.
+ It represents the type of target value is definitely the symbol type.
+ It is the part of SpecCell.
+
+ In this patch, we do not introduce SymbolUse tracking.
+ It will be added in the separate patch.
+
+ * bytecode/SpeculatedType.cpp:
+ (JSC::dumpSpeculation):
+ (JSC::speculationFromStructure):
+ * bytecode/SpeculatedType.h:
+ (JSC::isSymbolSpeculation):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGAbstractValue.cpp:
+ (JSC::DFG::AbstractValue::setType):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * tests/stress/typeof-symbol.js: Added.
+
+2015-05-14 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement tagged templates
+ https://bugs.webkit.org/show_bug.cgi?id=143183
+
+ Reviewed by Oliver Hunt.
+
+ This patch implements ES6 tagged templates.
+ In tagged templates, the function takes the template object.
+
+ The template object contains the raw and cooked template strings,
+ so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
+ While tagged templates require the both strings, the template literal only requires
+ the cooked strings. So when tokenizing under the template literal context,
+ we only builds the cooked strings.
+
+ As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
+ The template objects is cached. And every time we evaluate the same tagged templates,
+ the same (cached) template objects are used.
+ Since the spec freezes this template objects completely,
+ we cannot attach some properties to it.
+ So we can say that it behaves as if the template objects are the primitive values (like JSString).
+ Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
+ As the result, when there is no reference to the template object, we can garbage collect it
+ because the user has no way to test that the newly created template object does not equal
+ to the already collected template object.
+
+ So, to implement tagged templates, we implement the following components.
+
+ 1. JSTemplateRegistryKey
+ It holds the template registry key and it does not exposed to users.
+ TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
+ When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
+ we use this JSTemplateRegistryKey as a key to the map and look up the template object from
+ TemplateRegistry.
+ JSTemplateRegistryKey is created at the bytecode compiling time and
+ stored in the CodeBlock as like as JSString content values.
+
+ 2. TemplateRegistry
+ This manages the cached template objects.
+ It holds the weak map (JSTemplateRegistryKey -> the template object).
+ The template object is weakly referenced.
+ So if there is no reference to the template object,
+ the template object is automatically GC-ed.
+ When looking up the template object, it searches the cached template object.
+ If it is found, it is returned to the users.
+ If there is no cached template objects, it creates the new template object and
+ stores it with the given template registry key.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
+ (JSC::BytecodeGenerator::emitGetTemplateObject):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::TaggedTemplateNode::emitBytecode):
+ (JSC::TemplateLiteralNode::emitBytecode): Deleted.
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createTaggedTemplate):
+ (JSC::ASTBuilder::createTemplateLiteral): Deleted.
+ * parser/Lexer.cpp:
+ (JSC::Lexer<T>::setCode):
+ (JSC::Lexer<T>::parseTemplateLiteral):
+ (JSC::Lexer<T>::lex):
+ (JSC::Lexer<T>::scanTrailingTemplateString):
+ (JSC::Lexer<T>::clear):
+ * parser/Lexer.h:
+ (JSC::Lexer<T>::makeEmptyIdentifier):
+ * parser/NodeConstructors.h:
+ (JSC::TaggedTemplateNode::TaggedTemplateNode):
+ (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
+ * parser/Nodes.h:
+ (JSC::TemplateLiteralNode::templateStrings):
+ (JSC::TemplateLiteralNode::templateExpressions):
+ (JSC::TaggedTemplateNode::templateLiteral):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseTemplateString):
+ (JSC::Parser<LexerType>::parseTemplateLiteral):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ (JSC::Parser<LexerType>::parseMemberExpression):
+ * parser/Parser.h:
+ * parser/ParserArena.h:
+ (JSC::IdentifierArena::makeEmptyIdentifier):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createTaggedTemplate):
+ (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::getTemplateObject):
+ (JSC::JSGlobalObject::JSGlobalObject):
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::templateRegistry):
+ * runtime/JSTemplateRegistryKey.cpp: Added.
+ (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
+ (JSC::JSTemplateRegistryKey::create):
+ (JSC::JSTemplateRegistryKey::destroy):
+ * runtime/JSTemplateRegistryKey.h: Added.
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorFreeze):
+ * runtime/ObjectConstructor.h:
+ * runtime/TemplateRegistry.cpp: Added.
+ (JSC::TemplateRegistry::TemplateRegistry):
+ (JSC::TemplateRegistry::getTemplateObject):
+ * runtime/TemplateRegistry.h: Added.
+ * runtime/TemplateRegistryKey.h: Added.
+ (JSC::TemplateRegistryKey::isDeletedValue):
+ (JSC::TemplateRegistryKey::isEmptyValue):
+ (JSC::TemplateRegistryKey::hash):
+ (JSC::TemplateRegistryKey::rawStrings):
+ (JSC::TemplateRegistryKey::cookedStrings):
+ (JSC::TemplateRegistryKey::operator==):
+ (JSC::TemplateRegistryKey::operator!=):
+ (JSC::TemplateRegistryKey::Hasher::hash):
+ (JSC::TemplateRegistryKey::Hasher::equal):
+ (JSC::TemplateRegistryKey::TemplateRegistryKey):
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+ * tests/stress/tagged-templates-identity.js: Added.
+ (shouldBe):
+ * tests/stress/tagged-templates-raw-strings.js: Added.
+ (shouldBe):
+ (tag):
+ (testEval):
+ * tests/stress/tagged-templates-syntax.js: Added.
+ (tag):
+ (testSyntax):
+ (testSyntaxError):
+ * tests/stress/tagged-templates-template-object.js: Added.
+ (shouldBe):
+ (tag):
+ * tests/stress/tagged-templates-this.js: Added.
+ (shouldBe):
+ (tag):
+ * tests/stress/tagged-templates.js: Added.
+ (shouldBe):
+ (raw):
+ (cooked):
+ (Counter):
+
+2015-05-13 Ryosuke Niwa <rniwa@webkit.org>
+
+ REGRESSION(r180595): same-callee profiling no longer works
+ https://bugs.webkit.org/show_bug.cgi?id=144787
+
+ Reviewed by Filip Pizlo.
+
+ This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
+ always the same JSFunction. This condition doesn't hold when the byte code creates multiple
+ JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
+
+ To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
+ added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
+ our speculation that the callee is the same. To avoid recompiling the same code for different callee
+ objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
+ LLint and baseline JIT when multiple callees are observed.
+
+ Tests: stress/create-this-with-callee-variants.js
+
+ * bytecode/BytecodeList.json: Increased the number of operands to 5.
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
+ (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
+ we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
+ operand.
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
+ match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
+ as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
+ (JSC::JIT::emitSlow_op_create_this):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_this): Ditto.
+ (JSC::JIT::emitSlow_op_create_this):
+ * llint/LowLevelInterpreter32_64.asm:
+ (_llint_op_create_this): Ditto.
+ * llint/LowLevelInterpreter64.asm:
+ (_llint_op_create_this): Ditto.
+ * runtime/CommonSlowPaths.cpp:
+ (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
+ been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
+ * runtime/JSCell.h:
+ (JSC::JSCell::seenMultipleCalleeObjects): Added.
+ * runtime/WriteBarrier.h:
+ (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
+ * tests/stress/create-this-with-callee-variants.js: Added.
+
+2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ Clean up some possible RefPtr to PassRefPtr churn
+ https://bugs.webkit.org/show_bug.cgi?id=144779
+
+ Reviewed by Darin Adler.
+
+ * runtime/GenericTypedArrayViewInlines.h:
+ (JSC::GenericTypedArrayView<Adaptor>::create):
+ (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
+ * runtime/JSArrayBufferConstructor.cpp:
+ (JSC::constructArrayBuffer):
+ * runtime/Structure.cpp:
+ (JSC::Structure::toStructureShape):
+ * runtime/TypedArrayBase.h:
+ (JSC::TypedArrayBase::create):
+ (JSC::TypedArrayBase::createUninitialized):
+ * tools/FunctionOverrides.cpp:
+ (JSC::initializeOverrideInfo):
+ Release the last use of a RefPtr as it is passed on.
+
+2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Allow duplicate property names
+ https://bugs.webkit.org/show_bug.cgi?id=142895
+
+ Reviewed by Geoffrey Garen.
+
+ Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
+ that will define a single getter or setter property on an object.
+
+ The existing `op_put_getter_setter` opcode is still preferred for
+ putting both a getter and setter at the same time but cannot be used
+ for putting an individual getter or setter which is needed in
+ some cases.
+
+ Add a new slow path when generating bytecodes for a property list
+ with computed properties, as computed properties are the only time
+ the list of properties cannot be determined statically.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::PropertyListNode::emitBytecode):
+ - fast path for all constant properties
+ - slow but paired getter/setter path if there are no computed properties
+ - slow path, individual put operation for every property, if there are computed properties
+
+ * parser/Nodes.h:
+ Distinguish a Computed property from a Constant property.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseProperty):
+ (JSC::Parser<LexerType>::parsePropertyMethod):
+ Distingish Computed and Constant properties.
+
+ (JSC::Parser<LexerType>::parseObjectLiteral):
+ When we drop into strict mode it is because we saw a getter
+ or setter, so be more explicit.
+
+ (JSC::Parser<LexerType>::parseStrictObjectLiteral):
+ Eliminate duplicate property syntax error exception.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::getName):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::getName): Deleted.
+ No longer used.
+
+ * runtime/JSObject.h:
+ (JSC::JSObject::putDirectInternal):
+ When updating a property. If the Accessor attribute changed
+ update the Structure.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::putGetter):
+ (JSC::JSObject::putSetter):
+ Called by the opcodes, just perform the same operation that
+ __defineGetter__ or __defineSetter__ would do.
+
+ (JSC::JSObject::putDirectNonIndexAccessor):
+ This transition is now handled in putDirectInternal.
+
+ * runtime/Structure.h:
+ Add needed export.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitPutGetterById):
+ (JSC::BytecodeGenerator::emitPutSetterById):
+ * bytecompiler/BytecodeGenerator.h:
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emit_op_put_getter_by_id):
+ (JSC::JIT::emit_op_put_setter_by_id):
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emit_op_put_getter_by_id):
+ (JSC::JIT::emit_op_put_setter_by_id):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LLIntSlowPaths.h:
+ * llint/LowLevelInterpreter.asm:
+ New bytecodes. Modelled after existing op_put_getter_setter.
+
+2015-05-13 Filip Pizlo <fpizlo@apple.com>
+
+ Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
+ https://bugs.webkit.org/show_bug.cgi?id=144856
+
+ Reviewed by Benjamin Poulain.
+
+ First I made fixTypeForRepresentation() print out better diagnostics when it dies.
+
+ Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
+ converts to a representation-changing node, it needs to use one of the UseKinds that such
+ a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
+ something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
+
+ * dfg/DFGAbstractInterpreter.h:
+ (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGAbstractValue.cpp:
+ (JSC::DFG::AbstractValue::fixTypeForRepresentation):
+ * dfg/DFGAbstractValue.h:
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::initialize):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::convertToIdentityOn):
+ * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
+ (foo):
+
+2015-05-13 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r184313.
+ https://bugs.webkit.org/show_bug.cgi?id=144974
+
+ Introduced an assertion failure in class-syntax-
+ declaration.js, class-syntax-expression.js, and object-
+ literal-syntax.js (Requested by rniwa on #webkit).
+
+ Reverted changeset:
+
+ "Small refactoring before ES6 Arrow function implementation."
+ https://bugs.webkit.org/show_bug.cgi?id=144954
+ http://trac.webkit.org/changeset/184313
+
+2015-05-13 Oliver Hunt <oliver@apple.com>
+ Ensure that all the smart pointer types in WTF clear their pointer before deref
+ https://bugs.webkit.org/show_bug.cgi?id=143789
+
+ Reviewed by Ryosuke Niwa.
+
+ One of the simpler cases of this in JavaScriptCore. There
+ are other cases where we need to guard the derefs but they
+ are more complex cases.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::releaseImpl):
+ * inspector/JSJavaScriptCallFrame.cpp:
+ (Inspector::JSJavaScriptCallFrame::releaseImpl):
+
+2015-05-13 Alexandr Skachkov <gskachkov@gmail.com>
+
+ Small refactoring before ES6 Arrow function implementation.
+ https://bugs.webkit.org/show_bug.cgi?id=144954
+
+ Reviewed by Filip Pizlo.
+
+ * parser/Parser.h:
+ * parser/Parser.cpp:
+
+2015-05-13 Filip Pizlo <fpizlo@apple.com>
+
+ The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
+ https://bugs.webkit.org/show_bug.cgi?id=144945
+
+ Reviewed by Michael Saboff.
+
+ We were making the mistake of using DFG liveness for object allocation sinking decisions.
+ This is wrong. In fact we almost never want to use DFG liveness directly. The only place
+ where that makes sense is pruning in DFG AI.
+
+ So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
+ liveness.
+
+ In the process of doing this, I realized that the DFGForAllKills definition of combined
+ liveness at block tail was not strictly right; it was using the bytecode liveness at the
+ block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
+ I changed DFGForAllKills to work in terms of CombinedLiveness.
+
+ This allows me to unskip the test I added in r184260. I also added a new test that tries to
+ trigger this bug more directly.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGCombinedLiveness.cpp: Added.
+ (JSC::DFG::liveNodesAtHead):
+ (JSC::DFG::CombinedLiveness::CombinedLiveness):
+ * dfg/DFGCombinedLiveness.h: Added.
+ (JSC::DFG::CombinedLiveness::CombinedLiveness):
+ * dfg/DFGForAllKills.h:
+ (JSC::DFG::forAllKillsInBlock):
+ (JSC::DFG::forAllLiveNodesAtTail): Deleted.
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
+ (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
+ (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
+ (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
+ * tests/stress/escape-object-in-diamond-then-exit.js: Added.
+ * tests/stress/sink-object-past-invalid-check-sneaky.js:
+
+2015-05-13 Ryosuke Niwa <rniwa@webkit.org>
+
+ I skipped a wrong test in r184270. Fix that.
+ The failure is tracked by webkit.org/b/144947.
+
+ * tests/stress/arith-modulo-node-behaviors.js:
+ * tests/stress/arith-mul-with-constants.js:
+
+2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ Avoid always running some debug code in type profiling
+ https://bugs.webkit.org/show_bug.cgi?id=144775
+
+ Reviewed by Daniel Bates.
+
+ * runtime/TypeProfilerLog.cpp:
+ (JSC::TypeProfilerLog::processLogEntries):
+
+2015-05-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ Pass String as reference in more places
+ https://bugs.webkit.org/show_bug.cgi?id=144769
+
+ Reviewed by Daniel Bates.
+
+ * debugger/Breakpoint.h:
+ (JSC::Breakpoint::Breakpoint):
+ * parser/Parser.h:
+ (JSC::Parser::setErrorMessage):
+ (JSC::Parser::updateErrorWithNameAndMessage):
+ * parser/ParserError.h:
+ (JSC::ParserError::ParserError):
+ * runtime/RegExp.cpp:
+ (JSC::RegExpFunctionalTestCollector::outputOneTest):
+ * runtime/RegExpObject.cpp:
+ (JSC::regExpObjectSourceInternal):
+ * runtime/TypeProfiler.cpp:
+ (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
+ * runtime/TypeProfilerLog.cpp:
+ (JSC::TypeProfilerLog::processLogEntries):
+ * runtime/TypeProfilerLog.h:
+ * tools/FunctionOverrides.cpp:
+ (JSC::initializeOverrideInfo):
+ * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
+ (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
+
+ * inspector/scripts/codegen/objc_generator_templates.py:
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ Rebaseline tests after updating the generator.
+
+2015-05-13 Michael Saboff <msaboff@apple.com>
+
+ com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
+ https://bugs.webkit.org/show_bug.cgi?id=144933
+
+ Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT. Added some diagnostic messages to
+ help determine the cause for any crash.
+
+ Reviewed by Geoffrey Garen.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::finalizeUnconditionally):
+
+2015-05-13 Filip Pizlo <fpizlo@apple.com>
+
+ REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
+ https://bugs.webkit.org/show_bug.cgi?id=144951
+
+ Reviewed by Michael Saboff.
+
+ There were two issues here:
+
+ - In r184260 we expected a small number of possible use kinds in Check nodes, and
+ UntypedUse was not one of them. That seemed like a sensible assumption because we don't
+ create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
+ Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
+ follow the same idiom as everyone else and not create tautological checks.
+
+ - It's clearly not very robust to assume that Checks will not be used tautologically. So,
+ this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
+ which catches cases that AI would have already marked as unnecessary. It then also uses
+ a new helper called alreadyChecked(), which allows us to just ask if the check is
+ unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
+
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGMayExit.cpp:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGUseKind.h:
+ (JSC::DFG::alreadyChecked):
+ * dfg/DFGVarargsForwardingPhase.cpp:
+
+k
+2015-05-13 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement String.raw
+ https://bugs.webkit.org/show_bug.cgi?id=144330
+
+ Reviewed by Filip Pizlo.
+
+ Implement String.raw. It is intended to be used with tagged-templates syntax.
+ To implement ToString abstract operation efficiently,
+ we introduce @toString bytecode intrinsic. It emits op_to_string directly.
+
+ * CMakeLists.txt:
+ * builtins/StringConstructor.js: Added.
+ (raw):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
+ * runtime/CommonIdentifiers.h:
+ * runtime/StringConstructor.cpp:
+ * tests/stress/string-raw.js: Added.
+ (shouldBe):
+ (.get shouldBe):
+ (Counter):
+
+2015-05-12 Ryosuke Niwa <rniwa@webkit.org>
+
+ Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
+
+ * tests/stress/arith-mul-with-constants.js:
+
+2015-05-12 Filip Pizlo <fpizlo@apple.com>
+
+ js/dom/stack-trace.html fails with eager compilation
+ https://bugs.webkit.org/show_bug.cgi?id=144853
+
+ Reviewed by Benjamin Poulain.
+
+ All of our escape analyses were mishandling Check(). They were assuming that this is a
+ non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
+ candidate, then we need to do something: if we eliminate or sink @x, then the check no
+ longer makes any sense since a phantom allocation has no type. This will make us forget
+ that this operation would have exited. This was causing us to not call a valueOf method in
+ js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
+ +o where o had a valueOf method, and o was otherwise sinkable.
+
+ This changes our escape analyses to basically pretend that any Check() that isn't obviously
+ unnecessary is an escape. We don't have to be super careful here. Most checks will be
+ completely eliminated by constant-folding. If that doesn't run in time, then the most
+ common check we will see is CellUse. So, we just recognize some very obvious check kinds
+ that we know would have passed, and for all of the rest we just assume that it's an escape.
+
+ This was super tricky to test. The obvious way to test it is to use +o like
+ stack-trace.html, except that doing so relies on the fact that we still haven't implemented
+ the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
+
+ 1) Use +o. These will test what we want it to test for now, but at some point in the future
+ these tests will just be a good sanity-check that our op_to_number implementation is
+ right.
+
+ 2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
+ operation always sees integers even though we eventually feed it an object and that
+ object is a sink candidate.
+
+ 3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
+ value is an int32. This intrinsic is required to be implemented by DFG by
+ unconditionally speculating that the input is int32. This allows us to write much more
+ targetted tests of the underlying issue.
+
+ 4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
+ get regression test coverage of this test in eager mode.
+
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGVarargsForwardingPhase.cpp:
+ * ftl/FTLExitValue.cpp:
+ (JSC::FTL::ExitValue::dumpInContext):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+ * ftl/FTLOSRExitCompiler.cpp:
+ (JSC::FTL::compileFTLOSRExit):
+ * jsc.cpp:
+ (GlobalObject::finishCreation):
+ (functionIsInt32):
+ * runtime/Intrinsic.h:
+ * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
+ * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
+ * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
+ * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
+ * tests/stress/sink-arguments-past-invalid-check.js: Added.
+ * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
+ * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
+ * tests/stress/sink-object-past-invalid-check-int32.js: Added.
+ * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
+ * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
+ * tests/stress/sink-object-past-invalid-check.js: Added.
+
+2015-05-12 Benjamin Poulain <benjamin@webkit.org>
+
+ Fix the iteration count of arith-modulo-node-behaviors.js
+
+ * tests/stress/arith-modulo-node-behaviors.js:
+ No need for big numbers for the real testing.
+
+2015-05-12 Mark Lam <mark.lam@apple.com>
+
+ Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
+ https://bugs.webkit.org/show_bug.cgi?id=144924
+
+ Reviewed by Alex Christensen.
+
+ The present stack scanning code in the Windows port is expecting that the
+ GetCurrentThread() API will provide a unique HANDLE for each thread. The code
+ then saves and later uses that HANDLE with GetThreadContext() to get the
+ runtime state of the target thread from the GC thread. According to
+ https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
+ GetCurrentThread() does not provide this unique HANDLE that we expect:
+
+ "The function cannot be used by one thread to create a handle that can
+ be used by other threads to refer to the first thread. The handle is
+ always interpreted as referring to the thread that is using it. A
+ thread can create a "real" handle to itself that can be used by other
+ threads, or inherited by other processes, by specifying the pseudo
+ handle as the source handle in a call to the DuplicateHandle function."
+
+ As a result of this, GetCurrentThread() always returns the same HANDLE value, and
+ we end up never scanning the stacks of other threads because we wrongly think that
+ they are all equal (in identity) to the scanning thread. This, in turn, results
+ in crashes due to objects that are incorrectly collected.
+
+ The fix is to call DuplicateHandle() to create a HANDLE that we can use. The
+ MachineThreads::Thread class already accurately tracks the period of time when
+ we need that HANDLE for the VM. Hence, the life-cycle of the HANDLE can be tied
+ to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::getCurrentPlatformThread):
+ (JSC::MachineThreads::Thread::Thread):
+ (JSC::MachineThreads::Thread::~Thread):
+ (JSC::MachineThreads::Thread::suspend):
+ (JSC::MachineThreads::Thread::resume):
+ (JSC::MachineThreads::Thread::getRegisters):
+
+2015-05-12 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Make the NegZero backward propagated flags of ArithMod stricter
+ https://bugs.webkit.org/show_bug.cgi?id=144897
+
+ Reviewed by Geoffrey Garen.
+
+ The NegZero flags of ArithMod were the same as ArithDiv: both children were
+ marked as needing to handle NegativeZero.
+
+ Lucky for us, ArithMod is quite a bit different than ArithDiv.
+
+ First, the sign of the result is completely independent from
+ the sign of the divisor. A zero on the divisor always produces a NaN.
+ That's great, we can remove the NodeBytecodeNeedsNegZero
+ from the flags propagated to child2.
+
+ Second, the sign of the result is always the same as the sign of
+ the dividend. A dividend of zero produces a zero of same sign
+ unless the divisor is zero (in which case the result is NaN).
+ This is great too: we can just pass the flags we got into
+ ArithMod.
+
+ With those two out of the way, we can make a faster version of ArithRound
+ for Kraken's oscillator. Since we no longer care about negative zero,
+ rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
+ on the benchmark.
+
+ Unfortunatelly, most of the time is spent in FTL and the same optimization
+ does not apply well just yet: rdar://problem/20904149.
+
+ * dfg/DFGBackwardsPropagationPhase.cpp:
+ (JSC::DFG::BackwardsPropagationPhase::propagate):
+ Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithRound):
+ Faster Math.round() when negative zero is not important.
+
+ * tests/stress/arith-modulo-node-behaviors.js: Added.
+ (moduloWithNegativeZeroDividend):
+ (moduloWithUnusedNegativeZeroDividend):
+ (moduloWithNegativeZeroDivisor):
+
+2015-05-12 Mark Lam <mark.lam@apple.com>
+
+ Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
+ https://bugs.webkit.org/show_bug.cgi?id=144925
+
+ Reviewed by Michael Saboff.
+
+ Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
+ operate on the platformThread value in the MachineThreads::Thread struct. Instead, we
+ can apply better OO encapsulation and convert all these functions into methods of the
+ MachineThreads::Thread struct.
+
+ This will also make it easier to reason about the fix for
+ https://bugs.webkit.org/show_bug.cgi?id=144924 later.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::getCurrentPlatformThread):
+ (JSC::MachineThreads::Thread::createForCurrentThread):
+ (JSC::MachineThreads::Thread::operator!=):
+ (JSC::MachineThreads::Thread::operator==):
+ (JSC::MachineThreads::addCurrentThread):
+ (JSC::MachineThreads::removeThreadIfFound):
+ (JSC::MachineThreads::Thread::suspend):
+ (JSC::MachineThreads::Thread::resume):
+ (JSC::MachineThreads::Thread::getRegisters):
+ (JSC::MachineThreads::Thread::Registers::stackPointer):
+ (JSC::MachineThreads::Thread::freeRegisters):
+ (JSC::MachineThreads::Thread::captureStack):
+ (JSC::MachineThreads::tryCopyOtherThreadStack):
+ (JSC::MachineThreads::tryCopyOtherThreadStacks):
+ (JSC::equalThread): Deleted.
+ (JSC::suspendThread): Deleted.
+ (JSC::resumeThread): Deleted.
+ (JSC::getPlatformThreadRegisters): Deleted.
+ (JSC::otherThreadStackPointer): Deleted.
+ (JSC::freePlatformThreadRegisters): Deleted.
+ (JSC::otherThreadStack): Deleted.
+
+2015-05-12 Ryosuke Niwa <rniwa@webkit.org>
+
+ Array.slice should have a fast path like Array.splice
+ https://bugs.webkit.org/show_bug.cgi?id=144901
+
+ Reviewed by Geoffrey Garen.
+
+ Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
+ In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncSlice):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::fastSlice): Added.
+ * runtime/JSArray.h:
+
+2015-05-11 Filip Pizlo <fpizlo@apple.com>
+
+ OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
+ https://bugs.webkit.org/show_bug.cgi?id=143078
+
+ Reviewed by Andreas Kling.
+
+ In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
+ pruning is actually necessary. Well, not quite: we just need to prune out keys from the
+ heap availability map where the base node doesn't dominate the point where we are asking
+ for availability. If we don't do this, then eventually the IR gets corrupt because we'll
+ insert PutHints that reference the base node in places where the base node doesn't
+ dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
+ liveness. This is the strongest possible pruning we can do, and it should be sound. We
+ shouldn't have a node available for a virtual register if that register is live and the
+ node doesn't dominate.
+
+ Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
+ abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
+
+ * dfg/DFGAvailabilityMap.cpp:
+ (JSC::DFG::AvailabilityMap::pruneHeap):
+ (JSC::DFG::AvailabilityMap::pruneByLiveness):
+ (JSC::DFG::AvailabilityMap::prune): Deleted.
+ * dfg/DFGAvailabilityMap.h:
+ * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+ (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+ * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
+ * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
+
+2015-05-12 Gabor Loki <loki@webkit.org>
+
+ Workaround for Cortex-A53 erratum 843419
+ https://bugs.webkit.org/show_bug.cgi?id=144680
+
+ Reviewed by Michael Saboff.
+
+ This patch is about to give simple workaround for Cortex-A53 erratum 843419.
+ It inserts nops after ADRP instruction to avoid wrong address accesses.
+
+ * assembler/ARM64Assembler.h:
+ (JSC::ARM64Assembler::adrp):
+ (JSC::ARM64Assembler::nopCortexA53Fix843419):
+
+2015-05-11 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r184009.
+ https://bugs.webkit.org/show_bug.cgi?id=144900
+
+ Caused crashes on inspector tests (Requested by ap on
+ #webkit).
+
+ Reverted changeset:
+
+ "MapDataImpl::add() shouldn't do the same hash lookup twice."
+ https://bugs.webkit.org/show_bug.cgi?id=144759
+ http://trac.webkit.org/changeset/184009
+
+2015-05-11 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r184123.
+ https://bugs.webkit.org/show_bug.cgi?id=144899
+
+ Seems to have introduced flaky crashes in many JS tests
+ (Requested by rniwa on #webkit).
+
+ Reverted changeset:
+
+ "REGRESSION(r180595): same-callee profiling no longer works"
+ https://bugs.webkit.org/show_bug.cgi?id=144787
+ http://trac.webkit.org/changeset/184123
+
+2015-05-11 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Move Windows build target to Windows 7 (or newer)
+ https://bugs.webkit.org/show_bug.cgi?id=144890
+ <rdar://problem/20707307>
+
+ Reviewed by Anders Carlsson.
+
+ Update linked SDK and minimal Windows level to be compatible with
+ Windows 7 or newer.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * 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/jsc/jscLauncher.vcxproj:
+ * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
+ * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
+ * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
+ * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
+ * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
+ * config.h:
+
+2015-05-08 Filip Pizlo <fpizlo@apple.com>
+
+ CPS rethreading phase's flush detector flushes way too many SetLocals
+ https://bugs.webkit.org/show_bug.cgi?id=144819
+
+ Reviewed by Geoffrey Garen.
+
+ After probably unrelated changes, this eventually caused some arguments elimination to stop
+ working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
+ a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
+ meant to only affect the SetLocal itself.
+
+ This is a speed-up on Octane/earley.
+
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
+
+2015-05-11 Filip Pizlo <fpizlo@apple.com>
+
+ gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
+ https://bugs.webkit.org/show_bug.cgi?id=144854
+
+ Reviewed by Oliver Hunt.
+
+ This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
+ It used to be that Construct required less code, but that's not the case for now.
+
+ * ftl/FTLInlineCacheSize.cpp:
+ (JSC::FTL::sizeOfCallForwardVarargs):
+ (JSC::FTL::sizeOfConstructVarargs):
+ (JSC::FTL::sizeOfConstructForwardVarargs):
+
+2015-05-11 Ryosuke Niwa <rniwa@webkit.org>
+
+ REGRESSION(r180595): same-callee profiling no longer works
+ https://bugs.webkit.org/show_bug.cgi?id=144787
+
+ Reviewed by Michael Saboff.
+
+ This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
+ always the same JSFunction. This condition doesn't hold when the byte code creates multiple
+ JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
+
+ To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
+ added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
+ our speculation that the callee is the same. To avoid recompiling the same code for different callee
+ objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
+ LLint and baseline JIT when multiple callees are observed.
+
+ Tests: stress/create-this-with-callee-variants.js
+
+ * bytecode/BytecodeList.json: Increased the number of operands to 5.
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
+ operands.
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
+ (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
+ we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
+ operand.
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
+ match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
+ as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
+ (JSC::JIT::emitSlow_op_create_this):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_this): Ditto.
+ (JSC::JIT::emitSlow_op_create_this):
+ * llint/LowLevelInterpreter32_64.asm:
+ (_llint_op_create_this): Ditto.
+ * llint/LowLevelInterpreter64.asm:
+ (_llint_op_create_this): Ditto.
+ * runtime/CommonSlowPaths.cpp:
+ (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
+ been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
+ * runtime/JSCell.h:
+ (JSC::JSCell::seenMultipleCalleeObjects): Added.
+ * runtime/WriteBarrier.h:
+ (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
+ * tests/stress/create-this-with-callee-variants.js: Added.
+
+2015-05-11 Andreas Kling <akling@apple.com>
+
+ PropertyNameArray should use a Vector when there are few entries.
+ <https://webkit.org/b/144874>
+
+ Reviewed by Geoffrey Garen.
+
+ Bring back an optimization that was lost in the for-in refactoring.
+ PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
+ enough (20) entries to justify converting to a HashSet for contains().
+
+ Also inlined the code while we're here, since it has so few clients and
+ the call overhead adds up.
+
+ ~5% progression on Kraken/json-stringify-tinderbox.
+
+ * runtime/PropertyNameArray.cpp: Removed.
+ * runtime/PropertyNameArray.h:
+ (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
+ (JSC::PropertyNameArray::add):
+ (JSC::PropertyNameArray::addKnownUnique):
+
+2015-05-11 Matt Baker <mattbaker@apple.com>
+
+ Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
+ https://bugs.webkit.org/show_bug.cgi?id=144808
+
+ Reviewed by Darin Adler.
+
+ Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
+ The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
+
+ * profiler/Profile.cpp:
+ (JSC::Profile::create):
+ (JSC::Profile::Profile):
+ * profiler/Profile.h:
+ * profiler/ProfileGenerator.cpp:
+ (JSC::ProfileGenerator::ProfileGenerator):
+ (JSC::AddParentForConsoleStartFunctor::operator()):
+
+2015-05-11 Basile Clement <basile_clement@apple.com>
+
+ Unreviewed, remove unintended change.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2015-05-11 Filip Pizlo <fpizlo@apple.com>
+
+ Make it easy to enable eager/non-concurrent JIT compilation
+ https://bugs.webkit.org/show_bug.cgi?id=144877
+
+ Reviewed by Michael Saboff.
+
+ * runtime/Options.cpp:
+ (JSC::recomputeDependentOptions):
+ * runtime/Options.h:
+
+2015-05-10 Filip Pizlo <fpizlo@apple.com>
+
+ We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
+ https://bugs.webkit.org/show_bug.cgi?id=144851
+
+ Reviewed by Michael Saboff.
+
+ LoadVarargs loads arguments from some object and puts them on the stack. The region of
+ stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
+ shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
+ something that uses more stack than the LoadVarargs wanted to.
+
+ This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
+ promoter. This is an important promotion rule for performance, and in cases where we are
+ compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
+ the phantom arguments array that this phase sees. The LoadVarargs limit is based on
+ profiling and the phantom arguments array is a proof; in most cases the profiling is more
+ conservative.
+
+ But, you could write some crazy code where the statically obvious arguments array value is
+ bigger than what the profiling would have told you. When this happens, this promotion
+ effectively removes a bounds check. This either results in us clobbering a bunch of stack,
+ or it means that we never initialize a region of the stack that a later operation will read
+ (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
+ unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
+ the original LoadVarargs limit).
+
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
+ (foo):
+ (bar):
+ (baz):
+ * tests/stress/load-varargs-elimination-bounds-check.js: Added.
+ (foo):
+ (bar):
+ (baz):
+
+2015-05-11 Andreas Kling <akling@apple.com>
+
+ JSON.stringify shouldn't use generic get() to access Array.length
+ <https://webkit.org/b/144847>
+
+ Reviewed by Geoffrey Garen.
+
+ If the value being serialized is a JSArray object, we can downcast and call its
+ length() directly instead of doing a generic property lookup.
+
+ 0.5% progression on Kraken/json-stringify-tinderbox.
+
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::Holder::appendNextProperty):
+
+2015-05-10 Andreas Kling <akling@apple.com>
+
+ Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
+
+ Follow up to r184050 suggested by Darin.
+
+ * runtime/PropertyNameArray.h:
+
+2015-05-10 Andreas Kling <akling@apple.com>
+
+ Remove unused things from PropertyNameArray.
+ <https://webkit.org/b/144834>
+
+ Reviewed by Filip Pizlo.
+
+ PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
+ was refactored and optimized last year. Then more refactoring happened and this class
+ doesn't need to ring and toot anymore.
+
+ The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
+ actually using it for anything and we were just wasting time creating these.
+
+ Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::getPropertyNames):
+ * runtime/JSPropertyNameEnumerator.cpp:
+ (JSC::JSPropertyNameEnumerator::create):
+ (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
+ * runtime/JSPropertyNameEnumerator.h:
+ * runtime/PropertyNameArray.cpp:
+ (JSC::PropertyNameArray::add):
+ (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
+ * runtime/PropertyNameArray.h:
+ (JSC::PropertyNameArray::PropertyNameArray):
+ (JSC::PropertyNameArray::add):
+ (JSC::PropertyNameArray::addKnownUnique):
+ (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
+ (JSC::RefCountedIdentifierSet::contains): Deleted.
+ (JSC::RefCountedIdentifierSet::size): Deleted.
+ (JSC::RefCountedIdentifierSet::add): Deleted.
+ (JSC::PropertyNameArray::identifierSet): Deleted.
+ (JSC::PropertyNameArray::numCacheableSlots): Deleted.
+ (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
+ (JSC::PropertyNameArray::setBaseObject): Deleted.
+ (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
+
+2015-05-09 Yoav Weiss <yoav@yoav.ws>
+
+ Remove the PICTURE_SIZES build flag
+ https://bugs.webkit.org/show_bug.cgi?id=144679
+
+ Reviewed by Benjamin Poulain.
+
+ Removed the PICTURE_SIZES build time flag.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-05-08 Filip Pizlo <fpizlo@apple.com>
+
+ Extend the SaneChain optimization to Contiguous arrays
+ https://bugs.webkit.org/show_bug.cgi?id=144664
+
+ Reviewed by Mark Lam.
+
+ Previously if you loaded from a hole, you'd either have to take slow path for the array
+ load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
+ gathered the necessary profiling yet). But that's unnecessary if we know that the
+ prototype chain is sane - i.e. has no indexed properties. Then we can just return
+ Undefined for the hole.
+
+ Making this change requires setting more watchpoints on the array prototype chain. But
+ that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
+ itself up lazily. This means that this increased the number of recompilations we'd get
+ due to the array prototype chain being built up.
+
+ So, this change also removes the laziness and static tables from ArrayPrototype.
+
+ But to make that change, I also had to add a helper for eagerly building up a prototype
+ that has builtin functions.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * dfg/DFGArrayMode.h:
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
+ * runtime/ArrayPrototype.h:
+ * runtime/JSObject.h:
+
+2015-05-08 Michael Saboff <msaboff@apple.com>
+
+ Creating a large MarkedBlock sometimes results in more than one cell in the block
+ https://bugs.webkit.org/show_bug.cgi?id=144815
+
+ Reviewed by Mark Lam.
+
+ Large MarkedBlocks should have one and only one cell. Changed the calculation of
+ m_endAtom for large blocks to use the location of the first cell + 1. This
+ assures that large blocks only have one cell.
+
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::MarkedBlock):
+
+2015-05-08 Oliver Hunt <oliver@apple.com>
+
+ MapDataImpl::add() shouldn't do the same hash lookup twice.
+ https://bugs.webkit.org/show_bug.cgi?id=144759
+
+ Reviewed by Gavin Barraclough.
+
+ We don't actually need to do a double lookup here, all we need to
+ do is update the index to point to the correct m_size.
+
+ * runtime/MapDataInlines.h:
+ (JSC::JSIterator>::add):
+
+2015-05-08 Andreas Kling <akling@apple.com>
+
+ Micro-optimize JSON serialization of string primitives.
+ <https://webkit.org/b/144800>
+
+ Reviewed by Sam Weinig.
+
+ Don't use the out-of-line JSValue::getString() to grab at string primitives
+ in serialization. Just check if it's a JSString and then downcast to grab at
+ the WTF::String inside.
+
+ 2% progression on Kraken/json-stringify-tinderbox.
+
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::appendStringifiedValue):
+
+2015-05-08 Andreas Kling <akling@apple.com>
+
+ Optimize serialization of quoted JSON strings.
+ <https://webkit.org/b/144754>
+
+ Reviewed by Darin Adler.
+
+ Optimized the serialization of quoted strings into JSON by moving the logic into
+ StringBuilder so it can make smarter decisions about buffering.
+
+ 12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
+
+ * runtime/JSONObject.h:
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::Holder::appendNextProperty):
+ (JSC::appendStringToStringBuilder): Deleted.
+ (JSC::appendQuotedJSONStringToBuilder): Deleted.
+ (JSC::Stringifier::appendQuotedString): Deleted.
+ (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
+ to StringBuilder and call that from here.
+
+2015-05-07 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r183961.
+ https://bugs.webkit.org/show_bug.cgi?id=144784
+
+ Broke js/dom/JSON-stringify.html (Requested by kling on
+ #webkit).
+
+ Reverted changeset:
+
+ "Optimize serialization of quoted JSON strings."
+ https://bugs.webkit.org/show_bug.cgi?id=144754
+ http://trac.webkit.org/changeset/183961
+
+2015-05-07 Filip Pizlo <fpizlo@apple.com>
+
+ GC has trouble with pathologically large array allocations
+ https://bugs.webkit.org/show_bug.cgi?id=144609
+
+ Reviewed by Geoffrey Garen.
+
+ The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
+ after pinning them), and would skip the accounting. The GC calculates the size of the heap
+ in tandem with the scan to save time, and that accounting was part of how the GC would
+ know how big the heap was. The GC would then think that oversize copied blocks use no
+ memory, and would then mess up its scheduling of the next GC.
+
+ Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
+ size by summing the size from the last collection and the size by walking the eden heap.
+ But this breaks when we eagerly delete objects that the last collection touched. We can do
+ that in one corner case: copied block reallocation. The old block will be deleted from old
+ space during the realloc and a new block will be allocated in new space. In order for the
+ GC to know that the size of old space actually shrank, we need a field to tell us how much
+ such shrinkage could occur. Since this is a very dirty corner case and it only works for
+ very particular reasons arising from the special properties of copied space (single owner,
+ and the realloc is used in places where the compiler already knows that it cannot register
+ allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
+ devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
+
+ To test this, I needed to add an Option to force a particular RAM size in the GC. This
+ allows us to write tests that assert that the GC heap size is some value X, without
+ worrying about machine-to-machine variations due to GC heuristics changing based on RAM
+ size.
+
+ * heap/CopiedSpace.cpp:
+ (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
+ (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
+ * heap/CopiedSpace.h:
+ (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap): Allow the user to force the RAM size.
+ (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
+ * heap/SlotVisitorInlines.h:
+ (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
+ * jsc.cpp: Add size measuring hooks to write the largeish test.
+ (GlobalObject::finishCreation):
+ (functionGCAndSweep):
+ (functionFullGC):
+ (functionEdenGC):
+ (functionHeapSize):
+ * runtime/Options.h:
+ * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
+ * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
+ (foo):
+ (test):
+
+2015-05-07 Saam Barati <saambarati1@gmail.com>
+
+ Global functions should be initialized as JSFunctions in byte code
+ https://bugs.webkit.org/show_bug.cgi?id=144178
+
+ Reviewed by Geoffrey Garen.
+
+ This patch makes the initialization of global functions more explicit by
+ moving initialization into bytecode. It also prepares JSC for having ES6
+ style lexical scoping because initializing global functions in bytecode
+ easily allows global functions to be initialized with the proper scope that
+ will have access to global lexical variables. Global lexical variables
+ should be visible to global functions but don't live on the global object.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedProgramCodeBlock::visitChildren):
+ * bytecode/UnlinkedCodeBlock.h:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * bytecompiler/BytecodeGenerator.h:
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::initializeGlobalProperties):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::addGlobalVar):
+ (JSC::JSGlobalObject::addFunction):
+ * runtime/JSGlobalObject.h:
+
+2015-05-07 Benjamin Poulain <bpoulain@apple.com>
+
+ Fix the x86 32bits build
+
+ * assembler/X86Assembler.h:
+
+2015-05-07 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Add basic DFG/FTL support for Math.round
+ https://bugs.webkit.org/show_bug.cgi?id=144725
+
+ Reviewed by Filip Pizlo.
+
+ This patch adds two optimizations targeting Math.round():
+ -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
+ -Change the MacroAssembler to be stricter on how we fail to convert a double
+ to ingeter. Previously, any number valued zero would fail, now we only
+ fail for -0.
+
+ Since ArithRound speculate it produces int32, the MacroAssembler assembler
+ part became necessary because zero is a pretty common output of Math.round()
+ and we would OSR exit a lot (and eventually recompile for doubles).
+
+ The implementation itself of the inline Math.round() is exactly the same
+ as the C function that exists for Math.round(). We can very likely do better
+ but it is a good start known to be valid and inlining alone alread provides
+ significant speedups.
+
+ * assembler/X86Assembler.h:
+ (JSC::X86Assembler::movmskpd_rr):
+ * assembler/MacroAssemblerX86Common.h:
+ (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
+ When we have a zero, get the sign bit out of the double and check if is one.
+
+ I'll look into doing the same improvement for ARM.
+
+ * bytecode/SpeculatedType.cpp:
+ (JSC::typeOfDoubleRounding):
+ (JSC::typeOfDoubleFRound): Deleted.
+ * bytecode/SpeculatedType.h:
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::roundShouldSpeculateInt32):
+ (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::arithNodeFlags):
+ (JSC::DFG::Node::hasHeapPrediction):
+ (JSC::DFG::Node::hasArithMode):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithRound):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
+ (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
+ (JSC::FTL::LowerDFGToLLVM::compileArithRound):
+ * ftl/FTLOutput.h:
+ (JSC::FTL::Output::ceil64):
+ * jit/ThunkGenerators.cpp:
+ * runtime/MathCommon.cpp:
+ * runtime/MathCommon.h:
+ * runtime/MathObject.cpp:
+ (JSC::mathProtoFuncRound):
+ * tests/stress/math-round-basics.js: Added.
+ (mathRoundOnIntegers):
+ (mathRoundOnDoubles):
+ (mathRoundOnBooleans):
+ (uselessMathRound):
+ (mathRoundWithOverflow):
+ (mathRoundConsumedAsDouble):
+ (mathRoundDoesNotCareAboutMinusZero):
+ (mathRoundNoArguments):
+ (mathRoundTooManyArguments):
+ (testMathRoundOnConstants):
+ (mathRoundStructTransition):
+ (Math.round):
+
+2015-05-07 Saam Barati <saambarati1@gmail.com>
+
+ exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=144753
+
+ Reviewed by Mark Lam.
+
+ This allows the BytecodeGenerator to freely emit startup code that "may"
+ throw exceptions without worrying that this startup code will trigger
+ the exceptionFuzz exception. The exceptionFuzz counter will only begin
+ ticking when the 'enableExceptionFuzz' function is explicitly called in
+ the exceptionFuzz tests.
+
+ * jsc.cpp:
+ (GlobalObject::finishCreation):
+ (functionEnableExceptionFuzz):
+ * tests/exceptionFuzz/3d-cube.js:
+ * tests/exceptionFuzz/date-format-xparb.js:
+ * tests/exceptionFuzz/earley-boyer.js:
+
+2015-05-07 Andreas Kling <akling@apple.com>
+
+ Optimize serialization of quoted JSON strings.
+ <https://webkit.org/b/144754>
+
+ Reviewed by Darin Adler.
+
+ Optimized the serialization of quoted strings into JSON by moving the logic into
+ StringBuilder so it can make smarter decisions about buffering.
+
+ 12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
+
+ * runtime/JSONObject.h:
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::Holder::appendNextProperty):
+ (JSC::appendStringToStringBuilder): Deleted.
+ (JSC::appendQuotedJSONStringToBuilder): Deleted.
+ (JSC::Stringifier::appendQuotedString): Deleted.
+ (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
+ to StringBuilder and call that from here.
+
+2015-05-07 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
+ https://bugs.webkit.org/show_bug.cgi?id=144678
+
+ Reviewed by Geoffrey Garen.
+
+ Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
+ But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
+
+ function t() { var ok = {null: function () { } }; ok[ok = null](); }
+ t(); // Should not throw error.
+
+ This patch takes care about `subscriptHasAssignment`.
+ By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
+ it correctly moves the LHS value to a temporary register.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::FunctionCallBracketNode::emitBytecode):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::makeFunctionCallNode):
+ * parser/NodeConstructors.h:
+ (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
+ * parser/Nodes.h:
+ * tests/stress/assignment-in-function-call-bracket-node.js: Added.
+ (shouldBe):
+ (shouldBe.):
+
+2015-05-07 Basile Clement <basile_clement@apple.com>
+
+ Unreviewed, add missing braces on a single-line if that got expanded in r183939
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+
+2015-05-05 Myles C. Maxfield <mmaxfield@apple.com>
+
+ Revert "Introducing the Platform Abstraction Layer (PAL)"
+ https://bugs.webkit.org/show_bug.cgi?id=144751
+
+ Unreviewed.
+
+ PAL should be a new target inside WebCore, rather than a top-level folder.
+
+ * Configurations/FeatureDefines.xcconfig: Updated
+
+2015-05-07 Basile Clement <basile_clement@apple.com>
+
+ Dumping OSR ExitValue should expand materializations only once
+ https://bugs.webkit.org/show_bug.cgi?id=144694
+
+ Reviewed by Filip Pizlo.
+
+ Currently, dumping OSR exit values will print the full materialization
+ information each time it is encountered. We change it to print only a
+ brief description (only the materialization's address), and print the
+ whole set of materializations later on.
+
+ This makes the dump less confusing (less likely to think that two
+ instances of the same materialization are different), and will be a
+ necessary change if/when we support materialization cycles.
+
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLExitValue.cpp:
+ (JSC::FTL::ExitValue::dumpInContext):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+
+2015-05-07 Andreas Kling <akling@apple.com>
+
+ Worker threads leak WeakBlocks (as seen on leaks bot)
+ <https://webkit.org/b/144721>
+ <rdar://problem/20848288>
+
+ Reviewed by Darin Adler.
+
+ Nuke any remaining empty WeakBlocks when the Heap is being torn down.
+ Trying to peek into these blocks after the VM is dead would be a bug anyway.
+
+ This fixes a ~750 KB leak seen on the leaks bot.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::~Heap):
+
+2015-05-05 Geoffrey Garen <ggaren@apple.com>
+
+ Don't branch when accessing the callee
+ https://bugs.webkit.org/show_bug.cgi?id=144645
+
+ Reviewed by Michael Saboff.
+
+ The branch was added in <http://trac.webkit.org/changeset/81040> without
+ explanation.
+
+ kling found it to be a performance problem. See <https://webkit.org/b/144586>.
+
+ Our theory of access to Registers is that it's up to the client to access
+ them in the right way. So, let's do that.
+
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::callee):
+ (JSC::ExecState::setCallee): Call the field object instead of function
+ because nothing guarantees that it's a function.
+ * interpreter/ProtoCallFrame.h:
+ (JSC::ProtoCallFrame::callee):
+ (JSC::ProtoCallFrame::setCallee):
+ * interpreter/Register.h:
+ * runtime/JSObject.h:
+ (JSC::Register::object): Just do a cast like our other accessors do.
+ (JSC::Register::operator=):
+ (JSC::Register::function): Deleted.
+ (JSC::Register::withCallee): Deleted.
+
+2015-05-07 Dan Bernstein <mitz@apple.com>
+
+ <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
+ https://bugs.webkit.org/show_bug.cgi?id=144727
+
+ Reviewed by Darin Adler.
+
+ * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
+ INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
+
+2015-05-07 Andreas Kling <akling@apple.com>
+
+ Special-case Int32 values in JSON.stringify().
+ <https://webkit.org/b/144731>
+
+ Reviewed by Michael Saboff.
+
+ Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
+ simple integers through the full-blown dtoa() machinery.
+
+ ~50% speedup on Kraken/json-stringify-tinderbox.
+
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::appendStringifiedValue):
+
+2015-05-06 Ryosuke Niwa <rniwa@webkit.org>
+
+ ToT WebKit crashes while loading ES6 compatibility table
+ https://bugs.webkit.org/show_bug.cgi?id=144726
+
+ Reviewed by Filip Pizlo.
+
+ The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
+
+ Always build the identifier here as it could be a method name.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+
+2015-05-05 Filip Pizlo <fpizlo@apple.com>
+
+ Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
+ https://bugs.webkit.org/show_bug.cgi?id=144665
+
+ Reviewed by Michael Saboff.
+
+ This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
+ extending SaneChain to all indexing shapes.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
+ (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
+ * dfg/DFGWatchpointCollectionPhase.cpp:
+ (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
+ (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
+
+2015-04-02 Myles C. Maxfield <mmaxfield@apple.com>
+
+ Introducing the Platform Abstraction Layer (PAL)
+ https://bugs.webkit.org/show_bug.cgi?id=143358
+
+ Reviewed by Simon Fraser.
+
+ * Configurations/FeatureDefines.xcconfig: Updated
+
+2015-05-06 Andreas Kling <akling@apple.com>
+
+ Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
+ <https://webkit.org/b/144676>
+
+ Reviewed by Darin Adler.
+
+ We were creating a new String for every number JSValue passing through the JSON stringifier.
+ These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
+ Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
+ for the conversion instead.
+
+ 13% progression on Kraken/json-stringify-tinderbox.
+
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::appendStringifiedValue):
+
+2015-05-06 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r183847.
+ https://bugs.webkit.org/show_bug.cgi?id=144691
+
+ Caused many assertion failures (Requested by ap on #webkit).
+
+ Reverted changeset:
+
+ "GC has trouble with pathologically large array allocations"
+ https://bugs.webkit.org/show_bug.cgi?id=144609
+ http://trac.webkit.org/changeset/183847
+
+2015-05-05 Filip Pizlo <fpizlo@apple.com>
+
+ PutGlobalVar shouldn't have an unconditional store barrier
+ https://bugs.webkit.org/show_bug.cgi?id=133104
+
+ Reviewed by Benjamin Poulain.
+
+ We don't need a store barrier on PutGlobalVar if the value being stored can be
+ speculated to not be a cell.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+
+2015-05-05 Filip Pizlo <fpizlo@apple.com>
+
+ CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
+ https://bugs.webkit.org/show_bug.cgi?id=144667
+
+ Reviewed by Andreas Kling.
+
+ We are now calling this method for oversize blocks. It had an assertion that indirectly
+ implied that the block is not oversize, because it was claiming that the number of live
+ bytes should be smaller than the non-oversize-block size.
+
+ * heap/CopiedBlockInlines.h:
+ (JSC::CopiedBlock::reportLiveBytes):
+
+2015-05-05 Filip Pizlo <fpizlo@apple.com>
+
+ GC has trouble with pathologically large array allocations
+ https://bugs.webkit.org/show_bug.cgi?id=144609
+
+ Reviewed by Mark Lam.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::updateObjectCounts): Make this code less confusing.
+ * heap/SlotVisitorInlines.h:
+ (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
+ * jsc.cpp: Add size measuring hooks to write the largeish test.
+ (GlobalObject::finishCreation):
+ (functionGCAndSweep):
+ (functionFullGC):
+ (functionEdenGC):
+ (functionHeapSize):
+ * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
+ * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
+ (foo):
+ (test):
+
+2015-05-05 Filip Pizlo <fpizlo@apple.com>
+
+ FTL SwitchString slow case creates duplicate switch cases
+ https://bugs.webkit.org/show_bug.cgi?id=144634
+
+ Reviewed by Geoffrey Garen.
+
+ The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
+ added mostly-debug-only asserts to catch such issues earlier.
+
+ * bytecode/CallVariant.cpp:
+ (JSC::variantListWithVariant): Assertion to prevent similar bugs.
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
+ (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
+ * jit/BinarySwitch.cpp:
+ (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
+ * jit/Repatch.cpp:
+ (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
+ * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
+ (foo):
+ (cat):
+
+2015-05-05 Basile Clement <basile_clement@apple.com>
+
+ Fix debug builds after r183812
+ https://bugs.webkit.org/show_bug.cgi?id=144300
+
+ Rubber stamped by Andreas Kling and Filip Pizlo.
+
+ hasObjectMaterializationData() didn't treat MaterializeCreateActivation
+ as having materialization data, which was causing an assertion failure when
+ sinking CreateActivations on debug builds.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasObjectMaterializationData):
+
+2015-05-04 Basile Clement <basile_clement@apple.com>
+
+ Allow CreateActivation sinking
+ https://bugs.webkit.org/show_bug.cgi?id=144300
+
+ Reviewed by Filip Pizlo.
+
+ This pursues the work started in
+ https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
+ allocations we are able to sink by allowing sinking of CreateActivation
+ node.
+
+ This is achieved by following closely the way NewObject is currently
+ sunk: we add a new PhantomCreateActivation node to record the initial
+ position of the CreateActivation node, new ClosureVarPLoc promoted heap
+ locations to keep track of the variables put in the activation, and a
+ new MaterializeCreateActivation node to allocate and populate the sunk
+ activation.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::convertToPutClosureVarHint):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToPhantomCreateActivation):
+ (JSC::DFG::Node::isActivationAllocation):
+ (JSC::DFG::Node::isPhantomActivationAllocation):
+ (JSC::DFG::Node::isPhantomAllocation):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
+ (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGPromotedHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGPromotedHeapLocation.h:
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateCPS):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+ * tests/stress/activation-sink-osrexit.js: Added.
+ (bar):
+ (foo.set result):
+ * tests/stress/activation-sink.js: Added.
+ (bar):
+
+2015-05-04 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix stale comment.
+
+ * tests/mozilla/js1_5/Array/regress-101964.js:
+
+2015-05-04 Filip Pizlo <fpizlo@apple.com>
+
+ Large array shouldn't be slow
+ https://bugs.webkit.org/show_bug.cgi?id=144617
+
+ Rubber stamped by Mark Lam.
+
+ * tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.
+
+2015-05-04 Filip Pizlo <fpizlo@apple.com>
+
+ Large array shouldn't be slow
+ https://bugs.webkit.org/show_bug.cgi?id=144617
+
+ Rubber stamped by Mark Lam.
+
+ * tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.
+
+2015-05-04 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r183789.
+ https://bugs.webkit.org/show_bug.cgi?id=144620
+
+ Causing flakiness on exceptionFuzz tests locally on 32-bit
+ build (Requested by saamyjoon on #webkit).
+
+ Reverted changeset:
+
+ "Global functions should be initialized as JSFunctions in byte
+ code"
+ https://bugs.webkit.org/show_bug.cgi?id=144178
+ http://trac.webkit.org/changeset/183789
+
+2015-05-04 Saam Barati <saambarati1@gmail.com>
+
+ Global functions should be initialized as JSFunctions in byte code
+ https://bugs.webkit.org/show_bug.cgi?id=144178
+
+ Reviewed by Geoffrey Garen.
+
+ This patch makes the initialization of global functions more explicit by
+ moving initialization into bytecode. It also prepares JSC for having ES6
+ style lexical scoping because initializing global functions in bytecode
+ easily allows global functions to be initialized with the proper scope that
+ will have access to global lexical variables. Global lexical variables
+ should be visible to global functions but don't live on the global object.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedProgramCodeBlock::visitChildren):
+ * bytecode/UnlinkedCodeBlock.h:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * bytecompiler/BytecodeGenerator.h:
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::initializeGlobalProperties):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::addGlobalVar):
+ (JSC::JSGlobalObject::addFunction):
+ * runtime/JSGlobalObject.h:
+
+2015-05-04 Filip Pizlo <fpizlo@apple.com>
+
+ Large array shouldn't be slow
+ https://bugs.webkit.org/show_bug.cgi?id=144617
+
+ Reviewed by Geoffrey Garen.
+
+ Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
+ you're already using ArrayStorage mode, from the minimul array length required to use
+ ArrayStorage in a new Array(length) allocation.
+
+ Lift the array allocation length threshold to something very high. If this works, we'll
+ probably remove that threshold entirely.
+
+ This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
+ JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
+ for now.
+
+ * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
+ * runtime/ArrayConventions.h:
+ * runtime/JSArray.h:
+ (JSC::JSArray::create):
+ * runtime/JSGlobalObject.h:
+ (JSC::constructEmptyArray):
+ * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
+
+2015-05-03 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Add backed intrinsics to private functions exposed with private symbols in global object
+ https://bugs.webkit.org/show_bug.cgi?id=144545
+
+ Reviewed by Darin Adler.
+
+ Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
+ This patch adds intrinsic to private functions exposed with private symbols in global object,
+ @floor and @abs.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::globalPrivateFuncAbs): Deleted.
+ (JSC::globalPrivateFuncFloor): Deleted.
+ * runtime/MathObject.cpp:
+ * runtime/MathObject.h:
+ * tests/stress/array-from-abs-and-floor.js: Added.
+ (target1):
+ (target2):
+ (target3):
+
+2015-05-04 Csaba Osztrogonác <ossy@webkit.org>
+
+ [cmake] ARM related build system cleanup
+ https://bugs.webkit.org/show_bug.cgi?id=144566
+
+ Reviewed by Darin Adler.
+
+ * CMakeLists.txt:
+
+2015-05-04 Andreas Kling <akling@apple.com>
+
+ Optimize WeakBlock's "reap" and "visit" operations.
+ <https://webkit.org/b/144585>
+
+ Reviewed by Geoffrey Garen.
+
+ WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
+ That function was really written with conservative roots marking in mind, and will do a bunch
+ of sanity and bounds checks.
+
+ For weaks, we know that the pointer will have been a valid cell pointer into a block
+ of appropriate cell size, so we can skip a lot of the checks.
+
+ We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
+ MarkedBlock::blockFor() for every single cell when iterating.
+
+ Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
+ WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
+ be pointing to any live cells, and the only operation that will run on the block is sweep().
+
+ Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
+ In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
+ This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
+
+ This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
+ what looks like a 1% speedup locally.
+
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
+
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
+ block's state is known to be either Marked or Retired.
+
+ (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
+ would report that all cells are live anyway.
+
+ * heap/WeakBlock.cpp:
+ (JSC::WeakBlock::create):
+ (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
+
+ (JSC::WeakBlock::visit):
+ (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
+
+ * heap/WeakBlock.h:
+ (JSC::WeakBlock::disconnectMarkedBlock): Added.
+ * heap/WeakSet.cpp:
+ (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
+ ownership to Heap until it can die peacefully.
+
+ (JSC::WeakSet::addAllocator):
+ * heap/WeakSet.h:
+ (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
+
+2015-05-04 Basile Clement <basile_clement@apple.com>
+
+ Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
+ https://bugs.webkit.org/show_bug.cgi?id=144587
+
+ Rubber stamped by Filip Pizlo.
+
+ When sinking object allocations, we ensure in
+ determineMaterializationPoints that whenever an allocation is
+ materialized on a path to a block, it is materialized in all such
+ paths. Thus when running the SSA calculator to place Phis in
+ placeMaterializationPoints, we can't encounter a situation where some
+ Upsilons are referring to a materialization while others are referring
+ to the phantom object.
+
+ This replaces the code that was adding a materialization late in
+ placeMaterializationPoints to handle that case by an assertion that it
+ does not happen, which will make
+ https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
+
+2015-05-04 Ryosuke Niwa <rniwa@webkit.org>
+
+ Extending undefined in class syntax should throw a TypeError
+ https://bugs.webkit.org/show_bug.cgi?id=144284
+
+ Reviewed by Darin Adler.
+
+ The bug was caused by op_eq_null evaluating to true when compared to undefined.
+ Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
+
+ We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ClassExprNode::emitBytecode):
+
+2015-05-04 Ryosuke Niwa <rniwa@webkit.org>
+
+ new super should be a syntax error
+ https://bugs.webkit.org/show_bug.cgi?id=144282
+
+ Reviewed by Joseph Pecoraro.
+
+ Disallow "new super" as ES6 spec doesn't allow this.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseMemberExpression):
+
+2015-05-04 Saam Barati <saambarati1@gmail.com>
+
+ JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
+ https://bugs.webkit.org/show_bug.cgi?id=144265
+
+ Reviewed by Geoffrey Garen.
+
+ JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
+ for a static function if the parent has that property slot. JSCallbackObject::put
+ did not maintain this symmetry of also calling ::put on the parent if the parent
+ has the property. We should ensure that this symmetry exists.
+
+ * API/JSCallbackObjectFunctions.h:
+ (JSC::JSCallbackObject<Parent>::put):
+ * API/tests/testapi.c:
+ * API/tests/testapi.js:
+ (globalStaticFunction2):
+ (this.globalStaticFunction2):
+ (iAmNotAStaticFunction):
+ (this.iAmNotAStaticFunction):
+
+2015-05-04 Andreas Kling <akling@apple.com>
+
+ Make ExecState::vm() branchless in release builds.
+ <https://webkit.org/b/144586>
+
+ Reviewed by Geoffrey Garen.
+
+ Avoid null checking the ExecState's callee() before getting the
+ VM from it. The code was already dereferencing it anyway, since we
+ know it's not gonna be null.
+
+ * runtime/JSCellInlines.h:
+ (JSC::ExecState::vm):
+
+2015-05-04 Basile Clement <basile_clement@apple.com>
+
+ Object allocation not sinking properly through CheckStructure
+ https://bugs.webkit.org/show_bug.cgi?id=144465
+
+ Reviewed by Filip Pizlo.
+
+ Currently, sinking an allocation through a CheckStructure will
+ completely ignore all structure checking, which is obviously wrong.
+
+ A CheckStructureImmediate node type was present for that purpose, but
+ the CheckStructures were not properly replaced. This ensures that
+ CheckStructure nodes are replaced by CheckStructureImmediate nodes when
+ sunk through, and that structure checking happens correctly.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
+ (JSC::DFG::Node::hasStructureSet):
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
+ (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
+ (JSC::FTL::LowerDFGToLLVM::checkStructure):
+ * tests/stress/sink_checkstructure.js: Added.
+ (foo):
+
+2015-05-01 Geoffrey Garen <ggaren@apple.com>
+
+ REGRESSION(r183570): jslib-traverse-jquery is 22% slower
+ https://bugs.webkit.org/show_bug.cgi?id=144476
+
+ Reviewed by Sam Weinig.
+
+ jslib-traverse-jquery is now 31% faster than its unregressed baseline.
+
+ The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
+ to my knowledge, the topic of how to optimize it is not covered in any
+ literature about sorting.
+
+ On the slowest jQuery sorting test -- prevAll -- our new
+ Array.prototype.sort, compared to its predecessor, performed 12% fewer
+ comparisons and requireed 10X less overhead per comparison. Yet, it was
+ slower.
+
+ It was slower because it inadvertantly increased the average cost of the
+ comparison function by 2X. jQuery uses compareDocumentPosition to compare
+ DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
+ required to traverse backwards from b to a. In prevAll, we encounter the
+ worst case for merge sort of compareDocumentPosition: A long list of DOM
+ nodes in mostly reverse order. In this case, merge sort will sequentially
+ compareDocumentPosition(a, b), where a is not reachable backwards from
+ b, and therefore compareDocumentPosition will traverse the whole sibling
+ list.
+
+ The solution is simple enough: Call compareDocumentPosition(b, a) instead.
+
+ This is a pretty silly thing to do, but it is harmless, and jQuery is
+ popular, so let's do it.
+
+ We do not risk suffering the same problem in reverse when sorting a long
+ list of DOM nodes in forward order. (We still have a 37% speedup on the
+ nextAll benchmark.) The reason is that merge sort performs 2X fewer
+ comparisons when the list is already sorted, so we can worry less about
+ the cost of each comparison.
+
+ A fully principled soultion to this problem would probably do something
+ like Python's timsort, which special-cases ordered ranges to perform
+ only O(n) comparisons. But that would contradict our original
+ goal of just having something simple that works.
+
+ Another option is for elements to keep a compareDocumentPosition cache,
+ like a node list cache, which allows you to determine the absolute
+ position of a node using a hash lookup. I will leave this as an exercise
+ for kling.
+
+ * builtins/Array.prototype.js:
+ (sort.merge): Compare in an order that is favorable to a comparator
+ that calls compareDocumentPosition.
+
+2015-05-04 Csaba Osztrogonác <ossy@webkit.org>
+
+ [cmake] Fix generate-js-builtins related incremental build issue
+ https://bugs.webkit.org/show_bug.cgi?id=144094
+
+ Reviewed by Michael Saboff.
+
+ * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
+ Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
+ * DerivedSources.make:
+ Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
+ * generate-js-builtins: Accept input files and input directory too.
+
+2015-05-03 Simon Fraser <simon.fraser@apple.com>
+
+ Make some static data const
+ https://bugs.webkit.org/show_bug.cgi?id=144552
+
+ Reviewed by Andreas Kling.
+
+ Turn characterSetInfo into const data.
+
+ * yarr/YarrCanonicalizeUCS2.cpp:
+ * yarr/YarrCanonicalizeUCS2.h:
+
+2015-05-01 Filip Pizlo <fpizlo@apple.com>
+
+ TypeOf should be fast
+ https://bugs.webkit.org/show_bug.cgi?id=144396
+
+ Reviewed by Geoffrey Garen.
+
+ Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
+ are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
+ TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
+
+ This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
+ rely heavily on C++ calls to fulfill their function.
+
+ Because TypeOf is now so fast, we no longer need to do any speculations on this node.
+
+ In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
+ This means that if the TypeOf is dominated by any type checks, we will automatically prune
+ out cases that are redundant.
+
+ This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
+ code generation is designed to be reusable.
+
+ This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
+ the exotic call trap hook. That hook is now in a deeper slow path than before.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGHeapLocation.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
+ (JSC::DFG::SpeculativeJIT::compileIsFunction):
+ (JSC::DFG::SpeculativeJIT::compileTypeOf):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
+ (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
+ (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
+ (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
+ (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
+ * ftl/FTLSwitchCase.h:
+ (JSC::FTL::SwitchCase::SwitchCase):
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::branchIfNotEqual):
+ (JSC::AssemblyHelpers::branchIfEqual):
+ (JSC::AssemblyHelpers::branchIfNumber):
+ (JSC::AssemblyHelpers::branchIfNotNumber):
+ (JSC::AssemblyHelpers::branchIfBoolean):
+ (JSC::AssemblyHelpers::branchIfNotBoolean):
+ (JSC::AssemblyHelpers::boxBooleanPayload):
+ (JSC::AssemblyHelpers::boxBoolean):
+ (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
+ * jit/JITOperations.h:
+ * runtime/SmallStrings.h:
+ (JSC::SmallStrings::typeString):
+ * runtime/TypeofType.cpp: Added.
+ (WTF::printInternal):
+ * runtime/TypeofType.h: Added.
+ * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
+
+2015-05-02 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
+
+ * dfg/DFGLICMPhase.cpp:
+ (JSC::DFG::LICMPhase::attemptHoist):
+
+2015-05-02 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
+ https://bugs.webkit.org/show_bug.cgi?id=144525.
+
+ * dfg/DFGLICMPhase.cpp:
+ (JSC::DFG::LICMPhase::attemptHoist):
+ * dfg/DFGPhantomInsertionPhase.cpp:
+
+2015-05-02 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Static property hashtable should only lookup with non-symbol key
+ https://bugs.webkit.org/show_bug.cgi?id=144438
+
+ Reviewed by Darin Adler.
+
+ Static property hashtable compares the Identifier's uid
+ with the normal C string without interning it.
+ So this comparison is performed in their contents.
+ As the result, in this comparison, symbol-ness is not considered.
+
+ So if accidentally the hash collision occur with the symbol and the string
+ and they have the same contents, the hash table entry is looked up incorrectly.
+
+ * runtime/Lookup.h:
+ (JSC::HashTable::entry):
+
+2015-05-01 Ryosuke Niwa <rniwa@webkit.org>
+
+ Class syntax should allow string and numeric identifiers for method names
+ https://bugs.webkit.org/show_bug.cgi?id=144254
+
+ Reviewed by Darin Adler.
+
+ Added the support for string and numeric identifiers in class syntax.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
+ inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
+ outside a class constructor as it should be.
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
+ element to allow numeric and string method names. For both of those method names, parse it here instead
+ of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
+ (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
+ this function is never used to parse a class method.
+ (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
+ (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
+ * parser/Parser.h:
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createProperty):
+
+2015-05-01 Filip Pizlo <fpizlo@apple.com>
+
+ FTL should use AI more
+ https://bugs.webkit.org/show_bug.cgi?id=144500
+
+ Reviewed by Oliver Hunt.
+
+ This makes our type check folding even more comprehensive by ensuring that even if the FTL
+ decides to emit some checks, it will still do another query to the abstract interpreter to
+ see if the check is necessary. This helps with cases where we decided early on to speculate
+ one way, but later proved a more specific type of the value in question, and the constant
+ folder didn't catch it.
+
+ This also makes it more natural to query the abstract interpreter. For example, if you just
+ want the proven type, you can now say provenType(node) or provenType(edge).
+
+ * dfg/DFGArrayMode.cpp:
+ (JSC::DFG::ArrayMode::alreadyChecked):
+ * dfg/DFGArrayMode.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
+ (JSC::FTL::LowerDFGToLLVM::compileToThis):
+ (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
+ (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
+ (JSC::FTL::LowerDFGToLLVM::compileArithPow):
+ (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
+ (JSC::FTL::LowerDFGToLLVM::compileGetById):
+ (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
+ (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
+ (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
+ (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
+ (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
+ (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
+ (JSC::FTL::LowerDFGToLLVM::compileSwitch):
+ (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
+ (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
+ (JSC::FTL::LowerDFGToLLVM::compileIsString):
+ (JSC::FTL::LowerDFGToLLVM::compileIsObject):
+ (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
+ (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
+ (JSC::FTL::LowerDFGToLLVM::baseIndex):
+ (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
+ (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
+ (JSC::FTL::LowerDFGToLLVM::boolify):
+ (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
+ (JSC::FTL::LowerDFGToLLVM::lowInt32):
+ (JSC::FTL::LowerDFGToLLVM::lowInt52):
+ (JSC::FTL::LowerDFGToLLVM::lowCell):
+ (JSC::FTL::LowerDFGToLLVM::lowBoolean):
+ (JSC::FTL::LowerDFGToLLVM::lowDouble):
+ (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
+ (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
+ (JSC::FTL::LowerDFGToLLVM::isNumber):
+ (JSC::FTL::LowerDFGToLLVM::isNotNumber):
+ (JSC::FTL::LowerDFGToLLVM::isNotCell):
+ (JSC::FTL::LowerDFGToLLVM::isCell):
+ (JSC::FTL::LowerDFGToLLVM::isNotMisc):
+ (JSC::FTL::LowerDFGToLLVM::isMisc):
+ (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
+ (JSC::FTL::LowerDFGToLLVM::isBoolean):
+ (JSC::FTL::LowerDFGToLLVM::isNotOther):
+ (JSC::FTL::LowerDFGToLLVM::isOther):
+ (JSC::FTL::LowerDFGToLLVM::isProvenValue):
+ (JSC::FTL::LowerDFGToLLVM::isObject):
+ (JSC::FTL::LowerDFGToLLVM::isNotObject):
+ (JSC::FTL::LowerDFGToLLVM::isNotString):
+ (JSC::FTL::LowerDFGToLLVM::isString):
+ (JSC::FTL::LowerDFGToLLVM::isFunction):
+ (JSC::FTL::LowerDFGToLLVM::isNotFunction):
+ (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
+ (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
+ (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
+ (JSC::FTL::LowerDFGToLLVM::abstractValue):
+ (JSC::FTL::LowerDFGToLLVM::provenType):
+ (JSC::FTL::LowerDFGToLLVM::provenValue):
+ (JSC::FTL::LowerDFGToLLVM::abstractStructure):
+
+2015-05-01 Martin Robinson <mrobinson@igalia.com>
+
+ USE(...) macro should expect unprefixed variables
+ https://bugs.webkit.org/show_bug.cgi?id=144454
+
+ Reviewed by Daniel Bates.
+
+ * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
+
+2015-05-01 Jordan Harband <ljharb@gmail.com>
+
+ String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
+ https://bugs.webkit.org/show_bug.cgi?id=144314
+
+ Reviewed by Darin Adler.
+
+ Fixing handling of Infinity position args, per
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
+
+ * runtime/StringPrototype.cpp:
+ (JSC::clampInt32):
+ (JSC::stringProtoFuncStartsWith):
+ (JSC::stringProtoFuncEndsWith):
+ (JSC::stringProtoFuncIncludes):
+
+2015-05-01 Basile Clement <basile_clement@apple.com>
+
+ Math.abs() returns negative
+ https://bugs.webkit.org/show_bug.cgi?id=137827
+
+ Reviewed by Michael Saboff.
+
+ Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
+ identity function.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * tests/stress/math-abs-positive.js: Added, was previously failing.
+ (foo):
+
+2015-05-01 Basile Clement <basile_clement@apple.com>
+
+ Function allocation sinking shouldn't be performed on singleton functions
+ https://bugs.webkit.org/show_bug.cgi?id=144166
+
+ Reviewed by Geoffrey Garen.
+
+ Function allocations usually are free of any other side effects, but
+ this is not the case for allocations performed while the underlying
+ FunctionExecutable is still a singleton (as this allogation will fire
+ watchpoints invalidating code that depends on it being a singleton).
+ As the object allocation sinking phase assumes object allocation is
+ free of side-effects, sinking these allocations is not correct.
+
+ This also means that when materializing a function allocation on OSR
+ exit, that function's executable will never be a singleton, and we don't have
+ to worry about its watchpoint, allowing us to use
+ JSFunction::createWithInvalidatedRellocationWatchpoint instead of
+ JSFunction::create.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+
+2015-04-30 Jon Davis <jond@apple.com>
+
+ Web Inspector: console should show an icon for console.info() messages
+ https://bugs.webkit.org/show_bug.cgi?id=18530
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/ConsoleMessage.cpp:
+ (Inspector::messageLevelValue):
+ * inspector/protocol/Console.json:
+ * runtime/ConsoleClient.cpp:
+ (JSC::appendMessagePrefix):
+ * runtime/ConsolePrototype.cpp:
+ (JSC::ConsolePrototype::finishCreation):
+ (JSC::consoleProtoFuncInfo):
+ * runtime/ConsoleTypes.h:
+
+2015-04-30 Filip Pizlo <fpizlo@apple.com>
+
+ Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
+ https://bugs.webkit.org/show_bug.cgi?id=144462
+
+ Reviewed by Geoffrey Garen and Mark Lam.
+
+ At some point we started adding representation-agnostic helpers for doing common type tests.
+ We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
+ they had overlapping powers, though SpeculativeJIT was a bit better.
+
+ This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
+ better because now all of these helpers can be used in all of the assembly-based JITs, not
+ just the DFG. It also settles on what I find to be a slightly better naming convention.
+ For example where we previously would have said branchIsString, now we say
+ branchIfString. Similarly, branchNotString becomes branchIfNotString.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileValueToInt32):
+ (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
+ (JSC::DFG::SpeculativeJIT::compileInstanceOf):
+ (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
+ (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
+ (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
+ (JSC::DFG::SpeculativeJIT::speculateObject):
+ (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
+ (JSC::DFG::SpeculativeJIT::speculateString):
+ (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
+ (JSC::DFG::SpeculativeJIT::speculateNotCell):
+ (JSC::DFG::SpeculativeJIT::speculateOther):
+ (JSC::DFG::SpeculativeJIT::emitSwitchChar):
+ (JSC::DFG::SpeculativeJIT::emitSwitchString):
+ (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
+ (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+ (JSC::DFG::SpeculativeJIT::compileObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
+ (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+ (JSC::DFG::SpeculativeJIT::compile):
+ (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
+ (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+ (JSC::DFG::SpeculativeJIT::compileObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
+ (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+ (JSC::DFG::SpeculativeJIT::compile):
+ (JSC::DFG::SpeculativeJIT::writeBarrier):
+ (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
+ (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::branchIfCell):
+ (JSC::AssemblyHelpers::branchIfOther):
+ (JSC::AssemblyHelpers::branchIfNotOther):
+ (JSC::AssemblyHelpers::branchIfObject):
+ (JSC::AssemblyHelpers::branchIfNotObject):
+ (JSC::AssemblyHelpers::branchIfType):
+ (JSC::AssemblyHelpers::branchIfNotType):
+ (JSC::AssemblyHelpers::branchIfString):
+ (JSC::AssemblyHelpers::branchIfNotString):
+ (JSC::AssemblyHelpers::branchIfSymbol):
+ (JSC::AssemblyHelpers::branchIfNotSymbol):
+ (JSC::AssemblyHelpers::branchIfFunction):
+ (JSC::AssemblyHelpers::branchIfNotFunction):
+ (JSC::AssemblyHelpers::branchIfEmpty):
+ (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
+ (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitScopedArgumentsGetByVal):
+
+2015-04-30 Filip Pizlo <fpizlo@apple.com>
+
+ js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
+ https://bugs.webkit.org/show_bug.cgi?id=144463
+
+ Reviewed by Benjamin Poulain.
+
+ Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
+ into a Check(String:@x) followed by JSConstant(true). Then in these tests the
+ ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
+ converting the boolean into an integer. But as part of doing that, it would try to
+ short-circuit any profiling by leveraging the fact that the IsString is now a constant,
+ and it would try to figure out if the addition might overflow. Part of that logic
+ involved checking if the immediate is either a boolean or a sufficiently small integer.
+ But: it would check if it's a sufficiently small integer before checking if it was a
+ boolean, so it would try to call asNumber() on the boolean.
+
+ All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
+ case was previously never hit until I wrote these tests, and so we never knew that
+ calling asNumber() on a boolean was wrong.
+
+ The fix is super simple: the expression should just check for boolean first.
+
+ This bug was benign in release builds. JSValue::asNumber() on a boolean would return
+ garbage, and that's OK, since we'd take the boolean case anyway.
+
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
+
+2015-04-30 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
+
+ * jit/JITOperations.cpp:
+
+2015-04-30 Filip Pizlo <fpizlo@apple.com>
+
+ Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
+ particular that they cannot change their minds and may be called from compiler threads.
+
+ Rubber stamped by Geoffrey Garen.
+
+ * runtime/JSCell.h:
+
+2015-04-29 Filip Pizlo <fpizlo@apple.com>
+
+ DFG Is<Blah> versions of TypeOf should fold based on proven input type
+ https://bugs.webkit.org/show_bug.cgi?id=144409
+
+ Reviewed by Geoffrey Garen.
+
+ We were missing some obvious folding opportunities here. I don't know how this affects real
+ code, but in general, we like to ensure that our constant folding is comprehensive. So this
+ is more about placating my static analysis OCD than anything else.
+
+ I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+
+2015-04-30 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Use the default hash value for Symbolized StringImpl
+ https://bugs.webkit.org/show_bug.cgi?id=144347
+
+ Reviewed by Darin Adler.
+
+ Before this patch, symbolized StringImpl* has a special hash value
+ to avoid the hash collision with the other normal StringImpl*.
+ I guess that it is introduced when private symbols are introduced.
+ However, it prevents using symbolized StringImpl* in the other place
+ For example, using it as WTFString cause a problem because of its special hash value.
+
+ When only using private symbols, they are not exposed to the outside of JSC,
+ so we can handle it carefully. But now, it's extended to symbols.
+ So I think storing a special hash value in StringImpl* causes an error.
+
+ To avoid this, I propose using the usual hash value in symbolized StringImpl*.
+ And to provide significantly different hash value when using it as symbol,
+ store the additional hash value in symbolized StringImpl*. It is used when
+ the hash value is required by IdentifierRepHash.
+
+ * runtime/Identifier.h:
+ (JSC::IdentifierRepHash::hash):
+ * runtime/Lookup.h:
+ (JSC::HashTable::entry):
+ * runtime/PropertyMapHashTable.h:
+ (JSC::PropertyTable::find):
+ (JSC::PropertyTable::get):
+ * runtime/Structure.cpp:
+ (JSC::PropertyTable::checkConsistency):
+
+2015-04-29 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Remove RageConvert array conversion
+ https://bugs.webkit.org/show_bug.cgi?id=144433
+
+ Reviewed by Filip Pizlo.
+
+ RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
+ pretty hard:
+ -The indexing types shows that the array access varies between Int32 and DoubleArray.
+ -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
+ An Arrayify node would convert the Int32 to that type.
+ -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
+ node would use RageConvert instead of Convert.
+ -The Arrayify for that GetByVal with RageConvert would not convert the array to
+ Contiguous.
+ -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
+ now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
+ fail systematically and we never get to run the later code.
+
+ Getting rid of RageConvert fixes the problem and does not seems to have any
+ negative side effect on other benchmarks.
+
+ The improvments on Kraken are:
+ -stanford-crypto-aes: definitely 1.0915x faster.
+ -stanford-crypto-pbkdf2: definitely 1.2446x faster.
+ -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGArrayMode.cpp:
+ (JSC::DFG::ArrayMode::refine):
+ (JSC::DFG::arrayConversionToString):
+ * dfg/DFGArrayMode.h:
+ * dfg/DFGArrayifySlowPathGenerator.h:
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGTypeCheckHoistingPhase.cpp:
+ (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::convertDoubleToContiguous):
+ (JSC::JSObject::ensureContiguousSlow):
+ (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
+ (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
+ (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
+ * runtime/JSObject.h:
+ (JSC::JSObject::rageEnsureContiguous): Deleted.
+
+2015-04-29 Joseph Pecoraro <pecoraro@apple.com>
+
+ Gracefully handle missing auto pause key on remote inspector setup
+ https://bugs.webkit.org/show_bug.cgi?id=144411
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::receivedSetupMessage):
+
+2015-04-29 Joseph Pecoraro <pecoraro@apple.com>
+
+ NodeList has issues with Symbol and empty string
+ https://bugs.webkit.org/show_bug.cgi?id=144310
+
+ Reviewed by Darin Adler.
+
+ * runtime/PropertyName.h:
+ (JSC::PropertyName::isSymbol):
+ Helper to check if the PropertyName is a string or symbol property.
+
+2015-04-29 Alex Christensen <achristensen@webkit.org>
+
+ Fix non-cygwin incremental builds on Windows.
+ https://bugs.webkit.org/show_bug.cgi?id=143264
+
+ Reviewed by Brent Fulgham.
+
+ * generate-js-builtins:
+ Remove stale headers before calling os.rename to replace them.
+
+2015-04-29 Filip Pizlo <fpizlo@apple.com>
+
+ JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
+ https://bugs.webkit.org/show_bug.cgi?id=144397
+
+ Reviewed by Andreas Kling.
+
+ Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
+ callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
+ making a getCallData() call if it isn't necessary.
+
+ * API/JSCallbackObject.h:
+ * runtime/InternalFunction.h:
+ * runtime/JSTypeInfo.h:
+ (JSC::TypeInfo::typeOfShouldCallGetCallData):
+ * runtime/Operations.cpp:
+ (JSC::jsTypeStringForValue):
+ * tests/stress/type-of-functions-and-objects.js: Added.
+ (foo):
+ (bar):
+ (baz):
+ (fuzz):
+ (expect):
+ (test):
+
+2015-04-28 Geoffrey Garen <ggaren@apple.com>
+
+ It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
+ https://bugs.webkit.org/show_bug.cgi?id=144013
+
+ Reviewed by Mark Lam.
+
+ This patch implements Array.prototype.sort in JavaScript, removing the
+ C++ implementations. It is simpler and less error-prone to express our
+ operations in JavaScript, which provides memory safety, exception safety,
+ and recursion safety.
+
+ The performance result is mixed, but net positive in my opinion. It's
+ difficult to enumerate all the results, since we used to have so many
+ different sorting modes, and there are lots of different data patterns
+ across which you might want to measure sorting. Suffice it to say:
+
+ (*) The benchmarks we track are faster or unchanged.
+
+ (*) Sorting random input using a comparator -- which we think is
+ common -- is 3X faster.
+
+ (*) Sorting random input in a non-array object -- which jQuery does
+ -- is 4X faster.
+
+ (*) Sorting random input in a compact array of integers using a
+ trivial pattern-matchable comparator is 2X *slower*.
+
+ * builtins/Array.prototype.js:
+ (sort.min):
+ (sort.stringComparator):
+ (sort.compactSparse): Special case compaction for sparse arrays because
+ we don't want to hang when sorting new Array(BIG).
+
+ (sort.compact):
+ (sort.merge):
+ (sort.mergeSort): Use merge sort because it's a reasonably efficient
+ stable sort. We have evidence that some sites depend on stable sort,
+ even though the ES6 spec does not mandate it. (See
+ <http://trac.webkit.org/changeset/33967>.)
+
+ This is a textbook implementation of merge sort with three optimizations:
+
+ (1) Use iteration instead of recursion;
+
+ (2) Use array subscripting instead of array copying in order to
+ create logical sub-lists without creating physical sub-lists;
+
+ (3) Swap src and dst at each iteration instead of copying src into
+ dst, and only copy src into the subject array at the end if src is
+ not the subject array.
+
+ (sort.inflate):
+ (sort.comparatorSort):
+ (sort): Sort in JavaScript for the win.
+
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
+ names so we can use helper functions.
+
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::isNumericCompareFunction): Deleted.
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
+ (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::FunctionNode::emitBytecode): We don't do this special casing based
+ on pattern matching anymore. This was mainly an optimization to avoid
+ the overhead of calling from C++ to JS, which we now avoid by
+ sorting in JS.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::markRoots):
+ (JSC::Heap::pushTempSortVector): Deleted.
+ (JSC::Heap::popTempSortVector): Deleted.
+ (JSC::Heap::visitTempSortVectors): Deleted.
+ * heap/Heap.h: We don't have temp sort vectors anymore because we sort
+ in JavaScript using a normal JavaScript array for our temporary storage.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
+ helper functions.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::isNumericCompareFunction): Deleted.
+ (JSC::attemptFastSort): Deleted.
+ (JSC::performSlowSort): Deleted.
+ (JSC::arrayProtoFuncSort): Deleted.
+
+ * runtime/CommonIdentifiers.h: New strings used by sort.
+
+ * runtime/JSArray.cpp:
+ (JSC::compareNumbersForQSortWithInt32): Deleted.
+ (JSC::compareNumbersForQSortWithDouble): Deleted.
+ (JSC::compareNumbersForQSort): Deleted.
+ (JSC::compareByStringPairForQSort): Deleted.
+ (JSC::JSArray::sortNumericVector): Deleted.
+ (JSC::JSArray::sortNumeric): Deleted.
+ (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
+ (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
+ (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
+ (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
+ (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
+ (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
+ (JSC::JSArray::sortCompactedVector): Deleted.
+ (JSC::JSArray::sort): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
+ (JSC::JSArray::sortVector): Deleted.
+ (JSC::JSArray::compactForSorting): Deleted.
+ * runtime/JSArray.h:
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructor::finishCreation): Provide some builtins used
+ by sort.
+
+2015-04-29 Mark Lam <mark.lam@apple.com>
+
+ Safari WebKit crash when loading Google Spreadsheet.
+ https://bugs.webkit.org/show_bug.cgi?id=144020
+
+ Reviewed by Filip Pizlo.
+
+ The bug is that the object allocation sinking phase did not account for a case
+ where a property of a sunken object is only initialized on one path and not
+ another. As a result, on the path where the property is not initialized, we'll
+ encounter an Upsilon with a BottomValue (which is not allowed by definition).
+
+ The fix is to use a JSConstant(undefined) as the bottom value instead (of
+ BottomValue). If the property is uninitialized, it should still be accessible
+ and have the value undefined.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
+ * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
+ (foo):
+ (foo2):
+
+2015-04-29 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
+ https://bugs.webkit.org/show_bug.cgi?id=144257
+
+ Reviewed by Darin Adler.
+
+ SHA1 is used to calculate CodeBlockHash.
+ To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
+ However, the source code can contain null character.
+ So when performing `strlen` on the source code's CString, it returns the incorrect length.
+ In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
+
+ In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
+ As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
+
+ CString will be changed not to contain a null-character[1]. However, inserting the assertion here
+ is not correct. Because
+
+ 1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
+ 2. If CString can contain a null character, this assertion becomes incorrect.
+
+ So this patch just drops the assertion.
+
+ In the current implementation, we once convert the entire source code to the newly allocated
+ UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
+ Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
+ We'll implement it in the separate patch[2].
+
+ [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
+ [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
+
+ * tests/stress/eval-script-contains-null-character.js: Added.
+ (shouldBe):
+ (test):
+ * tests/stress/template-literal-line-terminators.js:
+ * tests/stress/template-literal-syntax.js:
+ * tests/stress/template-literal.js:
+
+2015-04-29 Filip Pizlo <fpizlo@apple.com>
+
+ Evict IsEnvironmentRecord from inline type flags
+ https://bugs.webkit.org/show_bug.cgi?id=144398
+
+ Reviewed by Mark Lam and Michael Saboff.
+
+ In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
+ type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
+ and evicts it into the out-of-line type flags. This change has no performance implications
+ because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
+ where we access it at all is in String.prototype.repeat, and there we already load the
+ structure anyway.
+
+ * runtime/JSTypeInfo.h:
+ (JSC::TypeInfo::implementsHasInstance):
+ (JSC::TypeInfo::structureIsImmortal):
+ (JSC::TypeInfo::isEnvironmentRecord):
+
+2015-04-29 Darin Adler <darin@apple.com>
+
+ [ES6] Implement Unicode code point escapes
+ https://bugs.webkit.org/show_bug.cgi?id=144377
+
+ Reviewed by Antti Koivisto.
+
+ * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
+ the header. Made it a non-member class so it doesn't need to be part
+ of a template. Made it use UChar32 instead of int for the value to
+ make it clearer what goes into this class.
+ (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
+ old type() function.
+ (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
+ parseFourDigitUnicodeHex and added support for code point escapes.
+ (JSC::isLatin1): Added an overload for UChar32.
+ (JSC::isIdentStart): Changed this to take UChar32; no caller tries
+ to call it with a UChar, so no need to overload for that type for now.
+ (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
+ Also added FIXME about a subtle ES6 change that we might want to make later.
+ (JSC::isIdentPart): Changed this to take UChar32; no caller tries
+ to call it with a UChar, so no need to overload for that type for now.
+ (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
+ don't need to repeat the code twice. Added code to handle code point escapes.
+ (JSC::isIdentPartIncludingEscape): Call the template instead of having the
+ code in line.
+ (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
+ (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
+ updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
+ (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
+ instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
+ the code that handles the escapes, since the code point escape code now
+ consumes characters while parsing rather than peeking ahead. Test case
+ covers this: Symptom would be that "\u{" would evaluate to "u" instead of
+ giving a syntax error.
+
+ * parser/Lexer.h: Updated for above changes.
+
+ * runtime/StringConstructor.cpp:
+ (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
+ out 0x10FFFF; clearer this way.
+
+2015-04-29 Martin Robinson <mrobinson@igalia.com>
+
+ [CMake] [GTK] Organize and clean up unused CMake variables
+ https://bugs.webkit.org/show_bug.cgi?id=144364
+
+ Reviewed by Gyuyoung Kim.
+
+ * PlatformGTK.cmake: Add variables specific to this project.
+
+2015-04-28 Filip Pizlo <fpizlo@apple.com>
+
+ TypeOf should return SpecStringIdent and the DFG should know this
+ https://bugs.webkit.org/show_bug.cgi?id=144376
+
+ Reviewed by Andreas Kling.
+
+ Make TypeOf return atomic strings. That's a simple change in SmallStrings.
+
+ Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
+ bad.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGAbstractValue.cpp:
+ (JSC::DFG::AbstractValue::setType):
+ * dfg/DFGAbstractValue.h:
+ (JSC::DFG::AbstractValue::setType):
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::initialize):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * runtime/SmallStrings.cpp:
+ (JSC::SmallStrings::initialize):
+ * tests/stress/switch-typeof-indirect.js: Added.
+ (bar):
+ (foo):
+ (test):
+ * tests/stress/switch-typeof-slightly-indirect.js: Added.
+ (foo):
+ (test):
+ * tests/stress/switch-typeof.js: Added.
+ (foo):
+ (test):
+
+2015-04-29 Joseph Pecoraro <pecoraro@apple.com>
+
+ REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
+ https://bugs.webkit.org/show_bug.cgi?id=144373
+
+ Reviewed by Darin Adler.
+
+ Revert r181868 as it caused a failure on live.com. We can try
+ re-enabling this exception after we make idl attributes configurable,
+ which may have prevented this particular failure.
+
+ * runtime/ObjectPrototype.cpp:
+ (JSC::objectProtoFuncDefineGetter):
+ (JSC::objectProtoFuncDefineSetter):
+
+2015-04-28 Joseph Pecoraro <pecoraro@apple.com>
+
+ Deadlock on applications using JSContext on non-main thread
+ https://bugs.webkit.org/show_bug.cgi?id=144370
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::singleton):
+ Prevent a possible deadlock by assuming we can synchronously
+ run something on the main queue at this time.
+
+2015-04-28 Filip Pizlo <fpizlo@apple.com>
+
+ FTL should fully support Switch (it currently lacks the SwitchString variant)
+ https://bugs.webkit.org/show_bug.cgi?id=144348
+
+ Reviewed by Benjamin Poulain.
+
+ This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
+ in LayoutTests/js/regress.
+
+ * dfg/DFGCommon.cpp:
+ (JSC::DFG::stringLessThan):
+ * dfg/DFGCommon.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileSwitch):
+ (JSC::FTL::LowerDFGToLLVM::switchString):
+ (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
+ (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
+ (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
+ (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
+ (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
+ (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
+ (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
+ * ftl/FTLOutput.cpp:
+ (JSC::FTL::Output::check):
+ * ftl/FTLOutput.h:
+ * ftl/FTLWeight.h:
+ (JSC::FTL::Weight::inverse):
+ * jit/JITOperations.h:
+
+2015-04-28 Michael Catanzaro <mcatanzaro@igalia.com>
+
+ Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
+ https://bugs.webkit.org/show_bug.cgi?id=144304
+
+ Reviewed by Geoffrey Garen.
+
+ * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
+ ENABLE_LLINT_C_LOOP, disabled by default.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
+
+2015-04-28 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r183514.
+ https://bugs.webkit.org/show_bug.cgi?id=144359
+
+ It broke cloop test bots (Requested by mcatanzaro on #webkit).
+
+ Reverted changeset:
+
+ "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
+ https://bugs.webkit.org/show_bug.cgi?id=144304
+ http://trac.webkit.org/changeset/183514
+
+2015-04-28 Michael Catanzaro <mcatanzaro@igalia.com>
+
+ Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
+ https://bugs.webkit.org/show_bug.cgi?id=144304
+
+ Reviewed by Geoffrey Garen.
+
+ * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
+ ENABLE_LLINT_C_LOOP, disabled by default.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
+
+2015-04-28 Joseph Pecoraro <pecoraro@apple.com>
+
+ Fix common typo "targetting" => "targeting"
+ https://bugs.webkit.org/show_bug.cgi?id=144349
+
+ Reviewed by Daniel Bates.
+
+ * bytecode/ExecutionCounter.h:
+
+2015-04-28 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
+ https://bugs.webkit.org/show_bug.cgi?id=144328
+
+ Reviewed by Andreas Kling.
+
+ Update the status of ES6 features.
+
+ * features.json:
+
+2015-04-28 Filip Pizlo <fpizlo@apple.com>
+
+ DFG should not use or preserve Phantoms during transformations
+ https://bugs.webkit.org/show_bug.cgi?id=143736
+
+ Reviewed by Geoffrey Garen.
+
+ Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
+ no longer necessary to preserve Phantoms during transformations. They are still useful just
+ before FixupPhase to support backwards propagation analyses. They are still inserted late in the
+ game in the DFG backend. But transformations don't need to worry about them. Inside a basic
+ block, we can be sure that so long as the IR pinpoints the place where the value becomes
+ available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
+ other block would need the value (either for OSR or for DFG execution), then we don't need any
+ liveness markers.
+
+ So, this removes any places where we inserted Phantoms just for liveness during transformation
+ and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
+ Check node only keeps its children so long as those children have checks.
+
+ The fact that we no longer convertToPhantom() means that we have to be more careful when
+ constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
+ Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
+ a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
+ Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
+ GetLocals.
+
+ The only Phantom-like cruft left over after this patch is:
+
+ - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
+ backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
+ the users of the original local's live range in bytecode. This is essential for supporting our
+ BackwardsPropagationPhase, which is an important optimization for things like asm.js.
+
+ - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
+ https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
+ alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
+ the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
+ treat GetLocal/SetLocal conservatively, this should all be sound.
+
+ This change should be perf-neutral although it does reduce the total work that the compiler
+ does.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGAdjacencyList.h:
+ (JSC::DFG::AdjacencyList::justChecks):
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGBasicBlock.cpp:
+ (JSC::DFG::BasicBlock::replaceTerminal):
+ * dfg/DFGBasicBlock.h:
+ (JSC::DFG::BasicBlock::findTerminal):
+ * dfg/DFGCFGSimplificationPhase.cpp:
+ (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
+ (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
+ (JSC::DFG::CPSRethreadingPhase::clearVariables):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
+ * dfg/DFGCSEPhase.cpp:
+ * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
+ (JSC::DFG::CleanUpPhase::CleanUpPhase):
+ (JSC::DFG::CleanUpPhase::run):
+ (JSC::DFG::performCleanUp):
+ (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
+ (JSC::DFG::PhantomRemovalPhase::run): Deleted.
+ (JSC::DFG::performPhantomRemoval): Deleted.
+ * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
+ (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
+ * dfg/DFGDCEPhase.cpp:
+ (JSC::DFG::DCEPhase::run):
+ (JSC::DFG::DCEPhase::fixupBlock):
+ (JSC::DFG::DCEPhase::cleanVariables):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupBlock):
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::convertStringAddUse):
+ (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
+ (JSC::DFG::FixupPhase::checkArray):
+ (JSC::DFG::FixupPhase::fixIntConvertingEdge):
+ (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
+ (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
+ (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
+ (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
+ (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
+ (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
+ (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::convertToConstant):
+ (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
+ * dfg/DFGGraph.h:
+ * dfg/DFGInsertionSet.h:
+ (JSC::DFG::InsertionSet::insertCheck):
+ * dfg/DFGIntegerCheckCombiningPhase.cpp:
+ (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
+ * dfg/DFGLICMPhase.cpp:
+ (JSC::DFG::LICMPhase::attemptHoist):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::remove):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::replaceWith):
+ (JSC::DFG::Node::convertToPhantom): Deleted.
+ (JSC::DFG::Node::convertToCheck): Deleted.
+ (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
+ * dfg/DFGNodeFlags.h:
+ * dfg/DFGNodeType.h:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
+ * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
+ * dfg/DFGPhantomRemovalPhase.cpp: Removed.
+ * dfg/DFGPhantomRemovalPhase.h: Removed.
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGPutStackSinkingPhase.cpp:
+ * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
+ * dfg/DFGResurrectionForValidationPhase.h: Removed.
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
+ * dfg/DFGStoreBarrierElisionPhase.cpp:
+ (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
+ * dfg/DFGStrengthReductionPhase.cpp:
+ (JSC::DFG::StrengthReductionPhase::handleNode):
+ (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validate):
+ (JSC::DFG::Validate::validateCPS):
+ (JSC::DFG::Validate::validateSSA):
+ * dfg/DFGVarargsForwardingPhase.cpp:
+ * ftl/FTLLink.cpp:
+ (JSC::FTL::link):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileNoOp):
+ (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
+
+2015-04-28 Andreas Kling <akling@apple.com>
+
+ DFG+FTL should generate efficient code for branching on a string's boolean value.
+ <https://webkit.org/b/144317>
+
+ Reviewed by Geoff Garen & Filip Pizlo
+
+ Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
+ instead of dropping out to C++ whenever we branch on a string.
+
+ The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
+ the DFG JIT gets some new codegen logic in this patch.
+
+ Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitStringBranch):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitBranch):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitBranch):
+
+2015-04-28 Filip Pizlo <fpizlo@apple.com>
+
+ VarargsForwardingPhase should only consider MovHints that have the candidate as a child
+ https://bugs.webkit.org/show_bug.cgi?id=144340
+
+ Reviewed by Michael Saboff and Mark Lam.
+
+ Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
+ CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
+ Basically, we'd keep it alive until the end of the block. This maximized the chances of
+ there being an interfering operation, which would prevent elimination.
+
+ The fix is to only consider MovHints that have the arguments candidate as a child. We only
+ care to track the liveness of those bytecode locals that would need an arguments object
+ recovery on OSR exit.
+
+ This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
+ introduced in http://trac.webkit.org/changeset/183406.
+
+ * dfg/DFGVarargsForwardingPhase.cpp:
+
+2015-04-28 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove WinCE cruft from cmake build system
+ https://bugs.webkit.org/show_bug.cgi?id=144325
+
+ Reviewed by Gyuyoung Kim.
+
+ * CMakeLists.txt:
+ * create_jit_stubs: Removed.
+
+2015-04-27 Andreas Kling <akling@apple.com>
+
+ RegExp matches arrays should use contiguous indexing.
+ <https://webkit.org/b/144286>
+
+ Reviewed by Geoffrey Garen.
+
+ We had a custom Structure being used for RegExp matches arrays that would
+ put the arrays into SlowPutArrayStorageShape mode. This was just left
+ from when matches arrays were custom, lazily initialized objects.
+
+ This change removes that Structure and switches the matches arrays to
+ using the default ContiguousShape Structure. This allows the FTL JIT
+ to compile the inner loop of the Octane/regexp benchmark.
+
+ Also made a version of initializeIndex() [inline] that takes the indexing
+ type in an argument, allowing createRegExpMatchesArray() to initialize
+ the entire array without branching on the indexing type for each entry.
+
+ ~3% progression on Octane/regexp.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::mapStructure):
+ (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
+ * runtime/JSObject.h:
+ (JSC::JSObject::initializeIndex):
+ * runtime/RegExpMatchesArray.cpp:
+ (JSC::createRegExpMatchesArray):
+
+2015-04-27 Filip Pizlo <fpizlo@apple.com>
+
+ FTL failed to initialize arguments.callee on the slow path as well as the fast path
+ https://bugs.webkit.org/show_bug.cgi?id=144293
+
+ Reviewed by Mark Lam.
+
+ The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
+ to initialize the callee on the common path after the fast and slow path.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
+ * tests/stress/arguments-callee-uninitialized.js: Added.
+ (foo):
+
+2015-04-27 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Add support for typed arrays to the Array profiling
+ https://bugs.webkit.org/show_bug.cgi?id=143913
+
+ Reviewed by Filip Pizlo.
+
+ This patch adds ArrayModes for every typed arrays. Having that information
+ let us generate better GetByVal and PutByVal when the type speculation
+ are not good enough.
+
+ A typical case where this is useful is any basic block for which the type
+ of the object is always more restrictive than the speculation (for example,
+ a basic block gated by a branch only taken for on type).
+
+ * bytecode/ArrayProfile.cpp:
+ (JSC::dumpArrayModes):
+ * bytecode/ArrayProfile.h:
+ (JSC::arrayModeFromStructure):
+ * dfg/DFGArrayMode.cpp:
+ (JSC::DFG::ArrayMode::fromObserved):
+ (JSC::DFG::ArrayMode::refine):
+ Maintain the refine() semantic. We do not support OutOfBounds access
+ for GetByVal on typed array.
+
+ * runtime/IndexingType.h:
+ * tests/stress/typed-array-get-by-val-profiling.js: Added.
+ (testArray.testCode):
+ (testArray):
+ * tests/stress/typed-array-put-by-val-profiling.js: Added.
+ (testArray.testCode):
+ (testArray):
+
+2015-04-27 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
+ causes many debug test failures.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::regExpMatchesArrayStructure):
+ * runtime/JSObject.h:
+ (JSC::JSObject::initializeIndex):
+ * runtime/RegExpMatchesArray.cpp:
+ (JSC::createRegExpMatchesArray):
+
+2015-04-27 Andreas Kling <akling@apple.com>
+
+ RegExp matches arrays should use contiguous indexing.
+ <https://webkit.org/b/144286>
+
+ Reviewed by Geoffrey Garen.
+
+ We had a custom Structure being used for RegExp matches arrays that would
+ put the arrays into SlowPutArrayStorageShape mode. This was just left
+ from when matches arrays were custom, lazily initialized objects.
+
+ This change removes that Structure and switches the matches arrays to
+ using the default ContiguousShape Structure. This allows the FTL JIT
+ to compile the inner loop of the Octane/regexp benchmark.
+
+ Also made a version of initializeIndex() [inline] that takes the indexing
+ type in an argument, allowing createRegExpMatchesArray() to initialize
+ the entire array without branching on the indexing type for each entry.
+
+ ~3% progression on Octane/regexp.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::mapStructure):
+ (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
+ * runtime/JSObject.h:
+ (JSC::JSObject::initializeIndex):
+ * runtime/RegExpMatchesArray.cpp:
+ (JSC::createRegExpMatchesArray):
+
+2015-04-27 Ryosuke Niwa <rniwa@webkit.org>
+
+ REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
+ https://bugs.webkit.org/show_bug.cgi?id=144257
+
+ Temporarily disable skip these tests.
+
+ * tests/stress/template-literal-line-terminators.js:
+ * tests/stress/template-literal-syntax.js:
+ * tests/stress/template-literal.js:
+
+2015-04-27 Basile Clement <basile_clement@apple.com>
+
+ Function allocations shouldn't sink through Put operations
+ https://bugs.webkit.org/show_bug.cgi?id=144176
+
+ Reviewed by Filip Pizlo.
+
+ By design, we don't support function allocation sinking through any
+ related operation ; however object allocation can sink through PutByOffset et
+ al.
+
+ Currently, the checks to prevent function allocation to sink through
+ these are misguided and do not prevent anything ; function allocation sinking
+ through these operations is prevented as a side effect of requiring an
+ AllocatePropertyStorage through which the function allocation is seen as
+ escaping.
+
+ This changes it so that ObjectAllocationSinkingPhase::handleNode()
+ checks properly that only object allocations sink through related write
+ operations.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+
+2015-04-25 Filip Pizlo <fpizlo@apple.com>
+
+ VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
+ https://bugs.webkit.org/show_bug.cgi?id=143843
+
+ Reviewed by Geoffrey Garen.
+
+ It will soon come to pass that Phantom isn't available at the time that
+ VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
+ a value dies for OSR.
+
+ This is simplified by two things:
+
+ 1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
+ before by polishing the API.
+
+ 2) This phase already operates on one node at a time and allows itself to do a full search
+ of the enclosing basic block for that node. This is fine because CreateDirectArguments
+ and friends is a rarely occurring node. The fact that it operates on one node at a time
+ makes it even easier to reason about OSR liveness - we just track the list of locals in
+ which it is live.
+
+ This change has no effect right now but it is a necessary prerequisite to implementing
+ https://bugs.webkit.org/show_bug.cgi?id=143736.
+
+ * dfg/DFGBasicBlock.h:
+ (JSC::DFG::BasicBlock::tryAt):
+ * dfg/DFGForAllKills.h:
+ (JSC::DFG::forAllKilledOperands):
+ * dfg/DFGPhantomInsertionPhase.cpp:
+ * dfg/DFGVarargsForwardingPhase.cpp:
+
+2015-04-27 Jordan Harband <ljharb@gmail.com>
+
+ Map#entries and Map#keys error for non-Maps is swapped
+ https://bugs.webkit.org/show_bug.cgi?id=144253
+
+ Reviewed by Simon Fraser.
+
+ Correcting error messages on Set/Map methods when called on
+ incompatible objects.
+
+ * runtime/MapPrototype.cpp:
+ (JSC::mapProtoFuncEntries):
+ (JSC::mapProtoFuncKeys):
+ * runtime/SetPrototype.cpp:
+ (JSC::setProtoFuncEntries):
+
+2015-04-24 Filip Pizlo <fpizlo@apple.com>
+
+ Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
+ https://bugs.webkit.org/show_bug.cgi?id=144186
+
+ Reviewed by Geoffrey Garen.
+
+ If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
+ Int32. We may later perform code simplifications based on the proof that this is Int32, and
+ we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
+ which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
+ except that we still need the overflow check!
+
+ Previously we mishandled this:
+
+ - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
+ to keep it alive. That's dirty and it's just indicative of a deeper issue.
+
+ - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
+ powerless. This was sort of hiding the bug.
+
+ - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
+ something that you are relying on for subsequent simplifications.
+
+ This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
+ nodes that may perform checks that are used by AI to guarantee the result type. As a result,
+ we no longer need the weird MustGenerate node.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDCEPhase.cpp:
+ (JSC::DFG::DCEPhase::run):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
+ * dfg/DFGIntegerCheckCombiningPhase.cpp:
+ (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
+ (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::willHaveCodeGenOrOSR):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPhantomCanonicalizationPhase.cpp:
+ (JSC::DFG::PhantomCanonicalizationPhase::run):
+ * dfg/DFGPhantomRemovalPhase.cpp:
+ (JSC::DFG::PhantomRemovalPhase::run):
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * 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/DFGTypeCheckHoistingPhase.cpp:
+ (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
+ (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
+ * dfg/DFGVarargsForwardingPhase.cpp:
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
+ (foo):
+ * tests/stress/fold-based-on-int32-proof-mul.js: Added.
+ (foo):
+ * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
+ (foo):
+ * tests/stress/fold-based-on-int32-proof.js: Added.
+ (foo):
+
+2015-04-26 Ryosuke Niwa <rniwa@webkit.org>
+
+ Class body ending with a semicolon throws a SyntaxError
+ https://bugs.webkit.org/show_bug.cgi?id=144244
+
+ Reviewed by Darin Adler.
+
+ The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
+ it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
+ it by continue'ing when it encounters a semicolon.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+
+2015-04-26 Ryosuke Niwa <rniwa@webkit.org>
+
+ Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
+ https://bugs.webkit.org/show_bug.cgi?id=144243
+
+ Reviewed by Darin Adler.
+
+ Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseGetterSetter):
+
+2015-04-26 Jordan Harband <ljharb@gmail.com>
+
+ Map#forEach does not pass "map" argument to callback.
+ https://bugs.webkit.org/show_bug.cgi?id=144187
+
+ Reviewed by Darin Adler.
+
+ Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
+ step 7.a.i., the callback should be called with three arguments.
+
+ * runtime/MapPrototype.cpp:
+ (JSC::mapProtoFuncForEach):
+
+2015-04-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement ES6 template literals
+ https://bugs.webkit.org/show_bug.cgi?id=142691
+
+ Reviewed by Darin Adler.
+
+ This patch implements TemplateLiteral.
+ Since TaggedTemplate requires some global states and
+ primitive operations like GetTemplateObject,
+ we separate the patch. It will be implemented in a subsequent patch.
+
+ Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
+ By disabling it, we can disable Template Literal support.
+
+ To implement template literals, in this patch,
+ we newly introduces bytecode op_to_string.
+ In template literals, we alternately evaluate the expression and
+ perform ToString onto the result of evaluation.
+ For example,
+
+ `${f1()} ${f2()}`
+
+ In this template literal, execution order is the following,
+ 1. calling f1()
+ 2. ToString(the result of f1())
+ 3. calling f2()
+ 4. ToString(the result of f2())
+
+ op_strcat also performs ToString. However, performing ToString
+ onto expressions are batched in op_strcat, it's not the same to the
+ template literal spec. In the above example,
+ ToString(f1()) should be called before calling f2().
+
+ * Configurations/FeatureDefines.xcconfig:
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::emitToString):
+ (JSC::BytecodeGenerator::emitToNumber): Deleted.
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::TemplateStringNode::emitBytecode):
+ (JSC::TemplateLiteralNode::emitBytecode):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ (JSC::JIT::privateCompileSlowCases):
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_to_string):
+ (JSC::JIT::emitSlow_op_to_string):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_to_string):
+ (JSC::JIT::emitSlow_op_to_string):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createTemplateString):
+ (JSC::ASTBuilder::createTemplateStringList):
+ (JSC::ASTBuilder::createTemplateExpressionList):
+ (JSC::ASTBuilder::createTemplateLiteral):
+ * parser/Lexer.cpp:
+ (JSC::Lexer<T>::Lexer):
+ (JSC::Lexer<T>::parseIdentifierSlowCase):
+ (JSC::Lexer<T>::parseString):
+ (JSC::LineNumberAdder::LineNumberAdder):
+ (JSC::LineNumberAdder::clear):
+ (JSC::LineNumberAdder::add):
+ (JSC::Lexer<T>::parseTemplateLiteral):
+ (JSC::Lexer<T>::lex):
+ (JSC::Lexer<T>::scanRegExp):
+ (JSC::Lexer<T>::scanTrailingTemplateString):
+ (JSC::Lexer<T>::parseStringSlowCase): Deleted.
+ * parser/Lexer.h:
+ * parser/NodeConstructors.h:
+ (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
+ (JSC::TemplateStringNode::TemplateStringNode):
+ (JSC::TemplateStringListNode::TemplateStringListNode):
+ (JSC::TemplateLiteralNode::TemplateLiteralNode):
+ * parser/Nodes.h:
+ (JSC::TemplateExpressionListNode::value):
+ (JSC::TemplateExpressionListNode::next):
+ (JSC::TemplateStringNode::cooked):
+ (JSC::TemplateStringNode::raw):
+ (JSC::TemplateStringListNode::value):
+ (JSC::TemplateStringListNode::next):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseTemplateString):
+ (JSC::Parser<LexerType>::parseTemplateLiteral):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ * parser/Parser.h:
+ * parser/ParserTokens.h:
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createTemplateString):
+ (JSC::SyntaxChecker::createTemplateStringList):
+ (JSC::SyntaxChecker::createTemplateExpressionList):
+ (JSC::SyntaxChecker::createTemplateLiteral):
+ (JSC::SyntaxChecker::createSpreadExpression): Deleted.
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ * tests/stress/template-literal-line-terminators.js: Added.
+ (test):
+ (testEval):
+ (testEvalLineNumber):
+ * tests/stress/template-literal-syntax.js: Added.
+ (testSyntax):
+ (testSyntaxError):
+ * tests/stress/template-literal.js: Added.
+ (test):
+ (testEval):
+ (testEmbedded):
+
+2015-04-26 Jordan Harband <ljharb@gmail.com>
+
+ Set#forEach does not pass "key" or "set" arguments to callback.
+ https://bugs.webkit.org/show_bug.cgi?id=144188
+
+ Reviewed by Darin Adler.
+
+ Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
+ Set#forEach should pass 3 arguments to the callback.
+
+ * runtime/SetPrototype.cpp:
+ (JSC::setProtoFuncForEach):
+
+2015-04-26 Benjamin Poulain <benjamin@webkit.org>
+
+ [JSC] Implement Math.clz32(), remove Number.clz()
+ https://bugs.webkit.org/show_bug.cgi?id=144205
+
+ Reviewed by Michael Saboff.
+
+ This patch adds the ES6 function Math.clz32(), and remove the non-standard
+ Number.clz(). Number.clz() probably came from an older draft.
+
+ The new function has a corresponding instrinsic: Clz32Intrinsic,
+ and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
+
+ * assembler/MacroAssemblerX86Common.h:
+ (JSC::MacroAssemblerX86Common::countLeadingZeros32):
+ * assembler/X86Assembler.h:
+ (JSC::X86Assembler::bsr_rr):
+ The x86 assembler did not have countLeadingZeros32() because there is
+ no native CLZ instruction on that architecture.
+
+ I have added the version with bsr + branches for the case of zero.
+ An other popular version uses cmov to handle the case of zero. I kept
+ it simple since the Assembler has no support for cmov.
+
+ It is unlikely to matter much. If the code is hot enough, LLVM picks
+ something good based on the surrounding code.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ Constant handling + effect propagation. The node only produces integer (between 0 and 32).
+
+ * dfg/DFGBackwardsPropagationPhase.cpp:
+ (JSC::DFG::BackwardsPropagationPhase::propagate):
+ Thanks to the definition of toUint32(), we can ignore plenty of details
+ from doubles.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * 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.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithClz32):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
+ * ftl/FTLOutput.h:
+ (JSC::FTL::Output::ctlz32):
+ * jit/ThunkGenerators.cpp:
+ (JSC::clz32ThunkGenerator):
+ * jit/ThunkGenerators.h:
+ * runtime/Intrinsic.h:
+ * runtime/MathCommon.h:
+ (JSC::clz32):
+ Fun fact: InstCombine does not recognize this pattern to eliminate
+ the branch which makes our FTL version better than the C version.
+
+ * runtime/MathObject.cpp:
+ (JSC::MathObject::finishCreation):
+ (JSC::mathProtoFuncClz32):
+ * runtime/NumberPrototype.cpp:
+ (JSC::clz): Deleted.
+ (JSC::numberProtoFuncClz): Deleted.
+ * runtime/VM.cpp:
+ (JSC::thunkGeneratorForIntrinsic):
+ * tests/stress/math-clz32-basics.js: Added.
+ (mathClz32OnInteger):
+ (testMathClz32OnIntegers):
+ (verifyMathClz32OnIntegerWithOtherTypes):
+ (mathClz32OnDouble):
+ (testMathClz32OnDoubles):
+ (verifyMathClz32OnDoublesWithOtherTypes):
+ (mathClz32NoArguments):
+ (mathClz32TooManyArguments):
+ (testMathClz32OnConstants):
+ (mathClz32StructTransition):
+ (Math.clz32):
+
+2015-04-26 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Array.from need to accept iterables
+ https://bugs.webkit.org/show_bug.cgi?id=141055
+
+ Reviewed by Darin Adler.
+
+ ES6 spec requires that Array.from accepts iterable objects.
+ This patch introduces this functionality, Array.from accepting iterable objects.
+
+ Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
+ However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
+ `typeof thisObj === "function"` queries the given object has `[[Call]]`.
+ This will be fixed in the subsequent patch[1].
+
+ [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
+
+ * builtins/ArrayConstructor.js:
+ (from):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner):
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * tests/stress/array-from-with-iterable.js: Added.
+ (shouldBe):
+ (.set for):
+ (.set var):
+ (.get var):
+ (argumentsGenerators):
+ (.set shouldBe):
+ (.set new):
+ * tests/stress/array-from-with-iterator.js: Added.
+ (shouldBe):
+ (shouldThrow):
+ (createIterator.iterator.return):
+ (createIterator):
+ (.):
+
+2015-04-25 Jordan Harband <ljharb@gmail.com>
+
+ Set#keys !== Set#values
+ https://bugs.webkit.org/show_bug.cgi?id=144190
+
+ Reviewed by Darin Adler.
+
+ per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
+ Set#keys should === Set#values
+
+ * runtime/SetPrototype.cpp:
+ (JSC::SetPrototype::finishCreation):
+ (JSC::setProtoFuncValues):
+ (JSC::setProtoFuncEntries):
+ (JSC::setProtoFuncKeys): Deleted.
+
+2015-04-25 Joseph Pecoraro <pecoraro@apple.com>
+
+ Allow for pausing a JSContext when opening a Web Inspector
+ <rdar://problem/20564788>
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::receivedSetupMessage):
+ * inspector/remote/RemoteInspectorConstants.h:
+ * inspector/remote/RemoteInspectorDebuggable.h:
+ * inspector/remote/RemoteInspectorDebuggableConnection.h:
+ * inspector/remote/RemoteInspectorDebuggableConnection.mm:
+ (Inspector::RemoteInspectorDebuggableConnection::setup):
+ On any incoming setup message, we may want to automatically
+ pause the debuggable. If requested, pause the debuggable
+ after we have setup the frontend connection.
+
+ * runtime/JSGlobalObjectDebuggable.h:
+ * runtime/JSGlobalObjectDebuggable.cpp:
+ (JSC::JSGlobalObjectDebuggable::pause):
+ Pass through to the inspector controller.
+
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::pause):
+ Enable pause on next statement.
+
+2015-04-23 Ryosuke Niwa <rniwa@webkit.org>
+
+ class methods should be non-enumerable
+ https://bugs.webkit.org/show_bug.cgi?id=143181
+
+ Reviewed by Darin Adler.
+
+ Fixed the bug by using Object.defineProperty to define methods.
+
+ This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
+ inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
+ index of zero.
+ * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
+ exactly one entry for Object.defineProperty.
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
+ constant register for the link time constant we're adding.
+ (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
+ register for the specified link time constant and notify UnlinkedCodeBlock about it.
+ (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
+ Object.defineProperty with it.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
+ non-enumerable by using emitCallDefineProperty to define them.
+ (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
+ (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
+ property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
+ (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::definePropertyFunction): Added.
+ (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
+ (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
+ returns a JSCell; e.g. Object.defineProperty.
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
+ * runtime/ObjectConstructor.h:
+
+2015-04-25 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement String.fromCodePoint
+ https://bugs.webkit.org/show_bug.cgi?id=144160
+
+ Reviewed by Darin Adler.
+
+ This patch implements String.fromCodePoint.
+ It accepts multiple code points and generates a string that consists of given code points.
+ The range [0x0000 - 0x10FFFF] is valid for code points.
+ If the given value is out of range, throw a range error.
+
+ When a 0xFFFF <= valid code point is given,
+ String.fromCodePoint generates a string that contains surrogate pairs.
+
+ * runtime/StringConstructor.cpp:
+ (JSC::stringFromCodePoint):
+ (JSC::constructWithStringConstructor):
+ * tests/stress/string-from-code-point.js: Added.
+ (shouldBe):
+ (shouldThrow):
+ (toCodePoints):
+ (passThrough):
+
+2015-04-25 Martin Robinson <mrobinson@igalia.com>
+
+ Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
+ https://bugs.webkit.org/show_bug.cgi?id=144182
+
+ Reviewed by Simon Fraser.
+
+ * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
+
+2015-04-25 Mark Lam <mark.lam@apple.com>
+
+ mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
+ https://bugs.webkit.org/show_bug.cgi?id=144152
+
+ Reviewed by Filip Pizlo.
+
+ Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
+ StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
+ OSR exits. This was overlooked in the original code.
+
+ While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
+ the Branch node, the other 3 may also trigger the same bug for other nodes.
+ To prevent this bug from manifesting with other nodes (and future ones that
+ are yet to be added to mayExits()'s "potential won't exit" set), we fix the
+ EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
+
+ Also added a test to exercise a code path that will trigger this bug with
+ the Branch node before the fix is applied.
+
+ * dfg/DFGMayExit.cpp:
+ * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
+ (inlinedFunction):
+ (foo):
+
+2015-04-24 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r183288.
+ https://bugs.webkit.org/show_bug.cgi?id=144189
+
+ Made js/sort-with-side-effecting-comparisons.html time out in
+ debug builds (Requested by ap on #webkit).
+
+ Reverted changeset:
+
+ "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
+ array."
+ https://bugs.webkit.org/show_bug.cgi?id=144013
+ http://trac.webkit.org/changeset/183288
+
+2015-04-24 Filip Pizlo <fpizlo@apple.com>
+
+ CRASH in operationCreateDirectArgumentsDuringExit()
+ https://bugs.webkit.org/show_bug.cgi?id=143962
+
+ Reviewed by Geoffrey Garen.
+
+ We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
+ recoverable so long as they are live. Therefore, OSR exit should track liveness of
+ constants instead of assuming that they are always live.
+
+ * dfg/DFGGenerationInfo.h:
+ (JSC::DFG::GenerationInfo::noticeOSRBirth):
+ (JSC::DFG::GenerationInfo::appendBirth):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
+ * dfg/DFGVariableEvent.cpp:
+ (JSC::DFG::VariableEvent::dump):
+ * dfg/DFGVariableEvent.h:
+ (JSC::DFG::VariableEvent::birth):
+ (JSC::DFG::VariableEvent::id):
+ (JSC::DFG::VariableEvent::dataFormat):
+ * dfg/DFGVariableEventStream.cpp:
+ (JSC::DFG::VariableEventStream::reconstruct):
+ * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
+ (foo):
+ (bar):
+ * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
+ (foo):
+ (bar):
+
+2015-04-24 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
+ https://bugs.webkit.org/show_bug.cgi?id=144169
+
+ Reviewed by Geoffrey Garen.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::convertInt32ForValue):
+ DoubleArray do not store NaN, they are used for holes.
+ What happened was:
+ 1) We fail to insert the NaN in the Int32 array because it is a double.
+ 2) We were converting the array to DoubleArray.
+ 3) We were trying to insert the value again. We would fail again because
+ DoubleArray does not store NaN.
+ 4) We would convert the DoubleArrayt to Contiguous Array, converting the values
+ to boxed values.
+
+ * tests/stress/int32array-transition-on-nan.js: Added.
+ The behavior is not really observable. This only test nothing crashes in those
+ cases.
+
+ (insertNaNWhileFilling):
+ (testInsertNaNWhileFilling):
+ (insertNaNAfterFilling):
+ (testInsertNaNAfterFilling):
+ (pushNaNWhileFilling):
+ (testPushNaNWhileFilling):
+
+2015-04-21 Geoffrey Garen <ggaren@apple.com>
+
+ It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
+ https://bugs.webkit.org/show_bug.cgi?id=144013
+
+ Reviewed by Mark Lam.
+
+ This patch implements Array.prototype.sort in JavaScript, removing the
+ C++ implementations. It is simpler and less error-prone to express our
+ operations in JavaScript, which provides memory safety, exception safety,
+ and recursion safety.
+
+ The performance result is mixed, but net positive in my opinion. It's
+ difficult to enumerate all the results, since we used to have so many
+ different sorting modes, and there are lots of different data patterns
+ across which you might want to measure sorting. Suffice it to say:
+
+ (*) The benchmarks we track are faster or unchanged.
+
+ (*) Sorting random input using a comparator -- which we think is
+ common -- is 3X faster.
+
+ (*) Sorting random input in a non-array object -- which jQuery does
+ -- is 4X faster.
+
+ (*) Sorting random input in a compact array of integers using a
+ trivial pattern-matchable comparator is 2X *slower*.
+
+ * builtins/Array.prototype.js:
+ (sort.min):
+ (sort.stringComparator):
+ (sort.compactSparse): Special case compaction for sparse arrays because
+ we don't want to hang when sorting new Array(BIG).
+
+ (sort.compact):
+ (sort.merge):
+ (sort.mergeSort): Use merge sort because it's a reasonably efficient
+ stable sort. We have evidence that some sites depend on stable sort,
+ even though the ES6 spec does not mandate it. (See
+ <http://trac.webkit.org/changeset/33967>.)
+
+ This is a textbook implementation of merge sort with three optimizations:
+
+ (1) Use iteration instead of recursion;
+
+ (2) Use array subscripting instead of array copying in order to
+ create logical sub-lists without creating physical sub-lists;
+
+ (3) Swap src and dst at each iteration instead of copying src into
+ dst, and only copy src into the subject array at the end if src is
+ not the subject array.
+
+ (sort.inflate):
+ (sort.comparatorSort):
+ (sort): Sort in JavaScript for the win.
+
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
+ names so we can use helper functions.
+
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::isNumericCompareFunction): Deleted.
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
+ (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::FunctionNode::emitBytecode): We don't do this special casing based
+ on pattern matching anymore. This was mainly an optimization to avoid
+ the overhead of calling from C++ to JS, which we now avoid by
+ sorting in JS.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::markRoots):
+ (JSC::Heap::pushTempSortVector): Deleted.
+ (JSC::Heap::popTempSortVector): Deleted.
+ (JSC::Heap::visitTempSortVectors): Deleted.
+ * heap/Heap.h: We don't have temp sort vectors anymore because we sort
+ in JavaScript using a normal JavaScript array for our temporary storage.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
+ helper functions.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::isNumericCompareFunction): Deleted.
+ (JSC::attemptFastSort): Deleted.
+ (JSC::performSlowSort): Deleted.
+ (JSC::arrayProtoFuncSort): Deleted.
+
+ * runtime/CommonIdentifiers.h: New strings used by sort.
+
+ * runtime/JSArray.cpp:
+ (JSC::compareNumbersForQSortWithInt32): Deleted.
+ (JSC::compareNumbersForQSortWithDouble): Deleted.
+ (JSC::compareNumbersForQSort): Deleted.
+ (JSC::compareByStringPairForQSort): Deleted.
+ (JSC::JSArray::sortNumericVector): Deleted.
+ (JSC::JSArray::sortNumeric): Deleted.
+ (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
+ (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
+ (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
+ (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
+ (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
+ (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
+ (JSC::JSArray::sortCompactedVector): Deleted.
+ (JSC::JSArray::sort): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
+ (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
+ (JSC::JSArray::sortVector): Deleted.
+ (JSC::JSArray::compactForSorting): Deleted.
+ * runtime/JSArray.h:
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructor::finishCreation): Provide some builtins used
+ by sort.
+
+2015-04-24 Matthew Mirman <mmirman@apple.com>
+
+ 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-23 Benjamin Poulain <bpoulain@apple.com>
+
+ Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
+ https://bugs.webkit.org/show_bug.cgi?id=144118
+
+ Reviewed by Geoffrey Garen.
+
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::addShouldSpeculateMachineInt):
+ Both block do the same thing.
+
+2015-04-23 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Speculative fix for non-main thread auto-attach failures
+ https://bugs.webkit.org/show_bug.cgi?id=144134
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::singleton):
+
+2015-04-23 Basile Clement <basile_clement@apple.com>
+
+ Allow function allocation sinking
+ https://bugs.webkit.org/show_bug.cgi?id=144016
+
+ Reviewed by Filip Pizlo.
+
+ This adds the ability to sink function allocations in the
+ DFGObjectAllocationSinkingPhase.
+
+ In order to enable this, we add a new PhantomNewFunction node that is
+ used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
+ a sunk NewFunction and keep track of the allocations that have to be performed
+ in case of OSR exit after the sunk allocation but before the real one.
+ The FunctionExecutable and JSLexicalEnvironment (activation) of the function
+ are stored onto the PhantomNewFunction through PutHints in order for them
+ to be recovered on OSR exit.
+
+ Contrary to sunk object allocations, sunk function allocations do not
+ support any kind of operations (e.g. storing into a field) ; any such operation
+ will mark the function allocation as escaping and trigger materialization. As
+ such, function allocations can only be sunk to places where it would have been
+ correct to syntactically move them, and we don't need a special
+ MaterializeNewFunction node to recover possible operations on the function. A
+ sunk NewFunction node will simply create new NewFunction nodes, then replace
+ itself with a PhantomNewFunction node.
+
+ In itself, this change is not expected to have a significant impact on
+ performances other than in degenerate cases (see e.g.
+ JSRegress/sink-function), but it is a step towards being able to sink recursive
+ closures onces we support CreateActivation sinking as well as allocation cycles
+ sinking.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToPhantomNewFunction):
+ (JSC::DFG::Node::isPhantomAllocation):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
+ (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGPromotedHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGPromotedHeapLocation.h:
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateCPS):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+ * tests/stress/function-sinking-no-double-allocate.js: Added.
+ (call):
+ (.f):
+ (sink):
+ * tests/stress/function-sinking-osrexit.js: Added.
+ (.g):
+ (sink):
+ * tests/stress/function-sinking-put.js: Added.
+ (.g):
+ (sink):
+
+2015-04-23 Basile Clement <basile_clement@apple.com>
+
+ Make FunctionRareData allocation thread-safe
+ https://bugs.webkit.org/show_bug.cgi?id=144001
+
+ Reviewed by Mark Lam.
+
+ The two things we want to prevent are:
+
+ 1. A thread seeing a pointer to a not-yet-fully-created rare data from
+ a JSFunction
+ 2. A thread seeing a pointer to a not-yet-fully-created Structure from
+ an ObjectAllocationProfile
+
+ For 1., only the JS thread can be creating the rare data (in
+ runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
+ worry about concurrent writes, and we don't need any fences when *reading* the
+ rare data from the JS thread. Thus we only need a storeStoreFence between the
+ rare data creation and assignment to m_rareData in
+ JSFunction::createAndInitializeRareData() to ensure that when the store to
+ m_rareData is issued, the rare data has been properly created.
+
+ For the DFG compilation threads, the only place they can access the
+ rare data is through JSFunction::rareData(), and so we only need a
+ loadLoadFence there to ensure that when we see a non-null pointer in
+ m_rareData, the pointed object will be seen as a fully created
+ FunctionRareData.
+
+
+ For 2., the structure is created in
+ ObjectAllocationProfile::initialize() (which appears to be called only by the
+ JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
+ which always happen in the JS thread), and read through
+ ObjectAllocationProfile::structure() and
+ ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
+ put a storeStoreFence in ObjectAllocationProfile::initialize() and a
+ loadLoadFence in ObjectAllocationProfile::structure() (and change
+ ObjectAllocationProfile::inlineCapacity() to go through
+ ObjectAllocationProfile::structure()).
+
+ We don't need a fence in ObjectAllocationProfile::clear() because
+ clearing the structure is already as atomic as it gets.
+
+ Finally, notice that we don't care about the ObjectAllocationProfile's
+ m_allocator as that is only used by ObjectAllocationProfile::initialize() and
+ ObjectAllocationProfile::clear() that are always run in the JS thread.
+ ObjectAllocationProfile::isNull() could cause some trouble, but it is
+ currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
+ thread. Doing isNull()-style pre-checks would be wrong in any other concurrent
+ thread anyway.
+
+ * bytecode/ObjectAllocationProfile.h:
+ (JSC::ObjectAllocationProfile::initialize):
+ (JSC::ObjectAllocationProfile::structure):
+ (JSC::ObjectAllocationProfile::inlineCapacity):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::allocateAndInitializeRareData):
+ * runtime/JSFunction.h:
+ (JSC::JSFunction::rareData):
+ (JSC::JSFunction::allocationStructure): Deleted.
+ This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
+
+2015-04-22 Filip Pizlo <fpizlo@apple.com>
+
+ DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
+ https://bugs.webkit.org/show_bug.cgi?id=143735
+
+ Reviewed by Geoffrey Garen.
+
+ We've always had bugs arising from the fact that we would MovHint something into a local,
+ and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
+ on those Nodes that were MovHinted. But this became increasingly tricky. Given the
+ sophistication of the transformations we are doing today, this approach is just not sound
+ anymore.
+
+ This comprehensively fixes these bugs by having the DFG backend automatically insert
+ Phantoms just before codegen based on bytecode liveness. To make this practical, this also
+ makes it much faster to query bytecode liveness.
+
+ It's about as perf-neutral as it gets for a change that increases compiler work without
+ actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
+ which should then speed us up. I can't really report concrete slow-down numbers because
+ they are low enough to basically be in the noise. For example, a 20-iteration run of
+ SunSpider yields "maybe 0.8% slower", whatever that means.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/BytecodeLivenessAnalysis.cpp:
+ (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
+ * bytecode/FullBytecodeLiveness.h:
+ (JSC::FullBytecodeLiveness::getLiveness):
+ * bytecode/VirtualRegister.h:
+ (JSC::VirtualRegister::operator+):
+ (JSC::VirtualRegister::operator-):
+ * dfg/DFGForAllKills.h:
+ (JSC::DFG::forAllLiveNodesAtTail):
+ (JSC::DFG::forAllKilledOperands):
+ (JSC::DFG::forAllKilledNodesAtNodeIndex):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::isLiveInBytecode):
+ (JSC::DFG::Graph::localsLiveInBytecode):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
+ (JSC::DFG::Graph::forAllLiveInBytecode):
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGMovHintRemovalPhase.cpp:
+ * dfg/DFGNodeType.h:
+ * dfg/DFGPhantomInsertionPhase.cpp: Added.
+ (JSC::DFG::performPhantomInsertion):
+ * dfg/DFGPhantomInsertionPhase.h: Added.
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGScoreBoard.h:
+ (JSC::DFG::ScoreBoard::sortFree):
+ (JSC::DFG::ScoreBoard::assertClear):
+ * dfg/DFGVirtualRegisterAllocationPhase.cpp:
+ (JSC::DFG::VirtualRegisterAllocationPhase::run):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+ * tests/stress/phantom-inadequacy.js: Added.
+ (bar):
+ (baz):
+ (foo):
+
+2015-04-23 Filip Pizlo <fpizlo@apple.com>
+
+ Rename HardPhantom to MustGenerate.
+
+ Rubber stamped by Geoffrey Garen.
+
+ We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
+ is more than that; it's a utility for forcing the execution of otherwise killable nodes.
+ NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
+ node should just be called MustGenerate.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDCEPhase.cpp:
+ (JSC::DFG::DCEPhase::run):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
+ * dfg/DFGIntegerCheckCombiningPhase.cpp:
+ (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::willHaveCodeGenOrOSR):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPhantomCanonicalizationPhase.cpp:
+ (JSC::DFG::PhantomCanonicalizationPhase::run):
+ * dfg/DFGPhantomRemovalPhase.cpp:
+ (JSC::DFG::PhantomRemovalPhase::run):
+ * 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/DFGTypeCheckHoistingPhase.cpp:
+ (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
+ (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
+ * dfg/DFGVarargsForwardingPhase.cpp:
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+
+2015-04-23 Jordan Harband <ljharb@gmail.com>
+
+ Implement `Object.assign`
+ https://bugs.webkit.org/show_bug.cgi?id=143980
+
+ Reviewed by Filip Pizlo.
+
+ per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
+
+ * builtins/ObjectConstructor.js: Added.
+ (assign):
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/ObjectConstructor.cpp:
+ * runtime/ObjectConstructor.h:
+
+2015-04-22 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix debug build.
+
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::performSubstitutionForEdge):
+
+2015-04-22 Filip Pizlo <fpizlo@apple.com>
+
+ Nodes should have an optional epoch field
+ https://bugs.webkit.org/show_bug.cgi?id=144084
+
+ Reviewed by Ryosuke Niwa and Mark Lam.
+
+ This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
+ https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
+ used.
+
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
+ * dfg/DFGCSEPhase.cpp:
+ * dfg/DFGEpoch.h:
+ (JSC::DFG::Epoch::fromUnsigned):
+ (JSC::DFG::Epoch::toUnsigned):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::clearReplacements):
+ (JSC::DFG::Graph::clearEpochs):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::performSubstitutionForEdge):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::Node):
+ (JSC::DFG::Node::replaceWith):
+ (JSC::DFG::Node::replacement):
+ (JSC::DFG::Node::setReplacement):
+ (JSC::DFG::Node::epoch):
+ (JSC::DFG::Node::setEpoch):
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+
+2015-04-22 Mark Lam <mark.lam@apple.com>
+
+ Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
+ https://bugs.webkit.org/show_bug.cgi?id=143898
+
+ Reviewed by Filip Pizlo.
+
+ CodeBlock::dumpSource() will access SourceCode strings in a way that requires
+ ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
+ compilation threads because StringImpls are not thread safe. As a result, we get
+ an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
+ build.
+
+ This patch fixes the issue by only collecting the CodeBlock (and associated info)
+ into a DeferredSourceDump record while compiling, and stashing it away in a
+ deferredSourceDump list in the DeferredCompilationCallback object to be dumped
+ later.
+
+ When compilation is done, the callback object will be notified that
+ compilationDidComplete(). We will dump the SourceCode strings from there.
+ Since compilationDidComplete() is guaranteed to only be called on the thread
+ doing JS execution, it is safe to access the SourceCode strings there and ref
+ their underlying StringImpls as needed.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/DeferredCompilationCallback.cpp:
+ (JSC::DeferredCompilationCallback::compilationDidComplete):
+ (JSC::DeferredCompilationCallback::sourceDumpInfo):
+ (JSC::DeferredCompilationCallback::dumpCompiledSources):
+ * bytecode/DeferredCompilationCallback.h:
+ * bytecode/DeferredSourceDump.cpp: Added.
+ (JSC::DeferredSourceDump::DeferredSourceDump):
+ (JSC::DeferredSourceDump::dump):
+ * bytecode/DeferredSourceDump.h: Added.
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseCodeBlock):
+ * dfg/DFGDriver.cpp:
+ (JSC::DFG::compileImpl):
+
+2015-04-22 Benjamin Poulain <benjamin@webkit.org>
+
+ Implement String.codePointAt()
+ https://bugs.webkit.org/show_bug.cgi?id=143934
+
+ Reviewed by Darin Adler.
+
+ This patch adds String.codePointAt() as defined by ES6.
+ I opted for a C++ implementation for now.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::StringPrototype::finishCreation):
+ (JSC::codePointAt):
+ (JSC::stringProtoFuncCodePointAt):
+
+2015-04-22 Mark Lam <mark.lam@apple.com>
+
+ SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
+ https://bugs.webkit.org/show_bug.cgi?id=144067
+
+ Reviewed by Michael Saboff.
+
+ Currently, there are a few places where the JSObject that owns the
+ SparseArrayValueMap is designated as the owner of the SparseArrayEntry
+ write barrier. This is a bug and can result in the GC collecting the
+ SparseArrayEntry even though it is being referenced by the
+ SparseArrayValueMap. This patch fixes the bug.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
+ (JSC::JSObject::putIndexedDescriptor):
+ * tests/stress/sparse-array-entry-update-144067.js: Added.
+ (useMemoryToTriggerGCs):
+ (foo):
+
+2015-04-22 Mark Lam <mark.lam@apple.com>
+
+ Give the heap object iterators the ability to return early.
+ https://bugs.webkit.org/show_bug.cgi?id=144011
+
+ Reviewed by Michael Saboff.
+
+ JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
+ candidate cell pointers, and, when in use, is called a lot more often than
+ the normal way those iterators are used. As a result, I see my instrumented
+ VM killed with a SIGXCPU (CPU time limit exceeded). This patch gives the
+ callback functor the ability to tell the iterators to return early when the
+ functor no longer needs to continue iterating. With this, my instrumented
+ VM is useful again for debugging.
+
+ Since heap iteration is not something that we do in a typical fast path,
+ I don't expect this to have any noticeable impact on performance.
+
+ I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
+ it checks JSCell addresses, not just JSObjects.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * debugger/Debugger.cpp:
+ * heap/GCLogging.cpp:
+ (JSC::LoggingFunctor::operator()):
+ * heap/Heap.cpp:
+ (JSC::Zombify::visit):
+ (JSC::Zombify::operator()):
+ * heap/HeapStatistics.cpp:
+ (JSC::StorageStatistics::visit):
+ (JSC::StorageStatistics::operator()):
+ * heap/HeapVerifier.cpp:
+ (JSC::GatherLiveObjFunctor::visit):
+ (JSC::GatherLiveObjFunctor::operator()):
+ * heap/MarkedBlock.cpp:
+ (JSC::SetNewlyAllocatedFunctor::operator()):
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::forEachCell):
+ (JSC::MarkedBlock::forEachLiveCell):
+ (JSC::MarkedBlock::forEachDeadCell):
+ * heap/MarkedSpace.h:
+ (JSC::MarkedSpace::forEachLiveCell):
+ (JSC::MarkedSpace::forEachDeadCell):
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::TypeRecompiler::visit):
+ (Inspector::TypeRecompiler::operator()):
+ * runtime/IterationStatus.h: Added.
+ * runtime/JSGlobalObject.cpp:
+ * runtime/VM.cpp:
+ (JSC::StackPreservingRecompiler::visit):
+ (JSC::StackPreservingRecompiler::operator()):
+ * tools/JSDollarVMPrototype.cpp:
+ (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
+ (JSC::CellAddressCheckFunctor::operator()):
+ (JSC::JSDollarVMPrototype::isValidCell):
+ (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
+ (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
+
+2015-04-22 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [[Set]] should be properly executed in JS builtins
+ https://bugs.webkit.org/show_bug.cgi?id=143996
+
+ Reviewed by Geoffrey Garen.
+
+ Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
+ However,
+
+ 1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
+ 2. It's different from the default JS behavior.
+
+ In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
+ And dropping the current hack for builtins.
+
+ * builtins/Array.prototype.js:
+ (filter):
+ (map):
+ (find):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitPutByVal):
+ * tests/stress/array-fill-put-by-val.js: Added.
+ (shouldThrow):
+ (.set get array):
+ * tests/stress/array-filter-put-by-val-direct.js: Added.
+ (shouldBe):
+ (.set get var):
+ * tests/stress/array-find-does-not-lookup-twice.js: Added.
+ (shouldBe):
+ (shouldThrow):
+ (.get shouldBe):
+ * tests/stress/array-from-put-by-val-direct.js: Added.
+ (shouldBe):
+ (.set get var):
+ * tests/stress/array-from-set-length.js: Added.
+ (shouldBe):
+ (ArrayLike):
+ (ArrayLike.prototype.set length):
+ (ArrayLike.prototype.get length):
+ * tests/stress/array-map-put-by-val-direct.js: Added.
+ (shouldBe):
+ (.set get var):
+
+2015-04-22 Basile Clement <basile_clement@apple.com>
+
+ Don't de-allocate FunctionRareData
+ https://bugs.webkit.org/show_bug.cgi?id=144000
+
+ Reviewed by Michael Saboff.
+
+ A function rare data (containing most notably its allocation profile) is currently
+ freed and re-allocated each time the function's prototype is cleared.
+ This is not optimal as it means we are invalidating the watchpoint and recompiling the
+ scope each time the prototype is cleared.
+
+ This makes it so that a single rare data is reused, clearing the underlying
+ ObjectAllocationProfile instead of throwing away the whole rare data on
+ .prototype updates.
+
+ * runtime/FunctionRareData.cpp:
+ (JSC::FunctionRareData::create):
+ (JSC::FunctionRareData::finishCreation):
+ * runtime/FunctionRareData.h:
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::allocateAndInitializeRareData):
+ (JSC::JSFunction::initializeRareData):
+
+2015-04-21 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+
+2015-04-21 Filip Pizlo <fpizlo@apple.com>
+
+ DFG should allow Phantoms after terminals
+ https://bugs.webkit.org/show_bug.cgi?id=126778
+
+ Reviewed by Mark Lam.
+
+ It's important for us to be able to place liveness-marking nodes after nodes that do
+ things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
+ terminals. That made things awkward, especially for Switch and Branch, which may do
+ things that necessitate liveness markers (for example they might want to use a converted
+ version of a value rather than the value that was MovHinted). We previously made this
+ work by disallowing certain optimizations on Switch and Branch, which was probably a bad
+ thing.
+
+ This changes our IR to allow for the terminal to not be the last node in a block. Asking
+ for the terminal involves a search. DFG::validate() checks that the nodes after the
+ terminal are liveness markers that have no effects or checks.
+
+ This is perf-neutral but will allow more optimizations in the future. It will also make
+ it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
+
+ * dfg/DFGBasicBlock.cpp:
+ (JSC::DFG::BasicBlock::replaceTerminal):
+ * dfg/DFGBasicBlock.h:
+ (JSC::DFG::BasicBlock::findTerminal):
+ (JSC::DFG::BasicBlock::terminal):
+ (JSC::DFG::BasicBlock::insertBeforeTerminal):
+ (JSC::DFG::BasicBlock::numSuccessors):
+ (JSC::DFG::BasicBlock::successor):
+ (JSC::DFG::BasicBlock::successorForCondition):
+ (JSC::DFG::BasicBlock::successors):
+ (JSC::DFG::BasicBlock::last): Deleted.
+ (JSC::DFG::BasicBlock::takeLast): Deleted.
+ (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
+ (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
+ * dfg/DFGBasicBlockInlines.h:
+ (JSC::DFG::BasicBlock::appendNonTerminal):
+ (JSC::DFG::BasicBlock::replaceTerminal):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::addToGraph):
+ (JSC::DFG::ByteCodeParser::inlineCall):
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::linkBlock):
+ (JSC::DFG::ByteCodeParser::parseCodeBlock):
+ * dfg/DFGCFGSimplificationPhase.cpp:
+ (JSC::DFG::CFGSimplificationPhase::run):
+ (JSC::DFG::CFGSimplificationPhase::convertToJump):
+ (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
+ * dfg/DFGCommon.h:
+ (JSC::DFG::NodeAndIndex::NodeAndIndex):
+ (JSC::DFG::NodeAndIndex::operator!):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupBlock):
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
+ (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
+ * dfg/DFGForAllKills.h:
+ (JSC::DFG::forAllLiveNodesAtTail):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::terminalsAreValid):
+ (JSC::DFG::Graph::dumpBlockHeader):
+ * dfg/DFGGraph.h:
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
+ * dfg/DFGLICMPhase.cpp:
+ (JSC::DFG::LICMPhase::run):
+ (JSC::DFG::LICMPhase::attemptHoist):
+ * dfg/DFGMovHintRemovalPhase.cpp:
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
+ (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
+ (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
+ (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
+ (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
+ (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
+ (JSC::DFG::Node::SuccessorsIterable::begin):
+ (JSC::DFG::Node::SuccessorsIterable::end):
+ (JSC::DFG::Node::successors):
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
+ (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
+ (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
+ * dfg/DFGPhantomRemovalPhase.cpp:
+ (JSC::DFG::PhantomRemovalPhase::run):
+ * dfg/DFGPutStackSinkingPhase.cpp:
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
+ (JSC::DFG::StaticExecutionCountEstimationPhase::run):
+ * dfg/DFGTierUpCheckInjectionPhase.cpp:
+ (JSC::DFG::TierUpCheckInjectionPhase::run):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validate):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ * tests/stress/closure-call-exit.js: Added.
+ (foo):
+
+2015-04-21 Basile Clement <basile_clement@apple.com>
+
+ PhantomNewObject should be marked NodeMustGenerate
+ https://bugs.webkit.org/show_bug.cgi?id=143974
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToPhantomNewObject):
+ Was not properly marking NodeMustGenerate when converting.
+
+2015-04-21 Filip Pizlo <fpizlo@apple.com>
+
+ DFG Call/ConstructForwardVarargs fails to restore the stack pointer
+ https://bugs.webkit.org/show_bug.cgi?id=144007
+
+ Reviewed by Mark Lam.
+
+ We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
+ if isForwardVarargs.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * tests/stress/varargs-then-slow-call.js: Added.
+ (foo):
+ (bar):
+ (fuzz):
+ (baz):
+
+2015-04-21 Basile Clement <basile_clement@apple.com>
+
+ Remove AllocationProfileWatchpoint node
+ https://bugs.webkit.org/show_bug.cgi?id=143999
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGHeapLocation.h:
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasCellOperand):
+ * 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):
+ * runtime/JSFunction.h:
+ (JSC::JSFunction::rareData):
+ (JSC::JSFunction::allocationProfileWatchpointSet): Deleted.
+
+2015-04-19 Filip Pizlo <fpizlo@apple.com>
+
+ MovHint should be a strong use
+ https://bugs.webkit.org/show_bug.cgi?id=143734
+
+ Reviewed by Geoffrey Garen.
+
+ This disables any DCE that assumes equivalence between DFG IR uses and bytecode uses. Doing
+ so is a major step towards allowing more fancy DFG transformations and also probably fixing
+ some bugs.
+
+ Just making MovHint a strong use would also completely disable DCE. So we mitigate this by
+ introducing a MovHint removal phase that runs in FTL.
+
+ This is a slight slowdown on Octane/gbemu, but it's basically neutral on suite averages.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CodeOrigin.cpp:
+ (JSC::InlineCallFrame::dumpInContext):
+ * dfg/DFGDCEPhase.cpp:
+ (JSC::DFG::DCEPhase::fixupBlock):
+ * dfg/DFGDisassembler.cpp:
+ (JSC::DFG::Disassembler::createDumpList):
+ * dfg/DFGEpoch.cpp: Added.
+ (JSC::DFG::Epoch::dump):
+ * dfg/DFGEpoch.h: Added.
+ (JSC::DFG::Epoch::Epoch):
+ (JSC::DFG::Epoch::first):
+ (JSC::DFG::Epoch::operator!):
+ (JSC::DFG::Epoch::next):
+ (JSC::DFG::Epoch::bump):
+ (JSC::DFG::Epoch::operator==):
+ (JSC::DFG::Epoch::operator!=):
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGMovHintRemovalPhase.cpp: Added.
+ (JSC::DFG::performMovHintRemoval):
+ * dfg/DFGMovHintRemovalPhase.h: Added.
+ * dfg/DFGNodeType.h:
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * runtime/Options.h:
+
+2015-04-21 Basile Clement <basile_clement@apple.com>
+
+ REGRESSION (r182899): icloud.com crashes
+ https://bugs.webkit.org/show_bug.cgi?id=143960
+
+ Reviewed by Filip Pizlo.
+
+ * runtime/JSFunction.h:
+ (JSC::JSFunction::allocationStructure):
+ * tests/stress/dfg-rare-data.js: Added.
+ (F): Regression test
+
+2015-04-21 Michael Saboff <msaboff@apple.com>
+
+ Crash in JSC::Interpreter::execute
+ https://bugs.webkit.org/show_bug.cgi?id=142625
+
+ Reviewed by Filip Pizlo.
+
+ We need to keep the FunctionExecutables in the code block for the eval flavor of
+ Interpreter::execute() in order to create the scope used to eval.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::jettisonFunctionDeclsAndExprs): Deleted.
+ * bytecode/CodeBlock.h:
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::registerFrozenValues):
+
+2015-04-21 Chris Dumez <cdumez@apple.com>
+
+ Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&) constructor explicit
+ https://bugs.webkit.org/show_bug.cgi?id=143970
+
+ Reviewed by Darin Adler.
+
+ Make Vector(const Vector<T, otherCapacity, otherOverflowBehaviour>&)
+ constructor explicit as it copies the vector and it is easy to call it
+ by mistake.
+
+ * bytecode/UnlinkedInstructionStream.cpp:
+ (JSC::UnlinkedInstructionStream::UnlinkedInstructionStream):
+ * bytecode/UnlinkedInstructionStream.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+
+2015-04-20 Basile Clement <basile_clement@apple.com>
+
+ PhantomNewObject should be marked NodeMustGenerate
+ https://bugs.webkit.org/show_bug.cgi?id=143974
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGNodeType.h: Mark PhantomNewObject as NodeMustGenerate
+
+2015-04-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Cleanup some StringBuilder use
+ https://bugs.webkit.org/show_bug.cgi?id=143550
+
+ Reviewed by Darin Adler.
+
+ * runtime/Symbol.cpp:
+ (JSC::Symbol::descriptiveString):
+ * runtime/TypeProfiler.cpp:
+ (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::toJSONString):
+ (JSC::StructureShape::propertyHash):
+ (JSC::StructureShape::stringRepresentation):
+ (JSC::StructureShape::toJSONString):
+
+2015-04-20 Mark Lam <mark.lam@apple.com>
+
+ Add debugging tools to test if a given pointer is a valid object and in the heap.
+ https://bugs.webkit.org/show_bug.cgi?id=143910
+
+ Reviewed by Geoffrey Garen.
+
+ When doing debugging from lldb, sometimes, it is useful to be able to tell if a
+ purported JSObject is really a valid object in the heap or not. We can add the
+ following utility functions to help:
+ isValidCell(heap, candidate) - returns true if the candidate is a "live" cell in the heap.
+ isInHeap(heap, candidate) - returns true if the candidate is the heap's Object space or Storage space.
+ isInObjectSpace(heap, candidate) - returns true if the candidate is the heap's Object space.
+ isInStorageSpace(heap, candidate) - returns true if the candidate is the heap's Storage space.
+
+ Also moved lldb callable debug utility function prototypes from
+ JSDollarVMPrototype.cpp to JSDollarVMPrototype.h as static members of the
+ JSDollarVMPrototype class. This is so that we can conveniently #include that
+ file to get the prototypes when we need to call them programmatically from
+ instrumentation that we add while debugging an issue.
+
+ * heap/Heap.h:
+ (JSC::Heap::storageSpace):
+ * tools/JSDollarVMPrototype.cpp:
+ (JSC::JSDollarVMPrototype::currentThreadOwnsJSLock):
+ (JSC::ensureCurrentThreadOwnsJSLock):
+ (JSC::JSDollarVMPrototype::gc):
+ (JSC::functionGC):
+ (JSC::JSDollarVMPrototype::edenGC):
+ (JSC::functionEdenGC):
+ (JSC::JSDollarVMPrototype::isInHeap):
+ (JSC::JSDollarVMPrototype::isInObjectSpace):
+ (JSC::JSDollarVMPrototype::isInStorageSpace):
+ (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor):
+ (JSC::ObjectAddressCheckFunctor::operator()):
+ (JSC::JSDollarVMPrototype::isValidCell):
+ (JSC::JSDollarVMPrototype::isValidCodeBlock):
+ (JSC::JSDollarVMPrototype::codeBlockForFrame):
+ (JSC::functionCodeBlockForFrame):
+ (JSC::codeBlockFromArg):
+ (JSC::JSDollarVMPrototype::printCallFrame):
+ (JSC::JSDollarVMPrototype::printStack):
+ (JSC::JSDollarVMPrototype::printValue):
+ (JSC::currentThreadOwnsJSLock): Deleted.
+ (JSC::gc): Deleted.
+ (JSC::edenGC): Deleted.
+ (JSC::isValidCodeBlock): Deleted.
+ (JSC::codeBlockForFrame): Deleted.
+ (JSC::printCallFrame): Deleted.
+ (JSC::printStack): Deleted.
+ (JSC::printValue): Deleted.
+ * tools/JSDollarVMPrototype.h:
+
+2015-04-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Improve Support for WeakSet in Console
+ https://bugs.webkit.org/show_bug.cgi?id=143951
+
+ Reviewed by Darin Adler.
+
+ * inspector/InjectedScriptSource.js:
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ (Inspector::JSInjectedScriptHost::weakSetSize):
+ (Inspector::JSInjectedScriptHost::weakSetEntries):
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries):
+ Treat WeakSets like special sets.
+
+ * inspector/protocol/Runtime.json:
+ Add a new object subtype, "weakset".
+
+2015-04-20 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ HashMap storing PropertyKey StringImpl* need to use IdentifierRepHash to handle Symbols
+ https://bugs.webkit.org/show_bug.cgi?id=143947
+
+ Reviewed by Darin Adler.
+
+ Type profiler has map between PropertyKey (StringImpl*) and offset.
+ StringImpl* is also used for Symbol PropertyKey.
+ So equality of hash tables is considered by interned StringImpl*'s pointer value.
+ To do so, use IdentifierRepHash instead of StringHash.
+
+ * runtime/SymbolTable.h:
+
+2015-04-20 Jordan Harband <ljharb@gmail.com>
+
+ Implement `Object.is`
+ https://bugs.webkit.org/show_bug.cgi?id=143865
+
+ Reviewed by Darin Adler.
+
+ Expose sameValue to JS, via Object.is
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.is
+
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorIs):
+ * runtime/PropertyDescriptor.cpp:
+ (JSC::sameValue):
+
+2015-04-19 Darin Adler <darin@apple.com>
+
+ Remove all the remaining uses of OwnPtr and PassOwnPtr in JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=143941
+
+ Reviewed by Gyuyoung Kim.
+
+ * API/JSCallbackObject.h: Use unique_ptr for m_callbackObjectData.
+ * API/JSCallbackObjectFunctions.h: Ditto.
+
+ * API/ObjCCallbackFunction.h: Use unique_ptr for the arguments to the
+ create function and the constructor and for m_impl.
+ * API/ObjCCallbackFunction.mm:
+ (CallbackArgumentOfClass::CallbackArgumentOfClass): Streamline this
+ class by using RetainPtr<Class>.
+ (ArgumentTypeDelegate::typeInteger): Use make_unique.
+ (ArgumentTypeDelegate::typeDouble): Ditto.
+ (ArgumentTypeDelegate::typeBool): Ditto.
+ (ArgumentTypeDelegate::typeVoid): Ditto.
+ (ArgumentTypeDelegate::typeId): Ditto.
+ (ArgumentTypeDelegate::typeOfClass): Ditto.
+ (ArgumentTypeDelegate::typeBlock): Ditto.
+ (ArgumentTypeDelegate::typeStruct): Ditto.
+ (ResultTypeDelegate::typeInteger): Ditto.
+ (ResultTypeDelegate::typeDouble): Ditto.
+ (ResultTypeDelegate::typeBool): Ditto.
+ (ResultTypeDelegate::typeVoid): Ditto.
+ (ResultTypeDelegate::typeId): Ditto.
+ (ResultTypeDelegate::typeOfClass): Ditto.
+ (ResultTypeDelegate::typeBlock): Ditto.
+ (ResultTypeDelegate::typeStruct): Ditto.
+ (JSC::ObjCCallbackFunctionImpl::ObjCCallbackFunctionImpl): Use
+ unique_ptr for the arguments to the constructor, m_arguments, and m_result.
+ Use RetainPtr<Class> for m_instanceClass.
+ (JSC::objCCallbackFunctionCallAsConstructor): Use nullptr instead of nil or 0
+ for non-Objective-C object pointer null.
+ (JSC::ObjCCallbackFunction::ObjCCallbackFunction): Use unique_ptr for
+ the arguments to the constructor and for m_impl.
+ (JSC::ObjCCallbackFunction::create): Use unique_ptr for arguments.
+ (skipNumber): Mark this static since it's local to this source file.
+ (objCCallbackFunctionForInvocation): Call parseObjCType without doing any
+ explicit adoptPtr since the types in the traits are now unique_ptr. Also use
+ nullptr instead of nil for JSObjectRef values.
+ (objCCallbackFunctionForMethod): Tweaked comment.
+ (objCCallbackFunctionForBlock): Use nullptr instead of 0 for JSObjectRef.
+
+ * bytecode/CallLinkInfo.h: Removed unneeded include of OwnPtr.h.
+
+ * heap/GCThread.cpp:
+ (JSC::GCThread::GCThread): Use unique_ptr.
+ * heap/GCThread.h: Use unique_ptr for arguments to the constructor and for
+ m_slotVisitor and m_copyVisitor.
+ * heap/GCThreadSharedData.cpp:
+ (JSC::GCThreadSharedData::GCThreadSharedData): Ditto.
+
+ * parser/SourceProvider.h: Removed unneeded include of PassOwnPtr.h.
+
+2015-04-19 Benjamin Poulain <benjamin@webkit.org>
+
+ Improve the feature.json files
+
+ * features.json:
+
+2015-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Introduce bytecode intrinsics
+ https://bugs.webkit.org/show_bug.cgi?id=143926
+
+ Reviewed by Filip Pizlo.
+
+ This patch introduces bytecode level intrinsics into builtins/*.js JS code.
+ When implementing functions in builtins/*.js,
+ sometimes we require lower level functionality.
+
+ For example, in the current Array.from, we use `result[k] = value`.
+ The spec requires `[[DefineOwnProperty]]` operation here.
+ However, usual `result[k] = value` is evaluated as `[[Set]]`. (`PutValue` => `[[Set]]`)
+ So if we implement `Array.prototype[k]` getter/setter, the difference is observable.
+
+ Ideally, reaching here, we would like to use put_by_val_direct bytecode.
+ However, there's no syntax to generate it directly.
+
+ This patch introduces bytecode level intrinsics into JSC BytecodeCompiler.
+ Like @call, @apply, we introduce a new node, Intrinsic.
+ These are generated when calling appropriate private symbols in privileged code.
+ AST parser detects them and generates Intrinsic nodes and
+ BytecodeCompiler detects them and generate required bytecodes.
+
+ Currently, Array.from implementation works fine without this patch.
+ This is because when the target code is builtin JS,
+ BytecodeGenerator emits put_by_val_direct instead of put_by_val.
+ This solves the above issue. However, instead of solving this issue,
+ it raises another issue; There's no way to emit `[[Set]]` operation.
+ `[[Set]]` operation is actually used in the spec (Array.from's "length" is set by `[[Set]]`).
+ So to implement it precisely, introducing bytecode level intrinsics is necessary.
+
+ In the subsequent fixes, we'll remove that special path emitting put_by_val_direct
+ for `result[k] = value` under builtin JS environment. Instead of that special handling,
+ use bytecode intrinsics instead. It solves problems and it is more intuitive
+ because written JS code in builtin works as the same to the usual JS code.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * builtins/ArrayConstructor.js:
+ (from):
+ * bytecode/BytecodeIntrinsicRegistry.cpp: Added.
+ (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
+ (JSC::BytecodeIntrinsicRegistry::lookup):
+ * bytecode/BytecodeIntrinsicRegistry.h: Added.
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BytecodeIntrinsicNode::emitBytecode):
+ (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::makeFunctionCallNode):
+ * parser/NodeConstructors.h:
+ (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
+ * parser/Nodes.h:
+ (JSC::BytecodeIntrinsicNode::identifier):
+ * runtime/CommonIdentifiers.cpp:
+ (JSC::CommonIdentifiers::CommonIdentifiers):
+ * runtime/CommonIdentifiers.h:
+ (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry):
+ * tests/stress/array-from-with-accessors.js: Added.
+ (shouldBe):
+
+2015-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Make Builtin functions non constructible
+ https://bugs.webkit.org/show_bug.cgi?id=143923
+
+ Reviewed by Darin Adler.
+
+ Builtin functions defined by builtins/*.js accidentally have [[Construct]].
+ According to the spec, these functions except for explicitly defined as a constructor do not have [[Construct]].
+ This patch fixes it. When the JS function used for a construction is builtin function, throw not a constructor error.
+
+ Ideally, returning ConstructTypeNone in JSFunction::getConstructData is enough.
+ However, to avoid calling getConstructData (it involves indirect call of function pointer of getConstructData), some places do not check ConstructType.
+ In these places, they only check the target function is JSFunction because previously JSFunction always has [[Construct]].
+ So in this patch, we check `isBuiltinFunction()` in those places.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::inliningCost):
+ * jit/JITOperations.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::setUpCall):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::getConstructData):
+ * tests/stress/builtin-function-is-construct-type-none.js: Added.
+ (shouldThrow):
+
+2015-04-19 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement WeakSet
+ https://bugs.webkit.org/show_bug.cgi?id=142408
+
+ Reviewed by Darin Adler.
+
+ This patch implements ES6 WeakSet.
+ Current implementation simply leverages WeakMapData with undefined value.
+ This WeakMapData should be optimized in the same manner as MapData/SetData in the subsequent patch[1].
+
+ And in this patch, we also fix WeakMap/WeakSet behavior to conform the ES6 spec.
+ Except for adders (WeakMap.prototype.set/WeakSet.prototype.add),
+ methods return false (or undefined for WeakMap.prototype.get)
+ when a key is not Object instead of throwing a type error.
+
+ [1]: https://bugs.webkit.org/show_bug.cgi?id=143919
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ * runtime/JSGlobalObject.h:
+ * runtime/JSWeakSet.cpp: Added.
+ (JSC::JSWeakSet::finishCreation):
+ (JSC::JSWeakSet::visitChildren):
+ * runtime/JSWeakSet.h: Added.
+ (JSC::JSWeakSet::createStructure):
+ (JSC::JSWeakSet::create):
+ (JSC::JSWeakSet::weakMapData):
+ (JSC::JSWeakSet::JSWeakSet):
+ * runtime/WeakMapPrototype.cpp:
+ (JSC::getWeakMapData):
+ (JSC::protoFuncWeakMapDelete):
+ (JSC::protoFuncWeakMapGet):
+ (JSC::protoFuncWeakMapHas):
+ * runtime/WeakSetConstructor.cpp: Added.
+ (JSC::WeakSetConstructor::finishCreation):
+ (JSC::callWeakSet):
+ (JSC::constructWeakSet):
+ (JSC::WeakSetConstructor::getConstructData):
+ (JSC::WeakSetConstructor::getCallData):
+ * runtime/WeakSetConstructor.h: Added.
+ (JSC::WeakSetConstructor::create):
+ (JSC::WeakSetConstructor::createStructure):
+ (JSC::WeakSetConstructor::WeakSetConstructor):
+ * runtime/WeakSetPrototype.cpp: Added.
+ (JSC::WeakSetPrototype::finishCreation):
+ (JSC::getWeakMapData):
+ (JSC::protoFuncWeakSetDelete):
+ (JSC::protoFuncWeakSetHas):
+ (JSC::protoFuncWeakSetAdd):
+ * runtime/WeakSetPrototype.h: Added.
+ (JSC::WeakSetPrototype::create):
+ (JSC::WeakSetPrototype::createStructure):
+ (JSC::WeakSetPrototype::WeakSetPrototype):
+ * tests/stress/weak-set-constructor-adder.js: Added.
+ (WeakSet.prototype.add):
+ * tests/stress/weak-set-constructor.js: Added.
+
+2015-04-17 Alexey Proskuryakov <ap@apple.com>
+
+ Remove unused BoundsCheckedPointer
+ https://bugs.webkit.org/show_bug.cgi?id=143896
+
+ Reviewed by Geoffrey Garen.
+
+ * bytecode/SpeculatedType.cpp: The header was included here.
+
+2015-04-17 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Fix name enumeration of static functions for Symbol constructor
+ https://bugs.webkit.org/show_bug.cgi?id=143891
+
+ Reviewed by Geoffrey Garen.
+
+ Fix missing symbolPrototypeTable registration to the js class object.
+ This patch fixes name enumeration of static functions (Symbol.key, Symbol.keyFor) for Symbol constructor.
+
+ * runtime/SymbolConstructor.cpp:
+
+2015-04-17 Basile Clement <basile_clement@apple.com>
+
+ Inline JSFunction allocation in DFG
+ https://bugs.webkit.org/show_bug.cgi?id=143858
+
+ Reviewed by Filip Pizlo.
+
+ Followup to my previous patch which inlines JSFunction allocation when
+ using FTL, now also enabled in DFG.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileNewFunction):
+
+2015-04-16 Jordan Harband <ljharb@gmail.com>
+
+ Number.parseInt is not === global parseInt in nightly r182673
+ https://bugs.webkit.org/show_bug.cgi?id=143799
+
+ Reviewed by Darin Adler.
+
+ Ensuring parseInt === Number.parseInt, per spec
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
+
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::parseIntFunction):
+ * runtime/NumberConstructor.cpp:
+ (JSC::NumberConstructor::finishCreation):
+
+2015-04-16 Mark Lam <mark.lam@apple.com>
+
+ Gardening: fix CLOOP build after r182927.
+
+ Not reviewed.
+
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::print):
+
+2015-04-16 Basile Clement <basile_clement@apple.com>
+
+ Inline JSFunction allocation in FTL
+ https://bugs.webkit.org/show_bug.cgi?id=143851
+
+ Reviewed by Filip Pizlo.
+
+ JSFunction allocation is a simple operation that should be inlined when possible.
+
+ * ftl/FTLAbstractHeapRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
+ * runtime/JSFunction.h:
+ (JSC::JSFunction::allocationSize):
+
+2015-04-16 Mark Lam <mark.lam@apple.com>
+
+ Add $vm debugging tool.
+ https://bugs.webkit.org/show_bug.cgi?id=143809
+
+ Reviewed by Geoffrey Garen.
+
+ For debugging VM bugs, it would be useful to be able to dump VM data structures
+ from JS code that we instrument. To this end, let's introduce a
+ JS_enableDollarVM option that, if true, installs an $vm property into each JS
+ global object at creation time. The $vm property refers to an object that
+ provides a collection of useful utility functions. For this initial
+ implementation, $vm will have the following:
+
+ crash() - trigger an intentional crash.
+
+ dfgTrue() - returns true if the current function is DFG compiled, else returns false.
+ jitTrue() - returns true if the current function is compiled by the baseline JIT, else returns false.
+ llintTrue() - returns true if the current function is interpreted by the LLINT, else returns false.
+
+ gc() - runs a full GC.
+ edenGC() - runs an eden GC.
+
+ codeBlockForFrame(frameNumber) - gets the codeBlock at the specified frame (0 = current, 1 = caller, etc).
+ printSourceFor(codeBlock) - prints the source code for the codeBlock.
+ printByteCodeFor(codeBlock) - prints the bytecode for the codeBlock.
+
+ print(str) - prints a string to dataLog output.
+ printCallFrame() - prints the current CallFrame.
+ printStack() - prints the JS stack.
+ printInternal(value) - prints the JSC internal info for the specified value.
+
+ With JS_enableDollarVM=true, JS code can use the above functions like so:
+
+ $vm.print("Using $vm features\n");
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::printCallOp):
+ - FTL compiled functions don't like it when we try to compute the CallLinkStatus.
+ Hence, we skip this step if we're dumping an FTL codeBlock.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::collectAndSweep):
+ (JSC::Heap::collectAllGarbage): Deleted.
+ * heap/Heap.h:
+ (JSC::Heap::collectAllGarbage):
+ - Add ability to do an Eden collection and sweep.
+
+ * interpreter/StackVisitor.cpp:
+ (JSC::printIndents):
+ (JSC::log):
+ (JSC::logF):
+ (JSC::StackVisitor::Frame::print):
+ (JSC::jitTypeName): Deleted.
+ (JSC::printif): Deleted.
+ - Modernize the implementation of StackVisitor::Frame::print(), and remove some
+ now redundant code.
+ - Also fix it so that it downgrades gracefully when encountering inlined DFG
+ and compiled FTL functions.
+
+ (DebugPrintFrameFunctor::DebugPrintFrameFunctor): Deleted.
+ (DebugPrintFrameFunctor::operator()): Deleted.
+ (debugPrintCallFrame): Deleted.
+ (debugPrintStack): Deleted.
+ - these have been moved into JSDollarVMPrototype.cpp.
+
+ * interpreter/StackVisitor.h:
+ - StackVisitor::Frame::print() is now enabled for release builds as well so that
+ we can call it from $vm.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ - Added the $vm instance to global objects conditional on the JSC_enableDollarVM
+ option.
+
+ * runtime/Options.h:
+ - Added the JSC_enableDollarVM option.
+
+ * tools/JSDollarVM.cpp: Added.
+ * tools/JSDollarVM.h: Added.
+ (JSC::JSDollarVM::createStructure):
+ (JSC::JSDollarVM::create):
+ (JSC::JSDollarVM::JSDollarVM):
+
+ * tools/JSDollarVMPrototype.cpp: Added.
+ - This file contains 2 sets of functions:
+
+ a. a C++ implementation of debugging utility functions that are callable when
+ doing debugging from lldb. To the extent possible, these functions try to
+ be cautious and not cause unintended crashes should the user call them with
+ the wrong info. Hence, they are designed to be robust rather than speedy.
+
+ b. the native implementations of JS functions in the $vm object. Where there
+ is overlapping functionality, these are built on top of the C++ functions
+ above to do the work.
+
+ Note: it does not make sense for all of the $vm functions to have a C++
+ counterpart for lldb debugging. For example, the $vm.dfgTrue() function is
+ only useful for JS code, and works via the DFG intrinsics mechanism.
+ When doing debugging via lldb, the optimization level of the currently
+ executing JS function can be gotten by dumping the current CallFrame instead.
+
+ (JSC::currentThreadOwnsJSLock):
+ (JSC::ensureCurrentThreadOwnsJSLock):
+ (JSC::JSDollarVMPrototype::addFunction):
+ (JSC::functionCrash): - $vm.crash()
+ (JSC::functionDFGTrue): - $vm.dfgTrue()
+ (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
+ (JSC::CallerFrameJITTypeFunctor::operator()):
+ (JSC::CallerFrameJITTypeFunctor::jitType):
+ (JSC::functionLLintTrue): - $vm.llintTrue()
+ (JSC::functionJITTrue): - $vm.jitTrue()
+ (JSC::gc):
+ (JSC::functionGC): - $vm.gc()
+ (JSC::edenGC):
+ (JSC::functionEdenGC): - $vm.edenGC()
+ (JSC::isValidCodeBlock):
+ (JSC::codeBlockForFrame):
+ (JSC::functionCodeBlockForFrame): - $vm.codeBlockForFrame(frameNumber)
+ (JSC::codeBlockFromArg):
+ (JSC::functionPrintSourceFor): - $vm.printSourceFor(codeBlock)
+ (JSC::functionPrintByteCodeFor): - $vm.printBytecodeFor(codeBlock)
+ (JSC::functionPrint): - $vm.print(str)
+ (JSC::PrintFrameFunctor::PrintFrameFunctor):
+ (JSC::PrintFrameFunctor::operator()):
+ (JSC::printCallFrame):
+ (JSC::printStack):
+ (JSC::functionPrintCallFrame): - $vm.printCallFrame()
+ (JSC::functionPrintStack): - $vm.printStack()
+ (JSC::printValue):
+ (JSC::functionPrintValue): - $vm.printValue()
+ (JSC::JSDollarVMPrototype::finishCreation):
+ * tools/JSDollarVMPrototype.h: Added.
+ (JSC::JSDollarVMPrototype::create):
+ (JSC::JSDollarVMPrototype::createStructure):
+ (JSC::JSDollarVMPrototype::JSDollarVMPrototype):
+
+2015-04-16 Geoffrey Garen <ggaren@apple.com>
+
+ Speculative fix after r182915
+ https://bugs.webkit.org/show_bug.cgi?id=143404
+
+ Reviewed by Alexey Proskuryakov.
+
+ * runtime/SymbolConstructor.h:
+
+2015-04-16 Mark Lam <mark.lam@apple.com>
+
+ Fixed some typos in a comment.
+
+ Not reviewed.
+
+ * dfg/DFGGenerationInfo.h:
+
+2015-04-16 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement Symbol.for and Symbol.keyFor
+ https://bugs.webkit.org/show_bug.cgi?id=143404
+
+ Reviewed by Geoffrey Garen.
+
+ This patch implements Symbol.for and Symbol.keyFor.
+ SymbolRegistry maintains registered StringImpl* symbols.
+ And to make this mapping enabled over realms,
+ VM owns this mapping (not JSGlobalObject).
+
+ While there's Default AtomicStringTable per thread,
+ SymbolRegistry should not exist over VMs.
+ So everytime VM is created, SymbolRegistry is also created.
+
+ In SymbolRegistry implementation, we don't leverage WeakGCMap (or weak reference design).
+ Theres are several reasons.
+ 1. StringImpl* which represents identity of Symbols is not GC-managed object.
+ So we cannot use WeakGCMap directly.
+ While Symbol* is GC-managed object, holding weak reference to Symbol* doesn't maintain JS symbols (exposed primitive values to users) liveness,
+ because distinct Symbol* can exist.
+ Distinct Symbol* means the Symbol* object that pointer value (Symbol*) is different from weakly referenced Symbol* but held StringImpl* is the same.
+
+ 2. We don't use WTF::WeakPtr. If we add WeakPtrFactory into StringImpl's member, we can track StringImpl*'s liveness by WeakPtr.
+ However there's problem about when we prune staled entries in SymbolRegistry.
+ Since the memory allocated for the Symbol is typically occupied by allocated symbolized StringImpl*'s content,
+ and it is not in GC-heap.
+ While heavily registering Symbols and storing StringImpl* into SymbolRegistry, Heap's EdenSpace is not so occupied.
+ So GC typically attempt to perform EdenCollection, and it doesn't call WeakGCMap's pruleStaleEntries callback.
+ As a result, before pruning staled entries in SymbolRegistry, fast malloc-ed memory fills up the system memory.
+
+ So instead of using Weak reference, we take relatively easy design.
+ When we register symbolized StringImpl* into SymbolRegistry, symbolized StringImpl* is aware of that.
+ And when destructing it, it removes its reference from SymbolRegistry as if atomic StringImpl do so with AtomicStringTable.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * runtime/SymbolConstructor.cpp:
+ (JSC::SymbolConstructor::getOwnPropertySlot):
+ (JSC::symbolConstructorFor):
+ (JSC::symbolConstructorKeyFor):
+ * runtime/SymbolConstructor.h:
+ * runtime/VM.cpp:
+ * runtime/VM.h:
+ (JSC::VM::symbolRegistry):
+ * tests/stress/symbol-registry.js: Added.
+ (test):
+
+2015-04-16 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Use specific functions for @@iterator functions
+ https://bugs.webkit.org/show_bug.cgi?id=143838
+
+ Reviewed by Geoffrey Garen.
+
+ In ES6, some methods are defined with the different names.
+
+ For example,
+
+ Map.prototype[Symbol.iterator] === Map.prototype.entries
+ Set.prototype[Symbol.iterator] === Set.prototype.values
+ Array.prototype[Symbol.iterator] === Array.prototype.values
+ %Arguments%[Symbol.iterator] === Array.prototype.values
+
+ However, current implementation creates different function objects per name.
+ This patch fixes it by setting the object that is used for the other method to @@iterator.
+ e.g. Setting Array.prototype.values function object to Array.prototype[Symbol.iterator].
+
+ And we drop Arguments' iterator implementation and replace Argument[@@iterator] implementation
+ with Array.prototype.values to conform to the spec.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ (Inspector::JSInjectedScriptHost::getInternalProperties):
+ (Inspector::JSInjectedScriptHost::iteratorEntries):
+ * runtime/ArgumentsIteratorConstructor.cpp: Removed.
+ * runtime/ArgumentsIteratorConstructor.h: Removed.
+ * runtime/ArgumentsIteratorPrototype.cpp: Removed.
+ * runtime/ArgumentsIteratorPrototype.h: Removed.
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ * runtime/ArrayPrototype.h:
+ * runtime/ClonedArguments.cpp:
+ (JSC::ClonedArguments::getOwnPropertySlot):
+ (JSC::ClonedArguments::put):
+ (JSC::ClonedArguments::deleteProperty):
+ (JSC::ClonedArguments::defineOwnProperty):
+ (JSC::ClonedArguments::materializeSpecials):
+ * runtime/ClonedArguments.h:
+ * runtime/CommonIdentifiers.h:
+ * runtime/DirectArguments.cpp:
+ (JSC::DirectArguments::overrideThings):
+ * runtime/GenericArgumentsInlines.h:
+ (JSC::GenericArguments<Type>::getOwnPropertySlot):
+ (JSC::GenericArguments<Type>::getOwnPropertyNames):
+ (JSC::GenericArguments<Type>::put):
+ (JSC::GenericArguments<Type>::deleteProperty):
+ (JSC::GenericArguments<Type>::defineOwnProperty):
+ * runtime/JSArgumentsIterator.cpp: Removed.
+ * runtime/JSArgumentsIterator.h: Removed.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::arrayProtoValuesFunction):
+ * runtime/MapPrototype.cpp:
+ (JSC::MapPrototype::finishCreation):
+ * runtime/ScopedArguments.cpp:
+ (JSC::ScopedArguments::overrideThings):
+ * runtime/SetPrototype.cpp:
+ (JSC::SetPrototype::finishCreation):
+ * tests/stress/arguments-iterator.js: Added.
+ (test):
+ (testArguments):
+ * tests/stress/iterator-functions.js: Added.
+ (test):
+ (argumentsTests):
+
+2015-04-14 Mark Lam <mark.lam@apple.com>
+
+ Add JSC_functionOverrides=<overrides file> debugging tool.
+ https://bugs.webkit.org/show_bug.cgi?id=143717
+
+ Reviewed by Geoffrey Garen.
+
+ This tool allows us to do runtime replacement of function bodies with alternatives
+ for debugging purposes. For example, this is useful when we need to debug VM bugs
+ which manifest in scripts executing in webpages downloaded from remote servers
+ that we don't control. The tool allows us to augment those scripts with logging
+ or test code to help isolate the bugs.
+
+ This tool works by substituting the SourceCode at FunctionExecutable creation
+ time. It identifies which SourceCode to substitute by comparing the source
+ string against keys in a set of key value pairs.
+
+ The keys are function body strings defined by 'override' clauses in the overrides
+ file specified by in the JSC_functionOverrides option. The values are function
+ body strings defines by 'with' clauses in the overrides file.
+ See comment blob at top of FunctionOverrides.cpp on the formatting
+ of the overrides file.
+
+ At FunctionExecutable creation time, if the SourceCode string matches one of the
+ 'override' keys from the overrides file, the tool will replace the SourceCode with
+ a new one based on the corresponding 'with' value string. The FunctionExecutable
+ will then be created with the new SourceCode instead.
+
+ Some design decisions:
+ 1. We opted to require that the 'with' clause appear on a separate line than the
+ 'override' clause because this makes it easier to read and write when the
+ 'override' clause's function body is single lined and long.
+
+ 2. The user can use any sequence of characters for the delimiter (except for '{',
+ '}' and white space characters) because this ensures that there can always be
+ some delimiter pattern that does not appear in the function body in the clause
+ e.g. in the body of strings in the JS code.
+
+ '{' and '}' are disallowed because they are used to mark the boundaries of the
+ function body string. White space characters are disallowed because they can
+ be error prone (the user may not be able to tell between spaces and tabs).
+
+ 3. The start and end delimiter must be an identical sequence of characters.
+
+ I had considered allowing the use of complementary characters like <>, [], and
+ () for making delimiter pairs like:
+ [[[[ ... ]]]]
+ <[([( ... )])]>
+
+ But in the end, decided against it because:
+ a. These sequences of complementary characters can exists in JS code.
+ In contrast, a repeating delimiter like %%%% is unlikely to appear in JS
+ code.
+ b. It can be error prone for the user to have to type the exact complement
+ character for the end delimiter in reverse order.
+ In contrast, a repeating delimiter like %%%% is much easier to type and
+ less error prone. Even a sequence like @#$%^ is less error prone than
+ a complementary sequence because it can be copy-pasted, and need not be
+ typed in reverse order.
+ c. It is easier to parse for the same delimiter string for both start and end.
+
+ 4. The tool does a lot of checks for syntax errors in the overrides file because
+ we don't want any overrides to fail silently. If a syntax error is detected,
+ the tool will print an error message and call exit(). This avoids the user
+ wasting time doing debugging only to be surprised later that their specified
+ overrides did not take effect because of some unnoticed typo.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::link):
+ * runtime/Executable.h:
+ * runtime/Options.h:
+ * tools/FunctionOverrides.cpp: Added.
+ (JSC::FunctionOverrides::overrides):
+ (JSC::FunctionOverrides::FunctionOverrides):
+ (JSC::initializeOverrideInfo):
+ (JSC::FunctionOverrides::initializeOverrideFor):
+ (JSC::hasDisallowedCharacters):
+ (JSC::parseClause):
+ (JSC::FunctionOverrides::parseOverridesInFile):
+ * tools/FunctionOverrides.h: Added.
+
+2015-04-16 Basile Clement <basile_clement@apple.com>
+
+ Extract the allocation profile from JSFunction into a rare object
+ https://bugs.webkit.org/show_bug.cgi?id=143807
+
+ Reviewed by Filip Pizlo.
+
+ The allocation profile is only needed for those functions that are used
+ to create objects with [new].
+ Extracting it into its own JSCell removes the need for JSFunction and
+ JSCallee to be JSDestructibleObjects, which should improve performances in most
+ cases at the cost of an extra pointer dereference when the allocation profile
+ is actually needed.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_this):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_this):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/FunctionRareData.cpp: Added.
+ (JSC::FunctionRareData::create):
+ (JSC::FunctionRareData::destroy):
+ (JSC::FunctionRareData::createStructure):
+ (JSC::FunctionRareData::visitChildren):
+ (JSC::FunctionRareData::FunctionRareData):
+ (JSC::FunctionRareData::~FunctionRareData):
+ (JSC::FunctionRareData::finishCreation):
+ * runtime/FunctionRareData.h: Added.
+ (JSC::FunctionRareData::offsetOfAllocationProfile):
+ (JSC::FunctionRareData::allocationProfile):
+ (JSC::FunctionRareData::allocationStructure):
+ (JSC::FunctionRareData::allocationProfileWatchpointSet):
+ * runtime/JSBoundFunction.cpp:
+ (JSC::JSBoundFunction::destroy): Deleted.
+ * runtime/JSBoundFunction.h:
+ * runtime/JSCallee.cpp:
+ (JSC::JSCallee::destroy): Deleted.
+ * runtime/JSCallee.h:
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::JSFunction):
+ (JSC::JSFunction::createRareData):
+ (JSC::JSFunction::visitChildren):
+ (JSC::JSFunction::put):
+ (JSC::JSFunction::defineOwnProperty):
+ (JSC::JSFunction::destroy): Deleted.
+ (JSC::JSFunction::createAllocationProfile): Deleted.
+ * runtime/JSFunction.h:
+ (JSC::JSFunction::offsetOfRareData):
+ (JSC::JSFunction::rareData):
+ (JSC::JSFunction::allocationStructure):
+ (JSC::JSFunction::allocationProfileWatchpointSet):
+ (JSC::JSFunction::offsetOfAllocationProfile): Deleted.
+ (JSC::JSFunction::allocationProfile): Deleted.
+ * runtime/JSFunctionInlines.h:
+ (JSC::JSFunction::JSFunction):
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+
+2015-04-16 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove the unnecessary WTF_CHANGES define
+ https://bugs.webkit.org/show_bug.cgi?id=143825
+
+ Reviewed by Andreas Kling.
+
+ * config.h:
+
+2015-04-15 Andreas Kling <akling@apple.com>
+
+ Make MarkedBlock and WeakBlock 4x smaller.
+ <https://webkit.org/b/143802>
+
+ Reviewed by Mark Hahnenberg.
+
+ To reduce GC heap fragmentation and generally use less memory, reduce the size of MarkedBlock
+ and its buddy WeakBlock by 4x, bringing them from 64kB+4kB to 16kB+1kB.
+
+ In a sampling of cool web sites, I'm seeing ~8% average reduction in overall GC heap size.
+ Some examples:
+
+ apple.com: 6.3MB -> 5.5MB (14.5% smaller)
+ reddit.com: 4.5MB -> 4.1MB ( 9.7% smaller)
+ twitter.com: 23.2MB -> 21.4MB ( 8.4% smaller)
+ cuteoverload.com: 24.5MB -> 23.6MB ( 3.8% smaller)
+
+ Benchmarks look mostly neutral.
+ Some small slowdowns on Octane, some slightly bigger speedups on Kraken and SunSpider.
+
+ * heap/MarkedBlock.h:
+ * heap/WeakBlock.h:
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * llint/LowLevelInterpreter.asm:
+
+2015-04-15 Jordan Harband <ljharb@gmail.com>
+
+ String.prototype.startsWith/endsWith/includes have wrong length in r182673
+ https://bugs.webkit.org/show_bug.cgi?id=143659
+
+ Reviewed by Benjamin Poulain.
+
+ Fix lengths of String.prototype.{includes,startsWith,endsWith} per spec
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
+
+ * runtime/StringPrototype.cpp:
+ (JSC::StringPrototype::finishCreation):
+
+2015-04-15 Mark Lam <mark.lam@apple.com>
+
+ Remove obsolete VMInspector debugging tool.
+ https://bugs.webkit.org/show_bug.cgi?id=143798
+
+ Reviewed by Michael Saboff.
+
+ I added the VMInspector tool 3 years ago to aid in VM hacking work. Some of it
+ has bit rotted, and now the VM also has better ways to achieve its functionality.
+ Hence this code is now obsolete and should be removed.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * interpreter/CallFrame.h:
+ * interpreter/VMInspector.cpp: Removed.
+ * interpreter/VMInspector.h: Removed.
+ * llint/LowLevelInterpreter.cpp:
+
+2015-04-15 Jordan Harband <ljharb@gmail.com>
+
+ Math.imul has wrong length in Safari 8.0.4
+ https://bugs.webkit.org/show_bug.cgi?id=143658
+
+ Reviewed by Benjamin Poulain.
+
+ Correcting function length from 1, to 2, to match spec
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.imul
+
+ * runtime/MathObject.cpp:
+ (JSC::MathObject::finishCreation):
+
+2015-04-15 Jordan Harband <ljharb@gmail.com>
+
+ Number.parseInt in nightly r182673 has wrong length
+ https://bugs.webkit.org/show_bug.cgi?id=143657
+
+ Reviewed by Benjamin Poulain.
+
+ Correcting function length from 1, to 2, to match spec
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-number.parseint
+
+ * runtime/NumberConstructor.cpp:
+ (JSC::NumberConstructor::finishCreation):
+
+2015-04-15 Filip Pizlo <fpizlo@apple.com>
+
+ Harden DFGForAllKills
+ https://bugs.webkit.org/show_bug.cgi?id=143792
+
+ Reviewed by Geoffrey Garen.
+
+ Unfortunately, we don't have a good way to test this yet - but it will be needed to prevent
+ bugs in https://bugs.webkit.org/show_bug.cgi?id=143734.
+
+ Previously ForAllKills used the bytecode kill analysis. That seemed like a good idea because
+ that analysis is cheaper than the full liveness analysis. Unfortunately, it's probably wrong:
+
+ - It looks for kill sites at forExit origin boundaries. But, something might have been killed
+ by an operation that was logically in between the forExit origins at the boundary, but was
+ removed from the DFG for whatever reason. The DFG is allowed to have bytecode instruction
+ gaps.
+
+ - It overlooked the fact that a MovHint that addresses a local that is always live kills that
+ local. For example, storing to an argument means that the prior value of the argument is
+ killed.
+
+ This fixes the analysis by making it handle MovHints directly, and making it define kills in
+ the most conservative way possible: it asks if you were live before but dead after. If we
+ have the compile time budget to afford this more direct approach, then it's definitel a good
+ idea since it's so fool-proof.
+
+ * dfg/DFGArgumentsEliminationPhase.cpp:
+ * dfg/DFGForAllKills.h:
+ (JSC::DFG::forAllKilledOperands):
+ (JSC::DFG::forAllKilledNodesAtNodeIndex):
+ (JSC::DFG::forAllDirectlyKilledOperands): Deleted.
+
+2015-04-15 Joseph Pecoraro <pecoraro@apple.com>
+
+ Provide SPI to allow changing whether JSContexts are remote debuggable by default
+ https://bugs.webkit.org/show_bug.cgi?id=143681
+
+ Reviewed by Darin Adler.
+
+ * API/JSRemoteInspector.h:
+ * API/JSRemoteInspector.cpp:
+ (JSRemoteInspectorGetInspectionEnabledByDefault):
+ (JSRemoteInspectorSetInspectionEnabledByDefault):
+ Provide SPI to toggle the default enabled inspection state of debuggables.
+
+ * API/JSContextRef.cpp:
+ (JSGlobalContextCreateInGroup):
+ Respect the default setting.
+
+2015-04-15 Joseph Pecoraro <pecoraro@apple.com>
+
+ JavaScriptCore: Use kCFAllocatorDefault where possible
+ https://bugs.webkit.org/show_bug.cgi?id=143747
+
+ Reviewed by Darin Adler.
+
+ * heap/HeapTimer.cpp:
+ (JSC::HeapTimer::HeapTimer):
+ * inspector/remote/RemoteInspectorDebuggableConnection.mm:
+ (Inspector::RemoteInspectorInitializeGlobalQueue):
+ (Inspector::RemoteInspectorDebuggableConnection::setupRunLoop):
+ For consistency and readability use the constant instead of
+ different representations of null.
+
+2015-04-14 Michael Saboff <msaboff@apple.com>
+
+ Remove JavaScriptCoreUseJIT default from JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=143746
+
+ Reviewed by Mark Lam.
+
+ * runtime/VM.cpp:
+ (JSC::enableAssembler):
+
+2015-04-14 Chris Dumez <cdumez@apple.com>
+
+ Regression(r180020): Web Inspector crashes on pages that have a stylesheet with an invalid MIME type
+ https://bugs.webkit.org/show_bug.cgi?id=143745
+ <rdar://problem/20243916>
+
+ Reviewed by Joseph Pecoraro.
+
+ Add assertion in ContentSearchUtilities::findMagicComment() to make
+ sure the content String is not null or we would crash in
+ JSC::Yarr::interpret() later.
+
+ * inspector/ContentSearchUtilities.cpp:
+ (Inspector::ContentSearchUtilities::findMagicComment):
+
+2015-04-14 Michael Saboff <msaboff@apple.com>
+
+ DFG register fillSpeculate*() functions should validate incoming spill format is compatible with requested fill format
+ https://bugs.webkit.org/show_bug.cgi?id=143727
+
+ Reviewed by Geoffrey Garen.
+
+ Used the result of AbstractInterpreter<>::filter() to check that the current spill format is compatible
+ with the requested fill format. If filter() reports a contradiction, then we force an OSR exit.
+ Removed individual checks made redundant by the new check.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
+ (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
+
+2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
+
+ Replace JavaScriptCoreOutputConsoleMessagesToSystemConsole default with an SPI
+ https://bugs.webkit.org/show_bug.cgi?id=143691
+
+ Reviewed by Geoffrey Garen.
+
+ * API/JSRemoteInspector.h:
+ * API/JSRemoteInspector.cpp:
+ (JSRemoteInspectorSetLogToSystemConsole):
+ Add SPI to enable/disable logging to the system console.
+ This only affects JSContext `console` logs and warnings.
+
+ * inspector/JSGlobalObjectConsoleClient.h:
+ * inspector/JSGlobalObjectConsoleClient.cpp:
+ (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
+ (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
+ (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
+ (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole): Deleted.
+ Simplify access to the setting now that it doesn't need to
+ initialize its value from preferences.
+
+2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Auto-attach fails after r179562, initialization too late after dispatch
+ https://bugs.webkit.org/show_bug.cgi?id=143682
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::singleton):
+ If we are on the main thread, run the initialization immediately.
+ Otherwise dispatch to the main thread. This way if the first JSContext
+ was created on the main thread it can get auto-attached if applicable.
+
+2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
+
+ Unreviewed build fix for Mavericks.
+
+ Mavericks includes this file but does not enable ENABLE_REMOTE_INSPECTOR
+ so the Inspector namespace is not available when compiling this file.
+
+ * API/JSRemoteInspector.cpp:
+
+2015-04-14 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Expose private APIs to interact with RemoteInspector instead of going through WebKit
+ https://bugs.webkit.org/show_bug.cgi?id=143729
+
+ Reviewed by Timothy Hatcher.
+
+ * API/JSRemoteInspector.h: Added.
+ * API/JSRemoteInspector.cpp: Added.
+ (JSRemoteInspectorDisableAutoStart):
+ (JSRemoteInspectorStart):
+ (JSRemoteInspectorSetParentProcessInformation):
+ Add the new SPIs for basic remote inspection behavior.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ Add the new files to Mac only, since remote inspection is only
+ enabled there anyways.
+
+2015-04-14 Mark Lam <mark.lam@apple.com>
+
+ Rename JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist.
+ https://bugs.webkit.org/show_bug.cgi?id=143722
+
+ Reviewed by Michael Saboff.
+
+ Renaming JSC_dfgFunctionWhitelistFile to JSC_dfgWhitelist so that it is
+ shorter, and easier to remember (without having to look it up) and to
+ type. JSC options now support descriptions, and one can always look up
+ the description if the option's purpose is not already obvious.
+
+ * dfg/DFGFunctionWhitelist.cpp:
+ (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist):
+ (JSC::DFG::FunctionWhitelist::contains):
+ * runtime/Options.h:
+
+2015-04-13 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix Windows build. Windows doesn't take kindly to private classes that use FAST_ALLOCATED.
+
+ * runtime/InferredValue.h:
+
+2015-04-13 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix build. I introduced a new cell type at the same time as kling changed how new cell types are written.
+
+ * runtime/InferredValue.h:
+
+2015-04-08 Filip Pizlo <fpizlo@apple.com>
+
+ JSC should detect singleton functions
+ https://bugs.webkit.org/show_bug.cgi?id=143232
+
+ Reviewed by Geoffrey Garen.
+
+ This started out as an attempt to make constructors faster by detecting when a constructor is a
+ singleton. The idea is that each FunctionExecutable has a VariableWatchpointSet - a watchpoint
+ along with an inferred value - that detects if only one JSFunction has been allocated for that
+ executable, and if so, what that JSFunction is. Then, inside the code for the FunctionExecutable,
+ if the watchpoint set has an inferred value (i.e. it's been initialized and it is still valid),
+ we can constant-fold GetCallee.
+
+ Unfortunately, constructors don't use GetCallee anymore, so that didn't pan out. But in the
+ process I realized a bunch of things:
+
+ - This allows us to completely eliminate the GetCallee/GetScope sequence that we still sometimes
+ had even in code where our singleton-closure detection worked. That's because singleton-closure
+ inference worked at the op_resolve_scope, and that op_resolve_scope still needed to keep alive
+ the incoming scope in case we OSR exit. But by constant-folding GetCallee, that sequence
+ disappears. OSR exit can rematerialize the callee or the scope by just knowing their constant
+ values.
+
+ - Singleton detection should be a reusable thing. So, I got rid of VariableWatchpointSet and
+ created InferredValue. InferredValue is a cell, so it can handle its own GC magic.
+ FunctionExecutable uses an InferredValue to tell you about singleton JSFunctions.
+
+ - The old singleton-scope detection in op_resolve_scope is better abstracted as a SymbolTable
+ detecting a singleton JSSymbolTableObject. So, SymbolTable uses an InferredValue to tell you
+ about singleton JSSymbolTableObjects. It's curious that we want to have singleton detection in
+ SymbolTable if we already have it in FunctionExecutable. This comes into play in two ways.
+ First, it means that the DFG can realize sooner that a resolve_scope resolves to a constant
+ scope. Ths saves compile times and it allows prediction propagation to benefit from the
+ constant folding. Second, it means that we will detect a singleton scope even if it is
+ referenced from a non-singleton scope that is nearer to us in the scope chain. This refactoring
+ allows us to eliminate the function reentry watchpoint.
+
+ - This allows us to use a normal WatchpointSet, instead of a VariableWatchpointSet, for inferring
+ constant values in scopes. Previously when the DFG inferred that a closure variable was
+ constant, it wouldn't know which closure that variable was in and so it couldn't just load that
+ value. But now we are first inferring that the function is a singleton, which means that we
+ know exactly what scope it points to, and we can load the value from the scope. Using a
+ WatchpointSet instead of a VariableWatchpointSet saves some memory and simplifies a bunch of
+ code. This also means that now, the only user of VariableWatchpointSet is FunctionExecutable.
+ I've tweaked the code of VariableWatchpointSet to reduce its power to just be what
+ FunctionExecutable wants.
+
+ This also has the effect of simplifying the implementation of block scoping. Prior to this
+ change, block scoping would have needed to have some story for the function reentry watchpoint on
+ any nested symbol table. That's totally weird to think about; it's not really a function reentry
+ but a scope reentry. Now we don't have to think about this. Constant inference on nested scopes
+ will "just work": if we prove that we know the constant value of the scope then the machinery
+ kicks in, otherwise it doesn't.
+
+ This is a small Octane and AsmBench speed-up. AsmBench sees 1% while Octane sees sub-1%.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::finalizeUnconditionally):
+ (JSC::CodeBlock::valueProfileForBytecodeOffset):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::valueProfileForBytecodeOffset): Deleted.
+ * bytecode/CodeOrigin.cpp:
+ (JSC::InlineCallFrame::calleeConstant):
+ (JSC::InlineCallFrame::visitAggregate):
+ * bytecode/CodeOrigin.h:
+ (JSC::InlineCallFrame::calleeConstant): Deleted.
+ (JSC::InlineCallFrame::visitAggregate): Deleted.
+ * bytecode/Instruction.h:
+ * bytecode/VariableWatchpointSet.cpp: Removed.
+ * bytecode/VariableWatchpointSet.h: Removed.
+ * bytecode/VariableWatchpointSetInlines.h: Removed.
+ * bytecode/VariableWriteFireDetail.cpp: Added.
+ (JSC::VariableWriteFireDetail::dump):
+ (JSC::VariableWriteFireDetail::touch):
+ * bytecode/VariableWriteFireDetail.h: Added.
+ (JSC::VariableWriteFireDetail::VariableWriteFireDetail):
+ * bytecode/Watchpoint.h:
+ (JSC::WatchpointSet::stateOnJSThread):
+ (JSC::WatchpointSet::startWatching):
+ (JSC::WatchpointSet::fireAll):
+ (JSC::WatchpointSet::touch):
+ (JSC::WatchpointSet::invalidate):
+ (JSC::InlineWatchpointSet::stateOnJSThread):
+ (JSC::InlineWatchpointSet::state):
+ (JSC::InlineWatchpointSet::hasBeenInvalidated):
+ (JSC::InlineWatchpointSet::invalidate):
+ (JSC::InlineWatchpointSet::touch):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::get):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::getScope): Deleted.
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDesiredWatchpoints.cpp:
+ (JSC::DFG::InferredValueAdaptor::add):
+ (JSC::DFG::DesiredWatchpoints::addLazily):
+ (JSC::DFG::DesiredWatchpoints::reallyAdd):
+ (JSC::DFG::DesiredWatchpoints::areStillValid):
+ * dfg/DFGDesiredWatchpoints.h:
+ (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated):
+ (JSC::DFG::DesiredWatchpoints::isWatched):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::tryGetConstantClosureVar):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasWatchpointSet):
+ (JSC::DFG::Node::watchpointSet):
+ (JSC::DFG::Node::hasVariableWatchpointSet): Deleted.
+ (JSC::DFG::Node::variableWatchpointSet): Deleted.
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileNewFunction):
+ (JSC::DFG::SpeculativeJIT::compileCreateActivation):
+ (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGVarargsForwardingPhase.cpp:
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
+ (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
+ (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
+ * interpreter/Interpreter.cpp:
+ (JSC::StackFrame::friendlySourceURL):
+ (JSC::StackFrame::friendlyFunctionName):
+ * interpreter/Interpreter.h:
+ (JSC::StackFrame::friendlySourceURL): Deleted.
+ (JSC::StackFrame::friendlyFunctionName): Deleted.
+ * jit/JIT.cpp:
+ (JSC::JIT::emitNotifyWrite):
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_touch_entry): Deleted.
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitPutGlobalVar):
+ (JSC::JIT::emitPutClosureVar):
+ (JSC::JIT::emitNotifyWrite): Deleted.
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emitPutGlobalVar):
+ (JSC::JIT::emitPutClosureVar):
+ (JSC::JIT::emitNotifyWrite): Deleted.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL): Deleted.
+ * runtime/CommonSlowPaths.h:
+ * runtime/Executable.cpp:
+ (JSC::FunctionExecutable::finishCreation):
+ (JSC::FunctionExecutable::visitChildren):
+ * runtime/Executable.h:
+ (JSC::FunctionExecutable::singletonFunction):
+ * runtime/InferredValue.cpp: Added.
+ (JSC::InferredValue::create):
+ (JSC::InferredValue::destroy):
+ (JSC::InferredValue::createStructure):
+ (JSC::InferredValue::visitChildren):
+ (JSC::InferredValue::InferredValue):
+ (JSC::InferredValue::~InferredValue):
+ (JSC::InferredValue::notifyWriteSlow):
+ (JSC::InferredValue::ValueCleanup::ValueCleanup):
+ (JSC::InferredValue::ValueCleanup::~ValueCleanup):
+ (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
+ * runtime/InferredValue.h: Added.
+ (JSC::InferredValue::inferredValue):
+ (JSC::InferredValue::state):
+ (JSC::InferredValue::isStillValid):
+ (JSC::InferredValue::hasBeenInvalidated):
+ (JSC::InferredValue::add):
+ (JSC::InferredValue::notifyWrite):
+ (JSC::InferredValue::invalidate):
+ * runtime/JSEnvironmentRecord.cpp:
+ (JSC::JSEnvironmentRecord::visitChildren):
+ * runtime/JSEnvironmentRecord.h:
+ (JSC::JSEnvironmentRecord::isValid):
+ (JSC::JSEnvironmentRecord::finishCreation):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::create):
+ * runtime/JSFunction.h:
+ (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
+ (JSC::JSFunction::createImpl):
+ (JSC::JSFunction::create): Deleted.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::addGlobalVar):
+ (JSC::JSGlobalObject::addFunction):
+ * runtime/JSGlobalObject.h:
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::symbolTablePut):
+ * runtime/JSScope.h:
+ (JSC::ResolveOp::ResolveOp):
+ * runtime/JSSegmentedVariableObject.h:
+ (JSC::JSSegmentedVariableObject::finishCreation):
+ * runtime/JSSymbolTableObject.h:
+ (JSC::JSSymbolTableObject::JSSymbolTableObject):
+ (JSC::JSSymbolTableObject::setSymbolTable):
+ (JSC::symbolTablePut):
+ (JSC::symbolTablePutWithAttributes):
+ * runtime/PutPropertySlot.h:
+ * runtime/SymbolTable.cpp:
+ (JSC::SymbolTableEntry::prepareToWatch):
+ (JSC::SymbolTable::SymbolTable):
+ (JSC::SymbolTable::finishCreation):
+ (JSC::SymbolTable::visitChildren):
+ (JSC::SymbolTableEntry::inferredValue): Deleted.
+ (JSC::SymbolTableEntry::notifyWriteSlow): Deleted.
+ (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup): Deleted.
+ (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup): Deleted.
+ (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally): Deleted.
+ * runtime/SymbolTable.h:
+ (JSC::SymbolTableEntry::disableWatching):
+ (JSC::SymbolTableEntry::watchpointSet):
+ (JSC::SymbolTable::singletonScope):
+ (JSC::SymbolTableEntry::notifyWrite): Deleted.
+ * runtime/TypeProfiler.cpp:
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+ * tests/stress/infer-uninitialized-closure-var.js: Added.
+ (foo.f):
+ (foo):
+ * tests/stress/singleton-scope-then-overwrite.js: Added.
+ (foo.f):
+ (foo):
+ * tests/stress/singleton-scope-then-realloc-and-overwrite.js: Added.
+ (foo):
+ * tests/stress/singleton-scope-then-realloc.js: Added.
+ (foo):
+
+2015-04-13 Andreas Kling <akling@apple.com>
+
+ Don't segregate heap objects based on Structure immortality.
+ <https://webkit.org/b/143638>
+
+ Reviewed by Darin Adler.
+
+ Put all objects that need a destructor call into the same MarkedBlock.
+ This reduces memory consumption in many situations, while improving locality,
+ since much more of the MarkedBlock space can be shared.
+
+ Instead of branching on the MarkedBlock type, we now check a bit in the
+ JSCell's inline type flags (StructureIsImmortal) to see whether it's safe
+ to access the cell's Structure during destruction or not.
+
+ Performance benchmarks look mostly neutral. Maybe a small regression on
+ SunSpider's date objects.
+
+ On the amazon.com landing page, this saves us 50 MarkedBlocks (3200kB) along
+ with a bunch of WeakBlocks that were hanging off of them. That's on the higher
+ end of savings we can get from this, but still a very real improvement.
+
+ Most of this patch is removing the "hasImmortalStructure" constant from JSCell
+ derived classes and passing that responsibility to the StructureIsImmortal flag.
+ StructureFlags is made public so that it's accessible from non-member functions.
+ I made sure to declare it everywhere and make classes final to try to make it
+ explicit what each class is doing to its inherited flags.
+
+ * API/JSCallbackConstructor.h:
+ * API/JSCallbackObject.h:
+ * bytecode/UnlinkedCodeBlock.h:
+ * debugger/DebuggerScope.h:
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileMakeRope):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
+ * heap/Heap.h:
+ (JSC::Heap::subspaceForObjectDestructor):
+ (JSC::Heap::allocatorForObjectWithDestructor):
+ (JSC::Heap::subspaceForObjectNormalDestructor): Deleted.
+ (JSC::Heap::subspaceForObjectsWithImmortalStructure): Deleted.
+ (JSC::Heap::allocatorForObjectWithNormalDestructor): Deleted.
+ (JSC::Heap::allocatorForObjectWithImmortalStructureDestructor): Deleted.
+ * heap/HeapInlines.h:
+ (JSC::Heap::allocateWithDestructor):
+ (JSC::Heap::allocateObjectOfType):
+ (JSC::Heap::subspaceForObjectOfType):
+ (JSC::Heap::allocatorForObjectOfType):
+ (JSC::Heap::allocateWithNormalDestructor): Deleted.
+ (JSC::Heap::allocateWithImmortalStructureDestructor): Deleted.
+ * heap/MarkedAllocator.cpp:
+ (JSC::MarkedAllocator::allocateBlock):
+ * heap/MarkedAllocator.h:
+ (JSC::MarkedAllocator::needsDestruction):
+ (JSC::MarkedAllocator::MarkedAllocator):
+ (JSC::MarkedAllocator::init):
+ (JSC::MarkedAllocator::destructorType): Deleted.
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::create):
+ (JSC::MarkedBlock::MarkedBlock):
+ (JSC::MarkedBlock::callDestructor):
+ (JSC::MarkedBlock::specializedSweep):
+ (JSC::MarkedBlock::sweep):
+ (JSC::MarkedBlock::sweepHelper):
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::needsDestruction):
+ (JSC::MarkedBlock::destructorType): Deleted.
+ * heap/MarkedSpace.cpp:
+ (JSC::MarkedSpace::MarkedSpace):
+ (JSC::MarkedSpace::resetAllocators):
+ (JSC::MarkedSpace::forEachAllocator):
+ (JSC::MarkedSpace::isPagedOut):
+ (JSC::MarkedSpace::clearNewlyAllocated):
+ * heap/MarkedSpace.h:
+ (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
+ (JSC::MarkedSpace::destructorAllocatorFor):
+ (JSC::MarkedSpace::allocateWithDestructor):
+ (JSC::MarkedSpace::forEachBlock):
+ (JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor): Deleted.
+ (JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure): Deleted.
+ (JSC::MarkedSpace::immortalStructureDestructorAllocatorFor): Deleted.
+ (JSC::MarkedSpace::normalDestructorAllocatorFor): Deleted.
+ (JSC::MarkedSpace::allocateWithImmortalStructureDestructor): Deleted.
+ (JSC::MarkedSpace::allocateWithNormalDestructor): Deleted.
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHostPrototype.h:
+ * inspector/JSJavaScriptCallFrame.h:
+ * inspector/JSJavaScriptCallFramePrototype.h:
+ * jsc.cpp:
+ * runtime/ArrayBufferNeuteringWatchpoint.h:
+ * runtime/ArrayConstructor.h:
+ * runtime/ArrayIteratorPrototype.h:
+ * runtime/BooleanPrototype.h:
+ * runtime/ClonedArguments.h:
+ * runtime/CustomGetterSetter.h:
+ * runtime/DateConstructor.h:
+ * runtime/DatePrototype.h:
+ * runtime/ErrorPrototype.h:
+ * runtime/ExceptionHelpers.h:
+ * runtime/Executable.h:
+ * runtime/GenericArguments.h:
+ * runtime/GetterSetter.h:
+ * runtime/InternalFunction.h:
+ * runtime/JSAPIValueWrapper.h:
+ * runtime/JSArgumentsIterator.h:
+ * runtime/JSArray.h:
+ * runtime/JSArrayBuffer.h:
+ * runtime/JSArrayBufferView.h:
+ * runtime/JSBoundFunction.h:
+ * runtime/JSCallee.h:
+ * runtime/JSCell.h:
+ * runtime/JSCellInlines.h:
+ (JSC::JSCell::classInfo):
+ * runtime/JSDataViewPrototype.h:
+ * runtime/JSEnvironmentRecord.h:
+ * runtime/JSFunction.h:
+ * runtime/JSGenericTypedArrayView.h:
+ * runtime/JSGlobalObject.h:
+ * runtime/JSLexicalEnvironment.h:
+ * runtime/JSNameScope.h:
+ * runtime/JSNotAnObject.h:
+ * runtime/JSONObject.h:
+ * runtime/JSObject.h:
+ (JSC::JSFinalObject::JSFinalObject):
+ * runtime/JSPromiseConstructor.h:
+ * runtime/JSPromiseDeferred.h:
+ * runtime/JSPromisePrototype.h:
+ * runtime/JSPromiseReaction.h:
+ * runtime/JSPropertyNameEnumerator.h:
+ * runtime/JSProxy.h:
+ * runtime/JSScope.h:
+ * runtime/JSString.h:
+ * runtime/JSSymbolTableObject.h:
+ * runtime/JSTypeInfo.h:
+ (JSC::TypeInfo::structureIsImmortal):
+ * runtime/MathObject.h:
+ * runtime/NumberConstructor.h:
+ * runtime/NumberPrototype.h:
+ * runtime/ObjectConstructor.h:
+ * runtime/PropertyMapHashTable.h:
+ * runtime/RegExp.h:
+ * runtime/RegExpConstructor.h:
+ * runtime/RegExpObject.h:
+ * runtime/RegExpPrototype.h:
+ * runtime/ScopedArgumentsTable.h:
+ * runtime/SparseArrayValueMap.h:
+ * runtime/StrictEvalActivation.h:
+ * runtime/StringConstructor.h:
+ * runtime/StringIteratorPrototype.h:
+ * runtime/StringObject.h:
+ * runtime/StringPrototype.h:
+ * runtime/Structure.cpp:
+ (JSC::Structure::Structure):
+ * runtime/Structure.h:
+ * runtime/StructureChain.h:
+ * runtime/StructureRareData.h:
+ * runtime/Symbol.h:
+ * runtime/SymbolPrototype.h:
+ * runtime/SymbolTable.h:
+ * runtime/WeakMapData.h:
+
+2015-04-13 Mark Lam <mark.lam@apple.com>
+
+ DFG inlining of op_call_varargs should keep the callee alive in case of OSR exit.
+ https://bugs.webkit.org/show_bug.cgi?id=143407
+
+ Reviewed by Filip Pizlo.
+
+ DFG inlining of a varargs call / construct needs to keep the local
+ containing the callee alive with a Phantom node because the LoadVarargs
+ node may OSR exit. After the OSR exit, the baseline JIT executes the
+ op_call_varargs with that callee in the local.
+
+ Previously, because that callee local was not explicitly kept alive,
+ the op_call_varargs case can OSR exit a DFG function and leave an
+ undefined value in that local. As a result, the baseline observes the
+ side effect of an op_call_varargs on an undefined value instead of the
+ function it expected.
+
+ Note: this issue does not manifest with op_construct_varargs because
+ the inlined constructor will have an op_create_this which operates on
+ the incoming callee value, thereby keeping it alive.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ * tests/stress/call-varargs-with-different-arguments-length-after-warmup.js: Added.
+ (foo):
+ (Foo):
+ (doTest):
+
+2015-04-12 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement Array.prototype.values
+ https://bugs.webkit.org/show_bug.cgi?id=143633
+
+ Reviewed by Darin Adler.
+
+ Symbol.unscopables is implemented, so we can implement Array.prototype.values
+ without largely breaking the web. The following script passes.
+
+ var array = [];
+ var values = 42;
+ with (array) {
+ assert(values, 42);
+ }
+
+ * runtime/ArrayPrototype.cpp:
+ * tests/stress/array-iterators-next.js:
+ * tests/stress/map-iterators-next.js:
+ * tests/stress/set-iterators-next.js:
+ * tests/stress/values-unscopables.js: Added.
+ (test):
+
+2015-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Run flaky conservative GC related test first before polluting stack and registers
+ https://bugs.webkit.org/show_bug.cgi?id=143634
+
+ Reviewed by Ryosuke Niwa.
+
+ After r182653, JSC API tests fail. However, it's not related to the change.
+ After investigating the cause of this failure, I've found that the failed test is flaky
+ because JSC's GC is conservative. If previously allocated JSGlobalObject is accidentally alive
+ due to conservative roots in C stack and registers, this test fails.
+
+ Since GC marks C stack and registers as roots conservatively,
+ objects not referenced logically can be accidentally marked and alive.
+ To avoid this situation as possible as we can,
+ 1. run this test first before stack is polluted,
+ 2. extract this test as a function to suppress stack height.
+
+ * API/tests/testapi.mm:
+ (testWeakValue):
+ (testObjectiveCAPIMain):
+ (testObjectiveCAPI):
+
+2015-04-11 Matt Baker <mattbaker@apple.com>
+
+ Web Inspector: create content view and details sidebar for Frames timeline
+ https://bugs.webkit.org/show_bug.cgi?id=143533
+
+ Reviewed by Timothy Hatcher.
+
+ Refactoring: RunLoop prefix changed to RenderingFrame.
+
+ * inspector/protocol/Timeline.json:
+
+2015-04-11 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Enable Symbol in web pages
+ https://bugs.webkit.org/show_bug.cgi?id=143375
+
+ Reviewed by Ryosuke Niwa.
+
+ Expose Symbol to web pages.
+ Symbol was exposed, but it was hidden since it breaks Facebook comments.
+ This is because at that time Symbol is implemented,
+ but methods for Symbol.iterator and Object.getOwnPropertySymbols are not implemented yet
+ and it breaks React.js and immutable.js.
+
+ Now methods for Symbol.iterator and Object.getOwnPropertySymbols are implemented
+ and make sure that Facebook comment input functionality is not broken with exposed Symbol.
+
+ So this patch replaces runtime flags SymbolEnabled to SymbolDisabled
+ and makes enabling symbols by default.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructor::finishCreation):
+ * runtime/RuntimeFlags.h:
+
+2015-04-10 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ ES6: Iterator toString names should be consistent
+ https://bugs.webkit.org/show_bug.cgi?id=142424
+
+ Reviewed by Geoffrey Garen.
+
+ Iterator Object Names in the spec right now have spaces.
+ In our implementation some do and some don't.
+ This patch aligns JSC to the spec.
+
+ * runtime/JSArrayIterator.cpp:
+ * runtime/JSStringIterator.cpp:
+ * tests/stress/iterator-names.js: Added.
+ (test):
+ (iter):
+ (check):
+
+2015-04-10 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (182567): regress/script-tests/sorting-benchmark.js fails on 32 bit dfg-eager tests
+ https://bugs.webkit.org/show_bug.cgi?id=143582
+
+ Reviewed by Mark Lam.
+
+ For 32 bit builds, we favor spilling unboxed values. The ASSERT at the root of this bug doesn't
+ fire for 64 bit builds, because we spill an "Other" value as a full JS value (DataFormatJS).
+ For 32 bit builds however, if we are able, we spill Other values as JSCell* (DataFormatCell).
+ The fix is to add a check in fillSpeculateInt32Internal() before the ASSERT that always OSR exits
+ if the spillFormat is DataFormatCell. Had we spilled in DataFormatJS and the value was a JSCell*,
+ we would still OSR exit after the speculation check.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode): Fixed an error in a comment while debugging.
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
+
+2015-04-10 Milan Crha <mcrha@redhat.com>
+
+ Disable Linux-specific code in a Windows build
+ https://bugs.webkit.org/show_bug.cgi?id=137973
+
+ Reviewed by Joseph Pecoraro.
+
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
+
+2015-04-10 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Fix calleeSaveRegisters() on non iOS platforms after r180516
+ https://bugs.webkit.org/show_bug.cgi?id=143368
+
+ Reviewed by Michael Saboff.
+
+ * jit/RegisterSet.cpp:
+ (JSC::RegisterSet::calleeSaveRegisters):
+
+2015-04-08 Joseph Pecoraro <pecoraro@apple.com>
+
+ Use jsNontrivialString in more places if the string is guaranteed to be 2 or more characters
+ https://bugs.webkit.org/show_bug.cgi?id=143430
+
+ Reviewed by Darin Adler.
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::errorDescriptionForValue):
+ * runtime/NumberPrototype.cpp:
+ (JSC::numberProtoFuncToExponential):
+ (JSC::numberProtoFuncToPrecision):
+ (JSC::numberProtoFuncToString):
+ * runtime/SymbolPrototype.cpp:
+ (JSC::symbolProtoFuncToString):
+
+2015-04-08 Filip Pizlo <fpizlo@apple.com>
+
+ JSArray::sortNumeric should handle ArrayWithUndecided
+ https://bugs.webkit.org/show_bug.cgi?id=143535
+
+ Reviewed by Geoffrey Garen.
+
+ ArrayWithUndecided is what you get if you haven't stored anything into the array yet. We need to handle it.
+
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::sortNumeric):
+ * tests/stress/sort-array-with-undecided.js: Added.
+
+2015-04-08 Filip Pizlo <fpizlo@apple.com>
+
+ DFG::IntegerCheckCombiningPhase's wrap-around check shouldn't trigger C++ undef behavior on wrap-around
+ https://bugs.webkit.org/show_bug.cgi?id=143532
+
+ Reviewed by Gavin Barraclough.
+
+ Oh the irony! We were protecting an optimization that only worked if there was no wrap-around in JavaScript.
+ But the C++ code had wrap-around, which is undef in C++. So, if the compiler was smart enough, our compiler
+ would think that there never was wrap-around.
+
+ This fixes a failure in stress/tricky-array-boiunds-checks.js when JSC is compiled with bleeding-edge clang.
+
+ * dfg/DFGIntegerCheckCombiningPhase.cpp:
+ (JSC::DFG::IntegerCheckCombiningPhase::isValid):
+
+2015-04-07 Michael Saboff <msaboff@apple.com>
+
+ Lazily initialize LogToSystemConsole flag to reduce memory usage
+ https://bugs.webkit.org/show_bug.cgi?id=143506
+
+ Reviewed by Mark Lam.
+
+ Only call into CF preferences code when we need to in order to reduce memory usage.
+
+ * inspector/JSGlobalObjectConsoleClient.cpp:
+ (Inspector::JSGlobalObjectConsoleClient::logToSystemConsole):
+ (Inspector::JSGlobalObjectConsoleClient::setLogToSystemConsole):
+ (Inspector::JSGlobalObjectConsoleClient::initializeLogToSystemConsole):
+ (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
+
+2015-04-07 Benjamin Poulain <benjamin@webkit.org>
+
+ Get the features.json files ready for open contributions
+ https://bugs.webkit.org/show_bug.cgi?id=143436
+
+ Reviewed by Darin Adler.
+
+ * features.json:
+
+2015-04-07 Filip Pizlo <fpizlo@apple.com>
+
+ Constant folding of typed array properties should be handled by AI rather than strength reduction
+ https://bugs.webkit.org/show_bug.cgi?id=143496
+
+ Reviewed by Geoffrey Garen.
+
+ Handling constant folding in AI is better because it precludes us from having to fixpoint the CFA
+ phase and whatever other phase did the folding in order to find all constants.
+
+ This also removes the TypedArrayWatchpoint node type because we can just set the watchpoint
+ directly.
+
+ This also fixes a bug in FTL lowering of GetTypedArrayByteOffset. The bug was previously not
+ found because all of the tests for it involved the property getting constant folded. I found that
+ the codegen was bad because an earlier version of the patch broke that constant folding. This
+ adds a new test for that node type, which makes constant folding impossible by allocating a new
+ typed array every type. The lesson here is: if you write a test for something, run the test with
+ full IR dumps to make sure it's actually testing the thing you want it to test.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::tryGetFoldableView):
+ (JSC::DFG::Graph::tryGetFoldableViewForChild1): Deleted.
+ * dfg/DFGGraph.h:
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasTypedArray): Deleted.
+ (JSC::DFG::Node::typedArray): Deleted.
+ * dfg/DFGNodeType.h:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
+ * 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): Deleted.
+ (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray): Deleted.
+ * dfg/DFGWatchpointCollectionPhase.cpp:
+ (JSC::DFG::WatchpointCollectionPhase::handle):
+ (JSC::DFG::WatchpointCollectionPhase::addLazily):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
+ (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
+ * tests/stress/fold-typed-array-properties.js:
+ (foo):
+ * tests/stress/typed-array-byte-offset.js: Added.
+ (foo):
+
+2015-04-07 Matthew Mirman <mmirman@apple.com>
+
+ Source and stack information should get appended only to native errors
+ and should be added directly after construction rather than when thrown.
+ This fixes frozen objects being unfrozen when thrown while conforming to
+ ecma script standard and other browser behavior.
+ rdar://problem/19927293
+ https://bugs.webkit.org/show_bug.cgi?id=141871
+
+ Reviewed by Geoffrey Garen.
+
+ Appending stack, source, line, and column information to an object whenever that object is thrown
+ is incorrect because it violates the ecma script standard for the behavior of throw. Suppose for example
+ that the object being thrown already has one of these properties or is frozen. Adding the properties
+ would then violate the frozen contract or overwrite those properties. Other browsers do not do this,
+ and doing this causes unnecessary performance hits in code with heavy use of the throw construct as
+ a control flow construct rather than just an error reporting mechanism.
+
+ Because WebCore adds "native" errors which do not inherit from any JSC native error,
+ appending the error properties as a seperate call after construction of the error is required
+ to avoid having to manually truncate the stack and gather local source information due to
+ the stack being extended by a nested call to construct one of the native jsc error.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::execute):
+ * interpreter/Interpreter.h:
+ * parser/ParserError.h:
+ (JSC::ParserError::toErrorObject):
+ * runtime/CommonIdentifiers.h:
+ * runtime/Error.cpp:
+ (JSC::createError):
+ (JSC::createEvalError):
+ (JSC::createRangeError):
+ (JSC::createReferenceError):
+ (JSC::createSyntaxError):
+ (JSC::createTypeError):
+ (JSC::createNotEnoughArgumentsError):
+ (JSC::createURIError):
+ (JSC::createOutOfMemoryError):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
+ (JSC::addErrorInfoAndGetBytecodeOffset): Added.
+ (JSC::addErrorInfo): Added special case for appending complete error info
+ to a newly constructed error object.
+ * runtime/Error.h:
+ * runtime/ErrorConstructor.cpp:
+ (JSC::Interpreter::constructWithErrorConstructor):
+ (JSC::Interpreter::callErrorConstructor):
+ * runtime/ErrorInstance.cpp:
+ (JSC::appendSourceToError): Moved from VM.cpp
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame):
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::index):
+ (JSC::addErrorInfoAndGetBytecodeOffset):
+ (JSC::ErrorInstance::finishCreation):
+ * runtime/ErrorInstance.h:
+ (JSC::ErrorInstance::create):
+ * runtime/ErrorPrototype.cpp:
+ (JSC::ErrorPrototype::finishCreation):
+ * runtime/ExceptionFuzz.cpp:
+ (JSC::doExceptionFuzzing):
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::createError):
+ (JSC::createInvalidFunctionApplyParameterError):
+ (JSC::createInvalidInParameterError):
+ (JSC::createInvalidInstanceofParameterError):
+ (JSC::createNotAConstructorError):
+ (JSC::createNotAFunctionError):
+ (JSC::createNotAnObjectError):
+ (JSC::throwOutOfMemoryError):
+ (JSC::createStackOverflowError): Deleted.
+ (JSC::createOutOfMemoryError): Deleted.
+ * runtime/ExceptionHelpers.h:
+ * runtime/JSArrayBufferConstructor.cpp:
+ (JSC::constructArrayBuffer):
+ * runtime/JSArrayBufferPrototype.cpp:
+ (JSC::arrayBufferProtoFuncSlice):
+ * runtime/JSGenericTypedArrayViewInlines.h:
+ (JSC::JSGenericTypedArrayView<Adaptor>::create):
+ (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
+ * runtime/NativeErrorConstructor.cpp:
+ (JSC::Interpreter::constructWithNativeErrorConstructor):
+ (JSC::Interpreter::callNativeErrorConstructor):
+ * runtime/VM.cpp:
+ (JSC::VM::throwException):
+ (JSC::appendSourceToError): Moved to Error.cpp
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor): Deleted.
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()): Deleted.
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::foundCallFrame): Deleted.
+ (JSC::FindFirstCallerFrameWithCodeblockFunctor::index): Deleted.
+ * tests/stress/freeze_leek.js: Added.
+
+2015-04-07 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ES6: Show Symbol properties on Objects
+ https://bugs.webkit.org/show_bug.cgi?id=141279
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Runtime.json:
+ Give PropertyDescriptor a reference to the Symbol RemoteObject
+ if the property is a symbol property.
+
+ * inspector/InjectedScriptSource.js:
+ Enumerate symbol properties on objects.
+
+2015-04-07 Filip Pizlo <fpizlo@apple.com>
+
+ Make it possible to enable LLVM FastISel
+ https://bugs.webkit.org/show_bug.cgi?id=143489
+
+ Reviewed by Michael Saboff.
+
+ The decision to enable FastISel is made by Options.h|cpp, but the LLVM library can disable it if it finds that it is built
+ against a version of LLVM that doesn't support it. Thereafter, JSC::enableLLVMFastISel is the flag that tells the system
+ if we should enable it.
+
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * llvm/InitializeLLVM.cpp:
+ (JSC::initializeLLVMImpl):
+ * llvm/InitializeLLVM.h:
+ * llvm/InitializeLLVMLinux.cpp:
+ (JSC::getLLVMInitializerFunction):
+ (JSC::initializeLLVMImpl): Deleted.
+ * llvm/InitializeLLVMMac.cpp:
+ (JSC::getLLVMInitializerFunction):
+ (JSC::initializeLLVMImpl): Deleted.
+ * llvm/InitializeLLVMPOSIX.cpp:
+ (JSC::getLLVMInitializerFunctionPOSIX):
+ (JSC::initializeLLVMPOSIX): Deleted.
+ * llvm/InitializeLLVMPOSIX.h:
+ * llvm/InitializeLLVMWin.cpp:
+ (JSC::getLLVMInitializerFunction):
+ (JSC::initializeLLVMImpl): Deleted.
+ * llvm/LLVMAPI.cpp:
+ * llvm/LLVMAPI.h:
+ * llvm/library/LLVMExports.cpp:
+ (initCommandLine):
+ (initializeAndGetJSCLLVMAPI):
+ * runtime/Options.cpp:
+ (JSC::Options::initialize):
+
+2015-04-06 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
+ https://bugs.webkit.org/show_bug.cgi?id=140426
+
+ Reviewed by Darin Adler.
+
+ In the put_by_val_direct operation, we use JSObject::putDirect.
+ However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
+ This patch checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
+
+ * dfg/DFGOperations.cpp:
+ (JSC::DFG::putByVal):
+ (JSC::DFG::operationPutByValInternal):
+ * jit/JITOperations.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/Identifier.h:
+ (JSC::isIndex):
+ (JSC::parseIndex):
+ * tests/stress/dfg-put-by-val-direct-with-edge-numbers.js: Added.
+ (lookupWithKey):
+ (toStringThrowsError.toString):
+
+2015-04-06 Alberto Garcia <berto@igalia.com>
+
+ [GTK] Fix HPPA build
+ https://bugs.webkit.org/show_bug.cgi?id=143453
+
+ Reviewed by Darin Adler.
+
+ Add HPPA to the list of supported CPUs.
+
+ * CMakeLists.txt:
+
+2015-04-06 Mark Lam <mark.lam@apple.com>
+
+ In the 64-bit DFG and FTL, Array::Double case for HasIndexedProperty should set its result to true when all is well.
+ <https://webkit.org/b/143396>
+
+ Reviewed by Filip Pizlo.
+
+ The DFG was neglecting to set the result boolean. The FTL was setting it with
+ an inverted value. Both of these are now resolved.
+
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileHasIndexedProperty):
+ * tests/stress/for-in-array-mode.js: Added.
+ (.):
+ (test):
+
+2015-04-06 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] DFG and FTL should be aware of that StringConstructor behavior for symbols becomes different from ToString
+ https://bugs.webkit.org/show_bug.cgi?id=143424
+
+ Reviewed by Geoffrey Garen.
+
+ In ES6, StringConstructor behavior becomes different from ToString abstract operations in the spec. (and JSValue::toString).
+
+ ToString(symbol) throws a type error.
+ However, String(symbol) produces SymbolDescriptiveString(symbol).
+
+ So, in DFG and FTL phase, they should not inline StringConstructor to ToString.
+
+ Now, in the template literals patch, ToString DFG operation is planned to be used.
+ And current ToString behavior is aligned to the spec (and JSValue::toString) and it's better.
+ So intead of changing ToString behavior, this patch adds CallStringConstructor operation into DFG and FTL.
+ In CallStringConstructor, all behavior in DFG analysis is the same.
+ Only the difference from ToString is, when calling DFG operation functions, it calls
+ operationCallStringConstructorOnCell and operationCallStringConstructor instead of
+ operationToStringOnCell and operationToString.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGBackwardsPropagationPhase.cpp:
+ (JSC::DFG::BackwardsPropagationPhase::propagate):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
+ (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
+ (JSC::DFG::FixupPhase::fixupToString): Deleted.
+ * 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::compileToStringOrCallStringConstructorOnCell):
+ (JSC::DFG::SpeculativeJIT::compileToStringOnCell): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGStructureRegistrationPhase.cpp:
+ (JSC::DFG::StructureRegistrationPhase::run):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
+ (JSC::FTL::LowerDFGToLLVM::compileToString): Deleted.
+ * runtime/StringConstructor.cpp:
+ (JSC::stringConstructor):
+ (JSC::callStringConstructor):
+ * runtime/StringConstructor.h:
+ * tests/stress/symbol-and-string-constructor.js: Added.
+ (performString):
+
+2015-04-06 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Return Optional<uint32_t> from PropertyName::asIndex
+ https://bugs.webkit.org/show_bug.cgi?id=143422
+
+ Reviewed by Darin Adler.
+
+ PropertyName::asIndex returns uint32_t and use UINT_MAX as NotAnIndex.
+ But it's not obvious to callers.
+
+ This patch changes
+ 1. PropertyName::asIndex() to return Optional<uint32_t> and
+ 2. function name `asIndex()` to `parseIndex()`.
+ It forces callers to check the value is index or not explicitly.
+
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeFor):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFor):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitDirectPutById):
+ * jit/Repatch.cpp:
+ (JSC::emitPutTransitionStubAndGetOldStructure):
+ * jsc.cpp:
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncSort):
+ * runtime/GenericArgumentsInlines.h:
+ (JSC::GenericArguments<Type>::getOwnPropertySlot):
+ (JSC::GenericArguments<Type>::put):
+ (JSC::GenericArguments<Type>::deleteProperty):
+ (JSC::GenericArguments<Type>::defineOwnProperty):
+ * runtime/Identifier.h:
+ (JSC::parseIndex):
+ (JSC::Identifier::isSymbol):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::defineOwnProperty):
+ * runtime/JSCJSValue.cpp:
+ (JSC::JSValue::putToPrimitive):
+ * runtime/JSGenericTypedArrayViewInlines.h:
+ (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
+ (JSC::JSGenericTypedArrayView<Adaptor>::put):
+ (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
+ (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::put):
+ (JSC::JSObject::putDirectAccessor):
+ (JSC::JSObject::putDirectCustomAccessor):
+ (JSC::JSObject::deleteProperty):
+ (JSC::JSObject::putDirectMayBeIndex):
+ (JSC::JSObject::defineOwnProperty):
+ * runtime/JSObject.h:
+ (JSC::JSObject::getOwnPropertySlot):
+ (JSC::JSObject::getPropertySlot):
+ (JSC::JSObject::putDirectInternal):
+ * runtime/JSString.cpp:
+ (JSC::JSString::getStringPropertyDescriptor):
+ * runtime/JSString.h:
+ (JSC::JSString::getStringPropertySlot):
+ * runtime/LiteralParser.cpp:
+ (JSC::LiteralParser<CharType>::parse):
+ * runtime/PropertyName.h:
+ (JSC::parseIndex):
+ (JSC::toUInt32FromCharacters): Deleted.
+ (JSC::toUInt32FromStringImpl): Deleted.
+ (JSC::PropertyName::asIndex): Deleted.
+ * runtime/PropertyNameArray.cpp:
+ (JSC::PropertyNameArray::add):
+ * runtime/StringObject.cpp:
+ (JSC::StringObject::deleteProperty):
+ * runtime/Structure.cpp:
+ (JSC::Structure::prototypeChainMayInterceptStoreTo):
+
+2015-04-05 Andreas Kling <akling@apple.com>
+
+ URI encoding/escaping should use efficient string building instead of calling snprintf().
+ <https://webkit.org/b/143426>
+
+ Reviewed by Gavin Barraclough.
+
+ I saw 0.5% of main thread time in snprintf() on <http://polymerlabs.github.io/benchmarks/>
+ which seemed pretty silly. This change gets that down to nothing in favor of using our
+ existing JSStringBuilder and HexNumber.h facilities.
+
+ These APIs are well-exercised by our existing test suite.
+
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::encode):
+ (JSC::globalFuncEscape):
+
+2015-04-05 Masataka Yakura <masataka.yakura@gmail.com>
+
+ documentation for ES Promises points to the wrong one
+ https://bugs.webkit.org/show_bug.cgi?id=143263
+
+ Reviewed by Darin Adler.
+
+ * features.json:
+
+2015-04-05 Simon Fraser <simon.fraser@apple.com>
+
+ Remove "go ahead and" from comments
+ https://bugs.webkit.org/show_bug.cgi?id=143421
+
+ Reviewed by Darin Adler, Benjamin Poulain.
+
+ Remove the phrase "go ahead and" from comments where it doesn't add
+ anything (which is almost all of them).
+
+ * interpreter/JSStack.cpp:
+ (JSC::JSStack::growSlowCase):
+
+2015-04-04 Andreas Kling <akling@apple.com>
+
+ Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
+ <https://webkit.org/b/143210>
+
+ Reviewed by Geoffrey Garen.
+
+ Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
+ we had a little problem where WeakBlocks with only null pointers would still keep their
+ MarkedBlock alive.
+
+ This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
+ that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
+ to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
+ destroying them once they're fully dead.
+
+ This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
+ a mysterious issue where doing two full garbage collections back-to-back would free additional
+ memory in the second collection.
+
+ Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
+ an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
+ calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.
+
+ * heap/Heap.h:
+ * heap/Heap.cpp:
+ (JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
+ owned by Heap, after everything else has been swept.
+
+ (JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
+ after a full garbage collection ends. Note that we don't do this after Eden collections, since
+ they are unlikely to cause entire WeakBlocks to go empty.
+
+ (JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
+ to the Heap when it's detached from a WeakSet.
+
+ (JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
+ of the logically empty WeakBlocks owned by Heap.
+
+ (JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
+ and updates the next-logically-empty-weak-block-to-sweep index.
+
+ (JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
+ won't be another chance after this.
+
+ * heap/IncrementalSweeper.h:
+ (JSC::IncrementalSweeper::hasWork): Deleted.
+
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::fullSweep):
+ (JSC::IncrementalSweeper::doSweep):
+ (JSC::IncrementalSweeper::sweepNextBlock): Restructured IncrementalSweeper a bit to simplify
+ adding a new sweeping stage for the Heap's logically empty WeakBlocks. sweepNextBlock() is
+ changed to return a bool (true if there's more work to be done.)
+
+ * heap/WeakBlock.cpp:
+ (JSC::WeakBlock::sweep): This now figures out if the WeakBlock is logically empty, i.e doesn't
+ contain any pointers to live objects. The answer is stored in a new SweepResult member.
+
+ * heap/WeakBlock.h:
+ (JSC::WeakBlock::isLogicallyEmptyButNotFree): Added. Can be queried after a sweep to determine
+ if the WeakBlock could be detached from the MarkedBlock.
+
+ (JSC::WeakBlock::SweepResult::SweepResult): Deleted in favor of initializing member variables
+ when declaring them.
+
+2015-04-04 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Implement ES6 Object.getOwnPropertySymbols
+ https://bugs.webkit.org/show_bug.cgi?id=141106
+
+ Reviewed by Geoffrey Garen.
+
+ This patch implements `Object.getOwnPropertySymbols`.
+ One technical issue is that, since we use private symbols (such as `@Object`) in the
+ privileged JS code in `builtins/`, they should not be exposed.
+ To distinguish them from the usual symbols, check the target `StringImpl*` is a not private name
+ before adding it into PropertyNameArray.
+
+ To check the target `StringImpl*` is a private name, we leverage privateToPublic map in `BuiltinNames`
+ since all private symbols are held in this map.
+
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createExecutableInternal):
+ * builtins/BuiltinNames.h:
+ (JSC::BuiltinNames::isPrivateName):
+ * runtime/CommonIdentifiers.cpp:
+ (JSC::CommonIdentifiers::isPrivateName):
+ * runtime/CommonIdentifiers.h:
+ * runtime/EnumerationMode.h:
+ (JSC::EnumerationMode::EnumerationMode):
+ (JSC::EnumerationMode::includeSymbolProperties):
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::createUndefinedVariableError):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
+ * runtime/JSSymbolTableObject.cpp:
+ (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructor::finishCreation):
+ (JSC::objectConstructorGetOwnPropertySymbols):
+ (JSC::defineProperties):
+ (JSC::objectConstructorSeal):
+ (JSC::objectConstructorFreeze):
+ (JSC::objectConstructorIsSealed):
+ (JSC::objectConstructorIsFrozen):
+ * runtime/ObjectConstructor.h:
+ (JSC::ObjectConstructor::create):
+ * runtime/Structure.cpp:
+ (JSC::Structure::getPropertyNamesFromStructure):
+ * tests/stress/object-get-own-property-symbols-perform-to-object.js: Added.
+ (compare):
+ * tests/stress/object-get-own-property-symbols.js: Added.
+ (forIn):
+ * tests/stress/symbol-define-property.js: Added.
+ (testSymbol):
+ * tests/stress/symbol-seal-and-freeze.js: Added.
+ * tests/stress/symbol-with-json.js: Added.
+
+2015-04-03 Mark Lam <mark.lam@apple.com>
+
+ Add Options::jitPolicyScale() as a single knob to make all compilations happen sooner.
+ <https://webkit.org/b/143385>
+
+ Reviewed by Geoffrey Garen.
+
+ For debugging purposes, sometimes, we want to be able to make compilation happen
+ sooner to see if we can accelerate the manifestation of certain events / bugs.
+ Currently, in order to achieve this, we'll have to tweak multiple JIT thresholds
+ which make up the compilation policy. Let's add a single knob that can tune all
+ the thresholds up / down in one go proportionately so that we can easily tweak
+ how soon compilation occurs.
+
+ * runtime/Options.cpp:
+ (JSC::scaleJITPolicy):
+ (JSC::recomputeDependentOptions):
+ * runtime/Options.h:
+
+2015-04-03 Geoffrey Garen <ggaren@apple.com>
+
+ is* API methods should be @properties
+ https://bugs.webkit.org/show_bug.cgi?id=143388
+
+ Reviewed by Mark Lam.
+
+ This appears to be the preferred idiom in WebKit, CA, AppKit, and
+ Foundation.
+
+ * API/JSValue.h: Be @properties.
+
+ * API/tests/testapi.mm:
+ (testObjectiveCAPI): Use the @properties.
+
+2015-04-03 Mark Lam <mark.lam@apple.com>
+
+ Some JSC Options refactoring and enhancements.
+ <https://webkit.org/b/143384>
+
+ Rubber stamped by Benjamin Poulain.
+
+ Create a better encapsulated Option class to make working with options easier. This
+ is a building block towards a JIT policy scaling debugging option I will introduce later.
+
+ This work entails:
+ 1. Convert Options::Option into a public class Option (who works closely with Options).
+ 2. Convert Options::EntryType into an enum class Options::Type and make it public.
+ 3. Renamed Options::OPT_<option name> to Options::<option name>ID because it reads better.
+ 4. Add misc methods to class Option to make it more useable.
+
+ * runtime/Options.cpp:
+ (JSC::Options::dumpOption):
+ (JSC::Option::dump):
+ (JSC::Option::operator==):
+ (JSC::Options::Option::dump): Deleted.
+ (JSC::Options::Option::operator==): Deleted.
+ * runtime/Options.h:
+ (JSC::Option::Option):
+ (JSC::Option::operator!=):
+ (JSC::Option::name):
+ (JSC::Option::description):
+ (JSC::Option::type):
+ (JSC::Option::isOverridden):
+ (JSC::Option::defaultOption):
+ (JSC::Option::boolVal):
+ (JSC::Option::unsignedVal):
+ (JSC::Option::doubleVal):
+ (JSC::Option::int32Val):
+ (JSC::Option::optionRangeVal):
+ (JSC::Option::optionStringVal):
+ (JSC::Option::gcLogLevelVal):
+ (JSC::Options::Option::Option): Deleted.
+ (JSC::Options::Option::operator!=): Deleted.
+
+2015-04-03 Geoffrey Garen <ggaren@apple.com>
+
+ JavaScriptCore API should support type checking for Array and Date
+ https://bugs.webkit.org/show_bug.cgi?id=143324
+
+ Follow-up to address a comment by Dan.
+
+ * API/WebKitAvailability.h: __MAC_OS_X_VERSION_MIN_REQUIRED <= 101100
+ is wrong, since this API is available when __MAC_OS_X_VERSION_MIN_REQUIRED
+ is equal to 101100.
+
+2015-04-03 Geoffrey Garen <ggaren@apple.com>
+
+ JavaScriptCore API should support type checking for Array and Date
+ https://bugs.webkit.org/show_bug.cgi?id=143324
+
+ Follow-up to address a comment by Dan.
+
+ * API/WebKitAvailability.h: Do use 10.0 because it was right all along.
+ Added a comment explaining why.
+
+2015-04-03 Csaba Osztrogonác <ossy@webkit.org>
+
+ FTL JIT tests should fail if LLVM library isn't available
+ https://bugs.webkit.org/show_bug.cgi?id=143374
+
+ Reviewed by Mark Lam.
+
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * runtime/Options.h:
+
+2015-04-03 Zan Dobersek <zdobersek@igalia.com>
+
+ Fix the EFL and GTK build after r182243
+ https://bugs.webkit.org/show_bug.cgi?id=143361
+
+ Reviewed by Csaba Osztrogonác.
+
+ * CMakeLists.txt: InspectorBackendCommands.js is generated in the
+ DerivedSources/JavaScriptCore/inspector/ directory.
+
+2015-04-03 Zan Dobersek <zdobersek@igalia.com>
+
+ Unreviewed, fixing Clang builds of the GTK port on Linux.
+
+ * runtime/Options.cpp:
+ Include the <math.h> header for isnan().
+
+2015-04-02 Mark Lam <mark.lam@apple.com>
+
+ Enhance ability to dump JSC Options.
+ <https://webkit.org/b/143357>
+
+ Reviewed by Benjamin Poulain.
+
+ Some enhancements to how the JSC options work:
+
+ 1. Add a JSC_showOptions option which take values: 0 = None, 1 = Overridden only,
+ 2 = All, 3 = Verbose.
+
+ The default is 0 (None). This dumps nothing.
+ With the Overridden setting, at VM initialization time, we will dump all
+ option values that have been changed from their default.
+ With the All setting, at VM initialization time, we will dump all option values.
+ With the Verbose setting, at VM initialization time, we will dump all option
+ values along with their descriptions (if available).
+
+ 2. We now store a copy of the default option values.
+
+ We later use this for comparison to tell if an option has been overridden, and
+ print the default value for reference. As a result, we no longer need the
+ didOverride flag since we can compute whether the option is overridden at any time.
+
+ 3. Added description strings to some options to be printed when JSC_showOptions=3 (Verbose).
+
+ This will come in handy later when we want to rename some of the options to more sane
+ names that are easier to remember. For example, we can change
+ Options::dfgFunctionWhitelistFile() to Options::dfgWhiteList(), and
+ Options::slowPathAllocsBetweenGCs() to Options::forcedGcRate(). With the availability
+ of the description, we can afford to use shorter and less descriptive option names,
+ but they will be easier to remember and use for day to day debugging work.
+
+ In this patch, I did not change the names of any of the options yet. I only added
+ description strings for options that I know about, and where I think the option name
+ isn't already descriptive enough.
+
+ 4. Also deleted some unused code.
+
+ * jsc.cpp:
+ (CommandLine::parseArguments):
+ * runtime/Options.cpp:
+ (JSC::Options::initialize):
+ (JSC::Options::setOption):
+ (JSC::Options::dumpAllOptions):
+ (JSC::Options::dumpOption):
+ (JSC::Options::Option::dump):
+ (JSC::Options::Option::operator==):
+ * runtime/Options.h:
+ (JSC::OptionRange::rangeString):
+ (JSC::Options::Option::Option):
+ (JSC::Options::Option::operator!=):
+
+2015-04-02 Geoffrey Garen <ggaren@apple.com>
+
+ JavaScriptCore API should support type checking for Array and Date
+ https://bugs.webkit.org/show_bug.cgi?id=143324
+
+ Reviewed by Darin Adler, Sam Weinig, Dan Bernstein.
+
+ * API/JSValue.h:
+ * API/JSValue.mm:
+ (-[JSValue isArray]):
+ (-[JSValue isDate]): Added an ObjC API.
+
+ * API/JSValueRef.cpp:
+ (JSValueIsArray):
+ (JSValueIsDate):
+ * API/JSValueRef.h: Added a C API.
+
+ * API/WebKitAvailability.h: Brought our availability macros up to date
+ and fixed a harmless bug where "10_10" translated to "10.0".
+
+ * API/tests/testapi.c:
+ (main): Added a test and corrected a pre-existing leak.
+
+ * API/tests/testapi.mm:
+ (testObjectiveCAPI): Added a test.
+
+2015-04-02 Mark Lam <mark.lam@apple.com>
+
+ Add Options::dumpSourceAtDFGTime().
+ <https://webkit.org/b/143349>
+
+ Reviewed by Oliver Hunt, and Michael Saboff.
+
+ Sometimes, we will want to see the JS source code that we're compiling, and it
+ would be nice to be able to do this without having to jump thru a lot of hoops.
+ So, let's add a Options::dumpSourceAtDFGTime() option just like we have a
+ Options::dumpBytecodeAtDFGTime() option.
+
+ Also added versions of CodeBlock::dumpSource() and CodeBlock::dumpBytecode()
+ that explicitly take no arguments (instead of relying on the version that takes
+ the default argument). These versions are friendlier to use when we want to call
+ them from an interactive debugging session.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpSource):
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecode/CodeBlock.h:
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseCodeBlock):
+ * runtime/Options.h:
+
+2015-04-02 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Clean up EnumerationMode to easily extend
+ https://bugs.webkit.org/show_bug.cgi?id=143276
+
+ Reviewed by Geoffrey Garen.
+
+ To make the followings easily,
+ 1. Adding new flag Include/ExcludeSymbols in the Object.getOwnPropertySymbols patch
+ 2. Make ExcludeSymbols implicitly default for the existing flags
+ we encapsulate EnumerationMode flags into EnumerationMode class.
+
+ And this class manages 2 flags. Later it will be extended to 3.
+ 1. DontEnumPropertiesMode (default is Exclude)
+ 2. JSObjectPropertiesMode (default is Include)
+ 3. SymbolPropertiesMode (default is Exclude)
+ SymbolPropertiesMode will be added in Object.getOwnPropertySymbols patch.
+
+ This patch replaces places using ExcludeDontEnumProperties
+ to EnumerationMode() value which represents default mode.
+
+ * API/JSCallbackObjectFunctions.h:
+ (JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
+ * API/JSObjectRef.cpp:
+ (JSObjectCopyPropertyNames):
+ * bindings/ScriptValue.cpp:
+ (Deprecated::jsToInspectorValue):
+ * bytecode/ObjectAllocationProfile.h:
+ (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncSort):
+ * runtime/EnumerationMode.h:
+ (JSC::EnumerationMode::EnumerationMode):
+ (JSC::EnumerationMode::includeDontEnumProperties):
+ (JSC::EnumerationMode::includeJSObjectProperties):
+ (JSC::shouldIncludeDontEnumProperties): Deleted.
+ (JSC::shouldExcludeDontEnumProperties): Deleted.
+ (JSC::shouldIncludeJSObjectPropertyNames): Deleted.
+ (JSC::modeThatSkipsJSObject): Deleted.
+ * runtime/GenericArgumentsInlines.h:
+ (JSC::GenericArguments<Type>::getOwnPropertyNames):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::getOwnNonIndexPropertyNames):
+ * runtime/JSArrayBuffer.cpp:
+ (JSC::JSArrayBuffer::getOwnNonIndexPropertyNames):
+ * runtime/JSArrayBufferView.cpp:
+ (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::getOwnNonIndexPropertyNames):
+ * runtime/JSFunction.h:
+ * runtime/JSGenericTypedArrayViewInlines.h:
+ (JSC::JSGenericTypedArrayView<Adaptor>::getOwnNonIndexPropertyNames):
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::Holder::appendNextProperty):
+ (JSC::Walker::walk):
+ * runtime/JSObject.cpp:
+ (JSC::getClassPropertyNames):
+ (JSC::JSObject::getOwnPropertyNames):
+ (JSC::JSObject::getOwnNonIndexPropertyNames):
+ (JSC::JSObject::getGenericPropertyNames):
+ * runtime/JSPropertyNameEnumerator.h:
+ (JSC::propertyNameEnumerator):
+ * runtime/JSSymbolTableObject.cpp:
+ (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorGetOwnPropertyNames):
+ (JSC::objectConstructorKeys):
+ (JSC::defineProperties):
+ (JSC::objectConstructorSeal):
+ (JSC::objectConstructorFreeze):
+ (JSC::objectConstructorIsSealed):
+ (JSC::objectConstructorIsFrozen):
+ * runtime/RegExpObject.cpp:
+ (JSC::RegExpObject::getOwnNonIndexPropertyNames):
+ (JSC::RegExpObject::getPropertyNames):
+ (JSC::RegExpObject::getGenericPropertyNames):
+ * runtime/StringObject.cpp:
+ (JSC::StringObject::getOwnPropertyNames):
+ * runtime/Structure.cpp:
+ (JSC::Structure::getPropertyNamesFromStructure):
+
+2015-04-01 Alex Christensen <achristensen@webkit.org>
+
+ Progress towards CMake on Windows and Mac.
+ https://bugs.webkit.org/show_bug.cgi?id=143293
+
+ Reviewed by Filip Pizlo.
+
+ * CMakeLists.txt:
+ Enabled using assembly on Windows.
+ Replaced unix commands with CMake commands.
+ * PlatformMac.cmake:
+ Tell open source builders where to find unicode headers.
+
+2015-04-01 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ IteratorClose should be called when jumping over the target for-of loop
+ https://bugs.webkit.org/show_bug.cgi?id=143140
+
+ Reviewed by Geoffrey Garen.
+
+ This patch fixes labeled break/continue behaviors with for-of and iterators.
+
+ 1. Support IteratorClose beyond multiple loop contexts
+ Previously, IteratorClose is only executed in for-of's breakTarget().
+ However, this misses IteratorClose execution when statement roll-ups multiple control flow contexts.
+ For example,
+ outer: for (var e1 of outer) {
+ inner: for (var e2 of inner) {
+ break outer;
+ }
+ }
+ In this case, return method of inner should be called.
+ We leverage the existing system for `finally` to execute inner.return method correctly.
+ Leveraging `finally` system fixes `break`, `continue` and `return` cases.
+ `throw` case is already supported by emitting try-catch handlers in for-of.
+
+ 2. Incorrect LabelScope creation is done in ForOfNode
+ ForOfNode creates duplicated LabelScope.
+ It causes infinite loop when executing the following program that contains
+ explicitly labeled for-of loop.
+ For example,
+ inner: for (var elm of array) {
+ continue inner;
+ }
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::pushFinallyContext):
+ (JSC::BytecodeGenerator::pushIteratorCloseContext):
+ (JSC::BytecodeGenerator::popFinallyContext):
+ (JSC::BytecodeGenerator::popIteratorCloseContext):
+ (JSC::BytecodeGenerator::emitComplexPopScopes):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::emitIteratorClose):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ForOfNode::emitBytecode):
+ * tests/stress/iterator-return-beyond-multiple-iteration-scopes.js: Added.
+ (createIterator.iterator.return):
+ (createIterator):
+ * tests/stress/raise-error-in-iterator-close.js: Added.
+ (createIterator.iterator.return):
+ (createIterator):
+
+2015-04-01 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Implement Symbol.unscopables
+ https://bugs.webkit.org/show_bug.cgi?id=142829
+
+ Reviewed by Geoffrey Garen.
+
+ This patch introduces Symbol.unscopables functionality.
+ In ES6, some generic names (like keys, values) are introduced
+ as Array's method name. And this breaks the web since some web sites
+ use like the following code.
+
+ var values = ...;
+ with (array) {
+ values; // This values is trapped by array's method "values".
+ }
+
+ To fix this, Symbol.unscopables introduces blacklist
+ for with scope's trapping. When resolving scope,
+ if name is found in the target scope and the target scope is with scope,
+ we check Symbol.unscopables object to filter generic names.
+
+ This functionality is only active for with scopes.
+ Global scope does not have unscopables functionality.
+
+ And since
+ 1) op_resolve_scope for with scope always return Dynamic resolve type,
+ 2) in that case, JSScope::resolve is always used in JIT and LLInt,
+ 3) the code which contains op_resolve_scope that returns Dynamic cannot be compiled with DFG and FTL,
+ to implement this functionality, we just change JSScope::resolve and no need to change JIT code.
+ So performance regression is only visible in Dynamic resolving case, and it is already much slow.
+
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::runtimeFlags):
+ * runtime/JSScope.cpp:
+ (JSC::isUnscopable):
+ (JSC::JSScope::resolve):
+ * runtime/JSScope.h:
+ (JSC::ScopeChainIterator::scope):
+ * tests/stress/global-environment-does-not-trap-unscopables.js: Added.
+ (test):
+ * tests/stress/unscopables.js: Added.
+ (test):
+ (.):
+
+2015-03-31 Ryosuke Niwa <rniwa@webkit.org>
+
+ ES6 class syntax should allow static setters and getters
+ https://bugs.webkit.org/show_bug.cgi?id=143180
+
+ Reviewed by Filip Pizlo
+
+ Apparently I misread the spec when I initially implemented parseClass.
+ ES6 class syntax allows static getters and setters so just allow that.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+
+2015-03-31 Filip Pizlo <fpizlo@apple.com>
+
+ PutClosureVar CSE def() rule has a wrong base
+ https://bugs.webkit.org/show_bug.cgi?id=143280
+
+ Reviewed by Michael Saboff.
+
+ I think that this code was incorrect in a benign way, since the base of a
+ PutClosureVar is not a JS-visible object. But it was preventing some optimizations.
+
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+
+2015-03-31 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r182200.
+ https://bugs.webkit.org/show_bug.cgi?id=143279
+
+ Probably causing assertion extravaganza on bots. (Requested by
+ kling on #webkit).
+
+ Reverted changeset:
+
+ "Logically empty WeakBlocks should not pin down their
+ MarkedBlocks indefinitely."
+ https://bugs.webkit.org/show_bug.cgi?id=143210
+ http://trac.webkit.org/changeset/182200
+
+2015-03-31 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Clean up Identifier factories to clarify the meaning of StringImpl*
+ https://bugs.webkit.org/show_bug.cgi?id=143146
+
+ Reviewed by Filip Pizlo.
+
+ In the a lot of places, `Identifier(VM*/ExecState*, StringImpl*)` constructor is used.
+ However, it's ambiguous because `StringImpl*` has 2 different meanings.
+ 1) normal string, it is replacable with `WTFString` and
+ 2) `uid`, which holds `isSymbol` information to represent Symbols.
+ So we dropped Identifier constructors for strings and instead, introduced 2 factory functions.
+ + `Identifier::fromString(VM*/ExecState*, const String&)`.
+ Just construct Identifier from strings. The symbol-ness of StringImpl* is not kept.
+ + `Identifier::fromUid(VM*/ExecState*, StringImpl*)`.
+ This function is used for 2) `uid`. So symbol-ness of `StringImpl*` is kept.
+
+ And to clean up `StringImpl` which is used as uid,
+ we introduce `StringKind` into `StringImpl`. There's 3 kinds
+ 1. StringNormal (non-atomic, non-symbol)
+ 2. StringAtomic (atomic, non-symbol)
+ 3. StringSymbol (non-atomic, symbol)
+ They are mutually exclusive. And (atomic, symbol) case should not exist.
+
+ * API/JSCallbackObjectFunctions.h:
+ (JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames):
+ * API/JSObjectRef.cpp:
+ (JSObjectMakeFunction):
+ * API/OpaqueJSString.cpp:
+ (OpaqueJSString::identifier):
+ * bindings/ScriptFunctionCall.cpp:
+ (Deprecated::ScriptFunctionCall::call):
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createExecutableInternal):
+ * builtins/BuiltinNames.h:
+ (JSC::BuiltinNames::BuiltinNames):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::emitThrowReferenceError):
+ (JSC::BytecodeGenerator::emitThrowTypeError):
+ (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ * dfg/DFGDesiredIdentifiers.cpp:
+ (JSC::DFG::DesiredIdentifiers::reallyAdd):
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::functionDetails):
+ (Inspector::constructInternalProperty):
+ (Inspector::JSInjectedScriptHost::weakMapEntries):
+ (Inspector::JSInjectedScriptHost::iteratorEntries):
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ * inspector/JSJavaScriptCallFramePrototype.cpp:
+ * inspector/ScriptCallStackFactory.cpp:
+ (Inspector::extractSourceInformationFromException):
+ * jit/JITOperations.cpp:
+ * jsc.cpp:
+ (GlobalObject::finishCreation):
+ (GlobalObject::addFunction):
+ (GlobalObject::addConstructableFunction):
+ (functionRun):
+ (runWithScripts):
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * llint/LowLevelInterpreter.asm:
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::addVar):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner):
+ (JSC::Parser<LexerType>::createBindingPattern):
+ * parser/ParserArena.h:
+ (JSC::IdentifierArena::makeIdentifier):
+ (JSC::IdentifierArena::makeIdentifierLCharFromUChar):
+ (JSC::IdentifierArena::makeNumericIdentifier):
+ * runtime/ArgumentsIteratorPrototype.cpp:
+ (JSC::ArgumentsIteratorPrototype::finishCreation):
+ * runtime/ArrayIteratorPrototype.cpp:
+ (JSC::ArrayIteratorPrototype::finishCreation):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::ArrayPrototype::finishCreation):
+ (JSC::arrayProtoFuncPush):
+ * runtime/ClonedArguments.cpp:
+ (JSC::ClonedArguments::getOwnPropertySlot):
+ * runtime/CommonIdentifiers.cpp:
+ (JSC::CommonIdentifiers::CommonIdentifiers):
+ * runtime/CommonIdentifiers.h:
+ * runtime/Error.cpp:
+ (JSC::addErrorInfo):
+ (JSC::hasErrorInfo):
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::createUndefinedVariableError):
+ * runtime/GenericArgumentsInlines.h:
+ (JSC::GenericArguments<Type>::getOwnPropertySlot):
+ * runtime/Identifier.h:
+ (JSC::Identifier::isSymbol):
+ (JSC::Identifier::Identifier):
+ (JSC::Identifier::from): Deleted.
+ * runtime/IdentifierInlines.h:
+ (JSC::Identifier::Identifier):
+ (JSC::Identifier::fromUid):
+ (JSC::Identifier::fromString):
+ * runtime/JSCJSValue.cpp:
+ (JSC::JSValue::dumpInContextAssumingStructure):
+ * runtime/JSCJSValueInlines.h:
+ (JSC::JSValue::toPropertyKey):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
+ * runtime/JSObject.cpp:
+ (JSC::getClassPropertyNames):
+ (JSC::JSObject::reifyStaticFunctionsForDelete):
+ * runtime/JSObject.h:
+ (JSC::makeIdentifier):
+ * runtime/JSPromiseConstructor.cpp:
+ (JSC::JSPromiseConstructorFuncRace):
+ (JSC::JSPromiseConstructorFuncAll):
+ * runtime/JSString.h:
+ (JSC::JSString::toIdentifier):
+ * runtime/JSSymbolTableObject.cpp:
+ (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
+ * runtime/LiteralParser.cpp:
+ (JSC::LiteralParser<CharType>::tryJSONPParse):
+ (JSC::LiteralParser<CharType>::makeIdentifier):
+ * runtime/Lookup.h:
+ (JSC::reifyStaticProperties):
+ * runtime/MapConstructor.cpp:
+ (JSC::constructMap):
+ * runtime/MapIteratorPrototype.cpp:
+ (JSC::MapIteratorPrototype::finishCreation):
+ * runtime/MapPrototype.cpp:
+ (JSC::MapPrototype::finishCreation):
+ * runtime/MathObject.cpp:
+ (JSC::MathObject::finishCreation):
+ * runtime/NumberConstructor.cpp:
+ (JSC::NumberConstructor::finishCreation):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructor::finishCreation):
+ * runtime/PrivateName.h:
+ (JSC::PrivateName::PrivateName):
+ * runtime/PropertyMapHashTable.h:
+ (JSC::PropertyTable::find):
+ (JSC::PropertyTable::get):
+ * runtime/PropertyName.h:
+ (JSC::PropertyName::PropertyName):
+ (JSC::PropertyName::publicName):
+ (JSC::PropertyName::asIndex):
+ * runtime/PropertyNameArray.cpp:
+ (JSC::PropertyNameArray::add):
+ * runtime/PropertyNameArray.h:
+ (JSC::PropertyNameArray::addKnownUnique):
+ * runtime/RegExpConstructor.cpp:
+ (JSC::RegExpConstructor::finishCreation):
+ * runtime/SetConstructor.cpp:
+ (JSC::constructSet):
+ * runtime/SetIteratorPrototype.cpp:
+ (JSC::SetIteratorPrototype::finishCreation):
+ * runtime/SetPrototype.cpp:
+ (JSC::SetPrototype::finishCreation):
+ * runtime/StringIteratorPrototype.cpp:
+ (JSC::StringIteratorPrototype::finishCreation):
+ * runtime/StringPrototype.cpp:
+ (JSC::StringPrototype::finishCreation):
+ * runtime/Structure.cpp:
+ (JSC::Structure::getPropertyNamesFromStructure):
+ * runtime/SymbolConstructor.cpp:
+ * runtime/VM.cpp:
+ (JSC::VM::throwException):
+ * runtime/WeakMapConstructor.cpp:
+ (JSC::constructWeakMap):
+
+2015-03-31 Andreas Kling <akling@apple.com>
+
+ Logically empty WeakBlocks should not pin down their MarkedBlocks indefinitely.
+ <https://webkit.org/b/143210>
+
+ Reviewed by Geoffrey Garen.
+
+ Since a MarkedBlock cannot be destroyed until all the WeakBlocks pointing into it are gone,
+ we had a little problem where WeakBlocks with only null pointers would still keep their
+ MarkedBlock alive.
+
+ This patch fixes that by detaching WeakBlocks from their MarkedBlock once a sweep discovers
+ that the WeakBlock contains no pointers to live objects. Ownership of the WeakBlock is passed
+ to the Heap, which will sweep the list of these detached WeakBlocks as part of a full GC,
+ destroying them once they're fully dead.
+
+ This allows the garbage collector to reclaim the 64kB MarkedBlocks much sooner, and resolves
+ a mysterious issue where doing two full garbage collections back-to-back would free additional
+ memory in the second collection.
+
+ Management of detached WeakBlocks is implemented as a Vector<WeakBlock*> in Heap, along with
+ an index of the next block in that vector that needs to be swept. The IncrementalSweeper then
+ calls into Heap::sweepNextLogicallyEmptyWeakBlock() to sweep one block at a time.
+
+ * heap/Heap.h:
+ * heap/Heap.cpp:
+ (JSC::Heap::collectAllGarbage): Add a final pass where we sweep the logically empty WeakBlocks
+ owned by Heap, after everything else has been swept.
+
+ (JSC::Heap::notifyIncrementalSweeper): Set up an incremental sweep of logically empty WeakBlocks
+ after a full garbage collection ends. Note that we don't do this after Eden collections, since
+ they are unlikely to cause entire WeakBlocks to go empty.
+
+ (JSC::Heap::addLogicallyEmptyWeakBlock): Added. Interface for passing ownership of a WeakBlock
+ to the Heap when it's detached from a WeakSet.
+
+ (JSC::Heap::sweepAllLogicallyEmptyWeakBlocks): Helper for collectAllGarbage() that sweeps all
+ of the logically empty WeakBlocks owned by Heap.
+
+ (JSC::Heap::sweepNextLogicallyEmptyWeakBlock): Sweeps one logically empty WeakBlock if needed
+ and updates the next-logically-empty-weak-block-to-sweep index.
+
+ (JSC::Heap::lastChanceToFinalize): call sweepAllLogicallyEmptyWeakBlocks() here, since there
+ won't be another chance after this.
+
+ * heap/IncrementalSweeper.h:
+ (JSC::IncrementalSweeper::hasWork): Deleted.
+
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::fullSweep):
+ (JSC::IncrementalSweeper::doSweep):
+ (JSC::IncrementalSweeper::sweepNextBlock): Restructured IncrementalSweeper a bit to simplify
+ adding a new sweeping stage for the Heap's logically empty WeakBlocks. sweepNextBlock() is
+ changed to return a bool (true if there's more work to be done.)
+
+ * heap/WeakBlock.cpp:
+ (JSC::WeakBlock::sweep): This now figures out if the WeakBlock is logically empty, i.e doesn't
+ contain any pointers to live objects. The answer is stored in a new SweepResult member.
+
+ * heap/WeakBlock.h:
+ (JSC::WeakBlock::isLogicallyEmptyButNotFree): Added. Can be queried after a sweep to determine
+ if the WeakBlock could be detached from the MarkedBlock.
+
+ (JSC::WeakBlock::SweepResult::SweepResult): Deleted in favor of initializing member variables
+ when declaring them.
+
+2015-03-31 Ryosuke Niwa <rniwa@webkit.org>
+
+ eval("this.foo") causes a crash if this had not been initialized in a derived class's constructor
+ https://bugs.webkit.org/show_bug.cgi?id=142883
+
+ Reviewed by Filip Pizlo.
+
+ The crash was caused by eval inside the constructor of a derived class not checking TDZ.
+
+ Fixed the bug by adding a parser flag that forces the TDZ check to be always emitted when accessing "this"
+ in eval inside a derived class' constructor.
+
+ * bytecode/EvalCodeCache.h:
+ (JSC::EvalCodeCache::getSlow):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ThisNode::emitBytecode):
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::evaluate):
+ * interpreter/Interpreter.cpp:
+ (JSC::eval):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::thisExpr):
+ * parser/NodeConstructors.h:
+ (JSC::ThisNode::ThisNode):
+ * parser/Nodes.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::Parser):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ * parser/Parser.h:
+ (JSC::parse):
+ * parser/ParserModes.h:
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::thisExpr):
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ (JSC::CodeCache::getProgramCodeBlock):
+ (JSC::CodeCache::getEvalCodeBlock):
+ * runtime/CodeCache.h:
+ (JSC::SourceCodeKey::SourceCodeKey):
+ * runtime/Executable.cpp:
+ (JSC::EvalExecutable::create):
+ * runtime/Executable.h:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::createEvalCodeBlock):
+ * runtime/JSGlobalObject.h:
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::globalFuncEval):
+ * tests/stress/class-syntax-no-tdz-in-eval.js: Added.
+ * tests/stress/class-syntax-tdz-in-eval.js: Added.
+
+2015-03-31 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r182186.
+ https://bugs.webkit.org/show_bug.cgi?id=143270
+
+ it crashes all the WebGL tests on the Debug bots (Requested by
+ dino on #webkit).
+
+ Reverted changeset:
+
+ "Web Inspector: add 2D/WebGL canvas instrumentation
+ infrastructure"
+ https://bugs.webkit.org/show_bug.cgi?id=137278
+ http://trac.webkit.org/changeset/182186
+
+2015-03-31 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ [ES6] Object type restrictions on a first parameter of several Object.* functions are relaxed
+ https://bugs.webkit.org/show_bug.cgi?id=142937
+
+ Reviewed by Darin Adler.
+
+ In ES6, Object type restrictions on a first parameter of several Object.* functions are relaxed.
+ In ES5 or prior, when a first parameter is not object type, these functions raise TypeError.
+ But now, several functions perform ToObject onto a non-object parameter.
+ And others behaves as if a parameter is a non-extensible ordinary object with no own properties.
+ It is described in ES6 Annex E.
+ Functions different from ES5 are following.
+
+ 1. An attempt is make to coerce the argument using ToObject.
+ Object.getOwnPropertyDescriptor
+ Object.getOwnPropertyNames
+ Object.getPrototypeOf
+ Object.keys
+
+ 2. Treated as if it was a non-extensible ordinary object with no own properties.
+ Object.freeze
+ Object.isExtensible
+ Object.isFrozen
+ Object.isSealed
+ Object.preventExtensions
+ Object.seal
+
+ * runtime/ObjectConstructor.cpp:
+ (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
+ (JSC::objectConstructorGetPrototypeOf):
+ (JSC::objectConstructorGetOwnPropertyDescriptor):
+ (JSC::objectConstructorGetOwnPropertyNames):
+ (JSC::objectConstructorKeys):
+ (JSC::objectConstructorSeal):
+ (JSC::objectConstructorFreeze):
+ (JSC::objectConstructorPreventExtensions):
+ (JSC::objectConstructorIsSealed):
+ (JSC::objectConstructorIsFrozen):
+ (JSC::objectConstructorIsExtensible):
+ * tests/stress/object-freeze-accept-non-object.js: Added.
+ * tests/stress/object-get-own-property-descriptor-perform-to-object.js: Added.
+ (canary):
+ * tests/stress/object-get-own-property-names-perform-to-object.js: Added.
+ (compare):
+ * tests/stress/object-get-prototype-of-perform-to-object.js: Added.
+ * tests/stress/object-is-extensible-accept-non-object.js: Added.
+ * tests/stress/object-is-frozen-accept-non-object.js: Added.
+ * tests/stress/object-is-sealed-accept-non-object.js: Added.
+ * tests/stress/object-keys-perform-to-object.js: Added.
+ (compare):
+ * tests/stress/object-prevent-extensions-accept-non-object.js: Added.
+ * tests/stress/object-seal-accept-non-object.js: Added.
+
+2015-03-31 Matt Baker <mattbaker@apple.com>
+
+ Web Inspector: add 2D/WebGL canvas instrumentation infrastructure
+ https://bugs.webkit.org/show_bug.cgi?id=137278
+
+ Reviewed by Timothy Hatcher.
+
+ Added Canvas protocol which defines types used by InspectorCanvasAgent.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * inspector/protocol/Canvas.json: Added.
+
+ * inspector/scripts/codegen/generator.py:
+ (Generator.stylized_name_for_enum_value):
+ Added special handling for 2D (always uppercase) and WebGL (rename mapping) enum strings.
+
+2015-03-30 Ryosuke Niwa <rniwa@webkit.org>
+
+ Extending null should set __proto__ to null
+ https://bugs.webkit.org/show_bug.cgi?id=142882
+
+ Reviewed by Geoffrey Garen and Benjamin Poulain.
+
+ Set Derived.prototype.__proto__ to null when extending null.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ClassExprNode::emitBytecode):
+
+2015-03-30 Mark Lam <mark.lam@apple.com>
+
+ REGRESSION (r181993): inspector-protocol/debugger/setBreakpoint-dfg-and-modify-local.html crashes.
+ <https://webkit.org/b/143105>
+
+ Reviewed by Filip Pizlo.
+
+ With r181993, the DFG and FTL may elide the storing of the scope register. As a result,
+ on OSR exits from DFG / FTL frames where this elision has take place, we may get baseline
+ JIT frames that may have its scope register not set. The Debugger's current implementation
+ which relies on the scope register is not happy about this. For example, this results in a
+ crash in the layout test inspector-protocol/debugger/setBreakpoint-dfg-and-modify-local.html.
+
+ The fix is to disable inlining when the debugger is in use. Also, we add Flush nodes to
+ ensure that the scope register value is flushed to the register in the stack frame.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::ByteCodeParser):
+ (JSC::DFG::ByteCodeParser::setLocal):
+ (JSC::DFG::ByteCodeParser::flush):
+ - Add code to flush the scope register.
+ (JSC::DFG::ByteCodeParser::inliningCost):
+ - Pretend that all codeBlocks are too expensive to inline if the debugger is in use, thereby
+ disabling inlining whenever the debugger is in use.
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::Graph):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::hasDebuggerEnabled):
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+ - Update the DFG codeBlock's scopeRegister since it can be moved during stack layout.
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ - Update the FTL codeBlock's scopeRegister since it can be moved during stack layout.
+
+2015-03-30 Michael Saboff <msaboff@apple.com>
+
+ Fix flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
+ https://bugs.webkit.org/show_bug.cgi?id=138391
+
+ Reviewed by Mark Lam.
+
+ Re-enabling these tests as I can't get them to fail on local iOS test devices.
+ There have been many changes since these tests were disabled.
+ I'll watch automated test results for failures. If there are failures running automated
+ testing, it might be due to the device's relative CPU performance.
+
+ * tests/stress/float32-repeat-out-of-bounds.js:
+ * tests/stress/int8-repeat-out-of-bounds.js:
+
+2015-03-30 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Regression: Preview for [[null]] shouldn't be []
+ https://bugs.webkit.org/show_bug.cgi?id=143208
+
+ Reviewed by Mark Lam.
+
+ * inspector/InjectedScriptSource.js:
+ Handle null when generating simple object previews.
+
+2015-03-30 Per Arne Vollan <peavo@outlook.com>
+
+ Avoid using hardcoded values for JSValue::Int32Tag, if possible.
+ https://bugs.webkit.org/show_bug.cgi?id=143134
+
+ Reviewed by Geoffrey Garen.
+
+ * jit/JSInterfaceJIT.h:
+ * jit/Repatch.cpp:
+ (JSC::tryCacheGetByID):
+
+2015-03-30 Filip Pizlo <fpizlo@apple.com>
+
+ REGRESSION: js/regress/inline-arguments-local-escape.html is flaky
+ https://bugs.webkit.org/show_bug.cgi?id=143104
+
+ Reviewed by Geoffrey Garen.
+
+ Created a test that is a 100% repro of the flaky failure. This test is called
+ get-my-argument-by-val-for-inlined-escaped-arguments.js. It fails all of the time because it
+ always causes the compiler to emit a GetMyArgumentByVal of the arguments object returned by
+ the inlined function. Other than that, it's the same as inline-arguments-local-escape.
+
+ Also created three more tests for three similar, but not identical, failures.
+
+ Then fixed the bug: PreciseLocalClobberize was assuming that if we read(Stack) then we are
+ only reading those parts of the stack that are relevant to the current semantic code origin.
+ That's false after ArgumentsEliminationPhase - we might have operations on phantom arguments,
+ like GetMyArgumentByVal, ForwardVarargs, CallForwardVarargs, and ConstructForwardVarargs, that
+ read parts of the stack associated with the inline call frame for the phantom arguments. This
+ may not be subsumed by the current semantic origin's stack area in cases that the arguments
+ were allowed to "locally" escape.
+
+ The higher-order lesson here is that in DFG SSA IR, the current semantic origin's stack area
+ is not really a meaningful concept anymore. It is only meaningful for nodes that will read
+ the stack due to function.arguments, but there are a bunch of other ways that we could also
+ read the stack and those operations may read any stack slot. I believe that this change makes
+ PreciseLocalClobberize right: it will refine a read(Stack) from Clobberize correctly by casing
+ on node type. In future, if we add a read(Stack) to Clobberize, we'll have to make sure that
+ readTop() in PreciseLocalClobberize does the right thing.
+
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGPreciseLocalClobberize.h:
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+ * dfg/DFGPutStackSinkingPhase.cpp:
+ * tests/stress/call-forward-varargs-for-inlined-escaped-arguments.js: Added.
+ * tests/stress/construct-forward-varargs-for-inlined-escaped-arguments.js: Added.
+ * tests/stress/forward-varargs-for-inlined-escaped-arguments.js: Added.
+ * tests/stress/get-my-argument-by-val-for-inlined-escaped-arguments.js: Added.
+ * tests/stress/real-forward-varargs-for-inlined-escaped-arguments.js: Added.
+
+2015-03-30 Benjamin Poulain <benjamin@webkit.org>
+
+ Start the features.json files
+ https://bugs.webkit.org/show_bug.cgi?id=143207
+
+ Reviewed by Darin Adler.
+
+ Start the features.json files to have something to experiment
+ with for the UI.
+
+ * features.json: Added.
+
+2015-03-29 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [Win] Addresing post-review comment after r182122
+ https://bugs.webkit.org/show_bug.cgi?id=143189
+
+ Unreviewed.
+
+2015-03-29 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [Win] Allow building JavaScriptCore without Cygwin
+ https://bugs.webkit.org/show_bug.cgi?id=143189
+
+ Reviewed by Brent Fulgham.
+
+ Paths like /usr/bin/ don't exist on Windows.
+ Hashbangs don't work on Windows. Instead we must explicitly call the executable.
+ Prefixing commands with environment variables doesn't work on Windows.
+ Windows doesn't have 'cmp'
+ Windows uses 'del' instead of 'rm'
+ Windows uses 'type NUL' intead of 'touch'
+
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
+ * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make:
+ * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl:
+ * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make:
+ * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl:
+ * JavaScriptCore.vcxproj/build-generated-files.pl:
+ * UpdateContents.py: Copied from Source/JavaScriptCore/JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl.
+
+2015-03-28 Joseph Pecoraro <pecoraro@apple.com>
+
+ Clean up JavaScriptCore/builtins
+ https://bugs.webkit.org/show_bug.cgi?id=143177
+
+ Reviewed by Ryosuke Niwa.
+
+ * builtins/ArrayConstructor.js:
+ (from):
+ - We can compare to undefined instead of using a typeof undefined check.
+ - Converge on double quoted strings everywhere.
+
+ * builtins/ArrayIterator.prototype.js:
+ (next):
+ * builtins/StringIterator.prototype.js:
+ (next):
+ - Use shorthand object construction to avoid duplication.
+ - Improve grammar in error messages.
+
+ * tests/stress/array-iterators-next-with-call.js:
+ * tests/stress/string-iterators.js:
+ - Update for new error message strings.
+
+2015-03-28 Saam Barati <saambarati1@gmail.com>
+
+ Web Inspector: ES6: Better support for Symbol types in Type Profiler
+ https://bugs.webkit.org/show_bug.cgi?id=141257
+
+ Reviewed by Joseph Pecoraro.
+
+ ES6 introduces the new primitive type Symbol. This patch makes JSC's
+ type profiler support this new primitive type.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * inspector/protocol/Runtime.json:
+ * runtime/RuntimeType.cpp:
+ (JSC::runtimeTypeForValue):
+ * runtime/RuntimeType.h:
+ (JSC::runtimeTypeIsPrimitive):
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::addTypeInformation):
+ (JSC::TypeSet::dumpTypes):
+ (JSC::TypeSet::doesTypeConformTo):
+ (JSC::TypeSet::displayName):
+ (JSC::TypeSet::inspectorTypeSet):
+ (JSC::TypeSet::toJSONString):
+ * runtime/TypeSet.h:
+ (JSC::TypeSet::seenTypes):
+ * tests/typeProfiler/driver/driver.js:
+ * tests/typeProfiler/symbol.js: Added.
+ (wrapper.foo):
+ (wrapper.bar):
+ (wrapper.bar.bar.baz):
+ (wrapper):
+
+2015-03-27 Saam Barati <saambarati1@gmail.com>
+
+ Deconstruction parameters are bound too late
+ https://bugs.webkit.org/show_bug.cgi?id=143148
+
+ Reviewed by Filip Pizlo.
+
+ Currently, a deconstruction pattern named with the same
+ name as a function will shadow the function. This is
+ wrong. It should be the other way around.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+
+2015-03-27 Ryosuke Niwa <rniwa@webkit.org>
+
+ parse doesn't initialize the 16-bit version of the JSC parser with defaultConstructorKind
+ https://bugs.webkit.org/show_bug.cgi?id=143170
+
+ Reviewed by Benjamin Poulain.
+
+ Assert that we never use 16-bit version of the parser to parse a default constructor
+ since both base and derived default constructors should be using a 8-bit string.
+
+ * parser/Parser.h:
+ (JSC::parse):
+
+2015-03-27 Ryosuke Niwa <rniwa@webkit.org>
+
+ ES6 Classes: Runtime error in JIT'd class calling super() with arguments and superclass has default constructor
+ https://bugs.webkit.org/show_bug.cgi?id=142862
+
+ Reviewed by Benjamin Poulain.
+
+ Add a test that used to fail in DFG now that the bug has been fixed by r181993.
+
+ * tests/stress/class-syntax-derived-default-constructor.js: Added.
+
+2015-03-27 Michael Saboff <msaboff@apple.com>
+
+ load8Signed() and load16Signed() should be renamed to avoid confusion
+ https://bugs.webkit.org/show_bug.cgi?id=143168
+
+ Reviewed by Benjamin Poulain.
+
+ Renamed load8Signed() to load8SignedExtendTo32() and load16Signed() to load16SignedExtendTo32().
+
+ * assembler/MacroAssemblerARM.h:
+ (JSC::MacroAssemblerARM::load8SignedExtendTo32):
+ (JSC::MacroAssemblerARM::load16SignedExtendTo32):
+ (JSC::MacroAssemblerARM::load8Signed): Deleted.
+ (JSC::MacroAssemblerARM::load16Signed): Deleted.
+ * assembler/MacroAssemblerARM64.h:
+ (JSC::MacroAssemblerARM64::load16SignedExtendTo32):
+ (JSC::MacroAssemblerARM64::load8SignedExtendTo32):
+ (JSC::MacroAssemblerARM64::load16Signed): Deleted.
+ (JSC::MacroAssemblerARM64::load8Signed): Deleted.
+ * assembler/MacroAssemblerARMv7.h:
+ (JSC::MacroAssemblerARMv7::load16SignedExtendTo32):
+ (JSC::MacroAssemblerARMv7::load8SignedExtendTo32):
+ (JSC::MacroAssemblerARMv7::load16Signed): Deleted.
+ (JSC::MacroAssemblerARMv7::load8Signed): Deleted.
+ * assembler/MacroAssemblerMIPS.h:
+ (JSC::MacroAssemblerMIPS::load8SignedExtendTo32):
+ (JSC::MacroAssemblerMIPS::load16SignedExtendTo32):
+ (JSC::MacroAssemblerMIPS::load8Signed): Deleted.
+ (JSC::MacroAssemblerMIPS::load16Signed): Deleted.
+ * assembler/MacroAssemblerSH4.h:
+ (JSC::MacroAssemblerSH4::load8SignedExtendTo32):
+ (JSC::MacroAssemblerSH4::load8):
+ (JSC::MacroAssemblerSH4::load16SignedExtendTo32):
+ (JSC::MacroAssemblerSH4::load16):
+ (JSC::MacroAssemblerSH4::load8Signed): Deleted.
+ (JSC::MacroAssemblerSH4::load16Signed): Deleted.
+ * assembler/MacroAssemblerX86Common.h:
+ (JSC::MacroAssemblerX86Common::load8SignedExtendTo32):
+ (JSC::MacroAssemblerX86Common::load16SignedExtendTo32):
+ (JSC::MacroAssemblerX86Common::load8Signed): Deleted.
+ (JSC::MacroAssemblerX86Common::load16Signed): Deleted.
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitIntTypedArrayGetByVal):
+
+2015-03-27 Michael Saboff <msaboff@apple.com>
+
+ Fix flakey dfg-int8array.js and dfg-int16array.js tests for ARM64
+ https://bugs.webkit.org/show_bug.cgi?id=138390
+
+ Reviewed by Mark Lam.
+
+ Changed load8Signed() and load16Signed() to only sign extend the loaded value to 32 bits
+ instead of 64 bits. This is what X86-64 does.
+
+ * assembler/MacroAssemblerARM64.h:
+ (JSC::MacroAssemblerARM64::load16Signed):
+ (JSC::MacroAssemblerARM64::load8Signed):
+
+2015-03-27 Saam Barati <saambarati1@gmail.com>
+
+ Add back previously broken assert from bug 141869
+ https://bugs.webkit.org/show_bug.cgi?id=143005
+
+ Reviewed by Michael Saboff.
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::invalidParameterInSourceAppender):
+
+2015-03-26 Geoffrey Garen <ggaren@apple.com>
+
+ Make some more objects use FastMalloc
+ https://bugs.webkit.org/show_bug.cgi?id=143122
+
+ Reviewed by Csaba Osztrogonác.
+
+ * API/JSCallbackObject.h:
+ * heap/IncrementalSweeper.h:
+ * jit/JITThunks.h:
+ * runtime/JSGlobalObjectDebuggable.h:
+ * runtime/RegExpCache.h:
+
+2015-03-27 Michael Saboff <msaboff@apple.com>
+
+ Objects with numeric properties intermittently get a phantom 'length' property
+ https://bugs.webkit.org/show_bug.cgi?id=142792
+
+ Reviewed by Csaba Osztrogonác.
+
+ Fixed a > (greater than) that should be a >> (right shift) in the code that disassembles
+ test and branch instructions. This function is used for linking tbz/tbnz branches between
+ two seperately JIT'ed sections of code. Sometime we'd create a bogus tbz instruction in
+ the failure case checks in the GetById array length stub created for "obj.length" access.
+ If the failure case code address was at a negative offset from the stub, we'd look for bit 1
+ being set when we should have been looking for bit 0.
+
+ * assembler/ARM64Assembler.h:
+ (JSC::ARM64Assembler::disassembleTestAndBranchImmediate):
+
+2015-03-27 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Insert exception check around toPropertyKey call
+ https://bugs.webkit.org/show_bug.cgi?id=142922
+
+ Reviewed by Geoffrey Garen.
+
+ In some places, exception check is missing after/before toPropertyKey.
+ However, since it calls toString, it's observable to users,
+
+ Missing exception checks in Object.prototype methods can be
+ observed since it would be overridden with toObject(null/undefined) errors.
+ We inserted exception checks after toPropertyKey.
+
+ Missing exception checks in GetById related code can be
+ observed since it would be overridden with toObject(null/undefined) errors.
+ In this case, we need to insert exception checks before/after toPropertyKey
+ since RequireObjectCoercible followed by toPropertyKey can cause exceptions.
+
+ JSValue::get checks null/undefined and raise an exception if |this| is null or undefined.
+ However, we need to check whether the baseValue is object coercible before executing JSValue::toPropertyKey.
+ According to the spec, we first perform RequireObjectCoercible and check the exception.
+ And second, we perform ToPropertyKey and check the exception.
+ Since JSValue::toPropertyKey can cause toString call, this is observable to users.
+ For example, if the target is not object coercible,
+ ToPropertyKey should not be executed, and toString should not be executed by ToPropertyKey.
+ So the order of observable actions (RequireObjectCoercible and ToPropertyKey) should be correct to the spec.
+
+ This patch introduces JSValue::requireObjectCoercible and use it because of the following 2 reasons.
+
+ 1. Using toObject instead of requireObjectCoercible produces unnecessary wrapper object.
+
+ toObject converts primitive types into wrapper objects.
+ But it is not efficient since wrapper objects are not necessary
+ if we look up methods from primitive values's prototype. (using synthesizePrototype is better).
+
+ 2. Using the result of toObject is not correct to the spec.
+
+ To align to the spec correctly, we cannot use JSObject::get
+ by using the wrapper object produced by the toObject suggested in (1).
+ If we use JSObject that is converted by toObject, getter will be called by using this JSObject as |this|.
+ It is not correct since getter should be called with the original |this| value that may be primitive types.
+
+ So in this patch, we use JSValue::requireObjectCoercible
+ to check the target is object coercible and raise an error if it's not.
+
+ * dfg/DFGOperations.cpp:
+ * jit/JITOperations.cpp:
+ (JSC::getByVal):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::getByVal):
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/JSCJSValue.h:
+ * runtime/JSCJSValueInlines.h:
+ (JSC::JSValue::requireObjectCoercible):
+ * runtime/ObjectPrototype.cpp:
+ (JSC::objectProtoFuncHasOwnProperty):
+ (JSC::objectProtoFuncDefineGetter):
+ (JSC::objectProtoFuncDefineSetter):
+ (JSC::objectProtoFuncLookupGetter):
+ (JSC::objectProtoFuncLookupSetter):
+ (JSC::objectProtoFuncPropertyIsEnumerable):
+ * tests/stress/exception-in-to-property-key-should-be-handled-early-in-object-methods.js: Added.
+ (shouldThrow):
+ (if):
+ * tests/stress/exception-in-to-property-key-should-be-handled-early.js: Added.
+ (shouldThrow):
+ (.):
+
+2015-03-26 Joseph Pecoraro <pecoraro@apple.com>
+
+ WebContent Crash when instantiating class with Type Profiling enabled
+ https://bugs.webkit.org/show_bug.cgi?id=143037
+
+ Reviewed by Ryosuke Niwa.
+
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::emitMoveEmptyValue):
+ We cannot profile the type of an uninitialized empty JSValue.
+ Nor do we expect this to be necessary, since it is effectively
+ an unseen undefined value. So add a way to put the empty value
+ without profiling.
+
+ (JSC::BytecodeGenerator::emitMove):
+ Add an assert to try to catch this issue early on, and force
+ callers to explicitly use emitMoveEmptyValue instead.
+
+ * tests/typeProfiler/classes.js: Added.
+ (wrapper.Base):
+ (wrapper.Derived):
+ (wrapper):
+ Add test coverage both for this case and classes in general.
+
+2015-03-26 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ES6: Provide a better view for Classes in the console
+ https://bugs.webkit.org/show_bug.cgi?id=142999
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Runtime.json:
+ Provide a new `subtype` enum "class". This is a subtype of `type`
+ "function", all other subtypes are subtypes of `object` types.
+ For a class, the frontend will immediately want to get the prototype
+ to enumerate its methods, so include the `classPrototype`.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ Denote class construction functions as "class" subtypes.
+
+ * inspector/InjectedScriptSource.js:
+ Handling for the new "class" type.
+
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedFunctionExecutable::isClassConstructorFunction):
+ * runtime/Executable.h:
+ (JSC::FunctionExecutable::isClassConstructorFunction):
+ * runtime/JSFunction.h:
+ * runtime/JSFunctionInlines.h:
+ (JSC::JSFunction::isClassConstructorFunction):
+ Check if this function is a class constructor function. That information
+ is on the UnlinkedFunctionExecutable, so plumb it through to JSFunction.
+
+2015-03-26 Geoffrey Garen <ggaren@apple.com>
+
+ Function.prototype.toString should not decompile the AST
+ https://bugs.webkit.org/show_bug.cgi?id=142853
+
+ Reviewed by Darin Adler.
+
+ Following up on Darin's review comments.
+
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck):
+
+2015-03-26 Geoffrey Garen <ggaren@apple.com>
+
+ "lineNo" does not match WebKit coding style guidelines
+ https://bugs.webkit.org/show_bug.cgi?id=143119
+
+ Reviewed by Michael Saboff.
+
+ We can afford to use whole words.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::lineNumberForBytecodeOffset):
+ (JSC::CodeBlock::expressionRangeForBytecodeOffset):
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::link):
+ (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
+ * bytecode/UnlinkedCodeBlock.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::WhileNode::emitBytecode):
+ * debugger/Debugger.cpp:
+ (JSC::Debugger::toggleBreakpoint):
+ * interpreter/Interpreter.cpp:
+ (JSC::StackFrame::computeLineAndColumn):
+ (JSC::GetStackTraceFunctor::operator()):
+ (JSC::Interpreter::execute):
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::computeLineAndColumn):
+ * parser/Nodes.h:
+ (JSC::Node::firstLine):
+ (JSC::Node::lineNo): Deleted.
+ (JSC::StatementNode::firstLine): Deleted.
+ * parser/ParserError.h:
+ (JSC::ParserError::toErrorObject):
+ * profiler/LegacyProfiler.cpp:
+ (JSC::createCallIdentifierFromFunctionImp):
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ * runtime/Executable.cpp:
+ (JSC::ScriptExecutable::ScriptExecutable):
+ (JSC::ScriptExecutable::newCodeBlockFor):
+ (JSC::FunctionExecutable::fromGlobalCode):
+ * runtime/Executable.h:
+ (JSC::ScriptExecutable::firstLine):
+ (JSC::ScriptExecutable::setOverrideLineNumber):
+ (JSC::ScriptExecutable::hasOverrideLineNumber):
+ (JSC::ScriptExecutable::overrideLineNumber):
+ (JSC::ScriptExecutable::lineNo): Deleted.
+ (JSC::ScriptExecutable::setOverrideLineNo): Deleted.
+ (JSC::ScriptExecutable::hasOverrideLineNo): Deleted.
+ (JSC::ScriptExecutable::overrideLineNo): Deleted.
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck):
+ * runtime/FunctionConstructor.h:
+ * tools/CodeProfile.cpp:
+ (JSC::CodeProfile::report):
+ * tools/CodeProfile.h:
+ (JSC::CodeProfile::CodeProfile):
+
+2015-03-26 Geoffrey Garen <ggaren@apple.com>
+
+ Assertion firing in JavaScriptCore/parser/parser.h for statesman.com site
+ https://bugs.webkit.org/show_bug.cgi?id=142974
+
+ Reviewed by Joseph Pecoraro.
+
+ This patch does two things:
+
+ (1) Restore JavaScriptCore's sanitization of line and column numbers to
+ one-based values.
+
+ We need this because WebCore sometimes provides huge negative column
+ numbers.
+
+ (2) Solve the attribute event listener line numbering problem a different
+ way: Rather than offseting all line numbers by -1 in an attribute event
+ listener in order to arrange for a custom result, instead use an explicit
+ feature for saying "all errors in this code should map to this line number".
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::link):
+ (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
+ * bytecode/UnlinkedCodeBlock.h:
+ * interpreter/Interpreter.cpp:
+ (JSC::StackFrame::computeLineAndColumn):
+ (JSC::GetStackTraceFunctor::operator()):
+ * interpreter/Interpreter.h:
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::computeLineAndColumn):
+ * parser/ParserError.h:
+ (JSC::ParserError::toErrorObject): Plumb through an override line number.
+ When a function has an override line number, all syntax and runtime
+ errors in the function will map to it. This is useful for attribute event
+ listeners.
+
+ * parser/SourceCode.h:
+ (JSC::SourceCode::SourceCode): Restore the old sanitization of line and
+ column numbers to one-based integers. It was kind of a hack to remove this.
+
+ * runtime/Executable.cpp:
+ (JSC::ScriptExecutable::ScriptExecutable):
+ (JSC::FunctionExecutable::fromGlobalCode):
+ * runtime/Executable.h:
+ (JSC::ScriptExecutable::setOverrideLineNo):
+ (JSC::ScriptExecutable::hasOverrideLineNo):
+ (JSC::ScriptExecutable::overrideLineNo):
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck):
+ * runtime/FunctionConstructor.h: Plumb through an override line number.
+
+2015-03-26 Filip Pizlo <fpizlo@apple.com>
+
+ If we're in code for accessing scoped arguments, we should probably check if the object is a scoped arguments rather than checking if it's a direct arguments.
+
+ Reviewed by Michael Saboff.
+
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitScopedArgumentsGetByVal):
+ * tests/stress/scoped-then-direct-arguments-get-by-val-in-baseline.js: Added.
+
+2015-03-26 Filip Pizlo <fpizlo@apple.com>
+
+ FTL ScopedArguments GetArrayLength generates incorrect code and crashes in LLVM
+ https://bugs.webkit.org/show_bug.cgi?id=143098
+
+ Reviewed by Csaba Osztrogonác.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength): Fix a typo.
+ * tests/stress/scoped-arguments-array-length.js: Added. This test previously always crashed in ftl-no-cjit mode.
+
+2015-03-26 Csaba Osztrogonác <ossy@webkit.org>
+
+ Unreviewed gardening, skip failing tests on AArch64 Linux.
+
+ * tests/mozilla/mozilla-tests.yaml:
+ * tests/stress/cached-prototype-setter.js:
+
+2015-03-26 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fixes to silly things. While landing fixes to r181993, I introduced crashes. This fixes them.
+
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants): I landed a fix for a VS warning. It broke this. Now I'm fixing it.
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::compile): Make sure we pass the module when dumping. This makes FTL debugging possible again.
+ * ftl/FTLState.cpp:
+ (JSC::FTL::State::dumpState): New overload that takes a module, so that we can call this after FTL::compile() clears State's module.
+ * ftl/FTLState.h:
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix obvious goof that was causing 32-bit debug crashes. The 64-bit version did it
+ right, so this just makes 32-bit do the same.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Fix a typo that ggaren found but that I didn't fix before.
+
+ * runtime/DirectArgumentsOffset.h:
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, VC found a bug. This fixes the bug.
+
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, try to fix Windows build.
+
+ * runtime/ClonedArguments.cpp:
+ (JSC::ClonedArguments::createWithInlineFrame):
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix debug build.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ConstDeclNode::emitCodeSingle):
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix CLOOP build.
+
+ * dfg/DFGMinifiedID.h:
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Heap variables shouldn't end up in the stack frame
+ https://bugs.webkit.org/show_bug.cgi?id=141174
+
+ Reviewed by Geoffrey Garen.
+
+ This is a major change to how JavaScriptCore handles declared variables (i.e. "var"). It removes
+ any ambiguity about whether a variable should be in the heap or on the stack. A variable will no
+ longer move between heap and stack during its lifetime. This enables a bunch of optimizations and
+ simplifications:
+
+ - Accesses to variables no longer need checks or indirections to determine where the variable is
+ at that moment in time. For example, loading a closure variable now takes just one load instead
+ of two. Loading an argument by index now takes a bounds check and a load in the fastest case
+ (when no arguments object allocation is required) while previously that same operation required
+ a "did I allocate arguments yet" check, a bounds check, and then the load.
+
+ - Reasoning about the allocation of an activation or arguments object now follows the same simple
+ logic as the allocation of any other kind of object. Previously, those objects were lazily
+ allocated - so an allocation instruction wasn't the actual allocation site, since it might not
+ allocate anything at all. This made the implementation of traditional escape analyses really
+ awkward, and ultimately it meant that we missed important cases. Now, we can reason about the
+ arguments object using the usual SSA tricks which allows for more comprehensive removal.
+
+ - The allocations of arguments objects, functions, and activations are now much faster. While
+ this patch generally expands our ability to eliminate arguments object allocations, an earlier
+ version of the patch - which lacked that functionality - was a progression on some arguments-
+ and closure-happy benchmarks because although no allocations were eliminated, all allocations
+ were faster.
+
+ - There is no tear-off. The runtime no loner needs to know about where on the stack a frame keeps
+ its arguments objects or activations. The runtime doesn't have to do things to the arguments
+ objects and activations that a frame allocated, when the frame is unwound. We always had horrid
+ bugs in that code, so it's good to see it go. This removes *a ton* of machinery from the DFG,
+ FTL, CodeBlock, and other places. All of the things having to do with "captured variables" is
+ now gone. This also enables implementing block-scoping. Without this change, block-scope
+ support would require telling CodeBlock and all of the rest of the runtime about all of the
+ variables that store currently-live scopes. That would have been so disastrously hard that it
+ might as well be impossible. With this change, it's fair game for the bytecode generator to
+ simply allocate whatever activations it wants, wherever it wants, and to keep them live for
+ however long it wants. This all works, because after bytecode generation, an activation is just
+ an object and variables that refer to it are just normal variables.
+
+ - SymbolTable can now tell you explicitly where a variable lives. The answer is in the form of a
+ VarOffset object, which has methods like isStack(), isScope(), etc. VirtualRegister is never
+ used for offsets of non-stack variables anymore. We now have shiny new objects for other kinds
+ of offsets - ScopeOffset for offsets into scopes, and DirectArgumentsOffset for offsets into
+ an arguments object.
+
+ - Functions that create activations can now tier-up into the FTL. Previously they couldn't. Also,
+ using activations used to prevent inlining; now functions that use activations can be inlined
+ just fine.
+
+ This is a >1% speed-up on Octane. This is a >2% speed-up on CompressionBench. This is a tiny
+ speed-up on AsmBench (~0.4% or something). This looks like it might be a speed-up on SunSpider.
+ It's only a slow-down on very short-running microbenchmarks we had previously written for our old
+ style of tear-off-based arguments optimization. Those benchmarks are not part of any major suite.
+
+ The easiest way of understanding this change is to start by looking at the changes in runtime/,
+ and then the changes in bytecompiler/, and then sort of work your way up the compiler tiers.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * assembler/AbortReason.h:
+ * assembler/AbstractMacroAssembler.h:
+ (JSC::AbstractMacroAssembler::BaseIndex::withOffset):
+ * bytecode/ByValInfo.h:
+ (JSC::hasOptimizableIndexingForJSType):
+ (JSC::hasOptimizableIndexing):
+ (JSC::jitArrayModeForJSType):
+ (JSC::jitArrayModePermitsPut):
+ (JSC::jitArrayModeForStructure):
+ * bytecode/BytecodeKills.h: Added.
+ (JSC::BytecodeKills::BytecodeKills):
+ (JSC::BytecodeKills::operandIsKilled):
+ (JSC::BytecodeKills::forEachOperandKilledAt):
+ (JSC::BytecodeKills::KillSet::KillSet):
+ (JSC::BytecodeKills::KillSet::add):
+ (JSC::BytecodeKills::KillSet::forEachLocal):
+ (JSC::BytecodeKills::KillSet::contains):
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeLivenessAnalysis.cpp:
+ (JSC::isValidRegisterForLiveness):
+ (JSC::stepOverInstruction):
+ (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
+ (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
+ (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
+ (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
+ (JSC::BytecodeLivenessAnalysis::computeKills):
+ (JSC::indexForOperand): Deleted.
+ (JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): Deleted.
+ (JSC::getLivenessInfo): Deleted.
+ * bytecode/BytecodeLivenessAnalysis.h:
+ * bytecode/BytecodeLivenessAnalysisInlines.h:
+ (JSC::operandIsAlwaysLive):
+ (JSC::operandThatIsNotAlwaysLiveIsLive):
+ (JSC::operandIsLive):
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::nameForRegister):
+ (JSC::CodeBlock::validate):
+ (JSC::CodeBlock::isCaptured): Deleted.
+ (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters): Deleted.
+ (JSC::CodeBlock::machineSlowArguments): Deleted.
+ * bytecode/CodeBlock.h:
+ (JSC::unmodifiedArgumentsRegister): Deleted.
+ (JSC::CodeBlock::setArgumentsRegister): Deleted.
+ (JSC::CodeBlock::argumentsRegister): Deleted.
+ (JSC::CodeBlock::uncheckedArgumentsRegister): Deleted.
+ (JSC::CodeBlock::usesArguments): Deleted.
+ (JSC::CodeBlock::captureCount): Deleted.
+ (JSC::CodeBlock::captureStart): Deleted.
+ (JSC::CodeBlock::captureEnd): Deleted.
+ (JSC::CodeBlock::argumentIndexAfterCapture): Deleted.
+ (JSC::CodeBlock::hasSlowArguments): Deleted.
+ (JSC::ExecState::argumentAfterCapture): Deleted.
+ * bytecode/CodeOrigin.h:
+ * bytecode/DataFormat.h:
+ (JSC::dataFormatToString):
+ * bytecode/FullBytecodeLiveness.h:
+ (JSC::FullBytecodeLiveness::getLiveness):
+ (JSC::FullBytecodeLiveness::operandIsLive):
+ (JSC::FullBytecodeLiveness::FullBytecodeLiveness): Deleted.
+ (JSC::FullBytecodeLiveness::getOut): Deleted.
+ * bytecode/Instruction.h:
+ (JSC::Instruction::Instruction):
+ * bytecode/Operands.h:
+ (JSC::Operands::virtualRegisterForIndex):
+ * bytecode/SpeculatedType.cpp:
+ (JSC::dumpSpeculation):
+ (JSC::speculationToAbbreviatedString):
+ (JSC::speculationFromClassInfo):
+ * bytecode/SpeculatedType.h:
+ (JSC::isDirectArgumentsSpeculation):
+ (JSC::isScopedArgumentsSpeculation):
+ (JSC::isActionableMutableArraySpeculation):
+ (JSC::isActionableArraySpeculation):
+ (JSC::isArgumentsSpeculation): Deleted.
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::setArgumentsRegister): Deleted.
+ (JSC::UnlinkedCodeBlock::usesArguments): Deleted.
+ (JSC::UnlinkedCodeBlock::argumentsRegister): Deleted.
+ * bytecode/ValueRecovery.cpp:
+ (JSC::ValueRecovery::dumpInContext):
+ * bytecode/ValueRecovery.h:
+ (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
+ (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated):
+ (JSC::ValueRecovery::nodeID):
+ (JSC::ValueRecovery::argumentsThatWereNotCreated): Deleted.
+ * bytecode/VirtualRegister.h:
+ (JSC::VirtualRegister::operator==):
+ (JSC::VirtualRegister::operator!=):
+ (JSC::VirtualRegister::operator<):
+ (JSC::VirtualRegister::operator>):
+ (JSC::VirtualRegister::operator<=):
+ (JSC::VirtualRegister::operator>=):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate):
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::initializeNextParameter):
+ (JSC::BytecodeGenerator::visibleNameForParameter):
+ (JSC::BytecodeGenerator::emitMove):
+ (JSC::BytecodeGenerator::variable):
+ (JSC::BytecodeGenerator::createVariable):
+ (JSC::BytecodeGenerator::emitResolveScope):
+ (JSC::BytecodeGenerator::emitGetFromScope):
+ (JSC::BytecodeGenerator::emitPutToScope):
+ (JSC::BytecodeGenerator::initializeVariable):
+ (JSC::BytecodeGenerator::emitInstanceOf):
+ (JSC::BytecodeGenerator::emitNewFunction):
+ (JSC::BytecodeGenerator::emitNewFunctionInternal):
+ (JSC::BytecodeGenerator::emitCall):
+ (JSC::BytecodeGenerator::emitReturn):
+ (JSC::BytecodeGenerator::emitConstruct):
+ (JSC::BytecodeGenerator::isArgumentNumber):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::addVar): Deleted.
+ (JSC::BytecodeGenerator::emitInitLazyRegister): Deleted.
+ (JSC::BytecodeGenerator::initializeCapturedVariable): Deleted.
+ (JSC::BytecodeGenerator::resolveCallee): Deleted.
+ (JSC::BytecodeGenerator::addCallee): Deleted.
+ (JSC::BytecodeGenerator::addParameter): Deleted.
+ (JSC::BytecodeGenerator::willResolveToArgumentsRegister): Deleted.
+ (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister): Deleted.
+ (JSC::BytecodeGenerator::createLazyRegisterIfNecessary): Deleted.
+ (JSC::BytecodeGenerator::isCaptured): Deleted.
+ (JSC::BytecodeGenerator::local): Deleted.
+ (JSC::BytecodeGenerator::constLocal): Deleted.
+ (JSC::BytecodeGenerator::emitResolveConstantLocal): Deleted.
+ (JSC::BytecodeGenerator::emitGetArgumentsLength): Deleted.
+ (JSC::BytecodeGenerator::emitGetArgumentByVal): Deleted.
+ (JSC::BytecodeGenerator::emitLazyNewFunction): Deleted.
+ (JSC::BytecodeGenerator::createArgumentsIfNecessary): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::Variable::Variable):
+ (JSC::Variable::isResolved):
+ (JSC::Variable::ident):
+ (JSC::Variable::offset):
+ (JSC::Variable::isLocal):
+ (JSC::Variable::local):
+ (JSC::Variable::isSpecial):
+ (JSC::BytecodeGenerator::argumentsRegister):
+ (JSC::BytecodeGenerator::emitNode):
+ (JSC::BytecodeGenerator::registerFor):
+ (JSC::Local::Local): Deleted.
+ (JSC::Local::operator bool): Deleted.
+ (JSC::Local::get): Deleted.
+ (JSC::Local::isSpecial): Deleted.
+ (JSC::ResolveScopeInfo::ResolveScopeInfo): Deleted.
+ (JSC::ResolveScopeInfo::isLocal): Deleted.
+ (JSC::ResolveScopeInfo::localIndex): Deleted.
+ (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister): Deleted.
+ (JSC::BytecodeGenerator::captureMode): Deleted.
+ (JSC::BytecodeGenerator::shouldTearOffArgumentsEagerly): Deleted.
+ (JSC::BytecodeGenerator::shouldCreateArgumentsEagerly): Deleted.
+ (JSC::BytecodeGenerator::hasWatchableVariable): Deleted.
+ (JSC::BytecodeGenerator::watchableVariableIdentifier): Deleted.
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ResolveNode::isPure):
+ (JSC::ResolveNode::emitBytecode):
+ (JSC::BracketAccessorNode::emitBytecode):
+ (JSC::DotAccessorNode::emitBytecode):
+ (JSC::EvalFunctionCallNode::emitBytecode):
+ (JSC::FunctionCallResolveNode::emitBytecode):
+ (JSC::CallFunctionCallDotNode::emitBytecode):
+ (JSC::ApplyFunctionCallDotNode::emitBytecode):
+ (JSC::PostfixNode::emitResolve):
+ (JSC::DeleteResolveNode::emitBytecode):
+ (JSC::TypeOfResolveNode::emitBytecode):
+ (JSC::PrefixNode::emitResolve):
+ (JSC::ReadModifyResolveNode::emitBytecode):
+ (JSC::AssignResolveNode::emitBytecode):
+ (JSC::ConstDeclNode::emitCodeSingle):
+ (JSC::EmptyVarExpression::emitBytecode):
+ (JSC::ForInNode::tryGetBoundLocal):
+ (JSC::ForInNode::emitLoopHeader):
+ (JSC::ForOfNode::emitBytecode):
+ (JSC::ArrayPatternNode::emitDirectBinding):
+ (JSC::BindingNode::bindValue):
+ (JSC::getArgumentByVal): Deleted.
+ * dfg/DFGAbstractHeap.h:
+ * dfg/DFGAbstractInterpreter.h:
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberWorld):
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberCapturedVars): Deleted.
+ * dfg/DFGAbstractValue.h:
+ * dfg/DFGArgumentPosition.h:
+ (JSC::DFG::ArgumentPosition::addVariable):
+ * dfg/DFGArgumentsEliminationPhase.cpp: Added.
+ (JSC::DFG::performArgumentsElimination):
+ * dfg/DFGArgumentsEliminationPhase.h: Added.
+ * dfg/DFGArgumentsSimplificationPhase.cpp: Removed.
+ * dfg/DFGArgumentsSimplificationPhase.h: Removed.
+ * dfg/DFGArgumentsUtilities.cpp: Added.
+ (JSC::DFG::argumentsInvolveStackSlot):
+ (JSC::DFG::emitCodeToGetArgumentsArrayLength):
+ * dfg/DFGArgumentsUtilities.h: Added.
+ * dfg/DFGArrayMode.cpp:
+ (JSC::DFG::ArrayMode::refine):
+ (JSC::DFG::ArrayMode::alreadyChecked):
+ (JSC::DFG::arrayTypeToString):
+ * dfg/DFGArrayMode.h:
+ (JSC::DFG::ArrayMode::canCSEStorage):
+ (JSC::DFG::ArrayMode::modeForPut):
+ * dfg/DFGAvailabilityMap.cpp:
+ (JSC::DFG::AvailabilityMap::prune):
+ * dfg/DFGAvailabilityMap.h:
+ (JSC::DFG::AvailabilityMap::closeOverNodes):
+ (JSC::DFG::AvailabilityMap::closeStartingWithLocal):
+ * dfg/DFGBackwardsPropagationPhase.cpp:
+ (JSC::DFG::BackwardsPropagationPhase::propagate):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::newVariableAccessData):
+ (JSC::DFG::ByteCodeParser::getLocal):
+ (JSC::DFG::ByteCodeParser::setLocal):
+ (JSC::DFG::ByteCodeParser::getArgument):
+ (JSC::DFG::ByteCodeParser::setArgument):
+ (JSC::DFG::ByteCodeParser::flushDirect):
+ (JSC::DFG::ByteCodeParser::flush):
+ (JSC::DFG::ByteCodeParser::noticeArgumentsUse):
+ (JSC::DFG::ByteCodeParser::handleVarargsCall):
+ (JSC::DFG::ByteCodeParser::attemptToInlineCall):
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
+ (JSC::DFG::ByteCodeParser::parseCodeBlock):
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
+ * dfg/DFGCSEPhase.cpp:
+ * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: Added.
+ (JSC::DFG::CallCreateDirectArgumentsSlowPathGenerator::CallCreateDirectArgumentsSlowPathGenerator):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::isSupportedForInlining):
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGCommon.h:
+ * dfg/DFGCommonData.h:
+ (JSC::DFG::CommonData::CommonData):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * dfg/DFGDCEPhase.cpp:
+ (JSC::DFG::DCEPhase::cleanVariables):
+ * dfg/DFGDisassembler.h:
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGFlushFormat.cpp:
+ (WTF::printInternal):
+ * dfg/DFGFlushFormat.h:
+ (JSC::DFG::resultFor):
+ (JSC::DFG::useKindFor):
+ (JSC::DFG::dataFormatFor):
+ * dfg/DFGForAllKills.h: Added.
+ (JSC::DFG::forAllLiveNodesAtTail):
+ (JSC::DFG::forAllDirectlyKilledOperands):
+ (JSC::DFG::forAllKilledOperands):
+ (JSC::DFG::forAllKilledNodesAtNodeIndex):
+ (JSC::DFG::forAllKillsInBlock):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::Graph):
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::substituteGetLocal):
+ (JSC::DFG::Graph::livenessFor):
+ (JSC::DFG::Graph::killsFor):
+ (JSC::DFG::Graph::tryGetConstantClosureVar):
+ (JSC::DFG::Graph::tryGetRegisters): Deleted.
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::symbolTableFor):
+ (JSC::DFG::Graph::uses):
+ (JSC::DFG::Graph::bytecodeRegisterForArgument): Deleted.
+ (JSC::DFG::Graph::capturedVarsFor): Deleted.
+ (JSC::DFG::Graph::usesArguments): Deleted.
+ (JSC::DFG::Graph::argumentsRegisterFor): Deleted.
+ (JSC::DFG::Graph::machineArgumentsRegisterFor): Deleted.
+ (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): Deleted.
+ * dfg/DFGHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGHeapLocation.h:
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::initialize):
+ (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::link):
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGMinifiedID.h:
+ * dfg/DFGMinifiedNode.cpp:
+ (JSC::DFG::MinifiedNode::fromNode):
+ * dfg/DFGMinifiedNode.h:
+ (JSC::DFG::belongsInMinifiedGraph):
+ (JSC::DFG::MinifiedNode::hasInlineCallFrame):
+ (JSC::DFG::MinifiedNode::inlineCallFrame):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::convertToIdentityOn):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasConstant):
+ (JSC::DFG::Node::constant):
+ (JSC::DFG::Node::hasScopeOffset):
+ (JSC::DFG::Node::scopeOffset):
+ (JSC::DFG::Node::hasDirectArgumentsOffset):
+ (JSC::DFG::Node::capturedArgumentsOffset):
+ (JSC::DFG::Node::variablePointer):
+ (JSC::DFG::Node::hasCallVarargsData):
+ (JSC::DFG::Node::hasLoadVarargsData):
+ (JSC::DFG::Node::hasHeapPrediction):
+ (JSC::DFG::Node::hasCellOperand):
+ (JSC::DFG::Node::objectMaterializationData):
+ (JSC::DFG::Node::isPhantomAllocation):
+ (JSC::DFG::Node::willHaveCodeGenOrOSR):
+ (JSC::DFG::Node::shouldSpeculateDirectArguments):
+ (JSC::DFG::Node::shouldSpeculateScopedArguments):
+ (JSC::DFG::Node::isPhantomArguments): Deleted.
+ (JSC::DFG::Node::hasVarNumber): Deleted.
+ (JSC::DFG::Node::varNumber): Deleted.
+ (JSC::DFG::Node::registerPointer): Deleted.
+ (JSC::DFG::Node::shouldSpeculateArguments): Deleted.
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+ (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
+ (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
+ * dfg/DFGOSRExitCompiler.cpp:
+ (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
+ * dfg/DFGOSRExitCompiler.h:
+ (JSC::DFG::OSRExitCompiler::badIndex): Deleted.
+ (JSC::DFG::OSRExitCompiler::initializePoisoned): Deleted.
+ (JSC::DFG::OSRExitCompiler::poisonIndex): Deleted.
+ * dfg/DFGOSRExitCompiler32_64.cpp:
+ (JSC::DFG::OSRExitCompiler::compileExit):
+ * dfg/DFGOSRExitCompiler64.cpp:
+ (JSC::DFG::OSRExitCompiler::compileExit):
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::reifyInlinedCallFrames):
+ (JSC::DFG::ArgumentsRecoveryGenerator::ArgumentsRecoveryGenerator): Deleted.
+ (JSC::DFG::ArgumentsRecoveryGenerator::~ArgumentsRecoveryGenerator): Deleted.
+ (JSC::DFG::ArgumentsRecoveryGenerator::generateFor): Deleted.
+ * dfg/DFGOSRExitCompilerCommon.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGPreciseLocalClobberize.h:
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::read):
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::write):
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::def):
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+ (JSC::DFG::preciseLocalClobberize):
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop): Deleted.
+ (JSC::DFG::forEachLocalReadByUnwind): Deleted.
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::run):
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
+ (JSC::DFG::PredictionPropagationPhase::propagateThroughArgumentPositions):
+ * dfg/DFGPromoteHeapAccess.h:
+ (JSC::DFG::promoteHeapAccess):
+ * dfg/DFGPromotedHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGPromotedHeapLocation.h:
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
+ (JSC::DFG::SpeculativeJIT::emitGetLength):
+ (JSC::DFG::SpeculativeJIT::emitGetCallee):
+ (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
+ (JSC::DFG::SpeculativeJIT::checkArray):
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
+ (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
+ (JSC::DFG::SpeculativeJIT::compileNewFunction):
+ (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
+ (JSC::DFG::SpeculativeJIT::compileCreateActivation):
+ (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
+ (JSC::DFG::SpeculativeJIT::compileGetFromArguments):
+ (JSC::DFG::SpeculativeJIT::compilePutToArguments):
+ (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
+ (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
+ (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Deleted.
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): Deleted.
+ (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength): Deleted.
+ (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck): Deleted.
+ (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression): Deleted.
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
+ (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
+ (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters): Deleted.
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+ * dfg/DFGStrengthReductionPhase.cpp:
+ (JSC::DFG::StrengthReductionPhase::handleNode):
+ * dfg/DFGStructureRegistrationPhase.cpp:
+ (JSC::DFG::StructureRegistrationPhase::run):
+ * dfg/DFGUnificationPhase.cpp:
+ (JSC::DFG::UnificationPhase::run):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateCPS):
+ * dfg/DFGValueSource.cpp:
+ (JSC::DFG::ValueSource::dump):
+ * dfg/DFGValueSource.h:
+ (JSC::DFG::dataFormatToValueSourceKind):
+ (JSC::DFG::valueSourceKindToDataFormat):
+ (JSC::DFG::ValueSource::ValueSource):
+ (JSC::DFG::ValueSource::forFlushFormat):
+ (JSC::DFG::ValueSource::valueRecovery):
+ * dfg/DFGVarargsForwardingPhase.cpp: Added.
+ (JSC::DFG::performVarargsForwarding):
+ * dfg/DFGVarargsForwardingPhase.h: Added.
+ * dfg/DFGVariableAccessData.cpp:
+ (JSC::DFG::VariableAccessData::VariableAccessData):
+ (JSC::DFG::VariableAccessData::flushFormat):
+ (JSC::DFG::VariableAccessData::mergeIsCaptured): Deleted.
+ * dfg/DFGVariableAccessData.h:
+ (JSC::DFG::VariableAccessData::shouldNeverUnbox):
+ (JSC::DFG::VariableAccessData::shouldUseDoubleFormat):
+ (JSC::DFG::VariableAccessData::isCaptured): Deleted.
+ (JSC::DFG::VariableAccessData::mergeIsArgumentsAlias): Deleted.
+ (JSC::DFG::VariableAccessData::isArgumentsAlias): Deleted.
+ * dfg/DFGVariableAccessDataDump.cpp:
+ (JSC::DFG::VariableAccessDataDump::dump):
+ * dfg/DFGVariableAccessDataDump.h:
+ * dfg/DFGVariableEventStream.cpp:
+ (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
+ * dfg/DFGVariableEventStream.h:
+ * ftl/FTLAbstractHeap.cpp:
+ (JSC::FTL::AbstractHeap::dump):
+ (JSC::FTL::AbstractField::dump):
+ (JSC::FTL::IndexedAbstractHeap::dump):
+ (JSC::FTL::NumberedAbstractHeap::dump):
+ (JSC::FTL::AbsoluteAbstractHeap::dump):
+ * ftl/FTLAbstractHeap.h:
+ * ftl/FTLAbstractHeapRepository.cpp:
+ * ftl/FTLAbstractHeapRepository.h:
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLExitArgument.cpp:
+ (JSC::FTL::ExitArgument::dump):
+ * ftl/FTLExitPropertyValue.cpp:
+ (JSC::FTL::ExitPropertyValue::withLocalsOffset):
+ * ftl/FTLExitPropertyValue.h:
+ * ftl/FTLExitTimeObjectMaterialization.cpp:
+ (JSC::FTL::ExitTimeObjectMaterialization::ExitTimeObjectMaterialization):
+ (JSC::FTL::ExitTimeObjectMaterialization::accountForLocalsOffset):
+ * ftl/FTLExitTimeObjectMaterialization.h:
+ (JSC::FTL::ExitTimeObjectMaterialization::origin):
+ * ftl/FTLExitValue.cpp:
+ (JSC::FTL::ExitValue::withLocalsOffset):
+ (JSC::FTL::ExitValue::valueFormat):
+ (JSC::FTL::ExitValue::dumpInContext):
+ * ftl/FTLExitValue.h:
+ (JSC::FTL::ExitValue::isArgument):
+ (JSC::FTL::ExitValue::argumentsObjectThatWasNotCreated): Deleted.
+ (JSC::FTL::ExitValue::isArgumentsObjectThatWasNotCreated): Deleted.
+ (JSC::FTL::ExitValue::valueFormat): Deleted.
+ * ftl/FTLInlineCacheSize.cpp:
+ (JSC::FTL::sizeOfCallForwardVarargs):
+ (JSC::FTL::sizeOfConstructForwardVarargs):
+ (JSC::FTL::sizeOfICFor):
+ * ftl/FTLInlineCacheSize.h:
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLJSCallVarargs.cpp:
+ (JSC::FTL::JSCallVarargs::JSCallVarargs):
+ (JSC::FTL::JSCallVarargs::emit):
+ * ftl/FTLJSCallVarargs.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compilePutStack):
+ (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
+ (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
+ (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
+ (JSC::FTL::LowerDFGToLLVM::compileCreateActivation):
+ (JSC::FTL::LowerDFGToLLVM::compileNewFunction):
+ (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
+ (JSC::FTL::LowerDFGToLLVM::compileCreateScopedArguments):
+ (JSC::FTL::LowerDFGToLLVM::compileCreateClonedArguments):
+ (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
+ (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
+ (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
+ (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
+ (JSC::FTL::LowerDFGToLLVM::compileGetArgumentCount):
+ (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
+ (JSC::FTL::LowerDFGToLLVM::compilePutClosureVar):
+ (JSC::FTL::LowerDFGToLLVM::compileGetFromArguments):
+ (JSC::FTL::LowerDFGToLLVM::compilePutToArguments):
+ (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
+ (JSC::FTL::LowerDFGToLLVM::compileForwardVarargs):
+ (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname):
+ (JSC::FTL::LowerDFGToLLVM::ArgumentsLength::ArgumentsLength):
+ (JSC::FTL::LowerDFGToLLVM::getArgumentsLength):
+ (JSC::FTL::LowerDFGToLLVM::getCurrentCallee):
+ (JSC::FTL::LowerDFGToLLVM::getArgumentsStart):
+ (JSC::FTL::LowerDFGToLLVM::baseIndex):
+ (JSC::FTL::LowerDFGToLLVM::allocateObject):
+ (JSC::FTL::LowerDFGToLLVM::allocateVariableSizedObject):
+ (JSC::FTL::LowerDFGToLLVM::isArrayType):
+ (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
+ (JSC::FTL::LowerDFGToLLVM::loadStructure):
+ (JSC::FTL::LowerDFGToLLVM::compilePhantomArguments): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::compileCheckArgumentsNotCreated): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::checkArgumentsNotCreated): Deleted.
+ * ftl/FTLOSRExitCompiler.cpp:
+ (JSC::FTL::compileRecovery):
+ (JSC::FTL::compileStub):
+ * ftl/FTLOperations.cpp:
+ (JSC::FTL::operationMaterializeObjectInOSR):
+ * ftl/FTLOutput.h:
+ (JSC::FTL::Output::aShr):
+ (JSC::FTL::Output::lShr):
+ (JSC::FTL::Output::zeroExtPtr):
+ * heap/CopyToken.h:
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::getArgumentUnsafe):
+ * interpreter/Interpreter.cpp:
+ (JSC::sizeOfVarargs):
+ (JSC::sizeFrameForVarargs):
+ (JSC::loadVarargs):
+ (JSC::unwindCallFrame):
+ * interpreter/Interpreter.h:
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::createArguments):
+ (JSC::StackVisitor::Frame::existingArguments): Deleted.
+ * interpreter/StackVisitor.h:
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::storeValue):
+ (JSC::AssemblyHelpers::loadValue):
+ (JSC::AssemblyHelpers::storeTrustedValue):
+ (JSC::AssemblyHelpers::branchIfNotCell):
+ (JSC::AssemblyHelpers::branchIsEmpty):
+ (JSC::AssemblyHelpers::argumentsStart):
+ (JSC::AssemblyHelpers::baselineArgumentsRegisterFor): Deleted.
+ (JSC::AssemblyHelpers::offsetOfLocals): Deleted.
+ (JSC::AssemblyHelpers::offsetOfArguments): Deleted.
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgument):
+ * jit/GPRInfo.h:
+ (JSC::JSValueRegs::withTwoAvailableRegs):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ (JSC::JIT::privateCompileSlowCases):
+ * jit/JIT.h:
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_lexical_environment):
+ (JSC::JIT::emit_op_new_func):
+ (JSC::JIT::emit_op_create_direct_arguments):
+ (JSC::JIT::emit_op_create_scoped_arguments):
+ (JSC::JIT::emit_op_create_out_of_band_arguments):
+ (JSC::JIT::emit_op_tear_off_arguments): Deleted.
+ (JSC::JIT::emit_op_create_arguments): Deleted.
+ (JSC::JIT::emit_op_init_lazy_reg): Deleted.
+ (JSC::JIT::emit_op_get_arguments_length): Deleted.
+ (JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
+ (JSC::JIT::emit_op_get_argument_by_val): Deleted.
+ (JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_lexical_environment):
+ (JSC::JIT::emit_op_tear_off_arguments): Deleted.
+ (JSC::JIT::emit_op_create_arguments): Deleted.
+ (JSC::JIT::emit_op_init_lazy_reg): Deleted.
+ (JSC::JIT::emit_op_get_arguments_length): Deleted.
+ (JSC::JIT::emitSlow_op_get_arguments_length): Deleted.
+ (JSC::JIT::emit_op_get_argument_by_val): Deleted.
+ (JSC::JIT::emitSlow_op_get_argument_by_val): Deleted.
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitGetClosureVar):
+ (JSC::JIT::emitPutClosureVar):
+ (JSC::JIT::emit_op_get_from_arguments):
+ (JSC::JIT::emit_op_put_to_arguments):
+ (JSC::JIT::emit_op_init_global_const):
+ (JSC::JIT::privateCompileGetByVal):
+ (JSC::JIT::emitDirectArgumentsGetByVal):
+ (JSC::JIT::emitScopedArgumentsGetByVal):
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emitGetClosureVar):
+ (JSC::JIT::emitPutClosureVar):
+ (JSC::JIT::emit_op_get_from_arguments):
+ (JSC::JIT::emit_op_put_to_arguments):
+ (JSC::JIT::emit_op_init_global_const):
+ * jit/SetupVarargsFrame.cpp:
+ (JSC::emitSetupVarargsFrameFastCase):
+ * llint/LLIntOffsetsExtractor.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * parser/Nodes.h:
+ (JSC::ScopeNode::captures):
+ * runtime/Arguments.cpp: Removed.
+ * runtime/Arguments.h: Removed.
+ * runtime/ArgumentsMode.h: Added.
+ * runtime/DirectArgumentsOffset.cpp: Added.
+ (JSC::DirectArgumentsOffset::dump):
+ * runtime/DirectArgumentsOffset.h: Added.
+ (JSC::DirectArgumentsOffset::DirectArgumentsOffset):
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ * runtime/ConstantMode.cpp: Added.
+ (WTF::printInternal):
+ * runtime/ConstantMode.h:
+ (JSC::modeForIsConstant):
+ * runtime/DirectArguments.cpp: Added.
+ (JSC::DirectArguments::DirectArguments):
+ (JSC::DirectArguments::createUninitialized):
+ (JSC::DirectArguments::create):
+ (JSC::DirectArguments::createByCopying):
+ (JSC::DirectArguments::visitChildren):
+ (JSC::DirectArguments::copyBackingStore):
+ (JSC::DirectArguments::createStructure):
+ (JSC::DirectArguments::overrideThings):
+ (JSC::DirectArguments::overrideThingsIfNecessary):
+ (JSC::DirectArguments::overrideArgument):
+ (JSC::DirectArguments::copyToArguments):
+ (JSC::DirectArguments::overridesSize):
+ * runtime/DirectArguments.h: Added.
+ (JSC::DirectArguments::internalLength):
+ (JSC::DirectArguments::length):
+ (JSC::DirectArguments::canAccessIndexQuickly):
+ (JSC::DirectArguments::getIndexQuickly):
+ (JSC::DirectArguments::setIndexQuickly):
+ (JSC::DirectArguments::callee):
+ (JSC::DirectArguments::argument):
+ (JSC::DirectArguments::overrodeThings):
+ (JSC::DirectArguments::offsetOfCallee):
+ (JSC::DirectArguments::offsetOfLength):
+ (JSC::DirectArguments::offsetOfMinCapacity):
+ (JSC::DirectArguments::offsetOfOverrides):
+ (JSC::DirectArguments::storageOffset):
+ (JSC::DirectArguments::offsetOfSlot):
+ (JSC::DirectArguments::allocationSize):
+ (JSC::DirectArguments::storage):
+ * runtime/FunctionPrototype.cpp:
+ * runtime/GenericArguments.h: Added.
+ (JSC::GenericArguments::GenericArguments):
+ * runtime/GenericArgumentsInlines.h: Added.
+ (JSC::GenericArguments<Type>::getOwnPropertySlot):
+ (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
+ (JSC::GenericArguments<Type>::getOwnPropertyNames):
+ (JSC::GenericArguments<Type>::put):
+ (JSC::GenericArguments<Type>::putByIndex):
+ (JSC::GenericArguments<Type>::deleteProperty):
+ (JSC::GenericArguments<Type>::deletePropertyByIndex):
+ (JSC::GenericArguments<Type>::defineOwnProperty):
+ (JSC::GenericArguments<Type>::copyToArguments):
+ * runtime/GenericOffset.h: Added.
+ (JSC::GenericOffset::GenericOffset):
+ (JSC::GenericOffset::operator!):
+ (JSC::GenericOffset::offsetUnchecked):
+ (JSC::GenericOffset::offset):
+ (JSC::GenericOffset::operator==):
+ (JSC::GenericOffset::operator!=):
+ (JSC::GenericOffset::operator<):
+ (JSC::GenericOffset::operator>):
+ (JSC::GenericOffset::operator<=):
+ (JSC::GenericOffset::operator>=):
+ (JSC::GenericOffset::operator+):
+ (JSC::GenericOffset::operator-):
+ (JSC::GenericOffset::operator+=):
+ (JSC::GenericOffset::operator-=):
+ * runtime/JSArgumentsIterator.cpp:
+ (JSC::JSArgumentsIterator::finishCreation):
+ (JSC::argumentsFuncIterator):
+ * runtime/JSArgumentsIterator.h:
+ (JSC::JSArgumentsIterator::create):
+ (JSC::JSArgumentsIterator::next):
+ * runtime/JSEnvironmentRecord.cpp:
+ (JSC::JSEnvironmentRecord::visitChildren):
+ * runtime/JSEnvironmentRecord.h:
+ (JSC::JSEnvironmentRecord::variables):
+ (JSC::JSEnvironmentRecord::isValid):
+ (JSC::JSEnvironmentRecord::variableAt):
+ (JSC::JSEnvironmentRecord::offsetOfVariables):
+ (JSC::JSEnvironmentRecord::offsetOfVariable):
+ (JSC::JSEnvironmentRecord::allocationSizeForScopeSize):
+ (JSC::JSEnvironmentRecord::allocationSize):
+ (JSC::JSEnvironmentRecord::JSEnvironmentRecord):
+ (JSC::JSEnvironmentRecord::finishCreationUninitialized):
+ (JSC::JSEnvironmentRecord::finishCreation):
+ (JSC::JSEnvironmentRecord::registers): Deleted.
+ (JSC::JSEnvironmentRecord::registerAt): Deleted.
+ (JSC::JSEnvironmentRecord::addressOfRegisters): Deleted.
+ (JSC::JSEnvironmentRecord::offsetOfRegisters): Deleted.
+ * runtime/JSFunction.cpp:
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::addGlobalVar):
+ (JSC::JSGlobalObject::addFunction):
+ (JSC::JSGlobalObject::visitChildren):
+ (JSC::JSGlobalObject::addStaticGlobals):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::directArgumentsStructure):
+ (JSC::JSGlobalObject::scopedArgumentsStructure):
+ (JSC::JSGlobalObject::outOfBandArgumentsStructure):
+ (JSC::JSGlobalObject::argumentsStructure): Deleted.
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::symbolTableGet):
+ (JSC::JSLexicalEnvironment::symbolTablePut):
+ (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
+ (JSC::JSLexicalEnvironment::symbolTablePutWithAttributes):
+ (JSC::JSLexicalEnvironment::visitChildren): Deleted.
+ * runtime/JSLexicalEnvironment.h:
+ (JSC::JSLexicalEnvironment::create):
+ (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
+ (JSC::JSLexicalEnvironment::registersOffset): Deleted.
+ (JSC::JSLexicalEnvironment::storageOffset): Deleted.
+ (JSC::JSLexicalEnvironment::storage): Deleted.
+ (JSC::JSLexicalEnvironment::allocationSize): Deleted.
+ (JSC::JSLexicalEnvironment::isValidIndex): Deleted.
+ (JSC::JSLexicalEnvironment::isValid): Deleted.
+ (JSC::JSLexicalEnvironment::registerAt): Deleted.
+ * runtime/JSNameScope.cpp:
+ (JSC::JSNameScope::visitChildren): Deleted.
+ * runtime/JSNameScope.h:
+ (JSC::JSNameScope::create):
+ (JSC::JSNameScope::value):
+ (JSC::JSNameScope::finishCreation):
+ (JSC::JSNameScope::JSNameScope):
+ * runtime/JSScope.cpp:
+ (JSC::abstractAccess):
+ * runtime/JSSegmentedVariableObject.cpp:
+ (JSC::JSSegmentedVariableObject::findVariableIndex):
+ (JSC::JSSegmentedVariableObject::addVariables):
+ (JSC::JSSegmentedVariableObject::visitChildren):
+ (JSC::JSSegmentedVariableObject::findRegisterIndex): Deleted.
+ (JSC::JSSegmentedVariableObject::addRegisters): Deleted.
+ * runtime/JSSegmentedVariableObject.h:
+ (JSC::JSSegmentedVariableObject::variableAt):
+ (JSC::JSSegmentedVariableObject::assertVariableIsInThisObject):
+ (JSC::JSSegmentedVariableObject::registerAt): Deleted.
+ (JSC::JSSegmentedVariableObject::assertRegisterIsInThisObject): Deleted.
+ * runtime/JSSymbolTableObject.h:
+ (JSC::JSSymbolTableObject::offsetOfSymbolTable):
+ (JSC::symbolTableGet):
+ (JSC::symbolTablePut):
+ (JSC::symbolTablePutWithAttributes):
+ * runtime/JSType.h:
+ * runtime/Options.h:
+ * runtime/ClonedArguments.cpp: Added.
+ (JSC::ClonedArguments::ClonedArguments):
+ (JSC::ClonedArguments::createEmpty):
+ (JSC::ClonedArguments::createWithInlineFrame):
+ (JSC::ClonedArguments::createWithMachineFrame):
+ (JSC::ClonedArguments::createByCopyingFrom):
+ (JSC::ClonedArguments::createStructure):
+ (JSC::ClonedArguments::getOwnPropertySlot):
+ (JSC::ClonedArguments::getOwnPropertyNames):
+ (JSC::ClonedArguments::put):
+ (JSC::ClonedArguments::deleteProperty):
+ (JSC::ClonedArguments::defineOwnProperty):
+ (JSC::ClonedArguments::materializeSpecials):
+ (JSC::ClonedArguments::materializeSpecialsIfNecessary):
+ * runtime/ClonedArguments.h: Added.
+ (JSC::ClonedArguments::specialsMaterialized):
+ * runtime/ScopeOffset.cpp: Added.
+ (JSC::ScopeOffset::dump):
+ * runtime/ScopeOffset.h: Added.
+ (JSC::ScopeOffset::ScopeOffset):
+ * runtime/ScopedArguments.cpp: Added.
+ (JSC::ScopedArguments::ScopedArguments):
+ (JSC::ScopedArguments::finishCreation):
+ (JSC::ScopedArguments::createUninitialized):
+ (JSC::ScopedArguments::create):
+ (JSC::ScopedArguments::createByCopying):
+ (JSC::ScopedArguments::createByCopyingFrom):
+ (JSC::ScopedArguments::visitChildren):
+ (JSC::ScopedArguments::createStructure):
+ (JSC::ScopedArguments::overrideThings):
+ (JSC::ScopedArguments::overrideThingsIfNecessary):
+ (JSC::ScopedArguments::overrideArgument):
+ (JSC::ScopedArguments::copyToArguments):
+ * runtime/ScopedArguments.h: Added.
+ (JSC::ScopedArguments::internalLength):
+ (JSC::ScopedArguments::length):
+ (JSC::ScopedArguments::canAccessIndexQuickly):
+ (JSC::ScopedArguments::getIndexQuickly):
+ (JSC::ScopedArguments::setIndexQuickly):
+ (JSC::ScopedArguments::callee):
+ (JSC::ScopedArguments::overrodeThings):
+ (JSC::ScopedArguments::offsetOfOverrodeThings):
+ (JSC::ScopedArguments::offsetOfTotalLength):
+ (JSC::ScopedArguments::offsetOfTable):
+ (JSC::ScopedArguments::offsetOfScope):
+ (JSC::ScopedArguments::overflowStorageOffset):
+ (JSC::ScopedArguments::allocationSize):
+ (JSC::ScopedArguments::overflowStorage):
+ * runtime/ScopedArgumentsTable.cpp: Added.
+ (JSC::ScopedArgumentsTable::ScopedArgumentsTable):
+ (JSC::ScopedArgumentsTable::~ScopedArgumentsTable):
+ (JSC::ScopedArgumentsTable::destroy):
+ (JSC::ScopedArgumentsTable::create):
+ (JSC::ScopedArgumentsTable::clone):
+ (JSC::ScopedArgumentsTable::setLength):
+ (JSC::ScopedArgumentsTable::set):
+ (JSC::ScopedArgumentsTable::createStructure):
+ * runtime/ScopedArgumentsTable.h: Added.
+ (JSC::ScopedArgumentsTable::length):
+ (JSC::ScopedArgumentsTable::get):
+ (JSC::ScopedArgumentsTable::lock):
+ (JSC::ScopedArgumentsTable::offsetOfLength):
+ (JSC::ScopedArgumentsTable::offsetOfArguments):
+ (JSC::ScopedArgumentsTable::at):
+ * runtime/SymbolTable.cpp:
+ (JSC::SymbolTableEntry::prepareToWatch):
+ (JSC::SymbolTable::SymbolTable):
+ (JSC::SymbolTable::visitChildren):
+ (JSC::SymbolTable::localToEntry):
+ (JSC::SymbolTable::entryFor):
+ (JSC::SymbolTable::cloneScopePart):
+ (JSC::SymbolTable::prepareForTypeProfiling):
+ (JSC::SymbolTable::uniqueIDForOffset):
+ (JSC::SymbolTable::globalTypeSetForOffset):
+ (JSC::SymbolTable::cloneCapturedNames): Deleted.
+ (JSC::SymbolTable::uniqueIDForRegister): Deleted.
+ (JSC::SymbolTable::globalTypeSetForRegister): Deleted.
+ * runtime/SymbolTable.h:
+ (JSC::SymbolTableEntry::varOffsetFromBits):
+ (JSC::SymbolTableEntry::scopeOffsetFromBits):
+ (JSC::SymbolTableEntry::Fast::varOffset):
+ (JSC::SymbolTableEntry::Fast::scopeOffset):
+ (JSC::SymbolTableEntry::Fast::isDontEnum):
+ (JSC::SymbolTableEntry::Fast::getAttributes):
+ (JSC::SymbolTableEntry::SymbolTableEntry):
+ (JSC::SymbolTableEntry::varOffset):
+ (JSC::SymbolTableEntry::isWatchable):
+ (JSC::SymbolTableEntry::scopeOffset):
+ (JSC::SymbolTableEntry::setAttributes):
+ (JSC::SymbolTableEntry::constantMode):
+ (JSC::SymbolTableEntry::isDontEnum):
+ (JSC::SymbolTableEntry::disableWatching):
+ (JSC::SymbolTableEntry::pack):
+ (JSC::SymbolTableEntry::isValidVarOffset):
+ (JSC::SymbolTable::createNameScopeTable):
+ (JSC::SymbolTable::maxScopeOffset):
+ (JSC::SymbolTable::didUseScopeOffset):
+ (JSC::SymbolTable::didUseVarOffset):
+ (JSC::SymbolTable::scopeSize):
+ (JSC::SymbolTable::nextScopeOffset):
+ (JSC::SymbolTable::takeNextScopeOffset):
+ (JSC::SymbolTable::add):
+ (JSC::SymbolTable::set):
+ (JSC::SymbolTable::argumentsLength):
+ (JSC::SymbolTable::setArgumentsLength):
+ (JSC::SymbolTable::argumentOffset):
+ (JSC::SymbolTable::setArgumentOffset):
+ (JSC::SymbolTable::arguments):
+ (JSC::SlowArgument::SlowArgument): Deleted.
+ (JSC::SymbolTableEntry::Fast::getIndex): Deleted.
+ (JSC::SymbolTableEntry::getIndex): Deleted.
+ (JSC::SymbolTableEntry::isValidIndex): Deleted.
+ (JSC::SymbolTable::captureStart): Deleted.
+ (JSC::SymbolTable::setCaptureStart): Deleted.
+ (JSC::SymbolTable::captureEnd): Deleted.
+ (JSC::SymbolTable::setCaptureEnd): Deleted.
+ (JSC::SymbolTable::captureCount): Deleted.
+ (JSC::SymbolTable::isCaptured): Deleted.
+ (JSC::SymbolTable::parameterCount): Deleted.
+ (JSC::SymbolTable::parameterCountIncludingThis): Deleted.
+ (JSC::SymbolTable::setParameterCountIncludingThis): Deleted.
+ (JSC::SymbolTable::slowArguments): Deleted.
+ (JSC::SymbolTable::setSlowArguments): Deleted.
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+ * runtime/VarOffset.cpp: Added.
+ (JSC::VarOffset::dump):
+ (WTF::printInternal):
+ * runtime/VarOffset.h: Added.
+ (JSC::VarOffset::VarOffset):
+ (JSC::VarOffset::assemble):
+ (JSC::VarOffset::isValid):
+ (JSC::VarOffset::operator!):
+ (JSC::VarOffset::kind):
+ (JSC::VarOffset::isStack):
+ (JSC::VarOffset::isScope):
+ (JSC::VarOffset::isDirectArgument):
+ (JSC::VarOffset::stackOffsetUnchecked):
+ (JSC::VarOffset::scopeOffsetUnchecked):
+ (JSC::VarOffset::capturedArgumentsOffsetUnchecked):
+ (JSC::VarOffset::stackOffset):
+ (JSC::VarOffset::scopeOffset):
+ (JSC::VarOffset::capturedArgumentsOffset):
+ (JSC::VarOffset::rawOffset):
+ (JSC::VarOffset::checkSanity):
+ (JSC::VarOffset::operator==):
+ (JSC::VarOffset::operator!=):
+ (JSC::VarOffset::hash):
+ (JSC::VarOffset::isHashTableDeletedValue):
+ (JSC::VarOffsetHash::hash):
+ (JSC::VarOffsetHash::equal):
+ * tests/stress/arguments-exit-strict-mode.js: Added.
+ * tests/stress/arguments-exit.js: Added.
+ * tests/stress/arguments-inlined-exit-strict-mode-fixed.js: Added.
+ * tests/stress/arguments-inlined-exit-strict-mode.js: Added.
+ * tests/stress/arguments-inlined-exit.js: Added.
+ * tests/stress/arguments-interference.js: Added.
+ * tests/stress/arguments-interference-cfg.js: Added.
+ * tests/stress/dead-get-closure-var.js: Added.
+ * tests/stress/get-declared-unpassed-argument-in-direct-arguments.js: Added.
+ * tests/stress/get-declared-unpassed-argument-in-scoped-arguments.js: Added.
+ * tests/stress/varargs-closure-inlined-exit-strict-mode.js: Added.
+ * tests/stress/varargs-closure-inlined-exit.js: Added.
+ * tests/stress/varargs-exit.js: Added.
+ * tests/stress/varargs-inlined-exit.js: Added.
+ * tests/stress/varargs-inlined-simple-exit-aliasing-weird-reversed-args.js: Added.
+ * tests/stress/varargs-inlined-simple-exit-aliasing-weird.js: Added.
+ * tests/stress/varargs-inlined-simple-exit-aliasing.js: Added.
+ * tests/stress/varargs-inlined-simple-exit.js: Added.
+ * tests/stress/varargs-too-few-arguments.js: Added.
+ * tests/stress/varargs-varargs-closure-inlined-exit.js: Added.
+ * tests/stress/varargs-varargs-inlined-exit-strict-mode.js: Added.
+ * tests/stress/varargs-varargs-inlined-exit.js: Added.
+
+2015-03-25 Andy Estes <aestes@apple.com>
+
+ [Cocoa] RemoteInspectorXPCConnection::deserializeMessage() leaks a NSDictionary under Objective-C GC
+ https://bugs.webkit.org/show_bug.cgi?id=143068
+
+ Reviewed by Dan Bernstein.
+
+ * inspector/remote/RemoteInspectorXPCConnection.mm:
+ (Inspector::RemoteInspectorXPCConnection::deserializeMessage): Used RetainPtr::autorelease(), which does the right thing under GC.
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Use JITCompilationCanFail in more places, and make the fail path of JITCompilationMustSucceed a crash instead of attempting GC
+ https://bugs.webkit.org/show_bug.cgi?id=142993
+
+ Reviewed by Geoffrey Garen and Mark Lam.
+
+ This changes the most commonly invoked paths that relied on JITCompilationMustSucceed
+ into using JITCompilationCanFail and having a legit fallback path. This mostly involves
+ having the FTL JIT do the same trick as the DFG JIT in case of any memory allocation
+ failure, but also involves adding the same kind of thing to the stub generators in
+ Repatch.
+
+ Because of that change, there are relatively few uses of JITCompilationMustSucceed. Most
+ of those uses cannot handle a GC, and so cannot do releaseExecutableMemory(). Only a few,
+ like host call stub generation, could handle a GC, but those get invoked very rarely. So,
+ this patch changes the releaseExecutableMemory() call into a crash with some diagnostic
+ printout.
+
+ Also add a way of inducing executable allocation failure, so that we can test this.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::compile):
+ (JSC::DFG::JITCompiler::compileFunction):
+ (JSC::DFG::JITCompiler::link): Deleted.
+ (JSC::DFG::JITCompiler::linkFunction): Deleted.
+ * dfg/DFGJITCompiler.h:
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateCodeSection):
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLLink.cpp:
+ (JSC::FTL::link):
+ * ftl/FTLState.h:
+ * jit/ArityCheckFailReturnThunks.cpp:
+ (JSC::ArityCheckFailReturnThunks::returnPCsFor):
+ * jit/ExecutableAllocationFuzz.cpp: Added.
+ (JSC::numberOfExecutableAllocationFuzzChecks):
+ (JSC::doExecutableAllocationFuzzing):
+ * jit/ExecutableAllocationFuzz.h: Added.
+ (JSC::doExecutableAllocationFuzzingIfEnabled):
+ * jit/ExecutableAllocatorFixedVMPool.cpp:
+ (JSC::ExecutableAllocator::allocate):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+ * jit/JITCompilationEffort.h:
+ * jit/Repatch.cpp:
+ (JSC::generateByIdStub):
+ (JSC::tryCacheGetByID):
+ (JSC::tryBuildGetByIDList):
+ (JSC::emitPutReplaceStub):
+ (JSC::emitPutTransitionStubAndGetOldStructure):
+ (JSC::tryCachePutByID):
+ (JSC::tryBuildPutByIdList):
+ (JSC::tryRepatchIn):
+ (JSC::linkPolymorphicCall):
+ * jsc.cpp:
+ (jscmain):
+ * runtime/Options.h:
+ * runtime/TestRunnerUtils.h:
+ * runtime/VM.cpp:
+ * tests/executableAllocationFuzz: Added.
+ * tests/executableAllocationFuzz.yaml: Added.
+ * tests/executableAllocationFuzz/v8-raytrace.js: Added.
+
+2015-03-25 Mark Lam <mark.lam@apple.com>
+
+ REGRESSION(169139): LLINT intermittently fails JSC testapi tests.
+ <https://webkit.org/b/135719>
+
+ Reviewed by Geoffrey Garen.
+
+ This is a regression introduced in http://trac.webkit.org/changeset/169139 which
+ changed VM::watchdog from an embedded field into a std::unique_ptr, but did not
+ update the LLINT to access it as such.
+
+ The issue has only manifested so far on the CLoop tests because those are LLINT
+ only. In the non-CLoop cases, the JIT kicks in and does the right thing, thereby
+ hiding the bug in the LLINT.
+
+ * API/JSContextRef.cpp:
+ (createWatchdogIfNeeded):
+ (JSContextGroupSetExecutionTimeLimit):
+ (JSContextGroupClearExecutionTimeLimit):
+ * llint/LowLevelInterpreter.asm:
+
+2015-03-25 Filip Pizlo <fpizlo@apple.com>
+
+ Change Atomic methods from using the_wrong_naming_conventions to using theRightNamingConventions. Also make seq_cst the default.
+
+ Rubber stamped by Geoffrey Garen.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::visitAggregate):
+
+2015-03-25 Joseph Pecoraro <pecoraro@apple.com>
+
+ Fix formatting in BuiltinExecutables
+ https://bugs.webkit.org/show_bug.cgi?id=143061
+
+ Reviewed by Ryosuke Niwa.
+
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createExecutableInternal):
+
+2015-03-25 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Classes: Program level class statement throws exception in strict mode
+ https://bugs.webkit.org/show_bug.cgi?id=143038
+
+ Reviewed by Ryosuke Niwa.
+
+ Classes expose a name to the current lexical environment. This treats
+ "class X {}" like "var X = class X {}". Ideally it would be "let X = class X {}".
+ Also, improve error messages for class statements where the class is missing a name.
+
+ * parser/Parser.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+ Fill name in info parameter if needed. Better error message if name is needed and missing.
+
+ (JSC::Parser<LexerType>::parseClassDeclaration):
+ Pass info parameter to get name, and expose the name as a variable name.
+
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ Pass info parameter that is ignored.
+
+ * parser/ParserFunctionInfo.h:
+ Add a parser info for class, to extract the name.
+
+2015-03-25 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ New map and set modification tests in r181922 fails
+ https://bugs.webkit.org/show_bug.cgi?id=143031
+
+ Reviewed and tweaked by Geoffrey Garen.
+
+ When packing Map/Set backing store, we need to decrement Map/Set iterator's m_index
+ to adjust for the packed backing store.
+
+ Consider the following map data.
+
+ x: deleted, o: exists
+ 0 1 2 3 4
+ x x x x o
+
+ And iterator with m_index 3.
+
+ When packing the map data, map data will become,
+
+ 0
+ o
+
+ At that time, we perfom didRemoveEntry 4 times on iterators.
+ times => m_index/index/result
+ 1 => 3/0/dec
+ 2 => 2/1/dec
+ 3 => 1/2/nothing
+ 4 => 1/3/nothing
+
+ After iteration, iterator's m_index becomes 1. But we expected that becomes 0.
+ This is because if we use decremented m_index for comparison,
+ while provided deletedIndex is the index in old storage, m_index is the index in partially packed storage.
+
+ In this patch, we compare against the packed index instead.
+ times => m_index/packedIndex/result
+ 1 => 3/0/dec
+ 2 => 2/0/dec
+ 3 => 1/0/dec
+ 4 => 0/0/nothing
+
+ So m_index becomes 0 as expected.
+
+ And according to the spec, once the iterator is closed (becomes done: true),
+ its internal [[Map]]/[[Set]] is set to undefined.
+ So after the iterator is finished, we don't revive the iterator (e.g. by clearing m_index = 0).
+
+ In this patch, we change 2 things.
+ 1.
+ Compare an iterator's index against the packed index when removing an entry.
+
+ 2.
+ If the iterator is closed (isFinished()), we don't apply adjustment to the iterator.
+
+ * runtime/MapData.h:
+ (JSC::MapDataImpl::IteratorData::finish):
+ (JSC::MapDataImpl::IteratorData::isFinished):
+ (JSC::MapDataImpl::IteratorData::didRemoveEntry):
+ (JSC::MapDataImpl::IteratorData::didRemoveAllEntries):
+ (JSC::MapDataImpl::IteratorData::startPackBackingStore):
+ * runtime/MapDataInlines.h:
+ (JSC::JSIterator>::replaceAndPackBackingStore):
+ * tests/stress/modify-map-during-iteration.js:
+ * tests/stress/modify-set-during-iteration.js:
+
+2015-03-24 Joseph Pecoraro <pecoraro@apple.com>
+
+ Setter should have a single formal parameter, Getter no parameters
+ https://bugs.webkit.org/show_bug.cgi?id=142903
+
+ Reviewed by Geoffrey Garen.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+ Enforce no parameters for getters and a single parameter
+ for setters, with informational error messages.
+
+2015-03-24 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Classes: Early return in sub-class constructor results in returning undefined instead of instance
+ https://bugs.webkit.org/show_bug.cgi?id=143012
+
+ Reviewed by Ryosuke Niwa.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitReturn):
+ Fix handling of "undefined" when returned from a Derived class. It was
+ returning "undefined" when it should have returned "this".
+
+2015-03-24 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION (r181458): Heap use-after-free in JSSetIterator destructor
+ https://bugs.webkit.org/show_bug.cgi?id=142696
+
+ Reviewed and tweaked by Geoffrey Garen.
+
+ Before r142556, JSSetIterator::destroy was not defined.
+ So accidentally MapData::const_iterator in JSSet was never destroyed.
+ But it had non trivial destructor, decrementing MapData->m_iteratorCount.
+
+ After r142556, JSSetIterator::destroy works.
+ It correctly destruct MapData::const_iterator and m_iteratorCount partially works.
+ But JSSetIterator::~JSSetIterator requires owned JSSet since it mutates MapData->m_iteratorCount.
+
+ It is guaranteed that JSSet is live since JSSetIterator has a reference to JSSet
+ and marks it in visitChildren (WriteBarrier<Unknown>).
+ However, the order of destructions is not guaranteed in GC-ed system.
+
+ Consider the following case,
+ allocate JSSet and subsequently allocate JSSetIterator.
+ And they resides in the separated MarkedBlock, <1> and <2>.
+
+ JSSet<1> <- JSSetIterator<2>
+
+ And after that, when performing GC, Marker decides that the above 2 objects are not marked.
+ And Marker also decides MarkedBlocks <1> and <2> can be sweeped.
+
+ First Sweeper sweep <1>, destruct JSSet<1> and free MarkedBlock<1>.
+ Second Sweeper sweep <2>, attempt to destruct JSSetIterator<2>.
+ However, JSSetIterator<2>'s destructor,
+ JSSetIterator::~JSSetIterator requires live JSSet<1>, it causes use-after-free.
+
+ In this patch, we introduce WeakGCMap into JSMap/JSSet to track live iterators.
+ When packing the removed elements in JSSet/JSMap, we apply the change to all live
+ iterators tracked by WeakGCMap.
+
+ WeakGCMap can only track JSCell since they are managed by GC.
+ So we drop JSSet/JSMap C++ style iterators. Instead of C++ style iterator, this patch
+ introduces JS style iterator signatures into C++ class IteratorData.
+ If we need to iterate over JSMap/JSSet, use JSSetIterator/JSMapIterator instead of using
+ IteratorData directly.
+
+ * runtime/JSMap.cpp:
+ (JSC::JSMap::destroy):
+ * runtime/JSMap.h:
+ (JSC::JSMap::JSMap):
+ (JSC::JSMap::begin): Deleted.
+ (JSC::JSMap::end): Deleted.
+ * runtime/JSMapIterator.cpp:
+ (JSC::JSMapIterator::destroy):
+ * runtime/JSMapIterator.h:
+ (JSC::JSMapIterator::next):
+ (JSC::JSMapIterator::nextKeyValue):
+ (JSC::JSMapIterator::iteratorData):
+ (JSC::JSMapIterator::JSMapIterator):
+ * runtime/JSSet.cpp:
+ (JSC::JSSet::destroy):
+ * runtime/JSSet.h:
+ (JSC::JSSet::JSSet):
+ (JSC::JSSet::begin): Deleted.
+ (JSC::JSSet::end): Deleted.
+ * runtime/JSSetIterator.cpp:
+ (JSC::JSSetIterator::destroy):
+ * runtime/JSSetIterator.h:
+ (JSC::JSSetIterator::next):
+ (JSC::JSSetIterator::iteratorData):
+ (JSC::JSSetIterator::JSSetIterator):
+ * runtime/MapData.h:
+ (JSC::MapDataImpl::IteratorData::finish):
+ (JSC::MapDataImpl::IteratorData::isFinished):
+ (JSC::MapDataImpl::shouldPack):
+ (JSC::JSIterator>::MapDataImpl):
+ (JSC::JSIterator>::KeyType::KeyType):
+ (JSC::JSIterator>::IteratorData::IteratorData):
+ (JSC::JSIterator>::IteratorData::next):
+ (JSC::JSIterator>::IteratorData::ensureSlot):
+ (JSC::JSIterator>::IteratorData::applyMapDataPatch):
+ (JSC::JSIterator>::IteratorData::refreshCursor):
+ (JSC::MapDataImpl::const_iterator::key): Deleted.
+ (JSC::MapDataImpl::const_iterator::value): Deleted.
+ (JSC::MapDataImpl::const_iterator::operator++): Deleted.
+ (JSC::MapDataImpl::const_iterator::finish): Deleted.
+ (JSC::MapDataImpl::const_iterator::atEnd): Deleted.
+ (JSC::MapDataImpl::begin): Deleted.
+ (JSC::MapDataImpl::end): Deleted.
+ (JSC::MapDataImpl<Entry>::MapDataImpl): Deleted.
+ (JSC::MapDataImpl<Entry>::clear): Deleted.
+ (JSC::MapDataImpl<Entry>::KeyType::KeyType): Deleted.
+ (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement): Deleted.
+ (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot): Deleted.
+ (JSC::MapDataImpl<Entry>::const_iterator::const_iterator): Deleted.
+ (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator): Deleted.
+ (JSC::MapDataImpl<Entry>::const_iterator::operator): Deleted.
+ (JSC::=): Deleted.
+ * runtime/MapDataInlines.h:
+ (JSC::JSIterator>::clear):
+ (JSC::JSIterator>::find):
+ (JSC::JSIterator>::contains):
+ (JSC::JSIterator>::add):
+ (JSC::JSIterator>::set):
+ (JSC::JSIterator>::get):
+ (JSC::JSIterator>::remove):
+ (JSC::JSIterator>::replaceAndPackBackingStore):
+ (JSC::JSIterator>::replaceBackingStore):
+ (JSC::JSIterator>::ensureSpaceForAppend):
+ (JSC::JSIterator>::visitChildren):
+ (JSC::JSIterator>::copyBackingStore):
+ (JSC::JSIterator>::applyMapDataPatch):
+ (JSC::MapDataImpl<Entry>::find): Deleted.
+ (JSC::MapDataImpl<Entry>::contains): Deleted.
+ (JSC::MapDataImpl<Entry>::add): Deleted.
+ (JSC::MapDataImpl<Entry>::set): Deleted.
+ (JSC::MapDataImpl<Entry>::get): Deleted.
+ (JSC::MapDataImpl<Entry>::remove): Deleted.
+ (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore): Deleted.
+ (JSC::MapDataImpl<Entry>::replaceBackingStore): Deleted.
+ (JSC::MapDataImpl<Entry>::ensureSpaceForAppend): Deleted.
+ (JSC::MapDataImpl<Entry>::visitChildren): Deleted.
+ (JSC::MapDataImpl<Entry>::copyBackingStore): Deleted.
+ * runtime/MapPrototype.cpp:
+ (JSC::mapProtoFuncForEach):
+ * runtime/SetPrototype.cpp:
+ (JSC::setProtoFuncForEach):
+ * runtime/WeakGCMap.h:
+ (JSC::WeakGCMap::forEach):
+ * tests/stress/modify-map-during-iteration.js: Added.
+ (testValue):
+ (identityPairs):
+ (.set if):
+ (var):
+ (set map):
+ * tests/stress/modify-set-during-iteration.js: Added.
+ (testValue):
+ (set forEach):
+ (set delete):
+
+2015-03-24 Mark Lam <mark.lam@apple.com>
+
+ The ExecutionTimeLimit test should use its own JSGlobalContextRef.
+ <https://webkit.org/b/143024>
+
+ Reviewed by Geoffrey Garen.
+
+ Currently, the ExecutionTimeLimit test is using a JSGlobalContextRef
+ passed in from testapi.c. It should create its own for better
+ encapsulation of the test.
+
+ * API/tests/ExecutionTimeLimitTest.cpp:
+ (currentCPUTimeAsJSFunctionCallback):
+ (testExecutionTimeLimit):
+ * API/tests/ExecutionTimeLimitTest.h:
+ * API/tests/testapi.c:
+ (main):
+
+2015-03-24 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Object Literal Methods toString is missing method name
+ https://bugs.webkit.org/show_bug.cgi?id=142992
+
+ Reviewed by Geoffrey Garen.
+
+ Always stringify functions in the pattern:
+
+ "function " + <function name> + <text from opening parenthesis to closing brace>.
+
+ * runtime/FunctionPrototype.cpp:
+ (JSC::functionProtoFuncToString):
+ Update the path that was not stringifying in this pattern.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedFunctionExecutable::parametersStartOffset):
+ * parser/Nodes.h:
+ * runtime/Executable.cpp:
+ (JSC::FunctionExecutable::FunctionExecutable):
+ * runtime/Executable.h:
+ (JSC::FunctionExecutable::parametersStartOffset):
+ Pass the already known function parameter opening parenthesis
+ start offset through to the FunctionExecutable.
+
+ * tests/mozilla/js1_5/Scope/regress-185485.js:
+ (with.g):
+ Add back original space in this test that was removed by r181810
+ now that we have the space again in stringification.
+
+2015-03-24 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (172175-172177): Change in for...in processing causes properties added in loop to be enumerated
+ https://bugs.webkit.org/show_bug.cgi?id=142856
+
+ Reviewed by Filip Pizlo.
+
+ Refactored the way the for .. in enumeration over objects is done. We used to make three C++ calls to
+ get info for three loops to iterate over indexed properties, structure properties and other properties,
+ respectively. We still have the three loops, but now we make one C++ call to get all the info needed
+ for all loops before we exectue any enumeration.
+
+ The JSPropertyEnumerator has a count of the indexed properties and a list of named properties.
+ The named properties are one list, with structured properties in the range [0,m_endStructurePropertyIndex)
+ and the generic properties in the range [m_endStructurePropertyIndex, m_endGenericPropertyIndex);
+
+ Eliminated the bytecodes op_get_structure_property_enumerator, op_get_generic_property_enumerator and
+ op_next_enumerator_pname.
+ Added the bytecodes op_get_property_enumerator, op_enumerator_structure_pname and op_enumerator_generic_pname.
+ The bytecodes op_enumerator_structure_pname and op_enumerator_generic_pname are similar except for what
+ end value we stop iterating on.
+
+ Made corresponding node changes to the DFG and FTL for the bytecode changes.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitGetPropertyEnumerator):
+ (JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName):
+ (JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName):
+ (JSC::BytecodeGenerator::emitGetStructurePropertyEnumerator): Deleted.
+ (JSC::BytecodeGenerator::emitGetGenericPropertyEnumerator): Deleted.
+ (JSC::BytecodeGenerator::emitNextEnumeratorPropertyName): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ForInNode::emitMultiLoopBytecode):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * 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):
+ * ftl/FTLAbstractHeapRepository.h:
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileGetEnumerableLength):
+ (JSC::FTL::LowerDFGToLLVM::compileGetPropertyEnumerator):
+ (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorStructurePname):
+ (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorGenericPname):
+ (JSC::FTL::LowerDFGToLLVM::compileGetStructurePropertyEnumerator): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::compileGetGenericPropertyEnumerator): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::compileGetEnumeratorPname): Deleted.
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_enumerator_structure_pname):
+ (JSC::JIT::emit_op_enumerator_generic_pname):
+ (JSC::JIT::emit_op_get_property_enumerator):
+ (JSC::JIT::emit_op_next_enumerator_pname): Deleted.
+ (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
+ (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_enumerator_structure_pname):
+ (JSC::JIT::emit_op_enumerator_generic_pname):
+ (JSC::JIT::emit_op_next_enumerator_pname): Deleted.
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * llint/LowLevelInterpreter.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ * runtime/JSPropertyNameEnumerator.cpp:
+ (JSC::JSPropertyNameEnumerator::create):
+ (JSC::JSPropertyNameEnumerator::finishCreation):
+ * runtime/JSPropertyNameEnumerator.h:
+ (JSC::JSPropertyNameEnumerator::indexedLength):
+ (JSC::JSPropertyNameEnumerator::endStructurePropertyIndex):
+ (JSC::JSPropertyNameEnumerator::endGenericPropertyIndex):
+ (JSC::JSPropertyNameEnumerator::indexedLengthOffset):
+ (JSC::JSPropertyNameEnumerator::endStructurePropertyIndexOffset):
+ (JSC::JSPropertyNameEnumerator::endGenericPropertyIndexOffset):
+ (JSC::JSPropertyNameEnumerator::cachedInlineCapacityOffset):
+ (JSC::propertyNameEnumerator):
+ (JSC::JSPropertyNameEnumerator::cachedPropertyNamesLengthOffset): Deleted.
+ (JSC::structurePropertyNameEnumerator): Deleted.
+ (JSC::genericPropertyNameEnumerator): Deleted.
+ * runtime/Structure.cpp:
+ (JSC::Structure::setCachedPropertyNameEnumerator):
+ (JSC::Structure::cachedPropertyNameEnumerator):
+ (JSC::Structure::canCachePropertyNameEnumerator):
+ (JSC::Structure::setCachedStructurePropertyNameEnumerator): Deleted.
+ (JSC::Structure::cachedStructurePropertyNameEnumerator): Deleted.
+ (JSC::Structure::setCachedGenericPropertyNameEnumerator): Deleted.
+ (JSC::Structure::cachedGenericPropertyNameEnumerator): Deleted.
+ (JSC::Structure::canCacheStructurePropertyNameEnumerator): Deleted.
+ (JSC::Structure::canCacheGenericPropertyNameEnumerator): Deleted.
+ * runtime/Structure.h:
+ * runtime/StructureRareData.cpp:
+ (JSC::StructureRareData::visitChildren):
+ (JSC::StructureRareData::cachedPropertyNameEnumerator):
+ (JSC::StructureRareData::setCachedPropertyNameEnumerator):
+ (JSC::StructureRareData::cachedStructurePropertyNameEnumerator): Deleted.
+ (JSC::StructureRareData::setCachedStructurePropertyNameEnumerator): Deleted.
+ (JSC::StructureRareData::cachedGenericPropertyNameEnumerator): Deleted.
+ (JSC::StructureRareData::setCachedGenericPropertyNameEnumerator): Deleted.
+ * runtime/StructureRareData.h:
+ * tests/stress/for-in-delete-during-iteration.js:
+
+2015-03-24 Michael Saboff <msaboff@apple.com>
+
+ Unreviewed build fix for debug builds.
+
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::invalidParameterInSourceAppender):
+
+2015-03-24 Saam Barati <saambarati1@gmail.com>
+
+ Improve error messages in JSC
+ https://bugs.webkit.org/show_bug.cgi?id=141869
+
+ Reviewed by Geoffrey Garen.
+
+ JavaScriptCore has some unintuitive error messages associated
+ with certain common errors. This patch changes some specific
+ error messages to be more understandable and also creates a
+ mechanism that will allow for easy modification of error messages
+ in the future. The specific errors we change are not a function
+ errors and invalid parameter errors.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * interpreter/Interpreter.cpp:
+ (JSC::sizeOfVarargs):
+ * jit/JITOperations.cpp:
+ op_throw_static_error always has a JSString as its argument.
+ There is no need to dance around this, and we should assert
+ that this always holds. This JSString represents the error
+ message we want to display to the user, so there is no need
+ to pass it into errorDescriptionForValue which will now place
+ quotes around the string.
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ (JSC::CommonSlowPaths::opIn):
+ * runtime/ErrorInstance.cpp:
+ (JSC::ErrorInstance::ErrorInstance):
+ * runtime/ErrorInstance.h:
+ (JSC::ErrorInstance::hasSourceAppender):
+ (JSC::ErrorInstance::sourceAppender):
+ (JSC::ErrorInstance::setSourceAppender):
+ (JSC::ErrorInstance::clearSourceAppender):
+ (JSC::ErrorInstance::setRuntimeTypeForCause):
+ (JSC::ErrorInstance::runtimeTypeForCause):
+ (JSC::ErrorInstance::clearRuntimeTypeForCause):
+ (JSC::ErrorInstance::appendSourceToMessage): Deleted.
+ (JSC::ErrorInstance::setAppendSourceToMessage): Deleted.
+ (JSC::ErrorInstance::clearAppendSourceToMessage): Deleted.
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::errorDescriptionForValue):
+ (JSC::defaultApproximateSourceError):
+ (JSC::defaultSourceAppender):
+ (JSC::functionCallBase):
+ (JSC::notAFunctionSourceAppender):
+ (JSC::invalidParameterInSourceAppender):
+ (JSC::invalidParameterInstanceofSourceAppender):
+ (JSC::createError):
+ (JSC::createInvalidFunctionApplyParameterError):
+ (JSC::createInvalidInParameterError):
+ (JSC::createInvalidInstanceofParameterError):
+ (JSC::createNotAConstructorError):
+ (JSC::createNotAFunctionError):
+ (JSC::createNotAnObjectError):
+ (JSC::createInvalidParameterError): Deleted.
+ * runtime/ExceptionHelpers.h:
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::hasInstance):
+ * runtime/RuntimeType.cpp: Added.
+ (JSC::runtimeTypeForValue):
+ (JSC::runtimeTypeAsString):
+ * runtime/RuntimeType.h: Added.
+ * runtime/TypeProfilerLog.cpp:
+ (JSC::TypeProfilerLog::processLogEntries):
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::getRuntimeTypeForValue): Deleted.
+ * runtime/TypeSet.h:
+ * runtime/VM.cpp:
+ (JSC::appendSourceToError):
+ (JSC::VM::throwException):
+
+2015-03-23 Filip Pizlo <fpizlo@apple.com>
+
+ JSC should have a low-cost asynchronous disassembler
+ https://bugs.webkit.org/show_bug.cgi?id=142997
+
+ Reviewed by Mark Lam.
+
+ This adds a JSC_asyncDisassembly option that disassembles on a thread. Disassembly
+ doesn't block execution. Some code will live a little longer because of this, since the
+ work tasks hold a ref to the code, but other than that there is basically no overhead.
+
+ At present, this isn't really a replacement for JSC_showDisassembly, since it doesn't
+ provide contextual IR information for Baseline and DFG disassemblies, and it doesn't do
+ the separate IR dumps for FTL. Using JSC_showDisassembly and friends along with
+ JSC_asyncDisassembly has bizarre behavior - so just choose one.
+
+ A simple way of understanding how great this is, is to run a small benchmark like
+ V8Spider/earley-boyer.
+
+ Performance without any disassembly flags: 60ms
+ Performance with JSC_showDisassembly=true: 477ms
+ Performance with JSC_asyncDisassembly=true: 65ms
+
+ So, the overhead of disassembly goes from 8x to 8%.
+
+ Note that JSC_asyncDisassembly=true does make it incorrect to run "time" as a way of
+ measuring benchmark performance. This is because at VM exit, we wait for all async
+ disassembly requests to finish. For example, for earley-boyer, we spend an extra ~130ms
+ after the benchmark completely finishes to finish the disassemblies. This small weirdness
+ should be OK for the intended use-cases, since all you have to do to get around it is to
+ measure the execution time of the benchmark payload rather than the end-to-end time of
+ launching the VM.
+
+ * assembler/LinkBuffer.cpp:
+ (JSC::LinkBuffer::finalizeCodeWithDisassembly):
+ * assembler/LinkBuffer.h:
+ (JSC::LinkBuffer::wasAlreadyDisassembled):
+ (JSC::LinkBuffer::didAlreadyDisassemble):
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::disassemble):
+ * dfg/DFGJITFinalizer.cpp:
+ (JSC::DFG::JITFinalizer::finalize):
+ (JSC::DFG::JITFinalizer::finalizeFunction):
+ * disassembler/Disassembler.cpp:
+ (JSC::disassembleAsynchronously):
+ (JSC::waitForAsynchronousDisassembly):
+ * disassembler/Disassembler.h:
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLLink.cpp:
+ (JSC::FTL::link):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+ * jsc.cpp:
+ * runtime/Options.h:
+ * runtime/VM.cpp:
+ (JSC::VM::~VM):
+
+2015-03-23 Dean Jackson <dino@apple.com>
+
+ ES7: Implement Array.prototype.includes
+ https://bugs.webkit.org/show_bug.cgi?id=142707
+
+ Reviewed by Geoffrey Garen.
+
+ Add support for the ES7 includes method on Arrays.
+ https://github.com/tc39/Array.prototype.includes
+
+ * builtins/Array.prototype.js:
+ (includes): Implementation in JS.
+ * runtime/ArrayPrototype.cpp: Add 'includes' to the lookup table.
+
+2015-03-23 Joseph Pecoraro <pecoraro@apple.com>
+
+ __defineGetter__/__defineSetter__ should throw exceptions
+ https://bugs.webkit.org/show_bug.cgi?id=142934
+
+ Reviewed by Geoffrey Garen.
+
+ * runtime/ObjectPrototype.cpp:
+ (JSC::objectProtoFuncDefineGetter):
+ (JSC::objectProtoFuncDefineSetter):
+ Throw exceptions when these functions are used directly.
+
+2015-03-23 Joseph Pecoraro <pecoraro@apple.com>
+
+ Fix DO_PROPERTYMAP_CONSTENCY_CHECK enabled build
+ https://bugs.webkit.org/show_bug.cgi?id=142952
+
+ Reviewed by Geoffrey Garen.
+
+ * runtime/Structure.cpp:
+ (JSC::PropertyTable::checkConsistency):
+ The check offset method doesn't exist in PropertyTable, it exists in Structure.
+
+ (JSC::Structure::checkConsistency):
+ So move it here, and always put it at the start to match normal behavior.
+
+2015-03-22 Filip Pizlo <fpizlo@apple.com>
+
+ Remove DFG::ValueRecoveryOverride; it's been dead since we removed forward speculations
+ https://bugs.webkit.org/show_bug.cgi?id=142956
+
+ Rubber stamped by Gyuyoung Kim.
+
+ Just removing dead code.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGOSRExit.h:
+ * dfg/DFGOSRExitCompiler.cpp:
+ * dfg/DFGValueRecoveryOverride.h: Removed.
+
+2015-03-22 Filip Pizlo <fpizlo@apple.com>
+
+ DFG OSR exit shouldn't assume that the frame count for exit is greater than the frame count in DFG
+ https://bugs.webkit.org/show_bug.cgi?id=142948
+
+ Reviewed by Sam Weinig.
+
+ It's necessary to ensure that the stack pointer accounts for the extent of our stack usage
+ since a signal may clobber the area below the stack pointer. When the DFG is executing,
+ the stack pointer accounts for the DFG's worst-case stack usage. When we OSR exit back to
+ baseline, we will use a different amount of stack. This is because baseline is a different
+ compiler. It will make different decisions. So it will use a different amount of stack.
+
+ This gets tricky when we are in the process of doing an OSR exit, because we are sort of
+ incrementally transforming the stack from how it looked in the DFG to how it will look in
+ baseline. The most conservative approach would be to set the stack pointer to the max of
+ DFG and baseline.
+
+ When this code was written, a reckless assumption was made: that the stack usage in
+ baseline is always at least as large as the stack usage in DFG. Based on this incorrect
+ assumption, the code first adjusts the stack pointer to account for the baseline stack
+ usage. This sort of usually works, because usually baseline does happen to use more stack.
+ But that's not an invariant. Nobody guarantees this. We will never make any changes that
+ would make this be guaranteed, because that would be antithetical to how optimizing
+ compilers work. The DFG should be allowed to use however much stack it decides that it
+ should use in order to get good performance, and it shouldn't try to guarantee that it
+ always uses less stack than baseline.
+
+ As such, we must always assume that the frame size for DFG execution (i.e.
+ frameRegisterCount) and the frame size in baseline once we exit (i.e.
+ requiredRegisterCountForExit) are two independent quantities and they have no
+ relationship.
+
+ Fortunately, though, this code can be made correct by just moving the stack adjustment to
+ just before we do conversions. This is because we have since changed the OSR exit
+ algorithm to first lift up all state from the DFG state into a scratch buffer, and then to
+ drop it out of the scratch buffer and into the stack according to the baseline layout. The
+ point just before conversions is the point where we have finished reading the DFG frame
+ and will not read it anymore, and we haven't started writing the baseline frame. So, at
+ this point it is safe to set the stack pointer to account for the frame size at exit.
+
+ This is benign because baseline happens to create larger frames than DFG.
+
+ * dfg/DFGOSRExitCompiler32_64.cpp:
+ (JSC::DFG::OSRExitCompiler::compileExit):
+ * dfg/DFGOSRExitCompiler64.cpp:
+ (JSC::DFG::OSRExitCompiler::compileExit):
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::adjustAndJumpToTarget):
+
+2015-03-22 Filip Pizlo <fpizlo@apple.com>
+
+ Shorten the number of iterations to 10,000 since that's enough to test all tiers.
+
+ Rubber stamped by Sam Weinig.
+
+ * tests/stress/equals-masquerader.js:
+
+2015-03-22 Filip Pizlo <fpizlo@apple.com>
+
+ tests/stress/*tdz* tests do 10x more iterations than necessary
+ https://bugs.webkit.org/show_bug.cgi?id=142946
+
+ Reviewed by Ryosuke Niwa.
+
+ The stress test harness runs all of these tests in various configurations. This includes
+ no-cjit, which has tier-up heuristics locked in such a way that 10,000 iterations is
+ enough to get to the highest tier. The only exceptions are very large functions or
+ functions that have some reoptimizations. That happens rarely, and when it does happen,
+ usually 20,000 iterations is enough.
+
+ Therefore, these tests use 10x too many iterations. This is bad, since these tests
+ allocate on each iteration, and so they run very slowly in debug mode.
+
+ * tests/stress/class-syntax-no-loop-tdz.js:
+ * tests/stress/class-syntax-no-tdz-in-catch.js:
+ * tests/stress/class-syntax-no-tdz-in-conditional.js:
+ * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
+ * tests/stress/class-syntax-no-tdz-in-loop.js:
+ * tests/stress/class-syntax-no-tdz.js:
+ * tests/stress/class-syntax-tdz-in-catch.js:
+ * tests/stress/class-syntax-tdz-in-conditional.js:
+ * tests/stress/class-syntax-tdz-in-loop.js:
+ * tests/stress/class-syntax-tdz.js:
+
+2015-03-21 Joseph Pecoraro <pecoraro@apple.com>
+
+ Fix a typo in Parser error message
+ https://bugs.webkit.org/show_bug.cgi?id=142942
+
+ Reviewed by Alexey Proskuryakov.
+
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitSlow_op_resolve_scope):
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emitSlow_op_resolve_scope):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+ Fix a common identifier typo.
+
+2015-03-21 Joseph Pecoraro <pecoraro@apple.com>
+
+ Computed Property names should allow only AssignmentExpressions not any Expression
+ https://bugs.webkit.org/show_bug.cgi?id=142902
+
+ Reviewed by Ryosuke Niwa.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseProperty):
+ Limit computed expressions to just assignment expressions instead of
+ any expression (which allowed comma expressions).
+
+2015-03-21 Andreas Kling <akling@apple.com>
+
+ Make UnlinkedFunctionExecutable fit in a 128-byte cell.
+ <https://webkit.org/b/142939>
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-arrange the members of UnlinkedFunctionExecutable so it can fit inside
+ a 128-byte heap cell instead of requiring a 256-byte one.
+
+ Threw in a static_assert to catch anyone pushing it over the limit again.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedFunctionExecutable::functionMode):
+
+2015-03-20 Mark Hahnenberg <mhahnenb@gmail.com>
+
+ GCTimer should know keep track of nested GC phases
+ https://bugs.webkit.org/show_bug.cgi?id=142675
+
+ Reviewed by Darin Adler.
+
+ This improves the GC phase timing output in Heap.cpp by linking
+ phases nested inside other phases together, allowing tools
+ to compute how much time we're spending in various nested phases.
+
+ * heap/Heap.cpp:
+
+2015-03-20 Geoffrey Garen <ggaren@apple.com>
+
+ FunctionBodyNode should known where its parameters started
+ https://bugs.webkit.org/show_bug.cgi?id=142926
+
+ Reviewed by Ryosuke Niwa.
+
+ This will allow us to re-parse parameters instead of keeping the
+ parameters piece of the AST around forever.
+
+ I also took the opportunity to initialize most FunctionBodyNode data
+ members at construction time, to help clarify that they are set right.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createFunctionExpr): No need to pass
+ functionKeywordStart here; we now provide it at FunctionBodyNode
+ creation time.
+
+ (JSC::ASTBuilder::createFunctionBody): Require everything we need at
+ construction time, including the start of our parameters.
+
+ (JSC::ASTBuilder::createGetterOrSetterProperty):
+ (JSC::ASTBuilder::createFuncDeclStatement): No need to pass
+ functionKeywordStart here; we now provide it at FunctionBodyNode
+ creation time.
+
+ (JSC::ASTBuilder::setFunctionNameStart): Deleted.
+
+ * parser/Nodes.cpp:
+ (JSC::FunctionBodyNode::FunctionBodyNode): Initialize everything at
+ construction time.
+
+ * parser/Nodes.h: Added a field for the location of our parameters.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionBody):
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseClass):
+ (JSC::Parser<LexerType>::parsePropertyMethod):
+ (JSC::Parser<LexerType>::parseGetterSetter):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ * parser/Parser.h: Refactored to match above interface changes.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createFunctionExpr):
+ (JSC::SyntaxChecker::createFunctionBody):
+ (JSC::SyntaxChecker::createFuncDeclStatement):
+ (JSC::SyntaxChecker::createGetterOrSetterProperty): Refactored to match
+ above interface changes.
+
+ (JSC::SyntaxChecker::setFunctionNameStart): Deleted.
+
+2015-03-20 Filip Pizlo <fpizlo@apple.com>
+
+ Observably effectful nodes in DFG IR should come last in their bytecode instruction (i.e. forExit section), except for Hint nodes
+ https://bugs.webkit.org/show_bug.cgi?id=142920
+
+ Reviewed by Oliver Hunt, Geoffrey Garen, and Mark Lam.
+
+ Observably effectful, n.: If we reexecute the bytecode instruction after this node has
+ executed, then something other than the bytecode instruction's specified outcome will
+ happen.
+
+ We almost never had observably effectful nodes except at the end of the bytecode
+ instruction. The exception is a lowered transitioning PutById:
+
+ PutStructure(@o, S1 -> S2)
+ PutByOffset(@o, @o, @v)
+
+ The PutStructure is observably effectful: if you try to reexecute the bytecode after
+ doing the PutStructure, then we'll most likely crash. The generic PutById handling means
+ first checking what the old structure of the object is; but if we reexecute, the old
+ structure will seem to be the new structure. But the property ensured by the new
+ structure hasn't been stored yet, so any attempt to load it or scan it will crash.
+
+ Intriguingly, however, none of the other operations involved in the PutById are
+ observably effectful. Consider this example:
+
+ PutByOffset(@o, @o, @v)
+ PutStructure(@o, S1 -> S2)
+
+ Note that the PutStructure node doesn't reallocate property storage; see further below
+ for an example that does that. Because no property storage is happening, we know that we
+ already had room for the new property. This means that the PutByOffset is no observable
+ until the PutStructure executes and "reveals" the property. Hence, PutByOffset is not
+ observably effectful.
+
+ Now consider this:
+
+ b: AllocatePropertyStorage(@o)
+ PutByOffset(@b, @o, @v)
+ PutStructure(@o, S1 -> S2)
+
+ Surprisingly, this is also safe, because the AllocatePropertyStorage is not observably
+ effectful. It *does* reallocate the property storage and the new property storage pointer
+ is stored into the object. But until the PutStructure occurs, the world will just think
+ that the reallocation didn't happen, in the sense that we'll think that the property
+ storage is using less memory than what we just allocated. That's harmless.
+
+ The AllocatePropertyStorage is safe in other ways, too. Even if we GC'd after the
+ AllocatePropertyStorage but before the PutByOffset (or before the PutStructure),
+ everything could be expected to be fine, so long as all of @o, @v and @b are on the
+ stack. If they are all on the stack, then the GC will leave the property storage alone
+ (so the extra memory we just allocated would be safe). The GC will not scan the part of
+ the property storage that contains @v, but that's fine, so long as @v is on the stack.
+
+ The better long-term solution is probably bug 142921.
+
+ But for now, this:
+
+ - Fixes an object materialization bug, exemplified by the two tests, that previously
+ crashed 100% of the time with FTL enabled and concurrent JIT disabled.
+
+ - Allows us to remove the workaround introduced in r174856.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handlePutById):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::insertCheck):
+ (JSC::DFG::FixupPhase::indexOfNode): Deleted.
+ (JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin): Deleted.
+ * dfg/DFGInsertionSet.h:
+ (JSC::DFG::InsertionSet::insertOutOfOrder): Deleted.
+ (JSC::DFG::InsertionSet::insertOutOfOrderNode): Deleted.
+ * tests/stress/materialize-past-butterfly-allocation.js: Added.
+ (bar):
+ (foo0):
+ (foo1):
+ (foo2):
+ (foo3):
+ (foo4):
+ * tests/stress/materialize-past-put-structure.js: Added.
+ (foo):
+
+2015-03-20 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION (r179429): Potential Use after free in JavaScriptCore`WTF::StringImpl::ref + 83
+ https://bugs.webkit.org/show_bug.cgi?id=142410
+
+ Reviewed by Geoffrey Garen.
+
+ Before this patch, added function JSValue::toPropertyKey returns PropertyName.
+ Since PropertyName doesn't have AtomicStringImpl ownership,
+ if Identifier is implicitly converted to PropertyName and Identifier is destructed,
+ PropertyName may refer freed AtomicStringImpl*.
+
+ This patch changes the result type of JSValue::toPropertyName from PropertyName to Identifier,
+ to keep AtomicStringImpl* ownership after the toPropertyName call is done.
+ And receive the result value as Identifier type to keep ownership in the caller side.
+
+ To catch the result of toPropertyKey as is, we catch the result of toPropertyName as auto.
+
+ However, now we don't need to have both Identifier and PropertyName.
+ So we'll merge PropertyName to Identifier in the subsequent patch.
+
+ * dfg/DFGOperations.cpp:
+ (JSC::DFG::operationPutByValInternal):
+ * jit/JITOperations.cpp:
+ (JSC::getByVal):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::getByVal):
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ (JSC::CommonSlowPaths::opIn):
+ * runtime/JSCJSValue.h:
+ * runtime/JSCJSValueInlines.h:
+ (JSC::JSValue::toPropertyKey):
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorGetOwnPropertyDescriptor):
+ (JSC::objectConstructorDefineProperty):
+ * runtime/ObjectPrototype.cpp:
+ (JSC::objectProtoFuncPropertyIsEnumerable):
+
+2015-03-18 Geoffrey Garen <ggaren@apple.com>
+
+ Function.prototype.toString should not decompile the AST
+ https://bugs.webkit.org/show_bug.cgi?id=142853
+
+ Reviewed by Sam Weinig.
+
+ To recover the function parameter string, Function.prototype.toString
+ decompiles the function parameters from the AST. This is bad for a few
+ reasons:
+
+ (1) It requires us to keep pieces of the AST live forever. This is an
+ awkward design and a waste of memory.
+
+ (2) It doesn't match Firefox or Chrome (because it changes whitespace
+ and ES6 destructuring expressions).
+
+ (3) It doesn't scale to ES6 default argument parameters, which require
+ arbitrarily complex decompilation.
+
+ (4) It can counterfeit all the line numbers in a function (because
+ whitespace can include newlines).
+
+ (5) It's expensive, and we've seen cases where websites invoke
+ Function.prototype.toString a lot by accident.
+
+ The fix is to do what we do for the rest of the function: Just quote the
+ original source text.
+
+ Since this change inevitably changes some function stringification, I
+ took the opportunity to make our stringification match Firefox's and
+ Chrome's.
+
+ * API/tests/testapi.c:
+ (assertEqualsAsUTF8String): Be more informative when this fails.
+
+ (main): Updated to match new stringification rules.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::paramString): Deleted. Yay!
+ * bytecode/UnlinkedCodeBlock.h:
+
+ * parser/Nodes.h:
+ (JSC::StatementNode::isFuncDeclNode): New helper for constructing
+ anonymous functions.
+
+ * parser/SourceCode.h:
+ (JSC::SourceCode::SourceCode): Allow zero because WebCore wants it.
+
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Updated for use
+ of function declaration over function expression.
+
+ * runtime/Executable.cpp:
+ (JSC::FunctionExecutable::paramString): Deleted. Yay!
+ * runtime/Executable.h:
+ (JSC::FunctionExecutable::parameterCount):
+
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck): Added a newline after
+ the opening brace to match Firefox and Chrome, and a space after the comma
+ to match Firefox and WebKit coding style. Added the function name to
+ the text of the function so it would look right when stringify-ing. Switched
+ from parentheses to braces to produce a function declaration instead of
+ a function expression because we are required to exclude the function's
+ name from its scope, and that's what a function declaration does.
+
+ * runtime/FunctionPrototype.cpp:
+ (JSC::functionProtoFuncToString): Removed an old workaround because the
+ library it worked around doesn't really exist anymore, and the behavior
+ doesn't match Firefox or Chrome. Use type profiling offsets instead of
+ function body offsets because we want to include the function name and
+ the parameter string, rather than stitching them in manually by
+ decompiling the AST.
+
+ (JSC::insertSemicolonIfNeeded): Deleted.
+
+ * tests/mozilla/js1_2/function/tostring-1.js:
+ * tests/mozilla/js1_5/Scope/regress-185485.js:
+ (with.g): Updated these test results for formatting changes.
+
+2015-03-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ SyntaxChecker assertion is trapped with computed property name and getter
+ https://bugs.webkit.org/show_bug.cgi?id=142863
+
+ Reviewed by Ryosuke Niwa.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::getName):
+ Remove invalid assert. Computed properties will not have a name
+ and the calling code is checking for null expecting it. The
+ AST path (non-CheckingPath) already does this without the assert
+ so it is well tested.
+
+2015-03-19 Mark Lam <mark.lam@apple.com>
+
+ JSCallbackObject<JSGlobalObject> should not destroy its JSCallbackObjectData before all its finalizers have been called.
+ <https://webkit.org/b/142846>
+
+ Reviewed by Geoffrey Garen.
+
+ Currently, JSCallbackObject<JSGlobalObject> registers weak finalizers via 2 mechanisms:
+ 1. JSCallbackObject<Parent>::init() registers a weak finalizer for all JSClassRef
+ that a JSCallbackObject references.
+ 2. JSCallbackObject<JSGlobalObject>::create() registers a finalizer via
+ vm.heap.addFinalizer() which destroys the JSCallbackObject.
+
+ The first finalizer is implemented as a virtual function of a JSCallbackObjectData
+ instance that will be destructed if the 2nd finalizer is called. Hence, if the
+ 2nd finalizer if called first, the later invocation of the 1st finalizer will
+ result in a crash.
+
+ This patch fixes the issue by eliminating the finalizer registration in init().
+ Instead, we'll have the JSCallbackObject destructor call all the JSClassRef finalizers
+ if needed. This ensures that these finalizers are called before the JSCallbackObject
+ is destructor.
+
+ Also added assertions to a few Heap functions because JSCell::classInfo() expects
+ all objects that are allocated from MarkedBlock::Normal blocks to be derived from
+ JSDestructibleObject. These assertions will help us catch violations of this
+ expectation earlier.
+
+ * API/JSCallbackObject.cpp:
+ (JSC::JSCallbackObjectData::finalize): Deleted.
+ * API/JSCallbackObject.h:
+ (JSC::JSCallbackObjectData::~JSCallbackObjectData):
+ * API/JSCallbackObjectFunctions.h:
+ (JSC::JSCallbackObject<Parent>::~JSCallbackObject):
+ (JSC::JSCallbackObject<Parent>::init):
+ * API/tests/GlobalContextWithFinalizerTest.cpp: Added.
+ (finalize):
+ (testGlobalContextWithFinalizer):
+ * API/tests/GlobalContextWithFinalizerTest.h: Added.
+ * API/tests/testapi.c:
+ (main):
+ * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
+ * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * heap/HeapInlines.h:
+ (JSC::Heap::allocateObjectOfType):
+ (JSC::Heap::subspaceForObjectOfType):
+ (JSC::Heap::allocatorForObjectOfType):
+
+2015-03-19 Andreas Kling <akling@apple.com>
+
+ JSCallee unnecessarily overrides a bunch of things in the method table.
+ <https://webkit.org/b/142855>
+
+ Reviewed by Geoffrey Garen.
+
+ Remove JSCallee method table overrides that simply call to base class.
+ This makes JSFunction property slot lookups slightly more efficient since
+ they can take the fast path when passing over JSCallee in the base class chain.
+
+ * runtime/JSCallee.cpp:
+ (JSC::JSCallee::getOwnPropertySlot): Deleted.
+ (JSC::JSCallee::getOwnNonIndexPropertyNames): Deleted.
+ (JSC::JSCallee::put): Deleted.
+ (JSC::JSCallee::deleteProperty): Deleted.
+ (JSC::JSCallee::defineOwnProperty): Deleted.
+ * runtime/JSCallee.h:
+
+2015-03-19 Andreas Kling <akling@apple.com>
+
+ DFGAllocator should use bmalloc's aligned allocator.
+ <https://webkit.org/b/142871>
+
+ Reviewed by Geoffrey Garen.
+
+ Switch DFGAllocator to using bmalloc through fastAlignedMalloc().
+
+ * dfg/DFGAllocator.h:
+ (JSC::DFG::Allocator<T>::allocateSlow):
+ (JSC::DFG::Allocator<T>::freeRegionsStartingAt):
+ * heap/CopiedSpace.h:
+ * heap/MarkedBlock.h:
+ * heap/MarkedSpace.h:
+
+2015-03-18 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6 Classes: Extends should accept an expression without parenthesis
+ https://bugs.webkit.org/show_bug.cgi?id=142840
+
+ Reviewed by Ryosuke Niwa.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+ "extends" allows a LeftHandExpression (new expression / call expression,
+ which includes a member expression), not a primary expression. Our
+ parseMemberExpression does all of these.
+
+2015-03-18 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Debugger Popovers and Probes should use FormattedValue/ObjectTreeView instead of Custom/ObjectPropertiesSection
+ https://bugs.webkit.org/show_bug.cgi?id=142830
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
+ Give Probe Samples object previews.
+
+2015-03-17 Ryuan Choi <ryuan.choi@navercorp.com>
+
+ [EFL] Expose JavaScript binding interface through ewk_extension
+ https://bugs.webkit.org/show_bug.cgi?id=142033
+
+ Reviewed by Gyuyoung Kim.
+
+ * PlatformEfl.cmake: Install Javascript APIs.
+
+2015-03-17 Geoffrey Garen <ggaren@apple.com>
+
+ Function bodies should always include braces
+ https://bugs.webkit.org/show_bug.cgi?id=142795
+
+ Reviewed by Michael Saboff.
+
+ Having a mode for excluding the opening and closing braces from a function
+ body was unnecessary and confusing.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock): Adopt the new one true linking function.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock):
+ (JSC::UnlinkedFunctionExecutable::link):
+ (JSC::UnlinkedFunctionExecutable::codeBlockFor): No need to pass through
+ a boolean: there is only one kind of function now.
+
+ (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Deleted.
+ (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Deleted. Let's only
+ have one way to do things. This removes the old mode that would pretend
+ that a function always started at column 1. That pretense was not true:
+ an attribute event listener does not necessarily start at column 1.
+
+ * bytecode/UnlinkedCodeBlock.h:
+ * generate-js-builtins: Adopt the new one true linking function.
+
+ * parser/Parser.h:
+ (JSC::Parser<LexerType>::parse):
+ (JSC::parse): needsReparsingAdjustment is always true now, so I removed it.
+
+ * runtime/Executable.cpp:
+ (JSC::ScriptExecutable::newCodeBlockFor):
+ (JSC::FunctionExecutable::FunctionExecutable):
+ (JSC::ProgramExecutable::initializeGlobalProperties):
+ (JSC::FunctionExecutable::fromGlobalCode):
+ * runtime/Executable.h:
+ (JSC::FunctionExecutable::create):
+ (JSC::FunctionExecutable::bodyIncludesBraces): Deleted. Removed unused stuff.
+
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck): Always provide a
+ leading space because that's what this function's comment says is required
+ for web compatibility. We used to fake this up after the fact when
+ stringifying, based on the bodyIncludesBraces flag, but that flag is gone now.
+
+ * runtime/FunctionPrototype.cpp:
+ (JSC::insertSemicolonIfNeeded):
+ (JSC::functionProtoFuncToString): No need to add braces and/or a space
+ after the fact -- we always have them now.
+
+2015-03-17 Mark Lam <mark.lam@apple.com>
+
+ Refactor execution time limit tests out of testapi.c.
+ <https://webkit.org/b/142798>
+
+ Rubber stamped by Michael Saboff.
+
+ These tests were sometimes failing to time out on C loop builds. Let's
+ refactor them out of the big monolith that is testapi.c so that we can
+ reason more easily about them and make adjustments if needed.
+
+ * API/tests/ExecutionTimeLimitTest.cpp: Added.
+ (currentCPUTime):
+ (currentCPUTimeAsJSFunctionCallback):
+ (shouldTerminateCallback):
+ (cancelTerminateCallback):
+ (extendTerminateCallback):
+ (testExecutionTimeLimit):
+ * API/tests/ExecutionTimeLimitTest.h: Added.
+ * API/tests/testapi.c:
+ (main):
+ (currentCPUTime): Deleted.
+ (currentCPUTime_callAsFunction): Deleted.
+ (shouldTerminateCallback): Deleted.
+ (cancelTerminateCallback): Deleted.
+ (extendTerminateCallback): Deleted.
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-03-17 Geoffrey Garen <ggaren@apple.com>
+
+ Built-in functions should know that they use strict mode
+ https://bugs.webkit.org/show_bug.cgi?id=142788
+
+ Reviewed by Mark Lam.
+
+ Even though all of our builtin functions use strict mode, the parser
+ thinks that they don't. This is because Executable::toStrictness treats
+ builtin-ness and strict-ness as mutually exclusive.
+
+ The fix is to disambiguate builtin-ness from strict-ness.
+
+ This bug is currently unobservable because of some other parser bugs. But
+ it causes lots of test failures once those other bugs are fixed.
+
+ * API/JSScriptRef.cpp:
+ (parseScript):
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createBuiltinExecutable): Adopt the new API
+ for a separate value to indicate builtin-ness vs strict-ness.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock):
+ (JSC::UnlinkedFunctionExecutable::codeBlockFor): Ditto.
+
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedFunctionExecutable::toStrictness): Deleted. This function
+ was misleading since it pretended that no builtin function was ever
+ strict, which is the opposite of true.
+
+ * parser/Lexer.cpp:
+ (JSC::Lexer<T>::Lexer):
+ * parser/Lexer.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::Parser):
+ * parser/Parser.h:
+ (JSC::parse): Adopt the new API.
+
+ * parser/ParserModes.h: Added JSParserBuiltinMode, and tried to give
+ existing modes clearer names.
+
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ (JSC::CodeCache::getProgramCodeBlock):
+ (JSC::CodeCache::getEvalCodeBlock):
+ (JSC::CodeCache::getFunctionExecutableFromGlobalCode): Adopt the new API.
+
+ * runtime/CodeCache.h:
+ (JSC::SourceCodeKey::SourceCodeKey): Be sure to treat strict-ness and
+ bulitin-ness as separate pieces of the code cache key. We would not want
+ a user function to match a built-in function in the cache, even if they
+ agreed about strictness, since builtin functions have different lexing
+ rules.
+
+ * runtime/Completion.cpp:
+ (JSC::checkSyntax):
+ * runtime/Executable.cpp:
+ (JSC::FunctionExecutable::FunctionExecutable):
+ (JSC::ProgramExecutable::checkSyntax):
+ * runtime/Executable.h:
+ (JSC::FunctionExecutable::create):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::createProgramCodeBlock):
+ (JSC::JSGlobalObject::createEvalCodeBlock): Adopt the new API.
+
+2015-03-16 Filip Pizlo <fpizlo@apple.com>
+
+ DFG IR shouldn't have a separate node for every kind of put hint that could be described using PromotedLocationDescriptor
+ https://bugs.webkit.org/show_bug.cgi?id=142769
+
+ Reviewed by Michael Saboff.
+
+ When we sink an object allocation, we need to have some way of tracking what stores would
+ have happened had the allocation not been sunk, so that we know how to rematerialize the
+ object on OSR exit. Prior to this change, trunk had two ways of describing such a "put
+ hint":
+
+ - The PutStrutureHint and PutByOffsetHint node types.
+ - The PromotedLocationDescriptor class, which has an enum with cases StructurePLoc and
+ NamedPropertyPLoc.
+
+ We also had ways of converting from a Node with those two node types to a
+ PromotedLocationDescriptor, and we had a way of converting a PromotedLocationDescriptor to
+ a Node.
+
+ This change removes the redundancy. We now have just one node type that corresponds to a
+ put hint, and it's called PutHint. It has a PromotedLocationDescriptor as metadata.
+ Converting between a PutHint node and a PromotedLocationDescriptor and vice-versa is now
+ trivial.
+
+ This means that if we add new kinds of sunken objects, we'll have less pro-forma to write
+ for the put hints to those objects. This is mainly to simplify the implementation of
+ arguments elimination in bug 141174.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::mergeRelevantToOSR):
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::convertToPutHint):
+ (JSC::DFG::Node::convertToPutStructureHint):
+ (JSC::DFG::Node::convertToPutByOffsetHint):
+ (JSC::DFG::Node::promotedLocationDescriptor):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasIdentifier):
+ (JSC::DFG::Node::hasPromotedLocationDescriptor):
+ (JSC::DFG::Node::convertToPutByOffsetHint): Deleted.
+ (JSC::DFG::Node::convertToPutStructureHint): Deleted.
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+ (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::run):
+ (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
+ (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGPromoteHeapAccess.h:
+ (JSC::DFG::promoteHeapAccess):
+ * dfg/DFGPromotedHeapLocation.cpp:
+ (JSC::DFG::PromotedHeapLocation::createHint):
+ * dfg/DFGPromotedHeapLocation.h:
+ (JSC::DFG::PromotedLocationDescriptor::imm1):
+ (JSC::DFG::PromotedLocationDescriptor::imm2):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateCPS):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+
+2015-03-17 Michael Saboff <msaboff@apple.com>
+
+ Windows X86-64 should use the fixed executable allocator
+ https://bugs.webkit.org/show_bug.cgi?id=142749
+
+ Reviewed by Filip Pizlo.
+
+ Added jit/ExecutableAllocatorFixedVMPool.cpp to Windows build.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * jit/ExecutableAllocatorFixedVMPool.cpp: Don't include unistd.h on Windows.
+
+2015-03-17 Matt Baker <mattbaker@apple.com>
+
+ Web Inspector: Show rendering frames (and FPS) in Layout and Rendering timeline
+ https://bugs.webkit.org/show_bug.cgi?id=142029
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Timeline.json:
+ Added new event type for runloop timeline records.
+
+2015-03-16 Ryosuke Niwa <rniwa@webkit.org>
+
+ Enable ES6 classes by default
+ https://bugs.webkit.org/show_bug.cgi?id=142774
+
+ Reviewed by Gavin Barraclough.
+
+ Enabled the feature and unskipped tests.
+
+ * Configurations/FeatureDefines.xcconfig:
+ * tests/stress/class-syntax-no-loop-tdz.js:
+ * tests/stress/class-syntax-no-tdz-in-catch.js:
+ * tests/stress/class-syntax-no-tdz-in-conditional.js:
+ * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js:
+ * tests/stress/class-syntax-no-tdz-in-loop.js:
+ * tests/stress/class-syntax-no-tdz.js:
+ * tests/stress/class-syntax-tdz-in-catch.js:
+ * tests/stress/class-syntax-tdz-in-conditional.js:
+ * tests/stress/class-syntax-tdz-in-loop.js:
+ * tests/stress/class-syntax-tdz.js:
+
+2015-03-16 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Better Console Previews for Arrays / Small Objects
+ https://bugs.webkit.org/show_bug.cgi?id=142322
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ Create deep valuePreviews for simple previewable objects,
+ such as arrays with 5 values, or basic objects with
+ 3 properties.
+
+2015-03-16 Ryosuke Niwa <rniwa@webkit.org>
+
+ Add support for default constructor
+ https://bugs.webkit.org/show_bug.cgi?id=142388
+
+ Reviewed by Filip Pizlo.
+
+ Added the support for default constructors. They're generated by ClassExprNode::emitBytecode
+ via BuiltinExecutables::createDefaultConstructor.
+
+ UnlinkedFunctionExecutable now has the ability to override SourceCode provided by the owner
+ executable. We can't make store SourceCode in UnlinkedFunctionExecutable since CodeCache can use
+ the same UnlinkedFunctionExecutable to generate code blocks for multiple functions.
+
+ Parser now has the ability to treat any function expression as a constructor of the kind specified
+ by m_defaultConstructorKind member variable.
+
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createDefaultConstructor): Added.
+ (JSC::BuiltinExecutables::createExecutableInternal): Generalized from createBuiltinExecutable.
+ Parse default constructors as normal non-builtin functions. Override SourceCode in the unlinked
+ function executable since the Miranda function's code is definitely not in the owner executable's
+ source code. That's the whole point.
+ * builtins/BuiltinExecutables.h:
+ (UnlinkedFunctionExecutable::createBuiltinExecutable): Added. Wraps createExecutableInternal.
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+ (JSC::UnlinkedFunctionExecutable::linkInsideExecutable):
+ (JSC::UnlinkedFunctionExecutable::linkGlobalCode):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedFunctionExecutable::create):
+ (JSC::UnlinkedFunctionExecutable::symbolTable): Deleted.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitNewDefaultConstructor): Added.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ClassExprNode::emitBytecode): Generate the default constructor if needed.
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::Parser):
+ (JSC::Parser<LexerType>::parseFunctionInfo): Override ownerClassKind and assume the function as
+ a constructor if we're parsing a default constructor.
+ (JSC::Parser<LexerType>::parseClass): Allow omission of the class constructor.
+ * parser/Parser.h:
+ (JSC::parse):
+
+2015-03-16 Alex Christensen <achristensen@webkit.org>
+
+ Progress towards CMake on Mac
+ https://bugs.webkit.org/show_bug.cgi?id=142747
+
+ Reviewed by Chris Dumez.
+
+ * CMakeLists.txt:
+ Include AugmentableInspectorController.h in CMake build.
+
+2015-03-16 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Enable generating idiv instructions if it is supported
+ https://bugs.webkit.org/show_bug.cgi?id=142725
+
+ Reviewed by Michael Saboff.
+
+ * assembler/ARMAssembler.h: Added sdiv and udiv implementation for ARM Traditional instruction set.
+ (JSC::ARMAssembler::sdiv):
+ (JSC::ARMAssembler::udiv):
+ * assembler/ARMv7Assembler.h: Use HAVE(ARM_IDIV_INSTRUCTIONS) instead of CPU(APPLE_ARMV7S).
+ * assembler/AbstractMacroAssembler.h:
+ (JSC::isARMv7IDIVSupported):
+ (JSC::optimizeForARMv7IDIVSupported):
+ (JSC::isARMv7s): Renamed to isARMv7IDIVSupported().
+ (JSC::optimizeForARMv7s): Renamed to optimizeForARMv7IDIVSupported().
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithDiv):
+ (JSC::DFG::SpeculativeJIT::compileArithMod):
+
+2015-03-15 Filip Pizlo <fpizlo@apple.com>
+
+ DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source, and emit GetStacks when the stack's value is needed and none is deferred
+ https://bugs.webkit.org/show_bug.cgi?id=141624
+
+ Reviewed by Geoffrey Garen.
+
+ Not eliminating GetStacks was an obvious omission from the original PutStackSinkingPhase.
+ Previously, we would treat GetStacks conservatively and assume that the stack slot
+ escaped. That's pretty dumb, since a GetStack is a local load of the stack. This change
+ makes GetStack a no-op from the standpoint of this phase's deferral analysis. At the end
+ we either keep the GetStack (if there was no concrete deferral) or we replace it with an
+ identity over the value that would have been stored by the deferred PutStack. Note that
+ this might be a Phi that the phase creates, so this is strictly stronger than what GCSE
+ could do.
+
+ But this change revealed the fact that this phase never correctly handled side effects in
+ case that we had done a GetStack, then a side-effect, and then found ourselves wanting the
+ value on the stack due to (for example) a Phi on a deferred PutStack and that GetStack.
+ Basically, it's only correct to use the SSA converter's incoming value mapping if we have
+ a concrete deferral - since anything but a concrete deferral may imply that the value has
+ been clobbered.
+
+ This has no performance change. I believe that the bug was previously benign because we
+ have so few operations that clobber the stack anymore, and most of those get used in a
+ very idiomatic way. The GetStack elimination will be very useful for the varargs
+ simplification that is part of bug 141174.
+
+ This includes a test for the case that Speedometer hit, plus tests for the other cases I
+ thought of once I realized the deeper issue.
+
+ * dfg/DFGPutStackSinkingPhase.cpp:
+ * tests/stress/get-stack-identity-due-to-sinking.js: Added.
+ (foo):
+ (bar):
+ * tests/stress/get-stack-mapping-with-dead-get-stack.js: Added.
+ (bar):
+ (foo):
+ * tests/stress/get-stack-mapping.js: Added.
+ (bar):
+ (foo):
+ * tests/stress/weird-put-stack-varargs.js: Added.
+ (baz):
+ (foo):
+ (fuzz):
+ (bar):
+
+2015-03-16 Joseph Pecoraro <pecoraro@apple.com>
+
+ Update Map/Set to treat -0 and 0 as the same value
+ https://bugs.webkit.org/show_bug.cgi?id=142709
+
+ Reviewed by Csaba Osztrogonác.
+
+ * runtime/MapData.h:
+ (JSC::MapDataImpl<Entry>::KeyType::KeyType):
+ No longer special case -0. It will be treated as the same as 0.
+
+2015-03-15 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Better handle displaying -0
+ https://bugs.webkit.org/show_bug.cgi?id=142708
+
+ Reviewed by Timothy Hatcher.
+
+ Modeled after a blink change:
+
+ Patch by <aandrey@chromium.org>
+ DevTools: DevTools: Show -0 for negative zero in console
+ https://src.chromium.org/viewvc/blink?revision=162605&view=revision
+
+ * inspector/InjectedScriptSource.js:
+ When creating a description string, or preview value string
+ for -0, be sure the string is "-0" and not "0".
+
+2015-03-14 Ryosuke Niwa <rniwa@webkit.org>
+
+ parseClass should popScope after pushScope
+ https://bugs.webkit.org/show_bug.cgi?id=142689
+
+ Reviewed by Benjamin Poulain.
+
+ Pop the parser scope as needed.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+
+2015-03-14 Dean Jackson <dino@apple.com>
+
+ Feature flag for Animations Level 2
+ https://bugs.webkit.org/show_bug.cgi?id=142699
+ <rdar://problem/20165097>
+
+ Reviewed by Brent Fulgham.
+
+ Add ENABLE_CSS_ANIMATIONS_LEVEL_2 and a runtime flag animationTriggersEnabled.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-03-14 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r181487.
+ https://bugs.webkit.org/show_bug.cgi?id=142695
+
+ Caused Speedometer/Full.html to fail (Requested by smfr on
+ #webkit).
+
+ Reverted changeset:
+
+ "DFG::PutStackSinkingPhase should eliminate GetStacks that
+ have an obviously known source"
+ https://bugs.webkit.org/show_bug.cgi?id=141624
+ http://trac.webkit.org/changeset/181487
+
+2015-03-14 Michael Saboff <msaboff@apple.com>
+
+ ES6: Add binary and octal literal support
+ https://bugs.webkit.org/show_bug.cgi?id=142681
+
+ Reviewed by Ryosuke Niwa.
+
+ Added a binary literal parser function, parseBinary(), to Lexer patterned after the octal parser.
+ Refactored the parseBinary, parseOctal and parseDecimal to use a constant size for the number of
+ characters to try and handle directly. Factored out the shifting past any prefix to be handled by
+ the caller. Added binary and octal parsing to toDouble() via helper functions.
+
+ * parser/Lexer.cpp:
+ (JSC::Lexer<T>::parseHex):
+ (JSC::Lexer<T>::parseBinary):
+ (JSC::Lexer<T>::parseOctal):
+ (JSC::Lexer<T>::parseDecimal):
+ (JSC::Lexer<T>::lex):
+ * parser/Lexer.h:
+ * parser/ParserTokens.h:
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::jsBinaryIntegerLiteral):
+ (JSC::jsOctalIntegerLiteral):
+ (JSC::toDouble):
+
+2015-03-13 Alex Christensen <achristensen@webkit.org>
+
+ Progress towards CMake on Mac.
+ https://bugs.webkit.org/show_bug.cgi?id=142680
+
+ Reviewed by Gyuyoung Kim.
+
+ * PlatformMac.cmake:
+ Generate TracingDtrace.h based on project.pbxproj.
+
+2015-03-13 Filip Pizlo <fpizlo@apple.com>
+
+ Object allocation sinking phase shouldn't re-decorate previously sunken allocations on each fixpoint operation
+ https://bugs.webkit.org/show_bug.cgi?id=142686
+
+ Reviewed by Oliver Hunt.
+
+ Just because promoteHeapAccess() notifies us of an effect to a heap location in a node doesn't
+ mean that we should handle it as if it was for one of our sinking candidates. Instead we should
+ prune based on m_sinkCandidates.
+
+ This fixes a benign bug where we would generate a lot of repeated IR for some pathological
+ tests.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
+
+2015-03-13 Eric Carlson <eric.carlson@apple.com>
+
+ [Mac] Enable WIRELESS_PLAYBACK_TARGET
+ https://bugs.webkit.org/show_bug.cgi?id=142635
+
+ Reviewed by Darin Adler.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-03-13 Ryosuke Niwa <rniwa@webkit.org>
+
+ Class constructor should throw TypeError when "called"
+ https://bugs.webkit.org/show_bug.cgi?id=142566
+
+ Reviewed by Michael Saboff.
+
+ Added ConstructorKind::None to denote code that doesn't belong to an ES6 class.
+ This allows BytecodeGenerator to emit code to throw TypeError when generating code block
+ to call ES6 class constructors.
+
+ Most of changes are about increasing the number of bits to store ConstructorKind from one
+ bit to two bits.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock):
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+ (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::ExecutableInfo::ExecutableInfo):
+ (JSC::ExecutableInfo::needsActivation):
+ (JSC::ExecutableInfo::usesEval):
+ (JSC::ExecutableInfo::isStrictMode):
+ (JSC::ExecutableInfo::isConstructor):
+ (JSC::ExecutableInfo::isBuiltinFunction):
+ (JSC::ExecutableInfo::constructorKind):
+ (JSC::UnlinkedFunctionExecutable::constructorKind):
+ (JSC::UnlinkedCodeBlock::constructorKind):
+ (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Deleted.
+ (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Deleted.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::generate): Don't emit bytecode when we had already emitted code
+ to throw TypeError.
+ (JSC::BytecodeGenerator::BytecodeGenerator): Emit code to throw TypeError when generating
+ code to call.
+ (JSC::BytecodeGenerator::emitReturn):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::constructorKind):
+ (JSC::BytecodeGenerator::constructorKindIsDerived): Deleted.
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ThisNode::emitBytecode):
+ (JSC::FunctionCallValueNode::emitBytecode):
+ * parser/Nodes.cpp:
+ (JSC::FunctionBodyNode::FunctionBodyNode):
+ * parser/Nodes.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo): Renamed the incoming function argument to
+ ownerClassKind. Set constructorKind to Base or Derived only if we're parsing a constructor.
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseClass): Don't parse static methods using MethodMode since that
+ would result in BytecodeGenerator erroneously treating static method named "constructor" as
+ a class constructor.
+ (JSC::Parser<LexerType>::parsePropertyMethod):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ * parser/Parser.h:
+ * parser/ParserModes.h:
+ * runtime/Executable.h:
+ (JSC::EvalExecutable::executableInfo):
+ (JSC::ProgramExecutable::executableInfo):
+
+2015-03-13 Filip Pizlo <fpizlo@apple.com>
+
+ DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source
+ https://bugs.webkit.org/show_bug.cgi?id=141624
+
+ Reviewed by Oliver Hunt.
+
+ This was an obvious omission from the original PutStackSinkingPhase. Previously, we would treat
+ GetStacks conservatively and assume that the stack slot escaped. That's pretty dumb, since a
+ GetStack is a local load of the stack. This change makes GetStack a no-op from the standpoint of
+ this phase's deferral analysis. At the end we either keep the GetStack (if there was no concrete
+ deferral) or we replace it with an identity over the value that would have been stored by the
+ deferred PutStack. Note that this might be a Phi that the phase creates, so this is strictly
+ stronger than what GCSE could do.
+
+ This is probably not a speed-up now, but it will be very useful for the varargs simplification
+ done in bug 141174.
+
+ * dfg/DFGPutStackSinkingPhase.cpp:
+
+2015-03-12 Geoffrey Garen <ggaren@apple.com>
+
+ Prohibit GC while sweeping
+ https://bugs.webkit.org/show_bug.cgi?id=142638
+
+ Reviewed by Andreas Kling.
+
+ I noticed in https://bugs.webkit.org/show_bug.cgi?id=142636 that a GC
+ could trigger a sweep which could trigger another GC. Yo Dawg.
+
+ I tried to figure out whether this could cause problems or not and it
+ made me cross-eyed.
+
+ (Some clients like to report extra memory cost during deallocation as a
+ way to indicate that the GC now owns something exclusively. It's
+ arguably a bug to communicate with the GC in this way, but we shouldn't
+ do crazy when this happens.)
+
+ This patch makes explicit the fact that we don't allow GC while sweeping.
+
+ Usually, sweeping implicitly defers GC by virtue of happening during
+ allocation. But not always.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::collectAllGarbage): Defer GC while sweeping due to an
+ explicit GC request.
+
+ (JSC::Heap::didFinishCollection): Make sure that zombifying sweep
+ defers GC by not returning to the non-GC state until we're all done.
+
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::sweepNextBlock): Defer GC while sweeping due
+ to a timer.
+
+2015-03-13 Mark Lam <mark.lam@apple.com>
+
+ Replace TCSpinLock with a new WTF::SpinLock based on WTF::Atomic.
+ <https://webkit.org/b/142674>
+
+ Reviewed by Filip Pizlo.
+
+ * API/JSValue.mm:
+ (handerForStructTag):
+ * API/JSWrapperMap.mm:
+ * dfg/DFGCommon.cpp:
+ (JSC::DFG::startCrashing):
+ (JSC::DFG::isCrashing):
+ - Changed to use a StaticSpinLock since that's what this code was trying to do
+ anyway.
+ * heap/CopiedBlock.h:
+ (JSC::CopiedBlock::CopiedBlock):
+ * heap/CopiedSpace.cpp:
+ (JSC::CopiedSpace::CopiedSpace):
+ * heap/CopiedSpace.h:
+ * heap/GCThreadSharedData.cpp:
+ (JSC::GCThreadSharedData::GCThreadSharedData):
+ * heap/GCThreadSharedData.h:
+ * heap/ListableHandler.h:
+ (JSC::ListableHandler::List::List):
+ * parser/SourceProvider.cpp:
+ * profiler/ProfilerDatabase.cpp:
+ (JSC::Profiler::Database::addDatabaseToAtExit):
+ (JSC::Profiler::Database::removeDatabaseFromAtExit):
+ (JSC::Profiler::Database::removeFirstAtExitDatabase):
+
+2015-03-13 Ryosuke Niwa <rniwa@webkit.org>
+
+ BytecodeGenerator needs to be re-entrant to support miranda functions
+ https://bugs.webkit.org/show_bug.cgi?id=142627
+
+ Reviewed by Filip Pizlo.
+
+ Made CodeCache::getGlobalCodeBlock and CodeCache::getFunctionExecutableFromGlobalCode re-entrant
+ by not keeping AddResult while invoking BytecodeGenerator::generate.
+
+ This is needed to support Miranda functions since they need to be lazily initialized.
+
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
+ * runtime/CodeCache.h:
+ (JSC::CodeCacheMap::findCacheAndUpdateAge): Extracted from add.
+ (JSC::CodeCacheMap::addCache): Extracted from add.
+ (JSC::CodeCacheMap::add): Deleted.
+
+2015-03-13 Mark Lam <mark.lam@apple.com>
+
+ Introduce WTF::Atomic to wrap std::atomic for a friendlier CAS.
+ <https://webkit.org/b/142661>
+
+ Reviewed by Filip Pizlo.
+
+ Changed CodeBlock, and the DFG's crashLock to use WTF::Atomic instead of
+ std::atomic.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::visitAggregate):
+ * bytecode/CodeBlock.h:
+ * dfg/DFGCommon.cpp:
+ (JSC::DFG::startCrashing):
+
+2015-03-12 Mark Lam <mark.lam@apple.com>
+
+ Change the DFG crashLock to use std::atomic.
+ <https://webkit.org/b/142649>
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGCommon.cpp:
+ (JSC::DFG::startCrashing):
+ (JSC::DFG::isCrashing):
+
+2015-03-12 Filip Pizlo <fpizlo@apple.com>
+
+ Bytecode liveness analysis should have more lambdas and fewer sets
+ https://bugs.webkit.org/show_bug.cgi?id=142647
+
+ Reviewed by Mark Lam.
+
+ In bug 141174 I'll need to identify all of the bytecode kill sites. This requires hooking into
+ the bytecode analysis' stepOverFunction method, except in such a way that we observe uses that
+ are not in outs. This refactors stepOverFunction so that you can pass it use/def functors that
+ can either be used to propagate outs (as we do right now) or to additionally detect kills or
+ whatever else.
+
+ In order to achieve this, the liveness analysis was moved off of maintaining uses/defs
+ bitvectors. This wasn't helping the abstraction and was probably inefficient. The new code
+ should be a bit faster since we don't have to clear uses/defs bitvectors on each instruction. On
+ the other hand, being able to intercept each use means that our code for exception handlers is
+ no longer a bitwise-merge; it requires finding set bits. Fortunately, this code only kicks in
+ for instructions inside a try, and its performance is O(live at catch), so that's probably not
+ bad.
+
+ * bytecode/BytecodeLivenessAnalysis.cpp:
+ (JSC::indexForOperand):
+ (JSC::stepOverInstruction):
+ (JSC::computeLocalLivenessForBytecodeOffset):
+ (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
+ (JSC::setForOperand): Deleted.
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+
+2015-03-12 Ryosuke Niwa <rniwa@webkit.org>
+
+ "this" should be in TDZ until super is called in the constructor of a derived class
+ https://bugs.webkit.org/show_bug.cgi?id=142527
+
+ Reviewed by Mark Hahnenberg.
+
+ DFG and FTL implementations co-authored by Filip Pizlo.
+
+ In ES6 class syntax, "this" register must be in the "temporal dead zone" (TDZ) and throw ReferenceError until
+ super() is called inside the constructor of a derived class.
+
+ Added op_check_tdz, a new OP code, which throws a reference error when the first operand is an empty value
+ to all tiers of JIT and LLint. The op code throws in the slow path on the basis that a TDZ error should be
+ a programming error and not a part of the programs' normal control flow. In DFG, this op code is represented
+ by a no-op must-generate node CheckNotEmpty modeled after CheckCell.
+
+ Also made the constructor of a derived class assign the empty value to "this" register rather than undefined
+ so that ThisNode can emit the op_check_tdz to check the initialized-ness of "this" in such a constructor.
+
+ * bytecode/BytecodeList.json: Added op_check_tdz.
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset): Ditto.
+ (JSC::computeDefsForBytecodeOffset): Ditto.
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Ditto.
+ * bytecode/ExitKind.cpp:
+ (JSC::exitKindToString): Added TDZFailure.
+ * bytecode/ExitKind.h: Ditto.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator): Assign the empty value to "this" register to indicate it's in TDZ.
+ (JSC::BytecodeGenerator::emitTDZCheck): Added.
+ (JSC::BytecodeGenerator::emitReturn): Emit the TDZ check since "this" can still be in TDZ if super() was never
+ called. e.g. class B extends A { constructor() { } }
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ThisNode::emitBytecode): Always emit the TDZ check if we're inside the constructor of a derived class.
+ We can't omit this check even if the result was ignored per spec.
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Previously, empty value could never appear
+ in a local variable. This is no longer true so generalize this code. Also added the support for CheckNotEmpty.
+ Like CheckCell, we phantomize this DFG node in the constant folding phase if the type of the operand is already
+ found to be not empty. Otherwise filter out SpecEmpty.
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock): Added op_check_tdz.
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel): op_check_tdz can be compiled and inlined.
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize): CheckNotEmpty doesn't read or write values.
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants): Convert CheckNotEmpty to a phantom if non-emptiness had already
+ been proven for the operand prior to this node.
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC): CheckNotEmpty does not trigger GC.
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode): CheckNotEmpty is a no-op in the fixup phase.
+ * dfg/DFGNodeType.h: CheckNotEmpty cannot be removed even if the result was ignored. See ThisNode::emitBytecode.
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate): CheckNotEmpty doesn't return any value.
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute): CheckNotEmpty doesn't load from heap so it's safe.
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile): Speculative the operand to be not empty. OSR exit if the speculation fails.
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile): Ditto.
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile): CheckNotEmpty can be compiled in FTL.
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode): Calls compileCheckNotEmpty for CheckNotEmpty.
+ (JSC::FTL::LowerDFGToLLVM::compileCheckNotEmpty): OSR exit with "TDZFailure" if the operand is not empty.
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass): Added op_check_tdz.
+ (JSC::JIT::privateCompileSlowCases): Ditto.
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_check_tdz): Implements op_check_tdz in Baseline JIT.
+ (JSC::JIT::emitSlow_op_check_tdz): Ditto.
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_check_tdz): Ditto.
+ (JSC::JIT::emitSlow_op_check_tdz): Ditto.
+ * llint/LowLevelInterpreter32_64.asm: Implements op_check_tdz in LLint.
+ * llint/LowLevelInterpreter64.asm: Ditto.
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL): Throws a reference error for op_check_tdz. Shared by LLint and Baseline JIT.
+ * runtime/CommonSlowPaths.h:
+ * tests/stress/class-syntax-no-loop-tdz.js: Added.
+ * tests/stress/class-syntax-no-tdz-in-catch.js: Added.
+ * tests/stress/class-syntax-no-tdz-in-conditional.js: Added.
+ * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js: Added.
+ * tests/stress/class-syntax-no-tdz-in-loop.js: Added.
+ * tests/stress/class-syntax-no-tdz.js: Added.
+ * tests/stress/class-syntax-tdz-in-catch.js: Added.
+ * tests/stress/class-syntax-tdz-in-conditional.js: Added.
+ * tests/stress/class-syntax-tdz-in-loop.js: Added.
+ * tests/stress/class-syntax-tdz.js: Added.
+
+2015-03-12 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Integrate MapData into JSMap and JSSet
+ https://bugs.webkit.org/show_bug.cgi?id=142556
+
+ Reviewed by Filip Pizlo.
+
+ This patch integrates MapData into JSMap and JSSet.
+ This removes 2 object allocation per one JSMap / JSSet.
+
+ MapDataImpl is specialized into MapData and SetData.
+ In the case of SetData, it does not have the dummy values
+ previously stored in the MapDataImpl. So the storage size of SetData
+ becomes the half of the previous implementation.
+
+ And now MapData and SetData are completely integrated into JSMap and JSSet,
+ these structures are not exposed to the other code even in WebCore world.
+
+ And at the same time, this patch fixes missing destroy functions
+ in JSMapIterator and JSSetIterator.
+ They are needed because MapData::const_iterator is a non-trivial destructor.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * runtime/JSMap.cpp:
+ (JSC::JSMap::destroy):
+ (JSC::JSMap::visitChildren):
+ (JSC::JSMap::copyBackingStore):
+ (JSC::JSMap::has):
+ (JSC::JSMap::size):
+ (JSC::JSMap::get):
+ (JSC::JSMap::set):
+ (JSC::JSMap::clear):
+ (JSC::JSMap::remove):
+ (JSC::JSMap::finishCreation): Deleted.
+ * runtime/JSMap.h:
+ (JSC::JSMap::Entry::key):
+ (JSC::JSMap::Entry::value):
+ (JSC::JSMap::Entry::visitChildren):
+ (JSC::JSMap::Entry::setKey):
+ (JSC::JSMap::Entry::setKeyWithoutWriteBarrier):
+ (JSC::JSMap::Entry::setValue):
+ (JSC::JSMap::Entry::clear):
+ (JSC::JSMap::begin):
+ (JSC::JSMap::end):
+ (JSC::JSMap::JSMap):
+ (JSC::JSMap::mapData): Deleted.
+ * runtime/JSMapIterator.cpp:
+ (JSC::JSMapIterator::finishCreation):
+ (JSC::JSMapIterator::destroy):
+ (JSC::JSMapIterator::visitChildren):
+ * runtime/JSMapIterator.h:
+ (JSC::JSMapIterator::JSMapIterator):
+ * runtime/JSSet.cpp:
+ (JSC::JSSet::destroy):
+ (JSC::JSSet::visitChildren):
+ (JSC::JSSet::copyBackingStore):
+ (JSC::JSSet::has):
+ (JSC::JSSet::size):
+ (JSC::JSSet::add):
+ (JSC::JSSet::clear):
+ (JSC::JSSet::remove):
+ (JSC::JSSet::finishCreation): Deleted.
+ * runtime/JSSet.h:
+ (JSC::JSSet::Entry::key):
+ (JSC::JSSet::Entry::value):
+ (JSC::JSSet::Entry::visitChildren):
+ (JSC::JSSet::Entry::setKey):
+ (JSC::JSSet::Entry::setKeyWithoutWriteBarrier):
+ (JSC::JSSet::Entry::setValue):
+ (JSC::JSSet::Entry::clear):
+ (JSC::JSSet::begin):
+ (JSC::JSSet::end):
+ (JSC::JSSet::JSSet):
+ (JSC::JSSet::mapData): Deleted.
+ * runtime/JSSetIterator.cpp:
+ (JSC::JSSetIterator::finishCreation):
+ (JSC::JSSetIterator::visitChildren):
+ (JSC::JSSetIterator::destroy):
+ * runtime/JSSetIterator.h:
+ (JSC::JSSetIterator::JSSetIterator):
+ * runtime/MapConstructor.cpp:
+ (JSC::constructMap):
+ * runtime/MapData.h:
+ (JSC::MapDataImpl::const_iterator::key):
+ (JSC::MapDataImpl::const_iterator::value):
+ (JSC::MapDataImpl::size):
+ (JSC::MapDataImpl<Entry>::MapDataImpl):
+ (JSC::MapDataImpl<Entry>::clear):
+ (JSC::MapDataImpl<Entry>::KeyType::KeyType):
+ (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement):
+ (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot):
+ (JSC::MapDataImpl<Entry>::const_iterator::const_iterator):
+ (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator):
+ (JSC::MapDataImpl<Entry>::const_iterator::operator):
+ (JSC::=):
+ (JSC::MapData::const_iterator::key): Deleted.
+ (JSC::MapData::const_iterator::value): Deleted.
+ (JSC::MapData::create): Deleted.
+ (JSC::MapData::createStructure): Deleted.
+ (JSC::MapData::size): Deleted.
+ (JSC::MapData::clear): Deleted.
+ (JSC::MapData::KeyType::KeyType): Deleted.
+ (JSC::MapData::const_iterator::internalIncrement): Deleted.
+ (JSC::MapData::const_iterator::ensureSlot): Deleted.
+ (JSC::MapData::const_iterator::const_iterator): Deleted.
+ (JSC::MapData::const_iterator::~const_iterator): Deleted.
+ (JSC::MapData::const_iterator::operator*): Deleted.
+ (JSC::MapData::const_iterator::end): Deleted.
+ (JSC::MapData::const_iterator::operator!=): Deleted.
+ (JSC::MapData::const_iterator::operator==): Deleted.
+ * runtime/MapDataInlines.h: Renamed from Source/JavaScriptCore/runtime/MapData.cpp.
+ (JSC::MapDataImpl<Entry>::find):
+ (JSC::MapDataImpl<Entry>::contains):
+ (JSC::MapDataImpl<Entry>::add):
+ (JSC::MapDataImpl<Entry>::set):
+ (JSC::MapDataImpl<Entry>::get):
+ (JSC::MapDataImpl<Entry>::remove):
+ (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore):
+ (JSC::MapDataImpl<Entry>::replaceBackingStore):
+ (JSC::MapDataImpl<Entry>::ensureSpaceForAppend):
+ (JSC::MapDataImpl<Entry>::visitChildren):
+ (JSC::MapDataImpl<Entry>::copyBackingStore):
+ * runtime/MapPrototype.cpp:
+ (JSC::getMap):
+ (JSC::mapProtoFuncClear):
+ (JSC::mapProtoFuncDelete):
+ (JSC::mapProtoFuncForEach):
+ (JSC::mapProtoFuncGet):
+ (JSC::mapProtoFuncHas):
+ (JSC::mapProtoFuncSet):
+ (JSC::mapProtoFuncSize):
+ (JSC::getMapData): Deleted.
+ * runtime/SetPrototype.cpp:
+ (JSC::getSet):
+ (JSC::setProtoFuncAdd):
+ (JSC::setProtoFuncClear):
+ (JSC::setProtoFuncDelete):
+ (JSC::setProtoFuncForEach):
+ (JSC::setProtoFuncHas):
+ (JSC::setProtoFuncSize):
+ (JSC::getMapData): Deleted.
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+
+2015-03-12 Mark Lam <mark.lam@apple.com>
+
+ Use std::atomic for CodeBlock::m_visitAggregateHasBeenCalled.
+ <https://webkit.org/b/142640>
+
+ Reviewed by Mark Hahnenberg.
+
+ We used to spin our own compare and swap on a uint8_t. Now that we can
+ use C++11, let's use std::atomic instead.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::visitAggregate):
+ - The CAS here needs std::memory_order_acquire ordering because it
+ requires lock acquisition semantics to visit the CodeBlock.
+
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlockSet::mark):
+ * heap/CodeBlockSet.cpp:
+ (JSC::CodeBlockSet::clearMarksForFullCollection):
+ (JSC::CodeBlockSet::clearMarksForEdenCollection):
+ - These can go with relaxed ordering because they are all done before
+ the GC starts parallel marking.
+
+2015-03-12 Csaba Osztrogonác <ossy@webkit.org>
+
+ [cmake] Fix the incremental build issue revealed by r181419
+ https://bugs.webkit.org/show_bug.cgi?id=142613
+
+ Reviewed by Carlos Garcia Campos.
+
+ * CMakeLists.txt:
+
+2015-03-11 Ryosuke Niwa <rniwa@webkit.org>
+
+ "static" should not be a reserved keyword in non-strict mode even when ES6 class is enabled
+ https://bugs.webkit.org/show_bug.cgi?id=142600
+
+ Reviewed by Mark Lam.
+
+ Make "static" RESERVED_IF_STRICT and manually detect it in parseClass.
+
+ No new tests. This is already checked by js/reserved-words.html and js/keywords-and-reserved_words.html
+
+ * parser/Keywords.table:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+ * parser/ParserTokens.h:
+
+2015-03-11 Geoffrey Garen <ggaren@apple.com>
+
+ Many users of Heap::reportExtraMemory* are wrong, causing lots of memory growth
+ https://bugs.webkit.org/show_bug.cgi?id=142593
+
+ Reviewed by Andreas Kling.
+
+ Adopt deprecatedReportExtraMemory as a short-term fix for runaway
+ memory growth in these cases where we have not adopted
+ reportExtraMemoryVisited.
+
+ Long-term, we should use reportExtraMemoryAllocated+reportExtraMemoryVisited.
+ That's tracked by https://bugs.webkit.org/show_bug.cgi?id=142595.
+
+ * API/JSBase.cpp:
+ (JSReportExtraMemoryCost):
+ * runtime/SparseArrayValueMap.cpp:
+ (JSC::SparseArrayValueMap::add):
+
+2015-03-11 Geoffrey Garen <ggaren@apple.com>
+
+ Refactored the JSC::Heap extra cost API for clarity and to make some known bugs more obvious
+ https://bugs.webkit.org/show_bug.cgi?id=142589
+
+ Reviewed by Andreas Kling.
+
+ * API/JSBase.cpp:
+ (JSReportExtraMemoryCost): Added a FIXME to annotate a known bug.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::visitAggregate):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::setJITCode): Updated for rename.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::reportExtraMemoryAllocatedSlowCase):
+ (JSC::Heap::deprecatedReportExtraMemorySlowCase): Renamed our reporting
+ APIs to clarify their relationship to each other: One must report extra
+ memory at the time of allocation, and at the time the GC visits it.
+
+ (JSC::Heap::extraMemorySize):
+ (JSC::Heap::size):
+ (JSC::Heap::capacity):
+ (JSC::Heap::sizeAfterCollect):
+ (JSC::Heap::willStartCollection): Updated for renames. Added explicit
+ API for deprecated users who can't use our best API.
+
+ (JSC::Heap::reportExtraMemoryCostSlowCase): Deleted.
+ (JSC::Heap::extraSize): Deleted.
+
+ * heap/Heap.h:
+ * heap/HeapInlines.h:
+ (JSC::Heap::reportExtraMemoryAllocated):
+ (JSC::Heap::reportExtraMemoryVisited):
+ (JSC::Heap::deprecatedReportExtraMemory):
+ (JSC::Heap::reportExtraMemoryCost): Deleted. Ditto.
+
+ * heap/SlotVisitor.h:
+ * heap/SlotVisitorInlines.h:
+ (JSC::SlotVisitor::reportExtraMemoryVisited):
+ (JSC::SlotVisitor::reportExtraMemoryUsage): Deleted. Moved this
+ functionality into the Heap since it's pretty detailed in its access
+ to the heap.
+
+ * runtime/JSArrayBufferView.cpp:
+ (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
+ * runtime/JSGenericTypedArrayViewInlines.h:
+ (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Updated for
+ renames.
+
+ * runtime/JSString.cpp:
+ (JSC::JSString::visitChildren):
+ (JSC::JSRopeString::resolveRopeToAtomicString):
+ (JSC::JSRopeString::resolveRope):
+ * runtime/JSString.h:
+ (JSC::JSString::finishCreation): Updated for renames.
+
+ * runtime/SparseArrayValueMap.cpp:
+ (JSC::SparseArrayValueMap::add): Added FIXME.
+
+ * runtime/WeakMapData.cpp:
+ (JSC::WeakMapData::visitChildren): Updated for rename.
+
+2015-03-11 Ryosuke Niwa <rniwa@webkit.org>
+
+ Calling super() in a base class results in a crash
+ https://bugs.webkit.org/show_bug.cgi?id=142563
+
+ Reviewed by Filip Pizlo.
+
+ The bug was caused by BytecodeGenerator trying to generate "super" expression inside the constructor of a base class.
+ Disallow that by keeping track of whether "super" has been used in the current scope or not (needsSuperBinding flag)
+ and then throwing a syntax error in parseFunctionInfo if it was used and the current scope wasn't the constructor of
+ a derived class.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo): Don't allow super() or super.foo outside the constructor of a derived class.
+ (JSC::Parser<LexerType>::parseClass): Pass in the constructor kind to parseGetterSetter.
+ (JSC::Parser<LexerType>::parseGetterSetter): Ditto to parseFunctionInfo.
+ (JSC::Parser<LexerType>::parseMemberExpression): Set needsSuperBinding flag true on the containing scope.
+ * parser/Parser.h:
+ (JSC::Scope::Scope):
+ (JSC::Scope::needsSuperBinding): Added.
+ (JSC::Scope::setNeedsSuperBinding): Added.
+
+2015-03-10 Darin Adler <darin@apple.com>
+
+ Some event handler fixes
+ https://bugs.webkit.org/show_bug.cgi?id=142474
+
+ Reviewed by Anders Carlsson.
+
+ * inspector/InjectedScriptManager.cpp:
+ (Inspector::InjectedScriptManager::createInjectedScript): Call clearException.
+ I spotted the fact it was missing by auditing all the calls to JSC::call.
+
+2015-03-10 Matthew Mirman <mmirman@apple.com>
+
+ Functions should have initialization precedence over arguments.
+ https://bugs.webkit.org/show_bug.cgi?id=142550
+ rdar://problem/19702564
+
+ Reviewed by Geoffrey Garen.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::initializeCapturedVariable):
+ * tests/stress/initialize_functions_after_arguments.js: Added.
+
+2015-03-10 Andreas Kling <akling@apple.com>
+
+ Eden collections should trigger sweep of MarkedBlocks containing new objects.
+ <https://webkit.org/b/142538>
+
+ Reviewed by Geoffrey Garen.
+
+ Take a snapshot of all MarkedBlocks with new objects as part of Eden collections,
+ and append that to the IncrementalSweeper's working set.
+
+ This ensures that we run destructors for objects that were discovered to be garbage during
+ Eden collections, instead of delaying their teardown until the next full collection,
+ or the next allocation cycle for their block.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::snapshotMarkedSpace): For Eden collections, snapshot the list of MarkedBlocks
+ that contain new objects, since those are the only ones we're interested in.
+ Also use Vector::resizeToFit() to allocate the snapshot for full collections, since we know
+ the final size we need up front.
+
+ (JSC::Heap::notifyIncrementalSweeper): For Eden collections, tell the IncrementalSweeper
+ to add the block snapshot (taken earlier) to its existing set of blocks instead of replacing
+ it entirely. This allows Eden collections and incremental sweeping to occur interleaved with
+ each other without missing destruction opportunities.
+
+ * heap/IncrementalSweeper.h:
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::doSweep):
+ (JSC::IncrementalSweeper::sweepNextBlock): Change the way we iterate over the sweeper's
+ work list: instead of keeping an index for the next block, just pop from the end of the list.
+ This allows us to add new blocks and deduplicate the list without disturbing iteration.
+
+ (JSC::IncrementalSweeper::startSweeping): Make this take a Vector<MarkedBlock>&& so we can
+ pass ownership of this Vector efficiently from Heap to IncrementalSweeper.
+
+ (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Added. This is used by Eden
+ collections to add a set of MarkedBlocks with new objects to the sweeper's existing
+ working set and kick the timer.
+
+ * heap/MarkedSpace.h:
+ (JSC::MarkedSpace::blocksWithNewObjects): Expose the list of MarkedBlocks with new objects.
+
+2015-03-10 Alex Christensen <achristensen@webkit.org>
+
+ Use unsigned for HashSet size.
+ https://bugs.webkit.org/show_bug.cgi?id=142518
+
+ Reviewed by Benjamin Poulain.
+
+ * dfg/DFGAvailabilityMap.cpp:
+ (JSC::DFG::AvailabilityMap::prune):
+ * ftl/FTLOSRExitCompiler.cpp:
+ (JSC::FTL::compileStub):
+ * heap/MarkedBlockSet.h:
+ (JSC::MarkedBlockSet::remove):
+ * runtime/WeakMapData.h:
+
+2015-03-10 Mark Lam <mark.lam@apple.com>
+
+ Use std::numeric_limits<unsigned>::max() instead of (unsigned)-1.
+ <https://webkit.org/b/142539>
+
+ Reviewed by Benjamin Poulain.
+
+ * jit/JIT.cpp:
+ (JSC::JIT::JIT):
+ (JSC::JIT::privateCompileMainPass):
+ (JSC::JIT::privateCompileSlowCases):
+ (JSC::JIT::privateCompile):
+ (JSC::JIT::privateCompileExceptionHandlers):
+ * jit/JITInlines.h:
+ (JSC::JIT::emitNakedCall):
+ (JSC::JIT::addSlowCase):
+ (JSC::JIT::addJump):
+ (JSC::JIT::emitJumpSlowToHot):
+ (JSC::JIT::emitGetVirtualRegister):
+ * jit/SlowPathCall.h:
+ (JSC::JITSlowPathCall::call):
+ * yarr/Yarr.h:
+
+2015-03-10 Mark Lam <mark.lam@apple.com>
+
+ [Win] JSC Build Warnings Need to be Resolved.
+ <https://webkit.org/b/142366>
+
+ Reviewed by Brent Fulgham.
+
+ Applied some benign changes to make the MSVC compiler happy.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::fillJSValue):
+ * runtime/BasicBlockLocation.cpp:
+ (JSC::BasicBlockLocation::getExecutedRanges):
+ * runtime/ControlFlowProfiler.cpp:
+ (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
+
+2015-03-10 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Upgrade Map, Set and WeakMap constructor interface
+ https://bugs.webkit.org/show_bug.cgi?id=142348
+
+ Reviewed by Filip Pizlo.
+
+ In the latest ES6 spec, Map and Set constructors take initialization data sets
+ as iterable value. And iterate it and add the values into the constructed one.
+
+ This is breaking change because the old constructor interface is
+ already shipped in Safari 8.
+
+ * runtime/MapConstructor.cpp:
+ (JSC::callMap):
+ (JSC::constructMap):
+ (JSC::MapConstructor::getCallData):
+ * runtime/SetConstructor.cpp:
+ (JSC::callSet):
+ (JSC::constructSet):
+ * runtime/WeakMapConstructor.cpp:
+ (JSC::callWeakMap):
+ (JSC::constructWeakMap):
+ (JSC::WeakMapConstructor::getCallData):
+ * tests/stress/map-constructor-adder.js: Added.
+ * tests/stress/map-constructor.js: Added.
+ (testCallTypeError):
+ (testTypeError):
+ (for):
+ * tests/stress/set-constructor-adder.js: Added.
+ (Set.prototype.add):
+ * tests/stress/set-constructor.js: Added.
+ (for):
+ * tests/stress/weak-map-constructor-adder.js: Added.
+ * tests/stress/weak-map-constructor.js: Added.
+ (testCallTypeError):
+ (testTypeError):
+ (for):
+
+2015-03-10 Michael Catanzaro <mcatanzaro@igalia.com>
+
+ GCC: CRASH() should be annotated with NORETURN
+ https://bugs.webkit.org/show_bug.cgi?id=142524
+
+ Reviewed by Anders Carlsson.
+
+ Don't return from a NORETURN function. This used to avoid a warning from GCC, but now it
+ causes one.
+
+ * jsc.cpp:
+
+2015-03-10 Mark Lam <mark.lam@apple.com>
+
+ Gardening: fix bleeding debug test bots.
+ https://webkit.org/b/142513>
+
+ Not reviewed.
+
+ The test needs to initialize WTF threading explicitly before using it.
+
+ * API/tests/CompareAndSwapTest.cpp:
+ (testCompareAndSwap):
+
+2015-03-10 Alex Christensen <achristensen@webkit.org>
+
+ [WinCairo] Unreviewed build fix.
+
+ * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
+ Added directory containing config.h, like r181304.
+
+2015-03-09 Mark Lam <mark.lam@apple.com>
+
+ Yet another build fix for Windows.
+ https://webkit.org/b/142513>
+
+ Reviewed by Alex Christensen.
+
+ Looks like MSVC requires the function be explicitly declared in a header file
+ in order for it to be linkable from another file in the same project. This is
+ strange, but it seems to make MSVC happy.
+
+ Also fixed a typo in testapi.vcxproj.filters.
+
+ * API/tests/CompareAndSwapTest.cpp:
+ * API/tests/CompareAndSwapTest.h: Added.
+ * API/tests/testapi.c:
+ * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
+ * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-03-09 Chris Dumez <cdumez@apple.com>
+
+ [iOS] Sweep all collected objects on critical memory pressure
+ https://bugs.webkit.org/show_bug.cgi?id=142457
+ <rdar://problem/20044440>
+
+ Reviewed by Geoffrey Garen.
+
+ All fullSweep() API to IncrementalSweeper so that we can call it in the
+ memory pressure handler.
+
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::fullSweep):
+ * heap/IncrementalSweeper.h:
+ (JSC::IncrementalSweeper::hasWork):
+
+2015-03-09 Mark Lam <mark.lam@apple.com>
+
+ Another build fix for Windows.
+ https://webkit.org/b/142513>
+
+ Not reviewed.
+
+ * API/tests/CompareAndSwapTest.cpp:
+ - Added JS_EXPORT_PRIVATE attribute.
+
+2015-03-09 Mark Lam <mark.lam@apple.com>
+
+ Build fix for Windows after r181305.
+ https://webkit.org/b/142513>
+
+ Reviewed by Alex Christensen.
+
+ Windows doesn't like pthreads anymore. Changed test to use WTF threading.
+
+ * API/tests/CompareAndSwapTest.cpp:
+ (setBitThreadFunc):
+ (testCompareAndSwap):
+
+2015-03-09 Mark Lam <mark.lam@apple.com>
+
+ 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:
+
+2015-03-09 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] testapi project is unable to find the 'config.h' file.
+
+ Rubberstamped by Mark Lam.
+
+ * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Add JavaScriptCore source directory
+ to the include path.
+
+2015-03-09 Andreas Kling <akling@apple.com>
+
+ Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
+ <https://webkit.org/b/142115>
+ <rdar://problem/19992268>
+
+ Reviewed by Geoffrey Garen.
+
+ Prune stale entries from WeakGCMaps as part of every full garbage collection.
+ This frees up tons of previously-stuck WeakBlocks that were only sitting around
+ with finalized handles waiting to die.
+
+ Note that WeakGCMaps register/unregister themselves with the GC heap in their
+ ctor/dtor, so creating one now requires passing the VM.
+
+ Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
+ to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
+ It seems somewhat excessive to do this on every Eden collection, so it's only
+ doing work in full collections for now.
+
+ Because the GC may now mutate WeakGCMap below object allocation, I've made it
+ so that the classic HashMap::add() optimization can't be used with WeakGCMap.
+ This caused intermittent test failures when originally landed due to having
+ an invalid iterator on the stack after add() inserted a new entry and we
+ proceeded to allocate the new object, triggering GC.
+
+ * API/JSWeakObjectMapRefInternal.h:
+ (OpaqueJSWeakObjectMap::create):
+ (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
+ * API/JSWeakObjectMapRefPrivate.cpp:
+ * API/JSWrapperMap.mm:
+ (-[JSWrapperMap initWithContext:]):
+ (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
+ it project-private so WebCore clients can access it.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::collect):
+ (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
+ stale entries from WeakGCMaps. This is only executed during full collections.
+
+ * heap/Heap.h:
+ * heap/HeapInlines.h:
+ (JSC::Heap::registerWeakGCMap):
+ (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
+ themselves with the Heap and provide a pruning callback.
+
+ * runtime/PrototypeMap.h:
+ (JSC::PrototypeMap::PrototypeMap):
+ * runtime/Structure.cpp:
+ (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
+
+ * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
+
+ * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
+
+ * runtime/JSString.cpp:
+ (JSC::jsStringWithCacheSlowCase):
+ * runtime/PrototypeMap.cpp:
+ (JSC::PrototypeMap::addPrototype):
+ (JSC::PrototypeMap::emptyObjectStructureForPrototype): Remove HashMap add()
+ optimization since it's not safe in the GC-managed WeakGCMap world.
+
+ * runtime/VM.cpp:
+ (JSC::VM::VM): Pass VM to WeakGCMap constructor.
+
+ * runtime/WeakGCMap.h:
+ (JSC::WeakGCMap::set):
+ (JSC::WeakGCMap::add):
+ (JSC::WeakGCMap::WeakGCMap): Deleted.
+ (JSC::WeakGCMap::gcMap): Deleted.
+ (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
+ * runtime/WeakGCMapInlines.h: Added.
+ (JSC::WeakGCMap::WeakGCMap):
+ (JSC::WeakGCMap::~WeakGCMap):
+ (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
+ to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
+ prunes WeakGCMap at certain growth milestones and instead rely on the GC
+ callback for housekeeping.
+
+2015-03-09 Ryosuke Niwa <rniwa@webkit.org>
+
+ Support extends and super keywords
+ https://bugs.webkit.org/show_bug.cgi?id=142200
+
+ Reviewed by Filip Pizlo.
+
+ Added the support for ES6 class syntax inheritance.
+
+ Added ConstructorKind as well as boolean flags indicating the constructor kind to
+ various classes in UnlinkedCodeBlock as well as AST nodes.
+
+ Each method stores the associated class as its homeObjectPrivateName. This value is used to
+ make super calls.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock):
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+ (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
+
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::ExecutableInfo::ExecutableInfo):
+ (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Added.
+ (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Added.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator): Don't emit op_create_this in a derived class
+ as the object is allocated by the highest base class's constructor. Also set "this" to null
+ and store the original value in m_newTargetRegister. "this" is supposed to be in TDZ but
+ that will be implemented in a separate patch.
+ (JSC::BytecodeGenerator::emitReturn): Allow "undefined" to be returned from a derived class.
+ In a derived class's constructor, not returning "undefined" or an object results in a type
+ error instead of "this" being returned.
+ (JSC::BytecodeGenerator::emitThrowTypeError): Added.
+
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::constructorKindIsDerived): Added.
+ (JSC::BytecodeGenerator::newTarget): Added.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::SuperNode::emitBytecode): Added. Emits the code to obtain the callee's parent class.
+ (JSC::emitSuperBaseForCallee): Added. Emits the code to obtain the parent class's prototype.
+ (JSC::emitPutHomeObject): Added.
+ (JSC::PropertyListNode::emitBytecode): Stores the home object when adding methods.
+ (JSC::PropertyListNode::emitPutConstantProperty): Ditto.
+ (JSC::BracketAccessorNode::emitBytecode): Added the support for super['foo'].
+ (JSC::DotAccessorNode::emitBytecode): Added the support for super.foo.
+ (JSC::FunctionCallValueNode::emitBytecode): Added the support for super().
+ (JSC::FunctionCallBracketNode::emitBytecode): Added the support for super['foo']().
+ (JSC::FunctionCallDotNode::emitBytecode): Added the support for super.foo().
+ (JSC::DeleteBracketNode::emitBytecode): Forbid "delete super.foo".
+ (JSC::DeleteDotNode::emitBytecode): Forbid "delete super['foo']".
+ (JSC::ClassExprNode::emitBytecode): Added the support for "classHeritage". This is the main
+ logic for inheritance. When a class B inherits from a class A, set B.__proto__ to A and set
+ B.prototype.__proto__ to A.prototype. Throw exceptions when either A or A.__proto__ is not
+ an object.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::superExpr): Added.
+
+ * parser/NodeConstructors.h:
+ (JSC::SuperNode::SuperNode): Added.
+
+ * parser/Nodes.cpp:
+ (JSC::FunctionBodyNode::FunctionBodyNode):
+
+ * parser/Nodes.h:
+ (JSC::ExpressionNode::isSuperNode):
+ (JSC::PropertyNode::type):
+ (JSC::PropertyNode::needsSuperBinding):
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionBody):
+ (JSC::Parser<LexerType>::parseFunctionInfo): Throw a parser error if super() is used outside
+ of class constructors.
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseClass): ConstructorKind is "derived" if and only if the parent
+ class is specified in the declaration / expression.
+ (JSC::Parser<LexerType>::parseGetterSetter):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ (JSC::Parser<LexerType>::parseMemberExpression): Added the support for "super()", "super.foo",
+ and "super['foo']". Throw a semantic error if "super" appears by itself.
+
+ * parser/Parser.h:
+ (JSC::Scope::Scope): Added m_hasDirectSuper. This variable keeps track of the use of "super()"
+ so that parseFunctionInfo can spit an error if it's used outside of class constructors.
+ (JSC::Scope::hasDirectSuper): Added.
+ (JSC::Scope::setHasDirectSuper): Added.
+
+ * parser/ParserModes.h:
+ (JSC::ConstructorKind): Added.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::superExpr): Added.
+
+ * runtime/CommonIdentifiers.h: Added homeObjectPrivateName.
+
+ * runtime/Executable.h:
+ (JSC::EvalExecutable::executableInfo):
+ (JSC::ProgramExecutable::executableInfo):
+
+2015-03-08 Andreas Kling <akling@apple.com>
+
+ JITThunks keeps finalized Weaks around, pinning WeakBlocks.
+ <https://webkit.org/b/142454>
+
+ Reviewed by Darin Adler.
+
+ Make JITThunks a WeakHandleOwner so it can keep its host function map free of stale entries.
+ This fixes an issue I was seeing where a bunch of WeakBlocks stuck around with nothing but
+ finalized Weak<NativeExecutable> entries.
+
+ * jit/JITThunks.h:
+ * jit/JITThunks.cpp:
+ (JSC::JITThunks::finalize): Make JITThunks inherit from WeakHandleOwner so it can receive
+ a callback when the NativeExecutables get garbage collected.
+
+ (JSC::JITThunks::hostFunctionStub): Pass 'this' as the handle owner when creating Weaks.
+
+2015-03-08 Andreas Kling <akling@apple.com>
+
+ BuiltinExecutables keeps finalized Weaks around, pinning WeakBlocks.
+ <https://webkit.org/b/142460>
+
+ Reviewed by Geoffrey Garen.
+
+ Make BuiltinExecutables a WeakHandleOwner so it can clear out its respective Weak members
+ if and when their pointees get garbage collected.
+
+ This fixes an issue I've seen locally where a WeakBlock is pinned down by a single one of
+ these Weak<BuiltinExecutables>.
+
+ * builtins/BuiltinExecutables.h: Make BuiltinExecutables inherit from WeakHandleOwner.
+
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::finalize): Clear out the relevant member pointer when it's been
+ garbage collected. We use the WeakImpl's "context" field to pass the address of the member.
+
+2015-03-07 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the removal of BlockAllocator, which is now unused.
+
+ * API/JSBase.cpp:
+ * CMakeLists.txt:
+ * JavaScriptCore.order:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * heap/BlockAllocator.cpp: Removed.
+ * heap/BlockAllocator.h: Removed.
+ * heap/GCThreadSharedData.h:
+ * heap/HandleBlockInlines.h:
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ * heap/Heap.h:
+ * heap/HeapInlines.h:
+ (JSC::Heap::blockAllocator): Deleted.
+ * heap/HeapTimer.cpp:
+ * heap/MarkedBlock.h:
+ * heap/MarkedSpace.h:
+ * heap/Region.h: Removed.
+ * heap/SuperRegion.cpp: Removed.
+ * heap/SuperRegion.h: Removed.
+
+2015-03-07 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r181010.
+ https://bugs.webkit.org/show_bug.cgi?id=142442
+
+ Broke media/video-src-invalid-poster.html (Requested by kling
+ on #webkit).
+
+ Reverted changeset:
+
+ "Stale entries in WeakGCMaps are keeping tons of WeakBlocks
+ alive unnecessarily."
+ https://bugs.webkit.org/show_bug.cgi?id=142115
+ http://trac.webkit.org/changeset/181010
+
+2015-03-07 Ryosuke Niwa <rniwa@webkit.org>
+
+ The code to link FunctionExecutable is duplicated everywhere
+ https://bugs.webkit.org/show_bug.cgi?id=142436
+
+ Reviewed by Darin Adler.
+
+ Reduced code duplication by factoring out linkInsideExecutable and linkGlobalCode.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock): Calls linkInsideExecutable.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Renamed from link. Now takes care of startOffset.
+ This change was needed to use this function in CodeBlock::CodeBlock. Also, this function no longer takes
+ lineOffset since this information is already stored in the source code.
+ (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Extracted from FunctionExecutable::fromGlobalCode.
+
+ * bytecode/UnlinkedCodeBlock.h:
+
+ * generate-js-builtins: Calls linkGlobalCode.
+
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::initializeGlobalProperties): Calls linkGlobalCode.
+ (JSC::FunctionExecutable::fromGlobalCode): Calls linkGlobalCode.
+
+2015-03-06 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the MarkedBlock piece of this patch.
+
+ * heap/MarkedAllocator.cpp:
+ (JSC::MarkedAllocator::allocateBlock):
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::create):
+ (JSC::MarkedBlock::destroy):
+ (JSC::MarkedBlock::MarkedBlock):
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::capacity):
+ * heap/MarkedSpace.cpp:
+ (JSC::MarkedSpace::freeBlock):
+
+2015-03-07 Ryosuke Niwa <rniwa@webkit.org>
+
+ fromGlobalCode has an unused Debugger* argument
+ https://bugs.webkit.org/show_bug.cgi?id=142430
+
+ Reviewed by Darin Adler.
+
+ Removed the debugger argument from UnlinkedFunctionExecutable::fromGlobalCode and
+ FunctionExecutable::fromGlobalCode since it's not used in either function.
+
+ Also use reference in other arguments.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
+ * bytecode/UnlinkedCodeBlock.h:
+ * runtime/Executable.cpp:
+ (JSC::FunctionExecutable::fromGlobalCode):
+ * runtime/Executable.h:
+ * runtime/FunctionConstructor.cpp:
+ (JSC::constructFunctionSkippingEvalEnabledCheck):
+
+2015-03-06 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Turn off a warning on Windows.
+
+ Reduce build logging noise on Windows.
+
+ * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
+
+2015-03-06 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ES6: Improved Support for Iterator Objects
+ https://bugs.webkit.org/show_bug.cgi?id=142420
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Runtime.json:
+ Add new object subtype "iterator" for built-in iterator objects.
+
+ * inspector/InjectedScriptSource.js:
+ Return iterator values as Entry objects.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ Identify "iterator" typed objects.
+
+ (Inspector::JSInjectedScriptHost::getInternalProperties):
+ Provide internal properties for the different Iterator objects.
+
+ (Inspector::JSInjectedScriptHost::iteratorEntries):
+ Fetch the next few iterator entries of a built-in iterator object.
+
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
+ Call through to JSInjectedScriptHost.
+
+ * runtime/JSArgumentsIterator.cpp:
+ (JSC::JSArgumentsIterator::clone):
+ * runtime/JSArgumentsIterator.h:
+ (JSC::JSArgumentsIterator::iteratedValue):
+ * runtime/JSArrayIterator.cpp:
+ (JSC::JSArrayIterator::kind):
+ (JSC::JSArrayIterator::iteratedValue):
+ (JSC::JSArrayIterator::clone):
+ * runtime/JSArrayIterator.h:
+ * runtime/JSMapIterator.cpp:
+ (JSC::JSMapIterator::finishCreation):
+ (JSC::JSMapIterator::clone):
+ * runtime/JSMapIterator.h:
+ (JSC::JSMapIterator::kind):
+ (JSC::JSMapIterator::iteratedValue):
+ * runtime/JSSetIterator.cpp:
+ (JSC::JSSetIterator::finishCreation):
+ (JSC::JSSetIterator::clone):
+ * runtime/JSSetIterator.h:
+ (JSC::JSSetIterator::kind):
+ (JSC::JSSetIterator::iteratedValue):
+ * runtime/JSStringIterator.cpp:
+ (JSC::JSStringIterator::iteratedValue):
+ (JSC::JSStringIterator::clone):
+ * runtime/JSStringIterator.h:
+ Add accessors for internal properties and provide a way to clone the
+ iterator so we can be at the same index and peek at the next few
+ objects without modifying the original iterator object.
+
+2015-03-06 Ryosuke Niwa <rniwa@webkit.org>
+
+ REGRESSION(r180595): construct varargs fails in FTL
+ https://bugs.webkit.org/show_bug.cgi?id=142030
+
+ Reviewed by Michael Saboff.
+
+ Increase sizeOfCallVarargs as done for sizeOfConstructVarargs in r180651.
+
+ * ftl/FTLInlineCacheSize.cpp:
+ (JSC::FTL::sizeOfCallVarargs):
+
+2015-03-06 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Adopt Object Literal Shorthand Property Construction Syntax
+ https://bugs.webkit.org/show_bug.cgi?id=142374
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+
+2015-03-06 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Object Literal Extensions - Methods
+ https://bugs.webkit.org/show_bug.cgi?id=142390
+
+ Reviewed by Geoffrey Garen.
+
+ Support method syntax in object literals.
+
+ * parser/Parser.h:
+ * parser/Parser.cpp:
+ (JSC::stringForFunctionMode):
+ (JSC::Parser<LexerType>::parseProperty):
+ Methods are allowed for identifier, string, and numeric names,
+ and computed property names.
+
+ (JSC::Parser<LexerType>::parsePropertyMethod):
+ Helper for parsing a property method.
+
+2015-03-05 Joseph Pecoraro <pecoraro@apple.com>
+
+ __proto__ shorthand property should not modify prototype in Object Literal construction
+ https://bugs.webkit.org/show_bug.cgi?id=142382
+
+ Reviewed by Geoffrey Garen.
+
+ When parsing shorthand property syntax we know we will do a
+ put direct, even if the property name is __proto__. Pass that
+ information through to bytecode generation.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitDirectPutById):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::PropertyListNode::emitPutConstantProperty):
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createGetterOrSetterProperty):
+ (JSC::ASTBuilder::createProperty):
+ * parser/NodeConstructors.h:
+ (JSC::PropertyNode::PropertyNode):
+ * parser/Nodes.h:
+ (JSC::PropertyNode::putType):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseClass):
+ (JSC::Parser<LexerType>::parseProperty):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createProperty):
+
+2015-03-06 Geoffrey Garen <ggaren@apple.com>
+
+ Fix crashes seen on the the 32-bit buildbots after my last patch.
+
+ Unreviewed.
+
+ * heap/CopiedBlock.h:
+ (JSC::CopiedBlock::payload):
+ * heap/CopiedSpace.cpp:
+ (JSC::CopiedSpace::tryAllocateOversize): Round up to the right alignment,
+ since the size of the CopiedBlock class is not guaranteed to be the
+ right alignment, and is in fact the wrong alignment on 32-bit.
+
+2015-03-05 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the CopiedBlock piece of this patch.
+
+ * heap/CopiedBlock.h:
+ (JSC::CopiedBlock::createNoZeroFill):
+ (JSC::CopiedBlock::destroy):
+ (JSC::CopiedBlock::create):
+ (JSC::CopiedBlock::CopiedBlock):
+ (JSC::CopiedBlock::isOversize):
+ (JSC::CopiedBlock::payloadEnd):
+ (JSC::CopiedBlock::capacity):
+ * heap/CopiedSpace.cpp:
+ (JSC::CopiedSpace::~CopiedSpace):
+ (JSC::CopiedSpace::tryAllocateOversize):
+ (JSC::CopiedSpace::tryReallocateOversize):
+ * heap/CopiedSpaceInlines.h:
+ (JSC::CopiedSpace::recycleEvacuatedBlock):
+ (JSC::CopiedSpace::recycleBorrowedBlock):
+ (JSC::CopiedSpace::allocateBlockForCopyingPhase):
+ (JSC::CopiedSpace::allocateBlock):
+ (JSC::CopiedSpace::startedCopying):
+ * heap/CopyWorkList.h:
+
+2015-03-06 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [iOS] SVG fonts are garbled
+ https://bugs.webkit.org/show_bug.cgi?id=142377
+
+ Reviewed by Simon Fraser.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-03-05 Joseph Pecoraro <pecoraro@apple.com>
+
+ ES6: Object Literal Extensions - Shorthand Properties (Identifiers)
+ https://bugs.webkit.org/show_bug.cgi?id=142353
+
+ Reviewed by Geoffrey Garen.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseProperty):
+ Parsing an identifier property followed by a comma or end brace treat
+ as a shorthand property and create a property that has the same
+ property name as the identifier name and value of a variable with that
+ identifier. Otherwise, fall through to getter/setter parsing.
+
+2015-03-05 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Unreviewed gardening.
+
+ Confirmed with JSC that warning 4611 (interaction between '_setjmp' and C++ object
+ destruction is non-portable) should be ignored in the JavaScriptCore project.
+
+ * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Silence warning 4611.
+
+2015-03-05 Chris Dumez <cdumez@apple.com>
+
+ Regression(r173761): ASSERTION FAILED: !is8Bit() in StringImpl::characters16()
+ https://bugs.webkit.org/show_bug.cgi?id=142350
+
+ Reviewed by Michael Saboff and Benjamin Poulain.
+
+ Call WTFString::hasInfixStartingAt() / hasInfixEndingAt() now that these
+ methods have been renamed for clarity.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncStartsWith):
+ (JSC::stringProtoFuncEndsWith):
+
+2015-03-05 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Implement ES6 StringIterator
+ https://bugs.webkit.org/show_bug.cgi?id=142080
+
+ Reviewed by Filip Pizlo.
+
+ This patch introduces ES6 String Iterator.
+ It enumerates code points instead of elements in String.
+ So surrogate pairs should be handled correctly.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * builtins/StringIterator.prototype.js: Added.
+ (next):
+ * runtime/CommonIdentifiers.h:
+ * runtime/JSGlobalObject.cpp:
+ * runtime/JSGlobalObject.h:
+ * runtime/JSStringIterator.cpp: Added.
+ (JSC::JSStringIterator::finishCreation):
+ * runtime/JSStringIterator.h: Added.
+ (JSC::JSStringIterator::createStructure):
+ (JSC::JSStringIterator::create):
+ (JSC::JSStringIterator::JSStringIterator):
+ * runtime/StringIteratorConstructor.cpp: Added.
+ (JSC::StringIteratorConstructor::finishCreation):
+ * runtime/StringIteratorConstructor.h: Added.
+ (JSC::StringIteratorConstructor::create):
+ (JSC::StringIteratorConstructor::createStructure):
+ (JSC::StringIteratorConstructor::StringIteratorConstructor):
+ * runtime/StringIteratorPrototype.cpp: Added.
+ (JSC::StringIteratorPrototype::finishCreation):
+ (JSC::StringIteratorPrototype::getOwnPropertySlot):
+ (JSC::stringIteratorPrototypeIterator):
+ * runtime/StringIteratorPrototype.h: Added.
+ (JSC::StringIteratorPrototype::create):
+ (JSC::StringIteratorPrototype::createStructure):
+ (JSC::StringIteratorPrototype::StringIteratorPrototype):
+ * runtime/StringPrototype.cpp:
+ (JSC::StringPrototype::finishCreation):
+ (JSC::stringProtoFuncIterator):
+ * tests/stress/string-iterators.js: Added.
+ (testSurrogatePair):
+ (increment):
+ (for):
+
+2015-03-05 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Fix the FTL build on Aarch64 Linux after r177421
+ https://bugs.webkit.org/show_bug.cgi?id=142040
+
+ Reviewed by Mark Lam.
+
+ * llvm/library/LLVMExports.cpp:
+ (initializeAndGetJSCLLVMAPI):
+
+2015-03-05 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Upgrade ES6 Iterator interfaces
+ https://bugs.webkit.org/show_bug.cgi?id=141351
+
+ Reviewed by Filip Pizlo.
+
+ This patch upgrades the exising ES6 iterator to align the latest spec.
+ In the latest spec,
+ 1. `Iterator.next` returns object that implements IteratorResult interface { value: value, done, boolean }.
+ 2. `Iterator.return` is introduced. When the iteration is terminated by the abrupt completion,
+ it is called to close iterator state.
+ 3. Iterator.next of Array is moved from an iterator object to `%ArrayIteratorPrototype%`.
+
+ To upgrade it, we changes the bytecode that represents for-of loops.
+ And to embody the efficient iteration with an iterator object,
+ we implemented %ArrayIteratorPrototype%.next in JavaScript and
+ it is located in builtins/ArrayIterator.prototype.js.
+ Implementing it in JavaScript encourages inlining and
+ utilizes escape analysis for an iterator result object in DFG JIT.
+ And we dropped the intrinsic version of %ArrayIteratorPrototype%.next.
+
+ And we introduced IteratorOperations that is defined in the spec.
+ It aligns the iteration in the runtime to the latest spec.
+ Currently, Promise.all and Promise.race uses an iterable object.
+ However, Promise.all and Promise.race implementation is also based on the old spec.
+ Subsequent patches will upgrade it.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * builtins/ArrayIterator.prototype.js: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.h.
+ (next):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitReturn):
+ (JSC::BytecodeGenerator::emitThrowTypeError):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::emitIsObject):
+ (JSC::BytecodeGenerator::emitIsUndefined):
+ * bytecompiler/BytecodeGenerator.h:
+ * jit/ThunkGenerators.cpp:
+ (JSC::arrayIteratorNextThunkGenerator): Deleted.
+ (JSC::arrayIteratorNextKeyThunkGenerator): Deleted.
+ (JSC::arrayIteratorNextValueThunkGenerator): Deleted.
+ * jit/ThunkGenerators.h:
+ * runtime/ArgumentsIteratorPrototype.cpp:
+ (JSC::ArgumentsIteratorPrototype::finishCreation):
+ (JSC::argumentsIteratorPrototypeFuncNext):
+ * runtime/ArrayIteratorPrototype.cpp:
+ (JSC::ArrayIteratorPrototype::finishCreation):
+ (JSC::ArrayIteratorPrototype::getOwnPropertySlot):
+ (JSC::arrayIteratorProtoFuncIterator):
+ (JSC::arrayIteratorPrototypeIterate): Deleted.
+ * runtime/ArrayIteratorPrototype.h:
+ * runtime/CommonIdentifiers.h:
+ * runtime/Intrinsic.h:
+ * runtime/IteratorOperations.cpp: Added.
+ (JSC::iteratorNext):
+ (JSC::iteratorValue):
+ (JSC::iteratorComplete):
+ (JSC::iteratorStep):
+ (JSC::iteratorClose):
+ (JSC::createIterResultObject):
+ * runtime/IteratorOperations.h: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.cpp.
+ * runtime/JSArrayIterator.cpp:
+ (JSC::JSArrayIterator::finishCreation):
+ (JSC::JSArrayIterator::visitChildren): Deleted.
+ (JSC::createIteratorResult): Deleted.
+ (JSC::arrayIteratorNext): Deleted.
+ (JSC::arrayIteratorNextKey): Deleted.
+ (JSC::arrayIteratorNextValue): Deleted.
+ (JSC::arrayIteratorNextGeneric): Deleted.
+ * runtime/JSArrayIterator.h:
+ (JSC::JSArrayIterator::JSArrayIterator):
+ (JSC::JSArrayIterator::iterationKind): Deleted.
+ (JSC::JSArrayIterator::iteratedObject): Deleted.
+ (JSC::JSArrayIterator::nextIndex): Deleted.
+ (JSC::JSArrayIterator::setNextIndex): Deleted.
+ (JSC::JSArrayIterator::finish): Deleted.
+ (JSC::JSArrayIterator::offsetOfIterationKind): Deleted.
+ (JSC::JSArrayIterator::offsetOfIteratedObject): Deleted.
+ (JSC::JSArrayIterator::offsetOfNextIndex): Deleted.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSPromiseConstructor.cpp:
+ (JSC::performPromiseRaceLoop):
+ (JSC::JSPromiseConstructorFuncRace):
+ (JSC::performPromiseAll):
+ (JSC::JSPromiseConstructorFuncAll):
+ * runtime/MapIteratorPrototype.cpp:
+ (JSC::MapIteratorPrototype::finishCreation):
+ (JSC::MapIteratorPrototypeFuncNext):
+ * runtime/SetIteratorPrototype.cpp:
+ (JSC::SetIteratorPrototype::finishCreation):
+ (JSC::SetIteratorPrototypeFuncNext):
+ * runtime/VM.cpp:
+ (JSC::thunkGeneratorForIntrinsic):
+ * tests/stress/array-iterators-next-with-call.js: Added.
+ (increment):
+ (for):
+ * tests/stress/array-iterators-next.js: Added.
+
+ Revive the older Array iterator tests that manually call 'next' method.
+
+ * tests/stress/custom-iterators.js: Added.
+ (iter.next):
+ (iter.Symbol.iterator):
+ (iter.return):
+ (iter.get next):
+ (iter.get return):
+ (iteratorInterfaceErrorTest.iter.next):
+ (iteratorInterfaceErrorTest.iter.Symbol.iterator):
+ (iteratorInterfaceErrorTest.iter.return):
+ (iteratorInterfaceErrorTest):
+ (iteratorInterfaceErrorTestReturn.iter.next):
+ (iteratorInterfaceErrorTestReturn.iter.Symbol.iterator):
+ (iteratorInterfaceErrorTestReturn.iter.return):
+ (iteratorInterfaceErrorTestReturn):
+ (iteratorInterfaceBreakTestReturn.iter.next):
+ (iteratorInterfaceBreakTestReturn.iter.Symbol.iterator):
+ (iteratorInterfaceBreakTestReturn.iter.return):
+ (iteratorInterfaceBreakTestReturn):
+
+ This tests the behavior of custom iterators.
+ 'next' and 'return' of iterator work with for-of.
+
+ * tests/stress/iterators-shape.js: Added.
+ (iteratorShape):
+ (sameNextMethods):
+ (set var):
+
+ This tests the shape of iterators; iterators of Array have 'next' method in %ArrayIteratorPrototype%.
+
+ * tests/stress/map-iterators-next.js: Added.
+ (set var):
+ (.get if):
+ (otherKey):
+ * tests/stress/set-iterators-next.js: Added.
+ (otherKey):
+
+2015-03-04 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Hide Promise with runtime flags under Cocoa JSContext API
+ https://bugs.webkit.org/show_bug.cgi?id=141965
+
+ Reviewed by Filip Pizlo.
+
+ Since there's no run loop in JavaScriptCore APIs, Promises don't work currently.
+ So until they work, we hide Promise from a global object.
+ Introduce new JSC runtime flag, PromiseDisabled. When `isPromiseDisabled` is true,
+ Promise constructor is not attached to JSGlobalObject.
+
+ To make 0 as default runtime flags, we choose PromiseDisabled flag
+ instead of PromiseEnabled flag. So by default, Promise is enabled.
+
+ * API/JSCallbackObjectFunctions.h:
+ (JSC::JSCallbackObject<Parent>::JSCallbackObject):
+ * API/JSContextRef.cpp:
+ (javaScriptRuntimeFlags):
+ (JSGlobalContextCreateInGroup):
+ * API/tests/testapi.c:
+ (main):
+ * API/tests/testapi.mm:
+ (testObjectiveCAPI):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::create):
+ * runtime/RuntimeFlags.h:
+ (JSC::RuntimeFlags::createAllEnabled):
+
+2015-03-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Array/Collection Sizes should be visible and distinct
+ https://bugs.webkit.org/show_bug.cgi?id=142254
+
+ Reviewed by Timothy Hatcher.
+
+ * runtime/WeakMapData.h:
+ (JSC::WeakMapData::size):
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::weakMapSize):
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
+ Add a way to get a WeakMap's size.
+
+ * inspector/protocol/Runtime.json:
+ Include size in RemoteObject and ObjectPreview.
+
+ * inspector/InjectedScriptSource.js:
+ Set the size of RemoteObjects and previews if they
+ are array/collection types.
+
+2015-03-04 Andreas Kling <akling@apple.com>
+
+ GC should compute stack bounds and dump registers at the earliest opportunity.
+ <https://webkit.org/b/142310>
+ <rdar://problem/20045624>
+
+ Reviewed by Geoffrey Garen.
+
+ Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
+ The wrapper function that grabs a snapshot of the current stack boundaries and register values
+ on entry, and sanitizes the stack on exit.
+
+ This is a speculative fix for what appears to be overly conservative behavior in the garbage
+ collector following r178364 which caused a measurable regression in memory usage on Membuster.
+ The theory being that we were putting pointers to dead things on the stack before scanning it,
+ and by doing that ended up marking things that we'd otherwise discover to be garbage.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::markRoots):
+ (JSC::Heap::gatherStackRoots):
+ (JSC::Heap::collect):
+ (JSC::Heap::collectImpl):
+ * heap/Heap.h:
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::gatherFromCurrentThread):
+ (JSC::MachineThreads::gatherConservativeRoots):
+ * heap/MachineStackMarker.h:
+
+2015-03-04 Debarshi Ray <debarshir@gnome.org>
+
+ Silence GCC's -Wstrict-prototypes
+ https://bugs.webkit.org/show_bug.cgi?id=142278
+
+ Reviewed by Alexey Proskuryakov.
+
+ * API/JSContextRef.h:
+
+2015-03-04 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Add a node for Math.log()
+ https://bugs.webkit.org/show_bug.cgi?id=142126
+
+ Reviewed by Geoffrey Garen.
+
+ This patch adds the DFG node ArithLog for LogIntrinsic.
+
+ Having a direct call to log has very little value by itself, the implementation
+ in DFG and FTL is a simple function call.
+
+ What is useful in ArithLog is that we know the operation is pure.
+ This allow us to hoist it out of loops when the argument is independent
+ is an invariant of the loop.
+
+ Perf wise, this patch gives:
+ -Kraken's imaging-darkroom: definitely 1.2372x faster.
+ -AsmBench's Towers.c: definitely 1.0261x faster.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithLog):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileArithLog):
+ * ftl/FTLOutput.h:
+ (JSC::FTL::Output::doubleLog):
+ * tests/stress/math-log-basics.js: Added.
+ * tests/stress/math-log-with-constants.js: Added.
+
+2015-03-04 Filip Pizlo <fpizlo@apple.com>
+
+ Only Heap should be in charge of deciding how to select a subspace for a type
+ https://bugs.webkit.org/show_bug.cgi?id=142304
+
+ Reviewed by Mark Lam.
+
+ This slightly reduces the code duplication for selecting subspace based on type, and what
+ duplication is left is at least localized in HeapInlines.h. The immediate effect is that
+ the DFG and FTL don't have to duplicate this pattern.
+
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
+ (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::allocateObject):
+ * heap/Heap.h:
+ * heap/HeapInlines.h:
+ (JSC::Heap::allocateObjectOfType):
+ (JSC::Heap::subspaceForObjectOfType):
+ (JSC::Heap::allocatorForObjectOfType):
+ * runtime/JSCellInlines.h:
+ (JSC::allocateCell):
+
+2015-03-04 Andreas Kling <akling@apple.com>
+
+ Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
+ <https://webkit.org/b/142115>
+ <rdar://problem/19992268>
+
+ Reviewed by Geoffrey Garen.
+
+ Prune stale entries from WeakGCMaps as part of every full garbage collection.
+ This frees up tons of previously-stuck WeakBlocks that were only sitting around
+ with finalized handles waiting to die.
+
+ Note that WeakGCMaps register/unregister themselves with the GC heap in their
+ ctor/dtor, so creating one now requires passing the VM.
+
+ Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
+ to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
+ It seems somewhat excessive to do this on every Eden collection, so it's only
+ doing work in full collections for now.
+
+ * API/JSWeakObjectMapRefInternal.h:
+ (OpaqueJSWeakObjectMap::create):
+ (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
+ * API/JSWeakObjectMapRefPrivate.cpp:
+ * API/JSWrapperMap.mm:
+ (-[JSWrapperMap initWithContext:]):
+ (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
+ it project-private so WebCore clients can access it.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::collect):
+ (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
+ stale entries from WeakGCMaps. This is only executed during full collections.
+
+ * heap/Heap.h:
+ * heap/HeapInlines.h:
+ (JSC::Heap::registerWeakGCMap):
+ (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
+ themselves with the Heap and provide a pruning callback.
+
+ * runtime/PrototypeMap.h:
+ (JSC::PrototypeMap::PrototypeMap):
+ * runtime/Structure.cpp:
+ (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
+
+ * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
+
+ * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
+
+ * runtime/VM.cpp:
+ (JSC::VM::VM): Pass VM to WeakGCMap constructor.
+
+ * runtime/WeakGCMap.h:
+ (JSC::WeakGCMap::set):
+ (JSC::WeakGCMap::add):
+ (JSC::WeakGCMap::WeakGCMap): Deleted.
+ (JSC::WeakGCMap::gcMap): Deleted.
+ (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
+ * runtime/WeakGCMapInlines.h: Added.
+ (JSC::WeakGCMap::WeakGCMap):
+ (JSC::WeakGCMap::~WeakGCMap):
+ (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
+ to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
+ prunes WeakGCMap at certain growth milestones and instead rely on the GC
+ callback for housekeeping.
+
+2015-03-03 Filip Pizlo <fpizlo@apple.com>
+
+ DFG IR should refer to FunctionExecutables directly and not via the CodeBlock
+ https://bugs.webkit.org/show_bug.cgi?id=142229
+
+ Reviewed by Mark Lam and Benjamin Poulain.
+
+ Anytime a DFG IR node refers to something in CodeBlock, it has three effects:
+
+ - Cumbersome API for accessing the thing that the node refers to.
+
+ - Not obvious how to create a new such node after bytecode parsing, especially if the
+ thing it refers to isn't already in the CodeBlock. We have done this in the past, but
+ it usually involves subtle changes to CodeBlock.
+
+ - Not obvious how to inline code that ends up using such nodes. Again, when we have done
+ this, it involved subtle changes to CodeBlock.
+
+ Prior to this change, the NewFunction* node types used an index into tables in CodeBlock.
+ For this reason, those operations were not inlineable. But the functin tables in CodeBlock
+ just point to FunctionExecutables, which are cells; this means that we can just abstract
+ these operands in DFG IR as cellOperands. cellOperands use DFG::FrozenValue, which means
+ that GC registration happens automagically. Even better, our dumping for cellOperand
+ already did FunctionExecutable dumping - so that functionality gets to be deduplicated.
+
+ Because this change increases the number of users of cellOperand, it also adds some
+ convenience methods for using it. For example, whereas before you'd say things like:
+
+ jsCast<Foo*>(node->cellOperand()->value())
+
+ you can now just say:
+
+ node->castOperand<Foo*>()
+
+ This change also changes existing cellOperand users to use the new conveniance API when
+ applicable.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::jettisonFunctionDeclsAndExprs):
+ * bytecode/CodeBlock.h:
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGFrozenValue.h:
+ (JSC::DFG::FrozenValue::cell):
+ (JSC::DFG::FrozenValue::dynamicCast):
+ (JSC::DFG::FrozenValue::cast):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::registerFrozenValues):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasCellOperand):
+ (JSC::DFG::Node::castOperand):
+ (JSC::DFG::Node::hasFunctionDeclIndex): Deleted.
+ (JSC::DFG::Node::functionDeclIndex): Deleted.
+ (JSC::DFG::Node::hasFunctionExprIndex): Deleted.
+ (JSC::DFG::Node::functionExprIndex): Deleted.
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
+ (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGWatchpointCollectionPhase.cpp:
+ (JSC::DFG::WatchpointCollectionPhase::handle):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileCheckCell):
+ (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
+
+2015-03-03 Michael Saboff <msaboff@apple.com>
+
+ DelayedReleaseScope drops locks during GC which can cause a thread switch and code reentry
+ https://bugs.webkit.org/show_bug.cgi?id=141275
+
+ Reviewed by Geoffrey Garen.
+
+ The original issue is that the CodeCache uses an unsafe method to add new UnlinkedCodeBlocks.
+ It basically adds a null UnlinkedCodeBlock if there isn't a cached entry and then later
+ updates the null entry to the result of the compilation. If during that compilation and
+ related processing we need to garbage collect, the DelayedReleaseScope would drop locks
+ possibly allowing another thread to try to get the same source out of the CodeCache.
+ This second thread would find the null entry and crash. The fix is to move the processing of
+ DelayedReleaseScope to when we drop locks and not drop locks during GC. That was done in
+ the original patch with the new function releaseDelayedReleasedObjects().
+
+ Updated releaseDelayedReleasedObjects() so that objects are released with all locks
+ dropped. Now its processing follows these steps
+ Increment recursion counter and do recursion check and exit if recursing
+ While there are objects to release
+ ASSERT that lock is held by current thread
+ Take all items from delayed release Vector and put into temporary Vector
+ Release API lock
+ Release and clear items from temporary vector
+ Reaquire API lock
+ This meets the requirement that we release while the API lock is released and it is
+ safer processing of the delayed release Vector.
+
+ Added new regression test to testapi.
+
+ Also added comment describing how recursion into releaseDelayedReleasedObjects() is
+ prevented.
+
+ * API/tests/Regress141275.h: Added.
+ * API/tests/Regress141275.mm: Added.
+ (+[JSTEvaluatorTask evaluatorTaskWithEvaluateBlock:completionHandler:]):
+ (-[JSTEvaluator init]):
+ (-[JSTEvaluator initWithScript:]):
+ (-[JSTEvaluator _accessPendingTasksWithBlock:]):
+ (-[JSTEvaluator insertSignPostWithCompletion:]):
+ (-[JSTEvaluator evaluateScript:completion:]):
+ (-[JSTEvaluator evaluateBlock:completion:]):
+ (-[JSTEvaluator waitForTasksDoneAndReportResults]):
+ (__JSTRunLoopSourceScheduleCallBack):
+ (__JSTRunLoopSourcePerformCallBack):
+ (__JSTRunLoopSourceCancelCallBack):
+ (-[JSTEvaluator _jsThreadMain]):
+ (-[JSTEvaluator _sourceScheduledOnRunLoop:]):
+ (-[JSTEvaluator _setupEvaluatorThreadContextIfNeeded]):
+ (-[JSTEvaluator _callCompletionHandler:ifNeededWithError:]):
+ (-[JSTEvaluator _sourcePerform]):
+ (-[JSTEvaluator _sourceCanceledOnRunLoop:]):
+ (runRegress141275):
+ * API/tests/testapi.mm:
+ (testObjectiveCAPI):
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * heap/Heap.cpp:
+ (JSC::Heap::releaseDelayedReleasedObjects):
+ * runtime/JSLock.cpp:
+ (JSC::JSLock::unlock):
+
+2015-03-03 Filip Pizlo <fpizlo@apple.com>
+
+ DFG should constant fold GetScope, and accesses to the scope register in the ByteCodeParser should not pretend that it's a constant as that breaks OSR exit liveness tracking
+ https://bugs.webkit.org/show_bug.cgi?id=106202
+
+ Rubber stamped by Benjamin Poulain.
+
+ This fixes a bug discovered by working on https://bugs.webkit.org/show_bug.cgi?id=142229,
+ which was in turn discovered by working on https://bugs.webkit.org/show_bug.cgi?id=141174.
+ Our way of dealing with scopes known to be constant is very sketchy, and only really works
+ when a function is inlined. When it is, we pretend that every load of the scopeRegister sees
+ a constant. But this breaks the DFG's tracking of the liveness of the scopeRegister. The way
+ this worked made us miss oppportunities for optimizing based on a constant scope, and it also
+ meant that in some cases - particularly like when we inline code that uses NewFuction and
+ friends, as I do in bug 142229 - it makes OSR exit think that the scope is dead even though
+ it's most definitely alive and it's a constant.
+
+ The problem here is that we were doing too many optimizations in the ByteCodeParser, and not
+ later. Later optimization phases know how to preserve OSR exit liveness. They're actually
+ really good at it. Also, later phases know how to infer that any variable is a constant no
+ matter how that constant arose - rather than the inlining-specific thing in ByteCodeParser.
+
+ This changes the ByteCodeParser to largely avoid doing constant folding on the scope, except
+ making the GetScope operation itself a constant. This is a compilation-time hack for small
+ functions, and it doesn't break the loads of local variables - so OSR exit liveness still
+ sees that the scopeRegister is in use. This then adds a vastly more powerful GetScope and
+ GetClosureVar constant folder in the AbstractInterpreter. This handles most general cases
+ including those that arise in complex control flow. This will catch cases where the scope
+ is constant for any number of reasons. Basically anytime that the callee is inferred constant
+ this will give us a constant scope. Also, we still have the parse-time constant folding of
+ ResolveScope based on the reentry watchpoint, which luckily did the right thing with respect
+ to OSR exit liveness (it splats a Phantom on its inputs, and it produces a constant result
+ which is then set() normally).
+
+ This appears to be a broad speed-up, albeit a small one. But mainly it unblocks bug 142229,
+ which then should unblock bug 141174.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::get):
+ (JSC::DFG::ByteCodeParser::getLocal):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::parse):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::tryGetConstantClosureVar):
+ (JSC::DFG::Graph::tryGetRegisters):
+ (JSC::DFG::Graph::tryGetActivation): Deleted.
+ * dfg/DFGGraph.h:
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasVariableWatchpointSet):
+ (JSC::DFG::Node::hasSymbolTable): Deleted.
+ (JSC::DFG::Node::symbolTable): Deleted.
+ * 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::compileGetClosureVar):
+ * runtime/SymbolTable.cpp:
+ (JSC::SymbolTable::visitChildren):
+ (JSC::SymbolTable::localToEntry):
+ (JSC::SymbolTable::entryFor):
+ * runtime/SymbolTable.h:
+ (JSC::SymbolTable::add):
+ (JSC::SymbolTable::set):
+ * tests/stress/function-expression-exit.js: Added.
+ * tests/stress/function-reentry-infer-on-self.js: Added.
+ (thingy):
+ * tests/stress/goofy-function-reentry-incorrect-inference.js: Added.
+
+2015-03-03 Anders Carlsson <andersca@apple.com>
+
+ Remove unused compression code
+ https://bugs.webkit.org/show_bug.cgi?id=142237
+
+ Reviewed by Geoffrey Garen.
+
+ * bytecode/UnlinkedCodeBlock.h:
+
+2015-03-03 Filip Pizlo <fpizlo@apple.com>
+
+ JIT debugging features that selectively disable the JITs for code blocks need to stay out of the way of the critical path of JIT management
+ https://bugs.webkit.org/show_bug.cgi?id=142234
+
+ Reviewed by Mark Lam and Benjamin Poulain.
+
+ Long ago, we used to selectively disable compilation of CodeBlocks for debugging purposes by
+ adding hacks to DFGDriver.cpp. This was all well and good. It used the existing
+ CompilationFailed mode of the DFG driver to signal failure of CodeBlocks that we didn't want
+ to compile. That's great because CompilationFailed is a well-supported return value on the
+ critical path, usually used for when we run out of JIT memory.
+
+ Later, this was moved into DFGCapabilities. This was basically incorrect. It introduced a bug
+ where disabling compiling of a CodeBlock meant that we stopped inlining it as well. So if
+ you had a compiler bug that arose if foo was inlined into bar, and you bisected down to bar,
+ then foo would no longer get inlined and you wouldn't see the bug. That's busted.
+
+ So then we changed the code in DFGCapabilities to mark bar as CanCompile and foo as
+ CanInline. Now, foo wouldn't get compiled alone but it would get inlined.
+
+ But then we removed CanCompile because that capability mode only existed for the purpose of
+ our old varargs hacks. After that removal, "CanInline" became CannotCompile. This means
+ that if you bisect down on bar in the "foo inlined into bar" case, you'll crash in the DFG
+ because the baseline JIT wouldn't have known to insert profiling on foo.
+
+ We could fix this by bringing back CanInline.
+
+ But this is all a pile of nonsense. The debug support to selectively disable compilation of
+ some CodeBlocks shouldn't cross-cut our entire engine and should most certainly never involve
+ adding new capability modes. This support is a hack at best and is for use by JSC hackers
+ only. It should be as unintrusive as possible.
+
+ So, as in the ancient times, the only proper place to put this hack is in DFGDriver.cpp, and
+ return CompilationFailed. This is correct not just because it takes capability modes out of
+ the picture (and obviates the need to introduce new ones), but also because it means that
+ disabling compilation doesn't change the profiling mode of other CodeBlocks in the Baseline
+ JIT. Capability mode influences profiling mode which in turn influences code generation in
+ the Baseline JIT, sometimes in very significant ways - like, we sometimes do additional
+ double-to-int conversions in Baseline if we know that we might tier-up into the DFG, since
+ this buys us more precise profiling.
+
+ This change reduces the intrusiveness of debugging hacks by making them use the very simple
+ CompilationFailed mechanism rather than trying to influence capability modes. Capability
+ modes have very subtle effects on the whole engine, while CompilationFailed just makes the
+ engine pretend like the DFG compilation will happen at timelike infinity. That makes these
+ hacks much more likely to continue working as we make other changes to the system.
+
+ This brings back the ability to bisect down onto a function bar when bar inlines foo. Prior
+ to this change, we would crash in that case.
+
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::isSupported):
+ (JSC::DFG::mightCompileEval):
+ (JSC::DFG::mightCompileProgram):
+ (JSC::DFG::mightCompileFunctionForCall):
+ (JSC::DFG::mightCompileFunctionForConstruct):
+ * dfg/DFGCapabilities.h:
+ * dfg/DFGDriver.cpp:
+ (JSC::DFG::compileImpl):
+
+2015-03-03 peavo@outlook.com <peavo@outlook.com>
+
+ [Win64] JSC compile error.
+ https://bugs.webkit.org/show_bug.cgi?id=142216
+
+ Reviewed by Mark Lam.
+
+ There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+
+2015-03-02 Filip Pizlo <fpizlo@apple.com>
+
+ DFG compile time measurements should really report milliseconds
+ https://bugs.webkit.org/show_bug.cgi?id=142209
+
+ Reviewed by Benjamin Poulain.
+
+ Fix this to record milliseconds instead of seconds.
+
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThread):
+ (JSC::DFG::Plan::compileInThreadImpl):
+
+2015-03-02 Filip Pizlo <fpizlo@apple.com>
+
+ Remove op_get_callee, it's unused
+ https://bugs.webkit.org/show_bug.cgi?id=142206
+
+ Reviewed by Andreas Kling.
+
+ It's a bit of a shame that we stopped using this opcode since it gives us same-callee
+ profiling. But, if we were to add this functionality back in, we would almost certainly do
+ it by adding a JSFunction allocation watchpoint on FunctionExecutable.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ (JSC::CodeBlock::finalizeUnconditionally):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ (JSC::JIT::privateCompileSlowCases):
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_get_callee): Deleted.
+ (JSC::JIT::emitSlow_op_get_callee): Deleted.
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_get_callee): Deleted.
+ (JSC::JIT::emitSlow_op_get_callee): Deleted.
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL): Deleted.
+
+2015-03-02 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Context Menu to Log a Particular Object
+ https://bugs.webkit.org/show_bug.cgi?id=142198
+
+ Reviewed by Timothy Hatcher.
+
+ Add a protocol method to assign a $n index to a value. For an object
+ use the injected script context for that object. For a value, use
+ the execution context to know where to save the value.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::saveResult):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptSource.js:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::saveResult):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/protocol/Debugger.json:
+ * inspector/protocol/Runtime.json:
+
+2015-03-02 Filip Pizlo <fpizlo@apple.com>
+
+ SpeculativeJIT::emitAllocateArguments() should be a bit faster, and shouldn't do destructor initialization
+ https://bugs.webkit.org/show_bug.cgi?id=142197
+
+ Reviewed by Geoffrey Garen.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Use shift instead of mul, since mul doesn't automatically strength-reduce to shift. Also pass the structure as a TrustedImmPtr.
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): Rationalize this a bit. The other emitAllocate... methods take a templated structure so that it can be either a TrustedImmPtr or a register. Also don't do destructor initialization, since its one client doesn't need it, and it's actually probably wrong.
+
+2015-03-02 Mark Lam <mark.lam@apple.com>
+
+ Exception stack unwinding in JSC hangs while the Timeline Profiler is enabled.
+ <https://webkit.org/b/142191>
+
+ Reviewed by Geoffrey Garen.
+
+ Imagine a scenario where the Inspector is paused / suspended at a breakpoint or
+ while the user is stepping through JS code. The user then tries to evaluate an
+ expression in the console, and that evaluation results in an exception being
+ thrown. Currently, if the Timeline Profiler is enabled while this exception is
+ being thrown, the WebProcess will hang while trying to handle that exception.
+
+ The issue is that the Timeline Profiler's ProfileGenerator::didExecute() will
+ return early and decline to process ProfileNodes if the Inspector is paused.
+ This is proper because it does not want to count work done for injected scripts
+ (e.g. from the console) towards the timeline profile of the webpage being run.
+ However, this is in conflict with ProfileGenerator::exceptionUnwind()'s
+ expectation that didExecute() will process ProfileNodes in order to do the stack
+ unwinding for the exception handling. As a result,
+ ProfileGenerator::exceptionUnwind() hangs.
+
+ ProfileGenerator::exceptionUnwind() is in error. While the Inspector is paused,
+ there will not be any ProfileNodes that it needs to "unwind". Hence, the fix is
+ simply to return early also in ProfileGenerator::exceptionUnwind() if the
+ Inspector is paused.
+
+ * profiler/ProfileGenerator.cpp:
+ (JSC::ProfileGenerator::exceptionUnwind):
+
+2015-03-02 Filip Pizlo <fpizlo@apple.com>
+
+ FTL should correctly document where it puts the argument count for inlined varargs frames
+ https://bugs.webkit.org/show_bug.cgi?id=142187
+
+ Reviewed by Geoffrey Garn.
+
+ After LLVM tells us where the captured variables alloca landed in the frame, we need to
+ tell all of our meta-data about it. We were forgetting to do so for the argument count
+ register, which is used by inlined varargs calls.
+
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * tests/stress/inline-varargs-get-arguments.js: Added.
+ (foo):
+ (bar):
+ (baz):
+
+2015-03-02 Filip Pizlo <fpizlo@apple.com>
+
+ Deduplicate slow path calling code in JITOpcodes.cpp/JITOpcodes32_64.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=142184
+
+ Reviewed by Michael Saboff.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_get_enumerable_length):
+ (JSC::JIT::emitSlow_op_has_structure_property):
+ (JSC::JIT::emit_op_has_generic_property):
+ (JSC::JIT::emit_op_get_structure_property_enumerator):
+ (JSC::JIT::emit_op_get_generic_property_enumerator):
+ (JSC::JIT::emit_op_to_index_string):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_get_enumerable_length): Deleted.
+ (JSC::JIT::emitSlow_op_has_structure_property): Deleted.
+ (JSC::JIT::emit_op_has_generic_property): Deleted.
+ (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
+ (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
+ (JSC::JIT::emit_op_to_index_string): Deleted.
+ (JSC::JIT::emit_op_profile_control_flow): Deleted.
+
+2015-03-02 Antti Koivisto <antti@apple.com>
+
+ Add way to dump cache meta data to file
+ https://bugs.webkit.org/show_bug.cgi?id=142183
+
+ Reviewed by Andreas Kling.
+
+ Export appendQuotedJSONStringToBuilder.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ObjectPatternNode::toString):
+ * runtime/JSONObject.cpp:
+ (JSC::appendQuotedJSONStringToBuilder):
+ (JSC::Stringifier::appendQuotedString):
+ (JSC::escapeStringToBuilder): Deleted.
+ * runtime/JSONObject.h:
+
+2015-03-02 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Add Context Menus to Object Tree properties
+ https://bugs.webkit.org/show_bug.cgi?id=142125
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::functionDetails):
+ Update to include columnNumber.
+
+2015-03-01 Filip Pizlo <fpizlo@apple.com>
+
+ BytecodeGenerator shouldn't emit op_resolve_scope as a roundabout way of returning the scopeRegister
+ https://bugs.webkit.org/show_bug.cgi?id=142153
+
+ Reviewed by Michael Saboff.
+
+ We don't need a op_resolve_scope if we know that it will simply return the scope register.
+ This changes the BytecodeGenerator to use the scope register directly in those cases where
+ we know statically that we would just have returned that from op_resolve_scope.
+
+ This doesn't appear to have a significant impact on performance.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitResolveScope):
+ (JSC::BytecodeGenerator::emitReturn):
+ (JSC::BytecodeGenerator::emitGetOwnScope): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ResolveNode::emitBytecode):
+ (JSC::EvalFunctionCallNode::emitBytecode):
+ (JSC::FunctionCallResolveNode::emitBytecode):
+ (JSC::PostfixNode::emitResolve):
+ (JSC::DeleteResolveNode::emitBytecode):
+ (JSC::TypeOfResolveNode::emitBytecode):
+ (JSC::PrefixNode::emitResolve):
+ (JSC::ReadModifyResolveNode::emitBytecode):
+ (JSC::AssignResolveNode::emitBytecode):
+ (JSC::ConstDeclNode::emitCodeSingle):
+ (JSC::EmptyVarExpression::emitBytecode):
+ (JSC::ForInNode::emitLoopHeader):
+ (JSC::ForOfNode::emitBytecode):
+ (JSC::BindingNode::bindValue):
+
+2015-02-27 Benjamin Poulain <bpoulain@apple.com>
+
+ [JSC] Use the way number constants are written to help type speculation
+ https://bugs.webkit.org/show_bug.cgi?id=142072
+
+ Reviewed by Filip Pizlo.
+
+ This patch changes how we interpret numeric constant based on how they appear
+ in the source.
+
+ Constants that are integers but written with a decimal point now carry that information
+ to the optimizating tiers. From there, we use that to be more aggressive about typing
+ math operations toward double operations.
+
+ For example, in:
+ var a = x + 1.0;
+ var b = y + 1;
+ The Add for a would be biased toward doubles, the Add for b would speculate
+ integer as usual.
+
+
+ The gains are tiny but this is a prerequisite to make my next patch useful:
+ -SunSpider's access-fannkuch: definitely 1.0661x faster
+ -SunSpider's math-cordic: definitely 1.0266x slower
+ overal: might be 1.0066x slower.
+ -Kraken's imaging-darkroom: definitely 1.0333x faster.
+
+ * parser/Lexer.cpp:
+ (JSC::tokenTypeForIntegerLikeToken):
+ (JSC::Lexer<T>::lex):
+ The lexer now create two types of tokens for number: INTEGER and DOUBLE.
+ Those token types only carry information about how the values were
+ entered, an INTEGER does not have to be an integer, it is only written like one.
+ Large integer still end up represented as double in memory.
+
+ One trap I fell into was typing numbers like 12e3 as double. This kind of literal
+ is frequently used in integer-typed code, while 12.e3 would appear in double-typed
+ code.
+ Because of that, the only signals for double are: decimal point, negative zero,
+ and ridiculously large values.
+
+ * parser/NodeConstructors.h:
+ (JSC::DoubleNode::DoubleNode):
+ (JSC::IntegerNode::IntegerNode):
+ * parser/Nodes.h:
+ (JSC::NumberNode::value):
+ (JSC::NumberNode::setValue): Deleted.
+ Number get specialized in two new kind of nodes in the AST: IntegerNode and DoubleNode.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::NumberNode::emitBytecode):
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createDoubleExpr):
+ (JSC::ASTBuilder::createIntegerExpr):
+ (JSC::ASTBuilder::createIntegerLikeNumber):
+ (JSC::ASTBuilder::createDoubleLikeNumber):
+ (JSC::ASTBuilder::createNumberFromBinaryOperation):
+ (JSC::ASTBuilder::createNumberFromUnaryOperation):
+ (JSC::ASTBuilder::makeNegateNode):
+ (JSC::ASTBuilder::makeBitwiseNotNode):
+ (JSC::ASTBuilder::makeMultNode):
+ (JSC::ASTBuilder::makeDivNode):
+ (JSC::ASTBuilder::makeModNode):
+ (JSC::ASTBuilder::makeAddNode):
+ (JSC::ASTBuilder::makeSubNode):
+ (JSC::ASTBuilder::makeLeftShiftNode):
+ (JSC::ASTBuilder::makeRightShiftNode):
+ (JSC::ASTBuilder::makeURightShiftNode):
+ (JSC::ASTBuilder::makeBitOrNode):
+ (JSC::ASTBuilder::makeBitAndNode):
+ (JSC::ASTBuilder::makeBitXOrNode):
+ (JSC::ASTBuilder::createNumberExpr): Deleted.
+ (JSC::ASTBuilder::createNumber): Deleted.
+ The AST has some optimization to resolve constants before emitting bytecode.
+ In the new code, the intger representation is kept if both operands where
+ also represented as integers.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseDeconstructionPattern):
+ (JSC::Parser<LexerType>::parseProperty):
+ (JSC::Parser<LexerType>::parseGetterSetter):
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ (JSC::Parser<LexerType>::printUnexpectedTokenText):
+ * parser/ParserTokens.h:
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createDoubleExpr):
+ (JSC::SyntaxChecker::createIntegerExpr):
+ (JSC::SyntaxChecker::createNumberExpr): Deleted.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::registerName):
+ (JSC::CodeBlock::constantName):
+ Change constantName(r, getConstant(r)) -> constantName(r) to simplify
+ the dump code.
+
+ (JSC::CodeBlock::dumpBytecode):
+ Dump thre soure representation information we have with each constant.
+
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::shrinkToFit):
+ (JSC::constantName): Deleted.
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::constantsSourceCodeRepresentation):
+ (JSC::CodeBlock::addConstant):
+ (JSC::CodeBlock::addConstantLazily):
+ (JSC::CodeBlock::constantSourceCodeRepresentation):
+ (JSC::CodeBlock::setConstantRegisters):
+
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::addConstant):
+ (JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
+ (JSC::UnlinkedCodeBlock::shrinkToFit):
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::addConstantValue):
+ (JSC::BytecodeGenerator::emitLoad):
+ * bytecompiler/BytecodeGenerator.h:
+ We have to differentiate between constants that have the same values but are
+ represented differently in the source. Values like 1.0 and 1 now end up
+ as different constants.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::get):
+ (JSC::DFG::ByteCodeParser::addConstantToGraph):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::registerFrozenValues):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::addSpeculationMode):
+ (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
+ ArithAdd is very aggressive toward using Int52, which is quite useful
+ in many benchmarks.
+
+ Here we need to specialize to make sure we don't force our literals
+ to Int52 if there were represented as double.
+
+ There is one exception to that rule: when the other operand is guaranteed
+ to come from a NodeResultInt32. This is because there is some weird code
+ doing stuff like:
+ var b = a|0;
+ var c = b*2.0;
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::Node):
+ (JSC::DFG::Node::setOpAndDefaultFlags):
+ (JSC::DFG::Node::sourceCodeRepresentation):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * runtime/JSCJSValue.h:
+ (JSC::EncodedJSValueWithRepresentationHashTraits::emptyValue):
+ (JSC::EncodedJSValueWithRepresentationHashTraits::constructDeletedValue):
+ (JSC::EncodedJSValueWithRepresentationHashTraits::isDeletedValue):
+ (JSC::EncodedJSValueWithRepresentationHash::hash):
+ (JSC::EncodedJSValueWithRepresentationHash::equal):
+ * tests/stress/arith-add-with-constants.js: Added.
+ * tests/stress/arith-mul-with-constants.js: Added.
+
+2015-02-26 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, roll out r180723. It broke a bunch of tests.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::constLocal):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ConstDeclNode::emitCodeSingle):
+ * tests/stress/const-arguments.js: Removed.
+
+2015-02-26 Mark Lam <mark.lam@apple.com>
+
+ Assertion fix for r180711: The bool returning form of BytecodeGenerator::addVar() can be removed.
+ <https://webkit.org/b/142064>
+
+ Reviewed by Joseph Pecoraro.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::addVar):
+
+2015-02-26 Mark Lam <mark.lam@apple.com>
+
+ MachineThreads::Thread clean up has a use after free race condition.
+ <https://webkit.org/b/141990>
+
+ Reviewed by Filip Pizlo.
+
+ MachineThreads::Thread clean up relies on the clean up mechanism
+ implemented in _pthread_tsd_cleanup_key(), which looks like this:
+
+ void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
+ {
+ void (*destructor)(void *);
+ if (_pthread_key_get_destructor(key, &destructor)) {
+ void **ptr = &self->tsd[key];
+ void *value = *ptr;
+
+ // === Start of window for the bug to manifest =================
+
+ // At this point, this thread has cached "destructor" and "value"
+ // (which is a MachineThreads*). If the VM gets destructed (along
+ // with its MachineThreads registry) by another thread, then this
+ // thread will have no way of knowing that the MachineThreads* is
+ // now pointing to freed memory. Calling the destructor below will
+ // therefore result in a use after free scenario when it tries to
+ // access the MachineThreads' data members.
+
+ if (value) {
+ *ptr = NULL;
+ if (destructor) {
+
+ // === End of window for the bug to manifest ==================
+
+ destructor(value);
+ }
+ }
+ }
+ }
+
+ The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
+ and always check if the manager still contains that MachineThreads object
+ before we call removeCurrentThread() on it. When MachineThreads is destructed,
+ it will remove itself from the manager. The add, remove, and checking
+ operations are all synchronized on the manager's lock, thereby ensuring that
+ the MachineThreads object, if found in the manager, will remain alive for the
+ duration of time we call removeCurrentThread() on it.
+
+ There's also possible for the MachineThreads object to already be destructed
+ and another one happened to have been instantiated at the same address.
+ Hence, we should only remove the exiting thread if it is found in the
+ MachineThreads object.
+
+ There is no test for this issue because this bug requires a race condition
+ between 2 threads where:
+ 1. Thread B, which had previously used the VM, exiting and
+ getting to the bug window shown in _pthread_tsd_cleanup_key() above.
+ 2. Thread A destructing the VM (and its MachineThreads object)
+ within that window of time before Thread B calls the destructor.
+
+ It is not possible to get a reliable test case without invasively
+ instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
+ to significantly increase that window of opportunity.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::ActiveMachineThreadsManager::Locker::Locker):
+ (JSC::ActiveMachineThreadsManager::add):
+ (JSC::ActiveMachineThreadsManager::remove):
+ (JSC::ActiveMachineThreadsManager::contains):
+ (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
+ (JSC::activeMachineThreadsManager):
+ (JSC::MachineThreads::MachineThreads):
+ (JSC::MachineThreads::~MachineThreads):
+ (JSC::MachineThreads::removeThread):
+ (JSC::MachineThreads::removeThreadIfFound):
+ (JSC::MachineThreads::removeCurrentThread): Deleted.
+ * heap/MachineStackMarker.h:
+
+2015-02-26 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Save Console Evaluations into Command Line variables $1-$99 ($n)
+ https://bugs.webkit.org/show_bug.cgi?id=142061
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Debugger.json:
+ * inspector/protocol/Runtime.json:
+ Input flag "saveResult" on whether we should try to save a result.
+ Output int "savedResultIndex" to tell the frontend the saved state.
+
+ * inspector/InjectedScriptSource.js:
+ Handle saving and clearing $1-$99 values.
+ Include in BasicCommandLineAPI for JSContext inspection.
+
+ * inspector/InjectedScriptBase.cpp:
+ (Inspector::InjectedScriptBase::makeEvalCall):
+ * inspector/InjectedScriptBase.h:
+ Allow an optional "savedResultIndex" out value on evals.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::evaluate):
+ (Inspector::InjectedScript::evaluateOnCallFrame):
+ * inspector/InjectedScript.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::evaluate):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ Plumbing for new in and out parameters.
+
+2015-02-26 Filip Pizlo <fpizlo@apple.com>
+
+ The bool returning form of BytecodeGenerator::addVar() can be removed
+ https://bugs.webkit.org/show_bug.cgi?id=142064
+
+ Reviewed by Mark Lam.
+
+ It's easier to implement addVar() when you don't have to return whether it's a new
+ variable or not.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::addVar):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::addVar): Deleted.
+
+2015-02-26 Filip Pizlo <fpizlo@apple.com>
+
+ Various array access corner cases should take OSR exit feedback
+ https://bugs.webkit.org/show_bug.cgi?id=142056
+
+ Reviewed by Geoffrey Garen.
+
+ Two major changes here:
+
+ - Don't keep converting GetById into GetArrayLength if we exited due to any kind of array
+ type check.
+
+ - Use a generic form of GetByVal/PutByVal if we exited due to any kind of exotic checks,
+ like the Arguments safety checks. We use the "ExoticObjectMode" for out-of-bounds on
+ arguments for now, since it's a convenient way of forcing out-of-bounds to be handled by
+ the Generic array mode.
+
+ * bytecode/ExitKind.cpp:
+ (JSC::exitKindToString):
+ * bytecode/ExitKind.h:
+ * dfg/DFGArrayMode.cpp:
+ (JSC::DFG::ArrayMode::refine):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
+ (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
+ * tests/stress/array-length-array-storage-plain-object.js: Added.
+ (foo):
+ * tests/stress/array-length-plain-object.js: Added.
+ (foo):
+
+2015-02-25 Filip Pizlo <fpizlo@apple.com>
+
+ DFG SSA stack accesses shouldn't speak of VariableAccessDatas
+ https://bugs.webkit.org/show_bug.cgi?id=142036
+
+ Reviewed by Michael Saboff.
+
+ VariableAccessData is a useful thing in LoadStore and ThreadedCPS, but it's purely harmful in
+ SSA because you can't cook up new VariableAccessDatas. So, if you know that you want to load
+ or store to the stack, and you know what format to use as well as the location, then prior to
+ this patch you couldn't do it unless you found some existing VariableAccessData that matched
+ your requirements. That can be a hard task.
+
+ It's better if SSA doesn't speak of VariableAccessDatas but instead just has stack accesses
+ that speak of the things that a stack access needs: local, machineLocal, and format. This
+ patch changes the SSA way of accessing the stack to do just that.
+
+ Also add more IR validation.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGFlushFormat.h:
+ (JSC::DFG::isConcrete):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ * dfg/DFGGraph.h:
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::hasVariableAccessData):
+ * dfg/DFGNode.h:
+ (JSC::DFG::StackAccessData::StackAccessData):
+ (JSC::DFG::StackAccessData::flushedAt):
+ (JSC::DFG::Node::convertToPutStack):
+ (JSC::DFG::Node::convertToGetStack):
+ (JSC::DFG::Node::hasUnlinkedLocal):
+ (JSC::DFG::Node::hasStackAccessData):
+ (JSC::DFG::Node::stackAccessData):
+ (JSC::DFG::Node::willHaveCodeGenOrOSR):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+ (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGPutLocalSinkingPhase.cpp: Removed.
+ * dfg/DFGPutLocalSinkingPhase.h: Removed.
+ * dfg/DFGPutStackSinkingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.cpp.
+ (JSC::DFG::performPutStackSinking):
+ (JSC::DFG::performPutLocalSinking): Deleted.
+ * dfg/DFGPutStackSinkingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.h.
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validate):
+ (JSC::DFG::Validate::validateCPS):
+ (JSC::DFG::Validate::validateSSA):
+ * dfg/DFGVirtualRegisterAllocationPhase.cpp:
+ (JSC::DFG::VirtualRegisterAllocationPhase::run):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileGetStack):
+ (JSC::FTL::LowerDFGToLLVM::compilePutStack):
+ (JSC::FTL::LowerDFGToLLVM::compileGetLocal): Deleted.
+ (JSC::FTL::LowerDFGToLLVM::compilePutLocal): Deleted.
+ * ftl/FTLOSRExit.h:
+ * tests/stress/many-sunken-locals.js: Added. This failure mode was caught by some miscellaneous test, so I figured I should write an explicit test for it.
+ (foo):
+ (bar):
+ (baz):
+ (fuzz):
+ (buzz):
+
+2015-02-26 Mark Lam <mark.lam@apple.com>
+
+ Rolling out r180602, r180608, r180613, r180617, r180671.
+ <https://webkit.org/b/141990>
+
+ Not reviewed.
+
+ The r180602 solution does result in more work for GC when worker
+ threads are in use. Filip is uncomfortable with that.
+ The EFL and GTK ports also seem to be unhappy with this change.
+ Rolling out while we investigate.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::gatherStackRoots):
+ (JSC::Heap::machineThreads): Deleted.
+ * heap/Heap.h:
+ (JSC::Heap::machineThreads):
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::MachineThreads):
+ (JSC::MachineThreads::~MachineThreads):
+ (JSC::MachineThreads::addCurrentThread):
+ * heap/MachineStackMarker.h:
+ * runtime/JSLock.cpp:
+ (JSC::JSLock::didAcquireLock):
+
+2015-02-26 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [Mac] [iOS] Parsing support for -apple-trailing-word
+ https://bugs.webkit.org/show_bug.cgi?id=141939
+
+ Reviewed by Andreas Kling.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-02-26 Michael Saboff <msaboff@apple.com>
+
+ [Win] Debug-only JavaScriptCore failures
+ https://bugs.webkit.org/show_bug.cgi?id=142045
+
+ Rubber stamped by Filip Pizlo.
+
+ Reduced loop count to a more reasonable value of 10,000. This still gets us to tier up
+ to the FTL, but doesn't take too long to run.
+
+ * tests/stress/repeated-arity-check-fail.js:
+
+2015-02-26 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Make build logs more legible by reducing noise
+ https://bugs.webkit.org/show_bug.cgi?id=142034
+
+ Reviewed by Alexey Proskuryakov.
+
+ Modify batch files, makefiles, and DOS commands to remove
+ uninteresting/unhelpful output.
+
+ * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
+ * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:
+ * JavaScriptCore.vcxproj/copy-files.cmd:
+ * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd:
+ * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:
+ * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd:
+ * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:
+ * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd:
+ * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd:
+ * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd:
+ * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:
+
+2015-02-26 Csaba Osztrogonác <ossy@webkit.org>
+
+ Add calleeSaveRegisters() implementation for ARM Traditional
+ https://bugs.webkit.org/show_bug.cgi?id=141903
+
+ Reviewed by Darin Adler.
+
+ * jit/RegisterSet.cpp:
+ (JSC::RegisterSet::calleeSaveRegisters):
+
+2015-02-25 Michael Saboff <msaboff@apple.com>
+
+ Web Inspector: CRASH when debugger pauses inside a Promise handler
+ https://bugs.webkit.org/show_bug.cgi?id=141396
+
+ Reviewed by Mark Lam.
+
+ For frames that don't have a scope, typically native frames, use the lexicalGlobalObject to
+ create the DebuggerScope for that frame.
+
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::scope):
+
+2015-02-25 Filip Pizlo <fpizlo@apple.com>
+
+ DFG abstract heaps should respect the difference between heap and stack
+ https://bugs.webkit.org/show_bug.cgi?id=142022
+
+ Reviewed by Geoffrey Garen.
+
+ We will soon (https://bugs.webkit.org/show_bug.cgi?id=141174) be in a world where a "world
+ clobbering" operation cannot write to our stack, but may be able to read from it. This
+ means that we need to change the DFG abstract heap hierarchy to have a notion of Heap that
+ subsumes all that World previously subsumed, and a new notion of Stack that is a subtype
+ of World and a sibling of Heap.
+
+ So, henceforth "clobbering the world" means reading World and writing Heap.
+
+ This makes a bunch of changes to make this work, including changing the implementation of
+ disjointness in AbstractHeap to make it support a more general hierarchy. I was expecting
+ a slow-down, but I measured the heck out of this and found no perf difference.
+
+ * dfg/DFGAbstractHeap.cpp:
+ (JSC::DFG::AbstractHeap::dump):
+ * dfg/DFGAbstractHeap.h:
+ (JSC::DFG::AbstractHeap::supertype):
+ (JSC::DFG::AbstractHeap::isStrictSubtypeOf):
+ (JSC::DFG::AbstractHeap::isSubtypeOf):
+ (JSC::DFG::AbstractHeap::overlaps):
+ (JSC::DFG::AbstractHeap::isDisjoint):
+ * dfg/DFGClobberize.cpp:
+ (JSC::DFG::clobbersHeap):
+ (JSC::DFG::clobbersWorld): Deleted.
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+
+2015-02-25 Ryosuke Niwa <rniwa@webkit.org>
+
+ REGRESSION(r180595): construct varargs fails in FTL
+ https://bugs.webkit.org/show_bug.cgi?id=142030
+
+ Reviewed by Geoffrey Garen.
+
+ The bug was caused by IC size being too small for construct_varargs even though we've added a new argument.
+ Fixed the bug by increasing the IC size to match call_varargs.
+
+ * ftl/FTLInlineCacheSize.cpp:
+ (JSC::FTL::sizeOfConstructVarargs):
+
+2015-02-25 Mark Lam <mark.lam@apple.com>
+
+ ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
+ <https://webkit.org/b/141672>
+
+ Reviewed by Alexey Proskuryakov.
+
+ ASan does not like the fact that we memcpy the stack for GC scans. So,
+ we're working around this by using our own memcpy (asanUnsafeMemcpy)
+ implementation that we can tell ASan to ignore.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::asanUnsafeMemcpy):
+
+2015-02-25 Benjamin Poulain <bpoulain@apple.com>
+
+ CodeBlock crashes when dumping op_push_name_scope
+ https://bugs.webkit.org/show_bug.cgi?id=141953
+
+ Reviewed by Filip Pizlo and Csaba Osztrogonác.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * tests/stress/op-push-name-scope-crashes-profiler.js: Added.
+
+2015-02-25 Benjamin Poulain <benjamin@webkit.org>
+
+ Make ParserError immutable by design
+ https://bugs.webkit.org/show_bug.cgi?id=141955
+
+ Reviewed by Geoffrey Garen.
+
+ This patch enforce that no field of ParserError can
+ be modified after the constructor.
+
+ * parser/ParserError.h:
+ Move the attributes to pack the integer + 2 bytes together.
+ This is irrelevant for memory impact, it is to remve a load-store
+ when copying by value.
+
+ Also move the attributes to be private.
+
+ (JSC::ParserError::isValid):
+ To client of the interface cared about the type of the error,
+ the only information needed was: is there an error.
+
+ (JSC::ParserError::ParserError):
+ (JSC::ParserError::syntaxErrorType):
+ (JSC::ParserError::token):
+ (JSC::ParserError::message):
+ (JSC::ParserError::line):
+ (JSC::ParserError::toErrorObject):
+ * API/JSScriptRef.cpp:
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createBuiltinExecutable):
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock):
+ (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
+ (JSC::UnlinkedFunctionExecutable::codeBlockFor):
+ * bytecode/UnlinkedCodeBlock.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::parse):
+ * jsc.cpp:
+ (runInteractive):
+ * parser/Parser.h:
+ (JSC::parse):
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
+ * runtime/CodeCache.h:
+ * runtime/Completion.h:
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::checkSyntax):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::createProgramCodeBlock):
+ (JSC::JSGlobalObject::createEvalCodeBlock):
+
+2015-02-25 Filip Pizlo <fpizlo@apple.com>
+
+ Need to pass RTLD_DEEPBIND to dlopen() to ensure that our LLVMOverrides take effect on Linux
+ https://bugs.webkit.org/show_bug.cgi?id=142006
+
+ Reviewed by Csaba Osztrogonác.
+
+ This fixes hard-to-reproduce concurrency-related crashes when running stress tests with FTL and
+ concurrent JIT enabled.
+
+ * llvm/InitializeLLVMPOSIX.cpp:
+ (JSC::initializeLLVMPOSIX):
+
+2015-02-24 Filip Pizlo <fpizlo@apple.com>
+
+ CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
+ https://bugs.webkit.org/show_bug.cgi?id=141989
+
+ Reviewed by Gyuyoung Kim.
+
+ * CMakeLists.txt:
+ * llvm/library/libllvmForJSC.version: Added.
+
+2015-02-24 Alexey Proskuryakov <ap@apple.com>
+
+ More iOS build fix after r180602.
+
+ * heap/Heap.h: Export Heap::machineThreads().
+
+2015-02-24 Brent Fulgham <bfulgham@apple.com>
+
+ Unreviewed build fix after r180602.
+
+ * heap/MachineStackMarker.h: Add missing 'no return'
+ declaration for Windows.
+
+2015-02-24 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r180599.
+ https://bugs.webkit.org/show_bug.cgi?id=141998
+
+ Lots of new test failures (Requested by smfr on #webkit).
+
+ Reverted changeset:
+
+ "Parsing support for -webkit-trailing-word"
+ https://bugs.webkit.org/show_bug.cgi?id=141939
+ http://trac.webkit.org/changeset/180599
+
+2015-02-24 Mark Lam <mark.lam@apple.com>
+
+ MachineThreads::Thread clean up has a use after free race condition.
+ <https://webkit.org/b/141990>
+
+ Reviewed by Michael Saboff.
+
+ MachineThreads::Thread clean up relies on the clean up mechanism
+ implemented in _pthread_tsd_cleanup_key(), which looks like this:
+
+ void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
+ {
+ void (*destructor)(void *);
+ if (_pthread_key_get_destructor(key, &destructor)) {
+ void **ptr = &self->tsd[key];
+ void *value = *ptr;
+
+ // At this point, this thread has cached "destructor" and "value"
+ // (which is a MachineThreads*). If the VM gets destructed (along
+ // with its MachineThreads registry) by another thread, then this
+ // thread will have no way of knowing that the MachineThreads* is
+ // now pointing to freed memory. Calling the destructor below will
+ // therefore result in a use after free scenario when it tries to
+ // access the MachineThreads' data members.
+
+ if (value) {
+ *ptr = NULL;
+ if (destructor) {
+ destructor(value);
+ }
+ }
+ }
+ }
+
+ The solution is simply to change MachineThreads from a per VM thread
+ registry to a process global singleton thread registry i.e. the
+ MachineThreads registry is now immortal and we cannot have a use after
+ free scenario since we never free it.
+
+ The cost of this change is that all VM instances will have to scan
+ stacks of all threads ever touched by a VM, and not just those that
+ touched a specific VM. However, stacks tend to be shallow. Hence,
+ those additional scans will tend to be cheap.
+
+ Secondly, it is not common for there to be multiple JSC VMs in use
+ concurrently on multiple threads. Hence, this cost should rarely
+ manifest in real world applications.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::machineThreads):
+ (JSC::Heap::gatherStackRoots):
+ * heap/Heap.h:
+ (JSC::Heap::machineThreads): Deleted.
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::MachineThreads):
+ (JSC::MachineThreads::~MachineThreads):
+ (JSC::MachineThreads::addCurrentThread):
+ * heap/MachineStackMarker.h:
+ * runtime/JSLock.cpp:
+ (JSC::JSLock::didAcquireLock):
+
+2015-02-24 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [Mac] [iOS] Parsing support for -apple-trailing-word
+ https://bugs.webkit.org/show_bug.cgi?id=141939
+
+ Reviewed by Andreas Kling.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-02-24 Ryosuke Niwa <rniwa@webkit.org>
+
+ Use "this" instead of "callee" to get the constructor
+ https://bugs.webkit.org/show_bug.cgi?id=141019
+
+ Reviewed by Filip Pizlo.
+
+ This patch uses "this" register to pass the constructor (newTarget) to op_create_this from
+ op_construct or op_construct_varargs. This will allow future patches that implement ES6 class
+ to pass in the most derived class' constructor through "this" argument.
+
+ BytecodeGenerator's emitConstruct and emitConstructVarargs now passes thisRegister like
+ regular calls and emitCreateThis passes in this register to op_create_this as constructor.
+
+ The rest of the code change removes the code for special casing "this" register not being used
+ in call to construct.
+
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitCreateThis):
+ (JSC::BytecodeGenerator::emitConstructVarargs):
+ (JSC::BytecodeGenerator::emitConstruct):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::NewExprNode::emitBytecode):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
+ (JSC::DFG::ByteCodeParser::handleVarargsCall):
+ (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
+ (JSC::DFG::ByteCodeParser::attemptToInlineCall):
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGJITCode.cpp:
+ (JSC::DFG::JITCode::reconstruct):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * ftl/FTLJSCallVarargs.cpp:
+ (JSC::FTL::JSCallVarargs::emit):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
+ (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
+ (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::executeConstruct):
+ * jit/JITOperations.cpp:
+
+2015-02-24 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Make Getter/Setter RemoteObject property and ObjectPreview handling consistent
+ https://bugs.webkit.org/show_bug.cgi?id=141587
+
+ Reviewed by Timothy Hatcher.
+
+ Convert getProperties(ownAndGetterProperties) to getDisplayableProperties().
+ Mark PropertyDescriptors that are presumed to be native getters / bindings
+ separately so that the frontend may display them differently.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getProperties):
+ (Inspector::InjectedScript::getDisplayableProperties):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptSource.js:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::getProperties):
+ (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/protocol/Runtime.json:
+
+2015-02-24 Mark Lam <mark.lam@apple.com>
+
+ Rolling out r179753. The fix was invalid.
+ <https://webkit.org/b/141990>
+
+ Not reviewed.
+
+ * API/tests/testapi.mm:
+ (threadMain):
+ (useVMFromOtherThread): Deleted.
+ (useVMFromOtherThreadAndOutliveVM): Deleted.
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::~Heap):
+ (JSC::Heap::gatherStackRoots):
+ * heap/Heap.h:
+ (JSC::Heap::machineThreads):
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::Thread::Thread):
+ (JSC::MachineThreads::MachineThreads):
+ (JSC::MachineThreads::~MachineThreads):
+ (JSC::MachineThreads::addCurrentThread):
+ (JSC::MachineThreads::removeThread):
+ (JSC::MachineThreads::removeCurrentThread):
+ * heap/MachineStackMarker.h:
+
+2015-02-24 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Constructor returning null should construct an object instead of null
+ https://bugs.webkit.org/show_bug.cgi?id=141640
+
+ Reviewed by Filip Pizlo.
+
+ When constructor code doesn't return object, constructor should return `this` object instead.
+ Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
+ it allows `null` as an object.
+ This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
+ Instead, constructor uses simplified `is_object`.
+
+ As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
+
+ 1. LLInt and baseline JIT support `op_is_object` as a fast path.
+ 2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
+ 3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
+ 4. FTL lowers DFG's IsObject into LLVM IR.
+
+ And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
+ in LLInt, JIT, DFG and FTL.
+ Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
+ So in many places, when the cell is not object, we recognize it as a string, and vice versa.
+ However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
+ So this patch stop using !isString as isObject.
+ To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
+ we examine typeInfo in JSCell.
+
+ * JavaScriptCore.order:
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFor):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitEqualityOp):
+ (JSC::BytecodeGenerator::emitReturn):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+
+ IsObject operation only touches JSCell typeInfoType.
+ And this value would be changed through structure transition.
+ As a result, IsObject can report that it doesn't read any information.
+
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+
+ Just like IsString, IsObject is also fixed up.
+
+ * dfg/DFGHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGHeapLocation.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::compilePeepHoleObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
+ (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
+ (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
+ (JSC::DFG::SpeculativeJIT::speculateObject):
+ (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
+ (JSC::DFG::SpeculativeJIT::speculateString):
+ (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
+ (JSC::DFG::SpeculativeJIT::emitSwitchChar):
+ (JSC::DFG::SpeculativeJIT::emitSwitchString):
+ (JSC::DFG::SpeculativeJIT::branchIsObject):
+ (JSC::DFG::SpeculativeJIT::branchNotObject):
+ (JSC::DFG::SpeculativeJIT::branchIsString):
+ (JSC::DFG::SpeculativeJIT::branchNotString):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compileObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
+ (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compileObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
+ (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileToString):
+ (JSC::FTL::LowerDFGToLLVM::compileIsObject):
+ (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
+ (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
+ (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
+ (JSC::FTL::LowerDFGToLLVM::isObject):
+ (JSC::FTL::LowerDFGToLLVM::isNotObject):
+ (JSC::FTL::LowerDFGToLLVM::isNotString):
+ (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::emitJumpIfCellObject):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_is_object):
+ (JSC::JIT::emit_op_to_primitive):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_is_object):
+ (JSC::JIT::emit_op_to_primitive):
+ (JSC::JIT::compileOpStrictEq):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ * runtime/Operations.cpp:
+ (JSC::jsIsObjectTypeOrNull):
+ (JSC::jsIsObjectType): Deleted.
+ * runtime/Operations.h:
+ * tests/stress/constructor-with-return.js: Added.
+ (Test):
+
+ When constructor doesn't return an object, `this` should be returned instead.
+ In this test, we check all primitives. And test object, array and wrappers.
+
+ * tests/stress/dfg-to-primitive-pass-symbol.js: Added.
+ (toPrimitiveTarget):
+ (doToPrimitive):
+
+ op_to_primitive operation passes Symbol in fast path.
+
+2015-02-24 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION(r179429): Can't type comments in Facebook
+ https://bugs.webkit.org/show_bug.cgi?id=141859
+
+ Reviewed by Brent Fulgham.
+
+ When window.Symbol is exposed to user-space pages,
+ Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
+ However, to work with Symbols completely, it also requires
+ 1) Object.getOwnPropertySymbols (for mixin including Symbols)
+ 2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
+ Since they are not landed yet, comments in Facebook don't work.
+
+ This patch introduces RuntimeFlags for JavaScriptCore.
+ Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
+ And drop JavaScriptExperimentsEnabled flag
+ because it is no longer used and use case of this is duplicated to runtime flags.
+
+ * JavaScriptCore.order:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * jsc.cpp:
+ (GlobalObject::javaScriptRuntimeFlags):
+ (GlobalObject::javaScriptExperimentsEnabled): Deleted.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::JSGlobalObject):
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::finishCreation):
+ (JSC::JSGlobalObject::javaScriptRuntimeFlags):
+ (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
+ * runtime/RuntimeFlags.h: Added.
+ (JSC::RuntimeFlags::RuntimeFlags):
+ (JSC::RuntimeFlags::createAllEnabled):
+
+2015-02-23 Filip Pizlo <fpizlo@apple.com>
+
+ Our bizarre behavior on Arguments::defineOwnProperty should be deliberate rather than a spaghetti incident
+ https://bugs.webkit.org/show_bug.cgi?id=141951
+
+ Reviewed by Benjamin Poulain.
+
+ This patch has no behavioral change, but it simplifies a bunch of wrong code. The code is
+ still wrong in exactly the same way, but at least it's obvious what's going on. The wrongness
+ is covered by this bug: https://bugs.webkit.org/show_bug.cgi?id=141952.
+
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::copyBackingStore): We should only see the arguments token; assert otherwise. This works because if the GC sees the butterfly token it calls the JSObject::copyBackingStore method directly.
+ (JSC::Arguments::defineOwnProperty): Make our bizarre behavior deliberate rather than an accident of a decade of patches.
+ * tests/stress/arguments-bizarre-behavior.js: Added.
+ (foo):
+ * tests/stress/arguments-bizarre-behaviour-disable-enumerability.js: Added. My choice of spellings of the word "behavio[u]r" is almost as consistent as our implementation of arguments.
+ (foo):
+ * tests/stress/arguments-custom-properties-gc.js: Added. I added this test because at first I was unsure if we GCd arguments correctly.
+ (makeBaseArguments):
+ (makeArray):
+ (cons):
+
+2015-02-23 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r180547 and r180550.
+ https://bugs.webkit.org/show_bug.cgi?id=141957
+
+ Broke 10 Windows tests. (Requested by bfulgham_ on #webkit).
+
+ Reverted changesets:
+
+ "REGRESSION(r179429): Can't type comments in Facebook"
+ https://bugs.webkit.org/show_bug.cgi?id=141859
+ http://trac.webkit.org/changeset/180547
+
+ "Constructor returning null should construct an object instead
+ of null"
+ https://bugs.webkit.org/show_bug.cgi?id=141640
+ http://trac.webkit.org/changeset/180550
+
+2015-02-23 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Constructor returning null should construct an object instead of null
+ https://bugs.webkit.org/show_bug.cgi?id=141640
+
+ Reviewed by Geoffrey Garen.
+
+ When constructor code doesn't return object, constructor should return `this` object instead.
+ Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
+ it allows `null` as an object.
+ This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
+ Instead, constructor uses simplified `is_object`.
+
+ As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
+
+ 1. LLInt and baseline JIT support `op_is_object` as a fast path.
+ 2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
+ 3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
+ 4. FTL lowers DFG's IsObject into LLVM IR.
+
+ And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
+ in LLInt, JIT, DFG and FTL.
+ Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
+ So in many places, when the cell is not object, we recognize it as a string, and vice versa.
+ However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
+ So this patch stop using !isString as isObject.
+ To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
+ we examine typeInfo in JSCell.
+
+ * JavaScriptCore.order:
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFor):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitEqualityOp):
+ (JSC::BytecodeGenerator::emitReturn):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+
+ IsObject operation only touches JSCell typeInfoType.
+ And this value would not be changed through structure transition.
+ As a result, IsObject can report that it doesn't read any information.
+
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+
+ Just like IsString, IsObject is also fixed up.
+
+ * dfg/DFGHeapLocation.cpp:
+ (WTF::printInternal):
+ * dfg/DFGHeapLocation.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::compilePeepHoleObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
+ (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
+ (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
+ (JSC::DFG::SpeculativeJIT::speculateObject):
+ (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
+ (JSC::DFG::SpeculativeJIT::speculateString):
+ (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
+ (JSC::DFG::SpeculativeJIT::emitSwitchChar):
+ (JSC::DFG::SpeculativeJIT::emitSwitchString):
+ (JSC::DFG::SpeculativeJIT::branchIsObject):
+ (JSC::DFG::SpeculativeJIT::branchNotObject):
+ (JSC::DFG::SpeculativeJIT::branchIsString):
+ (JSC::DFG::SpeculativeJIT::branchNotString):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compileObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
+ (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compileObjectEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
+ (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
+ (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileToString):
+ (JSC::FTL::LowerDFGToLLVM::compileIsObject):
+ (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
+ (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
+ (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
+ (JSC::FTL::LowerDFGToLLVM::isObject):
+ (JSC::FTL::LowerDFGToLLVM::isNotObject):
+ (JSC::FTL::LowerDFGToLLVM::isNotString):
+ (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::emitJumpIfCellObject):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_is_object):
+ (JSC::JIT::emit_op_to_primitive):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_is_object):
+ (JSC::JIT::emit_op_to_primitive):
+ (JSC::JIT::compileOpStrictEq):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ * runtime/Operations.cpp:
+ (JSC::jsIsObjectTypeOrNull):
+ (JSC::jsIsObjectType): Deleted.
+ * runtime/Operations.h:
+
+2015-02-23 Ryosuke Niwa <rniwa@webkit.org>
+
+ Disable font loading events until our implementation gets updated to match the latest spec
+ https://bugs.webkit.org/show_bug.cgi?id=141938
+
+ Reviewed by Andreas Kling.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-02-23 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ REGRESSION(r179429): Can't type comments in Facebook
+ https://bugs.webkit.org/show_bug.cgi?id=141859
+
+ Reviewed by Geoffrey Garen.
+
+ When window.Symbol is exposed to user-space pages,
+ Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
+ However, to work with Symbols completely, it also requires
+ 1) Object.getOwnPropertySymbols (for mixin including Symbols)
+ 2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
+ Since they are not landed yet, comments in Facebook don't work.
+
+ This patch introduces RuntimeFlags for JavaScriptCore.
+ Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
+ And drop JavaScriptExperimentsEnabled flag
+ because it is no longer used and use case of this is duplicated to runtime flags.
+
+ * JavaScriptCore.order:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * jsc.cpp:
+ (GlobalObject::javaScriptRuntimeFlags):
+ (GlobalObject::javaScriptExperimentsEnabled): Deleted.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::JSGlobalObject):
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::finishCreation):
+ (JSC::JSGlobalObject::javaScriptRuntimeFlags):
+ (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
+ * runtime/RuntimeFlags.h: Added.
+ (JSC::RuntimeFlags::RuntimeFlags):
+ (JSC::RuntimeFlags::createAllEnabled):
+
+2015-02-23 Benjamin Poulain <bpoulain@apple.com>
+
+ Set the semantic origin of delayed SetLocal to the Bytecode that originated it
+ https://bugs.webkit.org/show_bug.cgi?id=141727
+
+ Reviewed by Filip Pizlo.
+
+ Previously, delayed SetLocals would have the NodeOrigin of the next
+ bytecode. This was because delayed SetLocal are...delayed... and
+ currentCodeOrigin() is the one where the node is emitted.
+
+ This made debugging a little awkward since the OSR exits on SetLocal
+ were reported for the next bytecode. This patch changes the semantic
+ origin to keep the original bytecode.
+
+ From benchmarks, this looks like it could be a tiny bit faster
+ but it likely just noise.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::setDirect):
+ (JSC::DFG::ByteCodeParser::setLocal):
+ (JSC::DFG::ByteCodeParser::setArgument):
+ (JSC::DFG::ByteCodeParser::currentNodeOrigin):
+ (JSC::DFG::ByteCodeParser::addToGraph):
+ (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
+ (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
+
+2015-02-23 Benjamin Poulain <bpoulain@apple.com>
+
+ Remove DFGNode::predictHeap()
+ https://bugs.webkit.org/show_bug.cgi?id=141864
+
+ Reviewed by Geoffrey Garen.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::predictHeap): Deleted.
+ Unused code.
+
+2015-02-23 Filip Pizlo <fpizlo@apple.com>
+
+ Get rid of JSLexicalEnvironment::argumentsGetter
+ https://bugs.webkit.org/show_bug.cgi?id=141930
+
+ Reviewed by Mark Lam.
+
+ This function is unused, and the way it's written is bizarre - it's a return statement that
+ dominates a bunch of dead code.
+
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::argumentsGetter): Deleted.
+ * runtime/JSLexicalEnvironment.h:
+
+2015-02-23 Filip Pizlo <fpizlo@apple.com>
+
+ Remove unused activationCount and allTheThingsCount variable declarations.
+
+ Rubber stamped by Mark Lam and Michael Saboff.
+
+ * runtime/JSLexicalEnvironment.h:
+
+2015-02-23 Saam Barati <saambarati1@gmail.com>
+
+ Adjust the ranges of basic block statements in JSC's control flow profiler to be mutually exclusive
+ https://bugs.webkit.org/show_bug.cgi?id=141095
+
+ Reviewed by Mark Lam.
+
+ Suppose the control flow of a program forms basic block A with successor block
+ B. A's end offset will be the *same* as B's start offset in the current architecture
+ of the control flow profiler. This makes reasoning about the text offsets of
+ the control flow profiler unsound. To make reasoning about offsets sound, all
+ basic block ranges should be mutually exclusive. All calls to emitProfileControlFlow
+ now pass in the *start* of a basic block as the text offset argument. This simplifies
+ all calls to emitProfileControlFlow because the previous implementation had a
+ lot of edge cases for getting the desired basic block text boundaries.
+
+ This patch also ensures that the basic block boundary of a block statement
+ is the exactly the block's open and close brace offsets (inclusive). For example,
+ in if/for/while statements. This also has the consequence that for statements
+ like "if (cond) foo();", the whitespace preceding "foo()" is not part of
+ the "foo()" basic block, but instead is part of the "if (cond) " basic block.
+ This is okay because these text offsets aren't meant to be human readable.
+ Instead, they reflect the text offsets of JSC's AST nodes. The Web Inspector
+ is the only client of this API and user of these text offsets and it is
+ not negatively effected by this new behavior.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
+ When computing basic block boundaries in CodeBlock, we ensure that every
+ block's end offset is one less than its successor's start offset to
+ maintain that boundaries' ranges should be mutually exclusive.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ Because the control flow profiler needs to know which functions
+ have executed, we can't lazily create functions. This was a bug
+ from before that was hidden because the Type Profiler was always
+ enabled when the control flow profiler was enabled when profiling
+ was turned on from the Web Inspector. But, JSC allows for Control
+ Flow profiling to be turned on without Type Profiling, so we need
+ to ensure the Control Flow profiler has all the data it needs.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ConditionalNode::emitBytecode):
+ (JSC::IfElseNode::emitBytecode):
+ (JSC::WhileNode::emitBytecode):
+ (JSC::ForNode::emitBytecode):
+ (JSC::ForInNode::emitMultiLoopBytecode):
+ (JSC::ForOfNode::emitBytecode):
+ (JSC::TryNode::emitBytecode):
+ * jsc.cpp:
+ (functionHasBasicBlockExecuted):
+ We now assert that the substring argument is indeed a substring
+ of the function argument's text because subtle bugs could be
+ introduced otherwise.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::setStartOffset):
+ * parser/Nodes.h:
+ (JSC::Node::setStartOffset):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseBlockStatement):
+ (JSC::Parser<LexerType>::parseStatement):
+ (JSC::Parser<LexerType>::parseMemberExpression):
+ For the various function call AST nodes, their m_position member
+ variable is now the start of the entire function call expression
+ and not at the start of the open paren of the arguments list.
+
+ * runtime/BasicBlockLocation.cpp:
+ (JSC::BasicBlockLocation::getExecutedRanges):
+ * runtime/ControlFlowProfiler.cpp:
+ (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
+ Function ranges inserted as gaps should follow the same criteria
+ that the bytecode generator uses to ensure that basic blocks
+ start and end offsets are mutually exclusive.
+
+ * tests/controlFlowProfiler/brace-location.js: Added.
+ (foo):
+ (bar):
+ (baz):
+ (testIf):
+ (testForRegular):
+ (testForIn):
+ (testForOf):
+ (testWhile):
+ (testIfNoBraces):
+ (testForRegularNoBraces):
+ (testForInNoBraces):
+ (testForOfNoBraces):
+ (testWhileNoBraces):
+ * tests/controlFlowProfiler/conditional-expression.js: Added.
+ (foo):
+ (bar):
+ (baz):
+ (testConditionalBasic):
+ (testConditionalFunctionCall):
+ * tests/controlFlowProfiler/driver/driver.js:
+ (checkBasicBlock):
+
+2015-02-23 Matthew Mirman <mmirman@apple.com>
+
+ r9 is volatile on ARMv7 for iOS 3 and up.
+ https://bugs.webkit.org/show_bug.cgi?id=141489
+ rdar://problem/19432916
+
+ Reviewed by Michael Saboff.
+
+ * jit/RegisterSet.cpp:
+ (JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers.
+ * tests/stress/regress-141489.js: Added.
+ (foo):
+
+2015-02-23 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Add the necessary setupArgumentsWithExecState after bug141915
+ https://bugs.webkit.org/show_bug.cgi?id=141921
+
+ Reviewed by Michael Saboff.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+
+2015-02-23 Filip Pizlo <fpizlo@apple.com>
+
+ Scopes should always be created with a previously-created symbol table rather than creating one on the fly
+ https://bugs.webkit.org/show_bug.cgi?id=141915
+
+ Reviewed by Mark Lam.
+
+ The main effect of this change is that pushing name scopes no longer requires creating symbol
+ tables on the fly.
+
+ This also makes it so that JSEnvironmentRecords must always have an a priori symbol table.
+
+ JSSegmentedVariableObject still does a hack where it creates a blank symbol table on-demand.
+ This is needed because that's what JSGlobalObject and all of its many subclasses want. That's
+ harmless; I mainly needed a prior symbol tables for JSEnvironmentRecords anyway.
+
+ * bytecode/BytecodeList.json:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitPushFunctionNameScope):
+ (JSC::BytecodeGenerator::emitPushCatchScope):
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_push_name_scope):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_push_name_scope):
+ * jit/JITOperations.cpp:
+ (JSC::pushNameScope):
+ * jit/JITOperations.h:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter.asm:
+ * runtime/Executable.cpp:
+ (JSC::ScriptExecutable::newCodeBlockFor):
+ * runtime/JSCatchScope.h:
+ (JSC::JSCatchScope::JSCatchScope):
+ (JSC::JSCatchScope::create):
+ * runtime/JSEnvironmentRecord.h:
+ (JSC::JSEnvironmentRecord::JSEnvironmentRecord):
+ * runtime/JSFunctionNameScope.h:
+ (JSC::JSFunctionNameScope::JSFunctionNameScope):
+ (JSC::JSFunctionNameScope::create):
+ * runtime/JSNameScope.cpp:
+ (JSC::JSNameScope::create):
+ * runtime/JSNameScope.h:
+ (JSC::JSNameScope::create):
+ (JSC::JSNameScope::finishCreation):
+ (JSC::JSNameScope::JSNameScope):
+ * runtime/JSSegmentedVariableObject.h:
+ (JSC::JSSegmentedVariableObject::finishCreation):
+ * runtime/JSSymbolTableObject.h:
+ (JSC::JSSymbolTableObject::JSSymbolTableObject):
+ (JSC::JSSymbolTableObject::finishCreation): Deleted.
+ * runtime/SymbolTable.h:
+ (JSC::SymbolTable::createNameScopeTable):
+
+2015-02-23 Filip Pizlo <fpizlo@apple.com>
+
+ Add a comment to clarify that the test was taken from the bug report, in response to
+ feedback from Michael Saboff and Benjamin Poulain.
+
+ * tests/stress/regress-141883.js:
+
+2015-02-22 Filip Pizlo <fpizlo@apple.com>
+
+ Function name scope is only created on the function instance that triggered parsing rather than on every function instance that needs it
+ https://bugs.webkit.org/show_bug.cgi?id=141881
+
+ Reviewed by Michael Saboff.
+
+ Previously we only created the function name scope in a way that made it visible to the
+ function that triggered parsing/linking of the executable/codeBlock, and to the linker for
+ that code block. This was sort of the bare minimum for the feature to appear to work right to
+ synthetic tests.
+
+ There are two valid "times" to create the function name scope. Either it's created for each
+ JSFunction instance that needs a name scope, or it's created for each execution of such a
+ JSFunction. This change chooses the latter, because it happens to be the easiest to implement
+ with what we have right now. I opened a bug for optimizing this if we ever need to:
+ https://bugs.webkit.org/show_bug.cgi?id=141887.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::execute):
+ (JSC::Interpreter::executeCall):
+ (JSC::Interpreter::executeConstruct):
+ (JSC::Interpreter::prepareForRepeatCall):
+ * jit/JITOperations.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::setUpCall):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::isNumericCompareFunction):
+ * runtime/Executable.cpp:
+ (JSC::ScriptExecutable::newCodeBlockFor):
+ (JSC::ScriptExecutable::prepareForExecutionImpl):
+ (JSC::FunctionExecutable::FunctionExecutable):
+ * runtime/Executable.h:
+ (JSC::ScriptExecutable::prepareForExecution):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::addNameScopeIfNeeded): Deleted.
+ * runtime/JSFunction.h:
+ * tests/stress/function-name-scope.js: Added.
+ (check.verify):
+ (check):
+
+2015-02-22 Filip Pizlo <fpizlo@apple.com>
+
+ Crash in DFGFrozenValue
+ https://bugs.webkit.org/show_bug.cgi?id=141883
+
+ Reviewed by Benjamin Poulain.
+
+ If a value might be a cell, then we have to have Graph freeze it rather than trying to
+ create the FrozenValue directly. Creating it directly is just an optimization for when you
+ know for sure that it cannot be a cell.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * tests/stress/regress-141883.js: Added. Hacked the original test to be faster while still crashing before this fix.
+
+2015-02-21 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Generate Previews more often for RemoteObject interaction
+ https://bugs.webkit.org/show_bug.cgi?id=141875
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Runtime.json:
+ Add generatePreview to getProperties.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getProperties):
+ (Inspector::InjectedScript::getInternalProperties):
+ * inspector/InjectedScript.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::getProperties):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ Plumb the generatePreview boolean through to the injected script.
+
+ * inspector/InjectedScriptSource.js:
+ Add generatePreview for getProperties.
+ Fix callFunctionOn to generatePreviews if asked.
+
+2015-02-20 Mark Lam <mark.lam@apple.com>
+
+ Refactor JSWrapperMap.mm to defer creation of the ObjC JSValue until the latest possible moment.
+ <https://webkit.org/b/141856>
+
+ Reviewed by Geoffrey Garen.
+
+ 1. Make JSObjCClassInfo's -constructor and -wrapperForObject return a
+ JSC::JSObject* just like -prototype.
+ 2. Defer the creation of the ObjC JSValue from JSC::JSObject* until
+ the latest moment when it is needed. This allows us to not have to
+ keep converting back to a JSC::JSObject* in intermediate code.
+
+ * API/JSWrapperMap.mm:
+ (makeWrapper):
+ (objectWithCustomBrand):
+ (constructorWithCustomBrand):
+ (allocateConstructorForCustomClass):
+ (-[JSObjCClassInfo allocateConstructorAndPrototype]):
+ (-[JSObjCClassInfo wrapperForObject:]):
+ (-[JSObjCClassInfo constructor]):
+ (-[JSWrapperMap jsWrapperForObject:]):
+
+2015-02-20 Filip Pizlo <fpizlo@apple.com>
+
+ Build fix for gcc.
+
+ * runtime/JSNameScope.cpp:
+ (JSC::JSNameScope::create):
+
+2015-02-20 Filip Pizlo <fpizlo@apple.com>
+
+ Get rid of JSNameScope::m_type
+ https://bugs.webkit.org/show_bug.cgi?id=141851
+
+ Reviewed by Geoffrey Garen.
+
+ This is a big step towards getting rid of JSEnvironmentRecord::m_registers. To do it we need
+ to ensure that subclasses of JSEnvironmentRecord never have additional C++ fields, so that
+ JSEnvironmentRecord can always place "registers" right after the end of itself.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * debugger/DebuggerScope.cpp:
+ (JSC::DebuggerScope::isCatchScope):
+ (JSC::DebuggerScope::isFunctionNameScope):
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::execute):
+ * jit/JITOperations.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/JSCatchScope.cpp: Added.
+ * runtime/JSCatchScope.h: Added.
+ (JSC::JSCatchScope::JSCatchScope):
+ (JSC::JSCatchScope::create):
+ (JSC::JSCatchScope::createStructure):
+ * runtime/JSFunction.cpp:
+ (JSC::JSFunction::addNameScopeIfNeeded):
+ * runtime/JSFunctionNameScope.cpp: Added.
+ * runtime/JSFunctionNameScope.h: Added.
+ (JSC::JSFunctionNameScope::JSFunctionNameScope):
+ (JSC::JSFunctionNameScope::create):
+ (JSC::JSFunctionNameScope::createStructure):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::catchScopeStructure):
+ (JSC::JSGlobalObject::functionNameScopeStructure):
+ (JSC::JSGlobalObject::nameScopeStructure): Deleted.
+ * runtime/JSNameScope.cpp:
+ (JSC::JSNameScope::create):
+ * runtime/JSNameScope.h:
+ (JSC::JSNameScope::create):
+ (JSC::JSNameScope::JSNameScope):
+ (JSC::JSNameScope::createStructure): Deleted.
+ (JSC::JSNameScope::isFunctionNameScope): Deleted.
+ (JSC::JSNameScope::isCatchScope): Deleted.
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::isCatchScopeObject):
+ (JSC::JSObject::isFunctionNameScopeObject):
+ * runtime/JSObject.h:
+
+2015-02-20 Mark Lam <mark.lam@apple.com>
+
+ [JSObjCClassInfo reallocateConstructorAndOrPrototype] should also reallocate super class prototype chain.
+ <https://webkit.org/b/141809>
+
+ Reviewed by Geoffrey Garen.
+
+ A ObjC class that implement the JSExport protocol will have a JS prototype
+ chain and constructor automatically synthesized for its JS wrapper object.
+ However, if there are no more instances of that ObjC class reachable by a
+ JS GC root scan, then its synthesized prototype chain and constructors may
+ be released by the GC. If a new instance of that ObjC class is subsequently
+ instantiated, then [JSObjCClassInfo reallocateConstructorAndOrPrototype]
+ should re-construct the prototype chain and constructor (if they were
+ previously released). However, the current implementation only
+ re-constructs the immediate prototype, but not every other prototype
+ object upstream in the prototype chain.
+
+ To fix this, we do the following:
+ 1. We no longer allocate the JSObjCClassInfo's prototype and constructor
+ eagerly. Hence, -initWithContext:forClass: will no longer call
+ -allocateConstructorAndPrototypeWithSuperClassInfo:.
+ 2. Instead, we'll always access the prototype and constructor thru
+ accessor methods. The accessor methods will call
+ -allocateConstructorAndPrototype: if needed.
+ 3. -allocateConstructorAndPrototype: will fetch the needed superClassInfo
+ from the JSWrapperMap itself. This makes it so that we no longer
+ need to pass the superClassInfo all over.
+ 4. -allocateConstructorAndPrototype: will get the super class prototype
+ by invoking -prototype: on the superClassInfo, thereby allowing the
+ super class to allocate its prototype and constructor if needed and
+ fixing the issue in this bug.
+
+ 5. Also removed the GC warning comments, and ensured that needed JS
+ objects are kept alive by having a local var pointing to it from the
+ stack (which makes a GC root).
+
+ * API/JSWrapperMap.mm:
+ (-[JSObjCClassInfo initWithContext:forClass:]):
+ (-[JSObjCClassInfo allocateConstructorAndPrototype]):
+ (-[JSObjCClassInfo wrapperForObject:]):
+ (-[JSObjCClassInfo constructor]):
+ (-[JSObjCClassInfo prototype]):
+ (-[JSWrapperMap classInfoForClass:]):
+ (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Deleted.
+ (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Deleted.
+ (-[JSObjCClassInfo reallocateConstructorAndOrPrototype]): Deleted.
+ * API/tests/Regress141809.h: Added.
+ * API/tests/Regress141809.mm: Added.
+ (-[TestClassB name]):
+ (-[TestClassC name]):
+ (runRegress141809):
+ * API/tests/testapi.mm:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-02-20 Alexey Proskuryakov <ap@apple.com>
+
+ Remove svn:keywords property.
+
+ As far as I can tell, the property had no effect on any of these files, but also,
+ when it has effect it's likely harmful.
+
+ * builtins/ArrayConstructor.js: Removed property svn:keywords.
+
+2015-02-20 Michael Saboff <msaboff@apple.com>
+
+ DFG JIT needs to check for stack overflow at the start of Program and Eval execution
+ https://bugs.webkit.org/show_bug.cgi?id=141676
+
+ Reviewed by Filip Pizlo.
+
+ Added stack check to the beginning of the code the DFG copmiler emits for Program and Eval nodes.
+ To aid in testing the code, I replaced the EvalCodeCache::maxCacheableSourceLength const
+ a options in runtime/Options.h. The test script, run-jsc-stress-tests, sets that option
+ to a huge value when running with the "Eager" options. This allows the updated test to
+ reliably exercise the code in questions.
+
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::compile):
+ Added stack check.
+
+ * bytecode/EvalCodeCache.h:
+ (JSC::EvalCodeCache::tryGet):
+ (JSC::EvalCodeCache::getSlow):
+ * runtime/Options.h:
+ Replaced EvalCodeCache::imaxCacheableSourceLength with Options::maximumEvalCacheableSourceLength
+ so that it can be configured when running the related test.
+
+2015-02-20 Eric Carlson <eric.carlson@apple.com>
+
+ [iOS] cleanup AirPlay code
+ https://bugs.webkit.org/show_bug.cgi?id=141811
+
+ Reviewed by Jer Noble.
+
+ * Configurations/FeatureDefines.xcconfig: IOS_AIRPLAY -> WIRELESS_PLAYBACK_TARGET.
+
+2015-02-19 Dean Jackson <dino@apple.com>
+
+ ES6: Implement Array.from()
+ https://bugs.webkit.org/show_bug.cgi?id=141054
+ <rdar://problem/19654521>
+
+ Reviewed by Filip Pizlo.
+
+ Implement the Array.from() ES6 method
+ as defined in Section 22.1.2.1 of the specification.
+
+ Given that we can't rely on the built-in
+ global functions or objects to be untainted,
+ I had to expose a few of them directly to
+ the function via private names. In particular:
+ - Math.floor -> @floor
+ - Math.abs -> @abs
+ - Number -> @Number
+ - Array -> @Array
+ - isFinite -> @isFinite
+
+ * builtins/ArrayConstructor.js: Added.
+ (from): Implementation of Array.from in JavaScript.
+ * runtime/ArrayConstructor.cpp: Add "from" to the lookup
+ table for the constructor object.
+ * runtime/CommonIdentifiers.h: Add the private versions
+ of the identifiers listed above.
+ * runtime/JSGlobalObject.cpp: Add the implementations of
+ those identifiers to the global object (using their
+ private names).
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObjectFunctions.cpp:
+ (JSC::globalPrivateFuncAbs): Implementation of the abs function.
+ (JSC::globalPrivateFuncFloor): Implementation of the floor function.
+ * runtime/JSGlobalObjectFunctions.h:
+
+2015-02-19 Benjamin Poulain <bpoulain@apple.com>
+
+ Refine the FTL part of ArithPow
+ https://bugs.webkit.org/show_bug.cgi?id=141792
+
+ Reviewed by Filip Pizlo.
+
+ This patch refines the FTL lowering of ArithPow. This was left out
+ of the original patch to keep it simpler.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileArithPow):
+ Two improvements here:
+ 1) Do not generate the NaN check unless we know the exponent might be a NaN.
+ 2) Use one BasicBlock per check with the appropriate weight. Now that we have
+ one branch per test, move the Infinity check before the check for 1 since
+ it is the less common case.
+
+ * tests/stress/math-pow-becomes-custom-function.js: Added.
+ Test for changing the Math.pow() function after it has been optimized.
+
+ * tests/stress/math-pow-nan-behaviors.js:
+ The previous tests were only going as far as the DFGAbstractInterpreter
+ were the operations were replaced by the equivalent constant.
+
+ I duplicated the test functions to also test the dynamic behavior of DFG
+ and FTL.
+
+ * tests/stress/math-pow-with-constants.js:
+ Add cases covering exponent constants. LLVM removes many value
+ checks for those.
+
+ * tests/stress/math-pow-with-never-NaN-exponent.js: Added.
+ Test for the new optimization removing the NaN check.
+
+2015-02-19 Csaba Osztrogonác <ossy@webkit.org>
+
+ REGRESSION(r180279): It broke 20 tests on ARM Linux
+ https://bugs.webkit.org/show_bug.cgi?id=141771
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::callOperation): Align 64-bit values to respect ARM EABI.
+
+2015-02-18 Benjamin Poulain <bpoulain@apple.com>
+
+ Remove BytecodeGenerator's numberMap, it is dead code
+ https://bugs.webkit.org/show_bug.cgi?id=141779
+
+ Reviewed by Filip Pizlo.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitLoad): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ The JSValueMap seems better in every way.
+
+ The emitLoad() taking a double was the only way to use numberMap
+ and that code has no caller.
+
+2015-02-18 Michael Saboff <msaboff@apple.com>
+
+ Rollout r180247 & r180249 from trunk
+ https://bugs.webkit.org/show_bug.cgi?id=141773
+
+ Reviewed by Filip Pizlo.
+
+ Theses changes makes sense to fix the crash reported in https://bugs.webkit.org/show_bug.cgi?id=141730
+ only for branches. The change to fail the FTL compile but continue running is not comprehensive
+ enough for general use on trunk.
+
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
+ (JSC::FTL::LowerDFGToLLVM::compilePhi):
+ (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
+ (JSC::FTL::LowerDFGToLLVM::compileValueRep):
+ (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
+ (JSC::FTL::LowerDFGToLLVM::compilePutLocal):
+ (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
+ (JSC::FTL::LowerDFGToLLVM::compileArithMul):
+ (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
+ (JSC::FTL::LowerDFGToLLVM::compileArithMod):
+ (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
+ (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
+ (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
+ (JSC::FTL::LowerDFGToLLVM::compileGetById):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
+ (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
+ (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
+ (JSC::FTL::LowerDFGToLLVM::compileNewArray):
+ (JSC::FTL::LowerDFGToLLVM::compileToString):
+ (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
+ (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
+ (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
+ (JSC::FTL::LowerDFGToLLVM::compileSwitch):
+ (JSC::FTL::LowerDFGToLLVM::compare):
+ (JSC::FTL::LowerDFGToLLVM::boolify):
+ (JSC::FTL::LowerDFGToLLVM::opposite):
+ (JSC::FTL::LowerDFGToLLVM::lowJSValue):
+ (JSC::FTL::LowerDFGToLLVM::speculate):
+ (JSC::FTL::LowerDFGToLLVM::isArrayType):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
+ (JSC::FTL::LowerDFGToLLVM::setInt52):
+ (JSC::FTL::lowerDFGToLLVM):
+ (JSC::FTL::LowerDFGToLLVM::loweringFailed): Deleted.
+ * ftl/FTLLowerDFGToLLVM.h:
+
+2015-02-18 Filip Pizlo <fpizlo@apple.com>
+
+ DFG should really support varargs
+ https://bugs.webkit.org/show_bug.cgi?id=141332
+
+ Reviewed by Oliver Hunt.
+
+ This adds comprehensive vararg call support to the DFG and FTL compilers. Previously, if a
+ function had a varargs call, then it could only be compiled if that varargs call was just
+ forwarding arguments and we were inlining the function rather than compiling it directly. Also,
+ only varargs calls were dealt with; varargs constructs were not.
+
+ This lifts all of those restrictions. Every varargs call or construct can now be compiled by both
+ the DFG and the FTL. Those calls can also be inlined, too - provided that profiling gives us a
+ sensible bound on arguments list length. When we inline a varargs call, the act of loading the
+ varargs is now made explicit in IR. I believe that we have enough IR machinery in place that we
+ would be able to do the arguments forwarding optimization as an IR transformation. This patch
+ doesn't implement that yet, and keeps the old bytecode-based varargs argument forwarding
+ optimization for now.
+
+ There are three major IR features introduced in this patch:
+
+ CallVarargs/ConstructVarargs: these are like Call/Construct except that they take an arguments
+ array rather than a list of arguments. Currently, they splat this arguments array onto the stack
+ using the same basic technique as the baseline JIT has always done. Except, these nodes indicate
+ that we are not interested in doing the non-escaping "arguments" optimization.
+
+ CallForwardVarargs: this is a form of CallVarargs that just does the non-escaping "arguments"
+ optimization, aka forwarding arguments. It's somewhat lazy that this doesn't include
+ ConstructForwardVarargs, but the reason is that once we eliminate the lazy tear-off for
+ arguments, this whole thing will have to be tweaked - and for now forwarding on construct is just
+ not important in benchmarks. ConstructVarargs will still do forwarding, just not inlined.
+
+ LoadVarargs: loads all elements out of an array onto the stack in a manner suitable for a varargs
+ call. This is used only when a varargs call (or construct) was inlined. The bytecode parser will
+ make room on the stack for the arguments, and will use LoadVarars to put those arguments into
+ place.
+
+ In the future, we can consider adding strength reductions like:
+
+ - If CallVarargs/ConstructVarargs see an array of known size with known elements, turn them into
+ Call/Construct.
+
+ - If CallVarargs/ConstructVarargs are passed an unmodified, unescaped Arguments object, then
+ turn them into CallForwardVarargs/ConstructForwardVarargs.
+
+ - If LoadVarargs sees an array of known size, then turn it into a sequence of GetByVals and
+ PutLocals.
+
+ - If LoadVarargs sees an unmodified, unescaped Arguments object, then turn it into something like
+ LoadForwardVarargs.
+
+ - If CallVarargs/ConstructVarargs/LoadVarargs see the result of a splice (or other Array
+ prototype function), then do the splice and varargs loading in one go (maybe via a new node
+ type).
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * assembler/MacroAssembler.h:
+ (JSC::MacroAssembler::rshiftPtr):
+ (JSC::MacroAssembler::urshiftPtr):
+ * assembler/MacroAssemblerARM64.h:
+ (JSC::MacroAssemblerARM64::urshift64):
+ * assembler/MacroAssemblerX86_64.h:
+ (JSC::MacroAssemblerX86_64::urshift64):
+ * assembler/X86Assembler.h:
+ (JSC::X86Assembler::shrq_i8r):
+ * bytecode/CallLinkInfo.h:
+ (JSC::CallLinkInfo::CallLinkInfo):
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeFor):
+ (JSC::CallLinkStatus::setProvenConstantCallee):
+ (JSC::CallLinkStatus::dump):
+ * bytecode/CallLinkStatus.h:
+ (JSC::CallLinkStatus::maxNumArguments):
+ (JSC::CallLinkStatus::setIsProved): Deleted.
+ * bytecode/CodeOrigin.cpp:
+ (WTF::printInternal):
+ * bytecode/CodeOrigin.h:
+ (JSC::InlineCallFrame::varargsKindFor):
+ (JSC::InlineCallFrame::specializationKindFor):
+ (JSC::InlineCallFrame::isVarargs):
+ (JSC::InlineCallFrame::isNormalCall): Deleted.
+ * bytecode/ExitKind.cpp:
+ (JSC::exitKindToString):
+ * bytecode/ExitKind.h:
+ * bytecode/ValueRecovery.cpp:
+ (JSC::ValueRecovery::dumpInContext):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGArgumentsSimplificationPhase.cpp:
+ (JSC::DFG::ArgumentsSimplificationPhase::run):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::flush):
+ (JSC::DFG::ByteCodeParser::addCall):
+ (JSC::DFG::ByteCodeParser::handleCall):
+ (JSC::DFG::ByteCodeParser::handleVarargsCall):
+ (JSC::DFG::ByteCodeParser::emitFunctionChecks):
+ (JSC::DFG::ByteCodeParser::inliningCost):
+ (JSC::DFG::ByteCodeParser::inlineCall):
+ (JSC::DFG::ByteCodeParser::attemptToInlineCall):
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ (JSC::DFG::ByteCodeParser::handleMinMax):
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
+ (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::removeLastNodeFromGraph): Deleted.
+ (JSC::DFG::ByteCodeParser::undoFunctionChecks): Deleted.
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGCapabilities.h:
+ (JSC::DFG::functionCapabilityLevel):
+ (JSC::DFG::mightCompileFunctionFor):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGCommon.cpp:
+ (WTF::printInternal):
+ * dfg/DFGCommon.h:
+ (JSC::DFG::canInline):
+ (JSC::DFG::leastUpperBound):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ (JSC::DFG::Graph::dumpBlockHeader):
+ (JSC::DFG::Graph::isLiveInBytecode):
+ (JSC::DFG::Graph::valueProfileFor):
+ (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::valueProfileFor): Deleted.
+ (JSC::DFG::Graph::methodOfGettingAValueProfileFor): Deleted.
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::compileExceptionHandlers):
+ (JSC::DFG::JITCompiler::link):
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasCallVarargsData):
+ (JSC::DFG::Node::callVarargsData):
+ (JSC::DFG::Node::hasLoadVarargsData):
+ (JSC::DFG::Node::loadVarargsData):
+ (JSC::DFG::Node::hasHeapPrediction):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+ (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::reifyInlinedCallFrames):
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGOperations.h:
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::dumpAndVerifyGraph):
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGPreciseLocalClobberize.h:
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::writeTop):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSSAConversionPhase.cpp:
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::isFlushed):
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+ (JSC::DFG::StackLayoutPhase::assign):
+ * dfg/DFGStrengthReductionPhase.cpp:
+ (JSC::DFG::StrengthReductionPhase::handleNode):
+ * dfg/DFGTypeCheckHoistingPhase.cpp:
+ (JSC::DFG::TypeCheckHoistingPhase::run):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validateCPS):
+ * ftl/FTLAbbreviations.h:
+ (JSC::FTL::functionType):
+ (JSC::FTL::buildCall):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLInlineCacheSize.cpp:
+ (JSC::FTL::sizeOfCall):
+ (JSC::FTL::sizeOfCallVarargs):
+ (JSC::FTL::sizeOfCallForwardVarargs):
+ (JSC::FTL::sizeOfConstructVarargs):
+ (JSC::FTL::sizeOfIn):
+ (JSC::FTL::sizeOfICFor):
+ (JSC::FTL::sizeOfCheckIn): Deleted.
+ * ftl/FTLInlineCacheSize.h:
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLJSCall.cpp:
+ (JSC::FTL::JSCall::JSCall):
+ * ftl/FTLJSCallBase.cpp:
+ * ftl/FTLJSCallBase.h:
+ * ftl/FTLJSCallVarargs.cpp: Added.
+ (JSC::FTL::JSCallVarargs::JSCallVarargs):
+ (JSC::FTL::JSCallVarargs::numSpillSlotsNeeded):
+ (JSC::FTL::JSCallVarargs::emit):
+ (JSC::FTL::JSCallVarargs::link):
+ * ftl/FTLJSCallVarargs.h: Added.
+ (JSC::FTL::JSCallVarargs::node):
+ (JSC::FTL::JSCallVarargs::stackmapID):
+ (JSC::FTL::JSCallVarargs::operator<):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentsLength):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
+ (JSC::FTL::LowerDFGToLLVM::compileLoadVarargs):
+ (JSC::FTL::LowerDFGToLLVM::compileIn):
+ (JSC::FTL::LowerDFGToLLVM::emitStoreBarrier):
+ (JSC::FTL::LowerDFGToLLVM::vmCall):
+ (JSC::FTL::LowerDFGToLLVM::vmCallNoExceptions):
+ (JSC::FTL::LowerDFGToLLVM::callCheck):
+ * ftl/FTLOutput.h:
+ (JSC::FTL::Output::call):
+ * ftl/FTLState.cpp:
+ (JSC::FTL::State::State):
+ * ftl/FTLState.h:
+ * interpreter/Interpreter.cpp:
+ (JSC::sizeOfVarargs):
+ (JSC::sizeFrameForVarargs):
+ * interpreter/Interpreter.h:
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::readInlinedFrame):
+ * jit/AssemblyHelpers.cpp:
+ (JSC::AssemblyHelpers::emitExceptionCheck):
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::addressFor):
+ (JSC::AssemblyHelpers::calleeFrameSlot):
+ (JSC::AssemblyHelpers::calleeArgumentSlot):
+ (JSC::AssemblyHelpers::calleeFrameTagSlot):
+ (JSC::AssemblyHelpers::calleeFramePayloadSlot):
+ (JSC::AssemblyHelpers::calleeArgumentTagSlot):
+ (JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
+ (JSC::AssemblyHelpers::calleeFrameCallerFrame):
+ (JSC::AssemblyHelpers::selectScratchGPR):
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/GPRInfo.h:
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+ * jit/JIT.h:
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ (JSC::JIT::compileOpCall):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ (JSC::JIT::compileOpCall):
+ * jit/JITOperations.h:
+ * jit/SetupVarargsFrame.cpp:
+ (JSC::emitSetupVarargsFrameFastCase):
+ * jit/SetupVarargsFrame.h:
+ * runtime/Arguments.h:
+ (JSC::Arguments::create):
+ (JSC::Arguments::registerArraySizeInBytes):
+ (JSC::Arguments::finishCreation):
+ * runtime/Options.h:
+ * tests/stress/construct-varargs-inline-smaller-Foo.js: Added.
+ (Foo):
+ (bar):
+ (checkEqual):
+ (test):
+ * tests/stress/construct-varargs-inline.js: Added.
+ (Foo):
+ (bar):
+ (checkEqual):
+ (test):
+ * tests/stress/construct-varargs-no-inline.js: Added.
+ (Foo):
+ (bar):
+ (checkEqual):
+ (test):
+ * tests/stress/get-argument-by-val-in-inlined-varargs-call-out-of-bounds.js: Added.
+ (foo):
+ (bar):
+ * tests/stress/get-argument-by-val-safe-in-inlined-varargs-call-out-of-bounds.js: Added.
+ (foo):
+ (bar):
+ * tests/stress/get-my-argument-by-val-creates-arguments.js: Added.
+ (blah):
+ (foo):
+ (bar):
+ (checkEqual):
+ (test):
+ * tests/stress/load-varargs-then-inlined-call-exit-in-foo.js: Added.
+ (foo):
+ (bar):
+ (checkEqual):
+ * tests/stress/load-varargs-then-inlined-call-inlined.js: Added.
+ (foo):
+ (bar):
+ (baz):
+ (checkEqual):
+ (test):
+ * tests/stress/load-varargs-then-inlined-call.js: Added.
+ (foo):
+ (bar):
+ (checkEqual):
+ (test):
+
+2015-02-17 Michael Saboff <msaboff@apple.com>
+
+ Unreviewed, Restoring the C LOOP insta-crash fix in r180184.
+
+ Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
+ After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
+
+ * llint/LowLevelInterpreter.asm: Fixed a typo.
+
+2015-02-18 Csaba Osztrogonác <ossy@webkit.org>
+
+ URTBF after r180258 to fix Windows build.
+
+ * runtime/MathCommon.cpp:
+ (JSC::mathPowInternal):
+
+2015-02-18 Joseph Pecoraro <pecoraro@apple.com>
+
+ REGRESSION(r180235): It broke the !ENABLE(PROMISES) build
+ https://bugs.webkit.org/show_bug.cgi?id=141746
+
+ Unreviewed build fix.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::getInternalProperties):
+ Wrap JSPromise related code in ENABLE(PROMISES) guard.
+
+2015-02-18 Benjamin Poulain <benjamin@webkit.org>
+
+ Fix the C-Loop LLInt build
+ https://bugs.webkit.org/show_bug.cgi?id=141618
+
+ Reviewed by Filip Pizlo.
+
+ I broke C-Loop when moving the common code of pow()
+ to JITOperations because that file is #ifdefed out
+ when the JITs are disabled.
+
+ It would be weird to move it back to MathObject since
+ the function needs to know about the calling conventions.
+
+ To avoid making a mess, I just gave the function its own file
+ that is used by both the runtime and the JIT.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGAbstractInterpreterInlines.h:
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * runtime/MathCommon.cpp: Added.
+ (JSC::fdlibmScalbn):
+ (JSC::fdlibmPow):
+ (JSC::isDenormal):
+ (JSC::isEdgeCase):
+ (JSC::mathPowInternal):
+ (JSC::operationMathPow):
+ * runtime/MathCommon.h: Added.
+ * runtime/MathObject.cpp:
+
+2015-02-17 Benjamin Poulain <bpoulain@apple.com>
+
+ Clean up OSRExit's considerAddingAsFrequentExitSite()
+ https://bugs.webkit.org/show_bug.cgi?id=141690
+
+ Reviewed by Anders Carlsson.
+
+ Looks like some code was removed from CodeBlock::tallyFrequentExitSites()
+ and the OSRExit were left untouched.
+
+ This patch cleans up the two loops and remove the boolean return
+ on considerAddingAsFrequentExitSite().
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::tallyFrequentExitSites):
+ * dfg/DFGOSRExit.h:
+ (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
+ * dfg/DFGOSRExitBase.cpp:
+ (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
+ * dfg/DFGOSRExitBase.h:
+ (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
+ * ftl/FTLOSRExit.h:
+ (JSC::FTL::OSRExit::considerAddingAsFrequentExitSite):
+
+2015-02-17 Alexey Proskuryakov <ap@apple.com>
+
+ Debug build fix after r180247.
+
+ * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::loweringFailed):
+
+2015-02-17 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r180184.
+ https://bugs.webkit.org/show_bug.cgi?id=141733
+
+ Caused infinite recursion on js/function-apply-aliased.html
+ (Requested by ap_ on #webkit).
+
+ Reverted changeset:
+
+ "REGRESSION(r180060): C Loop crashes"
+ https://bugs.webkit.org/show_bug.cgi?id=141671
+ http://trac.webkit.org/changeset/180184
+
+2015-02-17 Michael Saboff <msaboff@apple.com>
+
+ CrashTracer: DFG_CRASH beneath JSC::FTL::LowerDFGToLLVM::compileNode
+ https://bugs.webkit.org/show_bug.cgi?id=141730
+
+ Reviewed by Geoffrey Garen.
+
+ Added a new failure handler, loweringFailed(), to LowerDFGToLLVM that reports failures
+ while processing DFG lowering. For debug builds, the failures are logged identical
+ to the way the DFG_CRASH() reports them. For release builds, the failures are reported
+ and that FTL compilation is terminated, but the process is allowed to continue.
+ Wrapped calls to loweringFailed() in a macro LOWERING_FAILED so the function and
+ line number are reported at the point of the inconsistancy.
+
+ Converted instances of DFG_CRASH to LOWERING_FAILED.
+
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl): Added lowerDFGToLLVM() failure check that
+ will fail the FTL compile.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
+ Added new member variable, m_loweringSucceeded, to stop compilation on the first
+ reported failure.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ * ftl/FTLLowerDFGToLLVM.h:
+ Added check for compilation failures and now report those failures via a boolean
+ return value.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
+ (JSC::FTL::LowerDFGToLLVM::compilePhi):
+ (JSC::FTL::LowerDFGToLLVM::compileDoubleRep):
+ (JSC::FTL::LowerDFGToLLVM::compileValueRep):
+ (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
+ (JSC::FTL::LowerDFGToLLVM::compilePutLocal):
+ (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
+ (JSC::FTL::LowerDFGToLLVM::compileArithMul):
+ (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
+ (JSC::FTL::LowerDFGToLLVM::compileArithMod):
+ (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
+ (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
+ (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
+ (JSC::FTL::LowerDFGToLLVM::compileGetById):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
+ (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
+ (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayPush):
+ (JSC::FTL::LowerDFGToLLVM::compileArrayPop):
+ (JSC::FTL::LowerDFGToLLVM::compileNewArray):
+ (JSC::FTL::LowerDFGToLLVM::compileToString):
+ (JSC::FTL::LowerDFGToLLVM::compileMakeRope):
+ (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
+ (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
+ (JSC::FTL::LowerDFGToLLVM::compileSwitch):
+ (JSC::FTL::LowerDFGToLLVM::compare):
+ (JSC::FTL::LowerDFGToLLVM::boolify):
+ (JSC::FTL::LowerDFGToLLVM::opposite):
+ (JSC::FTL::LowerDFGToLLVM::lowJSValue):
+ (JSC::FTL::LowerDFGToLLVM::speculate):
+ (JSC::FTL::LowerDFGToLLVM::isArrayType):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
+ (JSC::FTL::LowerDFGToLLVM::setInt52):
+ Changed DFG_CRASH() to LOWERING_FAILED(). Updated related control flow as appropriate.
+
+ (JSC::FTL::LowerDFGToLLVM::loweringFailed): New error reporting member function.
+
+2015-02-17 Filip Pizlo <fpizlo@apple.com>
+
+ StackLayoutPhase should use CodeBlock::usesArguments rather than FunctionExecutable::usesArguments
+ https://bugs.webkit.org/show_bug.cgi?id=141721
+ rdar://problem/17198633
+
+ Reviewed by Michael Saboff.
+
+ I've seen cases where the two are out of sync. We know we can trust the CodeBlock::usesArguments because
+ we use it everywhere else.
+
+ No test because I could never reproduce the crash.
+
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::usesArguments):
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+
+2015-02-16 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Improved Console Support for Bound Functions
+ https://bugs.webkit.org/show_bug.cgi?id=141635
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::getInternalProperties):
+ Expose internal properties of a JSBoundFunction.
+
+2015-02-16 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ES6: Improved Console Support for Promise Objects
+ https://bugs.webkit.org/show_bug.cgi?id=141634
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getInternalProperties):
+ * inspector/InjectedScriptSource.js:
+ Include internal properties in previews. Share code
+ with normal internal property handling.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::constructInternalProperty):
+ (Inspector::JSInjectedScriptHost::getInternalProperties):
+ Provide internal state of Promises.
+
+ * inspector/protocol/Runtime.json:
+ Provide an optional field to distinguish if a PropertyPreview
+ is for an Internal property or not.
+
+2015-02-17 Filip Pizlo <fpizlo@apple.com>
+
+ Throwing from an FTL call IC slow path may result in tag registers being clobbered on 64-bit CPUs
+ https://bugs.webkit.org/show_bug.cgi?id=141717
+ rdar://problem/19863382
+
+ Reviewed by Geoffrey Garen.
+
+ The best solution is to ensure that the engine catching an exception restores tag registers.
+
+ Each of these new test cases reliably crashed prior to this patch and they don't crash at all now.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_catch):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * tests/stress/throw-from-ftl-call-ic-slow-path-cells.js: Added.
+ * tests/stress/throw-from-ftl-call-ic-slow-path-undefined.js: Added.
+ * tests/stress/throw-from-ftl-call-ic-slow-path.js: Added.
+
+2015-02-17 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Add the necessary setupArgumentsWithExecState after bug141332
+ https://bugs.webkit.org/show_bug.cgi?id=141714
+
+ Reviewed by Michael Saboff.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+
+2015-02-15 Sam Weinig <sam@webkit.org>
+
+ Add experimental <attachment> element support
+ https://bugs.webkit.org/show_bug.cgi?id=141626
+
+ Reviewed by Tim Horton.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-02-16 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(r180060): C Loop crashes
+ https://bugs.webkit.org/show_bug.cgi?id=141671
+
+ Reviewed by Geoffrey Garen.
+
+ Fixed a typo that only affected the C Loop in the prologue() macro in LowLevelInterpreter.asm.
+ After the stackHeightOKGetCodeBlock label, codeBlockSetter(t1) should be codeBlockGetter(t1).
+ Fixed the processing of an out of stack exception in llint_stack_check to not get the caller's
+ frame. This isn't needed, since this helper is only called to check the stack on entry. Any
+ exception will be handled by a call ancestor.
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::llint_stack_check): Changed to use the current frame for processing an exception.
+ * llint/LowLevelInterpreter.asm: Fixed a typo.
+
+2015-02-16 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Scope details sidebar should label objects with constructor names
+ https://bugs.webkit.org/show_bug.cgi?id=139449
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::internalConstructorName):
+ * runtime/Structure.cpp:
+ (JSC::Structure::toStructureShape):
+ Share calculatedClassName.
+
+ * runtime/JSObject.h:
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::calculatedClassName):
+ Elaborate on a way to get an Object's class name.
+
+2015-02-16 Filip Pizlo <fpizlo@apple.com>
+
+ DFG SSA should use GetLocal for arguments, and the GetArgument node type should be removed
+ https://bugs.webkit.org/show_bug.cgi?id=141623
+
+ Reviewed by Oliver Hunt.
+
+ During development of https://bugs.webkit.org/show_bug.cgi?id=141332, I realized that I
+ needed to use GetArgument for loading something that has magically already appeared on the
+ stack, so currently trunk sort of allows this. But then I realized three things:
+
+ - A GetArgument with a non-JSValue flush format means speculating that the value on the
+ stack obeys that format, rather than just assuming that that it already has that format.
+ In bug 141332, I want it to assume rather than speculate. That also happens to be more
+ intuitive; I don't think I was wrong to expect that.
+
+ - The node I really want is GetLocal. I'm just getting the value of the local and I don't
+ want to do anything else.
+
+ - Maybe it would be easier if we just used GetLocal for all of the cases where we currently
+ use GetArgument.
+
+ This changes the FTL to do argument speculations in the prologue just like the DFG does.
+ This brings some consistency to our system, and allows us to get rid of the GetArgument
+ node. The speculations that the FTL must do are now made explicit in the m_argumentFormats
+ vector in DFG::Graph. This has natural DCE behavior: even if all uses of the argument are
+ dead we will still speculate. We already have safeguards to ensure we only speculate if
+ there are uses that benefit from speculation (which is a much more conservative criterion
+ than DCE).
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDCEPhase.cpp:
+ (JSC::DFG::DCEPhase::run):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGFlushFormat.h:
+ (JSC::DFG::typeFilterFor):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::valueProfileFor):
+ (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::initialize):
+ * dfg/DFGNode.cpp:
+ (JSC::DFG::Node::hasVariableAccessData):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
+ (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
+ (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGPutLocalSinkingPhase.cpp:
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
+ (JSC::FTL::LowerDFGToLLVM::compileGetArgument): Deleted.
+ * tests/stress/dead-speculating-argument-use.js: Added.
+ (foo):
+ (o.valueOf):
+
+2015-02-15 Filip Pizlo <fpizlo@apple.com>
+
+ Rare case profiling should actually work
+ https://bugs.webkit.org/show_bug.cgi?id=141632
+
+ Reviewed by Michael Saboff.
+
+ This simple adjustment appears to be a 2% speed-up on Octane. Over time, the slow case
+ heuristic has essentially stopped working because the typical execution count threshold for a
+ bytecode instruction is around 66 while the slow case threshold is 100: virtually
+ guaranteeing that the DFG will never think that a bytecode instruction has taken the slow
+ case even if it took it every single time. So, this changes the slow case threshold to 20.
+
+ I checked if we could lower this down further, like to 10. That is worse than 20, and about
+ as bad as 100.
+
+ * runtime/Options.h:
+
+2015-02-15 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: remove unused XHR replay code
+ https://bugs.webkit.org/show_bug.cgi?id=141622
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Network.json: remove XHR replay methods.
+
+2015-02-15 David Kilzer <ddkilzer@apple.com>
+
+ REGRESSION (r180082): WebCore Debug builds fail on Mavericks due to weak export symbols
+ <http://webkit.org/b/141607>
+
+ More work towards fixing the Mavericks Debug build.
+
+ * inspector/ScriptDebugServer.h:
+ (Inspector::ScriptDebugServer::Task):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ (Inspector::InspectorDebuggerAgent::Listener):
+ - Remove subclass exports. They did not help.
+
+ * runtime/JSCJSValue.h:
+ (JSC::JSValue::toFloat): Do not mark inline method for export.
+
+2015-02-09 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: remove some unnecessary Inspector prefixes from class names in Inspector namespace
+ https://bugs.webkit.org/show_bug.cgi?id=141372
+
+ Reviewed by Joseph Pecoraro.
+
+ * inspector/ConsoleMessage.cpp:
+ (Inspector::ConsoleMessage::addToFrontend):
+ (Inspector::ConsoleMessage::updateRepeatCountInConsole):
+ * inspector/ConsoleMessage.h:
+ * inspector/InspectorAgentBase.h:
+ * inspector/InspectorAgentRegistry.cpp:
+ (Inspector::AgentRegistry::AgentRegistry):
+ (Inspector::AgentRegistry::append):
+ (Inspector::AgentRegistry::appendExtraAgent):
+ (Inspector::AgentRegistry::didCreateFrontendAndBackend):
+ (Inspector::AgentRegistry::willDestroyFrontendAndBackend):
+ (Inspector::AgentRegistry::discardAgents):
+ (Inspector::InspectorAgentRegistry::InspectorAgentRegistry): Deleted.
+ (Inspector::InspectorAgentRegistry::append): Deleted.
+ (Inspector::InspectorAgentRegistry::appendExtraAgent): Deleted.
+ (Inspector::InspectorAgentRegistry::didCreateFrontendAndBackend): Deleted.
+ (Inspector::InspectorAgentRegistry::willDestroyFrontendAndBackend): Deleted.
+ (Inspector::InspectorAgentRegistry::discardAgents): Deleted.
+ * inspector/InspectorAgentRegistry.h:
+ * inspector/InspectorBackendDispatcher.cpp:
+ (Inspector::BackendDispatcher::CallbackBase::CallbackBase):
+ (Inspector::BackendDispatcher::CallbackBase::isActive):
+ (Inspector::BackendDispatcher::CallbackBase::sendFailure):
+ (Inspector::BackendDispatcher::CallbackBase::sendIfActive):
+ (Inspector::BackendDispatcher::create):
+ (Inspector::BackendDispatcher::registerDispatcherForDomain):
+ (Inspector::BackendDispatcher::dispatch):
+ (Inspector::BackendDispatcher::sendResponse):
+ (Inspector::BackendDispatcher::reportProtocolError):
+ (Inspector::BackendDispatcher::getInteger):
+ (Inspector::BackendDispatcher::getDouble):
+ (Inspector::BackendDispatcher::getString):
+ (Inspector::BackendDispatcher::getBoolean):
+ (Inspector::BackendDispatcher::getObject):
+ (Inspector::BackendDispatcher::getArray):
+ (Inspector::BackendDispatcher::getValue):
+ (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase): Deleted.
+ (Inspector::InspectorBackendDispatcher::CallbackBase::isActive): Deleted.
+ (Inspector::InspectorBackendDispatcher::CallbackBase::sendFailure): Deleted.
+ (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive): Deleted.
+ (Inspector::InspectorBackendDispatcher::create): Deleted.
+ (Inspector::InspectorBackendDispatcher::registerDispatcherForDomain): Deleted.
+ (Inspector::InspectorBackendDispatcher::dispatch): Deleted.
+ (Inspector::InspectorBackendDispatcher::sendResponse): Deleted.
+ (Inspector::InspectorBackendDispatcher::reportProtocolError): Deleted.
+ (Inspector::InspectorBackendDispatcher::getInteger): Deleted.
+ (Inspector::InspectorBackendDispatcher::getDouble): Deleted.
+ (Inspector::InspectorBackendDispatcher::getString): Deleted.
+ (Inspector::InspectorBackendDispatcher::getBoolean): Deleted.
+ (Inspector::InspectorBackendDispatcher::getObject): Deleted.
+ (Inspector::InspectorBackendDispatcher::getArray): Deleted.
+ (Inspector::InspectorBackendDispatcher::getValue): Deleted.
+ * inspector/InspectorBackendDispatcher.h:
+ (Inspector::SupplementalBackendDispatcher::SupplementalBackendDispatcher):
+ (Inspector::SupplementalBackendDispatcher::~SupplementalBackendDispatcher):
+ (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher): Deleted.
+ (Inspector::InspectorSupplementalBackendDispatcher::~InspectorSupplementalBackendDispatcher): Deleted.
+ * inspector/InspectorFrontendChannel.h:
+ (Inspector::FrontendChannel::~FrontendChannel):
+ (Inspector::InspectorFrontendChannel::~InspectorFrontendChannel): Deleted.
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+ (Inspector::JSGlobalObjectInspectorController::globalObjectDestroyed):
+ (Inspector::JSGlobalObjectInspectorController::connectFrontend):
+ (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
+ (Inspector::JSGlobalObjectInspectorController::dispatchMessageFromFrontend):
+ (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/agents/InspectorAgent.cpp:
+ (Inspector::InspectorAgent::didCreateFrontendAndBackend):
+ (Inspector::InspectorAgent::willDestroyFrontendAndBackend):
+ * inspector/agents/InspectorAgent.h:
+ * inspector/agents/InspectorConsoleAgent.cpp:
+ (Inspector::InspectorConsoleAgent::didCreateFrontendAndBackend):
+ (Inspector::InspectorConsoleAgent::willDestroyFrontendAndBackend):
+ * inspector/agents/InspectorConsoleAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::didCreateFrontendAndBackend):
+ (Inspector::InspectorDebuggerAgent::willDestroyFrontendAndBackend):
+ (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
+ (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
+ (Inspector::InspectorDebuggerAgent::pause):
+ (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
+ (Inspector::InspectorDebuggerAgent::didPause):
+ (Inspector::InspectorDebuggerAgent::breakProgram):
+ (Inspector::InspectorDebuggerAgent::clearBreakDetails):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
+ (Inspector::JSGlobalObjectRuntimeAgent::didCreateFrontendAndBackend):
+ (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend):
+ * inspector/agents/JSGlobalObjectRuntimeAgent.h:
+ * inspector/augmentable/AlternateDispatchableAgent.h:
+ * inspector/augmentable/AugmentableInspectorController.h:
+ * inspector/remote/RemoteInspectorDebuggable.h:
+ * inspector/remote/RemoteInspectorDebuggableConnection.h:
+ * inspector/scripts/codegen/cpp_generator.py:
+ (CppGenerator.cpp_type_for_formal_out_parameter):
+ (CppGenerator.cpp_type_for_stack_out_parameter):
+ * inspector/scripts/codegen/cpp_generator_templates.py:
+ (AlternateBackendDispatcher):
+ (Alternate):
+ (void):
+ (AlternateInspectorBackendDispatcher): Deleted.
+ (AlternateInspector): Deleted.
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
+ (CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.Alternate):
+ (CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
+ (CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector): Deleted.
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
+ (CppBackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
+ (CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
+ (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
+ (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
+ * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ * runtime/JSGlobalObjectDebuggable.cpp:
+ (JSC::JSGlobalObjectDebuggable::connect):
+ (JSC::JSGlobalObjectDebuggable::disconnect):
+ * runtime/JSGlobalObjectDebuggable.h:
+
+2015-02-14 David Kilzer <ddkilzer@apple.com>
+
+ REGRESSION (r180082): WebCore Debug builds fail on Mavericks due to weak export symbols
+ <http://webkit.org/b/141607>
+
+ Work towards fixing the Mavericks Debug build.
+
+ * inspector/ScriptDebugServer.h:
+ (Inspector::ScriptDebugServer::Task): Export class.
+ * inspector/agents/InspectorDebuggerAgent.h:
+ (Inspector::InspectorDebuggerAgent::Listener): Export class.
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::setConsoleClient): Do not mark inline
+ method for export.
+
+2015-02-14 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Symbol RemoteObject should not send sub-type
+ https://bugs.webkit.org/show_bug.cgi?id=141604
+
+ Reviewed by Brian Burg.
+
+ * inspector/InjectedScriptSource.js:
+
+2015-02-13 Benjamin Poulain <bpoulain@apple.com>
+
+ Attempt to fix 32bits build after r180098
+
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ I copied the attribute from the MathObject version of that function when I moved
+ it over. DFG has no version of a function call taking those attributes.
+
+2015-02-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ JSContext Inspector: Do not stash console messages for non-debuggable JSContext
+ https://bugs.webkit.org/show_bug.cgi?id=141589
+
+ Reviewed by Timothy Hatcher.
+
+ Consider developer extras disabled for JSContext inspection if the
+ RemoteInspector server is not enabled (typically a non-debuggable
+ process rejected by webinspectord) or if remote debugging on the
+ JSContext was explicitly disabled via SPI.
+
+ When developer extras are disabled, console message will not be stashed.
+
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::developerExtrasEnabled):
+ * inspector/JSGlobalObjectInspectorController.h:
+
+2015-02-13 Benjamin Poulain <bpoulain@apple.com>
+
+ Add a DFG node for the Pow Intrinsics
+ https://bugs.webkit.org/show_bug.cgi?id=141540
+
+ Reviewed by Filip Pizlo.
+
+ Add a DFG Node for PowIntrinsic. This patch covers the basic cases
+ need to avoid massive regression. I will iterate over the node to cover
+ the missing types.
+
+ With this patch I get the following progressions on benchmarks:
+ -LongSpider's math-partial-sums: +5%.
+ -Kraken's imaging-darkroom: +17%
+ -AsmBench's cray.c: +6.6%
+ -CompressionBench: +2.2% globally.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ Cover a couple of trivial cases:
+ -If the exponent is zero, the result is always one, regardless of the base.
+ -If both arguments are constants, compute the result at compile time.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ We only support 2 basic cases at this time:
+ -Math.pow(double, int)
+ -Math.pow(double, double).
+
+ I'll cover Math.pow(int, int) in a follow up.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToArithSqrt):
+ (JSC::DFG::Node::arithNodeFlags):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::compileArithPowIntegerFastPath):
+ (JSC::DFG::SpeculativeJIT::compileArithPow):
+ * 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):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::validate):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLIntrinsicRepository.h:
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileArithPow):
+ * ftl/FTLOutput.h:
+ (JSC::FTL::Output::doublePow):
+ (JSC::FTL::Output::doublePowi):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * runtime/MathObject.cpp:
+ (JSC::mathProtoFuncPow):
+ (JSC::isDenormal): Deleted.
+ (JSC::isEdgeCase): Deleted.
+ (JSC::mathPow): Deleted.
+
+ * tests/stress/math-pow-basics.js: Added.
+ * tests/stress/math-pow-integer-exponent-fastpath.js: Added.
+ * tests/stress/math-pow-nan-behaviors.js: Added.
+ * tests/stress/math-pow-with-constants.js: Added.
+ Start some basic testing of Math.pow().
+ Due to the various transform, the value change when the code tiers up,
+ I covered this by checking for approximate values.
+
+2015-02-13 Benjamin Poulain <bpoulain@apple.com>
+
+ ArithSqrt should not be conditional on supportsFloatingPointSqrt
+ https://bugs.webkit.org/show_bug.cgi?id=141546
+
+ Reviewed by Geoffrey Garen and Filip Pizlo.
+
+ Just fallback to the function call in the DFG codegen.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleIntrinsic):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileArithSqrt):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * tests/stress/math-sqrt-basics.js: Added.
+ Basic coverage.
+
+ * tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js: Added.
+ Same tests but forcing the function call.
+
+2015-02-13 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(r180060) New js/regress-141098 test crashes when LLInt is disabled.
+ https://bugs.webkit.org/show_bug.cgi?id=141577
+
+ Reviewed by Benjamin Poulain.
+
+ Changed the prologue of the baseline JIT to check for stack space for all
+ types of code blocks. Previously, it was only checking Function. Now
+ it checks Program and Eval as well.
+
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+
+2015-02-13 Benjamin Poulain <bpoulain@apple.com>
+
+ Generate incq instead of addq when the immediate value is one
+ https://bugs.webkit.org/show_bug.cgi?id=141548
+
+ Reviewed by Gavin Barraclough.
+
+ JSC emits "addq #1 (rXX)" *a lot*.
+ This patch replace that by incq, which is one byte shorter
+ and is the adviced form.
+
+ Sunspider: +0.47%
+ Octane: +0.28%
+ Kraken: +0.44%
+ AsmBench, CompressionBench: neutral.
+
+ * assembler/MacroAssemblerX86_64.h:
+ (JSC::MacroAssemblerX86_64::add64):
+ * assembler/X86Assembler.h:
+ (JSC::X86Assembler::incq_m):
+
+2015-02-13 Benjamin Poulain <benjamin@webkit.org>
+
+ Little clean up of Bytecode Generator's Label
+ https://bugs.webkit.org/show_bug.cgi?id=141557
+
+ Reviewed by Michael Saboff.
+
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/BytecodeGenerator.cpp:
+ Label was a friend of BytecodeGenerator in order to access
+ m_instructions. There is no need for that, BytecodeGenerator
+ has a public getter.
+
+ * bytecompiler/Label.h:
+ (JSC::Label::Label):
+ (JSC::Label::setLocation):
+ (JSC::BytecodeGenerator::newLabel):
+ Make it explicit that the generator must exist.
+
+2015-02-13 Michael Saboff <msaboff@apple.com>
+
+ Google doc spreadsheet reproducibly crashes when sorting
+ https://bugs.webkit.org/show_bug.cgi?id=141098
+
+ Reviewed by Oliver Hunt.
+
+ Moved the stack check to before the callee registers are allocated in the
+ prologue() by movving it from the functionInitialization() macro. This
+ way we can check the stack before moving the stack pointer, avoiding a
+ crash during a "call" instruction. Before this change, we weren't even
+ checking the stack for program and eval execution.
+
+ Made a couple of supporting changes.
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::llint_stack_check): We can't just go up one frame as we
+ may be processing an exception to an entry frame.
+
+ * llint/LowLevelInterpreter.asm:
+
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ (llint_throw_from_slow_path_trampoline): Changed method to get the vm
+ from the code block to not use the codeBlock, since we may need to
+ continue from an exception in a native function.
+
+2015-02-12 Benjamin Poulain <benjamin@webkit.org>
+
+ Simplify the initialization of BytecodeGenerator a bit
+ https://bugs.webkit.org/show_bug.cgi?id=141505
+
+ Reviewed by Anders Carlsson.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * bytecompiler/BytecodeGenerator.h:
+ Setup the default initialization at the declaration level
+ instead of the constructor.
+
+ Also made m_scopeNode and m_codeType const to make it explicit
+ that they are invariant after construction.
+
+ * parser/Nodes.cpp:
+ * runtime/Executable.cpp:
+ Remove 2 useless #includes.
+
+2015-02-12 Benjamin Poulain <benjamin@webkit.org>
+
+ Move the generators for GetScope and SkipScope to the common core in DFGSpeculativeJIT
+ https://bugs.webkit.org/show_bug.cgi?id=141506
+
+ Reviewed by Michael Saboff.
+
+ The generators for the nodes GetScope and SkipScope were
+ completely identical between 32 and 64bits.
+
+ This patch moves the duplicated code to DFGSpeculativeJIT.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileGetScope):
+ (JSC::DFG::SpeculativeJIT::compileSkipScope):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+
+2015-02-11 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] [64-bit] Work around MSVC2013 Runtime Bug
+ https://bugs.webkit.org/show_bug.cgi?id=141498
+ <rdar://problem/19803642>
+
+ Reviewed by Anders Carlsson.
+
+ Disable FMA3 instruction use in the MSVC math library to
+ work around a VS2013 runtime crash. We can remove this
+ workaround when we switch to VS2015.
+
+ * API/tests/testapi.c: Call _set_FMA3_enable(0) to disable
+ FMA3 support.
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add new files.
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
+ * JavaScriptCore.vcxproj/JavaScriptCoreDLL.cpp: Added.
+ * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Call _set_FMA3_enable(0)
+ to disable FMA3 support.
+ * jsc.cpp: Ditto.
+ * testRegExp.cpp: Ditto.
+
+2015-02-11 Filip Pizlo <fpizlo@apple.com>
+
+ The callee frame helpers in DFG::SpeculativeJIT should be available to other JITs
+ https://bugs.webkit.org/show_bug.cgi?id=141493
+
+ Reviewed by Michael Saboff.
+
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::calleeFrameSlot): Deleted.
+ (JSC::DFG::SpeculativeJIT::calleeArgumentSlot): Deleted.
+ (JSC::DFG::SpeculativeJIT::calleeFrameTagSlot): Deleted.
+ (JSC::DFG::SpeculativeJIT::calleeFramePayloadSlot): Deleted.
+ (JSC::DFG::SpeculativeJIT::calleeArgumentTagSlot): Deleted.
+ (JSC::DFG::SpeculativeJIT::calleeArgumentPayloadSlot): Deleted.
+ (JSC::DFG::SpeculativeJIT::calleeFrameCallerFrame): Deleted.
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::calleeFrameSlot):
+ (JSC::AssemblyHelpers::calleeArgumentSlot):
+ (JSC::AssemblyHelpers::calleeFrameTagSlot):
+ (JSC::AssemblyHelpers::calleeFramePayloadSlot):
+ (JSC::AssemblyHelpers::calleeArgumentTagSlot):
+ (JSC::AssemblyHelpers::calleeArgumentPayloadSlot):
+ (JSC::AssemblyHelpers::calleeFrameCallerFrame):
+
+2015-02-11 Filip Pizlo <fpizlo@apple.com>
+
+ SetupVarargsFrame should not assume that an inline stack frame would have identical layout to a normal stack frame
+ https://bugs.webkit.org/show_bug.cgi?id=141485
+
+ Reviewed by Oliver Hunt.
+
+ The inlineStackOffset argument was meant to make it easy for the DFG to use this helper for
+ vararg calls from inlined code, but that doesn't work since the DFG inline call frame
+ doesn't actually put the argument count at the JSStack::ArgumentCount offset. In fact there
+ is really no such thing as an inlineStackOffset except when we OSR exit; while the code is
+ running the stack layout is compacted so that the stackOffset is not meaningful.
+
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/SetupVarargsFrame.cpp:
+ (JSC::emitSetupVarargsFrameFastCase):
+ * jit/SetupVarargsFrame.h:
+
+2015-02-10 Filip Pizlo <fpizlo@apple.com>
+
+ Split FTL::JSCall into the part that knows about call inline caching and the part that interacts with LLVM patchpoints
+ https://bugs.webkit.org/show_bug.cgi?id=141455
+
+ Reviewed by Mark Lam.
+
+ The newly introduced FTL::JSCallBase can be used to build other things, like the FTL portion
+ of https://bugs.webkit.org/show_bug.cgi?id=141332.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CallLinkInfo.h:
+ (JSC::CallLinkInfo::specializationKindFor):
+ (JSC::CallLinkInfo::specializationKind):
+ * ftl/FTLJSCall.cpp:
+ (JSC::FTL::JSCall::JSCall):
+ (JSC::FTL::JSCall::emit): Deleted.
+ (JSC::FTL::JSCall::link): Deleted.
+ * ftl/FTLJSCall.h:
+ * ftl/FTLJSCallBase.cpp: Added.
+ (JSC::FTL::JSCallBase::JSCallBase):
+ (JSC::FTL::JSCallBase::emit):
+ (JSC::FTL::JSCallBase::link):
+ * ftl/FTLJSCallBase.h: Added.
+
+2015-02-10 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix build.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+
+2015-02-10 Filip Pizlo <fpizlo@apple.com>
+
+ op_call_varargs should only load the length once
+ https://bugs.webkit.org/show_bug.cgi?id=141440
+ rdar://problem/19761683
+
+ Reviewed by Michael Saboff.
+
+ Refactors the pair of calls that set up the varargs frame so that the first call returns the
+ length, and the second call uses the length returned by the first one. It turns out that this
+ gave me an opportunity to shorten a lot of the code.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::sizeFrameForVarargs):
+ (JSC::loadVarargs):
+ (JSC::setupVarargsFrame):
+ (JSC::setupVarargsFrameAndSetThis):
+ * interpreter/Interpreter.h:
+ (JSC::calleeFrameForVarargs):
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/JIT.h:
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * jit/SetupVarargsFrame.cpp:
+ (JSC::emitSetVarargsFrame):
+ (JSC::emitSetupVarargsFrameFastCase):
+ * jit/SetupVarargsFrame.h:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::copyToArguments):
+ * runtime/Arguments.h:
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::copyToArguments):
+ * runtime/JSArray.h:
+ * runtime/VM.h:
+ * tests/stress/call-varargs-length-effects.js: Added.
+ (foo):
+ (bar):
+
+2015-02-10 Michael Saboff <msaboff@apple.com>
+
+ Crash in JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq
+ https://bugs.webkit.org/show_bug.cgi?id=139398
+
+ Reviewed by Filip Pizlo.
+
+ Due to CFA analysis, the CompareStrictEq node was determined to be unreachable, but later
+ was determined to be reachable. When we go to lower to LLVM, the edges for the CompareStrictEq
+ node are UntypedUse which we can't compile. Fixed this by checking that the IR before
+ lowering can still be handled by the FTL.
+
+ Had to add GetArgument as a node that the FTL can compile as the SSA conversion phase converts
+ a SetArgument to a GetArgument. Before this change FTL::canCompile() would never see a GetArgument
+ node. With the check right before lowering, we see this node.
+
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl): Added a final FTL::canCompile() check before lowering
+ to verify that after all the transformations we still have valid IR for the FTL.
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile): Added GetArgument as a node the FTL can compile.
+
+2015-02-10 Filip Pizlo <fpizlo@apple.com>
+
+ Remove unused DFG::SpeculativeJIT::calleeFrameOffset().
+
+ Rubber stamped by Michael Saboff.
+
+ Not only was this not used, I believe that the math was wrong. The callee frame doesn't
+ actually land past m_nextMachineLocal; instead it lands just below wherever we put SP and
+ that decision is made elsewhere. Also, it makes no sense to subtract 1 from
+ m_nextMachineLocal when trying to deduce the number of in-use stack slots.
+
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::calleeFrameOffset): Deleted.
+
+2015-02-10 Saam Barati <saambarati1@gmail.com>
+
+ Parser::parseVarDeclarationList gets the wrong JSToken for the last identifier
+ https://bugs.webkit.org/show_bug.cgi?id=141272
+
+ Reviewed by Oliver Hunt.
+
+ This patch fixes a bug where the wrong text location would be
+ assigned to a variable declaration inside a ForIn/ForOf loop.
+ It also fixes a bug in the type profiler where the type profiler
+ emits the wrong text offset for a ForIn loop's variable declarator
+ when it's not a pattern node.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ForInNode::emitLoopHeader):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseVarDeclarationList):
+ * tests/typeProfiler/loop.js:
+ (testForIn):
+ (testForOf):
+
+2015-02-09 Saam Barati <saambarati1@gmail.com>
+
+ JSC's Type Profiler doesn't profile the type of the looping variable in ForOf/ForIn loops
+ https://bugs.webkit.org/show_bug.cgi?id=141241
+
+ Reviewed by Filip Pizlo.
+
+ Type information is now recorded for ForIn and ForOf statements.
+ It was an oversight to not have these statements profiled before.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ForInNode::emitLoopHeader):
+ (JSC::ForOfNode::emitBytecode):
+ * tests/typeProfiler/loop.js: Added.
+ (testForIn):
+ (testForOf):
+
+2015-02-09 Filip Pizlo <fpizlo@apple.com>
+
+ DFG::StackLayoutPhase should always set the scopeRegister to VirtualRegister() because the DFG doesn't do anything to make its value valid
+ https://bugs.webkit.org/show_bug.cgi?id=141412
+
+ Reviewed by Michael Saboff.
+
+ StackLayoutPhase was attempting to ensure that the register that
+ CodeBlock::scopeRegister() points to is the right one for the DFG. But the DFG did nothing
+ else to maintain the validity of the scopeRegister(). It wasn't captured as far as I can
+ tell. StackLayoutPhase didn't explicitly mark it live. PreciseLocalClobberize didn't mark
+ it as being live. So, by the time we got here the register referred to by
+ CodeBlock::scopeRegister() would have been junk. Moreover, CodeBlock::scopeRegister() was
+ not used for DFG code blocks, and was hardly ever used outside of bytecode generation.
+
+ So, this patch just removes the code to manipulate this field and replaces it with an
+ unconditional setScopeRegister(VirtualRegister()). Setting it to the invalid register
+ ensures that any attempst to read the scopeRegister in a DFG or FTL frame immediately
+ punts.
+
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+
+2015-02-09 Filip Pizlo <fpizlo@apple.com>
+
+ Varargs frame set-up should be factored out for use by other JITs
+ https://bugs.webkit.org/show_bug.cgi?id=141388
+
+ Reviewed by Michael Saboff.
+
+ Previously the code that dealt with varargs always assumed that we were setting up a varargs call
+ frame by literally following the execution semantics of op_call_varargs. This isn't how it'll
+ happen once the DFG and FTL do varargs calls, or when varargs calls get inlined. The DFG and FTL
+ don't literally execute bytecode; for example their stack frame layout has absolutely nothing in
+ common with what the bytecode says, and that will never change.
+
+ This patch makes two changes:
+
+ Setting up the varargs callee frame can be done in smaller steps: particularly in the case of a
+ varargs call that gets inlined, we aren't going to actually want to set up a callee frame in
+ full - we just want to put the arguments somewhere, and that place will not have much (if
+ anything) in common with the call frame format. This patch factors that out into something called
+ a loadVarargs. The thing we used to call loadVarargs is now called setupVarargsFrame. This patch
+ also separates loading varargs from setting this, since the fact that those two things are done
+ together is a detail made explicit in bytecode but it's not at all required in the higher-tier
+ engines. In the process of factoring this code out, I found a bunch of off-by-one errors in the
+ various calculations. I fixed them. The distance from the caller's frame pointer to the callee
+ frame pointer is always:
+
+ numUsedCallerSlots + argCount + 1 + CallFrameSize
+
+ where numUsedCallerSlots is toLocal(firstFreeRegister) - 1, which simplifies down to just
+ -firstFreeRegister. The code now speaks of numUsedCallerSlots rather than firstFreeRegister,
+ since the latter is a bytecode peculiarity that doesn't apply in the DFG or FTL. In the DFG, the
+ internally-computed frame size, minus the parameter slots, will be used for numUsedCallerSlots.
+ In the FTL, we will essentially compute numUsedCallerSlots dynamically by subtracting SP from FP.
+ Eventually, LLVM might give us some cleaner way of doing this, but it probably doesn't matter
+ very much.
+
+ The arguments forwarding optimization is factored out of the Baseline JIT: the DFG and FTL will
+ want to do this optimization as well, but it involves quite a bit of code. So, this code is now
+ factored out into SetupVarargsFrame.h|cpp, so that other JITs can use it. In the process of factoring
+ this code out I noticed that the 32-bit and 64-bit code is nearly identical, so I combined them.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CodeBlock.h:
+ (JSC::ExecState::r):
+ (JSC::ExecState::uncheckedR):
+ * bytecode/VirtualRegister.h:
+ (JSC::VirtualRegister::operator+):
+ (JSC::VirtualRegister::operator-):
+ (JSC::VirtualRegister::operator+=):
+ (JSC::VirtualRegister::operator-=):
+ * interpreter/CallFrame.h:
+ * interpreter/Interpreter.cpp:
+ (JSC::sizeFrameForVarargs):
+ (JSC::loadVarargs):
+ (JSC::setupVarargsFrame):
+ (JSC::setupVarargsFrameAndSetThis):
+ * interpreter/Interpreter.h:
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
+ (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
+ (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
+ * jit/JIT.h:
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileSetupVarargsFrame):
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ (JSC::JIT::emitGetFromCallFrameHeaderPtr): Deleted.
+ (JSC::JIT::emitGetFromCallFrameHeader32): Deleted.
+ (JSC::JIT::emitGetFromCallFrameHeader64): Deleted.
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * jit/SetupVarargsFrame.cpp: Added.
+ (JSC::emitSetupVarargsFrameFastCase):
+ * jit/SetupVarargsFrame.h: Added.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::copyToArguments):
+ * runtime/Arguments.h:
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::copyToArguments):
+ * runtime/JSArray.h:
+
+2015-02-09 Filip Pizlo <fpizlo@apple.com>
+
+ DFG call codegen should resolve the callee operand as late as possible
+ https://bugs.webkit.org/show_bug.cgi?id=141398
+
+ Reviewed by Mark Lam.
+
+ This is mostly a benign restructuring to help with the implementation of
+ https://bugs.webkit.org/show_bug.cgi?id=141332.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+
+2015-02-08 Filip Pizlo <fpizlo@apple.com>
+
+ DFG should only have two mechanisms for describing effectfulness of nodes; previously there were three
+ https://bugs.webkit.org/show_bug.cgi?id=141369
+
+ Reviewed by Michael Saboff.
+
+ We previously used the NodeMightClobber and NodeClobbersWorld NodeFlags to describe
+ effectfulness. Starting over a year ago, we introduced a more powerful mechanism - the
+ DFG::clobberize() function. Now we only have one remaining client of the old NodeFlags,
+ and everyone else uses DFG::clobberize(). We should get rid of those NodeFlags and
+ finally switch everyone over to DFG::clobberize().
+
+ Unfortunately there is still another place where effectfulness of nodes is described: the
+ AbstractInterpreter. This is because the AbstractInterpreter has special tuning both for
+ compile time performance and there are places where the AI is more precise than
+ clobberize() because of its flow-sensitivity.
+
+ This means that after this change there will be only two places, rather than three, where
+ the effectfulness of a node has to be described:
+
+ - DFG::clobberize()
+ - DFG::AbstractInterpreter
+
+ * dfg/DFGClobberize.cpp:
+ (JSC::DFG::clobbersWorld):
+ * dfg/DFGClobberize.h:
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteLength):
+ (JSC::DFG::FixupPhase::convertToGetArrayLength):
+ (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
+ * dfg/DFGGraph.h:
+ (JSC::DFG::Graph::isPredictedNumerical): Deleted.
+ (JSC::DFG::Graph::byValIsPure): Deleted.
+ (JSC::DFG::Graph::clobbersWorld): Deleted.
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToConstant):
+ (JSC::DFG::Node::convertToGetLocalUnlinked):
+ (JSC::DFG::Node::convertToGetByOffset):
+ (JSC::DFG::Node::convertToMultiGetByOffset):
+ (JSC::DFG::Node::convertToPutByOffset):
+ (JSC::DFG::Node::convertToMultiPutByOffset):
+ * dfg/DFGNodeFlags.cpp:
+ (JSC::DFG::dumpNodeFlags):
+ * dfg/DFGNodeFlags.h:
+ * dfg/DFGNodeType.h:
+
+2015-02-09 Csaba Osztrogonác <ossy@webkit.org>
+
+ Fix the !ENABLE(DFG_JIT) build
+ https://bugs.webkit.org/show_bug.cgi?id=141387
+
+ Reviewed by Darin Adler.
+
+ * jit/Repatch.cpp:
+
+2015-02-08 Benjamin Poulain <benjamin@webkit.org>
+
+ Remove a few duplicate propagation steps from the DFG's PredictionPropagation phase
+ https://bugs.webkit.org/show_bug.cgi?id=141363
+
+ Reviewed by Darin Adler.
+
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ Some blocks were duplicated, they probably evolved separately
+ to the same state.
+
+2015-02-08 Benjamin Poulain <benjamin@webkit.org>
+
+ Remove useless declarations and a stale comment from DFGByteCodeParser.h
+ https://bugs.webkit.org/show_bug.cgi?id=141361
+
+ Reviewed by Darin Adler.
+
+ The comment refers to the original form of the ByteCodeParser:
+ parse(Graph&, JSGlobalData*, CodeBlock*, unsigned startIndex);
+
+ That form is long dead, the comment is more misleading than anything.
+
+ * dfg/DFGByteCodeParser.cpp:
+ * dfg/DFGByteCodeParser.h:
+
+2015-02-08 Benjamin Poulain <benjamin@webkit.org>
+
+ Encapsulate DFG::Plan's beforeFTL timestamp
+ https://bugs.webkit.org/show_bug.cgi?id=141360
+
+ Reviewed by Darin Adler.
+
+ Make the attribute private, it is an internal state.
+
+ Rename beforeFTL->timeBeforeFTL for readability.
+
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThread):
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGPlan.h:
+
+2015-02-08 Benjamin Poulain <bpoulain@apple.com>
+
+ Remove DFGNode::hasArithNodeFlags()
+ https://bugs.webkit.org/show_bug.cgi?id=141319
+
+ Reviewed by Michael Saboff.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasArithNodeFlags): Deleted.
+ Unused code is unused.
+
+2015-02-07 Chris Dumez <cdumez@apple.com>
+
+ Add Vector::removeFirstMatching() / removeAllMatching() methods taking lambda functions
+ https://bugs.webkit.org/show_bug.cgi?id=141321
+
+ Reviewed by Darin Adler.
+
+ Use new Vector::removeFirstMatching() / removeAllMatching() methods.
+
+2015-02-06 Filip Pizlo <fpizlo@apple.com>
+
+ DFG SSA shouldn't have SetArgument nodes
+ https://bugs.webkit.org/show_bug.cgi?id=141342
+
+ Reviewed by Mark Lam.
+
+ I was wondering why we kept the SetArgument around for captured
+ variables. It turns out we did so because we thought we had to, even
+ though we didn't have to. The node is meaningless in SSA.
+
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+
+2015-02-06 Filip Pizlo <fpizlo@apple.com>
+
+ It should be possible to use the DFG SetArgument node to indicate that someone set the value of a local out-of-band
+ https://bugs.webkit.org/show_bug.cgi?id=141337
+
+ Reviewed by Mark Lam.
+
+ This mainly involved ensuring that SetArgument behaves just like SetLocal from a CPS standpoint, but with a special case for those SetArguments that
+ are associated with the prologue.
+
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::run):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeSet):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
+ (JSC::DFG::CPSRethreadingPhase::specialCaseArguments):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeSetLocal): Deleted.
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeSetArgument): Deleted.
+
+2015-02-06 Mark Lam <mark.lam@apple.com>
+
+ MachineThreads should be ref counted.
+ <https://webkit.org/b/141317>
+
+ Reviewed by Filip Pizlo.
+
+ The VM's MachineThreads registry object is being referenced from other
+ threads as a raw pointer. In a scenario where the VM is destructed on
+ the main thread, there is no guarantee that another thread isn't still
+ holding a reference to the registry and will eventually invoke
+ removeThread() on it on thread exit. Hence, there's a possible use
+ after free scenario here.
+
+ The fix is to make MachineThreads ThreadSafeRefCounted, and have all
+ threads that references keep a RefPtr to it to ensure that it stays
+ alive until the very last thread is done with it.
+
+ * API/tests/testapi.mm:
+ (useVMFromOtherThread): - Renamed to be more descriptive.
+ (useVMFromOtherThreadAndOutliveVM):
+ - Added a test that has another thread which uses the VM outlive the
+ VM to confirm that there is no crash.
+
+ However, I was not actually able to get the VM to crash without this
+ patch because I wasn't always able to the thread destructor to be
+ called. With this patch applied, I did verify with some logging that
+ the MachineThreads registry is only destructed after all threads
+ have removed themselves from it.
+
+ (threadMain): Deleted.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::~Heap):
+ (JSC::Heap::gatherStackRoots):
+ * heap/Heap.h:
+ (JSC::Heap::machineThreads):
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::Thread::Thread):
+ (JSC::MachineThreads::addCurrentThread):
+ (JSC::MachineThreads::removeCurrentThread):
+ * heap/MachineStackMarker.h:
+
+2015-02-06 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r179743.
+ https://bugs.webkit.org/show_bug.cgi?id=141335
+
+ caused missing symbols in non-WebKit clients of WTF::Vector
+ (Requested by kling on #webkit).
+
+ Reverted changeset:
+
+ "Remove WTF::fastMallocGoodSize()."
+ https://bugs.webkit.org/show_bug.cgi?id=141020
+ http://trac.webkit.org/changeset/179743
+
+2015-02-04 Filip Pizlo <fpizlo@apple.com>
+
+ Remove BytecodeGenerator::preserveLastVar() and replace it with a more robust mechanism for preserving non-temporary registers
+ https://bugs.webkit.org/show_bug.cgi?id=141211
+
+ Reviewed by Mark Lam.
+
+ Previously, the way non-temporary registers were preserved (i.e. not reclaimed anytime
+ we did newTemporary()) by calling preserveLastVar() after all non-temps are created. It
+ would raise the refcount on the last (highest-numbered) variable created, and rely on
+ the fact that register reclamation started at higher-numbered registers and worked its
+ way down. So any retained register would block any lower-numbered registers from being
+ reclaimed.
+
+ Also, preserveLastVar() sets a thing called m_firstConstantIndex. It's unused.
+
+ This removes preserveLastVar() and makes addVar() retain each register it creates. This
+ is more explicit, since addVar() is the mechanism for creating non-temporary registers.
+
+ To make this work I had to remove an assertion that Register::setIndex() can only be
+ called when the refcount is zero. This method might be called after a var is created to
+ change its index. This previously worked because preserveLastVar() would be called after
+ we had already made all index changes, so the vars would still have refcount zero. Now
+ they have refcount 1. I think it's OK to lose this assertion; I can't remember this
+ assertion ever firing in a way that alerted me to a serious issue.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::preserveLastVar): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::addVar):
+ * bytecompiler/RegisterID.h:
+ (JSC::RegisterID::setIndex):
+
+2015-02-06 Andreas Kling <akling@apple.com>
+
+ Remove WTF::fastMallocGoodSize().
+ <https://webkit.org/b/141020>
+
+ Reviewed by Anders Carlsson.
+
+ * assembler/AssemblerBuffer.h:
+ (JSC::AssemblerData::AssemblerData):
+ (JSC::AssemblerData::grow):
+
+2015-02-05 Michael Saboff <msaboff@apple.com>
+
+ CodeCache is not thread safe when adding the same source from two different threads
+ https://bugs.webkit.org/show_bug.cgi?id=141275
+
+ Reviewed by Mark Lam.
+
+ The issue for this bug is that one thread, takes a cache miss in CodeCache::getGlobalCodeBlock,
+ but in the process creates a cache entry with a nullptr UnlinkedCodeBlockType* which it
+ will fill in later in the function. During the body of that function, it allocates
+ objects that may garbage collect. During that garbage collection, we drop the all locks.
+ While the locks are released by the first thread, another thread can enter the VM and might
+ have exactly the same source and enter CodeCache::getGlobalCodeBlock() itself. When it
+ looks up the code block, it sees it as a cache it and uses the nullptr UnlinkedCodeBlockType*
+ and crashes. This fixes the problem by not dropping the locks during garbage collection.
+ There are other likely scenarios where we have a data structure like this code cache in an
+ unsafe state for arbitrary reentrance.
+
+ Moved the functionality of DelayedReleaseScope directly into Heap. Changed it into
+ a simple list that is cleared with the new function Heap::releaseDelayedReleasedObjects.
+ Now we accumulate objects to be released and release them when all locks are dropped or
+ when destroying the Heap. This eliminated the dropping and reaquiring of locks associated
+ with the old scope form of this list.
+
+ Given that all functionality of DelayedReleaseScope is now used and referenced by Heap
+ and the lock management no longer needs to be done, just made the list a member of Heap.
+ We do need to guard against the case that releasing an object can create more objects
+ by calling into JS. That is why releaseDelayedReleasedObjects() is written to remove
+ an object to release so that we aren't recursively in Vector code. The other thing we
+ do in releaseDelayedReleasedObjects() is to guard against recursive calls to itself using
+ the m_delayedReleaseRecursionCount. We only release at the first entry into the function.
+ This case is already tested by testapi.mm.
+
+ * heap/DelayedReleaseScope.h: Removed file
+
+ * API/JSAPIWrapperObject.mm:
+ * API/ObjCCallbackFunction.mm:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::doSweep):
+ * heap/MarkedAllocator.cpp:
+ (JSC::MarkedAllocator::tryAllocateHelper):
+ (JSC::MarkedAllocator::tryAllocate):
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::sweep):
+ * heap/MarkedSpace.cpp:
+ (JSC::MarkedSpace::MarkedSpace):
+ (JSC::MarkedSpace::lastChanceToFinalize):
+ (JSC::MarkedSpace::didFinishIterating):
+ * heap/MarkedSpace.h:
+ * heap/Heap.cpp:
+ (JSC::Heap::collectAllGarbage):
+ (JSC::Heap::zombifyDeadObjects):
+ Removed references to DelayedReleaseScope and DelayedReleaseScope.h.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap): Initialized m_delayedReleaseRecursionCount.
+ (JSC::Heap::lastChanceToFinalize): Call releaseDelayedObjectsNow() as the VM is going away.
+ (JSC::Heap::releaseDelayedReleasedObjects): New function that released the accumulated
+ delayed release objects.
+
+ * heap/Heap.h:
+ (JSC::Heap::m_delayedReleaseObjects): List of objects to be released later.
+ (JSC::Heap::m_delayedReleaseRecursionCount): Counter to indicate that
+ releaseDelayedReleasedObjects is being called recursively.
+ * heap/HeapInlines.h:
+ (JSC::Heap::releaseSoon): Changed location of list to add delayed release objects.
+
+ * runtime/JSLock.cpp:
+ (JSC::JSLock::willReleaseLock):
+ Call Heap::releaseDelayedObjectsNow() when releasing the lock.
+
+2015-02-05 Youenn Fablet <youenn.fablet@crf.canon.fr> and Xabier Rodriguez Calvar <calvaris@igalia.com>
+
+ [Streams API] Implement a barebone ReadableStream interface
+ https://bugs.webkit.org/show_bug.cgi?id=141045
+
+ Reviewed by Benjamin Poulain.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-02-05 Saam Barati <saambarati1@gmail.com>
+
+ Crash in uninitialized deconstructing variable.
+ https://bugs.webkit.org/show_bug.cgi?id=141070
+
+ Reviewed by Michael Saboff.
+
+ According to the ES6 spec, when a destructuring pattern occurs
+ as the left hand side of an assignment inside a var declaration
+ statement, the assignment must also have a right hand side value.
+ "var {x} = {};" is a legal syntactic statement, but,
+ "var {x};" is a syntactic error.
+
+ Section 13.2.2 of the latest draft ES6 spec specifies this requirement:
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-variable-statement
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseVarDeclaration):
+ (JSC::Parser<LexerType>::parseVarDeclarationList):
+ (JSC::Parser<LexerType>::parseForStatement):
+ * parser/Parser.h:
+
+2015-02-04 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Unreviewed, fix a build break on EFL port since r179648.
+
+ * heap/MachineStackMarker.cpp: EFL port doesn't use previousThread variable.
+ (JSC::MachineThreads::tryCopyOtherThreadStacks):
+
+2015-02-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ES6: Improved Console Support for Symbol Objects
+ https://bugs.webkit.org/show_bug.cgi?id=141173
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Runtime.json:
+ New type, "symbol".
+
+ * inspector/InjectedScriptSource.js:
+ Handle Symbol objects in a few places. They don't have properties
+ and they cannot be implicitly converted to strings.
+
+2015-02-04 Mark Lam <mark.lam@apple.com>
+
+ Undo gardening: Restoring the expected ERROR message since that is not the cause of the bot unhappiness.
+
+ Not reviewed.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::tryCopyOtherThreadStacks):
+
+2015-02-04 Mark Lam <mark.lam@apple.com>
+
+ Gardening: Changed expected ERROR message to WARNING to make test bots happy.
+
+ Rubber stamped by Simon Fraser.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::tryCopyOtherThreadStacks):
+
+2015-02-04 Mark Lam <mark.lam@apple.com>
+
+ r179576 introduce a deadlock potential during GC thread suspension.
+ <https://webkit.org/b/141268>
+
+ Reviewed by Michael Saboff.
+
+ http://trac.webkit.org/r179576 introduced a potential for deadlocking.
+ In the GC thread suspension loop, we currently delete
+ MachineThreads::Thread that we detect to be invalid. This is unsafe
+ because we may have already suspended some threads, and one of those
+ suspended threads may still be holding the C heap lock which we need
+ for deleting the invalid thread.
+
+ The fix is to put the invalid threads in a separate toBeDeleted list,
+ and delete them only after GC has resumed all threads.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::removeCurrentThread):
+ - Undo refactoring removeThreadWithLockAlreadyAcquired() out of
+ removeCurrentThread() since it is no longer needed.
+
+ (JSC::MachineThreads::tryCopyOtherThreadStacks):
+ - Put invalid Threads on a threadsToBeDeleted list, and delete those
+ Threads only after all threads have been resumed.
+
+ (JSC::MachineThreads::removeThreadWithLockAlreadyAcquired): Deleted.
+ * heap/MachineStackMarker.h:
+
+2015-02-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Clean up Object Property Descriptor Collection
+ https://bugs.webkit.org/show_bug.cgi?id=141222
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ Use a list of options when determining which properties to collect
+ instead of a few booleans with overlapping responsibilities.
+
+2015-02-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: console.table with columnName filter for non-existent property should still show column
+ https://bugs.webkit.org/show_bug.cgi?id=141066
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/ConsoleMessage.cpp:
+ (Inspector::ConsoleMessage::addToFrontend):
+ When a user provides a second argument, e.g. console.table(..., columnNames),
+ then pass that second argument to the frontend.
+
+ * inspector/InjectedScriptSource.js:
+ Add a FIXME about the old, unused path now.
+
+2015-02-04 Saam Barati <saambarati1@gmail.com>
+
+ TypeSet can use 1 byte instead of 4 bytes for its m_seenTypes member variable
+ https://bugs.webkit.org/show_bug.cgi?id=141204
+
+ Reviewed by Darin Adler.
+
+ There is no need to use 32 bits to store a TypeSet::RuntimeType set
+ bit-vector when the largest value for a single TypeSet::RuntimeType
+ is 0x80. 8 bits is enough to represent the set of seen types.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::doesTypeConformTo):
+ * runtime/TypeSet.h:
+ (JSC::TypeSet::seenTypes):
+
+2015-02-04 Mark Lam <mark.lam@apple.com>
+
+ Remove concept of makeUsableFromMultipleThreads().
+ <https://webkit.org/b/141221>
+
+ Reviewed by Mark Hahnenberg.
+
+ Currently, we rely on VM::makeUsableFromMultipleThreads() being called before we
+ start acquiring the JSLock and entering the VM from different threads.
+ Acquisition of the JSLock will register the acquiring thread with the VM's thread
+ registry if not already registered. However, it will only do this if the VM's
+ thread specific key has been initialized by makeUsableFromMultipleThreads().
+
+ This is fragile, and also does not read intuitively because one would expect to
+ acquire the JSLock before calling any methods on the VM. This is exactly what
+ JSGlobalContextCreateInGroup() did (i.e. acquire the lock before calling
+ makeUsableFromMultipleThreads()), but is wrong. The result is that the invoking
+ thread will not have been registered with the VM during that first entry into
+ the VM.
+
+ The fix is to make it so that we initialize the VM's thread specific key on
+ construction of the VM's MachineThreads registry instead of relying on
+ makeUsableFromMultipleThreads() being called. With this, we can eliminate
+ makeUsableFromMultipleThreads() altogether.
+
+ Performance results are neutral in aggregate.
+
+ * API/JSContextRef.cpp:
+ (JSGlobalContextCreateInGroup):
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::MachineThreads):
+ (JSC::MachineThreads::~MachineThreads):
+ (JSC::MachineThreads::addCurrentThread):
+ (JSC::MachineThreads::removeThread):
+ (JSC::MachineThreads::gatherConservativeRoots):
+ (JSC::MachineThreads::makeUsableFromMultipleThreads): Deleted.
+ * heap/MachineStackMarker.h:
+ * runtime/VM.cpp:
+ (JSC::VM::sharedInstance):
+ * runtime/VM.h:
+ (JSC::VM::makeUsableFromMultipleThreads): Deleted.
+
+2015-02-04 Chris Dumez <cdumez@apple.com>
+
+ Add removeFirst(value) / removeAll(value) methods to WTF::Vector
+ https://bugs.webkit.org/show_bug.cgi?id=141192
+
+ Reviewed by Benjamin Poulain.
+
+ Use new Vector::removeFirst(value) / removeAll(value) API to simplify the
+ code a bit.
+
+ * inspector/InspectorValues.cpp:
+ (Inspector::InspectorObjectBase::remove):
+
+2015-02-03 Mark Lam <mark.lam@apple.com>
+
+ Workaround a thread library bug where thread destructors may not get called.
+ <https://webkit.org/b/141209>
+
+ Reviewed by Michael Saboff.
+
+ There's a bug where thread destructors may not get called. As far as
+ we know, this only manifests on darwin ports. We will work around this
+ by checking at GC time if the platform thread is still valid. If not,
+ we'll purge it from the VM's registeredThreads list before proceeding
+ with thread scanning activity.
+
+ Note: it is important that we do this invalid thread detection during
+ suspension, because the validity (and liveness) of the other thread is
+ only guaranteed while it is suspended.
+
+ * API/tests/testapi.mm:
+ (threadMain):
+ - Added a test to enter the VM from another thread before we GC on
+ the main thread.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::removeThreadWithLockAlreadyAcquired):
+ (JSC::MachineThreads::removeCurrentThread):
+ - refactored removeThreadWithLockAlreadyAcquired() out from
+ removeCurrentThread() so that we can also call it for purging invalid
+ threads.
+ (JSC::suspendThread):
+ - Added a return status to tell if the suspension succeeded or not.
+ (JSC::MachineThreads::tryCopyOtherThreadStacks):
+ - Check if the suspension failed, and purge the thread if we can't
+ suspend it. Failure to suspend implies that the thread has
+ terminated without calling its destructor.
+ * heap/MachineStackMarker.h:
+
+2015-02-03 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ASSERT mainThreadPthread launching remote debuggable JSContext app with Debug JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=141189
+
+ Reviewed by Michael Saboff.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::singleton):
+ Ensure we call WTF::initializeMainThread() on the main thread so that
+ we can perform automatic String <-> NSString conversions.
+
+2015-02-03 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Project file cleanups after r179429.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+
+2015-02-02 Filip Pizlo <fpizlo@apple.com>
+
+ arguments[-1] should have well-defined behavior
+ https://bugs.webkit.org/show_bug.cgi?id=141183
+
+ Reviewed by Mark Lam.
+
+ According to JSC's internal argument numbering, 0 is "this" and 1 is the first argument.
+ In the "arguments[i]" expression, "this" is not accessible and i = 0 refers to the first
+ argument. Previously we handled the bounds check in "arguments[i]" - where "arguments" is
+ statically known to be the current function's arguments object - as follows:
+
+ add 1, i
+ branchAboveOrEqual i, callFrame.ArgumentCount, slowPath
+
+ The problem with this is that if i = -1, this passes the test, and we end up accessing
+ what would be the "this" argument slot. That's wrong, since we should really be bottoming
+ out in arguments["-1"], which is usually undefined but could be anything. It's even worse
+ if the function is inlined or if we're in a constructor - in that case the "this" slot
+ could be garbage.
+
+ It turns out that we had this bug in all of our engines.
+
+ This fixes the issue by changing the algorithm to:
+
+ load32 callFrame.ArgumentCount, tmp
+ sub 1, tmp
+ branchAboveOrEqual i, tmp, slowPath
+
+ In some engines, we would have used the modified "i" (the one that had 1 added to it) for
+ the subsequent argument load; since we don't do this anymore I also had to change some of
+ the offsets on the BaseIndex arguments load.
+
+ This also includes tests that are written in such a way as to get coverage on LLInt and
+ Baseline JIT (get-my-argument-by-val-wrap-around-no-warm-up), DFG and FTL
+ (get-my-argument-by-val-wrap-around), and DFG when we're being paranoid about the user
+ overwriting the "arguments" variable (get-my-argument-by-val-safe-wrap-around). This also
+ includes off-by-1 out-of-bounds tests for each of these cases, since in the process of
+ writing the patch I broke the arguments[arguments.length] case in the DFG and didn't see
+ any test failures.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::offsetOfArguments):
+ (JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis): Deleted.
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_get_argument_by_val):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_get_argument_by_val):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * tests/stress/get-my-argument-by-val-out-of-bounds-no-warm-up.js: Added.
+ (foo):
+ * tests/stress/get-my-argument-by-val-out-of-bounds.js: Added.
+ (foo):
+ * tests/stress/get-my-argument-by-val-safe-out-of-bounds.js: Added.
+ (foo):
+ * tests/stress/get-my-argument-by-val-safe-wrap-around.js: Added.
+ (foo):
+ * tests/stress/get-my-argument-by-val-wrap-around-no-warm-up.js: Added.
+ (foo):
+ * tests/stress/get-my-argument-by-val-wrap-around.js: Added.
+ (foo):
+
+2015-02-02 Filip Pizlo <fpizlo@apple.com>
+
+ MultiGetByOffset should be marked NodeMustGenerate
+ https://bugs.webkit.org/show_bug.cgi?id=140137
+
+ Reviewed by Michael Saboff.
+
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToGetByOffset): We were sloppy - we should also clear NodeMustGenerate once it's a GetByOffset.
+ (JSC::DFG::Node::convertToMultiGetByOffset): Assert that we converted from something that already had NodeMustGenerate.
+ * dfg/DFGNodeType.h: We shouldn't DCE a node that does checks and could be effectful in baseline. Making MultiGetByOffset as NodeMustGenerate prevents DCE. FTL could still DCE the actual loads, but the checks will stay.
+ * tests/stress/multi-get-by-offset-dce.js: Added. This previously failed because the getter wasn't called.
+ (foo):
+
+2015-02-02 Filip Pizlo <fpizlo@apple.com>
+
+ [FTL] inlined GetMyArgumentByVal with no arguments passed causes instant crash
+ https://bugs.webkit.org/show_bug.cgi?id=141180
+ rdar://problem/19677552
+
+ Reviewed by Benjamin Poulain.
+
+ If we do a GetMyArgumentByVal on an inlined call frame that has no arguments, then the
+ bounds check already terminates execution. This means we can skip the part where we
+ previously did an out-of-bound array access on the inlined call frame arguments vector.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyArgumentByVal):
+ (JSC::FTL::LowerDFGToLLVM::terminate):
+ (JSC::FTL::LowerDFGToLLVM::didAlreadyTerminate):
+ (JSC::FTL::LowerDFGToLLVM::crash):
+ * tests/stress/get-my-argument-by-val-inlined-no-formal-parameters.js: Added.
+ (foo):
+ (bar):
+
+2015-02-02 Filip Pizlo <fpizlo@apple.com>
+
+ REGRESSION(r179477): arguments simplification no longer works
+ https://bugs.webkit.org/show_bug.cgi?id=141169
+
+ Reviewed by Mark Lam.
+
+ The operations involved in callee/scope access don't exit and shouldn't get in the way
+ of strength-reducing a Flush to a PhantomLocal. Then the PhantomLocal shouldn't get in
+ the way of further such strength-reduction. We also need to canonicalize PhantomLocal
+ before running arguments simplification.
+
+ * dfg/DFGMayExit.cpp:
+ (JSC::DFG::mayExit):
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ * dfg/DFGStrengthReductionPhase.cpp:
+ (JSC::DFG::StrengthReductionPhase::handleNode):
+
+2015-02-02 Filip Pizlo <fpizlo@apple.com>
+
+ VirtualRegister should really know how to dump itself
+ https://bugs.webkit.org/show_bug.cgi?id=141171
+
+ Reviewed by Geoffrey Garen.
+
+ Gives VirtualRegister a dump() method that pretty-prints the virtual register. The rest of
+ the patch is all about using this new power.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CodeBlock.cpp:
+ (JSC::constantName):
+ (JSC::CodeBlock::registerName):
+ * bytecode/CodeBlock.h:
+ (JSC::missingThisObjectMarker): Deleted.
+ * bytecode/VirtualRegister.cpp: Added.
+ (JSC::VirtualRegister::dump):
+ * bytecode/VirtualRegister.h:
+ (WTF::printInternal): Deleted.
+ * dfg/DFGArgumentPosition.h:
+ (JSC::DFG::ArgumentPosition::dump):
+ * dfg/DFGFlushedAt.cpp:
+ (JSC::DFG::FlushedAt::dump):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::dump):
+ * dfg/DFGPutLocalSinkingPhase.cpp:
+ * dfg/DFGSSAConversionPhase.cpp:
+ (JSC::DFG::SSAConversionPhase::run):
+ * dfg/DFGValidate.cpp:
+ (JSC::DFG::Validate::reportValidationContext):
+ * dfg/DFGValueSource.cpp:
+ (JSC::DFG::ValueSource::dump):
+ * dfg/DFGVariableEvent.cpp:
+ (JSC::DFG::VariableEvent::dump):
+ (JSC::DFG::VariableEvent::dumpSpillInfo):
+ * ftl/FTLExitArgumentForOperand.cpp:
+ (JSC::FTL::ExitArgumentForOperand::dump):
+ * ftl/FTLExitValue.cpp:
+ (JSC::FTL::ExitValue::dumpInContext):
+ * profiler/ProfilerBytecodeSequence.cpp:
+ (JSC::Profiler::BytecodeSequence::BytecodeSequence):
+
+2015-02-02 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the HandleBlock piece of this patch.
+
+ * heap/HandleBlock.h:
+ * heap/HandleBlockInlines.h:
+ (JSC::HandleBlock::create):
+ (JSC::HandleBlock::destroy):
+ (JSC::HandleBlock::HandleBlock):
+ (JSC::HandleBlock::payloadEnd):
+ * heap/HandleSet.cpp:
+ (JSC::HandleSet::~HandleSet):
+ (JSC::HandleSet::grow):
+
+2015-02-02 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Support console.table
+ https://bugs.webkit.org/show_bug.cgi?id=141058
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ Include the firstLevelKeys filter when generating previews.
+
+ * runtime/ConsoleClient.cpp:
+ (JSC::appendMessagePrefix):
+ Differentiate console.table logs to system log.
+
+2015-01-31 Filip Pizlo <fpizlo@apple.com>
+
+ BinarySwitch should be faster on average
+ https://bugs.webkit.org/show_bug.cgi?id=141046
+
+ Reviewed by Anders Carlsson.
+
+ This optimizes our binary switch using math. It's strictly better than what we had before
+ assuming we bottom out in some case (rather than fall through), assuming all cases get
+ hit with equal probability. The difference is particularly large for large switch
+ statements. For example, a switch statement with 1000 cases would previously require on
+ average 13.207 branches to get to some case, while now it just requires 10.464.
+
+ This is also a progression for the fall-through case, though we could shave off another
+ 1/6 branch on average if we wanted to - though it would regress taking a case (not falling
+ through) by 1/6 branch. I believe it's better to bias the BinarySwitch for not falling
+ through.
+
+ This also adds some randomness to the algorithm to minimize the likelihood of us
+ generating a switch statement that is always particularly bad for some input. Note that
+ the randomness has no effect on average-case performance assuming all cases are equally
+ likely.
+
+ This ought to have no actual performance change because we don't rely on binary switches
+ that much. The main reason why this change is interesting is that I'm finding myself
+ increasingly relying on BinarySwitch, and I'd like to know that it's optimal.
+
+ * jit/BinarySwitch.cpp:
+ (JSC::BinarySwitch::BinarySwitch):
+ (JSC::BinarySwitch::~BinarySwitch):
+ (JSC::BinarySwitch::build):
+ * jit/BinarySwitch.h:
+
+2015-02-02 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Extend CSS.getSupportedCSSProperties to provide values for properties for CSS Augmented JSContext
+ https://bugs.webkit.org/show_bug.cgi?id=141064
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/CSS.json:
+
+2015-02-02 Daniel Bates <dabates@apple.com>
+
+ [iOS] ASSERTION FAILED: m_scriptExecutionContext->isContextThread() in ContextDestructionObserver::observeContext
+ https://bugs.webkit.org/show_bug.cgi?id=141057
+ <rdar://problem/19068790>
+
+ Reviewed by Alexey Proskuryakov.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::receivedIndicateMessage): Modified to call WTF::callOnWebThreadOrDispatchAsyncOnMainThread().
+ (Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable): Deleted; moved logic to common helper function,
+ WTF::callOnWebThreadOrDispatchAsyncOnMainThread() so that it can be called from both RemoteInspector::receivedIndicateMessage()
+ and CryptoKeyRSA::generatePair().
+
+2015-02-02 Saam Barati <saambarati1@gmail.com>
+
+ Create tests for JSC's Control Flow Profiler
+ https://bugs.webkit.org/show_bug.cgi?id=141123
+
+ Reviewed by Filip Pizlo.
+
+ This patch creates a control flow profiler testing API in jsc.cpp
+ that accepts a function and a string as arguments. The string must
+ be a substring of the text of the function argument. The API returns
+ a boolean indicating whether or not the basic block that encloses the
+ substring has executed.
+
+ This patch uses this API to test that the control flow profiler
+ behaves as expected on basic block boundaries. These tests do not
+ provide full coverage for all JavaScript statements that can create
+ basic blocks boundaries. Full coverage will come in a later patch.
+
+ * jsc.cpp:
+ (GlobalObject::finishCreation):
+ (functionHasBasicBlockExecuted):
+ * runtime/ControlFlowProfiler.cpp:
+ (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
+ * runtime/ControlFlowProfiler.h:
+ * tests/controlFlowProfiler: Added.
+ * tests/controlFlowProfiler.yaml: Added.
+ * tests/controlFlowProfiler/driver: Added.
+ * tests/controlFlowProfiler/driver/driver.js: Added.
+ (assert):
+ * tests/controlFlowProfiler/if-statement.js: Added.
+ (testIf):
+ (noMatches):
+ * tests/controlFlowProfiler/loop-statements.js: Added.
+ (forRegular):
+ (forIn):
+ (forOf):
+ (whileLoop):
+ * tests/controlFlowProfiler/switch-statements.js: Added.
+ (testSwitch):
+ * tests/controlFlowProfiler/test-jit.js: Added.
+ (tierUpToBaseline):
+ (tierUpToDFG):
+ (baselineTest):
+ (dfgTest):
+
+2015-01-28 Filip Pizlo <fpizlo@apple.com>
+
+ Polymorphic call inlining should be based on polymorphic call inline caching rather than logging
+ https://bugs.webkit.org/show_bug.cgi?id=140660
+
+ Reviewed by Geoffrey Garen.
+
+ When we first implemented polymorphic call inlining, we did the profiling based on a call
+ edge log. The idea was to store each call edge (a tuple of call site and callee) into a
+ global log that was processed lazily. Processing the log would give precise counts of call
+ edges, and could be used to drive well-informed inlining decisions - polymorphic or not.
+ This was a speed-up on throughput tests but a slow-down for latency tests. It was a net win
+ nonetheless.
+
+ Experience with this code shows three things. First, the call edge profiler is buggy and
+ complex. It would take work to fix the bugs. Second, the call edge profiler incurs lots of
+ overhead for latency code that we care deeply about. Third, it's not at all clear that
+ having call edge counts for every possible callee is any better than just having call edge
+ counts for the limited number of callees that an inline cache would catch.
+
+ So, this patch removes the call edge profiler and replaces it with a polymorphic call inline
+ cache. If we miss the basic call inline cache, we inflate the cache to be a jump to an
+ out-of-line stub that cases on the previously known callees. If that misses again, then we
+ rewrite that stub to include the new callee. We do this up to some number of callees. If we
+ hit the limit then we switch to using a plain virtual call.
+
+ Substantial speed-up on V8Spider; undoes the slow-down that the original call edge profiler
+ caused. Might be a SunSpider speed-up (below 1%), depending on hardware.
+
+ Rolling this back in after fixing https://bugs.webkit.org/show_bug.cgi?id=141107.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CallEdge.h:
+ (JSC::CallEdge::count):
+ (JSC::CallEdge::CallEdge):
+ * bytecode/CallEdgeProfile.cpp: Removed.
+ * bytecode/CallEdgeProfile.h: Removed.
+ * bytecode/CallEdgeProfileInlines.h: Removed.
+ * bytecode/CallLinkInfo.cpp:
+ (JSC::CallLinkInfo::unlink):
+ (JSC::CallLinkInfo::visitWeak):
+ * bytecode/CallLinkInfo.h:
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::CallLinkStatus):
+ (JSC::CallLinkStatus::computeFor):
+ (JSC::CallLinkStatus::computeFromCallLinkInfo):
+ (JSC::CallLinkStatus::isClosureCall):
+ (JSC::CallLinkStatus::makeClosureCall):
+ (JSC::CallLinkStatus::dump):
+ (JSC::CallLinkStatus::computeFromCallEdgeProfile): Deleted.
+ * bytecode/CallLinkStatus.h:
+ (JSC::CallLinkStatus::CallLinkStatus):
+ (JSC::CallLinkStatus::isSet):
+ (JSC::CallLinkStatus::variants):
+ (JSC::CallLinkStatus::size):
+ (JSC::CallLinkStatus::at):
+ (JSC::CallLinkStatus::operator[]):
+ (JSC::CallLinkStatus::canOptimize):
+ (JSC::CallLinkStatus::edges): Deleted.
+ (JSC::CallLinkStatus::canTrustCounts): Deleted.
+ * bytecode/CallVariant.cpp:
+ (JSC::variantListWithVariant):
+ (JSC::despecifiedVariantList):
+ * bytecode/CallVariant.h:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::~CodeBlock):
+ (JSC::CodeBlock::linkIncomingPolymorphicCall):
+ (JSC::CodeBlock::unlinkIncomingCalls):
+ (JSC::CodeBlock::noticeIncomingCall):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::isIncomingCallAlreadyLinked): Deleted.
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
+ (JSC::DFG::ByteCodeParser::handleCall):
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGDriver.cpp:
+ (JSC::DFG::compileImpl):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasHeapPrediction):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGTierUpCheckInjectionPhase.cpp:
+ (JSC::DFG::TierUpCheckInjectionPhase::run):
+ (JSC::DFG::TierUpCheckInjectionPhase::removeFTLProfiling): Deleted.
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * heap/Heap.cpp:
+ (JSC::Heap::collect):
+ * jit/BinarySwitch.h:
+ * jit/ClosureCallStubRoutine.cpp: Removed.
+ * jit/ClosureCallStubRoutine.h: Removed.
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileOpCall):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileOpCall):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ (JSC::operationLinkPolymorphicCallFor):
+ (JSC::operationLinkClosureCallFor): Deleted.
+ * jit/JITStubRoutine.h:
+ * jit/JITWriteBarrier.h:
+ * jit/PolymorphicCallStubRoutine.cpp: Added.
+ (JSC::PolymorphicCallNode::~PolymorphicCallNode):
+ (JSC::PolymorphicCallNode::unlink):
+ (JSC::PolymorphicCallCase::dump):
+ (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
+ (JSC::PolymorphicCallStubRoutine::~PolymorphicCallStubRoutine):
+ (JSC::PolymorphicCallStubRoutine::variants):
+ (JSC::PolymorphicCallStubRoutine::edges):
+ (JSC::PolymorphicCallStubRoutine::visitWeak):
+ (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
+ * jit/PolymorphicCallStubRoutine.h: Added.
+ (JSC::PolymorphicCallNode::PolymorphicCallNode):
+ (JSC::PolymorphicCallCase::PolymorphicCallCase):
+ (JSC::PolymorphicCallCase::variant):
+ (JSC::PolymorphicCallCase::codeBlock):
+ * jit/Repatch.cpp:
+ (JSC::linkSlowFor):
+ (JSC::linkFor):
+ (JSC::revertCall):
+ (JSC::unlinkFor):
+ (JSC::linkVirtualFor):
+ (JSC::linkPolymorphicCall):
+ (JSC::linkClosureCall): Deleted.
+ * jit/Repatch.h:
+ * jit/ThunkGenerators.cpp:
+ (JSC::linkPolymorphicCallForThunkGenerator):
+ (JSC::linkPolymorphicCallThunkGenerator):
+ (JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator):
+ (JSC::linkClosureCallForThunkGenerator): Deleted.
+ (JSC::linkClosureCallThunkGenerator): Deleted.
+ (JSC::linkClosureCallThatPreservesRegsThunkGenerator): Deleted.
+ * jit/ThunkGenerators.h:
+ (JSC::linkPolymorphicCallThunkGeneratorFor):
+ (JSC::linkClosureCallThunkGeneratorFor): Deleted.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::jitCompileAndSetHeuristics):
+ * runtime/Options.h:
+ * runtime/VM.cpp:
+ (JSC::VM::prepareToDiscardCode):
+ (JSC::VM::ensureCallEdgeLog): Deleted.
+ * runtime/VM.h:
+
+2015-01-30 Filip Pizlo <fpizlo@apple.com>
+
+ Converting Flushes and PhantomLocals to Phantoms requires an OSR availability analysis rather than just using the SetLocal's child
+ https://bugs.webkit.org/show_bug.cgi?id=141107
+
+ Reviewed by Michael Saboff.
+
+ See the bugzilla for a discussion of the problem. This addresses the problem by ensuring
+ that Flushes are always strength-reduced to PhantomLocals, and CPS rethreading does a mini
+ OSR availability analysis to determine the right MovHint value to use for the Phantom.
+
+ * dfg/DFGCPSRethreadingPhase.cpp:
+ (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
+ (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
+ (JSC::DFG::CPSRethreadingPhase::clearVariables):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
+ (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
+ (JSC::DFG::CPSRethreadingPhase::clearVariablesAtHeadAndTail): Deleted.
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertPhantomToPhantomLocal):
+ (JSC::DFG::Node::convertFlushToPhantomLocal):
+ (JSC::DFG::Node::convertToPhantomLocal): Deleted.
+ * dfg/DFGStrengthReductionPhase.cpp:
+ (JSC::DFG::StrengthReductionPhase::handleNode):
+ * tests/stress/inline-call-that-doesnt-use-all-args.js: Added.
+ (foo):
+ (bar):
+ (baz):
+
+2015-01-31 Michael Saboff <msaboff@apple.com>
+
+ Crash (DFG assertion) beneath AbstractInterpreter::verifyEdge() @ http://experilous.com/1/planet-generator/2014-09-28/version-1
+ https://bugs.webkit.org/show_bug.cgi?id=141111
+
+ Reviewed by Filip Pizlo.
+
+ In LowerDFGToLLVM::compileNode(), if we determine while compiling a node that we would have
+ exited, we don't need to process the OSR availability or abstract interpreter.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::safelyInvalidateAfterTermination): Broke this out a a separate
+ method since we need to call it at the top and near the bottom of compileNode().
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+
+2015-01-31 Sam Weinig <sam@webkit.org>
+
+ Remove even more Mountain Lion support
+ https://bugs.webkit.org/show_bug.cgi?id=141124
+
+ Reviewed by Alexey Proskuryakov.
+
+ * API/tests/DateTests.mm:
+ * Configurations/Base.xcconfig:
+ * Configurations/DebugRelease.xcconfig:
+ * Configurations/FeatureDefines.xcconfig:
+ * Configurations/Version.xcconfig:
+ * jit/ExecutableAllocatorFixedVMPool.cpp:
+
+2015-01-31 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r179426.
+ https://bugs.webkit.org/show_bug.cgi?id=141119
+
+ "caused a memory use regression" (Requested by Guest45 on
+ #webkit).
+
+ Reverted changeset:
+
+ "Use FastMalloc (bmalloc) instead of BlockAllocator for GC
+ pages"
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+ http://trac.webkit.org/changeset/179426
+
+2015-01-30 Daniel Bates <dabates@apple.com>
+
+ Clean up: Remove unnecessary <dispatch/dispatch.h> header from RemoteInspectorDebuggableConnection.h
+ https://bugs.webkit.org/show_bug.cgi?id=141067
+
+ Reviewed by Timothy Hatcher.
+
+ Remove the header <dispatch/dispatch.h> from RemoteInspectorDebuggableConnection.h as we
+ do not make use of its functionality. Instead, include this header in RemoteInspectorDebuggableConnection.mm
+ and RemoteInspector.mm. The latter depended on <dispatch/dispatch.h> being included via
+ header RemoteInspectorDebuggableConnection.h.
+
+ * inspector/remote/RemoteInspector.mm: Include header <dispatch/dispatch.h>.
+ * inspector/remote/RemoteInspectorDebuggableConnection.h: Remove header <dispatch/dispatch.h>.
+ * inspector/remote/RemoteInspectorDebuggableConnection.mm: Include header <dispatch/dispatch.h>.
+
+2015-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Implement ES6 Symbol
+ https://bugs.webkit.org/show_bug.cgi?id=140435
+
+ Reviewed by Geoffrey Garen.
+
+ This patch implements ES6 Symbol. In this patch, we don't support
+ Symbol.keyFor, Symbol.for, Object.getOwnPropertySymbols. They will be
+ supported in the subsequent patches.
+
+ Since ES6 Symbol is introduced as new primitive value, we implement
+ Symbol as a derived class from JSCell. And now JSValue accepts Symbol*
+ as a new primitive value.
+
+ Symbol has a *unique* flagged StringImpl* as an `uid`. Which pointer
+ value represents the Symbol's identity. So don't compare Symbol's
+ JSCell pointer value for comparison.
+ This enables re-producing Symbol primitive value from StringImpl* uid
+ by executing`Symbol::create(vm, uid)`. This is needed to produce
+ Symbol primitive values from stored StringImpl* in `Object.getOwnPropertySymbols`.
+
+ And Symbol.[[Description]] is folded into the string value of Symbol's uid.
+ By doing so, we can represent ES6 Symbol without extending current PropertyTable key; StringImpl*.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.order:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createBuiltinExecutable):
+ * builtins/BuiltinNames.h:
+ * dfg/DFGOperations.cpp:
+ (JSC::DFG::operationPutByValInternal):
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ * interpreter/Interpreter.cpp:
+ * jit/JITOperations.cpp:
+ (JSC::getByVal):
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::getByVal):
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter.asm:
+ * runtime/CommonIdentifiers.h:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ (JSC::CommonSlowPaths::opIn):
+ * runtime/ExceptionHelpers.cpp:
+ (JSC::createUndefinedVariableError):
+ * runtime/JSCJSValue.cpp:
+ (JSC::JSValue::synthesizePrototype):
+ (JSC::JSValue::dumpInContextAssumingStructure):
+ (JSC::JSValue::toStringSlowCase):
+ * runtime/JSCJSValue.h:
+ * runtime/JSCJSValueInlines.h:
+ (JSC::JSValue::isSymbol):
+ (JSC::JSValue::isPrimitive):
+ (JSC::JSValue::toPropertyKey):
+
+ It represents ToPropertyKey abstract operation in the ES6 spec.
+ It cleans up the old implementation's `isName` checks.
+ And to prevent performance regressions in
+ js/regress/fold-get-by-id-to-multi-get-by-offset-rare-int.html
+ js/regress/fold-get-by-id-to-multi-get-by-offset.html
+ we annnotate this function as ALWAYS_INLINE.
+
+ (JSC::JSValue::getPropertySlot):
+ (JSC::JSValue::get):
+ (JSC::JSValue::equalSlowCaseInline):
+ (JSC::JSValue::strictEqualSlowCaseInline):
+ * runtime/JSCell.cpp:
+ (JSC::JSCell::put):
+ (JSC::JSCell::putByIndex):
+ (JSC::JSCell::toPrimitive):
+ (JSC::JSCell::getPrimitiveNumber):
+ (JSC::JSCell::toNumber):
+ (JSC::JSCell::toObject):
+ * runtime/JSCell.h:
+ * runtime/JSCellInlines.h:
+ (JSC::JSCell::isSymbol):
+ (JSC::JSCell::toBoolean):
+ (JSC::JSCell::pureToBoolean):
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::symbolPrototype):
+ (JSC::JSGlobalObject::symbolObjectStructure):
+ * runtime/JSONObject.cpp:
+ (JSC::Stringifier::Stringifier):
+ * runtime/JSSymbolTableObject.cpp:
+ (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
+ * runtime/JSType.h:
+ * runtime/JSTypeInfo.h:
+ (JSC::TypeInfo::isName): Deleted.
+ * runtime/MapData.cpp:
+ (JSC::MapData::find):
+ (JSC::MapData::add):
+ (JSC::MapData::remove):
+ (JSC::MapData::replaceAndPackBackingStore):
+ * runtime/MapData.h:
+ (JSC::MapData::clear):
+ * runtime/NameInstance.h: Removed.
+ * runtime/NamePrototype.cpp: Removed.
+ * runtime/ObjectConstructor.cpp:
+ (JSC::objectConstructorGetOwnPropertyDescriptor):
+ (JSC::objectConstructorDefineProperty):
+ * runtime/ObjectPrototype.cpp:
+ (JSC::objectProtoFuncHasOwnProperty):
+ (JSC::objectProtoFuncDefineGetter):
+ (JSC::objectProtoFuncDefineSetter):
+ (JSC::objectProtoFuncLookupGetter):
+ (JSC::objectProtoFuncLookupSetter):
+ (JSC::objectProtoFuncPropertyIsEnumerable):
+ * runtime/Operations.cpp:
+ (JSC::jsTypeStringForValue):
+ (JSC::jsIsObjectType):
+ * runtime/PrivateName.h:
+ (JSC::PrivateName::PrivateName):
+ (JSC::PrivateName::operator==):
+ (JSC::PrivateName::operator!=):
+ * runtime/PropertyMapHashTable.h:
+ (JSC::PropertyTable::find):
+ (JSC::PropertyTable::get):
+ * runtime/PropertyName.h:
+ (JSC::PropertyName::PropertyName):
+ (JSC::PropertyName::publicName):
+ * runtime/SmallStrings.h:
+ * runtime/StringConstructor.cpp:
+ (JSC::callStringConstructor):
+
+ In ES6, String constructor accepts Symbol to execute `String(symbol)`.
+
+ * runtime/Structure.cpp:
+ (JSC::Structure::getPropertyNamesFromStructure):
+ * runtime/StructureInlines.h:
+ (JSC::Structure::prototypeForLookup):
+ * runtime/Symbol.cpp: Added.
+ (JSC::Symbol::Symbol):
+ (JSC::SymbolObject::create):
+ (JSC::Symbol::toPrimitive):
+ (JSC::Symbol::toBoolean):
+ (JSC::Symbol::getPrimitiveNumber):
+ (JSC::Symbol::toObject):
+ (JSC::Symbol::toNumber):
+ (JSC::Symbol::destroy):
+ (JSC::Symbol::descriptiveString):
+ * runtime/Symbol.h: Added.
+ (JSC::Symbol::createStructure):
+ (JSC::Symbol::create):
+ (JSC::Symbol::privateName):
+ (JSC::Symbol::finishCreation):
+ (JSC::asSymbol):
+ * runtime/SymbolConstructor.cpp: Renamed from Source/JavaScriptCore/runtime/NameConstructor.cpp.
+ (JSC::SymbolConstructor::SymbolConstructor):
+ (JSC::SymbolConstructor::finishCreation):
+ (JSC::callSymbol):
+ (JSC::SymbolConstructor::getConstructData):
+ (JSC::SymbolConstructor::getCallData):
+ * runtime/SymbolConstructor.h: Renamed from Source/JavaScriptCore/runtime/NameConstructor.h.
+ (JSC::SymbolConstructor::create):
+ (JSC::SymbolConstructor::createStructure):
+ * runtime/SymbolObject.cpp: Renamed from Source/JavaScriptCore/runtime/NameInstance.cpp.
+ (JSC::SymbolObject::SymbolObject):
+ (JSC::SymbolObject::finishCreation):
+ (JSC::SymbolObject::defaultValue):
+
+ Now JSC doesn't support @@toPrimitive. So instead of it, we implement
+ Symbol.prototype[@@toPrimitive] as ES5 Symbol.[[DefaultValue]].
+
+ * runtime/SymbolObject.h: Added.
+ (JSC::SymbolObject::create):
+ (JSC::SymbolObject::internalValue):
+ (JSC::SymbolObject::createStructure):
+ * runtime/SymbolPrototype.cpp: Added.
+ (JSC::SymbolPrototype::SymbolPrototype):
+ (JSC::SymbolPrototype::finishCreation):
+ (JSC::SymbolPrototype::getOwnPropertySlot):
+ (JSC::symbolProtoFuncToString):
+ (JSC::symbolProtoFuncValueOf):
+ * runtime/SymbolPrototype.h: Renamed from Source/JavaScriptCore/runtime/NamePrototype.h.
+ (JSC::SymbolPrototype::create):
+ (JSC::SymbolPrototype::createStructure):
+
+ SymbolPrototype object is ordinary JS object. Not wrapper object of Symbol.
+ It is tested in js/symbol-prototype-is-ordinary-object.html.
+
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+
+2015-01-30 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the HandleBlock piece of this patch.
+
+ * heap/HandleBlock.h:
+ * heap/HandleBlockInlines.h:
+ (JSC::HandleBlock::create):
+ (JSC::HandleBlock::destroy):
+ (JSC::HandleBlock::HandleBlock):
+ (JSC::HandleBlock::payloadEnd):
+ * heap/HandleSet.cpp:
+ (JSC::HandleSet::~HandleSet):
+ (JSC::HandleSet::grow):
+
+2015-01-30 Geoffrey Garen <ggaren@apple.com>
+
+ GC marking threads should clear malloc caches
+ https://bugs.webkit.org/show_bug.cgi?id=141097
+
+ Reviewed by Sam Weinig.
+
+ Follow-up based on Mark Hahnenberg's review: Release after the copy
+ phase, rather than after any phase, since we'd rather not release
+ between marking and copying.
+
+ * heap/GCThread.cpp:
+ (JSC::GCThread::waitForNextPhase):
+ (JSC::GCThread::gcThreadMain):
+
+2015-01-30 Geoffrey Garen <ggaren@apple.com>
+
+ GC marking threads should clear malloc caches
+ https://bugs.webkit.org/show_bug.cgi?id=141097
+
+ Reviewed by Andreas Kling.
+
+ This is an attempt to ameliorate a potential memory use regression
+ caused by https://bugs.webkit.org/show_bug.cgi?id=140900
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages.
+
+ FastMalloc may accumulate a per-thread cache on each of the 8-ish
+ GC marking threads, which can be expensive.
+
+ * heap/GCThread.cpp:
+ (JSC::GCThread::waitForNextPhase): Scavenge the current thread before
+ going to sleep. There's probably not too much value to keeping our
+ per-thread cache between GCs, and it has some memory footprint.
+
+2015-01-30 Chris Dumez <cdumez@apple.com>
+
+ Rename shared() static member functions to singleton() for singleton classes.
+ https://bugs.webkit.org/show_bug.cgi?id=141088
+
+ Reviewed by Ryosuke Niwa and Benjamin Poulain.
+
+ Rename shared() static member functions to singleton() for singleton
+ classes as per the recent coding style change.
+
+ * inspector/remote/RemoteInspector.h:
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::singleton):
+ (Inspector::RemoteInspector::start):
+ (Inspector::RemoteInspector::shared): Deleted.
+ * inspector/remote/RemoteInspectorDebuggable.cpp:
+ (Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable):
+ (Inspector::RemoteInspectorDebuggable::init):
+ (Inspector::RemoteInspectorDebuggable::update):
+ (Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed):
+ (Inspector::RemoteInspectorDebuggable::pauseWaitingForAutomaticInspection):
+ (Inspector::RemoteInspectorDebuggable::unpauseForInitializedInspector):
+ * inspector/remote/RemoteInspectorDebuggableConnection.mm:
+ (Inspector::RemoteInspectorDebuggableConnection::setup):
+ (Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend):
+
+2015-01-30 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the CopyWorkListSegment piece of this patch.
+
+ * heap/CopiedBlockInlines.h:
+ (JSC::CopiedBlock::reportLiveBytes):
+ * heap/CopyWorkList.h:
+ (JSC::CopyWorkListSegment::create):
+ (JSC::CopyWorkListSegment::destroy):
+ (JSC::CopyWorkListSegment::CopyWorkListSegment):
+ (JSC::CopyWorkList::CopyWorkList):
+ (JSC::CopyWorkList::~CopyWorkList):
+ (JSC::CopyWorkList::append):
+
+2015-01-29 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r179357 and r179358.
+ https://bugs.webkit.org/show_bug.cgi?id=141062
+
+ Suspect this caused WebGL tests to start flaking (Requested by
+ kling on #webkit).
+
+ Reverted changesets:
+
+ "Polymorphic call inlining should be based on polymorphic call
+ inline caching rather than logging"
+ https://bugs.webkit.org/show_bug.cgi?id=140660
+ http://trac.webkit.org/changeset/179357
+
+ "Unreviewed, fix no-JIT build."
+ http://trac.webkit.org/changeset/179358
+
+2015-01-29 Geoffrey Garen <ggaren@apple.com>
+
+ Removed op_ret_object_or_this
+ https://bugs.webkit.org/show_bug.cgi?id=141048
+
+ Reviewed by Michael Saboff.
+
+ op_ret_object_or_this was one opcode that would keep us out of the
+ optimizing compilers.
+
+ We don't need a special-purpose opcode; we can just use a branch.
+
+ * bytecode/BytecodeBasicBlock.cpp:
+ (JSC::isTerminal): Removed.
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset): Removed.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Removed.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitReturn): Use an explicit branch to determine
+ if we need to substitute 'this' for the return value. Our engine no longer
+ benefits from fused opcodes that dispatch less in the interpreter.
+
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::emit_op_ret_object_or_this): Deleted.
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_ret_object_or_this): Deleted.
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm: Removed.
+
+2015-01-29 Ryosuke Niwa <rniwa@webkit.org>
+
+ Implement ES6 class syntax without inheritance support
+ https://bugs.webkit.org/show_bug.cgi?id=140918
+
+ Reviewed by Geoffrey Garen.
+
+ Added the most basic support for ES6 class syntax. After this patch, we support basic class definition like:
+ class A {
+ constructor() { }
+ someMethod() { }
+ }
+
+ We'll add the support for "extends" keyword and automatically generating a constructor in follow up patches.
+ We also don't support block scoping of a class declaration.
+
+ We support both class declaration and class expression. A class expression is implemented by the newly added
+ ClassExprNode AST node. A class declaration is implemented by ClassDeclNode, which is a thin wrapper around
+ AssignResolveNode.
+
+ Tests: js/class-syntax-declaration.html
+ js/class-syntax-expression.html
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ObjectLiteralNode::emitBytecode): Create a new object instead of delegating the work to PropertyListNode.
+ Also fixed the 5-space indentation.
+ (JSC::PropertyListNode::emitBytecode): Don't create a new object now that ObjectLiteralNode does this.
+ (JSC::ClassDeclNode::emitBytecode): Added. Just let the AssignResolveNode node emit the byte code.
+ (JSC::ClassExprNode::emitBytecode): Create the class constructor and add static methods to the constructor by
+ emitting the byte code for PropertyListNode. Add instance methods to the class's prototype object the same way.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createClassExpr): Added. Creates a ClassExprNode.
+ (JSC::ASTBuilder::createClassDeclStatement): Added. Creates a AssignResolveNode and wraps it by a ClassDeclNode.
+
+ * parser/NodeConstructors.h:
+ (JSC::ClassDeclNode::ClassDeclNode): Added.
+ (JSC::ClassExprNode::ClassExprNode): Added.
+
+ * parser/Nodes.h:
+ (JSC::ClassExprNode): Added.
+ (JSC::ClassDeclNode): Added.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseStatement): Added the support for class declaration.
+ (JSC::stringForFunctionMode): Return "method" for MethodMode.
+ (JSC::Parser<LexerType>::parseClassDeclaration): Added. Uses parseClass to create a class expression and wraps
+ it with ClassDeclNode as described above.
+ (JSC::Parser<LexerType>::parseClass): Parses a class expression.
+ (JSC::Parser<LexerType>::parseProperty):
+ (JSC::Parser<LexerType>::parseGetterSetter): Extracted from parseProperty to share the code between parseProperty
+ and parseClass.
+ (JSC::Parser<LexerType>::parsePrimaryExpression): Added the support for class expression.
+
+ * parser/Parser.h:
+ (FunctionParseMode): Added MethodMode.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createClassExpr): Added.
+ (JSC::SyntaxChecker::createClassDeclStatement): Added.
+
+2015-01-29 Geoffrey Garen <ggaren@apple.com>
+
+ Try to fix the Windows build.
+
+ Not reviewed.
+
+ * heap/WeakBlock.h: Use the fully qualified name when declaring our friend.
+
+2015-01-29 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the WeakBlock piece of this patch.
+
+ * heap/WeakBlock.cpp:
+ (JSC::WeakBlock::create):
+ (JSC::WeakBlock::destroy):
+ (JSC::WeakBlock::WeakBlock):
+ * heap/WeakBlock.h:
+ * heap/WeakSet.cpp:
+ (JSC::WeakSet::~WeakSet):
+ (JSC::WeakSet::addAllocator):
+ (JSC::WeakSet::removeAllocator):
+
+2015-01-29 Geoffrey Garen <ggaren@apple.com>
+
+ Use Vector instead of GCSegmentedArray in CodeBlockSet
+ https://bugs.webkit.org/show_bug.cgi?id=141044
+
+ Reviewed by Ryosuke Niwa.
+
+ This is allowed now that we've gotten rid of fastMallocForbid.
+
+ 4kB was a bit overkill for just storing a few pointers.
+
+ * heap/CodeBlockSet.cpp:
+ (JSC::CodeBlockSet::CodeBlockSet):
+ * heap/CodeBlockSet.h:
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+
+2015-01-29 Filip Pizlo <fpizlo@apple.com>
+
+ Unreviewed, fix no-JIT build.
+
+ * jit/PolymorphicCallStubRoutine.cpp:
+
+2015-01-28 Filip Pizlo <fpizlo@apple.com>
+
+ Polymorphic call inlining should be based on polymorphic call inline caching rather than logging
+ https://bugs.webkit.org/show_bug.cgi?id=140660
+
+ Reviewed by Geoffrey Garen.
+
+ When we first implemented polymorphic call inlining, we did the profiling based on a call
+ edge log. The idea was to store each call edge (a tuple of call site and callee) into a
+ global log that was processed lazily. Processing the log would give precise counts of call
+ edges, and could be used to drive well-informed inlining decisions - polymorphic or not.
+ This was a speed-up on throughput tests but a slow-down for latency tests. It was a net win
+ nonetheless.
+
+ Experience with this code shows three things. First, the call edge profiler is buggy and
+ complex. It would take work to fix the bugs. Second, the call edge profiler incurs lots of
+ overhead for latency code that we care deeply about. Third, it's not at all clear that
+ having call edge counts for every possible callee is any better than just having call edge
+ counts for the limited number of callees that an inline cache would catch.
+
+ So, this patch removes the call edge profiler and replaces it with a polymorphic call inline
+ cache. If we miss the basic call inline cache, we inflate the cache to be a jump to an
+ out-of-line stub that cases on the previously known callees. If that misses again, then we
+ rewrite that stub to include the new callee. We do this up to some number of callees. If we
+ hit the limit then we switch to using a plain virtual call.
+
+ Substantial speed-up on V8Spider; undoes the slow-down that the original call edge profiler
+ caused. Might be a SunSpider speed-up (below 1%), depending on hardware.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/CallEdge.h:
+ (JSC::CallEdge::count):
+ (JSC::CallEdge::CallEdge):
+ * bytecode/CallEdgeProfile.cpp: Removed.
+ * bytecode/CallEdgeProfile.h: Removed.
+ * bytecode/CallEdgeProfileInlines.h: Removed.
+ * bytecode/CallLinkInfo.cpp:
+ (JSC::CallLinkInfo::unlink):
+ (JSC::CallLinkInfo::visitWeak):
+ * bytecode/CallLinkInfo.h:
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::CallLinkStatus):
+ (JSC::CallLinkStatus::computeFor):
+ (JSC::CallLinkStatus::computeFromCallLinkInfo):
+ (JSC::CallLinkStatus::isClosureCall):
+ (JSC::CallLinkStatus::makeClosureCall):
+ (JSC::CallLinkStatus::dump):
+ (JSC::CallLinkStatus::computeFromCallEdgeProfile): Deleted.
+ * bytecode/CallLinkStatus.h:
+ (JSC::CallLinkStatus::CallLinkStatus):
+ (JSC::CallLinkStatus::isSet):
+ (JSC::CallLinkStatus::variants):
+ (JSC::CallLinkStatus::size):
+ (JSC::CallLinkStatus::at):
+ (JSC::CallLinkStatus::operator[]):
+ (JSC::CallLinkStatus::canOptimize):
+ (JSC::CallLinkStatus::edges): Deleted.
+ (JSC::CallLinkStatus::canTrustCounts): Deleted.
+ * bytecode/CallVariant.cpp:
+ (JSC::variantListWithVariant):
+ (JSC::despecifiedVariantList):
+ * bytecode/CallVariant.h:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::~CodeBlock):
+ (JSC::CodeBlock::linkIncomingPolymorphicCall):
+ (JSC::CodeBlock::unlinkIncomingCalls):
+ (JSC::CodeBlock::noticeIncomingCall):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::isIncomingCallAlreadyLinked): Deleted.
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
+ (JSC::DFG::ByteCodeParser::handleCall):
+ (JSC::DFG::ByteCodeParser::handleInlining):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::foldConstants):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGDriver.cpp:
+ (JSC::DFG::compileImpl):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::hasHeapPrediction):
+ * dfg/DFGNodeType.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGPredictionPropagationPhase.cpp:
+ (JSC::DFG::PredictionPropagationPhase::propagate):
+ * dfg/DFGSafeToExecute.h:
+ (JSC::DFG::safeToExecute):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGTierUpCheckInjectionPhase.cpp:
+ (JSC::DFG::TierUpCheckInjectionPhase::run):
+ (JSC::DFG::TierUpCheckInjectionPhase::removeFTLProfiling): Deleted.
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * heap/Heap.cpp:
+ (JSC::Heap::collect):
+ * jit/BinarySwitch.h:
+ * jit/ClosureCallStubRoutine.cpp: Removed.
+ * jit/ClosureCallStubRoutine.h: Removed.
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileOpCall):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileOpCall):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ (JSC::operationLinkPolymorphicCallFor):
+ (JSC::operationLinkClosureCallFor): Deleted.
+ * jit/JITStubRoutine.h:
+ * jit/JITWriteBarrier.h:
+ * jit/PolymorphicCallStubRoutine.cpp: Added.
+ (JSC::PolymorphicCallNode::~PolymorphicCallNode):
+ (JSC::PolymorphicCallNode::unlink):
+ (JSC::PolymorphicCallCase::dump):
+ (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
+ (JSC::PolymorphicCallStubRoutine::~PolymorphicCallStubRoutine):
+ (JSC::PolymorphicCallStubRoutine::variants):
+ (JSC::PolymorphicCallStubRoutine::edges):
+ (JSC::PolymorphicCallStubRoutine::visitWeak):
+ (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
+ * jit/PolymorphicCallStubRoutine.h: Added.
+ (JSC::PolymorphicCallNode::PolymorphicCallNode):
+ (JSC::PolymorphicCallCase::PolymorphicCallCase):
+ (JSC::PolymorphicCallCase::variant):
+ (JSC::PolymorphicCallCase::codeBlock):
+ * jit/Repatch.cpp:
+ (JSC::linkSlowFor):
+ (JSC::linkFor):
+ (JSC::revertCall):
+ (JSC::unlinkFor):
+ (JSC::linkVirtualFor):
+ (JSC::linkPolymorphicCall):
+ (JSC::linkClosureCall): Deleted.
+ * jit/Repatch.h:
+ * jit/ThunkGenerators.cpp:
+ (JSC::linkPolymorphicCallForThunkGenerator):
+ (JSC::linkPolymorphicCallThunkGenerator):
+ (JSC::linkPolymorphicCallThatPreservesRegsThunkGenerator):
+ (JSC::linkClosureCallForThunkGenerator): Deleted.
+ (JSC::linkClosureCallThunkGenerator): Deleted.
+ (JSC::linkClosureCallThatPreservesRegsThunkGenerator): Deleted.
+ * jit/ThunkGenerators.h:
+ (JSC::linkPolymorphicCallThunkGeneratorFor):
+ (JSC::linkClosureCallThunkGeneratorFor): Deleted.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::jitCompileAndSetHeuristics):
+ * runtime/Options.h:
+ * runtime/VM.cpp:
+ (JSC::VM::prepareToDiscardCode):
+ (JSC::VM::ensureCallEdgeLog): Deleted.
+ * runtime/VM.h:
+
+2015-01-29 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ES6: Improved Console Format for Set and Map Objects (like Arrays)
+ https://bugs.webkit.org/show_bug.cgi?id=122867
+
+ Reviewed by Timothy Hatcher.
+
+ Add new Runtime.RemoteObject object subtypes for "map", "set", and "weakmap".
+
+ Upgrade Runtime.ObjectPreview to include type/subtype information. Now,
+ an ObjectPreview can be used for any value, in place of a RemoteObject,
+ and not capture / hold a reference to the value. The value will be in
+ the string description.
+
+ Adding this information to ObjectPreview can duplicate some information
+ in the protocol messages if a preview is provided, but simplifies
+ previews, so that all the information you need for any RemoteObject
+ preview is available. To slim messages further, make "overflow" and
+ "properties" only available on previews that may contain properties.
+ So, not primitives or null.
+
+ Finally, for "Map/Set/WeakMap" add an "entries" list to the preview
+ that will return previews with "key" and "value" properties depending
+ on the collection type. To get live, non-preview objects from a
+ collection, use Runtime.getCollectionEntries.
+
+ In order to keep the WeakMap's values Weak the frontend may provide
+ a unique object group name when getting collection entries. It may
+ then release that object group, e.g. when not showing the WeakMap's
+ values to the user, and thus remove the strong reference to the keys
+ so they may be garbage collected.
+
+ * runtime/WeakMapData.h:
+ (JSC::WeakMapData::begin):
+ (JSC::WeakMapData::end):
+ Expose iterators so the Inspector may access WeakMap keys/values.
+
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries):
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ Discern "map", "set", and "weakmap" object subtypes.
+
+ (Inspector::JSInjectedScriptHost::weakMapEntries):
+ Return a list of WeakMap entries. These are strong references
+ that the Inspector code is responsible for releasing.
+
+ * inspector/protocol/Runtime.json:
+ Update types and expose the new getCollectionEntries command.
+
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::getCollectionEntries):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getInternalProperties):
+ (Inspector::InjectedScript::getCollectionEntries):
+ Pass through to the InjectedScript and call getCollectionEntries.
+
+ * inspector/scripts/codegen/generator.py:
+ Add another type with runtime casting.
+
+ * inspector/InjectedScriptSource.js:
+ - Implement getCollectionEntries to get a range of values from a
+ collection. The non-Weak collections have an order to their keys (in
+ order of added) so range'd gets are okay. WeakMap does not have an
+ order, so only allow fetching a number of values.
+ - Update preview generation to address the Runtime.ObjectPreview
+ type changes.
+
+2015-01-28 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Re-landing just the GCArraySegment piece of this patch.
+
+ * heap/CodeBlockSet.cpp:
+ (JSC::CodeBlockSet::CodeBlockSet):
+ * heap/CodeBlockSet.h:
+ * heap/GCSegmentedArray.h:
+ (JSC::GCArraySegment::GCArraySegment):
+ * heap/GCSegmentedArrayInlines.h:
+ (JSC::GCSegmentedArray<T>::GCSegmentedArray):
+ (JSC::GCSegmentedArray<T>::~GCSegmentedArray):
+ (JSC::GCSegmentedArray<T>::clear):
+ (JSC::GCSegmentedArray<T>::expand):
+ (JSC::GCSegmentedArray<T>::refill):
+ (JSC::GCArraySegment<T>::create):
+ (JSC::GCArraySegment<T>::destroy):
+ * heap/GCThreadSharedData.cpp:
+ (JSC::GCThreadSharedData::GCThreadSharedData):
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ * heap/MarkStack.cpp:
+ (JSC::MarkStackArray::MarkStackArray):
+ * heap/MarkStack.h:
+ * heap/SlotVisitor.cpp:
+ (JSC::SlotVisitor::SlotVisitor):
+
+2015-01-29 Csaba Osztrogonác <ossy@webkit.org>
+
+ Move HAVE_DTRACE definition back to Platform.h
+ https://bugs.webkit.org/show_bug.cgi?id=141033
+
+ Reviewed by Dan Bernstein.
+
+ * Configurations/Base.xcconfig:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2015-01-28 Geoffrey Garen <ggaren@apple.com>
+
+ Removed fastMallocForbid / fastMallocAllow
+ https://bugs.webkit.org/show_bug.cgi?id=141012
+
+ Reviewed by Mark Hahnenberg.
+
+ Copy non-current thread stacks before scanning them instead of scanning
+ them in-place.
+
+ This operation is uncommon (i.e., never in the web content process),
+ and even in a stress test with 4 threads it only copies about 27kB,
+ so I think the performance cost is OK.
+
+ Scanning in-place requires a complex dance where we constrain our GC
+ data structures not to use malloc, free, or any other interesting functions
+ that might acquire locks. We've gotten this wrong many times in the past,
+ and I just got it wrong again yesterday. Since this code path is rarely
+ tested, I want it to just make sense, and not depend on or constrain the
+ details of the rest of the GC heap's design.
+
+ * heap/MachineStackMarker.cpp:
+ (JSC::otherThreadStack): Factored out a helper function for dealing with
+ unaligned and/or backwards pointers.
+
+ (JSC::MachineThreads::tryCopyOtherThreadStack): This is now the only
+ constrained function, and it only calls memcpy and low-level thread APIs.
+
+ (JSC::MachineThreads::tryCopyOtherThreadStacks): The design here is that
+ you do one pass over all the threads to compute their combined size,
+ and then a second pass to do all the copying. In theory, the threads may
+ grow in between passes, in which case you'll continue until the threads
+ stop growing. In practice, you never continue.
+
+ (JSC::growBuffer): Helper function for growing.
+
+ (JSC::MachineThreads::gatherConservativeRoots):
+ (JSC::MachineThreads::gatherFromOtherThread): Deleted.
+ * heap/MachineStackMarker.h: Updated for interface changes.
+
+2015-01-28 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: remove CSS.setPropertyText, CSS.toggleProperty and related dead code
+ https://bugs.webkit.org/show_bug.cgi?id=140961
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/CSS.json: Remove unused protocol methods.
+
+2015-01-28 Dana Burkart <dburkart@apple.com>
+
+ Move ASan flag settings from DebugRelease.xcconfig to Base.xcconfig
+ https://bugs.webkit.org/show_bug.cgi?id=136765
+
+ Reviewed by Alexey Proskuryakov.
+
+ * Configurations/Base.xcconfig:
+ * Configurations/DebugRelease.xcconfig:
+
+2015-01-27 Filip Pizlo <fpizlo@apple.com>
+
+ ExitSiteData saying m_takesSlowPath shouldn't mean early returning takesSlowPath() since for the non-LLInt case we later set m_couldTakeSlowPath, which is more precise
+ https://bugs.webkit.org/show_bug.cgi?id=140980
+
+ Reviewed by Oliver Hunt.
+
+ * bytecode/CallLinkStatus.cpp:
+ (JSC::CallLinkStatus::computeFor):
+
+2015-01-27 Filip Pizlo <fpizlo@apple.com>
+
+ Move DFGBinarySwitch out of the DFG so that all of the JITs can use it
+ https://bugs.webkit.org/show_bug.cgi?id=140959
+
+ Rubber stamped by Geoffrey Garen.
+
+ I want to use this for polymorphic stubs for https://bugs.webkit.org/show_bug.cgi?id=140660.
+ This code no longer has DFG dependencies so this is a very clean move.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * dfg/DFGBinarySwitch.cpp: Removed.
+ * dfg/DFGBinarySwitch.h: Removed.
+ * dfg/DFGSpeculativeJIT.cpp:
+ * jit/BinarySwitch.cpp: Copied from Source/JavaScriptCore/dfg/DFGBinarySwitch.cpp.
+ * jit/BinarySwitch.h: Copied from Source/JavaScriptCore/dfg/DFGBinarySwitch.h.
+
+2015-01-27 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r179192.
+ https://bugs.webkit.org/show_bug.cgi?id=140953
+
+ Caused numerous layout test failures (Requested by mattbaker_
+ on #webkit).
+
+ Reverted changeset:
+
+ "Use FastMalloc (bmalloc) instead of BlockAllocator for GC
+ pages"
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+ http://trac.webkit.org/changeset/179192
+
+2015-01-27 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(r178591): 20% regression in Octane box2d
+ https://bugs.webkit.org/show_bug.cgi?id=140948
+
+ Reviewed by Geoffrey Garen.
+
+ Added check that we have a lexical environment to the arguments is captured check.
+ It doesn't make sense to resolve "arguments" when it really isn't captured.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::willResolveToArgumentsRegister):
+
+2015-01-26 Geoffrey Garen <ggaren@apple.com>
+
+ Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
+ https://bugs.webkit.org/show_bug.cgi?id=140900
+
+ Reviewed by Mark Hahnenberg.
+
+ Removes some more custom allocation code.
+
+ Looks like a speedup. (See results attached to bugzilla.)
+
+ Will hopefully reduce memory use by improving sharing between the GC and
+ malloc heaps.
+
+ * API/JSBase.cpp:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj: Feed the compiler.
+
+ * heap/BlockAllocator.cpp: Removed.
+ * heap/BlockAllocator.h: Removed. No need for a custom allocator anymore.
+
+ * heap/CodeBlockSet.cpp:
+ (JSC::CodeBlockSet::CodeBlockSet):
+ * heap/CodeBlockSet.h: Feed the compiler.
+
+ * heap/CopiedBlock.h:
+ (JSC::CopiedBlock::createNoZeroFill):
+ (JSC::CopiedBlock::create):
+ (JSC::CopiedBlock::CopiedBlock):
+ (JSC::CopiedBlock::isOversize):
+ (JSC::CopiedBlock::payloadEnd):
+ (JSC::CopiedBlock::capacity):
+ * heap/CopiedBlockInlines.h:
+ (JSC::CopiedBlock::reportLiveBytes): Each copied block now tracks its
+ own size, since we can't rely on Region to tell us our size anymore.
+
+ * heap/CopiedSpace.cpp:
+ (JSC::CopiedSpace::~CopiedSpace):
+ (JSC::CopiedSpace::tryAllocateOversize):
+ (JSC::CopiedSpace::tryReallocateOversize):
+ * heap/CopiedSpaceInlines.h:
+ (JSC::CopiedSpace::recycleEvacuatedBlock):
+ (JSC::CopiedSpace::recycleBorrowedBlock):
+ (JSC::CopiedSpace::allocateBlockForCopyingPhase):
+ (JSC::CopiedSpace::allocateBlock):
+ (JSC::CopiedSpace::startedCopying): Deallocate blocks directly, rather
+ than pushing them onto the block allocator's free list; the block
+ allocator doesn't exist anymore.
+
+ * heap/CopyWorkList.h:
+ (JSC::CopyWorkListSegment::create):
+ (JSC::CopyWorkListSegment::CopyWorkListSegment):
+ (JSC::CopyWorkList::~CopyWorkList):
+ (JSC::CopyWorkList::append):
+ (JSC::CopyWorkList::CopyWorkList): Deleted.
+ * heap/GCSegmentedArray.h:
+ (JSC::GCArraySegment::GCArraySegment):
+ * heap/GCSegmentedArrayInlines.h:
+ (JSC::GCSegmentedArray<T>::GCSegmentedArray):
+ (JSC::GCSegmentedArray<T>::~GCSegmentedArray):
+ (JSC::GCSegmentedArray<T>::clear):
+ (JSC::GCSegmentedArray<T>::expand):
+ (JSC::GCSegmentedArray<T>::refill):
+ (JSC::GCArraySegment<T>::create):
+ * heap/GCThreadSharedData.cpp:
+ (JSC::GCThreadSharedData::GCThreadSharedData):
+ * heap/GCThreadSharedData.h: Feed the compiler.
+
+ * heap/HandleBlock.h:
+ * heap/HandleBlockInlines.h:
+ (JSC::HandleBlock::create):
+ (JSC::HandleBlock::HandleBlock):
+ (JSC::HandleBlock::payloadEnd):
+ * heap/HandleSet.cpp:
+ (JSC::HandleSet::~HandleSet):
+ (JSC::HandleSet::grow): Same as above.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ * heap/Heap.h: Removed the block allocator since it is unused now.
+
+ * heap/HeapBlock.h:
+ (JSC::HeapBlock::destroy):
+ (JSC::HeapBlock::HeapBlock):
+ (JSC::HeapBlock::region): Deleted. Removed the Region pointer from each
+ HeapBlock since a HeapBlock is just a normal allocation now.
+
+ * heap/HeapInlines.h:
+ (JSC::Heap::blockAllocator): Deleted.
+
+ * heap/HeapTimer.cpp:
+ * heap/MarkStack.cpp:
+ (JSC::MarkStackArray::MarkStackArray):
+ * heap/MarkStack.h: Feed the compiler.
+
+ * heap/MarkedAllocator.cpp:
+ (JSC::MarkedAllocator::allocateBlock): No need to use a custom code path
+ based on size, since we use a general purpose allocator now.
+
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::create):
+ (JSC::MarkedBlock::destroy):
+ (JSC::MarkedBlock::MarkedBlock):
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::capacity): Track block size explicitly, like CopiedBlock.
+
+ * heap/MarkedSpace.cpp:
+ (JSC::MarkedSpace::freeBlock):
+ * heap/MarkedSpace.h:
+
+ * heap/Region.h: Removed.
+
+ * heap/SlotVisitor.cpp:
+ (JSC::SlotVisitor::SlotVisitor): Removed reference to block allocator.
+
+ * heap/SuperRegion.cpp: Removed.
+ * heap/SuperRegion.h: Removed.
+
+ * heap/WeakBlock.cpp:
+ (JSC::WeakBlock::create):
+ (JSC::WeakBlock::WeakBlock):
+ * heap/WeakBlock.h:
+ * heap/WeakSet.cpp:
+ (JSC::WeakSet::~WeakSet):
+ (JSC::WeakSet::addAllocator):
+ (JSC::WeakSet::removeAllocator): Removed reference to block allocator.
+
+2015-01-27 Csaba Osztrogonác <ossy@webkit.org>
+
+ [ARM] Typo fix after r176083
+ https://bugs.webkit.org/show_bug.cgi?id=140937
+
+ Reviewed by Anders Carlsson.
+
+ * assembler/ARMv7Assembler.h:
+ (JSC::ARMv7Assembler::ldrh):
+
+2015-01-27 Csaba Osztrogonác <ossy@webkit.org>
+
+ [Win] Unreviewed gardening, skip failing tests.
+
+ * tests/exceptionFuzz.yaml: Skip exception fuzz tests due to bug140928.
+ * tests/mozilla/mozilla-tests.yaml: Skip ecma/Date/15.9.5.28-1.js due to bug140927.
+
+2015-01-26 Csaba Osztrogonác <ossy@webkit.org>
+
+ [Win] Enable JSC stress tests by default
+ https://bugs.webkit.org/show_bug.cgi?id=128307
+
+ Unreviewed typo fix after r179165.
+
+ * tests/mozilla/mozilla-tests.yaml:
+
+2015-01-26 Csaba Osztrogonác <ossy@webkit.org>
+
+ [Win] Enable JSC stress tests by default
+ https://bugs.webkit.org/show_bug.cgi?id=128307
+
+ Reviewed by Brent Fulgham.
+
+ * tests/mozilla/mozilla-tests.yaml: Skipped on Windows.
+ * tests/stress/ftl-arithcos.js: Skipped on Windows.
+
+2015-01-26 Ryosuke Niwa <rniwa@webkit.org>
+
+ Parse a function expression as a primary expression
+ https://bugs.webkit.org/show_bug.cgi?id=140908
+
+ Reviewed by Mark Lam.
+
+ Moved the code to generate an AST node for a function expression from parseMemberExpression
+ to parsePrimaryExpression to match the ES6 specification terminology:
+ https://people.mozilla.org/~jorendorff/es6-draft.html#sec-primary-expression
+
+ There should be no behavior change from this change since parsePrimaryExpression is only
+ called in parseMemberExpression other than the fact failIfStackOverflow() is called.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parsePrimaryExpression):
+ (JSC::Parser<LexerType>::parseMemberExpression):
+
+2015-01-26 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [iOS] [SVG -> OTF Converter] Flip the switch off on iOS
+ https://bugs.webkit.org/show_bug.cgi?id=140860
+
+ Reviewed by Darin Adler.
+
+ The fonts it makes are grotesque. (See what I did there? Typographic
+ humor is the best humor.)
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-01-23 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Rename InjectedScriptHost::type to subtype
+ https://bugs.webkit.org/show_bug.cgi?id=140841
+
+ Reviewed by Timothy Hatcher.
+
+ We were using this to set the subtype of an "object" type RemoteObject
+ so we should clean up the name and call it subtype.
+
+ * inspector/InjectedScriptHost.h:
+ * inspector/InjectedScriptSource.js:
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::subtype):
+ (Inspector::JSInjectedScriptHost::type): Deleted.
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionSubtype):
+ (Inspector::jsInjectedScriptHostPrototypeFunctionType): Deleted.
+
+2015-01-23 Michael Saboff <msaboff@apple.com>
+
+ LayoutTests/js/script-tests/reentrant-caching.js crashing on 32 bit builds
+ https://bugs.webkit.org/show_bug.cgi?id=140843
+
+ Reviewed by Oliver Hunt.
+
+ When we are in vmEntryToJavaScript, we keep the stack pointer at an
+ alignment sutiable for pointing to a call frame header, which is the
+ alignment post making a call. We adjust the sp when calling to JS code,
+ but don't adjust it before calling the out of stack handler.
+
+ * llint/LowLevelInterpreter32_64.asm:
+ Moved stack point down 8 bytes to get it aligned.
+
+2015-01-23 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Object Previews in the Console
+ https://bugs.webkit.org/show_bug.cgi?id=129204
+
+ Reviewed by Timothy Hatcher.
+
+ Update the very old, unused object preview code. Part of this comes from
+ the earlier WebKit legacy implementation, and the Blink implementation.
+
+ A RemoteObject may include a preview, if it is asked for, and if the
+ RemoteObject is an object. Previews are a shallow (single level) list
+ of a limited number of properties on the object. The previewed
+ properties are always stringified (even if primatives). Previews are
+ limited to just 5 properties or 100 indices. Previews are marked
+ as lossless if they are a complete snapshot of the object.
+
+ There is a path to make previews two levels deep, that is currently
+ unused but should soon be used for tables (e.g. IndexedDB).
+
+ * inspector/InjectedScriptSource.js:
+ - Move some code off of InjectedScript to be generic functions
+ usable by RemoteObject as well.
+ - Update preview generation to use
+
+ * inspector/protocol/Runtime.json:
+ - Add a new type, "accessor" for preview objects. This represents
+ a getter / setter. We currently don't get the value.
+
+2015-01-23 Michael Saboff <msaboff@apple.com>
+
+ Immediate crash when setting JS breakpoint
+ https://bugs.webkit.org/show_bug.cgi?id=140811
+
+ Reviewed by Mark Lam.
+
+ When the DFG stack layout phase doesn't allocate a register for the scope register,
+ it incorrectly sets the scope register in the code block to a bad value, one with
+ an offset of 0. Changed it so that we set the code block's scope register to the
+ invalid VirtualRegister instead.
+
+ No tests needed as adding the ASSERT in setScopeRegister() was used to find the bug.
+ We crash with that ASSERT in testapi and likely many other tests as well.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::setScopeRegister):
+ (JSC::CodeBlock::scopeRegister):
+ Added ASSERTs to catch any future improper setting of the code block's scope register.
+
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+
+2015-01-22 Mark Hahnenberg <mhahnenb@gmail.com>
+
+ EdenCollections unnecessarily visit SmallStrings
+ https://bugs.webkit.org/show_bug.cgi?id=140762
+
+ Reviewed by Geoffrey Garen.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::copyBackingStores): Also added a GCPhase for copying
+ backing stores, which is a significant portion of garbage collection.
+ (JSC::Heap::visitSmallStrings): Check to see if we need to visit
+ SmallStrings based on the collection type.
+ * runtime/SmallStrings.cpp:
+ (JSC::SmallStrings::SmallStrings):
+ (JSC::SmallStrings::visitStrongReferences): Set the fact that we have
+ visited the SmallStrings since the last modification.
+ * runtime/SmallStrings.h:
+ (JSC::SmallStrings::needsToBeVisited): If we're doing a
+ FullCollection, we need to visit. Otherwise, it depends on whether
+ we've been visited since the last modification/allocation.
+
+2015-01-22 Ryosuke Niwa <rniwa@webkit.org>
+
+ Add a build flag for ES6 class syntax
+ https://bugs.webkit.org/show_bug.cgi?id=140760
+
+ Reviewed by Michael Saboff.
+
+ Added ES6_CLASS_SYNTAX build flag and used it in tokenizer to recognize
+ "class", "extends", "static" and "super" keywords.
+
+ * Configurations/FeatureDefines.xcconfig:
+ * parser/Keywords.table:
+ * parser/ParserTokens.h:
+
+2015-01-22 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r178894.
+ https://bugs.webkit.org/show_bug.cgi?id=140775
+
+ Broke JSC and bindings tests (Requested by ap_ on #webkit).
+
+ Reverted changeset:
+
+ "put_by_val_direct need to check the property is index or not
+ for using putDirect / putDirectIndex"
+ https://bugs.webkit.org/show_bug.cgi?id=140426
+ http://trac.webkit.org/changeset/178894
+
+2015-01-22 Mark Lam <mark.lam@apple.com>
+
+ BytecodeGenerator::initializeCapturedVariable() sets a misleading value for the 5th operand of op_put_to_scope.
+ <https://webkit.org/b/140743>
+
+ Reviewed by Oliver Hunt.
+
+ BytecodeGenerator::initializeCapturedVariable() was setting the 5th operand to
+ op_put_to_scope to an inappropriate value (i.e. 0). As a result, the execution
+ of put_to_scope could store a wrong inferred value into the VariableWatchpointSet
+ for which ever captured variable is at local index 0. In practice, this turns
+ out to be the local for the Arguments object. In this reproduction case in the
+ bug, the wrong inferred value written there is the boolean true.
+
+ Subsequently, DFG compilation occurs and CreateArguments is emitted to first do
+ a check of the local for the Arguments object. But because that local has a
+ wrong inferred value, the check always discovers a non-null value and we never
+ actually create the Arguments object. Immediately after this, an OSR exit
+ occurs leaving the Arguments object local uninitialized. Later on at arguments
+ tear off, we run into a boolean true where we had expected to find an Arguments
+ object, which in turn, leads to the crash.
+
+ The fix is to:
+ 1. In the case where the resolveModeType is LocalClosureVar, change the
+ 5th operand of op_put_to_scope to be a boolean. True means that the
+ local var is watchable. False means it is not watchable. We no longer
+ pass the local index (instead of true) and UINT_MAX (instead of false).
+
+ This allows us to express more clearer in the code what that value means,
+ as well as remove the redundant way of getting the local's identifier.
+ The identifier is always the one passed in the 2nd operand.
+
+ 2. Previously, though intuitively, we know that the watchable variable
+ identifier should be the same as the one that is passed in operand 2, this
+ relationship was not clear in the code. By code analysis, I confirmed that
+ the callers of BytecodeGenerator::emitPutToScope() always use the same
+ identifier for operand 2 and for filling out the ResolveScopeInfo from
+ which we get the watchable variable identifier later. I've changed the
+ code to make this clear now by always using the identifier passed in
+ operand 2.
+
+ 3. In the case where the resolveModeType is LocalClosureVar,
+ initializeCapturedVariable() and emitPutToScope() will now query
+ hasWatchableVariable() to determine if the local is watchable or not.
+ Accordingly, we pass the boolean result of hasWatchableVariable() as
+ operand 5 of op_put_to_scope.
+
+ Also added some assertions.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::initializeCapturedVariable):
+ (JSC::BytecodeGenerator::hasConstant):
+ (JSC::BytecodeGenerator::emitPutToScope):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::hasWatchableVariable):
+ (JSC::BytecodeGenerator::watchableVariableIdentifier):
+ (JSC::BytecodeGenerator::watchableVariable): Deleted.
+
+2015-01-22 Ryosuke Niwa <rniwa@webkit.org>
+
+ PropertyListNode::emitNode duplicates the code to put a constant property
+ https://bugs.webkit.org/show_bug.cgi?id=140761
+
+ Reviewed by Geoffrey Garen.
+
+ Extracted PropertyListNode::emitPutConstantProperty to share the code.
+
+ Also made PropertyListNode::emitBytecode private since nobody is calling this function directly.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::PropertyListNode::emitBytecode):
+ (JSC::PropertyListNode::emitPutConstantProperty): Added.
+ * parser/Nodes.h:
+
+2015-01-22 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
+ https://bugs.webkit.org/show_bug.cgi?id=140426
+
+ Reviewed by Geoffrey Garen.
+
+ In the put_by_val_direct operation, we use JSObject::putDirect.
+ However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
+ This patch changes Identifier::asIndex() to return Optional<uint32_t>.
+ It forces callers to check the value is index or not explicitly.
+ Additionally, it checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
+
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeFor):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFor):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitDirectPutById):
+ * dfg/DFGOperations.cpp:
+ (JSC::DFG::operationPutByValInternal):
+ * jit/JITOperations.cpp:
+ * jit/Repatch.cpp:
+ (JSC::emitPutTransitionStubAndGetOldStructure):
+ * jsc.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::getOwnPropertySlot):
+ (JSC::Arguments::put):
+ (JSC::Arguments::deleteProperty):
+ (JSC::Arguments::defineOwnProperty):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncSort):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::defineOwnProperty):
+ * runtime/JSCJSValue.cpp:
+ (JSC::JSValue::putToPrimitive):
+ * runtime/JSGenericTypedArrayViewInlines.h:
+ (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
+ (JSC::JSGenericTypedArrayView<Adaptor>::put):
+ (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
+ (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::put):
+ (JSC::JSObject::putDirectAccessor):
+ (JSC::JSObject::putDirectCustomAccessor):
+ (JSC::JSObject::deleteProperty):
+ (JSC::JSObject::putDirectMayBeIndex):
+ (JSC::JSObject::defineOwnProperty):
+ * runtime/JSObject.h:
+ (JSC::JSObject::getOwnPropertySlot):
+ (JSC::JSObject::getPropertySlot):
+ (JSC::JSObject::putDirectInternal):
+ * runtime/JSString.cpp:
+ (JSC::JSString::getStringPropertyDescriptor):
+ * runtime/JSString.h:
+ (JSC::JSString::getStringPropertySlot):
+ * runtime/LiteralParser.cpp:
+ (JSC::LiteralParser<CharType>::parse):
+ * runtime/PropertyName.h:
+ (JSC::toUInt32FromCharacters):
+ (JSC::toUInt32FromStringImpl):
+ (JSC::PropertyName::asIndex):
+ * runtime/PropertyNameArray.cpp:
+ (JSC::PropertyNameArray::add):
+ * runtime/StringObject.cpp:
+ (JSC::StringObject::deleteProperty):
+ * runtime/Structure.cpp:
+ (JSC::Structure::prototypeChainMayInterceptStoreTo):
+
+2015-01-21 Ryosuke Niwa <rniwa@webkit.org>
+
+ Consolidate out arguments of parseFunctionInfo into a struct
+ https://bugs.webkit.org/show_bug.cgi?id=140754
+
+ Reviewed by Oliver Hunt.
+
+ Introduced ParserFunctionInfo for storing out arguments of parseFunctionInfo.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createFunctionExpr):
+ (JSC::ASTBuilder::createGetterOrSetterProperty): This one takes a property name in addition to
+ ParserFunctionInfo since the property name and the function name could differ.
+ (JSC::ASTBuilder::createFuncDeclStatement):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseProperty):
+ (JSC::Parser<LexerType>::parseMemberExpression):
+ * parser/Parser.h:
+ * parser/ParserFunctionInfo.h: Added.
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createFunctionExpr):
+ (JSC::SyntaxChecker::createFuncDeclStatement):
+ (JSC::SyntaxChecker::createClassDeclStatement):
+ (JSC::SyntaxChecker::createGetterOrSetterProperty):
+
+2015-01-21 Mark Hahnenberg <mhahnenb@gmail.com>
+
+ Change Heap::m_compiledCode to use a Vector
+ https://bugs.webkit.org/show_bug.cgi?id=140717
+
+ Reviewed by Andreas Kling.
+
+ Right now it's a DoublyLinkedList, which is iterated during each
+ collection. This contributes to some of the longish Eden pause times.
+ A Vector would be more appropriate and would also allow ExecutableBase
+ to be 2 pointers smaller.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::deleteAllCompiledCode):
+ (JSC::Heap::deleteAllUnlinkedFunctionCode):
+ (JSC::Heap::clearUnmarkedExecutables):
+ * heap/Heap.h:
+ * runtime/Executable.h: No longer need to inherit from DoublyLinkedListNode.
+
+2015-01-21 Ryosuke Niwa <rniwa@webkit.org>
+
+ BytecodeGenerator shouldn't expose all of its member variables
+ https://bugs.webkit.org/show_bug.cgi?id=140752
+
+ Reviewed by Mark Lam.
+
+ Added "private:" and removed unused data members as detected by clang.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::lastOpcodeID): Added. Used in BinaryOpNode::emitBytecode.
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BinaryOpNode::emitBytecode):
+
+2015-01-21 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ASSERT expanding objects in console PrimitiveBindingTraits<T>::assertValueHasExpectedType
+ https://bugs.webkit.org/show_bug.cgi?id=140746
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScriptSource.js:
+ Do not add impure properties to the descriptor object that will
+ eventually be sent to the frontend.
+
+2015-01-21 Matthew Mirman <mmirman@apple.com>
+
+ Updated split such that it does not include the empty end of input string match.
+ https://bugs.webkit.org/show_bug.cgi?id=138129
+ <rdar://problem/18807403>
+
+ Reviewed by Filip Pizlo.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncSplit):
+ * tests/stress/empty_eos_regex_split.js: Added.
+
+2015-01-21 Michael Saboff <msaboff@apple.com>
+
+ Eliminate Scope slot from JavaScript CallFrame
+ https://bugs.webkit.org/show_bug.cgi?id=136724
+
+ Reviewed by Geoffrey Garen.
+
+ This finishes the removal of the scope chain slot from the call frame header.
+
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::reifyInlinedCallFrames):
+ * dfg/DFGPreciseLocalClobberize.h:
+ (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::emitCall):
+ * ftl/FTLJSCall.cpp:
+ (JSC::FTL::JSCall::emit):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
+ (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
+ * interpreter/JSStack.h:
+ * interpreter/VMInspector.cpp:
+ (JSC::VMInspector::dumpFrame):
+ * jit/JITCall.cpp:
+ (JSC::JIT::compileOpCall):
+ * jit/JITCall32_64.cpp:
+ (JSC::JIT::compileOpCall):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::privateCompileCTINativeCall):
+ * jit/Repatch.cpp:
+ (JSC::generateByIdStub):
+ (JSC::linkClosureCall):
+ * jit/ThunkGenerators.cpp:
+ (JSC::virtualForThunkGenerator):
+ (JSC::nativeForGenerator):
+ Deleted ScopeChain slot from JSStack. Removed all code where ScopeChain was being
+ read or set. In most cases this was where we make JS calls.
+
+ * interpreter/CallFrameClosure.h:
+ (JSC::CallFrameClosure::setArgument):
+ (JSC::CallFrameClosure::resetCallFrame): Deleted.
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::execute):
+ (JSC::Interpreter::executeCall):
+ (JSC::Interpreter::executeConstruct):
+ (JSC::Interpreter::prepareForRepeatCall):
+ * interpreter/ProtoCallFrame.cpp:
+ (JSC::ProtoCallFrame::init):
+ * interpreter/ProtoCallFrame.h:
+ (JSC::ProtoCallFrame::scope): Deleted.
+ (JSC::ProtoCallFrame::setScope): Deleted.
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter64.asm:
+ Removed the related scopeChainValue member from ProtoCallFrame. Reduced the number of
+ registers that needed to be copied from the ProtoCallFrame to a callee's frame
+ from 5 to 4.
+
+ * llint/LowLevelInterpreter32_64.asm:
+ In addition to the prior changes, also deleted the unused macro getDeBruijnScope.
+
+2015-01-21 Michael Saboff <msaboff@apple.com>
+
+ Eliminate construct methods from NullGetterFunction and NullSetterFunction classes
+ https://bugs.webkit.org/show_bug.cgi?id=140708
+
+ Reviewed by Mark Lam.
+
+ Eliminated construct methods and change getConstructData() for both classes to return
+ ConstructTypeNone as they can never be called.
+
+ * runtime/NullGetterFunction.cpp:
+ (JSC::NullGetterFunction::getConstructData):
+ (JSC::constructReturnUndefined): Deleted.
+ * runtime/NullSetterFunction.cpp:
+ (JSC::NullSetterFunction::getConstructData):
+ (JSC::constructReturnUndefined): Deleted.
+
+2015-01-21 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove ENABLE(INSPECTOR) ifdef guards
+ https://bugs.webkit.org/show_bug.cgi?id=140668
+
+ Reviewed by Darin Adler.
+
+ * Configurations/FeatureDefines.xcconfig:
+ * bindings/ScriptValue.cpp:
+ (Deprecated::ScriptValue::toInspectorValue):
+ * bindings/ScriptValue.h:
+ * inspector/ConsoleMessage.cpp:
+ * inspector/ConsoleMessage.h:
+ * inspector/ContentSearchUtilities.cpp:
+ * inspector/ContentSearchUtilities.h:
+ * inspector/IdentifiersFactory.cpp:
+ * inspector/IdentifiersFactory.h:
+ * inspector/InjectedScript.cpp:
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptBase.cpp:
+ * inspector/InjectedScriptBase.h:
+ * inspector/InjectedScriptHost.cpp:
+ * inspector/InjectedScriptHost.h:
+ * inspector/InjectedScriptManager.cpp:
+ * inspector/InjectedScriptManager.h:
+ * inspector/InjectedScriptModule.cpp:
+ * inspector/InjectedScriptModule.h:
+ * inspector/InspectorAgentRegistry.cpp:
+ * inspector/InspectorBackendDispatcher.cpp:
+ * inspector/InspectorBackendDispatcher.h:
+ * inspector/InspectorProtocolTypes.h:
+ * inspector/JSGlobalObjectConsoleClient.cpp:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/JSGlobalObjectScriptDebugServer.cpp:
+ * inspector/JSGlobalObjectScriptDebugServer.h:
+ * inspector/JSInjectedScriptHost.cpp:
+ * inspector/JSInjectedScriptHost.h:
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ * inspector/JSInjectedScriptHostPrototype.h:
+ * inspector/JSJavaScriptCallFrame.cpp:
+ * inspector/JSJavaScriptCallFrame.h:
+ * inspector/JSJavaScriptCallFramePrototype.cpp:
+ * inspector/JSJavaScriptCallFramePrototype.h:
+ * inspector/JavaScriptCallFrame.cpp:
+ * inspector/JavaScriptCallFrame.h:
+ * inspector/ScriptCallFrame.cpp:
+ (Inspector::ScriptCallFrame::buildInspectorObject):
+ * inspector/ScriptCallFrame.h:
+ * inspector/ScriptCallStack.cpp:
+ (Inspector::ScriptCallStack::buildInspectorArray):
+ * inspector/ScriptCallStack.h:
+ * inspector/ScriptDebugServer.cpp:
+ * inspector/agents/InspectorAgent.cpp:
+ * inspector/agents/InspectorAgent.h:
+ * inspector/agents/InspectorConsoleAgent.cpp:
+ * inspector/agents/InspectorConsoleAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
+ * inspector/agents/JSGlobalObjectConsoleAgent.h:
+ * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
+ * inspector/agents/JSGlobalObjectDebuggerAgent.h:
+ * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
+ * inspector/agents/JSGlobalObjectRuntimeAgent.h:
+ * inspector/scripts/codegen/cpp_generator_templates.py:
+ (CppGeneratorTemplates):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::inspectorTypeSet):
+ (JSC::StructureShape::inspectorRepresentation):
+
+2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Clean up InjectedScriptSource.js
+ https://bugs.webkit.org/show_bug.cgi?id=140709
+
+ Reviewed by Timothy Hatcher.
+
+ This patch includes some relevant Blink patches and small changes.
+
+ Patch by <aandrey@chromium.org>
+ DevTools: Remove console last result $_ on console clear.
+ https://src.chromium.org/viewvc/blink?revision=179179&view=revision
+
+ Patch by <eustas@chromium.org>
+ [Inspect DOM properties] incorrect CSS Selector Syntax
+ https://src.chromium.org/viewvc/blink?revision=156903&view=revision
+
+ * inspector/InjectedScriptSource.js:
+
+2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Cleanup RuntimeAgent a bit
+ https://bugs.webkit.org/show_bug.cgi?id=140706
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InjectedScript.h:
+ * inspector/InspectorBackendDispatcher.h:
+ * inspector/ScriptCallFrame.cpp:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::evaluate):
+ (Inspector::InspectorRuntimeAgent::getProperties):
+ (Inspector::InspectorRuntimeAgent::run):
+ (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
+ (Inspector::recompileAllJSFunctionsForTypeProfiling):
+ (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
+
+2015-01-20 Matthew Mirman <mmirman@apple.com>
+
+ Made Identity in the DFG allocate a new temp register and move
+ the old data to it.
+ https://bugs.webkit.org/show_bug.cgi?id=140700
+ <rdar://problem/19339106>
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ Added scratch registers for Identity.
+ * tests/mozilla/mozilla-tests.yaml: enabled previously failing test
+
+2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Expanding event objects in console shows undefined for most values, it should have real values
+ https://bugs.webkit.org/show_bug.cgi?id=137306
+
+ Reviewed by Timothy Hatcher.
+
+ Provide another optional parameter to getProperties, to gather a list
+ of all own and getter properties.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getProperties):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptSource.js:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::getProperties):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/protocol/Runtime.json:
+
+2015-01-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Should show dynamic specificity values
+ https://bugs.webkit.org/show_bug.cgi?id=140647
+
+ Reviewed by Benjamin Poulain.
+
+ * inspector/protocol/CSS.json:
+ Clarify CSSSelector optional values and add "dynamic" property indicating
+ if the selector can be dynamic based on the element it is matched against.
+
+2015-01-20 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r178751.
+ https://bugs.webkit.org/show_bug.cgi?id=140694
+
+ Caused 32-bit JSC test failures (Requested by JoePeck on
+ #webkit).
+
+ Reverted changeset:
+
+ "put_by_val_direct need to check the property is index or not
+ for using putDirect / putDirectIndex"
+ https://bugs.webkit.org/show_bug.cgi?id=140426
+ http://trac.webkit.org/changeset/178751
+
+2015-01-20 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ put_by_val_direct need to check the property is index or not for using putDirect / putDirectIndex
+ https://bugs.webkit.org/show_bug.cgi?id=140426
+
+ Reviewed by Geoffrey Garen.
+
+ In the put_by_val_direct operation, we use JSObject::putDirect.
+ However, it only accepts non-index property. For index property, we need to use JSObject::putDirectIndex.
+ This patch changes Identifier::asIndex() to return Optional<uint32_t>.
+ It forces callers to check the value is index or not explicitly.
+ Additionally, it checks toString-ed Identifier is index or not to choose putDirect / putDirectIndex.
+
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeFor):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFor):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitDirectPutById):
+ * dfg/DFGOperations.cpp:
+ (JSC::DFG::operationPutByValInternal):
+ * jit/JITOperations.cpp:
+ * jit/Repatch.cpp:
+ (JSC::emitPutTransitionStubAndGetOldStructure):
+ * jsc.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::getOwnPropertySlot):
+ (JSC::Arguments::put):
+ (JSC::Arguments::deleteProperty):
+ (JSC::Arguments::defineOwnProperty):
+ * runtime/ArrayPrototype.cpp:
+ (JSC::arrayProtoFuncSort):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::defineOwnProperty):
+ * runtime/JSCJSValue.cpp:
+ (JSC::JSValue::putToPrimitive):
+ * runtime/JSGenericTypedArrayViewInlines.h:
+ (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
+ (JSC::JSGenericTypedArrayView<Adaptor>::put):
+ (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
+ (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::put):
+ (JSC::JSObject::putDirectAccessor):
+ (JSC::JSObject::putDirectCustomAccessor):
+ (JSC::JSObject::deleteProperty):
+ (JSC::JSObject::putDirectMayBeIndex):
+ (JSC::JSObject::defineOwnProperty):
+ * runtime/JSObject.h:
+ (JSC::JSObject::getOwnPropertySlot):
+ (JSC::JSObject::getPropertySlot):
+ (JSC::JSObject::putDirectInternal):
+ * runtime/JSString.cpp:
+ (JSC::JSString::getStringPropertyDescriptor):
+ * runtime/JSString.h:
+ (JSC::JSString::getStringPropertySlot):
+ * runtime/LiteralParser.cpp:
+ (JSC::LiteralParser<CharType>::parse):
+ * runtime/PropertyName.h:
+ (JSC::toUInt32FromCharacters):
+ (JSC::toUInt32FromStringImpl):
+ (JSC::PropertyName::asIndex):
+ * runtime/PropertyNameArray.cpp:
+ (JSC::PropertyNameArray::add):
+ * runtime/StringObject.cpp:
+ (JSC::StringObject::deleteProperty):
+ * runtime/Structure.cpp:
+ (JSC::Structure::prototypeChainMayInterceptStoreTo):
+
+2015-01-20 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(178696): Sporadic crashes while garbage collecting
+ https://bugs.webkit.org/show_bug.cgi?id=140688
+
+ Reviewed by Geoffrey Garen.
+
+ Added missing visitor.append(&thisObject->m_nullSetterFunction).
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::visitChildren):
+
+2015-01-19 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Replay: code generator should take supplemental specifications and allow cross-framework references
+ https://bugs.webkit.org/show_bug.cgi?id=136312
+
+ Reviewed by Joseph Pecoraro.
+
+ Some types are shared between replay inputs from different frameworks.
+ Previously, these type declarations were duplicated in every input
+ specification file in which they were used. This caused some type encoding
+ traits to be emitted twice if used from WebCore inputs and WebKit2 inputs.
+
+ This patch teaches the replay inputs code generator to accept multiple
+ input specification files. Inputs can freely reference types from other
+ frameworks without duplicating declarations.
+
+ On the code generation side, the model could contain types and inputs from
+ frameworks that are not the target framework. Only generate code for the
+ target framework.
+
+ To properly generate cross-framework type encoding traits, use
+ Type.encoding_type_argument in more places, and add the export macro for WebCore
+ and the Test framework.
+
+ Adjust some tests so that enum coverage is preserved by moving the enum types
+ into "Test" (the target framework for tests).
+
+ * JavaScriptCore.vcxproj/copy-files.cmd:
+ For Windows, copy over JSInputs.json as if it were a private header.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj: Make JSInputs.json a private header.
+ * replay/JSInputs.json:
+ Put all primitive types and WTF types in this specification file.
+
+ * replay/scripts/CodeGeneratorReplayInputs.py:
+ (Input.__init__):
+ (InputsModel.__init__): Keep track of the input's framework.
+ (InputsModel.parse_specification): Parse the framework here. Adjust to new format,
+ and allow either types or inputs to be missing from a single file.
+
+ (InputsModel.parse_type_with_framework):
+ (InputsModel.parse_input_with_framework):
+ (Generator.should_generate_item): Added helper method.
+ (Generator.generate_header): Filter inputs to generate.
+ (Generator.generate_implementation): Filter inputs to generate.
+ (Generator.generate_enum_trait_declaration): Filter enums to generate.
+ Add WEBCORE_EXPORT macro to enum encoding traits.
+
+ (Generator.generate_for_each_macro): Filter inputs to generate.
+ (Generator.generate_enum_trait_implementation): Filter enums to generate.
+ (generate_from_specifications): Added.
+ (generate_from_specifications.parse_json_from_file):
+ (InputsModel.parse_toplevel): Deleted.
+ (InputsModel.parse_type_with_framework_name): Deleted.
+ (InputsModel.parse_input): Deleted.
+ (generate_from_specification): Deleted.
+ * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
+ * replay/scripts/tests/expected/fail-on-no-inputs.json-error: Removed.
+ * replay/scripts/tests/expected/fail-on-no-types.json-error: Removed.
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
+ * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
+ * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
+ * replay/scripts/tests/fail-on-c-style-enum-no-storage.json:
+ * replay/scripts/tests/fail-on-duplicate-enum-type.json:
+ * replay/scripts/tests/fail-on-duplicate-input-names.json:
+ * replay/scripts/tests/fail-on-duplicate-type-names.json:
+ * replay/scripts/tests/fail-on-enum-type-missing-values.json:
+ * replay/scripts/tests/fail-on-missing-input-member-name.json:
+ * replay/scripts/tests/fail-on-missing-input-name.json:
+ * replay/scripts/tests/fail-on-missing-input-queue.json:
+ * replay/scripts/tests/fail-on-missing-type-mode.json:
+ * replay/scripts/tests/fail-on-missing-type-name.json:
+ * replay/scripts/tests/fail-on-no-inputs.json:
+ Removed, no longer required to be in a single file.
+
+ * replay/scripts/tests/fail-on-no-types.json:
+ Removed, no longer required to be in a single file.
+
+ * replay/scripts/tests/fail-on-unknown-input-queue.json:
+ * replay/scripts/tests/fail-on-unknown-member-type.json:
+ * replay/scripts/tests/fail-on-unknown-type-mode.json:
+ * replay/scripts/tests/generate-enum-encoding-helpers-with-guarded-values.json:
+ * replay/scripts/tests/generate-enum-encoding-helpers.json:
+ * replay/scripts/tests/generate-enum-with-guard.json:
+ Include enums that are and are not generated.
+
+ * replay/scripts/tests/generate-enums-with-same-base-name.json:
+ * replay/scripts/tests/generate-event-loop-shape-types.json:
+ * replay/scripts/tests/generate-input-with-guard.json:
+ * replay/scripts/tests/generate-input-with-vector-members.json:
+ * replay/scripts/tests/generate-inputs-with-flags.json:
+ * replay/scripts/tests/generate-memoized-type-modes.json:
+
+2015-01-20 Tomas Popela <tpopela@redhat.com>
+
+ [GTK] Cannot compile 2.7.3 on PowerPC machines
+ https://bugs.webkit.org/show_bug.cgi?id=140616
+
+ Include climits for INT_MAX and wtf/DataLog.h for dataLogF
+
+ Reviewed by Csaba Osztrogonác.
+
+ * runtime/BasicBlockLocation.cpp:
+
+2015-01-19 Michael Saboff <msaboff@apple.com>
+
+ A "cached" null setter should throw a TypeException when called in strict mode and doesn't
+ https://bugs.webkit.org/show_bug.cgi?id=139418
+
+ Reviewed by Filip Pizlo.
+
+ Made a new NullSetterFunction class similar to NullGetterFunction. The difference is that
+ NullSetterFunction will throw a TypeError per the ECMA262 spec for a strict mode caller.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ Added new files NullSetterFunction.cpp and NullSetterFunction.h.
+
+ * runtime/GetterSetter.h:
+ (JSC::GetterSetter::GetterSetter):
+ (JSC::GetterSetter::isSetterNull):
+ (JSC::GetterSetter::setSetter):
+ Change setter instances from using NullGetterFunction to using NullSetterFunction.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::nullSetterFunction):
+ Added m_nullSetterFunction and accessor.
+
+ * runtime/NullSetterFunction.cpp: Added.
+ (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
+ (JSC::GetCallerStrictnessFunctor::operator()):
+ (JSC::GetCallerStrictnessFunctor::callerIsStrict):
+ (JSC::callerIsStrict):
+ Method to determine if the caller is in strict mode.
+
+ (JSC::callReturnUndefined):
+ (JSC::constructReturnUndefined):
+ (JSC::NullSetterFunction::getCallData):
+ (JSC::NullSetterFunction::getConstructData):
+ * runtime/NullSetterFunction.h: Added.
+ (JSC::NullSetterFunction::create):
+ (JSC::NullSetterFunction::createStructure):
+ (JSC::NullSetterFunction::NullSetterFunction):
+ Class with handlers for a null setter.
+
+2015-01-19 Saam Barati <saambarati1@gmail.com>
+
+ Web Inspector: Provide a front end for JSC's Control Flow Profiler
+ https://bugs.webkit.org/show_bug.cgi?id=138454
+
+ Reviewed by Timothy Hatcher.
+
+ This patch puts the final touches on what JSC needs to provide
+ for the Web Inspector to show a UI for the control flow profiler.
+
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::recompileAllJSFunctionsForTypeProfiling):
+ * runtime/ControlFlowProfiler.cpp:
+ (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
+ * runtime/FunctionHasExecutedCache.cpp:
+ (JSC::FunctionHasExecutedCache::getFunctionRanges):
+ (JSC::FunctionHasExecutedCache::getUnexecutedFunctionRanges): Deleted.
+ * runtime/FunctionHasExecutedCache.h:
+
+2015-01-19 David Kilzer <ddkilzer@apple.com>
+
+ [iOS] Only use LLVM static library arguments on 64-bit builds of libllvmForJSC.dylib
+ <http://webkit.org/b/140658>
+
+ Reviewed by Filip Pizlo.
+
+ * Configurations/LLVMForJSC.xcconfig: Set OTHER_LDFLAGS_LLVM
+ only when building for 64-bit architectures.
+
+2015-01-19 Filip Pizlo <fpizlo@apple.com>
+
+ ClosureCallStubRoutine no longer needs codeOrigin
+ https://bugs.webkit.org/show_bug.cgi?id=140659
+
+ Reviewed by Michael Saboff.
+
+ Once upon a time, we would look for the CodeOrigin associated with a return PC. This search
+ would start with the CodeBlock according to the caller frame's call frame header. But if the
+ call was a closure call, the return PC would be inside some closure call stub. So if the
+ CodeBlock search failed, we would search *all* closure call stub routines to see which one
+ encompasses the return PC. Then, we would use the CodeOrigin stored in the stub routine
+ object. This was all a bunch of madness, and we actually got rid of it - we now determine
+ the CodeOrigin for a call frame using the encoded code origin bits inside the tag of the
+ argument count.
+
+ This patch removes the final vestiges of the madness:
+
+ - Remove the totally unused method declaration for the thing that did the closure call stub
+ search.
+
+ - Remove the CodeOrigin field from the ClosureCallStubRoutine. Except for that crazy search
+ that we no longer do, everyone else who finds a ClosureCallStubRoutine will find it via
+ the CallLinkInfo. The CallLinkInfo also has the CodeOrigin, so we don't need this field
+ anymore.
+
+ * bytecode/CodeBlock.h:
+ * jit/ClosureCallStubRoutine.cpp:
+ (JSC::ClosureCallStubRoutine::ClosureCallStubRoutine):
+ * jit/ClosureCallStubRoutine.h:
+ (JSC::ClosureCallStubRoutine::executable):
+ (JSC::ClosureCallStubRoutine::codeOrigin): Deleted.
+ * jit/Repatch.cpp:
+ (JSC::linkClosureCall):
+
+2015-01-19 Saam Barati <saambarati1@gmail.com>
+
+ Basic block start offsets should never be larger than end offsets in the control flow profiler
+ https://bugs.webkit.org/show_bug.cgi?id=140377
+
+ Reviewed by Filip Pizlo.
+
+ The bytecode generator will emit code more than once for some AST nodes. For instance,
+ the finally block of TryNode will emit two code paths for its finally block: one for
+ the normal path, and another for the path where an exception is thrown in the catch block.
+
+ This repeated code emission of the same AST node previously broke how the control
+ flow profiler computed text ranges of basic blocks because when the same AST node
+ is emitted multiple times, there is a good chance that there are ranges that span
+ from the end offset of one of these duplicated nodes back to the start offset of
+ the same duplicated node. This caused a basic block range to report a larger start
+ offset than end offset. This was incorrect. Now, when this situation is encountered
+ while linking a CodeBlock, the faulty range in question is ignored.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
+ * bytecode/CodeBlock.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ForInNode::emitMultiLoopBytecode):
+ (JSC::ForOfNode::emitBytecode):
+ (JSC::TryNode::emitBytecode):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseConditionalExpression):
+ * runtime/ControlFlowProfiler.cpp:
+ (JSC::ControlFlowProfiler::ControlFlowProfiler):
+ * runtime/ControlFlowProfiler.h:
+ (JSC::ControlFlowProfiler::dummyBasicBlock):
+
+2015-01-19 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [SVG -> OTF Converter] Flip the switch on
+ https://bugs.webkit.org/show_bug.cgi?id=140592
+
+ Reviewed by Antti Koivisto.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-01-19 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Replay: convert to is<T> and downcast<T> for decoding replay inputs
+ https://bugs.webkit.org/show_bug.cgi?id=140512
+
+ Reviewed by Chris Dumez.
+
+ Generate a SPECIALIZE_TYPE_TRAITS_* chunk of code for each input. This cannot
+ be done using REPLAY_INPUT_NAMES_FOR_EACH macro since that doesn't fully qualify
+ input types, and the type traits macro is defined in namespace WTF.
+
+ * replay/NondeterministicInput.h: Make overridden methods public.
+ * replay/scripts/CodeGeneratorReplayInputs.py:
+ (Generator.generate_header):
+ (Generator.qualified_input_name): Allow forcing qualification. WTF is never a target framework.
+ (Generator.generate_input_type_trait_declaration): Added.
+ * replay/scripts/CodeGeneratorReplayInputsTemplates.py: Add a template.
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
+
+2015-01-19 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r178653.
+ https://bugs.webkit.org/show_bug.cgi?id=140634
+
+ Broke multiple SVG tests on Mountain Lion (Requested by ap on
+ #webkit).
+
+ Reverted changeset:
+
+ "[SVG -> OTF Converter] Flip the switch on"
+ https://bugs.webkit.org/show_bug.cgi?id=140592
+ http://trac.webkit.org/changeset/178653
+
+2015-01-18 Dean Jackson <dino@apple.com>
+
+ ES6: Support Array.of construction
+ https://bugs.webkit.org/show_bug.cgi?id=140605
+ <rdar://problem/19513655>
+
+ Reviewed by Geoffrey Garen.
+
+ Add and implementation of Array.of, described in 22.1.2.3 of the ES6
+ specification (15 Jan 2015). The Array.of() method creates a new Array
+ instance with a variable number of arguments, regardless of number or type
+ of the arguments.
+
+ * runtime/ArrayConstructor.cpp:
+ (JSC::arrayConstructorOf): Create a new empty Array, then iterate
+ over the arguments, setting them to the appropriate index.
+
+2015-01-19 Myles C. Maxfield <mmaxfield@apple.com>
+
+ [SVG -> OTF Converter] Flip the switch on
+ https://bugs.webkit.org/show_bug.cgi?id=140592
+
+ Reviewed by Antti Koivisto.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-01-17 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: highlight data for overlay should use protocol type builders
+ https://bugs.webkit.org/show_bug.cgi?id=129441
+
+ Reviewed by Timothy Hatcher.
+
+ Add a new domain for overlay types.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * inspector/protocol/OverlayTypes.json: Added.
+
+2015-01-17 Michael Saboff <msaboff@apple.com>
+
+ Crash in JSScope::resolve() on tools.ups.com
+ https://bugs.webkit.org/show_bug.cgi?id=140579
+
+ Reviewed by Geoffrey Garen.
+
+ For op_resolve_scope of a global property or variable that needs to check for the var
+ injection check watchpoint, we need to keep the scope around with a Phantom. The
+ baseline JIT slowpath for op_resolve_scope needs the scope value if the watchpoint
+ fired.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+
+2015-01-16 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: code generator should introduce typedefs for protocol types that are arrays
+ https://bugs.webkit.org/show_bug.cgi?id=140557
+
+ Reviewed by Joseph Pecoraro.
+
+ Currently, there is no generated type name for "array" type declarations such as Console.CallStack.
+ This makes it longwinded and confusing to use the type in C++ code.
+
+ This patch adds a typedef for array type declarations, so types such as Console::CallStack
+ can be referred to directly, rather than using Inspector::Protocol::Array<Console::CallFrame>.
+
+ Some tests were updated to cover array type declarations used as parameters and type members.
+
+ * inspector/ScriptCallStack.cpp: Use the new typedef.
+ (Inspector::ScriptCallStack::buildInspectorArray):
+ * inspector/ScriptCallStack.h:
+ * inspector/scripts/codegen/cpp_generator.py:
+ (CppGenerator.cpp_protocol_type_for_type): If an ArrayType is nominal, use the typedef'd name instead.
+ * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
+ (_generate_typedefs_for_domain): Also generate typedefs for array type declarations.
+ (_generate_typedefs_for_domain.Inspector):
+ * inspector/scripts/codegen/models.py: Save the name of an ArrayType when it is a type declaration.
+ (ArrayType.__init__):
+ (Protocol.resolve_types):
+ (Protocol.lookup_type_reference):
+ * inspector/scripts/tests/commands-with-async-attribute.json:
+ * inspector/scripts/tests/commands-with-optional-call-return-parameters.json:
+ * inspector/scripts/tests/events-with-optional-parameters.json:
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ * inspector/scripts/tests/type-declaration-object-type.json:
+
+2015-01-16 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Replay: purge remaining PassRefPtr uses and minor cleanup
+ https://bugs.webkit.org/show_bug.cgi?id=140456
+
+ Reviewed by Andreas Kling.
+
+ Get rid of PassRefPtr. Introduce default initializers where it makes sense.
+ Remove mistaken uses of AtomicString that were not removed as part of r174113.
+
+ * replay/EmptyInputCursor.h:
+ * replay/InputCursor.h:
+ (JSC::InputCursor::InputCursor):
+
+2015-01-16 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: code generator should fail on duplicate parameter and member names
+ https://bugs.webkit.org/show_bug.cgi?id=140555
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/scripts/codegen/models.py:
+ (find_duplicates): Add a helper function to find duplicates in a list.
+ (Protocol.parse_type_declaration):
+ (Protocol.parse_command):
+ (Protocol.parse_event):
+ * inspector/scripts/tests/expected/fail-on-duplicate-command-call-parameter-names.json-error: Added.
+ * inspector/scripts/tests/expected/fail-on-duplicate-command-return-parameter-names.json-error: Added.
+ * inspector/scripts/tests/expected/fail-on-duplicate-event-parameter-names.json-error: Added.
+ * inspector/scripts/tests/expected/fail-on-duplicate-type-member-names.json-error: Added.
+ * inspector/scripts/tests/fail-on-duplicate-command-call-parameter-names.json: Added.
+ * inspector/scripts/tests/fail-on-duplicate-command-return-parameter-names.json: Added.
+ * inspector/scripts/tests/fail-on-duplicate-event-parameter-names.json: Added.
+ * inspector/scripts/tests/fail-on-duplicate-type-member-names.json: Added.
+
+2015-01-16 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (r174226): Header on huffingtonpost.com is too large
+ https://bugs.webkit.org/show_bug.cgi?id=140306
+
+ Reviewed by Filip Pizlo.
+
+ BytecodeGenerator::willResolveToArguments() is used to check to see if we can use the
+ arguments register or whether we need to resolve "arguments". If the arguments have
+ been captured, then they are stored in the lexical environment and the arguments
+ register is not used.
+
+ Changed BytecodeGenerator::willResolveToArguments() to also check to see if the arguments
+ register is captured. Renamed the function to willResolveToArgumentsRegister() to
+ better indicate what we are checking.
+
+ Aligned 32 and 64 bit paths in ArgumentsRecoveryGenerator::generateFor() for creating
+ an arguments object that was optimized out of an inlined callFrame. The 32 bit path
+ incorrectly calculated the location of the reified callee frame. This alignment resulted
+ in the removal of operationCreateInlinedArgumentsDuringOSRExit()
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::willResolveToArgumentsRegister):
+ (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
+ (JSC::BytecodeGenerator::emitCall):
+ (JSC::BytecodeGenerator::emitConstruct):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::willResolveToArguments): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BracketAccessorNode::emitBytecode):
+ (JSC::DotAccessorNode::emitBytecode):
+ (JSC::getArgumentByVal):
+ (JSC::ApplyFunctionCallDotNode::emitBytecode):
+ (JSC::ArrayPatternNode::emitDirectBinding):
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::ArgumentsRecoveryGenerator::generateFor):
+ * dfg/DFGOperations.cpp:
+ (JSC::operationCreateInlinedArgumentsDuringOSRExit): Deleted.
+ * dfg/DFGOperations.h:
+ (JSC::operationCreateInlinedArgumentsDuringOSRExit): Deleted.
+
+2015-01-15 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove ENABLE(SQL_DATABASE) guards
+ https://bugs.webkit.org/show_bug.cgi?id=140434
+
+ Reviewed by Darin Adler.
+
+ * CMakeLists.txt:
+ * Configurations/FeatureDefines.xcconfig:
+ * DerivedSources.make:
+ * inspector/protocol/Database.json:
+
+2015-01-14 Alexey Proskuryakov <ap@apple.com>
+
+ Web Inspector and regular console use different source code locations for messages
+ https://bugs.webkit.org/show_bug.cgi?id=140478
+
+ Reviewed by Brian Burg.
+
+ * inspector/ConsoleMessage.h: Expose computed source location.
+
+ * inspector/agents/InspectorConsoleAgent.cpp:
+ (Inspector::InspectorConsoleAgent::addMessageToConsole):
+ (Inspector::InspectorConsoleAgent::stopTiming):
+ (Inspector::InspectorConsoleAgent::count):
+ * inspector/agents/InspectorConsoleAgent.h:
+ addMessageToConsole() now takes a pre-made ConsoleMessage object.
+
+ * inspector/JSGlobalObjectConsoleClient.cpp:
+ (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
+ (Inspector::JSGlobalObjectConsoleClient::warnUnimplemented):
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::reportAPIException):
+ * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
+ (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
+ Updated for the above changes.
+
+2015-01-15 Mark Lam <mark.lam@apple.com>
+
+ [Part 2] Argument object created by "Function dot arguments" should use a clone of argument values.
+ <https://webkit.org/b/140093>
+
+ Reviewed by Geoffrey Garen.
+
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::createArguments):
+ - We should not fetching the lexicalEnvironment here. The reason we've
+ introduced the ClonedArgumentsCreationMode is because the lexicalEnvironment
+ may not be available to us at this point. Instead, we'll just pass a nullptr.
+
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::tearOffForCloning):
+ * runtime/Arguments.h:
+ (JSC::Arguments::finishCreation):
+ - Use the new tearOffForCloning() to tear off arguments right out of the values
+ passed on the stack. tearOff() is not appropriate for this purpose because
+ it takes slowArgumentsData into account.
+
+2015-01-14 Matthew Mirman <mmirman@apple.com>
+
+ Removed accidental commit of "invalid_array.js"
+ http://trac.webkit.org/changeset/178439
+
+ * tests/stress/invalid_array.js: Removed.
+
+2015-01-14 Matthew Mirman <mmirman@apple.com>
+
+ Fixes operationPutByIdOptimizes such that they check that the put didn't
+ change the structure of the object who's property access is being
+ cached. Also removes uses of the new base value from the cache generation code.
+ https://bugs.webkit.org/show_bug.cgi?id=139500
+
+ Reviewed by Filip Pizlo.
+
+ * jit/JITOperations.cpp:
+ (JSC::operationPutByIdStrictOptimize): saved the structure before the put.
+ (JSC::operationPutByIdNonStrictOptimize): ditto.
+ (JSC::operationPutByIdDirectStrictOptimize): ditto.
+ (JSC::operationPutByIdDirectNonStrictOptimize): ditto.
+ * jit/Repatch.cpp:
+ (JSC::generateByIdStub):
+ (JSC::tryCacheGetByID):
+ (JSC::tryBuildGetByIDList):
+ (JSC::emitPutReplaceStub):
+ (JSC::emitPutTransitionStubAndGetOldStructure): Added.
+ (JSC::tryCachePutByID):
+ (JSC::repatchPutByID):
+ (JSC::tryBuildPutByIdList):
+ (JSC::tryRepatchIn):
+ (JSC::emitPutTransitionStub): Deleted.
+ * jit/Repatch.h:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/JSPropertyNameEnumerator.h:
+ (JSC::genericPropertyNameEnumerator):
+ * runtime/Operations.h:
+ (JSC::normalizePrototypeChainForChainAccess): restructured to not use the base value.
+ (JSC::normalizePrototypeChain): restructured to not use the base value.
+ * tests/mozilla/mozilla-tests.yaml:
+ * tests/stress/proto-setter.js: Added.
+ * tests/stress/put-by-id-build-list-order-recurse.js: Added.
+ Added test that fails without this patch.
+
+2015-01-13 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Remove unused ResizeImage and DecodeImageData timeline events
+ https://bugs.webkit.org/show_bug.cgi?id=140404
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/Timeline.json:
+
+2015-01-13 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ DFG can call PutByValDirect for generic arrays
+ https://bugs.webkit.org/show_bug.cgi?id=140389
+
+ Reviewed by Geoffrey Garen.
+
+ Computed properties in object initializers (ES6) use the put_by_val_direct operation.
+ However, current DFG asserts that put_by_val_direct is not used for the generic array,
+ the assertion failure is raised.
+ This patch allow DFG to use put_by_val_direct to generic arrays.
+
+ And fix the DFG put_by_val_direct implementation for string properties.
+ At first, put_by_val_direct is inteded to be used for spread elements.
+ So the property keys were limited to numbers (indexes).
+ But now, it's also used for computed properties in object initializers.
+
+ * dfg/DFGOperations.cpp:
+ (JSC::DFG::operationPutByValInternal):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+
+2015-01-13 Geoffrey Garen <ggaren@apple.com>
+
+ Out of bounds access in BytecodeGenerator::emitGetById under DotAccessorNode::emitBytecode
+ https://bugs.webkit.org/show_bug.cgi?id=140397
+
+ Reviewed by Geoffrey Garen.
+
+ Patch by Alexey Proskuryakov.
+
+ Reviewed, performance tested, and ChangeLogged by Geoffrey Garen.
+
+ No performance change.
+
+ 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.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BracketAccessorNode::emitBytecode):
+ (JSC::DotAccessorNode::emitBytecode):
+ (JSC::FunctionCallBracketNode::emitBytecode):
+ (JSC::PostfixNode::emitResolve):
+ (JSC::DeleteBracketNode::emitBytecode):
+ (JSC::DeleteDotNode::emitBytecode):
+ (JSC::PrefixNode::emitResolve):
+ (JSC::UnaryOpNode::emitBytecode):
+ (JSC::BitwiseNotNode::emitBytecode):
+ (JSC::BinaryOpNode::emitBytecode):
+ (JSC::EqualNode::emitBytecode):
+ (JSC::StrictEqualNode::emitBytecode):
+ (JSC::ThrowableBinaryOpNode::emitBytecode):
+ (JSC::AssignDotNode::emitBytecode):
+ (JSC::AssignBracketNode::emitBytecode): Use RefPtr in more places. Any
+ register used across a call to a function that might allocate a new
+ temporary register must be held in a RefPtr.
+
+2015-01-12 Michael Saboff <msaboff@apple.com>
+
+ Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection
+ https://bugs.webkit.org/show_bug.cgi?id=140348
+
+ Reviewed by Mark Lam.
+
+ We used to read registers in MachineThreads::gatherFromCurrentThread(), but that is too late
+ because those registers may have been spilled on the stack and replaced with other values by
+ the time we call down to gatherFromCurrentThread().
+
+ Now we get the register contents at the same place that we demarcate the current top of
+ stack using the address of a local variable, in Heap::markRoots(). The register contents
+ buffer is passed along with the demarcation pointer. These need to be done at this level
+ in the call tree and no lower, as markRoots() calls various functions that visit object
+ pointers that may be latter proven dead. Any of those pointers that are left on the
+ stack or in registers could be incorrectly marked as live if we scan the stack contents
+ from a called function or one of its callees. The stack demarcation pointer and register
+ saving need to be done in the same function so that we have a consistent stack, active
+ and spilled registers.
+
+ Because we don't want to make unnecessary calls to get the register contents, we use
+ a macro to allocated, and possibly align, the register structure and get the actual
+ register contents.
+
+
+ * heap/Heap.cpp:
+ (JSC::Heap::markRoots):
+ (JSC::Heap::gatherStackRoots):
+ * heap/Heap.h:
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::gatherFromCurrentThread):
+ (JSC::MachineThreads::gatherConservativeRoots):
+ * heap/MachineStackMarker.h:
+
+2015-01-12 Benjamin Poulain <benjamin@webkit.org>
+
+ Add basic pattern matching support to the url filters
+ https://bugs.webkit.org/show_bug.cgi?id=140283
+
+ Reviewed by Andreas Kling.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ Make YarrParser.h private in order to use it from WebCore.
+
+2015-01-12 Geoffrey Garen <ggaren@apple.com>
+
+ 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-01-11 Sam Weinig <sam@webkit.org>
+
+ Remove support for SharedWorkers
+ https://bugs.webkit.org/show_bug.cgi?id=140344
+
+ Reviewed by Anders Carlsson.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-01-12 Myles C. Maxfield <mmaxfield@apple.com>
+
+ Allow targetting the SVG->OTF font converter with ENABLE(SVG_OTF_CONVERTER)
+ https://bugs.webkit.org/show_bug.cgi?id=136769
+
+ Reviewed by Antti Koivisto.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2015-01-12 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r178266.
+ https://bugs.webkit.org/show_bug.cgi?id=140363
+
+ Broke a JSC test (Requested by ap on #webkit).
+
+ Reverted changeset:
+
+ "Local JSArray* "keys" in objectConstructorKeys() is not
+ marked during garbage collection"
+ https://bugs.webkit.org/show_bug.cgi?id=140348
+ http://trac.webkit.org/changeset/178266
+
+2015-01-12 Michael Saboff <msaboff@apple.com>
+
+ Local JSArray* "keys" in objectConstructorKeys() is not marked during garbage collection
+ https://bugs.webkit.org/show_bug.cgi?id=140348
+
+ Reviewed by Mark Lam.
+
+ Move the address of the local variable that is used to demarcate the top of the stack for
+ conservative roots down to MachineThreads::gatherFromCurrentThread() since it also gets
+ the register values using setjmp(). That way we don't lose any callee save register
+ contents between Heap::markRoots(), where it was set, and gatherFromCurrentThread().
+ If we lose any JSObject* that are only in callee save registers, they will be GC'ed
+ erroneously.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::markRoots):
+ (JSC::Heap::gatherStackRoots):
+ * heap/Heap.h:
+ * heap/MachineStackMarker.cpp:
+ (JSC::MachineThreads::gatherFromCurrentThread):
+ (JSC::MachineThreads::gatherConservativeRoots):
+ * heap/MachineStackMarker.h:
+
+2015-01-11 Eric Carlson <eric.carlson@apple.com>
+
+ Fix typo in testate.c error messages
+ https://bugs.webkit.org/show_bug.cgi?id=140305
+
+ Reviewed by Geoffrey Garen.
+
+ * API/tests/testapi.c:
+ (main): "... script did not timed out ..." -> "... script did not time out ..."
+
+2015-01-09 Michael Saboff <msaboff@apple.com>
+
+ Breakpoint doesn't fire in this HTML5 game
+ https://bugs.webkit.org/show_bug.cgi?id=140269
+
+ Reviewed by Mark Lam.
+
+ When parsing a single line cached function, use the lineStartOffset of the
+ location where we found the cached function instead of the cached lineStartOffset.
+ The cache location's lineStartOffset has not been adjusted for any possible
+ containing functions.
+
+ This change is not needed for multi-line cached functions. Consider the
+ single line source:
+
+ function outer(){function inner1(){doStuff();}; (function inner2() {doMoreStuff()})()}
+
+ The first parser pass, we parse and cache inner1() and inner2() with a lineStartOffset
+ of 0. Later when we parse outer() and find inner1() in the cache, SourceCode start
+ character is at outer()'s outermost open brace. That is what we should use for
+ lineStartOffset for inner1(). When done parsing inner1() we set the parsing token
+ to the saved location for inner1(), including the lineStartOffset of 0. We need
+ to use the value of lineStartOffset before we started parsing inner1(). That is
+ what the fix does. When we parse inner2() the lineStartOffset will be correct.
+
+ For a multi-line function, the close brace is guaranteed to be on a different line
+ than the open brace. Hence, its lineStartOffset will not change with the change of
+ the SourceCode start character
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+
+2015-01-09 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Uncaught Exception in ProbeManager deleting breakpoint
+ https://bugs.webkit.org/show_bug.cgi?id=140279
+ rdar://problem/19422299
+
+ Reviewed by Oliver Hunt.
+
+ * runtime/MapData.cpp:
+ (JSC::MapData::replaceAndPackBackingStore):
+ The cell table also needs to have its values fixed.
+
+2015-01-09 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Remove or use TimelineAgent Resource related event types
+ https://bugs.webkit.org/show_bug.cgi?id=140155
+
+ Reviewed by Timothy Hatcher.
+
+ Remove unused / stale Timeline event types.
+
+ * inspector/protocol/Timeline.json:
+
+2015-01-09 Csaba Osztrogonác <ossy@webkit.org>
+
+ REGRESSION(r177925): It broke the !ENABLE(INSPECTOR) build
+ https://bugs.webkit.org/show_bug.cgi?id=140098
+
+ Reviewed by Brian Burg.
+
+ * inspector/InspectorBackendDispatcher.h: Missing ENABLE(INSPECTOR) guard added.
+
+2015-01-08 Mark Lam <mark.lam@apple.com>
+
+ Argument object created by "Function dot arguments" should use a clone of the argument values.
+ <https://webkit.org/b/140093>
+
+ Reviewed by Geoffrey Garen.
+
+ After the change in <https://webkit.org/b/139827>, the dfg-tear-off-arguments-not-activation.js
+ test will crash. The relevant code which manifests the issue is as follows:
+
+ function bar() {
+ return foo.arguments;
+ }
+
+ function foo(p) {
+ var x = 42;
+ if (p)
+ return (function() { return x; });
+ else
+ return bar();
+ }
+
+ In this case, foo() has no knowledge of bar() needing its LexicalEnvironment and
+ has dead code eliminated the SetLocal that stores it into its designated local.
+ In bar(), the factory for the Arguments object (for creating foo.arguments) tries
+ to read foo's LexicalEnvironment from its designated lexicalEnvironment local,
+ but instead, finds it to be uninitialized. This results in a null pointer access
+ which causes a crash.
+
+ This can be resolved by having bar() instantiate a clone of the Arguments object
+ instead, and populate its elements with values fetched directly from foo's frame.
+ There's no need to reference foo's LexicalEnvironment (whether present or not).
+
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::createArguments):
+ * runtime/Arguments.h:
+ (JSC::Arguments::finishCreation):
+
+2015-01-08 Mark Lam <mark.lam@apple.com>
+
+ Make the LLINT and Baseline JIT's op_create_arguments and op_get_argument_by_val use their lexicalEnvironment operand.
+ <https://webkit.org/b/140236>
+
+ Reviewed by Geoffrey Garen.
+
+ Will change the DFG to use the operand on a subsequent pass. For now,
+ the DFG uses a temporary thunk (operationCreateArgumentsForDFG()) to
+ retain the old behavior of getting the lexicalEnviroment from the
+ ExecState.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::emitGetArgumentByVal):
+ (JSC::BytecodeGenerator::createArgumentsIfNecessary):
+ - When the lexicalEnvironment is not available, pass the invalid VirtualRegister
+ instead of an empty JSValue as the lexicalEnvironment operand.
+
+ * dfg/DFGOperations.cpp:
+ - Use the lexicalEnvironment from the ExecState for now.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ - Use the operationCreateArgumentsForDFG() thunk for now.
+
+ * interpreter/CallFrame.cpp:
+ (JSC::CallFrame::lexicalEnvironmentOrNullptr):
+ * interpreter/CallFrame.h:
+ - Added this convenience function to return either the
+ lexicalEnvironment or a nullptr so that we don't need to do a
+ conditional check on codeBlock->needsActivation() at multiple sites.
+
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::createArguments):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_arguments):
+ (JSC::JIT::emitSlow_op_get_argument_by_val):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_arguments):
+ (JSC::JIT::emitSlow_op_get_argument_by_val):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/Arguments.h:
+ (JSC::Arguments::create):
+ (JSC::Arguments::finishCreation):
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/JSLexicalEnvironment.cpp:
+ (JSC::JSLexicalEnvironment::argumentsGetter):
+
+2015-01-08 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Pause Reason Improvements (Breakpoint, Debugger Statement, Pause on Next Statement)
+ https://bugs.webkit.org/show_bug.cgi?id=138991
+
+ Reviewed by Timothy Hatcher.
+
+ * debugger/Debugger.cpp:
+ (JSC::Debugger::Debugger):
+ (JSC::Debugger::pauseIfNeeded):
+ (JSC::Debugger::didReachBreakpoint):
+ When actually pausing, if we hit a breakpoint ensure the reason
+ is PausedForBreakpoint, otherwise use the current reason.
+
+ * debugger/Debugger.h:
+ Make pause reason and pausing breakpoint ID public.
+
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::buildAssertPauseReason):
+ (Inspector::buildCSPViolationPauseReason):
+ (Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason):
+ (Inspector::InspectorDebuggerAgent::buildExceptionPauseReason):
+ (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
+ (Inspector::buildObjectForBreakpointCookie):
+ (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
+ (Inspector::InspectorDebuggerAgent::removeBreakpoint):
+ (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
+ (Inspector::InspectorDebuggerAgent::pause):
+ (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
+ (Inspector::InspectorDebuggerAgent::currentCallFrames):
+ (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
+ Clean up creation of pause reason objects and other cleanup
+ of PassRefPtr use and InjectedScript use.
+
+ (Inspector::InspectorDebuggerAgent::didPause):
+ Clean up so that we first check for an Exception, and then fall
+ back to including a Pause Reason derived from the Debugger.
+
+ * inspector/protocol/Debugger.json:
+ Add new DebuggerStatement, Breakpoint, and PauseOnNextStatement reasons.
+
+2015-01-08 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Type check NSArray's in ObjC Interfaces have the right object types
+ https://bugs.webkit.org/show_bug.cgi?id=140209
+
+ Reviewed by Timothy Hatcher.
+
+ Check the types of objects in NSArrays for all interfaces (commands, events, types)
+ when the user can set an array of objects. Previously we were only type checking
+ they were RWIJSONObjects, now we add an explicit check for the exact object type.
+
+ * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
+ (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
+ * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event):
+ * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
+ (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
+ (ObjCProtocolTypesImplementationGenerator._generate_setter_for_member):
+ * inspector/scripts/codegen/objc_generator.py:
+ (ObjCGenerator.objc_class_for_array_type):
+ (ObjCGenerator):
+
+2015-01-07 Mark Lam <mark.lam@apple.com>
+
+ Add the lexicalEnvironment as an operand to op_get_argument_by_val.
+ <https://webkit.org/b/140233>
+
+ Reviewed by Filip Pizlo.
+
+ This patch only adds the operand to the bytecode. It is not in use yet.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitGetArgumentByVal):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+
+2015-01-07 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Investigate the character type of repeated string instead of checking is8Bit flag
+ https://bugs.webkit.org/show_bug.cgi?id=140139
+
+ Reviewed by Darin Adler.
+
+ Instead of checking is8Bit flag of the repeated string, investigate
+ the actual value of the repeated character since i8Bit flag give a false negative case.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::repeatCharacter):
+ (JSC::stringProtoFuncRepeat):
+ (JSC::repeatSmallString): Deleted.
+
+2015-01-07 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ObjC Generate types from the GenericTypes domain
+ https://bugs.webkit.org/show_bug.cgi?id=140229
+
+ Reviewed by Timothy Hatcher.
+
+ Generate types from the GenericTypes domain, as they are expected
+ by other domains (like Page domain). Also, don't include the @protocol
+ forward declaration for a domain if it doesn't have any commands.
+
+ * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
+ (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
+ (ObjCBackendDispatcherHeaderGenerator): Deleted.
+ (ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations_for_domains): Deleted.
+ * inspector/scripts/codegen/objc_generator.py:
+ (ObjCGenerator):
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+
+2015-01-07 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Remove unnecessary copyRef for paramsObject in generated dispatchers
+ https://bugs.webkit.org/show_bug.cgi?id=140228
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
+ (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
+ * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+
+2015-01-07 Saam Barati <saambarati1@gmail.com>
+
+ interpret op_profile_type in the LLInt instead of unconditionally calling into the slow path
+ https://bugs.webkit.org/show_bug.cgi?id=140165
+
+ Reviewed by Michael Saboff.
+
+ Inlining the functionality of TypeProfilerLog::recordTypeInformationForLocation
+ into the LLInt speeds up type profiling.
+
+ * llint/LLIntOffsetsExtractor.cpp:
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+ * runtime/CommonSlowPaths.h:
+ * runtime/TypeProfilerLog.h:
+ (JSC::TypeProfilerLog::recordTypeInformationForLocation): Deleted.
+
+2015-01-07 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: purge PassRefPtr from Inspector code and use Ref for typed and untyped protocol objects
+ https://bugs.webkit.org/show_bug.cgi?id=140053
+
+ Reviewed by Andreas Kling.
+
+ This patch replaces uses of PassRefPtr with uses of RefPtr&& and WTF::move() in code
+ related to Web Inspector. It also converts many uses of RefPtr to Ref where
+ references are always non-null. These two refactorings have been combined since
+ they tend to require similar changes to the code.
+
+ Creation methods for subclasses of InspectorValue now return a Ref, and callsites
+ have been updated to take a Ref instead of RefPtr.
+
+ Builders for typed protocol objects now return a Ref. Since there is no implicit
+ call to operator&, callsites now must explicitly call .release() to convert a
+ builder object into the corresponding protocol object once required fields are set.
+ Update callsites and use auto to eliminate repetition of longwinded protocol types.
+
+ Tests for inspector protocol and replay inputs have been rebaselined.
+
+ * bindings/ScriptValue.cpp:
+ (Deprecated::jsToInspectorValue):
+ (Deprecated::ScriptValue::toInspectorValue):
+ * bindings/ScriptValue.h:
+ * inspector/ConsoleMessage.cpp:
+ (Inspector::ConsoleMessage::addToFrontend):
+ * inspector/ContentSearchUtilities.cpp:
+ (Inspector::ContentSearchUtilities::buildObjectForSearchMatch):
+ (Inspector::ContentSearchUtilities::searchInTextByLines):
+ * inspector/ContentSearchUtilities.h:
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getFunctionDetails):
+ (Inspector::InjectedScript::getProperties):
+ (Inspector::InjectedScript::getInternalProperties):
+ (Inspector::InjectedScript::wrapCallFrames):
+ (Inspector::InjectedScript::wrapObject):
+ (Inspector::InjectedScript::wrapTable):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptBase.cpp:
+ (Inspector::InjectedScriptBase::makeEvalCall): Split the early exits.
+ * inspector/InspectorBackendDispatcher.cpp:
+ (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase):
+ (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive):
+ (Inspector::InspectorBackendDispatcher::create):
+ (Inspector::InspectorBackendDispatcher::dispatch):
+ (Inspector::InspectorBackendDispatcher::sendResponse):
+ (Inspector::InspectorBackendDispatcher::reportProtocolError):
+ (Inspector::getPropertyValue): Add a comment to clarify what this clever code does.
+ (Inspector::InspectorBackendDispatcher::getInteger):
+ (Inspector::InspectorBackendDispatcher::getDouble):
+ (Inspector::InspectorBackendDispatcher::getString):
+ (Inspector::InspectorBackendDispatcher::getBoolean):
+ (Inspector::InspectorBackendDispatcher::getObject):
+ (Inspector::InspectorBackendDispatcher::getArray):
+ (Inspector::InspectorBackendDispatcher::getValue):
+ * inspector/InspectorBackendDispatcher.h: Use a typed protocol object to collect
+ protocol error strings.
+ (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher):
+ Convert the supplemental dispatcher's reference to Ref since it is never null.
+ * inspector/InspectorEnvironment.h:
+ * inspector/InspectorProtocolTypes.h: Get rid of ArrayItemHelper and
+ StructItemTraits. Add more versions of addItem to handle pushing various types.
+ (Inspector::Protocol::Array::openAccessors):
+ (Inspector::Protocol::Array::addItem):
+ (Inspector::Protocol::Array::create):
+ (Inspector::Protocol::StructItemTraits::push):
+ (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Assert argument.
+ (Inspector::Protocol::StructItemTraits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<String>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<int>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<double>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<bool>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<InspectorValue>::Traits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<InspectorObject>::Traits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<InspectorArray>::Traits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<Protocol::Array<T>>::Traits::pushRefPtr): Deleted.
+ * inspector/InspectorValues.cpp: Straighten out getArray and getObject to have
+ the same call signature as other getters. Use Ref where possible.
+ (Inspector::InspectorObjectBase::getBoolean):
+ (Inspector::InspectorObjectBase::getString):
+ (Inspector::InspectorObjectBase::getObject):
+ (Inspector::InspectorObjectBase::getArray):
+ (Inspector::InspectorObjectBase::getValue):
+ (Inspector::InspectorObjectBase::writeJSON):
+ (Inspector::InspectorArrayBase::get):
+ (Inspector::InspectorObject::create):
+ (Inspector::InspectorArray::create):
+ (Inspector::InspectorValue::null):
+ (Inspector::InspectorString::create):
+ (Inspector::InspectorBasicValue::create):
+ (Inspector::InspectorObjectBase::get): Deleted.
+ * inspector/InspectorValues.h:
+ (Inspector::InspectorObjectBase::setValue):
+ (Inspector::InspectorObjectBase::setObject):
+ (Inspector::InspectorObjectBase::setArray):
+ (Inspector::InspectorArrayBase::pushValue):
+ (Inspector::InspectorArrayBase::pushObject):
+ (Inspector::InspectorArrayBase::pushArray):
+ * inspector/JSGlobalObjectConsoleClient.cpp:
+ (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
+ (Inspector::JSGlobalObjectConsoleClient::count):
+ (Inspector::JSGlobalObjectConsoleClient::timeEnd):
+ (Inspector::JSGlobalObjectConsoleClient::timeStamp):
+ * inspector/JSGlobalObjectConsoleClient.h:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::executionStopwatch):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/ScriptCallFrame.cpp:
+ (Inspector::ScriptCallFrame::buildInspectorObject):
+ * inspector/ScriptCallFrame.h:
+ * inspector/ScriptCallStack.cpp:
+ (Inspector::ScriptCallStack::create):
+ (Inspector::ScriptCallStack::buildInspectorArray):
+ * inspector/ScriptCallStack.h:
+ * inspector/agents/InspectorAgent.cpp:
+ (Inspector::InspectorAgent::enable):
+ (Inspector::InspectorAgent::inspect):
+ (Inspector::InspectorAgent::activateExtraDomain):
+ * inspector/agents/InspectorAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
+ (Inspector::buildObjectForBreakpointCookie):
+ (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
+ (Inspector::InspectorDebuggerAgent::setBreakpoint):
+ (Inspector::InspectorDebuggerAgent::continueToLocation):
+ (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
+ (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
+ (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
+ (Inspector::InspectorDebuggerAgent::currentCallFrames):
+ (Inspector::InspectorDebuggerAgent::didParseSource):
+ (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
+ (Inspector::InspectorDebuggerAgent::breakProgram):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::buildErrorRangeObject):
+ (Inspector::InspectorRuntimeAgent::callFunctionOn):
+ (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
+ (Inspector::InspectorRuntimeAgent::getBasicBlocks):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/scripts/codegen/cpp_generator.py:
+ (CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
+ (CppGenerator.cpp_type_for_type_with_name):
+ (CppGenerator.cpp_type_for_formal_async_parameter):
+ (CppGenerator.should_use_references_for_type):
+ (CppGenerator):
+ * inspector/scripts/codegen/cpp_generator_templates.py:
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
+ (CppBackendDispatcherHeaderGenerator.generate_output):
+ (CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
+ (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
+ (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
+ (CppFrontendDispatcherHeaderGenerator.generate_output):
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
+ (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
+ * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
+ (CppProtocolTypesHeaderGenerator.generate_output):
+ (_generate_class_for_object_declaration):
+ (_generate_unchecked_setter_for_member):
+ (_generate_forward_declarations_for_binding_traits):
+ * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
+ (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
+ * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event):
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
+ * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
+ (ObjCProtocolTypesImplementationGenerator.generate_output):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ * replay/EncodedValue.cpp:
+ (JSC::EncodedValue::asObject):
+ (JSC::EncodedValue::asArray):
+ (JSC::EncodedValue::put<EncodedValue>):
+ (JSC::EncodedValue::append<EncodedValue>):
+ (JSC::EncodedValue::get<EncodedValue>):
+ * replay/EncodedValue.h:
+ * replay/scripts/CodeGeneratorReplayInputs.py:
+ (Type.borrow_type):
+ (Type.argument_type):
+ (Generator.generate_member_move_expression):
+ * runtime/ConsoleClient.cpp:
+ (JSC::ConsoleClient::printConsoleMessageWithArguments):
+ (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
+ (JSC::ConsoleClient::logWithLevel):
+ (JSC::ConsoleClient::clear):
+ (JSC::ConsoleClient::dir):
+ (JSC::ConsoleClient::dirXML):
+ (JSC::ConsoleClient::table):
+ (JSC::ConsoleClient::trace):
+ (JSC::ConsoleClient::assertCondition):
+ (JSC::ConsoleClient::group):
+ (JSC::ConsoleClient::groupCollapsed):
+ (JSC::ConsoleClient::groupEnd):
+ * runtime/ConsoleClient.h:
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::allStructureRepresentations):
+ (JSC::TypeSet::inspectorTypeSet):
+ (JSC::StructureShape::inspectorRepresentation):
+ * runtime/TypeSet.h:
+
+2015-01-07 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r178039.
+ https://bugs.webkit.org/show_bug.cgi?id=140187
+
+ Breaks ObjC Inspector Protocol (Requested by JoePeck on
+ #webkit).
+
+ Reverted changeset:
+
+ "Web Inspector: purge PassRefPtr from Inspector code and use
+ Ref for typed and untyped protocol objects"
+ https://bugs.webkit.org/show_bug.cgi?id=140053
+ http://trac.webkit.org/changeset/178039
+
+2015-01-06 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: purge PassRefPtr from Inspector code and use Ref for typed and untyped protocol objects
+ https://bugs.webkit.org/show_bug.cgi?id=140053
+
+ Reviewed by Andreas Kling.
+
+ This patch replaces uses of PassRefPtr with uses of RefPtr&& and WTF::move() in code
+ related to Web Inspector. It also converts many uses of RefPtr to Ref where
+ references are always non-null. These two refactorings have been combined since
+ they tend to require similar changes to the code.
+
+ Creation methods for subclasses of InspectorValue now return a Ref, and callsites
+ have been updated to take a Ref instead of RefPtr.
+
+ Builders for typed protocol objects now return a Ref. Since there is no implicit
+ call to operator&, callsites now must explicitly call .release() to convert a
+ builder object into the corresponding protocol object once required fields are set.
+ Update callsites and use auto to eliminate repetition of longwinded protocol types.
+
+ Tests for inspector protocol and replay inputs have been rebaselined.
+
+ * bindings/ScriptValue.cpp:
+ (Deprecated::jsToInspectorValue):
+ (Deprecated::ScriptValue::toInspectorValue):
+ * bindings/ScriptValue.h:
+ * inspector/ConsoleMessage.cpp:
+ (Inspector::ConsoleMessage::addToFrontend):
+ * inspector/ContentSearchUtilities.cpp:
+ (Inspector::ContentSearchUtilities::buildObjectForSearchMatch):
+ (Inspector::ContentSearchUtilities::searchInTextByLines):
+ * inspector/ContentSearchUtilities.h:
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::getFunctionDetails):
+ (Inspector::InjectedScript::getProperties):
+ (Inspector::InjectedScript::getInternalProperties):
+ (Inspector::InjectedScript::wrapCallFrames):
+ (Inspector::InjectedScript::wrapObject):
+ (Inspector::InjectedScript::wrapTable):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptBase.cpp:
+ (Inspector::InjectedScriptBase::makeEvalCall): Split the early exits.
+ * inspector/InspectorBackendDispatcher.cpp:
+ (Inspector::InspectorBackendDispatcher::CallbackBase::CallbackBase):
+ (Inspector::InspectorBackendDispatcher::CallbackBase::sendIfActive):
+ (Inspector::InspectorBackendDispatcher::create):
+ (Inspector::InspectorBackendDispatcher::dispatch):
+ (Inspector::InspectorBackendDispatcher::sendResponse):
+ (Inspector::InspectorBackendDispatcher::reportProtocolError):
+ (Inspector::getPropertyValue): Add a comment to clarify what this clever code does.
+ (Inspector::InspectorBackendDispatcher::getInteger):
+ (Inspector::InspectorBackendDispatcher::getDouble):
+ (Inspector::InspectorBackendDispatcher::getString):
+ (Inspector::InspectorBackendDispatcher::getBoolean):
+ (Inspector::InspectorBackendDispatcher::getObject):
+ (Inspector::InspectorBackendDispatcher::getArray):
+ (Inspector::InspectorBackendDispatcher::getValue):
+ * inspector/InspectorBackendDispatcher.h: Use a typed protocol object to collect
+ protocol error strings.
+ (Inspector::InspectorSupplementalBackendDispatcher::InspectorSupplementalBackendDispatcher):
+ Convert the supplemental dispatcher's reference to Ref since it is never null.
+ * inspector/InspectorEnvironment.h:
+ * inspector/InspectorProtocolTypes.h: Get rid of ArrayItemHelper and
+ StructItemTraits. Add more versions of addItem to handle pushing various types.
+ (Inspector::Protocol::Array::openAccessors):
+ (Inspector::Protocol::Array::addItem):
+ (Inspector::Protocol::Array::create):
+ (Inspector::Protocol::StructItemTraits::push):
+ (Inspector::Protocol::BindingTraits<Protocol::Array<T>>::runtimeCast): Assert argument.
+ (Inspector::Protocol::StructItemTraits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<String>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<int>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<double>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<bool>::Traits::pushRaw): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<InspectorValue>::Traits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<InspectorObject>::Traits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<InspectorArray>::Traits::pushRefPtr): Deleted.
+ (Inspector::Protocol::ArrayItemHelper<Protocol::Array<T>>::Traits::pushRefPtr): Deleted.
+ * inspector/InspectorValues.cpp: Straighten out getArray and getObject to have
+ the same call signature as other getters. Use Ref where possible.
+ (Inspector::InspectorObjectBase::getBoolean):
+ (Inspector::InspectorObjectBase::getString):
+ (Inspector::InspectorObjectBase::getObject):
+ (Inspector::InspectorObjectBase::getArray):
+ (Inspector::InspectorObjectBase::getValue):
+ (Inspector::InspectorObjectBase::writeJSON):
+ (Inspector::InspectorArrayBase::get):
+ (Inspector::InspectorObject::create):
+ (Inspector::InspectorArray::create):
+ (Inspector::InspectorValue::null):
+ (Inspector::InspectorString::create):
+ (Inspector::InspectorBasicValue::create):
+ (Inspector::InspectorObjectBase::get): Deleted.
+ * inspector/InspectorValues.h:
+ (Inspector::InspectorObjectBase::setValue):
+ (Inspector::InspectorObjectBase::setObject):
+ (Inspector::InspectorObjectBase::setArray):
+ (Inspector::InspectorArrayBase::pushValue):
+ (Inspector::InspectorArrayBase::pushObject):
+ (Inspector::InspectorArrayBase::pushArray):
+ * inspector/JSGlobalObjectConsoleClient.cpp:
+ (Inspector::JSGlobalObjectConsoleClient::messageWithTypeAndLevel):
+ (Inspector::JSGlobalObjectConsoleClient::count):
+ (Inspector::JSGlobalObjectConsoleClient::timeEnd):
+ (Inspector::JSGlobalObjectConsoleClient::timeStamp):
+ * inspector/JSGlobalObjectConsoleClient.h:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::executionStopwatch):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/ScriptCallFrame.cpp:
+ (Inspector::ScriptCallFrame::buildInspectorObject):
+ * inspector/ScriptCallFrame.h:
+ * inspector/ScriptCallStack.cpp:
+ (Inspector::ScriptCallStack::create):
+ (Inspector::ScriptCallStack::buildInspectorArray):
+ * inspector/ScriptCallStack.h:
+ * inspector/agents/InspectorAgent.cpp:
+ (Inspector::InspectorAgent::enable):
+ (Inspector::InspectorAgent::inspect):
+ (Inspector::InspectorAgent::activateExtraDomain):
+ * inspector/agents/InspectorAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
+ (Inspector::buildObjectForBreakpointCookie):
+ (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
+ (Inspector::InspectorDebuggerAgent::setBreakpoint):
+ (Inspector::InspectorDebuggerAgent::continueToLocation):
+ (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
+ (Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement):
+ (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
+ (Inspector::InspectorDebuggerAgent::currentCallFrames):
+ (Inspector::InspectorDebuggerAgent::didParseSource):
+ (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
+ (Inspector::InspectorDebuggerAgent::breakProgram):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::buildErrorRangeObject):
+ (Inspector::InspectorRuntimeAgent::callFunctionOn):
+ (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
+ (Inspector::InspectorRuntimeAgent::getBasicBlocks):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/scripts/codegen/cpp_generator.py:
+ (CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
+ (CppGenerator.cpp_type_for_type_with_name):
+ (CppGenerator.cpp_type_for_formal_async_parameter):
+ (CppGenerator.should_use_references_for_type):
+ (CppGenerator):
+ * inspector/scripts/codegen/cpp_generator_templates.py:
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
+ (CppBackendDispatcherHeaderGenerator.generate_output):
+ (CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
+ (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
+ (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
+ (CppFrontendDispatcherHeaderGenerator.generate_output):
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
+ (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
+ * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
+ (CppProtocolTypesHeaderGenerator.generate_output):
+ (_generate_class_for_object_declaration):
+ (_generate_unchecked_setter_for_member):
+ (_generate_forward_declarations_for_binding_traits):
+ * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
+ (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
+ * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event):
+ (ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
+ * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
+ (ObjCProtocolTypesImplementationGenerator.generate_output):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ * replay/EncodedValue.cpp:
+ (JSC::EncodedValue::asObject):
+ (JSC::EncodedValue::asArray):
+ (JSC::EncodedValue::put<EncodedValue>):
+ (JSC::EncodedValue::append<EncodedValue>):
+ (JSC::EncodedValue::get<EncodedValue>):
+ * replay/EncodedValue.h:
+ * replay/scripts/CodeGeneratorReplayInputs.py:
+ (Type.borrow_type):
+ (Type.argument_type):
+ (Generator.generate_member_move_expression):
+ * runtime/ConsoleClient.cpp:
+ (JSC::ConsoleClient::printConsoleMessageWithArguments):
+ (JSC::ConsoleClient::internalMessageWithTypeAndLevel):
+ (JSC::ConsoleClient::logWithLevel):
+ (JSC::ConsoleClient::clear):
+ (JSC::ConsoleClient::dir):
+ (JSC::ConsoleClient::dirXML):
+ (JSC::ConsoleClient::table):
+ (JSC::ConsoleClient::trace):
+ (JSC::ConsoleClient::assertCondition):
+ (JSC::ConsoleClient::group):
+ (JSC::ConsoleClient::groupCollapsed):
+ (JSC::ConsoleClient::groupEnd):
+ * runtime/ConsoleClient.h:
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::allStructureRepresentations):
+ (JSC::TypeSet::inspectorTypeSet):
+ (JSC::StructureShape::inspectorRepresentation):
+ * runtime/TypeSet.h:
+
+2015-01-06 Chris Dumez <cdumez@apple.com>
+
+ Drop ResourceResponseBase::connectionID and connectionReused members
+ https://bugs.webkit.org/show_bug.cgi?id=140158
+
+ Reviewed by Sam Weinig.
+
+ Drop ResourceResponseBase::connectionID and connectionReused members.
+ Those were needed by the Chromium port but are no longer used.
+
+ * inspector/protocol/Network.json:
+
+2015-01-06 Mark Lam <mark.lam@apple.com>
+
+ Add the lexicalEnvironment as an operand to op_create_arguments.
+ <https://webkit.org/b/140148>
+
+ Reviewed by Geoffrey Garen.
+
+ This patch only adds the operand to the bytecode. It is not in use yet.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::createArgumentsIfNecessary):
+ - Adds the lexicalEnvironment register (if present) as an operand to
+ op_create_arguments. Else, adds a constant empty JSValue.
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+
+2015-01-06 Alexey Proskuryakov <ap@apple.com>
+
+ ADDRESS_SANITIZER macro is overloaded
+ https://bugs.webkit.org/show_bug.cgi?id=140130
+
+ Reviewed by Anders Carlsson.
+
+ * interpreter/JSStack.cpp: (JSC::JSStack::sanitizeStack): Use the new macro.
+ This code is nearly unused (only compiled in when JIT is disabled at build time),
+ however I've been told that it's best to keep it.
+
+2015-01-06 Mark Lam <mark.lam@apple.com>
+
+ Fix Use details for op_create_arguments.
+ <https://webkit.org/b/140110>
+
+ Rubber stamped by Filip Pizlo.
+
+ The previous patch was wrong about op_create_arguments not using its 1st operand.
+ It does read from it (hence, used) to check if the Arguments object has already
+ been created or not. This patch reverts the change for op_create_arguments.
+
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+
+2015-01-06 Mark Lam <mark.lam@apple.com>
+
+ Fix Use details for op_create_lexical_environment and op_create_arguments.
+ <https://webkit.org/b/140110>
+
+ Reviewed by Filip Pizlo.
+
+ The current "Use" details for op_create_lexical_environment and
+ op_create_arguments are wrong. op_create_argument uses nothing instead of the
+ 1st operand (the output local). op_create_lexical_environment uses its 2nd
+ operand (the scope chain) instead of the 1st (the output local).
+ This patch fixes them to specify the proper uses.
+
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+
+2015-01-06 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Implement ES6 String.prototype.repeat(count)
+ https://bugs.webkit.org/show_bug.cgi?id=140047
+
+ Reviewed by Darin Adler.
+
+ Introducing ES6 String.prototype.repeat(count) function.
+
+ * runtime/JSString.h:
+ * runtime/StringPrototype.cpp:
+ (JSC::StringPrototype::finishCreation):
+ (JSC::repeatSmallString):
+ (JSC::stringProtoFuncRepeat):
+
+2015-01-03 Michael Saboff <msaboff@apple.com>
+
+ Crash in operationNewFunction when scrolling on Google+
+ https://bugs.webkit.org/show_bug.cgi?id=140033
+
+ Reviewed by Oliver Hunt.
+
+ In DFG code, the scope register can be eliminated because all uses have been
+ dead code eliminated. In the case where one of the uses was creating a function
+ that is never used, the baseline code will still create the function. If we OSR
+ exit to a path where that function gets created, check the scope register value
+ and set the new, but dead, function to undefined instead of creating a new function.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_new_func_exp):
+
+2015-01-01 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ String includes methods perform toString on searchString before toInt32 on a offset
+ https://bugs.webkit.org/show_bug.cgi?id=140031
+
+ Reviewed by Darin Adler.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncStartsWith):
+ (JSC::stringProtoFuncEndsWith):
+ (JSC::stringProtoFuncIncludes):
+
+2015-01-01 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Change to return std::unique_ptr<> in fooCreate()
+ https://bugs.webkit.org/show_bug.cgi?id=139983
+
+ Reviewed by Darin Adler.
+
+ To avoid unnecessary std::unique_ptr<> casting, fooCreate() returns std::unique_ptr<> directly.
+
+ * create_regex_tables:
+ * yarr/YarrPattern.h:
+ (JSC::Yarr::YarrPattern::reset):
+ (JSC::Yarr::YarrPattern::newlineCharacterClass):
+ (JSC::Yarr::YarrPattern::digitsCharacterClass):
+ (JSC::Yarr::YarrPattern::spacesCharacterClass):
+ (JSC::Yarr::YarrPattern::wordcharCharacterClass):
+ (JSC::Yarr::YarrPattern::nondigitsCharacterClass):
+ (JSC::Yarr::YarrPattern::nonspacesCharacterClass):
+ (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
+
+2015-01-01 Jeff Miller <jeffm@apple.com>
+
+ Update user-visible copyright strings to include 2015
+ https://bugs.webkit.org/show_bug.cgi?id=139880
+
+ Reviewed by Darin Adler.
+
+ * Info.plist:
+
+2015-01-01 Darin Adler <darin@apple.com>
+
+ We often misspell identifier as "identifer"
+ https://bugs.webkit.org/show_bug.cgi?id=140025
+
+ Reviewed by Michael Saboff.
+
+ * runtime/ArrayConventions.h: Fix it.
+
+2014-12-29 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Move JavaScriptCore/yarr to std::unique_ptr
+ https://bugs.webkit.org/show_bug.cgi?id=139621
+
+ Reviewed by Anders Carlsson.
+
+ Final clean up OwnPtr|PassOwnPtr in JavaScriptCore/yarr.
+
+ * yarr/YarrInterpreter.cpp:
+ (JSC::Yarr::ByteCompiler::atomParenthesesSubpatternEnd):
+ * yarr/YarrInterpreter.h:
+ (JSC::Yarr::BytecodePattern::BytecodePattern):
+ * yarr/YarrJIT.cpp:
+ (JSC::Yarr::YarrGenerator::opCompileParenthesesSubpattern):
+ (JSC::Yarr::YarrGenerator::opCompileParentheticalAssertion):
+ (JSC::Yarr::YarrGenerator::opCompileBody):
+ * yarr/YarrPattern.cpp:
+ (JSC::Yarr::CharacterClassConstructor::charClass):
+ (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
+ (JSC::Yarr::YarrPatternConstructor::reset):
+ (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
+ (JSC::Yarr::YarrPatternConstructor::atomCharacterClassEnd):
+ (JSC::Yarr::YarrPatternConstructor::atomParenthesesSubpatternBegin):
+ (JSC::Yarr::YarrPatternConstructor::atomParentheticalAssertionBegin):
+ (JSC::Yarr::YarrPatternConstructor::copyDisjunction):
+ (JSC::Yarr::YarrPatternConstructor::checkForTerminalParentheses):
+ (JSC::Yarr::YarrPatternConstructor::optimizeDotStarWrappedExpressions):
+ * yarr/YarrPattern.h:
+ (JSC::Yarr::PatternDisjunction::addNewAlternative):
+ (JSC::Yarr::YarrPattern::newlineCharacterClass):
+ (JSC::Yarr::YarrPattern::digitsCharacterClass):
+ (JSC::Yarr::YarrPattern::spacesCharacterClass):
+ (JSC::Yarr::YarrPattern::wordcharCharacterClass):
+ (JSC::Yarr::YarrPattern::nondigitsCharacterClass):
+ (JSC::Yarr::YarrPattern::nonspacesCharacterClass):
+ (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
+
+2014-12-26 Dan Bernstein <mitz@apple.com>
+
+ <rdar://problem/19348208> REGRESSION (r177027): iOS builds use the wrong toolchain
+ https://bugs.webkit.org/show_bug.cgi?id=139950
+
+ Reviewed by David Kilzer.
+
+ * Configurations/Base.xcconfig: Only define TOOLCHAINS when building for OS X, doing so
+ in a manner that works with Xcode 5.1.1.
+
+2014-12-22 Mark Lam <mark.lam@apple.com>
+
+ Use ctiPatchCallByReturnAddress() in JITOperations.cpp.
+ <https://webkit.org/b/139892>
+
+ Reviewed by Michael Saboff.
+
+ The code in JITOperations.cpp sometimes calls RepatchBuffer::relinkCallerToFunction()
+ directly, and sometimes uses a helper function, ctiPatchCallByReturnAddress().
+ This patch changes it to use the helper function consistently.
+
+ * jit/JITOperations.cpp:
+
+2014-12-22 Mark Lam <mark.lam@apple.com>
+
+ Fix some typos in a comment.
+ <https://webkit.org/b/139882>
+
+ Reviewed by Michael Saboff.
+
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emit_op_get_by_val):
+
+2014-12-22 Mark Lam <mark.lam@apple.com>
+
+ Assert that Array elements not copied when changing shape to ArrayStorage type are indeed holes.
+ <https://webkit.org/b/138118>
+
+ Reviewed by Michael Saboff.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::convertInt32ToArrayStorage):
+ (JSC::JSObject::convertDoubleToArrayStorage):
+ (JSC::JSObject::convertContiguousToArrayStorage):
+
+2014-12-20 Eric Carlson <eric.carlson@apple.com>
+
+ [iOS] add optimized fullscreen API
+ https://bugs.webkit.org/show_bug.cgi?id=139833
+ <rdar://problem/18844486>
+
+ Reviewed by Simon Fraser.
+
+ * Configurations/FeatureDefines.xcconfig: Add ENABLE_VIDEO_PRESENTATION_MODE.
+
+2014-12-20 David Kilzer <ddkilzer@apple.com>
+
+ Switch from using PLATFORM_NAME to SDK selectors in WebCore, WebInspectorUI, WebKit, WebKit2
+ <http://webkit.org/b/139463>
+
+ Reviewed by Mark Rowe.
+
+ * Configurations/JavaScriptCore.xcconfig:
+ - Simplify SECTORDER_FLAGS.
+
+2014-12-19 Andreas Kling <akling@apple.com>
+
+ Plug leak below LLVMCopyStringRepOfTargetData().
+ <https://webkit.org/b/139832>
+
+ Reviewed by Michael Saboff.
+
+ LLVMCopyStringRepOfTargetData() returns a strdup()'ed string, so make sure
+ to free() it after we're done using it.
+
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+
+2014-12-19 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: CRASH inspector-protocol/debugger/breakpoint-action-detach.html
+ https://bugs.webkit.org/show_bug.cgi?id=139797
+
+ Reviewed by Mark Lam.
+
+ * debugger/Debugger.h:
+ * debugger/Debugger.cpp:
+ (JSC::Debugger::isAttached):
+ Check if we are the debugger for a particular global object.
+ (JSC::Debugger::pauseIfNeeded):
+ Pass the global object on when hitting a brekapoint.
+
+ * inspector/ScriptDebugServer.h:
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::handleBreakpointHit):
+ Stop evaluting breakpoint actions if a previous action caused the
+ debugger to detach from this global object.
+ (Inspector::ScriptDebugServer::handlePause):
+ Standardize on passing JSGlobalObject parameter first.
+
+2014-12-19 Mark Lam <mark.lam@apple.com>
+
+ [Win] Endless compiler warnings created by DFGEdge.h.
+ <https://webkit.org/b/139801>
+
+ Reviewed by Brent Fulgham.
+
+ Add a cast to fix the type just the way the 64-bit version does.
+
+ * dfg/DFGEdge.h:
+ (JSC::DFG::Edge::makeWord):
+
+2014-12-19 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r177574.
+ https://bugs.webkit.org/show_bug.cgi?id=139821
+
+ "Broke Production builds by installing
+ libWebCoreTestSupport.dylib in the wrong directory" (Requested
+ by ddkilzer on #webkit).
+
+ Reverted changeset:
+
+ "Switch from using PLATFORM_NAME to SDK selectors in WebCore,
+ WebInspectorUI, WebKit, WebKit2"
+ https://bugs.webkit.org/show_bug.cgi?id=139463
+ http://trac.webkit.org/changeset/177574
+
+2014-12-19 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(174226): Captured arguments in a using function compiled by the DFG have the initial value when the closure was invoked
+ https://bugs.webkit.org/show_bug.cgi?id=139808
+
+ Reviewed by Oliver Hunt.
+
+ There are three changes here.
+ 1) Create a VariableWatchpointSet for captured arguments variables.
+ 2) Properly use the VariableWatchpointSet* found in op_put_to_scope in the 64 bit LLInt code.
+ 3) Add the same putLocalClosureVar path to the 32 bit LLInt code that exists in the 64 bit version.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+
+2014-12-19 David Kilzer <ddkilzer@apple.com>
+
+ Switch from using PLATFORM_NAME to SDK selectors in WebCore, WebInspectorUI, WebKit, WebKit2
+ <http://webkit.org/b/139463>
+
+ Reviewed by Mark Rowe.
+
+ * Configurations/JavaScriptCore.xcconfig:
+ - Simplify SECTORDER_FLAGS.
+
+2014-12-18 Brent Fulgham <bfulgham@apple.com>
+
+ Unreviewed build fix.
+
+ * jsc.cpp: Remove typo.
+
+2014-12-17 Michael Saboff <msaboff@apple.com>
+
+ Tests with infinite recursion frequently crash
+ https://bugs.webkit.org/show_bug.cgi?id=139548
+
+ Reviewed by Geoffrey Garen.
+
+ While unwinding, if the call frame doesn't have a codeblock, then we
+ are in native code, handle appropriately.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::unwindCallFrame):
+ (JSC::UnwindFunctor::operator()):
+ Added checks for null CodeBlock.
+
+ (JSC::Interpreter::unwind): Removed wrong ASSERT.
+
+2014-12-17 Chris Dumez <cdumez@apple.com>
+
+ [iOS] Make it possible to toggle FeatureCounter support at runtime
+ https://bugs.webkit.org/show_bug.cgi?id=139688
+ <rdar://problem/19266254>
+
+ Reviewed by Andreas Kling.
+
+ Stop linking against AppSupport framework as the functionality is no
+ longer in WTF (it was moved to WebCore).
+
+ * Configurations/JavaScriptCore.xcconfig:
+
+2014-12-17 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Correct DebugSuffix builds under MSBuild
+ https://bugs.webkit.org/show_bug.cgi?id=139733
+ <rdar://problem/19276880>
+
+ Reviewed by Simon Fraser.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.proj: Make sure to use the
+ '_debug' suffix when building the DebugSuffix target.
+
+2014-12-16 Enrica Casucci <enrica@apple.com>
+
+ Fix iOS builders for 8.0
+ https://bugs.webkit.org/show_bug.cgi?id=139495
+
+ Reviewed by Michael Saboff.
+
+ * Configurations/LLVMForJSC.xcconfig:
+ * llvm/library/LLVMExports.cpp:
+ (initializeAndGetJSCLLVMAPI):
+
+2014-12-16 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r177380.
+ https://bugs.webkit.org/show_bug.cgi?id=139707
+
+ "Breaks js/regres/elidable-new-object-* tests" (Requested by
+ msaboff_ on #webkit).
+
+ Reverted changeset:
+
+ "Fixes operationPutByIdOptimizes such that they check that the
+ put didn't"
+ https://bugs.webkit.org/show_bug.cgi?id=139500
+ http://trac.webkit.org/changeset/177380
+
+2014-12-16 Matthew Mirman <mmirman@apple.com>
+
+ Fixes operationPutByIdOptimizes such that they check that the put didn't
+ change the structure of the object who's property access is being
+ cached.
+ https://bugs.webkit.org/show_bug.cgi?id=139500
+
+ Reviewed by Geoffrey Garen.
+
+ * jit/JITOperations.cpp:
+ (JSC::operationPutByIdStrictOptimize): saved the structure before the put.
+ (JSC::operationPutByIdNonStrictOptimize): ditto.
+ (JSC::operationPutByIdDirectStrictOptimize): ditto.
+ (JSC::operationPutByIdDirectNonStrictOptimize): ditto.
+ * jit/Repatch.cpp:
+ (JSC::tryCachePutByID): Added argument for the old structure
+ (JSC::repatchPutByID): Added argument for the old structure
+ * jit/Repatch.h:
+ * tests/stress/put-by-id-build-list-order-recurse.js:
+ Added test that fails without this patch.
+
+2014-12-15 Chris Dumez <cdumez@apple.com>
+
+ [iOS] Add feature counting support
+ https://bugs.webkit.org/show_bug.cgi?id=139652
+ <rdar://problem/19255690>
+
+ Reviewed by Gavin Barraclough.
+
+ Link against AppSupport framework on iOS as we need it to implement
+ the new FeatureCounter API in WTF.
+
+ * Configurations/JavaScriptCore.xcconfig:
+
+2014-12-15 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r177284.
+ https://bugs.webkit.org/show_bug.cgi?id=139658
+
+ "Breaks API tests and LayoutTests on Yosemite Debug"
+ (Requested by msaboff on #webkit).
+
+ Reverted changeset:
+
+ "Make sure range based iteration of Vector<> still receives
+ bounds checking"
+ https://bugs.webkit.org/show_bug.cgi?id=138821
+ http://trac.webkit.org/changeset/177284
+
+2014-12-15 Dániel Bátyai <dbatyai.u-szeged@partner.samsung.com>
+
+ [EFL] FTL JIT not working on ARM64
+ https://bugs.webkit.org/show_bug.cgi?id=139295
+
+ Reviewed by Michael Saboff.
+
+ Added the missing code for stack unwinding and some additional small fixes
+ to get FTL working correctly.
+
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLUnwindInfo.cpp:
+ (JSC::FTL::UnwindInfo::parse):
+
+2014-12-15 Oliver Hunt <oliver@apple.com>
+
+ Make sure range based iteration of Vector<> still receives bounds checking
+ https://bugs.webkit.org/show_bug.cgi?id=138821
+
+ Reviewed by Mark Lam.
+
+ Update code to deal with slightly changed iterator semantics.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::visitChildren):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitComplexPopScopes):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
+ * ftl/FTLAbbreviations.h:
+ (JSC::FTL::mdNode):
+ (JSC::FTL::buildCall):
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * parser/Parser.h:
+ (JSC::Scope::Scope):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::setLengthWithArrayStorage):
+ (JSC::JSArray::sortCompactedVector):
+ * tools/ProfileTreeNode.h:
+ (JSC::ProfileTreeNode::dumpInternal):
+ * yarr/YarrJIT.cpp:
+ (JSC::Yarr::YarrGenerator::matchCharacterClass):
+
+2014-12-14 Filip Pizlo <fpizlo@apple.com>
+
+ PutLocalSinkingPhase has an invalid assertion about incoming values, because both liveness and deferral analyses are conservative
+ https://bugs.webkit.org/show_bug.cgi?id=139630
+
+ Reviewed by Oliver Hunt.
+
+ Replaces a faulty assertion with code to handle an awesome special case. Also adds a lot of
+ comments that reconstruct my reasoning about this code. I had to work hard to remember how
+ deferral worked so I wrote my discoveries down.
+
+ * dfg/DFGInsertionSet.h:
+ (JSC::DFG::InsertionSet::insertBottomConstantForUse):
+ * dfg/DFGPutLocalSinkingPhase.cpp:
+ * tests/stress/put-local-conservative.js: Added.
+ (foo):
+ (.result):
+ (bar):
+
+2014-12-14 Andreas Kling <akling@apple.com>
+
+ Replace PassRef with Ref/Ref&& across the board.
+ <https://webkit.org/b/139587>
+
+ Reviewed by Darin Adler.
+
+ * runtime/Identifier.cpp:
+ (JSC::Identifier::add):
+ (JSC::Identifier::add8):
+ * runtime/Identifier.h:
+ (JSC::Identifier::add):
+ * runtime/IdentifierInlines.h:
+ (JSC::Identifier::add):
+
+2014-12-12 Matthew Mirman <mmirman@apple.com>
+
+ shiftCountWithArrayStorage should exit to slow path if the object has a sparse map.
+ https://bugs.webkit.org/show_bug.cgi?id=139598
+ <rdar://problem/18779367>
+
+ Reviewed by Filip Pizlo.
+
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::shiftCountWithArrayStorage): Added check for object having a sparse map.
+ * tests/stress/sparse_splice.js: Added.
+
+2014-12-12 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Final clean up OwnPtr in JSC - runtime, ftl, and tool directories
+ https://bugs.webkit.org/show_bug.cgi?id=139532
+
+ Reviewed by Mark Lam.
+
+ Final remove OwnPtr, PassOwnPtr in runtime, ftl, and tools directories of JSC.
+
+ * builtins/BuiltinExecutables.h:
+ * bytecode/CodeBlock.h:
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock):
+ * ftl/FTLAbstractHeap.cpp:
+ (JSC::FTL::IndexedAbstractHeap::atSlow):
+ * ftl/FTLAbstractHeap.h:
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLJITFinalizer.h:
+ * jsc.cpp:
+ (jscmain):
+ * parser/Lexer.h:
+ * runtime/PropertyMapHashTable.h:
+ (JSC::PropertyTable::clearDeletedOffsets):
+ (JSC::PropertyTable::addDeletedOffset):
+ * runtime/PropertyTable.cpp:
+ (JSC::PropertyTable::PropertyTable):
+ * runtime/RegExpObject.cpp:
+ * runtime/SmallStrings.cpp:
+ * runtime/Structure.cpp:
+ * runtime/StructureIDTable.cpp:
+ (JSC::StructureIDTable::StructureIDTable):
+ (JSC::StructureIDTable::resize):
+ * runtime/StructureIDTable.h:
+ * runtime/StructureTransitionTable.h:
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ (JSC::VM::~VM):
+ * runtime/VM.h:
+ * tools/CodeProfile.h:
+ (JSC::CodeProfile::CodeProfile):
+ (JSC::CodeProfile::addChild):
+
+2014-12-11 Dan Bernstein <mitz@apple.com>
+
+ iOS Simulator production build fix.
+
+ * Configurations/JavaScriptCore.xcconfig: Don’t use an order file when building for the iOS
+ Simulator, as we did prior to 177027.
+
+2014-12-11 Joseph Pecoraro <pecoraro@apple.com>
+
+ Explicitly export somre more RWIProtocol classes.
+ rdar://problem/19220408
+
+ Unreviewed build fix.
+
+ * inspector/scripts/codegen/generate_objc_configuration_header.py:
+ (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
+ * inspector/scripts/codegen/generate_objc_header.py:
+ (ObjCHeaderGenerator._generate_event_interfaces):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+
+2014-12-11 Alexey Proskuryakov <ap@apple.com>
+
+ Explicitly export some RWIProtocol classes
+ rdar://problem/19220408
+
+ * inspector/scripts/codegen/generate_objc_header.py:
+ (ObjCHeaderGenerator._generate_type_interface):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+
+2014-12-11 Mark Lam <mark.lam@apple.com>
+
+ Fix broken build after r177146.
+ https://bugs.webkit.org/show_bug.cgi?id=139533
+
+ Not reviewed.
+
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::init):
+ - Restored CallFrame::init() minus the unused JSScope* arg.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ - Remove JSScope* arg when calling CallFrame::init().
+
+2014-12-11 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION: Use of undefined CallFrame::ScopeChain value
+ https://bugs.webkit.org/show_bug.cgi?id=139533
+
+ Reviewed by Mark Lam.
+
+ Removed CallFrame::scope() and CallFrame::setScope() and eliminated or changed
+ all usages of these funcitons. In some cases the scope is passed in or determined
+ another way. In some cases the scope is used to calculate other values. Lastly
+ were places where these functions where used that are no longer needed. For
+ example when making a call, the caller's ScopeChain was copied to the callee's
+ ScopeChain. This change no longer uses the ScopeChain call frame header slot.
+ That slot will be removed in a future patch.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * runtime/JSLexicalEnvironment.h:
+ (JSC::JSLexicalEnvironment::create):
+ (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_lexical_environment):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_lexical_environment):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ (JSC::LLInt::handleHostCall):
+ (JSC::LLInt::setUpCall):
+ (JSC::LLInt::llint_throw_stack_overflow_error):
+ Pass the current scope value to the helper operationCreateActivation() and
+ the call to JSLexicalEnvironment::create() instead of using the stack frame
+ scope chain value.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ CreateActivation now has a second child, the scope.
+
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::init): Deleted. This is dead code.
+ (JSC::ExecState::scope): Deleted.
+ (JSC::ExecState::setScope): Deleted.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::dumpRegisters): Changed so we didn't access the scope
+ chain slot.
+
+ (JSC::Interpreter::execute):
+ (JSC::Interpreter::executeCall):
+ (JSC::Interpreter::executeConstruct):
+ Changed process to find JSScope values on the stack or by some other means.
+
+ * runtime/JSWithScope.h:
+ (JSC::JSWithScope::JSWithScope): Deleted.
+ Eliminated unused constructor.
+
+ * runtime/StrictEvalActivation.cpp:
+ (JSC::StrictEvalActivation::StrictEvalActivation):
+ * runtime/StrictEvalActivation.h:
+ (JSC::StrictEvalActivation::create):
+ Changed to pass in the current scope.
+
+2014-12-10 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use std::unique_ptr instead of OwnPtr in JSC - heap, jit, runtime, and parser directories
+ https://bugs.webkit.org/show_bug.cgi?id=139351
+
+ Reviewed by Filip Pizlo.
+
+ As a step to use std::unique_ptr<>, this cleans up OwnPtr and PassOwnPtr.
+
+ * bytecode/SamplingTool.h:
+ (JSC::SamplingTool::SamplingTool):
+ * heap/CopiedBlock.h:
+ (JSC::CopiedBlock::didSurviveGC):
+ (JSC::CopiedBlock::pin):
+ * heap/CopiedBlockInlines.h:
+ (JSC::CopiedBlock::reportLiveBytes):
+ * heap/GCActivityCallback.h:
+ * heap/GCThread.cpp:
+ * heap/Heap.h:
+ * heap/HeapInlines.h:
+ (JSC::Heap::markListSet):
+ * jit/ExecutableAllocator.cpp:
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompile):
+ * jit/JIT.h:
+ * jit/JITThunks.cpp:
+ (JSC::JITThunks::JITThunks):
+ (JSC::JITThunks::clearHostFunctionStubs):
+ * jit/JITThunks.h:
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::Parser):
+ * parser/Parser.h:
+ (JSC::Scope::Scope):
+ (JSC::Scope::pushLabel):
+ * parser/ParserArena.cpp:
+ * parser/ParserArena.h:
+ (JSC::ParserArena::identifierArena):
+ * parser/SourceProviderCache.h:
+ * runtime/CodeCache.h:
+ * runtime/Executable.h:
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::sortVector):
+ * runtime/JSGlobalObject.h:
+
+2014-12-10 Geoffrey Garen <ggaren@apple.com>
+
+ Please disable the webkitFirstVersionWithInitConstructorSupport check on Apple TV
+ https://bugs.webkit.org/show_bug.cgi?id=139501
+
+ Reviewed by Gavin Barraclough.
+
+ NSVersionOfLinkTimeLibrary only works if you link directly against
+ JavaScriptCore, which is a bit awkward for our Apple TV client to do.
+
+ It's easy enough just to disable this check on Apple TV, since it has no
+ backwards compatibility requirement.
+
+ * API/JSWrapperMap.mm:
+ (supportsInitMethodConstructors):
+
+2014-12-10 Matthew Mirman <mmirman@apple.com>
+
+ Fixes operationPutByIds such that they check that the put didn't
+ change the structure of the object who's property access is being
+ cached.
+ https://bugs.webkit.org/show_bug.cgi?id=139196
+
+ Reviewed by Filip Pizlo.
+
+ * jit/JITOperations.cpp:
+ (JSC::operationGetByIdOptimize): changed get to getPropertySlot
+ (JSC::operationPutByIdStrictBuildList): saved the structure before the put.
+ (JSC::operationPutByIdNonStrictBuildList): ditto.
+ (JSC::operationPutByIdDirectStrictBuildList): ditto.
+ (JSC::operationPutByIdDirectNonStrictBuildList): ditto.
+ * jit/Repatch.cpp:
+ (JSC::tryCachePutByID): fixed structure() to use the existant vm.
+ (JSC::tryBuildPutByIdList): Added a check that the old structure's id
+ is the same as the new.
+ (JSC::buildPutByIdList): Added an argument
+ * jit/Repatch.h:
+ (JSC::buildPutByIdList): Added an argument
+ * tests/stress/put-by-id-strict-build-list-order.js: Added.
+
+2014-12-10 Csaba Osztrogonác <ossy@webkit.org>
+
+ URTBF after r177030.
+
+ Fix linking failure occured on ARM buildbots:
+ lib/libjavascriptcore_efl.so.1.11.0: undefined reference to `JSC::Structure::get(JSC::VM&, JSC::PropertyName, unsigned int&)'
+
+ * runtime/NullGetterFunction.cpp:
+
+2014-12-09 Michael Saboff <msaboff@apple.com>
+
+ DFG Tries using an inner object's getter/setter when one hasn't been defined
+ https://bugs.webkit.org/show_bug.cgi?id=139229
+
+ Reviewed by Filip Pizlo.
+
+ Added a new NullGetterFunction singleton class to use for getters and setters that
+ haven't been set to a user defined value. The NullGetterFunction callReturnUndefined()
+ and createReturnUndefined() methods return undefined. Changed all null checks of the
+ getter and setter pointers to the newly added isGetterNull() and isSetterNull()
+ helper methods.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ Added NullGetterFunction.cpp & .h to build files.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * runtime/ObjectPrototype.cpp:
+ (JSC::objectProtoFuncLookupGetter):
+ (JSC::objectProtoFuncLookupSetter):
+ * runtime/PropertyDescriptor.cpp:
+ (JSC::PropertyDescriptor::setDescriptor):
+ (JSC::PropertyDescriptor::setAccessorDescriptor):
+ Changed checking getter and setter to null to use new isGetterNull() and isSetterNull()
+ helpers.
+
+ * inspector/JSInjectedScriptHostPrototype.cpp:
+ (Inspector::JSInjectedScriptHostPrototype::finishCreation):
+ * inspector/JSJavaScriptCallFramePrototype.cpp:
+ * jit/JITOperations.cpp:
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::putIndexedDescriptor):
+ (JSC::putDescriptor):
+ (JSC::JSObject::defineOwnNonIndexProperty):
+ * runtime/MapPrototype.cpp:
+ (JSC::MapPrototype::finishCreation):
+ * runtime/SetPrototype.cpp:
+ (JSC::SetPrototype::finishCreation):
+ Updated calls to GetterSetter::create(), setGetter(), setSetter(), withGetter()
+ and withSetter() to provide a global object.
+
+ * runtime/GetterSetter.cpp:
+ (JSC::GetterSetter::withGetter):
+ (JSC::GetterSetter::withSetter):
+ (JSC::callGetter):
+ (JSC::callSetter):
+ * runtime/GetterSetter.h:
+ (JSC::GetterSetter::GetterSetter):
+ (JSC::GetterSetter::create):
+ (JSC::GetterSetter::isGetterNull):
+ (JSC::GetterSetter::isSetterNull):
+ (JSC::GetterSetter::setGetter):
+ (JSC::GetterSetter::setSetter):
+ Changed to use NullGetterFunction for unspecified getters / setters.
+
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ (JSC::JSGlobalObject::createThrowTypeError):
+ (JSC::JSGlobalObject::visitChildren):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::nullGetterFunction):
+ (JSC::JSGlobalObject::evalFunction):
+ Added m_nullGetterFunction singleton. Updated calls to GetterSetter::create(),
+ setGetter() and setSetter() to provide a global object.
+
+ * runtime/NullGetterFunction.cpp: Added.
+ (JSC::callReturnUndefined):
+ (JSC::constructReturnUndefined):
+ (JSC::NullGetterFunction::getCallData):
+ (JSC::NullGetterFunction::getConstructData):
+ * runtime/NullGetterFunction.h: Added.
+ (JSC::NullGetterFunction::create):
+ (JSC::NullGetterFunction::createStructure):
+ (JSC::NullGetterFunction::NullGetterFunction):
+ New singleton class that returns undefined when called.
+
+2014-12-09 Geoffrey Garen <ggaren@apple.com>
+
+ Re-enable function.arguments
+ https://bugs.webkit.org/show_bug.cgi?id=139452
+ <rdar://problem/18848149>
+
+ Reviewed by Sam Weinig.
+
+ Disabling function.arguments broke a few websites, and we don't have
+ time right now to work through the details.
+
+ I'm re-enabling function.arguments but leaving in the infrastructure
+ to re-disable it, so we can try this experiment again in the future.
+
+ * runtime/Options.h:
+
+2014-12-09 David Kilzer <ddkilzer@apple.com>
+
+ Switch from using PLATFORM_NAME to SDK selectors in ANGLE, bmalloc, gtest, JavaScriptCore, WTF
+ <http://webkit.org/b/139212>
+
+ Reviewed by Joseph Pecoraro.
+
+ * Configurations/Base.xcconfig:
+ - Only set GCC_ENABLE_OBJC_GC, GCC_MODEL_TUNING and TOOLCHAINS
+ on OS X.
+ - Only set LLVM_LOCAL_HEADER_PATH and LLVM_SYSTEM_HEADER_PATH on
+ OS X.
+ - Set JAVASCRIPTCORE_CONTENTS_DIR and
+ JAVASCRIPTCORE_FRAMEWORKS_DIR separately for iOS and OS X.
+
+ * Configurations/DebugRelease.xcconfig:
+ - Only set MACOSX_DEPLOYMENT_TARGET and SDKROOT on OS X.
+
+ * Configurations/JSC.xcconfig:
+ - Only set CODE_SIGN_ENTITLEMENTS for iOS hardware builds.
+
+ * Configurations/JavaScriptCore.xcconfig:
+ - Set OTHER_LDFLAGS separately for iOS and OS X.
+ - Set SECTORDER_FLAGS separately for iOS and OS X, but only for
+ Production builds.
+ - Only set EXCLUDED_SOURCE_FILE_NAMES for iOS.
+
+ * Configurations/LLVMForJSC.xcconfig:
+ - Rename LLVM_LIBS_iphoneos to LLVM_LIBS_ios.
+ - Set LLVM_LIBRARY_PATHS and OTHER_LDFLAGS_LLVM_ENABLE_FTL_JIT
+ separately for iOS hardware and OS X.
+ - Fix curly braces in LIBRARY_SEARCH_PATHS.
+ - Merge OTHER_LDFLAGS_BASE into OTHER_LDFLAGS. (Could have been
+ done before this patch.)
+
+ * Configurations/ToolExecutable.xcconfig:
+ - Only set CODE_SIGN_ENTITLEMENTS for iOS, per target.
+ - Only set CLANG_ENABLE_OBJC_ARC for i386 on the iOS Simulator.
+ - Add missing newline.
+
+ * Configurations/Version.xcconfig:
+ - Set SYSTEM_VERSION_PREFIX separately for iOS and OS X.
+
+2014-12-08 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Fix EFL build fix since r177001
+ https://bugs.webkit.org/show_bug.cgi?id=139428
+
+ Unreviewed, EFL build fix.
+
+ Do not inherit duplicated class. ExpressionNode is already
+ child of ParserArenaFreeable class.
+
+ * parser/Nodes.h:
+
+2014-12-08 Shivakumar JM <shiva.jm@samsung.com>
+
+ Fix Build Warning in JavaScriptCore ControlFlowProfiler::dumpData() api.
+ https://bugs.webkit.org/show_bug.cgi?id=139384
+
+ Reviewed by Mark Lam.
+
+ Fix Build Warning by using dataLog() function instead of dataLogF() function.
+
+ * runtime/ControlFlowProfiler.cpp:
+ (JSC::ControlFlowProfiler::dumpData):
+
+2014-12-08 Saam Barati <saambarati1@gmail.com>
+
+ Web Inspector: Enable runtime API for JSC's control flow profiler
+ https://bugs.webkit.org/show_bug.cgi?id=139346
+
+ Reviewed by Joseph Pecoraro.
+
+ This patch creates an API that the Web Inspector can use
+ to get information about which basic blocks have exectued
+ from JSC's control flow profiler.
+
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::getBasicBlocks):
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * inspector/protocol/Runtime.json:
+
+2014-12-08 Geoffrey Garen <ggaren@apple.com>
+
+ Removed some allocation and cruft from the parser
+ https://bugs.webkit.org/show_bug.cgi?id=139416
+
+ Reviewed by Mark Lam.
+
+ Now, the only AST nodes that require a destructor are the ones that
+ relate to pickling a function's arguments -- which will required some
+ deeper thinking to resolve.
+
+ This is a < 1% parser speedup.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj: Removed NodeInfo because it
+ was unused.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::CommaNode::emitBytecode):
+ (JSC::SourceElements::lastStatement):
+ (JSC::SourceElements::emitBytecode): Updated for interface change to linked list.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::ASTBuilder):
+ (JSC::ASTBuilder::varDeclarations):
+ (JSC::ASTBuilder::funcDeclarations):
+ (JSC::ASTBuilder::createFuncDeclStatement):
+ (JSC::ASTBuilder::addVar): Removed the ParserArenaData abstraction because
+ it wasn't buying us anything. We can just use Vector directly.
+
+ (JSC::ASTBuilder::createCommaExpr):
+ (JSC::ASTBuilder::appendToCommaExpr): Changed to use a linked list instead
+ of a vector, to avoid allocating a vector with inline capacity in the
+ common case in which an expression is not followed by a vector.
+
+ (JSC::ASTBuilder::Scope::Scope): Use Vector directly to avoid new'ing
+ up a Vector*.
+
+ (JSC::ASTBuilder::appendToComma): Deleted.
+ (JSC::ASTBuilder::combineCommaNodes): Deleted.
+
+ * parser/Lexer.cpp:
+
+ * parser/NodeConstructors.h:
+ (JSC::StatementNode::StatementNode):
+ (JSC::CommaNode::CommaNode):
+ (JSC::SourceElements::SourceElements): Updated for interface change to linked list.
+
+ * parser/NodeInfo.h: Removed.
+
+ * parser/Nodes.cpp:
+ (JSC::SourceElements::append):
+ (JSC::SourceElements::singleStatement): Use a linked list instead of a
+ vector to track the statements in a list. This removes some allocation
+ and it means that we don't need a destructor anymore.
+
+ (JSC::ScopeNode::ScopeNode):
+ (JSC::ProgramNode::ProgramNode):
+ (JSC::EvalNode::EvalNode):
+ (JSC::FunctionNode::FunctionNode): Updated for interface change to reference,
+ since these values are never null.
+
+ * parser/Nodes.h:
+ (JSC::StatementNode::next):
+ (JSC::StatementNode::setNext):
+ (JSC::CommaNode::append): Deleted. Updated for interface change to linked list.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::didFinishParsing): Updated for interface change to reference.
+
+ (JSC::Parser<LexerType>::parseVarDeclarationList):
+ (JSC::Parser<LexerType>::parseExpression): Track comma expressions as
+ an explicit list of CommaNodes, removing a use of vector and a destructor.
+
+ * parser/Parser.h:
+ (JSC::Parser<LexerType>::parse):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createCommaExpr):
+ (JSC::SyntaxChecker::appendToCommaExpr):
+ (JSC::SyntaxChecker::appendToComma): Deleted. Updated for interface changes.
+
+2014-12-08 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r176979.
+ https://bugs.webkit.org/show_bug.cgi?id=139424
+
+ "New JSC test in this patch is failing" (Requested by mlam on
+ #webkit).
+
+ Reverted changeset:
+
+ "Fixes operationPutByIds such that they check that the put
+ didn't"
+ https://bugs.webkit.org/show_bug.cgi?id=139196
+ http://trac.webkit.org/changeset/176979
+
+2014-12-08 Matthew Mirman <mmirman@apple.com>
+
+ Fixes operationPutByIds such that they check that the put didn't
+ change the structure of the object who's property access is being
+ cached.
+ https://bugs.webkit.org/show_bug.cgi?id=139196
+
+ Reviewed by Filip Pizlo.
+
+ * jit/JITOperations.cpp:
+ (JSC::operationGetByIdOptimize): changed get to getPropertySlot
+ (JSC::operationPutByIdStrictBuildList): saved the structure before the put.
+ (JSC::operationPutByIdNonStrictBuildList): ditto.
+ (JSC::operationPutByIdDirectStrictBuildList): ditto.
+ (JSC::operationPutByIdDirectNonStrictBuildList): ditto.
+ * jit/Repatch.cpp:
+ (JSC::tryCachePutByID): fixed structure() to use the existant vm.
+ (JSC::tryBuildPutByIdList): Added a check that the old structure's id
+ is the same as the new.
+ (JSC::buildPutByIdList): Added an argument
+ * jit/Repatch.h:
+ (JSC::buildPutByIdList): Added an argument
+ * tests/stress/put-by-id-build-list-order-recurse.js: Test that failed before the change
+ * tests/stress/put-by-id-strict-build-list-order.js: Added.
+
+
+2014-12-08 Anders Carlsson <andersca@apple.com>
+
+ Change WTF::currentCPUTime to return std::chrono::microseconds and get rid of currentCPUTimeMS
+ https://bugs.webkit.org/show_bug.cgi?id=139410
+
+ Reviewed by Andreas Kling.
+
+ * API/JSContextRef.cpp:
+ (JSContextGroupSetExecutionTimeLimit):
+ (JSContextGroupClearExecutionTimeLimit):
+ * runtime/Watchdog.cpp:
+ (JSC::Watchdog::setTimeLimit):
+ (JSC::Watchdog::didFire):
+ (JSC::Watchdog::startCountdownIfNeeded):
+ (JSC::Watchdog::startCountdown):
+ * runtime/Watchdog.h:
+ * runtime/WatchdogMac.cpp:
+ (JSC::Watchdog::startTimer):
+
+2014-12-08 Mark Lam <mark.lam@apple.com>
+
+ CFA wrongly assumes that a speculation for SlowPutArrayStorageShape disallows ArrayStorageShape arrays.
+ <https://webkit.org/b/139327>
+
+ Reviewed by Michael Saboff.
+
+ The code generator and runtime slow paths expects otherwise. This patch fixes
+ CFA to match the code generator's expectation.
+
+ * dfg/DFGArrayMode.h:
+ (JSC::DFG::ArrayMode::arrayModesThatPassFiltering):
+ (JSC::DFG::ArrayMode::arrayModesWithIndexingShapes):
+
+2014-12-08 Chris Dumez <cdumez@apple.com>
+
+ Revert r176293 & r176275
+
+ Unreviewed, revert r176293 & r176275 changing the Vector API to use unsigned type
+ instead of size_t. There is some disagreement regarding the long-term direction
+ of the API and we shouldn’t leave the API partly transitioned to unsigned type
+ while making a decision.
+
+ * bytecode/PreciseJumpTargets.cpp:
+ * replay/EncodedValue.h:
+
+2014-12-07 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove the unused WTF_USE_GCC_COMPUTED_GOTO_WORKAROUND after r129453.
+ https://bugs.webkit.org/show_bug.cgi?id=139373
+
+ Reviewed by Sam Weinig.
+
+ * interpreter/Interpreter.cpp:
+
+2014-12-06 Anders Carlsson <andersca@apple.com>
+
+ Fix build with newer versions of clang.
+ rdar://problem/18978716
+
+ * ftl/FTLJITCode.h:
+ Add missing overrides.
+
+2014-12-05 Roger Fong <roger_fong@apple.com>
+
+ [Win] proj files copying over too many resources..
+ https://bugs.webkit.org/show_bug.cgi?id=139315.
+ <rdar://problem/19148278>
+
+ Reviewed by Brent Fulgham.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.proj: Only copy resource folders and JavaScriptCore.dll.
+
+2014-12-05 Juergen Ributzka <juergen@apple.com>
+
+ [JSC][FTL] Add the data layout to the module and fix the pass order.
+ https://bugs.webkit.org/show_bug.cgi?id=138748
+
+ Reviewed by Oliver Hunt.
+
+ This adds the data layout to the module, so it can be used by all
+ optimization passes in the LLVM optimizer pipeline. This also allows
+ FastISel to select more instructions, because less non-legal types are
+ generated.
+
+ Also fix the order of the alias analysis passes in the optimization
+ pipeline.
+
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+
+2014-12-05 Geoffrey Garen <ggaren@apple.com>
+
+ Removed an unused function.
+
+ Reviewed by Michael Saboff.
+
+ Broken out from https://bugs.webkit.org/show_bug.cgi?id=139305.
+
+ * parser/ParserArena.h:
+
+2014-12-05 David Kilzer <ddkilzer@apple.com>
+
+ FeatureDefines.xcconfig: Workaround bug in Xcode 5.1.1 when defining ENABLE_WEB_REPLAY
+ <http://webkit.org/b/139286>
+
+ Reviewed by Daniel Bates.
+
+ * Configurations/FeatureDefines.xcconfig: Switch back to using
+ PLATFORM_NAME to workaround a bug in Xcode 5.1.1 on 10.8.
+
+2014-12-04 Mark Rowe <mrowe@apple.com>
+
+ Build fix after r176836.
+
+ Reviewed by Mark Lam.
+
+ * runtime/VM.h:
+ (JSC::VM::controlFlowProfiler): Don't try to export an inline function.
+ Doing so results in a weak external symbol being generated.
+
+2014-12-04 Saam Barati <saambarati1@gmail.com>
+
+ JavaScript Control Flow Profiler
+ https://bugs.webkit.org/show_bug.cgi?id=137785
+
+ Reviewed by Filip Pizlo.
+
+ This patch introduces a mechanism for JavaScriptCore to profile
+ which basic blocks have executed. This mechanism will then be
+ used by the Web Inspector to indicate which basic blocks
+ have and have not executed.
+
+ The profiling works by compiling in an op_profile_control_flow
+ at the start of every basic block. Then, whenever this op code
+ executes, we know that a particular basic block has executed.
+
+ When we tier up a CodeBlock that contains an op_profile_control_flow
+ that corresponds to an already executed basic block, we don't
+ have to emit code for that particular op_profile_control_flow
+ because the internal data structures used to keep track of
+ basic block locations has already recorded that the corresponding
+ op_profile_control_flow has executed.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ (JSC::CodeBlock::CodeBlock):
+ * bytecode/Instruction.h:
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::addOpProfileControlFlowBytecodeOffset):
+ (JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitProfileControlFlow):
+ * bytecompiler/BytecodeGenerator.h:
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ConditionalNode::emitBytecode):
+ (JSC::IfElseNode::emitBytecode):
+ (JSC::WhileNode::emitBytecode):
+ (JSC::ForNode::emitBytecode):
+ (JSC::ContinueNode::emitBytecode):
+ (JSC::BreakNode::emitBytecode):
+ (JSC::ReturnNode::emitBytecode):
+ (JSC::CaseClauseNode::emitBytecode):
+ (JSC::SwitchNode::emitBytecode):
+ (JSC::ThrowNode::emitBytecode):
+ (JSC::TryNode::emitBytecode):
+ (JSC::ProgramNode::emitBytecode):
+ (JSC::FunctionNode::emitBytecode):
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::basicBlockLocation):
+ * 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):
+ * inspector/agents/InspectorRuntimeAgent.cpp:
+ (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_profile_control_flow):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_profile_control_flow):
+ * jsc.cpp:
+ (GlobalObject::finishCreation):
+ (functionFindTypeForExpression):
+ (functionReturnTypeFor):
+ (functionDumpBasicBlockExecutionRanges):
+ * llint/LowLevelInterpreter.asm:
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createFunctionExpr):
+ (JSC::ASTBuilder::createGetterOrSetterProperty):
+ (JSC::ASTBuilder::createFuncDeclStatement):
+ (JSC::ASTBuilder::endOffset):
+ (JSC::ASTBuilder::setStartOffset):
+ * parser/NodeConstructors.h:
+ (JSC::Node::Node):
+ * parser/Nodes.h:
+ (JSC::CaseClauseNode::setStartOffset):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseSwitchClauses):
+ (JSC::Parser<LexerType>::parseSwitchDefaultClause):
+ (JSC::Parser<LexerType>::parseBlockStatement):
+ (JSC::Parser<LexerType>::parseStatement):
+ (JSC::Parser<LexerType>::parseFunctionDeclaration):
+ (JSC::Parser<LexerType>::parseIfStatement):
+ (JSC::Parser<LexerType>::parseExpression):
+ (JSC::Parser<LexerType>::parseConditionalExpression):
+ (JSC::Parser<LexerType>::parseProperty):
+ (JSC::Parser<LexerType>::parseMemberExpression):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createFunctionExpr):
+ (JSC::SyntaxChecker::createFuncDeclStatement):
+ (JSC::SyntaxChecker::createGetterOrSetterProperty):
+ (JSC::SyntaxChecker::operatorStackPop):
+ * runtime/BasicBlockLocation.cpp: Added.
+ (JSC::BasicBlockLocation::BasicBlockLocation):
+ (JSC::BasicBlockLocation::insertGap):
+ (JSC::BasicBlockLocation::getExecutedRanges):
+ (JSC::BasicBlockLocation::dumpData):
+ (JSC::BasicBlockLocation::emitExecuteCode):
+ * runtime/BasicBlockLocation.h: Added.
+ (JSC::BasicBlockLocation::startOffset):
+ (JSC::BasicBlockLocation::endOffset):
+ (JSC::BasicBlockLocation::setStartOffset):
+ (JSC::BasicBlockLocation::setEndOffset):
+ (JSC::BasicBlockLocation::hasExecuted):
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ * runtime/ControlFlowProfiler.cpp: Added.
+ (JSC::ControlFlowProfiler::~ControlFlowProfiler):
+ (JSC::ControlFlowProfiler::getBasicBlockLocation):
+ (JSC::ControlFlowProfiler::dumpData):
+ (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
+ * runtime/ControlFlowProfiler.h: Added. This class is in
+ charge of generating BasicBlockLocations and also
+ providing an interface that the Web Inspector can use to ping
+ which basic blocks have executed based on the source id of a script.
+
+ (JSC::BasicBlockKey::BasicBlockKey):
+ (JSC::BasicBlockKey::isHashTableDeletedValue):
+ (JSC::BasicBlockKey::operator==):
+ (JSC::BasicBlockKey::hash):
+ (JSC::BasicBlockKeyHash::hash):
+ (JSC::BasicBlockKeyHash::equal):
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::ProgramExecutable):
+ (JSC::ProgramExecutable::initializeGlobalProperties):
+ * runtime/FunctionHasExecutedCache.cpp:
+ (JSC::FunctionHasExecutedCache::getUnexecutedFunctionRanges):
+ * runtime/FunctionHasExecutedCache.h:
+ * runtime/Options.h:
+ * runtime/TypeProfiler.cpp:
+ (JSC::TypeProfiler::logTypesForTypeLocation):
+ (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
+ (JSC::TypeProfiler::findLocation):
+ (JSC::TypeProfiler::dumpTypeProfilerData):
+ * runtime/TypeProfiler.h:
+ (JSC::TypeProfiler::functionHasExecutedCache): Deleted.
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ (JSC::enableProfilerWithRespectToCount):
+ (JSC::disableProfilerWithRespectToCount):
+ (JSC::VM::enableTypeProfiler):
+ (JSC::VM::disableTypeProfiler):
+ (JSC::VM::enableControlFlowProfiler):
+ (JSC::VM::disableControlFlowProfiler):
+ (JSC::VM::dumpTypeProfilerData):
+ * runtime/VM.h:
+ (JSC::VM::functionHasExecutedCache):
+ (JSC::VM::controlFlowProfiler):
+
+2014-12-04 Filip Pizlo <fpizlo@apple.com>
+
+ printInternal(PrintStream& out, JSC::JITCode::JITType type) ends up dumping a literal %s
+ https://bugs.webkit.org/show_bug.cgi?id=139274
+
+ Reviewed by Geoffrey Garen.
+
+ * jit/JITCode.cpp:
+ (WTF::printInternal):
+
+2014-12-04 Geoffrey Garen <ggaren@apple.com>
+
+ Removed the concept of ParserArenaRefCounted
+ https://bugs.webkit.org/show_bug.cgi?id=139277
+
+ Reviewed by Oliver Hunt.
+
+ This is a step toward a parser speedup.
+
+ Now that we have a clear root node type for each parse tree, there's no
+ need to have a concept for "I might be refcounted or arena allocated".
+ Instead, we can just use unique_ptr to manage the tree as a whole.
+
+ * API/JSScriptRef.cpp:
+ (parseScript):
+ * builtins/BuiltinExecutables.cpp:
+ (JSC::BuiltinExecutables::createBuiltinExecutable): Updated for type change.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock): Use unique_ptr. No need to call
+ destroyData() explicitly: the unique_ptr destructor will do everything
+ we need, as Bjarne intended.
+
+ * parser/NodeConstructors.h:
+ (JSC::ParserArenaRoot::ParserArenaRoot):
+ (JSC::ParserArenaRefCounted::ParserArenaRefCounted): Deleted.
+
+ * parser/Nodes.cpp:
+ (JSC::ScopeNode::ScopeNode):
+ (JSC::ProgramNode::ProgramNode):
+ (JSC::EvalNode::EvalNode):
+ (JSC::FunctionNode::FunctionNode):
+ (JSC::ProgramNode::create): Deleted.
+ (JSC::EvalNode::create): Deleted.
+ (JSC::FunctionNode::create): Deleted. All special create semantics can
+ just go away now that we play by C++ constructor / destructor rules.
+
+ * parser/Nodes.h:
+ (JSC::ParserArenaRoot::parserArena):
+ (JSC::ParserArenaRoot::~ParserArenaRoot): Just a normal class now, which
+ holds onto the whole parse tree by virtue of owning the arena in which
+ all the parsed nodes (except for itself) were allocated.
+
+ (JSC::ProgramNode::closedVariables):
+ (JSC::ParserArenaRefCounted::~ParserArenaRefCounted): Deleted.
+
+ (JSC::ScopeNode::destroyData): Deleted. No need to destroy anything
+ explicitly anymore -- we can just rely on destructors.
+
+ (JSC::ScopeNode::parserArena): Deleted.
+
+ * parser/Parser.h:
+ (JSC::Parser<LexerType>::parse):
+ (JSC::parse): unique_ptr all the things.
+
+ * parser/ParserArena.cpp:
+ (JSC::ParserArena::reset):
+ (JSC::ParserArena::isEmpty):
+ (JSC::ParserArena::contains): Deleted.
+ (JSC::ParserArena::last): Deleted.
+ (JSC::ParserArena::removeLast): Deleted.
+ (JSC::ParserArena::derefWithArena): Deleted.
+ * parser/ParserArena.h:
+ (JSC::ParserArena::swap): Much delete. Such wow.
+
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
+ * runtime/Completion.cpp:
+ (JSC::checkSyntax):
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::checkSyntax): unique_ptr all the things.
+
+2014-12-04 Andreas Kling <akling@apple.com>
+
+ REGRESSION(r173188): Text inserted when trying to delete a word from the Twitter message box.
+ <https://webkit.org/b/139076>
+
+ Reviewed by Geoffrey Garen.
+
+ The StringImpl* -> Weak<JSString> cache used by the DOM bindings
+ had a bug where the key could become a stale pointer if the cached
+ JSString had its internal StringImpl atomicized.
+
+ If a new StringImpl was then later constructed at the exact same
+ address as the stale key, before the Weak<JSString> got booted out
+ of the string cache, we'd now have a situation where asking the
+ string cache for that key would return the old JSString.
+
+ Solve this by not allowing JSString::toExistingAtomicString() to
+ change the JSString's internal StringImpl unless it's resolving a
+ rope string. (The StringImpl nullity determines rope state.)
+
+ This means that calling toExistingAtomicString() may now have to
+ query the AtomicString table on each call rather than just once.
+ All clients of this API would be forced to do this regardless,
+ since they return value will be used to key into containers with
+ AtomicStringImpl* keys.
+
+ No test because this relies on malloc putting two StringImpls
+ at the same address at different points in time and we have no
+ mechanism to reliably test that.
+
+ * runtime/JSString.h:
+ (JSC::JSString::toExistingAtomicString):
+
+2014-12-04 Geoffrey Garen <ggaren@apple.com>
+
+ Marked some final things final.
+
+ Reviewed by Andreas Kling.
+
+ * parser/Nodes.h:
+
+2014-12-04 Geoffrey Garen <ggaren@apple.com>
+
+ Split out FunctionNode from FunctionBodyNode
+ https://bugs.webkit.org/show_bug.cgi?id=139273
+
+ Reviewed by Andreas Kling.
+
+ This is step toward a parser speedup.
+
+ We used to use FunctionBodyNode for two different purposes:
+
+ (1) "I am the root function you are currently parsing";
+
+ (2) "I am a lazy record of a nested function, which you will parse later".
+
+ This made for awkward lifetime semantics and interfaces.
+
+ Now, case (1) is handled by FunctionBodyNode, and case (2) is handled by
+ a new node named FunctionNode.
+
+ Since case (1) no longer needs to handle being the root of the parse
+ tree, FunctionBodyNode can be a normal arena-allocated node.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::generateFunctionCodeBlock): Use FunctionNode instead of
+ FunctionBodyNode, since we are producing the root of the function parse
+ tree.
+
+ (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): Removed
+ some unused data, and default-initialized other data, which isn't filled
+ in meaningfully until recordParse() is called. (The previous values were
+ incorrect / meaningless, since the FunctionBodyNode didn't have
+ meaningful values in this case.)
+
+ * bytecode/UnlinkedCodeBlock.h: Ditto.
+
+ (JSC::UnlinkedFunctionExecutable::forceUsesArguments): Deleted.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator): Use FunctionNode instead of
+ FunctionBodyNode, since we are generating code starting at the root of
+ the parse tree.
+
+ (JSC::BytecodeGenerator::resolveCallee):
+ (JSC::BytecodeGenerator::addCallee):
+ * bytecompiler/BytecodeGenerator.h: Ditto.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::FunctionBodyNode::emitBytecode):
+ (JSC::FunctionNode::emitBytecode): Moved the emitBytecode implementation
+ to FunctionNode, since we never generate code for FunctionBodyNode,
+ since it's just a placeholder in the AST.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createFunctionBody):
+ (JSC::ASTBuilder::setUsesArguments): Deleted. Updated for interface
+ changes.
+
+ * parser/Nodes.cpp:
+ (JSC::FunctionBodyNode::FunctionBodyNode):
+ (JSC::FunctionBodyNode::finishParsing):
+ (JSC::FunctionBodyNode::setEndPosition):
+ (JSC::FunctionNode::FunctionNode):
+ (JSC::FunctionNode::create):
+ (JSC::FunctionNode::finishParsing):
+ (JSC::FunctionBodyNode::create): Deleted.
+
+ * parser/Nodes.h:
+ (JSC::FunctionBodyNode::parameters):
+ (JSC::FunctionBodyNode::source):
+ (JSC::FunctionBodyNode::startStartOffset):
+ (JSC::FunctionBodyNode::isInStrictContext):
+ (JSC::FunctionNode::parameters):
+ (JSC::FunctionNode::ident):
+ (JSC::FunctionNode::functionMode):
+ (JSC::FunctionNode::startColumn):
+ (JSC::FunctionNode::endColumn):
+ (JSC::ScopeNode::setSource): Deleted.
+ (JSC::FunctionBodyNode::parameterCount): Deleted. Split out the differences
+ between FunctionNode and FunctionBodyNode.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createClauseList):
+ (JSC::SyntaxChecker::setUsesArguments): Deleted. Removed setUsesArguments
+ since it wasn't used.
+
+ * runtime/Executable.cpp:
+ (JSC::ProgramExecutable::checkSyntax): Removed a branch that was always
+ false.
+
+2014-12-02 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: timeline probe records have inaccurate per-probe hit counts
+ https://bugs.webkit.org/show_bug.cgi?id=138976
+
+ Reviewed by Joseph Pecoraro.
+
+ Previously, the DebuggerAgent was responsible for assigning unique ids to samples.
+ However, this makes it impossible for the frontend's Timeline manager to associate
+ a Probe Sample timeline record with the corresponding probe sample data. The record
+ only included the probe batchId (misnamed as hitCount in ScriptDebugServer).
+
+ This patch moves both the batchId and sampleId counters into ScriptDebugServer, so
+ any client of ScriptDebugListener will get the correct sampleId for each sample.
+
+ * inspector/ScriptDebugListener.h:
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::ScriptDebugServer):
+ (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
+ (Inspector::ScriptDebugServer::handleBreakpointHit):
+ * inspector/ScriptDebugServer.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
+ (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
+ * inspector/agents/InspectorDebuggerAgent.h:
+
+2014-12-04 Oliver Hunt <oliver@apple.com>
+
+ 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-12-03 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Move JavaScriptCore/dfg to std::unique_ptr
+ https://bugs.webkit.org/show_bug.cgi?id=139169
+
+ Reviewed by Filip Pizlo.
+
+ Use std::unique_ptr<>|std::make_unique<> in JavaScriptCore/dfg directory.
+
+ * dfg/DFGBasicBlock.h:
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::JITCompiler):
+ (JSC::DFG::JITCompiler::compile):
+ (JSC::DFG::JITCompiler::link):
+ (JSC::DFG::JITCompiler::compileFunction):
+ (JSC::DFG::JITCompiler::linkFunction):
+ * dfg/DFGJITCompiler.h:
+ * dfg/DFGPlan.cpp:
+ (JSC::DFG::Plan::compileInThreadImpl):
+ (JSC::DFG::Plan::cancel):
+ * dfg/DFGPlan.h:
+ * dfg/DFGSlowPathGenerator.h:
+ * dfg/DFGWorklist.h:
+ * ftl/FTLFail.cpp:
+ (JSC::FTL::fail):
+ * ftl/FTLState.cpp:
+ (JSC::FTL::State::State):
+
+2014-12-03 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (r176479): DFG ASSERTION beneath emitOSRExitCall running Kraken/imaging-gaussian-blur.js.ftl-no-cjit-osr-validation and other tests
+ https://bugs.webkit.org/show_bug.cgi?id=139246
+
+ Reviewed by Geoffrey Garen.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
+ The DFG_ASSERT that checks liveness at exit time doesn't properly
+ handle the case where the local is not available at OSR exit time,
+ but the local is live in the bytecode. This now happens with the
+ allocated scope register when we are compiling for FTLForOSREntryMode
+ due to DCE done when the control flow was changed and a new entrypoint
+ was added in the OSR entrypoint creation phase. Therefore we silence
+ the assert when compiling for FTLForOSREntryMode.
+
+2014-12-03 Geoffrey Garen <ggaren@apple.com>
+
+ Removed the global parser arena
+ https://bugs.webkit.org/show_bug.cgi?id=139236
+
+ Reviewed by Sam Weinig.
+
+ Simplifies parser lifetime logic.
+
+ There's no need to keep a global arena. We can create a new arena
+ each time we parse.
+
+ * bytecompiler/BytecodeGenerator.h: Global replace to pass around a
+ ParserArena instead of VM*, since the VM no longer owns the arena.
+ (JSC::BytecodeGenerator::parserArena):
+
+ * bytecompiler/NodesCodegen.cpp: Ditto.
+ (JSC::ArrayNode::toArgumentList):
+ (JSC::ApplyFunctionCallDotNode::emitBytecode):
+ * parser/ASTBuilder.h: Ditto.
+ (JSC::ASTBuilder::ASTBuilder):
+ (JSC::ASTBuilder::createSourceElements):
+ (JSC::ASTBuilder::createCommaExpr):
+ (JSC::ASTBuilder::createLogicalNot):
+ (JSC::ASTBuilder::createUnaryPlus):
+ (JSC::ASTBuilder::createVoid):
+ (JSC::ASTBuilder::thisExpr):
+ (JSC::ASTBuilder::createResolve):
+ (JSC::ASTBuilder::createObjectLiteral):
+ (JSC::ASTBuilder::createArray):
+ (JSC::ASTBuilder::createNumberExpr):
+ (JSC::ASTBuilder::createString):
+ (JSC::ASTBuilder::createBoolean):
+ (JSC::ASTBuilder::createNull):
+ (JSC::ASTBuilder::createBracketAccess):
+ (JSC::ASTBuilder::createDotAccess):
+ (JSC::ASTBuilder::createSpreadExpression):
+ (JSC::ASTBuilder::createRegExp):
+ (JSC::ASTBuilder::createNewExpr):
+ (JSC::ASTBuilder::createConditionalExpr):
+ (JSC::ASTBuilder::createAssignResolve):
+ (JSC::ASTBuilder::createFunctionExpr):
+ (JSC::ASTBuilder::createFunctionBody):
+ (JSC::ASTBuilder::createGetterOrSetterProperty):
+ (JSC::ASTBuilder::createArguments):
+ (JSC::ASTBuilder::createArgumentsList):
+ (JSC::ASTBuilder::createProperty):
+ (JSC::ASTBuilder::createPropertyList):
+ (JSC::ASTBuilder::createElementList):
+ (JSC::ASTBuilder::createFormalParameterList):
+ (JSC::ASTBuilder::createClause):
+ (JSC::ASTBuilder::createClauseList):
+ (JSC::ASTBuilder::createFuncDeclStatement):
+ (JSC::ASTBuilder::createBlockStatement):
+ (JSC::ASTBuilder::createExprStatement):
+ (JSC::ASTBuilder::createIfStatement):
+ (JSC::ASTBuilder::createForLoop):
+ (JSC::ASTBuilder::createForInLoop):
+ (JSC::ASTBuilder::createForOfLoop):
+ (JSC::ASTBuilder::createEmptyStatement):
+ (JSC::ASTBuilder::createVarStatement):
+ (JSC::ASTBuilder::createEmptyVarExpression):
+ (JSC::ASTBuilder::createReturnStatement):
+ (JSC::ASTBuilder::createBreakStatement):
+ (JSC::ASTBuilder::createContinueStatement):
+ (JSC::ASTBuilder::createTryStatement):
+ (JSC::ASTBuilder::createSwitchStatement):
+ (JSC::ASTBuilder::createWhileStatement):
+ (JSC::ASTBuilder::createDoWhileStatement):
+ (JSC::ASTBuilder::createLabelStatement):
+ (JSC::ASTBuilder::createWithStatement):
+ (JSC::ASTBuilder::createThrowStatement):
+ (JSC::ASTBuilder::createDebugger):
+ (JSC::ASTBuilder::createConstStatement):
+ (JSC::ASTBuilder::appendConstDecl):
+ (JSC::ASTBuilder::combineCommaNodes):
+ (JSC::ASTBuilder::createDeconstructingAssignment):
+ (JSC::ASTBuilder::Scope::Scope):
+ (JSC::ASTBuilder::createNumber):
+ (JSC::ASTBuilder::makeTypeOfNode):
+ (JSC::ASTBuilder::makeDeleteNode):
+ (JSC::ASTBuilder::makeNegateNode):
+ (JSC::ASTBuilder::makeBitwiseNotNode):
+ (JSC::ASTBuilder::makeMultNode):
+ (JSC::ASTBuilder::makeDivNode):
+ (JSC::ASTBuilder::makeModNode):
+ (JSC::ASTBuilder::makeAddNode):
+ (JSC::ASTBuilder::makeSubNode):
+ (JSC::ASTBuilder::makeLeftShiftNode):
+ (JSC::ASTBuilder::makeRightShiftNode):
+ (JSC::ASTBuilder::makeURightShiftNode):
+ (JSC::ASTBuilder::makeBitOrNode):
+ (JSC::ASTBuilder::makeBitAndNode):
+ (JSC::ASTBuilder::makeBitXOrNode):
+ (JSC::ASTBuilder::makeFunctionCallNode):
+ (JSC::ASTBuilder::makeBinaryNode):
+ (JSC::ASTBuilder::makeAssignNode):
+ (JSC::ASTBuilder::makePrefixNode):
+ (JSC::ASTBuilder::makePostfixNode):
+
+ * parser/NodeConstructors.h: Ditto.
+ (JSC::ParserArenaFreeable::operator new):
+ (JSC::ParserArenaDeletable::operator new):
+ (JSC::ParserArenaRefCounted::ParserArenaRefCounted):
+
+ * parser/Nodes.cpp: Ditto.
+ (JSC::ScopeNode::ScopeNode):
+ (JSC::ProgramNode::ProgramNode):
+ (JSC::ProgramNode::create):
+ (JSC::EvalNode::EvalNode):
+ (JSC::EvalNode::create):
+ (JSC::FunctionBodyNode::FunctionBodyNode):
+ (JSC::FunctionBodyNode::create):
+
+ * parser/Nodes.h: Ditto.
+ (JSC::ScopeNode::parserArena):
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::Parser):
+ (JSC::Parser<LexerType>::parseInner):
+ (JSC::Parser<LexerType>::parseProperty): The parser now owns its own
+ arena, and transfers ownership of its contents when invoking the ScopeNode
+ constructor.
+
+ * parser/Parser.h:
+ (JSC::Parser<LexerType>::parse): No need to explicitly reset the arena,
+ since its lifetime is tied to the parser's lifetime now.
+
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createProperty):
+ (JSC::SyntaxChecker::createGetterOrSetterProperty):
+
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h: The point of the patch: no more global.
+
+2014-12-03 Geoffrey Garen <ggaren@apple.com>
+
+ The parser should allocate all pieces of the AST
+ https://bugs.webkit.org/show_bug.cgi?id=139230
+
+ Reviewed by Oliver Hunt.
+
+ This is a step toward a 14% parsing speedup.
+
+ Previously, allocation was split between the parser and certain node
+ constructor functions. This made for some duplicated code and circular
+ dependencies.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::createGetterOrSetterProperty): No need to pass through
+ the VM, since our callee no longer needs to allocate anything.
+
+ (JSC::ASTBuilder::createProperty): Allocate the identifier for our
+ callee, since that is simpler than requiring our callee to notice that
+ we didn't do so, and do it for us.
+
+ (JSC::ASTBuilder::createForInLoop): Allocate the DeconstructingAssignmentNode
+ for our callee, since that is simpler than requiring our callee to notice
+ that we didn't do so, and do it for us.
+
+ Also, reuse some code instead of duplicating it.
+
+ (JSC::ASTBuilder::createForOfLoop): Ditto.
+
+ (JSC::ASTBuilder::createArrayPattern):
+ (JSC::ASTBuilder::createObjectPattern):
+ (JSC::ASTBuilder::createBindingLocation): No need to pass through a VM
+ pointer, since our callee no longer needs to allocate anything.
+
+ (JSC::ASTBuilder::createBreakStatement): Deleted.
+ (JSC::ASTBuilder::createContinueStatement): Deleted.
+
+ * parser/NodeConstructors.h:
+ (JSC::PropertyNode::PropertyNode):
+ (JSC::DeconstructionPatternNode::DeconstructionPatternNode):
+ (JSC::ArrayPatternNode::ArrayPatternNode):
+ (JSC::ArrayPatternNode::create):
+ (JSC::ObjectPatternNode::ObjectPatternNode):
+ (JSC::ObjectPatternNode::create):
+ (JSC::BindingNode::create):
+ (JSC::BindingNode::BindingNode):
+ (JSC::ContinueNode::ContinueNode): Deleted.
+ (JSC::BreakNode::BreakNode): Deleted.
+ (JSC::EnumerationNode::EnumerationNode): Deleted.
+ (JSC::ForInNode::ForInNode): Deleted.
+ (JSC::ForOfNode::ForOfNode): Deleted. Deleted a bunch of special cases
+ that don't exist anymore, now that the parser allocates all pieces of
+ the AST unconditionally.
+
+ * parser/Nodes.h: Ditto.
+
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseBreakStatement):
+ (JSC::Parser<LexerType>::parseContinueStatement): Allocate the null
+ identifier for our callee, since that is simpler than requiring our
+ callee to notice that we didn't do so, and do it for us.
+
+ (JSC::Parser<LexerType>::parseProperty):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::createProperty): No need to pass through a VM
+ pointer, since our callee no longer needs to allocate anything.
+
+2014-12-03 Zsolt Borbely <zsborbely.u-szeged@partner.samsung.com>
+
+ Remove unused JSC runtime options
+ https://bugs.webkit.org/show_bug.cgi?id=133070
+
+ Reviewed by Csaba Osztrogonác.
+
+ * runtime/Options.h:
+
+2014-12-02 Mark Lam <mark.lam@apple.com>
+
+ Rolling out r176592, r176603, r176616, and r176705 until build and perf issues are resolved.
+ https://bugs.webkit.org/show_bug.cgi?id=138821
+
+ Not reviewed.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::visitChildren):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitComplexPopScopes):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
+ * ftl/FTLAbbreviations.h:
+ (JSC::FTL::mdNode):
+ (JSC::FTL::buildCall):
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * parser/Parser.h:
+ (JSC::Scope::Scope):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::setLengthWithArrayStorage):
+ (JSC::JSArray::sortCompactedVector):
+ * tools/ProfileTreeNode.h:
+ (JSC::ProfileTreeNode::dumpInternal):
+ * yarr/YarrJIT.cpp:
+ (JSC::Yarr::YarrGenerator::matchCharacterClass):
+
+2014-12-02 Michael Saboff <msaboff@apple.com>
+
+ Change CallFrame::globalThisValue() to not use CallFrame::scope()
+ https://bugs.webkit.org/show_bug.cgi?id=139202
+
+ Reviewed by Mark Lam.
+
+ Changed to use the globalThis() on the globalObject associated with the
+ callee. Moved the inline definition to JSGlobalObject.h instead of
+ including JSGlobalObject.h in JSScope.h. Also moved it as JSScope
+ objects are no longer involved in getting the value.
+
+ * runtime/JSGlobalObject.h:
+ (JSC::ExecState::globalThisValue):
+ * runtime/JSScope.h:
+ (JSC::ExecState::globalThisValue): Deleted.
+
+2014-12-02 Matthew Mirman <mmirman@apple.com>
+
+ Fixes inline cache fast path accessing nonexistant getters.
+ <rdar://problem/18416918>
+ https://bugs.webkit.org/show_bug.cgi?id=136961
+
+ Reviewed by Filip Pizlo.
+
+ Fixes a bug in inline caching where getters would have been able to
+ modify the property they are getting during
+ building the inline cache and then accessing that
+ property through the inline cache site causing a recursive
+ inline cache building and allowing the fast path of the cache to
+ try to load a getter for the property that no longer exists.
+
+ * jit/JITOperations.cpp: Switched use of get to getPropertySlot.
+ * runtime/JSCJSValue.h:
+ added getPropertySlot for when you don't want to perform the get quite yet but want
+ to fill out the slot.
+ * runtime/JSCJSValueInlines.h: Added implementation for getPropertySlot
+ (JSC::JSValue::get): changed to simply call getPropertySlot
+ (JSC::JSValue::getPropertySlot): added.
+ * tests/stress/recursive_property_redefine_during_inline_caching.js: Added test case for bug.
+ (test):
+
+2014-12-01 Michael Saboff <msaboff@apple.com>
+
+ Remove GetMyScope node from DFG
+ https://bugs.webkit.org/show_bug.cgi?id=139166
+
+ Reviewed by Oliver Hunt.
+
+ Eliminated GetMyScope DFG node type.
+
+ * dfg/DFGAbstractInterpreterInlines.h:
+ (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
+ * dfg/DFGClobberize.h:
+ (JSC::DFG::clobberize):
+ * dfg/DFGDoesGC.cpp:
+ (JSC::DFG::doesGC):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGGraph.cpp:
+ (JSC::DFG::Graph::isLiveInBytecode):
+ * 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):
+ * ftl/FTLCapabilities.cpp:
+ (JSC::FTL::canCompile):
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileNode):
+ (JSC::FTL::LowerDFGToLLVM::compileGetMyScope): Deleted.
+
+2014-12-01 Michael Saboff <msaboff@apple.com>
+
+ Crash (integer overflow) beneath ByteCodeParser::handleGetById typing in search field on weather.com
+ https://bugs.webkit.org/show_bug.cgi?id=139165
+
+ Reviewed by Oliver Hunt.
+
+ If we don't have any getById or putById variants, emit non-cached versions of these operations.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::handleGetById):
+ (JSC::DFG::ByteCodeParser::handlePutById):
+
+2014-12-01 Andreas Kling <akling@apple.com>
+
+ Optimize constructing JSC::Identifier from AtomicString.
+ <https://webkit.org/b/139157>
+
+ Reviewed by Michael Saboff.
+
+ Add constructors for Identifier taking AtomicString and AtomicStringImpl.
+ This avoids branching on the string's isAtomic flag, which is obviously
+ always true for AtomicString & AtomicStringImpl.
+
+ Had to add a Identifier(const char*) constructor to resolve implicit
+ ambiguity between String / AtomicString.
+
+ Also made PrivateName::uid() return AtomicStringImpl* to take advantage
+ of the new constructor in a few places.
+
+ * runtime/Identifier.h:
+ (JSC::Identifier::Identifier):
+ * runtime/IdentifierInlines.h:
+ (JSC::Identifier::Identifier):
+ * runtime/PrivateName.h:
+ (JSC::PrivateName::uid):
+
+2014-12-01 Alexey Proskuryakov <ap@apple.com>
+
+ Several JavaScriptCore date tests are flaky, because they expect time to be frozen during execution
+ https://bugs.webkit.org/show_bug.cgi?id=139138
+
+ Reviewed by Mark Lam.
+
+ Merged a fix by Bob Clary.
+
+ * tests/mozilla/ecma/Date/15.9.1.1-1.js:
+ * tests/mozilla/ecma/Date/15.9.1.1-2.js:
+ * tests/mozilla/ecma/Date/15.9.2.1.js:
+ * tests/mozilla/ecma/Date/15.9.2.2-1.js:
+ * tests/mozilla/ecma/Date/15.9.2.2-2.js:
+ * tests/mozilla/ecma/Date/15.9.2.2-3.js:
+ * tests/mozilla/ecma/Date/15.9.2.2-4.js:
+ * tests/mozilla/ecma/Date/15.9.2.2-5.js:
+ * tests/mozilla/ecma/Date/15.9.2.2-6.js:
+
+2014-11-17 Oliver Hunt <oliver@apple.com>
+
+ Make sure range based iteration of Vector<> still receives bounds checking
+ https://bugs.webkit.org/show_bug.cgi?id=138821
+
+ Reviewed by Mark Lam.
+
+ There are a few uses of begin()/end() that explicitly require pointers,
+ so we use getPtr() to extract the underlying pointer generically.
+
+ * bytecode/UnlinkedCodeBlock.cpp:
+ (JSC::UnlinkedCodeBlock::visitChildren):
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitComplexPopScopes):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
+ * ftl/FTLAbbreviations.h:
+ (JSC::FTL::mdNode):
+ (JSC::FTL::buildCall):
+ * llint/LLIntData.cpp:
+ (JSC::LLInt::Data::performAssertions):
+ * parser/Parser.h:
+ (JSC::Scope::Scope):
+ * profiler/ProfileNode.cpp:
+ (JSC::ProfileNode::debugPrintRecursively):
+ * runtime/JSArray.cpp:
+ (JSC::JSArray::setLengthWithArrayStorage):
+ (JSC::JSArray::sortCompactedVector):
+ * tools/ProfileTreeNode.h:
+ (JSC::ProfileTreeNode::dumpInternal):
+ * yarr/YarrJIT.cpp:
+ (JSC::Yarr::YarrGenerator::matchCharacterClass):
+
+2014-11-29 Andreas Kling <akling@apple.com>
+
+ PropertyTable keys should be AtomicStringImpl.
+ <https://webkit.org/b/139096>
+
+ Reviewed by Sam Weinig.
+
+ Since PropertyTable keys are really always Identifiers, switch the key
+ type from StringImpl* to AtomicStringImpl*.
+
+ We have code in the GetByVal opcode implementations that assumes things
+ about this, so this change adds confidence to those algorithms.
+
+ * bytecode/ComplexGetStatus.cpp:
+ (JSC::ComplexGetStatus::computeFor):
+ * bytecode/ComplexGetStatus.h:
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeFromLLInt):
+ (JSC::GetByIdStatus::computeFor):
+ (JSC::GetByIdStatus::computeForStubInfo):
+ * bytecode/GetByIdStatus.h:
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeFromLLInt):
+ (JSC::PutByIdStatus::computeFor):
+ (JSC::PutByIdStatus::computeForStubInfo):
+ * bytecode/PutByIdStatus.h:
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
+ * dfg/DFGDesiredIdentifiers.cpp:
+ (JSC::DFG::DesiredIdentifiers::addLazily):
+ (JSC::DFG::DesiredIdentifiers::at):
+ * dfg/DFGDesiredIdentifiers.h:
+ (JSC::DFG::DesiredIdentifiers::operator[]):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
+ * runtime/Identifier.h:
+ (JSC::Identifier::impl):
+ * runtime/IntendedStructureChain.cpp:
+ (JSC::IntendedStructureChain::mayInterceptStoreTo):
+ * runtime/IntendedStructureChain.h:
+ * runtime/PropertyMapHashTable.h:
+ * runtime/Structure.cpp:
+ (JSC::StructureTransitionTable::contains):
+ (JSC::StructureTransitionTable::get):
+ (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
+ (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
+ (JSC::Structure::getConcurrently):
+ (JSC::Structure::add):
+ (JSC::Structure::remove):
+ * runtime/Structure.h:
+ (JSC::PropertyMapEntry::PropertyMapEntry):
+ * runtime/StructureInlines.h:
+ (JSC::Structure::getConcurrently):
+ * runtime/StructureTransitionTable.h:
+ (JSC::StructureTransitionTable::Hash::hash):
+
+2014-11-28 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use std::unique_ptr<>|make_unique<> in ftl, bytecode of JSC
+ https://bugs.webkit.org/show_bug.cgi?id=139063
+
+ Reviewed by Andreas Kling.
+
+ Clean up OwnPtr and PassOwnPtr in JSC.
+
+ * bytecode/StructureStubClearingWatchpoint.cpp:
+ (JSC::StructureStubClearingWatchpoint::push):
+ * bytecode/StructureStubClearingWatchpoint.h:
+ (JSC::StructureStubClearingWatchpoint::StructureStubClearingWatchpoint):
+ * ftl/FTLCompile.cpp:
+ (JSC::FTL::mmAllocateDataSection):
+ * ftl/FTLJITFinalizer.h:
+ * ftl/FTLLink.cpp:
+ (JSC::FTL::link):
+ * parser/SourceProviderCacheItem.h:
+
+2014-11-27 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use std::unique_ptr instead of OwnPtr in JSC classes
+ https://bugs.webkit.org/show_bug.cgi?id=139009
+
+ Reviewed by Filip Pizlo.
+
+ As a step of using std::unique_ptr<>, this patch replaces OwnPtr with
+ std::unique_ptr<>|std::make_unique<>.
+
+ * bytecode/DFGExitProfile.cpp:
+ (JSC::DFG::ExitProfile::add):
+ * bytecode/DFGExitProfile.h:
+ * bytecode/LazyOperandValueProfile.cpp:
+ (JSC::CompressedLazyOperandValueProfileHolder::add):
+ * bytecode/LazyOperandValueProfile.h:
+ * heap/MarkedBlock.cpp:
+ (JSC::MarkedBlock::specializedSweep):
+ (JSC::MarkedBlock::stopAllocating):
+ * heap/MarkedBlock.h:
+ (JSC::MarkedBlock::clearNewlyAllocated):
+ * inspector/ContentSearchUtilities.cpp:
+ (Inspector::ContentSearchUtilities::findMagicComment):
+ * runtime/RegExp.cpp:
+ (JSC::RegExp::invalidateCode):
+ * runtime/RegExp.h:
+ * yarr/RegularExpression.cpp:
+ (JSC::Yarr::RegularExpression::Private::compile):
+ (JSC::Yarr::RegularExpression::isValid):
+ * yarr/YarrInterpreter.cpp:
+ (JSC::Yarr::ByteCompiler::compile):
+ (JSC::Yarr::ByteCompiler::regexBegin):
+ (JSC::Yarr::byteCompile):
+ * yarr/YarrInterpreter.h:
+ (JSC::Yarr::BytecodePattern::BytecodePattern):
+
+2014-11-24 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Clean up OwnPtr and PassOwnPtr in JSC - bytecode, jit, inspector, and interpreter
+ https://bugs.webkit.org/show_bug.cgi?id=139022
+
+ Reviewed by Filip Pizlo.
+
+ As a step of using std::unique_ptr<>, this patch replaces OwnPtr with
+ std::unique_ptr<>|std::make_unique<>.
+
+ * bytecode/DFGExitProfile.cpp:
+ (JSC::DFG::ExitProfile::add):
+ * bytecode/DFGExitProfile.h:
+ * dfg/DFGJITCompiler.cpp:
+ (JSC::DFG::JITCompiler::link):
+ (JSC::DFG::JITCompiler::linkFunction):
+ * dfg/DFGJITFinalizer.cpp:
+ (JSC::DFG::JITFinalizer::JITFinalizer):
+ * dfg/DFGJITFinalizer.h:
+ * heap/IncrementalSweeper.h:
+ * inspector/ContentSearchUtilities.cpp:
+ (Inspector::ContentSearchUtilities::findMagicComment):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/JSGlobalObjectRuntimeAgent.h:
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::enableSampler):
+ * interpreter/Interpreter.h:
+ * jit/ExecutableAllocator.cpp:
+ (JSC::ExecutableAllocator::ExecutableAllocator):
+ * jit/ExecutableAllocator.h:
+
+2014-11-22 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Clean up OwnPtr and PassOwnPtr in some of JS classes
+ https://bugs.webkit.org/show_bug.cgi?id=138724
+
+ Reviewed by Filip Pizlo.
+
+ As a step to use std::unique_ptr<> and std::make_unique<>, this patch replaces
+ OwnPtr with std::unique_ptr<>. Besides create() factory function is removed as well.
+
+ * builtins/BuiltinExecutables.h:
+ (JSC::BuiltinExecutables::create): Deleted.
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::createRareDataIfNecessary):
+ * bytecode/StructureStubInfo.h:
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::hasRareData):
+ (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
+ * runtime/CodeCache.cpp:
+ (JSC::CodeCache::getGlobalCodeBlock):
+ * runtime/CodeCache.h:
+ (JSC::CodeCache::create): Deleted.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::clearRareData):
+ * runtime/JSGlobalObject.h:
+ (JSC::JSGlobalObject::createRareDataIfNeeded):
+ * runtime/RegExpConstructor.h:
+ * runtime/SmallStrings.cpp:
+ (JSC::SmallStrings::createSingleCharacterString):
+ (JSC::SmallStrings::singleCharacterStringRep):
+ * runtime/SmallStrings.h:
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ * runtime/VM.h:
+
+2014-11-21 Michael Saboff <msaboff@apple.com>
+
+ r176455: ASSERT(!m_vector.isEmpty()) in IntendedStructureChain.cpp(143)
+ https://bugs.webkit.org/show_bug.cgi?id=139000
+
+ Reviewed by Darin Adler.
+
+ Check that the chainCount is non-zero before using a StructureChain.
+
+ * bytecode/ComplexGetStatus.cpp:
+ (JSC::ComplexGetStatus::computeFor):
+
+2014-11-21 Michael Saboff <msaboff@apple.com>
+
+ Allocate local ScopeChain register
+ https://bugs.webkit.org/show_bug.cgi?id=138793
+
+ Reviewed by Geoffrey Garen.
+
+ Now we allocate the scope register as a local. The allocated register is stored in the
+ CodeBlock for use by other components. Update the DFG to work with a local scope register.
+ Changed usage of JSStack::ScopeChain access to the CallFrame header to use the allocated
+ local register.
+
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ Updated to properly represent the operand inputs and bytecode result.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * bytecode/CodeBlock.h:
+ (JSC::CodeBlock::setScopeRegister):
+ (JSC::CodeBlock::scopeRegister):
+ * bytecode/UnlinkedCodeBlock.h:
+ (JSC::UnlinkedCodeBlock::setScopeRegister):
+ (JSC::UnlinkedCodeBlock::scopeRegister):
+ Added scope register member and accessors.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::allocateAndEmitScope):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::scopeRegister):
+ Change m_scopeRegister to an allocated register. Added allocateAndEmitScope helper to
+ allocate the scope register, set the CodeBlock with its value and emit op_get_scope.
+
+ * debugger/DebuggerCallFrame.cpp:
+ (JSC::DebuggerCallFrame::scope): Changed to access the scope using the new convention.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::get):
+ (JSC::DFG::ByteCodeParser::flush):
+ (JSC::DFG::ByteCodeParser::inlineCall):
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ Changed op_create_lexical_environment to set the scope VirtualRegister operand.
+ Filled out op_get_scope processing to emit a GetScope node putting the result in
+ the scope VirtualRegister result operand.
+ Added Phantoms where appropriate to keep the Scope register alive in places where
+ it use is optimized away, but where the baseline JIT would need to use its value.
+ Eliminated uses of JSStack::ScopeChain.
+
+ * dfg/DFGStackLayoutPhase.cpp:
+ (JSC::DFG::StackLayoutPhase::run):
+ Make sure that the scope register stack location is allocated using the same place
+ that the codeBlock expects.
+
+ * dfg/DFGStrengthReductionPhase.cpp:
+ (JSC::DFG::StrengthReductionPhase::handleNode):
+ Allow strength reduction of Flush to skip of GetScope nodes looking for a prior
+ corresponding SetLocal.
+
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::scope):
+ (JSC::ExecState::setScope):
+ Added new scope() and setScope() helpers that take a VirtualRegister offset.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::eval):
+ Changed eval() to get the scope from the caller's scope register instead of from the
+ temporary frame created for eval.
+
+ * interpreter/Interpreter.cpp:
+ (JSC::Interpreter::unwind):
+ Changed unwind() to manipulate the scope n the allocated register instead of from the
+ call frame slot.
+
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::readNonInlinedFrame):
+ (JSC::StackVisitor::readInlinedFrame):
+ * interpreter/StackVisitor.h:
+ (JSC::StackVisitor::Frame::callee):
+ (JSC::StackVisitor::Frame::scope): Deleted.
+ Eliminated the scope member as it needed to change and no StackVisitor users use it.
+
+ * jit/JITOperations.cpp:
+ (JSC::operationPushNameScope):
+ (JSC::operationPushWithScope):
+ * runtime/JSNameScope.h:
+ (JSC::JSNameScope::create):
+ * runtime/JSWithScope.h:
+ (JSC::JSWithScope::create): Deleted.
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ Deleted JSNameScope::create() and JSWithScope::create() flavors tht used the ScopeChain slot
+ in the CallFrame header. Changed the only user of these function, op_push_name_scope and
+ op_push_with_scope helpers, to use the remaining create variants that require explicit scope.
+ Those operations get the scope from the register pointed to by their scope operands.
+
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ Changed resolveScope to use the allocated register.
+
+2014-11-21 Csaba Osztrogonác <ossy@webkit.org>
+
+ [JSC] Disable verifyHeap
+ https://bugs.webkit.org/show_bug.cgi?id=138962
+
+ Reviewed by Mark Lam.
+
+ * runtime/Options.h:
+
+2014-11-20 Mark Lam <mark.lam@apple.com>
+
+ Add some comments to describe the DFG UseKind representations.
+ <https://webkit.org/b/138934>
+
+ Reviewed by Filip Pizlo.
+
+ * dfg/DFGUseKind.h:
+ - Also regrouped the UseKind enums by representation to be more readable.
+
+2014-11-20 Mark Lam <mark.lam@apple.com>
+
+ Add Heap verification infrastructure.
+ <https://webkit.org/b/138851>
+
+ Reviewed by Geoffrey Garen.
+
+ The verification infrastructure code is always built in but disabled by
+ default. When disabled, the cost is minimal:
+ 1. Heap has a m_verifier field.
+ 2. GC does a few "if (m_verifier)" checks that should fail.
+ 3. HeapVerifier takes up code space though not used.
+
+ When enabled:
+ 1. The HeapVerifier will keep N number of GC cycle data.
+ Each GC cycle will contain a "before marking" and "after marking" live
+ object list.
+ The GC cycles is a circular buffer. Only data for the last N GC cycles
+ will be retained.
+ 2. During GC, the current GC cycle's live objects lists will be populated
+ before and after marking.
+ 3. The current GC cycle's live object lists will be validated before GC,
+ after marking, and after GC.
+
+ Currently, the only validation being done is to verify that object
+ butterflies are allocated from valid blocks in the Storage (aka Copied)
+ space.
+
+ * CMakeLists.txt:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::collect):
+ * heap/Heap.h:
+ * heap/HeapVerifier.cpp: Added.
+ (JSC::LiveObjectList::findObject):
+ (JSC::HeapVerifier::HeapVerifier):
+ (JSC::HeapVerifier::collectionTypeName):
+ (JSC::HeapVerifier::phaseName):
+ (JSC::getButterflyDetails):
+ (JSC::HeapVerifier::initializeGCCycle):
+ (JSC::GatherLiveObjFunctor::GatherLiveObjFunctor):
+ (JSC::GatherLiveObjFunctor::operator()):
+ (JSC::HeapVerifier::gatherLiveObjects):
+ (JSC::HeapVerifier::liveObjectListForGathering):
+ (JSC::trimDeadObjectsFromList):
+ (JSC::HeapVerifier::trimDeadObjects):
+ (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
+ (JSC::HeapVerifier::verify):
+ (JSC::HeapVerifier::reportObject):
+ (JSC::HeapVerifier::checkIfRecorded):
+ * heap/HeapVerifier.h: Added.
+ (JSC::LiveObjectData::LiveObjectData):
+ (JSC::LiveObjectList::LiveObjectList):
+ (JSC::LiveObjectList::reset):
+ (JSC::HeapVerifier::GCCycle::GCCycle):
+ (JSC::HeapVerifier::GCCycle::collectionTypeName):
+ (JSC::HeapVerifier::incrementCycle):
+ (JSC::HeapVerifier::currentCycle):
+ (JSC::HeapVerifier::cycleForIndex):
+ * runtime/Options.h:
+
+2014-11-20 Yusuke Suzuki <utatane.tea@gmail.com>
+
+ Rename String.prototype.contains to String.prototype.includes
+ https://bugs.webkit.org/show_bug.cgi?id=138923
+
+ As per the latest TC39 meeting[1, 2], String.prototype.contains is
+ renamed to String.prototype.includes. This is because the name
+ `contains` breaks the web since it conflicts with existing `contains`
+ implementations in major libraries.
+
+ [1]: https://github.com/mathiasbynens/String.prototype.includes
+ [2]: https://github.com/tc39/test262/pull/119
+
+ Reviewed by Geoffrey Garen.
+
+ * runtime/StringPrototype.cpp:
+ (JSC::StringPrototype::finishCreation):
+ (JSC::stringProtoFuncIncludes):
+ (JSC::stringProtoFuncContains): Deleted.
+
+2014-11-19 Mark Lam <mark.lam@apple.com>
+
+ WTFCrashWithSecurityImplication under SpeculativeJIT::compile() when loading a page from theblaze.com.
+ <https://webkit.org/b/137642>
+
+ Reviewed by Filip Pizlo.
+
+ In the DFG, we have a ConstantFolding phase that occurs after all LocalCSE
+ phases have already transpired. Hence, Identity nodes introduced in the
+ ConstantFolding phase will be left in the node graph. Subsequently, the
+ DFG code generator asserts that CSE phases have consumed all Identity nodes.
+ This turns out to not be true. Hence, the crash. We fix this by teaching
+ the DFG code generator to emit code for Identity nodes.
+
+ Unlike the DFG, the FTL does not have this issue. That is because the FTL
+ plan has GlobalCSE phases that come after ConstantFolding and any other
+ phases that can generate Identity nodes. Hence, for the FTL, it is true that
+ CSE will consume all Identity nodes, and the code generator should not see any
+ Identity nodes.
+
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+
+2014-11-19 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: JSContext inspection Resource search does not work
+ https://bugs.webkit.org/show_bug.cgi?id=131252
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::searchInContent):
+ * inspector/protocol/Debugger.json:
+ Do some cleanup of the description and implementation of content searching.
+
+2014-11-19 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Provide $exception in the console for the thrown exception value
+ https://bugs.webkit.org/show_bug.cgi?id=138726
+
+ Reviewed by Timothy Hatcher.
+
+ * debugger/DebuggerScope.cpp:
+ (JSC::DebuggerScope::caughtValue):
+ * debugger/DebuggerScope.h:
+ Access the caught value if this scope is a catch scope.
+
+ * runtime/JSNameScope.h:
+ (JSC::JSNameScope::isFunctionNameScope):
+ (JSC::JSNameScope::isCatchScope):
+ (JSC::JSNameScope::value):
+ Provide an accessor for the single value in the JSNameScope (with / catch block).
+
+ * inspector/InjectedScriptSource.js:
+ Save the exception value and expose it via $exception. Since the command line api
+ is recreated on each evaluation, $exception is essentially readonly.
+
+ * inspector/ScriptDebugServer.h:
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::dispatchDidPause):
+ (Inspector::ScriptDebugServer::exceptionOrCaughtValue):
+ When pausing, get the exception or caught value. The exception will be provided
+ if we are breaking on an explicit exception. When inside of a catch block, we
+ can get the caught value by walking up the scope chain.
+
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
+ (Inspector::InspectorDebuggerAgent::resume):
+ (Inspector::InspectorDebuggerAgent::stepOver):
+ (Inspector::InspectorDebuggerAgent::stepInto):
+ (Inspector::InspectorDebuggerAgent::stepOut):
+ Clearing state can be done in didContinue.
+
+ (Inspector::InspectorDebuggerAgent::didPause):
+ Set the exception value explicitly in the injected script when we have it.
+
+ (Inspector::InspectorDebuggerAgent::didContinue):
+ Clear state saved when we had paused, including clearly an exception value if needed.
+
+ (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
+ (Inspector::InspectorDebuggerAgent::clearExceptionValue):
+ Call into the injected script only when needed.
+
+ * inspector/InjectedScript.cpp:
+ (Inspector::InjectedScript::setExceptionValue):
+ (Inspector::InjectedScript::clearExceptionValue):
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptManager.cpp:
+ (Inspector::InjectedScriptManager::clearExceptionValue):
+ * inspector/InjectedScriptManager.h:
+ Clear on all injected scripts.
+
+2014-11-19 Joseph Pecoraro <pecoraro@apple.com>
+
+ Unreviewed build fixes after r176329.
+
+ - export all of the codegen python files as they are included by the main generator
+ - update the imports of the main generator to match __init__.py
+ - remove bundling the python scripts as framework resources, just have them PrivateHeaders
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/scripts/generate-inspector-protocol-bindings.py:
+
+2014-11-18 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: standardize language-specific protocol generator file, class, and method prefixes
+ https://bugs.webkit.org/show_bug.cgi?id=138237
+
+ Reviewed by Joseph Pecoraro.
+
+ Settle on cpp/objc/js file prefixes and Cpp/ObjC/JS class prefixes for generators.
+ Move C++-specific static methods into CppGenerator and add cpp_ prefixes where relevant.
+ Split the templates file into language-specific template files.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/scripts/codegen/__init__.py:
+ * inspector/scripts/codegen/cpp_generator.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generator.py.
+ * inspector/scripts/codegen/cpp_generator_templates.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generator_templates.py.
+ (CppGeneratorTemplates):
+ * inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_dispatcher_header.py.
+ * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_dispatcher_implementation.py.
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_frontend_dispatcher_header.py.
+ * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py.
+ * inspector/scripts/codegen/generate_cpp_protocol_types_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_protocol_types_header.py.
+ * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_protocol_types_implementation.py.
+ * inspector/scripts/codegen/generate_js_backend_commands.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_backend_commands.py.
+ * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_backend_dispatcher_header.py.
+ * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py.
+ * inspector/scripts/codegen/generate_objc_configuration_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_configuration_header.py.
+ * inspector/scripts/codegen/generate_objc_configuration_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_configuration_implementation.py.
+ * inspector/scripts/codegen/generate_objc_conversion_helpers.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_conversion_helpers.py.
+ * inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py.
+ * inspector/scripts/codegen/generate_objc_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_header.py.
+ * inspector/scripts/codegen/generate_objc_internal_header.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_internal_header.py.
+ * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c_types_implementation.py.
+ * inspector/scripts/codegen/generator.py:
+ * inspector/scripts/codegen/generator_templates.py:
+ * inspector/scripts/codegen/objc_generator.py: Renamed from Source/JavaScriptCore/inspector/scripts/codegen/generate_objective_c.py.
+ * inspector/scripts/codegen/objc_generator_templates.py: Added.
+ * inspector/scripts/generate-inspector-protocol-bindings.py:
+
+2014-11-19 Juergen Ributzka <juergen@apple.com>
+
+ Update WebKit to build with LLVM TOT
+ https://bugs.webkit.org/show_bug.cgi?id=138519
+
+ Reviewed by Alexey Proskuryakov.
+
+ * Configurations/LLVMForJSC.xcconfig:
+ * llvm/LLVMAPIFunctions.h:
+ * llvm/library/LLVMExports.cpp:
+ (initializeAndGetJSCLLVMAPI):
+
+2014-11-18 David Kilzer <ddkilzer@apple.com>
+
+ FeatureDefines.xcconfig: Switch from using PLATFORM_NAME to SDK selectors
+ <http://webkit.org/b/138813>
+
+ Reviewed by Mark Rowe.
+
+ * Configurations/FeatureDefines.xcconfig: Switch to using SDK
+ selectors.
+
+2014-11-18 Chris Dumez <cdumez@apple.com>
+
+ Update the Vector API to deal with unsigned types instead of size_t
+ https://bugs.webkit.org/show_bug.cgi?id=138824
+
+ Reviewed by Andreas Kling.
+
+ Update code base to fix build errors related to the typing changes
+ in the Vector API (size_t -> unsigned).
+
+ * bytecode/PreciseJumpTargets.cpp:
+ * replay/EncodedValue.h:
+
+2014-11-18 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r176207.
+ https://bugs.webkit.org/show_bug.cgi?id=138836
+
+ Not ready yet (Requested by ap on #webkit).
+
+ Reverted changeset:
+
+ "Update WebKit to build with LLVM TOT"
+ https://bugs.webkit.org/show_bug.cgi?id=138519
+ http://trac.webkit.org/changeset/176207
+
+2014-11-17 Mark Lam <mark.lam@apple.com>
+
+ Add printing functionality in JITted code for debugging purposes.
+ <https://webkit.org/b/138660>
+
+ Reviewed by Geoffrey Garen.
+
+ Sometimes, for debugging, it'd be nice to be able to just print the
+ values of constants or registers used in JITted code, or even just
+ a string to log that certain pieces of JITted code have been executed.
+ Using the JIT probe mechanism, we can make this happen.
+
+ * assembler/ARMv7Assembler.h:
+ * assembler/AbstractMacroAssembler.h:
+ (JSC::AbstractMacroAssembler::CPUState::registerName):
+ (JSC::AbstractMacroAssembler::CPUState::registerValue):
+ (JSC::AbstractMacroAssembler::print):
+ (JSC::AbstractMacroAssembler::PrintArg::PrintArg):
+ (JSC::AbstractMacroAssembler::appendPrintArg):
+ (JSC::AbstractMacroAssembler::printInternal):
+ (JSC::AbstractMacroAssembler::printCallback):
+ * assembler/MacroAssemblerARM.cpp:
+ (JSC::MacroAssemblerARM::printCPURegisters):
+ (JSC::MacroAssemblerARM::printRegister):
+ * assembler/MacroAssemblerARM.h:
+ * assembler/MacroAssemblerARMv7.cpp:
+ (JSC::MacroAssemblerARMv7::printCPURegisters):
+ (JSC::MacroAssemblerARMv7::printRegister):
+ * assembler/MacroAssemblerARMv7.h:
+ * assembler/MacroAssemblerX86Common.cpp:
+ (JSC::MacroAssemblerX86Common::printRegister):
+ * assembler/MacroAssemblerX86Common.h:
+
+2014-11-17 Anders Carlsson <andersca@apple.com>
+
+ Fix JavaScriptCore build with newer versions of clang.
+ <rdar://problem/18978716>
+
+ * heap/Heap.cpp:
+ (JSC::Heap::visitTempSortVectors):
+ (JSC::Heap::deleteAllCompiledCode): Deleted.
+ * inspector/agents/InspectorConsoleAgent.h:
+
+2014-11-17 Juergen Ributzka <juergen@apple.com>
+
+ Update WebKit to build with LLVM TOT
+ https://bugs.webkit.org/show_bug.cgi?id=138519
+
+ Reviewed by Alexey Proskuryakov.
+
+ * Configurations/LLVMForJSC.xcconfig:
+ * llvm/LLVMAPIFunctions.h:
+ * llvm/library/LLVMExports.cpp:
+ (initializeAndGetJSCLLVMAPI):
+
+2014-11-14 Benjamin Poulain <bpoulain@apple.com>
+
+ STRH can store values with the wrong offset
+ https://bugs.webkit.org/show_bug.cgi?id=138723
+
+ Reviewed by Michael Saboff.
+
+ This is the counterpart of r176083 for the str instruction.
+
+ I believe this code is currently unreachable because there is only one client of strh()
+ in the MacroAssembler and it always setup the scale explicitely.
+
+ * assembler/ARMv7Assembler.h:
+ (JSC::ARMv7Assembler::strh):
+
+2014-11-13 Mark Lam <mark.lam@apple.com>
+
+ Reduce amount of cut-and-paste needed for probe mechanism implementations.
+ <https://webkit.org/b/138671>
+
+ Reviewed by Geoffrey Garen.
+
+ The existing code requires that each MacroAssembler implementation provide
+ their own copy of all of the probe implementations even when most of it is
+ identical. This patch hoists the common parts into AbstractMacroAssembler
+ (with some minor renaming). Each target specific MacroAssembler now only
+ need to implement a few target specific methods that are expected by and
+ documented in AbstractMacroAssembler.h in the ENABLE(MASM_PROBE) section.
+
+ In this patch, I also simplified the X86 and X86_64 ports to use the same
+ port implementation. The ARMv7 probe implementation should not conditionally
+ exclude the higher FP registers (since the JIT doesn't). Fixed the ARMv7
+ probe code to include the higher FP registers always.
+
+ This is all done in preparation to add printing functionality in JITted code
+ for debugging.
+
+ * assembler/AbstractMacroAssembler.h:
+ (JSC::AbstractMacroAssembler::Label::Label):
+ (JSC::AbstractMacroAssembler::ConvertibleLoadLabel::ConvertibleLoadLabel):
+ (JSC::AbstractMacroAssembler::DataLabelPtr::DataLabelPtr):
+ (JSC::AbstractMacroAssembler::DataLabel32::DataLabel32):
+ (JSC::AbstractMacroAssembler::DataLabelCompact::DataLabelCompact):
+ (JSC::AbstractMacroAssembler::Jump::link):
+ (JSC::AbstractMacroAssembler::Jump::linkTo):
+ (JSC::AbstractMacroAssembler::JumpList::link):
+ (JSC::AbstractMacroAssembler::JumpList::linkTo):
+ (JSC::AbstractMacroAssembler::ProbeContext::print):
+ (JSC::AbstractMacroAssembler::printIndent):
+ (JSC::AbstractMacroAssembler::printCPU):
+ (JSC::AbstractMacroAssembler::CachedTempRegister::CachedTempRegister):
+ - Except for the 3 printing methods (which are for the probe), the rest
+ are touched simply because we need to add the MacroAssemblerType to the
+ template args.
+ The MacroAssemblerType is used by the abstract probe code to call the
+ few probe methods that need to have CPU specific implementations.
+
+ * assembler/MacroAssemblerARM.cpp:
+ (JSC::MacroAssemblerARM::printCPURegisters):
+ - This was refactored from ProbeContext::dumpCPURegisters() which no
+ longer exists.
+ (JSC::MacroAssemblerARM::ProbeContext::dumpCPURegisters): Deleted.
+ (JSC::MacroAssemblerARM::ProbeContext::dump): Deleted.
+
+ * assembler/MacroAssemblerARM.h:
+ * assembler/MacroAssemblerARM64.h:
+
+ * assembler/MacroAssemblerARMv7.cpp:
+ (JSC::MacroAssemblerARMv7::printCPURegisters):
+ - This was refactored from ProbeContext::dumpCPURegisters() which no
+ longer exists.
+ (JSC::MacroAssemblerARMv7::ProbeContext::dumpCPURegisters): Deleted.
+ (JSC::MacroAssemblerARMv7::ProbeContext::dump): Deleted.
+
+ * assembler/MacroAssemblerARMv7.h:
+ * assembler/MacroAssemblerMIPS.h:
+ * assembler/MacroAssemblerSH4.h:
+ * assembler/MacroAssemblerX86.h:
+ (JSC::MacroAssemblerX86::trustedImm32FromPtr): Deleted.
+ (JSC::MacroAssemblerX86::probe): Deleted.
+
+ * assembler/MacroAssemblerX86Common.cpp:
+ (JSC::MacroAssemblerX86Common::printCPURegisters):
+ - This was refactored from ProbeContext::dumpCPURegisters() which no
+ longer exists.
+ (JSC::MacroAssemblerX86Common::probe):
+ - This implementation of probe() is based on the one originally in
+ MacroAssemblerX86_64.h. It is generic and should work for both
+ 32-bit and 64-bit.
+ (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters): Deleted.
+ (JSC::MacroAssemblerX86Common::ProbeContext::dump): Deleted.
+
+ * assembler/MacroAssemblerX86Common.h:
+ * assembler/MacroAssemblerX86_64.h:
+ (JSC::MacroAssemblerX86_64::trustedImm64FromPtr): Deleted.
+ (JSC::MacroAssemblerX86_64::probe): Deleted.
+ * jit/JITStubsARMv7.h:
+
+2014-11-13 Michael Saboff <msaboff@apple.com>
+
+ Add scope operand to op_new_func* byte codes
+ https://bugs.webkit.org/show_bug.cgi?id=138707
+
+ Reviewed by Mark Lam.
+
+ Added scope operand to op_new_func and op_new_func_expr to replace the implicit use
+ of exec->scope().
+
+ * bytecode/BytecodeList.json: Increased size of op_new_func & op_new_func_expr bytecodes.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Added scope operand to dump output.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitNewFunctionInternal):
+ (JSC::BytecodeGenerator::emitNewFunctionExpression):
+ Emit scope operand.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ Added new scope source nodes to NewFunction, NewFunctionExpression & NewFunctionNoCheck.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
+ (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::compile):
+ Use scope children when making new function JIT_Operation calls. Use JSScope* value instead of
+ exec->scope().
+
+ * dfg/DFGOperations.h:
+ * dfg/DFGOperations.cpp:
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::callOperation):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_new_func):
+ (JSC::JIT::emit_op_new_func_exp):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ Added new Jsc JIT_Operation parameter type for JSScope* values. Created declarations and
+ definitions for new JIT_Operations with Jsc parameters. Use the JSScope* parameters in lieu
+ of exec->scope() in operationNewFunction().
+ Removed comment for unused Jsa (JSLexicalEnvironment*) JIT_Operation parameter type.
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ Use the scope operand instead of exec->scope().
+
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ Changed the operand indecies for added scope operand.
+
+2014-11-13 Mark Lam <mark.lam@apple.com>
+
+ Change X86/64 JIT probes to save/restore xmm regs as double instead of __m128. [Follow up]
+ <https://webkit.org/b/138708>
+
+ Reviewed by Michael Saboff.
+
+ Removed a stale comment and a now unnecessary #include.
+
+ * assembler/X86Assembler.h:
+
+2014-11-13 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r176087.
+ https://bugs.webkit.org/show_bug.cgi?id=138714
+
+ Broke the build (Requested by ap on #webkit).
+
+ Reverted changeset:
+
+ "Update WebKit to build with LLVM TOT"
+ https://bugs.webkit.org/show_bug.cgi?id=138519
+ http://trac.webkit.org/changeset/176087
+
+2014-11-13 Mark Lam <mark.lam@apple.com>
+
+ Change X86/64 JIT probes to save/restore xmm regs as double instead of __m128.
+ <https://webkit.org/b/138708>
+
+ Reviewed by Michael Saboff.
+
+ The JIT code only uses the xmm regs as double registers. This patch changes
+ the storage types of the FP registers in X86Assembler.h to double instead of
+ __m128, and updates the X86 and X86_64 JIT probe implementations accordingly.
+
+ Also made some minor cosmetic changes in the output of the probe dump functions.
+
+ * assembler/MacroAssemblerX86Common.cpp:
+ (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
+ * assembler/X86Assembler.h:
+ * jit/JITStubsX86.h:
+ * jit/JITStubsX86Common.h:
+ * jit/JITStubsX86_64.h:
+
+2014-11-13 Juergen Ributzka <juergen@apple.com>
+
+ Update WebKit to build with LLVM TOT
+ https://bugs.webkit.org/show_bug.cgi?id=138519
+
+ Reviewed by Geoffrey Garen.
+
+ * Configurations/LLVMForJSC.xcconfig:
+ * llvm/LLVMAPIFunctions.h:
+ * llvm/library/LLVMExports.cpp:
+ (initializeAndGetJSCLLVMAPI):
+
+2014-11-13 Benjamin Poulain <benjamin@webkit.org>
+
+ ARMv7(s) Assembler: LDRH with immediate offset is loading from the wrong offset
+ https://bugs.webkit.org/show_bug.cgi?id=136914
+
+ Reviewed by Michael Saboff.
+
+ TLDR: the immediate offset of half-word load was divided by 2.
+
+ Story time: So I started getting those weird reports of :nth-child() behaving bizarrely
+ on ARMv7 and ARMv7s. To make things worse, the behavior changes depending on style updates.
+
+ I started looking the disassembly on the tests cases...
+
+ The first thing I noticed was that the computation of An+B looked wrong. For example,
+ in the case of n+6, the instruction should have been:
+ subs r1, r1, #6
+ but was
+ subs r1, r1, #2
+
+ After spending a lot of time trying to find the error in the assembler, I discovered
+ the problem was not real, but just a bug in the disassembler.
+ This is the first fix: ARMv7DOpcodeAddSubtractImmediate3's immediate3() was truncating
+ the value to 2 bits instead of 3 bits.
+
+ The disassembler being fixed, I still have no lead on the weird bug. Some disassembly later,
+ I realize the LDRH instruction is not decoded at all. The reason is that both LDRH and STRH
+ were under the umbrella ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord but the pattern
+ only matched SRTH.
+
+ I fix that next, ARMv7DOpcodeLoadStoreRegisterImmediateHalfWord is split into
+ ARMv7DOpcodeStoreRegisterImmediateHalfWord and ARMv7DOpcodeLoadRegisterImmediateHalfWord,
+ each with their own pattern and their instruction group.
+
+ Now that I can see the LDRHs correctly, there is something fishy about them, their offset
+ is way too small for the data I load.
+
+ This time, looking at the binary, the generated code is indeed incorrect. It turns out that
+ the ARMv7 assembler shifted the offset of half-word load as if they were byte load: divided by 4.
+ As a result, all the load of half-words with more than zero offset were loading
+ values with a smaller offset than what they should have.
+
+ That being fixed, I dump the assembly: still wrong. I am ready to throw my keyboard through
+ my screen at that point.
+
+ Looking at the disassembler, there is yet again a bug. The computation of the scale() adjustment
+ of the offset was incorrect for anything but word loads.
+ I replaced it by a switch-case to make it explicit.
+
+ STRH is likely incorrect too. I'll fix that in a follow up, I want to survey all the 16 bits cases
+ that are not directly used by the CSS JIT.
+
+ * assembler/ARMv7Assembler.h:
+ (JSC::ARMv7Assembler::ldrh):
+ Fix the immediate scaling. Add an assertion to make sure the alignment of the input is correct.
+
+ * disassembler/ARMv7/ARMv7DOpcode.cpp:
+ (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale):
+ Fix the scaling code. Just hardcode instruction-to-scale table.
+
+ * disassembler/ARMv7/ARMv7DOpcode.h:
+ (JSC::ARMv7Disassembler::ARMv7DOpcodeAddSubtractImmediate3::immediate3):
+ The mask for a 3 bits immediate is not 3 :)
+
+ (JSC::ARMv7Disassembler::ARMv7DOpcodeLoadStoreRegisterImmediate::scale): Deleted.
+
+2014-11-13 Andreas Kling <akling@apple.com>
+
+ Generate put_by_id for bracket assignment with constant string subscript.
+ <https://webkit.org/b/138702>
+
+ Reviewed by Geoffrey Garen.
+
+ Transform o["f"]=x to o.f=x when generating bytecode. This allows our JIT
+ to inline-cache those accesses instead of always dropping out to C++.
+
+ Just like the get_by_id transformations, this gets a bunch of use on
+ real-web content (and Speedometer) but little/none on raw JS benchmarks.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::AssignBracketNode::emitBytecode):
+
+2014-11-12 Mark Lam <mark.lam@apple.com>
+
+ Create canonical lists of registers used by both the Assemblers and the JIT probes.
+ <https://webkit.org/b/138681>
+
+ Reviewed by Filip Pizlo.
+
+ * assembler/ARMAssembler.h:
+ * assembler/ARMv7Assembler.h:
+ * assembler/X86Assembler.h:
+ - The FP register storage type is still defined as __m128 because the JIT
+ probe code still expects that amount of storage to be available. Will
+ change this to double when the JIT probe code is updated accordingly in a
+ later patch.
+
+2014-11-12 Andreas Kling <akling@apple.com>
+
+ Generate get_by_id for bracket access with constant string subscript.
+ <https://webkit.org/b/138663>
+
+ Reviewed by Michael Saboff.
+
+ Transform o["f"] into o.f when generating bytecode. This allows our JIT
+ to inline-cache those accesses instead of always dropping out to C++.
+
+ This is surprisingly common in real-web content, less so in benchmarks.
+ Interestingly, Speedometer does hit the optimization quite a bit.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BracketAccessorNode::emitBytecode):
+
+2014-11-12 Mark Lam <mark.lam@apple.com>
+
+ Rename USE(MASM_PROBE) to ENABLE(MASM_PROBE).
+ <https://webkit.org/b/138661>
+
+ Reviewed by Michael Saboff.
+
+ Also move the switch for enabling the use of MASM_PROBE from JavaScriptCore's
+ config.h to WTF's Platform.h. This ensures that the setting is consistently
+ applied even when building WebCore parts as well.
+
+ * assembler/ARMAssembler.h:
+ * assembler/ARMv7Assembler.h:
+ * assembler/MacroAssemblerARM.cpp:
+ * assembler/MacroAssemblerARM.h:
+ * assembler/MacroAssemblerARMv7.cpp:
+ * assembler/MacroAssemblerARMv7.h:
+ * assembler/MacroAssemblerX86.h:
+ * assembler/MacroAssemblerX86Common.cpp:
+ * assembler/MacroAssemblerX86Common.h:
+ * assembler/MacroAssemblerX86_64.h:
+ * assembler/X86Assembler.h:
+ * config.h:
+ * jit/JITStubs.h:
+ * jit/JITStubsARM.h:
+ * jit/JITStubsARMv7.h:
+ * jit/JITStubsX86.h:
+ * jit/JITStubsX86Common.h:
+ * jit/JITStubsX86_64.h:
+
+2014-11-12 peavo@outlook.com <peavo@outlook.com>
+
+ [WinCairo] Incorrect names for test executables in debug mode.
+ https://bugs.webkit.org/show_bug.cgi?id=138659
+
+ Reviewed by Alex Christensen.
+
+ In debug mode, jsc.exe, and testapi.exe are not created, causing JSC test failures.
+
+ * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
+ * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
+
+2014-11-11 Michael Saboff <msaboff@apple.com>
+
+ Change DFG to use scope operand for op_resolve_scope
+ https://bugs.webkit.org/show_bug.cgi?id=138651
+
+ Reviewed by Geoffrey Garen.
+
+ Changed to use the provided scope VirtualRegister.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::getScope): Changed to use an argument scope register.
+ (JSC::DFG::ByteCodeParser::parseBlock): Created VirtualRegister from scope operand.
+
+2014-11-11 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Remove IncrementalSweeper::create()
+ https://bugs.webkit.org/show_bug.cgi?id=138243
+
+ Reviewed by Filip Pizlo.
+
+ As a step to use std::unique_ptr<> and std::make_unique<>, this patch removes
+ IncrementalSweeper::create(), then set constructor of IncrementalSweeper to public.
+ Now we begins to use std::make_unique<> to create IncrementalSweeper instance.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::Heap):
+ (JSC::Heap::setIncrementalSweeper):
+ * heap/Heap.h:
+ * heap/IncrementalSweeper.cpp:
+ (JSC::IncrementalSweeper::create): Deleted.
+ * heap/IncrementalSweeper.h:
+
+2014-11-11 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Handle activating extra agents properly after inspector has connected
+ https://bugs.webkit.org/show_bug.cgi?id=138639
+
+ Reviewed by Timothy Hatcher.
+
+ Instead of having the protocol configuration directly add the extra agent
+ to the inspector registry, isntead go through the augmentable controller.
+ The controller will initialize as required if we are already connected or not,
+ and will add to the registry.
+
+ The functional change here is that the frontend can be notified to activate
+ extra agents multiple times as agents eventually become available.
+
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::appendExtraAgent):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/agents/InspectorAgent.cpp:
+ (Inspector::InspectorAgent::activateExtraDomain):
+ * inspector/agents/InspectorAgent.h:
+ * inspector/augmentable/AugmentableInspectorController.h:
+ * inspector/scripts/codegen/generator_templates.py:
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ Rebased results.
+
+2014-11-11 Michael Saboff <msaboff@apple.com>
+
+ Use scope register when processing op_resolve_scope in LLInt and Baseline JIT
+ https://bugs.webkit.org/show_bug.cgi?id=138637
+
+ Reviewed by Mark Lam.
+
+ Filled out op_resolve_scope processing to use the scope operand to access the current
+ scope chain.
+
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ Added scope virtual register parameter to emitResolveClosure(). Added new callOperation() to
+ support the additional argument.
+
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitResolveClosure):
+ (JSC::JIT::emit_op_resolve_scope):
+ (JSC::JIT::emitSlow_op_resolve_scope):
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emitResolveClosure):
+ (JSC::JIT::emit_op_resolve_scope):
+ (JSC::JIT::emitSlow_op_resolve_scope):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ Added "scope" parameter to emitResolveClosure(). Passed scope register index to slow path.
+ Used scope virtual register instead of JSStack::ScopeChain.
+
+2014-11-11 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Don't require a debugger be attached for inspector auto attach
+ https://bugs.webkit.org/show_bug.cgi?id=138638
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate):
+
+2014-11-11 Akos Kiss <akiss@inf.u-szeged.hu>
+
+ Handle cases in StackVisitor::Frame::existingArguments() when lexicalEnvironment and/or unmodifiedArgumentsRegister is not set up yet
+ https://bugs.webkit.org/show_bug.cgi?id=138543
+
+ Reviewed by Geoffrey Garen.
+
+ Exception fuzzing may may raise exceptions in places where they would be
+ otherwise impossible. Therefore, a callFrame may lack activation even if
+ the codeBlock signals need of activation. Also, even if codeBlock
+ signals the use of arguments, the unmodifiedArgumentsRegister may not be
+ initialized yet (neither locally nor in lexicalEnvironment).
+
+ If codeBlock()->needsActivation() is false, unmodifiedArgumentsRegister
+ is already checked for Undefined. This patch applies the same check when
+ the condition is true (and also checks whether
+ callFrame()->hasActivation()).
+
+ * interpreter/CallFrame.h:
+ (JSC::ExecState::hasActivation):
+ Moved to interpreter/CallFrameInlines.h.
+ * interpreter/CallFrameInlines.h:
+ (JSC::CallFrame::hasActivation):
+ Fixed to verify that the JSValue returned by uncheckedActivation() is a
+ cell.
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::existingArguments):
+
+2014-11-11 Andreas Kling <akling@apple.com>
+
+ Another assertion fix for debug builds after r175846.
+
+ generateByIdStub() can now be called with an empty prototype chain
+ if kind == GetUndefined, so tweak the assertion to cover that.
+
+ * jit/Repatch.cpp:
+ (JSC::generateByIdStub):
+
+2014-11-10 Andreas Kling <akling@apple.com>
+
+ Assertion fix for debug builds after r175846.
+
+ PropertySlot::slotBase() will assert if the slot is unset, so reorder
+ the tests to check for isCacheableValue() first.
+
+ * jit/Repatch.cpp:
+ (JSC::tryCacheGetByID):
+
+2014-11-10 Andreas Kling <akling@apple.com>
+
+ The JIT should cache property lookup misses.
+ <https://webkit.org/b/135578>
+
+ Add support for inline caching of missed property lookups.
+ Previously this would banish us to C++ slow path.
+
+ It's implemented as a simple GetById cache that returns jsUndefined()
+ as long as the Structure chain check passes. There's no DFG exploitation
+ of this knowledge in this patch.
+
+ Test: js/regress/undefined-property-access.js (~5.5x speedup)
+
+ Reviewed by Filip Pizlo.
+
+ * bytecode/PolymorphicGetByIdList.h:
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeForStubInfo):
+
+ Add GetByIdAccess::SimpleMiss so we can communicate to the DFG that
+ the access has been cached.
+
+ * jit/Repatch.cpp:
+ (JSC::toString):
+ (JSC::kindFor):
+ (JSC::generateByIdStub):
+ (JSC::tryCacheGetByID):
+ (JSC::tryBuildGetByIDList):
+
+ Added a GetUndefined stub kind, just a simple "store jsUndefined()" snippet.
+ Use this to cache missed lookups, piggybacking mostly on the GetValue kind.
+
+ * runtime/PropertySlot.h:
+ (JSC::PropertySlot::isUnset):
+
+ Exposed the unset state so PropertySlot can communicate that lookup failed.
+
+2014-11-10 Michael Saboff <msaboff@apple.com>
+
+ Add scope operand to op_create_lexical_environment
+ https://bugs.webkit.org/show_bug.cgi?id=138588
+
+ Reviewed by Geoffrey Garen.
+
+ Added a second operand to op_create_lexical_environment that contains the scope register
+ to update. Note that the DFG relies on operationCreateActivation() to update the
+ scope register since we can't issue a set() with a non-local, non-argument register.
+ This is temporary until the scope register is allocated as a local.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ Added the scope register operand.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ Filled in the scope register operand.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_create_lexical_environment):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_create_lexical_environment):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ Set the scope register with the result of the appropriate create activation slow call.
+
+2014-11-09 Akos Kiss <akiss@inf.u-szeged.hu>
+
+ Fix 'noreturn' function does return warning in LLVMOverrides.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=138306
+
+ Reviewed by Filip Pizlo.
+
+ Adding NO_RETURN where needed.
+
+ * llvm/library/LLVMExports.cpp:
+ (initializeAndGetJSCLLVMAPI):
+ * llvm/library/LLVMOverrides.cpp:
+ * llvm/library/LLVMTrapCallback.h:
+
+2014-11-07 Dániel Bátyai <dbatyai.u-szeged@partner.samsung.com>
+
+ Fix an alignment issue with operationPushCatchScope on ARMv7
+ https://bugs.webkit.org/show_bug.cgi?id=138510
+
+ Reviewed by Csaba Osztrogonác.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+
+2014-11-07 Michael Saboff <msaboff@apple.com>
+
+ Update scope related slow path code to use scope register added to opcodes
+ https://bugs.webkit.org/show_bug.cgi?id=138254
+
+ Reviewed by Mark Lam.
+
+ Updated slow paths for op_pop_scope, op_push_name_scope and op_push_with_scope.
+ Added scope register index parameter to the front of the relevant argument lists of the
+ slow functions. In the case of op_push_name_scope for x86 (32 bit), there aren't enough
+ registers to accomodate all the parameters. Therefore, added two new JSVALUE32_64 slow
+ paths called operationPushCatchScope() and operationPushFunctionNameScope() to eliminate
+ the last "type" argument.
+
+
+ * assembler/MacroAssemblerCodeRef.h:
+ (JSC::FunctionPtr::FunctionPtr): Added a new template to take 6 arguments.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ New variants of setupArgumentsWithExecState() and callOperation() to handle the new
+ combinations of argument types and counts.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_push_with_scope):
+ (JSC::JIT::emit_op_pop_scope):
+ (JSC::JIT::emit_op_push_name_scope):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_push_with_scope):
+ (JSC::JIT::emit_op_pop_scope):
+ (JSC::JIT::emit_op_push_name_scope):
+ Use the new slow paths.
+
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ Updates to set the scope result using the scope register index. Added operationPushCatchScope()
+ and operationPushFunctionNameScope().
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ Updated the scope slow paths to use the scope register index in the instruction to read and
+ write the register instead of using CallFrame::scope() and CallFrame::setScope().
+
+2014-11-07 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Apply std::unique_ptr to slowPathCall()
+ https://bugs.webkit.org/show_bug.cgi?id=138489
+
+ Reviewed by Mark Lam.
+
+ As a step to use std::unique_ptr<>, this patch makes slowPathCall() use std::unique_ptr<>,
+ std::make_unique<>, and WTF::move().
+
+ * dfg/DFGSlowPathGenerator.h:
+ (JSC::DFG::slowPathCall):
+ (JSC::DFG::slowPathMove):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitAllocateJSArray):
+ (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
+ (JSC::DFG::SpeculativeJIT::arrayify):
+ (JSC::DFG::SpeculativeJIT::compileIn):
+ (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
+ * dfg/DFGSpeculativeJIT.h:
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::cachedGetById):
+ (JSC::DFG::SpeculativeJIT::cachedPutById):
+ (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
+ (JSC::DFG::SpeculativeJIT::compile):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::cachedGetById):
+ (JSC::DFG::SpeculativeJIT::cachedPutById):
+ (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
+ (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
+ (JSC::DFG::SpeculativeJIT::compile):
+
+2014-11-06 Mark Lam <mark.lam@apple.com>
+
+ slow_path_get_direct_pname() needs to be hardened against a constant baseValue.
+ <https://webkit.org/b/138476>
+
+ Reviewed by Michael Saboff.
+
+ slow_path_get_direct_pname() currently assumes that the baseValue is always a
+ non-constant virtual register. However, this is not always the case like in the
+ following:
+
+ function foo() {
+ var o = { a:1 };
+ for (var n in o)
+ 0[n];
+ }
+ foo();
+
+ This patch fixes it to also check for constant virtual register indexes.
+
+ * runtime/CommonSlowPaths.cpp:
+ (JSC::SLOW_PATH_DECL):
+
+2014-11-06 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION (r174985-174986): Site display disappears
+ https://bugs.webkit.org/show_bug.cgi?id=138082
+
+ Reviewed by Geoffrey Garen.
+
+ In support of the change in WebCore, this adds a new functor class to unwind to our
+ caller's frame possibly skipping of intermediate C++ frames.
+
+ * interpreter/StackVisitor.h:
+ (JSC::CallerFunctor::CallerFunctor):
+ (JSC::CallerFunctor::callerFrame):
+ (JSC::CallerFunctor::operator()):
+
+2014-11-06 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use std::unique_ptr in CodeBlock class
+ https://bugs.webkit.org/show_bug.cgi?id=138395
+
+ Reviewed by Darin Adler.
+
+ * bytecode/CodeBlock.h: Use std::unique_ptr.
+ (JSC::CodeBlock::setJITCodeMap):
+ * jit/CompactJITCodeMap.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
+ (JSC::CompactJITCodeMap::CompactJITCodeMap):
+ (JSC::CompactJITCodeMap::Encoder::finish): Use std::unique_ptr instead of PassOwnPtr.
+
+2014-11-05 Mark Lam <mark.lam@apple.com>
+
+ PutById inline caches should have a store barrier when it triggers a structure transition.
+ <https://webkit.org/b/138441>
+
+ Reviewed by Geoffrey Garen.
+
+ After r174025, we no longer insert DFG store barriers when the payload of a
+ PutById operation is not a cell. However, this can lead to a crash when we have
+ PutById inline cache code transitioning the structure and re-allocating the
+ butterfly of an old gen object. The lack of a store barrier in that inline
+ cache results in the old gen object not being noticed during an eden GC scan.
+ As a result, its newly allocated butterfly will not be kept alive, which leads
+ to a stale butterfly pointer and, eventually, a crash.
+
+ It is also possible that the new structure can be collected by the eden GC if
+ (at GC time):
+ 1. It is in the eden gen.
+ 2. The inline cache that installed it has been evicted.
+ 3. There are no live eden gen objects referring to it.
+
+ The chances of this should be more rare than the butterfly re-allocation, but
+ it is still possible. Hence, the fix is to always add a store barrier if the
+ inline caches performs a structure transition.
+
+ * jit/Repatch.cpp:
+ (JSC::emitPutTransitionStub):
+ - Added store barrier code based on SpeculativeJIT::storeToWriteBarrierBuffer()'s
+ implementation.
+
+2014-11-05 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use std::unique_ptr in JSClassRef and JSCallbackObject
+ https://bugs.webkit.org/show_bug.cgi?id=138402
+
+ Reviewed by Geoffrey Garen.
+
+ * API/JSCallbackObject.h: Use std::unique_ptr instead of OwnPtr|PassOwnPtr.
+ (JSC::JSCallbackObjectData::setPrivateProperty): ditto.
+ * API/JSClassRef.cpp: ditto.
+ * API/JSClassRef.h: ditto.
+
+2014-11-05 Michael Saboff <msaboff@apple.com>
+
+ Disable flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
+ https://bugs.webkit.org/show_bug.cgi?id=138381
+
+ Reviewed by Mark Lam.
+
+ Disabled these test for ARM64. Will address the failures and then re-enable.
+
+ * tests/stress/float32-repeat-out-of-bounds.js:
+ * tests/stress/int8-repeat-out-of-bounds.js:
+
+2014-11-05 Alexey Proskuryakov <ap@apple.com>
+
+ Incorrect sandbox_check in RemoteInspector.mm
+ https://bugs.webkit.org/show_bug.cgi?id=138408
+
+ Reviewed by Joseph Pecoraro.
+
+ * inspector/remote/RemoteInspector.mm:
+ (Inspector::canAccessWebInspectorMachPort):
+
+2014-11-03 Dean Jackson <dino@apple.com>
+
+ Add ENABLE_FILTERS_LEVEL_2 feature guard.
+ https://bugs.webkit.org/show_bug.cgi?id=138362
+
+ Reviewed by Tim Horton.
+
+ Add a new feature define for Level 2 of CSS Filters.
+ http://dev.w3.org/fxtf/filters-2/
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2014-11-04 Mark Lam <mark.lam@apple.com>
+
+ Rename checkMarkByte() to jumpIfIsRememberedOrInEden().
+ <https://webkit.org/b/138369>
+
+ Reviewed by Geoffrey Garen.
+
+ Write barriers are needed for GC Eden collections so that we can scan pointers
+ pointing from old generation objects to eden generation objects. The barrier
+ currently checks the mark byte in a cell to see if we should skip adding the
+ cell to the GC remembered set. The addition should be skipped if:
+
+ 1. The cell is in the young generation. It has no old to eden pointers by
+ definition.
+ 2. The cell is already in the remembered set. While it is ok to add the cell
+ to the GC remembered set more than once, it would be redundant. Hence,
+ we skip this as an optimization to avoid doing unnecessary work.
+
+ The barrier currently names this check as checkMarkByte(). We should rename it
+ to jumpIfIsRememberedOrInEden() to be clearer about its intent.
+
+ Similarly, Jump results of this check are currently named
+ ownerNotMarkedOrAlreadyRemembered. This can be misinterpreted as the owner is
+ not marked or not already remembered. We should rename it to
+ ownerIsRememberedOrInEden which is clearer about the intent of the
+ check. What we are really checking for is that the cell is in the eden gen,
+ which is implied by it being "not marked".
+
+ * dfg/DFGOSRExitCompilerCommon.cpp:
+ (JSC::DFG::osrWriteBarrier):
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::writeBarrier):
+ * dfg/DFGSpeculativeJIT32_64.cpp:
+ (JSC::DFG::SpeculativeJIT::writeBarrier):
+ * dfg/DFGSpeculativeJIT64.cpp:
+ (JSC::DFG::SpeculativeJIT::writeBarrier):
+ * jit/AssemblyHelpers.h:
+ (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
+ (JSC::AssemblyHelpers::checkMarkByte): Deleted.
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emitWriteBarrier):
+ * llint/LowLevelInterpreter.asm:
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ * runtime/JSCell.h:
+
+2014-11-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Pause on exceptions should show the actual exception
+ https://bugs.webkit.org/show_bug.cgi?id=63096
+
+ Reviewed by Timothy Hatcher.
+
+ * debugger/Debugger.h:
+ Expose accessor for the pause reason to subclasses.
+
+ * inspector/JSInjectedScriptHost.cpp:
+ (Inspector::JSInjectedScriptHost::type):
+ New "error" subtype for error objects.
+
+ * inspector/InjectedScriptSource.js:
+ When an object is an error object, use toString to provide a richer description.
+
+ * inspector/protocol/Runtime.json:
+ Expose a new "error" subtype for Error types (TypeError, ReferenceError, EvalError, etc).
+
+ * inspector/protocol/Debugger.json:
+ Provide type checked objects for different Debugger.pause pause reasons.
+ An exception provides the thrown object, but assert / CSP pauses provide
+ a richer typed object as the auxiliary data.
+
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::dispatchDidPause):
+ When paused because of an exception, pass the exception on.
+
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
+ (Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
+ Provide richer data in pause events.
+
+ * inspector/scripts/codegen/generate_backend_commands.py:
+ (BackendCommandsGenerator.generate_domain.is_anonymous_enum_param):
+ (BackendCommandsGenerator.generate_domain):
+ * inspector/scripts/tests/expected/enum-values.json-result:
+ Generate frontend enums for anonymous enum event parameters.
+
+2014-11-04 Michael Saboff <msaboff@apple.com>
+
+ Disable flakey float32-repeat-out-of-bounds.js and int8-repeat-out-of-bounds.js tests for ARM64
+ https://bugs.webkit.org/show_bug.cgi?id=138381
+
+ Reviewed by Mark Lam.
+
+ Disabled these test for ARM64. Will address the failures and then re-enable.
+
+ * tests/stress/float32-repeat-out-of-bounds.js:
+ * tests/stress/int8-repeat-out-of-bounds.js:
+
+2014-11-04 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Enum value collisions between different generators
+ https://bugs.webkit.org/show_bug.cgi?id=138343
+
+ Reviewed by Brian Burg.
+
+ Each generator was using its own filtered list of domains_to_generate
+ to build the shared unique list of enum value encodings. This list
+ was slightly different across different generators. Instead always
+ use the list of all non-supplemental domains to generate the shared
+ list of enum values.
+
+ * inspector/scripts/codegen/generator.py:
+ (Generator.non_supplemental_domains):
+ (Generator.domains_to_generate):
+ (Generator._traverse_and_assign_enum_values):
+ * inspector/scripts/tests/enum-values.json: Added.
+ * inspector/scripts/tests/expected/enum-values.json-result: Added.
+
+2014-11-03 Akos Kiss <akiss@inf.u-szeged.hu>
+
+ Workaround for Cortex-A53 erratum 835769
+ https://bugs.webkit.org/show_bug.cgi?id=138315
+
+ Reviewed by Filip Pizlo.
+
+ This patch introduces CMake variable and preprocessor macro
+ WTF_CPU_ARM64_CORTEXA53 with the aim of enabling Cortex-A53-specific
+ code paths, if set true. The patch also implements one case where such
+ code paths are needed: the workaround for Cortex-A53 erratum 835769. If
+ WTF_CPU_ARM64_CORTEXA53 is set then:
+ - CMake checks whether the compiler already has support for a workaround
+ and adds -mfix-cortex-a53-835769 to the compiler flags if so,
+ - the ARM64 backend of offlineasm inserts a nop between memory and
+ multiply-accumulate instructions, and
+ - the ARM64 assembler also inserts a nop between memory and (64-bit)
+ multiply-accumulate instructions.
+
+ * assembler/ARM64Assembler.h:
+ (JSC::ARM64Assembler::madd):
+ Call nopCortexA53Fix835769() to insert a nop if CPU(ARM64_CORTEXA53) and
+ if necessary.
+ (JSC::ARM64Assembler::msub): Likewise.
+ (JSC::ARM64Assembler::smaddl): Likewise.
+ (JSC::ARM64Assembler::smsubl): Likewise.
+ (JSC::ARM64Assembler::umaddl): Likewise.
+ (JSC::ARM64Assembler::umsubl): Likewise.
+ (JSC::ARM64Assembler::nopCortexA53Fix835769):
+ Added. Insert a nop if the previously emitted instruction was a load, a
+ store, or a prefetch, and if the current instruction is 64-bit.
+ * offlineasm/arm64.rb:
+ Add the arm64CortexA53Fix835769 phase and call it from
+ getModifiedListARM64 to insert nopCortexA53Fix835769 between appropriate
+ macro instructions. Also, lower nopCortexA53Fix835769 to nop if
+ CPU(ARM64_CORTEXA53), to nothing otherwise.
+ * offlineasm/instructions.rb:
+ Define macro instruction nopFixCortexA53Err835769.
+
+2014-11-03 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r175509.
+ https://bugs.webkit.org/show_bug.cgi?id=138349
+
+ broke some builds (Requested by msaboff on #webkit).
+
+ Reverted changeset:
+
+ "Update scope related slow path code to use scope register
+ added to opcodes"
+ https://bugs.webkit.org/show_bug.cgi?id=138254
+ http://trac.webkit.org/changeset/175509
+
+2014-11-03 Michael Saboff <msaboff@apple.com>
+
+ Update scope related slow path code to use scope register added to opcodes
+ https://bugs.webkit.org/show_bug.cgi?id=138254
+
+ Reviewed by Mark Lam.
+
+ Updated slow paths for op_pop_scope, op_push_name_scope and op_push_with_scope.
+ Added scope register index parameter to the front of the relevant argument lists of the
+ slow functions. In the case of op_push_name_scope for x86 (32 bit), there aren't enough
+ registers to accomodate all the parameters. Therefore, added two new JSVALUE32_64 slow
+ paths called operationPushCatchScope() and operationPushFunctionNameScope() to eliminate
+ the last "type" argument.
+
+
+ * assembler/MacroAssemblerCodeRef.h:
+ (JSC::FunctionPtr::FunctionPtr): Added a new template to take 6 arguments.
+
+ * jit/CCallHelpers.h:
+ (JSC::CCallHelpers::setupArgumentsWithExecState):
+ * jit/JIT.h:
+ * jit/JITInlines.h:
+ (JSC::JIT::callOperation):
+ New variants of setupArgumentsWithExecState() and callOperation() to handle the new
+ combinations of argument types and counts.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_push_with_scope):
+ (JSC::JIT::emit_op_pop_scope):
+ (JSC::JIT::emit_op_push_name_scope):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_push_with_scope):
+ (JSC::JIT::emit_op_pop_scope):
+ (JSC::JIT::emit_op_push_name_scope):
+ Use the new slow paths.
+
+ * jit/JITOperations.cpp:
+ * jit/JITOperations.h:
+ Updates to set the scope result using the scope register index. Added operationPushCatchScope()
+ and operationPushFunctionNameScope().
+
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ Updated the scope slow paths to use the scope register index in the instruction to read and
+ write the register instead of using CallFrame::scope() and CallFrame::setScope().
+
+2014-11-03 Michael Saboff <msaboff@apple.com>
+
+ Add "get scope" byte code
+ https://bugs.webkit.org/show_bug.cgi?id=138326
+
+ Reviewed by Mark Lam.
+
+ Added op_get_scope. Added implementations for the LLInt and baseline JIT.
+ Provided nop implementation for DFG and FTL. The new byte code is emitted
+ after op_enter for any function, program or eval. It is expected that the
+ DFG will be implemented such that unneeded op_get_scope would be eliminated
+ during DFG compilation.
+
+ * bytecode/BytecodeList.json:
+ * bytecode/BytecodeUseDef.h:
+ (JSC::computeUsesForBytecodeOffset):
+ (JSC::computeDefsForBytecodeOffset):
+ Added new op_get_scope bytecode.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::emitGetScope):
+ * bytecompiler/BytecodeGenerator.h:
+ Emit new op_get_scope bytecode.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ Added framework for new op_get_scope bytecode.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode):
+ * jit/JIT.cpp:
+ (JSC::JIT::privateCompileMainPass):
+ * jit/JIT.h:
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_get_scope):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_get_scope):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ Implementation of op_get_scope bytecode.
+
+2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Fix RWIProtocol 64-to-32 bit conversion warnings
+ https://bugs.webkit.org/show_bug.cgi?id=138325
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/InspectorValues.h:
+ Vector's length really is an unsigned, so a static_cast here is fine.
+
+ * inspector/scripts/codegen/generate_objective_c.py:
+ (ObjCGenerator.objc_type_for_raw_name):
+ Use int instead of NSInteger for APIs that eventually map to
+ InspectorObject's setInteger, which takes an int.
+
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ Rebaselined results with the type change.
+
+2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Show Selector's Specificity
+ https://bugs.webkit.org/show_bug.cgi?id=138189
+
+ Reviewed by Timothy Hatcher.
+
+ * inspector/protocol/CSS.json:
+ Create a new named type CSSSelector to include a selector's text and specificity.
+ The specificity tuple is optional as it may soon be made dynamic in some cases.
+
+2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ObjC Protocol Interfaces should throw exceptions for nil arguments
+ https://bugs.webkit.org/show_bug.cgi?id=138221
+
+ Reviewed by Timothy Hatcher.
+
+ The RWIProtocol APIs will now raise exceptions when:
+
+ - any properties are set on a type with a nil value or key (handled by RWIProtocolJSONObject)
+ - required parameters in type constructors have nil value
+ - required or optional command return parameters have nil values
+ - required or optional event parameters have nil values
+
+ The exceptions include the name of the field when possible.
+
+ * inspector/scripts/codegen/generate_objective_c.py:
+ (ObjCGenerator.is_type_objc_pointer_type):
+ Provide a quick check to see if type would be a pointer or not
+ in the ObjC API. Enums for example are not pointers in the API
+ because we manage converting them to/from strings.
+
+ * inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py:
+ (ObjectiveCConfigurationImplementationGenerator._generate_success_block_for_command):
+ * inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py:
+ (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event):
+ * inspector/scripts/codegen/generate_objective_c_types_implementation.py:
+ (ObjectiveCTypesImplementationGenerator._generate_init_method_for_required_members):
+ (ObjectiveCTypesImplementationGenerator._generate_setter_for_member):
+ Throw exceptions when nil values are disallowed.
+
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ Rebaseline tests which include the exception raise calls.
+
+2014-11-03 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: ALTERNATE_DISPATCHERS Let the frontend know about extra agents
+ https://bugs.webkit.org/show_bug.cgi?id=138236
+
+ Reviewed by Brian Burg.
+
+ Inform the frontend about any extra domains the backend may have
+ above and beyond the default list of domains for the debuggable type.
+ This approach means there is almost no cost to normal debugging.
+ When a JSContext is debugged with extra agents, a message is sent
+ to the frontend letting it know which domains to then activate,
+ and perform any initialization work that may be required.
+
+ * inspector/InspectorAgentBase.h:
+ (Inspector::InspectorAgentBase::domainName):
+ * inspector/InspectorAgentRegistry.cpp:
+ (Inspector::InspectorAgentRegistry::appendExtraAgent):
+ * inspector/InspectorAgentRegistry.h:
+ * inspector/scripts/codegen/generator_templates.py:
+ Provide a way to get a list of just the extra domains.
+ To aggregate this list provide a different "append"
+ specifically for extra agents.
+
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+ (Inspector::JSGlobalObjectInspectorController::connectFrontend):
+ When a frontend connects, inform it of the extra domains.
+
+ * inspector/protocol/Inspector.json:
+ * inspector/agents/InspectorAgent.h:
+ * inspector/agents/InspectorAgent.cpp:
+ (Inspector::InspectorAgent::enable):
+ (Inspector::InspectorAgent::activateExtraDomains):
+ Send an event with the extra domains to activate.
+
+2014-11-01 Michael Saboff <msaboff@apple.com>
+
+ Add scope operand to op_resolve_scope
+ https://bugs.webkit.org/show_bug.cgi?id=138253
+
+ Reviewed by Mark Lam.
+
+ Added scope operand to op_resolve_scope. Although the scope register is filled in with
+ the ScopeChain register, this operand is not used in the processing of the bytecode.
+ That will be addressed in a future patch.
+
+ * bytecode/BytecodeList.json: Lengthened the three bytecodes.
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Added code to dump the scope operand.
+
+ (JSC::CodeBlock::CodeBlock):
+ (JSC::CodeBlock::finalizeUnconditionally):
+ Updated the operand indecies for the processing of op_resolve_scope.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitResolveScope):
+ (JSC::BytecodeGenerator::emitGetOwnScope):
+ (JSC::BytecodeGenerator::emitReturn):
+ Added scope register to these emit functions and the bytecodes they emit.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::parseBlock):
+ * dfg/DFGCapabilities.cpp:
+ (JSC::DFG::capabilityLevel):
+ * jit/JITPropertyAccess.cpp:
+ (JSC::JIT::emit_op_resolve_scope):
+ (JSC::JIT::emitSlow_op_resolve_scope):
+ * jit/JITPropertyAccess32_64.cpp:
+ (JSC::JIT::emit_op_resolve_scope):
+ (JSC::JIT::emitSlow_op_resolve_scope):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+ Updated the operand indecies for the processing of op_resolve_scope.
+
+2014-11-01 Carlos Garcia Campos <cgarcia@igalia.com>
+
+ REGRESSION(CMake): Make it possible to build without introspection
+ https://bugs.webkit.org/show_bug.cgi?id=138006
+
+ Reviewed by Philippe Normand.
+
+ Do not install introspection files when introspection is disabled.
+
+ * PlatformGTK.cmake:
+
+2014-10-31 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use std::unique_ptr for TypeCountSet
+ https://bugs.webkit.org/show_bug.cgi?id=138242
+
+ Reviewed by Andreas Kling.
+
+ * heap/Heap.cpp:
+ (JSC::Heap::protectedObjectTypeCounts):
+ Use std::unique_ptr<> instead of PassOwnPtr|OwnPtr.
+ (JSC::Heap::objectTypeCounts): ditto.
+ * heap/Heap.h:
+
+2014-10-31 Michael Saboff <msaboff@apple.com>
+
+ Add scope operand to op_push_with_scope, op_push_name_scope and op_pop_scope
+ https://bugs.webkit.org/show_bug.cgi?id=138252
+
+ Reviewed by Geoffrey Garen.
+
+ Added scope operand to op_push_with_scope, op_push_name_scope and op_pop_scope.
+ Although the scope register is filled in with the ScopeChain register for all
+ three bytecodes, this operand is not used in the processing of the bytecodes.
+ That will be addressed in a future patch.
+
+ * bytecode/BytecodeList.json: Lengthened the three bytecodes.
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::dumpBytecode): Added code to dump the scope operand.
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::emitPushWithScope):
+ (JSC::BytecodeGenerator::emitPopScope):
+ (JSC::BytecodeGenerator::emitComplexPopScopes):
+ (JSC::BytecodeGenerator::emitPopScopes):
+ (JSC::BytecodeGenerator::emitPushFunctionNameScope):
+ (JSC::BytecodeGenerator::emitPushCatchScope):
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::scopeRegister):
+ Added scope register to these emit functions and the bytecodes they emit.
+ New m_scopeRegister and accessor.
+
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::ContinueNode::emitBytecode):
+ (JSC::BreakNode::emitBytecode):
+ (JSC::ReturnNode::emitBytecode):
+ (JSC::WithNode::emitBytecode):
+ (JSC::TryNode::emitBytecode):
+ Created a RegisterID for the ScopeChain register and used it to emit the updated
+ bytecodes.
+
+ * jit/JITOpcodes.cpp:
+ (JSC::JIT::emit_op_push_with_scope):
+ (JSC::JIT::emit_op_push_name_scope):
+ * jit/JITOpcodes32_64.cpp:
+ (JSC::JIT::emit_op_push_with_scope):
+ (JSC::JIT::emit_op_push_name_scope):
+ * llint/LLIntSlowPaths.cpp:
+ (JSC::LLInt::LLINT_SLOW_PATH_DECL):
+ * llint/LowLevelInterpreter.asm:
+ Updated the operand indecies for the processing of the updated bytecodes.
+
+2014-10-31 Andreas Kling <akling@apple.com>
+
+ Make writes to RegExpObject.lastIndex cacheable.
+ <https://webkit.org/b/138255>
+
+ Reviewed by Geoffrey Garen.
+
+ We were neglecting to IC the puts to RegExpObject.lastIndex on Octane/regexp,
+ and ended up spending 4.5% of a time profile in operationPutByIdNonStrict.
+
+ ~3% progression on Octane/regexp.
+
+ * runtime/RegExpObject.cpp:
+ (JSC::regExpObjectSetLastIndexStrict):
+ (JSC::regExpObjectSetLastIndexNonStrict):
+ (JSC::RegExpObject::put):
+
+2014-10-31 Chris Dumez <cdumez@apple.com>
+
+ Fix a couple of warnings in JSC reported by clang static analyzer
+ https://bugs.webkit.org/show_bug.cgi?id=138240
+
+ Reviewed by Geoffrey Garen.
+
+ Fix a couple of warnings in JSC reported by clang static analyzer about
+ value stored in variables never being read. This is addressed by
+ reducing the scope of the variable or removing the variable entirely.
+
+ * dfg/DFGConstantFoldingPhase.cpp:
+ (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
+ * runtime/VM.cpp:
+ (JSC::VM::throwException):
+
+2014-10-30 Dana Burkart <dburkart@apple.com>
+
+ <rdar://problem/18821260> Prepare for the mysterious future
+
+ Reviewed by Lucas Forschler.
+
+ * Configurations/Base.xcconfig:
+ * Configurations/DebugRelease.xcconfig:
+ * Configurations/FeatureDefines.xcconfig:
+ * Configurations/Version.xcconfig:
+
+2014-10-30 Saam Barati <saambarati1@gmail.com>
+
+ AST Nodes should keep track of their end offset
+ https://bugs.webkit.org/show_bug.cgi?id=138143
+
+ Reviewed by Filip Pizlo.
+
+ AST nodes nodes now have an int property for their end text
+ offsets. This change lays some foundational work that will be
+ needed in profiling which basic blocks have executed.
+
+ * parser/ASTBuilder.h:
+ (JSC::ASTBuilder::setEndOffset):
+ * parser/Nodes.h:
+ (JSC::Node::endOffset):
+ (JSC::Node::setEndOffset):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseStatement):
+ (JSC::Parser<LexerType>::parseFunctionInfo):
+ (JSC::Parser<LexerType>::parseExpression):
+ (JSC::Parser<LexerType>::parseProperty):
+ * parser/Parser.h:
+ (JSC::Parser<LexerType>::parse):
+ * parser/SyntaxChecker.h:
+ (JSC::SyntaxChecker::operatorStackPop):
+
+2014-10-30 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Generate ObjC inspector protocol types and alternate dispatcher interfaces
+ https://bugs.webkit.org/show_bug.cgi?id=138048
+
+ Reviewed by Brian Burg.
+
+ Generate Objective-C interfaces for inspector protocol types, command, and event dispatchers.
+ This is very much like the InspectorProtocolTypes, BackendDispatchers, and FrontendDispatchers,
+ but with an ObjC spin on things.
+
+ The private API that clients would use is all encapsulated in RWIProtocol.h. It includes the
+ types interfaces, command handler protocol, and event dispatcher interface. Where possible the
+ API uses real enums, which hides the raw protocol enum strings from clients.
+
+ Inspector protocol types are, like InspectorProtocolObjects, built on top of an InspectorObject.
+ This offers the flexibilty of adding arbitrary key/values using the RWIProtocolJSONObject
+ interface, which may be required for certain protocol objects like "Network.Headers" which
+ have no fields, but expect arbitrary properties to be added.
+
+ Command handler protocols always have two callbacks. An error callback and a success callback.
+ The signature is very much like BackendDispatchers. In parameters are passed directly to
+ the selectors, and out parameters are defined by the success callback. It will be the client's
+ responsibility to call either of these callbacks to complete handling of a request.
+
+ Event dispatcher interfaces are straight forward, just packaging up the arguments and sending
+ the message to the frontend.
+
+ ObjC <-> Protocol conversion happens in each of the generated files. In type getters / setters,
+ in commands parameters and event parameters. For this to work we generate conversion helpers
+ for all enums, ObjC enum <-> protocol strings. For NSArray <-> InspectorArray there are some
+ static helpers to do the conversions. We do lose some type safety in these conversions.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/scripts/codegen/__init__.py:
+ * inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py:
+ (AlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
+ * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
+ (BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector):
+ (BackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
+ (BackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
+ * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
+ (BackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
+ (BackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
+ * inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
+ (FrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
+ * inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
+ (FrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
+ * inspector/scripts/codegen/generate_objective_c.py: Added.
+ (join_type_and_name):
+ (strip_comment_markers):
+ (remove_duplicate_from_str):
+ (ObjCTypeCategory):
+ (ObjCTypeCategory.category_of_type):
+ (ObjCGenerator):
+ (ObjCGenerator.identifier_to_objc_identifier):
+ (ObjCGenerator.objc_identifier_to_identifier):
+ (ObjCGenerator.should_generate_domain_types_filter):
+ (ObjCGenerator.should_generate_domain_types_filter.should_generate_domain_types):
+ (ObjCGenerator.should_generate_domain_command_handler_filter):
+ (ObjCGenerator.should_generate_domain_command_handler_filter.should_generate_domain_command_handler):
+ (ObjCGenerator.should_generate_domain_event_dispatcher_filter):
+ (ObjCGenerator.should_generate_domain_event_dispatcher_filter.should_generate_domain_event_dispatcher):
+ (ObjCGenerator.objc_name_for_type):
+ (ObjCGenerator.objc_enum_name_for_anonymous_enum_declaration):
+ (ObjCGenerator.objc_enum_name_for_anonymous_enum_member):
+ (ObjCGenerator.objc_enum_name_for_anonymous_enum_parameter):
+ (ObjCGenerator.objc_enum_name_for_non_anonymous_enum):
+ (ObjCGenerator.variable_name_prefix_for_domain):
+ (ObjCGenerator.objc_accessor_type_for_raw_name):
+ (ObjCGenerator.objc_type_for_raw_name):
+ (ObjCGenerator.objc_class_for_raw_name):
+ (ObjCGenerator.protocol_type_for_raw_name):
+ (ObjCGenerator.protocol_type_for_type):
+ (ObjCGenerator.objc_class_for_type):
+ (ObjCGenerator.objc_accessor_type_for_member):
+ (ObjCGenerator.objc_accessor_type_for_member_internal):
+ (ObjCGenerator.objc_type_for_member):
+ (ObjCGenerator.objc_type_for_member_internal):
+ (ObjCGenerator.objc_type_for_param):
+ (ObjCGenerator.objc_type_for_param_internal):
+ (ObjCGenerator.objc_protocol_export_expression_for_variable):
+ (ObjCGenerator.objc_protocol_import_expression_for_member):
+ (ObjCGenerator.objc_protocol_import_expression_for_parameter):
+ (ObjCGenerator.objc_protocol_import_expression_for_variable):
+ (ObjCGenerator.objc_to_protocol_expression_for_member):
+ (ObjCGenerator.protocol_to_objc_expression_for_member):
+ (ObjCGenerator.objc_setter_method_for_member):
+ (ObjCGenerator.objc_setter_method_for_member_internal):
+ (ObjCGenerator.objc_getter_method_for_member):
+ (ObjCGenerator.objc_getter_method_for_member_internal):
+ * inspector/scripts/codegen/generate_objective_c_backend_dispatcher_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
+ (ObjectiveCBackendDispatcherHeaderGenerator):
+ (ObjectiveCBackendDispatcherHeaderGenerator.output_filename):
+ (ObjectiveCBackendDispatcherHeaderGenerator.domains_to_generate):
+ (ObjectiveCBackendDispatcherHeaderGenerator.generate_output):
+ (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
+ (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations_for_domains):
+ (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
+ (ObjectiveCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
+ * inspector/scripts/codegen/generate_objective_c_backend_dispatcher_implementation.py: Added.
+ (ObjectiveCConfigurationImplementationGenerator):
+ (ObjectiveCConfigurationImplementationGenerator.__init__):
+ (ObjectiveCConfigurationImplementationGenerator.output_filename):
+ (ObjectiveCConfigurationImplementationGenerator.domains_to_generate):
+ (ObjectiveCConfigurationImplementationGenerator.generate_output):
+ (ObjectiveCConfigurationImplementationGenerator._generate_handler_implementation_for_domain):
+ (ObjectiveCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
+ (ObjectiveCConfigurationImplementationGenerator._generate_success_block_for_command):
+ (ObjectiveCConfigurationImplementationGenerator._generate_conversions_for_command):
+ (ObjectiveCConfigurationImplementationGenerator._generate_invocation_for_command):
+ * inspector/scripts/codegen/generate_objective_c_configuration_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
+ (ObjectiveCConfigurationHeaderGenerator):
+ (ObjectiveCConfigurationHeaderGenerator.output_filename):
+ (ObjectiveCConfigurationHeaderGenerator.generate_output):
+ (ObjectiveCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
+ (ObjectiveCConfigurationHeaderGenerator._generate_properties_for_domain):
+ * inspector/scripts/codegen/generate_objective_c_configuration_implementation.py: Added.
+ (ObjectiveCBackendDispatcherImplementationGenerator):
+ (ObjectiveCBackendDispatcherImplementationGenerator.__init__):
+ (ObjectiveCBackendDispatcherImplementationGenerator.output_filename):
+ (ObjectiveCBackendDispatcherImplementationGenerator.generate_output):
+ (ObjectiveCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
+ (ObjectiveCBackendDispatcherImplementationGenerator._generate_ivars):
+ (ObjectiveCBackendDispatcherImplementationGenerator._generate_dealloc):
+ (ObjectiveCBackendDispatcherImplementationGenerator._generate_handler_setter_for_domain):
+ (ObjectiveCBackendDispatcherImplementationGenerator._generate_event_dispatcher_getter_for_domain):
+ * inspector/scripts/codegen/generate_objective_c_conversion_helpers.py: Added.
+ (add_whitespace_separator):
+ (ObjectiveCConversionHelpersGenerator):
+ (ObjectiveCConversionHelpersGenerator.__init__):
+ (ObjectiveCConversionHelpersGenerator.output_filename):
+ (ObjectiveCConversionHelpersGenerator.domains_to_generate):
+ (ObjectiveCConversionHelpersGenerator.generate_output):
+ (ObjectiveCConversionHelpersGenerator._generate_enum_conversion_functions):
+ (ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_declaration):
+ (ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_member):
+ (ObjectiveCConversionHelpersGenerator._generate_anonymous_enum_conversion_for_parameter):
+ (ObjectiveCConversionHelpersGenerator._generate_enum_objc_to_protocol_string):
+ (ObjectiveCConversionHelpersGenerator._generate_enum_from_protocol_string):
+ * inspector/scripts/codegen/generate_objective_c_frontend_dispatcher_implementation.py: Added.
+ (ObjectiveCFrontendDispatcherImplementationGenerator):
+ (ObjectiveCFrontendDispatcherImplementationGenerator.__init__):
+ (ObjectiveCFrontendDispatcherImplementationGenerator.output_filename):
+ (ObjectiveCFrontendDispatcherImplementationGenerator.domains_to_generate):
+ (ObjectiveCFrontendDispatcherImplementationGenerator.generate_output):
+ (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
+ (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event):
+ (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_signature):
+ (ObjectiveCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
+ * inspector/scripts/codegen/generate_objective_c_header.py: Added.
+ (add_whitespace_separator):
+ (ObjectiveCHeaderGenerator):
+ (ObjectiveCHeaderGenerator.__init__):
+ (ObjectiveCHeaderGenerator.output_filename):
+ (ObjectiveCHeaderGenerator.generate_output):
+ (ObjectiveCHeaderGenerator._generate_forward_declarations):
+ (ObjectiveCHeaderGenerator._generate_enums):
+ (ObjectiveCHeaderGenerator._generate_types):
+ (ObjectiveCHeaderGenerator._generate_anonymous_enum_for_declaration):
+ (ObjectiveCHeaderGenerator._generate_anonymous_enum_for_member):
+ (ObjectiveCHeaderGenerator._generate_anonymous_enum_for_parameter):
+ (ObjectiveCHeaderGenerator._generate_enum):
+ (ObjectiveCHeaderGenerator._generate_enum.NS_ENUM):
+ (ObjectiveCHeaderGenerator._generate_type_interface):
+ (ObjectiveCHeaderGenerator._generate_init_method_for_required_members):
+ (ObjectiveCHeaderGenerator._generate_member_property):
+ (ObjectiveCHeaderGenerator._generate_command_protocols):
+ (ObjectiveCHeaderGenerator._generate_single_command_protocol):
+ (ObjectiveCHeaderGenerator._callback_block_for_command):
+ (ObjectiveCHeaderGenerator._generate_event_interfaces):
+ (ObjectiveCHeaderGenerator._generate_single_event_interface):
+ * inspector/scripts/codegen/generate_objective_c_internal_header.py: Copied from Source/JavaScriptCore/inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py.
+ (ObjectiveCTypesInternalHeaderGenerator):
+ (ObjectiveCTypesInternalHeaderGenerator.output_filename):
+ (ObjectiveCTypesInternalHeaderGenerator.generate_output):
+ (ObjectiveCTypesInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
+ * inspector/scripts/codegen/generate_objective_c_types_implementation.py: Added.
+ (add_whitespace_separator):
+ (ObjectiveCTypesImplementationGenerator):
+ (ObjectiveCTypesImplementationGenerator.__init__):
+ (ObjectiveCTypesImplementationGenerator.output_filename):
+ (ObjectiveCTypesImplementationGenerator.domains_to_generate):
+ (ObjectiveCTypesImplementationGenerator.generate_output):
+ (ObjectiveCTypesImplementationGenerator.generate_type_implementations):
+ (ObjectiveCTypesImplementationGenerator.generate_type_implementation):
+ (ObjectiveCTypesImplementationGenerator._generate_init_method_for_required_members):
+ (ObjectiveCTypesImplementationGenerator._generate_setter_for_member):
+ (ObjectiveCTypesImplementationGenerator._generate_getter_for_member):
+ * inspector/scripts/codegen/generate_protocol_types_header.py:
+ (ProtocolTypesHeaderGenerator._generate_forward_declarations):
+ (_generate_typedefs_for_domain):
+ (_generate_builders_for_domain):
+ * inspector/scripts/codegen/generator.py:
+ (Generator.wrap_with_guard_for_domain):
+ (Generator):
+ (Generator.wrap_with_guard):
+ * inspector/scripts/codegen/generator_templates.py:
+ (AlternateInspector):
+ (ObjCInspector):
+ * inspector/scripts/codegen/models.py:
+ (Framework.fromString):
+ (Frameworks):
+ * inspector/scripts/generate-inspector-protocol-bindings.py:
+ (generate_from_specification):
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+
+2014-10-30 Andreas Kling <akling@apple.com>
+
+ Unreviewed assertion fix.
+
+ RegExpCachedResult::m_reified is now the dedicated member that knows whether
+ the result was reified into an array or not. Check that instead of m_result
+ which is now single-purpose.
+
+ * runtime/RegExpCachedResult.cpp:
+ (JSC::RegExpCachedResult::setInput):
+
+2014-10-29 Andreas Kling <akling@apple.com>
+
+ Use plain JSArray for RegExp matches instead of a lazily populated custom object.
+ <https://webkit.org/b/138191>
+
+ Reviewed by Geoffrey Garen.
+
+ We're already offering two RegExp matching APIs, one that collects subpattern
+ matches (exec), and one that simply tests for a match (test).
+ Given that, it was pretty overkill to lazily populate the resulting array of
+ matches, since the user could simply use test() if they didn't need them.
+
+ This allows the JIT to generate better code for RegExp match arrays, and also
+ enables some fast paths in the JSC runtime that check if an object isJSArray().
+
+ Looks like ~1.5% improvement on Octane/regexp according to run-jsc-benchmarks.
+
+ * jit/Repatch.cpp:
+ (JSC::tryCacheGetByID):
+ * runtime/JSArray.h:
+ (JSC::createArrayButterflyWithExactLength): Deleted.
+ * runtime/JSGlobalObject.cpp:
+ (JSC::JSGlobalObject::init):
+ * runtime/RegExpCachedResult.cpp:
+ (JSC::RegExpCachedResult::visitChildren):
+ (JSC::RegExpCachedResult::lastResult):
+ (JSC::RegExpCachedResult::leftContext):
+ (JSC::RegExpCachedResult::rightContext):
+ * runtime/RegExpCachedResult.h:
+ (JSC::RegExpCachedResult::RegExpCachedResult):
+ (JSC::RegExpCachedResult::record):
+ (JSC::RegExpCachedResult::input):
+ * runtime/RegExpConstructor.cpp:
+ (JSC::RegExpConstructor::getBackref):
+ (JSC::RegExpConstructor::getLastParen):
+ (JSC::RegExpConstructor::getLeftContext):
+ (JSC::RegExpConstructor::getRightContext):
+ * runtime/RegExpMatchesArray.cpp:
+ (JSC::createRegExpMatchesArray):
+ (JSC::RegExpMatchesArray::RegExpMatchesArray): Deleted.
+ (JSC::RegExpMatchesArray::create): Deleted.
+ (JSC::RegExpMatchesArray::finishCreation): Deleted.
+ (JSC::RegExpMatchesArray::visitChildren): Deleted.
+ (JSC::RegExpMatchesArray::reifyAllProperties): Deleted.
+ (JSC::RegExpMatchesArray::reifyMatchProperty): Deleted.
+ (JSC::RegExpMatchesArray::leftContext): Deleted.
+ (JSC::RegExpMatchesArray::rightContext): Deleted.
+ * runtime/RegExpMatchesArray.h:
+ (JSC::RegExpMatchesArray::createStructure): Deleted.
+ (JSC::RegExpMatchesArray::reifyAllPropertiesIfNecessary): Deleted.
+ (JSC::RegExpMatchesArray::reifyMatchPropertyIfNecessary): Deleted.
+ (JSC::RegExpMatchesArray::getOwnPropertySlot): Deleted.
+ (JSC::RegExpMatchesArray::getOwnPropertySlotByIndex): Deleted.
+ (JSC::RegExpMatchesArray::put): Deleted.
+ (JSC::RegExpMatchesArray::putByIndex): Deleted.
+ (JSC::RegExpMatchesArray::deleteProperty): Deleted.
+ (JSC::RegExpMatchesArray::deletePropertyByIndex): Deleted.
+ (JSC::RegExpMatchesArray::getOwnPropertyNames): Deleted.
+ (JSC::RegExpMatchesArray::defineOwnProperty): Deleted.
+ (JSC::isRegExpMatchesArray): Deleted.
+ * runtime/RegExpObject.cpp:
+ (JSC::RegExpObject::exec):
+ * runtime/StringPrototype.cpp:
+ (JSC::stringProtoFuncMatch):
+
+2014-10-29 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Fix Type Dependency Issues
+ https://bugs.webkit.org/show_bug.cgi?id=125664
+
+ Reviewed by Brian Burg.
+
+ Now that all JSON protocol files are processed together again
+ in r174892, we can remove the duplicated types which were only
+ needed when the domains were split.
+
+ * inspector/protocol/Console.json:
+ * inspector/protocol/Runtime.json:
+
+2014-10-28 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r175249.
+ https://bugs.webkit.org/show_bug.cgi?id=138138
+
+ Appears to be failing some JS tests (Requested by mlam_ on
+ #webkit).
+
+ Reverted changeset:
+
+ "Holes are not copied properly when Arrays change shape to
+ ArrayStorage type."
+ https://bugs.webkit.org/show_bug.cgi?id=138118
+ http://trac.webkit.org/changeset/175249
+
+2014-10-27 Mark Lam <mark.lam@apple.com>
+
+ Holes are not copied properly when Arrays change shape to ArrayStorage type.
+ <https://webkit.org/b/138118>
+
+ Reviewed by Mark Hahnenberg.
+
+ When we convert non-ArrayStorage typed arrays into ArrayStorage typed arrays,
+ we skipped the holes. As a result, the slots in the ArrayStorage vector that
+ corresponds to those holes are uninitialize. This is now fixed.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::convertUndecidedToArrayStorage):
+ (JSC::JSObject::convertInt32ToArrayStorage):
+ (JSC::JSObject::convertDoubleToArrayStorage):
+ (JSC::JSObject::convertContiguousToArrayStorage):
+
+2014-10-27 Mark Lam <mark.lam@apple.com>
+
+ Crash when attempting to perform array iteration on a non-array with numeric keys not initialized.
+ <https://webkit.org/b/137814>
+
+ 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-27 Mark Lam <mark.lam@apple.com>
+
+ Simplified some JSObject methods for converting arrays to ArrayStorage shape.
+ <https://webkit.org/b/138119>
+
+ Reviewed by Filip Pizlo.
+
+ Currently, for each Undecided, Int32, Double, and Contiguous array shapes,
+ there are 3 JSObject methods to convert them to ArrayStorage shape:
+ ArrayStorage* convert<shape>ToArrayStorage(VM&, NonPropertyTransition, unsigned neededLength);
+ ArrayStorage* convert<shape>ToArrayStorage(VM&, NonPropertyTransition);
+ ArrayStorage* convert<shape>ToArrayStorage(VM&);
+
+ However, the neededLength that is passed is always m_butterfly->vectorLength().
+ Hence, the method that takes a neededLength is really not needed. This patch
+ removes this unneeded verbosity.
+
+ * runtime/JSObject.cpp:
+ (JSC::JSObject::convertUndecidedToArrayStorage):
+ (JSC::JSObject::convertInt32ToArrayStorage):
+ - Also reordered the placement of the DeferGC statement so this Int32 function
+ will look more similar to the others.
+ (JSC::JSObject::convertDoubleToArrayStorage):
+ (JSC::JSObject::convertContiguousToArrayStorage):
+ * runtime/JSObject.h:
+
+2014-10-25 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: timelines should not count time elapsed while paused in the debugger
+ https://bugs.webkit.org/show_bug.cgi?id=136351
+
+ Unreviewed, follow-up fix after r175203. The debugger agent should not assume
+ that the inspector environment's stopwatch has already been started.
+
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::didPause): Check if the stopwatch isActive() before stopping.
+
+2014-10-18 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Inspector: timelines should not count time elapsed while paused in the debugger
+ https://bugs.webkit.org/show_bug.cgi?id=136351
+
+ Reviewed by Timothy Hatcher.
+
+ Now that we have a stopwatch to provide pause-aware timing data, we can remove the
+ profiler's handling of debugger pause/continue callbacks. The debugger agent accounts
+ for suspended execution by pausing and resuming the stopwatch.
+
+ * API/JSProfilerPrivate.cpp:
+ (JSStartProfiling): Use a fresh stopwatch when profiling from the JSC API.
+ * inspector/InspectorEnvironment.h:
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+ (Inspector::JSGlobalObjectInspectorController::executionStopwatch):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/ScriptDebugServer.cpp:
+ (Inspector::ScriptDebugServer::handlePause):
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::InspectorDebuggerAgent::didPause):
+ (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
+ (Inspector::InspectorDebuggerAgent::didContinue):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * profiler/LegacyProfiler.cpp:
+ (JSC::LegacyProfiler::profiler): Use nullptr.
+ (JSC::LegacyProfiler::startProfiling): Hand off a stopwatch to the profile generator.
+ (JSC::LegacyProfiler::stopProfiling): Use nullptr.
+ (JSC::LegacyProfiler::didPause): Deleted.
+ (JSC::LegacyProfiler::didContinue): Deleted.
+ * profiler/LegacyProfiler.h:
+ * profiler/Profile.cpp: The root node should always have a start time of 0.0.
+ (JSC::Profile::Profile):
+ * profiler/ProfileGenerator.cpp: Remove debugger pause/continue callbacks and the
+ timestamp member that was used to track time elapsed by the debugger. Just use the
+ stopwatch's elapsed times to generate start/elapsed times for function calls.
+
+ (JSC::ProfileGenerator::create):
+ (JSC::ProfileGenerator::ProfileGenerator):
+ (JSC::AddParentForConsoleStartFunctor::operator()): The parent node of |console.profile|
+ should have a start time of 0.0, since it represents the starting node of profiling.
+
+ (JSC::ProfileGenerator::beginCallEntry):
+ (JSC::ProfileGenerator::endCallEntry):
+ (JSC::ProfileGenerator::didPause): Deleted.
+ (JSC::ProfileGenerator::didContinue): Deleted.
+ * profiler/ProfileGenerator.h:
+
+2014-10-24 Mark Lam <mark.lam@apple.com>
+
+ Simplified IndexingType's hasAnyArrayStorage().
+ <https://webkit.org/b/138051>
+
+ Reviewed by Michael Saboff.
+
+ IndexingType's hasAnyArrayStorage() currently does subtraction of ArrayStorageShape
+ with the purpose of making non-ArrayStorage types underflow (with that subtraction)
+ and have a result that exceeds SlowPutArrayStorageShape. What it is doing is
+ basically checking for a shape value that is greater equal to ArrayStorageShape.
+ We can just simplify the code as such.
+
+ Also added a comment to describe the structure of the bits in IndexingType.
+
+ * runtime/IndexingType.h:
+ (JSC::hasAnyArrayStorage):
+
+2014-10-23 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Provide a way to have alternate inspector agents
+ https://bugs.webkit.org/show_bug.cgi?id=137901
+
+ Reviewed by Brian Burg.
+
+ Provide a way to use alternate inspector agents debugging a JSContext.
+ Expose a very slim private API that a client could use to know when
+ an inspector has connected/disconnected, and a way to register its
+ augmentative agents.
+
+ * Configurations/FeatureDefines.xcconfig:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ New feature guard. New files.
+
+ * API/JSContextRef.cpp:
+ (JSGlobalContextGetAugmentableInspectorController):
+ * API/JSContextRefInspectorSupport.h: Added.
+ Access to the private interface from a JSContext.
+
+ * inspector/JSGlobalObjectInspectorController.cpp:
+ (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
+ (Inspector::JSGlobalObjectInspectorController::connectFrontend):
+ (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
+ * inspector/JSGlobalObjectInspectorController.h:
+ * inspector/augmentable/AugmentableInspectorController.h: Added.
+ (Inspector::AugmentableInspectorController::~AugmentableInspectorController):
+ (Inspector::AugmentableInspectorController::connected):
+ * inspector/augmentable/AugmentableInspectorControllerClient.h: Added.
+ (Inspector::AugmentableInspectorControllerClient::~AugmentableInspectorControllerClient):
+ * inspector/augmentable/AlternateDispatchableAgent.h: Added.
+ (Inspector::AlternateDispatchableAgent::AlternateDispatchableAgent):
+ Provide the private APIs a client could use to add alternate agents using alternate backend dispatchers.
+
+ * inspector/scripts/codegen/__init__.py:
+ * inspector/scripts/generate-inspector-protocol-bindings.py:
+ (generate_from_specification):
+ New includes, and use the new generator.
+
+ * inspector/scripts/codegen/generate_alternate_backend_dispatcher_header.py: Added.
+ (AlternateBackendDispatcherHeaderGenerator):
+ (AlternateBackendDispatcherHeaderGenerator.__init__):
+ (AlternateBackendDispatcherHeaderGenerator.output_filename):
+ (AlternateBackendDispatcherHeaderGenerator.generate_output):
+ (AlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
+ (AlternateBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
+ Generate the abstract AlternateInspectorBackendDispatcher interfaces.
+
+ * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
+ (BackendDispatcherHeaderGenerator.generate_output):
+ (BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains):
+ (BackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.AlternateInspector):
+ Forward declare alternate dispatchers, and allow setting an alternate dispatcher on a domain dispatcher.
+
+ * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
+ (BackendDispatcherImplementationGenerator.generate_output):
+ (BackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
+ Check for and dispatch on an AlternateInspectorBackendDispatcher if there is one for this domain.
+
+ * inspector/scripts/codegen/generator_templates.py:
+ (AlternateInspectorBackendDispatcher):
+ (AlternateInspector):
+ Template boilerplate for prelude and postlude.
+
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ Rebaseline tests.
+
+2014-10-23 Michael Saboff <msaboff@apple.com>
+
+ offsets.rb:183:in `buildOffsetsMap': unhandled exception - is offlineasm dependency tracking broken? (132668)
+ https://bugs.webkit.org/show_bug.cgi?id=138017
+
+ Reviewed by Mark Lam.
+
+ Removed from the nput file $(SRCROOT)/llint/LowLevelAssembler.asm and output file
+ $(BUILT_PRODUCTS_DIR)/LLIntOffsets/LLIntDesiredOffsets.h from the Generate Derived Sources
+ build phase in the LLInt Offset target. There is no need for Xcode to do any dependency
+ checking with these files as the ruby script offlineasm/generate_offset_extractor.rb will
+ do that for us.
+
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+
+2014-10-23 Michael Saboff <msaboff@apple.com>
+
+ Change CallFrame::lexicalGlobalObject() to use Callee instead of JSScope
+ https://bugs.webkit.org/show_bug.cgi?id=136901
+
+ Reviewed by Mark Lam.
+
+ Implement ExecState::lexicalGlobalObject() using Callee.
+
+ * runtime/JSScope.h:
+ (JSC::ExecState::lexicalGlobalObject):
+
+2014-10-22 Milan Crha <mcrha@redhat.com>
+
+ Prefix isnan() with std::.
+ <https://webkit.org/b/137966>.
+
+ Reviewed by Carlos Garcia Campos.
+
+ * profiler/ProfileNode.h:
+ (JSC::ProfileNode::Call::setStartTime):
+ (JSC::ProfileNode::Call::setElapsedTime):
+
+2014-10-22 Mark Lam <mark.lam@apple.com>
+
+ Refactoring to simplify some code in DatePrototype.cpp.
+ <https://webkit.org/b/137997>
+
+ Reviewed by Filip Pizlo.
+
+ A bunch of functions in DatePrototype.cpp have the pattern of loading a
+ constant into a local variable only to pass it to a callee function
+ immediately after. There is no other use for that variable. This adds
+ additional verbosity with no added benefit.
+
+ This patch refactors those functions to just pass the constant arg directly.
+
+ * runtime/DatePrototype.cpp:
+ (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):
+
+2014-10-22 Byungseon Shin <sun.shin@lge.com>
+
+ 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-10-22 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Fix generator importing of protocol type "any", treat as value
+ https://bugs.webkit.org/show_bug.cgi?id=137931
+
+ Reviewed by Timothy Hatcher.
+
+ Treat incoming "any" objects as InspectorValues, which can be any type.
+ Add the necessary boilerplate to import.
+
+ * inspector/InspectorBackendDispatcher.cpp:
+ (Inspector::AsMethodBridges::asValue):
+ (Inspector::InspectorBackendDispatcher::getValue):
+ * inspector/InspectorBackendDispatcher.h:
+ * inspector/scripts/codegen/generator.py:
+ (Generator.keyed_get_method_for_type):
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+
+2014-10-22 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(r174996): Broke C_LOOP
+ https://bugs.webkit.org/show_bug.cgi?id=137971
+
+ Reviewed by Mark Lam.
+
+ Removed incorrect move to cfr (CallFrameRegister) before we make the call to a native function.
+ After r174996, the source register for the move contained garbage causing the crash. The move
+ to cfr before making the call to the native function is wrong and should have been removed
+ some time ago. This brings the ARM64 / C_LOOP code path inline with the other CPU paths.
+ Tested on ARM64 as well as a C_LOOP build.
+
+ * llint/LowLevelInterpreter64.asm:
+
+2014-10-21 Mark Lam <mark.lam@apple.com>
+
+ Remove erroneous canUseJIT() in the intrinsics version of JITThunks::hostFunctionStub().
+ <https://webkit.org/b/137937>
+
+ Reviewed by Michael Saboff.
+
+ This version of JITThunks::hostFunctionStub() can only be called from the intrinsics
+ version of VM::getHostFunction() which asserts canUseJIT(). Hence, we can eliminate
+ the canUseJIT() check in JITThunks::hostFunctionStub(). We don't handle the
+ !canUseJIT() case properly there anyway.
+
+ * jit/JITThunks.cpp:
+ (JSC::JITThunks::hostFunctionStub):
+
+2014-10-21 Michael Saboff <msaboff@apple.com>
+
+ Add operator==(PropertyName, const char*)
+ https://bugs.webkit.org/show_bug.cgi?id=137925
+
+ Reviewed by Mark Lam.
+
+ * runtime/PropertyName.h:
+ (JSC::operator==): Added to simplify comparison with string literals.
+
+
+2014-10-21 Michael Saboff <msaboff@apple.com>
+
+ Change native call frames to use the scope from their Callee instead of their caller's scope
+ https://bugs.webkit.org/show_bug.cgi?id=137907
+
+ Reviewed by Mark Lam.
+
+ Changed setting of scope for native CallFrames to use the scope associated with the
+ Callee instead of the caller's scope.
+
+ * jit/ThunkGenerators.cpp:
+ (JSC::nativeForGenerator):
+ * llint/LowLevelInterpreter32_64.asm:
+ * llint/LowLevelInterpreter64.asm:
+
+2014-10-21 Tibor Meszaros <tmeszaros.u-szeged@partner.samsung.com>
+
+ Add missing ENABLE(FTL_NATIVE_CALL_INLINING) guard to BundlePath.cpp after r174940
+ https://bugs.webkit.org/show_bug.cgi?id=137924
+
+ Reviewed by Csaba Osztrogonác.
+
+ * runtime/BundlePath.cpp:
+
+2014-10-21 Dániel Bátyai <dbatyai.u-szeged@partner.samsung.com>
+
+ Fix FTL Native Inlining for EFL
+ https://bugs.webkit.org/show_bug.cgi?id=137774
+
+ Reviewed by Michael Saboff.
+
+ Added required functionality for Native Inlining to EFL, and fixed a bug/typo in the original code,
+ which caused incorrect memory allocation.
+
+ * CMakeLists.txt:
+ * create-llvm-ir-from-source-file.py: Added.
+ * create-symbol-table-index.py: Added.
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::lower):
+ (JSC::FTL::LowerDFGToLLVM::getModuleByPathForSymbol):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForAvailability):
+ (JSC::FTL::LowerDFGToLLVM::exitValueForNode):
+ * runtime/BundlePath.cpp: Added.
+ (JSC::bundlePath):
+ * runtime/JSDataViewPrototype.cpp:
+ (JSC::getData):
+ (JSC::setData):
+ * runtime/MathObject.cpp:
+
+2014-10-21 Milan Crha <mcrha@redhat.com>
+
+ Move JSC::MacroAssemblerX86Common::s_sse2CheckState definition to MacroAssemblerX86Common.cpp.
+ <https://webkit.org/b/137807>
+
+ Reviewed by Csaba Osztrogonác.
+
+ * assembler/MacroAssemblerX86Common.cpp:
+ * jit/JIT.cpp:
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Unreviewed add back copyright line that was accidentally removed.
+
+ * inspector/scripts/codegen/generator_templates.py:
+ (GeneratorTemplates):
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: InspectorBackendCommands should include when to activate particular domains
+ https://bugs.webkit.org/show_bug.cgi?id=137753
+
+ Reviewed by Timothy Hatcher.
+
+ Add an availability property to domains that only activate for
+ particular debuggable types. If missing, the domain is always
+ activated. Otherwise it must be a debuggable type string.
+ When a frontend is opened for that debuggable type, the domain
+ will be activated.
+
+ * inspector/scripts/codegen/models.py:
+ (Protocol.parse_domain):
+ (Domain.__init__):
+ (Domains):
+ Parse and validate the Domain's "availability" property.
+
+ * inspector/scripts/codegen/generate_backend_commands.py:
+ (BackendCommandsGenerator.generate_domain):
+ Emit InspectorBackend.activateDomain with debuggable type filter.
+
+ * inspector/protocol/ApplicationCache.json:
+ * inspector/protocol/CSS.json:
+ * inspector/protocol/DOM.json:
+ * inspector/protocol/DOMDebugger.json:
+ * inspector/protocol/DOMStorage.json:
+ * inspector/protocol/Database.json:
+ * inspector/protocol/IndexedDB.json:
+ * inspector/protocol/LayerTree.json:
+ * inspector/protocol/Network.json:
+ * inspector/protocol/Page.json:
+ * inspector/protocol/Replay.json:
+ * inspector/protocol/Timeline.json:
+ * inspector/protocol/Worker.json:
+ These domains only activate for Web debuggables.
+
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ Update existing tests that now have activate output.
+
+ * inspector/scripts/tests/expected/fail-on-domain-availability.json-error: Added.
+ * inspector/scripts/tests/fail-on-domain-availability.json: Added.
+ Add a test for "availability" validation.
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ [Win] Build fix for generated inspector files.
+
+ Rubberstamped by Brent Fulgham.
+
+ * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
+ (BackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
+ * inspector/scripts/codegen/generator_templates.py:
+ (GeneratorTemplates):
+
+2014-10-20 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Unreviewed build fix.
+
+ We need to (1) pass the 'windows' argument to our script for checking feature definitions,
+ and (2) we must use Cwd::realpath on our path input arguments to avoid Cygwin and Windows
+ getting confused about path separators versus escape characters.
+
+
+ * JavaScriptCore.vcxproj/build-generated-files.pl:
+
+2014-10-20 Mark Lam <mark.lam@apple.com>
+
+ [Follow up] Web Process crash when starting the web inspector after r174025.
+ <https://webkit.org/b/137340>
+
+ Reviewed by Geoffrey Garen.
+
+ Applied Geoff's feedback to clean up some code for better clarity after
+ r174856.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::insertCheck):
+ * dfg/DFGInsertionSet.h:
+ (JSC::DFG::InsertionSet::insertOutOfOrder):
+
+2014-10-20 Mark Lam <mark.lam@apple.com>
+
+ Factor out JITCode::typeName() for debugging use.
+ <https://webkit.org/b/137888>
+
+ Reviewed by Geoffrey Garen.
+
+ JITCode's printInternal() currently decodes the JITType into a string and
+ prints it. This change factors out the part that decodes the JITType into
+ JITCode::typeName() so that we can call it from lldb while debugging to
+ quickly decode a JITType value.
+
+ * jit/JITCode.cpp:
+ (JSC::JITCode::typeName):
+ (WTF::printInternal):
+ * jit/JITCode.h:
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Unreviewed Windows Build Fix #2 after r174892.
+
+ * JavaScriptCore.vcxproj/build-generated-files.pl:
+ Define FEATURE_DEFINES for JavaScriptCore's DerivedSources.make.
+ This uses the same technique as WebCore.
+
+2014-10-20 Mark Lam <mark.lam@apple.com>
+
+ Fix placement of a few items in vcxproj ItemGroups.
+ <https://webkit.org/b/137886>
+
+ Reviewed by Geoffrey Garen.
+
+ https://webkit.org/b/137873 is likely a cut-and-paste error that manifested
+ because we had ClCompile and ClInclude entries mixed up in the wrong ItemGroups.
+ We should fix these so that ClCompile entries are in the ClCompile ItemGroup,
+ and ClInclude entries in the ClInclude ItemGroup. This will help reduce the
+ chance of future cut-and-paste errors of this nature.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Unreviewed Windows Build Fix after r174892.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ Update file name to the new generated file name.
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Rename generated Inspector.json to CombinedDomains.json to prevent name collisions
+ https://bugs.webkit.org/show_bug.cgi?id=137825
+
+ Reviewed by Timothy Hatcher.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/copy-files.cmd:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ * inspector/protocol/Inspector.json: Renamed from Source/JavaScriptCore/inspector/protocol/InspectorDomain.json.
+
+2014-10-20 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Generate all Inspector domains together in JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=137748
+
+ Reviewed by Brian Burg.
+
+ * inspector/protocol/ApplicationCache.json: Renamed from Source/WebCore/inspector/protocol/ApplicationCache.json.
+ * inspector/protocol/CSS.json: Renamed from Source/WebCore/inspector/protocol/CSS.json.
+ * inspector/protocol/DOM.json: Renamed from Source/WebCore/inspector/protocol/DOM.json.
+ * inspector/protocol/DOMDebugger.json: Renamed from Source/WebCore/inspector/protocol/DOMDebugger.json.
+ * inspector/protocol/DOMStorage.json: Renamed from Source/WebCore/inspector/protocol/DOMStorage.json.
+ * inspector/protocol/Database.json: Renamed from Source/WebCore/inspector/protocol/Database.json.
+ * inspector/protocol/IndexedDB.json: Renamed from Source/WebCore/inspector/protocol/IndexedDB.json.
+ * inspector/protocol/LayerTree.json: Renamed from Source/WebCore/inspector/protocol/LayerTree.json.
+ * inspector/protocol/Network.json: Renamed from Source/WebCore/inspector/protocol/Network.json.
+ * inspector/protocol/Page.json: Renamed from Source/WebCore/inspector/protocol/Page.json.
+ * inspector/protocol/Replay.json: Renamed from Source/WebCore/inspector/protocol/Replay.json.
+ * inspector/protocol/Timeline.json: Renamed from Source/WebCore/inspector/protocol/Timeline.json.
+ * inspector/protocol/Worker.json: Renamed from Source/WebCore/inspector/protocol/Worker.json.
+ Move all protocol files into this directory.
+
+ * inspector/InspectorProtocolTypesBase.h: Renamed from Source/JavaScriptCore/inspector/InspectorProtocolTypes.h.
+ Renamed the base types file to not clash with the generated types file.
+
+ * CMakeLists.txt:
+ * DerivedSources.make:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+ * JavaScriptCore.vcxproj/copy-files.cmd:
+ * JavaScriptCore.xcodeproj/project.pbxproj:
+ Update build phases for new JSON files and new filenames.
+
+ * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
+ * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
+ * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
+ * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
+ * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
+ * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
+ * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
+ * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
+ * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
+ * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
+ Updated names of things now that prefixes are no longer needed.
+
+ * inspector/ConsoleMessage.h:
+ * inspector/ContentSearchUtilities.cpp:
+ * inspector/ContentSearchUtilities.h:
+ * inspector/InjectedScript.h:
+ * inspector/InjectedScriptBase.h:
+ * inspector/ScriptCallFrame.h:
+ * inspector/ScriptCallStack.h:
+ * inspector/agents/InspectorAgent.h:
+ * inspector/agents/InspectorConsoleAgent.h:
+ * inspector/agents/InspectorDebuggerAgent.cpp:
+ (Inspector::breakpointActionTypeForString):
+ * inspector/agents/InspectorDebuggerAgent.h:
+ * inspector/agents/InspectorRuntimeAgent.h:
+ * runtime/TypeProfiler.cpp:
+ * runtime/TypeSet.cpp:
+ Update includes and update a few function names that are generated.
+
+ * inspector/scripts/codegen/generate_protocol_types_header.py:
+ (ProtocolTypesHeaderGenerator.output_filename):
+ (ProtocolTypesHeaderGenerator.generate_output):
+ Include an export macro for type string constants defined in the implementation file.
+
+ * inspector/scripts/codegen/generate_backend_commands.py:
+ (BackendCommandsGenerator.output_filename):
+ * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
+ (BackendDispatcherHeaderGenerator.output_filename):
+ (BackendDispatcherHeaderGenerator.generate_output):
+ * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
+ (BackendDispatcherImplementationGenerator.output_filename):
+ (BackendDispatcherImplementationGenerator.generate_output):
+ (BackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
+ (BackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
+ * inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
+ (FrontendDispatcherHeaderGenerator.output_filename):
+ (FrontendDispatcherHeaderGenerator.generate_output):
+ * inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
+ (FrontendDispatcherImplementationGenerator.output_filename):
+ (FrontendDispatcherImplementationGenerator.generate_output):
+ (FrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
+ (_generate_class_for_object_declaration):
+ (_generate_builder_setter_for_member):
+ (_generate_unchecked_setter_for_member):
+ * inspector/scripts/codegen/generate_protocol_types_implementation.py:
+ (ProtocolTypesImplementationGenerator.output_filename):
+ (ProtocolTypesImplementationGenerator.generate_output):
+ (ProtocolTypesImplementationGenerator._generate_enum_mapping):
+ * inspector/scripts/codegen/models.py:
+ (Framework.fromString):
+ (Frameworks):
+ * inspector/scripts/generate-inspector-protocol-bindings.py:
+ Simplify generator now that prefixes are no longer needed. This updates
+ filenames, includes, and the list of supported directories.
+
+2014-10-20 Csaba Osztrogonác <ossy@webkit.org>
+
+ Remove obsolete comments after r99798
+ https://bugs.webkit.org/show_bug.cgi?id=137871
+
+ Reviewed by Darin Adler.
+
+ r99798 removed the comment in MacroAssemblerARMv7::supportsFloatingPointTruncate(),
+ so we should remove the stale references to this removed comment.
+
+ * assembler/MacroAssemblerX86.h:
+ * assembler/MacroAssemblerX86_64.h:
+
+2014-10-20 Csaba Osztrogonác <ossy@webkit.org>
+
+ MacroAssemblerX86Common.cpp should be built on Windows too
+ https://bugs.webkit.org/show_bug.cgi?id=137873
+
+ Reviewed by Brent Fulgham.
+
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
+ * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
+
+2014-10-20 Csaba Osztrogonác <ossy@webkit.org>
+
+ [cmake] Remove duplicated source files
+ https://bugs.webkit.org/show_bug.cgi?id=137875
+
+ Reviewed by Gyuyoung Kim.
+
+ * CMakeLists.txt:
+
+2014-10-18 Brian J. Burg <burg@cs.washington.edu>
+
+ Web Replay: code generator shouldn't complain about enums without a storage type if they are in an enclosing scope
+ https://bugs.webkit.org/show_bug.cgi?id=137084
+
+ Reviewed by Joseph Pecoraro.
+
+ In order to generate encode/decode method declarations without pulling in lots of headers,
+ the generator must forward declare enums (for enum classes or enums with explicit sizes).
+
+ Change the generator to not require an explicit size if an enum is declared inside a struct
+ or class definition. In that case, it must pull in headers since scoped enums can't be
+ forward declared.
+
+ This patch also fixes some chained if-statements that should be if-else statements.
+
+ Test: updated replay/scripts/tests/generate-enum-encoding-helpers.json to cover the new case.
+
+ * replay/scripts/CodeGeneratorReplayInputs.py:
+ (InputsModel.parse_type_with_framework_name.is):
+ (InputsModel.parse_type_with_framework_name.is.must):
+ (Generator.generate_enum_trait_implementation):
+ (InputsModel.parse_type_with_framework_name): Deleted.
+ * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
+ * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
+ (JSC::EncodingTraits<WebCore::MouseButton>::decodeValue):
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
+ (JSC::EncodingTraits<WebCore::MouseButton>::decodeValue):
+ (JSC::EncodingTraits<WebCore::PlatformEvent::Type>::encodeValue):
+ (JSC::EncodingTraits<WebCore::PlatformEvent::Type>::decodeValue):
+ * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
+ * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
+ (JSC::EncodingTraits<WebCore::FormData1::Type>::decodeValue):
+ (JSC::EncodingTraits<PlatformEvent1::Type>::decodeValue):
+ * replay/scripts/tests/generate-enum-encoding-helpers.json: Added a new input to cover this case.
+
+2014-10-17 Mark Lam <mark.lam@apple.com>
+
+ Web Process crash when starting the web inspector after r174025.
+ <https://webkit.org/b/137340>
+
+ Reviewed by Filip Pizlo.
+
+ After r174025, we can generate a bad graph in the DFG fixup phase like so:
+
+ 102:<!0:-> StoreBarrier(Check:KnownCell:@19, ..., bc#44)
+ 60:<!0:-> PutStructure(Check:KnownCell:@19, ..., bc#44)
+ 103:<!0:-> Check(Check:NotCell:@54, ..., bc#44)
+ // ^-- PutByOffset's StoreBarrier has been elided and replaced
+ // with a speculation check which can OSR exit.
+ 61:<!0:-> PutByOffset(Check:KnownCell:@19, ..., bc#44)
+
+ As a result, the structure change will get executed even if we end up OSR
+ exiting before the PutByOffset. In the baseline JIT code, the structure now
+ erroneously tells the put operation that there is a value in that property
+ slot when it is actually uninitialized (hence, the crash).
+
+ The fix is to insert the Check at the earliest point possible:
+
+ 1. If the checked node is in the same bytecode as the PutByOffset, then
+ the earliest point where we can insert the Check is right after the
+ checked node.
+
+ 2. If the checked node is from a preceding bytecode (before the PutByOffset),
+ then the earliest point where we can insert the Check is at the start
+ of the current bytecode.
+
+ Also reverted the workaround from r174749: https://webkit.org/b/137758.
+
+ Benchmark results appear to be a wash on aggregate.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::indexOfNode):
+ (JSC::DFG::FixupPhase::indexOfFirstNodeOfExitOrigin):
+ (JSC::DFG::FixupPhase::fixupNode):
+ (JSC::DFG::FixupPhase::insertCheck):
+ * dfg/DFGInsertionSet.h:
+ (JSC::DFG::InsertionSet::insertOutOfOrder):
+ (JSC::DFG::InsertionSet::insertOutOfOrderNode):
+
+2014-10-10 Oliver Hunt <oliver@apple.com>
+
+ Various arguments optimisations in codegen fail to account for arguments being in lexical record
+ https://bugs.webkit.org/show_bug.cgi?id=137617
+
+ Reviewed by Michael Saboff.
+
+ Rework the way we track |arguments| references so that we don't try
+ to use the |arguments| reference on the stack if it's not safe.
+
+ To do this without nuking performance it was necessary to update
+ the parser to track modification of the |arguments| reference
+ itself.
+
+ * bytecode/CodeBlock.cpp:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::willResolveToArguments):
+ (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
+ (JSC::BytecodeGenerator::emitCall):
+ (JSC::BytecodeGenerator::emitConstruct):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::uncheckedRegisterForArguments): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BracketAccessorNode::emitBytecode):
+ (JSC::DotAccessorNode::emitBytecode):
+ (JSC::getArgumentByVal):
+ (JSC::CallFunctionCallDotNode::emitBytecode):
+ (JSC::ApplyFunctionCallDotNode::emitBytecode):
+ (JSC::ArrayPatternNode::emitDirectBinding):
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::existingArguments):
+ * parser/Nodes.h:
+ (JSC::ScopeNode::modifiesArguments):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner):
+ * parser/Parser.h:
+ (JSC::Scope::getCapturedVariables):
+ * parser/ParserModes.h:
+
+2014-10-17 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Use WTF::move() instead of std::move() to help ensure move semantics in JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=137809
+
+ Reviewed by Csaba Osztrogonác.
+
+ Substitution of WTF::move() for std::move(). Clean up std::move() in JavaScriptCore.
+
+ * bytecode/GetByIdStatus.cpp:
+ (JSC::GetByIdStatus::computeForStubInfo):
+ * bytecode/PutByIdStatus.cpp:
+ (JSC::PutByIdStatus::computeForStubInfo):
+ * bytecode/PutByIdVariant.cpp:
+ (JSC::PutByIdVariant::setter):
+
+2014-10-15 Oliver Hunt <oliver@apple.com>
+
+ Use a single allocation for the Arguments object
+ https://bugs.webkit.org/show_bug.cgi?id=137751
+
+ Reviewed by Filip Pizlo.
+
+ This patch removes the secondary allocation for parameters in the Arguments
+ object. This is faily simple, but we needed to make it possible for the JIT
+ to allocate a variable GC object. To do this i've added a new
+ emitAllocateVariableSizedJSObject function to the JIT that does the work to
+ find the correct heap for a variable sized allocation and then bump that
+ allocator.
+
+ * dfg/DFGSpeculativeJIT.cpp:
+ (JSC::DFG::SpeculativeJIT::emitAllocateArguments):
+ * dfg/DFGSpeculativeJIT.h:
+ (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
+ * heap/CopyToken.h:
+ * heap/Heap.h:
+ (JSC::Heap::subspaceForObjectWithoutDestructor):
+ (JSC::Heap::subspaceForObjectNormalDestructor):
+ (JSC::Heap::subspaceForObjectsWithImmortalStructure):
+ * heap/MarkedSpace.h:
+ (JSC::MarkedSpace::subspaceForObjectsWithNormalDestructor):
+ (JSC::MarkedSpace::subspaceForObjectsWithImmortalStructure):
+ (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::createArguments):
+ * runtime/Arguments.cpp:
+ (JSC::Arguments::visitChildren):
+ (JSC::Arguments::copyBackingStore):
+ (JSC::Arguments::tearOff):
+ (JSC::Arguments::allocateRegisterArray): Deleted.
+ * runtime/Arguments.h:
+ (JSC::Arguments::create):
+ (JSC::Arguments::isTornOff):
+ (JSC::Arguments::offsetOfRegisterArray):
+ (JSC::Arguments::registerArraySizeInBytes):
+ (JSC::Arguments::registerArray):
+ (JSC::Arguments::allocationSize): Deleted.
+
+2014-10-15 Filip Pizlo <fpizlo@apple.com>
+
+ Apparently we've had a hole in arguments capture all along
+ https://bugs.webkit.org/show_bug.cgi?id=137767
+
+ Reviewed by Oliver Hunt.
+
+ * dfg/DFGByteCodeParser.cpp:
+ (JSC::DFG::ByteCodeParser::getArgument):
+ * tests/stress/arguments-captured.js: Added.
+ (foo):
+ (bar):
+
+2014-10-16 Saam Barati <saambarati1@gmail.com>
+
+ Have the ProfileType node in the DFG convert to a structure check where it can
+ https://bugs.webkit.org/show_bug.cgi?id=137596
+
+ Reviewed by Filip Pizlo.
+
+ TypeSet now keeps track of the live set of Structures it has seen.
+ It no longer nukes everything during GC. It now only removes unmarked
+ structures during GC. This modification allows the ProfileType node
+ to convert into a CheckStructure node safely in the DFG.
+
+ This change brings up the conversion rate from ProfileType to Check
+ or CheckStructrue from ~45% to ~65%. This change also speeds the
+ type profiler up significantly: consistently between 2x-20x faster.
+
+ This patch also does some slight refactoring: a few type profiler
+ related fields are moved from VM to TypeProfiler.
+
+ * bytecode/CodeBlock.cpp:
+ (JSC::CodeBlock::CodeBlock):
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+ * dfg/DFGNode.h:
+ (JSC::DFG::Node::convertToCheckStructure):
+ * heap/Heap.cpp:
+ (JSC::Heap::collect):
+ * runtime/SymbolTable.cpp:
+ (JSC::SymbolTable::uniqueIDForVariable):
+ * runtime/SymbolTable.h:
+ * runtime/TypeLocationCache.cpp:
+ (JSC::TypeLocationCache::getTypeLocation):
+ * runtime/TypeProfiler.cpp:
+ (JSC::TypeProfiler::TypeProfiler):
+ (JSC::TypeProfiler::nextTypeLocation):
+ (JSC::TypeProfiler::invalidateTypeSetCache):
+ (JSC::TypeProfiler::dumpTypeProfilerData):
+ * runtime/TypeProfiler.h:
+ (JSC::TypeProfiler::getNextUniqueVariableID):
+ * runtime/TypeProfilerLog.cpp:
+ (JSC::TypeProfilerLog::processLogEntries):
+ * runtime/TypeSet.cpp:
+ (JSC::TypeSet::addTypeInformation):
+ (JSC::TypeSet::invalidateCache):
+ * runtime/TypeSet.h:
+ (JSC::TypeSet::structureSet):
+ * runtime/VM.cpp:
+ (JSC::VM::VM):
+ (JSC::VM::enableTypeProfiler):
+ (JSC::VM::disableTypeProfiler):
+ (JSC::VM::dumpTypeProfilerData):
+ (JSC::VM::nextTypeLocation): Deleted.
+ (JSC::VM::invalidateTypeSetCache): Deleted.
+ * runtime/VM.h:
+ (JSC::VM::typeProfiler):
+ (JSC::VM::getNextUniqueVariableID): Deleted.
+ * tests/typeProfiler/dfg-jit-optimizations.js:
+
+2014-10-16 Adrien Destugues <pulkomandy@gmail.com>
+
+ Use isnan from std namespace in ProfileGenerator.cpp
+ https://bugs.webkit.org/show_bug.cgi?id=137653
+
+ Reviewed by Darin Adler.
+
+ The C++ isnan() function is in the std namespace. The unprefixed isnan
+ may be available because of C99 headers leakage in C++, but should not
+ be used.
+
+ No new tests: no functional change, build fix on platforms which don't
+ export C99 functions in C++.
+
+ * profiler/ProfileGenerator.cpp:
+ (JSC::ProfileGenerator::beginCallEntry):
+ (JSC::ProfileGenerator::endCallEntry):
+ (JSC::ProfileGenerator::didPause):
+ (JSC::ProfileGenerator::didContinue):
+
+2014-10-15 Michael Saboff <msaboff@apple.com>
+
+ REGRESSION(r174025): remote inspector crashes frequently when executing inspector frontend's JavaScript
+ https://bugs.webkit.org/show_bug.cgi?id=137758
+
+ Rubber stamped by Filip Pizlo.
+
+ Reverted r174025 for just PutByOffset Nodes.
+
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode):
+
+2014-10-14 Gyuyoung Kim <gyuyoung.kim@samsung.com>
+
+ Clean up unnecessary PassOwnPtr.h inclusion
+ https://bugs.webkit.org/show_bug.cgi?id=137726
+
+ Reviewed by Chris Dumez.
+
+ * API/JSCallbackObject.h: Remove PassOwnPtr.h inclusion.
+ * bytecode/DFGExitProfile.cpp: ditto.
+
+2014-10-14 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Unreviewed gardening. Ignore Visual Studio *.sdf files.
+
+ * JavaScriptCore.vcxproj: Modified properties svn:ignore and svn:ignore.
+ * JavaScriptCore.vcxproj/jsc: Modified property svn:ignore.
+
+2014-10-14 Matthew Mirman <mmirman@apple.com>
+
+ Removes references to LLVMJIT which is no longer part of LLVM
+ https://bugs.webkit.org/show_bug.cgi?id=137708
+
+ Reviewed by Filip Pizlo.
+
+ * Configurations/LLVMForJSC.xcconfig: removed -lLLVMJIT
+ * llvm/LLVMAPIFunctions.h: removed LinkInJIT
+
+2014-10-14 peavo@outlook.com <peavo@outlook.com>
+
+ [Win32] Thunk is not implemented.
+ https://bugs.webkit.org/show_bug.cgi?id=137691
+
+ Reviewed by Mark Lam.
+
+ Thunks for functions with double operands (floor, etc.) are not implemented on Win32.
+
+ * jit/ThunkGenerators.cpp:
+
+2014-10-12 Alexey Proskuryakov <ap@apple.com>
+
+ Adding svn:ignore so that .pyc files don't show up as new.
+
+ * inspector/scripts/codegen: Added property svn:ignore.
+
+2014-10-10 Commit Queue <commit-queue@webkit.org>
+
+ Unreviewed, rolling out r174606.
+ https://bugs.webkit.org/show_bug.cgi?id=137621
+
+ broke a JSC test (Requested by estes on #webkit).
+
+ Reverted changeset:
+
+ "Various arguments optimisations in codegen fail to account
+ for arguments being in lexical record"
+ https://bugs.webkit.org/show_bug.cgi?id=137617
+ http://trac.webkit.org/changeset/174606
+
+2014-10-10 Oliver Hunt <oliver@apple.com>
+
+ Various arguments optimisations in codegen fail to account for arguments being in lexical record
+ https://bugs.webkit.org/show_bug.cgi?id=137617
+
+ Reviewed by Michael Saboff.
+
+ Rework the way we track |arguments| references so that we don't try
+ to use the |arguments| reference on the stack if it's not safe.
+
+ To do this without nuking performance it was necessary to update
+ the parser to track modification of the |arguments| reference
+ itself.
+
+ * bytecode/CodeBlock.cpp:
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::BytecodeGenerator):
+ (JSC::BytecodeGenerator::willResolveToArguments):
+ (JSC::BytecodeGenerator::uncheckedLocalArgumentsRegister):
+ (JSC::BytecodeGenerator::emitCall):
+ (JSC::BytecodeGenerator::emitConstruct):
+ (JSC::BytecodeGenerator::emitEnumeration):
+ (JSC::BytecodeGenerator::uncheckedRegisterForArguments): Deleted.
+ * bytecompiler/BytecodeGenerator.h:
+ (JSC::BytecodeGenerator::hasSafeLocalArgumentsRegister):
+ * bytecompiler/NodesCodegen.cpp:
+ (JSC::BracketAccessorNode::emitBytecode):
+ (JSC::DotAccessorNode::emitBytecode):
+ (JSC::getArgumentByVal):
+ (JSC::CallFunctionCallDotNode::emitBytecode):
+ (JSC::ApplyFunctionCallDotNode::emitBytecode):
+ (JSC::ArrayPatternNode::emitDirectBinding):
+ * interpreter/StackVisitor.cpp:
+ (JSC::StackVisitor::Frame::existingArguments):
+ * parser/Nodes.h:
+ (JSC::ScopeNode::modifiesArguments):
+ * parser/Parser.cpp:
+ (JSC::Parser<LexerType>::parseInner):
+ * parser/Parser.h:
+ (JSC::Scope::getCapturedVariables):
+ * parser/ParserModes.h:
+
+2014-10-09 Joseph Pecoraro <pecoraro@apple.com>
+
+ Web Inspector: Remove unused generator code
+ https://bugs.webkit.org/show_bug.cgi?id=137564
+
+ Reviewed by Brian Burg.
+
+ * inspector/scripts/codegen/generate_backend_dispatcher_header.py:
+ (BackendDispatcherHeaderGenerator.generate_output): Deleted.
+ * inspector/scripts/codegen/generate_backend_dispatcher_implementation.py:
+ (BackendDispatcherImplementationGenerator.generate_output):
+ * inspector/scripts/codegen/generate_frontend_dispatcher_header.py:
+ (FrontendDispatcherHeaderGenerator.generate_output):
+ * inspector/scripts/codegen/generate_frontend_dispatcher_implementation.py:
+ (FrontendDispatcherImplementationGenerator.generate_output):
+ * inspector/scripts/codegen/generate_protocol_types_header.py:
+ (ProtocolTypesHeaderGenerator.generate_output):
+ * inspector/scripts/codegen/generate_protocol_types_implementation.py:
+ (ProtocolTypesImplementationGenerator.generate_output):
+ inputFilename is now handled by the generic generator base class.
+
+ * inspector/scripts/codegen/models.py:
+ (Framework.fromString):
+ (Frameworks):
+ * inspector/scripts/generate-inspector-protocol-bindings.py:
+ The WTF framework is unused. Remove unexpected frameworks.
+
+2014-10-09 Dean Jackson <dino@apple.com>
+
+ Remove ENABLE_CSS3_CONDITIONAL_RULES
+ https://bugs.webkit.org/show_bug.cgi?id=137571
+
+ Reviewed by Simon Fraser.
+
+ * Configurations/FeatureDefines.xcconfig:
+
+2014-10-09 Adrien Destugues <pulkomandy@gmail.com>
+
+ Fix compiler warning on noreturn function
+ https://bugs.webkit.org/show_bug.cgi?id=137558
+
+ Reviewed by Darin Adler.
+
+ The function is marked "noreturn", but the stub implementation does
+ return. No new tests: function is never called. Only fixes a warning.
+
+ * heap/HeapStatistics.cpp:
+ (JSC::HeapStatistics::exitWithFailure):
+
+2014-10-09 Akos Kiss <akiss@inf.u-szeged.hu>
+
+ Ensure that inline assembly Thunk functions don't conflict with the section designations of the compiler
+ https://bugs.webkit.org/show_bug.cgi?id=137434
+
+ Reviewed by Michael Saboff.
+
+ The ARM64 version of the defineUnaryDoubleOpWrapper macro in
+ ThunkGenerators.cpp contains inline assembly with .text assembler
+ directive followed by a static variable declaration. This macro gets
+ expanded several times afterwards, however, only during the compilation
+ of the first expansion does gcc insert a .data assembler directive
+ before the assembled version of the static variable. Thus, only the
+ first variable gets allocated in the .data section, all the others
+ remain in .text. If JavaScriptCore is built as a shared library then
+ this causes a segmentation fault during dynamic linking.
+
+ This patch puts a .previous directive at the end of the inline assembly
+ to ensure that the assumptions of the compiler about the sections are
+ not broken and the following variable goes to the right place.
+
+ * jit/ThunkGenerators.cpp:
+
+2014-10-08 Oliver Hunt <oliver@apple.com>
+
+ Make sure arguments tearoff is performed through the environment record if necessary
+ https://bugs.webkit.org/show_bug.cgi?id=137538
+
+ Reviewed by Michael Saboff.
+
+ Fairly simple change. If we have a lexical record we need to pull the unmodified
+ arguments object from the record and then use the standard op_tear_off_arguments
+ instruction on the temporary.
+
+ * bytecompiler/BytecodeGenerator.cpp:
+ (JSC::BytecodeGenerator::emitGetOwnScope):
+ (JSC::BytecodeGenerator::emitReturn):
+ * bytecompiler/BytecodeGenerator.h:
+
+2014-10-08 peavo@outlook.com <peavo@outlook.com>
+
+ [WinCairo] Enable JIT on 32-bit.
+ https://bugs.webkit.org/show_bug.cgi?id=137521
+
+ Reviewed by Mark Lam.
+
+ Enable JIT on Windows 32-bit, but disable it at runtime if SSE2 is not present.
+
+ * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl:
+ * runtime/Options.cpp:
+ (JSC::recomputeDependentOptions):
+
+2014-10-08 Brent Fulgham <bfulgham@apple.com>
+
+ [Win] Resolve some static analysis warnings in JavaScriptCore
+ https://bugs.webkit.org/show_bug.cgi?id=137508
+
+ Reviewed by Geoffrey Garen.
+
+ * API/tests/testapi.c:
+ (assertEqualsAsCharactersPtr): MSVC insists on using %Iu as its format specifier
+ for size_t. Make the format string conditional on Windows.
+ * bytecode/Watchpoint.h:
+ (JSC::InlineWatchpointSet::encodeState): Silence warning about left-shifting 'state'
+ as a 32-bit value before OR-ing it with a 64-bit value.
+ * dfg/DFGFixupPhase.cpp:
+ (JSC::DFG::FixupPhase::fixupNode): Silence warning about operator prescedence
+ causing the || operation to take place before the >= test.
+ * dfg/DFGInPlaceAbstractState.cpp:
+ (JSC::DFG::InPlaceAbstractState::endBasicBlock): Ditto (|| before !=)
+ * testRegExp.cpp:
+ (testOneRegExp): Ditto %Iu format specifier.
+ * yarr/YarrInterpreter.cpp:
+ (JSC::Yarr::Interpreter::allocParenthesesDisjunctionContext): Silence warning about
+ using a 32-bit value as part of a 64-bit calculation.
+
+2014-10-07 Simon Fraser <simon.fraser@apple.com>
+
+ Roll-over Changelogs.
+
+ * ChangeLog-2014-10-07: Copied from Source/JavaScriptCore/ChangeLog.
+
+== Rolled over to ChangeLog-2014-10-07 ==
projects / apple / javascriptcore.git / blobdiff