2017-11-06 Jason Marcell <jmarcell@apple.com> Cherry-pick r224426. rdar://problem/35364681 2017-11-03 Michael Saboff <msaboff@apple.com> The Abstract Interpreter needs to change similar to clobberize() in r224366 https://bugs.webkit.org/show_bug.cgi?id=179267 Reviewed by Saam Barati. Add clobberWorld() to HasGenericProperty, HasStructureProperty & GetPropertyEnumerator cases in the abstract interpreter to match what was done for r224366. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): 2017-11-05 Jason Marcell <jmarcell@apple.com> Cherry-pick r224416. rdar://problem/35296415 2017-11-03 Keith Miller <keith_miller@apple.com> PutProperytSlot should inform the IC about the property before effects. https://bugs.webkit.org/show_bug.cgi?id=179262 Reviewed by Mark Lam. This patch fixes an issue where we choose to cache setters based on incorrect information. If we did so we might end up OSR exiting more than we would otherwise need to. The new model is that the PutPropertySlot should inform the IC of what the property looked like before any potential side effects might have occurred. * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/Lookup.h: (JSC::putEntry): 2017-11-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r224366. rdar://problem/35329722 2017-11-02 Michael Saboff <msaboff@apple.com> DFG needs to handle code motion of code in for..in loop bodies https://bugs.webkit.org/show_bug.cgi?id=179212 Reviewed by Keith Miller. The processing of the DFG nodes HasGenericProperty, HasStructureProperty & GetPropertyEnumerator make calls with side effects. Updated clobberize() for those nodes to take that into account. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2017-11-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r224349. rdar://problem/35329729 2017-11-02 Filip Pizlo <fpizlo@apple.com> AI does not correctly model the clobber case of ArithClz32 https://bugs.webkit.org/show_bug.cgi?id=179188 Reviewed by Michael Saboff. The non-Int32 case clobbers the world because it may call valueOf. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): 2017-11-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r224302. rdar://problem/35296412 2017-11-01 Michael Saboff <msaboff@apple.com> Integer overflow in code generated by LoadVarargs processing in DFG and FTL. https://bugs.webkit.org/show_bug.cgi?id=179140 Reviewed by Saam Barati. Added overflow checks to computation of arg count plus this. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs): 2017-10-21 Jason Marcell <jmarcell@apple.com> Cherry-pick r223731. rdar://problem/35100279 2017-10-19 Mark Lam <mark.lam@apple.com> Stringifier::appendStringifiedValue() is missing an exception check. https://bugs.webkit.org/show_bug.cgi?id=178386 <rdar://problem/35027610> Reviewed by Saam Barati. * runtime/JSONObject.cpp: (JSC::Stringifier::appendStringifiedValue): 2017-10-21 Jason Marcell <jmarcell@apple.com> Cherry-pick r223645. rdar://problem/34820875 2017-10-18 Mark Lam <mark.lam@apple.com> RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified. https://bugs.webkit.org/show_bug.cgi?id=177600 <rdar://problem/34710985> Reviewed by Saam Barati. According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor, section 9.1.6.3-7.a.ii, we should only check if the value is the same if the descriptor value is present. * runtime/RegExpObject.cpp: (JSC::RegExpObject::defineOwnProperty): 2017-10-18 Jason Marcell <jmarcell@apple.com> Cherry-pick r221607. rdar://problem/35041474 2017-09-04 Saam Barati <sbarati@apple.com> typeCheckHoistingPhase may emit a CheckStructure on the empty value which leads to a dereference of zero on 64 bit platforms https://bugs.webkit.org/show_bug.cgi?id=176317 Reviewed by Keith Miller. It turns out that TypeCheckHoistingPhase may hoist a CheckStructure up to the SetLocal of a particular value where the value is the empty JSValue. On 64-bit platforms, the empty value is zero. This means that the empty value passes a cell check. This will lead to a crash when we dereference null to load the value's structure. This patch teaches TypeCheckHoistingPhase to be conservative in the structure checks it hoists. On 64-bit platforms, instead of emitting a CheckStructure node, we now emit a CheckStructureOrEmpty node. This node allows the empty value to flow through. If the value isn't empty, it'll perform the normal structure check that CheckStructure performs. For now, we only emit CheckStructureOrEmpty on 64-bit platforms since a cell check on 32-bit platforms does not allow the empty value to flow through. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGArgumentsEliminationPhase.cpp: * 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/DFGNode.h: (JSC::DFG::Node::convertCheckStructureOrEmptyToCheckStructure): (JSC::DFG::Node::hasStructureSet): * dfg/DFGNodeType.h: * dfg/DFGObjectAllocationSinkingPhase.cpp: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge): (JSC::DFG::SafeToExecuteEdge::operator()): (JSC::DFG::SafeToExecuteEdge::maySeeEmptyChild): (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitStructureCheck): (JSC::DFG::SpeculativeJIT::compileCheckStructure): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGTypeCheckHoistingPhase.cpp: (JSC::DFG::TypeCheckHoistingPhase::run): * dfg/DFGValidate.cpp: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureOrEmpty): 2017-10-18 Jason Marcell <jmarcell@apple.com> Cherry-pick r223409. rdar://problem/34792148 2017-10-16 JF Bastien <jfbastien@apple.com> JSRunLoopTimer: reduce likely race when used improperly https://bugs.webkit.org/show_bug.cgi?id=178298 <rdar://problem/32899816> Reviewed by Saam Barati. If an API user sets a timer on JSRunLoopTimer, and then racily destroys the JSRunLoopTimer while the timer is firing then it's possible for timerDidFire to cause a use-after-free and / or crash because e.g. m_apiLock becomes a nullptr while timerDidFire is executing. That results from an invalid use of JSRunLoopTimer, but we should try to be more resilient for that type of misuse because it's not necessarily easy to catch by inspection. With this change the only remaining race is if the timer fires, and then only timerDidFire's prologue executes, but not the load of the m_apiLock pointer from `this`. It's a much smaller race. Separately, I'll reach out to API users who are seemingly misusing the API. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack, and checks for nullptr. This prevents loading it twice off of `this` and turns a nullptr deref into "just" a use-after-free. (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before calling m_vm->unregisterRunLoopTimer(this), which in turn does CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents timerDidFire from doing much while the timers are un-registered. ~JSRunLoopTimer also needs to set m_apiLock to nullptr before releasing the lock, so it needs its own local copy. 2017-10-18 Jason Marcell <jmarcell@apple.com> Cherry-pick r223614. rdar://problem/34920288 2017-10-18 Mark Lam <mark.lam@apple.com> The compiler should always register a structure when it adds its transitionWatchPointSet. https://bugs.webkit.org/show_bug.cgi?id=178420 <rdar://problem/34814024> Reviewed by Saam Barati and Filip Pizlo. Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we now invoke Graph::registerAndWatchStructureTransition() on the structure. registerAndWatchStructureTransition() both registers the structure and add its transitionWatchpointSet to the plan desired watchpoints. Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure() except registerAndWatchStructureTransition() adds the structure's transitionWatchpointSet unconditionally. * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine const): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::registerAndWatchStructureTransition): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileGetByValOnString): - The second set of addLazily()s is redundant. This set is executed only when prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and only if we've executed the if statement above it. That preceding if statement already registerAndWatchStructureTransition() the same 2 structures. Hence, this second set can be deleted. * dfg/DFGWatchpointCollectionPhase.cpp: (JSC::DFG::WatchpointCollectionPhase::addLazily): - Deleted an unused function. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt): 2017-10-16 Jason Marcell <jmarcell@apple.com> Cherry-pick r222417. rdar://problem/35010839 2017-09-22 Fujii Hironori <Hironori.Fujii@sony.com> [Win64] Crashes in Yarr JIT compiled code https://bugs.webkit.org/show_bug.cgi?id=177293 Reviewed by Yusuke Suzuki. In x64 Windows, rcx register is used for the address of allocated space for the return value. But, rcx is used for regT1 since r221052. Save rcx in the stack. * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateEnter): Push ecx. (JSC::Yarr::YarrGenerator::generateReturn): Pop ecx. 2017-10-08 Jason Marcell <jmarcell@apple.com> Cherry-pick r222748. rdar://problem/34820919 2017-10-02 Keith Miller <keith_miller@apple.com> VMTraps shouldn't crash if it sees an exception it doesn't understand. https://bugs.webkit.org/show_bug.cgi?id=177780 Reviewed by Mark Lam. VMTraps could see a JIT breakpoint (SegV) for any number of reasons it doesn't understand. e.g. a bug in JIT code, Wasm OOB, etc. This patch makes it handle that case gracefully. It's worth noting that this means there's no way to know if, due to a bug, we didn't accurately track all the VMTraps we installed. I'm not sure if there is a good solution to that problem though. * runtime/VMTraps.cpp: 2017-10-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r222598. rdar://problem/34771434 2017-09-27 Mark Lam <mark.lam@apple.com> JSArray::canFastCopy() should fail if the source and destination arrays are the same. https://bugs.webkit.org/show_bug.cgi?id=177584 <rdar://problem/34463903> Reviewed by Saam Barati. If the source and destination arrays are the same, we may be copying overlapping regions. Hence, we need to take the slow path. * runtime/JSArrayInlines.h: (JSC::JSArray::canFastCopy): 2017-10-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r221400. rdar://problem/34771396 2017-08-30 Saam Barati <sbarati@apple.com> semicolon is being interpreted as an = in the LiteralParser https://bugs.webkit.org/show_bug.cgi?id=176114 Reviewed by Oliver Hunt. When lexing a semicolon in the LiteralParser, we were properly setting the TokenType on the current token, however, we were *returning* the wrong TokenType. The lex function both returns the TokenType and sets it on the current token. Semicolon was setting the TokenType to semicolon, but returning the TokenType for '='. This caused programs like `x;123` to be interpreted as `x=123`. * runtime/LiteralParser.cpp: (JSC::LiteralParser<CharType>::Lexer::lex): (JSC::LiteralParser<CharType>::Lexer::next): 2017-09-12 Jason Marcell <jmarcell@apple.com> Cherry-pick r221711. rdar://problem/34404472 2017-09-06 Mark Lam <mark.lam@apple.com> constructGenericTypedArrayViewWithArguments() is missing an exception check. https://bugs.webkit.org/show_bug.cgi?id=176485 <rdar://problem/33898874> Reviewed by Keith Miller. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): 2017-08-09 Jason Marcell <jmarcell@apple.com> Cherry-pick r220473. rdar://problem/33810961 2017-08-09 Wenson Hsieh <wenson_hsieh@apple.com> [iOS DnD] ENABLE_DRAG_SUPPORT should be turned off for iOS 10 and enabled by default https://bugs.webkit.org/show_bug.cgi?id=175392 <rdar://problem/33783207> Reviewed by Tim Horton and Megan Gardner. Tweak FeatureDefines to enable drag and drop by default, and disable only on unsupported platforms (i.e. iOS 10). * Configurations/FeatureDefines.xcconfig: 2017-08-09 Jason Marcell <jmarcell@apple.com> Cherry-pick r220346. rdar://problem/33810976 2017-08-07 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r220144. https://bugs.webkit.org/show_bug.cgi?id=175276 "It did not actually speed things up in the way I expected" (Requested by saamyjoon on #webkit). Reverted changeset: "On memory-constrained iOS devices, reduce the rate at which the JS heap grows before a GC to try to keep more memory available for the system" https://bugs.webkit.org/show_bug.cgi?id=175041 http://trac.webkit.org/changeset/220144 2017-08-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r220144. rdar://problem/33692161 2017-08-02 Saam Barati <sbarati@apple.com> On memory-constrained iOS devices, reduce the rate at which the JS heap grows before a GC to try to keep more memory available for the system https://bugs.webkit.org/show_bug.cgi?id=175041 <rdar://problem/33659370> Reviewed by Filip Pizlo. The testing I have done shows that this new function is a ~10% progression running JetStream on 1GB iOS devices. I've also tried this on a few > 1GB iOS devices, and the testing shows this is either neutral or a regression. Right now, we'll just enable this for <= 1GB devices since it's a win. In the future, we might want to either look into tweaking these parameters or coming up with a new function for > 1GB devices. * heap/Heap.cpp: * runtime/Options.h: 2017-08-02 Jason Marcell <jmarcell@apple.com> Cherry-pick r220144. rdar://problem/33687404 2017-08-02 Saam Barati <sbarati@apple.com> On memory-constrained iOS devices, reduce the rate at which the JS heap grows before a GC to try to keep more memory available for the system https://bugs.webkit.org/show_bug.cgi?id=175041 <rdar://problem/33659370> Reviewed by Filip Pizlo. The testing I have done shows that this new function is a ~10% progression running JetStream on 1GB iOS devices. I've also tried this on a few > 1GB iOS devices, and the testing shows this is either neutral or a regression. Right now, we'll just enable this for <= 1GB devices since it's a win. In the future, we might want to either look into tweaking these parameters or coming up with a new function for > 1GB devices. * heap/Heap.cpp: * runtime/Options.h: 2017-07-31 Jason Marcell <jmarcell@apple.com> Cherry-pick r220012. rdar://problem/33619526 2017-07-28 Mark Lam <mark.lam@apple.com> ObjectToStringAdaptiveStructureWatchpoint should not fire if it's dying imminently. https://bugs.webkit.org/show_bug.cgi?id=174948 <rdar://problem/33495680> Reviewed by Filip Pizlo. ObjectToStringAdaptiveStructureWatchpoint is owned by StructureRareData. If its owner StructureRareData is already known to be dead (in terms of GC liveness) but hasn't been destructed yet (i.e. not swept by the GC yet), we should ignore all requests to fire this watchpoint. If the GC had the chance to sweep the StructureRareData, thereby destructing the ObjectToStringAdaptiveStructureWatchpoint, it (the watchpoint) would have removed itself from the WatchpointSet it was on. Hence, it would not have been fired. But since the watchpoint hasn't been destructed yet, it still remains on the WatchpointSet and needs to guard against being fired in this state. The fix is to simply return early if its owner StructureRareData is not live. This has the effect of the watchpoint fire being a no-op, which is equivalent to the watchpoint not firing as we would expect. This patch also removes some cargo cult copying of watchpoint code which instantiates a StringFireDetail. In a few cases, that StringFireDetail is never used. This patch removes these unnecessary instantiations. * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp: (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal): * runtime/StructureRareData.cpp: (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire): 2017-07-28 Jason Marcell <jmarcell@apple.com> Cherry-pick r219895. rdar://problem/33595450 2017-07-25 Keith Miller <keith_miller@apple.com> Remove Broken CompareEq constant folding phase. https://bugs.webkit.org/show_bug.cgi?id=174846 <rdar://problem/32978808> Reviewed by Saam Barati. This bug happened when we would get code like the following: a: JSConst(Undefined) b: GetLocal(SomeObjectOrUndefined) ... c: CompareEq(Check:ObjectOrOther:b, Check:ObjectOrOther:a) constant folding will turn this into: a: JSConst(Undefined) b: GetLocal(SomeObjectOrUndefined) ... c: CompareEq(Check:ObjectOrOther:b, Other:a) But the SpeculativeJIT/FTL lowering will fail to check b properly which leads to an assertion failure in the AI. I'll follow up with a more robust fix later. For now, I'll remove the case that generates the code. Removing the code appears to be perf neutral. * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): 2017-07-22 Jason Marcell <jmarcell@apple.com> Cherry-pick r219633. rdar://problem/33465535 2017-07-18 Saam Barati <sbarati@apple.com> AirLowerAfterRegAlloc may incorrectly use a callee save that's live as a scratch register https://bugs.webkit.org/show_bug.cgi?id=174515 <rdar://problem/33358092> Reviewed by Filip Pizlo. AirLowerAfterRegAlloc was computing the set of available scratch registers incorrectly. It was always excluding callee save registers from the set of live registers. It did not guarantee that live callee save registers were not in the set of scratch registers that could get clobbered. That's incorrect as the shuffling code is free to overwrite whatever is in the scratch register it gets passed. * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/testb3.cpp: (JSC::B3::functionNineArgs): (JSC::B3::testShuffleDoesntTrashCalleeSaves): (JSC::B3::run): * jit/RegisterSet.h: 2017-07-17 Jason Marcell <jmarcell@apple.com> Cherry-pick r219413. rdar://problem/33337335 2017-06-29 Dean Jackson <dino@apple.com> Disable some features on this release branch. <rdar://problem/32913370> * Configurations/FeatureDefines.xcconfig: * runtime/Options.h: 2017-07-17 Saam Barati <sbarati@apple.com> Remove custom defined RELEASE_ASSERT in DFGObjectAllocationSinkingPhase https://bugs.webkit.org/show_bug.cgi?id=174584 Rubber stamped by Keith Miller. I used it to diagnose a bug. The bug is now fixed. This custom RELEASE_ASSERT is no longer needed. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-17 Michael Catanzaro <mcatanzaro@igalia.com> -Wformat-truncation warning in ConfigFile.cpp https://bugs.webkit.org/show_bug.cgi?id=174506 Reviewed by Darin Adler. Check if the JSC config filename would be truncated due to exceeding max path length. If so, return ParseError. * runtime/ConfigFile.cpp: (JSC::ConfigFile::parse): 2017-07-17 Konstantin Tokarev <annulen@yandex.ru> [CMake] Create targets before WEBKIT_INCLUDE_CONFIG_FILES_IF_EXISTS is called https://bugs.webkit.org/show_bug.cgi?id=174557 Reviewed by Michael Catanzaro. * CMakeLists.txt: 2017-07-14 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Use std::unique_ptr for StackTrace https://bugs.webkit.org/show_bug.cgi?id=174495 Reviewed by Alex Christensen. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/VM.cpp: (JSC::VM::throwException): 2017-07-14 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use WTFMove to prune liveness in DFGAvailabilityMap https://bugs.webkit.org/show_bug.cgi?id=174423 Reviewed by Saam Barati. * dfg/DFGAvailabilityMap.cpp: (JSC::DFG::AvailabilityMap::pruneHeap): (JSC::DFG::AvailabilityMap::pruneByLiveness): 2017-07-13 Michael Catanzaro <mcatanzaro@igalia.com> Fix compiler warnings when building with GCC 7 https://bugs.webkit.org/show_bug.cgi?id=174463 Reviewed by Darin Adler. * disassembler/udis86/udis86_decode.c: (decode_operand): 2017-07-13 Michael Catanzaro <mcatanzaro@igalia.com> Incorrect assertion in JSC::CallLinkInfo::callTypeFor https://bugs.webkit.org/show_bug.cgi?id=174467 Reviewed by Saam Barati. * bytecode/CallLinkInfo.cpp: (JSC::CallLinkInfo::callTypeFor): 2017-07-13 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Remove unused and untested Page domain commands https://bugs.webkit.org/show_bug.cgi?id=174429 Reviewed by Timothy Hatcher. * inspector/protocol/Page.json: 2017-07-13 Saam Barati <sbarati@apple.com> Missing exception check in JSObject::hasInstance https://bugs.webkit.org/show_bug.cgi?id=174455 <rdar://problem/31384608> Reviewed by Mark Lam. * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): 2017-07-13 Caio Lima <ticaiolima@gmail.com> [ESnext] Implement Object Spread https://bugs.webkit.org/show_bug.cgi?id=167963 Reviewed by Saam Barati. This patch implements ECMA262 stage 3 Object Spread proposal [1]. It's implemented using CopyDataPropertiesNoExclusions to copy all enumerable keys from object being spreaded. The implementation of CopyDataPropertiesNoExclusions follows the CopyDataProperties implementation, however we don't receive excludedNames as parameter. [1] - https://github.com/tc39/proposal-object-rest-spread * builtins/GlobalOperations.js: (globalPrivate.copyDataPropertiesNoExclusions): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitLoad): * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): (JSC::ObjectSpreadExpressionNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::createObjectSpreadExpression): (JSC::ASTBuilder::createProperty): * parser/NodeConstructors.h: (JSC::PropertyNode::PropertyNode): (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): * parser/Nodes.h: (JSC::ObjectSpreadExpressionNode::expression): * parser/Parser.cpp: (JSC::Parser<LexerType>::parseProperty): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createObjectSpreadExpression): (JSC::SyntaxChecker::createProperty): 2017-07-12 Mark Lam <mark.lam@apple.com> Gardening: build fix after r219434. https://bugs.webkit.org/show_bug.cgi?id=174441 Not reviewed. Make public some MacroAssembler functions that are needed by the probe implementationq. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::trustedImm32FromPtr): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::linkCall): 2017-07-12 Mark Lam <mark.lam@apple.com> Move Probe code from AbstractMacroAssembler to MacroAssembler. https://bugs.webkit.org/show_bug.cgi?id=174441 Reviewed by Saam Barati. This is a pure refactoring patch for moving probe code from the AbstractMacroAssembler to MacroAssembler. There is no code behavior change. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler<AssemblerType>::Address::indexedBy): (JSC::AbstractMacroAssembler::CPUState::gprName): Deleted. (JSC::AbstractMacroAssembler::CPUState::fprName): Deleted. (JSC::AbstractMacroAssembler::CPUState::gpr): Deleted. (JSC::AbstractMacroAssembler::CPUState::fpr): Deleted. (JSC::MacroAssemblerType>::Address::indexedBy): Deleted. * assembler/MacroAssembler.h: (JSC::MacroAssembler::CPUState::gprName): (JSC::MacroAssembler::CPUState::fprName): (JSC::MacroAssembler::CPUState::gpr): (JSC::MacroAssembler::CPUState::fpr): * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerARM::probe): Deleted. * assembler/MacroAssemblerARM.h: * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerARM64::probe): Deleted. * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerARMv7::probe): Deleted. * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerMIPS.h: * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssembler::probe): (JSC::MacroAssemblerX86Common::probe): Deleted. * assembler/MacroAssemblerX86Common.h: 2017-07-12 Saam Barati <sbarati@apple.com> GenericArguments consults the wrong state when tracking modified argument descriptors and mapped arguments https://bugs.webkit.org/show_bug.cgi?id=174411 <rdar://problem/31696186> Reviewed by Mark Lam. The code for deleting an argument was incorrectly referencing state when it decided if it should unmap or mark a property as having its descriptor modified. This patch fixes the bug where if we delete a property, we would sometimes not unmap an argument when deleting it. * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments<Type>::getOwnPropertySlot): (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex): (JSC::GenericArguments<Type>::deleteProperty): (JSC::GenericArguments<Type>::deletePropertyByIndex): 2017-07-12 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r219176. https://bugs.webkit.org/show_bug.cgi?id=174436 "Can cause infinite recursion on iOS" (Requested by mlam on #webkit). Reverted changeset: "WTF::Thread should have the threads stack bounds." https://bugs.webkit.org/show_bug.cgi?id=173975 http://trac.webkit.org/changeset/219176 2017-07-12 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r219401. This revision rolled out the previous patch, but after talking with reviewer, a rebaseline is what was needed.Rolling back in before rebaseline. Reverted changeset: "Unreviewed, rolling out r219379." https://bugs.webkit.org/show_bug.cgi?id=174400 http://trac.webkit.org/changeset/219401 2017-07-12 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r219379. This revision caused a consistent failure in the test fast/dom/Window/property-access-on-cached-window-after-frame- removed.html. Reverted changeset: "Remove NAVIGATOR_HWCONCURRENCY" https://bugs.webkit.org/show_bug.cgi?id=174400 http://trac.webkit.org/changeset/219379 2017-07-12 Tooru Fujisawa [:arai] <arai.unmht@gmail.com> Wrong radix used in Unicode Escape in invalid character error message https://bugs.webkit.org/show_bug.cgi?id=174419 Reviewed by Alex Christensen. * parser/Lexer.cpp: (JSC::Lexer<T>::invalidCharacterMessage): 2017-07-11 Dean Jackson <dino@apple.com> Remove NAVIGATOR_HWCONCURRENCY https://bugs.webkit.org/show_bug.cgi?id=174400 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: 2017-07-11 Dean Jackson <dino@apple.com> Rolling out r219372. * Configurations/FeatureDefines.xcconfig: 2017-07-11 Dean Jackson <dino@apple.com> Remove NAVIGATOR_HWCONCURRENCY https://bugs.webkit.org/show_bug.cgi?id=174400 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: 2017-07-11 Saam Barati <sbarati@apple.com> remove the empty JavaScriptCore/wasm/js/WebAssemblyFunctionCell.* files https://bugs.webkit.org/show_bug.cgi?id=174397 Rubber stamped by David Kilzer. * wasm/js/WebAssemblyFunctionCell.cpp: Removed. * wasm/js/WebAssemblyFunctionCell.h: Removed. 2017-07-10 Saam Barati <sbarati@apple.com> Allocation sinking phase should consider a CheckStructure that would fail as an escape https://bugs.webkit.org/show_bug.cgi?id=174321 <rdar://problem/32604963> Reviewed by Filip Pizlo. When the allocation sinking phase was generating stores to materialize objects in a cycle with each other, it would assume that each materialized object had a valid, non empty, set of structures. This is an OK assumption for the phase to make because how do you materialize an object with no structure? The abstract interpretation part of the phase will model what's in the heap. However, it would sometimes model that a CheckStructure would fail. The phase did nothing special for this; it just stored the empty set of structures for its representation of a particular allocation. However, what the phase proved in such a scenario is that, had the CheckStructure executed, it would have exited. This patch treats such CheckStructures and MultiGetByOffsets as escape points. This will cause the allocation in question to be materialized just before the CheckStructure, and then at execution time, the CheckStructure will exit. I wasn't able to write a test case for this. However, I was able to reproduce this crash by manually editing the IR. I've opened a separate bug to help us create a testing framework for writing tests for hard to reproduce bugs like this: https://bugs.webkit.org/show_bug.cgi?id=174322 * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-10 Devin Rousso <drousso@apple.com> Web Inspector: Highlight matching CSS canvas clients when hovering contexts in the Resources tab https://bugs.webkit.org/show_bug.cgi?id=174279 Reviewed by Matt Baker. * inspector/protocol/DOM.json: Add `highlightNodeList` command that will highlight each node in the given list. 2017-07-03 Brian Burg <bburg@apple.com> Web Replay: remove some unused code https://bugs.webkit.org/show_bug.cgi?id=173903 Rubber-stamped by Joseph Pecoraro. * CMakeLists.txt: * Configurations/FeatureDefines.xcconfig: * DerivedSources.make: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/protocol/Replay.json: Removed. * replay/EmptyInputCursor.h: Removed. * replay/EncodedValue.cpp: Removed. * replay/EncodedValue.h: Removed. * replay/InputCursor.h: Removed. * replay/JSInputs.json: Removed. * replay/NondeterministicInput.h: Removed. * replay/scripts/CodeGeneratorReplayInputs.py: Removed. * replay/scripts/CodeGeneratorReplayInputsTemplates.py: Removed. * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error: Removed. * replay/scripts/tests/expected/fail-on-duplicate-enum-type.json-error: Removed. * replay/scripts/tests/expected/fail-on-duplicate-input-names.json-error: Removed. * replay/scripts/tests/expected/fail-on-duplicate-type-names.json-error: Removed. * replay/scripts/tests/expected/fail-on-enum-type-missing-values.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-input-member-name.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-input-name.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-input-queue.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-type-mode.json-error: Removed. * replay/scripts/tests/expected/fail-on-missing-type-name.json-error: Removed. * replay/scripts/tests/expected/fail-on-unknown-input-queue.json-error: Removed. * replay/scripts/tests/expected/fail-on-unknown-member-type.json-error: Removed. * replay/scripts/tests/expected/fail-on-unknown-type-mode.json-error: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-event-loop-shape-types.json-error: Removed. * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h: Removed. * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp: Removed. * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h: Removed. * replay/scripts/tests/fail-on-c-style-enum-no-storage.json: Removed. * replay/scripts/tests/fail-on-duplicate-enum-type.json: Removed. * replay/scripts/tests/fail-on-duplicate-input-names.json: Removed. * replay/scripts/tests/fail-on-duplicate-type-names.json: Removed. * replay/scripts/tests/fail-on-enum-type-missing-values.json: Removed. * replay/scripts/tests/fail-on-missing-input-member-name.json: Removed. * replay/scripts/tests/fail-on-missing-input-name.json: Removed. * replay/scripts/tests/fail-on-missing-input-queue.json: Removed. * replay/scripts/tests/fail-on-missing-type-mode.json: Removed. * replay/scripts/tests/fail-on-missing-type-name.json: Removed. * replay/scripts/tests/fail-on-unknown-input-queue.json: Removed. * replay/scripts/tests/fail-on-unknown-member-type.json: Removed. * replay/scripts/tests/fail-on-unknown-type-mode.json: Removed. * replay/scripts/tests/generate-enum-encoding-helpers-with-guarded-values.json: Removed. * replay/scripts/tests/generate-enum-encoding-helpers.json: Removed. * replay/scripts/tests/generate-enum-with-guard.json: Removed. * replay/scripts/tests/generate-enums-with-same-base-name.json: Removed. * replay/scripts/tests/generate-event-loop-shape-types.json: Removed. * replay/scripts/tests/generate-input-with-guard.json: Removed. * replay/scripts/tests/generate-input-with-vector-members.json: Removed. * replay/scripts/tests/generate-inputs-with-flags.json: Removed. * replay/scripts/tests/generate-memoized-type-modes.json: Removed. * runtime/DateConstructor.cpp: (JSC::constructDate): (JSC::dateNow): (JSC::deterministicCurrentTime): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::setInputCursor): Deleted. * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::inputCursor): Deleted. 2017-07-10 Carlos Garcia Campos <cgarcia@igalia.com> Move make-js-file-arrays.py from WebCore to JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=174024 Reviewed by Michael Catanzaro. It's currently used only by WebCore, but it depends on other JavaScriptCore scripts and it's not WebCore specific at all. I plan to use it to compile the JavaScript atoms used by the WebDriver implementation. Added command line option to pass the namespace to use instead of using WebCore. * JavaScriptCore.xcodeproj/project.pbxproj: * Scripts/make-js-file-arrays.py: Renamed from Source/WebCore/Scripts/make-js-file-arrays.py. (main): 2017-07-09 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Drop LineNumberAdder since we no longer treat <LF><CR> (not <CR><LF>) as one line terminator https://bugs.webkit.org/show_bug.cgi?id=174296 Reviewed by Mark Lam. Previously, we treat <LF><CR> as one line terminator. So we increase line number by one. It caused a problem in scanning template literals. While template literals normalize <LF><CR> to <LF><LF>, we still needed to increase line number by only one. To handle it correctly, LineNumberAdder is introduced. As of r219263, <LF><CR> is counted as two line terminators. So we do not need to have LineNumberAdder. Let's just use shiftLineTerminator() instead. * parser/Lexer.cpp: (JSC::Lexer<T>::parseTemplateLiteral): (JSC::LineNumberAdder::LineNumberAdder): Deleted. (JSC::LineNumberAdder::clear): Deleted. (JSC::LineNumberAdder::add): Deleted. 2017-07-09 Dan Bernstein <mitz@apple.com> [Xcode] ICU headers aren’t treated as system headers after r219155 https://bugs.webkit.org/show_bug.cgi?id=174299 Reviewed by Sam Weinig. * Configurations/JavaScriptCore.xcconfig: Pass --system-header-prefix=unicode/ to the C and C++ compilers. * runtime/IntlCollator.cpp: Removed documentation warning suppression. * runtime/IntlDateTimeFormat.cpp: Ditto. * runtime/JSGlobalObject.cpp: Ditto. * runtime/StringPrototype.cpp: Ditto. 2017-07-09 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use fastMalloc / fastFree for STL containers https://bugs.webkit.org/show_bug.cgi?id=174297 Reviewed by Sam Weinig. In some places, we intentionally use STL containers over WTF containers. For example, we sometimes use std::unordered_{set,map} instead of WTF::Hash{Set,Map} because we do not have effective empty / deleted representations in the space of key's value. But just using STL container means using libc's malloc instead of our fast malloc (bmalloc if it is enabled). We introduce WTF::FastAllocator. This is C++ allocator implementation using fastMalloc and fastFree. We specify this allocator to STL containers' template parameter to allocate memory from fastMalloc. This WTF::FastAllocator gives us a chance to use STL containers if it is necessary without compromising memory allocation throughput. * dfg/DFGGraph.h: * dfg/DFGIntegerCheckCombiningPhase.cpp: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow): * runtime/FunctionHasExecutedCache.h: * runtime/TypeLocationCache.h: 2017-07-08 Yusuke Suzuki <utatane.tea@gmail.com> Drop NOSNIFF compile flag https://bugs.webkit.org/show_bug.cgi?id=174289 Reviewed by Michael Catanzaro. * Configurations/FeatureDefines.xcconfig: 2017-07-07 AJ Ringer <aringer@apple.com> Lower the max_protection for the separated heap https://bugs.webkit.org/show_bug.cgi?id=174281 Reviewed by Oliver Hunt. Switch to vm_protect so we can set maximum page protection. * jit/ExecutableAllocator.cpp: (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps): (JSC::ExecutableAllocator::allocate): 2017-07-07 Devin Rousso <drousso@apple.com> Web Inspector: Show all elements currently using a given CSS Canvas https://bugs.webkit.org/show_bug.cgi?id=173965 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add `requestCSSCanvasClientNodes` command for getting the node IDs all nodes using this canvas via -webkit-canvas. - Add `cssCanvasClientNodesChanged` event that is dispatched whenever a node is added/removed from the list of -webkit-canvas clients. 2017-07-07 Mark Lam <mark.lam@apple.com> \n\r is not the same as \r\n. https://bugs.webkit.org/show_bug.cgi?id=173053 Reviewed by Keith Miller. * parser/Lexer.cpp: (JSC::Lexer<T>::shiftLineTerminator): (JSC::LineNumberAdder::add): 2017-07-07 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r219238, r219239, and r219241. https://bugs.webkit.org/show_bug.cgi?id=174265 "fast/workers/dedicated-worker-lifecycle.html is flaky" (Requested by yusukesuzuki on #webkit). Reverted changesets: "[WTF] Implement WTF::ThreadGroup" https://bugs.webkit.org/show_bug.cgi?id=174081 http://trac.webkit.org/changeset/219238 "Unreviewed, build fix after r219238" https://bugs.webkit.org/show_bug.cgi?id=174081 http://trac.webkit.org/changeset/219239 "Unreviewed, CLoop build fix after r219238" https://bugs.webkit.org/show_bug.cgi?id=174081 http://trac.webkit.org/changeset/219241 2017-07-06 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, CLoop build fix after r219238 https://bugs.webkit.org/show_bug.cgi?id=174081 * heap/MachineStackMarker.cpp: 2017-07-05 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Implement WTF::ThreadGroup https://bugs.webkit.org/show_bug.cgi?id=174081 Reviewed by Mark Lam. Large part of MachineThreads are now removed and replaced with WTF::ThreadGroup. And SamplingProfiler and others interact with WTF::Thread directly. * API/tests/ExecutionTimeLimitTest.cpp: * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): (JSC::captureStack): (JSC::MachineThreads::tryCopyOtherThreadStack): (JSC::MachineThreads::tryCopyOtherThreadStacks): (JSC::MachineThreads::gatherConservativeRoots): (JSC::ActiveMachineThreadsManager::Locker::Locker): Deleted. (JSC::ActiveMachineThreadsManager::add): Deleted. (JSC::ActiveMachineThreadsManager::remove): Deleted. (JSC::ActiveMachineThreadsManager::contains): Deleted. (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager): Deleted. (JSC::activeMachineThreadsManager): Deleted. (JSC::MachineThreads::~MachineThreads): Deleted. (JSC::MachineThreads::addCurrentThread): Deleted. (): Deleted. (JSC::MachineThreads::removeThread): Deleted. (JSC::MachineThreads::removeThreadIfFound): Deleted. (JSC::MachineThreads::MachineThread::MachineThread): Deleted. (JSC::MachineThreads::MachineThread::getRegisters): Deleted. (JSC::MachineThreads::MachineThread::Registers::stackPointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::framePointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::instructionPointer): Deleted. (JSC::MachineThreads::MachineThread::Registers::llintPC): Deleted. (JSC::MachineThreads::MachineThread::captureStack): Deleted. * heap/MachineStackMarker.h: (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::getLock): (JSC::MachineThreads::threads): (JSC::MachineThreads::MachineThread::suspend): Deleted. (JSC::MachineThreads::MachineThread::resume): Deleted. (JSC::MachineThreads::MachineThread::threadID): Deleted. (JSC::MachineThreads::MachineThread::stackBase): Deleted. (JSC::MachineThreads::MachineThread::stackEnd): Deleted. (JSC::MachineThreads::threadsListHead): Deleted. * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::takeSample): (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread): * runtime/SamplingProfiler.h: * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-07-06 Saam Barati <sbarati@apple.com> We are missing places where we invalidate the for-in context https://bugs.webkit.org/show_bug.cgi?id=174184 Reviewed by Geoffrey Garen. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::invalidateForInContextForLocal): * bytecompiler/NodesCodegen.cpp: (JSC::EmptyLetExpression::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::BindingNode::bindValue): 2017-07-06 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, suppress warnings in GCC environment * dfg/DFGObjectAllocationSinkingPhase.cpp: * runtime/IntlCollator.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/JSGlobalObject.cpp: * runtime/StringPrototype.cpp: 2017-07-05 Saam Barati <sbarati@apple.com> NewArray in FTLLowerDFGToB3 does not handle speculating on doubles when having a bad time https://bugs.webkit.org/show_bug.cgi?id=174188 <rdar://problem/30581423> Reviewed by Mark Lam. We were calling lowJSValue(edge) when we were speculating the edge as double. This isn't allowed. We should have been using lowDouble. This patch also adds a new option, called useArrayAllocationProfiling, which defaults to true. When false, it will make the array allocation profile not actually sample seen arrays. It'll force the allocation profile's predicted indexing type to be ArrayWithUndecided. Adding this option made it trivial to write a test for this bug. * bytecode/ArrayAllocationProfile.cpp: (JSC::ArrayAllocationProfile::updateIndexingType): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNewArray): * runtime/Options.h: 2017-07-05 Yusuke Suzuki <utatane.tea@gmail.com> WTF::Thread should have the threads stack bounds. https://bugs.webkit.org/show_bug.cgi?id=173975 Reviewed by Keith Miller. There is a site in JSC that try to walk another thread's stack. Currently, stack bounds are stored in WTFThreadData which is located in TLS. Thus, only the thread itself can access its own WTFThreadData. We workaround this situation by holding StackBounds in MachineThread in JSC, but StackBounds should be put in WTF::Thread instead. This patch moves StackBounds from WTFThreadData to WTF::Thread. StackBounds information is tightly coupled with Thread. Thus putting it in WTF::Thread is natural choice. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::captureStack): * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimits): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::isSafeToRecurse): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * runtime/VMTraps.cpp: * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse): 2017-07-05 Keith Miller <keith_miller@apple.com> Crashing with information should have an abort reason https://bugs.webkit.org/show_bug.cgi?id=174185 Reviewed by Saam Barati. Add crash information for the abstract interpreter and add an enum value for object allocation sinking. * assembler/AbortReason.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge): * dfg/DFGGraph.cpp: (JSC::DFG::logDFGAssertionFailure): * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-03 Myles C. Maxfield <mmaxfield@apple.com> Remove copy of ICU headers from WebKit https://bugs.webkit.org/show_bug.cgi?id=116407 Reviewed by Alex Christensen. Use WTF's copy of ICU headers. * Configurations/Base.xcconfig: * icu/unicode/localpointer.h: Removed. * icu/unicode/parseerr.h: Removed. * icu/unicode/platform.h: Removed. * icu/unicode/ptypes.h: Removed. * icu/unicode/putil.h: Removed. * icu/unicode/uchar.h: Removed. * icu/unicode/ucnv.h: Removed. * icu/unicode/ucnv_err.h: Removed. * icu/unicode/ucol.h: Removed. * icu/unicode/uconfig.h: Removed. * icu/unicode/ucurr.h: Removed. * icu/unicode/uenum.h: Removed. * icu/unicode/uiter.h: Removed. * icu/unicode/uloc.h: Removed. * icu/unicode/umachine.h: Removed. * icu/unicode/unorm.h: Removed. * icu/unicode/unorm2.h: Removed. * icu/unicode/urename.h: Removed. * icu/unicode/uscript.h: Removed. * icu/unicode/uset.h: Removed. * icu/unicode/ustring.h: Removed. * icu/unicode/utf.h: Removed. * icu/unicode/utf16.h: Removed. * icu/unicode/utf8.h: Removed. * icu/unicode/utf_old.h: Removed. * icu/unicode/utypes.h: Removed. * icu/unicode/uvernum.h: Removed. * icu/unicode/uversion.h: Removed. * runtime/IntlCollator.cpp: * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): * runtime/JSGlobalObject.cpp: * runtime/StringPrototype.cpp: (JSC::normalize): (JSC::stringProtoFuncNormalize): 2017-07-05 Devin Rousso <drousso@apple.com> Web Inspector: Allow users to log any tracked canvas context https://bugs.webkit.org/show_bug.cgi?id=173397 <rdar://problem/33111581> Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: Add `resolveCanvasContext` command that returns a RemoteObject for the given canvas context. 2017-07-05 Jonathan Bedard <jbedard@apple.com> Add WebKitPrivateFrameworkStubs for iOS 11 https://bugs.webkit.org/show_bug.cgi?id=173988 Reviewed by David Kilzer. * Configurations/Base.xcconfig: iphoneos and iphonesimulator should use the same directory for private framework stubs. 2017-07-05 JF Bastien <jfbastien@apple.com> WebAssembly: implement name section's module name, skip unknown sections https://bugs.webkit.org/show_bug.cgi?id=172008 Reviewed by Keith Miller. Parse the WebAssembly module name properly, and skip unknown sections. This is useful because as toolchains support new types of names we want to keep displaying the information we know about and simply ignore new information. That capability was designed into WebAssembly's name section. Failure to commit this patch would mean that WebKit won't display stack trace information, which would make developers sad. Module names were added here: https://github.com/WebAssembly/design/pull/1055 Note that this patch doesn't do anything with the parsed name! Two reasons for this: module names aren't supported in binaryen yet, so I can't write a simple binary test; and using the name is a slightly riskier change because it requires changing StackVisitor + StackFrame (where they print "[wasm code]") which requires figuring out the frame's Module. The latter bit isn't trivial because we only know wasm frames from their tag bits, and CodeBlocks are always nullptr. Binaryen bug: https://github.com/WebAssembly/binaryen/issues/1010 I filed #174098 to use the module name. * wasm/WasmFormat.h: (JSC::Wasm::isValidNameType): * wasm/WasmNameSectionParser.cpp: 2017-07-04 Joseph Pecoraro <pecoraro@apple.com> Cleanup some StringBuilder use https://bugs.webkit.org/show_bug.cgi?id=174118 Reviewed by Andreas Kling. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * tools/FunctionOverrides.cpp: (JSC::parseClause): * wasm/WasmOMGPlan.cpp: * wasm/WasmPlan.cpp: * wasm/WasmValidate.cpp: 2017-07-03 Saam Barati <sbarati@apple.com> LayoutTest workers/bomb.html is a Crash https://bugs.webkit.org/show_bug.cgi?id=167757 <rdar://problem/33086462> Reviewed by Keith Miller. VMTraps::SignalSender was accessing VM fields even after the VM was destroyed. This happened when the SignalSender thread was in the middle of its work() function while VMTraps was notified that the VM was shutting down. The VM would proceed to run its destructor even after the SignalSender thread finished doing its work. This means that the SignalSender thread was accessing VM field eve after VM was destructed (including itself, since it is transitively owned by the VM). The VM must wait for the SignalSender thread to shutdown before it can continue to destruct itself. * runtime/VMTraps.cpp: (JSC::VMTraps::willDestroyVM): 2017-07-03 Saam Barati <sbarati@apple.com> DFGBytecodeParser op_to_this does not access the correct instruction offset for to this status https://bugs.webkit.org/show_bug.cgi?id=174110 Reviewed by Michael Saboff. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): 2017-07-03 Saam Barati <sbarati@apple.com> Add a new assertion to object allocation sinking phase https://bugs.webkit.org/show_bug.cgi?id=174107 Rubber stamped by Filip Pizlo. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-03 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r219060. https://bugs.webkit.org/show_bug.cgi?id=174108 crashing constantly when initializing UIWebView (Requested by thorton on #webkit). Reverted changeset: "WTF::Thread should have the threads stack bounds." https://bugs.webkit.org/show_bug.cgi?id=173975 http://trac.webkit.org/changeset/219060 2017-07-03 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r219103. Caused multiple build failures. Reverted changeset: "Remove copy of ICU headers from WebKit" https://bugs.webkit.org/show_bug.cgi?id=116407 http://trac.webkit.org/changeset/219103 2017-07-03 Myles C. Maxfield <mmaxfield@apple.com> Remove copy of ICU headers from WebKit https://bugs.webkit.org/show_bug.cgi?id=116407 Reviewed by Alex Christensen. Use WTF's copy of ICU headers. * Configurations/Base.xcconfig: * icu/unicode/localpointer.h: Removed. * icu/unicode/parseerr.h: Removed. * icu/unicode/platform.h: Removed. * icu/unicode/ptypes.h: Removed. * icu/unicode/putil.h: Removed. * icu/unicode/uchar.h: Removed. * icu/unicode/ucnv.h: Removed. * icu/unicode/ucnv_err.h: Removed. * icu/unicode/ucol.h: Removed. * icu/unicode/uconfig.h: Removed. * icu/unicode/ucurr.h: Removed. * icu/unicode/uenum.h: Removed. * icu/unicode/uiter.h: Removed. * icu/unicode/uloc.h: Removed. * icu/unicode/umachine.h: Removed. * icu/unicode/unorm.h: Removed. * icu/unicode/unorm2.h: Removed. * icu/unicode/urename.h: Removed. * icu/unicode/uscript.h: Removed. * icu/unicode/uset.h: Removed. * icu/unicode/ustring.h: Removed. * icu/unicode/utf.h: Removed. * icu/unicode/utf16.h: Removed. * icu/unicode/utf8.h: Removed. * icu/unicode/utf_old.h: Removed. * icu/unicode/utypes.h: Removed. * icu/unicode/uvernum.h: Removed. * icu/unicode/uversion.h: Removed. * runtime/IntlCollator.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/JSGlobalObject.cpp: * runtime/StringPrototype.cpp: 2017-07-03 Saam Barati <sbarati@apple.com> Add better crash logging for allocation sinking phase https://bugs.webkit.org/show_bug.cgi?id=174102 <rdar://problem/33112092> Rubber stamped by Filip Pizlo. I'm trying to gather better information from crashlogs about why we're crashing in the allocation sinking phase. I'm adding a allocation sinking specific RELEASE_ASSERT as well as marking a few functions as NEVER_INLINE to have the stack traces in the crash trace contain more actionable information. * dfg/DFGObjectAllocationSinkingPhase.cpp: 2017-07-03 Sam Weinig <sam@webkit.org> [WebIDL] Remove more unnecessary uses of the preprocessor in idl files https://bugs.webkit.org/show_bug.cgi?id=174083 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: Add ENABLE_NAVIGATOR_STANDALONE. 2017-07-03 Andy Estes <aestes@apple.com> [Xcode] Add an experimental setting to build with ccache https://bugs.webkit.org/show_bug.cgi?id=173875 Reviewed by Tim Horton. * Configurations/DebugRelease.xcconfig: Included ccache.xcconfig. 2017-07-03 Devin Rousso <drousso@apple.com> Web Inspector: Support listing WebGL2 and WebGPU contexts https://bugs.webkit.org/show_bug.cgi?id=173396 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: * inspector/scripts/codegen/generator.py: (Generator.stylized_name_for_enum_value): Add cases for handling new Canvas.ContextType protocol enumerations: - "webgl2" maps to `WebGL2` - "webgpu" maps to `WebGPU` 2017-07-02 Yusuke Suzuki <utatane.tea@gmail.com> WTF::Thread should have the threads stack bounds. https://bugs.webkit.org/show_bug.cgi?id=173975 Reviewed by Mark Lam. There is a site in JSC that try to walk another thread's stack. Currently, stack bounds are stored in WTFThreadData which is located in TLS. Thus, only the thread itself can access its own WTFThreadData. We workaround this situation by holding StackBounds in MachineThread in JSC, but StackBounds should be put in WTF::Thread instead. This patch moves StackBounds from WTFThreadData to WTF::Thread. StackBounds information is tightly coupled with Thread. Thus putting it in WTF::Thread is natural choice. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::captureStack): * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::updateStackLimits): (JSC::VM::committedStackByteCount): * runtime/VM.h: (JSC::VM::isSafeToRecurse): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): * runtime/VMInlines.h: (JSC::VM::ensureStackCapacityFor): * runtime/VMTraps.cpp: * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPatternConstructor::isSafeToRecurse): 2017-07-01 Dan Bernstein <mitz@apple.com> [iOS] Remove code only needed when building for iOS 9.x https://bugs.webkit.org/show_bug.cgi?id=174068 Reviewed by Tim Horton. * Configurations/FeatureDefines.xcconfig: * jit/ExecutableAllocator.cpp: * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2017-07-01 Dan Bernstein <mitz@apple.com> [macOS] Remove code only needed when building for OS X Yosemite https://bugs.webkit.org/show_bug.cgi?id=174067 Reviewed by Tim Horton. * API/WebKitAvailability.h: * Configurations/Base.xcconfig: * Configurations/DebugRelease.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/Version.xcconfig: 2017-07-01 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for GCC https://bugs.webkit.org/show_bug.cgi?id=174034 * b3/testb3.cpp: (JSC::B3::testDoubleLiteralComparison): 2017-06-30 Keith Miller <keith_miller@apple.com> Force crashWithInfo to be out of line. https://bugs.webkit.org/show_bug.cgi?id=174028 Reviewed by Filip Pizlo. Update DFG_ASSERT macro to call CRASH_WITH_SECURITY_IMPLICATION_AND_INFO. * dfg/DFGGraph.cpp: (JSC::DFG::logDFGAssertionFailure): (JSC::DFG::Graph::logAssertionFailure): (JSC::DFG::crash): Deleted. (JSC::DFG::Graph::handleAssertionFailure): Deleted. * dfg/DFGGraph.h: 2017-06-30 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use AbstractMacroAssembler::random instead of holding WeakRandom in JIT https://bugs.webkit.org/show_bug.cgi?id=174053 Reviewed by Geoffrey Garen. We already have AbstractMacroAssembler::random() function. Use it instead. * jit/JIT.cpp: (JSC::JIT::JIT): (JSC::JIT::compileWithoutLinking): * jit/JIT.h: 2017-06-30 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Drop SymbolRegistry::keyForSymbol https://bugs.webkit.org/show_bug.cgi?id=174052 Reviewed by Sam Weinig. * runtime/SymbolConstructor.cpp: (JSC::symbolConstructorKeyFor): 2017-06-30 Saam Barati <sbarati@apple.com> B3ReduceStrength should reduce EqualOrUnordered over const float input https://bugs.webkit.org/show_bug.cgi?id=174039 Reviewed by Michael Saboff. We perform this folding for ConstDoubleValue. It is simply an oversight that we didn't do it for ConstFloatValue. * b3/B3ConstFloatValue.cpp: (JSC::B3::ConstFloatValue::equalOrUnorderedConstant): * b3/B3ConstFloatValue.h: * b3/testb3.cpp: (JSC::B3::testFloatEqualOrUnorderedFolding): (JSC::B3::testFloatEqualOrUnorderedFoldingNaN): (JSC::B3::testFloatEqualOrUnorderedDontFold): (JSC::B3::run): 2017-06-30 Matt Baker <mattbaker@apple.com> Web Inspector: AsyncStackTrace nodes can be corrupted when truncating https://bugs.webkit.org/show_bug.cgi?id=173840 <rdar://problem/30840820> Reviewed by Joseph Pecoraro. When truncating an asynchronous stack trace, the parent chain is traversed until a locked node is found. The path from this node to the root is shared by more than one stack trace, and cannot be safely modified. Starting at the first locked node, the path is cloned and becomes a new stack trace tree. However, the clone operation initialized each new AsyncStackTrace node with the original node's parent. This would increment the child count of the original node. When cloning nodes, new nodes should not have their parent set until the next node up the parent chain is cloned. * inspector/AsyncStackTrace.cpp: (Inspector::AsyncStackTrace::truncate): 2017-06-30 Michael Saboff <msaboff@apple.com> RegExp's anchored with .* with \g flag can return wrong match start for strings with multiple matches https://bugs.webkit.org/show_bug.cgi?id=174044 Reviewed by Oliver Hunt. The .* enclosure optimization didn't respect that we can start matching from a non-zero index. This optimization treats /.*<some-terms>.*/ by first matching the <some-terms> and then finding the extent of the match by going back to the beginning of the line and going forward to the end of the line. The code that went back to the beginning of the line checked for an index of 0 instead of comparing the index to the start position. This start position is passed as the initial index. Added another temporary register to the YARR JIT to contain the start position for platforms that have spare registers. * yarr/Yarr.h: * yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::matchDotStarEnclosure): (JSC::Yarr::Interpreter::Interpreter): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::generateDotStarEnclosure): (JSC::Yarr::YarrGenerator::compile): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::YarrPattern): * yarr/YarrPattern.h: (JSC::Yarr::YarrPattern::reset): 2017-06-30 Saam Barati <sbarati@apple.com> B3MoveConstants floatZero() returns the wrong ValueKey https://bugs.webkit.org/show_bug.cgi?id=174040 Reviewed by Filip Pizlo. It had a typo where the ValueKey for floatZero() produces a Double instead of a Float. * b3/B3MoveConstants.cpp: 2017-06-30 Saam Barati <sbarati@apple.com> B3ReduceDoubleToFloat incorrectly reduces operations over two double constants https://bugs.webkit.org/show_bug.cgi?id=174034 <rdar://problem/30793007> Reviewed by Filip Pizlo. B3ReduceDoubleToFloat had a bug in it where it would incorrectly reduce binary operations over double constants into the same binary operation over the double constants casted to floats. This is clearly incorrect as these two things will produce different values. For example: a = DoubleConst(bitwise_cast<double>(0x8000000000000001ull)) b = DoubleConst(bitwise_cast<double>(0x0000000000000000ull)) c = EqualOrUnordered(@a, @b) // produces 0 into: a = FloatConst(static_cast<float>(bitwise_cast<double>(0x8000000000000001ull))) b = FloatConst(static_cast<float>(bitwise_cast<double>(0x0000000000000000ull))) c = EqualOrUnordered(@a, @b) // produces 1 Which produces a different value for @c. * b3/B3ReduceDoubleToFloat.cpp: * b3/testb3.cpp: (JSC::B3::doubleEq): (JSC::B3::doubleNeq): (JSC::B3::doubleGt): (JSC::B3::doubleGte): (JSC::B3::doubleLt): (JSC::B3::doubleLte): (JSC::B3::testDoubleLiteralComparison): (JSC::B3::run): 2017-06-29 Jer Noble <jer.noble@apple.com> Make Legacy EME API controlled by RuntimeEnabled setting. https://bugs.webkit.org/show_bug.cgi?id=173994 Reviewed by Sam Weinig. * Configurations/FeatureDefines.xcconfig: * runtime/CommonIdentifiers.h: 2017-06-30 Ryosuke Niwa <rniwa@webkit.org> Ran sort-Xcode-project-file. * JavaScriptCore.xcodeproj/project.pbxproj: 2017-06-30 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r218992. The patch broke the iOS device builds. Reverted changeset: "DFG_ASSERT should allow stuffing registers before trapping." https://bugs.webkit.org/show_bug.cgi?id=174005 http://trac.webkit.org/changeset/218992 2017-06-30 Filip Pizlo <fpizlo@apple.com> RegExpCachedResult::setInput should reify left and right contexts https://bugs.webkit.org/show_bug.cgi?id=173818 Reviewed by Keith Miller. If you don't reify them in setInput, then when you later try to reify them, you'll end up using indices into an old input string to create a substring of a new input string. That never goes well. * runtime/RegExpCachedResult.cpp: (JSC::RegExpCachedResult::setInput): 2017-06-30 Keith Miller <keith_miller@apple.com> DFG_ASSERT should allow stuffing registers before trapping. https://bugs.webkit.org/show_bug.cgi?id=174005 Reviewed by Mark Lam. DFG_ASSERT currently prints error data to stderr before crashing, which is nice for local development. In the wild, however, we can't see this information in crash logs. This patch enables stuffing some of the most useful information from DFG_ASSERTS into up to five registers right before crashing. The values stuffed should not impact any logging during local development. * assembler/AbortReason.h: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge): * dfg/DFGGraph.cpp: (JSC::DFG::logForCrash): (JSC::DFG::Graph::logAssertionFailure): (JSC::DFG::crash): Deleted. (JSC::DFG::Graph::handleAssertionFailure): Deleted. * dfg/DFGGraph.h: 2017-06-29 Saam Barati <sbarati@apple.com> Calculating postCapacity in unshiftCountSlowCase is wrong https://bugs.webkit.org/show_bug.cgi?id=173992 <rdar://problem/32283199> Reviewed by Keith Miller. This patch fixes a bug inside unshiftCountSlowCase where we would use more memory than we allocated. The bug was when deciding how much extra space we have after the vector we've allocated. This area is called the postCapacity. The largest legal postCapacity value we could use is the space we allocated minus the space we need: largestPossiblePostCapacity = newStorageCapacity - requiredVectorLength; However, the code was calculating the postCapacity as: postCapacity = max(newStorageCapacity - requiredVectorLength, count); where count is how many elements we're appending. Depending on the inputs, count could be larger than (newStorageCapacity - requiredVectorLength). This would cause us to use more memory than we actually allocated. * runtime/JSArray.cpp: (JSC::JSArray::unshiftCountSlowCase): 2017-06-29 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r218512. https://bugs.webkit.org/show_bug.cgi?id=173981 "It changes the behavior of the JS API's JSEvaluateScript which breaks TurboTax" (Requested by saamyjoon on #webkit). Reverted changeset: "test262: Completion values for control flow do not match the spec" https://bugs.webkit.org/show_bug.cgi?id=171265 http://trac.webkit.org/changeset/218512 2017-06-29 JF Bastien <jfbastien@apple.com> WebAssembly: disable some APIs under CSP https://bugs.webkit.org/show_bug.cgi?id=173892 <rdar://problem/32914613> Reviewed by Daniel Bates. We should disable parts of WebAssembly under Content Security Policy as discussed here: https://github.com/WebAssembly/design/issues/1092 Exactly what should be disabled isn't super clear, so we may as well be conservative and disable many things if developers already opted into CSP. It's easy to loosen what we disable later. This patch disables: - WebAssembly.Instance - WebAssembly.instantiate - WebAssembly.Memory - WebAssembly.Table And leaves: - WebAssembly on the global object - WebAssembly.Module - WebAssembly.compile - WebAssembly.CompileError - WebAssembly.LinkError Nothing because currently unimplmented: - WebAssembly.compileStreaming - WebAssembly.instantiateStreaming That way it won't be possible to call WebAssembly-compiled code, or create memories (which use fancy 4GiB allocations sometimes). Table isn't really useful on its own, and eventually we may make them shareable so without more details it seems benign to disable them (and useless if we don't). I haven't done anything with postMessage, so you can still postMessage a WebAssembly.Module cross-CSP, but you can't instantiate it so it's useless. Because of this I elected to leave WebAssembly.Module and friends available. I haven't added any new directives. It's still unsafe-eval. We can add something else later, but it seems odd to add a WebAssembly as a new capability and tell developers "you should have been using this directive which we just implemented if you wanted to disable WebAssembly which didn't exist when you adopted CSP". So IMO we should keep unsafe-eval as it currently is, add WebAssembly to what it disables, and later consider having two new directives which do each individually or something. In all cases I throw an EvalError *before* other WebAssembly errors would be produced. Note that, as for eval, reporting doesn't work and is tracked by https://webkit.org/b/111869 * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::webAssemblyEnabled): (JSC::JSGlobalObject::webAssemblyDisabledErrorMessage): (JSC::JSGlobalObject::setWebAssemblyEnabled): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::create): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::create): * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::constructJSWebAssemblyMemory): 2017-06-28 Keith Miller <keith_miller@apple.com> VMTraps has some races https://bugs.webkit.org/show_bug.cgi?id=173941 Reviewed by Michael Saboff. This patch refactors much of the VMTraps API. On the message sending side: 1) No longer uses the Yarr JIT check to determine if we are in RegExp code. That was unsound because RegExp JIT code can be run on compilation threads. Instead it looks at the current frame's code block slot and checks if it is valid, which is the same as what it did for JIT code previously. 2) Only have one signal sender thread, previously, there could be many at once, which caused some data races. Additionally, the signal sender thread is an automatic thread so it will deallocate itself when not in use. On the VMTraps breakpoint side: 1) We now have a true mapping of if we hit a breakpoint instead of a JIT assertion. So the exception handler won't eat JIT assertions anymore. 2) It jettisons all CodeBlocks that have VMTraps breakpoints on them instead of every CodeBlock on the stack. This both prevents us from hitting stale VMTraps breakpoints and also doesn't OSR codeblocks that otherwise don't need to be jettisoned. 3) The old exception handler could theoretically fail for a couple of reasons then resume execution with a clobbered instruction set. This patch will kill the program if the exception handler would fail. This patch also refactors some of the jsc.cpp functions to take the CommandLine options object instead of individual options. Also, there is a new command line option that makes exceptions due to watchdog timeouts an acceptable result. * API/tests/testapi.c: (main): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::installVMTrapBreakpoints): * dfg/DFGCommonData.cpp: (JSC::DFG::pcCodeBlockMap): (JSC::DFG::CommonData::invalidate): (JSC::DFG::CommonData::~CommonData): (JSC::DFG::CommonData::installVMTrapBreakpoints): (JSC::DFG::codeBlockForVMTrapPC): * dfg/DFGCommonData.h: * jsc.cpp: (functionDollarAgentStart): (checkUncaughtException): (checkException): (runWithOptions): (printUsageStatement): (CommandLine::parseArguments): (jscmain): (runWithScripts): Deleted. * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/VMTraps.cpp: (JSC::sanitizedTopCallFrame): (JSC::VMTraps::tryInstallTrapBreakpoints): (JSC::VMTraps::willDestroyVM): (JSC::VMTraps::fireTrap): (JSC::VMTraps::handleTraps): (JSC::VMTraps::VMTraps): (JSC::VMTraps::~VMTraps): (JSC::findActiveVMAndStackBounds): Deleted. (JSC::installSignalHandler): Deleted. (JSC::VMTraps::addSignalSender): Deleted. (JSC::VMTraps::removeSignalSender): Deleted. (JSC::VMTraps::SignalSender::willDestroyVM): Deleted. (JSC::VMTraps::SignalSender::send): Deleted. * runtime/VMTraps.h: (JSC::VMTraps::~VMTraps): Deleted. (JSC::VMTraps::SignalSender::SignalSender): Deleted. 2017-06-28 Devin Rousso <drousso@apple.com> Web Inspector: Instrument active pixel memory used by canvases https://bugs.webkit.org/show_bug.cgi?id=173087 <rdar://problem/32719261> Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add optional `memoryCost` attribute to the `Canvas` type. - Add `canvasMemoryChanged` event that is dispatched when the `memoryCost` of a canvas changes. 2017-06-28 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Cleanup Protocol JSON files https://bugs.webkit.org/show_bug.cgi?id=173934 Reviewed by Matt Baker. * inspector/protocol/ApplicationCache.json: * inspector/protocol/CSS.json: * inspector/protocol/Console.json: * inspector/protocol/DOM.json: * inspector/protocol/DOMDebugger.json: * inspector/protocol/Debugger.json: * inspector/protocol/LayerTree.json: * inspector/protocol/Network.json: * inspector/protocol/Page.json: * inspector/protocol/Runtime.json: Be more consistent about placement of `description` property. 2017-06-27 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Remove unused Inspector domain events https://bugs.webkit.org/show_bug.cgi?id=173905 Reviewed by Matt Baker. * inspector/protocol/Inspector.json: 2017-06-28 JF Bastien <jfbastien@apple.com> Ensure that computed new stack pointer values do not underflow. https://bugs.webkit.org/show_bug.cgi?id=173700 <rdar://problem/32926032> Reviewed by Filip Pizlo and Saam Barati, update reviewed by Mark Lam. Patch by Mark Lam, with the following fix: Re-apply this patch, it originally broke the ARM build because the llint code generated `subs xzr, x3, sp` which isn't valid ARM64: the third operand cannot be SP (that encoding would be ZR instead, subtracting zero). Flip the comparison and operands to emit valid code (because the second operand can be SP). 1. Added a RELEASE_ASSERT to BytecodeGenerator::generate() to ensure that m_numCalleeLocals is sane. 2. Added underflow checks in LLInt code and VarargsFrame code. 3. Introduce minimumReservedZoneSize, which is hardcoded to 16K. Ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize. Ensure that Options::softReservedZoneSize() is at least greater than Options::reservedZoneSize() by minimumReservedZoneSize. 4. Ensure that stack checks emitted by JIT tiers include an underflow check if and only if the max size of the frame is greater than Options::reservedZoneSize(). By design, we are guaranteed to have at least Options::reservedZoneSize() bytes of memory at the bottom (end) of the stack. This means that, at any time, the frame pointer must be at least Options::reservedZoneSize() bytes away from the end of the stack. Hence, if the max frame size is less than Options::reservedZoneSize(), there's no way that frame pointer - max frame size can underflow, and we can elide the underflow check. Note that we use Options::reservedZoneSize() instead of Options::softReservedZoneSize() for determine if we need an underflow check. This is because the softStackLimit that is used for stack checks can be set based on Options::reservedZoneSize() during error handling (e.g. when creating strings for instantiating the Error object). Hence, the guaranteed minimum of distance between the frame pointer and the end of the stack is Options::reservedZoneSize() and nor Options::softReservedZoneSize(). Note also that we ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize (i.e. 16K). In typical deployments, Options::reservedZoneSize() may be larger. Using Options::reservedZoneSize() instead of minimumReservedZoneSize gives us more chances to elide underflow checks. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): * dfg/DFGJITCompiler.cpp: (JSC::DFG::emitStackOverflowCheck): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/MinimumReservedZoneSize.h: Added. * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/VM.cpp: (JSC::VM::updateStackLimits): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-06-28 Chris Dumez <cdumez@apple.com> Unreviewed, rolling out r218869. Broke the iOS build Reverted changeset: "Ensure that computed new stack pointer values do not underflow." https://bugs.webkit.org/show_bug.cgi?id=173700 http://trac.webkit.org/changeset/218869 2017-06-28 Chris Dumez <cdumez@apple.com> Unreviewed, rolling out r218873. Broke the iOS build Reverted changeset: "Gardening: CLoop build fix." https://bugs.webkit.org/show_bug.cgi?id=173700 http://trac.webkit.org/changeset/218873 2017-06-28 Mark Lam <mark.lam@apple.com> Gardening: CLoop build fix. https://bugs.webkit.org/show_bug.cgi?id=173700 <rdar://problem/32926032> Not reviewed. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2017-06-28 Mark Lam <mark.lam@apple.com> Ensure that computed new stack pointer values do not underflow. https://bugs.webkit.org/show_bug.cgi?id=173700 <rdar://problem/32926032> Reviewed by Filip Pizlo and Saam Barati. 1. Added a RELEASE_ASSERT to BytecodeGenerator::generate() to ensure that m_numCalleeLocals is sane. 2. Added underflow checks in LLInt code and VarargsFrame code. 3. Introduce minimumReservedZoneSize, which is hardcoded to 16K. Ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize. Ensure that Options::softReservedZoneSize() is at least greater than Options::reservedZoneSize() by minimumReservedZoneSize. 4. Ensure that stack checks emitted by JIT tiers include an underflow check if and only if the max size of the frame is greater than Options::reservedZoneSize(). By design, we are guaranteed to have at least Options::reservedZoneSize() bytes of memory at the bottom (end) of the stack. This means that, at any time, the frame pointer must be at least Options::reservedZoneSize() bytes away from the end of the stack. Hence, if the max frame size is less than Options::reservedZoneSize(), there's no way that frame pointer - max frame size can underflow, and we can elide the underflow check. Note that we use Options::reservedZoneSize() instead of Options::softReservedZoneSize() for determine if we need an underflow check. This is because the softStackLimit that is used for stack checks can be set based on Options::reservedZoneSize() during error handling (e.g. when creating strings for instantiating the Error object). Hence, the guaranteed minimum of distance between the frame pointer and the end of the stack is Options::reservedZoneSize() and nor Options::softReservedZoneSize(). Note also that we ensure that Options::reservedZoneSize() is at least minimumReservedZoneSize (i.e. 16K). In typical deployments, Options::reservedZoneSize() may be larger. Using Options::reservedZoneSize() instead of minimumReservedZoneSize gives us more chances to elide underflow checks. * JavaScriptCore.xcodeproj/project.pbxproj: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/MinimumReservedZoneSize.h: Added. * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/VM.cpp: (JSC::VM::updateStackLimits): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-06-27 JF Bastien <jfbastien@apple.com> WebAssembly: running out of executable memory should throw OoM https://bugs.webkit.org/show_bug.cgi?id=171537 <rdar://problem/32963338> Reviewed by Saam Barati. Both on first compile with BBQ as well as on tier-up with OMG, running out of X memory shouldn't cause the entire program to terminate. An exception will do when compiling initial code (since we don't have any other fallback at the moment), and refusal to tier up will do as well (it'll just be slower). This is useful because programs which generate huge amounts of code simply look like crashes, which developers report to us. Getting a JavaScript exception instead is much clearer. * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::allocate): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::shouldJIT): * runtime/Options.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::complete): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): * wasm/WasmBinding.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): 2017-06-27 Saam Barati <sbarati@apple.com> JITStubRoutine::passesFilter should use isJITPC https://bugs.webkit.org/show_bug.cgi?id=173906 Reviewed by JF Bastien. This patch makes JITStubRoutine use the isJITPC abstraction defined inside ExecutableAllocator.h. Before, JITStubRoutine was using a hardcoded platform size constant. This means it'd do the wrong thing if Options::jitMemoryReservationSize() was larger than the defined constant for that platform. This patch also removes a bunch of dead code in that file. * jit/ExecutableAllocator.cpp: * jit/ExecutableAllocator.h: * jit/JITStubRoutine.h: (JSC::JITStubRoutine::passesFilter): (JSC::JITStubRoutine::canPerformRangeFilter): Deleted. (JSC::JITStubRoutine::filteringStartAddress): Deleted. (JSC::JITStubRoutine::filteringExtentSize): Deleted. 2017-06-27 Saam Barati <sbarati@apple.com> Fix some stale comments in Wasm code base https://bugs.webkit.org/show_bug.cgi?id=173814 Reviewed by Mark Lam. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::runOMGPlanForIndex): 2017-06-27 Caio Lima <ticaiolima@gmail.com> [ESnext] Implement Object Rest - Implementing Object Rest Destructuring https://bugs.webkit.org/show_bug.cgi?id=167962 Reviewed by Saam Barati. Object Rest/Spread Destructing proposal is in stage 3[1] and this Patch is a prototype implementation of it. A simple change over the parser was necessary to support the new '...' token on Object Pattern destruction rule. In the bytecode generator side, We changed the bytecode generated on ObjectPatternNode::bindValue to store in an set the identifiers of already destructured properties, following spec draft section[2], and then pass it as excludedNames to CopyDataProperties. The rest destructuring calls copyDataProperties to perform the copy of rest properties in rhs. We also implemented CopyDataProperties as private JS global operation on builtins/GlobalOperations.js following it's specification on [3]. It is implemented using Set object to verify if a property is on excludedNames to keep this algorithm with O(n + m) complexity, where n = number of source's own properties and m = excludedNames.length. In this implementation we aren't using excludeList as constant if destructuring pattern contains computed property, i.e. we can just determine the key to be excluded at runtime. If we can define all identifiers in the pattern in compile time, we then create a constant JSSet. This approach gives a good performance improvement, since we allocate the excludeSet just once, reducing GC pressure. [1] - https://github.com/tc39/proposal-object-rest-spread [2] - https://tc39.github.io/proposal-object-rest-spread/#Rest-RuntimeSemantics-PropertyDestructuringAssignmentEvaluation [3] - https://tc39.github.io/proposal-object-rest-spread/#AbstractOperations-CopyDataProperties * builtins/BuiltinNames.h: * builtins/GlobalOperations.js: (globalPrivate.copyDataProperties): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): * bytecompiler/NodesCodegen.cpp: (JSC::ObjectPatternNode::bindValue): * parser/ASTBuilder.h: (JSC::ASTBuilder::appendObjectPatternEntry): (JSC::ASTBuilder::appendObjectPatternRestEntry): (JSC::ASTBuilder::setContainsObjectRestElement): * parser/Nodes.h: (JSC::ObjectPatternNode::appendEntry): (JSC::ObjectPatternNode::setContainsRestElement): * parser/Parser.cpp: (JSC::Parser<LexerType>::parseDestructuringPattern): (JSC::Parser<LexerType>::parseProperty): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::operatorStackPop): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::asyncFunctionStructure): (JSC::JSGlobalObject::setStructure): Deleted. * runtime/JSGlobalObjectFunctions.cpp: (JSC::privateToObject): * runtime/JSGlobalObjectFunctions.h: * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-06-27 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Do not touch VM after notifying Ready in DFG::Worklist https://bugs.webkit.org/show_bug.cgi?id=173888 Reviewed by Saam Barati. After notifying Plan::Ready and releasing Worklist lock, VM can be destroyed. Thus, Plan::vm() can return a destroyed VM. Do not touch it. This causes occasional SEGV / assertion failures in workers/bomb test. * dfg/DFGWorklist.cpp: 2017-06-27 Saam Barati <sbarati@apple.com> Remove an inaccurate comment inside DFGClobberize.h https://bugs.webkit.org/show_bug.cgi?id=163874 Reviewed by Filip Pizlo. The comment said that Clobberize may or may not be sound if run prior to doing type inference. This is not correct, though. Clobberize *must* be sound prior do doing type inference since we use it inside the BytecodeParser, which is the very first thing the DFG does. * dfg/DFGClobberize.h: (JSC::DFG::clobberize): 2017-06-27 Saam Barati <sbarati@apple.com> Function constructor needs to follow the spec and validate parameters and body independently https://bugs.webkit.org/show_bug.cgi?id=173303 <rdar://problem/32732526> Reviewed by Keith Miller. The Function constructor must check the arguments and body strings independently for syntax errors. People rely on this specified behavior to verify that a particular string is a valid function body. We used to check these things strings concatenated together, instead of independently. For example, this used to be valid: `Function("/*", "*/){")`. However, we should throw a syntax error here since "(/*)" is not a valid parameter list, and "*/){" is not a valid body. To implement the specified behavior, we check the syntax independently of both the body and the parameter list. To check that the parameter list has valid syntax, we check that it is valid if in a function with an empty body. To check that the body has valid syntax, we check it is valid in a function with an empty parameter list. * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): 2017-06-27 Ting-Wei Lan <lantw44@gmail.com> Add missing includes to fix compilation error on FreeBSD https://bugs.webkit.org/show_bug.cgi?id=172919 Reviewed by Mark Lam. * API/JSRemoteInspector.h: * API/tests/GlobalContextWithFinalizerTest.cpp: * API/tests/TypedArrayCTest.cpp: 2017-06-27 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Crash generating object preview for ArrayIterator https://bugs.webkit.org/show_bug.cgi?id=173754 <rdar://problem/32859012> Reviewed by Saam Barati. When Inspector generates an object preview for an ArrayIterator instance it made a "clone" of the original ArrayIterator instance by constructing a new object with the instance's structure. However, user code could have modified that instance's structure, such as adding / removing properties. The `return` property had special meaning, and our clone did not fill that slot. This approach is brittle in that we weren't satisfying the expectations of an object with a particular Structure, and the original goal of having Web Inspector peek values of built-in Iterators was to avoid observable behavior. This tightens Web Inspector's Iterator preview to only peek values if the Iterators would actually be non-observable. It also builds an ArrayIterator clone like a regular object construction. * inspector/JSInjectedScriptHost.cpp: (Inspector::cloneArrayIteratorObject): Build up the Object from scratch with a new ArrayIterator prototype. (Inspector::JSInjectedScriptHost::iteratorEntries): Only clone and peek iterators if it would not be observable. Also update iteration to be more in line with IterationOperations, such as when we call iteratorClose. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::init): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::stringIteratorProtocolWatchpoint): * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isStringPrototypeIteratorProtocolFastAndNonObservable): Add a StringIterator WatchPoint in line with the Array/Map/Set iterator watchpoints. * runtime/JSMap.cpp: (JSC::JSMap::isIteratorProtocolFastAndNonObservable): (JSC::JSMap::canCloneFastAndNonObservable): * runtime/JSMap.h: * runtime/JSSet.cpp: (JSC::JSSet::isIteratorProtocolFastAndNonObservable): (JSC::JSSet::canCloneFastAndNonObservable): * runtime/JSSet.h: Promote isIteratorProtocolFastAndNonObservable to a method. * runtime/JSObject.cpp: (JSC::canDoFastPutDirectIndex): * runtime/JSTypeInfo.h: (JSC::TypeInfo::isArgumentsType): Helper to detect if an Object is an Arguments type. 2017-06-26 Saam Barati <sbarati@apple.com> RegExpPrototype.js builtin uses for-of iteration which is almost certainly incorrect https://bugs.webkit.org/show_bug.cgi?id=173740 Reviewed by Mark Lam. The builtin was using for-of iteration to iterate over an internal list in its algorithm. For-of iteration is observable via user code in the global object, so this approach was wrong as it would break if a user changed the Array iteration protocol in some way. * builtins/RegExpPrototype.js: (replace): 2017-06-26 Mark Lam <mark.lam@apple.com> Renamed DumpRegisterFunctor to DumpReturnVirtualPCFunctor. https://bugs.webkit.org/show_bug.cgi?id=173848 Reviewed by JF Bastien. This functor only dumps the return VirtualPC. * interpreter/Interpreter.cpp: (JSC::DumpReturnVirtualPCFunctor::DumpReturnVirtualPCFunctor): (JSC::Interpreter::dumpRegisters): (JSC::DumpRegisterFunctor::DumpRegisterFunctor): Deleted. (JSC::DumpRegisterFunctor::operator()): Deleted. 2017-06-26 Saam Barati <sbarati@apple.com> Crash in JSC::Lexer<unsigned char>::setCode https://bugs.webkit.org/show_bug.cgi?id=172754 Reviewed by Mark Lam. The lexer was asking one of its buffers to reserve initial space that was O(text size in bytes). For large sources, this would end up causing the vector to overflow and crash. This patch changes this code be like the Lexer's other buffers and to only reserve a small starting buffer. * parser/Lexer.cpp: (JSC::Lexer<T>::setCode): 2017-06-26 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Drop Thread::create(obsolete things) API since we can use lambda https://bugs.webkit.org/show_bug.cgi?id=173825 Reviewed by Saam Barati. * jsc.cpp: (startTimeoutThreadIfNeeded): (timeoutThreadMain): Deleted. 2017-06-26 Konstantin Tokarev <annulen@yandex.ru> Unreviewed, add missing header for CLoop * runtime/SymbolTable.cpp: 2017-06-26 Konstantin Tokarev <annulen@yandex.ru> Unreviewed, add missing header icncludes * parser/Lexer.h: 2017-06-25 Konstantin Tokarev <annulen@yandex.ru> Remove excessive headers from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=173812 Reviewed by Darin Adler. * API/APIUtils.h: * assembler/LinkBuffer.cpp: * assembler/MacroAssemblerCodeRef.cpp: * b3/air/AirLiveness.h: * b3/air/AirLowerAfterRegAlloc.cpp: * bindings/ScriptValue.cpp: * bindings/ScriptValue.h: * bytecode/AccessCase.cpp: * bytecode/AccessCase.h: * bytecode/ArrayProfile.h: * bytecode/BytecodeDumper.h: * bytecode/BytecodeIntrinsicRegistry.cpp: * bytecode/BytecodeKills.h: * bytecode/BytecodeLivenessAnalysis.h: * bytecode/BytecodeUseDef.h: * bytecode/CallLinkStatus.h: * bytecode/CodeBlock.h: * bytecode/CodeOrigin.h: * bytecode/ComplexGetStatus.h: * bytecode/GetByIdStatus.h: * bytecode/GetByIdVariant.h: * bytecode/InlineCallFrame.h: * bytecode/InlineCallFrameSet.h: * bytecode/Instruction.h: * bytecode/InternalFunctionAllocationProfile.h: * bytecode/JumpTable.h: * bytecode/MethodOfGettingAValueProfile.h: * bytecode/ObjectPropertyConditionSet.h: * bytecode/Operands.h: * bytecode/PolymorphicAccess.h: * bytecode/PutByIdStatus.h: * bytecode/SpeculatedType.cpp: * bytecode/StructureSet.h: * bytecode/StructureStubInfo.h: * bytecode/UnlinkedCodeBlock.h: * bytecode/UnlinkedFunctionExecutable.h: * bytecode/ValueProfile.h: * bytecompiler/BytecodeGenerator.cpp: * bytecompiler/BytecodeGenerator.h: * bytecompiler/Label.h: * bytecompiler/StaticPropertyAnalysis.h: * debugger/DebuggerCallFrame.cpp: * dfg/DFGAbstractInterpreter.h: * dfg/DFGAdjacencyList.h: * dfg/DFGArgumentsUtilities.h: * dfg/DFGArrayMode.h: * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGBackwardsPropagationPhase.h: * dfg/DFGBasicBlock.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * dfg/DFGCapabilities.h: * dfg/DFGCommon.h: * dfg/DFGCommonData.h: * dfg/DFGDesiredIdentifiers.h: * dfg/DFGDesiredWatchpoints.h: * dfg/DFGDisassembler.cpp: * dfg/DFGDominators.h: * dfg/DFGDriver.cpp: * dfg/DFGDriver.h: * dfg/DFGEdgeDominates.h: * dfg/DFGFinalizer.h: * dfg/DFGGenerationInfo.h: * dfg/DFGJITCompiler.cpp: * dfg/DFGJITCompiler.h: * dfg/DFGJITFinalizer.h: * dfg/DFGLivenessAnalysisPhase.h: * dfg/DFGMinifiedNode.h: * dfg/DFGMultiGetByOffsetData.h: * dfg/DFGNaturalLoops.cpp: * dfg/DFGNaturalLoops.h: * dfg/DFGNode.h: * dfg/DFGOSRAvailabilityAnalysisPhase.h: * dfg/DFGOSRExit.h: * dfg/DFGOSRExitCompilationInfo.h: * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitJumpPlaceholder.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPlan.h: * dfg/DFGPreciseLocalClobberize.h: * dfg/DFGPromotedHeapLocation.h: * dfg/DFGRegisteredStructure.h: * dfg/DFGRegisteredStructureSet.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: * dfg/DFGSnippetParams.h: * dfg/DFGSpeculativeJIT.h: * dfg/DFGToFTLDeferredCompilationCallback.h: * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: * dfg/DFGValidate.h: * dfg/DFGValueSource.h: * dfg/DFGVariableEvent.h: * dfg/DFGVariableEventStream.h: * dfg/DFGWorklist.h: * domjit/DOMJITCallDOMGetterSnippet.h: * domjit/DOMJITEffect.h: * ftl/FTLLink.cpp: * ftl/FTLLowerDFGToB3.cpp: * ftl/FTLPatchpointExceptionHandle.h: * heap/AllocatorAttributes.h: * heap/CodeBlockSet.h: * heap/DeferGC.h: * heap/GCSegmentedArray.h: * heap/Heap.cpp: * heap/Heap.h: * heap/IncrementalSweeper.h: * heap/ListableHandler.h: * heap/MachineStackMarker.h: * heap/MarkedAllocator.h: * heap/MarkedBlock.cpp: * heap/MarkedBlock.h: * heap/MarkingConstraint.h: * heap/SlotVisitor.cpp: * heap/SlotVisitor.h: * inspector/ConsoleMessage.cpp: * inspector/ConsoleMessage.h: * inspector/InjectedScript.h: * inspector/InjectedScriptHost.h: * inspector/InjectedScriptManager.cpp: * inspector/JSGlobalObjectInspectorController.cpp: * inspector/JavaScriptCallFrame.h: * inspector/ScriptCallStack.h: * inspector/ScriptCallStackFactory.cpp: * inspector/ScriptDebugServer.h: * inspector/agents/InspectorConsoleAgent.h: * inspector/agents/InspectorDebuggerAgent.cpp: * inspector/agents/InspectorDebuggerAgent.h: * inspector/agents/InspectorHeapAgent.cpp: * inspector/agents/InspectorHeapAgent.h: * inspector/agents/InspectorRuntimeAgent.h: * inspector/agents/InspectorScriptProfilerAgent.cpp: * inspector/agents/InspectorScriptProfilerAgent.h: * inspector/agents/JSGlobalObjectConsoleAgent.h: * inspector/agents/JSGlobalObjectDebuggerAgent.cpp: * inspector/agents/JSGlobalObjectDebuggerAgent.h: * inspector/agents/JSGlobalObjectRuntimeAgent.h: * inspector/augmentable/AlternateDispatchableAgent.h: * interpreter/CLoopStack.h: * interpreter/CachedCall.h: * interpreter/CallFrame.h: * interpreter/Interpreter.cpp: * interpreter/Interpreter.h: * jit/AssemblyHelpers.cpp: * jit/AssemblyHelpers.h: * jit/CCallHelpers.h: * jit/CallFrameShuffler.h: * jit/ExecutableAllocator.h: * jit/GCAwareJITStubRoutine.h: * jit/HostCallReturnValue.h: * jit/ICStats.h: * jit/JIT.cpp: * jit/JIT.h: * jit/JITAddGenerator.h: * jit/JITCall32_64.cpp: * jit/JITCode.h: * jit/JITDisassembler.cpp: * jit/JITExceptions.cpp: * jit/JITMathIC.h: * jit/JITOpcodes.cpp: * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITThunks.cpp: * jit/JITThunks.h: * jit/JSInterfaceJIT.h: * jit/PCToCodeOriginMap.h: * jit/PolymorphicCallStubRoutine.h: * jit/RegisterSet.h: * jit/Repatch.h: * jit/SetupVarargsFrame.h: * jit/Snippet.h: * jit/SnippetParams.h: * jit/ThunkGenerators.h: * jsc.cpp: * llint/LLIntCLoop.h: * llint/LLIntEntrypoint.h: * llint/LLIntExceptions.h: * llint/LLIntOfflineAsmConfig.h: * llint/LLIntSlowPaths.cpp: * parser/NodeConstructors.h: * parser/Nodes.cpp: * parser/Nodes.h: * parser/Parser.cpp: * parser/Parser.h: * parser/ParserTokens.h: * parser/SourceProviderCacheItem.h: * profiler/ProfilerBytecodeSequence.h: * profiler/ProfilerDatabase.cpp: * profiler/ProfilerDatabase.h: * profiler/ProfilerOrigin.h: * profiler/ProfilerOriginStack.h: * profiler/ProfilerProfiledBytecodes.h: * profiler/ProfilerUID.h: * runtime/AbstractModuleRecord.h: * runtime/ArrayConstructor.h: * runtime/ArrayConventions.h: * runtime/ArrayIteratorPrototype.h: * runtime/ArrayPrototype.h: * runtime/BasicBlockLocation.h: * runtime/Butterfly.h: * runtime/CallData.cpp: * runtime/CodeCache.h: * runtime/CommonSlowPaths.cpp: * runtime/CommonSlowPaths.h: * runtime/CommonSlowPathsExceptions.cpp: * runtime/Completion.cpp: * runtime/ControlFlowProfiler.h: * runtime/DateInstanceCache.h: * runtime/ErrorConstructor.h: * runtime/ErrorInstance.h: * runtime/ExceptionHelpers.cpp: * runtime/ExceptionHelpers.h: * runtime/ExecutableBase.h: * runtime/FunctionExecutable.h: * runtime/HasOwnPropertyCache.h: * runtime/Identifier.h: * runtime/InternalFunction.h: * runtime/IntlCollator.cpp: * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormatPrototype.h: * runtime/IteratorOperations.cpp: * runtime/JSArray.h: * runtime/JSArrayBufferPrototype.h: * runtime/JSCJSValue.h: * runtime/JSCJSValueInlines.h: * runtime/JSCell.h: * runtime/JSFunction.cpp: * runtime/JSFunction.h: * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: * runtime/JSGlobalObject.cpp: * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectDebuggable.cpp: * runtime/JSGlobalObjectDebuggable.h: * runtime/JSGlobalObjectFunctions.cpp: * runtime/JSGlobalObjectFunctions.h: * runtime/JSJob.cpp: * runtime/JSLock.h: * runtime/JSModuleLoader.cpp: * runtime/JSModuleNamespaceObject.h: * runtime/JSModuleRecord.h: * runtime/JSObject.cpp: * runtime/JSObject.h: * runtime/JSRunLoopTimer.h: * runtime/JSTemplateRegistryKey.h: * runtime/JSTypedArrayPrototypes.cpp: * runtime/JSTypedArrayPrototypes.h: * runtime/JSTypedArrays.h: * runtime/LiteralParser.h: * runtime/MatchResult.h: * runtime/MemoryStatistics.h: * runtime/PrivateName.h: * runtime/PromiseDeferredTimer.h: * runtime/ProxyObject.h: * runtime/RegExp.h: * runtime/SamplingProfiler.cpp: * runtime/SmallStrings.h: * runtime/StringPrototype.cpp: * runtime/StringRecursionChecker.h: * runtime/Structure.h: * runtime/SymbolConstructor.h: * runtime/SymbolPrototype.cpp: * runtime/SymbolPrototype.h: * runtime/TypeProfiler.h: * runtime/TypeProfilerLog.h: * runtime/TypedArrayType.h: * runtime/VM.cpp: * runtime/VM.h: * runtime/VMEntryScope.h: * runtime/WeakMapData.h: * runtime/WriteBarrier.h: * tools/FunctionOverrides.cpp: * tools/FunctionOverrides.h: * wasm/WasmBinding.cpp: * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/WebAssemblyPrototype.cpp: * yarr/Yarr.h: * yarr/YarrJIT.cpp: * yarr/YarrJIT.h: * yarr/YarrParser.h: 2017-06-24 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Clean up Object.entries implementation https://bugs.webkit.org/show_bug.cgi?id=173759 Reviewed by Sam Weinig. This patch cleans up Object.entries implementation. We drop unused private functions. And we merge the implementation into Object.entries. It slightly speeds up Object.entries speed. baseline patched object-entries 148.0101+-5.6627 142.1877+-4.8661 might be 1.0409x faster * builtins/BuiltinNames.h: * builtins/ObjectConstructor.js: (entries): (globalPrivate.enumerableOwnProperties): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/ObjectConstructor.cpp: (JSC::ownEnumerablePropertyKeys): Deleted. * runtime/ObjectConstructor.h: 2017-06-24 Joseph Pecoraro <pecoraro@apple.com> Remove Reflect.enumerate https://bugs.webkit.org/show_bug.cgi?id=173806 Reviewed by Yusuke Suzuki. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): (Inspector::JSInjectedScriptHost::getInternalProperties): (Inspector::JSInjectedScriptHost::iteratorEntries): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSPropertyNameIterator.cpp: Removed. * runtime/JSPropertyNameIterator.h: Removed. * runtime/ReflectObject.cpp: (JSC::reflectObjectEnumerate): Deleted. 2017-06-23 Keith Miller <keith_miller@apple.com> Switch VMTraps to use halt instructions rather than breakpoint instructions https://bugs.webkit.org/show_bug.cgi?id=173677 <rdar://problem/32178892> Reviewed by JF Bastien. Using the breakpoint instruction for VMTraps caused issues with lldb. Since we only need some way to stop execution we can, in theory, use any exceptioning instruction we want. I went with the halt instruction on X86 since that is the only one byte instruction that does not breakpoint (in my tests both 0xf1 and 0xd6 produced EXC_BREAKPOINT). On ARM we use the data cache clearing instruction with the zero register, which triggers a segmentation fault. Also, update the platform code to only use signaling VMTraps on where we have an appropriate instruction (x86 and ARM64). * API/tests/ExecutionTimeLimitTest.cpp: (testExecutionTimeLimit): * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::replaceWithVMHalt): (JSC::ARM64Assembler::dataCacheZeroVirtualAddress): (JSC::ARM64Assembler::replaceWithBkpt): Deleted. * assembler/ARMAssembler.h: (JSC::ARMAssembler::replaceWithBkpt): Deleted. * assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::replaceWithBkpt): Deleted. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::replaceWithBkpt): Deleted. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::replaceWithVMHalt): (JSC::MacroAssemblerARM64::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::storeFence): (JSC::MacroAssemblerARMv7::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::replaceWithBreakpoint): Deleted. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::replaceWithVMHalt): (JSC::MacroAssemblerX86Common::replaceWithBreakpoint): Deleted. * assembler/X86Assembler.h: (JSC::X86Assembler::replaceWithHlt): (JSC::X86Assembler::replaceWithInt3): Deleted. * dfg/DFGJumpReplacement.cpp: (JSC::DFG::JumpReplacement::installVMTrapBreakpoint): * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::installSignalHandler): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): Deleted. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::enableFastMemory): 2017-06-22 Saam Barati <sbarati@apple.com> The lowering of Identity in the DFG backend needs to use ManualOperandSpeculation https://bugs.webkit.org/show_bug.cgi?id=173743 <rdar://problem/32932536> Reviewed by Mark Lam. The code always manually speculates, however, we weren't specifying ManualOperandSpeculation when creating a JSValueOperand. This would fire an assertion in JSValueOperand construction for a node like: Identity(String:@otherNode) I spent about 45 minutes trying to craft a test and came up empty. However, this fixes a debug assertion on an internal Apple website. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): 2017-06-22 Saam Barati <sbarati@apple.com> ValueRep(DoubleRep(@v)) can not simply convert to @v https://bugs.webkit.org/show_bug.cgi?id=173687 <rdar://problem/32855563> Reviewed by Mark Lam. Consider this IR: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here v: ValueRep(DoubleRepUse:@d) a: NewArrayWithSize(Int32:@v) some more nodes here ... Because the flow of ValueRep(DoubleRep(@p)) will not produce an Int32, AI proves that the Int32 check will fail. Constant folding phase removes all nodes after @a and inserts an Unreachable after the NewArrayWithSize node. The IR then looks like this: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here v: ValueRep(DoubleRepUse:@d) a: NewArrayWithSize(Int32:@v) Unreachable However, there was a strength reduction rule that tries eliminate redundant conversions. It used to convert the program to: block#x p: Phi() // int32 and double flows into this phi from various control flow d: DoubleRep(@p) some uses of @d here a: NewArrayWithSize(Int32:@p) Unreachable However, at runtime, @p will actually be an Int32, so @a will not OSR exit, and we'll crash. This patch removes this strength reduction rule since it does not maintain what would have happened if we executed the program before the rule. This rule is also wrong for other types of programs (I'm not sure we'd actually emit this code, but if such IR were generated, we would previously optimize it incorrectly): @a: Constant(JSTrue) @b: DoubleRep(@a) @c: ValueRep(@b) @d: use(@c) However, the strength reduction rule would've transformed this into: @a: Constant(JSTrue) @d: use(@a) And this would be wrong because node @c before the transformation would have produced the JSValue jsNumber(1.0). This patch was neutral in the benchmark run I did. * dfg/DFGStrengthReductionPhase.cpp: (JSC::DFG::StrengthReductionPhase::handleNode): 2017-06-22 JF Bastien <jfbastien@apple.com> ARM64: doubled executable memory limit from 32MiB to 64MiB https://bugs.webkit.org/show_bug.cgi?id=173734 <rdar://problem/32932407> Reviewed by Oliver Hunt. Some WebAssembly programs stress the amount of memory we have available, especially when we consider tiering (BBQ never dies, and is bigger that OMG). Tiering to OMG just piles on more memory, and we're also competing with JavaScript. * jit/ExecutableAllocator.h: 2017-06-22 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Pausing with a deep call stack can be very slow, avoid eagerly generating object previews https://bugs.webkit.org/show_bug.cgi?id=173698 Reviewed by Matt Baker. When pausing in a deep call stack the majority of the time spent in JavaScriptCore when preparing Inspector pause information is spent generating object previews for the `thisObject` of each of the call frames. In some cases, this could be more than 95% of the time generating pause information. In the common case, only one of these (the top frame) will ever be seen by users. This change avoids eagerly generating object previews up front and let the frontend request previews if they are needed. This introduces the `Runtime.getPreview` protocol command. This can be used to: - Get a preview for a RemoteObject that did not have a preview but could. - Update a preview for a RemoteObject that had a preview. This patch only uses it for the first case, but the second is valid and may be something we want to do in the future. * inspector/protocol/Runtime.json: A new command to get an up to date preview for an object. * inspector/InjectedScript.h: * inspector/InjectedScript.cpp: (Inspector::InjectedScript::getPreview): * inspector/agents/InspectorRuntimeAgent.cpp: (Inspector::InspectorRuntimeAgent::getPreview): * inspector/agents/InspectorRuntimeAgent.h: Plumbing for the new command. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.getPreview): Implementation just uses the existing helper. (InjectedScript.CallFrameProxy): Do not generate a preview for the this object as it may not be shown. Let the frontend request a preview if it wants or needs one. 2017-06-22 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Remove stale "rawScopes" concept that was never available in JSC https://bugs.webkit.org/show_bug.cgi?id=173686 Reviewed by Mark Lam. * inspector/InjectedScript.cpp: (Inspector::InjectedScript::functionDetails): * inspector/InjectedScriptSource.js: (InjectedScript.prototype.functionDetails): * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::functionDetails): 2017-06-22 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Object.values should be implemented in C++ https://bugs.webkit.org/show_bug.cgi?id=173703 Reviewed by Sam Weinig. As the same to Object.assign, Object.values() is also inherently polymorphic. And allocating JSString / Symbol for Identifier and JSArray for Object.keys() result is costly. In this patch, we implement Object.values() in C++. It can avoid above allocations. Furthermore, by using `slot.isTaintedByOpaqueObject()` information, we can skip non-observable JSObject::get() calls. This improves performance by 2.49x. And also now Object.values() beats Object.keys(object).map(key => object[key]) implementation. baseline patched object-values 132.1551+-3.7209 ^ 53.1254+-1.6139 ^ definitely 2.4876x faster object-keys-map-values 78.2008+-2.1378 ? 78.9078+-2.2121 ? * builtins/ObjectConstructor.js: (values): Deleted. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorValues): 2017-06-21 Saam Barati <sbarati@apple.com> ArrayPrototype.map builtin declares a var it does not use https://bugs.webkit.org/show_bug.cgi?id=173685 Reviewed by Keith Miller. * builtins/ArrayPrototype.js: (map): 2017-06-21 Saam Barati <sbarati@apple.com> eval virtual call is incorrect in the baseline JIT https://bugs.webkit.org/show_bug.cgi?id=173587 <rdar://problem/32867897> Reviewed by Michael Saboff. When making a virtual call for call_eval, e.g, when the thing we're calling isn't actually eval, we end up calling the caller instead of the callee. This is clearly wrong. The code ends up issuing a load for the Callee in the callers frame instead of the callee we're calling. The fix is simple, we just need to load the real callee. Only the 32-bit baseline JIT had this bug. * jit/JITCall32_64.cpp: (JSC::JIT::compileCallEvalSlowCase): 2017-06-21 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Using "break on all exceptions" when throwing stack overflow hangs inspector https://bugs.webkit.org/show_bug.cgi?id=172432 <rdar://problem/29870873> Reviewed by Saam Barati. Avoid pausing on StackOverflow and OutOfMemory errors to avoid a hang. We will proceed to improve debugging of these cases in the follow-up bugs. * debugger/Debugger.cpp: (JSC::Debugger::exception): Ignore pausing on these errors. * runtime/ErrorInstance.h: (JSC::ErrorInstance::setStackOverflowError): (JSC::ErrorInstance::isStackOverflowError): (JSC::ErrorInstance::setOutOfMemoryError): (JSC::ErrorInstance::isOutOfMemoryError): * runtime/ExceptionHelpers.cpp: (JSC::createStackOverflowError): * runtime/Error.cpp: (JSC::createOutOfMemoryError): Mark these kinds of errors. 2017-06-21 Saam Barati <sbarati@apple.com> Make it clear that regenerating ICs are holding the CodeBlock's lock by passing the locker as a parameter https://bugs.webkit.org/show_bug.cgi?id=173609 Reviewed by Keith Miller. This patch makes many of the IC generating functions require a locker as a parameter. We do this in other places in JSC to indicate that a particular API is only valid while a particular lock is held. This is the case when generating ICs. This patch just makes it explicit in the IC generating interface. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::addCases): (JSC::PolymorphicAccess::addCase): (JSC::PolymorphicAccess::commit): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: * bytecode/StructureStubInfo.cpp: (JSC::StructureStubInfo::addAccessCase): (JSC::StructureStubInfo::initStub): Deleted. * bytecode/StructureStubInfo.h: * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::repatchGetByID): (JSC::tryCachePutByID): (JSC::repatchPutByID): (JSC::tryRepatchIn): (JSC::repatchIn): 2017-06-20 Myles C. Maxfield <mmaxfield@apple.com> Disable font variations on macOS Sierra and iOS 10 https://bugs.webkit.org/show_bug.cgi?id=173618 <rdar://problem/32879164> Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: 2017-06-20 Keith Miller <keith_miller@apple.com> Fix leak of ModuleInformations in BBQPlan constructors. https://bugs.webkit.org/show_bug.cgi?id=173577 Reviewed by Saam Barati. This patch fixes a leak in the BBQPlan constructiors. Previously, the plans were calling makeRef on the newly constructed objects. This patch fixes the issue and uses adoptRef instead. Additionally, an old, incorrect, attempt to fix the leak is removed. * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection): * jit/JITWorklist.cpp: (JSC::JITWorklist::Thread::Thread): * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::addPendingPromise): * runtime/VM.cpp: (JSC::VM::VM): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): 2017-06-20 Devin Rousso <drousso@apple.com> Web Inspector: Send context attributes for tracked canvases https://bugs.webkit.org/show_bug.cgi?id=173327 Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: Add ContextAttributes object type that is optionally used for WebGL canvases. 2017-06-20 Konstantin Tokarev <annulen@yandex.ru> Remove excessive include directives from WTF https://bugs.webkit.org/show_bug.cgi?id=173553 Reviewed by Saam Barati. * profiler/ProfilerDatabase.cpp: Added missing include directive. * runtime/SamplingProfiler.cpp: Ditto. 2017-06-20 Oleksandr Skachkov <gskachkov@gmail.com> Revert changes in bug#160417 about extending `null` not being a derived class https://bugs.webkit.org/show_bug.cgi?id=169293 Reviewed by Saam Barati. Reverted changes in bug#160417 about extending `null` not being a derived class according to changes in spec: https://github.com/tc39/ecma262/commit/c57ef95c45a371f9c9485bb1c3881dbdc04524a2 * builtins/BuiltinNames.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitReturn): * bytecompiler/NodesCodegen.cpp: (JSC::ClassExprNode::emitBytecode): 2017-06-20 Saam Barati <sbarati@apple.com> repatchIn needs to lock the CodeBlock's lock https://bugs.webkit.org/show_bug.cgi?id=173573 Reviewed by Yusuke Suzuki. CodeBlock::propagateTransitions and CodeBlock::visitWeakly grab the CodeBlock's lock before modifying the StructureStubInfo/PolymorphicAccess. When regenerating an IC, we must hold the CodeBlock's to prevent the executing thread from racing with the marking thread. repatchIn was not grabbing the lock. I haven't been able to get it to crash, but this is needed for the same reasons that get and put IC regeneration grab the lock. * jit/Repatch.cpp: (JSC::repatchIn): 2017-06-19 Devin Rousso <drousso@apple.com> Web Inspector: create canvas content view and details sidebar panel https://bugs.webkit.org/show_bug.cgi?id=138941 <rdar://problem/19051672> Reviewed by Joseph Pecoraro. * inspector/protocol/Canvas.json: - Add an optional `nodeId` attribute to the `Canvas` type. - Add `requestNode` command for getting the node id of the backing canvas element. - Add `requestContent` command for getting the current image content of the canvas. 2017-06-19 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for ARM * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::internalCompare32): 2017-06-13 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] More ArrayIndexOf fixups for various types https://bugs.webkit.org/show_bug.cgi?id=173176 Reviewed by Saam Barati. This patch further expands coverage of ArrayIndexOf optimization in DFG and FTL. 1. We attempt to fold ArrayIndexOf to constant (-1) if we know that its array never contains the given search value. 2. We support Symbol and Other specialization additionally. Especially, Other is useful because null/undefined can be used as a sentinel value. One interesting thing is that Array.prototype.indexOf does not consider holes as undefineds. Thus, var array = [,,,,,,,]; array.indexOf(undefined); // => -1 This can be trivially achieved in JSC because Empty and Undefined are different values. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupArrayIndexOf): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): (JSC::DFG::SpeculativeJIT::speculateOther): * dfg/DFGSpeculativeJIT.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf): 2017-06-19 Caio Lima <ticaiolima@gmail.com> [ARMv6][DFG] ARM MacroAssembler is always emitting cmn when immediate is 0 https://bugs.webkit.org/show_bug.cgi?id=172972 Reviewed by Mark Lam. We are changing internalCompare32 implementation in ARM MacroAssembler to emit "cmp" when the "right.value" is 0. It is generating wrong comparison cases, since the semantics of cmn is opposite of cmp[1]. One case that it's breaking is "branch32(MacroAssembler::Above, gpr, TrustedImm32(0))", where ends resulting in following assembly code: ``` cmn $r0, #0 bhi <address> ``` However, as cmn is similar to "adds", it will never take the branch when $r0 > 0. In that case, the correct opcode is "cmp". With this patch we will fix current broken tests that uses "branch32(MacroAssembler::Above, gpr, TrustedImm32(0))", such as ForwardVarargs, Spread and GetRestLength. [1] - http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihiddid.html * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::internalCompare32): 2017-06-19 Joseph Pecoraro <pecoraro@apple.com> test262: Completion values for control flow do not match the spec https://bugs.webkit.org/show_bug.cgi?id=171265 Reviewed by Saam Barati. * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::shouldBeConcernedWithCompletionValue): When we care about having proper completion values (global code in programs, modules, and eval) insert undefined results for control flow statements. * bytecompiler/NodesCodegen.cpp: (JSC::SourceElements::emitBytecode): Reduce writing a default `undefined` value to the completion result to only once before the last statement we know will produce a value. (JSC::IfElseNode::emitBytecode): (JSC::WithNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ForOfNode::emitBytecode): (JSC::SwitchNode::emitBytecode): Insert an undefined to handle cases where code may break out of an if/else or with statement (break/continue). (JSC::TryNode::emitBytecode): Same handling for break cases. Also, finally block statement completion values are always ignored for the try statement result. (JSC::ClassDeclNode::emitBytecode): Class declarations, like function declarations, produce an empty result. * parser/Nodes.cpp: (JSC::SourceElements::lastStatement): (JSC::SourceElements::hasCompletionValue): (JSC::SourceElements::hasEarlyBreakOrContinue): (JSC::BlockNode::lastStatement): (JSC::BlockNode::singleStatement): (JSC::BlockNode::hasCompletionValue): (JSC::BlockNode::hasEarlyBreakOrContinue): (JSC::ScopeNode::singleStatement): (JSC::ScopeNode::hasCompletionValue): (JSC::ScopeNode::hasEarlyBreakOrContinue): The only non-trivial cases need to loop through their list of statements to determine if this has a completion value or not. Likewise for determining if there is an early break / continue, meaning a break or continue statement with no preceding statement that has a completion value. * parser/Nodes.h: (JSC::StatementNode::next): (JSC::StatementNode::hasCompletionValue): Helper to check if a statement nodes produces a completion value or not. 2017-06-19 Adrian Perez de Castro <aperez@igalia.com> Missing <functional> includes make builds fail with GCC 7.x https://bugs.webkit.org/show_bug.cgi?id=173544 Unreviewed gardening. Fix compilation with GCC 7. * API/tests/CompareAndSwapTest.cpp: * runtime/VMEntryScope.h: 2017-06-17 Keith Miller <keith_miller@apple.com> ArrayBuffer constructor needs to create subclass structures before its buffer https://bugs.webkit.org/show_bug.cgi?id=173510 Reviewed by Yusuke Suzuki. * runtime/JSArrayBufferConstructor.cpp: (JSC::constructArrayBuffer): 2017-06-17 Keith Miller <keith_miller@apple.com> ArrayPrototype methods should use JSValue::toLength for non-Arrays. https://bugs.webkit.org/show_bug.cgi?id=173506 Reviewed by Ryosuke Niwa. This patch changes the result of unshift if old length + unshift.arguments.length > (2 ** 53) - 1 to be a type error. Also, the getLength function, which was always incorrect to use, has been removed. Additionally, some cases where we were using a constant for (2 ** 53) - 1 have been replaced with maxSafeInteger() * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncToLocaleString): (JSC::arrayProtoFuncPop): (JSC::arrayProtoFuncPush): (JSC::arrayProtoFuncReverse): (JSC::arrayProtoFuncShift): (JSC::arrayProtoFuncSlice): (JSC::arrayProtoFuncSplice): (JSC::arrayProtoFuncUnShift): (JSC::arrayProtoFuncIndexOf): (JSC::arrayProtoFuncLastIndexOf): * runtime/JSArrayInlines.h: (JSC::getLength): Deleted. * runtime/JSCJSValue.cpp: (JSC::JSValue::toLength): * runtime/NumberConstructor.cpp: (JSC::numberConstructorFuncIsSafeInteger): 2017-06-16 Matt Baker <mattbaker@apple.com> Web Inspector: Instrument 2D/WebGL canvas contexts in the backend https://bugs.webkit.org/show_bug.cgi?id=172623 <rdar://problem/32415986> Reviewed by Devin Rousso and Joseph Pecoraro. This patch adds a basic Canvas protocol. It includes Canvas and related types and events for monitoring the lifetime of canvases in the page. * CMakeLists.txt: * DerivedSources.make: * inspector/protocol/Canvas.json: Added. * inspector/scripts/codegen/generator.py: (Generator.stylized_name_for_enum_value): Add special handling for Canvas.ContextType protocol enumeration, so that "canvas-2d" and "webgl" map to `Canvas2D` and `WebGL`. 2017-06-16 Wenson Hsieh <wenson_hsieh@apple.com> [iOS DnD] Upstream iOS drag and drop implementation into OpenSource WebKit https://bugs.webkit.org/show_bug.cgi?id=173366 <rdar://problem/32767014> Reviewed by Tim Horton. Introduce ENABLE_DATA_INTERACTION and ENABLE_DRAG_SUPPORT to FeatureDefines.xcconfig. * Configurations/FeatureDefines.xcconfig: 2017-06-16 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Add fast path for Object.assign https://bugs.webkit.org/show_bug.cgi?id=173416 Reviewed by Mark Lam. In Object.assign implementation, we need to ensure that given key is still enumerable own key. This seems duplicate look up. And we want to avoid this. However, we still need to perform this check in the face of Proxy. Proxy can observe that this check is done correctly. In almost all the cases, the above check is duplicate to the subsequent [[Get]] operation. In this patch, we perform this check. But at that time, we investigate `isTaintedByOpaqueObject()`. If it is false, we can say that getOwnPropertySlot is pure. In that case, we can just retrieve the value by calling `slot.getValue()`. This further improves performance of Object.assign. baseline patched object-assign.es6 363.6706+-6.4381 ^ 324.1769+-6.9624 ^ definitely 1.1218x faster * runtime/ObjectConstructor.cpp: (JSC::objectConstructorAssign): 2017-06-16 Michael Saboff <msaboff@apple.com> Intermittent crash running Internal/Tests/InternalJSTests/Regress/radar-24300617.js https://bugs.webkit.org/show_bug.cgi?id=173488 Reviewed by Filip Pizlo. ClonedArguments lazily sets its callee and interator properties and it used its own inline code to initialize its butterfly. This means that these lazily set properties can have bogus values in those slots. Instead, let's use the standard BUtterfly:tryCreate() method to create the butterfly as it clears out of line properties. * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createEmpty): 2017-06-16 Mark Lam <mark.lam@apple.com> Interpreter methods for mapping between Opcode and OpcodeID need not be instance methods. https://bugs.webkit.org/show_bug.cgi?id=173491 Reviewed by Keith Miller. The implementation are based on static data. There's no need to get the interpreter instance. Hence, we can make these methods static and avoid doing unnecessary work to compute the interpreter this pointer. Also removed the unused isCallBytecode method. * bytecode/BytecodeBasicBlock.cpp: (JSC::BytecodeBasicBlock::computeImpl): * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::printGetByIdOp): (JSC::BytecodeDumper<Block>::printGetByIdCacheStatus): (JSC::BytecodeDumper<Block>::dumpBytecode): (JSC::BytecodeDumper<Block>::dumpBlock): * bytecode/BytecodeLivenessAnalysis.cpp: (JSC::BytecodeLivenessAnalysis::dumpResults): * bytecode/BytecodeLivenessAnalysisInlines.h: (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction): * bytecode/BytecodeRewriter.cpp: (JSC::BytecodeRewriter::adjustJumpTargetsInFragment): * bytecode/CallLinkStatus.cpp: (JSC::CallLinkStatus::computeFromLLInt): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::propagateTransitions): (JSC::CodeBlock::finalizeLLIntInlineCaches): (JSC::CodeBlock::hasOpDebugForLineAndColumn): (JSC::CodeBlock::usesOpcode): (JSC::CodeBlock::valueProfileForBytecodeOffset): (JSC::CodeBlock::arithProfileForPC): (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler): * bytecode/PreciseJumpTargets.cpp: (JSC::getJumpTargetsForBytecodeOffset): (JSC::computePreciseJumpTargetsInternal): (JSC::findJumpTargetsForBytecodeOffset): * bytecode/PreciseJumpTargetsInlines.h: (JSC::extractStoredJumpTargetsForBytecodeOffset): * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::applyModification): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): (JSC::Interpreter::isOpcode): (): Deleted. * interpreter/Interpreter.h: (JSC::Interpreter::getOpcode): Deleted. (JSC::Interpreter::getOpcodeID): Deleted. (JSC::Interpreter::isCallBytecode): Deleted. * interpreter/InterpreterInlines.h: (JSC::Interpreter::getOpcode): (JSC::Interpreter::getOpcodeID): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JITOpcodes.cpp: (JSC::JIT::emitNewFuncCommon): (JSC::JIT::emitNewFuncExprCommon): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitSlow_op_put_by_val): (JSC::JIT::privateCompilePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitSlow_op_put_by_val): * llint/LLIntSlowPaths.cpp: (JSC::LLInt::llint_trace_operand): (JSC::LLInt::llint_trace_value): (JSC::LLInt::LLINT_SLOW_PATH_DECL): * profiler/ProfilerBytecodeSequence.cpp: (JSC::Profiler::BytecodeSequence::BytecodeSequence): 2017-06-16 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r218376. The patch cause multiple Layout Test Crashes. Reverted changeset: "Web Inspector: Instrument 2D/WebGL canvas contexts in the backend" https://bugs.webkit.org/show_bug.cgi?id=172623 http://trac.webkit.org/changeset/218376 2017-06-16 Konstantin Tokarev <annulen@yandex.ru> REGRESSION(r166799): LogsPageMessagesToSystemConsoleEnabled corrupts non-ASCII characters https://bugs.webkit.org/show_bug.cgi?id=173470 Reviewed by Joseph Pecoraro. ConsoleClient::printConsoleMessageWithArguments() incorrectly uses const char* overload of StringBuilder::append() that assummes Latin1 encoding, not UTF8. * runtime/ConsoleClient.cpp: (JSC::ConsoleClient::printConsoleMessageWithArguments): 2017-06-15 Mark Lam <mark.lam@apple.com> Add a JSRunLoopTimer registry in VM. https://bugs.webkit.org/show_bug.cgi?id=173429 <rdar://problem/31287961> Reviewed by Filip Pizlo. This way, we can be sure we've got every JSRunLoopTimer instance covered if we need to change their run loop (e.g. when setting to the WebThread's run loop). * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::setRunLoop): Deleted. * heap/Heap.h: (JSC::Heap::runLoop): Deleted. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::setRunLoop): (JSC::JSRunLoopTimer::~JSRunLoopTimer): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::registerRunLoopTimer): (JSC::VM::unregisterRunLoopTimer): (JSC::VM::setRunLoop): * runtime/VM.h: (JSC::VM::runLoop): 2017-06-15 Joseph Pecoraro <pecoraro@apple.com> [Cocoa] Modernize some internal initializers to use instancetype instead of id https://bugs.webkit.org/show_bug.cgi?id=173112 Reviewed by Wenson Hsieh. * API/JSContextInternal.h: * API/JSWrapperMap.h: * API/JSWrapperMap.mm: (-[JSObjCClassInfo initForClass:]): (-[JSWrapperMap initWithGlobalContextRef:]): 2017-06-15 Matt Baker <mattbaker@apple.com> Web Inspector: Instrument 2D/WebGL canvas contexts in the backend https://bugs.webkit.org/show_bug.cgi?id=172623 <rdar://problem/32415986> Reviewed by Devin Rousso. This patch adds a basic Canvas protocol. It includes Canvas and related types and events for monitoring the lifetime of canvases in the page. * CMakeLists.txt: * DerivedSources.make: * inspector/protocol/Canvas.json: Added. * inspector/scripts/codegen/generator.py: (Generator.stylized_name_for_enum_value): Add special handling for Canvas.ContextType protocol enumeration, so that "canvas-2d" and "webgl" map to `Canvas2D` and `WebGL`. 2017-06-15 Keith Miller <keith_miller@apple.com> Add logging to MachineStackMarker to try to diagnose crashes in the wild https://bugs.webkit.org/show_bug.cgi?id=173427 Reviewed by Mark Lam. This patch adds some logging to the MachineStackMarker constructor to help figure out where we are seeing crashes. Since macOS does not support os_log_info my hope is that if we set all the callee save registers before making any calls in the C++ code we can figure out which calls is the source of the crash. We also, set all the caller save registers before returning in case some weirdness is happening in the Heap constructor. This logging should not matter from a performance perspective. We only create MachineStackMarkers when we are creating a new VM, which is already expensive. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): 2017-06-15 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Implement Object.assign in C++ https://bugs.webkit.org/show_bug.cgi?id=173414 Reviewed by Saam Barati. Implementing Object.assign in JS is not so good compared to C++ version because, 1. JS version allocates JS array for object own keys. And we allocate JSString / Symbol for each key. But basically, they can be handled as UniquedStringImpl in C++. Allocating these cells are wasteful. 2. While implementing builtins in JS offers some good type speculation chances, Object.assign is inherently super polymorphic. So JS's type profile doesn't help well. 3. We have a chance to introduce various fast path for Object.assign in C++. This patch moves implementation from JS to C++. It achieves the above (1) and (2). (3) is filed in [1]. We can see 1.65x improvement in SixSpeed object-assign.es6. baseline patched object-assign.es6 643.3253+-8.0521 ^ 389.1075+-8.8840 ^ definitely 1.6533x faster [1]: https://bugs.webkit.org/show_bug.cgi?id=173416 * builtins/ObjectConstructor.js: (entries): (assign): Deleted. * runtime/JSCJSValueInlines.h: (JSC::JSValue::putInline): * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::JSCell::putInline): * runtime/JSObject.cpp: (JSC::JSObject::put): * runtime/JSObject.h: * runtime/JSObjectInlines.h: (JSC::JSObject::putInlineForJSObject): (JSC::JSObject::putInline): Deleted. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorAssign): 2017-06-14 Dan Bernstein <mitz@apple.com> [Cocoa] Objective-C class whose name begins with an underscore can’t be exported to JavaScript https://bugs.webkit.org/show_bug.cgi?id=168578 Reviewed by Geoff Garen. * API/JSWrapperMap.mm: (allocateConstructorForCustomClass): Updated for change to forEachProtocolImplementingProtocol. (-[JSObjCClassInfo allocateConstructorAndPrototype]): Ditto. (-[JSWrapperMap classInfoForClass:]): If the class name begins with an underscore, check if it defines conformance to a JSExport-derived protocol and if so, avoid using the superclass as a substitute as we’d normally do. * API/ObjcRuntimeExtras.h: (forEachProtocolImplementingProtocol): Added a "stop" argument to the block to let callers bail out. * API/tests/JSExportTests.mm: (+[JSExportTests classNamePrefixedWithUnderscoreTest]): New test for this. (runJSExportTests): Run new test. 2017-06-14 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, suppress invalid register alloation validation assertion in 32 bit part 2 https://bugs.webkit.org/show_bug.cgi?id=172421 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): 2017-06-14 Claudio Saavedra <csaavedra@igalia.com> REGRESSION: 15 new jsc failures in WPE and GTK+ https://bugs.webkit.org/show_bug.cgi?id=173349 Reviewed by JF Bastien. Recent changes to generateWasm.py are not accounted for from CMake, which leads to WasmOps.h not being regenerated in partial builds. Make generateWasm.py an additional dependency. * CMakeLists.txt: 2017-06-13 Joseph Pecoraro <pecoraro@apple.com> Debugger has unexpected effect on program correctness https://bugs.webkit.org/show_bug.cgi?id=172683 Reviewed by Saam Barati. * inspector/InjectedScriptSource.js: (InjectedScript.RemoteObject.prototype._appendPropertyPreviews): (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal): (BasicCommandLineAPI): Eliminate for..of use with Arrays from InjectedScriptSource as it can be observable. We still use it for Set / Map iteration which we can eliminate when moving to builtins. 2017-06-13 JF Bastien <jfbastien@apple.com> WebAssembly: fix erroneous signature comment https://bugs.webkit.org/show_bug.cgi?id=173334 Reviewed by Keith Miller. * wasm/WasmSignature.h: 2017-06-13 Michael Saboff <msaboff@apple.com> Refactor AbsenceOfSetter to AbsenceOfSetEffects https://bugs.webkit.org/show_bug.cgi?id=173322 Reviewed by Filip Pizlo. * bytecode/ObjectPropertyCondition.h: (JSC::ObjectPropertyCondition::absenceOfSetEffectWithoutBarrier): (JSC::ObjectPropertyCondition::absenceOfSetEffect): (JSC::ObjectPropertyCondition::absenceOfSetterWithoutBarrier): Deleted. (JSC::ObjectPropertyCondition::absenceOfSetter): Deleted. * bytecode/ObjectPropertyConditionSet.cpp: (JSC::generateConditionsForPropertySetterMiss): (JSC::generateConditionsForPropertySetterMissConcurrently): * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::dumpInContext): (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint): (JSC::PropertyCondition::isStillValid): (WTF::printInternal): * bytecode/PropertyCondition.h: (JSC::PropertyCondition::absenceOfSetEffectWithoutBarrier): (JSC::PropertyCondition::absenceOfSetEffect): (JSC::PropertyCondition::hasPrototype): (JSC::PropertyCondition::hash): (JSC::PropertyCondition::operator==): (JSC::PropertyCondition::absenceOfSetterWithoutBarrier): Deleted. (JSC::PropertyCondition::absenceOfSetter): Deleted. 2017-06-13 JF Bastien <jfbastien@apple.com> WebAssembly: import updated spec tests https://bugs.webkit.org/show_bug.cgi?id=173287 <rdar://problem/32725975> Reviewed by Saam Barati. Import spec tests as of 31c641cc15f2aedbec2fa45a5185f68416df578b, with a few modifications so things work. Fix a bunch of bugs found through this process, and punt a few tests (which I marked as blocked by this bug). Fixes: Fix load / store alignment: r216908 erroneously implemented it as bit alignment instead of byte alignment. It was also missing memory-alignment.js despite it being in the ChangeLog, so add it too. This allows spec-test/align.wast.js to pass. Tables can be imported or in a section. There can be only one, but sections can be empty. An Elements section can exist if there's no Table, as long as it is also empty. Memories can be imported or in a section. There can be only one, but sections can be empty. A Data section can exist if there's no Memory, as long as it is also empty. Prototypes: stringify without .prototype. in the string. WebAssembly.Table.prototype.grow was plain wrong: it takes a delta parameter, not a final size, and throws a RangeError on failure, not a TypeError. Fix compile / instantiate so the reject the promise if given an argument of the wrong type (instead of failing instantly). Fix async on neuter test. Element section shouldn't affect any Table if any of the elements are out of bounds. We need to process it in two passes. Segment section shouldn't affect any Data if any of the segments are out of bounds. We need to process it in two passes. Empty data segments are valid, but only when there is no memory. Their index still gets validated, and has to be zero. Punts: Error messages with context, the test seems overly restrictive but this is minor. compile/instantiate/validate property descriptors. UTF-8 bugs. Temporarily disable NaN tests. We need to go back and implement the following semantics: https://github.com/WebAssembly/spec/pull/414 This doesn't matter as much as getting all the other tests passing. Worth noting for NaNs: f64.no_fold_mul_one (also a NaN test) as well as no_fold_promote_demote (an interesting corner case which we get wrong). mul by one is (assert_return (invoke \"f64.no_fold_mul_one\" (i64.const 0x7ff4000000000000)) (i64.const 0x7ff8000000000000)) which means converting sNaN to qNaN, and promote/demote is (assert_return (invoke \"no_fold_promote_demote\" (i32.const 0x7fa00000)) (i32.const 0x7fc00000)) which is the same. I'm not sure why they're not allowed. * wasm/WasmB3IRGenerator.cpp: * wasm/WasmFunctionParser.h: * wasm/WasmModuleParser.cpp: * wasm/WasmModuleParser.h: * wasm/WasmParser.h: (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): * wasm/generateWasm.py: (memoryLog2Alignment): * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::grow): * wasm/js/JSWebAssemblyTable.h: * wasm/js/WebAssemblyCompileErrorPrototype.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: * wasm/js/WebAssemblyLinkErrorPrototype.cpp: * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModulePrototype.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyInstantiateFunc): * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::webAssemblyTableProtoFuncGrow): 2017-06-13 Michael Saboff <msaboff@apple.com> DFG doesn't properly handle a property that is change to read only in a prototype https://bugs.webkit.org/show_bug.cgi?id=173321 Reviewed by Filip Pizlo. We need to check for ReadOnly as well as a not being a Setter when checking an AbsenceOfSetter. * bytecode/PropertyCondition.cpp: (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint): 2017-06-13 Daniel Bates <dabates@apple.com> Implement W3C Secure Contexts Draft Specification https://bugs.webkit.org/show_bug.cgi?id=158121 <rdar://problem/26012994> Reviewed by Brent Fulgham. Part 4 Adds isSecureContext to the list of common identifiers as needed to support toggling its exposure from a runtime enabled feature flag. * runtime/CommonIdentifiers.h: 2017-06-13 Don Olmstead <don.olmstead@sony.com> [JSC] Remove redundant includes in config.h https://bugs.webkit.org/show_bug.cgi?id=173294 Reviewed by Alex Christensen. * config.h: 2017-06-12 Saam Barati <sbarati@apple.com> We should not claim that SpecEmpty is filtered out of cell checks on 64 bit platforms https://bugs.webkit.org/show_bug.cgi?id=172957 <rdar://problem/32602704> Reviewed by Filip Pizlo. Consider this program: ``` block#1: n: GetClosureVar(..., |this|) // this will load empty JSValue() SetLocal(Cell:@n, locFoo) // Cell check succeeds because JSValue() looks like a cell Branch(#2, #3) Block#3: x: GetLocal(locFoo) y: CheckNotEmpty(@x) ``` If we claim that a cell check filters out the empty value, we will incorrectly eliminate the CheckNotEmpty node @y. This patch fixes AI, FTLLowerDFGToB3, and DFGSpeculativeJIT to no longer make this claim. On 64 bit platforms: - Cell use kind *now allows* the empty value to pass through. - CellOrOther use kind *now allows* for the empty value to pass through - NotCell use kind *no longer allows* the empty value to pass through. * assembler/CPU.h: (JSC::isARMv7IDIVSupported): (JSC::isARM64): (JSC::isX86): (JSC::isX86_64): (JSC::is64Bit): (JSC::is32Bit): (JSC::isMIPS): Make these functions constexpr so we can use them in static variable assignment. * bytecode/SpeculatedType.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileDoubleRep): (JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther): (JSC::DFG::SpeculativeJIT::emitStringOrOtherBranch): (JSC::DFG::SpeculativeJIT::speculateCell): (JSC::DFG::SpeculativeJIT::speculateCellOrOther): (JSC::DFG::SpeculativeJIT::speculateObjectOrOther): (JSC::DFG::SpeculativeJIT::speculateString): (JSC::DFG::SpeculativeJIT::speculateStringOrOther): (JSC::DFG::SpeculativeJIT::speculateSymbol): (JSC::DFG::SpeculativeJIT::speculateNotCell): * dfg/DFGSpeculativeJIT32_64.cpp: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::fillSpeculateCell): (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep): (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32): (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject): (JSC::FTL::DFG::LowerDFGToB3::boolify): (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined): (JSC::FTL::DFG::LowerDFGToB3::lowCell): (JSC::FTL::DFG::LowerDFGToB3::lowNotCell): (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc): (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc): (JSC::FTL::DFG::LowerDFGToB3::isNotCell): (JSC::FTL::DFG::LowerDFGToB3::isCell): (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateObjectOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateString): (JSC::FTL::DFG::LowerDFGToB3::speculateStringOrOther): (JSC::FTL::DFG::LowerDFGToB3::speculateSymbol): 2017-06-12 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, suppress invalid register alloation validation assertion in 32 bit https://bugs.webkit.org/show_bug.cgi?id=172421 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): 2017-06-12 Oleksandr Skachkov <gskachkov@gmail.com> We incorrectly allow escaped characters in keyword tokens https://bugs.webkit.org/show_bug.cgi?id=171310 Reviewed by Yusuke Suzuki. According spec it is not allow to use escaped characters in keywords. https://tc39.github.io/ecma262/#sec-reserved-words Current patch implements this requirements. * parser/Lexer.cpp: (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): * parser/Parser.cpp: (JSC::Parser<LexerType>::printUnexpectedTokenText): * parser/ParserTokens.h: 2017-06-12 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, add branch64(Cond, BaseIndex, RegisterID) for ARM64 https://bugs.webkit.org/show_bug.cgi?id=172421 * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::branch64): (JSC::MacroAssemblerARM64::branchPtr): 2017-06-12 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r218093. https://bugs.webkit.org/show_bug.cgi?id=173259 Break builds (Requested by yusukesuzuki on #webkit). Reverted changeset: "Unreviewed, build fix for ARM64" https://bugs.webkit.org/show_bug.cgi?id=172421 http://trac.webkit.org/changeset/218093 2017-06-12 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for ARM64 https://bugs.webkit.org/show_bug.cgi?id=172421 * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): 2017-06-09 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Add ArrayIndexOf intrinsic https://bugs.webkit.org/show_bug.cgi?id=172421 Reviewed by Saam Barati. This patch introduces ArrayIndexOfInstrinsic for DFG and FTL optimizations. We emit array check and go fast path if the array is Array::Int32, Array::Double or Array::Continugous. In addition, for Array::Int32 and Array::Double case, we have inlined fast paths. With updated ARES-6 Babylon, Before firstIteration: 45.76 +- 3.87 ms averageWorstCase: 24.41 +- 2.17 ms steadyState: 8.01 +- 0.22 ms After firstIteration: 45.64 +- 4.23 ms averageWorstCase: 23.03 +- 3.34 ms steadyState: 7.33 +- 0.34 ms In SixSpeed. baseline patched map-set-lookup.es5 734.4701+-10.4383 ^ 102.0968+-2.6357 ^ definitely 7.1939x faster map-set.es5 41.1396+-1.0558 ^ 33.1916+-0.7986 ^ definitely 1.2395x faster map-set-object.es5 62.8317+-1.2518 ^ 45.6944+-0.8369 ^ definitely 1.3750x faster * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * 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::hasArrayMode): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArrayIndexOf): (JSC::DFG::SpeculativeJIT::speculateObject): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::speculateInt32): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf): * jit/JITOperations.h: * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::finishCreation): * runtime/Intrinsic.cpp: (JSC::intrinsicName): * runtime/Intrinsic.h: 2017-06-11 Keith Miller <keith_miller@apple.com> TypedArray constructor with string shouldn't throw https://bugs.webkit.org/show_bug.cgi?id=173181 Reviewed by JF Bastien. We should be coercing primitive arguments to numbers in the various TypedArray constructors. * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewWithArguments): 2017-06-11 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Make ThreadMessage portable https://bugs.webkit.org/show_bug.cgi?id=172073 Reviewed by Keith Miller. * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): * tools/CodeProfiling.cpp: (JSC::profilingTimer): 2017-06-11 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Shrink Structure size https://bugs.webkit.org/show_bug.cgi?id=173239 Reviewed by Mark Lam. We find that the size of our Structure is slightly enlarged due to paddings. By changing the order of members, we can reduce the size from 120 to 112. This is good because 120 and 112 are categorized into different size classes. For 120, we allocate 128 bytes. And for 112, we allocate 112 bytes. We now save 16 bytes per Structure for free. * runtime/ConcurrentJSLock.h: * runtime/Structure.cpp: (JSC::Structure::Structure): * runtime/Structure.h: 2017-06-11 Konstantin Tokarev <annulen@yandex.ru> Unreviewed, attempt to fix JSC tests on Win after r217771 * jsc.cpp: (currentWorkingDirectory): buffer is not NULL-terminated 2017-06-10 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Add RegisteredSymbolImpl https://bugs.webkit.org/show_bug.cgi?id=173230 Reviewed by Mark Lam. * runtime/SymbolConstructor.cpp: (JSC::symbolConstructorKeyFor): 2017-06-10 Dan Bernstein <mitz@apple.com> Reverted r218056 because it made the IDE reindex constantly. * Configurations/DebugRelease.xcconfig: 2017-06-10 Dan Bernstein <mitz@apple.com> [Xcode] With Xcode 9 developer beta, everything rebuilds when switching between command-line and IDE https://bugs.webkit.org/show_bug.cgi?id=173223 Reviewed by Sam Weinig. The rebuilds were happening due to a difference in the compiler options that the IDE and xcodebuild were specifying. Only the IDE was passing the -index-store-path option. To make xcodebuild pass that option, too, set CLANG_INDEX_STORE_ENABLE to YES if it is unset, and specify an appropriate path in CLANG_INDEX_STORE_PATH. * Configurations/DebugRelease.xcconfig: 2017-06-10 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Update RegExp.prototype.[@@search]] implementation according to the latest spec https://bugs.webkit.org/show_bug.cgi?id=173227 Reviewed by Mark Lam. The latest spec introduces slight change to RegExp.prototype.[@@search]. This patch applies this change. Basically, this change is done in the slow path of the RegExp.prototype[@@search]. https://tc39.github.io/ecma262/#sec-regexp.prototype-@@search * builtins/RegExpPrototype.js: (search): 2017-06-09 Chris Dumez <cdumez@apple.com> Update Thread::create() to take in a WTF::Function instead of a std::function https://bugs.webkit.org/show_bug.cgi?id=173175 Reviewed by Mark Lam. * API/tests/CompareAndSwapTest.cpp: (testCompareAndSwap): 2017-06-09 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Add verboseDFGOSRExit https://bugs.webkit.org/show_bug.cgi?id=173156 Reviewed by Saam Barati. This patch adds verboseDFGOSRExit which is similar to verboseFTLOSRExit. * dfg/DFGOSRExitCompiler.cpp: * runtime/Options.h: 2017-06-09 Guillaume Emont <guijemont@igalia.com> [JSC][MIPS] Add MacroAssemblerMIPS::xor32(Address, RegisterID) implementation https://bugs.webkit.org/show_bug.cgi?id=173170 Reviewed by Yusuke Suzuki. MIPS does not build since r217711 because it is missing this implementation. This patch fixes the build. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::xor32): 2017-06-09 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] FTL does not require dlfcn https://bugs.webkit.org/show_bug.cgi?id=173143 Reviewed by Darin Adler. We no longer use LLVM library. Thus, dlfcn.h is not necessary. Also, ProcessID is not used in FTLLowerDFGToB3.cpp. * ftl/FTLLowerDFGToB3.cpp: 2017-06-09 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Add --verboseDFGFailure https://bugs.webkit.org/show_bug.cgi?id=173155 Reviewed by Sam Weinig. Similar to verboseFTLFailure, JSC should have verboseDFGFailure flag to show DFG failures quickly. * dfg/DFGCapabilities.cpp: (JSC::DFG::verboseCapabilities): (JSC::DFG::debugFail): * runtime/Options.cpp: (JSC::recomputeDependentOptions): * runtime/Options.h: 2017-06-09 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Drop OS(DARWIN) for VM_TAG_FOR_WEBASSEMBLY_MEMORY https://bugs.webkit.org/show_bug.cgi?id=173147 Reviewed by JF Bastien. Because this value becomes -1 in non-Darwin environments. Thus, we do not need to use OS(DARWIN) here. * wasm/WasmMemory.cpp: 2017-06-09 Daewoong Jang <daewoong.jang@navercorp.com> Reduce compiler warnings https://bugs.webkit.org/show_bug.cgi?id=172078 Reviewed by Yusuke Suzuki. * runtime/IntlDateTimeFormat.h: 2017-06-08 Joseph Pecoraro <pecoraro@apple.com> [Cocoa] JSWrapperMap leaks for all JSContexts https://bugs.webkit.org/show_bug.cgi?id=173110 <rdar://problem/32602198> Reviewed by Geoffrey Garen. * API/JSContext.mm: (-[JSContext ensureWrapperMap]): Ensure this allocation gets released. 2017-06-08 Filip Pizlo <fpizlo@apple.com> REGRESSION: js/dom/prototype-chain-caching-with-impure-get-own-property-slot-traps-5.html has a flaky failure https://bugs.webkit.org/show_bug.cgi?id=161156 Reviewed by Saam Barati. Since LLInt does not register impure property watchpoints for self property accesses, it shouldn't try to cache accesses that require a watchpoint. This manifested as a flaky failure because the test would fire the watchpoint after we had usually already tiered up. Without concurrent JIT, we would have always tiered up before getting to the bad case. With concurrent JIT, we would sometimes not tier up by that time. This also adds a test that deterministically failed in LLInt without this change; it does so by just running a lot shorter. * llint/LLIntSlowPaths.cpp: (JSC::LLInt::LLINT_SLOW_PATH_DECL): 2017-06-08 Keith Miller <keith_miller@apple.com> WebAssembly: We should only create wrappers for functions that can be exported https://bugs.webkit.org/show_bug.cgi?id=173088 Reviewed by Saam Barati. This patch makes it so we only create wrappers for WebAssembly functions that can actually be exported. It appears to be a ~2.5% speedup on WasmBench compile times. This patch also removes most of the old testWasmModuleFunctions api from the jsc CLI. Most of the tests were duplicates of ones in the spec-tests directory. The others I have converted to use the normal API. * jsc.cpp: (GlobalObject::finishCreation): (valueWithTypeOfWasmValue): Deleted. (box): Deleted. (callWasmFunction): Deleted. (functionTestWasmModuleFunctions): Deleted. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): * wasm/WasmBBQPlan.h: * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmFormat.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2017-06-07 JF Bastien <jfbastien@apple.com> WebAssembly: test imports and exports with 16-bit characters https://bugs.webkit.org/show_bug.cgi?id=165977 <rdar://problem/29760130> Reviewed by Saam Barati. Add the missing UTF-8 conversions. Improve import failure error messages, otherwise it's hard to figure out which import is wrong. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::finishCreation): (JSC::WebAssemblyModuleRecord::link): 2017-06-07 Devin Rousso <drousso@apple.com> Web Inspector: Add ContextMenu item to log WebSocket object to console https://bugs.webkit.org/show_bug.cgi?id=172878 Reviewed by Joseph Pecoraro. * inspector/protocol/Network.json: Add resolveWebSocket command. 2017-06-07 Jon Davis <jond@apple.com> Update feature status for features Supported In Preview https://bugs.webkit.org/show_bug.cgi?id=173071 Reviewed by Darin Adler. Updated Media Capture and Streams, Performance Observer, Resource Timing Level 2, User Timing Level 2, Web Cryptography API, WebGL 2, WebRTC. * features.json: 2017-06-07 Saam Barati <sbarati@apple.com> Assertion failure in com.apple.WebKit.WebContent.Development in com.apple.JavaScriptCore: JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined + 141 https://bugs.webkit.org/show_bug.cgi?id=172673 <rdar://problem/32250144> Reviewed by Mark Lam. This patch simply removes this assertion. It's faulty because it races with the main thread when doing concurrent compilation. Consider a program with: - a FrozenValue over an object O and Structure S1. S1 starts off as dfgWatchable() being true. - Structure S2 The DFG IR is like so: a: JSConstant(O) // FrozenValue {O, S1} b: CheckStructure(@a, S2) c: ToThis(@a) d: CheckEq(@c, nullConstant) Branch(@d) The AbstractValue for @a will start off as having a finite structure because S1 is dfgWatchable(). When running AI, we'll notice that node @b will OSR exit, so nodes after @b are unreachable. Later in the compilation, S1 is no longer dfgWatchable(). Now, when running AI, @a will have Top for its structure set. No longer will we think @b exits. The DFG backend asserts that under such a situation, we should have simplified the CheckEq to false. However, this is a racy thing to assert, since the transition from dfgWatchable() to !dfgWatchable() can happen right before we enter the backend. Hence, this assertion is not valid. (Note, the generated code for the above program will never actually execute. Since we noticed S1 as dfgWatchable(), we make the compilation dependent on S1 not transitioning. S1 transitions, so we won't actually run the code that gets compiled.) * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined): 2017-06-07 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] has_generic_property never accepts non-String https://bugs.webkit.org/show_bug.cgi?id=173057 Reviewed by Darin Adler. We never pass non-String value to has_generic_property bytecode. * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): 2017-06-06 Fujii Hironori <Hironori.Fujii@sony.com> [Win][x86-64] Some callee saved registers aren't preserved https://bugs.webkit.org/show_bug.cgi?id=171266 Reviewed by Saam Barati. * jit/RegisterSet.cpp: (JSC::RegisterSet::calleeSaveRegisters): Added edi and esi for X86_64 Windows. 2017-06-06 Mark Lam <mark.lam@apple.com> Contiguous storage butterfly length should not exceed MAX_STORAGE_VECTOR_LENGTH. https://bugs.webkit.org/show_bug.cgi?id=173035 <rdar://problem/32554593> Reviewed by Geoffrey Garen and Filip Pizlo. Also added and fixed up some assertions. * runtime/ArrayConventions.h: * runtime/JSArray.cpp: (JSC::JSArray::setLength): * runtime/JSObject.cpp: (JSC::JSObject::createInitialIndexedStorage): (JSC::JSObject::ensureLengthSlow): (JSC::JSObject::reallocateAndShrinkButterfly): * runtime/JSObject.h: (JSC::JSObject::ensureLength): * runtime/RegExpObject.cpp: (JSC::collectMatches): * runtime/RegExpPrototype.cpp: (JSC::regExpProtoFuncSplitFast): 2017-06-06 Saam Barati <sbarati@apple.com> Make sure we restore SP when doing calls that could be to JS https://bugs.webkit.org/show_bug.cgi?id=172946 <rdar://problem/32579026> Reviewed by JF Bastien. I was worried that there was a bug where we'd call JS, JS would tail call, and we'd end up with a bogus SP. However, this bug does not exist since wasm always calls to JS through a stub, and the stub treats SP as a callee save. I wrote a test for this, and also made a note that this is the needed ABI. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): 2017-06-06 Keith Miller <keith_miller@apple.com> OMG tier up checks should be a patchpoint https://bugs.webkit.org/show_bug.cgi?id=172944 Reviewed by Saam Barati. Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes. In order to reduce code generated out of line in each function. We generate a single stub that pushes all the callee-saves. This looks like a 5-10% compile time speedup. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): * wasm/WasmThunks.cpp: (JSC::Wasm::triggerOMGTierUpThunkGenerator): * wasm/WasmThunks.h: 2017-06-06 Darin Adler <darin@apple.com> Cut down use of WTF_ARRAY_LENGTH https://bugs.webkit.org/show_bug.cgi?id=172997 Reviewed by Chris Dumez. * parser/Lexer.cpp: (JSC::singleEscape): Use WTF_ARRAY_LENGTH instead of ARRAY_SIZE. * runtime/NumberPrototype.cpp: (JSC::toStringWithRadix): Use std::end instead of WTF_ARRAY_LENGTH. 2017-06-06 Konstantin Tokarev <annulen@yandex.ru> Add missing <functional> includes https://bugs.webkit.org/show_bug.cgi?id=173017 Patch by Thiago Macieira <thiago.macieira@intel.com> Reviewed by Yusuke Suzuki. This patch fixes compilation with GCC 7. * inspector/InspectorBackendDispatcher.h: 2017-06-06 Filip Pizlo <fpizlo@apple.com> Unreviewed, fix 32-bit build. * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_unreachable): 2017-06-06 Joseph Pecoraro <pecoraro@apple.com> Unreviewed rollout r217807. Caused a test to crash. * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::buildSnapshot): (JSC::HeapSnapshotBuilder::json): (): Deleted. * heap/HeapSnapshotBuilder.h: * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): 2017-06-06 Filip Pizlo <fpizlo@apple.com> index out of bound in bytecodebasicblock https://bugs.webkit.org/show_bug.cgi?id=172963 Reviewed by Saam Barati and Mark Lam. We were leaving an unterminated basic block when generating CodeForCall for a class constructor. This was mostly benign since that unterminated block was not reachable, but it does cause an ASSERT. This fixes the issue by appending op_unreachable to that block. I added op_unreachable because this really is the cleanest and most idiomatic way to solve this problem, so even though it makes the change bigger it's probabably worth it. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/Opcode.h: (JSC::isTerminal): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::emitUnreachable): * bytecompiler/BytecodeGenerator.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_unreachable): * llint/LowLevelInterpreter.asm: * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: 2017-06-06 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r217812. This change caused test failures on arm64. Reverted changeset: "OMG tier up checks should be a patchpoint" https://bugs.webkit.org/show_bug.cgi?id=172944 http://trac.webkit.org/changeset/217812 2017-06-06 Carlos Garcia Campos <cgarcia@igalia.com> [WPE] Enable remote inspector https://bugs.webkit.org/show_bug.cgi?id=172971 Reviewed by Žan Doberšek. We can just build the current glib remote inspector, without adding a frontend implementation and using a WebKitGTK+ browser as frontend for now. * PlatformWPE.cmake: Add remote inspector files to compilation. * inspector/remote/glib/RemoteInspectorUtils.cpp: (Inspector::backendCommands): Load the inspector resources library. 2017-06-06 Carlos Garcia Campos <cgarcia@igalia.com> [GLIB] Make remote inspector DBus protocol common to all glib based ports https://bugs.webkit.org/show_bug.cgi?id=172970 Reviewed by Žan Doberšek. We are currently using "webkitgtk" in the names of DBus interfaces and object paths inside an ifdef with the idea that other ports could use their own names. However, the protocol is the same, so we could use the same names and make all glib based ports compatible to each other. This way we could use the GTK+ MiniBrowser to debug WPE, without having to implement the frontend part in WPE yet. * inspector/remote/glib/RemoteInspectorGlib.cpp: Use webkit instead of webkitgtk and reomve platform idfeds. * inspector/remote/glib/RemoteInspectorServer.cpp: Ditto. 2017-06-06 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Web Process deadlock when closing the remote inspector frontend https://bugs.webkit.org/show_bug.cgi?id=172973 Reviewed by Žan Doberšek. We are taking the remote inspector mutex twice. First close message is received, and receivedCloseMessage() takes the mutex. Then RemoteConnectionToTarget::close() is called that, when connected, calls PageDebuggable::disconnect() that ends up calling RemoteInspector::updateTarget() that also takes the remote inspector mutex. We should release the mutex before calling RemoteConnectionToTarget::close(). * inspector/remote/glib/RemoteInspectorGlib.cpp: (Inspector::RemoteInspector::receivedCloseMessage): 2017-06-05 Saam Barati <sbarati@apple.com> Try to fix features.json by adding an ESNext section. Unreviewed. * features.json: 2017-06-05 David Kilzer <ddkilzer@apple.com> Follow-up: Update JSC's features.json https://bugs.webkit.org/show_bug.cgi?id=172942 Rubber-stamped by Jon Davis. * features.json: Change "Supported in preview" to "Supported" to try to fix <https://webkit.org/status/>. 2017-06-05 Saam Barati <sbarati@apple.com> We don't properly parse init_expr when the opcode is an unexpected opcode https://bugs.webkit.org/show_bug.cgi?id=172945 Reviewed by JF Bastien. The bug is a simple typo. It should use the constant `true` instead of `false` when invoking the WASM_PARSER_FAIL_IF macro. This failure is already caught by spec tests that fail on arm64 devices. * wasm/WasmModuleParser.cpp: 2017-06-05 Keith Miller <keith_miller@apple.com> OMG tier up checks should be a patchpoint https://bugs.webkit.org/show_bug.cgi?id=172944 Reviewed by Saam Barati. Tier up checks in BBQ should be done as a patchpoint rather than individual B3 opcodes. In order to reduce code generated out of line in each function. We generate a single stub that pushes all the callee-saves. This looks like a 5-10% compile time speedup. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): * wasm/WasmThunks.cpp: (JSC::Wasm::triggerOMGTierUpThunkGenerator): * wasm/WasmThunks.h: 2017-06-05 Joseph Pecoraro <pecoraro@apple.com> Remove unused VM members https://bugs.webkit.org/show_bug.cgi?id=172941 Reviewed by Mark Lam. * runtime/HashMapImpl.h: (JSC::HashMapImpl::selectStructure): Deleted. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-06-05 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Improve ES6 Class instances in Heap Snapshot instances view https://bugs.webkit.org/show_bug.cgi?id=172848 <rdar://problem/25709212> Reviewed by Saam Barati. * heap/HeapSnapshotBuilder.h: * heap/HeapSnapshotBuilder.cpp: Update the snapshot version. Change the node's 0 | 1 internal value to be a 32bit bit flag. This is nice in that it is both compatible with the previous snapshot version and the same size. We can use more flags in the future. (JSC::HeapSnapshotBuilder::json): In cases where the classInfo gives us "Object" check for a better class name by checking (o).__proto__.constructor.name. We avoid this check in cases where (o).hasOwnProperty("constructor") which is the case for most Foo.prototype objects. Otherwise this would get the name of the Foo superclass for the Foo.prototype object. * runtime/JSObject.cpp: (JSC::JSObject::calculatedClassName): Handle some possible edge cases that were not handled before. Such as a JSObject without a GlobalObject, and an object which doesn't have a default getPrototype. Try to make the code a little clearer. 2017-06-05 Saam Barati <sbarati@apple.com> Update JSC's features.json https://bugs.webkit.org/show_bug.cgi?id=172942 Rubber stamped by Mark Lam. * features.json: 2017-06-04 Konstantin Tokarev <annulen@yandex.ru> Fix build of Windows-specific code with ICU 59.1 https://bugs.webkit.org/show_bug.cgi?id=172729 Reviewed by Darin Adler. Fix conversions from WTF::String to wchar_t* and vice versa. * jsc.cpp: (currentWorkingDirectory): (fetchModuleFromLocalFileSystem): * runtime/DateConversion.cpp: (JSC::formatDateTime): 2017-06-04 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Drop unnecessary USE(CF) guard for getenv https://bugs.webkit.org/show_bug.cgi?id=172903 Reviewed by Sam Weinig. getenv is not related to USE(CF) and OS(UNIX). It seems that this ifdef only hits in WinCairo, but WinCairo can use getenv. Moreover, in VM::VM, we already use getenv without any ifdef guard. This patch just drops it. * runtime/VM.cpp: (JSC::enableAssembler): 2017-06-04 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Drop OS(DARWIN) for uintptr_t type conflict https://bugs.webkit.org/show_bug.cgi?id=172904 Reviewed by Sam Weinig. In non-Darwin environment, uintptr_t may have the same type to uint64_t. We avoided the compile error by using OS(DARWIN). But, since it depends on cstdint implementaion rather than OS, it is flaky. Instead, we just use template parameter IntegralType. And we describe the type constraint in a SFINAE manner. * dfg/DFGOpInfo.h: (JSC::DFG::OpInfo::OpInfo): 2017-06-03 Csaba Osztrogonác <ossy@webkit.org> [ARM] Unreviewed buildfix after r217711. * assembler/MacroAssemblerARM.h: (JSC::MacroAssemblerARM::xor32): 2017-06-02 Yusuke Suzuki <utatane.tea@gmail.com> ASSERTION FAILED: "We should only declare a function as a lexically scoped variable in scopes where var declarations aren't allowed. ..." for function redeclaration with async function module export https://bugs.webkit.org/show_bug.cgi?id=168844 Reviewed by Saam Barati. As the same to the exported function declaration, we should set statementDepth = 1 for exported async function declaration. * parser/Parser.cpp: (JSC::DepthManager::DepthManager): (JSC::Parser<LexerType>::parseExportDeclaration): * parser/Parser.h: (JSC::Parser::DepthManager::DepthManager): Deleted. (JSC::Parser::DepthManager::~DepthManager): Deleted. 2017-06-02 Keith Miller <keith_miller@apple.com> Defer installing mach breakpoint handler until watchdog is actually called https://bugs.webkit.org/show_bug.cgi?id=172885 Reviewed by Saam Barati. Eagerly installing the mach breakpoint handler causes issues with Xcode GUI debugging. This hides the issue, so it won't occur as often. * runtime/VMTraps.cpp: (JSC::VMTraps::SignalSender::send): (JSC::VMTraps::VMTraps): Deleted. * runtime/VMTraps.h: 2017-06-02 Filip Pizlo <fpizlo@apple.com> Atomics.load and Atomics.store need to be fully fenced https://bugs.webkit.org/show_bug.cgi?id=172844 Reviewed by Keith Miller. Implement fully fenced loads and stores in FTL using AtomicXchgAdd(0, ptr) for the load and AtomicXchg(value, ptr) for the store. DFG needed no changes because it implements all atomics using a CAS loop. AtomicsObject.cpp now uses new Atomic<> API for fully fences loads and stores. Prior to this change, we used half fences (acquire/release) for atomic loads and stores. This is not correct according to my current understanding of the SAB memory model, which requires that atomic operations are SC with respect to everything not just other atomics. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): * ftl/FTLOutput.cpp: (JSC::FTL::Output::atomicWeakCAS): * ftl/FTLOutput.h: * runtime/AtomicsObject.cpp: 2017-06-02 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, attempt to fix the iOS build after r217711. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::xor32): (JSC::MacroAssemblerARM64::xor64): 2017-06-01 Filip Pizlo <fpizlo@apple.com> GC should use scrambled free-lists https://bugs.webkit.org/show_bug.cgi?id=172793 Reviewed by Mark Lam. Previously, our bump'n'pop allocator would use a conventional linked-list for the free-list. The linked-list would be threaded through free memory, as is the usual convention. This scrambles the next pointers of that free-list. It also scrambles the head pointer, because this leads to a more natural fast-path structure and saves one register on ARM64. The secret with which pointers are scrambled is per-allocator. Allocators choose a new secret every time they do a sweep-to-pop. This doesn't change the behavior of the bump part of bump'n'pop, but it does refactor the code quite a bit. Previously, there were four copies of the allocator fast path: two in MarkedAllocatorInlines.h, one in MarkedAllocator.cpp, and one in AssemblyHelpers.h. The JIT one was obviously different-looking, but the other three were almost identical. This moves all of that logic into FreeList. There are now just two copies of the allocator: FreeListInlines.h and AssemblyHelpers.h. This appears to be just as fast as our previously allocator. * JavaScriptCore.xcodeproj/project.pbxproj: * heap/FreeList.cpp: (JSC::FreeList::FreeList): (JSC::FreeList::~FreeList): (JSC::FreeList::clear): (JSC::FreeList::initializeList): (JSC::FreeList::initializeBump): (JSC::FreeList::contains): (JSC::FreeList::dump): * heap/FreeList.h: (JSC::FreeList::allocationWillFail): (JSC::FreeList::originalSize): (JSC::FreeList::addressOfList): (JSC::FreeList::offsetOfBlock): (JSC::FreeList::offsetOfList): (JSC::FreeList::offsetOfIndex): (JSC::FreeList::offsetOfPayloadEnd): (JSC::FreeList::offsetOfRemaining): (JSC::FreeList::offsetOfOriginalSize): (JSC::FreeList::FreeList): Deleted. (JSC::FreeList::list): Deleted. (JSC::FreeList::bump): Deleted. (JSC::FreeList::operator==): Deleted. (JSC::FreeList::operator!=): Deleted. (JSC::FreeList::operator bool): Deleted. * heap/FreeListInlines.h: Added. (JSC::FreeList::addFreeCell): (JSC::FreeList::allocate): (JSC::FreeList::forEach): (JSC::FreeList::toOffset): (JSC::FreeList::fromOffset): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::sweepNextBlock): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::MarkedAllocator): (JSC::MarkedAllocator::didConsumeFreeList): (JSC::MarkedAllocator::tryAllocateWithoutCollecting): (JSC::MarkedAllocator::tryAllocateIn): (JSC::MarkedAllocator::allocateSlowCaseImpl): (JSC::MarkedAllocator::stopAllocating): (JSC::MarkedAllocator::prepareForAllocation): (JSC::MarkedAllocator::resumeAllocating): (JSC::MarkedAllocator::sweep): (JSC::MarkedAllocator::setFreeList): Deleted. * heap/MarkedAllocator.h: (JSC::MarkedAllocator::freeList): (JSC::MarkedAllocator::isFreeListedCell): Deleted. * heap/MarkedAllocatorInlines.h: (JSC::MarkedAllocator::isFreeListedCell): (JSC::MarkedAllocator::tryAllocate): (JSC::MarkedAllocator::allocate): * heap/MarkedBlock.cpp: (JSC::MarkedBlock::Handle::stopAllocating): (JSC::MarkedBlock::Handle::lastChanceToFinalize): (JSC::MarkedBlock::Handle::resumeAllocating): (JSC::MarkedBlock::Handle::zap): (JSC::MarkedBlock::Handle::sweep): (JSC::MarkedBlock::Handle::isFreeListedCell): (JSC::MarkedBlock::Handle::forEachFreeCell): Deleted. * heap/MarkedBlock.h: * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::specializedSweep): (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace): (JSC::MarkedBlock::Handle::isFreeListedCell): Deleted. * heap/Subspace.cpp: (JSC::Subspace::finishSweep): * heap/Subspace.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator): * runtime/JSDestructibleObjectSubspace.cpp: (JSC::JSDestructibleObjectSubspace::finishSweep): * runtime/JSDestructibleObjectSubspace.h: * runtime/JSSegmentedVariableObjectSubspace.cpp: (JSC::JSSegmentedVariableObjectSubspace::finishSweep): * runtime/JSSegmentedVariableObjectSubspace.h: * runtime/JSStringSubspace.cpp: (JSC::JSStringSubspace::finishSweep): * runtime/JSStringSubspace.h: * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep): * wasm/js/JSWebAssemblyCodeBlockSubspace.h: 2017-06-02 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use @globalPrivate for concatSlowPath https://bugs.webkit.org/show_bug.cgi?id=172802 Reviewed by Darin Adler. Use @globalPrivate instead of manually putting it to JSGlobalObject. * builtins/ArrayPrototype.js: (concatSlowPath): Deleted. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): 2017-06-01 Andy Estes <aestes@apple.com> REGRESSION (r217626): ENABLE_APPLE_PAY_SESSION_V3 was disabled by mistake https://bugs.webkit.org/show_bug.cgi?id=172828 Reviewed by Beth Dakin. * Configurations/FeatureDefines.xcconfig: 2017-06-01 Keith Miller <keith_miller@apple.com> Undo rollout in r217638 with bug fix https://bugs.webkit.org/show_bug.cgi?id=172824 Unreviewed, reland patch with unused set_state code removed. * API/tests/ExecutionTimeLimitTest.cpp: (dispatchTermitateCallback): (testExecutionTimeLimit): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): (JSC::installSignalHandler): (JSC::VMTraps::SignalSender::send): * tools/SigillCrashAnalyzer.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::dump): (JSC::installCrashHandler): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-06-01 Guillaume Emont <guijemont@igalia.com> [JSC][MIPS] SamplingProfiler::timerLoop() sleeps for 4000+ seconds https://bugs.webkit.org/show_bug.cgi?id=172800 Reviewed by Saam Barati. This fixes a static_cast<uint64_t> by making it a cast to int64_t instead, which looks like the original intent. This fixes the sampling-profiler tests in JSTests/stress. * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::timerLoop): 2017-06-01 Tomas Popela <tpopela@redhat.com>, Mark Lam <mark.lam@apple.com> RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians https://bugs.webkit.org/show_bug.cgi?id=170945 Reviewed by Mark Lam. Re-define PutByIdFlags as a int32_t enum explicitly because it is stored as an int32_t value in UnlinkedInstruction. This prevents a bug on 64-bit big endian architectures where the word order is inverted (when we convert the UnlinkedInstruction into a CodeBlock Instruction), resulting in the PutByIdFlags value not being stored in the 32-bit word that the rest of the code expects it to be in. * bytecode/PutByIdFlags.h: 2017-05-31 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Implement String.prototype.concat in JS builtins https://bugs.webkit.org/show_bug.cgi?id=172798 Reviewed by Sam Weinig. Since we have highly effective + operation for strings, implementing String.prototype.concat in JS simplifies the implementation and improves performance by using speculated types. Added microbenchmarks show performance improvement. string-concat-long-convert 1063.2787+-12.9101 ^ 109.0855+-2.8083 ^ definitely 9.7472x faster string-concat-convert 1111.1366+-12.2363 ^ 99.3402+-1.9874 ^ definitely 11.1852x faster string-concat 131.7377+-3.8359 ^ 54.3949+-0.9580 ^ definitely 2.4219x faster string-concat-long 79.4726+-1.9644 ^ 64.6301+-1.4941 ^ definitely 1.2297x faster * builtins/StringPrototype.js: (globalPrivate.stringConcatSlowPath): (concat): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncConcat): Deleted. 2017-05-31 Mark Lam <mark.lam@apple.com> Remove overrides of visitChildren() that do not add any functionality. https://bugs.webkit.org/show_bug.cgi?id=172789 <rdar://problem/32500865> Reviewed by Andreas Kling. * bytecode/UnlinkedModuleProgramCodeBlock.cpp: (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted. * bytecode/UnlinkedModuleProgramCodeBlock.h: * bytecode/UnlinkedProgramCodeBlock.cpp: (JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted. * bytecode/UnlinkedProgramCodeBlock.h: * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::visitChildren): Deleted. * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::WebAssemblyInstanceConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyInstanceConstructor.h: * wasm/js/WebAssemblyMemoryConstructor.cpp: (JSC::WebAssemblyMemoryConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyMemoryConstructor.h: * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyModuleConstructor.h: * wasm/js/WebAssemblyTableConstructor.cpp: (JSC::WebAssemblyTableConstructor::visitChildren): Deleted. * wasm/js/WebAssemblyTableConstructor.h: 2017-05-31 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r217611 and r217631. https://bugs.webkit.org/show_bug.cgi?id=172785 "caused wasm-hashset-many.html to become flaky." (Requested by keith_miller on #webkit). Reverted changesets: "Reland r216808, underlying lldb bug has been fixed." https://bugs.webkit.org/show_bug.cgi?id=172759 http://trac.webkit.org/changeset/217611 "Use dispatch queues for mach exceptions" https://bugs.webkit.org/show_bug.cgi?id=172775 http://trac.webkit.org/changeset/217631 2017-05-31 Oleksandr Skachkov <gskachkov@gmail.com> Rolling out: Prevent async methods named 'function' https://bugs.webkit.org/show_bug.cgi?id=172776 Reviewed by Mark Lam. Rolling out https://bugs.webkit.org/show_bug.cgi?id=172660 r217578, https://bugs.webkit.org/show_bug.cgi?id=172598 r217478 PR to spec was closed, so changes need to roll out. See https://github.com/tc39/ecma262/pull/884#issuecomment-305212494 * parser/Parser.cpp: (JSC::Parser<LexerType>::parseClass): (JSC::Parser<LexerType>::parsePropertyMethod): 2017-05-31 Andy Estes <aestes@apple.com> Rename ENABLE_APPLE_PAY_DELEGATE to ENABLE_APPLE_PAY_SESSION_V3 and bump the supported version number https://bugs.webkit.org/show_bug.cgi?id=172366 Reviewed by Daniel Bates. * Configurations/FeatureDefines.xcconfig: 2017-05-31 Keith Miller <keith_miller@apple.com> Reland r216808, underlying lldb bug has been fixed. https://bugs.webkit.org/show_bug.cgi?id=172759 Unreviewed, relanding old patch. See: rdar://problem/31183352 * API/tests/ExecutionTimeLimitTest.cpp: (dispatchTermitateCallback): (testExecutionTimeLimit): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): (JSC::installSignalHandler): (JSC::VMTraps::SignalSender::send): * tools/SigillCrashAnalyzer.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::dump): (JSC::installCrashHandler): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-05-31 Keith Miller <keith_miller@apple.com> Fix leak in PromiseDeferredTimer https://bugs.webkit.org/show_bug.cgi?id=172755 Reviewed by JF Bastien. We were not properly freeing the list of dependencies if we were already tracking the promise before. This is because addPendingPromise takes the list of dependencies as an rvalue-reference. In the case where we were already tracking the promise we append the provided dependency list to the existing list. Since we never bound or rvalue-ref to a non-temporary value we never destructed the Vector, leaking its contents. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::addPendingPromise): 2017-05-30 Oleksandr Skachkov <gskachkov@gmail.com> Prevent async methods named 'function' in Object literal https://bugs.webkit.org/show_bug.cgi?id=172660 Reviewed by Saam Barati. Prevent async method named 'function' in object. https://github.com/tc39/ecma262/pull/884 * parser/Parser.cpp: (JSC::Parser<LexerType>::parsePropertyMethod): 2017-05-30 Oleksandr Skachkov <gskachkov@gmail.com> ASSERTION FAILED: generator.isConstructor() || generator.derivedContextType() == DerivedContextType::DerivedConstructorContext https://bugs.webkit.org/show_bug.cgi?id=171274 Reviewed by Saam Barati. Current patch allow to use async arrow function within constructor, and allow to access to `this`. Current patch force load 'this' from virtual scope each time as we access to `this` in async arrow function within constructor it is neccessary because async function can be suspended and `superCall` can be called and async function resumed. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitPutGeneratorFields): (JSC::BytecodeGenerator::ensureThis): * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::makeFunction): 2017-05-30 Ali Juma <ajuma@chromium.org> [CredentialManagement] Incorporate IDL updates from latest spec https://bugs.webkit.org/show_bug.cgi?id=172011 Reviewed by Daniel Bates. * runtime/CommonIdentifiers.h: 2017-05-30 Alex Christensen <achristensen@webkit.org> Update libwebrtc configuration https://bugs.webkit.org/show_bug.cgi?id=172727 Reviewed by Geoffrey Garen. * Configurations/FeatureDefines.xcconfig: 2017-05-28 Dan Bernstein <mitz@apple.com> [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES https://bugs.webkit.org/show_bug.cgi?id=172691 Reviewed by Tim Horton. * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO. * JavaScriptCore.xcodeproj/project.pbxproj: Added ParseInt.h to the JavaScriptCore target. 2017-05-28 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Provide better type information of toLength and tighten bytecode https://bugs.webkit.org/show_bug.cgi?id=172690 Reviewed by Sam Weinig. In this patch, we carefully leverage operator + in order to 1. tighten bytecode operator+ emits to_number bytecode. What this bytecode does is the same to @Number() call. It is more efficient, and it is smaller bytecode than @Number() call (load global variable @Number, set up arguments, and call it). 2. offer better type prediction data Now, we have code like length > 0 ? (length < @MAX_SAFE_INTEGER ? length : @MAX_SAFE_INTEGER) : 0 This is not good because DFG prediction propagation phase predicts as Double since @MAX_SAFE_INTEGER is double. But actually it rarely becomes Double. Usually, the result becomes Int32. This patch leverages to_number in a bit interesting way: to_number has value profiling to offer better type prediction. This value profiling can offer a chance to change the prediction to Int32 efficiently. It is a bit tricky. But it is worth doing to speed up our builtin functions, which should leverage all the JSC's tricky things to be optimized. Related microbenchmarks show performance improvement. baseline patched array-prototype-forEach 50.2348+-2.2331 49.7568+-2.3507 array-prototype-map 51.0574+-1.8166 47.9531+-2.1653 might be 1.0647x faster array-prototype-some 52.3926+-1.8882 ^ 48.3632+-2.0852 ^ definitely 1.0833x faster array-prototype-every 52.7394+-2.0712 50.2896+-2.1480 might be 1.0487x faster array-prototype-reduce 54.9994+-2.3638 51.8716+-2.6253 might be 1.0603x faster array-prototype-reduceRight 209.7594+-9.2594 ^ 51.5867+-2.5745 ^ definitely 4.0662x faster * builtins/GlobalOperations.js: (globalPrivate.toInteger): (globalPrivate.toLength): 2017-05-28 Sam Weinig <sam@webkit.org> [WebIDL] @@iterator should only be accessed once when disambiguating a union type https://bugs.webkit.org/show_bug.cgi?id=172684 Reviewed by Yusuke Suzuki. * runtime/IteratorOperations.cpp: (JSC::iteratorMethod): (JSC::iteratorForIterable): * runtime/IteratorOperations.h: (JSC::forEachInIterable): Add additional iterator helpers to allow union + sequence conversion code to check for iterability by getting the iterator method, and iterate using that method later on. 2017-05-28 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for Windows https://bugs.webkit.org/show_bug.cgi?id=172413 Optimized jsDynamicCast for JSMap and JSSet will be handled in [1]. [1]: https://bugs.webkit.org/show_bug.cgi?id=172685 * runtime/JSMap.h: (JSC::isJSMap): (JSC::jsDynamicCast): Deleted. (JSC::>): Deleted. * runtime/JSSet.h: (JSC::isJSSet): (JSC::jsDynamicCast): Deleted. (JSC::>): Deleted. * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/SetConstructor.cpp: (JSC::constructSet): 2017-05-28 Mark Lam <mark.lam@apple.com> Implement a faster Interpreter::getOpcodeID(). https://bugs.webkit.org/show_bug.cgi?id=172669 Reviewed by Saam Barati. We can implement Interpreter::getOpcodeID() without a hash table lookup by always embedding the OpcodeID in the 32-bit word just before the start of the LLInt handler code that executes each opcode. getOpcodeID() can therefore just read the 32-bits before the opcode address to get its OpcodeID. This is currently only enabled for CPU(X86), CPU(X86_64), CPU(ARM64), CPU(ARM_THUMB2), and only for OS(DARWIN). It'll probably just work for linux as well, but I'll let the Linux folks turn that on after they have verified that it works on linux too. I'll also take this opportunity to clean up how we initialize the opcodeIDTable: 1. we only need to initialize it once per process, not once per VM / interpreter instance. 2. we can initialize it in the Interpreter constructor instead of requiring a separate call to an initialize() function. On debug builds, the Interpreter constructor will also verify that getOpcodeID() is working correctly for each opcode when USE(LLINT_EMBEDDED_OPCODE_ID). * bytecode/BytecodeList.json: * generate-bytecode-files: * interpreter/Interpreter.cpp: (JSC::Interpreter::Interpreter): (JSC::Interpreter::opcodeIDTable): (JSC::Interpreter::initialize): Deleted. * interpreter/Interpreter.h: (JSC::Interpreter::getOpcode): (JSC::Interpreter::getOpcodeID): * llint/LowLevelInterpreter.cpp: * runtime/VM.cpp: (JSC::VM::VM): 2017-05-27 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Map and Set constructors should have fast path for cloning https://bugs.webkit.org/show_bug.cgi?id=172413 Reviewed by Saam Barati. In this patch, we add a fast path for cloning in Set and Map constructors. In ARES-6 Air, we have code like `new Set(set)` to clone the given set. At that time, our generic path just iterates the given set object and add it to the newly created one. It is quite slow because we need to follow the iterator protocol inside C++ and we need to call set.add() repeatedly while the given set guarantees the elements are unique. This patch implements clone() function to JSMap and JSSet. Cloning JSMap and JSSet are done really fast without invoking any observable JS functions. To check whether we can use this clone() function in Set and Map constructors, we set several watchpoints. In the case of Set, 1. Set.prototype[Symbol.iterator] is not changed. 2. SetIterator.prototype.next is not changed. 3. Set.prototype.add is not changed. 4. The given Set does not have [Symbol.iterator] function in its instance. 5. The given Set's [[Prototype]] is Set.prototype. 6. Newly created set's [[Prototype]] is Set.prototype. If the above requirements are met, cloning the given Set is not observable to users. Thus we can take a fast path. Currently, we do not integrate this optimization into DFG and FTL. And we do not optimize other iterables. For example, we can optimize Set constructor taking Int32 Array. And we should optimize generic iterator cases too. They are planned as part of a separate bug[1]. This change improves ARES-6 Air by 5.3% in steady state. Baseline: Running... Air ( 1 to go) firstIteration: 76.41 +- 15.60 ms averageWorstCase: 40.63 +- 7.54 ms steadyState: 9.13 +- 0.51 ms Patched: Running... Air ( 1 to go) firstIteration: 75.00 +- 22.54 ms averageWorstCase: 39.18 +- 8.45 ms steadyState: 8.67 +- 0.28 ms [1]: https://bugs.webkit.org/show_bug.cgi?id=172419 * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Removed. * runtime/HashMapImpl.h: (JSC::HashMapBucket::extractValue): (JSC::HashMapImpl::finishCreation): (JSC::HashMapImpl::add): (JSC::HashMapImpl::setUpHeadAndTail): (JSC::HashMapImpl::addNormalizedNonExistingForCloning): (JSC::HashMapImpl::addNormalizedInternal): * runtime/InternalFunction.cpp: (JSC::InternalFunction::createSubclassStructureSlow): (JSC::InternalFunction::createSubclassStructure): Deleted. * runtime/InternalFunction.h: (JSC::InternalFunction::createSubclassStructure): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::JSGlobalObject): (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::mapIteratorProtocolWatchpoint): (JSC::JSGlobalObject::setIteratorProtocolWatchpoint): (JSC::JSGlobalObject::mapSetWatchpoint): (JSC::JSGlobalObject::setAddWatchpoint): (JSC::JSGlobalObject::mapPrototype): (JSC::JSGlobalObject::jsSetPrototype): (JSC::JSGlobalObject::setStructure): * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isMapPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isSetPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isMapPrototypeSetFastAndNonObservable): (JSC::JSGlobalObject::isSetPrototypeAddFastAndNonObservable): * runtime/JSMap.cpp: (JSC::JSMap::clone): (JSC::JSMap::canCloneFastAndNonObservable): * runtime/JSMap.h: (JSC::jsDynamicCast): (JSC::>): (JSC::JSMap::createStructure): Deleted. (JSC::JSMap::create): Deleted. (JSC::JSMap::set): Deleted. (JSC::JSMap::JSMap): Deleted. * runtime/JSSet.cpp: (JSC::JSSet::clone): (JSC::JSSet::canCloneFastAndNonObservable): * runtime/JSSet.h: (JSC::jsDynamicCast): (JSC::>): (JSC::JSSet::createStructure): Deleted. (JSC::JSSet::create): Deleted. (JSC::JSSet::JSSet): Deleted. * runtime/MapConstructor.cpp: (JSC::constructMap): * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorAdaptiveWatchpoint.h. (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint): * runtime/SetConstructor.cpp: (JSC::constructSet): 2017-05-27 Yusuke Suzuki <utatane.tea@gmail.com> [DOMJIT] Move DOMJIT patchpoint infrastructure out of domjit https://bugs.webkit.org/show_bug.cgi?id=172260 Reviewed by Filip Pizlo. DOMJIT::Patchpoint is now used for generalized CheckSubClass. And it becomes mature enough to be used as a general-purpose injectable compiler over all the JIT tiers. We extract DOMJIT::Patchpoint to jit/ and rename it JSC::Snippet. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/AccessCaseSnippetParams.cpp: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.cpp. (JSC::SlowPathCallGeneratorWithArguments::generateImpl): (JSC::AccessCaseSnippetParams::emitSlowPathCalls): * bytecode/AccessCaseSnippetParams.h: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.h. (JSC::AccessCaseSnippetParams::AccessCaseSnippetParams): * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::blessCallDOMGetter): (JSC::DFG::ByteCodeParser::handleDOMJITGetter): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): * dfg/DFGGraph.h: * dfg/DFGNode.h: * dfg/DFGSnippetParams.cpp: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.cpp. * dfg/DFGSnippetParams.h: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h. (JSC::DFG::SnippetParams::SnippetParams): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::allocateTemporaryRegistersForSnippet): (JSC::DFG::SpeculativeJIT::compileCallDOMGetter): (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::allocateTemporaryRegistersForPatchpoint): Deleted. * domjit/DOMJITCallDOMGetterSnippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMGetterPatchpoint.h. (JSC::DOMJIT::CallDOMGetterSnippet::create): * domjit/DOMJITGetterSetter.h: * domjit/DOMJITSignature.h: * domjit/DOMJITValue.h: Removed. * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter): * ftl/FTLSnippetParams.cpp: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp. * ftl/FTLSnippetParams.h: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h. (JSC::FTL::SnippetParams::SnippetParams): * jit/Snippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpoint.h. (JSC::Snippet::create): (JSC::Snippet::setGenerator): (JSC::Snippet::generator): * jit/SnippetParams.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h. (JSC::SnippetParams::~SnippetParams): (JSC::SnippetParams::Value::Value): (JSC::SnippetParams::Value::isGPR): (JSC::SnippetParams::Value::isFPR): (JSC::SnippetParams::Value::isJSValueRegs): (JSC::SnippetParams::Value::gpr): (JSC::SnippetParams::Value::fpr): (JSC::SnippetParams::Value::jsValueRegs): (JSC::SnippetParams::Value::reg): (JSC::SnippetParams::Value::value): (JSC::SnippetParams::SnippetParams): * jit/SnippetReg.h: Renamed from Source/JavaScriptCore/domjit/DOMJITReg.h. (JSC::SnippetReg::SnippetReg): * jit/SnippetSlowPathCalls.h: Renamed from Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h. * jsc.cpp: (WTF::DOMJITNode::checkSubClassSnippet): (WTF::DOMJITFunctionObject::checkSubClassSnippet): (WTF::DOMJITNode::checkSubClassPatchpoint): Deleted. (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): Deleted. * runtime/ClassInfo.h: 2017-05-26 Keith Miller <keith_miller@apple.com> REEGRESSION(r217459): testapi fails in JSExportTest's wrapperForNSObjectisObject(). https://bugs.webkit.org/show_bug.cgi?id=172654 Reviewed by Mark Lam. The test's intent is to assert that an exception has not been thrown (as indicated by the message string), but the test was erroneously checking for ! the right condition. This is now fixed. * API/tests/JSExportTests.mm: (wrapperForNSObjectisObject): 2017-05-26 Joseph Pecoraro <pecoraro@apple.com> JSContext Inspector: Improve the reliability of automatically pausing in auto-attach https://bugs.webkit.org/show_bug.cgi?id=172664 <rdar://problem/32362933> Reviewed by Matt Baker. Automatically pause on connection was triggering a pause before the frontend may have initialized. Often during frontend initialization the frontend may perform an action that clears the pause state requested by the developer. This change defers the pause until after the frontend has initialized, right before returning to the application's code. * inspector/remote/RemoteControllableTarget.h: * inspector/remote/RemoteInspectionTarget.h: * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm: (Inspector::RemoteConnectionToTarget::setup): * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: (Inspector::RemoteConnectionToTarget::setup): * runtime/JSGlobalObjectDebuggable.cpp: (JSC::JSGlobalObjectDebuggable::connect): (JSC::JSGlobalObjectDebuggable::pause): Deleted. * runtime/JSGlobalObjectDebuggable.h: Pass an immediatelyPause boolean on to the controller. Remove the current path that invokes a pause before initialization. * inspector/JSGlobalObjectInspectorController.h: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::connectFrontend): (Inspector::JSGlobalObjectInspectorController::disconnectFrontend): Manage should immediately pause state. (Inspector::JSGlobalObjectInspectorController::frontendInitialized): (Inspector::JSGlobalObjectInspectorController::pause): Deleted. When initialized, trigger a pause if requested. 2017-05-26 Mark Lam <mark.lam@apple.com> Temporarily commenting out a JSExportTest test until webkit.org/b/172654 is fixed. https://bugs.webkit.org/show_bug.cgi?id=172655 Reviewed by Saam Barati. * API/tests/JSExportTests.mm: (wrapperForNSObjectisObject): 2017-05-26 Mark Lam <mark.lam@apple.com> REGRESSION(216914): testCFStrings encounters an invalid ExecState callee pointer. https://bugs.webkit.org/show_bug.cgi?id=172651 Reviewed by Saam Barati. This is because the assertion utility functions used in testCFStrings() expects to get the JSGlobalContextRef from the global context variable. However, testCFStrings() creates its own JSGlobalContextRef but does not set the global context variable to it. The fix is to make testCFStrings() initialize the global context variable properly. * API/tests/testapi.c: (testCFStrings): 2017-05-26 Yusuke Suzuki <utatane.tea@gmail.com> Give ModuleProgram the same treatment that we did for ProgramCode in bug#167725 https://bugs.webkit.org/show_bug.cgi?id=167805 Reviewed by Saam Barati. Since ModuleProgramExecutable is executed only once, we can skip compiling code unreachable from the current program count. This can skip massive initialization code. We already do this for global code in bug#167725. This patch extends it to module code. * interpreter/Interpreter.cpp: (JSC::Interpreter::executeModuleProgram): * interpreter/Interpreter.h: * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * runtime/JSModuleRecord.cpp: (JSC::JSModuleRecord::evaluate): * runtime/JSModuleRecord.h: (JSC::JSModuleRecord::moduleProgramExecutable): Deleted. 2017-05-26 Oleksandr Skachkov <gskachkov@gmail.com> Prevent async methods named 'function' https://bugs.webkit.org/show_bug.cgi?id=172598 Reviewed by Mark Lam. Prevent async method named 'function' in class. Link to change in ecma262 specification https://github.com/tc39/ecma262/pull/884 * parser/Parser.cpp: (JSC::Parser<LexerType>::parseClass): 2017-05-25 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for GCC std::tuple does not have implicit constructor. Thus, we cannot use implicit construction with initializer brace. We should specify the name like `GetInst { }`. * bytecompiler/BytecodeGenerator.h: (JSC::StructureForInContext::addGetInst): 2017-05-25 Keith Miller <keith_miller@apple.com> Cleanup tests after r217240 https://bugs.webkit.org/show_bug.cgi?id=172466 Reviewed by Mark Lam. I forgot to make my test an actual test. Also, remove second call runJSExportTests() * API/tests/JSExportTests.mm: (wrapperForNSObjectisObject): * API/tests/testapi.mm: (testObjectiveCAPIMain): 2017-05-25 Michael Saboff <msaboff@apple.com> The default setting of Option::criticalGCMemoryThreshold is too high for iOS https://bugs.webkit.org/show_bug.cgi?id=172617 Reviewed by Mark Lam. Reducing criticalGCMemoryThreshold to 0.80 eliminated jetsam on iOS devices when tested running JetStream. * runtime/Options.h: 2017-05-25 Saam Barati <sbarati@apple.com> Our for-in optimization in the bytecode generator does its static analysis incorrectly https://bugs.webkit.org/show_bug.cgi?id=172532 <rdar://problem/32369452> Reviewed by Mark Lam. Our static analysis for when a for-in induction variable is written to tried to its analysis as we generate bytecode. This has issues, since it does not account for the dynamic execution path of the program. Let's consider a program where our old analysis worked: ``` for (let p in o) { o[p]; // We can transform this into a fast get_direct_pname p = 20; o[p]; // We cannot transform this since p has been changed. } ``` However, our static analysis did not account for loops, which exist in JavaScript. e.g, it would incorrectly compile this program as: ``` for (let p in o) { for (let i = 0; i < 20; ++i) { o[p]; // It transforms this to use get_direct_pname even though p will be over-written if we get here from the inner loop back edge! p = 20; o[p]; // We correctly do not transform this. } } ``` Because of this flaw, I've made the optimization more conservative. We now optimistically emit code for the optimized access. However, if a for-in context is *ever* invalidated, before we pop it off the stack, we rewrite the program's optimized accesses to no longer be optimized. To do this, each context keeps track of its optimized accesses. This patch also adds a new bytecode, op_nop, which is just a no-op. It was helpful to add this because reverting get_direct_pname to get_by_val will leave us with an extra instruction word because get_direct_pname is has a length of 7 where get_by_val has a length of 6. This leaves us with an extra slot that we fill with an op_nop. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitGetByVal): (JSC::BytecodeGenerator::popIndexedForInScope): (JSC::BytecodeGenerator::popStructureForInScope): (JSC::BytecodeGenerator::invalidateForInContextForLocal): (JSC::StructureForInContext::pop): (JSC::IndexedForInContext::pop): * bytecompiler/BytecodeGenerator.h: (JSC::StructureForInContext::addGetInst): (JSC::IndexedForInContext::addGetInst): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_nop): * llint/LowLevelInterpreter.asm: 2017-05-25 Mark Lam <mark.lam@apple.com> ObjectToStringAdaptiveInferredPropertyValueWatchpoint should not reinstall itself nor handleFire if it's dying shortly. https://bugs.webkit.org/show_bug.cgi?id=172548 <rdar://problem/31458393> Reviewed by Filip Pizlo. Consider the following scenario: 1. A ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1, watches for structure transitions, e.g. structure S2 transitioning to structure S3. In this case, O1 would be installed in S2's watchpoint set. 2. When the structure transition happens, structure S2 will fire watchpoint O1. 3. O1's handler will normally re-install itself in the watchpoint set of the new "transitioned to" structure S3. 4. "Installation" here requires writing into the StructureRareData SD3 of the new structure S3. If SD3 does not exist yet, the installation process will trigger the allocation of StructureRareData SD3. 5. It is possible that the Structure S1, and StructureRareData SD1 that owns the ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1 is no longer reachable by the GC, and therefore will be collected soon. 6. The allocation of SD3 in (4) may trigger the sweeping of the StructureRareData SD1. This, in turn, triggers the deletion of the ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1. After O1 is deleted in (6) and SD3 is allocated in (4), execution continues in AdaptiveInferredPropertyValueWatchpointBase::fire() where O1 gets installed in structure S3's watchpoint set. This is obviously incorrect because O1 is already deleted. The result is that badness happens later when S3's watchpoint set fires its watchpoints and accesses the deleted O1. The fix is to enhance AdaptiveInferredPropertyValueWatchpointBase::fire() to check if "this" is still valid before proceeding to re-install itself or to invoke its handleFire() method. ObjectToStringAdaptiveInferredPropertyValueWatchpoint (which extends AdaptiveInferredPropertyValueWatchpointBase) will override its isValid() method, and return false its owner StructureRareData is no longer reachable by the GC. This ensures that it won't be deleted while it's installed to any watchpoint set. Additional considerations and notes: 1. In the above, I talked about the ObjectToStringAdaptiveInferredPropertyValueWatchpoint being installed in watchpoint sets. What actually happens is that ObjectToStringAdaptiveInferredPropertyValueWatchpoint has 2 members (m_structureWatchpoint and m_propertyWatchpoint) which may be installed in watchpoint sets. The ObjectToStringAdaptiveInferredPropertyValueWatchpoint is not itself a Watchpoint object. But for brevity, in the above, I refer to the ObjectToStringAdaptiveInferredPropertyValueWatchpoint instead of its Watchpoint members. The description of the issue is still accurate given the life-cycle of the Watchpoint members are embedded in the enclosing ObjectToStringAdaptiveInferredPropertyValueWatchpoint object, and hence, they share the same life-cycle. 2. The top of AdaptiveInferredPropertyValueWatchpointBase::fire() removes its m_structureWatchpoint and m_propertyWatchpoint if they have been added to any watchpoint sets. This is safe to do even if the owner StructureRareData is no longer reachable by the GC. This is because the only way we can get to AdaptiveInferredPropertyValueWatchpointBase::fire() is if its Watchpoint members are still installed in some watchpoint set that fired. This means that the AdaptiveInferredPropertyValueWatchpointBase instance has not been deleted yet, because its destructor will automatically remove the Watchpoint members from any watchpoint sets. * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp: (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire): (JSC::AdaptiveInferredPropertyValueWatchpointBase::isValid): * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h: * heap/FreeList.cpp: (JSC::FreeList::contains): * heap/FreeList.h: * heap/HeapCell.h: * heap/HeapCellInlines.h: (JSC::HeapCell::isLive): * heap/MarkedAllocator.h: (JSC::MarkedAllocator::isFreeListedCell): * heap/MarkedBlock.h: * heap/MarkedBlockInlines.h: (JSC::MarkedBlock::Handle::isFreeListedCell): * runtime/StructureRareData.cpp: (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid): 2017-05-23 Saam Barati <sbarati@apple.com> We should not mmap zero bytes for a memory in Wasm https://bugs.webkit.org/show_bug.cgi?id=172528 <rdar://problem/32257076> Reviewed by Mark Lam. This patch fixes a bug where we would call into mmap with zero bytes when creating a slow WasmMemory with zero initial page size. This fix is simple: if we don't have any initial bytes, we just call the constructor in WasmMemory that's meant to handle this case. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::create): 2017-05-23 Brian Burg <bburg@apple.com> REGRESSION(r217051): Automation sessions fail to complete bootstrap https://bugs.webkit.org/show_bug.cgi?id=172513 <rdar://problem/32338354> Reviewed by Joseph Pecoraro. The changes to be more strict about typechecking messages were too strict. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::receivedSetupMessage): WIRAutomatically is an optional key in the setup message. In the relay, this key gets copied into an NSDictionary as NSNull if the key isn't present in a forwarded command. We need to revert NSNull values to nil, since it's valid to call [nil boolValue] but not [[NSNull null] boolValue]. We also need to allow for nil in the typecheck for this key. 2017-05-23 Myles C. Maxfield <mmaxfield@apple.com> Remove dead ENABLE(FONT_LOAD_EVENTS) code https://bugs.webkit.org/show_bug.cgi?id=172517 Rubber-stamped by Simon Fraser. * Configurations/FeatureDefines.xcconfig: 2017-05-23 Saam Barati <sbarati@apple.com> CFGSimplificationPhase should not merge a block with itself https://bugs.webkit.org/show_bug.cgi?id=172508 <rdar://problem/28424006> Reviewed by Keith Miller. CFGSimplificationPhase can run into or create IR that ends up with a block that has a Jump to itself, and no other predecessors. It should gracefully handle such IR. Before this patch, it would not. The only criteria for merging 'block' with 'targetBlock' used to be that 'targetBlock.predecessors.size() == 1'. The code is written in such a way that if we merge a block with itself, we will infinite loop until we run out of memory. Merging a block with itself does not make sense for a few reasons. First, we're joining the contents of two blocks. What is the definition of joining a block with itself? I suppose we could simply unroll this self loop one level, but that would not be wise because this self loop is by definition unreachable unless it's the root block in the graph (which I think is invalid IR since we'd never generate bytecode that would do this). This patch employs an easy fix: we can't merge a block with itself. * dfg/DFGCFGSimplificationPhase.cpp: (JSC::DFG::CFGSimplificationPhase::canMergeBlocks): (JSC::DFG::CFGSimplificationPhase::run): (JSC::DFG::CFGSimplificationPhase::convertToJump): (JSC::DFG::CFGSimplificationPhase::mergeBlocks): 2017-05-22 Brian Burg <bburg@apple.com> Web Inspector: webkit reload policy should match default behavior https://bugs.webkit.org/show_bug.cgi?id=171385 <rdar://problem/31871515> Reviewed by Joseph Pecoraro. Add a new option to Page.reload that allows the test harness to reload its test page using the old reload behavior. The new behavior of revalidating expired cached subresources only is the current default, since only the test harness needs the old behavior. * inspector/protocol/Page.json: 2017-05-22 Keith Miller <keith_miller@apple.com> [Cocoa] An exported Objective C class’s prototype and constructor don't persist across JSContext deallocation https://bugs.webkit.org/show_bug.cgi?id=167708 Reviewed by Geoffrey Garen. This patch moves the Objective C wrapper map to the global object. In order to make this work the JSWrapperMap class no longer holds a reference to the JSContext. Instead, the context must be provided when getting a wrapper. Also, this patch fixes a "bug" where we would observe changes to the Object property on the global object when creating a wrapper for NSObject. * API/APICast.h: (toJSGlobalObject): * API/JSContext.mm: (-[JSContext ensureWrapperMap]): (-[JSContext initWithVirtualMachine:]): (-[JSContext dealloc]): (-[JSContext wrapperMap]): (-[JSContext initWithGlobalContextRef:]): (-[JSContext wrapperForObjCObject:]): (-[JSContext wrapperForJSObject:]): * API/JSWrapperMap.h: * API/JSWrapperMap.mm: (-[JSObjCClassInfo initForClass:]): (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]): (-[JSObjCClassInfo wrapperForObject:inContext:]): (-[JSObjCClassInfo constructorInContext:]): (-[JSObjCClassInfo prototypeInContext:]): (-[JSWrapperMap initWithGlobalContextRef:]): (-[JSWrapperMap classInfoForClass:]): (-[JSWrapperMap jsWrapperForObject:inContext:]): (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]): (-[JSObjCClassInfo initWithContext:forClass:]): Deleted. (-[JSObjCClassInfo allocateConstructorAndPrototype]): Deleted. (-[JSObjCClassInfo wrapperForObject:]): Deleted. (-[JSObjCClassInfo constructor]): Deleted. (-[JSObjCClassInfo prototype]): Deleted. (-[JSWrapperMap initWithContext:]): Deleted. (-[JSWrapperMap jsWrapperForObject:]): Deleted. (-[JSWrapperMap objcWrapperForJSValueRef:]): Deleted. * API/tests/JSExportTests.mm: (wrapperLifetimeIsTiedToGlobalObject): (runJSExportTests): * API/tests/testapi.mm: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::wrapperMap): (JSC::JSGlobalObject::setWrapperMap): 2017-05-22 Filip Pizlo <fpizlo@apple.com> FTL stack overflow handling should not assume that B3 never selects callee-saves in the prologue https://bugs.webkit.org/show_bug.cgi?id=172455 Reviewed by Mark Lam. The FTL needs to run B3's callee-save register restoration before it runs the exception handler's callee-save register restoration. This exposes B3's callee-save register algorithm in AssemblyHelpers so that the FTL can call it. * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): Fix the bug. * heap/Subspace.cpp: Added some debugging support. (JSC::Subspace::allocate): (JSC::Subspace::tryAllocate): (JSC::Subspace::didAllocate): * heap/Subspace.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::emitSave): (JSC::AssemblyHelpers::emitRestore): 2017-05-20 Yusuke Suzuki <utatane.tea@gmail.com> [FTL] Support GetByVal with ArrayStorage and SlowPutArrayStorage https://bugs.webkit.org/show_bug.cgi?id=172216 Reviewed by Saam Barati. This patch adds GetByVal support for ArrayStorage and SlowPutArrayStorage. To lower CheckInBounds in FTL, we add a new GetVectorLength op. It only accepts ArrayStorage and SlowPutArrayStorage, then it produces vector length. CheckInBounds uses this vector length to perform bound checking for ArrayStorage and SlowPutArrayStorage. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGArrayMode.cpp: (JSC::DFG::permitsBoundsCheckLowering): * 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/DFGIntegerRangeOptimizationPhase.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasArrayMode): * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::lowerBoundsCheck): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: (JSC::FTL::AbstractHeapRepository::forIndexingType): (JSC::FTL::AbstractHeapRepository::forArrayType): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileGetVectorLength): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitArrayStoragePutByVal): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emitArrayStorageLoad): (JSC::JIT::emitArrayStoragePutByVal): 2017-05-21 Saam Barati <sbarati@apple.com> We incorrectly throw a syntax error when declaring a top level for-loop iteration variable the same as a parameter https://bugs.webkit.org/show_bug.cgi?id=171041 <rdar://problem/32082516> Reviewed by Yusuke Suzuki. We were treating a for-loop variable declaration potentially as a top level statement, e.g, in a program like this: ``` function foo() { for (let variable of expr) { } } ``` But we should not be. This had the consequence of making this type of program throw a syntax error: ``` function foo(arg) { for (let arg of expr) { } } ``` even though it should not. The fix is simple, we just need to increment the statement depth before parsing anything inside the for loop. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseForStatement): 2017-05-19 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Make get_by_val & string "499" to number 499 https://bugs.webkit.org/show_bug.cgi?id=172225 Reviewed by Saam Barati. Property subscript will be converted by ToString. So JS code is not aware of the original type of the subscript value. But our get_by_val can leverage information if the given subscript is number. Thus, passing number instead of string can improve the performance of get_by_val in all the tiers. In this patch, we add BytecodeGenerator::emitNodeForProperty. It attempts to convert the given value to Int32 index constant if the given value is a string that can be converted to Int32. This patch improves SixSpeed map-string.es5 by 9.8x. This accessing form can appear in some code like accessing the result of JSON. map-string.es5 1640.6738+-110.9182 ^ 167.4121+-23.8328 ^ definitely 9.8002x faster * bytecompiler/BytecodeGenerator.h: (JSC::BytecodeGenerator::emitNodeForProperty): (JSC::BytecodeGenerator::emitNodeForLeftHandSideForProperty): * bytecompiler/NodesCodegen.cpp: (JSC::TaggedTemplateNode::emitBytecode): (JSC::BracketAccessorNode::emitBytecode): (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect): (JSC::FunctionCallBracketNode::emitBytecode): (JSC::PostfixNode::emitBracket): (JSC::PrefixNode::emitBracket): (JSC::AssignBracketNode::emitBytecode): (JSC::ReadModifyBracketNode::emitBytecode): (JSC::ForInNode::emitLoopHeader): (JSC::ForOfNode::emitBytecode): (JSC::ObjectPatternNode::bindValue): (JSC::AssignmentElementNode::bindValue): 2017-05-21 Saam Barati <sbarati@apple.com> We overwrite the callee save space on the stack when throwing stack overflow from wasm https://bugs.webkit.org/show_bug.cgi?id=172316 Reviewed by Mark Lam. When throwing a stack overflow exception, the overflow thunk would do the following: move fp, sp populate argument registers call C code However, the C function is allowed to clobber our spilled callee saves that live below fp. The reason I did this move is that when we jump to this code, we've proven that sp is out of bounds on the stack. So we're not allowed to just use its value or keep growing the stack from that point. However, this patch revises this approach to be the same in spirit, but actually correct. We conservatively assume the B3 function we're coming from could have saved all callee saves. So we emit code like this now: add -maxNumCalleeSaveSpace, fp, sp populate argument registers call C code This ensures our callee saves will not be overwritten. Note that fp is still in a valid stack range here, since the thing calling the wasm code did a stack check. Also note that maxNumCalleeSaveSpace is less than our redzone size, so it's safe to decrement sp by this amount. The previously added wasm stack overflow test is an instance crash without this change on arm64. It also appears that this test crashed on some other x86 devices. * wasm/WasmThunks.cpp: (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator): 2017-05-20 Chris Dumez <cdumez@apple.com> Drop [NoInterfaceObject] from RTCDTMFSender and RTCStatsReport https://bugs.webkit.org/show_bug.cgi?id=172418 Reviewed by Youenn Fablet. Add CommonIdentifiers that are now needed. * runtime/CommonIdentifiers.h: 2017-05-20 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, add scope.release() to propertyIsEnumerable functions. https://bugs.webkit.org/show_bug.cgi?id=172411 * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncPropertyIsEnumerable): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncPropertyIsEnumerable): 2017-05-20 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Drop MapBase https://bugs.webkit.org/show_bug.cgi?id=172417 Reviewed by Sam Weinig. MapBase is a purely additional indirection. JSMap and JSSet can directly inherit HashMapImpl. Thus MapBase is unnecessary. This patch drops it. It is good because we can eliminate one indirection when accessing to map implementation. Moreover, we can drop one unnecessary allocation per Map and Set. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket): * runtime/HashMapImpl.cpp: (JSC::HashMapImpl<HashMapBucket>::estimatedSize): (JSC::getHashMapImplKeyClassInfo): Deleted. (JSC::getHashMapImplKeyValueClassInfo): Deleted. * runtime/HashMapImpl.h: (JSC::HashMapImpl::finishCreation): (JSC::HashMapImpl::get): (JSC::HashMapImpl::info): Deleted. (JSC::HashMapImpl::createStructure): Deleted. (JSC::HashMapImpl::create): Deleted. * runtime/JSMap.h: (JSC::JSMap::set): (JSC::JSMap::get): Deleted. * runtime/JSMapIterator.cpp: (JSC::JSMapIterator::finishCreation): * runtime/JSSet.h: (JSC::JSSet::add): Deleted. * runtime/JSSetIterator.cpp: (JSC::JSSetIterator::finishCreation): * runtime/MapBase.cpp: Removed. * runtime/MapBase.h: Removed. * runtime/MapPrototype.cpp: (JSC::mapProtoFuncSize): * runtime/SetConstructor.cpp: (JSC::constructSet): * runtime/SetPrototype.cpp: (JSC::setProtoFuncSize): * runtime/VM.cpp: (JSC::VM::VM): 2017-05-20 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Speedup Object.assign for slow case by using propertyIsEnumerable https://bugs.webkit.org/show_bug.cgi?id=172411 Reviewed by Sam Weinig. We use @Reflect.@getOwnPropertyDescriptor() to check 1. the descriptor exists, 2. and the descriptor.enumrable is true But Object::propertyIsEnumerable does the completely same thing without allocating a new object for property descriptor. In this patch, we add a new private function @propertyIsEnumerable, and use it in Object.assign implementation. It does not allocate unnecessary objects. It is good for GC-pressure and performance. This patch improves SixSpeed object-assign.es6 by 1.7x. While this patch does not introduce a fast path for objects that do not have accessors, and it could speed up things further, this patch can speed up the common slow path cases that is the current implementation of Object.assign. object-assign.es6 1103.2487+-21.5602 ^ 621.8478+-34.9875 ^ definitely 1.7741x faster * builtins/BuiltinNames.h: * builtins/ObjectConstructor.js: (globalPrivate.enumerableOwnProperties): (assign): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncPropertyIsEnumerable): * runtime/JSGlobalObjectFunctions.h: 2017-05-19 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Enable testapi on Mac CMake build https://bugs.webkit.org/show_bug.cgi?id=172354 Reviewed by Alex Christensen. This patch makes testapi buildable and runnable for Mac CMake port. * API/tests/DateTests.mm: (+[DateTests JSDateToNSDateTest]): (+[DateTests roundTripThroughJSDateTest]): This test only works with the en_US locale. * shell/CMakeLists.txt: * shell/PlatformMac.cmake: Some of tests rely on ARC. We enable ARC for those files. * shell/PlatformWin.cmake: Clean up. 2017-05-19 Mark Lam <mark.lam@apple.com> [Re-landing] DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers. https://bugs.webkit.org/show_bug.cgi?id=172383 <rdar://problem/31418651> Reviewed by Filip Pizlo. pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always available as a scratch register. This assumption is wrong if this canTrample register is used for a silentFill() after an operation that returns a result in regT0 or regT1. Turns out the only reason we need the canTrample register is for SetDoubleConstant. We can remove the need for this canTrample register by introducing a moveDouble() pseudo instruction in the MacroAssembler to do the job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on ARM64. In so doing, we can simplify the silentFill() code and eliminate the bug. Update for re-landing: Changed ARM64 to use scratchRegister() as well. scratchRegister() is the proper way to get the underlying dataMemoryTempRegister() as a scratch register. * assembler/MacroAssembler.h: (JSC::MacroAssembler::moveDouble): * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator): * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallSlowPathGenerator::tearDown): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compileToLowerCase): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::emitUntypedBitOp): (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::emitSwitchImm): (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters): (JSC::DFG::SpeculativeJIT::silentFillAllRegisters): (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::convertAnyInt): 2017-05-19 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r217156. This change broke the iOS build. Reverted changeset: "DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers." https://bugs.webkit.org/show_bug.cgi?id=172383 http://trac.webkit.org/changeset/217156 2017-05-19 Mark Lam <mark.lam@apple.com> Add missing exception check. https://bugs.webkit.org/show_bug.cgi?id=172346 <rdar://problem/32289640> Reviewed by Geoffrey Garen. * runtime/JSObject.cpp: (JSC::JSObject::hasInstance): 2017-05-19 Mark Lam <mark.lam@apple.com> DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers. https://bugs.webkit.org/show_bug.cgi?id=172383 <rdar://problem/31418651> Reviewed by Filip Pizlo. pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always available as a scratch register. This assumption is wrong if this canTrample register is used for a silentFill() after an operation that returns a result in regT0 or regT1. Turns out the only reason we need the canTrample register is for SetDoubleConstant. We can remove the need for this canTrample register by introducing a moveDouble() pseudo instruction in the MacroAssembler to do the job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on ARM64. In so doing, we can simplify the silentFill() code and eliminate the bug. * assembler/MacroAssembler.h: (JSC::MacroAssembler::moveDouble): * dfg/DFGArrayifySlowPathGenerator.h: * dfg/DFGCallArrayAllocatorSlowPathGenerator.h: (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator): * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h: * dfg/DFGSaneStringGetByValSlowPathGenerator.h: * dfg/DFGSlowPathGenerator.h: (JSC::DFG::CallSlowPathGenerator::tearDown): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::compileToLowerCase): (JSC::DFG::SpeculativeJIT::compileValueToInt32): (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::emitUntypedBitOp): (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp): (JSC::DFG::SpeculativeJIT::compileArithDiv): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::emitSwitchImm): (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::silentFill): (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters): (JSC::DFG::SpeculativeJIT::silentFillAllRegisters): (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq): (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::convertAnyInt): 2017-05-19 Filip Pizlo <fpizlo@apple.com> Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy https://bugs.webkit.org/show_bug.cgi?id=172382 Reviewed by Saam Barati. This is just a small clean-up - my last patch here created some unnecessary code duplication. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): 2017-05-19 Filip Pizlo <fpizlo@apple.com> arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided https://bugs.webkit.org/show_bug.cgi?id=172369 Reviewed by Mark Lam. * heap/Subspace.cpp: Reshaped the code a bit to aid debugging. (JSC::Subspace::allocate): (JSC::Subspace::tryAllocate): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug! * runtime/ObjectInitializationScope.cpp: Provide even better feedback. (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized): 2017-05-18 Filip Pizlo <fpizlo@apple.com> B3::Value::effects() says that having a fence range implies the fence bit, but on x86_64 we lower loadAcq/storeRel to load/store so the store-before-load fence bit orderings won't be honored https://bugs.webkit.org/show_bug.cgi?id=172306 Reviewed by Michael Saboff. This changes B3 to emit xchg and its variants for fenced stores on x86. This ensures that fenced stores cannot be reordered around other fenced instructions. Previously, B3 emitted normal store instructions for fenced stores. That's wrong because then you get reorderings that are possible in TSO but impossible in SC. Fenced instructions are supposed to be SC with respect for each other. This is imprecise. If you really just wanted a store-release, then every X86 store does this. But, in B3, fenced stores are ARM-style store-release, meaning that they are fenced with respect to all other fences. If we ever did want to say that something is a store release in the traditional sense, then we'd want MemoryValue to have a fence flag. Then, having a fence range without the fence flag would mean the traditional store-release, which lowers to a normal store on x86. But to my knowledge, that traditional store-release is only useful for unlocking spinlocks. We don't use spinlocks in JSC. Adaptive locks require CAS for unlock, and B3 CAS is plenty fast. I think it's OK to have this small imprecision of giving clients an ARM-style store-release on x86 using xchg. The implication of this change is that the FTL no longer violates the SAB memory model. * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::xchg8): (JSC::MacroAssemblerX86Common::xchg16): (JSC::MacroAssemblerX86Common::xchg32): (JSC::MacroAssemblerX86Common::loadAcq8): Deleted. (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32): Deleted. (JSC::MacroAssemblerX86Common::loadAcq16): Deleted. (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32): Deleted. (JSC::MacroAssemblerX86Common::loadAcq32): Deleted. (JSC::MacroAssemblerX86Common::storeRel8): Deleted. (JSC::MacroAssemblerX86Common::storeRel16): Deleted. (JSC::MacroAssemblerX86Common::storeRel32): Deleted. * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::xchg64): (JSC::MacroAssemblerX86_64::loadAcq64): Deleted. (JSC::MacroAssemblerX86_64::storeRel64): Deleted. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::ArgPromise::inst): (JSC::B3::Air::LowerToAir::trappingInst): (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp): (JSC::B3::Air::LowerToAir::createStore): (JSC::B3::Air::LowerToAir::storeOpcode): (JSC::B3::Air::LowerToAir::appendStore): (JSC::B3::Air::LowerToAir::append): (JSC::B3::Air::LowerToAir::appendTrapping): (JSC::B3::Air::LowerToAir::fillStackmap): (JSC::B3::Air::LowerToAir::lower): * b3/air/AirKind.cpp: (JSC::B3::Air::Kind::dump): * b3/air/AirKind.h: (JSC::B3::Air::Kind::Kind): (JSC::B3::Air::Kind::operator==): (JSC::B3::Air::Kind::hash): * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerMacros.cpp: (JSC::B3::Air::lowerMacros): * b3/air/AirOpcode.opcodes: * b3/air/AirValidate.cpp: * b3/air/opcode_generator.rb: * b3/testb3.cpp: (JSC::B3::correctSqrt): (JSC::B3::testSqrtArg): (JSC::B3::testSqrtImm): (JSC::B3::testSqrtMem): (JSC::B3::testSqrtArgWithUselessDoubleConversion): (JSC::B3::testSqrtArgWithEffectfulDoubleConversion): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testTrappingLoad): (JSC::B3::testTrappingStore): (JSC::B3::testTrappingLoadAddStore): (JSC::B3::testTrappingLoadDCE): 2017-05-19 Don Olmstead <don.olmstead@am.sony.com> [JSC] Remove PLATFORM(WIN) references https://bugs.webkit.org/show_bug.cgi?id=172294 Reviewed by Yusuke Suzuki. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::removeThread): * llint/LLIntOfflineAsmConfig.h: * runtime/ConfigFile.h: * runtime/VM.cpp: (JSC::VM::updateStackLimits): 2017-05-19 Yusuke Suzuki <utatane.tea@gmail.com> [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass https://bugs.webkit.org/show_bug.cgi?id=172098 Reviewed by Saam Barati. In this patch, we generalize CheckDOM to CheckSubClass. It can accept any ClassInfo and perform ClassInfo check in DFG / FTL. Now, we add a new function pointer to ClassInfo, checkSubClassPatchpoint. It can create DOMJIT patchpoint for that ClassInfo. It it natural that ClassInfo holds the way to emit DOMJIT::Patchpoint to perform CheckSubClass rather than having it in each DOMJIT getter / function signature annotation. One problem is that it enlarges the size of ClassInfo. But this is the best place to put this function pointer. By doing so, we can add a patchpoint for CheckSubClass in an non-intrusive manner: WebCore can inject patchpoints without interactive JSC. We still have a way to reduce the size of ClassInfo if we move ArrayBuffer related methods out to the other places. This patch touches many files because we add a new function pointer to ClassInfo. But they are basically mechanical change. * API/JSAPIWrapperObject.mm: * API/JSCallbackConstructor.cpp: * API/JSCallbackFunction.cpp: * API/JSCallbackObject.cpp: * API/ObjCCallbackFunction.mm: * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: * bytecode/DOMJITAccessCasePatchpointParams.h: (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams): * bytecode/EvalCodeBlock.cpp: * bytecode/FunctionCodeBlock.cpp: * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/ModuleProgramCodeBlock.cpp: * bytecode/ProgramCodeBlock.cpp: * bytecode/UnlinkedCodeBlock.cpp: * bytecode/UnlinkedEvalCodeBlock.cpp: * bytecode/UnlinkedFunctionCodeBlock.cpp: * bytecode/UnlinkedFunctionExecutable.cpp: * bytecode/UnlinkedModuleProgramCodeBlock.cpp: * bytecode/UnlinkedProgramCodeBlock.cpp: * debugger/DebuggerScope.cpp: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleDOMJITGetter): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDOMJITPatchpointParams.h: (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeCallDOM): (JSC::DFG::FixupPhase::fixupCheckSubClass): (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::hasClassInfo): (JSC::DFG::Node::classInfo): (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted. (JSC::DFG::Node::checkDOMPatchpoint): Deleted. * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::vm): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * domjit/DOMJITGetterSetter.h: * domjit/DOMJITPatchpointParams.h: (JSC::DOMJIT::PatchpointParams::PatchpointParams): (JSC::DOMJIT::PatchpointParams::vm): * domjit/DOMJITSignature.h: (JSC::DOMJIT::Signature::Signature): (JSC::DOMJIT::Signature::checkDOM): Deleted. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLDOMJITPatchpointParams.h: (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted. * inspector/JSInjectedScriptHost.cpp: * inspector/JSInjectedScriptHostPrototype.cpp: * inspector/JSJavaScriptCallFrame.cpp: * inspector/JSJavaScriptCallFramePrototype.cpp: * jsc.cpp: (WTF::DOMJITNode::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::finishCreation): (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): (WTF::DOMJITCheckSubClassObject::createStructure): (WTF::DOMJITCheckSubClassObject::create): (WTF::DOMJITCheckSubClassObject::safeFunction): (WTF::DOMJITCheckSubClassObject::unsafeFunction): (WTF::DOMJITCheckSubClassObject::finishCreation): (GlobalObject::finishCreation): (functionCreateDOMJITCheckSubClassObject): (WTF::DOMJITNode::checkDOMJITNode): Deleted. (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted. * runtime/AbstractModuleRecord.cpp: * runtime/ArrayBufferNeuteringWatchpoint.cpp: * runtime/ArrayConstructor.cpp: * runtime/ArrayIteratorPrototype.cpp: * runtime/ArrayPrototype.cpp: * runtime/AsyncFunctionConstructor.cpp: * runtime/AsyncFunctionPrototype.cpp: * runtime/AtomicsObject.cpp: * runtime/BooleanConstructor.cpp: * runtime/BooleanObject.cpp: * runtime/BooleanPrototype.cpp: * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp. (JSC::ClassInfo::dump): * runtime/ClassInfo.h: (JSC::ClassInfo::offsetOfParentClass): * runtime/ClonedArguments.cpp: * runtime/ConsoleObject.cpp: * runtime/CustomGetterSetter.cpp: * runtime/DateConstructor.cpp: * runtime/DateInstance.cpp: * runtime/DatePrototype.cpp: * runtime/DirectArguments.cpp: * runtime/Error.cpp: * runtime/ErrorConstructor.cpp: * runtime/ErrorInstance.cpp: * runtime/ErrorPrototype.cpp: * runtime/EvalExecutable.cpp: * runtime/Exception.cpp: * runtime/ExceptionHelpers.cpp: * runtime/ExecutableBase.cpp: * runtime/FunctionConstructor.cpp: * runtime/FunctionExecutable.cpp: * runtime/FunctionPrototype.cpp: * runtime/FunctionRareData.cpp: * runtime/GeneratorFunctionConstructor.cpp: * runtime/GeneratorFunctionPrototype.cpp: * runtime/GeneratorPrototype.cpp: * runtime/GetterSetter.cpp: * runtime/HashMapImpl.cpp: * runtime/HashMapImpl.h: * runtime/InferredType.cpp: (JSC::InferredType::create): * runtime/InferredTypeTable.cpp: * runtime/InferredValue.cpp: * runtime/InspectorInstrumentationObject.cpp: * runtime/InternalFunction.cpp: * runtime/IntlCollator.cpp: * runtime/IntlCollatorConstructor.cpp: * runtime/IntlCollatorPrototype.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlObject.cpp: * runtime/IteratorPrototype.cpp: * runtime/JSAPIValueWrapper.cpp: * runtime/JSArray.cpp: * runtime/JSArrayBuffer.cpp: * runtime/JSArrayBufferConstructor.cpp: * runtime/JSArrayBufferPrototype.cpp: * runtime/JSArrayBufferView.cpp: * runtime/JSAsyncFunction.cpp: * runtime/JSBoundFunction.cpp: * runtime/JSCallee.cpp: * runtime/JSCustomGetterSetterFunction.cpp: * runtime/JSDataView.cpp: * runtime/JSDataViewPrototype.cpp: * runtime/JSEnvironmentRecord.cpp: * runtime/JSFixedArray.cpp: * runtime/JSFunction.cpp: * runtime/JSGeneratorFunction.cpp: * runtime/JSGlobalLexicalEnvironment.cpp: * runtime/JSGlobalObject.cpp: * runtime/JSInternalPromise.cpp: * runtime/JSInternalPromiseConstructor.cpp: * runtime/JSInternalPromiseDeferred.cpp: * runtime/JSInternalPromisePrototype.cpp: * runtime/JSLexicalEnvironment.cpp: * runtime/JSMap.cpp: * runtime/JSMapIterator.cpp: * runtime/JSModuleEnvironment.cpp: * runtime/JSModuleLoader.cpp: * runtime/JSModuleNamespaceObject.cpp: * runtime/JSModuleRecord.cpp: * runtime/JSNativeStdFunction.cpp: * runtime/JSONObject.cpp: * runtime/JSObject.cpp: * runtime/JSPromise.cpp: * runtime/JSPromiseConstructor.cpp: * runtime/JSPromiseDeferred.cpp: * runtime/JSPromisePrototype.cpp: * runtime/JSPropertyNameEnumerator.cpp: * runtime/JSPropertyNameIterator.cpp: * runtime/JSProxy.cpp: * runtime/JSScriptFetcher.cpp: * runtime/JSSet.cpp: * runtime/JSSetIterator.cpp: * runtime/JSSourceCode.cpp: * runtime/JSString.cpp: * runtime/JSStringIterator.cpp: * runtime/JSSymbolTableObject.cpp: * runtime/JSTemplateRegistryKey.cpp: * runtime/JSTypedArrayConstructors.cpp: * runtime/JSTypedArrayPrototypes.cpp: * runtime/JSTypedArrayViewConstructor.cpp: * runtime/JSTypedArrays.cpp: * runtime/JSWeakMap.cpp: * runtime/JSWeakSet.cpp: * runtime/JSWithScope.cpp: * runtime/MapConstructor.cpp: * runtime/MapIteratorPrototype.cpp: * runtime/MapPrototype.cpp: * runtime/MathObject.cpp: * runtime/ModuleLoaderPrototype.cpp: * runtime/ModuleProgramExecutable.cpp: * runtime/NativeErrorConstructor.cpp: * runtime/NativeExecutable.cpp: * runtime/NativeStdFunctionCell.cpp: * runtime/NullGetterFunction.cpp: * runtime/NullSetterFunction.cpp: * runtime/NumberConstructor.cpp: * runtime/NumberObject.cpp: * runtime/NumberPrototype.cpp: * runtime/ObjectConstructor.cpp: * runtime/ObjectPrototype.cpp: * runtime/ProgramExecutable.cpp: * runtime/PropertyTable.cpp: * runtime/ProxyConstructor.cpp: * runtime/ProxyObject.cpp: * runtime/ProxyRevoke.cpp: * runtime/ReflectObject.cpp: * runtime/RegExp.cpp: * runtime/RegExpConstructor.cpp: * runtime/RegExpObject.cpp: * runtime/RegExpPrototype.cpp: * runtime/ScopedArguments.cpp: * runtime/ScopedArgumentsTable.cpp: * runtime/ScriptExecutable.cpp: * runtime/SetConstructor.cpp: * runtime/SetIteratorPrototype.cpp: * runtime/SetPrototype.cpp: * runtime/SparseArrayValueMap.cpp: * runtime/StrictEvalActivation.cpp: * runtime/StringConstructor.cpp: * runtime/StringIteratorPrototype.cpp: * runtime/StringObject.cpp: * runtime/StringPrototype.cpp: * runtime/Structure.cpp: * runtime/StructureChain.cpp: * runtime/StructureRareData.cpp: * runtime/Symbol.cpp: * runtime/SymbolConstructor.cpp: * runtime/SymbolObject.cpp: * runtime/SymbolPrototype.cpp: * runtime/SymbolTable.cpp: * runtime/WeakMapConstructor.cpp: * runtime/WeakMapData.cpp: * runtime/WeakMapPrototype.cpp: * runtime/WeakSetConstructor.cpp: * runtime/WeakSetPrototype.cpp: * testRegExp.cpp: * tools/JSDollarVM.cpp: * tools/JSDollarVMPrototype.cpp: * wasm/JSWebAssembly.cpp: * wasm/js/JSWebAssemblyCodeBlock.cpp: * wasm/js/JSWebAssemblyCompileError.cpp: * wasm/js/JSWebAssemblyInstance.cpp: * wasm/js/JSWebAssemblyLinkError.cpp: * wasm/js/JSWebAssemblyMemory.cpp: * wasm/js/JSWebAssemblyModule.cpp: * wasm/js/JSWebAssemblyRuntimeError.cpp: * wasm/js/JSWebAssemblyTable.cpp: * wasm/js/WebAssemblyCompileErrorConstructor.cpp: * wasm/js/WebAssemblyCompileErrorPrototype.cpp: * wasm/js/WebAssemblyFunction.cpp: * wasm/js/WebAssemblyFunctionBase.cpp: * wasm/js/WebAssemblyInstanceConstructor.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: * wasm/js/WebAssemblyLinkErrorConstructor.cpp: * wasm/js/WebAssemblyLinkErrorPrototype.cpp: * wasm/js/WebAssemblyMemoryConstructor.cpp: * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyModulePrototype.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: * wasm/js/WebAssemblyPrototype.cpp: * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: * wasm/js/WebAssemblyTableConstructor.cpp: * wasm/js/WebAssemblyTablePrototype.cpp: * wasm/js/WebAssemblyToJSCallee.cpp: * wasm/js/WebAssemblyWrapperFunction.cpp: 2017-05-18 JF Bastien <jfbastien@apple.com> WebAssembly: exports is a getter https://bugs.webkit.org/show_bug.cgi?id=172129 Reviewed by Saam Barati. As updated here: https://github.com/WebAssembly/design/pull/1062 * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): don't putDirect here anymore * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::moduleNamespaceObject): add accessor * wasm/js/WebAssemblyFunctionBase.cpp: squelch causing a warning * wasm/js/WebAssemblyInstancePrototype.cpp: use LUT (JSC::getInstance): helper, as in surrounding files (JSC::webAssemblyInstanceProtoFuncExports): instead of putDirect * wasm/js/WebAssemblyMemoryPrototype.cpp: pass VM around as for Table (JSC::getMemory): (JSC::webAssemblyMemoryProtoFuncGrow): (JSC::webAssemblyMemoryProtoFuncBuffer): * wasm/js/WebAssemblyTablePrototype.cpp: static everywhere as with other code (JSC::webAssemblyTableProtoFuncLength): (JSC::webAssemblyTableProtoFuncGrow): (JSC::webAssemblyTableProtoFuncGet): (JSC::webAssemblyTableProtoFuncSet): 2017-05-18 Saam Barati <sbarati@apple.com> Proxy's [[Get]] passes incorrect receiver https://bugs.webkit.org/show_bug.cgi?id=164849 <rdar://problem/31767058> Reviewed by Yusuke Suzuki. * runtime/ProxyObject.cpp: (JSC::performProxyGet): 2017-05-18 Andy Estes <aestes@apple.com> ENABLE(APPLE_PAY_DELEGATE) should be NO on macOS Sierra and earlier https://bugs.webkit.org/show_bug.cgi?id=172305 Reviewed by Anders Carlsson. * Configurations/FeatureDefines.xcconfig: 2017-05-18 Saam Barati <sbarati@apple.com> We need to destroy worker threads in jsc.cpp https://bugs.webkit.org/show_bug.cgi?id=170751 <rdar://problem/31800412> Reviewed by Filip Pizlo. This patch fixes a bug where a $ agent worker would still have compilation threads running after the thread the worker was created on dies. This manifested itself inside DFG AI where we would notice a string constant is atomic, then the worker thread would die, destroying its atomic string table, then we'd notice the same string is no longer atomic, and we'd crash because we'd fail to see the same speculated type for the same JSValue. This patch makes it so that $ agent workers destroy their VM when they're done executing. Before a VM gets destroyed, it ensures that all its compilation threads finish. * jsc.cpp: (functionDollarAgentStart): (runJSC): (jscmain): 2017-05-18 Michael Saboff <msaboff@apple.com> Add FTL whitelist debugging option https://bugs.webkit.org/show_bug.cgi?id=172321 Reviewed by Saam Barati. * dfg/DFGTierUpCheckInjectionPhase.cpp: (JSC::DFG::ensureGlobalFTLWhitelist): (JSC::DFG::TierUpCheckInjectionPhase::run): * runtime/Options.h: * tools/FunctionWhitelist.cpp: (JSC::FunctionWhitelist::contains): 2017-05-18 Filip Pizlo <fpizlo@apple.com> Constructor calls set this too early https://bugs.webkit.org/show_bug.cgi?id=172302 Reviewed by Saam Barati. We were setting this before evaluating the arguments, so this code: var x = 42; new x(x = function() { }); Would crash because we would pass 42 as this, and create_this would treat it as a cell. Dereferencing a non-cell is guaranteed to crash. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitConstruct): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::NewExprNode::emitBytecode): (JSC::FunctionCallValueNode::emitBytecode): 2017-05-18 Saam Barati <sbarati@apple.com> WebAssembly: perform stack checks https://bugs.webkit.org/show_bug.cgi?id=165546 <rdar://problem/29760307> Reviewed by Filip Pizlo. This patch adds stack checks to wasm. It implements it by storing the stack bounds on the Context. Stack checking works as normal, except we do a small optimization for terminal nodes in the call tree (nodes that don't make any calls). These nodes will only do a stack check if their frame size is beyond 1024 bytes. Otherwise, it's assumed the parent that called them did their stack check for them. This is because all things that make calls make sure to do an extra 1024 bytes whenever doing a stack check. We also take into account stack size for potential JS calls when doing stack checks since our JS stubs don't do this on their own. Each frame will ensure it does a stack check large enough for any potential JS call stubs it'll execute. Surprisingly, this patch is neutral on WasmBench and TitzerBench. * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * runtime/Error.cpp: (JSC::createRangeError): (JSC::addErrorInfoAndGetBytecodeOffset): I fixed a bug here where we assumed that the first frame that has line and column info would be in our stack trace. This is not correct since we limit our stack trace size. If everything in our limited size stack trace is Wasm, then we won't have any frames with line and column info. * runtime/Error.h: * runtime/ExceptionHelpers.cpp: (JSC::createStackOverflowError): * runtime/ExceptionHelpers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure): * runtime/JSType.h: * runtime/Options.h: I've added a new option that controls whether or not we use fast TLS for the wasm context. * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmContext.cpp: (JSC::Wasm::loadContext): (JSC::Wasm::storeContext): * wasm/WasmContext.h: (JSC::Wasm::useFastTLSForContext): * wasm/WasmExceptionType.h: * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator): (JSC::Wasm::Thunks::stub): * wasm/WasmThunks.h: * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): (JSC::JSWebAssemblyInstance::cachedStackLimit): (JSC::JSWebAssemblyInstance::setCachedStackLimit): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object. This is needed for correctness because we may call into JS, and then the first JS frame could stack overflow. When it stack overflows, it rolls back one frame to the wasm->js call stub with the wasm->js callee. It gets the lexical global object from this frame, meaning it gets the global object from the callee. Therefore, we must make it an object since all objects have global objects. (JSC::WebAssemblyToJSCallee::create): * wasm/js/WebAssemblyToJSCallee.h: 2017-05-18 Keith Miller <keith_miller@apple.com> WebAssembly API: test with neutered inputs https://bugs.webkit.org/show_bug.cgi?id=163899 Reviewed by JF Bastien. Add tests to check that we properly throw a type error when we get a transferred ArrayBuffer. Also, we should make sure we cannot post message a wasm memory's ArrayBuffer. * API/JSTypedArray.cpp: (JSObjectGetArrayBufferBytesPtr): * runtime/ArrayBuffer.cpp: (JSC::ArrayBuffer::makeShared): (JSC::ArrayBuffer::makeWasmMemory): (JSC::ArrayBuffer::transferTo): (JSC::ArrayBuffer::neuter): (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer): (JSC::errorMesasgeForTransfer): * runtime/ArrayBuffer.h: (JSC::ArrayBuffer::isLocked): (JSC::ArrayBuffer::isWasmMemory): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::buffer): (JSC::JSWebAssemblyMemory::grow): 2017-05-18 Joseph Pecoraro <pecoraro@apple.com> Remote Inspector: Be stricter about checking message types https://bugs.webkit.org/show_bug.cgi?id=172259 <rdar://problem/32264839> Reviewed by Brian Burg. * inspector/remote/cocoa/RemoteInspectorCocoa.mm: (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedDidCloseMessage): (Inspector::RemoteInspector::receivedIndicateMessage): (Inspector::RemoteInspector::receivedConnectionDiedMessage): (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage): (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage): (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage): * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm: (Inspector::RemoteInspectorXPCConnection::deserializeMessage): (Inspector::RemoteInspectorXPCConnection::handleEvent): (Inspector::RemoteInspectorXPCConnection::sendMessage): Bail if we don't receive the expected types for message data. 2017-05-18 Filip Pizlo <fpizlo@apple.com> DFG inlining should be hardened for the no-result case https://bugs.webkit.org/show_bug.cgi?id=172290 Reviewed by Saam Barati. Previously, if we were inlining a setter call, we might have a bad time because the setter's result register is the invalid VirtualRegister(), and much of the intrinsic handling code assumes that the result register is valid. This doesn't usually cause problems because people don't usually point a setter at something that we recognize as an intrinsic. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment. * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal. (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner. (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug. (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter). * runtime/Intrinsic.cpp: Added. I needed this to debug. (JSC::intrinsicName): (WTF::printInternal): * runtime/Intrinsic.h: 2017-05-18 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r217031, r217032, and r217037. https://bugs.webkit.org/show_bug.cgi?id=172293 cause linking errors in Windows (Requested by yusukesuzuki on #webkit). Reverted changesets: "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass" https://bugs.webkit.org/show_bug.cgi?id=172098 http://trac.webkit.org/changeset/217031 "Unreviewed, rebaseline for newly added ClassInfo" https://bugs.webkit.org/show_bug.cgi?id=172098 http://trac.webkit.org/changeset/217032 "Unreviewed, fix debug and non-JIT build" https://bugs.webkit.org/show_bug.cgi?id=172098 http://trac.webkit.org/changeset/217037 2017-05-17 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, fix debug and non-JIT build https://bugs.webkit.org/show_bug.cgi?id=172098 * jsc.cpp: (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): 2017-05-17 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, rebaseline for newly added ClassInfo https://bugs.webkit.org/show_bug.cgi?id=172098 * wasm/js/WebAssemblyFunctionBase.cpp: 2017-05-16 Yusuke Suzuki <utatane.tea@gmail.com> [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass https://bugs.webkit.org/show_bug.cgi?id=172098 Reviewed by Saam Barati. In this patch, we generalize CheckDOM to CheckSubClass. It can accept any ClassInfo and perform ClassInfo check in DFG / FTL. Now, we add a new function pointer to ClassInfo, checkSubClassPatchpoint. It can create DOMJIT patchpoint for that ClassInfo. It it natural that ClassInfo holds the way to emit DOMJIT::Patchpoint to perform CheckSubClass rather than having it in each DOMJIT getter / function signature annotation. One problem is that it enlarges the size of ClassInfo. But this is the best place to put this function pointer. By doing so, we can add a patchpoint for CheckSubClass in an non-intrusive manner: WebCore can inject patchpoints without interactive JSC. We still have a way to reduce the size of ClassInfo if we move ArrayBuffer related methods out to the other places. This patch touches many files because we add a new function pointer to ClassInfo. But they are basically mechanical change. * API/JSAPIWrapperObject.mm: * API/JSCallbackConstructor.cpp: * API/JSCallbackFunction.cpp: * API/JSCallbackObject.cpp: * API/ObjCCallbackFunction.mm: * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: * bytecode/DOMJITAccessCasePatchpointParams.h: (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams): * bytecode/EvalCodeBlock.cpp: * bytecode/FunctionCodeBlock.cpp: * bytecode/GetterSetterAccessCase.cpp: (JSC::GetterSetterAccessCase::emitDOMJITGetter): * bytecode/ModuleProgramCodeBlock.cpp: * bytecode/ProgramCodeBlock.cpp: * bytecode/UnlinkedCodeBlock.cpp: * bytecode/UnlinkedEvalCodeBlock.cpp: * bytecode/UnlinkedFunctionCodeBlock.cpp: * bytecode/UnlinkedFunctionExecutable.cpp: * bytecode/UnlinkedModuleProgramCodeBlock.cpp: * bytecode/UnlinkedProgramCodeBlock.cpp: * debugger/DebuggerScope.cpp: * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleDOMJITGetter): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDOMJITPatchpointParams.h: (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::attemptToMakeCallDOM): (JSC::DFG::FixupPhase::fixupCheckSubClass): (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNode.h: (JSC::DFG::Node::hasClassInfo): (JSC::DFG::Node::classInfo): (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted. (JSC::DFG::Node::checkDOMPatchpoint): Deleted. * dfg/DFGNodeType.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCheckSubClass): (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted. * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::vm): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo. And ClassInfo knows how to perform CheckSubClass efficiently. If ClassInfo does not have a way to perform CheckSubClass efficiently, we just perform jsDynamicCast thing in ASM. * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * domjit/DOMJITGetterSetter.h: * domjit/DOMJITPatchpointParams.h: (JSC::DOMJIT::PatchpointParams::PatchpointParams): (JSC::DOMJIT::PatchpointParams::vm): * domjit/DOMJITSignature.h: (JSC::DOMJIT::Signature::Signature): (JSC::DOMJIT::Signature::checkDOM): Deleted. * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLDOMJITPatchpointParams.h: (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted. * inspector/JSInjectedScriptHost.cpp: * inspector/JSInjectedScriptHostPrototype.cpp: * inspector/JSJavaScriptCallFrame.cpp: * inspector/JSJavaScriptCallFramePrototype.cpp: * jsc.cpp: (WTF::DOMJITNode::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): (WTF::DOMJITFunctionObject::finishCreation): (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject): (WTF::DOMJITCheckSubClassObject::createStructure): (WTF::DOMJITCheckSubClassObject::create): (WTF::DOMJITCheckSubClassObject::safeFunction): (WTF::DOMJITCheckSubClassObject::unsafeFunction): (WTF::DOMJITCheckSubClassObject::finishCreation): (GlobalObject::finishCreation): (functionCreateDOMJITCheckSubClassObject): (WTF::DOMJITNode::checkDOMJITNode): Deleted. (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted. * runtime/AbstractModuleRecord.cpp: * runtime/ArrayBufferNeuteringWatchpoint.cpp: * runtime/ArrayConstructor.cpp: * runtime/ArrayIteratorPrototype.cpp: * runtime/ArrayPrototype.cpp: * runtime/AsyncFunctionConstructor.cpp: * runtime/AsyncFunctionPrototype.cpp: * runtime/AtomicsObject.cpp: * runtime/BooleanConstructor.cpp: * runtime/BooleanObject.cpp: * runtime/BooleanPrototype.cpp: * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp. (JSC::ClassInfo::dump): * runtime/ClassInfo.h: (JSC::ClassInfo::offsetOfParentClass): * runtime/ClonedArguments.cpp: * runtime/ConsoleObject.cpp: * runtime/CustomGetterSetter.cpp: * runtime/DateConstructor.cpp: * runtime/DateInstance.cpp: * runtime/DatePrototype.cpp: * runtime/DirectArguments.cpp: * runtime/Error.cpp: * runtime/ErrorConstructor.cpp: * runtime/ErrorInstance.cpp: * runtime/ErrorPrototype.cpp: * runtime/EvalExecutable.cpp: * runtime/Exception.cpp: * runtime/ExceptionHelpers.cpp: * runtime/ExecutableBase.cpp: * runtime/FunctionConstructor.cpp: * runtime/FunctionExecutable.cpp: * runtime/FunctionPrototype.cpp: * runtime/FunctionRareData.cpp: * runtime/GeneratorFunctionConstructor.cpp: * runtime/GeneratorFunctionPrototype.cpp: * runtime/GeneratorPrototype.cpp: * runtime/GetterSetter.cpp: * runtime/HashMapImpl.cpp: * runtime/HashMapImpl.h: * runtime/InferredType.cpp: (JSC::InferredType::create): * runtime/InferredTypeTable.cpp: * runtime/InferredValue.cpp: * runtime/InspectorInstrumentationObject.cpp: * runtime/InternalFunction.cpp: * runtime/IntlCollator.cpp: * runtime/IntlCollatorConstructor.cpp: * runtime/IntlCollatorPrototype.cpp: * runtime/IntlDateTimeFormat.cpp: * runtime/IntlDateTimeFormatConstructor.cpp: * runtime/IntlDateTimeFormatPrototype.cpp: * runtime/IntlNumberFormat.cpp: * runtime/IntlNumberFormatConstructor.cpp: * runtime/IntlNumberFormatPrototype.cpp: * runtime/IntlObject.cpp: * runtime/IteratorPrototype.cpp: * runtime/JSAPIValueWrapper.cpp: * runtime/JSArray.cpp: * runtime/JSArrayBuffer.cpp: * runtime/JSArrayBufferConstructor.cpp: * runtime/JSArrayBufferPrototype.cpp: * runtime/JSArrayBufferView.cpp: * runtime/JSAsyncFunction.cpp: * runtime/JSBoundFunction.cpp: * runtime/JSCallee.cpp: * runtime/JSCustomGetterSetterFunction.cpp: * runtime/JSDataView.cpp: * runtime/JSDataViewPrototype.cpp: * runtime/JSEnvironmentRecord.cpp: * runtime/JSFixedArray.cpp: * runtime/JSFunction.cpp: * runtime/JSGeneratorFunction.cpp: * runtime/JSGlobalLexicalEnvironment.cpp: * runtime/JSGlobalObject.cpp: * runtime/JSInternalPromise.cpp: * runtime/JSInternalPromiseConstructor.cpp: * runtime/JSInternalPromiseDeferred.cpp: * runtime/JSInternalPromisePrototype.cpp: * runtime/JSLexicalEnvironment.cpp: * runtime/JSMap.cpp: * runtime/JSMapIterator.cpp: * runtime/JSModuleEnvironment.cpp: * runtime/JSModuleLoader.cpp: * runtime/JSModuleNamespaceObject.cpp: * runtime/JSModuleRecord.cpp: * runtime/JSNativeStdFunction.cpp: * runtime/JSONObject.cpp: * runtime/JSObject.cpp: * runtime/JSPromise.cpp: * runtime/JSPromiseConstructor.cpp: * runtime/JSPromiseDeferred.cpp: * runtime/JSPromisePrototype.cpp: * runtime/JSPropertyNameEnumerator.cpp: * runtime/JSPropertyNameIterator.cpp: * runtime/JSProxy.cpp: * runtime/JSScriptFetcher.cpp: * runtime/JSSet.cpp: * runtime/JSSetIterator.cpp: * runtime/JSSourceCode.cpp: * runtime/JSString.cpp: * runtime/JSStringIterator.cpp: * runtime/JSSymbolTableObject.cpp: * runtime/JSTemplateRegistryKey.cpp: * runtime/JSTypedArrayConstructors.cpp: * runtime/JSTypedArrayPrototypes.cpp: * runtime/JSTypedArrayViewConstructor.cpp: * runtime/JSTypedArrays.cpp: * runtime/JSWeakMap.cpp: * runtime/JSWeakSet.cpp: * runtime/JSWithScope.cpp: * runtime/MapConstructor.cpp: * runtime/MapIteratorPrototype.cpp: * runtime/MapPrototype.cpp: * runtime/MathObject.cpp: * runtime/ModuleLoaderPrototype.cpp: * runtime/ModuleProgramExecutable.cpp: * runtime/NativeErrorConstructor.cpp: * runtime/NativeExecutable.cpp: * runtime/NativeStdFunctionCell.cpp: * runtime/NullGetterFunction.cpp: * runtime/NullSetterFunction.cpp: * runtime/NumberConstructor.cpp: * runtime/NumberObject.cpp: * runtime/NumberPrototype.cpp: * runtime/ObjectConstructor.cpp: * runtime/ObjectPrototype.cpp: * runtime/ProgramExecutable.cpp: * runtime/PropertyTable.cpp: * runtime/ProxyConstructor.cpp: * runtime/ProxyObject.cpp: * runtime/ProxyRevoke.cpp: * runtime/ReflectObject.cpp: * runtime/RegExp.cpp: * runtime/RegExpConstructor.cpp: * runtime/RegExpObject.cpp: * runtime/RegExpPrototype.cpp: * runtime/ScopedArguments.cpp: * runtime/ScopedArgumentsTable.cpp: * runtime/ScriptExecutable.cpp: * runtime/SetConstructor.cpp: * runtime/SetIteratorPrototype.cpp: * runtime/SetPrototype.cpp: * runtime/SparseArrayValueMap.cpp: * runtime/StrictEvalActivation.cpp: * runtime/StringConstructor.cpp: * runtime/StringIteratorPrototype.cpp: * runtime/StringObject.cpp: * runtime/StringPrototype.cpp: * runtime/Structure.cpp: * runtime/StructureChain.cpp: * runtime/StructureRareData.cpp: * runtime/Symbol.cpp: * runtime/SymbolConstructor.cpp: * runtime/SymbolObject.cpp: * runtime/SymbolPrototype.cpp: * runtime/SymbolTable.cpp: * runtime/WeakMapConstructor.cpp: * runtime/WeakMapData.cpp: * runtime/WeakMapPrototype.cpp: * runtime/WeakSetConstructor.cpp: * runtime/WeakSetPrototype.cpp: * testRegExp.cpp: * tools/JSDollarVM.cpp: * tools/JSDollarVMPrototype.cpp: * wasm/JSWebAssembly.cpp: * wasm/js/JSWebAssemblyCodeBlock.cpp: * wasm/js/JSWebAssemblyCompileError.cpp: * wasm/js/JSWebAssemblyInstance.cpp: * wasm/js/JSWebAssemblyLinkError.cpp: * wasm/js/JSWebAssemblyMemory.cpp: * wasm/js/JSWebAssemblyModule.cpp: * wasm/js/JSWebAssemblyRuntimeError.cpp: * wasm/js/JSWebAssemblyTable.cpp: * wasm/js/WebAssemblyCompileErrorConstructor.cpp: * wasm/js/WebAssemblyCompileErrorPrototype.cpp: * wasm/js/WebAssemblyFunction.cpp: * wasm/js/WebAssemblyInstanceConstructor.cpp: * wasm/js/WebAssemblyInstancePrototype.cpp: * wasm/js/WebAssemblyLinkErrorConstructor.cpp: * wasm/js/WebAssemblyLinkErrorPrototype.cpp: * wasm/js/WebAssemblyMemoryConstructor.cpp: * wasm/js/WebAssemblyMemoryPrototype.cpp: * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyModulePrototype.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: * wasm/js/WebAssemblyPrototype.cpp: * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp: * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: * wasm/js/WebAssemblyTableConstructor.cpp: * wasm/js/WebAssemblyTablePrototype.cpp: * wasm/js/WebAssemblyToJSCallee.cpp: * wasm/js/WebAssemblyWrapperFunction.cpp: 2017-05-17 Saam Barati <sbarati@apple.com> We don't do context switches for Wasm->Wasm call indirect https://bugs.webkit.org/show_bug.cgi?id=172188 <rdar://problem/32231828> Reviewed by Keith Miller. We did not do a context switch when doing an indirect call. This is clearly wrong, since the thing we're making an indirect call to could be from another instance. This patch fixes this oversight by doing a very simple context switch. I've also opened a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197 since this patch adds yet another branch to the indirect call path. I've also added tests that either throw or crash before this change. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * wasm/WasmB3IRGenerator.cpp: * wasm/js/JSWebAssemblyTable.h: (JSC::JSWebAssemblyTable::offsetOfJSFunctions): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::visitChildren): (JSC::WebAssemblyFunction::finishCreation): Deleted. * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::instance): Deleted. (JSC::WebAssemblyFunction::offsetOfInstance): Deleted. * wasm/js/WebAssemblyFunctionBase.cpp: Added. (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase): (JSC::WebAssemblyFunctionBase::visitChildren): (JSC::WebAssemblyFunctionBase::finishCreation): * wasm/js/WebAssemblyFunctionBase.h: Added. (JSC::WebAssemblyFunctionBase::instance): (JSC::WebAssemblyFunctionBase::offsetOfInstance): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): (JSC::WebAssemblyWrapperFunction::finishCreation): (JSC::WebAssemblyWrapperFunction::visitChildren): * wasm/js/WebAssemblyWrapperFunction.h: 2017-05-17 Filip Pizlo <fpizlo@apple.com> JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform https://bugs.webkit.org/show_bug.cgi?id=172208 Reviewed by Saam Barati. * dfg/DFGArgumentsEliminationPhase.cpp: 2017-05-17 Don Olmstead <don.olmstead@am.sony.com> [Win] Support $vm.getpid() https://bugs.webkit.org/show_bug.cgi?id=172248 Reviewed by Mark Lam. * tools/JSDollarVMPrototype.cpp: (JSC::functionGetPID): (JSC::JSDollarVMPrototype::finishCreation): 2017-05-17 Michael Saboff <msaboff@apple.com> [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info https://bugs.webkit.org/show_bug.cgi?id=172186 Reviewed by Geoffrey Garen. The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call the OS to get up to date values. In overCriticalMemoryThreshold(), we get the current value every 100th call and use a cached value the rest of the time. When colleciton is done, we start with a new overCriticalMemoryThreshold value for the next cycle. The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact performance and still provides timely memory footprint data. With additional debug logging, I determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream. Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per GC cycle. Dividing both of these numbers by 100 seems reasonable. * heap/Heap.cpp: (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::updateAllocationLimits): (JSC::Heap::shouldDoFullCollection): * heap/Heap.h: 2017-05-17 Saam Barati <sbarati@apple.com> PinnedRegisters should be better modeled in IRC/Briggs https://bugs.webkit.org/show_bug.cgi?id=171955 Reviewed by Filip Pizlo. This patch fixes a bug in Briggs/IRC with respect to pinned registers. Pinned registers were not part of the assignable register file in IRC/Briggs, and this would lead to an asymmetry because they were modeled in the interference graph. The bug is that we use registerCount() to move various Tmps between various lists in the different allocators, and if a Tmp interfered with a pinned register (usually via a Patchpoint's clobbered set), we'd have an interference edge modeled in the degree for that Tmp, but the registerCount() would make us think that this particular Tmp is not assignable. This would lead us to fail to color a colorable graph. Specifically, this happened in our various patchpoint tests that stress the register allocator by forcing the entire register file into arguments for the patchpoint and then doing interesting things with the result, arguments, etc. This patch fixes the bug by coming up with an more natural way to model pinned registers. Pinned registers are now part of the register file. However, pinned registers are live at every point in the program (this is a defining property of a pinned register). In practice, this means that the only Tmps that can be assigned to pinned registers are ones that are coalescing candidates. This means the program has some number of defs for a Tmp T like: MoveType pinnedReg, T Note, if any other defs for T happen, like: Add32, t1, t2, T T will have an interference edge with pinnedReg, since pinnedReg is live at every point in the program. Modeling pinned registers this way allows IRC/Briggs to have no special casing for them. It treats it like any other precolored Tmp. This allows us to do coalescing, biased coloring, etc, which could all lead to a Tmp being assigned to a pinned register. Interestingly, we used to have special handling for the frame pointer register, which in many ways, acts like a pinned register, since FP is always live, and we wanted it to take place in coalescing. The allocator had a side-table interference graph with FP. Interestingly, we didn't even handle this properly everywhere since we could rely on a patchpoint never claiming to clobber FP (this would be illegal). So the code only handled the pseudo-pinned register properties of FP in various places. This patch drops this special casing and pins FP since all pinned registers can take part in coalescing. * b3/B3PatchpointSpecial.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::mutableGPRs): (JSC::B3::Procedure::mutableFPRs): * b3/B3Procedure.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): (JSC::B3::Air::Code::pinRegister): (JSC::B3::Air::Code::mutableGPRs): (JSC::B3::Air::Code::mutableFPRs): * b3/air/AirCode.h: (JSC::B3::Air::Code::pinnedRegisters): * b3/air/AirSpecial.h: * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs): (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testLateRegister): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2): (JSC::B3::testMoveConstants): 2017-05-16 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String) https://bugs.webkit.org/show_bug.cgi?id=172115 Reviewed by Saam Barati. In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping empty strings. However, when we are in Fixup phase, we do not have much information about constant values. In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce MakeRope handling in constant folding phase. It shows 7.5% performance improvement in ARES-6 Babylon steadyState. Before: firstIteration: 50.02 +- 14.56 ms averageWorstCase: 26.52 +- 4.52 ms steadyState: 8.15 +- 0.23 ms After: firstIteration: 49.08 +- 12.90 ms averageWorstCase: 25.16 +- 3.82 ms steadyState: 7.58 +- 0.21 ms * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): 2017-05-16 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, add Objective C files to CMake Mac port https://bugs.webkit.org/show_bug.cgi?id=172103 * shell/PlatformMac.cmake: Added. 2017-05-16 JF Bastien <jfbastien@apple.com> WebAssembly: enforce size limits https://bugs.webkit.org/show_bug.cgi?id=165833 <rdar://problem/29760219> Reviewed by Keith Miller. Use the same limits as V8. * JavaScriptCore.xcodeproj/project.pbxproj: * wasm/WasmLimits.h: Added. * wasm/WasmModuleParser.cpp: * wasm/WasmParser.h: (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): 2017-05-15 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Build testapi in non Apple ports https://bugs.webkit.org/show_bug.cgi?id=172103 Reviewed by Filip Pizlo. This patch makes JSC testapi buildable in non-Apple ports. We isolate CF related tests in testapi.c. If we do not use CF, we include JavaScript.h instead of JavaScriptCore.h. By running the testapi in Linux, we found that contraints test have a bug: If constraint marker runs after WeakRefs are destroyed, it accesses destroyed WeakRef. This patch also fixes it. * API/tests/CurrentThisInsideBlockGetterTest.h: * API/tests/CustomGlobalObjectClassTest.c: * API/tests/ExecutionTimeLimitTest.cpp: * API/tests/FunctionOverridesTest.cpp: * API/tests/GlobalContextWithFinalizerTest.cpp: * API/tests/JSObjectGetProxyTargetTest.cpp: * API/tests/MultithreadedMultiVMExecutionTest.cpp: * API/tests/PingPongStackOverflowTest.cpp: * API/tests/TypedArrayCTest.cpp: * API/tests/testapi.c: (assertEqualsAsCharactersPtr): (markingConstraint): (testMarkingConstraintsAndHeapFinalizers): (testCFStrings): (main): * shell/CMakeLists.txt: 2017-05-16 JF Bastien <jfbastien@apple.com> WebAssembly: report Memory usage to GC https://bugs.webkit.org/show_bug.cgi?id=170690 <rdar://problem/31965310> Reviewed by Keith Miller. * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::finishCreation): (JSC::JSWebAssemblyMemory::visitChildren): 2017-05-16 JF Bastien <jfbastien@apple.com> WebAssembly: validate load / store alignment https://bugs.webkit.org/show_bug.cgi?id=168836 <rdar://problem/31965349> Reviewed by Keith Miller. * wasm/WasmFunctionParser.h: check the alignment * wasm/generateWasm.py: generate the log2 alignment helper (Wasm): (isSimple): (memoryLog2Alignment): * wasm/generateWasmOpsHeader.py: (memoryLog2AlignmentGenerator): * wasm/wasm.json: fix formatting 2017-05-15 Mark Lam <mark.lam@apple.com> Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread. https://bugs.webkit.org/show_bug.cgi?id=172147 Rubber-stamped by Saam Barati. I rolled out every thing in those 2 patches except for the change to make CodeBlock::finishCreation() return a bool plus its clients that depend on this. I made this exception because r214931 relies on this change, and this part of the change looks correct. * builtins/BuiltinNames.h: * builtins/GlobalOperations.js: (globalPrivate.speciesConstructor): (globalPrivate.copyDataProperties): Deleted. * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted. * bytecode/CodeBlock.h: * bytecode/UnlinkedCodeBlock.h: (JSC::UnlinkedCodeBlock::addBitVector): (JSC::UnlinkedCodeBlock::constantRegisters): (JSC::UnlinkedCodeBlock::addSetConstant): Deleted. (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted. * bytecompiler/BytecodeGenerator.cpp: * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::PropertyListNode::emitBytecode): (JSC::ObjectPatternNode::bindValue): (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted. * parser/ASTBuilder.h: (JSC::ASTBuilder::createProperty): (JSC::ASTBuilder::appendObjectPatternEntry): (JSC::ASTBuilder::createObjectSpreadExpression): Deleted. (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted. (JSC::ASTBuilder::setContainsObjectRestElement): Deleted. * parser/NodeConstructors.h: (JSC::PropertyNode::PropertyNode): (JSC::SpreadExpressionNode::SpreadExpressionNode): (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted. * parser/Nodes.h: (JSC::ObjectPatternNode::appendEntry): (JSC::ObjectSpreadExpressionNode::expression): Deleted. (JSC::ObjectPatternNode::setContainsRestElement): Deleted. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseDestructuringPattern): (JSC::Parser<LexerType>::parseProperty): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createSpreadExpression): (JSC::SyntaxChecker::createProperty): (JSC::SyntaxChecker::operatorStackPop): (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted. * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/SetPrototype.cpp: (JSC::SetPrototype::finishCreation): 2017-05-15 David Kilzer <ddkilzer@apple.com> JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic <https://webkit.org/b/172134> Reviewed by Saam Barati. * runtime/JSEnvironmentRecord.h: (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return size_t and use checked arithmetic. (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change to use checked arithmetic. 2017-05-15 Mark Lam <mark.lam@apple.com> WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution(). https://bugs.webkit.org/show_bug.cgi?id=171775 <rdar://problem/30975761> Reviewed by Filip Pizlo. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/Options.h: - Added the unexpectedExceptionStackTraceLimit option. * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-13 David Kilzer <ddkilzer@apple.com> Unused lambda capture in JSContextGroupAddMarkingConstraint() <https://webkit.org/b/172084> Reviewed by Saam Barati. Fixes the following warning with newer clang: Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture] [&vm, constraintCallback, userData] ^ * API/JSMarkingConstraintPrivate.cpp: (JSContextGroupAddMarkingConstraint): Remove unused lambda capture for '&vm'. 2017-05-13 David Kilzer <ddkilzer@apple.com> [JSC] config.rb fails when checking some clang versions <https://webkit.org/b/172082> Reviewed by Mark Lam. * offlineasm/config.rb: - Add support for quad-dotted version of Apple clang (800.0.12.1). - Add support for checking open source clang version (5.0.0). 2017-05-13 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r216808. https://bugs.webkit.org/show_bug.cgi?id=172075 caused lldb to hang when debugging (Requested by smfr on #webkit). Reverted changeset: "Use Mach exceptions instead of signals where possible" https://bugs.webkit.org/show_bug.cgi?id=171865 http://trac.webkit.org/changeset/216808 2017-05-13 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r216801. https://bugs.webkit.org/show_bug.cgi?id=172072 Many memory corruption crashes on worker threads (Requested by ap on #webkit). Reverted changeset: "WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution()." https://bugs.webkit.org/show_bug.cgi?id=171775 http://trac.webkit.org/changeset/216801 2017-05-12 Geoffrey Garen <ggaren@apple.com> [JSC] DFG::Node should not have its own allocator https://bugs.webkit.org/show_bug.cgi?id=160098 Reviewed by Saam Barati. I just rebased the patch from <http://trac.webkit.org/changeset/203808>. I ran Octane and JetStream locally on a MacBook Air and I wasn't able to reproduce a regression. Let's land this again and see what the bots say. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::packIndices): * dfg/DFGAllocator.h: Removed. * dfg/DFGDriver.cpp: (JSC::DFG::compileImpl): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::~Graph): (JSC::DFG::Graph::deleteNode): (JSC::DFG::Graph::packNodeIndices): (JSC::DFG::Graph::addNodeToMapByIndex): Deleted. * dfg/DFGGraph.h: (JSC::DFG::Graph::addNode): (JSC::DFG::Graph::maxNodeCount): (JSC::DFG::Graph::nodeAt): * dfg/DFGLongLivedState.cpp: Removed. * dfg/DFGLongLivedState.h: Removed. * dfg/DFGNode.h: * dfg/DFGNodeAllocator.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThread): (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGPlan.h: * dfg/DFGWorklist.cpp: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: 2017-05-12 Keith Miller <keith_miller@apple.com> Use Mach exceptions instead of signals where possible https://bugs.webkit.org/show_bug.cgi?id=171865 Reviewed by Mark Lam. This patch adds some new JSC options. The first is an option that enables or disables web assembly tier up. The second controls whether or not we use mach exceptions (where available). * API/tests/ExecutionTimeLimitTest.cpp: (dispatchTermitateCallback): (testExecutionTimeLimit): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: * runtime/VMTraps.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::adjustPCToPointToTrappingInstruction): (JSC::installSignalHandler): (JSC::VMTraps::SignalSender::send): * tools/SigillCrashAnalyzer.cpp: (JSC::SignalContext::SignalContext): (JSC::SignalContext::dump): (JSC::installCrashHandler): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::compileFunctions): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): * wasm/WasmMachineThreads.cpp: (JSC::Wasm::resetInstructionCacheOnAllThreads): 2017-05-12 Mark Lam <mark.lam@apple.com> WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution(). https://bugs.webkit.org/show_bug.cgi?id=171775 <rdar://problem/30975761> Reviewed by Saam Barati. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/Options.h: - Added the unexpectedExceptionStackTraceLimit option. * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-12 Daniel Bates <dabates@apple.com> Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject& https://bugs.webkit.org/show_bug.cgi?id=172021 Reviewed by Mark Lam. Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject& instead of a const JSGlobalObject* as all implementations expect to be passed a non- const, non-null JSGlobalObject object. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::queueMicrotask): * runtime/JSGlobalObject.h: * runtime/VM.cpp: (JSC::VM::queueMicrotask): * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as it is only called from JavaScriptCore code. 2017-05-12 Michael Saboff <msaboff@apple.com> [iOS] Use memory footprint to dynamically adjust behavior of allocators https://bugs.webkit.org/show_bug.cgi?id=171944 Reviewed by Filip Pizlo. This change is iOS only. Added the ability to react to when memory usage is critical. This is defined as memory usage being above the newly added option criticalGCMemoryThreshold. When we are in this critical state, all collections are Full and we limit the amount of memory we allocate between collections to 1/4th the memory above the critical threshold. Changed the calculation of proportionalHeapSize to be based on process memory footprint and not how big the heap is. Also, the values of Options::smallHeapRAMFraction and Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens using the more agressive Options::smallHeapGrowthFactor. * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::overCriticalMemoryThreshold): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/Options.cpp: (JSC::overrideDefaults): (JSC::Options::initialize): * runtime/Options.h: 2017-05-11 Saam Barati <sbarati@apple.com> Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles https://bugs.webkit.org/show_bug.cgi?id=171962 Reviewed by Filip Pizlo. The purpose of getting the result width is to get the width of the result of the arithmetic. It does not care about that the Check happens to define scratches. * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::forEachArg): * b3/testb3.cpp: (JSC::B3::testCheckMul): (JSC::B3::testCheckMulMemory): (JSC::B3::testCheckMul64): (JSC::B3::testCheckMulFold): (JSC::B3::testCheckMulFoldFail): (JSC::B3::testCheckMulArgumentAliasing64): (JSC::B3::testCheckMulArgumentAliasing32): (JSC::B3::testCheckMul64SShr): 2017-05-11 Saam Barati <sbarati@apple.com> isValidForm for SimpleAddr should use ptr() instead of tmp() https://bugs.webkit.org/show_bug.cgi?id=171992 Reviewed by Filip Pizlo. Arg::tmp() asserts that its kind is Tmp. Inst::isValidForm for SimpleAddr was using Arg::tmp() instead of ptr() to check if the address Tmp isGP(). It should be using Arg::ptr() instead of Arg::tmp() since Arg::ptr() is designed for SimpleAddr. This patch also fixes an incorrect assertion in the ARM64 macro assembler. We were asserting various atomic ops were only over 32/64 bit operations. However, the code was properly handling 8/16/32/64 bit ops. I changed the assertion to reflect what is actually going on. * assembler/ARM64Assembler.h: (JSC::ARM64Assembler::ldar): (JSC::ARM64Assembler::ldxr): (JSC::ARM64Assembler::ldaxr): (JSC::ARM64Assembler::stxr): (JSC::ARM64Assembler::stlr): (JSC::ARM64Assembler::stlxr): * b3/air/opcode_generator.rb: * b3/testb3.cpp: (JSC::B3::testLoadAcq42): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testStoreRelAddLoadAcq8): (JSC::B3::testStoreRelAddFenceLoadAcq8): (JSC::B3::testStoreRelAddLoadAcq16): (JSC::B3::testStoreRelAddLoadAcq64): (JSC::B3::testAtomicWeakCAS): (JSC::B3::testAtomicStrongCAS): (JSC::B3::testAtomicXchg): 2017-05-11 Matt Lewis <jlewis3@apple.com> Unreviewed, rolling out r216677. Patch caused layout test crashes. Reverted changeset: "WorkerThread::stop() should call scheduleExecutionTermination() last." https://bugs.webkit.org/show_bug.cgi?id=171775 http://trac.webkit.org/changeset/216677 2017-05-11 Don Olmstead <don.olmstead@am.sony.com> [CMake] Add HAVE check for regex.h https://bugs.webkit.org/show_bug.cgi?id=171950 Reviewed by Michael Catanzaro. * runtime/ConfigFile.cpp: (JSC::ConfigFile::parse): 2017-05-11 Filip Pizlo <fpizlo@apple.com> Callers of JSString::unsafeView() should check exceptions https://bugs.webkit.org/show_bug.cgi?id=171995 Reviewed by Mark Lam. unsafeView() can throw OOME. So, callers of unsafeView() should check for exceptions before trying to access the view. Also, I made the functions surrounding unsafeView() take ExecState* not ExecState&, to comply with the rest of JSC. * dfg/DFGOperations.cpp: * jsc.cpp: (printInternal): (functionDebug): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncJoin): * runtime/FunctionConstructor.cpp: (JSC::constructFunctionSkippingEvalEnabledCheck): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorFuncCompare): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncJoin): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncParseFloat): * runtime/JSONObject.cpp: (JSC::JSONProtoFuncParse): * runtime/JSString.cpp: (JSC::JSString::getPrimitiveNumber): (JSC::JSString::toNumber): * runtime/JSString.h: (JSC::JSString::getIndex): (JSC::JSRopeString::unsafeView): (JSC::JSRopeString::viewWithUnderlyingString): (JSC::JSString::unsafeView): (JSC::JSString::viewWithUnderlyingString): * runtime/JSStringJoiner.h: (JSC::JSStringJoiner::appendWithoutSideEffects): (JSC::JSStringJoiner::append): * runtime/ParseInt.h: (JSC::toStringView): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncRepeatCharacter): (JSC::stringProtoFuncCharAt): (JSC::stringProtoFuncCharCodeAt): (JSC::stringProtoFuncIndexOf): (JSC::stringProtoFuncNormalize): 2017-05-11 Filip Pizlo <fpizlo@apple.com> Offer SPI to notify clients that GC has happened https://bugs.webkit.org/show_bug.cgi?id=171980 Reviewed by Geoffrey Garen. Sometimes when you're programming with weak references, it's most convenient if the GC tells you when it finishes. This adds exactly such an API. This API is called at the *flip*: the moment when the GC knows for sure which objects are dead and has definitely not allocated any new objects or executed any JS code. The finalization part of the flip, which is where this callback gets called, runs on the "main" thread - i.e. some thread that is attempting to execute JS code and holds the JS lock. This will usually run as a side-effect of some allocation or from the runloop. This means, for example, that if you implemented a vector of weak references and registered a callback to prune the vector of null weak references, then aside from the callback, nobody would ever see a null weak reference in the vector. * API/JSHeapFinalizerPrivate.cpp: Added. (JSContextGroupAddHeapFinalizer): (JSContextGroupRemoveHeapFinalizer): * API/JSHeapFinalizerPrivate.h: Added. * API/tests/testapi.c: (heapFinalizer): (testMarkingConstraintsAndHeapFinalizers): (main): (testMarkingConstraints): Deleted. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::finalize): (JSC::Heap::addHeapFinalizerCallback): (JSC::Heap::removeHeapFinalizerCallback): * heap/Heap.h: * heap/HeapFinalizerCallback.cpp: Added. (JSC::HeapFinalizerCallback::dump): * heap/HeapFinalizerCallback.h: Added. (JSC::HeapFinalizerCallback::HeapFinalizerCallback): (JSC::HeapFinalizerCallback::operator==): (JSC::HeapFinalizerCallback::operator!=): (JSC::HeapFinalizerCallback::operator bool): (JSC::HeapFinalizerCallback::run): 2017-05-11 Filip Pizlo <fpizlo@apple.com> JSWeakCreate/Retain/Release should take a JSContextGroupRef and not a JSContextRef https://bugs.webkit.org/show_bug.cgi?id=171979 Reviewed by Mark Lam. Functions that don't execute arbitrary JS but just need access to the VM should take a JSContextGroupRef, not a JSContextRef. * API/JSWeakPrivate.cpp: (JSWeakCreate): (JSWeakRetain): (JSWeakRelease): * API/JSWeakPrivate.h: * API/tests/testapi.c: (testMarkingConstraints): 2017-05-11 Mark Lam <mark.lam@apple.com> WorkerThread::stop() should call scheduleExecutionTermination() last. https://bugs.webkit.org/show_bug.cgi?id=171775 <rdar://problem/30975761> Reviewed by Geoffrey Garen. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-11 JF Bastien <jfbastien@apple.com> WebAssembly: stop supporting 0xD https://bugs.webkit.org/show_bug.cgi?id=168788 <rdar://problem/31880922> Reviewed by Saam Barati. Only version 1 is supported by other browsers, and there shouldn't be any 0xD binaries in the wild anymore. * wasm/WasmModuleParser.cpp: 2017-05-09 Sam Weinig <sam@webkit.org> Remove support for legacy Notifications https://bugs.webkit.org/show_bug.cgi?id=171487 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: Remove definition of ENABLE_LEGACY_NOTIFICATIONS. 2017-05-10 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r216635. https://bugs.webkit.org/show_bug.cgi?id=171953 "Some worker tests are failing". (Requested by mlam on #webkit). Reverted changeset: "WorkerThread::stop() should call scheduleExecutionTermination() last." https://bugs.webkit.org/show_bug.cgi?id=171775 http://trac.webkit.org/changeset/216635 2017-05-10 Mark Lam <mark.lam@apple.com> Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer). https://bugs.webkit.org/show_bug.cgi?id=160337 <rdar://problem/27611733> Not reviewed. Updated a comment per Geoff's suggestion. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::tryCopyOtherThreadStack): 2017-05-10 Mark Lam <mark.lam@apple.com> WorkerThread::stop() should call scheduleExecutionTermination() last. https://bugs.webkit.org/show_bug.cgi?id=171775 <rdar://problem/30975761> Reviewed by Geoffrey Garen. Increased the number of frames captured in VM::nativeStackTraceOfLastThrow() from 25 to 100. From experience, I found that 25 is sometimes not sufficient for our debugging needs. Also added VM::throwingThread() to track which thread an exception was thrown in. This may be useful if the client is entering the VM from different threads. * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): (JSC::ExceptionScope::releaseAssertIsTerminatedExecutionException): * runtime/ExceptionScope.h: (JSC::ExceptionScope::exception): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::throwingThread): (JSC::VM::clearException): 2017-05-10 Mark Lam <mark.lam@apple.com> Crash in JavaScriptCore GC when using JSC on dispatch queues (thread_get_state returns NULL stack pointer). https://bugs.webkit.org/show_bug.cgi?id=160337 <rdar://problem/27611733> Reviewed by Filip Pizlo and Geoffrey Garen. This is a workaround for <rdar://problem/27607384>. During thread initialization, for some target platforms, thread state is momentarily set to 0 before being filled in with the target thread's real register values. As a result, there's a race condition that may result in us getting a null stackPointer during a GC scan. This issue may manifest with workqueue threads where the OS may choose to recycle a thread for an expired task. The workaround is simply to indicate that there's nothing to copy and return. This is correct because we will only ever observe a null pointer during thread initialization. Hence, by definition, there's nothing there that we need to scan yet, and therefore, nothing that needs to be copied. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::tryCopyOtherThreadStack): 2017-05-10 JF Bastien <jfbastien@apple.com> WebAssembly: support name section https://bugs.webkit.org/show_bug.cgi?id=171263 Reviewed by Keith Miller. The name section is an optional custom section in the WebAssembly spec. At least when debugging, developers expect to be able to use this section to obtain intelligible stack traces, otherwise we just number the wasm functions which is somewhat painful. This patch parses this section, dropping its content eagerly on error, and if there is a name section then backtraces use their value instead of numbers. Otherwise we stick to numbers as before. Note that the format of name sections changed in mid-February: https://github.com/WebAssembly/design/pull/984 And binaryen was only updated in early March: https://github.com/WebAssembly/binaryen/pull/933 * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::Frame::functionName): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::wasmFunctionIndexOrName): * runtime/StackFrame.cpp: (JSC::StackFrame::functionName): * runtime/StackFrame.h: (JSC::StackFrame::StackFrame): (JSC::StackFrame::wasm): * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCallee.cpp: (JSC::Wasm::Callee::Callee): * wasm/WasmCallee.h: (JSC::Wasm::Callee::create): (JSC::Wasm::Callee::indexOrName): * wasm/WasmFormat.cpp: (JSC::Wasm::makeString): * wasm/WasmFormat.h: (JSC::Wasm::isValidExternalKind): (JSC::Wasm::isValidNameType): (JSC::Wasm::NameSection::get): * wasm/WasmIndexOrName.cpp: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp. (JSC::Wasm::IndexOrName::IndexOrName): (JSC::Wasm::makeString): * wasm/WasmIndexOrName.h: Copied from Source/JavaScriptCore/wasm/WasmFormat.cpp. * wasm/WasmModuleInformation.h: * wasm/WasmModuleParser.cpp: * wasm/WasmName.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp. * wasm/WasmNameSectionParser.cpp: Added. * wasm/WasmNameSectionParser.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.cpp. (JSC::Wasm::NameSectionParser::NameSectionParser): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmParser.h: (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): 2017-05-10 Filip Pizlo <fpizlo@apple.com> Null pointer dereference in WTF::RefPtr<WTF::StringImpl>::operator!() under slow_path_get_direct_pname https://bugs.webkit.org/show_bug.cgi?id=171801 Reviewed by Michael Saboff. This was a goofy oversight. The for-in optimization relies on the bytecode generator to detect when the loop's index variable gets mutated. We forgot to have the hooks for detecting this in prefix and postfix operations (++i and i++). * bytecompiler/NodesCodegen.cpp: (JSC::PostfixNode::emitResolve): (JSC::PrefixNode::emitResolve): 2017-05-10 Michael Catanzaro <mcatanzaro@igalia.com> [GTK] -Wmissing-field-initializers triggered by RemoteInspectorServer.cpp:128 https://bugs.webkit.org/show_bug.cgi?id=171273 Reviewed by Carlos Garcia Campos. * inspector/remote/glib/RemoteInspectorGlib.cpp: * inspector/remote/glib/RemoteInspectorServer.cpp: 2017-05-10 Adrian Perez de Castro <aperez@igalia.com> Remove some last remnants of the EFL port https://bugs.webkit.org/show_bug.cgi?id=171922 Reviewed by Antonio Gomes. The EFL port is no more. * PlatformEfl.cmake: Removed. * shell/PlatformEfl.cmake: Removed. 2017-05-09 Filip Pizlo <fpizlo@apple.com> JSInjectedScriptHost should get a copy of the boundArgs https://bugs.webkit.org/show_bug.cgi?id=171897 Reviewed by Joseph Pecoraro. The boundArgs array is very special - it cannot be mutated in any way. So, it makes sense for the inspector to get a copy of it. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::getInternalProperties): * runtime/JSBoundFunction.cpp: (JSC::JSBoundFunction::boundArgsCopy): * runtime/JSBoundFunction.h: (JSC::JSBoundFunction::boundArgs): 2017-05-09 Mark Lam <mark.lam@apple.com> Unindent some code in Watchdog::shouldTerminate(). https://bugs.webkit.org/show_bug.cgi?id=171896 Rubber stamped by Keith Miller. I should have done this before I landed r213107, but I forgot. Unindenting it now. * runtime/Watchdog.cpp: (JSC::Watchdog::shouldTerminate): 2017-05-09 Michael Saboff <msaboff@apple.com> Cap the number of FTL compilation threads on iOS to 2 https://bugs.webkit.org/show_bug.cgi?id=171887 Reviewed by Filip Pizlo. Set an iOS specific max of 2 threads. * runtime/Options.h: 2017-05-09 Filip Pizlo <fpizlo@apple.com> Heap::heap() should behave gracefully for null pointers https://bugs.webkit.org/show_bug.cgi?id=171888 <rdar://problem/32005315> Reviewed by Mark Lam. Some callers of Heap::heap() can pass a null cell and they will behave gracefully if we return a null Heap. So, let's do that. This fixes a crash and it does not hurt performance. I'm seeing a possible 0.5% regression with 74% probability. That's a neutral result by our usual 95% standard. * heap/HeapInlines.h: (JSC::Heap::heap): 2017-05-09 Yusuke Suzuki <utatane.tea@gmail.com> Handle IDLPromise<> properly https://bugs.webkit.org/show_bug.cgi?id=166752 Reviewed by Youenn Fablet. Add JSPromise::resolve static function. This applies `Promise.resolve()` conversion to a given value. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseResolveFunction): * runtime/JSPromise.cpp: (JSC::JSPromise::resolve): * runtime/JSPromise.h: 2017-05-09 Zan Dobersek <zdobersek@igalia.com> Upstream the WPE port https://bugs.webkit.org/show_bug.cgi?id=171110 Reviewed by Alex Christensen. * PlatformWPE.cmake: Added. * shell/PlatformWPE.cmake: Added. 2017-05-09 Saam Barati <sbarati@apple.com> CallLinkInfos belonging to Wasm->JS stubs need to be informed when we clearCode() from all Executables https://bugs.webkit.org/show_bug.cgi?id=171707 <rdar://problem/31891649> Reviewed by Filip Pizlo. This patch fixes a bug where a Wasm->JS IC call stub would go stale and point into a CodeBlock no longer owned by any executable. The problematic scenario is this: 1. We generate the call IC which has a branch on a callee check. This callee owns the Executable in question. If the branch succeeds, it will call code belonging to a particular CodeBlock associated with that Executable. 2. Heap::deleteAllCodeBlocks is called. This leads the Executable to clear its various CodeBlock references. 3. Wasm has no idea this happened, so now it has stale ICs that point into code from a CodeBlock no longer belonging to an Executable. This patch fixes the bug by informing all JSWebAssemblyCodeBlocks to unlink their CallLinkInfo when Heap::deleteAllCodeBlocks is called. We track all JSWebAssemblyCodeBlocks by creating a new subspace for them. This allows us to quickly iterate over the live JSWebAssemblyCodeBlocks in the heap. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/Heap.cpp: (JSC::Heap::deleteAllCodeBlocks): * heap/Subspace.h: * heap/SubspaceInlines.h: (JSC::Subspace::forEachLiveCell): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::clearJSCallICs): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::createStructure): Deleted. (JSC::JSWebAssemblyCodeBlock::functionImportCount): Deleted. (JSC::JSWebAssemblyCodeBlock::module): Deleted. (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted. (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): Deleted. (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): Deleted. (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): Deleted. (JSC::JSWebAssemblyCodeBlock::codeBlock): Deleted. (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): Deleted. (JSC::JSWebAssemblyCodeBlock::allocationSize): Deleted. (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): Deleted. * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp: Added. (JSC::JSWebAssemblyCodeBlockSubspace::JSWebAssemblyCodeBlockSubspace): (JSC::JSWebAssemblyCodeBlockSubspace::~JSWebAssemblyCodeBlockSubspace): (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep): (JSC::JSWebAssemblyCodeBlockSubspace::destroy): * wasm/js/JSWebAssemblyCodeBlockSubspace.h: Added. 2017-05-08 Saam Barati <sbarati@apple.com> testWasmBoundsCheck and testCallFunctionWithHellaArguments is broken in testb3 https://bugs.webkit.org/show_bug.cgi?id=171392 <rdar://problem/31872222> Reviewed by Keith Miller. This patch fixes two bugs. The first one is: Inside testb3, we were using the wrong WasmBoundsCheckValue constructor. Everything compiled OK because of implicit casting in C. I've changed one of the constructors to take arguments in a different order so we don't run into this problem again. The second bug was that Air::ShufflePair::inst was assuming that a move from BigImm to its destination is always valid. This is not the case. For example, the store, `Move BigImm, Addr` is not allowed. I refactored the code to be correct by emitting more than one instruction when needeed. When testing my changes, I ran ARM64 testb3 both in debug and release. I ran into many pre-existing failures. I've opened a new bug to fix those here: https://bugs.webkit.org/show_bug.cgi?id=171826 * b3/B3WasmBoundsCheckValue.cpp: (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue): * b3/B3WasmBoundsCheckValue.h: * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::insts): (JSC::B3::Air::ShufflePair::inst): Deleted. * b3/air/AirEmitShuffle.h: * b3/air/AirLowerMacros.cpp: (JSC::B3::Air::lowerMacros): * b3/testb3.cpp: (JSC::B3::testLoadAcq42): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testStoreRelAddLoadAcq8): (JSC::B3::testStoreRelAddFenceLoadAcq8): (JSC::B3::testStoreRelAddLoadAcq16): (JSC::B3::testStoreRelAddLoadAcq64): (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs): (JSC::B3::testCheckMul): (JSC::B3::testCheckMulMemory): (JSC::B3::testCheckMul64): (JSC::B3::testCheckMulFold): (JSC::B3::testCheckMulFoldFail): (JSC::B3::testCheckMulArgumentAliasing64): (JSC::B3::testCheckMulArgumentAliasing32): (JSC::B3::testCheckMul64SShr): (JSC::B3::testCallFunctionWithHellaArguments): (JSC::B3::functionWithHellaArguments2): (JSC::B3::testCallFunctionWithHellaArguments2): (JSC::B3::functionWithHellaArguments3): (JSC::B3::testCallFunctionWithHellaArguments3): (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testLateRegister): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2): (JSC::B3::testMoveConstants): (JSC::B3::testAtomicWeakCAS): (JSC::B3::testAtomicStrongCAS): (JSC::B3::testAtomicXchg): (JSC::B3::testWasmBoundsCheck): (JSC::B3::run): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): 2017-05-08 Filip Pizlo <fpizlo@apple.com> Expose a function to get proxy targets https://bugs.webkit.org/show_bug.cgi?id=171797 <rdar://problem/32027549> Reviewed by Mark Lam. This exposes a new private API function, JSObjectGetProxyTarget(), that gets the target of a proxy. It works with both ProxyObject and JSProxy, but it's primarily intended for use with JSProxy. * API/JSObjectRef.cpp: (JSObjectGetProxyTarget): * API/JSObjectRefPrivate.h: * API/tests/JSObjectGetProxyTargetTest.cpp: Added. (testJSObjectGetProxyTarget): * API/tests/JSObjectGetProxyTargetTest.h: Added. * API/tests/testapi.c: (main): * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/ProxyObject.h: * shell/PlatformWin.cmake: 2017-05-08 Mark Lam <mark.lam@apple.com> op_throw_static_error's use of its first operand should be reflected in DFG BytecodeUseDef as well. https://bugs.webkit.org/show_bug.cgi?id=171786 <rdar://problem/32051023> Reviewed by Saam Barati. * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::dumpBytecode): - Fix BytecodeDumper to dump op_throw_static_error correctly. Previously, it was expecting op1 to always be a constant. r206870 changed it to take a variable string as well. * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): - Fix the bug. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::parseBlock): - Move the Phantom of op1 after the ThrowStaticError node, because technically, the ThrowStaticError represents op_throw_static_error, and op_throw_static_error uses op1. In practice, this probably doesn't matter, but let's have the code accurately communicate the behavior we're expecting. 2017-05-08 JF Bastien <jfbastien@apple.com> WebAssembly: don't just emit extended offset adds for patch https://bugs.webkit.org/show_bug.cgi?id=171799 Reviewed by Mark Lam. It isn't necessary to restrict. * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): 2017-05-08 Mark Lam <mark.lam@apple.com> Introduce ExceptionScope::assertNoException() and releaseAssertNoException(). https://bugs.webkit.org/show_bug.cgi?id=171776 Reviewed by Keith Miller. Instead of ASSERT(!scope.exception()), we can now do scope.assertNoException(). Ditto for RELEASE_ASSERT and scope.releaseAssertNoException(). The advantage of using ExceptionScope::assertNoException() and releaseAssertNoException() is that if the assertion fails, these utility functions will print the stack trace for where the unexpected exception is detected as well as where the unexpected exception was thrown from. This makes it much easier to debug the source of unhandled exceptions. * debugger/Debugger.cpp: (JSC::Debugger::pauseIfNeeded): * dfg/DFGOperations.cpp: * interpreter/Interpreter.cpp: (JSC::eval): (JSC::notifyDebuggerOfUnwinding): (JSC::Interpreter::executeProgram): (JSC::Interpreter::executeCall): (JSC::Interpreter::executeConstruct): (JSC::Interpreter::prepareForRepeatCall): (JSC::Interpreter::execute): (JSC::Interpreter::debug): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::functionsOnStack): * jsc.cpp: (GlobalObject::moduleLoaderResolve): (GlobalObject::moduleLoaderFetch): (functionGenerateHeapSnapshot): (functionSamplingProfilerStackTraces): (box): (runWithScripts): * runtime/AbstractModuleRecord.cpp: (JSC::AbstractModuleRecord::finishCreation): * runtime/ArrayPrototype.cpp: (JSC::ArrayPrototype::tryInitializeSpeciesWatchpoint): * runtime/Completion.cpp: (JSC::rejectPromise): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::sanitizedToString): * runtime/ExceptionHelpers.cpp: (JSC::createError): * runtime/ExceptionScope.cpp: (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/ExceptionScope.h: (JSC::ExceptionScope::assertNoException): (JSC::ExceptionScope::releaseAssertNoException): (JSC::ExceptionScope::unexpectedExceptionMessage): * runtime/GenericArgumentsInlines.h: (JSC::GenericArguments<Type>::defineOwnProperty): * runtime/IntlCollator.cpp: (JSC::IntlCollator::createCollator): (JSC::IntlCollator::resolvedOptions): * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::resolvedOptions): (JSC::IntlDateTimeFormat::format): * runtime/IntlNumberFormat.cpp: (JSC::IntlNumberFormat::createNumberFormat): (JSC::IntlNumberFormat::resolvedOptions): * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitiveByIndex): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::genericTypedArrayViewProtoFuncIncludes): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncHostPromiseRejectionTracker): * runtime/JSModuleEnvironment.cpp: (JSC::JSModuleEnvironment::getOwnPropertySlot): * runtime/JSModuleLoader.cpp: (JSC::JSModuleLoader::finishCreation): * runtime/JSModuleNamespaceObject.cpp: (JSC::JSModuleNamespaceObject::finishCreation): * runtime/JSONObject.cpp: (JSC::Stringifier::toJSON): * runtime/JSObject.cpp: (JSC::JSObject::ordinaryToPrimitive): * runtime/JSPropertyNameEnumerator.h: (JSC::propertyNameEnumerator): * runtime/ObjectConstructor.cpp: (JSC::objectConstructorGetOwnPropertyDescriptors): (JSC::objectConstructorDefineProperty): * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncHasOwnProperty): * runtime/ProgramExecutable.cpp: (JSC::ProgramExecutable::initializeGlobalProperties): * runtime/ReflectObject.cpp: (JSC::reflectObjectDefineProperty): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::nameFromCallee): * runtime/StringPrototype.cpp: (JSC::stringProtoFuncRepeatCharacter): * runtime/TemplateRegistry.cpp: (JSC::TemplateRegistry::getTemplateObject): * runtime/VM.cpp: (JSC::VM::throwException): * runtime/VM.h: (JSC::VM::nativeStackTraceOfLastThrow): (JSC::VM::clearException): * wasm/WasmB3IRGenerator.cpp: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::create): 2017-05-06 Bill Ming <mbbill@gmail.com> Fix 32bit Windows build by giving correct parameters to MASM https://bugs.webkit.org/show_bug.cgi?id=170833 Reviewed by Alex Christensen. * CMakeLists.txt: 2017-05-06 Oleksandr Skachkov <gskachkov@gmail.com> [ES6] Arrow function. Issue in access to this after eval('super()') within constructor https://bugs.webkit.org/show_bug.cgi?id=171543 Reviewed by Saam Barati. Current patch force to use 'this' within arrow function or eval from virtual scope each time, instead of using thisRegister. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::ensureThis): 2017-05-05 Keith Miller <keith_miller@apple.com> Put does not properly consult the prototype chain https://bugs.webkit.org/show_bug.cgi?id=171754 Reviewed by Saam Barati. We should do a follow up that cleans up the rest of put. See: https://bugs.webkit.org/show_bug.cgi?id=171759 * runtime/JSCJSValue.cpp: (JSC::JSValue::putToPrimitive): * runtime/JSObject.cpp: (JSC::JSObject::putInlineSlow): * runtime/JSObjectInlines.h: (JSC::JSObject::canPerformFastPutInline): 2017-05-05 JF Bastien <jfbastien@apple.com> WebAssembly: Air::Inst::generate crashes on large binary on A64 https://bugs.webkit.org/show_bug.cgi?id=170215 Reviewed by Filip Pizlo. ARM can't encode all offsets in a single instruction. We usualy handle this type of detail early, or the macro assembler uses a scratch register to take care of the large immediate. After register allocation we assumed that we would never get large offsets, and asserted this was the case. That was a fine assumption with JavaScript, but WebAssembly ends up generating stack frames which are too big to encode. There are two places that needed to be fixed: 1. AirGenerate 2. AirLowerStackArgs We now unconditionally pin the dataTempRegister on ARM64, and use it when immediates don't fit. Number 1. is easy: we're just incrementing SP, make sure we can use a scratch register when that happens. Number 2. is more complex: not all Inst can receive a stack argument whose base register isn't SP or FP. Specifically, Patchpoints and Stackmaps get very sad because they just want to know the offset value, but when we materialize the offset as follows: Move (spill337), (spill201), %r0, @8735 Becomes (where %r16 is dataTempRegister): Move $1404, %r16, @8736 Add64 %sp, %r16, @8736 Move (%r16), 2032(%sp), %r0, @8736 The code currently doesn't see through our little dance. To work around this issue we introduce a new Air Arg kind: ExtendedOffsetAddr. This is the same as a regular Addr, but with an offset which may be too big to encode. Opcodes then declare whether their arguments can handle such inputs, and if so we generate them, otherwise we generate Addr as shown above. None of this affects x86 because it can always encode large immediates. This patch also drive-by converts some uses of `override` to `final`. It makes the code easier to grok, and maybe helps the optimizer sometimes but really that doens't matter. * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM64.h: * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::admitsExtendedOffsetAddr): * b3/B3CheckSpecial.h: * b3/B3Common.cpp: (JSC::B3::pinnedExtendedOffsetAddrRegister): keep the CPU-specific pinning information in a cpp file * b3/B3Common.h: * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::admitsExtendedOffsetAddr): * b3/B3PatchpointSpecial.h: * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::isArgValidForRep): (JSC::B3::StackmapSpecial::repForArg): * b3/B3StackmapSpecial.h: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::isStackMemory): (JSC::B3::Air::Arg::jsHash): (JSC::B3::Air::Arg::dump): (WTF::printInternal): (JSC::B3::Air::Arg::stackAddrImpl): Deleted. There was only one use of this (in AirLowerStackArgs) and it was now confusing to split the logic up between these two. Inline the code that used to be here into its one usepoint instead. * b3/air/AirArg.h: (JSC::B3::Air::Arg::extendedOffsetAddr): (JSC::B3::Air::Arg::isExtendedOffsetAddr): (JSC::B3::Air::Arg::isMemory): (JSC::B3::Air::Arg::base): (JSC::B3::Air::Arg::offset): (JSC::B3::Air::Arg::isGP): (JSC::B3::Air::Arg::isFP): (JSC::B3::Air::Arg::isValidForm): (JSC::B3::Air::Arg::forEachTmpFast): (JSC::B3::Air::Arg::forEachTmp): (JSC::B3::Air::Arg::asAddress): (JSC::B3::Air::Arg::stackAddr): Deleted. * b3/air/AirCCallSpecial.cpp: (JSC::B3::Air::CCallSpecial::isValid): (JSC::B3::Air::CCallSpecial::admitsExtendedOffsetAddr): (JSC::B3::Air::CCallSpecial::generate): * b3/air/AirCCallSpecial.h: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): (JSC::B3::Air::Code::pinRegister): Check that the register wasn't pinned before pinning it. It's likely a bug to pin the same register twice. * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::CCallCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::ShuffleCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::EntrySwitchCustom::admitsExtendedOffsetAddr): (JSC::B3::Air::WasmBoundsCheckCustom::admitsExtendedOffsetAddr): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * b3/air/AirInst.h: * b3/air/AirInstInlines.h: (JSC::B3::Air::Inst::admitsExtendedOffsetAddr): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * b3/air/AirPrintSpecial.cpp: (JSC::B3::Air::PrintSpecial::admitsExtendedOffsetAddr): (JSC::B3::Air::PrintSpecial::generate): * b3/air/AirPrintSpecial.h: * b3/air/AirSpecial.h: * b3/air/opcode_generator.rb: 2017-05-05 Oliver Hunt <oliver@apple.com> Move trivial String prototype functions to JS builtins https://bugs.webkit.org/show_bug.cgi?id=171737 Reviewed by Saam Barati. Super simple change to migrate all of the old school html-ifying string operations to builtin JS. Core implementation is basically a 1-for-1 match to the spec. * builtins/StringPrototype.js: (globalPrivate.createHTML): (anchor): (big): (blink): (bold): (fixed): (fontcolor): (fontsize): (italics): (link): (small): (strike): (sub): (sup): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): (JSC::stringProtoFuncBig): Deleted. (JSC::stringProtoFuncSmall): Deleted. (JSC::stringProtoFuncBlink): Deleted. (JSC::stringProtoFuncBold): Deleted. (JSC::stringProtoFuncFixed): Deleted. (JSC::stringProtoFuncItalics): Deleted. (JSC::stringProtoFuncStrike): Deleted. (JSC::stringProtoFuncSub): Deleted. (JSC::stringProtoFuncSup): Deleted. (JSC::stringProtoFuncFontcolor): Deleted. (JSC::stringProtoFuncFontsize): Deleted. (JSC::stringProtoFuncAnchor): Deleted. (JSC::stringProtoFuncLink): Deleted. 2017-05-05 Don Olmstead <don.olmstead@am.sony.com> [JSC] Remove export from Intrinsic https://bugs.webkit.org/show_bug.cgi?id=171752 Reviewed by Alexey Proskuryakov. * runtime/Intrinsic.h: 2017-05-05 Saam Barati <sbarati@apple.com> putDirectIndex does not properly do defineOwnProperty https://bugs.webkit.org/show_bug.cgi?id=171591 <rdar://problem/31735695> Reviewed by Geoffrey Garen. This patch fixes putDirectIndex and its JIT implementations to be compatible with the ES6 spec. I think our code became out of date when we implemented ArraySpeciesCreate since ArraySpeciesCreate may return arbitrary objects. We perform putDirectIndex on that arbitrary object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}). However, we weren't doing this. putDirectIndex assumed it could just splat data into any descendent of JSObject's butterfly. For example, this means we'd just splat into the butterfly of a typed array, even though a typed array doesn't use its butterfly to store its indexed properties in the usual way. Also, typed array properties are non-configurable, so this operation should throw. This also means if we saw a ProxyObject, we'd just splat into its butterfly, but this is obviously wrong because ProxyObject should intercept the defineProperty operation. This patch fixes this issue by adding a whitelist of cell types that can go down putDirectIndex's fast path. Anything not in that whitelist will simply call into defineOwnProperty. * bytecode/ByValInfo.h: (JSC::jitArrayModePermitsPutDirect): * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * jit/JITOperations.cpp: * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createStructure): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty): * runtime/JSObject.cpp: (JSC::canDoFastPutDirectIndex): (JSC::JSObject::defineOwnIndexedProperty): (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength): (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted. * runtime/JSObject.h: (JSC::JSObject::putDirectIndex): (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted. * runtime/JSType.h: 2017-05-05 Guillaume Emont <guijemont@igalia.com> [JSC] include JSCInlines.h in ObjectInitializationScope.cpp https://bugs.webkit.org/show_bug.cgi?id=171744 Reviewed by Mark Lam. * runtime/ObjectInitializationScope.cpp: 2017-05-05 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Assertion failure in Inspector::RemoteInspector::setRemoteInspectorClient when disposing WebKitWebContext https://bugs.webkit.org/show_bug.cgi?id=171644 Reviewed by Michael Catanzaro. Fix ASSERT that requires given client to be a valid pointer, since it's valid to pass nullptr to unset the client. The ASSERT now ensures that client is set or unset. I also renamed the function to setClient because setRemoteInspectorClient is redundant for a class named RemoteInspector. And added a getter too, to check if the remote inspector has a client. * inspector/remote/RemoteInspector.cpp: (Inspector::RemoteInspector::setClient): * inspector/remote/RemoteInspector.h: 2017-05-04 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r216206. https://bugs.webkit.org/show_bug.cgi?id=171714 Multiple LayoutTests crashing in Document::page() (Requested by ap on #webkit). Reverted changeset: "Remove support for legacy Notifications" https://bugs.webkit.org/show_bug.cgi?id=171487 http://trac.webkit.org/changeset/216206 2017-05-04 Don Olmstead <don.olmstead@am.sony.com> [Win] Remove redundant macros that are set in the CMake config https://bugs.webkit.org/show_bug.cgi?id=171571 Reviewed by Brent Fulgham. * config.h: 2017-05-04 Mark Lam <mark.lam@apple.com> Gardening: Build fix for Windows after r216217. https://bugs.webkit.org/show_bug.cgi?id=171586 Not reviewed. * shell/PlatformWin.cmake: 2017-05-04 Filip Pizlo <fpizlo@apple.com> JSC::Heap should expose a richer API for requesting GCs https://bugs.webkit.org/show_bug.cgi?id=171690 Reviewed by Geoffrey Garen. I want to stop WebCore from requesting synchronous GCs. But various parts of that work may cause regressions, so I'd like to land it separately from the functionality that is needed on the JSC side. This change is mostly a JSC-side refactoring that does not change behavior. In the future I'll land the behavior changes (i.e. not requesting sync GCs). This change allows you to enumerate over synchronousness, so that we can make all APIs take synchronousness as an argument. It replaces the collectAllGarbage API with a collectNow(Synchronousness, GCRequest) API. GCRequest is a new concept, which subsumes std::optional<CollectionScope> and gives us the ability to register callbacks along with a GC. So, you can ask for an async GC and get a callback when it's done. Also adds ability to request that fastMalloc memory be released after the incremental sweeper finishes. * API/JSBase.cpp: (JSSynchronousGarbageCollectForDebugging): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/FullGCActivityCallback.cpp: (JSC::FullGCActivityCallback::doCollection): * heap/FullGCActivityCallback.h: * heap/GCRequest.cpp: Added. (JSC::GCRequest::subsumedBy): (JSC::GCRequest::dump): * heap/GCRequest.h: Added. (JSC::GCRequest::GCRequest): * heap/Heap.cpp: (JSC::Heap::collect): (JSC::Heap::collectNow): (JSC::Heap::collectAsync): (JSC::Heap::collectSync): (JSC::Heap::runBeginPhase): (JSC::Heap::runEndPhase): (JSC::Heap::requestCollection): (JSC::Heap::willStartCollection): (JSC::Heap::sweeper): (JSC::Heap::collectNowFullIfNotDoneRecently): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectAllGarbage): Deleted. (JSC::Heap::collectAllGarbageIfNotDoneRecently): Deleted. * heap/Heap.h: * heap/HeapSnapshotBuilder.cpp: (JSC::HeapSnapshotBuilder::buildSnapshot): * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doSweep): * heap/IncrementalSweeper.h: (JSC::IncrementalSweeper::freeFastMallocMemoryAfterSweeping): * heap/MarkedAllocator.cpp: (JSC::MarkedAllocator::doTestCollectionsIfNeeded): * heap/MarkedSpace.cpp: (JSC::MarkedSpace::sweep): * heap/Synchronousness.cpp: Added. (WTF::printInternal): * heap/Synchronousness.h: Added. * inspector/agents/InspectorHeapAgent.cpp: (Inspector::InspectorHeapAgent::gc): * jsc.cpp: (functionGCAndSweep): (runJSC): * tools/JSDollarVMPrototype.cpp: (JSC::JSDollarVMPrototype::gc): * wasm/WasmMemory.cpp: 2017-05-04 Mark Lam <mark.lam@apple.com> NeverDestroyed<String>(ASCIILiteral(...)) is not thread safe. https://bugs.webkit.org/show_bug.cgi?id=171586 <rdar://problem/31873190> Reviewed by Yusuke Suzuki. JavaScriptCore allows multiple VMs to be instantiated, and each of these should be able to run concurrently on different threads. There is code in the VM that allocates NeverDestroyed<String>(ASCIILiteral(...)) to defined immortal strings meant to be shared by all VMs. However, NeverDestroyed<String>(ASCIILiteral(...)) is not thread-safe because each thread will ref and deref the underlying StringImpl. Since this ref and deref is not done in a thread-safe way, the NeverDestroyed<String> may get destroyed due to the ref/deref races. Additionally, each thread may modify the StringImpl by setting its hash and also twiddling its flags. The fix is to use the StaticStringImpl class which is safe for ref/derefing concurrently from different threads. StaticStringImpl is also pre-set with a hash on construction, and its flags are set in such a way as to prevent twiddling at runtime. Hence, we will be able to share a NeverDestroyed<String> between VMs, as long as it is backed by a StaticStringImpl. An alternative solution would be to change all the uses of NeverDestroyed<String> to use per-VM strings. However, this solution is cumbersome, and makes it harder to allocate the intended shared string. It also uses more memory and takes more CPU time because it requires allocating the same string for each VM instance. The StaticStringImpl solution wins out because it is more efficient and is easier to use. The StaticStringImpl solution also can be used in WTF without a layer violation. See Source/WTF/wtf/text/icu/TextBreakIteratorICU.h for an example. Also added the MultithreadedMultiVMExecutionTest which runs multiple VMs in multiple threads, all banging on the BuiltinExecutable's baseConstructorCode NeverDestroyed<String>. The test will manifest the issue reliably (before this fix) if run on an ASAN build. * API/tests/MultithreadedMultiVMExecutionTest.cpp: Added. (threadsList): (startMultithreadedMultiVMExecutionTest): (finalizeMultithreadedMultiVMExecutionTest): * API/tests/MultithreadedMultiVMExecutionTest.h: Added. * API/tests/testapi.c: (main): * JavaScriptCore.xcodeproj/project.pbxproj: * builtins/BuiltinExecutables.cpp: (JSC::BuiltinExecutables::createDefaultConstructor): * inspector/agents/InspectorDebuggerAgent.cpp: (Inspector::objectGroupForBreakpointAction): * replay/scripts/CodeGeneratorReplayInputsTemplates.py: * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::SavedMouseButton>::type): * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::SavedMouseButton>::type): * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::HandleWheelEvent>::type): * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::FormCombo>::type): * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::GetCurrentTime>::type): (JSC::InputTraits<Test::SetRandomSeed>::type): * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::ArrayOfThings>::type): (JSC::InputTraits<Test::SavedHistory>::type): * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::ScalarInput1>::type): (JSC::InputTraits<Test::ScalarInput2>::type): * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp: (JSC::InputTraits<Test::ScalarInput>::type): (JSC::InputTraits<Test::MapInput>::type): * runtime/IntlObject.cpp: (JSC::numberingSystemsForLocale): 2017-05-04 Sam Weinig <sam@webkit.org> Remove support for legacy Notifications https://bugs.webkit.org/show_bug.cgi?id=171487 Reviewed by Jon Lee. * Configurations/FeatureDefines.xcconfig: Remove definition of ENABLE_LEGACY_NOTIFICATIONS. 2017-05-04 Konstantin Tokarev <annulen@yandex.ru> Fix compilation with ICU 59.1 https://bugs.webkit.org/show_bug.cgi?id=171612 Reviewed by Mark Lam. ICU 59.1 has broken source compatibility. Now it defines UChar as char16_t, which does not allow automatic type conversion from unsigned short in C++ code. * API/JSStringRef.cpp: (JSStringCreateWithCharacters): (JSStringCreateWithCharactersNoCopy): (JSStringGetCharactersPtr): * runtime/DateConversion.cpp: (JSC::formatDateTime): 2017-05-04 Saam Barati <sbarati@apple.com> stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory https://bugs.webkit.org/show_bug.cgi?id=171008 Reviewed by Yusuke Suzuki. This patch lowers the threshold for .call/.apply recursion in an attempt to emit less code and not impact perf. We're currently failing tests on x86-32 by running out of executable memory. If perf gets impacted because of this, then I'll apply a stricter change just to 32-bit platforms. However, if this doesn't negatively impact perf, it's all around better than all platforms emit less bytecode. * bytecompiler/NodesCodegen.cpp: 2017-05-04 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Math unary functions should be handled by DFG https://bugs.webkit.org/show_bug.cgi?id=171269 Reviewed by Saam Barati. ArithSin, ArithCos, and ArithLog are just calling a C runtime function. While handling them in DFG is not very effective for performance, they can drop some type checks & value conversions and mark them as pure operations. It is effective if they are involved in some complex optimization phase. Actually, ArithLog is effective in kraken. While a few of Math functions have DFG nodes, basically math functions are pure. And large part of these functions are just calling a C runtime function. This patch generalizes these nodes in DFG as ArithUnary. And we annotate many unary math functions with Intrinsics and convert them to ArithUnary in DFG. It also cleans up duplicate code in ArithSin, ArithCos, and ArithLog. If your math function has some good DFG / FTL optimization rather than calling a C runtime function, you should add a specialized DFG node, like ArithSqrt. We also create a new namespace JSC::Math. Inside it, we collect math functions. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGArithMode.cpp: (JSC::DFG::arithUnaryFunction): (JSC::DFG::arithUnaryOperation): (WTF::printInternal): * dfg/DFGArithMode.h: * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * 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): * dfg/DFGNode.h: (JSC::DFG::Node::hasArithUnaryType): (JSC::DFG::Node::arithUnaryType): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithUnary): (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted. (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted. (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted. (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted. * 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/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileArithUnary): (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted. (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted. * ftl/FTLOutput.cpp: (JSC::FTL::Output::doubleUnary): (JSC::FTL::Output::doubleSin): Deleted. (JSC::FTL::Output::doubleCos): Deleted. (JSC::FTL::Output::doubleTan): Deleted. (JSC::FTL::Output::doubleLog): Deleted. * ftl/FTLOutput.h: * runtime/Intrinsic.h: * runtime/MathCommon.cpp: (JSC::Math::log1p): * runtime/MathCommon.h: * runtime/MathObject.cpp: (JSC::MathObject::finishCreation): (JSC::mathProtoFuncACos): (JSC::mathProtoFuncASin): (JSC::mathProtoFuncATan): (JSC::mathProtoFuncCos): (JSC::mathProtoFuncExp): (JSC::mathProtoFuncLog): (JSC::mathProtoFuncSin): (JSC::mathProtoFuncTan): (JSC::mathProtoFuncACosh): (JSC::mathProtoFuncASinh): (JSC::mathProtoFuncATanh): (JSC::mathProtoFuncCbrt): (JSC::mathProtoFuncCosh): (JSC::mathProtoFuncExpm1): (JSC::mathProtoFuncLog1p): (JSC::mathProtoFuncLog10): (JSC::mathProtoFuncLog2): (JSC::mathProtoFuncSinh): (JSC::mathProtoFuncTanh): 2017-05-03 Saam Barati <sbarati@apple.com> How we build polymorphic cases is wrong when making a call from Wasm https://bugs.webkit.org/show_bug.cgi?id=171527 Reviewed by JF Bastien. This patches fixes a bug when we emit a polymorphic call IC from Wasm. We were incorrectly assuming that if we made a call *from wasm*, then the thing we are *calling to* does not have a CodeBlock. This is obviously wrong. This patch fixes the incorrect assumption. This patch also does two more things: 1. Add a new option that makes us make calls to JS using a slow path instead of using a call IC. 2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's JSWebAssemblyModule pointer. * jit/Repatch.cpp: (JSC::linkPolymorphicCall): * runtime/Options.h: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::finishCreation): * wasm/js/JSWebAssemblyCodeBlock.h: * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): 2017-05-03 Keith Miller <keith_miller@apple.com> Array.prototype.sort should also allow a null comparator https://bugs.webkit.org/show_bug.cgi?id=171621 <rdar://problem/30757933> Reviewed by Michael Saboff. It looks like sort not accepting a null comparator causes some pages to stop working. Those pages work in Chrome/Firefox so we should try to match them. * builtins/ArrayPrototype.js: (sort): 2017-05-03 Mark Lam <mark.lam@apple.com> Use the CLoop for CPU(ARM64E). https://bugs.webkit.org/show_bug.cgi?id=171620 <rdar://problem/31973027> Reviewed by Geoffrey Garen. * llint/LLIntOfflineAsmConfig.h: * tools/SigillCrashAnalyzer.cpp: (JSC::SigillCrashAnalyzer::dumpCodeBlock): 2017-05-03 Keith Miller <keith_miller@apple.com> Different behaviour with the .sort(callback) method (unlike Firefox & Chrome) https://bugs.webkit.org/show_bug.cgi?id=47825 Reviewed by Saam Barati. This patch makes our sort function match the behavior of Firefox and Chrome when the result of the comparison function is a boolean. When we first switched to using merge sort, it regressed JQuery sorting of DOM nodes by 30%. The regression was do to the fact that JQuery was using compareDocumentPosition to compare the locations of objects. Since one of the benchmarks would pass a reverse sorted list to the sort function we would end up walking the entire DOM to do comparisons. The solution to this was to merge based on comparison(right, left) rather than comparison(left, right). Although, in practice this does nothing since sort could just as easily receive an already sorted list and we're back in the same spot. The downside of sorting with comparison(right, left) is that to maintain stability when sorting, you only want to merge from right when the comparison function returns a negative value. This is where the problem with booleans comes in. Since booleans toNumber false to 0 and true to 1 both values are "equal". This patch fixes this by special casing boolean return values. * builtins/ArrayPrototype.js: (sort.merge): 2017-05-03 Andy VanWagoner <thetalecrafter@gmail.com> [INTL] Support dashed values in unicode locale extensions https://bugs.webkit.org/show_bug.cgi?id=171480 Reviewed by JF Bastien. Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it. This fixes locale extensions with values that include '-'. The following calendars work now: ethiopic-amete-alem islamic-umalqura islamic-tbla islamic-civil islamic-rgsa While updating IntlObject, the comments containing spec text were replaced with a single url at the top of each function pointing to the relevant part of ECMA-402. * runtime/IntlObject.cpp: (JSC::unicodeExtensionSubTags): Added. (JSC::resolveLocale): Updated to latest standard. 2017-05-02 Don Olmstead <don.olmstead@am.sony.com> Build fix after r216078 https://bugs.webkit.org/show_bug.cgi?id=171554 Reviewed by Saam Barati. * API/tests/testapi.c: 2017-05-02 Filip Pizlo <fpizlo@apple.com> Unreviewed, fix pedantic C compilers. * API/tests/testapi.c: (markingConstraint): (testMarkingConstraints): 2017-05-02 Filip Pizlo <fpizlo@apple.com> Unreviewed, fix cmake build. * CMakeLists.txt: 2017-05-02 Filip Pizlo <fpizlo@apple.com> JSC C API should expose GC marking constraints and weak references https://bugs.webkit.org/show_bug.cgi?id=171554 Reviewed by Geoffrey Garen. This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC what is marked and you can tell the GC to mark things. The constraint callback cannot do a whole lot, but it can query marking state and it can dereference weak references. Additionally, this exposes a very simple weak reference API in C. * API/JSMarkingConstraintPrivate.cpp: Added. (JSC::isMarked): (JSC::mark): (JSContextGroupRegisterMarkingConstraint): * API/JSMarkingConstraintPrivate.h: Added. * API/JSWeakPrivate.cpp: Added. (OpaqueJSWeak::OpaqueJSWeak): (JSWeakCreate): (JSWeakRetain): (JSWeakRelease): (JSWeakGetObject): * API/JSWeakPrivate.h: Added. * API/tests/testapi.c: (markingConstraint): (testMarkingConstraints): (main): * JavaScriptCore.xcodeproj/project.pbxproj: * heap/SlotVisitor.h: * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::appendHiddenUnbarriered): (JSC::SlotVisitor::appendHidden): 2017-05-02 Mark Lam <mark.lam@apple.com> JSFixedArray::allocationSize() should not allow for allocation failure. https://bugs.webkit.org/show_bug.cgi?id=171516 Reviewed by Geoffrey Garen. Since JSFixedArray::createFromArray() now handles allocation failures by throwing OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer size to allocate) should also allow for allocation failure on overflow. This issue is covered by the stress/js-fixed-array-out-of-memory.js test when run on 32-bit builds. * runtime/JSFixedArray.h: (JSC::JSFixedArray::tryCreate): (JSC::JSFixedArray::allocationSize): 2017-05-01 Zan Dobersek <zdobersek@igalia.com> [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate() https://bugs.webkit.org/show_bug.cgi?id=170672 Reviewed by Filip Pizlo. In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on the stack for ARM64 because that can lead to disallowed usage of the scratch register in MacroAssemblerARM64 when generating a call with an address Arg in Air::CCallSpecial::generate(). The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the original issue by force-spilling everything on the stack and enforcing the use of the linear scan register allocation by using an optimization level of 1. * b3/air/AirCCallSpecial.cpp: (JSC::B3::Air::CCallSpecial::admitsStack): * b3/testb3.cpp: (JSC::B3::testLinearScanWithCalleeOnStack): (JSC::B3::run): 2017-05-01 David Kilzer <ddkilzer@apple.com> Stop using sprintf() in JavaScriptCore debugger <https://webkit.org/b/171512> Reviewed by Keith Miller. * disassembler/udis86/udis86.c: (ud_insn_hex): Switch from sprintf() to snprintf(). 2017-04-21 Filip Pizlo <fpizlo@apple.com> Air::fixObviousSpills should remove totally redundant instructions https://bugs.webkit.org/show_bug.cgi?id=171131 Reviewed by Saam Barati. This is a modest compile-time-neutral improvement to fixObviousSpills. That phase builds up a classic alias analysis data structure over spills and registers and then uses it to remove the most common spill pathologies we encounter. For example, if you use a spill but the spill is aliased to a register or constant, then we can replace the use of the spill with a use of the register or constant. But that phase was missing perhaps one of the most obvious fixups that its analysis allows us to do: if any instruction creates an alias we already know about, then the instruction is redundant. This turned out to be super important for https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this kind of optimization might be a good clean-up for many other kinds of optimizations. * b3/air/AirFixObviousSpills.cpp: 2017-04-30 Oleksandr Skachkov <gskachkov@gmail.com> We initialize functions too early in an eval https://bugs.webkit.org/show_bug.cgi?id=161099 Reviewed by Saam Barati. Current patch allow to fix problem with scope in function that is declared within eval. Before scope was set inside Interpretator.cpp and it was scope where eval is executed, but in this case function would not see let/const variables and classes declated in eval. This patch devide declaration and binding in two operation, first just declare variable with function name, and second bind variable to function with correct scope * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::generate): (JSC::BytecodeGenerator::BytecodeGenerator): * bytecompiler/BytecodeGenerator.h: * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): 2017-04-30 Oleksandr Skachkov <gskachkov@gmail.com> [ES6]. Implement Annex B.3.3 function hoisting rules for eval https://bugs.webkit.org/show_bug.cgi?id=163208 Reviewed by Saam Barati. Current patch implements Annex B.3.3 that is related to hoisting of function declaration in eval. https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation Function declaration in eval should create variable with function name in function scope where eval is invoked or bind to variable if it declared outside of the eval. If variable is created it can be removed by 'delete a;' command. If eval is invoke in block scope that contains let/const variable with the same name as function declaration we do not bind. This patch leads to the following behavior: ''' function foo() { { print(boo); // undefined eval('{ function boo() {}}'); print(boo); // function boo() {} } print(boo); // function boo() {} } function foobar() { { let boo = 10; print(boo); // 10; eval('{ function boo() {}}'); print(boo); // 10; } print(boo) // 10 } function bar() { { var boo = 10; print(boo); // 10 eval('{ function boo() {} }'); print(boo); // function boo() {} } print(boo); // function boo() {} } function bas() { { let boo = 10; eval(' { function boo() {} } '); print(boo); // 10 } print(boo); //Reference Error } ''' Current implementation relies on already implemented 'hoist function in sloppy mode' feature, with small changes. In short it works in following way: during hoisting of function with name S in eval, we are looking for first scope that contains space for variable with name S and if this scope has var type we bind function there To implement this feature was added bytecode ops: op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope or return undefined if variable can't be binded there. There is a corner case, hoist function in eval within catch block, that is not covered by this patch, and will be fixed in https://bugs.webkit.org/show_bug.cgi?id=168184 * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/EvalCodeBlock.h: (JSC::EvalCodeBlock::functionHoistingCandidate): (JSC::EvalCodeBlock::numFunctionHoistingCandidates): * bytecode/UnlinkedEvalCodeBlock.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval): * bytecompiler/BytecodeGenerator.h: * 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::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): * dfg/DFGSpeculativeJIT.h: (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/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * llint/LowLevelInterpreter.asm: * parser/Parser.cpp: (JSC::Parser<LexerType>::parseFunctionDeclarationStatement): * parser/Parser.h: (JSC::Scope::getSloppyModeHoistedFunctions): (JSC::Parser::declareFunction): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/EvalExecutable.h: (JSC::EvalExecutable::numFunctionHoistingCandidates): (JSC::EvalExecutable::numTopLevelFunctionDecls): (JSC::EvalExecutable::numberOfFunctionDecls): Deleted. * runtime/JSScope.cpp: (JSC::JSScope::resolve): (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval): * runtime/JSScope.h: 2017-04-29 Oleksandr Skachkov <gskachkov@gmail.com> Deep nesting is leading to ReferenceError for hoisted function https://bugs.webkit.org/show_bug.cgi?id=171456 Reviewed by Yusuke Suzuki. Current patch fix error that appears during hoisting of the function in block scope. Error happens only when exist some deep scope that lead to increase scope stack, after which list of the hosted candidates do not copied to updated scope stack. * parser/Parser.h: (JSC::Scope::Scope): 2017-04-29 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] LabelScopePtr is not necessary https://bugs.webkit.org/show_bug.cgi?id=171474 Reviewed by Geoffrey Garen. Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>. LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly since Vector<> can relocate LocalScopes inside it. The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<> prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>. But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no longer necessary. And use SegmentedVector for LabelScopes. * bytecompiler/BytecodeGenerator.cpp: (JSC::reclaim): (JSC::BytecodeGenerator::reclaimFreeRegisters): (JSC::BytecodeGenerator::newLabelScope): (JSC::BytecodeGenerator::newLabel): (JSC::BytecodeGenerator::pushFinallyControlFlowScope): (JSC::BytecodeGenerator::breakTarget): (JSC::BytecodeGenerator::continueTarget): (JSC::BytecodeGenerator::emitEnumeration): * bytecompiler/BytecodeGenerator.h: * bytecompiler/LabelScope.h: (JSC::LabelScope::LabelScope): (JSC::LabelScope::breakTarget): (JSC::LabelScope::continueTarget): (JSC::LabelScope::type): (JSC::LabelScope::name): (JSC::LabelScope::scopeDepth): (JSC::LabelScope::ref): (JSC::LabelScope::deref): (JSC::LabelScope::refCount): (JSC::LabelScopePtr::LabelScopePtr): Deleted. (JSC::LabelScopePtr::operator=): Deleted. (JSC::LabelScopePtr::~LabelScopePtr): Deleted. (JSC::LabelScopePtr::operator!): Deleted. (JSC::LabelScopePtr::operator*): Deleted. (JSC::LabelScopePtr::operator->): Deleted. (JSC::LabelScopePtr::null): Deleted. * bytecompiler/NodesCodegen.cpp: (JSC::DoWhileNode::emitBytecode): (JSC::WhileNode::emitBytecode): (JSC::ForNode::emitBytecode): (JSC::ForInNode::emitBytecode): (JSC::ContinueNode::trivialTarget): (JSC::ContinueNode::emitBytecode): (JSC::BreakNode::trivialTarget): (JSC::BreakNode::emitBytecode): (JSC::SwitchNode::emitBytecode): (JSC::LabelNode::emitBytecode): 2017-04-28 Mark Lam <mark.lam@apple.com> Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed. https://bugs.webkit.org/show_bug.cgi?id=170094 Reviewed by JF Bastien and Keith Miller. * heap/Heap.cpp: (JSC::Heap::resumeThePeriphery): 2017-04-27 Andy VanWagoner <thetalecrafter@gmail.com> [INTL] Implement the caseFirst option for Intl.Collator https://bugs.webkit.org/show_bug.cgi?id=158188 Reviewed by Geoffrey Garen. Implements the caseFirst option and unicode locale extension. The caseFirst option explicitly determines whether upper or lower case comes first. * runtime/IntlCollator.cpp: (JSC::sortLocaleData): Added kf data. (JSC::searchLocaleData): Added kf data. (JSC::IntlCollator::initializeCollator): Set caseFirst option. (JSC::IntlCollator::createCollator): Set new attributes on ICU collator. (JSC::IntlCollator::caseFirstString): Added. (JSC::IntlCollator::resolvedOptions): Added caseFirst property. * runtime/IntlCollator.h: 2017-04-27 Mark Lam <mark.lam@apple.com> Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors. https://bugs.webkit.org/show_bug.cgi?id=171404 <rdar://problem/31876178> Reviewed by Saam Barati. 1. Added some tryAllocate() functions in JSCellInlines.h. 2. Consolidated the implementations of allocateCell() template functions into a single tryAllocateCellHelper() to reduce redundancy and eliminate needing to copy-paste for variations of allocateCell and tryAllocateCell. 3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for allocation failure and throw an OutOfMemoryError. It was already possible to throw errors from these functions for other reasons. So, their clients are already ready to handle OOMEs. * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * runtime/JSCInlines.h: * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::tryAllocateCellHelper): (JSC::allocateCell): (JSC::tryAllocateCell): * runtime/JSFixedArray.h: (JSC::JSFixedArray::createFromArray): (JSC::JSFixedArray::tryCreate): (JSC::JSFixedArray::create): Deleted. * runtime/JSGlobalObject.h: (JSC::constructEmptyArray): 2017-04-27 Joseph Pecoraro <pecoraro@apple.com> Support for promise rejection events (unhandledrejection) https://bugs.webkit.org/show_bug.cgi?id=150358 <rdar://problem/28441651> Reviewed by Saam Barati. Patch by Joseph Pecoraro and Yusuke Suzuki. Implement support for promise.[[PromiseIsHandled]] and the HostPromiseRejectionTracker hook for HTML to track promise rejections: https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections * builtins/BuiltinNames.h: New private symbols. * builtins/PromiseOperations.js: (globalPrivate.newHandledRejectedPromise): Utility to create a rejected promise with [[PromiseIsHandled]] to true. (globalPrivate.rejectPromise): (globalPrivate.initializePromise): * builtins/PromisePrototype.js: (then): Implement standard behavior of [[PromiseIsHandled]] and the host hook. * runtime/JSPromise.cpp: (JSC::JSPromise::isHandled): * runtime/JSPromise.h: C++ accessors for the [[PromiseIsHandled]] state. * bytecode/BytecodeIntrinsicRegistry.cpp: (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): * bytecode/BytecodeIntrinsicRegistry.h: Expose private values for the Reject / Handle enum values in built-ins. * jsc.cpp: * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::promiseResolveFunction): Add a new GlobalObjectMethodTable hook matching the promise rejection hook. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObjectFunctions.cpp: (JSC::globalFuncHostPromiseRejectionTracker): * runtime/JSGlobalObjectFunctions.h: Plumb the builtin hook through to the optional GlobalObjectMethodTable hook. * inspector/InjectedScriptSource.js: (InjectedScript.prototype.createFakeValueDescriptor): Silence possible rejected promises created internally via Web Inspector. 2017-04-27 Saam Barati <sbarati@apple.com> B3::FoldPathConstants does not consider the fall through case for Switch https://bugs.webkit.org/show_bug.cgi?id=171390 Reviewed by Filip Pizlo. foldPathConstants was not taking into account a Switch's default case when it tried to constant propagate the switch's operand value. e.g, we incorrectly transformed this code: ``` x = argumentGPR0; switch (x) { case 10: return 20; case 0: default: return x == 0; } ``` into: ``` x = argumentGPR0; switch (x) { case 10: return 20; case 0: default: return 1; } ``` Because we didn't take into account the default case, we incorrectly optimized the code as if case 0's block was only reachable if x is equal to zero. This is obviously not true, since it's the same block as the default case. This fix ensures that we can run the WebAssembly Tanks demo even when we set webAssemblyBBQOptimizationLevel=2. * b3/B3FoldPathConstants.cpp: * b3/B3SwitchValue.cpp: (JSC::B3::SwitchValue::fallThrough): (JSC::B3::SwitchValue::removeCase): Deleted. * b3/B3SwitchValue.h: * b3/testb3.cpp: (JSC::B3::testCallFunctionWithHellaArguments): (JSC::B3::testSwitchSameCaseAsDefault): (JSC::B3::testWasmBoundsCheck): (JSC::B3::run): 2017-04-27 Keith Miller <keith_miller@apple.com> WebAssembly: Don't tier up the same function twice https://bugs.webkit.org/show_bug.cgi?id=171397 Reviewed by Filip Pizlo. Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following: Threads A and B are running count in memory is (0): A: load tier up count (0) B: load tier up count (0) A: decrement count to -2 and see we need to check for tier up (0) A: store -2 to count (-2) A: exchangeOr(1) to tier up count (-1) B: decrement count to -2 and see we need to check for tier up (-1) B: store -2 to count (-2) B: exchangeOr(1) to tier up count (-1) This would cause us to tier up the same function twice, which we would rather avoid. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitTierUpCheck): * wasm/WasmTierUpCount.h: (JSC::Wasm::TierUpCount::TierUpCount): (JSC::Wasm::TierUpCount::loopDecrement): (JSC::Wasm::TierUpCount::functionEntryDecrement): (JSC::Wasm::TierUpCount::shouldStartTierUp): 2017-04-27 Keith Miller <keith_miller@apple.com> REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &) https://bugs.webkit.org/show_bug.cgi?id=171380 Reviewed by JF Bastien. This patch fixes the association of VMs to Wasm::Plans. For validation we want all the completion tasks to be associate with a VM. For BBQ, we want the main task to not be associated with any VM. * jsc.cpp: (functionTestWasmModuleFunctions): * wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::BBQPlan): * wasm/WasmBBQPlan.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::compileAsync): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::create): * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::getOrCreateCodeBlock): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::compileAsync): * wasm/WasmModule.h: * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::runOMGPlanForIndex): * wasm/WasmOMGPlan.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast): * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyValidateFunc): 2017-04-27 Saam Barati <sbarati@apple.com> Restore some caching functionality that got accidentally removed when doing Wasm PIC patches https://bugs.webkit.org/show_bug.cgi?id=171382 Reviewed by Keith Miller. When I created Wasm::CodeBlock, I accidentally removed caching the creation of JSWebAssemblyCodeBlocks. This patch restores it. It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock cache because creating a JSWebAssemblyCodeBlock does non trivial work by creating the various IC call stubs. * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::codeBlock): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): * wasm/js/JSWebAssemblyModule.h: 2017-04-27 Mark Lam <mark.lam@apple.com> Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate(). https://bugs.webkit.org/show_bug.cgi?id=171344 <rdar://problem/31352667> Reviewed by Filip Pizlo. JSArray::tryCreateForInitializationPrivate() should only be used in performance critical paths, and should always be used with care because it creates an uninitialized object that needs to be initialized by its client before the object can be released into the system. Before the object is fully initialized: a. the client should not re-enter the VM to execute JS code, and b. GC should not run. This is because until the object is fully initialized, it is an inconsistent state that the GC and JS code will not be happy about. In this patch, we do the following: 1. Renamed JSArray::tryCreateForInitializationPrivate() to JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous and can be confused with APIs that are called freely within WebKit but are not meant for clients of WebKit. In this case, we intend for use of this API to be restricted to only a few carefully considered and crafted cases. 2. Introduce the ObjectInitializationScope RAII object which covers the period when the uninitialized object is created and gets initialized. ObjectInitializationScope will asserts that either the object is created fully initialized (in the case where the object structure is not an "original" structure) or if created uninitialized, is fully initialized at the end of the scope. If the object is created uninitialized, the ObjectInitializationScope also ensures that we do not GC nor re-enter the VM to execute JS code. This is achieved by enabling DisallowGC and DisallowVMReentry scopes. tryCreateUninitializedRestricted() and initializeIndex() now requires an ObjectInitializationScope instance. The ObjectInitializationScope replaces the VM& argument because it can be used to pass the VM& itself. This is a small optimization that makes passing the ObjectInitializationScope free even on release builds. 3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it. Introduce a DisallowVMReentry class that extends DisallowScope. 4. Fixed a bug found by the ObjectInitializationScope. The bug is that there are scenarios where the structure passed to tryCreateUninitializedRestricted() that may not be an "original" structure. As a result, initializeIndex() would end up allocating new structures, and therefore trigger a GC. The fix is to detect that the structure passed to tryCreateUninitializedRestricted() is not an "original" one, and pre-initialize the array with 0s. This bug was detected by existing tests. Hence, no new test needed. 5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with tryCreate(). Inappropriate uses here means code that is not in performance critical paths. Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex(). This patch is performance neutral (according to the JSC command line benchmarks). * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOperations.cpp: * ftl/FTLOperations.cpp: (JSC::FTL::operationMaterializeObjectInOSR): * heap/DeferGC.cpp: * heap/DeferGC.h: (JSC::DisallowGC::DisallowGC): (JSC::DisallowGC::initialize): (JSC::DisallowGC::scopeReentryCount): (JSC::DisallowGC::setScopeReentryCount): (JSC::DisallowGC::~DisallowGC): Deleted. (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted. * heap/GCDeferralContextInlines.h: (JSC::GCDeferralContext::~GCDeferralContext): * heap/Heap.cpp: (JSC::Heap::collectIfNecessaryOrDefer): * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): * runtime/ClonedArguments.cpp: (JSC::ClonedArguments::createWithInlineFrame): (JSC::ClonedArguments::createByCopyingFrom): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/DisallowScope.h: Added. (JSC::DisallowScope::DisallowScope): (JSC::DisallowScope::~DisallowScope): (JSC::DisallowScope::isInEffectOnCurrentThread): (JSC::DisallowScope::enable): (JSC::DisallowScope::enterScope): (JSC::DisallowScope::exitScope): * runtime/DisallowVMReentry.cpp: Added. * runtime/DisallowVMReentry.h: Added. (JSC::DisallowVMReentry::DisallowVMReentry): (JSC::DisallowVMReentry::initialize): (JSC::DisallowVMReentry::scopeReentryCount): (JSC::DisallowVMReentry::setScopeReentryCount): * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/JSArray.cpp: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::fastSlice): (JSC::JSArray::tryCreateForInitializationPrivate): Deleted. * runtime/JSArray.h: (JSC::JSArray::tryCreateUninitializedRestricted): (JSC::JSArray::tryCreate): (JSC::constructArray): (JSC::constructArrayNegativeIndexed): (JSC::JSArray::tryCreateForInitializationPrivate): Deleted. (JSC::createArrayButterfly): Deleted. * runtime/JSCellInlines.h: (JSC::allocateCell): * runtime/JSObject.h: (JSC::JSObject::initializeIndex): (JSC::JSObject::initializeIndexWithoutBarrier): * runtime/ObjectInitializationScope.cpp: Added. (JSC::ObjectInitializationScope::ObjectInitializationScope): (JSC::ObjectInitializationScope::~ObjectInitializationScope): (JSC::ObjectInitializationScope::notifyAllocated): (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized): * runtime/ObjectInitializationScope.h: Added. (JSC::ObjectInitializationScope::ObjectInitializationScope): (JSC::ObjectInitializationScope::vm): (JSC::ObjectInitializationScope::notifyAllocated): * runtime/Operations.h: (JSC::isScribbledValue): (JSC::scribble): * runtime/RegExpMatchesArray.cpp: (JSC::createEmptyRegExpMatchesArray): * runtime/RegExpMatchesArray.h: (JSC::tryCreateUninitializedRegExpMatchesArray): (JSC::createRegExpMatchesArray): * runtime/VMEntryScope.cpp: (JSC::VMEntryScope::VMEntryScope): 2017-04-27 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Remote inspector should support inspecting targets with previous version of backend commands https://bugs.webkit.org/show_bug.cgi?id=171267 Reviewed by Michael Catanzaro. Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by client right after connecting to the server. The method now receives the client backend commands hash as argument and returns the contents of the backend commands file in case the hash doesn't match with the local version. * PlatformGTK.cmake: Add RemoteInspectorUtils to compilation. * inspector/remote/glib/RemoteInspectorServer.cpp: (Inspector::RemoteInspectorServer::setupInspectorClient): * inspector/remote/glib/RemoteInspectorServer.h: * inspector/remote/glib/RemoteInspectorUtils.cpp: Added. (Inspector::backendCommands): (Inspector::backendCommandsHash): * inspector/remote/glib/RemoteInspectorUtils.h: Added. 2017-04-27 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Handle PhantomSpread in LoadVarargs as the same to the others https://bugs.webkit.org/show_bug.cgi?id=171262 Reviewed by Saam Barati. This is follow-up patch after r215720. In that patch, accidentally we did not apply the same change to LoadVarargs in argument elimination phase. This patch just does the same rewriting to handle PhantomSpread correctly. * dfg/DFGArgumentsEliminationPhase.cpp: 2017-04-26 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Uint8ClampedArray should be treated like an array, not an object https://bugs.webkit.org/show_bug.cgi?id=171364 <rdar://problem/10873037> Reviewed by Sam Weinig. * inspector/JSInjectedScriptHost.cpp: (Inspector::JSInjectedScriptHost::subtype): Treat Uint8ClampedArray (like other Typed Arrays) as an array. 2017-04-26 Saam Barati <sbarati@apple.com> Print Wasm function index in stack trace https://bugs.webkit.org/show_bug.cgi?id=171349 Reviewed by JF Bastien. This patch prints a Callee's index in the function index space in Error.stack. This will lead to stack traces that have lines of text like: wasm function index: 4@[wasm code] We don't ascribe indices to everything in wasm. Specifically, the Wasm->JS call stub callee does not get a name, and neither does the JS -> Wasm entrypoint. * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::Frame::functionName): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::wasmFunctionIndex): * runtime/StackFrame.cpp: (JSC::StackFrame::functionName): * runtime/StackFrame.h: (JSC::StackFrame::StackFrame): (JSC::StackFrame::wasm): (JSC::StackFrame::hasBytecodeOffset): (JSC::StackFrame::bytecodeOffset): * wasm/WasmBBQPlanInlines.h: (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmCallee.cpp: (JSC::Wasm::Callee::Callee): * wasm/WasmCallee.h: (JSC::Wasm::Callee::create): (JSC::Wasm::Callee::index): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): 2017-04-26 Keith Miller <keith_miller@apple.com> Follow up to r215843 https://bugs.webkit.org/show_bug.cgi?id=171361 Reviewed by Saam Barati. This patch fixes some style comments Saam didn't get a chance to request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134. It renames Wasm::CodeBlock::m_wasmEntrypoints to m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and indentation. * wasm/WasmBBQPlan.cpp: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): * wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * wasm/WasmTierUpCount.h: (JSC::Wasm::TierUpCount::TierUpCount): (JSC::Wasm::TierUpCount::loopDecrement): (JSC::Wasm::TierUpCount::functionEntryDecrement): (JSC::Wasm::TierUpCount::shouldStartTierUp): (JSC::Wasm::TierUpCount::count): 2017-04-26 Saam Barati <sbarati@apple.com> ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender() https://bugs.webkit.org/show_bug.cgi?id=170924 <rdar://problem/31721052> Reviewed by Mark Lam. The error message handler for "in" was searching for the literal string "in". However, our parser incorrectly allows escaped characters to be part of keywords. So this is parsed as "in" in JSC: "i\u006E". It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310 to address this issue. Regardless, the error message handlers should handle unexpected text gracefully. All functions that try to augment error messages with the goal of providing a more textual context for the error message should use the original error message instead of crashing when they detect unexpected text. This patch also changes the already buggy code that tries to find the base of a function call. That could would fail for code like this: "zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304 It would think that the base is "z". However, the algorithm that tries to find the base can often tell when it fails, and when it does, it should happily return the approximate text error message instead of thinking that the base is "z". * runtime/ExceptionHelpers.cpp: (JSC::functionCallBase): (JSC::notAFunctionSourceAppender): (JSC::invalidParameterInSourceAppender): 2017-04-26 Keith Miller <keith_miller@apple.com> WebAssembly: Implement tier up https://bugs.webkit.org/show_bug.cgi?id=170134 Reviewed by Filip Pizlo. This patch implements tier up for wasm functions. Unlike with JS code, wasm code needs to be able to tier up concurrently with the running code. Since JS code is synchronous we can always link on the running thread, wasm, however, can run the same code on more than one thread. In order to make patching work correctly, we need to ensure that all patches of callsites are aligned. On ARM we get this for free since every call is a near call. On X86 we ensure that the 32-bit relative offset is 32-bit aligned. This patch also modifies how Wasm::Plan works. Now Plan is a abstract super class and there are two subclasses, which correspond to the different tiers of our wasm engine. The first, Build Bytecode Quickly (BBQ) tier, roughly does what the old plan code did before. The new tier, Optimized Machine code Generation (OMG), can be called at any point by BBQ code and compiles exactly one function. Once an OMGPlan finishes it will link it's code internally then reset the instruction cache of all running wasm threads, via, a ThreadMessage. Once the instruction caches have been reset all the other functions will be patched to call the new code. * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::ensureCacheLineSpace): * assembler/CodeLocation.h: (JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall): * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::threadSafePatchableNearCall): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::threadSafeNearCall): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::threadSafePatchableNearCall): * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::inst): (JSC::B3::Air::ShufflePair::opcode): Deleted. * b3/air/AirEmitShuffle.h: * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * runtime/Options.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::materializeWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::constant): (JSC::Wasm::B3IRGenerator::emitTierUpCheck): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::addTopLevel): (JSC::Wasm::B3IRGenerator::addBlock): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp. (JSC::Wasm::BBQPlan::BBQPlan): (JSC::Wasm::BBQPlan::stateString): (JSC::Wasm::BBQPlan::moveToState): (JSC::Wasm::BBQPlan::parseAndValidateModule): (JSC::Wasm::BBQPlan::prepare): (JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder): (JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::BBQPlan::compileFunctions): (JSC::Wasm::BBQPlan::complete): (JSC::Wasm::BBQPlan::work): * wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h. * wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h. (JSC::Wasm::BBQPlan::initializeCallees): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmCallee.h: (JSC::Wasm::Callee::entrypoint): * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): * wasm/WasmCodeBlock.h: (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::tierUpCount): (JSC::Wasm::CodeBlock::mode): * wasm/WasmFormat.h: (JSC::Wasm::CallableFunction::CallableFunction): (JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation): * wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h. (JSC::Wasm::wasmThreads): (JSC::Wasm::startTrackingCurrentThread): (JSC::Wasm::resetInstructionCacheOnAllThreads): * wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h. * wasm/WasmModule.cpp: (JSC::Wasm::makeValidationResult): (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): * wasm/WasmModule.h: (JSC::Wasm::Module::codeBlockFor): * wasm/WasmOMGPlan.cpp: Added. (JSC::Wasm::OMGPlan::OMGPlan): (JSC::Wasm::OMGPlan::work): (JSC::Wasm::runOMGPlanForIndex): * wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h. * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::runCompletionTasks): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::waitForCompletion): (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast): (JSC::Wasm::Plan::fail): (JSC::Wasm::Plan::stateString): Deleted. (JSC::Wasm::Plan::moveToState): Deleted. (JSC::Wasm::Plan::parseAndValidateModule): Deleted. (JSC::Wasm::Plan::prepare): Deleted. (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted. (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted. (JSC::Wasm::Plan::compileFunctions): Deleted. (JSC::Wasm::Plan::complete): Deleted. * wasm/WasmPlan.h: (JSC::Wasm::Plan::exports): Deleted. (JSC::Wasm::Plan::internalFunctionCount): Deleted. (JSC::Wasm::Plan::takeModuleInformation): Deleted. (JSC::Wasm::Plan::takeCallLinkInfos): Deleted. (JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted. (JSC::Wasm::Plan::hasWork): Deleted. (JSC::Wasm::Plan::hasBeenPrepared): Deleted. * wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h. (JSC::Wasm::TierUpCount::TierUpCount): (JSC::Wasm::TierUpCount::loopDecrement): (JSC::Wasm::TierUpCount::functionEntryDecrement): (JSC::Wasm::TierUpCount::shouldStartTierUp): (JSC::Wasm::TierUpCount::count): * wasm/WasmWorklist.cpp: * wasm/WasmWorklist.h: (JSC::Wasm::Worklist::nextTicket): * wasm/js/JSWebAssemblyCodeBlock.cpp: * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted. * wasm/js/JSWebAssemblyTable.cpp: (JSC::JSWebAssemblyTable::setFunction): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::create): (JSC::WebAssemblyFunction::WebAssemblyFunction): * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::signatureIndex): (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation): (JSC::WebAssemblyFunction::callableFunction): (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): (JSC::WebAssemblyFunction::wasmEntrypoint): Deleted. (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted. * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyValidateFunc): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction): (JSC::WebAssemblyWrapperFunction::create): * wasm/js/WebAssemblyWrapperFunction.h: (JSC::WebAssemblyWrapperFunction::signatureIndex): (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation): (JSC::WebAssemblyWrapperFunction::callableFunction): (JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted. 2017-04-26 Caitlin Potter <caitp@igalia.com> [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys() https://bugs.webkit.org/show_bug.cgi?id=171330 Reviewed by Mark Lam. Ensure RETURN_IF_EXCEPTION() following invokation of the filterPropertyIfNeeded() lambda. * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): 2017-04-26 Caitlin Potter <caitp@igalia.com> [JSC] Object.keys() must discard property names with no PropertyDescriptor https://bugs.webkit.org/show_bug.cgi?id=171291 Reviewed by Yusuke Suzuki. Proxy objects can produce an arbitrary list of property names from the "ownKeys" trap, however the Object.keys() algorithm is required to discard names which do not have a PropertyDescriptor. This also applies to other uses of the EnumerableOwnProperties() algorithm (https://tc39.github.io/ecma262/#sec-enumerableownproperties) Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290 * runtime/ObjectConstructor.cpp: (JSC::ownPropertyKeys): 2017-04-25 Andy VanWagoner <thetalecrafter@gmail.com> Unhandled enumeration values in IntlDateTimeFormat.cpp https://bugs.webkit.org/show_bug.cgi?id=171241 Reviewed by JF Bastien. Added some missing cases of the UDateFormatField to partTypeString, and made them conditional to the ICU version that added them. This should remove the warnings that appear on platform builds using the newer system ICU headers. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): 2017-04-25 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r215476. https://bugs.webkit.org/show_bug.cgi?id=171304 "It broke JSBench" (Requested by saamyjoon on #webkit). Reverted changeset: "[ES6]. Implement Annex B.3.3 function hoisting rules for eval" https://bugs.webkit.org/show_bug.cgi?id=163208 http://trac.webkit.org/changeset/215476 2017-04-25 Saam Barati <sbarati@apple.com> JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object https://bugs.webkit.org/show_bug.cgi?id=171150 <rdar://problem/31771880> Reviewed by Sam Weinig. This patch fixes a huge oversight from the patch that introduced op_spread/Spread. The original patch did not account for the base object having Symbol.iterator or getters that could change the iterator protocol. This patch fixes the oversight both in the C code, as well as the DFG/FTL backends. We only perform the memcpy version of spread if we've proven that it's guaranteed to be side-effect free (no indexed getters), and if the iterator protocol is guaranteed to be the original protocol. To do this, we must prove that: 1. The protocol on Array.prototype hasn't changed (this is the same as the introductory patch for op_spread). 2. The base object's __proto__ is Array.prototype 3. The base object does not have indexed getters 4. The base object does not have Symbol.iterator property. * dfg/DFGGraph.cpp: (JSC::DFG::Graph::canDoFastSpread): * dfg/DFGGraph.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileSpread): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileSpread): * runtime/JSArray.cpp: (JSC::JSArray::isIteratorProtocolFastAndNonObservable): * runtime/JSArray.h: * runtime/JSArrayInlines.h: (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted. * runtime/JSGlobalObject.h: * runtime/JSGlobalObjectInlines.h: (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable): (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted. 2017-04-25 Mark Lam <mark.lam@apple.com> Array.prototype.slice() should ensure that end >= begin. https://bugs.webkit.org/show_bug.cgi?id=170989 <rdar://problem/31705652> Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSlice): 2017-04-25 Don Olmstead <don.olmstead@am.sony.com> [Win] Use Clang's __has_declspec_attribute for export macros https://bugs.webkit.org/show_bug.cgi?id=171240 Reviewed by Alex Christensen. * runtime/JSExportMacros.h: 2017-04-25 Saam Barati <sbarati@apple.com> Unreviewed. Attempt armv7k build fix after r215720 I think we're just missing an include for the definition of ExecState::r(). * runtime/JSFixedArray.cpp: 2017-04-25 Daniel Bates <dabates@apple.com> [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header https://bugs.webkit.org/show_bug.cgi?id=136452 <rdar://problem/23412620> Reviewed by Brent Fulgham. Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms. * Configurations/FeatureDefines.xcconfig: 2017-04-25 Mark Lam <mark.lam@apple.com> Local CSE wrongly CSEs array accesses with different result types. https://bugs.webkit.org/show_bug.cgi?id=170990 <rdar://problem/31705945> Reviewed by Saam Barati. The fix is to use different LocationKind enums for the different type of array result types. This makes the HeapLocation values different based on the result types, and allows CSE to discern between them. * dfg/DFGCSEPhase.cpp: * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGHeapLocation.cpp: (WTF::printInternal): * dfg/DFGHeapLocation.h: (JSC::DFG::indexedPropertyLocForResultType): 2017-04-25 Mark Lam <mark.lam@apple.com> Make DFG SpeculatedType dumps easier to read. https://bugs.webkit.org/show_bug.cgi?id=171280 Reviewed by Saam Barati. Adding a pretty printer to insert |s between each type string and changing the dumped strings to match the SpeculatedType names case-wise. * bytecode/SpeculatedType.cpp: (JSC::PrettyPrinter::PrettyPrinter): (JSC::PrettyPrinter::print): (JSC::dumpSpeculation): * bytecode/SpeculatedType.h: 2017-04-25 JF Bastien <jfbastien@apple.com> lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets https://bugs.webkit.org/show_bug.cgi?id=171278 Reviewed by Filip Pizlo. lowerStackArgs checked that the FP offsets it tries to generate are valid form, but didn't check that the fallback was valid form. This lead to stackAddr's assertion being dead, and the MaroAssembler asserting way later on move / add when handed a huge immediate. * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::stackAddrImpl): 2017-04-25 Zan Dobersek <zdobersek@igalia.com> [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers https://bugs.webkit.org/show_bug.cgi?id=170891 Reviewed by Saam Barati. moveConditionally32() and moveConditionallyTest32() operations in MacroAssemblerARM64 properly perform comparisons and tests on 32-bit values, but end up performing the moves from and to 32-bit registers. Move operations should instead be done on 64-bit registers, just like on the X86_64 platform. This is achieved by specifying 64 as the data size for the csel instructions. * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::moveConditionally32): (JSC::MacroAssemblerARM64::moveConditionallyTest32): 2017-04-24 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js https://bugs.webkit.org/show_bug.cgi?id=171190 Reviewed by Saam Barati. * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon): (JSC::BytecodeGenerator::emitNewFunction): * bytecompiler/NodesCodegen.cpp: (JSC::FunctionNode::emitBytecode): (JSC::Scope::setSourceParseMode): * parser/ParserModes.h: (JSC::isFunctionParseMode): (JSC::isMethodParseMode): (JSC::isGeneratorOrAsyncFunctionWrapperParseMode): (JSC::isGeneratorParseMode): (JSC::isGeneratorWrapperParseMode): * runtime/FunctionExecutable.h: * runtime/JSFunction.cpp: (JSC::JSFunction::getOwnPropertySlot): Add a new GeneratorWrapperMethodMode parse mode. The other function types (async, arrow) already have a FunctionMode and a MethodMode. Give generators one as well. This lets isMethodParseMode actually be accurate. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseInner): (JSC::Parser<LexerType>::isArrowFunctionParameters): (JSC::Parser<LexerType>::parseFormalParameters): (JSC::stringForFunctionMode): (JSC::Parser<LexerType>::parseFunctionParameters): (JSC::Parser<LexerType>::parseFunctionInfo): (JSC::Parser<LexerType>::parseClass): (JSC::Parser<LexerType>::parsePropertyMethod): * parser/Parser.h: Add a duplicate parameter failure if there are duplicate parameters in method syntax. 2017-04-24 Andy VanWagoner <thetalecrafter@gmail.com> Clean up ICU headers https://bugs.webkit.org/show_bug.cgi?id=170997 Reviewed by JF Bastien. Update all icu headers to 55.1 * icu/LICENSE: Update copyright * icu/README: Explain ICU headers for OS X better * icu/unicode/localpointer.h: (LocalPointer::LocalPointer): (LocalPointer::adoptInsteadAndCheckErrorCode): * icu/unicode/platform.h: * icu/unicode/putil.h: * icu/unicode/ucal.h: * icu/unicode/uchar.h: * icu/unicode/ucnv.h: * icu/unicode/ucol.h: * icu/unicode/uconfig.h: * icu/unicode/ucurr.h: * icu/unicode/udatpg.h: * icu/unicode/udisplaycontext.h: * icu/unicode/uformattable.h: * icu/unicode/uloc.h: * icu/unicode/umachine.h: * icu/unicode/unum.h: * icu/unicode/unumsys.h: * icu/unicode/urename.h: * icu/unicode/uscript.h: * icu/unicode/uset.h: * icu/unicode/ustring.h: * icu/unicode/utf8.h: * icu/unicode/utypes.h: 2017-04-24 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use JSFixedArray directly when using call_varargs https://bugs.webkit.org/show_bug.cgi?id=171057 Reviewed by Saam Barati. Previously we always emit new_array_with_spread when calling call(...args). But this array is unnecessary if varargs operation can handle Spread directly. This patch implements a peep-hole optimization in the bytecode compiler layer to omit new_array_with_spread. This is very simple and effective because this peep-hole optimization is quite common when using (...args) style calls and this optimization works all the tiers. While we can implement the phase to omit this NewArrayWithSpread in argument elimination phase, it only works for FTL. While such an optimization can work with complex data flow, this peep-hole optimization can optimize a common case easily. For now, Spread and PhantomSpread can be directly drained by CallVarargs and LoadVarargs related operations. We modify DFG and FTL to handle this correctly. This shows six-speed improvement. spread.es6 89.4300+-2.0236 ^ 69.6015+-1.7278 ^ definitely 1.2849x faster spread-generator.es6 344.7879+-5.9147 ^ 331.2712+-6.8610 ^ definitely 1.0408x faster * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitCall): (JSC::BytecodeGenerator::emitConstruct): * dfg/DFGArgumentsEliminationPhase.cpp: * dfg/DFGPreciseLocalClobberize.h: (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread): * interpreter/Interpreter.cpp: (JSC::sizeOfVarargs): (JSC::loadVarargs): * parser/Nodes.h: (JSC::ArrayNode::elements): * runtime/JSFixedArray.cpp: (JSC::JSFixedArray::copyToArguments): * runtime/JSFixedArray.h: 2017-04-24 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code https://bugs.webkit.org/show_bug.cgi?id=171199 Reviewed by Mark Lam. This patch adds a utility method to produce demangled names with dladdr. It fixes several memory leaks because the result of abi::__cxa_demangle() needs to be `free`-ed. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * inspector/JSGlobalObjectInspectorController.cpp: (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::StackFrame::displayName): * tools/CellProfile.h: * tools/CodeProfile.cpp: (JSC::CodeProfile::report): (JSC::symbolName): Deleted. 2017-04-24 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: ObjC RWIProtocol codegen should better handle optional members https://bugs.webkit.org/show_bug.cgi?id=171251 <rdar://problem/31697002> Reviewed by Brian Burg. * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py: (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member): * inspector/scripts/codegen/objc_generator.py: (ObjCGenerator.protocol_to_objc_expression_for_member): (ObjCGenerator.protocol_to_objc_code_block_for_object_member): Always be safe and nil check object property accesses, optional or not. * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result: * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result: Rebaselined inspector generator tests. 2017-04-24 Saam Barati <sbarati@apple.com> ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests https://bugs.webkit.org/show_bug.cgi?id=171119 <rdar://problem/31760635> Reviewed by Keith Miller. The HashSet of timer set notification callbacks can be accessed and augmented simultaneously from different threads. e.g, the worker thread can augment it while the wasm compilation thread will access it. Therefore, accesses must be guarded by a lock. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::addTimerSetNotification): (JSC::JSRunLoopTimer::removeTimerSetNotification): * runtime/JSRunLoopTimer.h: 2017-04-24 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/computed-property-names/class/static/getter-prototype.js https://bugs.webkit.org/show_bug.cgi?id=170897 Reviewed by Saam Barati. * parser/ASTBuilder.h: (JSC::ASTBuilder::createArguments): (JSC::ASTBuilder::createArgumentsList): Reorder so all the createProperty methods are grouped together. * parser/Parser.h: * parser/Parser.cpp: (JSC::Parser<LexerType>::parseClass): (JSC::Parser<LexerType>::parseProperty): (JSC::Parser<LexerType>::parseGetterSetter): Refine the conditions for syntax errors for getter/setter properties names. "prototype" is not allowed as a static and "constructor" is not all when non-static. * runtime/JSObject.cpp: (JSC::JSObject::putGetter): (JSC::JSObject::putSetter): Throw exceptions. These methods are only used by this path via op_put_getter_by_val / op_put_setter_by_val. 2017-04-24 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js https://bugs.webkit.org/show_bug.cgi?id=171160 Reviewed by JF Bastien. * parser/ASTBuilder.h: (JSC::ASTBuilder::tryInferNameInPattern): (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier): We supported getting the name from a BindingNode. We extend this to support getting the name from a ResolveNode inside of an AssignmentElementNode. * parser/Nodes.h: (JSC::DestructuringPatternNode::isAssignmentElementNode): (JSC::AssignmentElementNode::isAssignmentElementNode): Make it possible to identify an assignment element node. 2017-04-24 Alex Christensen <achristensen@webkit.org> Reduce copies and allocations in SharedBuffer::append https://bugs.webkit.org/show_bug.cgi?id=170956 Reviewed by Andreas Kling. * runtime/ArrayBuffer.h: 2017-04-24 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector https://bugs.webkit.org/show_bug.cgi?id=166680 Reviewed by Michael Catanzaro. Add GTK+ port implementation of RemoteInspector. * PlatformGTK.cmake: * inspector/remote/RemoteConnectionToTarget.h: * inspector/remote/RemoteInspector.h: * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added. (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget): (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget): (Inspector::RemoteConnectionToTarget::setup): (Inspector::RemoteConnectionToTarget::sendMessageToTarget): (Inspector::RemoteConnectionToTarget::close): (Inspector::RemoteConnectionToTarget::targetClosed): (Inspector::RemoteConnectionToTarget::targetIdentifier): (Inspector::RemoteConnectionToTarget::sendMessageToFrontend): * inspector/remote/glib/RemoteInspectorGlib.cpp: Added. (Inspector::RemoteInspector::singleton): (Inspector::RemoteInspector::RemoteInspector): (Inspector::RemoteInspector::start): (Inspector::RemoteInspector::stopInternal): (Inspector::RemoteInspector::setupConnection): (Inspector::dbusConnectionCallAsyncReadyCallback): (Inspector::RemoteInspector::listingForInspectionTarget): (Inspector::RemoteInspector::listingForAutomationTarget): (Inspector::RemoteInspector::pushListingsNow): (Inspector::RemoteInspector::pushListingsSoon): (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage): (Inspector::RemoteInspector::sendMessageToRemote): (Inspector::RemoteInspector::receivedGetTargetListMessage): (Inspector::RemoteInspector::receivedSetupMessage): (Inspector::RemoteInspector::receivedDataMessage): (Inspector::RemoteInspector::receivedCloseMessage): (Inspector::RemoteInspector::setup): (Inspector::RemoteInspector::sendMessageToTarget): (Inspector::RemoteInspector::requestAutomationSession): * inspector/remote/glib/RemoteInspectorServer.cpp: Added. (Inspector::generateConnectionID): (Inspector::RemoteInspectorServer::singleton): (Inspector::RemoteInspectorServer::~RemoteInspectorServer): (Inspector::RemoteInspectorServer::interfaceInfo): (Inspector::RemoteInspectorServer::start): (Inspector::RemoteInspectorServer::newConnectionCallback): (Inspector::RemoteInspectorServer::connectionClosedCallback): (Inspector::RemoteInspectorServer::newConnection): (Inspector::dbusConnectionCallAsyncReadyCallback): (Inspector::RemoteInspectorServer::setTargetList): (Inspector::RemoteInspectorServer::clientConnectionClosedCallback): (Inspector::RemoteInspectorServer::getTargetList): (Inspector::RemoteInspectorServer::setup): (Inspector::RemoteInspectorServer::close): (Inspector::RemoteInspectorServer::clientConnectionClosed): (Inspector::RemoteInspectorServer::connectionClosed): (Inspector::RemoteInspectorServer::sendMessageToBackend): (Inspector::RemoteInspectorServer::sendMessageToFrontend): (Inspector::RemoteInspectorServer::startAutomationSession): * inspector/remote/glib/RemoteInspectorServer.h: Added. (Inspector::RemoteInspectorServer::isRunning): 2017-04-24 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/expressions/generators/yield-as-label.js https://bugs.webkit.org/show_bug.cgi?id=170979 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseVariableDeclarationList): (JSC::Parser<LexerType>::parseDestructuringPattern): (JSC::Parser<LexerType>::parseFormalParameters): Converge on "Cannot" instead of "Can't" in error messages. (JSC::Parser<LexerType>::parseFunctionInfo): Disallow "yield" as the generator function name in function expressions. This refers to the difference between Declaration and Expression, where only GeneratorExpression explicitly has [+Yield] disallowing yield for the generator name: GeneratorDeclaration[Yield, Await, Default]: function * BindingIdentifier[?Yield, ?Await] ... GeneratorExpression: function * BindingIdentifier[+Yield, ~Await]opt ... (JSC::Parser<LexerType>::parseExpressionOrLabelStatement): Disallow "yield" as a label name in strict mode or inside a generator. (JSC::Parser<LexerType>::parseProperty): Disallow "yield" or any keyword in object literal shorthands. * parser/Parser.h: (JSC::Parser::getToken): (JSC::Parser::isDisallowedIdentifierLet): (JSC::Parser::isDisallowedIdentifierYield): (JSC::Parser::disallowedIdentifierLetReason): (JSC::Parser::disallowedIdentifierYieldReason): Follow pattern for improved error messages based on context. 2017-04-23 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r215674. https://bugs.webkit.org/show_bug.cgi?id=171212 Possible unintended commit. This patch was on the wrong bug. (Requested by JoePeck on #webkit). Reverted changeset: "test262: test262/test/language/expressions/generators/yield- as-label.js" https://bugs.webkit.org/show_bug.cgi?id=170979 http://trac.webkit.org/changeset/215674 2017-04-23 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js https://bugs.webkit.org/show_bug.cgi?id=171197 Reviewed by Saam Barati. * runtime/NumberPrototype.cpp: (JSC::numberProtoFuncToExponential): (JSC::numberProtoFuncToFixed): (JSC::numberProtoFuncToPrecision): Refine the order of operations to match the spec. 2017-04-23 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/expressions/generators/yield-as-label.js https://bugs.webkit.org/show_bug.cgi?id=170979 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseVariableDeclarationList): (JSC::Parser<LexerType>::parseDestructuringPattern): (JSC::Parser<LexerType>::parseFormalParameters): Converge on "Cannot" instead of "Can't" in error messages. (JSC::Parser<LexerType>::parseFunctionInfo): Disallow "yield" as the generator function name in function expressions. This refers to the difference between Declaration and Expression, where only GeneratorExpression explicitly has [+Yield] disallowing yield for the generator name: GeneratorDeclaration[Yield, Await, Default]: function * BindingIdentifier[?Yield, ?Await] ... GeneratorExpression: function * BindingIdentifier[+Yield, ~Await]opt ... (JSC::Parser<LexerType>::parseExpressionOrLabelStatement): Disallow "yield" as a label name in strict mode or inside a generator. (JSC::Parser<LexerType>::parseProperty): Disallow "yield" or any keyword in object literal shorthands. * parser/Parser.h: (JSC::Parser::getToken): (JSC::Parser::isDisallowedIdentifierLet): (JSC::Parser::isDisallowedIdentifierYield): (JSC::Parser::disallowedIdentifierLetReason): (JSC::Parser::disallowedIdentifierYieldReason): Follow pattern for improved error messages based on context. 2017-04-23 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/Number/parseFloat.js https://bugs.webkit.org/show_bug.cgi?id=171193 Reviewed by Yusuke Suzuki. * runtime/CommonIdentifiers.h: * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::JSGlobalObject::visitChildren): * runtime/JSGlobalObject.h: (JSC::JSGlobalObject::parseFloatFunction): Expose parseFloat on the global object to be shared with Number constructor. * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): parseFloat uses the same value as the global parseFloat. 2017-04-22 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use DoublyLinkedList for MachineThread https://bugs.webkit.org/show_bug.cgi?id=171171 Reviewed by Mark Lam. MachineThread can use WTF::DoublyLinkedList to simplify its implementation. We should not use Vector<> etc. since we do not want to call allocations during suspending and resuming threads. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThreads): (JSC::MachineThreads::~MachineThreads): (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::removeThreadIfFound): (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::tryCopyOtherThreadStacks): * heap/MachineStackMarker.h: (JSC::MachineThreads::threadsListHead): * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): * runtime/VMTraps.cpp: (JSC::findActiveVMAndStackBounds): 2017-04-22 JF Bastien <jfbastien@apple.com> WebAssembly: Module.exports, Module.imports, Module.customSections are wrong https://bugs.webkit.org/show_bug.cgi?id=171078 Reviewed by Saam Barati. They're static properties of Module, not instance properties of a module. https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::webAssemblyModuleCustomSections): (JSC::webAssemblyModuleImports): (JSC::webAssemblyModuleExports): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoCustomSections): Deleted. (JSC::webAssemblyModuleProtoImports): Deleted. (JSC::webAssemblyModuleProtoExports): Deleted. 2017-04-21 Saam Barati <sbarati@apple.com> SharedArrayBuffer-opt.js fails with Briggs https://bugs.webkit.org/show_bug.cgi?id=170948 <rdar://problem/31740568> Reviewed by Michael Saboff. The bug was not actually with Briggs, but instead was with our X86-64 MacroAssembler. Michael fixed the bug here: https://trac.webkit.org/changeset/215618/webkit The issue was we weren't adding the REX byte for AtomicXchg8, leading to the incorrect encoding for the result register depending on which register it was. If you look at this code, you'll see the issue: Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49) AtomicXchg8 %rsi, (%rax,%rdx), @38 0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx) Int32 @66 = Const32(255, DFG:@49) Int32 @67 = BitAnd(@38, $255(@66), DFG:@49) ZeroExtend8To32 %rsi, %rax, @67 0x2dcb5bc00162: movzx %sil, %eax Air thought the result was in the lower 8 bits of %rsi, however, the code we emitted stored it in the [8-15] bits of %rdx. Since this issue is fixed, I'm turning Briggs back on. * b3/air/AirAllocateRegistersByGraphColoring.h: (JSC::B3::Air::useIRC): 2017-04-20 Mark Lam <mark.lam@apple.com> Refactor MASM probe to allow printing of custom types. https://bugs.webkit.org/show_bug.cgi?id=171101 Reviewed by JF Bastien. For example, this allows us to add MASM printing of CodeBlock* and Air::Args. In general, MASM print can be used like dataLog, except that it generates JITted code for doing the dataLogging later when the JITted code runs. MASM print can print any value type that a specialized Printer template or a setPrinter() function implemented for that type. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/MacroAssembler.h: * assembler/MacroAssemblerPrinter.cpp: (JSC::Printer::printAllRegisters): (JSC::Printer::printPCRegister): (JSC::Printer::printRegisterID): (JSC::Printer::printFPRegisterID): (JSC::Printer::printAddress): (JSC::Printer::printMemory): (JSC::Printer::printCallback): (JSC::printIndent): Deleted. (JSC::printCPU): Deleted. (JSC::printCPURegisters): Deleted. (JSC::printPC): Deleted. (JSC::printRegister): Deleted. (JSC::printMemory): Deleted. (JSC::MacroAssemblerPrinter::printCallback): Deleted. * assembler/MacroAssemblerPrinter.h: (JSC::AllRegisters::AllRegisters): (JSC::Printer::Printer<AllRegisters>::Printer): (JSC::Printer::Printer<PCRegister>::Printer): (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer): (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer): (JSC::Printer::Printer<MacroAssembler::Address>::Printer): (JSC::Printer::Printer<Memory>::Printer): (JSC::Printer::Printer<MemWord<IntType>>::Printer): (JSC::MacroAssembler::print): (JSC::MacroAssemblerPrinter::print): Deleted. (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted. (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted. - Refactored to move the underlying PrintRecord (and associated data structures) out to Printer.cpp/h. - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like RegisterID and Memory. It also defines the implementation of MacroAssembler::print(). As before, JIT code that wishes to use MacroAssembler::print() needs to #include "MacroAssemblerPrinter.h". - Also added the ability to specify an optional indentation (in number of chars) when MASM printing AllRegisters. This is useful because AllRegisters prints a block of data unlike other printers which print inline. * assembler/Printer.cpp: Added. (JSC::Printer::printConstCharString): (JSC::Printer::printIntptr): (JSC::Printer::printUintptr): (JSC::Printer::printPointer): (JSC::Printer::setPrinter): * assembler/Printer.h: Added. (JSC::Printer::Context::Context): (JSC::Printer::PrintRecord::PrintRecord): (JSC::Printer::appendPrinter): (JSC::Printer::makePrintRecordList): (JSC::Printer::Printer<RawPointer>::Printer): (JSC::Printer::setPrinter): (JSC::Printer::Printer::Printer): - Data structures for creating a list of PrintRecords. Classes which wish to add custom support for MASM printing can #include "Printer.h" and implement either: 1. a specialized Printer template, or 2. a setPrinter() function. See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of (1). See CodeBlock's setPrinter() for an example of (2). * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::print): * b3/air/AirPrintSpecial.cpp: Added. (JSC::B3::Air::PrintSpecial::PrintSpecial): (JSC::B3::Air::PrintSpecial::~PrintSpecial): (JSC::B3::Air::PrintSpecial::forEachArg): (JSC::B3::Air::PrintSpecial::isValid): (JSC::B3::Air::PrintSpecial::admitsStack): (JSC::B3::Air::PrintSpecial::reportUsedRegisters): (JSC::B3::Air::PrintSpecial::generate): (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs): (JSC::B3::Air::PrintSpecial::extraClobberedRegs): (JSC::B3::Air::PrintSpecial::dumpImpl): (JSC::B3::Air::PrintSpecial::deepDumpImpl): (JSC::Printer::printAirArg): * b3/air/AirPrintSpecial.h: Added. (JSC::Printer::appendAirArg): (JSC::Printer::appendAirArgs): (JSC::Printer::Printer<B3::Air::Tmp>::Printer): (JSC::Printer::Printer<Reg>::Printer): - Add the print() operation for use in LowerToAir. print() will emit a PrintSpecial that will ultimately emit a MASM print to print what we want. - LowerToAir's print() adds the ability to print Air::Args. - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the usage of registers. This is because PrintSpecial is a patch point, and it prevents certain optimizations. If not used carefully, an attempt to print() an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would otherwise do so. So, use LowerToAir's print() with care. * bytecode/CodeBlock.cpp: (JSC::setPrinter): - Now we can MASM print CodeBlock*. (WTF::printInternal): - Now we can dataLog CodeBlock* (including null CodeBlock pointers). * bytecode/CodeBlock.h: * runtime/VM.cpp: (JSC::VM::throwException): - Use the new ability to dataLog CodeBlock*. No need to do an explicit null check before printing anymore. 2017-04-21 Keith Miller <keith_miller@apple.com> Unreviewed, rolling out r215634. underlying build issues should have been fixed Reverted changeset: "Unreviewed, rolling out r215620 and r215623." https://bugs.webkit.org/show_bug.cgi?id=171139 http://trac.webkit.org/changeset/215634 2017-04-21 Commit Queue <commit-queue@webkit.org> Unreviewed, rolling out r215620 and r215623. https://bugs.webkit.org/show_bug.cgi?id=171139 broke arm64 build (Requested by keith_miller on #webkit). Reverted changesets: "Add signaling API" https://bugs.webkit.org/show_bug.cgi?id=170976 http://trac.webkit.org/changeset/215620 "Unreviewed, fix Cloop build." http://trac.webkit.org/changeset/215623 2017-04-21 Keith Miller <keith_miller@apple.com> Remove LL/SC from Atomics https://bugs.webkit.org/show_bug.cgi?id=171141 Reviewed by Saam Barati. Adding load link and store conditionally was not an actual progression and the existing code is causing problems for users of Atomics. So let's get rid of it. * heap/LargeAllocation.h: (JSC::LargeAllocation::testAndSetMarked): * heap/MarkedBlock.h: (JSC::MarkedBlock::testAndSetMarked): * heap/SlotVisitor.cpp: (JSC::SlotVisitor::setMarkedAndAppendToMarkStack): 2017-04-21 Keith Miller <keith_miller@apple.com> Unreviewed, fix Cloop build. * jit/ExecutableAllocator.h: (JSC::isJITPC): 2017-04-20 Keith Miller <keith_miller@apple.com> Add signaling API https://bugs.webkit.org/show_bug.cgi?id=170976 Reviewed by Filip Pizlo. Update various uses of sigaction to use the new signaling API. Also switch VMTraps to use the thread message system instead of rolling it's own. * jit/ExecutableAllocator.h: (JSC::isJITPC): * runtime/VMTraps.cpp: (JSC::installSignalHandler): (JSC::VMTraps::VMTraps): (JSC::VMTraps::SignalSender::send): (JSC::handleSigusr1): Deleted. (JSC::handleSigtrap): Deleted. (JSC::installSignalHandlers): Deleted. * runtime/VMTraps.h: * tools/SigillCrashAnalyzer.cpp: (JSC::installCrashHandler): (JSC::handleCrash): Deleted. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): (JSC::Wasm::enableFastMemory): 2017-04-21 Michael Saboff <msaboff@apple.com> X86-64 Assembler doesn't handle xchg with byte register src https://bugs.webkit.org/show_bug.cgi?id=171118 Reviewed by Saam Barati. * assembler/X86Assembler.h: (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes. 2017-04-21 Andy VanWagoner <thetalecrafter@gmail.com> [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts https://bugs.webkit.org/show_bug.cgi?id=169458 Reviewed by JF Bastien. Use udat_formatForFields to iterate through the parts of a formatted date string. Make formatToParts and related functions dependent on ICU version >= 55. * icu/unicode/udat.h: Update to 55.1. * icu/unicode/ufieldpositer.h: Added from 55.1. * icu/unicode/uvernum.h: Update to 55.1 * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string. (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string. * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts. 2017-04-20 Konstantin Tokarev <annulen@yandex.ru> [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere https://bugs.webkit.org/show_bug.cgi?id=171071 Reviewed by Michael Catanzaro. "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should be available for all ports. * CMakeLists.txt: * PlatformWin.cmake: 2017-04-20 Konstantin Tokarev <annulen@yandex.ru> Remove unused lamda captures https://bugs.webkit.org/show_bug.cgi?id=171098 Reviewed by Yusuke Suzuki. * bytecompiler/NodesCodegen.cpp: (JSC::ArrayNode::emitBytecode): * ftl/FTLState.cpp: (JSC::FTL::State::State): * wasm/WasmB3IRGenerator.cpp: 2017-04-20 Yusuke Suzuki <utatane.tea@gmail.com> [JSC][FTL] FTL should support Arrayify https://bugs.webkit.org/show_bug.cgi?id=169596 Reviewed by Saam Barati. This patch simply expands the coverage of FTL by supporting Arrayify. While ArrayifyToStructure is already supported, Arrayify is not supported in FTL. While supporting Arrayify in FTL itself does not offer so much performance difference from DFG's one, no FTL support for Arrayify prevents us applying FTL to the code including Arrayify. * dfg/DFGArrayMode.cpp: (JSC::DFG::toIndexingShape): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileArrayify): (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray): (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify): (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray): (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted. (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted. 2017-04-20 Mark Lam <mark.lam@apple.com> virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls. https://bugs.webkit.org/show_bug.cgi?id=171079 <rdar://problem/31684756> Reviewed by Saam Barati. This is needed because tail calls would restore callee saved registers (and therefore, potentially clobber the tag registers) before jumping to the thunk. * jit/ThunkGenerators.cpp: (JSC::virtualThunkFor): 2017-04-20 Mark Lam <mark.lam@apple.com> Build fix after r215592. https://bugs.webkit.org/show_bug.cgi?id=171088 Not reviewed. * assembler/MacroAssemblerPrinter.h: 2017-04-20 Mark Lam <mark.lam@apple.com> Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function). https://bugs.webkit.org/show_bug.cgi?id=171088 Reviewed by Michael Saboff and Saam Barati. Experience shows that we never use the 2nd arg. So, let's remove it to reduce the footprint at each probe site. Also fix the MacroAssembler::print() function so that it is a no-op when !ENABLE(MASM_PROBE). This will allow us to have print() statements in JIT code without a lot of #if ENABLE(MASM_PROBE)s later. * assembler/AbstractMacroAssembler.h: * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::probe): * assembler/MacroAssemblerARM.h: * assembler/MacroAssemblerARM64.cpp: (JSC::MacroAssemblerARM64::probe): * assembler/MacroAssemblerARM64.h: * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssemblerARMv7::probe): * assembler/MacroAssemblerARMv7.h: * assembler/MacroAssemblerPrinter.cpp: (JSC::MacroAssemblerPrinter::printCallback): * assembler/MacroAssemblerPrinter.h: (JSC::MacroAssemblerPrinter::print): (JSC::MacroAssembler::print): * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssemblerX86Common::probe): * assembler/MacroAssemblerX86Common.h: 2017-04-20 Matt Baker <mattbaker@apple.com> Web Inspector: Add regular expression support to XHR breakpoints https://bugs.webkit.org/show_bug.cgi?id=170099 <rdar://problem/31558082> Reviewed by Joseph Pecoraro. * inspector/protocol/DOMDebugger.json: New optional `isRegex` parameter denotes whether `url` contains a regular expression. 2017-04-15 Filip Pizlo <fpizlo@apple.com> Optimize SharedArrayBuffer in the DFG+FTL https://bugs.webkit.org/show_bug.cgi?id=164108 Reviewed by Saam Barati. This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more powerful than what we need right now. In the DFG backend, I went with an easy-to-write implementation that just reduces everything to a weak CAS loop. It's very inefficient with registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care. To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for the slow paths can share code with the native functions. This also fixes register handling in the X86 implementations of CAS, in the case that expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS. I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance. This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this change. It's still about 3x slower than native. I investigated this only a bit. I suspect that the story will be different in asm.js code, which will get constant-folding of the typed array backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays. It's worth noting that the native lock I was comparing against, the very nicely-tuned CascadeLock, is at the very high end of lock throughput under virtually all conditions (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and the only ones that performed better in this microbenchmark were spinlocks. I don't recommend using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than the fastest native lock that I have in my arsenal. Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield, as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I did not investigate why. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::JumpList::append): * assembler/CPU.h: (JSC::is64Bit): (JSC::is32Bit): * b3/B3Common.h: (JSC::B3::is64Bit): Deleted. (JSC::B3::is32Bit): Deleted. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::appendTrapping): (JSC::B3::Air::LowerToAir::appendCAS): (JSC::B3::Air::LowerToAir::appendGeneralAtomic): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleIntrinsicCall): * 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::hasHeapPrediction): (JSC::DFG::Node::hasArrayMode): * dfg/DFGNodeType.h: (JSC::DFG::isAtomicsIntrinsic): (JSC::DFG::numExtraAtomicsArgs): * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSSALoweringPhase.cpp: (JSC::DFG::SSALoweringPhase::handleNode): * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray): (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult): (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray): (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand): (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::callOperation): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::decorateFencedAccess): (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal): (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray): (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray): (JSC::FTL::DFG::LowerDFGToB3::storeType): (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult): (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand): (JSC::FTL::DFG::LowerDFGToB3::vmCall): * ftl/FTLOutput.cpp: (JSC::FTL::Output::store): (JSC::FTL::Output::store32As8): (JSC::FTL::Output::store32As16): (JSC::FTL::Output::atomicXchgAdd): (JSC::FTL::Output::atomicXchgAnd): (JSC::FTL::Output::atomicXchgOr): (JSC::FTL::Output::atomicXchgSub): (JSC::FTL::Output::atomicXchgXor): (JSC::FTL::Output::atomicXchg): (JSC::FTL::Output::atomicStrongCAS): * ftl/FTLOutput.h: (JSC::FTL::Output::store32): (JSC::FTL::Output::store64): (JSC::FTL::Output::storePtr): (JSC::FTL::Output::storeFloat): (JSC::FTL::Output::storeDouble): * jit/JITOperations.h: * runtime/AtomicsObject.cpp: (JSC::atomicsFuncAdd): (JSC::atomicsFuncAnd): (JSC::atomicsFuncCompareExchange): (JSC::atomicsFuncExchange): (JSC::atomicsFuncIsLockFree): (JSC::atomicsFuncLoad): (JSC::atomicsFuncOr): (JSC::atomicsFuncStore): (JSC::atomicsFuncSub): (JSC::atomicsFuncWait): (JSC::atomicsFuncWake): (JSC::atomicsFuncXor): (JSC::operationAtomicsAdd): (JSC::operationAtomicsAnd): (JSC::operationAtomicsCompareExchange): (JSC::operationAtomicsExchange): (JSC::operationAtomicsIsLockFree): (JSC::operationAtomicsLoad): (JSC::operationAtomicsOr): (JSC::operationAtomicsStore): (JSC::operationAtomicsSub): (JSC::operationAtomicsXor): * runtime/AtomicsObject.h: 2017-04-19 Youenn Fablet <youenn@apple.com> [Mac] Allow customizing H264 encoder https://bugs.webkit.org/show_bug.cgi?id=170829 Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-04-19 Michael Saboff <msaboff@apple.com> Tune GC related JSC options for iOS https://bugs.webkit.org/show_bug.cgi?id=171019 Reviewed by Mark Lam. Always set these GC options on iOS. * runtime/Options.cpp: (JSC::overrideDefaults): 2017-04-19 JF Bastien <jfbastien@apple.com> WebAssembly: fast memory cleanups https://bugs.webkit.org/show_bug.cgi?id=170909 Reviewed by Saam Barati. * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent (JSC::B3::Air::LowerToAir::lower): * b3/B3Procedure.h: * b3/B3Validate.cpp: * b3/B3Value.cpp: (JSC::B3::Value::effects): * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a maximum, so we don't have to know so much about wasm here (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue): (JSC::B3::WasmBoundsCheckValue::cloneImpl): (JSC::B3::WasmBoundsCheckValue::dumpMeta): * b3/B3WasmBoundsCheckValue.h: (JSC::B3::WasmBoundsCheckValue::boundsType): (JSC::B3::WasmBoundsCheckValue::bounds): * b3/air/AirCode.h: * b3/air/AirCustom.h: (JSC::B3::Air::WasmBoundsCheckCustom::generate): * b3/testb3.cpp: (JSC::B3::testWasmBoundsCheck): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::createJSToWasmWrapper): remove dead code * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd (JSC::Wasm::Memory::initializePreallocations): verbose-only code, and copy-pasta bug 2017-04-19 Mark Lam <mark.lam@apple.com> B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg. https://bugs.webkit.org/show_bug.cgi?id=170973 <rdar://problem/30318657> Reviewed by Filip Pizlo. In the event of an arithmetic overflow on a binary sub instruction (where the result register is same as one of the operand registers), the CheckSub FTL operation will try to recover the original value in the clobbered result register. This recover is done by adding the other operand value to the result register. However, this recovery method only works if the width of the original value in the result register is less or equal to the width of the expected result. If the width of the original operand value (e.g. a JSInt32) is wider than the result (e.g. a machine Int32), then the sub operation would have zero extended the result and cleared the upper 32-bits of the result register. Recovery by adding back the other operand will not restore the JSValue tag in the upper word. This poses a problem if the stackmap value for the operand relies on that same clobbered register. The fix is to detect this potential scenario (i.e. width of the Def's arg < width of a stackmap value). If this condition is detected, we'll declare the stackmap value to be LateColdUse to ensure that the register allocator gives it a different register if needed so that it's not dependent on the clobbered register. * b3/B3CheckSpecial.cpp: (JSC::B3::CheckSpecial::forEachArg): * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::forEachArg): * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::forEachArgImpl): * b3/B3StackmapSpecial.h: 2017-04-19 JF Bastien <jfbastien@apple.com> Unreviewed, rolling out r215520. Broke Debian 8 Reverted changeset: "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts" https://bugs.webkit.org/show_bug.cgi?id=169458 http://trac.webkit.org/changeset/215520 2017-04-19 JF Bastien <jfbastien@apple.com> WebAssembly: limit slow memories https://bugs.webkit.org/show_bug.cgi?id=170825 Reviewed by Saam Barati. We limits the number of fast memories, partly because ASLR. The code then falls back to slow memories. It first tries to virtually allocated any declared maximum (and in there, physically the initial), and if that fails it tries to physically allocate the initial without any extra. This can still be used to cause a bunch of virtual allocation. This patch imposes soft limit on slow memories as well. The total virtual maximum for slow memories is set at the same (theoretical) value as that for fast memories. Anything exceeding that limit causes allocation/grow to fail. * wasm/WasmMemory.cpp: 2017-04-19 JF Bastien <jfbastien@apple.com> Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor https://bugs.webkit.org/show_bug.cgi?id=170875 Reviewed by Mark Lam. WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined copy constructor, and its implicitly-defined copy constructor is deleted because the default std::pair implementation on FreeBSD has a non-trivial copy constructor. /usr/include/c++/v1/__config says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep ABI compatibility: https://svnweb.freebsd.org/changeset/base/261801. That's a huge bummer, and I'm not a fan of broken stdlibs, but in this case it's pretty nice to have a custom named type anyways and costs nothing. * runtime/VMTraps.cpp: (JSC::findActiveVMAndStackBounds): (JSC::handleSigusr1): (JSC::handleSigtrap): 2017-04-19 Andy VanWagoner <thetalecrafter@gmail.com> [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts https://bugs.webkit.org/show_bug.cgi?id=169458 Reviewed by JF Bastien. Use udat_formatForFields to iterate through the parts of a formatted date string. * icu/unicode/udat.h: Update to 55.1. * icu/unicode/ufieldpositer.h: Added from 55.1. * runtime/IntlDateTimeFormat.cpp: (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string. (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string. * runtime/IntlDateTimeFormat.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts. 2017-04-19 JF Bastien <jfbastien@apple.com> WebAssembly: don't expose any WebAssembly JS object if JIT is off https://bugs.webkit.org/show_bug.cgi?id=170782 Reviewed by Saam Barati. It's unexpected that we expose the global WebAssembly object if no JIT is present because it can't be used to compile or instantiate. Other APIs such as Memory should also be Inaccessible in those circumstances. Also ensure that we don't pre-allocate fast memories if WebAssembly won't be used, and don't mark our intention to use a fast TLS slot for WebAssembly. * runtime/Options.cpp: (JSC::recomputeDependentOptions): 2017-04-19 Yusuke Suzuki <utatane.tea@gmail.com> r211670 broke double to int conversion. https://bugs.webkit.org/show_bug.cgi?id=170961 Reviewed by Mark Lam. In this patch, we take a template parameter way. While it reduces duplicate code, it effectively produces optimized code for operationToInt32SensibleSlow, and fixes kraken pbkdf2 regression on Linux. And this patch also fixes undefined behavior by changing int32_t to uint32_t. If exp is 31, missingOne is 1 << 31, INT32_MIN. Thus missingOne - 1 will cause int32_t overflow, and it is an undefined behavior. * runtime/MathCommon.cpp: (JSC::operationToInt32SensibleSlow): * runtime/MathCommon.h: (JSC::toInt32Internal): (JSC::toInt32): 2017-04-18 Mark Lam <mark.lam@apple.com> r211670 broke double to int conversion. https://bugs.webkit.org/show_bug.cgi?id=170961 <rdar://problem/31687696> Reviewed by Yusuke Suzuki. This is because operationToInt32SensibleSlow() assumes that left shifts of greater than 31 bits on an 31-bit value will produce a 0. However, the spec says that "if the value of the right operand is negative or is greater or equal to the number of bits in the promoted left operand, the behavior is undefined." See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators. This patch fixes this by restoring the check to prevent a shift of greater than 31 bits. It also consolidates the optimization in operationToInt32SensibleSlow() back into toInt32() so that we don't have 2 copies of the same code with only a slight variation. JSC benchmarks shows that performance is neutral with this patch. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileValueToInt32): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32): * runtime/MathCommon.cpp: (JSC::operationToInt32SensibleSlow): Deleted. * runtime/MathCommon.h: (JSC::toInt32): 2017-04-18 Oleksandr Skachkov <gskachkov@gmail.com> [ES6]. Implement Annex B.3.3 function hoisting rules for eval https://bugs.webkit.org/show_bug.cgi?id=163208 Reviewed by Saam Barati. Current patch implements Annex B.3.3 that is related to hoisting of function declaration in eval. https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation Function declaration in eval should create variable with function name in function scope where eval is invoked or bind to variable if it declared outside of the eval. If variable is created it can be removed by 'delete a;' command. If eval is invoke in block scope that contains let/const variable with the same name as function declaration we do not bind. This patch leads to the following behavior: ''' function foo() { { print(boo); // undefined eval('{ function boo() {}}'); print(boo); // function boo() {} } print(boo); // function boo() {} } function foobar() { { let boo = 10; print(boo); // 10; eval('{ function boo() {}}'); print(boo); // 10; } print(boo) // 10 } function bar() { { var boo = 10; print(boo); // 10 eval('{ function boo() {} }'); print(boo); // function boo() {} } print(boo); // function boo() {} } function bas() { { let boo = 10; eval(' { function boo() {} } '); print(boo); // 10 } print(boo); //Reference Error } ''' Current implementation relies on already implemented 'hoist function in sloppy mode' feature, with small changes. In short it works in following way: during hoisting of function with name S in eval, we are looking for first scope that contains space for variable with name S and if this scope has var type we bind function there To implement this feature was added bytecode ops: op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope or return undefined if variable can't be binded there. There is a corner case, hoist function in eval within catch block, that is not covered by this patch, and will be fixed in https://bugs.webkit.org/show_bug.cgi?id=168184 * bytecode/BytecodeDumper.cpp: (JSC::BytecodeDumper<Block>::dumpBytecode): * bytecode/BytecodeList.json: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeOffset): (JSC::computeDefsForBytecodeOffset): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finalizeLLIntInlineCaches): * bytecode/EvalCodeBlock.h: (JSC::EvalCodeBlock::functionHoistingCandidate): (JSC::EvalCodeBlock::numFunctionHoistingCandidates): * bytecode/UnlinkedEvalCodeBlock.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary): (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval): * bytecompiler/BytecodeGenerator.h: * 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::hasIdentifier): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval): * dfg/DFGSpeculativeJIT.h: (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/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval): * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): * jit/JIT.h: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): * llint/LowLevelInterpreter.asm: * parser/Parser.cpp: (JSC::Parser<LexerType>::parseFunctionDeclarationStatement): * parser/Parser.h: (JSC::Scope::getSloppyModeHoistedFunctions): (JSC::Parser::declareFunction): * runtime/CommonSlowPaths.cpp: (JSC::SLOW_PATH_DECL): * runtime/CommonSlowPaths.h: * runtime/EvalExecutable.h: (JSC::EvalExecutable::numFunctionHoistingCandidates): (JSC::EvalExecutable::numTopLevelFunctionDecls): (JSC::EvalExecutable::numberOfFunctionDecls): Deleted. * runtime/JSScope.cpp: (JSC::JSScope::resolve): (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval): * runtime/JSScope.h: 2017-04-18 Saam Barati <sbarati@apple.com> Follow up to address Mark's comments after r215453 Rubber stamped by Mark Lam. This patch chooses better names for things, adhering to Mark's suggestions in https://bugs.webkit.org/show_bug.cgi?id=139847 * bytecompiler/NodesCodegen.cpp: (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): * parser/NodeConstructors.h: (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::recordCallOrApplyDepth): (JSC::Parser<LexerType>::parseMemberExpression): * parser/Parser.h: (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope): (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild): (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope): (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted. (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted. (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted. 2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String) https://bugs.webkit.org/show_bug.cgi?id=170943 Reviewed by Geoffrey Garen. This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String). This has 2 great features. 1. MakeRope(ToString(Int32), String) is less clobbering. While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String) and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively executed because of ValueAdd's clobbering. 2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd. While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString operation. And later, MakeRope can fall into the fast path that just takes a string from a free list. It is simply faster than ValueAdd. We ensure that this patch shows performance improvement in attached benchmarks. baseline patched number-to-string-with-add-empty 16.2763+-3.3930 ^ 10.3142+-1.0967 ^ definitely 1.5780x faster number-to-string-with-add-in-loop 168.7621+-10.9738 ^ 15.5307+-3.3179 ^ definitely 10.8664x faster number-to-string-with-add 18.8557+-4.8292 11.6901+-2.5650 might be 1.6130x faster In SixSpeed, baseline patched template_string_tag.es5 200.1027+-20.6871 ^ 25.7925+-11.4052 ^ definitely 7.7582x faster template_string_tag.es6 331.3913+-12.1750 ^ 286.6958+-26.0441 ^ definitely 1.1559x faster for-of-array.es5 412.4344+-23.2517 ^ 272.8707+-47.2118 ^ definitely 1.5115x faster for-of-array.es6 504.0082+-65.5045 ^ 300.3277+-12.8193 ^ definitely 1.6782x faster * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::createToString): * dfg/DFGPredictionPropagationPhase.cpp: 2017-04-18 Michael Saboff <msaboff@apple.com> REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower https://bugs.webkit.org/show_bug.cgi?id=170881 Reviewed by Saam Barati. * runtime/ObjectConstructor.cpp: (JSC::objectConstructorSeal): (JSC::objectConstructorFreeze): Restored fast paths for final objects that don't have indexed properties. 2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Use Phantom for base instead of getter when inlining intrinsic getter https://bugs.webkit.org/show_bug.cgi?id=170947 Reviewed by Saam Barati. getter does not need to be live after OSR Exit. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::handleGetById): 2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, follow-up patch after r215459 https://bugs.webkit.org/show_bug.cgi?id=170940 Reviewed by Filip Pizlo. CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::emitFunctionChecks): (JSC::DFG::ByteCodeParser::handleGetById): 2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com> [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object https://bugs.webkit.org/show_bug.cgi?id=170940 Reviewed by Filip Pizlo. The second argument of CheckCell is not used in meaningful way. It is just *use* the node. The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and prevent us from eliminating object allocations. Actually, it materializes Array iterator when inlining `next()`. Instead, we should use Phantom in such a case. It improves destructuring.es6 in SixSpeed 2.5x. destructuring.es6 308.5184+-25.3490 ^ 119.5680+-15.0520 ^ definitely 2.5803x faster Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed tests each one in isolated way. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::emitFunctionChecks): (JSC::DFG::ByteCodeParser::handleGetById): 2017-04-18 Yusuke Suzuki <utatane.tea@gmail.com> [JSC][GTK] glib RunLoop does not accept negative start interval https://bugs.webkit.org/show_bug.cgi?id=170775 Reviewed by Saam Barati. * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::scheduleTimer): 2017-04-17 Saam Barati <sbarati@apple.com> BytecodeGenerator ".call" and ".apply" is exponential in nesting depth https://bugs.webkit.org/show_bug.cgi?id=139847 <rdar://problem/19321122> Reviewed by Oliver Hunt. The BytecodeGenerator's .apply(...) and .call(...) code would emit bytecode for the evaluation of its arguments twice. This is exponential, specifically, 2^n, where n is the nesting depth of .call(...) or .apply(...) inside other .call(...) or .apply(...). The reason we emit code for the arguments twice is that we try to emit efficient code for when .call or .apply is Function.prototype.call or Function.prototype.apply. Because of this, we compare .call/.apply to Function.prototype.call/.apply, and if they're the same, we emit a specialized function call in bytecode. Otherwise, we emit the generalized version. This patch makes it so that each .call(...) and .apply(...) records its max inner nesting depth. Then, we only perform the optimization for the bottom k (where k = 6) layers of the nesting tree. The reason we apply the optimization to the bottom k layers instead of top k layers is that we'll produce less code this way. * bytecompiler/NodesCodegen.cpp: (JSC::CallFunctionCallDotNode::emitBytecode): (JSC::ApplyFunctionCallDotNode::emitBytecode): * parser/ASTBuilder.h: (JSC::ASTBuilder::makeFunctionCallNode): * parser/NodeConstructors.h: (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode): (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode): * parser/Nodes.h: * parser/Parser.cpp: (JSC::recordCallOrApplyDepth): (JSC::Parser<LexerType>::parseMemberExpression): * parser/Parser.h: (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): (JSC::Parser::CallOrApplyDepth::maxChildDepth): (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): * parser/SyntaxChecker.h: (JSC::SyntaxChecker::makeFunctionCallNode): 2017-04-17 Mark Lam <mark.lam@apple.com> JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too. https://bugs.webkit.org/show_bug.cgi?id=170896 <rdar://problem/31651319> Reviewed by JF Bastien and Keith Miller. * runtime/JSArray.cpp: (JSC::JSArray::appendMemcpy): 2017-04-17 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Doesn't show size of compressed content correctly https://bugs.webkit.org/show_bug.cgi?id=155112 <rdar://problem/25006728> Reviewed by Alex Christensen and Timothy Hatcher. * inspector/protocol/Network.json: New, exact size metrics, available after the load completes. 2017-04-17 Youenn Fablet <youenn@apple.com> Disable outdated WritableStream API https://bugs.webkit.org/show_bug.cgi?id=170749 <rdar://problem/31446233> Reviewed by Alex Christensen. * Configurations/FeatureDefines.xcconfig: 2017-04-17 Yusuke Suzuki <utatane.tea@gmail.com> [JSCOnly] Fix build failures in macOS https://bugs.webkit.org/show_bug.cgi?id=170887 Reviewed by Alex Christensen. Align ICU header configuration to MacCMake port. * PlatformJSCOnly.cmake: 2017-04-17 JF Bastien <jfbastien@apple.com> B3: don't allow unsigned offsets in Value https://bugs.webkit.org/show_bug.cgi?id=170692 Reviewed by Filip Pizlo. MemoryValue and similar B3 opcode classes always expects a signed offset. Giving it an out-of-bounds unsigned offset causes implementation-defined behavior, which can cause badness as I just fixed in WebAssembly. This patch makes it impossible to create a Value opcodes with an unsigned value, or with an overly-large value. * b3/B3AtomicValue.cpp: (JSC::B3::AtomicValue::AtomicValue): * b3/B3AtomicValue.h: * b3/B3Common.h: (JSC::B3::isRepresentableAs): * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::scaleForShl): (JSC::B3::Air::LowerToAir::effectiveAddr): (JSC::B3::Air::LowerToAir::addr): (JSC::B3::Air::LowerToAir::tryAppendLea): * b3/B3MemoryValue.cpp: (JSC::B3::MemoryValue::isLegalOffsetImpl): (JSC::B3::MemoryValue::MemoryValue): * b3/B3MemoryValue.h: * b3/B3MemoryValueInlines.h: (JSC::B3::MemoryValue::isLegalOffsetImpl): * b3/B3MoveConstants.cpp: * b3/B3ReduceStrength.cpp: * b3/B3StackmapSpecial.cpp: (JSC::B3::StackmapSpecial::repForArg): * b3/B3Value.h: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::stackAddrImpl): * b3/air/AirArg.h: (JSC::B3::Air::Arg::addr): (JSC::B3::Air::Arg::stack): (JSC::B3::Air::Arg::callArg): (JSC::B3::Air::Arg::stackAddr): (JSC::B3::Air::Arg::index): (JSC::B3::Air::Arg::offset): (JSC::B3::Air::Arg::isValidAddrForm): (JSC::B3::Air::Arg::isValidIndexForm): (JSC::B3::Air::Arg::asTrustedImm32): (JSC::B3::Air::Arg::asAddress): (JSC::B3::Air::Arg::asBaseIndex): * b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * b3/testb3.cpp: (JSC::B3::testMulArgStore): (JSC::B3::testStore32): (JSC::B3::testStoreConstant): (JSC::B3::testStoreConstantPtr): (JSC::B3::testStoreAddLoad32): (JSC::B3::testStoreAddLoadImm32): (JSC::B3::testStoreAddLoad8): (JSC::B3::testStoreAddLoadImm8): (JSC::B3::testStoreAddLoad16): (JSC::B3::testStoreAddLoadImm16): (JSC::B3::testStoreAddLoad64): (JSC::B3::testStoreAddLoadImm64): (JSC::B3::testStoreAddLoad32Index): (JSC::B3::testStoreAddLoadImm32Index): (JSC::B3::testStoreAddLoad64Index): (JSC::B3::testStoreAddLoadImm64Index): (JSC::B3::testStoreSubLoad): (JSC::B3::testStoreAddLoadInterference): (JSC::B3::testStoreAddAndLoad): (JSC::B3::testStoreNegLoad32): (JSC::B3::testStoreNegLoadPtr): (JSC::B3::testLoadOffset): (JSC::B3::testLoadOffsetNotConstant): (JSC::B3::testLoadOffsetUsingAdd): (JSC::B3::testLoadOffsetUsingAddInterference): (JSC::B3::testLoadOffsetUsingAddNotConstant): (JSC::B3::testStoreLoadStackSlot): (JSC::B3::testLoad): (JSC::B3::testInterpreter): (JSC::B3::testTrappingStore): (JSC::B3::testTrappingLoadAddStore): (JSC::B3::testWasmAddress): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::emitLoadOp): (JSC::Wasm::B3IRGenerator::emitStoreOp): 2017-04-16 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js https://bugs.webkit.org/show_bug.cgi?id=170882 Reviewed by Saam Barati. * runtime/ObjectPrototype.cpp: (JSC::objectProtoFuncToLocaleString): We should be using the this value without ToObject conversion both when getting the potential accessor and calling it. In strict mode, the this value will remain its simple value, in non-strict it is still converted. 2017-04-16 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js https://bugs.webkit.org/show_bug.cgi?id=170888 Reviewed by Saam Barati. * runtime/ExceptionHelpers.h: * runtime/ExceptionHelpers.cpp: (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction): Fix up this function name. * runtime/JSObject.cpp: (JSC::callToPrimitiveFunction): When called with @@isPrimitive, bail on undefined or null and throw a type error if the value is not callable. (JSC::JSObject::toPrimitive): Use throw scope to check for exception. 2017-04-16 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/expressions/tagged-template/template-object.js https://bugs.webkit.org/show_bug.cgi?id=170878 Reviewed by Saam Barati. * runtime/JSArray.cpp: (JSC::JSArray::put): The fast path for setting an Array's length should check if length is writable before checking for and possibly throwing a RangeError. 2017-04-16 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js https://bugs.webkit.org/show_bug.cgi?id=170879 Reviewed by Saam Barati. * runtime/StringObject.h: * runtime/StringObject.cpp: (JSC::StringObject::getOwnPropertyNames): (JSC::StringObject::getOwnNonIndexPropertyNames): Ensure 'length' comes after all indexed properties by moving it out to the getOwnNonIndexPropertyNames method which is called inside of getOwnPropertyNames after JSObject handles indices. 2017-04-16 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js https://bugs.webkit.org/show_bug.cgi?id=170884 Reviewed by Yusuke Suzuki. * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::addFunctionProperties): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): Give symbol property functions proper function names. This addresses function.name but not function.toString(). 2017-04-15 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/global-code/new.target-arrow.js https://bugs.webkit.org/show_bug.cgi?id=170872 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser<LexerType>::Parser): Mark the global code scope. (JSC::Parser<LexerType>::parseMemberExpression): If new.target is detected in an arrow function defined in global scope throw a SyntaxError. * parser/Parser.h: (JSC::Scope::Scope): (JSC::Scope::setIsGlobalCodeScope): (JSC::Scope::isGlobalCodeScope): Marker for a global code scope. * parser/ParserModes.h: (JSC::isModuleParseMode): (JSC::isProgramParseMode): (JSC::isProgramOrModuleParseMode): Helper for detecting global code based on parse mode. 2017-04-14 Nikita Vasilyev <nvasilyev@apple.com> Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly https://bugs.webkit.org/show_bug.cgi?id=170760 Reviewed by Joseph Pecoraro. Add payloadLength property, which is used to display size. When payloadLength is unavailable, it is calculated from payloadData by Web Inspector frontend. This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect. * inspector/protocol/Network.json: 2017-04-14 Saam Barati <sbarati@apple.com> ParseInt intrinsic in DFG backend doesn't properly flush its operands https://bugs.webkit.org/show_bug.cgi?id=170865 Reviewed by Mark Lam and Geoffrey Garen. The DFG backend code needed to first call .gpr()/.jsValueRegs() before calling flushRegisters(), or the input JSValueOperand would not be flushed. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileParseInt): 2017-04-14 Mark Lam <mark.lam@apple.com> Update architectures in xcconfig files. https://bugs.webkit.org/show_bug.cgi?id=170867 <rdar://problem/31628104> Reviewed by Joseph Pecoraro. * Configurations/Base.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/JavaScriptCore.xcconfig: * Configurations/ToolExecutable.xcconfig: 2017-04-14 Keith Miller <keith_miller@apple.com> WebAssembly: B3IRGenerator should use phis for result types https://bugs.webkit.org/show_bug.cgi?id=170863 Reviewed by Filip Pizlo. Currently, we use variables for the result types of control flow in Wasm. We did this originally since we weren't sure that the phis we generated would be optimal. Since then, we have verified that the edges in wasm control flow ensure that each upsilon will dominate its phi so we don't need to use variables. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::ControlData::ControlData): (JSC::Wasm::B3IRGenerator::addTopLevel): (JSC::Wasm::B3IRGenerator::addBlock): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::unify): 2017-04-14 Alex Christensen <achristensen@webkit.org> Fix Windows build after r215368. https://bugs.webkit.org/show_bug.cgi?id=170641 * CMakeLists.txt: Add new directory containing files needed in WebCore. 2017-04-14 Caitlin Potter <caitp@igalia.com> [JSC] use ExpressionErrorClassifier for AwaitExpression operand https://bugs.webkit.org/show_bug.cgi?id=170844 Reviewed by Saam Barati. In parseAssignmentExpression(), several cover grammars are handled, and use ExpressionErrorClassifier to record hints about which grammars to try. In parseAwaitExpression(), the hints recorded during parsing of the operand need to be discarded, because if they propagate to the outer parseAssignmentExpression(), the hints will lead the parser down invalid branches that should be skipped. This change adds an additional ExpressionErrorClassifier to parseAwaitExpression(), in order to discard hints recorded trying to parse the operand. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseAwaitExpression): 2017-04-14 Saam Barati <sbarati@apple.com> WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called https://bugs.webkit.org/show_bug.cgi?id=170641 Reviewed by Keith Miller. There is an unlikely race when a CodeBlock compilation fails, the module compiles a new CodeBlock for that memory mode, all while the CodeBlock is notifying its callbacks that it has finished. There is a chance that the Module could deref its failed CodeBlock at that point, destroying it, before the callbacks were able to grab a Ref to the CodeBlock. This patch fixes the race by having the callbacks ref the CodeBlock. This patch also has the Plan clear out all of its callbacks once it gets completed. This adds an extra defense to anybody that grabs refs to the Plan in the callback. * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::compileAsync): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::complete): 2017-04-13 Filip Pizlo <fpizlo@apple.com> Air::RegLiveness should be constraint-based https://bugs.webkit.org/show_bug.cgi?id=170817 Reviewed by Saam Barati. Previously, I changed the Air liveness analyses based on Air::Liveness<> to be constraint-based and this was a significant speed-up. Now I'm adding the same functionality to RegLiveness. This is a 1% speed-up on wasm B3 -O1 compile times. * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirLivenessAdapter.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::prepareToCompute): (JSC::B3::Air::LivenessAdapter::actionsAt): * b3/air/AirRegLiveness.cpp: (JSC::B3::Air::RegLiveness::RegLiveness): (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness): (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute): (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted. * b3/air/AirRegLiveness.h: (JSC::B3::Air::RegLiveness::Actions::Actions): (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase): (JSC::B3::Air::RegLiveness::LocalCalcBase::live): (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive): (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): (JSC::B3::Air::RegLiveness::LocalCalc::execute): (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted. (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted. 2017-04-13 JF Bastien <jfbastien@apple.com> WebAssembly: fix windows build https://bugs.webkit.org/show_bug.cgi?id=170832 Reviewed by Mark Lam. My previous patch re-declared isIOS which AssemblerCommon.h already provided, and which was already included by Options.cpp. * runtime/Options.cpp: 2017-04-13 Saam Barati <sbarati@apple.com> WebAssembly: We should be able to postMessage a JSWebAssemblyModule https://bugs.webkit.org/show_bug.cgi?id=170573 Reviewed by Filip Pizlo. This patch adds a callback to JSRunLoopTimer to notify clients that a timer has been set. This is used inside WorkerRunLoop in WebCore so that its RunLoop can perform an iteration when it sees that a timer got set. * JavaScriptCore.xcodeproj/project.pbxproj: * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::addTimerSetNotification): (JSC::JSRunLoopTimer::removeTimerSetNotification): * runtime/JSRunLoopTimer.h: * wasm/WasmCodeBlock.cpp: (JSC::Wasm::CodeBlock::~CodeBlock): * wasm/WasmCodeBlock.h: * wasm/WasmModule.cpp: (JSC::Wasm::Module::~Module): (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): (JSC::Wasm::makeValidationCallback): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::validateSyncImpl): Deleted. (JSC::Wasm::Module::makeValidationCallback): Deleted. * wasm/WasmModule.h: (JSC::Wasm::Module::validateSync): Deleted. (JSC::Wasm::Module::validateAsync): Deleted. (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted. (JSC::Wasm::Module::nonNullCodeBlock): Deleted. * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::create): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): Deleted. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::source): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::source): Deleted. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyModulePrototype.cpp: 2017-04-13 Mark Lam <mark.lam@apple.com> Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister(). https://bugs.webkit.org/show_bug.cgi?id=170661 <rdar://problem/31579046> Reviewed by Filip Pizlo. Previously, we were using flush() to flush the outermost frame's scopeRegister. This is incorrect because flush() expects the VirtualRegister value passed to it to be that of the top most inlined frame. In the event that we reach a terminal condition while inside an inlined frame, flush() will end up flushing the wrong register. The fix is simply to use flushDirect() instead. * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::flush): 2017-04-13 Andy VanWagoner <thetalecrafter@gmail.com> Change Intl prototypes to plain objects https://bugs.webkit.org/show_bug.cgi?id=168178 Reviewed by JF Bastien. * builtins/StringPrototype.js: (localeCompare): Create default Collator once instead of using prototype. * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::IntlCollatorPrototype): * runtime/IntlCollatorPrototype.h: * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype): * runtime/IntlDateTimeFormatPrototype.h: * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype): * runtime/IntlNumberFormatPrototype.h: * runtime/IntlObject.cpp: (JSC::IntlObject::finishCreation): Don't set constructor on each prototype. 2017-04-13 Oliver Hunt <oliver@apple.com> allocationSize should use safe arithmetic by default https://bugs.webkit.org/show_bug.cgi?id=170804 Reviewed by JF Bastien. Make all allocationSize() functions work in terms of Checked<size_t> * runtime/DirectArguments.h: (JSC::DirectArguments::offsetOfSlot): (JSC::DirectArguments::allocationSize): * runtime/HashMapImpl.h: (JSC::HashMapBuffer::allocationSize): * runtime/JSArray.h: (JSC::JSArray::allocationSize): * runtime/JSArrayBufferView.h: (JSC::JSArrayBufferView::allocationSize): * runtime/JSAsyncFunction.h: (JSC::JSAsyncFunction::allocationSize): * runtime/JSFixedArray.h: (JSC::JSFixedArray::allocationSize): * runtime/JSFunction.h: (JSC::JSFunction::allocationSize): * runtime/JSGeneratorFunction.h: (JSC::JSGeneratorFunction::allocationSize): * runtime/JSModuleNamespaceObject.h: * runtime/JSObject.h: (JSC::JSFinalObject::allocationSize): * runtime/JSWrapperObject.h: (JSC::JSWrapperObject::allocationSize): * runtime/ScopedArguments.h: (JSC::ScopedArguments::allocationSize): * runtime/VM.h: (JSC::ScratchBuffer::allocationSize): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): (JSC::JSWebAssemblyCodeBlock::allocationSize): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::allocationSize): 2017-04-13 JF Bastien <jfbastien@apple.com> WebAssembly: manage memory better https://bugs.webkit.org/show_bug.cgi?id=170628 Reviewed by Keith Miller, Michael Saboff. WebAssembly fast memories weren't managed very well. This patch refactors it and puts us in a good position to further improve our fast memory handling in the future. We now cache fast memories at a process granularity, but make sure that they don't consume dirty pages. We add a cap to the total number of allocated fast memories to avoid ASLR degradation. We teach the GC about memories as a kind of resource it should care about because it didn't have visibility into the amount of memory each represented. This allows benchmarks which allocate memories back-to-back to reliably get fast memories 100% of the time, even on a system under load, which wasn't the case before. This reliability yields roughly 8% perf bump on x86-64 WasmBench. The GC heuristic is as follows: each time we allocate a fast memory we notify the GC, which then keeps track of the total number of fast memories allocated since it last GC'd. We separately keep track of the total number of fast memories which have ever existed at any point in time (cached + allocated). This is a monotonically-increasing high watermark. The GC will force a full collection if, since it last ran, half or more of the high watermark of fast memories was allocated. At the same time, if we fail obtaining a fast memory from the cache we do a GC to try to find one. If that fails we'll allocate a new one (this can also fail, then we go to slow memory). This can also be improved, but it's a good start. This currently disables fast memories on iOS because getting fast memories isn't a guaranteed thing. Rather, we get quite a few of them and achieve significant speedups, but benchmarks which allocate memories back-to-back end up falling behind because the GC can conservatively hold onto memories, which then yields a perf cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18 fast memories when in theory it should get all of them fast (as MacOS does). The patch significantly improves the state of iOS though, and in a follow-up we could re-enable fast memories. Part of this good positioning is a facility to pre-allocate fast memories very early at startup, before any fragmentation occurs. This is currently disabled but worked extremely reliably on iOS. Once we fix the above issues we'll want to re-visit and turn on pre-allocation. We also avoid locking for fast memory identification when performing signal handling. I'm very nervous about acquiring locks in a signal handler because in general signals can happen when we've messed up. This isn't the case with fast memories: we're raising a signal on purpose and handling it. However this doesn't mean we won't mess up elsewhere! This will get more complicated once we add support for multiple threads sharing memories and being able to grow their memories. One example: the code calls CRASH(), which executes the following code in release: *(int *)(uintptr_t)0xbbadbeef = 0; This is a segfault, which our fast memory signal handler tries to handle. It does so by first figuring out whether 0xbbadbeef is in a fast memory region, reqiring a lock. If we CRASH() while holding the lock then our thread self-deadlocks, giving us no crash report and a bad user experience. Avoiding a lock therefore it's not about speed or reduced contention. In fact, I'd use something else than a FIFO if these were a concern. We're also doing syscalls, which dwarf any locking cost. We now only allocate 4GiB + redzone of 64k * 128 for fast memories instead of 8GiB. This patch reuses the logic from B3::WasmBoundsCheck to perform bounds checks when accesses could exceed the redzone. We'll therefore benefit from CSE goodness when it reaches WasmBoundsCheck. See bug #163469. * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in bug #170692 to prevent this type of bug once and for all. (JSC::B3::Air::LowerToAir::lower): * b3/B3Validate.cpp: update WasmBoundsCheck validation. * b3/B3Value.cpp: (JSC::B3::Value::effects): update WasmBoundsCheck effects. * b3/B3WasmBoundsCheckValue.cpp: (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue): (JSC::B3::WasmBoundsCheckValue::redzoneLimit): (JSC::B3::WasmBoundsCheckValue::dumpMeta): * b3/B3WasmBoundsCheckValue.h: (JSC::B3::WasmBoundsCheckValue::maximum): * b3/air/AirCustom.cpp: (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm): * b3/testb3.cpp: (JSC::B3::testWasmBoundsCheck): * heap/Heap.cpp: (JSC::Heap::Heap): (JSC::Heap::reportWebAssemblyFastMemoriesAllocated): (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold): (JSC::Heap::updateAllocationLimits): (JSC::Heap::didAllocateWebAssemblyFastMemories): (JSC::Heap::shouldDoFullCollection): (JSC::Heap::collectIfNecessaryOrDefer): * heap/Heap.h: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/Options.cpp: * runtime/Options.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::emitLoadOp): (JSC::Wasm::B3IRGenerator::emitStoreOp): (JSC::Wasm::createJSToWasmWrapper): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * wasm/WasmMemory.cpp: Rewrite. (JSC::Wasm::makeString): (JSC::Wasm::Memory::initializePreallocations): (JSC::Wasm::Memory::createImpl): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::~Memory): (JSC::Wasm::Memory::fastMappedRedzoneBytes): (JSC::Wasm::Memory::fastMappedBytes): (JSC::Wasm::Memory::maxFastMemoryCount): (JSC::Wasm::Memory::addressIsInActiveFastMemory): (JSC::Wasm::Memory::grow): * wasm/WasmMemory.h: (Memory::maxFastMemoryCount): (Memory::addressIsInActiveFastMemory): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::globalMemoryByteSize): * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): (JSC::JSWebAssemblyMemory::finishCreation): (JSC::JSWebAssemblyMemory::visitChildren): 2017-04-13 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use proper ifdef guard for code using MachineContext https://bugs.webkit.org/show_bug.cgi?id=170800 Reviewed by Carlos Alberto Lopez Perez. This patch drops MachineContext use if it is not available. This situation can be considered like, building WebKit with musl. In that case, we simply disable features that rely on MachineContext. Examples are wasm fast memory, sampling profiler, and code profiling. * runtime/Options.cpp: (JSC::overrideDefaults): * tools/CodeProfiling.cpp: (JSC::CodeProfiling::begin): (JSC::CodeProfiling::end): Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded. This patch just includes such platforms. * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::enableFastMemory): 2017-04-12 Dan Bernstein <mitz@apple.com> [Mac] Future-proof .xcconfig files https://bugs.webkit.org/show_bug.cgi?id=170802 Reviewed by Tim Horton. * Configurations/Base.xcconfig: * Configurations/DebugRelease.xcconfig: * Configurations/FeatureDefines.xcconfig: * Configurations/Version.xcconfig: 2017-04-12 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/NativeErrors/EvalError/proto.js https://bugs.webkit.org/show_bug.cgi?id=170668 Reviewed by Keith Miller. * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): The [[Prototype]] of NativeError Constructor's should be the %Error%. https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors 2017-04-12 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/language/literals/regexp/u-dec-esc.js https://bugs.webkit.org/show_bug.cgi?id=170687 Reviewed by Michael Saboff. * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): * yarr/YarrPattern.cpp: (JSC::Yarr::YarrPattern::errorMessage): (JSC::Yarr::YarrPattern::compile): * yarr/YarrPattern.h: In unicoe patterns, invalid backreferences are an error. 2017-04-12 Filip Pizlo <fpizlo@apple.com> Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp https://bugs.webkit.org/show_bug.cgi?id=170799 Reviewed by Michael Saboff and Keith Miller. When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by putting their declarations in AirAllocateStackByGraphColoring.h. That was pretty weird. This patch moves a family of stack allocation helper functions out of AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The linear scan stack allocator no longer has to include the other stack allocator's header, which addresses my OCD. I moved the functions transitively reachable from the two functions that the linear scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl") and short descriptive comments. I think that such comments are useful in code that is doing a convoluted version of some theoretical concept. No behavior change. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirAllocateStackByGraphColoring.cpp: (JSC::B3::Air::allocateStackByGraphColoring): (JSC::B3::Air::allocateEscapedStackSlots): Deleted. (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted. * b3/air/AirAllocateStackByGraphColoring.h: * b3/air/AirStackAllocation.cpp: Added. (JSC::B3::Air::attemptAssignment): (JSC::B3::Air::assign): (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize): (JSC::B3::Air::allocateEscapedStackSlots): (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): * b3/air/AirStackAllocation.h: Added. 2017-04-12 Filip Pizlo <fpizlo@apple.com> B3 -O1 should not allocateStackByGraphColoring https://bugs.webkit.org/show_bug.cgi?id=170742 Reviewed by Keith Miller. One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to this would be to make that phase cheaper. But it's weird that this phase reruns liveness after register allocation already ran liveness. If only it could reuse the liveness computed by register allocation then it would run a lot faster. At -O2, we do not want this, since we run phases between register allocation and stack allocation, and those phases are free to change the liveness of spill slots (in fact, fixObviousSpills will both shorten and lengthen live ranges because of load and store elimination, respectively). But at -O1, we don't really need to run any phases between register and stack allocation. This changes Air's backend in the following ways: - Linear scan does stack allocation. This means that we don't need to run allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but we don't run the expensive part of it (liveness->interference->coalescing->coloring). This is a speed-up because we only run liveness once and reuse it for both register and stack allocation. - Phases that previously ran between register and stack allocation are taken care of, each in its own special way: -> handleCalleSaves: this is now a utility function called by both allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan. -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done. -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because it could change register usage (vis a vis callee saves) and it could introduce spill slots. I changed this phase to have a secondary mode for when it runs after stack allocation. - The part of allocateStackByGraphColoring that lowered stack addresses and took care of the call arg area is now a separate phase called lowerStackArgs. We run this phase regardless of optimization level. It's a cheap and general lowering. This also removes spillEverything, because we never use that phase, we never test it, and it got in the way in this refactoring. This is a 21% speed-up on wasm -O1 compile times. This does not significantly change -O1 throughput. We had already disabled allocateStack's most important optimization (spill coalescing). This probably regresses average stack frame size, but I didn't measure by how much. Stack frame size is really not that important. The algorithm in allocateStackByGraphColoring is about much more than optimal frame size; it also tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course it coalesces. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Procedure.cpp: (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList): (JSC::B3::Procedure::calleeSaveRegisters): Deleted. * b3/B3Procedure.h: * b3/B3StackmapGenerationParams.cpp: (JSC::B3::StackmapGenerationParams::unavailableRegisters): * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp. (JSC::B3::Air::allocateRegistersAndStackByLinearScan): (JSC::B3::Air::allocateRegistersByLinearScan): Deleted. * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h. * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed. * b3/air/AirAllocateRegistersByLinearScan.h: Removed. * b3/air/AirAllocateStackByGraphColoring.cpp: (JSC::B3::Air::allocateEscapedStackSlots): (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): (JSC::B3::Air::allocateStackByGraphColoring): * b3/air/AirAllocateStackByGraphColoring.h: * b3/air/AirArg.cpp: (JSC::B3::Air::Arg::stackAddr): * b3/air/AirArg.h: (JSC::B3::Air::Arg::stackAddr): Deleted. * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addStackSlot): (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList): (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList): (JSC::B3::Air::Code::dump): * b3/air/AirCode.h: (JSC::B3::Air::Code::setStackIsAllocated): (JSC::B3::Air::Code::stackIsAllocated): (JSC::B3::Air::Code::calleeSaveRegisters): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): (JSC::B3::Air::generate): * b3/air/AirHandleCalleeSaves.cpp: (JSC::B3::Air::handleCalleeSaves): * b3/air/AirHandleCalleeSaves.h: * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerStackArgs.cpp: Added. (JSC::B3::Air::lowerStackArgs): * b3/air/AirLowerStackArgs.h: Added. * b3/testb3.cpp: (JSC::B3::testPinRegisters): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * jit/RegisterAtOffsetList.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2017-04-12 Michael Saboff <msaboff@apple.com> Implement Object.isFrozen() and Object.isSealed() per ECMA spec https://bugs.webkit.org/show_bug.cgi?id=170753 Reviewed by Mark Lam. * runtime/ObjectConstructor.cpp: (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard. (JSC::objectConstructorSeal): (JSC::objectConstructorFreeze): Eliminated incomplete special handling of JSFinalObjects. (JSC::objectConstructorIsSealed): (JSC::objectConstructorIsFrozen): Refactored to use the new testIntegrityLevel() helper. 2017-04-12 Yusuke Suzuki <utatane.tea@gmail.com> Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT) https://bugs.webkit.org/show_bug.cgi?id=170770 Rubber stamped by Mark Lam. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::Registers::framePointer): (JSC::MachineThreads::MachineThread::Registers::instructionPointer): (JSC::MachineThreads::MachineThread::Registers::llintPC): * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::llintInstructionPointer): 2017-04-12 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT) https://bugs.webkit.org/show_bug.cgi?id=170770 Reviewed by Mark Lam. We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And we clean up heap/MachineStackMarker.cpp by using MachineContext functions. * heap/MachineStackMarker.cpp: (JSC::MachineThreads::MachineThread::Registers::stackPointer): (JSC::MachineThreads::MachineThread::Registers::framePointer): (JSC::MachineThreads::MachineThread::Registers::instructionPointer): (JSC::MachineThreads::MachineThread::Registers::llintPC): * heap/MachineStackMarker.h: * runtime/MachineContext.h: (JSC::MachineContext::stackPointer): (JSC::MachineContext::framePointer): (JSC::MachineContext::instructionPointer): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::llintInstructionPointer): 2017-04-12 Yusuke Suzuki <utatane.tea@gmail.com> [WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one https://bugs.webkit.org/show_bug.cgi?id=170502 Reviewed by Mark Lam. * API/tests/CompareAndSwapTest.cpp: (testCompareAndSwap): * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::run): * bytecode/SuperSampler.cpp: (JSC::initializeSuperSampler): * dfg/DFGWorklist.cpp: * disassembler/Disassembler.cpp: * heap/Heap.cpp: (JSC::Heap::lastChanceToFinalize): (JSC::Heap::notifyIsSafeToCollect): * heap/Heap.h: * heap/MachineStackMarker.cpp: (JSC::MachineThreads::~MachineThreads): (JSC::MachineThreads::addCurrentThread): (JSC::MachineThreads::removeThread): (JSC::MachineThreads::removeThreadIfFound): (JSC::MachineThreads::MachineThread::MachineThread): (JSC::MachineThreads::MachineThread::getRegisters): (JSC::MachineThreads::MachineThread::Registers::stackPointer): (JSC::MachineThreads::MachineThread::Registers::framePointer): (JSC::MachineThreads::MachineThread::Registers::instructionPointer): (JSC::MachineThreads::MachineThread::Registers::llintPC): (JSC::MachineThreads::MachineThread::captureStack): (JSC::MachineThreads::tryCopyOtherThreadStack): (JSC::MachineThreads::tryCopyOtherThreadStacks): (pthreadSignalHandlerSuspendResume): Deleted. (JSC::threadData): Deleted. (JSC::MachineThreads::Thread::Thread): Deleted. (JSC::MachineThreads::Thread::createForCurrentThread): Deleted. (JSC::MachineThreads::Thread::operator==): Deleted. (JSC::MachineThreads::machineThreadForCurrentThread): Deleted. (JSC::MachineThreads::ThreadData::ThreadData): Deleted. (JSC::MachineThreads::ThreadData::~ThreadData): Deleted. (JSC::MachineThreads::ThreadData::suspend): Deleted. (JSC::MachineThreads::ThreadData::resume): Deleted. (JSC::MachineThreads::ThreadData::getRegisters): Deleted. (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted. (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted. (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted. (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted. (JSC::MachineThreads::ThreadData::freeRegisters): Deleted. (JSC::MachineThreads::ThreadData::captureStack): Deleted. * heap/MachineStackMarker.h: (JSC::MachineThreads::MachineThread::suspend): (JSC::MachineThreads::MachineThread::resume): (JSC::MachineThreads::MachineThread::threadID): (JSC::MachineThreads::MachineThread::stackBase): (JSC::MachineThreads::MachineThread::stackEnd): (JSC::MachineThreads::threadsListHead): (JSC::MachineThreads::Thread::operator!=): Deleted. (JSC::MachineThreads::Thread::suspend): Deleted. (JSC::MachineThreads::Thread::resume): Deleted. (JSC::MachineThreads::Thread::getRegisters): Deleted. (JSC::MachineThreads::Thread::freeRegisters): Deleted. (JSC::MachineThreads::Thread::captureStack): Deleted. (JSC::MachineThreads::Thread::platformThread): Deleted. (JSC::MachineThreads::Thread::stackBase): Deleted. (JSC::MachineThreads::Thread::stackEnd): Deleted. * jit/ICStats.cpp: (JSC::ICStats::ICStats): (JSC::ICStats::~ICStats): * jit/ICStats.h: * jsc.cpp: (functionDollarAgentStart): (startTimeoutThreadIfNeeded): * runtime/JSLock.cpp: (JSC::JSLock::lock): * runtime/JSLock.h: (JSC::JSLock::ownerThread): (JSC::JSLock::currentThreadIsHoldingLock): * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::isValidFramePointer): (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::createThreadIfNecessary): (JSC::SamplingProfiler::takeSample): * runtime/SamplingProfiler.h: * runtime/VM.h: (JSC::VM::ownerThread): * runtime/VMTraps.cpp: (JSC::findActiveVMAndStackBounds): (JSC::VMTraps::SignalSender::send): (JSC::VMTraps::fireTrap): 2017-04-11 Dean Jackson <dino@apple.com> Disable outdated WritableStream API https://bugs.webkit.org/show_bug.cgi?id=170749 <rdar://problem/31446233> Reviewed by Tim Horton. The API we implement is no longer accurate. Disable it until we are compatible with the new specification * Configurations/FeatureDefines.xcconfig: 2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for CF ports after r215241 https://bugs.webkit.org/show_bug.cgi?id=170725 * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::nextFireTime): 2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com> [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime https://bugs.webkit.org/show_bug.cgi?id=170725 Reviewed by Sam Weinig. This patch makes GCActivityCallback return MonotonicTime instead of raw double value. * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::nextFireTime): * heap/GCActivityCallback.h: 2017-04-11 Guillaume Emont <guijemont@igalia.com> [jsc] Add missing MacroAssemblerMIPS::or32() implementation https://bugs.webkit.org/show_bug.cgi?id=169714 Reviewed by Michael Catanzaro. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::or32): Added or32(TrustedImm32, Address). 2017-04-11 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/annexB/language/comments/multi-line-html-close.js https://bugs.webkit.org/show_bug.cgi?id=170648 Reviewed by Keith Miller. * parser/Lexer.cpp: (JSC::Lexer<T>::lex): A multi-line comment that contains a line terminator is itself treated like a line terminator. An HTML Close Comment that comes after it can therefore treat it like it is at the start of a line, because it was immediately preceeded by the equivalent of a line terminator. 2017-04-11 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/built-ins/Array/S15.4.3_A2.2.js https://bugs.webkit.org/show_bug.cgi?id=170652 Reviewed by Michael Saboff. * runtime/ArrayConstructor.cpp: (JSC::ArrayConstructor::finishCreation): * runtime/BooleanConstructor.cpp: (JSC::BooleanConstructor::finishCreation): * runtime/DateConstructor.cpp: (JSC::DateConstructor::finishCreation): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::finishCreation): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSArrayBufferConstructor::finishCreation): * runtime/NumberConstructor.cpp: (JSC::NumberConstructor::finishCreation): * runtime/ObjectConstructor.cpp: (JSC::ObjectConstructor::finishCreation): * runtime/RegExpConstructor.cpp: (JSC::RegExpConstructor::finishCreation): * runtime/StringConstructor.cpp: (JSC::StringConstructor::finishCreation): * runtime/SymbolConstructor.cpp: (JSC::SymbolConstructor::finishCreation): Ensure the "length" property on these native constructors is configurable (deletable). 2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com> Unreviewed, build fix for Windows after r215228 part 2 https://bugs.webkit.org/show_bug.cgi?id=170723 Since GCActivityCallback class is annotated exported, we do not need to annotate each member. * heap/GCActivityCallback.h: 2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com> [JSC][GTK] Use RunLoop::Timer in GTK port https://bugs.webkit.org/show_bug.cgi?id=170723 Reviewed by Carlos Garcia Campos. This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer. Only Cocoa-based ports use platform-specific Timer because it has additional feature that changes RunLoop to the WebThread one. And we enable Heap timers in all the ports including JSCOnly port. * heap/EdenGCActivityCallback.cpp: (JSC::EdenGCActivityCallback::lastGCLength): * heap/EdenGCActivityCallback.h: * heap/FullGCActivityCallback.cpp: (JSC::FullGCActivityCallback::lastGCLength): * heap/FullGCActivityCallback.h: * heap/GCActivityCallback.cpp: (JSC::GCActivityCallback::GCActivityCallback): (JSC::GCActivityCallback::doWork): (JSC::GCActivityCallback::scheduleTimer): (JSC::GCActivityCallback::cancelTimer): (JSC::GCActivityCallback::nextFireTime): (JSC::GCActivityCallback::didAllocate): * heap/GCActivityCallback.h: * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::doWork): (JSC::IncrementalSweeper::doSweep): * heap/IncrementalSweeper.h: * heap/StopIfNecessaryTimer.cpp: (JSC::StopIfNecessaryTimer::scheduleSoon): * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::setRunLoop): (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::cancelTimer): (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::~JSRunLoopTimer): (JSC::JSRunLoopTimer::timerDidFireCallback): * runtime/JSRunLoopTimer.h: * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::scheduleWorkSoon): 2017-04-11 Guillaume Emont <guijemont@igalia.com> [jsc][mips] Add missing MacroAssembler functions after r214187 https://bugs.webkit.org/show_bug.cgi?id=170089 Reviewed by Yusuke Suzuki. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::loadFloat): Added. (JSC::MacroAssemblerMIPS::storeFloat): Added. 2017-04-11 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Enable JSRunLoopTimer for JSCOnly and Windows https://bugs.webkit.org/show_bug.cgi?id=170655 Reviewed by Carlos Garcia Campos. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::cancelTimer): * runtime/JSRunLoopTimer.h: 2017-04-10 Alex Christensen <achristensen@webkit.org> Revert r215217 https://bugs.webkit.org/show_bug.cgi?id=170703 * Configurations/FeatureDefines.xcconfig: 2017-04-10 Alex Christensen <achristensen@webkit.org> Continue enabling WebRTC https://bugs.webkit.org/show_bug.cgi?id=170703 Reviewed by Youenn Fablet. * Configurations/FeatureDefines.xcconfig: 2017-04-10 Mark Lam <mark.lam@apple.com> Move ProbeContext and ProbeFunction out of AbstractMacroAssembler. https://bugs.webkit.org/show_bug.cgi?id=170681 Reviewed by Michael Saboff. This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted. (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted. (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted. (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted. * assembler/MacroAssembler.cpp: (JSC::stdFunctionCallback): (JSC::MacroAssembler::probe): * assembler/MacroAssembler.h: (JSC::ProbeContext::gpr): (JSC::ProbeContext::fpr): (JSC::ProbeContext::gprName): (JSC::ProbeContext::fprName): * assembler/MacroAssemblerARM.cpp: (JSC::MacroAssemblerARM::probe): * assembler/MacroAssemblerARM64.cpp: (JSC::arm64ProbeTrampoline): (JSC::MacroAssemblerARM64::probe): * assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssemblerARMv7::probe): * assembler/MacroAssemblerPrinter.cpp: * assembler/MacroAssemblerPrinter.h: * assembler/MacroAssemblerX86Common.cpp: (JSC::MacroAssemblerX86Common::probe): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::abstractStructure): (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted. - Deleted because this became a useless place-holder after the transition to B3. 2017-04-10 Keith Miller <keith_miller@apple.com> WebAssembly: Fix B3IRGenerator for BrTable https://bugs.webkit.org/show_bug.cgi?id=170685 Reviewed by JF Bastien. For some reason this didn't get included in r215141. This fixes an issue with BrTable and loops where we would use the loop's return type as the branch target type. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch): (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock): 2017-04-08 Oliver Hunt <oliver@apple.com> Remove use of strcpy from JSC https://bugs.webkit.org/show_bug.cgi?id=170646 Reviewed by Mark Lam. Replace the use of strcpy with memcpy as strcpy keeps on tripping various analyser warnings even though its trivially safe in this case. Essentially code hygiene, no change in behaviour, no perf impact. * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpDisassembly): 2017-04-09 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js https://bugs.webkit.org/show_bug.cgi?id=170650 Reviewed by Saam Barati. * parser/Parser.cpp: (JSC::Parser<LexerType>::parseClass): (JSC::Parser<LexerType>::parseProperty): There needs to be special handling of: PropertyDefinition : PropertyName ':' AssignmentExpression When the property name is __proto__. In this case the SetFunctionName path does not happen, so the name "__proto__" is not inferred on any anonymous function. See: https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers * parser/Parser.h: * parser/SyntaxChecker.h: (JSC::SyntaxChecker::createProperty): * parser/ASTBuilder.h: (JSC::ASTBuilder::createProperty): Add an extra parameter to see if inferring / setting names are allowed. 2017-04-09 Joseph Pecoraro <pecoraro@apple.com> test262: test262/test/annexB/language/literals/regexp/identity-escape.js https://bugs.webkit.org/show_bug.cgi?id=170651 Reviewed by Saam Barati. * yarr/YarrParser.h: (JSC::Yarr::Parser::parseEscape): For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number. See: https://tc39.github.io/ecma262/#sec-decimalescape 2017-04-08 Youenn Fablet <youenn@apple.com> WebRTC tests gardening https://bugs.webkit.org/show_bug.cgi?id=170508 Reviewed by Eric Carlson. * Configurations/FeatureDefines.xcconfig: 2017-04-07 Keith Miller <keith_miller@apple.com> WebAssembly: Fix issue with BrTable targeting a Loop https://bugs.webkit.org/show_bug.cgi?id=170638 Reviewed by Saam Barati. This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537 * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::ControlData::branchTargetSignature): 2017-04-07 Keith Miller <keith_miller@apple.com> Add a PriorityQueue class https://bugs.webkit.org/show_bug.cgi?id=170579 Reviewed by Saam Barati. Update Wasm::Worklist to use WTF::PriorityQueue. * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): (JSC::Wasm::Worklist::completePlanSynchronously): (JSC::Wasm::Worklist::stopAllPlansForVM): (JSC::Wasm::Worklist::~Worklist): (JSC::Wasm::Worklist::iterate): Deleted. * wasm/WasmWorklist.h: (JSC::Wasm::Worklist::isHigherPriority): (JSC::Wasm::Worklist::Comparator::operator()): Deleted. 2017-04-07 Yuichiro Kikura <y.kikura@gmail.com> WebGPU: implement ComputeCommandEncoder and related components https://bugs.webkit.org/show_bug.cgi?id=170444 Reviewed by Alex Christensen. I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal. https://webkit.org/wp-content/uploads/webgpu-api-proposal.html * runtime/CommonIdentifiers.h: 2017-04-07 Saam Barati <sbarati@apple.com> WebAssembly: Module::getOrCreateCodeBlock is wrong https://bugs.webkit.org/show_bug.cgi?id=170612 Reviewed by Keith Miller. When we were getting a module's CodeBlock, we were checking if !runnable(), and if !runnable(), we were re-creating the CodeBlock. This is wrong, since !runnable() is true while the CodeBlock is compiling. Instead, we should check if we've finished compiling, and if so, if that compilation failed. * wasm/WasmModule.cpp: (JSC::Wasm::Module::getOrCreateCodeBlock): 2017-04-07 Saam Barati <sbarati@apple.com> WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules https://bugs.webkit.org/show_bug.cgi?id=170488 Reviewed by JF Bastien. This patch adds a class called Wasm::Module. It contains the bits from JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock, which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used to own. This patch also simplifies how we verify and compile code. Wasm::Module now has an API for both sync/async validation and compilation. This API abstracts away how Wasm::Plan works. This is hopefully the last patch needed before we can implement window.postMessage for a JSWebAssemblyModule. I think all that's needed now to implement postMessage is simply creating a new JSWebAssemblyModule with the underlying Wasm::Module. This patch is neutral on WasmBench. Finally, this patch changes the promise deferred timer to allow for new tasks to be added while we're executing a task. Before, we'd deadlock if this happened. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::scheduleWorkSoon): * runtime/PromiseDeferredTimer.h: * wasm/WasmB3IRGenerator.cpp: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): (JSC::Wasm::exitStubGenerator): Deleted. * wasm/WasmBinding.h: * wasm/WasmCodeBlock.cpp: Added. (JSC::Wasm::CodeBlock::CodeBlock): (JSC::Wasm::CodeBlock::waitUntilFinished): (JSC::Wasm::CodeBlock::compileAsync): (JSC::Wasm::CodeBlock::isSafeToRun): * wasm/WasmCodeBlock.h: Added. (JSC::Wasm::CodeBlock::create): (JSC::Wasm::CodeBlock::compilationFinished): (JSC::Wasm::CodeBlock::runnable): (JSC::Wasm::CodeBlock::errorMessage): (JSC::Wasm::CodeBlock::functionImportCount): (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): * wasm/WasmModule.cpp: Added. (JSC::Wasm::Module::Module): (JSC::Wasm::makeValidationResult): (JSC::Wasm::Module::validateSyncImpl): (JSC::Wasm::Module::getOrCreateCodeBlock): (JSC::Wasm::Module::compileSync): (JSC::Wasm::Module::makeValidationCallback): (JSC::Wasm::Module::compileAsync): * wasm/WasmModule.h: Added. (JSC::Wasm::Module::create): (JSC::Wasm::Module::validateSync): (JSC::Wasm::Module::validateAsync): (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): (JSC::Wasm::Module::moduleInformation): (JSC::Wasm::Module::nonNullCodeBlock): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::prepare): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast): (JSC::Wasm::Plan::cancel): Deleted. * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): (JSC::Wasm::Plan::takeWasmToWasmExitStubs): (JSC::Wasm::Plan::mode): (JSC::Wasm::Plan::takeWasmExitStubs): Deleted. (JSC::Wasm::Plan::vm): Deleted. * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::stopAllPlansForVM): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): (JSC::JSWebAssemblyCodeBlock::isSafeToRun): (JSC::JSWebAssemblyCodeBlock::initialize): Deleted. * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::functionImportCount): (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): (JSC::JSWebAssemblyCodeBlock::mode): Deleted. (JSC::JSWebAssemblyCodeBlock::initialized): Deleted. (JSC::JSWebAssemblyCodeBlock::plan): Deleted. (JSC::JSWebAssemblyCodeBlock::runnable): Deleted. (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted. (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted. (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted. * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::initialized): Deleted. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::JSWebAssemblyModule): (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::moduleInformation): (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace): (JSC::JSWebAssemblyModule::module): * wasm/js/WebAssemblyFunction.cpp: (JSC::WebAssemblyFunction::create): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyPrototype.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyValidateFunc): 2017-04-07 Carlos Garcia Campos <cgarcia@igalia.com> [GTK] Update the priorities used in glib main loop sources https://bugs.webkit.org/show_bug.cgi?id=170457 Reviewed by Žan Doberšek. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::JSRunLoopTimer): 2017-04-06 Filip Pizlo <fpizlo@apple.com> Rename allocateStack to allocateStackByGraphColoring. Rubber stamped by Saam Barati. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirAllocateStack.cpp: Removed. * b3/air/AirAllocateStack.h: Removed. * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp. (JSC::B3::Air::allocateStackByGraphColoring): (JSC::B3::Air::allocateStack): Deleted. * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h. * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): 2017-04-06 Michael Saboff <msaboff@apple.com> Cannot Object.seal() or Object.freeze() global "this" https://bugs.webkit.org/show_bug.cgi?id=170549 Reviewed by Mark Lam. Needed to implement JSProxy::isExtensible() which returns the results of calling the same on wrapped object. Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript spec to properly return a TypeError object when attempting to add properties to a non-extensible global object. * interpreter/Interpreter.cpp: (JSC::Interpreter::execute): * runtime/JSProxy.cpp: (JSC::JSProxy::isExtensible): * runtime/JSProxy.h: 2017-04-06 Filip Pizlo <fpizlo@apple.com> Linear scan should run liveness only once https://bugs.webkit.org/show_bug.cgi?id=170569 Reviewed by Keith Miller. Air has a longstanding design bug that Tmps from different banks are indexed independently. This means that all of our analyses over Tmps do separate GP and FP passes. This does have some marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad. However, I don't want to think about solving that general problem. Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear" indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once, instead of twice, for linear scan). This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring doing separate passes. This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no longer the longest pole in the tent. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3VariableLiveness.h: (JSC::B3::VariableLivenessAdapter::prepareToCompute): * b3/air/AirAllocateRegistersByLinearScan.cpp: (JSC::B3::Air::allocateRegistersByLinearScan): * b3/air/AirCode.h: (JSC::B3::Air::Code::forEachTmp): * b3/air/AirLiveness.h: * b3/air/AirLivenessAdapter.h: (JSC::B3::Air::LivenessAdapter::Actions::Actions): (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::adapter): (JSC::B3::Air::LivenessAdapter::prepareToCompute): (JSC::B3::Air::LivenessAdapter::actionsAt): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): (JSC::B3::Air::TmpLivenessAdapter::numIndices): (JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter): (JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices): (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank): (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole): (JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex): (JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue): * b3/air/AirLivenessConstraints.h: Removed. * b3/air/AirRegLiveness.h: (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): * b3/air/AirTmp.cpp: * b3/air/AirTmp.h: * b3/air/AirTmpInlines.h: (JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed): (JSC::B3::Air::Tmp::LinearlyIndexed::index): (JSC::B3::Air::Tmp::linearlyIndexed): (JSC::B3::Air::Tmp::indexEnd): (JSC::B3::Air::Tmp::absoluteIndexEnd): (JSC::B3::Air::Tmp::linearIndexEnd): (JSC::B3::Air::Tmp::tmpForAbsoluteIndex): (JSC::B3::Air::Tmp::tmpForLinearIndex): * b3/air/AirTmpMap.h: Added. (JSC::B3::Air::TmpMap::TmpMap): (JSC::B3::Air::TmpMap::resize): (JSC::B3::Air::TmpMap::clear): (JSC::B3::Air::TmpMap::operator[]): (JSC::B3::Air::TmpMap::append): 2017-04-06 Ryan Haddad <ryanhaddad@apple.com> Unreviewed, rolling out r215046. This change broke internal builds. Reverted changeset: "WebRTC tests gardening" https://bugs.webkit.org/show_bug.cgi?id=170508 http://trac.webkit.org/changeset/215046 2017-04-06 Joseph Pecoraro <pecoraro@apple.com> Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar https://bugs.webkit.org/show_bug.cgi?id=16531 <rdar://problem/5712895> Reviewed by Timothy Hatcher. * inspector/protocol/Network.json: Optional refined list of request headers in Metrics. 2017-04-06 Filip Pizlo <fpizlo@apple.com> B3 -O1 should generate better code than -O0 https://bugs.webkit.org/show_bug.cgi?id=170563 Reviewed by Michael Saboff. Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned out to be because of reduceStrength optimizations that increase live ranges and create register pressure, which then creates problems for linear scan. It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast and harmless. So, I focused on removing: - CSE, which increases live ranges. This is a risky optimization when we know that we've chosen to use a bad register allocator. - Sophisticated strength reductions that create more code, like the insane division optimization. - Anything that inserts basic blocks. CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile time. This change also reduces the running time of reduceStrength by making it not a fixpoint at optLevel<2. This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use -O0, but at least now -O1 isn't totally useless. * b3/B3ReduceStrength.cpp: 2017-04-06 Jon Davis <jond@apple.com> Updates feature status for recently shipped features https://bugs.webkit.org/show_bug.cgi?id=170359 Reviewed by Brian Burg. Changed "Done" status to "Supported". * features.json: 2017-04-06 Youenn Fablet <youenn@apple.com> WebRTC tests gardening https://bugs.webkit.org/show_bug.cgi?id=170508 Reviewed by Eric Carlson. * Configurations/FeatureDefines.xcconfig: 2017-04-06 Guillaume Emont <guijemont@igalia.com> [JSC][MIPS][DFG] Use x86 generic HasOwnProperty https://bugs.webkit.org/show_bug.cgi?id=170222 Reviewed by Yusuke Suzuki. * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): use the X86 special version for HasOwnProperty on MIPS too. * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): use the X86 special version for HasOwnProperty on MIPS too. 2017-04-05 Saam Barati <sbarati@apple.com> REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern https://bugs.webkit.org/show_bug.cgi?id=170494 <rdar://problem/31446485> Reviewed by Yusuke Suzuki and Mark Lam. This patch fixes how we test a 64 bit JSValue pattern to see if it's a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits. The new test is for a Wasm Callee is as follows: isWasm(uint64_t x) { return x & 0xffff000000000007 == 3; } This test works because the lower 3 bits of the non-number immediate values are as follows: undefined: 0b010 null: 0b010 true: 0b111 false: 0b110 The test rejects all of these because none have just the value 3 in their lower 3 bits. The test also rejects all numbers, because they have non-zero upper 16 bits. The test also rejects normal cells because they won't have the number 3 as their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc, predicates to work on a Wasm::Callee because the various tests will fail if you bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees TagBitTypeOther. The other tests also trivially fail, since it won't be a number, and it won't be equal to null, undefined, true, or false. The isBoolean() predicate will fail because we won't have TagBitBool set. * interpreter/CallFrame.h: (JSC::ExecState::guaranteedJSValueCallee): (JSC::ExecState::calleeAsValue): Deleted. * interpreter/CalleeBits.h: (JSC::CalleeBits::boxWasm): (JSC::CalleeBits::isWasm): (JSC::CalleeBits::asWasmCallee): * jit/JITOperations.cpp: * runtime/JSCJSValue.h: 2017-04-05 Keith Miller <keith_miller@apple.com> WebAssembly: Plans should be able to have more than one completion task. https://bugs.webkit.org/show_bug.cgi?id=170516 Reviewed by Saam Barati. This patch also eliminates the need for blocked tasks on the PromiseDeferredTimer and pendingPromise on Wasm::Plan. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::cancelPendingPromise): (JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted. * runtime/PromiseDeferredTimer.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::addCompletionTask): (JSC::Wasm::Plan::complete): * wasm/WasmPlan.h: (JSC::Wasm::Plan::setMode): (JSC::Wasm::Plan::mode): (JSC::Wasm::Plan::setModeAndPromise): Deleted. (JSC::Wasm::Plan::pendingPromise): Deleted. * wasm/WasmWorklist.cpp: (JSC::Wasm::Worklist::enqueue): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyPrototype.cpp: (JSC::instantiate): 2017-04-05 Guilherme Iscaro <iscaro@profusion.mobi> Do not use BLX for immediates (ARM-32) https://bugs.webkit.org/show_bug.cgi?id=170351 Reviewed by Mark Lam. Currently the offline asm generator for 32-bit ARM code translates the 'call' meta-instruction (which may be found in LowLevelInterpreter.asm and friends) to the ARM's BLX instrunction. The BLX instruction may be used for labels (immediates) and registers and one side effect of BLX is that it may switch the processor's instruction set. A 'BLX register' instruction will change/remain the processor state to ARM if the register_bit[0] is set to 0 or change/remain to Thumb if register_bit[0] is set to 1. However, a 'BLX label' instruction will always switch the processor state. It switches ARM to thumb and vice-versa. This behaviour is unwanted, since the C++ code and the offlineasm generated code are both compiled using the same instruction set, thus a instruction set change will likely produce a crash. In order to fix the problem the BL instruction can be used for labels. It will branch just like BLX, but it won't change the instruction set. It's important to note that Darwin is not affected by this problem, thus to minimize the impact of this change the BL instruction will only be used on non-darwin targets. BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20 * offlineasm/arm.rb: 2017-04-05 Keith Miller <keith_miller@apple.com> WebAssembly: We shouldn't need to pin size registers if we have a fast memory. https://bugs.webkit.org/show_bug.cgi?id=170504 Reviewed by Mark Lam. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave): 2017-04-05 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Suppress warnings in GCC https://bugs.webkit.org/show_bug.cgi?id=170501 Reviewed by Keith Miller. Should use ASSERT_NOT_REACHED since return-type pragma is only enabled under ASSERT_DISABLED environment. We shoud use ASSERT_NOTREACHED to emit assertions in debug build. It effectively catches bugs while keeping performance in release build. * b3/B3Opcode.cpp: (JSC::B3::storeOpcode): * b3/B3Width.h: (JSC::B3::mask): * runtime/Options.cpp: (JSC::parse): * wasm/WasmSections.h: (JSC::Wasm::makeString): * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::tryCleanup): * wasm/generateWasmValidateInlinesHeader.py: 2017-04-05 Carlos Garcia Campos <cgarcia@igalia.com> Implement PromiseDeferredTimer for non CF based ports https://bugs.webkit.org/show_bug.cgi?id=170391 Reviewed by Yusuke Suzuki. RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports. * jsc.cpp: (runJSC): Remove CF ifdefs. * runtime/PromiseDeferredTimer.cpp: (JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop. (JSC::PromiseDeferredTimer::runRunLoop): Ditto. * runtime/PromiseDeferredTimer.h: 2017-04-05 Carlos Garcia Campos <cgarcia@igalia.com> WebAssembly: several tests added in r214504 crash when building with GCC https://bugs.webkit.org/show_bug.cgi?id=170390 Reviewed by Saam Barati. The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the foo is used to invoke the function. * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda. (JSC::instantiate): Ditto. (JSC::compileAndInstantiate): Ditto. 2017-03-16 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Generate TemplateObjects at linking time https://bugs.webkit.org/show_bug.cgi?id=169743 Reviewed by Keith Miller. Currently, the code calls getTemplateObject to get appropriate template objects at runtime. But this template object is constant value and never changed. So instead of creating it at runtime, we should create it at linking time and store it in the constant registers. * builtins/BuiltinNames.h: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::finishCreation): (JSC::CodeBlock::setConstantRegisters): * bytecode/CodeBlock.h: * bytecode/UnlinkedCodeBlock.cpp: (JSC::UnlinkedCodeBlock::shrinkToFit): * bytecode/UnlinkedCodeBlock.h: * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant): (JSC::BytecodeGenerator::emitGetTemplateObject): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::TaggedTemplateNode::emitBytecode): * runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::init): (JSC::getTemplateObject): Deleted. * runtime/JSTemplateRegistryKey.cpp: * runtime/JSTemplateRegistryKey.h: (JSC::isTemplateRegistryKey): 2017-04-04 Mark Lam <mark.lam@apple.com> On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32. https://bugs.webkit.org/show_bug.cgi?id=170473 <rdar://problem/29912391> Reviewed by Saam Barati. In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the divisor is 0, we want it to return 0. The result is expected to be of DataFormatIn32. The ARM implementation just returns the value in the divisor register. However, the divisor in this case can be of DataFormatJSInt32. On ARM64, returning the divisor register yields the wrong result format because the same register also holds the upper 32-bit of the JSValue encoding. The fix is to return an immediate 0 instead. Also turned on the assertion in jitAssertIsInt32 for ARM64. This assertion being disabled may have contributed to this bug going unnoticed all this time. * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileArithMod): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitAssertIsInt32): 2017-04-04 Filip Pizlo <fpizlo@apple.com> Air::eliminateDeadCode should not repeatedly process the same live instructions https://bugs.webkit.org/show_bug.cgi?id=170490 Reviewed by Keith Miller. This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set of Insts that might be dead. Every time we detect that one is live, we remove it from the set. This is a big (>2x) speed-up because lots of Insts are immediately found to be live. This is a ~1% wasm -O1 compile time progression. * b3/air/AirEliminateDeadCode.cpp: (JSC::B3::Air::eliminateDeadCode): 2017-04-04 Filip Pizlo <fpizlo@apple.com> Air::eliminateDeadCode() should not use a HashSet https://bugs.webkit.org/show_bug.cgi?id=170487 Reviewed by Saam Barati. Introduce TmpSet, which is like a HashSet<Tmp>. Use this to make eliminateDeadCode() about 50% faster, resulting in a 1% wasm -O1 compile time progression. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirEliminateDeadCode.cpp: (JSC::B3::Air::eliminateDeadCode): * b3/air/AirTmpSet.h: Added. (JSC::B3::Air::TmpSet::TmpSet): (JSC::B3::Air::TmpSet::add): (JSC::B3::Air::TmpSet::remove): (JSC::B3::Air::TmpSet::contains): (JSC::B3::Air::TmpSet::size): (JSC::B3::Air::TmpSet::isEmpty): (JSC::B3::Air::TmpSet::iterator::iterator): (JSC::B3::Air::TmpSet::iterator::operator*): (JSC::B3::Air::TmpSet::iterator::operator++): (JSC::B3::Air::TmpSet::iterator::operator==): (JSC::B3::Air::TmpSet::iterator::operator!=): (JSC::B3::Air::TmpSet::begin): (JSC::B3::Air::TmpSet::end): 2017-04-04 Keith Miller <keith_miller@apple.com> WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads. https://bugs.webkit.org/show_bug.cgi?id=170478 Reviewed by Saam Barati. ModuleInformation has been moved to its own file and is now ThreadSafeRefCounted. All the Strings we used to keep in the ModuleInformation have been switched to Vector<LChar> this has the advantage that it can be passed across threads. However, this does mean that we need to decode the utf8 strings in each thread. This is likely not a problem because: 1) most modules have few imports/exports/custom sections. 2) most of the time they are ascii so the conversion is cheap. 3) we only have to do it once per thread, and there shouldn't be too many. This patch also removes moduleSignatureIndicesToUniquedSignatureIndices since that information can already be recovered from the SignatureInformation. * JavaScriptCore.xcodeproj/project.pbxproj: * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/Identifier.h: (JSC::Identifier::fromString): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmFormat.cpp: (JSC::Wasm::makeString): (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted. * wasm/WasmFormat.h: (JSC::Wasm::makeString): (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted. (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted. (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted. (JSC::Wasm::ModuleInformation::importFunctionCount): Deleted. (JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::FunctionParser): * wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h. (JSC::Wasm::ModuleInformation::~ModuleInformation): * wasm/WasmModuleInformation.h: Added. (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): (JSC::Wasm::ModuleInformation::importFunctionCount): (JSC::Wasm::ModuleInformation::internalFunctionCount): (JSC::Wasm::ModuleInformation::ModuleInformation): * wasm/WasmModuleParser.cpp: * wasm/WasmModuleParser.h: (JSC::Wasm::ModuleParser::ModuleParser): * wasm/WasmParser.h: (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::prepare): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): (JSC::Wasm::Plan::cancel): * wasm/WasmPlan.h: (JSC::Wasm::Plan::internalFunctionCount): (JSC::Wasm::Plan::takeModuleInformation): * wasm/WasmSignature.cpp: (JSC::Wasm::SignatureInformation::get): * wasm/WasmSignature.h: * wasm/WasmValidate.cpp: (JSC::Wasm::validateFunction): * wasm/WasmValidate.h: * wasm/js/JSWebAssemblyHelpers.h: (JSC::createSourceBufferFromValue): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::JSWebAssemblyModule): (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::moduleInformation): (JSC::JSWebAssemblyModule::source): * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoCustomSections): (JSC::webAssemblyModuleProtoImports): (JSC::webAssemblyModuleProtoExports): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): * wasm/js/WebAssemblyModuleRecord.h: * wasm/js/WebAssemblyPrototype.cpp: (JSC::webAssemblyCompileFunc): (JSC::instantiate): (JSC::compileAndInstantiate): 2017-04-04 Filip Pizlo <fpizlo@apple.com> B3::fixSSA() needs a tune-up https://bugs.webkit.org/show_bug.cgi?id=170485 Reviewed by Saam Barati. After the various optimizations to liveness, register allocation, and other phases, the fixSSA() phase now looks like one of the top offenders. This includes a bunch of changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression. Here's what I did: - We now use IndexSparseSet instead of IndexMap for tracking variable values. This makes it cheaper to chew through small blocks while there is a non-trivial number of total variables. - We now do a "local SSA conversion" pass before anything else. This eliminates obvious Get's. If we were using temporary Variables, it would eliminate many of those. That's useful for when we use demoteValues() and duplciateTails(). For wasm -O1, we mainly care about the fact that it makes a bunch of Set's dead. - We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures that any block-local live intervals of Variables disappear and don't need further consideration. - We now cache the reaching defs calculation. - We now perform the reaching defs calculation lazily. * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3SSACalculator.cpp: (JSC::B3::SSACalculator::reachingDefAtTail): * b3/B3VariableLiveness.cpp: (JSC::B3::VariableLiveness::VariableLiveness): * b3/air/AirLiveness.h: (JSC::B3::Air::Liveness::Liveness): * dfg/DFGLivenessAnalysisPhase.cpp: (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted. (JSC::DFG::LivenessAnalysisPhase::run): Deleted. (JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted. 2017-04-04 Joseph Pecoraro <pecoraro@apple.com> Remove stale LLVM Header Path includes from JavaScriptCore https://bugs.webkit.org/show_bug.cgi?id=170483 Reviewed by Mark Lam. * Configurations/Base.xcconfig: 2017-04-04 Filip Pizlo <fpizlo@apple.com> B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1) https://bugs.webkit.org/show_bug.cgi?id=169867 Reviewed by Saam Barati. The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the BitXor into the CAS condition read-out. But there is no version of this that is profitable or correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...) becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately. So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): * b3/testb3.cpp: (JSC::B3::testAtomicStrongCAS): 2017-04-04 Saam Barati <sbarati@apple.com> WebAssembly: JSWebAssemblyCallee should not be a JSCell https://bugs.webkit.org/show_bug.cgi?id=170135 Reviewed by Michael Saboff. This patch is perhaps the last big change to the design of fundamental Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing called Wasm::Callee. It serves the same purpose as before, except Wasm::Callee is not a JSCell. I had to refactor the various parts of the runtime that will see CallFrame's with Wasm::Callee's in the callee slot. Thankfully, the parts of the runtime that Wasm touches are limited. The main refactoring is changing the exception handling code, such as taking a stack trace, to be friendly to seeing a non JSCell callee. The callee() function on ExecState now returns a class I added in this patch called CalleeBits. CalleeBits will tell you if the callee is a JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower bit so we can easily tell what is and isn't a Wasm::Callee. The stub that calls out from Wasm to JS still puts a JSCell callee into the call frame, even though the callee logically represents a Wasm frame. The reason for this is that we use the call IC infrastructure to make a call out to JS code, and the code that writes the IC expects a JSCell as the callee. This is knowingly part of our design. When we do structured cloning of Wasm Modules, we'll need to regenerate these JS call stubs. * API/JSContextRef.cpp: (BacktraceFunctor::operator()): * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * debugger/Debugger.cpp: (JSC::Debugger::pauseIfNeeded): (JSC::Debugger::currentDebuggerCallFrame): * debugger/DebuggerCallFrame.cpp: (JSC::DebuggerCallFrame::create): (JSC::DebuggerCallFrame::DebuggerCallFrame): (JSC::DebuggerCallFrame::currentPosition): (JSC::DebuggerCallFrame::positionForCallFrame): * debugger/DebuggerCallFrame.h: * interpreter/CallFrame.cpp: (JSC::CallFrame::vmEntryGlobalObject): (JSC::CallFrame::wasmAwareLexicalGlobalObject): (JSC::CallFrame::isAnyWasmCallee): (JSC::CallFrame::callerSourceOrigin): * interpreter/CallFrame.h: (JSC::ExecState::calleeAsValue): (JSC::ExecState::jsCallee): (JSC::ExecState::callee): (JSC::ExecState::unsafeCallee): (JSC::ExecState::scope): (JSC::ExecState::iterate): * interpreter/CalleeBits.h: Added. (JSC::CalleeBits::CalleeBits): (JSC::CalleeBits::operator=): (JSC::CalleeBits::boxWasm): (JSC::CalleeBits::isWasm): (JSC::CalleeBits::isCell): (JSC::CalleeBits::asCell): (JSC::CalleeBits::asWasmCallee): (JSC::CalleeBits::rawPtr): * interpreter/Interpreter.cpp: (JSC::GetStackTraceFunctor::operator()): (JSC::Interpreter::getStackTrace): (JSC::notifyDebuggerOfUnwinding): (JSC::UnwindFunctor::UnwindFunctor): (JSC::UnwindFunctor::operator()): (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::Interpreter::unwind): (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown): * interpreter/Interpreter.h: * interpreter/Register.h: (JSC::Register::pointer): * interpreter/ShadowChicken.cpp: (JSC::ShadowChicken::update): * interpreter/ShadowChickenInlines.h: (JSC::ShadowChicken::iterate): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::StackVisitor): (JSC::StackVisitor::readFrame): (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::readInlinedFrame): (JSC::StackVisitor::Frame::calleeSaveRegisters): (JSC::StackVisitor::Frame::functionName): (JSC::StackVisitor::Frame::dump): * interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::callee): (JSC::StackVisitor::visit): * jit/Repatch.cpp: (JSC::linkFor): (JSC::linkPolymorphicCall): * jsc.cpp: (callWasmFunction): (functionTestWasmModuleFunctions): * runtime/ArrayPrototype.cpp: * runtime/Error.cpp: (JSC::addErrorInfoAndGetBytecodeOffset): * runtime/ErrorInstance.cpp: (JSC::ErrorInstance::finishCreation): * runtime/JSCell.cpp: (JSC::JSCell::isAnyWasmCallee): Deleted. * runtime/JSCell.h: * runtime/JSCellInlines.h: (JSC::ExecState::vm): * runtime/JSFunction.cpp: (JSC::RetrieveArgumentsFunctor::operator()): (JSC::RetrieveCallerFunctionFunctor::operator()): * runtime/JSGlobalObject.cpp: * runtime/SamplingProfiler.cpp: (JSC::FrameWalker::recordJSFrame): (JSC::SamplingProfiler::processUnverifiedStackTraces): * runtime/SamplingProfiler.h: (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame): * runtime/StackFrame.cpp: (JSC::StackFrame::sourceURL): (JSC::StackFrame::functionName): * runtime/StackFrame.h: (JSC::StackFrame::wasm): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::throwException): * runtime/VM.h: * wasm/JSWebAssembly.h: * wasm/WasmB3IRGenerator.cpp: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToWasm): * wasm/WasmCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp. (JSC::Wasm::Callee::Callee): (JSC::JSWebAssemblyCallee::JSWebAssemblyCallee): Deleted. (JSC::JSWebAssemblyCallee::finishCreation): Deleted. (JSC::JSWebAssemblyCallee::destroy): Deleted. * wasm/WasmCallee.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.h. (JSC::Wasm::Callee::create): (JSC::JSWebAssemblyCallee::create): Deleted. (JSC::JSWebAssemblyCallee::createStructure): Deleted. (JSC::JSWebAssemblyCallee::entrypoint): Deleted. (JSC::JSWebAssemblyCallee::calleeSaveRegisters): Deleted. * wasm/WasmContext.h: * wasm/WasmPlan.cpp: * wasm/WasmPlan.h: * wasm/WasmPlanInlines.h: (JSC::Wasm::Plan::initializeCallees): * wasm/WasmThunks.cpp: (JSC::Wasm::throwExceptionFromWasmThunkGenerator): * wasm/js/JSWebAssemblyCallee.cpp: Removed. * wasm/js/JSWebAssemblyCallee.h: Removed. * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): (JSC::JSWebAssemblyCodeBlock::initialize): (JSC::JSWebAssemblyCodeBlock::visitChildren): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport): (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs): (JSC::JSWebAssemblyCodeBlock::allocationSize): (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): (JSC::JSWebAssemblyCodeBlock::callees): Deleted. (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): Deleted. * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee): * wasm/js/JSWebAssemblyModule.cpp: * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): (JSC::WebAssemblyFunction::create): (JSC::WebAssemblyFunction::WebAssemblyFunction): (JSC::WebAssemblyFunction::visitChildren): (JSC::WebAssemblyFunction::finishCreation): * wasm/js/WebAssemblyFunction.h: (JSC::WebAssemblyFunction::wasmEntrypoint): (JSC::WebAssemblyFunction::jsEntrypoint): (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode): Deleted. * wasm/js/WebAssemblyModuleConstructor.cpp: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): 2017-04-04 Keith Miller <keith_miller@apple.com> WasmBench asserts in debug jsc https://bugs.webkit.org/show_bug.cgi?id=170462 Reviewed by Saam Barati. The assertion should have been an if. * wasm/WasmWorklist.cpp: 2017-04-04 Filip Pizlo <fpizlo@apple.com> Air::lowerAfterRegAlloc should bail early if it finds no Shuffles or ColdCCalls https://bugs.webkit.org/show_bug.cgi?id=170305 Reviewed by Saam Barati. This reduces and sometimes completely eliminates the need to run lowerAfterRegAlloc(). This lowers the Shuffle for the arguments of a CCall before register allocation unless the CCall arguments require a real shuffle (like if the CCall arguments were argument registers). This lowers a ColdCCall like a CCall for optLevel<2. Finally, lowerAfterRegAlloc() now checks if there are any Shuffles or CCalls before it does anything else. For wasm at -O1, this means that the phase doesn't run at all. This is a ~3% wasm -O1 compile time progression. To make this easy, I changed optLevel into a property of Procedure and Code rather than an argument we thread through everything. I like how Procedure and Code are dumping ground classes. This does not bother me. Note that I cloned optLevel into Procedure and Code so that it's cheap to query inside Air phases. * b3/B3Compile.cpp: (JSC::B3::compile): * b3/B3Compile.h: * b3/B3Generate.cpp: (JSC::B3::prepareForGeneration): (JSC::B3::generateToAir): * b3/B3Generate.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::setOptLevel): * b3/B3Procedure.h: (JSC::B3::Procedure::optLevel): * b3/air/AirCode.h: (JSC::B3::Air::Code::isPinned): (JSC::B3::Air::Code::setOptLevel): (JSC::B3::Air::Code::optLevel): * b3/air/AirEmitShuffle.cpp: (JSC::B3::Air::ShufflePair::bank): (JSC::B3::Air::ShufflePair::opcode): (JSC::B3::Air::ShufflePair::inst): (JSC::B3::Air::emitShuffle): * b3/air/AirEmitShuffle.h: (JSC::B3::Air::moveFor): * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirGenerate.h: * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerMacros.cpp: (JSC::B3::Air::lowerMacros): * b3/testb3.cpp: (JSC::B3::compileProc): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2017-04-04 Filip Pizlo <fpizlo@apple.com> Don't need to Air::reportUsedRegisters for wasm at -O1 https://bugs.webkit.org/show_bug.cgi?id=170459 Reviewed by Saam Barati. I did some refactorings to Liveness<> to try to understand its performance. Based on this I concluded that the bigger immediate issue is just removing unnecessary phases from -O1. This removes Air::reportUsedRegisters() from -O1 if the user has indicated that he is not interested in StackmapGenerationParams::usedRegisters(). The logic here is a bit weird because of how Air does spill code generation. The register allocator's spiller will emit spill code using identifiable spill slots, which allows subsequent phases to register-allocate the spill slots. We do this by a forward flow CSE phase called fixObviousSpills (which is a terrible name since there is no longer anything obvious about some of the spills that this phase can fix!). As is most natural for CSEs over 3AC, it rewires the uses of redundant computations rather than removing the redundant computations. This means that if a spill got "fixed", there may be either or both of the following: - Dead loads from the stack. - Dead stores to the stack. We know that a load from the stack is dead if the register is dead at the point of the load. We know that a store to the stack is dead if the spill slot is dead at the point of the store. Unfortunately, liveness analysis - over either registers or spill slots - is expensive. Fortunately, allocateStack() already does liveness analysis over spill slots. So, we baked elimination of stores to the stack into that phase. That aspect of clean-up after the spill CSE comes for free. Also fortunately for the FTL, we have to do reportUsedRegisters() anyway. This is a phase that enables StackmapGenerationParams::usedRegisters() to work, which then enables the FTL's patchpoints to do crazy slow-path live range splitting. So, Air's strategy for the load fix-up after spill CSE is to do it as part of reportUsedRegisters(). This patch introduces the Procedure::setNeedsUsedRegisters() API. But if you set needsUsedRegisters to false then we will still run reportUsedRegisters() at -O2 as an optimization - it removes dead loads from the stack that are left behind from fixObviousSpills(). This is a ~6% compile time progression at -O1. * b3/B3Procedure.h: (JSC::B3::Procedure::setNeedsUsedRegisters): (JSC::B3::Procedure::needsUsedRegisters): * b3/B3StackmapGenerationParams.h: * b3/B3VariableLiveness.cpp: (JSC::B3::VariableLiveness::VariableLiveness): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::needsUsedRegisters): * b3/air/AirCode.h: * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): * b3/air/AirLiveness.h: (JSC::B3::Air::Liveness::Liveness): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): 2017-04-03 Filip Pizlo <fpizlo@apple.com> Air liveness should build constraints and solve them rather than repeatedly parsing IR https://bugs.webkit.org/show_bug.cgi?id=170421 Reviewed by Saam Barati. Inst::forEach<> is expensive. The LivenessAdapter uses forEach with a particularly gnarly lambda that has many extra checks. Therefore, a lot of the time spent in liveness analysis is just recomputing forEach<> and that lambda to get uses and defs. This introduces LivenessConstraints<>, which is a liveness constraint system based on Adapter. It basically caches the results of doing forEach. It'll give you the uses and defs at each instruction boundary. This is a ~5% compile time progression at optLevel=1. It's also a ~3% compile time progression at optLevel=2. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirLivenessAdapter.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): * b3/air/AirLivenessConstraints.h: Added. (JSC::B3::Air::LivenessConstraints::Actions::Actions): (JSC::B3::Air::LivenessConstraints::LivenessConstraints): (JSC::B3::Air::LivenessConstraints::at): 2017-04-03 Mark Lam <mark.lam@apple.com> Fix incorrect capacity delta calculation reported in SparseArrayValueMap::add(). https://bugs.webkit.org/show_bug.cgi?id=170412 <rdar://problem/29697336> Reviewed by Filip Pizlo. Here's an example of code that will trigger underflow in the "deprecatedExtraMemory" reported by SparseArrayValueMap::add() that is added to Heap::m_deprecatedExtraMemorySize: arr = new Array; Object.defineProperty(arr, 18, ({writable: true, configurable: true})); for (var i = 0; i < 3; ++i) { Array.prototype.push.apply(arr, ["", () => {}, {}]); Array.prototype.sort.apply(arr, [() => {}, []]); } However, Heap::m_deprecatedExtraMemorySize is only 1 of 3 values that are added up to form the result of Heap::extraMemorySize(). Heap::m_extraMemorySize and Heap::m_arrayBuffers.size() are the other 2. While Heap::m_arrayBuffers.size() is bounded by actual allocated memory, both Heap::m_deprecatedExtraMemorySize and Heap::m_extraMemorySize are added to without any bounds checks, and they are only reset to 0 at the start of a full GC. As a result, if we have a long sequence of eden GCs with a lot of additions to Heap::m_extraMemorySize and/or Heap::m_deprecatedExtraMemorySize, then these values could theoretically overflow. Coupling this with the underflow from SparseArrayValueMap::add(), the result for Heap::extraMemorySize() can easily overflow. Note: Heap::extraMemorySize() is used to compute the value currentHeapSize. If multiple conditions line up just right, the above overflows can result in this debug assertion failure during an eden GC: ASSERT(currentHeapSize >= m_sizeAfterLastCollect); Otherwise, the effects of the overflows will only result in the computed currentHeapSize not being representative of actual memory usage, and therefore, a full GC may be triggered earlier or later than is ideal. This patch ensures that SparseArrayValueMap::add() cannot underflow Heap::m_deprecatedExtraMemorySize. It also adds overflows checks in the calculations of Heap::m_deprecatedExtraMemorySize, Heap::m_extraMemorySize, and Heap::extraMemorySize() so that their values are saturated appropriately to ensure that GC collections are triggered based on representative memory usage. * heap/Heap.cpp: (JSC::Heap::deprecatedReportExtraMemorySlowCase): (JSC::Heap::extraMemorySize): (JSC::Heap::updateAllocationLimits): (JSC::Heap::reportExtraMemoryVisited): * runtime/SparseArrayValueMap.cpp: (JSC::SparseArrayValueMap::add): 2017-04-03 Filip Pizlo <fpizlo@apple.com> Move the Liveness<> adapters from AirLiveness.h to AirLivenessAdapter.h. Rubber stamped by Keith Miller. This will make it easier to write other code that uses those adapters. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirLiveness.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): Deleted. (JSC::B3::Air::LivenessAdapter::blockSize): Deleted. (JSC::B3::Air::LivenessAdapter::forEachUse): Deleted. (JSC::B3::Air::LivenessAdapter::forEachDef): Deleted. (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): Deleted. (JSC::B3::Air::TmpLivenessAdapter::numIndices): Deleted. (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): Deleted. (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): Deleted. (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): Deleted. (JSC::B3::Air::TmpLivenessAdapter::indexToValue): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): Deleted. (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): Deleted. * b3/air/AirLivenessAdapter.h: Added. (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::blockSize): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): (JSC::B3::Air::TmpLivenessAdapter::numIndices): (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): (JSC::B3::Air::TmpLivenessAdapter::indexToValue): (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): 2017-04-03 Filip Pizlo <fpizlo@apple.com> WTF::Liveness should have an API that focuses on actions at instruction boundaries https://bugs.webkit.org/show_bug.cgi?id=170407 Reviewed by Keith Miller. Adopt changes to the WTF::Liveness<> API. Instead of having separate functions for the early/late versions of uses and defs, we now have just a use/def API. Those automatically take care of eary/late issues as needed. This reduces the API surface between WTF::Liveness<> and its clients, which makes it easier to implement some other optimizations I'm thinking about. * b3/B3VariableLiveness.h: (JSC::B3::VariableLivenessAdapter::forEachUse): (JSC::B3::VariableLivenessAdapter::forEachDef): (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): Deleted. (JSC::B3::VariableLivenessAdapter::forEachLateUse): Deleted. (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): Deleted. (JSC::B3::VariableLivenessAdapter::forEachLateDef): Deleted. * b3/air/AirLiveness.h: (JSC::B3::Air::LivenessAdapter::blockSize): (JSC::B3::Air::LivenessAdapter::forEachUse): (JSC::B3::Air::LivenessAdapter::forEachDef): (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): Deleted. (JSC::B3::Air::LivenessAdapter::forEachLateUse): Deleted. (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): Deleted. (JSC::B3::Air::LivenessAdapter::forEachLateDef): Deleted. 2017-04-03 Filip Pizlo <fpizlo@apple.com> Inst::forEachArg could compile to more compact code https://bugs.webkit.org/show_bug.cgi?id=170406 Reviewed by Sam Weinig. Prior to this change, Inst::forEachArg compiled to a ginormous ALWAYS_INLINE switch statement. It had one case for each opcode, and then each of those cases would have a switch statement over the number of operands. Then the cases of that switch statement would have a sequence of calls to the passed lambda. This meant that every user of forEachArg would generate an insane amount of code. It also meant that the inlining achieved nothing, since the lambda would surely then not be inlined - and if it was, then the icache pressure due to code bloat would surely negate any benefits. This replaces that code with a loop over a compact look-up table. We use the opcode and number of operands as keys into that look-up table. The table only takes about 20KB. It has one byte for each argument in each overload of each opcode. I can't measure any reproducible change in performance, but the JavaScriptCore framework binary shrinks by 2.7 MB. This is a 15% reduction in JavaScriptCore binary size. * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Width.h: * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::forEachArg): * b3/air/AirFormTable.h: Added. (JSC::B3::Air::decodeFormRole): (JSC::B3::Air::decodeFormBank): (JSC::B3::Air::decodeFormWidth): * b3/air/AirInst.h: * b3/air/opcode_generator.rb: 2017-04-03 Keith Miller <keith_miller@apple.com> WebAssembly: remove lastAllocatedMode from Memory https://bugs.webkit.org/show_bug.cgi?id=170405 Reviewed by Mark Lam. It's not used anymore so there isn't any point in keeping it around. * wasm/WasmMemory.cpp: (JSC::Wasm::Memory::createImpl): (JSC::Wasm::Memory::lastAllocatedMode): Deleted. * wasm/WasmMemory.h: 2017-04-03 Zan Dobersek <zdobersek@igalia.com> [jsc] Add patchableJumpSize() for MIPS https://bugs.webkit.org/show_bug.cgi?id=169716 Reviewed by Yusuke Suzuki. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::patchableJumpSize): Added. * assembler/MacroAssemblerMIPS.h: (JSC::MacroAssemblerMIPS::patchableJumpSize): Added. 2017-04-03 Guillaume Emont <guijemont@igalia.com> [jsc] implement MIPSAssembler::relinkJumpToNop() https://bugs.webkit.org/show_bug.cgi?id=169720 Reviewed by Yusuke Suzuki. * assembler/MIPSAssembler.h: (JSC::MIPSAssembler::relinkJumpToNop): Added. 2017-04-02 Carlos Garcia Campos <cgarcia@igalia.com> Share implementation of JSRunLoopTimer::timerDidFire https://bugs.webkit.org/show_bug.cgi?id=170392 Reviewed by Michael Catanzaro. The code is cross-platform but it's duplicated in CF and GLib implementations, it could be shared instead. * runtime/JSRunLoopTimer.cpp: (JSC::JSRunLoopTimer::timerDidFire): Move common implementation here. (JSC::JSRunLoopTimer::setRunLoop): Use timerDidFireCallback. (JSC::JSRunLoopTimer::timerDidFireCallback): Call JSRunLoopTimer::timerDidFire(). * runtime/JSRunLoopTimer.h: 2017-04-01 Oleksandr Skachkov <gskachkov@gmail.com> Object with numerical keys with gaps gets filled by NaN values https://bugs.webkit.org/show_bug.cgi?id=164412 Reviewed by Mark Lam. This patch fixes issue when object have two properties with name as number. The issue appears when during invoking convertDoubleToArrayStorage, array is filled by pNaN and method converting it to real NaN. This happeneds because a pNaN in a Double array is a hole, and Double arrays cannot have NaN values. To fix issue we need to check value and clear it if it pNaN. * runtime/JSObject.cpp: (JSC::JSObject::convertDoubleToArrayStorage): 2017-03-31 Saam Barati <sbarati@apple.com> WebAssembly: Make our calls out to JS PIC friendly https://bugs.webkit.org/show_bug.cgi?id=170261 Reviewed by Keith Miller. This patch removes a direct call from the module to the Wasm to JS stub. Instead, we do an indirect call to the stub by loading the stub's executable address off of the CodeBlock. This is to make the code we emit for comply with requirements needed for PIC. Adding this indirection is not ideal. Although this patch is neutral on WasmBench, we really want to get back to a world where we have an IC call infrastructure. This patch is obviously a regression on some types of programs. I've filed this bug to make sure we implement a PIC compliant Wasm to JS call IC: https://bugs.webkit.org/show_bug.cgi?id=170375 * wasm/WasmB3IRGenerator.cpp: * wasm/WasmFormat.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::complete): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::initialize): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub): (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): (JSC::JSWebAssemblyCodeBlock::allocationSize): (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): 2017-03-31 Keith Miller <keith_miller@apple.com> WebAssembly: webAssemblyB3OptimizationLevel should use defaultB3OptLevel by default https://bugs.webkit.org/show_bug.cgi?id=170378 Reviewed by Saam Barati. * runtime/Options.h: * wasm/WasmB3IRGenerator.h: 2017-03-31 Keith Miller <keith_miller@apple.com> WebAssembly: Add compilation level option https://bugs.webkit.org/show_bug.cgi?id=170374 Reviewed by Mark Lam. This patch adds an option, webAssemblyB3OptimizationLevel, which changes the optimization mode wasm passes to B3. * runtime/Options.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::compileFunctions): 2017-03-31 Saam Barati <sbarati@apple.com> WebAssembly: Strip WasmParser and WasmFunctionParser from knowing about VM https://bugs.webkit.org/show_bug.cgi?id=170312 Reviewed by Mark Lam. This is another step towards PIC-ifying Wasm. This patch removes the VM field that is no longer used. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::FunctionParser): * wasm/WasmModuleParser.h: (JSC::Wasm::ModuleParser::ModuleParser): * wasm/WasmParser.h: (JSC::Wasm::Parser<SuccessType>::Parser): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::compileFunctions): * wasm/WasmValidate.cpp: (JSC::Wasm::validateFunction): * wasm/WasmValidate.h: 2017-03-31 Saam Barati <sbarati@apple.com> WebAssembly: Ref count Signature and SignatureInformation should not care about VM https://bugs.webkit.org/show_bug.cgi?id=170316 Reviewed by Keith Miller. This is yet again another step towards PIC-ifying Wasm. Signature should be ref counted so we can tell when no code is holding onto a Signature. This makes it easy to free unused Signatures. Also, this patch rids SignatureInfo of any VM knowledge. Now, there is just a single SignatureInfo that lives in a process. * runtime/VM.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/WasmCallingConvention.h: (JSC::Wasm::CallingConvention::loadArguments): * wasm/WasmFormat.h: * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser<Context>::FunctionParser): * wasm/WasmModuleParser.cpp: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): * wasm/WasmSignature.cpp: (JSC::Wasm::Signature::hash): (JSC::Wasm::Signature::tryCreate): (JSC::Wasm::SignatureInformation::SignatureInformation): (JSC::Wasm::SignatureInformation::singleton): (JSC::Wasm::SignatureInformation::adopt): (JSC::Wasm::SignatureInformation::get): (JSC::Wasm::SignatureInformation::tryCleanup): (JSC::Wasm::Signature::create): Deleted. (JSC::Wasm::Signature::createInvalid): Deleted. (JSC::Wasm::Signature::destroy): Deleted. (JSC::Wasm::SignatureInformation::~SignatureInformation): Deleted. * wasm/WasmSignature.h: (JSC::Wasm::Signature::allocatedSize): (JSC::Wasm::Signature::operator==): * wasm/WasmValidate.cpp: (JSC::Wasm::validateFunction): * wasm/WasmValidate.h: * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::destroy): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyFunction.h: * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyWrapperFunction.cpp: (JSC::WebAssemblyWrapperFunction::create): * wasm/js/WebAssemblyWrapperFunction.h: 2017-03-31 Mark Lam <mark.lam@apple.com> Array.prototype.splice() should not be using JSArray::tryCreateForInitializationPrivate(). https://bugs.webkit.org/show_bug.cgi?id=170303 <rdar://problem/31358281> Reviewed by Filip Pizlo. This is because it needs to call getProperty() later to get the values for initializing the array. getProperty() can execute arbitrary code and potentially trigger the GC. This is not allowed for clients of JSArray::tryCreateForInitializationPrivate(). * runtime/ArrayPrototype.cpp: (JSC::arrayProtoFuncSplice): (JSC::copySplicedArrayElements): Deleted. 2017-03-31 Oleksandr Skachkov <gskachkov@gmail.com> String.prototype.replace incorrectly applies "special replacement parameters" when passed a function https://bugs.webkit.org/show_bug.cgi?id=170151 Reviewed by Saam Barati. This patch fixes issue for String.prototype.replace when passed a function with special symbols "$$". It happeneds because substituteBackreferences applies unconditionally, but according to the spec it should be applied only for text 21.1.3.16.8 https://tc39.github.io/ecma262/#sec-string.prototype.replace * runtime/StringPrototype.cpp: (JSC::replaceUsingStringSearch): 2017-03-30 Saam Barati <sbarati@apple.com> WebAssembly: When Wasm calls to C, it should use Wasm::Context* instead of ExecState* to get VM https://bugs.webkit.org/show_bug.cgi?id=170185 Reviewed by Michael Saboff. This is one more step in the direction of PIC-ified Wasm. When we lift WasmCallee above VM, we will no longer be able to get VM from ExecState*. This patch ensures that we don't do that from within the Wasm runtime. Instead, we use the Wasm::Context* to get the VM. This patch also adds a new class, Wasm::Thunks. There is a single Wasm::Thunks that lives in the process. It is responsible for generating a thunk that Wasm relies on. The only such thunk right now is the exception throwing thunk. This patch also rids WasmFaultSignalHandler from any knowledge of VM. Previously, it relied on VM to get the exception handling thunk. The only part of the Wasm runtime that will be allowed to get VM& from ExecState will be WasmBinding. In the future, we plan to keep the calls out to JS to keep a JSCell as the callee. * JavaScriptCore.xcodeproj/project.pbxproj: * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * interpreter/Interpreter.cpp: (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBufferImpl): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromWasmThunkGenerator): Deleted. * jit/ThunkGenerators.h: * runtime/InitializeThreading.cpp: (JSC::initializeThreading): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::getAllCalleeSaveRegisterOffsets): * runtime/VM.h: (JSC::VM::topVMEntryFrameOffset): (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::emitExceptionCheck): * wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * wasm/WasmMemory.cpp: (JSC::Wasm::tryGetFastMemory): * wasm/WasmThunks.cpp: Added. (JSC::Wasm::throwExceptionFromWasmThunkGenerator): (JSC::Wasm::Thunks::initialize): (JSC::Wasm::Thunks::singleton): (JSC::Wasm::Thunks::stub): (JSC::Wasm::Thunks::existingStub): * wasm/WasmThunks.h: Added. * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfVM): * wasm/js/JSWebAssemblyMemory.cpp: (JSC::JSWebAssemblyMemory::grow): * wasm/js/JSWebAssemblyMemory.h: * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::webAssemblyMemoryProtoFuncGrow): 2017-03-30 Mark Lam <mark.lam@apple.com> IntlObject should not be using JSArray::initializeIndex(). https://bugs.webkit.org/show_bug.cgi?id=170302 <rdar://problem/31356918> Reviewed by Saam Barati. JSArray::initializeIndex() is only meant to be used with arrays created using JSArray::tryCreateForInitializationPrivate() under very constrained conditions. * runtime/IntlObject.cpp: (JSC::canonicalizeLocaleList): (JSC::intlObjectFuncGetCanonicalLocales): 2017-03-30 Filip Pizlo <fpizlo@apple.com> Air should support linear scan for optLevel<2 https://bugs.webkit.org/show_bug.cgi?id=170161 Reviewed by Saam Barati. This changes the default opt level of B3 to 2. It makes the other opt levels useful by adding a new register allocator. This new linear scan allocator will produce significantly worse code. But it will produce that code a lot faster than IRC or Briggs. The opt levels are: 0: no optimizations, linear scan 1: some optimizations, linear scan 2: full optimizations, graph coloring (IRC or Briggs based on CPU) What we used to call optLevel=1 is not called optLevel=2, or better yet, optLevel=B3::defaultOptLevel(). We no longer have anything like the old optLevel=0 (which did no optimizations but ran graph coloring). allocateRegistersByLinearScan() faithfully implements Massimiliano Poletto and Vivek Sarkar's famous algorithm. It uses the variant that handles clobbered registers by avoiding assigning ranges to those registers if the range overlaps a clobber. It's engineered to allocate registers very quickly and generate inefficient code without falling off a cliff. The new optLevel=1 speeds up B3 by a factor of 2, and results in a 80% throughput regression. Linear scan runs 4.7x faster than graph coloring on average. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3BasicBlockUtils.h: (JSC::B3::blocksInPreOrder): (JSC::B3::blocksInPostOrder): * b3/B3BlockWorklist.h: * b3/B3CFG.h: (JSC::B3::CFG::newMap): * b3/B3Common.h: (JSC::B3::defaultOptLevel): * b3/B3Compile.h: * b3/B3DuplicateTails.cpp: * b3/B3EliminateCommonSubexpressions.cpp: * b3/B3FixSSA.cpp: (JSC::B3::demoteValues): (JSC::B3::fixSSA): * b3/B3FixSSA.h: * b3/B3Generate.cpp: (JSC::B3::prepareForGeneration): (JSC::B3::generateToAir): * b3/B3Generate.h: * b3/B3HeapRange.cpp: Removed. * b3/B3HeapRange.h: (JSC::B3::HeapRange::HeapRange): Deleted. (JSC::B3::HeapRange::top): Deleted. (JSC::B3::HeapRange::operator==): Deleted. (JSC::B3::HeapRange::operator!=): Deleted. (JSC::B3::HeapRange::operator|): Deleted. (JSC::B3::HeapRange::operator bool): Deleted. (JSC::B3::HeapRange::begin): Deleted. (JSC::B3::HeapRange::end): Deleted. (JSC::B3::HeapRange::overlaps): Deleted. * b3/B3LowerToAir.cpp: * b3/B3MoveConstants.cpp: * b3/B3PhiChildren.h: * b3/B3Procedure.cpp: (JSC::B3::Procedure::dump): (JSC::B3::Procedure::deleteOrphans): (JSC::B3::Procedure::setBlockOrderImpl): * b3/B3ReduceDoubleToFloat.cpp: * b3/B3ReduceStrength.cpp: * b3/B3SSACalculator.h: * b3/B3UseCounts.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: * b3/air/AirAllocateRegistersByLinearScan.cpp: Added. (JSC::B3::Air::allocateRegistersByLinearScan): * b3/air/AirAllocateRegistersByLinearScan.h: Added. * b3/air/AirAllocateStack.cpp: (JSC::B3::Air::allocateStack): * b3/air/AirArg.cpp: (WTF::printInternal): * b3/air/AirArg.h: (JSC::B3::Air::Arg::activeAt): (JSC::B3::Air::Arg::timing): (JSC::B3::Air::Arg::forEachPhase): * b3/air/AirBasicBlock.h: * b3/air/AirBlockWorklist.h: * b3/air/AirCFG.h: (JSC::B3::Air::CFG::newMap): * b3/air/AirEliminateDeadCode.cpp: (JSC::B3::Air::eliminateDeadCode): * b3/air/AirFixObviousSpills.cpp: * b3/air/AirFixPartialRegisterStalls.cpp: (JSC::B3::Air::fixPartialRegisterStalls): * b3/air/AirFixSpillsAfterTerminals.cpp: Added. (JSC::B3::Air::fixSpillsAfterTerminals): * b3/air/AirFixSpillsAfterTerminals.h: Added. * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): (JSC::B3::Air::generate): * b3/air/AirGenerate.h: * b3/air/AirGenerationContext.h: * b3/air/AirInsertionSet.h: * b3/air/AirInst.cpp: (JSC::B3::Air::Inst::needsPadding): * b3/air/AirLowerAfterRegAlloc.cpp: (JSC::B3::Air::lowerAfterRegAlloc): * b3/air/AirLowerEntrySwitch.cpp: (JSC::B3::Air::lowerEntrySwitch): * b3/air/AirOpcode.opcodes: * b3/air/AirPhaseInsertionSet.cpp: Added. (JSC::B3::Air::PhaseInsertionSet::execute): * b3/air/AirPhaseInsertionSet.h: Added. (JSC::B3::Air::PhaseInsertion::PhaseInsertion): (JSC::B3::Air::PhaseInsertion::phase): (JSC::B3::Air::PhaseInsertion::operator<): (JSC::B3::Air::PhaseInsertionSet::PhaseInsertionSet): (JSC::B3::Air::PhaseInsertionSet::appendInsertion): (JSC::B3::Air::PhaseInsertionSet::insertInst): (JSC::B3::Air::PhaseInsertionSet::insert): * b3/air/AirRegLiveness.h: (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): * b3/air/AirSpillEverything.cpp: (JSC::B3::Air::spillEverything): * b3/air/AirTmp.cpp: * b3/air/AirTmp.h: (JSC::B3::Air::Tmp::tmpForIndex): * b3/air/AirTmpInlines.h: (JSC::B3::Air::Tmp::Indexed::Indexed): (JSC::B3::Air::Tmp::Indexed::index): (JSC::B3::Air::Tmp::AbsolutelyIndexed::AbsolutelyIndexed): (JSC::B3::Air::Tmp::AbsolutelyIndexed::index): (JSC::B3::Air::Tmp::indexed): (JSC::B3::Air::Tmp::absolutelyIndexed): (JSC::B3::Air::Tmp::tmpForAbsoluteIndex): * b3/testb3.cpp: (JSC::B3::compile): (JSC::B3::testMulLoadTwice): * jit/RegisterSet.h: (JSC::RegisterSet::add): (JSC::RegisterSet::remove): * runtime/Options.h: * wasm/WasmB3IRGenerator.h: 2017-03-30 Youenn Fablet <youenn@apple.com> Clean up RTCDataChannel https://bugs.webkit.org/show_bug.cgi?id=169732 Reviewed by Chris Dumez. * runtime/CommonIdentifiers.h: Adding RTCDataChannelEvent. 2017-03-30 Saam Barati <sbarati@apple.com> WebAssembly: pass Wasm::Context* to vmEntryToWasm when not using fast TLS https://bugs.webkit.org/show_bug.cgi?id=170182 Reviewed by Mark Lam. This is one more step in the direction of PIC-ified Wasm. I'm removing assumptions that a wasm callee is a cell. We used to use the callee to get the WasmContext off the callee's VM. Instead, this patch makes it so that we pass in the context as a parameter to the JS entrypoint. * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfVM): Deleted. * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::loadWasmContext): (JSC::AssemblyHelpers::storeWasmContext): (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): * jsc.cpp: (functionTestWasmModuleFunctions): * runtime/VM.h: (JSC::VM::wasmContextOffset): Deleted. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::materializeWasmContext): (JSC::Wasm::B3IRGenerator::restoreWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::createJSToWasmWrapper): * wasm/WasmContext.cpp: (JSC::Wasm::loadContext): (JSC::Wasm::storeContext): (JSC::loadWasmContext): Deleted. (JSC::storeWasmContext): Deleted. * wasm/WasmContext.h: (JSC::Wasm::useFastTLS): (JSC::Wasm::useFastTLSForContext): * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::PinnedRegisterInfo::get): * wasm/WasmMemoryInformation.h: (JSC::Wasm::useFastTLS): Deleted. (JSC::Wasm::useFastTLSForWasmContext): Deleted. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): 2017-03-30 JF Bastien <jfbastien@apple.com> WebAssembly: fix misc JS API implementation inconsistencies https://bugs.webkit.org/show_bug.cgi?id=170187 Reviewed by Keith Miller. Auto-generate lookup tables. Methods should be on prototype. Exception returns should be idiomatic. * wasm/JSWebAssembly.cpp: validate / compile / instantiate should be on the prototype (JSC::JSWebAssembly::create): (JSC::JSWebAssembly::finishCreation): (JSC::reject): Deleted. (JSC::webAssemblyCompileFunc): Deleted. (JSC::resolve): Deleted. (JSC::instantiate): Deleted. (JSC::compileAndInstantiate): Deleted. (JSC::webAssemblyInstantiateFunc): Deleted. (JSC::webAssemblyValidateFunc): Deleted. * wasm/JSWebAssembly.h: * wasm/js/WebAssemblyMemoryPrototype.cpp: move from JSWebAssembly.cpp (JSC::webAssemblyMemoryProtoFuncBuffer): (JSC::WebAssemblyMemoryPrototype::create): (JSC::WebAssemblyMemoryPrototype::finishCreation): * wasm/js/WebAssemblyMemoryPrototype.h: * wasm/js/WebAssemblyPrototype.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyInstantiateFunc): (JSC::webAssemblyValidateFunc): (JSC::webAssemblyFunctionValidate): Deleted. (JSC::webAssemblyFunctionCompile): Deleted. * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::webAssemblyTableProtoFuncGrow): (JSC::webAssemblyTableProtoFuncGet): (JSC::webAssemblyTableProtoFuncSet): (JSC::WebAssemblyTablePrototype::create): (JSC::WebAssemblyTablePrototype::finishCreation): * wasm/js/WebAssemblyTablePrototype.h: 2017-03-29 Keith Miller <keith_miller@apple.com> Unreviewed, fix the build, again. Hopefully for the last time, again! * runtime/Options.cpp: 2017-03-29 Keith Miller <keith_miller@apple.com> Unreviewed, fix the build, again. Hopefully for the last time! * runtime/Options.cpp: (JSC::parse): 2017-03-29 Keith Miller <keith_miller@apple.com> Unreviewed, windows build fix. * runtime/Options.cpp: (JSC::parse): 2017-03-29 Keith Miller <keith_miller@apple.com> WebAssembly: B3IRGenerator should pool constants https://bugs.webkit.org/show_bug.cgi?id=170266 Reviewed by Filip Pizlo. This patch adds a HashMap to B3IRGenerator that contains all the constants used in a function. B3IRGenerator then uses an InsertionSet to add all those constants to the root BB. This doesn't appear to be a compile time improvement but it could be valuable in the future. * b3/B3Opcode.h: (JSC::B3::opcodeForConstant): * b3/B3Procedure.cpp: (JSC::B3::Procedure::addConstant): * b3/B3Procedure.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::constant): (JSC::Wasm::B3IRGenerator::insertConstants): (JSC::Wasm::B3IRGenerator::addConstant): (JSC::Wasm::B3IRGenerator::dump): (JSC::Wasm::parseAndCompile): (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv): (JSC::Wasm::B3IRGenerator::zeroForType): Deleted. * wasm/generateWasmB3IRGeneratorInlinesHeader.py: (generateConstCode): 2017-03-29 Saam Barati <sbarati@apple.com> LinkBuffer and ExecutableAllocator shouldn't have anything to do with VM https://bugs.webkit.org/show_bug.cgi?id=170210 Reviewed by Mark Lam. This is one more step in the direction of PIC-ified Wasm. LinkBuffer and ExecutableAllocator have no business knowing about VM. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::allocate): * assembler/LinkBuffer.h: (JSC::LinkBuffer::LinkBuffer): (JSC::LinkBuffer::vm): Deleted. * b3/B3Compile.cpp: (JSC::B3::compile): * b3/B3Compile.h: * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::compileProc): (JSC::B3::compileAndRun): (JSC::B3::testLoadAcq42): (JSC::B3::testAddArgZeroImmZDef): (JSC::B3::testAddLoadTwice): (JSC::B3::testMulLoadTwice): (JSC::B3::testMulAddArgsLeft): (JSC::B3::testMulAddArgsRight): (JSC::B3::testMulAddArgsLeft32): (JSC::B3::testMulAddArgsRight32): (JSC::B3::testMulSubArgsLeft): (JSC::B3::testMulSubArgsRight): (JSC::B3::testMulSubArgsLeft32): (JSC::B3::testMulSubArgsRight32): (JSC::B3::testMulNegArgs): (JSC::B3::testMulNegArgs32): (JSC::B3::testCompareFloatToDoubleThroughPhi): (JSC::B3::testDoubleToFloatThroughPhi): (JSC::B3::testReduceFloatToDoubleValidates): (JSC::B3::testDoubleProducerPhiToFloatConversion): (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer): (JSC::B3::testDoubleProducerPhiWithNonFloatConst): (JSC::B3::testIToD64Arg): (JSC::B3::testIToF64Arg): (JSC::B3::testIToD32Arg): (JSC::B3::testIToF32Arg): (JSC::B3::testIToD64Mem): (JSC::B3::testIToF64Mem): (JSC::B3::testIToD32Mem): (JSC::B3::testIToF32Mem): (JSC::B3::testIToDReducedToIToF64Arg): (JSC::B3::testIToDReducedToIToF32Arg): (JSC::B3::testStoreRelAddLoadAcq32): (JSC::B3::testStoreRelAddLoadAcq8): (JSC::B3::testStoreRelAddFenceLoadAcq8): (JSC::B3::testStoreRelAddLoadAcq16): (JSC::B3::testStoreRelAddLoadAcq64): (JSC::B3::testBranch): (JSC::B3::testBranchPtr): (JSC::B3::testDiamond): (JSC::B3::testBranchNotEqual): (JSC::B3::testBranchNotEqualCommute): (JSC::B3::testBranchNotEqualNotEqual): (JSC::B3::testBranchEqual): (JSC::B3::testBranchEqualEqual): (JSC::B3::testBranchEqualCommute): (JSC::B3::testBranchEqualEqual1): (JSC::B3::testBranchLoadPtr): (JSC::B3::testBranchLoad32): (JSC::B3::testBranchLoad8S): (JSC::B3::testBranchLoad8Z): (JSC::B3::testBranchLoad16S): (JSC::B3::testBranchLoad16Z): (JSC::B3::testBranch8WithLoad8ZIndex): (JSC::B3::testComplex): (JSC::B3::testSimpleCheck): (JSC::B3::testCheckFalse): (JSC::B3::testCheckTrue): (JSC::B3::testCheckLessThan): (JSC::B3::testCheckMegaCombo): (JSC::B3::testCheckTrickyMegaCombo): (JSC::B3::testCheckTwoMegaCombos): (JSC::B3::testCheckTwoNonRedundantMegaCombos): (JSC::B3::testCheckAddImm): (JSC::B3::testCheckAddImmCommute): (JSC::B3::testCheckAddImmSomeRegister): (JSC::B3::testCheckAdd): (JSC::B3::testCheckAdd64): (JSC::B3::testCheckAddFold): (JSC::B3::testCheckAddFoldFail): (JSC::B3::testCheckAddSelfOverflow64): (JSC::B3::testCheckAddSelfOverflow32): (JSC::B3::testCheckSubImm): (JSC::B3::testCheckSubBadImm): (JSC::B3::testCheckSub): (JSC::B3::testCheckSub64): (JSC::B3::testCheckSubFold): (JSC::B3::testCheckSubFoldFail): (JSC::B3::testCheckNeg): (JSC::B3::testCheckNeg64): (JSC::B3::testCheckMul): (JSC::B3::testCheckMulMemory): (JSC::B3::testCheckMul2): (JSC::B3::testCheckMul64): (JSC::B3::testCheckMulFold): (JSC::B3::testCheckMulFoldFail): (JSC::B3::testCheckMul64SShr): (JSC::B3::testSwitch): (JSC::B3::testSwitchChillDiv): (JSC::B3::testSwitchTargettingSameBlock): (JSC::B3::testSwitchTargettingSameBlockFoldPathConstant): (JSC::B3::testBasicSelect): (JSC::B3::testSelectTest): (JSC::B3::testSelectCompareDouble): (JSC::B3::testSelectDouble): (JSC::B3::testSelectDoubleTest): (JSC::B3::testSelectDoubleCompareDouble): (JSC::B3::testSelectFloatCompareFloat): (JSC::B3::testSelectFold): (JSC::B3::testSelectInvert): (JSC::B3::testCheckSelect): (JSC::B3::testCheckSelectCheckSelect): (JSC::B3::testCheckSelectAndCSE): (JSC::B3::testTrivialInfiniteLoop): (JSC::B3::testFoldPathEqual): (JSC::B3::testLShiftSelf32): (JSC::B3::testRShiftSelf32): (JSC::B3::testURShiftSelf32): (JSC::B3::testLShiftSelf64): (JSC::B3::testRShiftSelf64): (JSC::B3::testURShiftSelf64): (JSC::B3::testPatchpointDoubleRegs): (JSC::B3::testSpillDefSmallerThanUse): (JSC::B3::testSpillUseLargerThanDef): (JSC::B3::testLateRegister): (JSC::B3::testInterpreter): (JSC::B3::testEntrySwitchSimple): (JSC::B3::testEntrySwitchNoEntrySwitch): (JSC::B3::testEntrySwitchWithCommonPaths): (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint): (JSC::B3::testEntrySwitchLoop): (JSC::B3::testSomeEarlyRegister): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled): (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2): (JSC::B3::testPatchpointTerminalReturnValue): (JSC::B3::testMemoryFence): (JSC::B3::testStoreFence): (JSC::B3::testLoadFence): (JSC::B3::testPCOriginMapDoesntInsertNops): (JSC::B3::testPinRegisters): (JSC::B3::testX86LeaAddAddShlLeft): (JSC::B3::testX86LeaAddAddShlRight): (JSC::B3::testX86LeaAddAdd): (JSC::B3::testX86LeaAddShlRight): (JSC::B3::testX86LeaAddShlLeftScale1): (JSC::B3::testX86LeaAddShlLeftScale2): (JSC::B3::testX86LeaAddShlLeftScale4): (JSC::B3::testX86LeaAddShlLeftScale8): (JSC::B3::testAddShl32): (JSC::B3::testAddShl64): (JSC::B3::testAddShl65): (JSC::B3::testLoadBaseIndexShift2): (JSC::B3::testLoadBaseIndexShift32): (JSC::B3::testOptimizeMaterialization): (JSC::B3::testAtomicWeakCAS): (JSC::B3::testAtomicStrongCAS): (JSC::B3::testAtomicXchg): (JSC::B3::testDepend32): (JSC::B3::testDepend64): (JSC::B3::testWasmBoundsCheck): (JSC::B3::testWasmAddress): (JSC::B3::run): (JSC::B3::compile): Deleted. * bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGLazyJSValue.cpp: (JSC::DFG::LazyJSValue::emit): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLazySlowPath.cpp: (JSC::FTL::LazySlowPath::generate): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLOSRExitHandle.cpp: (JSC::FTL::OSRExitHandle::emitExitThunk): * ftl/FTLSlowPathCall.cpp: (JSC::FTL::SlowPathCallContext::makeCall): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * ftl/FTLState.h: * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * ftl/FTLThunks.h: (JSC::FTL::generateIfNecessary): (JSC::FTL::Thunks::getSlowPathCallThunk): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::emitDumbVirtualCall): * jit/AssemblyHelpers.h: * jit/ExecutableAllocator.cpp: (JSC::ExecutableAllocator::initializeAllocator): (JSC::ExecutableAllocator::singleton): (JSC::ExecutableAllocator::ExecutableAllocator): (JSC::ExecutableAllocator::allocate): * jit/ExecutableAllocator.h: * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * jit/JITCall.cpp: (JSC::JIT::compileCallEvalSlowCase): * jit/JITMathIC.h: (JSC::JITMathIC::generateOutOfLine): * jit/JITOpcodes.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileHasIndexedProperty): * jit/JITOperations.cpp: * jit/JITOperations.h: * jit/JITPropertyAccess.cpp: (JSC::JIT::stringGetByValStubGenerator): (JSC::JIT::privateCompileGetByVal): (JSC::JIT::privateCompileGetByValWithCachedId): (JSC::JIT::privateCompilePutByVal): (JSC::JIT::privateCompilePutByValWithCachedId): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::stringGetByValStubGenerator): * jit/JITStubRoutine.h: * jit/Repatch.cpp: (JSC::ftlThunkAwareRepatchCall): (JSC::linkPolymorphicCall): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::linkCallThunkGenerator): (JSC::linkPolymorphicCallThunkGenerator): (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::arityFixupGenerator): (JSC::unreachableGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): (JSC::throwExceptionFromWasmThunkGenerator): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::takeSample): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * runtime/VMTraps.cpp: (JSC::VMTraps::tryInstallTrapBreakpoints): * tools/VMInspector.cpp: * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): (JSC::Wasm::exitStubGenerator): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::complete): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::compile): (JSC::Yarr::jitCompile): 2017-03-29 Keith Miller <keith_miller@apple.com> WebAssembly: Worklist should periodically check in to see if there are higher priority jobs to do. https://bugs.webkit.org/show_bug.cgi?id=170204 Reviewed by Saam Barati. This patch makes it so that Wasm::Plan's compileFunctions method can return periodically to its caller. The main use for this is if a user asynchronously compiles a wasm module then later synchronously compiles another module. In this case we want to be able to pause compilation of other worklists. This patch also adds support for size_t Options. * runtime/Options.cpp: (JSC::parse): (JSC::Option::dump): (JSC::Option::operator==): * runtime/Options.h: * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::moveToState): (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::Plan::compileFunctions): * wasm/WasmPlan.h: * wasm/WasmWorklist.cpp: 2017-03-29 Mark Lam <mark.lam@apple.com> Remove obsolete references to HeapTimer in JavaScriptCore.order. https://bugs.webkit.org/show_bug.cgi?id=170252 Reviewed by Saam Barati. The HeapTimer was renamed to JSRunLoopTimer back in r214504. These HeapTimer entries are now no longer meaningful. * JavaScriptCore.order: 2017-03-29 JF Bastien <jfbastien@apple.com> WebAssembly: add shell-only Memory mode helper https://bugs.webkit.org/show_bug.cgi?id=170227 Reviewed by Mark Lam. * jsc.cpp: (GlobalObject::finishCreation): (functionWebAssemblyMemoryMode): * wasm/WasmMemory.h: * wasm/js/JSWebAssemblyInstance.h: * wasm/js/JSWebAssemblyMemory.h: 2017-03-29 Keith Miller <keith_miller@apple.com> WebAssembly: pack OpcodeOrigin to fit in a pointer https://bugs.webkit.org/show_bug.cgi?id=170244 Reviewed by Michael Saboff. This patch makes it so we don't have to have allocate the OpcodeOrigin and can just pack all the data into the pointer B3::Origin already has. * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmOpcodeOrigin.cpp: (JSC::Wasm::OpcodeOrigin::dump): * wasm/WasmOpcodeOrigin.h: (JSC::Wasm::OpcodeOrigin::OpcodeOrigin): (JSC::Wasm::OpcodeOrigin::opcode): (JSC::Wasm::OpcodeOrigin::location): 2017-03-29 JF Bastien <jfbastien@apple.com> WebAssembly: NFC s/goto/lambda/g https://bugs.webkit.org/show_bug.cgi?id=170242 Reviewed by Mark Lam. Lambdas are more in-style than the goto I just used. * wasm/WasmMemory.cpp: (JSC::Wasm::tryGetFastMemory): 2017-03-28 Saam Barati <sbarati@apple.com> AssemblyHelpers should not have a VM field https://bugs.webkit.org/show_bug.cgi?id=170207 Reviewed by Yusuke Suzuki. APIs that need VM should take one as a parameter. When doing position independent code for Wasm, we can't tie code generation to a VM. * b3/B3Compile.cpp: (JSC::B3::compile): * b3/air/testair.cpp: * b3/testb3.cpp: (JSC::B3::testEntrySwitchSimple): (JSC::B3::testEntrySwitchNoEntrySwitch): (JSC::B3::testEntrySwitchWithCommonPaths): (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint): (JSC::B3::testEntrySwitchLoop): * bytecode/AccessCase.cpp: (JSC::AccessCase::generateWithGuard): (JSC::AccessCase::generateImpl): * bytecode/DOMJITAccessCasePatchpointParams.cpp: (JSC::SlowPathCallGeneratorWithArguments::generateImpl): * bytecode/InlineAccess.cpp: (JSC::InlineAccess::dumpCacheSizesAndCrash): (JSC::InlineAccess::generateSelfPropertyAccess): (JSC::InlineAccess::generateSelfPropertyReplace): (JSC::InlineAccess::generateArrayLength): (JSC::InlineAccess::rewireStubAsJump): * bytecode/InlineAccess.h: * bytecode/PolymorphicAccess.cpp: (JSC::AccessGenerationState::emitExplicitExceptionHandler): (JSC::PolymorphicAccess::regenerate): * bytecode/PolymorphicAccess.h: (JSC::AccessGenerationState::AccessGenerationState): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::JITCompiler): (JSC::DFG::JITCompiler::compileExceptionHandlers): (JSC::DFG::JITCompiler::link): (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): (JSC::DFG::JITCompiler::exceptionCheck): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback): (JSC::DFG::JITCompiler::fastExceptionCheck): (JSC::DFG::JITCompiler::vm): * dfg/DFGOSRExitCompiler.cpp: * dfg/DFGOSRExitCompiler.h: * dfg/DFGOSRExitCompiler32_64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::adjustAndJumpToTarget): * dfg/DFGOSRExitCompilerCommon.h: * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::emitAllocateRawObject): (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject): (JSC::DFG::SpeculativeJIT::compileMakeRope): (JSC::DFG::SpeculativeJIT::compileGetGlobalObject): (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon): (JSC::DFG::SpeculativeJIT::compileCreateActivation): (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments): (JSC::DFG::SpeculativeJIT::compileSpread): (JSC::DFG::SpeculativeJIT::compileArraySlice): (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly): (JSC::DFG::SpeculativeJIT::compileNewStringObject): (JSC::DFG::SpeculativeJIT::compileNewTypedArray): (JSC::DFG::SpeculativeJIT::compileStoreBarrier): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize): (JSC::DFG::SpeculativeJIT::emitAllocateJSObject): (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined): (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined): (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): (JSC::DFG::SpeculativeJIT::compileLogicalNot): (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch): (JSC::DFG::SpeculativeJIT::emitBranch): (JSC::DFG::SpeculativeJIT::compile): (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize): * dfg/DFGThunks.cpp: (JSC::DFG::osrEntryThunkGenerator): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLJITFinalizer.h: * ftl/FTLLazySlowPath.cpp: (JSC::FTL::LazySlowPath::generate): * ftl/FTLLazySlowPathCall.h: (JSC::FTL::createLazyCallGenerator): * ftl/FTLLink.cpp: (JSC::FTL::link): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction): (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments): (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope): (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull): (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject): (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation): (JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps): (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl): (JSC::FTL::DFG::LowerDFGToB3::allocateObject): (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray): (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLSlowPathCall.h: (JSC::FTL::callOperation): * ftl/FTLState.h: (JSC::FTL::State::vm): * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::jitReleaseAssertNoException): (JSC::AssemblyHelpers::callExceptionFuzz): (JSC::AssemblyHelpers::emitJumpIfException): (JSC::AssemblyHelpers::emitExceptionCheck): (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck): (JSC::AssemblyHelpers::emitLoadStructure): (JSC::AssemblyHelpers::emitRandomThunk): (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::emitConvertValueToBoolean): (JSC::AssemblyHelpers::debugCall): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::AssemblyHelpers): (JSC::AssemblyHelpers::codeBlock): (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer): (JSC::AssemblyHelpers::barrierBranch): (JSC::AssemblyHelpers::barrierStoreLoadFence): (JSC::AssemblyHelpers::mutatorFence): (JSC::AssemblyHelpers::storeButterfly): (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly): (JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded): (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize): (JSC::AssemblyHelpers::emitAllocateJSObject): (JSC::AssemblyHelpers::emitAllocateVariableSizedCell): (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject): (JSC::AssemblyHelpers::emitAllocateDestructibleObject): (JSC::AssemblyHelpers::vm): Deleted. (JSC::AssemblyHelpers::debugCall): Deleted. * jit/CCallHelpers.cpp: (JSC::CCallHelpers::ensureShadowChickenPacket): * jit/CCallHelpers.h: (JSC::CCallHelpers::CCallHelpers): (JSC::CCallHelpers::jumpToExceptionHandler): * jit/JIT.cpp: (JSC::JIT::emitEnterOptimizationCheck): (JSC::JIT::privateCompileExceptionHandlers): * jit/JIT.h: (JSC::JIT::exceptionCheck): (JSC::JIT::exceptionCheckWithCallFrameRollback): * jit/JITMathIC.h: (JSC::JITMathIC::generateOutOfLine): * jit/JITOpcodes.cpp: (JSC::JIT::emit_op_instanceof): (JSC::JIT::emit_op_is_undefined): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jeq_null): (JSC::JIT::emit_op_jneq_null): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_eq_null): (JSC::JIT::emit_op_neq_null): (JSC::JIT::emitSlow_op_loop_hint): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITOpcodes32_64.cpp: (JSC::JIT::privateCompileCTINativeCall): (JSC::JIT::emit_op_new_object): (JSC::JIT::emit_op_jfalse): (JSC::JIT::emit_op_jtrue): (JSC::JIT::emit_op_throw): (JSC::JIT::emit_op_catch): (JSC::JIT::emit_op_create_this): (JSC::JIT::emit_op_log_shadow_chicken_prologue): (JSC::JIT::emit_op_log_shadow_chicken_tail): * jit/JITPropertyAccess.cpp: (JSC::JIT::emitWriteBarrier): * jit/JSInterfaceJIT.h: (JSC::JSInterfaceJIT::JSInterfaceJIT): (JSC::JSInterfaceJIT::vm): * jit/Repatch.cpp: (JSC::tryCacheGetByID): (JSC::tryCachePutByID): (JSC::linkPolymorphicCall): (JSC::resetGetByID): (JSC::resetPutByID): * jit/SetupVarargsFrame.cpp: (JSC::emitSetupVarargsFrameFastCase): * jit/SetupVarargsFrame.h: * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::linkCallThunkGenerator): (JSC::linkPolymorphicCallThunkGenerator): (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::randomThunkGenerator): (JSC::boundThisNoArgsFunctionCallGenerator): (JSC::throwExceptionFromWasmThunkGenerator): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::parseAndCompile): * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): 2017-03-28 Keith Miller <keith_miller@apple.com> WebAssembly: We should have Origins https://bugs.webkit.org/show_bug.cgi?id=170217 Reviewed by Mark Lam. This patch adds wasm origins for B3::Values, called OpcodeOrigin. Currently, OpcodeOrigin just tracks the original opcode and the location of that opcode. Here's a sample: BB#0: ; frequency = 1.000000 Int64 @4 = Patchpoint(generator = 0x10f487fa8, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister) Int64 @5 = FramePointer() Void @8 = Store(@4, @5, offset = 24, ControlDependent|Writes:Top) Int64 @10 = Const64(0) Void @12 = Store($0(@10), @5, offset = 16, ControlDependent|Writes:Top) Int64 @13 = Patchpoint(generator = 0x10f4be7f0, earlyClobbered = [], lateClobbered = [], usedRegisters = [], resultConstraint = SomeRegister, ExitsSideways|ControlDependent|WritesPinned|ReadsPinned|Fence|Writes:Top|Reads:Top) Int64 @16 = ArgumentReg(%rdi) Int64 @18 = ArgumentReg(%rsi) Int32 @22 = Trunc(@18, Wasm: {opcode: I64Rotl, location: 5}) Int64 @23 = RotL(@16, @22, Wasm: {opcode: I64Rotl, location: 5}) Void @27 = Return(@23, Terminal, Wasm: {opcode: End, location: 6}) * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3Value.cpp: (JSC::B3::Value::deepDump): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::setParser): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::emitLoadOp): (JSC::Wasm::B3IRGenerator::emitStoreOp): (JSC::Wasm::B3IRGenerator::addConstant): (JSC::Wasm::B3IRGenerator::addLoop): (JSC::Wasm::B3IRGenerator::unify): (JSC::Wasm::parseAndCompile): (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv): (JSC::Wasm::getMemoryBaseAndSize): Deleted. * wasm/WasmFunctionParser.h: (JSC::Wasm::FunctionParser::currentOpcode): (JSC::Wasm::FunctionParser::currentOpcodeStartingOffset): (JSC::Wasm::FunctionParser<Context>::FunctionParser): * wasm/WasmOpcodeOrigin.cpp: Added. (JSC::Wasm::OpcodeOrigin::dump): * wasm/WasmOpcodeOrigin.h: Added. (JSC::Wasm::OpcodeOrigin::OpcodeOrigin): * wasm/WasmValidate.cpp: (JSC::Wasm::Validate::setParser): * wasm/generateWasmB3IRGeneratorInlinesHeader.py: (CodeGenerator.generate): (generateB3OpCode): (generateConstCode): 2017-03-28 JF Bastien <jfbastien@apple.com> WebAssembly: option to crash if no fast memory is available https://bugs.webkit.org/show_bug.cgi?id=170219 Reviewed by Mark Lam. * runtime/Options.h: * wasm/WasmMemory.cpp: (JSC::Wasm::webAssemblyCouldntGetFastMemory): (JSC::Wasm::tryGetFastMemory): 2017-03-28 Mark Lam <mark.lam@apple.com> The Mutator should not be able to steal the conn if the Collector hasn't reached the NotRunning phase yet. https://bugs.webkit.org/show_bug.cgi?id=170213 <rdar://problem/30755345> Reviewed by Filip Pizlo. The current condition for stealing the conn isn't tight enough. Restricting the stealing to when m_currentPhase == NotRunning ensures that the Collector is really done running. No test because this issue only manifests with a race condition that is difficult to reproduce on demand. * heap/Heap.cpp: (JSC::Heap::requestCollection): 2017-03-28 Keith Miller <keith_miller@apple.com> WebAssembly: Make WebAssembly.instantiate/compile truly asynchronous https://bugs.webkit.org/show_bug.cgi?id=169187 Reviewed by Saam Barati. This patch allows WebAssembly compilations to happen asynchronously. To do so, it refactors how much of the compilation happens and adds new infrastructure for async promises. First, there is a new class, PromiseDeferredTimer that lives on the VM. PromiseDeferredTimer will manage the life-cycle of async pending promises and any dependencies that promise needs. PromiseDeferredTimer automagically releases the pending promise and dependencies once the JSPromiseDeferred is resolved or rejected. Additionally, PromiseDeferredTimer provides a mechanism to poll the run-loop whenever the async task needs to synchronize with the JS thread. Normally, that will be whenever the async task finishes. In the case of Web Assembly we also use this feature for the compile + instantiate case, where we might have more work after the first async task completes (more on that later). The next class is Wasm::Worklist, which is used to manage Wasm compilation tasks. The worklist class works similarly to the DFG/FTL Worklists. It has a pool of threads that it manages. One interesting aspect of Wasm Worklist is that it can synchronously compile a plan that is already potentially running asynchronously. This can occur if a user calls WebAssembly.instantiate() then new WebAssembly.instantiate() on the same module. In that case the Wasm Worklist will bump the priority of the running pending Plan and block the JS thread. This patch also makes some of the Wasm Plan code cleaner. Since we now defer all compilation to instantiation time, we no longer need to guess at which memory we are going to get. Also, Wasm Plans now track the work they have done with a state enum. Finally, this patch makes renamed HeapTimer to JSRunLoopTimer. It also adds changes test262AsyncTest to a more generic testing infrastructure. Now, in addition to the old functionality, you can call asyncTest() with the number of tests you expect. When the jsc CLI exits, it will guarantee that asyncTestPassed() is called that many times. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * heap/GCActivityCallback.h: * heap/IncrementalSweeper.cpp: (JSC::IncrementalSweeper::scheduleTimer): (JSC::IncrementalSweeper::IncrementalSweeper): * heap/IncrementalSweeper.h: * heap/StopIfNecessaryTimer.cpp: (JSC::StopIfNecessaryTimer::StopIfNecessaryTimer): * heap/StopIfNecessaryTimer.h: * heap/StrongInlines.h: * jsc.cpp: (GlobalObject::finishCreation): (printInternal): (functionAsyncTestStart): (functionAsyncTestPassed): (functionTestWasmModuleFunctions): (CommandLine::parseArguments): (runJSC): * runtime/JSPromiseDeferred.cpp: (JSC::JSPromiseDeferred::resolve): (JSC::JSPromiseDeferred::reject): * runtime/JSPromiseDeferred.h: (JSC::JSPromiseDeferred::promiseAsyncPending): * runtime/JSRunLoopTimer.cpp: Renamed from Source/JavaScriptCore/heap/HeapTimer.cpp. (JSC::JSRunLoopTimer::JSRunLoopTimer): (JSC::JSRunLoopTimer::setRunLoop): (JSC::JSRunLoopTimer::~JSRunLoopTimer): (JSC::JSRunLoopTimer::timerDidFire): (JSC::JSRunLoopTimer::scheduleTimer): (JSC::JSRunLoopTimer::cancelTimer): (JSC::JSRunLoopTimer::invalidate): * runtime/JSRunLoopTimer.h: Copied from Source/JavaScriptCore/heap/HeapTimer.h. * runtime/Options.h: * runtime/PromiseDeferredTimer.cpp: Added. (JSC::PromiseDeferredTimer::PromiseDeferredTimer): (JSC::PromiseDeferredTimer::doWork): (JSC::PromiseDeferredTimer::runRunLoop): (JSC::PromiseDeferredTimer::addPendingPromise): (JSC::PromiseDeferredTimer::cancelPendingPromise): (JSC::PromiseDeferredTimer::scheduleWorkSoon): (JSC::PromiseDeferredTimer::scheduleBlockedTask): * runtime/PromiseDeferredTimer.h: Renamed from Source/JavaScriptCore/heap/HeapTimer.h. (JSC::PromiseDeferredTimer::stopRunningTasks): * runtime/VM.cpp: (JSC::VM::VM): (JSC::VM::~VM): * runtime/VM.h: * wasm/JSWebAssembly.cpp: (JSC::reject): (JSC::webAssemblyCompileFunc): (JSC::resolve): (JSC::instantiate): (JSC::compileAndInstantiate): (JSC::webAssemblyInstantiateFunc): (JSC::webAssemblyValidateFunc): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer): (JSC::Wasm::B3IRGenerator::memoryKind): (JSC::Wasm::parseAndCompile): * wasm/WasmB3IRGenerator.h: * wasm/WasmFormat.h: (JSC::Wasm::ModuleInformation::internalFunctionCount): * wasm/WasmFunctionParser.h: * wasm/WasmMemory.h: * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::MemoryInformation::MemoryInformation): * wasm/WasmMemoryInformation.h: (JSC::Wasm::MemoryInformation::maximum): (JSC::Wasm::MemoryInformation::hasReservedMemory): Deleted. (JSC::Wasm::MemoryInformation::takeReservedMemory): Deleted. (JSC::Wasm::MemoryInformation::mode): Deleted. * wasm/WasmModuleParser.cpp: * wasm/WasmModuleParser.h: (JSC::Wasm::ModuleParser::ModuleParser): * wasm/WasmPlan.cpp: (JSC::Wasm::Plan::Plan): (JSC::Wasm::Plan::stateString): (JSC::Wasm::Plan::moveToState): (JSC::Wasm::Plan::fail): (JSC::Wasm::Plan::parseAndValidateModule): (JSC::Wasm::Plan::prepare): (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): (JSC::Wasm::Plan::compileFunctions): (JSC::Wasm::Plan::complete): (JSC::Wasm::Plan::waitForCompletion): (JSC::Wasm::Plan::cancel): (JSC::Wasm::Plan::run): Deleted. (JSC::Wasm::Plan::initializeCallees): Deleted. * wasm/WasmPlan.h: (JSC::Wasm::Plan::dontFinalize): (JSC::Wasm::Plan::exports): (JSC::Wasm::Plan::internalFunctionCount): (JSC::Wasm::Plan::takeModuleInformation): (JSC::Wasm::Plan::takeCallLinkInfos): (JSC::Wasm::Plan::takeWasmExitStubs): (JSC::Wasm::Plan::setModeAndPromise): (JSC::Wasm::Plan::mode): (JSC::Wasm::Plan::pendingPromise): (JSC::Wasm::Plan::vm): (JSC::Wasm::Plan::errorMessage): (JSC::Wasm::Plan::failed): (JSC::Wasm::Plan::hasWork): (JSC::Wasm::Plan::hasBeenPrepared): * wasm/WasmPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmB3IRGenerator.h. (JSC::Wasm::Plan::initializeCallees): * wasm/WasmValidate.cpp: * wasm/WasmWorklist.cpp: Added. (JSC::Wasm::Worklist::priorityString): (JSC::Wasm::Worklist::QueueElement::setToNextPriority): (JSC::Wasm::Worklist::iterate): (JSC::Wasm::Worklist::enqueue): (JSC::Wasm::Worklist::completePlanSynchronously): (JSC::Wasm::Worklist::stopAllPlansForVM): (JSC::Wasm::Worklist::Worklist): (JSC::Wasm::Worklist::~Worklist): (JSC::Wasm::existingWorklistOrNull): (JSC::Wasm::ensureWorklist): * wasm/WasmWorklist.h: Added. (JSC::Wasm::Worklist::nextTicket): (JSC::Wasm::Worklist::Comparator::operator()): * wasm/js/JSWebAssemblyCallee.h: * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock): (JSC::JSWebAssemblyCodeBlock::initialize): (JSC::JSWebAssemblyCodeBlock::isSafeToRun): * wasm/js/JSWebAssemblyCodeBlock.h: (JSC::JSWebAssemblyCodeBlock::create): (JSC::JSWebAssemblyCodeBlock::initialized): (JSC::JSWebAssemblyCodeBlock::plan): (JSC::JSWebAssemblyCodeBlock::runnable): (JSC::JSWebAssemblyCodeBlock::errorMessage): (JSC::JSWebAssemblyCodeBlock::callees): * wasm/js/JSWebAssemblyHelpers.h: (JSC::createSourceBufferFromValue): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): (JSC::JSWebAssemblyInstance::finalizeCreation): (JSC::JSWebAssemblyInstance::create): (JSC::JSWebAssemblyInstance::setMemory): Deleted. * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::codeBlock): (JSC::JSWebAssemblyInstance::initialized): (JSC::JSWebAssemblyInstance::module): (JSC::JSWebAssemblyInstance::importFunction): (JSC::JSWebAssemblyInstance::setMemory): (JSC::JSWebAssemblyInstance::table): (JSC::JSWebAssemblyInstance::importFunctions): (JSC::JSWebAssemblyInstance::setImportFunction): Deleted. (JSC::JSWebAssemblyInstance::setTable): Deleted. * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::createStub): (JSC::JSWebAssemblyModule::JSWebAssemblyModule): (JSC::JSWebAssemblyModule::finishCreation): (JSC::JSWebAssemblyModule::setCodeBlock): (JSC::JSWebAssemblyModule::buildCodeBlock): Deleted. (JSC::JSWebAssemblyModule::create): Deleted. (JSC::JSWebAssemblyModule::codeBlock): Deleted. * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::moduleInformation): (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::source): (JSC::JSWebAssemblyModule::takeReservedMemory): Deleted. (JSC::JSWebAssemblyModule::codeBlockFor): Deleted. * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::constructJSWebAssemblyInstance): (JSC::WebAssemblyInstanceConstructor::createInstance): Deleted. * wasm/js/WebAssemblyModuleConstructor.cpp: (JSC::WebAssemblyModuleConstructor::createModule): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoImports): (JSC::webAssemblyModuleProtoExports): * wasm/js/WebAssemblyModuleRecord.cpp: (JSC::WebAssemblyModuleRecord::finishCreation): (JSC::WebAssemblyModuleRecord::link): (JSC::WebAssemblyModuleRecord::evaluate): * wasm/js/WebAssemblyModuleRecord.h: 2017-03-28 Yusuke Suzuki <utatane.tea@gmail.com> WebAssembly: add fallback to use pinned register to load/store state https://bugs.webkit.org/show_bug.cgi?id=169773 Reviewed by Saam Barati. This patch adds a new pinned register to hold JSWebAssemblyInstance, which is used to represent the context of running Wasm code. While we use fast TLS to hold the context in macOS, we do not have any system reserved fast TLS slot in the other systems. This pinned register approach is used in these systems. These changes decouple VM from Wasm module to make Wasm module position independent code. While using fast TLS could be beneficial in x64 systems which number of registers is relatively small, pinned register approach could be beneficial in ARM64 which has plenty of registers. In macOS, we can switch the implementation with the runtime flag. Thus macOS port can compare the performance and decide which implementation is used after landing this patch. * heap/MarkedBlock.h: (JSC::MarkedBlock::offsetOfVM): * jit/AssemblyHelpers.cpp: (JSC::AssemblyHelpers::loadWasmContext): (JSC::AssemblyHelpers::storeWasmContext): (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::loadWasmContext): Deleted. (JSC::AssemblyHelpers::storeWasmContext): Deleted. (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): Deleted. (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): Deleted. * jit/Repatch.cpp: (JSC::webAssemblyOwner): (JSC::linkFor): (JSC::linkPolymorphicCall): (JSC::isWebAssemblyToJSCallee): Deleted. * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromWasmThunkGenerator): * llint/LLIntData.cpp: (JSC::LLInt::Data::performAssertions): * llint/LowLevelInterpreter.asm: * runtime/JSCell.cpp: (JSC::JSCell::isAnyWasmCallee): * runtime/JSCellInlines.h: (JSC::isWebAssemblyToJSCallee): * runtime/JSType.h: * runtime/StackFrame.cpp: (JSC::StackFrame::functionName): * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: (JSC::VM::wasmContextOffset): * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::materializeWasmContext): (JSC::Wasm::B3IRGenerator::restoreWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::getMemoryBaseAndSize): (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::loadWasmContext): Deleted. (JSC::Wasm::storeWasmContext): Deleted. (JSC::Wasm::restoreWebAssemblyGlobalState): Deleted. * wasm/WasmBinding.cpp: (JSC::Wasm::wasmToJs): * wasm/WasmContext.cpp: (JSC::loadWasmContext): (JSC::storeWasmContext): * wasm/WasmContext.h: * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::getPinnedRegisters): (JSC::Wasm::PinnedRegisterInfo::get): (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo): * wasm/WasmMemoryInformation.h: (JSC::Wasm::PinnedRegisterInfo::toSave): (JSC::Wasm::useFastTLS): (JSC::Wasm::useFastTLSForWasmContext): * wasm/js/JSWebAssemblyInstance.cpp: (JSC::JSWebAssemblyInstance::finishCreation): (JSC::JSWebAssemblyInstance::visitChildren): * wasm/js/JSWebAssemblyInstance.h: (JSC::JSWebAssemblyInstance::offsetOfCallee): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::finishCreation): (JSC::JSWebAssemblyModule::visitChildren): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::callee): * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): (JSC::WebAssemblyFunction::create): * wasm/js/WebAssemblyToJSCallee.cpp: (JSC::WebAssemblyToJSCallee::create): (JSC::WebAssemblyToJSCallee::createStructure): (JSC::WebAssemblyToJSCallee::finishCreation): (JSC::WebAssemblyToJSCallee::visitChildren): (JSC::WebAssemblyToJSCallee::destroy): Deleted. * wasm/js/WebAssemblyToJSCallee.h: 2017-03-28 Brian Burg <bburg@apple.com> Web Inspector: Add "Disable Caches" option that only applies to the inspected page while Web Inspector is open https://bugs.webkit.org/show_bug.cgi?id=169865 <rdar://problem/31250573> Reviewed by Joseph Pecoraro. * inspector/protocol/Network.json: Rename the command for disabling resource caching to match the WebCore::Page flag. This also removes the possibility that this could be confused for the old, buggy command that this patch rips out. 2017-03-25 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Move platformThreadSignal to WTF https://bugs.webkit.org/show_bug.cgi?id=170097 Reviewed by Mark Lam. It is a small clean up towards https://bugs.webkit.org/show_bug.cgi?id=170027. platformThreadSignal uses PlatformThread in JSC, but it can be implemented in WTF ThreadIdentifier. * runtime/JSLock.cpp: (JSC::JSLock::lock): * runtime/JSLock.h: (JSC::JSLock::ownerThread): (JSC::JSLock::currentThreadIsHoldingLock): * runtime/PlatformThread.h: (JSC::platformThreadSignal): Deleted. * runtime/VM.h: (JSC::VM::ownerThread): * runtime/VMTraps.cpp: (JSC::VMTraps::SignalSender::send): 2017-03-28 JF Bastien <jfbastien@apple.com> WebAssembly: implement Module imports/exports https://bugs.webkit.org/show_bug.cgi?id=166982 Reviewed by Saam Barati. As defined in: https://github.com/WebAssembly/design/commit/18cbacb90cd3584dd5c9aa3d392e4e55f66af6ab * wasm/WasmFormat.h: (JSC::Wasm::makeString): use uppercase instead, it was only used for diagnostic but is now used for the expected JS property's capitalization * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::webAssemblyModuleProtoImports): (JSC::webAssemblyModuleProtoExports): 2017-03-27 JF Bastien <jfbastien@apple.com> WebAssembly: JSWebAssemblyCodeBlock.h belongs in JavaScriptCore/wasm/js not JavaScriptCore/wasm https://bugs.webkit.org/show_bug.cgi?id=170160 Reviewed by Mark Lam. * JavaScriptCore.xcodeproj/project.pbxproj: * wasm/js/JSWebAssemblyCodeBlock.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssemblyCodeBlock.h. 2017-03-27 JF Bastien <jfbastien@apple.com> WebAssembly: misc memory testing https://bugs.webkit.org/show_bug.cgi?id=170137 Reviewed by Keith Miller. * wasm/js/WebAssemblyInstanceConstructor.cpp: (JSC::WebAssemblyInstanceConstructor::createInstance): improve error messages 2017-03-27 Michael Saboff <msaboff@apple.com> Add ARM64 system instructions to disassembler https://bugs.webkit.org/show_bug.cgi?id=170084 Reviewed by Saam Barati. This changes adds support for MRS and MSR instructions, and refactors the DMB disassembly to handle all of the barrier instructions. * disassembler/ARM64/A64DOpcode.cpp: (JSC::ARM64Disassembler::A64DOpcodeMSRImmediate::format): (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::format): (JSC::ARM64Disassembler::A64DOpcodeSystemSync::format): (JSC::ARM64Disassembler::A64DOpcodeDmb::format): Deleted. * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcodeSystem::lBit): (JSC::ARM64Disassembler::A64DOpcodeSystem::op0): (JSC::ARM64Disassembler::A64DOpcodeSystem::op1): (JSC::ARM64Disassembler::A64DOpcodeSystem::crN): (JSC::ARM64Disassembler::A64DOpcodeSystem::crM): (JSC::ARM64Disassembler::A64DOpcodeSystem::op2): (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::opName): (JSC::ARM64Disassembler::A64DOpcodeMSROrMRSRegister::systemRegister): (JSC::ARM64Disassembler::A64DOpcodeSystemSync::opName): (JSC::ARM64Disassembler::A64DOpcodeSystemSync::option): (JSC::ARM64Disassembler::A64DOpcodeDmb::opName): Deleted. (JSC::ARM64Disassembler::A64DOpcodeDmb::option): Deleted. (JSC::ARM64Disassembler::A64DOpcodeDmb::crM): Deleted. 2017-03-26 Filip Pizlo <fpizlo@apple.com> B3::fixSSA should do liveness pruning https://bugs.webkit.org/show_bug.cgi?id=170111 Reviewed by Saam Barati. This moves all of the logic of Air::Liveness<> to WTF::Liveness<> and then uses that to create B3::VariableLiveness. Then this uses VariableLiveness::LiveAtHead to prune Phi construction. This makes B3::fixSSA run twice as fast. This is a 13% progression on WasmBench compile times. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3BasicBlock.h: (JSC::B3::BasicBlock::get): * b3/B3FixSSA.cpp: (JSC::B3::fixSSA): * b3/B3VariableLiveness.cpp: Added. (JSC::B3::VariableLiveness::VariableLiveness): (JSC::B3::VariableLiveness::~VariableLiveness): * b3/B3VariableLiveness.h: Added. (JSC::B3::VariableLivenessAdapter::VariableLivenessAdapter): (JSC::B3::VariableLivenessAdapter::numIndices): (JSC::B3::VariableLivenessAdapter::valueToIndex): (JSC::B3::VariableLivenessAdapter::indexToValue): (JSC::B3::VariableLivenessAdapter::blockSize): (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): (JSC::B3::VariableLivenessAdapter::forEachLateUse): (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): (JSC::B3::VariableLivenessAdapter::forEachLateDef): * b3/air/AirCFG.h: Added. (JSC::B3::Air::CFG::CFG): (JSC::B3::Air::CFG::root): (JSC::B3::Air::CFG::newMap): (JSC::B3::Air::CFG::successors): (JSC::B3::Air::CFG::predecessors): (JSC::B3::Air::CFG::index): (JSC::B3::Air::CFG::node): (JSC::B3::Air::CFG::numNodes): (JSC::B3::Air::CFG::dump): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirCode.h: (JSC::B3::Air::Code::cfg): * b3/air/AirLiveness.h: (JSC::B3::Air::LivenessAdapter::LivenessAdapter): (JSC::B3::Air::LivenessAdapter::blockSize): (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): (JSC::B3::Air::LivenessAdapter::forEachLateUse): (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): (JSC::B3::Air::LivenessAdapter::forEachLateDef): (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): (JSC::B3::Air::TmpLivenessAdapter::numIndices): (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): (JSC::B3::Air::Liveness::Liveness): (JSC::B3::Air::Liveness::LocalCalc::LocalCalc): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::begin): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::end): Deleted. (JSC::B3::Air::Liveness::LocalCalc::Iterable::contains): Deleted. (JSC::B3::Air::Liveness::LocalCalc::live): Deleted. (JSC::B3::Air::Liveness::LocalCalc::isLive): Deleted. (JSC::B3::Air::Liveness::LocalCalc::execute): Deleted. (JSC::B3::Air::Liveness::rawLiveAtHead): Deleted. (JSC::B3::Air::Liveness::Iterable::Iterable): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::iterator): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator*): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator++): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator==): Deleted. (JSC::B3::Air::Liveness::Iterable::iterator::operator!=): Deleted. (JSC::B3::Air::Liveness::Iterable::begin): Deleted. (JSC::B3::Air::Liveness::Iterable::end): Deleted. (JSC::B3::Air::Liveness::Iterable::contains): Deleted. (JSC::B3::Air::Liveness::liveAtHead): Deleted. (JSC::B3::Air::Liveness::liveAtTail): Deleted. (JSC::B3::Air::Liveness::workset): Deleted. 2017-03-25 Filip Pizlo <fpizlo@apple.com> Air::Liveness shouldn't need HashSets https://bugs.webkit.org/show_bug.cgi?id=170102 Reviewed by Yusuke Suzuki. This converts Air::Liveness<> to no longer use HashSets or BitVectors. This turns out to be easy because it's cheap enough to do a sorted merge of the things being added to liveAtHead and the things in the predecessors' liveAtTail. This turns out to be faster - it's a 2% overall compile time progression on WasmBench. * b3/B3LowerToAir.cpp: (JSC::B3::Air::LowerToAir::lower): Add a FIXME unrelated to this patch. * b3/air/AirLiveness.h: (JSC::B3::Air::AbstractLiveness::AbstractLiveness): (JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc): (JSC::B3::Air::AbstractLiveness::rawLiveAtHead): (JSC::B3::Air::AbstractLiveness::liveAtHead): (JSC::B3::Air::AbstractLiveness::liveAtTail): * b3/air/AirTmp.h: (JSC::B3::Air::Tmp::bank): (JSC::B3::Air::Tmp::tmpIndex): * dfg/DFGStoreBarrierClusteringPhase.cpp: 2017-03-26 Filip Pizlo <fpizlo@apple.com> Air should use RegisterSet for RegLiveness https://bugs.webkit.org/show_bug.cgi?id=170108 Reviewed by Yusuke Suzuki. The biggest change here is the introduction of the new RegLiveness class. This is a drop-in replacement for the old RegLiveness, which was a specialization of AbstractLiveness<>, but it's about 30% faster. It gets its speed boost from just using sets everywhere, which is efficient for registers since RegisterSet is just two (on x86-64) or three 32-bit (on ARM64) statically allocated words. This looks like a 1% compile time progression on WasmBench. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/B3TimingScope.cpp: Records phase timing totals. (JSC::B3::TimingScope::TimingScope): (JSC::B3::TimingScope::~TimingScope): * b3/B3TimingScope.h: * b3/air/AirAllocateRegistersByGraphColoring.cpp: (JSC::B3::Air::allocateRegistersByGraphColoring): * b3/air/AirLiveness.h: Move code around and rename a bit to make it more like RegLiveness; in particular we want the `iterator` to be called `iterator` not `Iterator`, and we want it to be internal to its iterable. Also rename this template to Liveness, to match the header filename. (JSC::B3::Air::Liveness::Liveness): (JSC::B3::Air::Liveness::LocalCalc::LocalCalc): (JSC::B3::Air::Liveness::LocalCalc::Iterable::Iterable): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::iterator): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator++): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator*): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator==): (JSC::B3::Air::Liveness::LocalCalc::Iterable::iterator::operator!=): (JSC::B3::Air::Liveness::LocalCalc::Iterable::begin): (JSC::B3::Air::Liveness::LocalCalc::Iterable::end): (JSC::B3::Air::Liveness::Iterable::Iterable): (JSC::B3::Air::Liveness::Iterable::iterator::iterator): (JSC::B3::Air::RegLivenessAdapter::RegLivenessAdapter): Deleted. (JSC::B3::Air::RegLivenessAdapter::numIndices): Deleted. (JSC::B3::Air::RegLivenessAdapter::acceptsBank): Deleted. (JSC::B3::Air::RegLivenessAdapter::acceptsRole): Deleted. (JSC::B3::Air::RegLivenessAdapter::valueToIndex): Deleted. (JSC::B3::Air::RegLivenessAdapter::indexToValue): Deleted. (JSC::B3::Air::AbstractLiveness::AbstractLiveness): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::LocalCalc): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::Iterator): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator++): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator*): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator==): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterator::operator!=): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::Iterable): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::begin): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::end): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::Iterable::contains): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::live): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::isLive): Deleted. (JSC::B3::Air::AbstractLiveness::LocalCalc::execute): Deleted. (JSC::B3::Air::AbstractLiveness::rawLiveAtHead): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::Iterable): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::iterator): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator*): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator++): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator==): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::iterator::operator!=): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::begin): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::end): Deleted. (JSC::B3::Air::AbstractLiveness::Iterable::contains): Deleted. (JSC::B3::Air::AbstractLiveness::liveAtHead): Deleted. (JSC::B3::Air::AbstractLiveness::liveAtTail): Deleted. (JSC::B3::Air::AbstractLiveness::workset): Deleted. * b3/air/AirLogRegisterPressure.cpp: * b3/air/AirLowerAfterRegAlloc.cpp: * b3/air/AirRegLiveness.cpp: Added. (JSC::B3::Air::RegLiveness::RegLiveness): (JSC::B3::Air::RegLiveness::~RegLiveness): (JSC::B3::Air::RegLiveness::LocalCalc::execute): * b3/air/AirRegLiveness.h: Added. (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc): (JSC::B3::Air::RegLiveness::LocalCalc::live): (JSC::B3::Air::RegLiveness::LocalCalc::isLive): (JSC::B3::Air::RegLiveness::liveAtHead): (JSC::B3::Air::RegLiveness::liveAtTail): * b3/air/AirReportUsedRegisters.cpp: * jit/RegisterSet.h: (JSC::RegisterSet::add): (JSC::RegisterSet::remove): (JSC::RegisterSet::contains): (JSC::RegisterSet::subsumes): (JSC::RegisterSet::iterator::iterator): (JSC::RegisterSet::iterator::operator*): (JSC::RegisterSet::iterator::operator++): (JSC::RegisterSet::iterator::operator==): (JSC::RegisterSet::iterator::operator!=): (JSC::RegisterSet::begin): (JSC::RegisterSet::end): 2017-03-25 Filip Pizlo <fpizlo@apple.com> Fix wasm by returning after we do TLS. Rubber stamped by Keith Miller. * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::storeWasmContext): 2017-03-24 Mark Lam <mark.lam@apple.com> Add some instrumentation in Heap::resumeThePeriphery() to help debug an issue. https://bugs.webkit.org/show_bug.cgi?id=170086 <rdar://problem/31253673> Reviewed by Saam Barati. Adding some instrumentation in Heap::resumeThePeriphery() to dump some Heap state just before we RELEASE_ASSERT_NOT_REACHED. * heap/Heap.cpp: (JSC::Heap::resumeThePeriphery): 2017-03-24 JF Bastien <jfbastien@apple.com> WebAssembly: store state in TLS instead of on VM https://bugs.webkit.org/show_bug.cgi?id=169611 Reviewed by Filip Pizlo. Using thread-local storage instead of VM makes code more position independent. We used to store the WebAssembly top Instance (the latest one in the call stack) on VM, now we instead store it in TLS. This top Instance is used to access a bunch of state such as Memory location, size, table (for call_indirect), etc. Instead of calling it "top", which is confusing, we now just call it WasmContext. Making the code PIC means future patches will be able to postMessage and structured clone into IDB without having to recompile the code. This wasn't possible before because we hard-coded the address of VM at compilation time. That doesn't work between workers, and doesn't work across reloads (which IDB is intended to do). It'll also potentially make code faster once we start tuning what's in TLS, what's in which of the 4 free slots, and what's in pinned registers. I'm leaving this tuning for later because there's lower lying fruit for us to pick. * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * assembler/AbstractMacroAssembler.h: * assembler/AllowMacroScratchRegisterUsageIf.h: Copied from assembler/AllowMacroScratchRegisterUsage.h. (JSC::AllowMacroScratchRegisterUsageIf::AllowMacroScratchRegisterUsageIf): (JSC::AllowMacroScratchRegisterUsageIf::~AllowMacroScratchRegisterUsageIf): * assembler/MacroAssembler.h: (JSC::MacroAssembler::storeToTLSPtr): we previously didn't have the code required to store to TLS, only to load * assembler/MacroAssemblerARM64.h: (JSC::MacroAssemblerARM64::loadFromTLSPtrNeedsMacroScratchRegister): (JSC::MacroAssemblerARM64::storeToTLS32): (JSC::MacroAssemblerARM64::storeToTLS64): (JSC::MacroAssemblerARM64::storeToTLSPtrNeedsMacroScratchRegister): * assembler/MacroAssemblerX86Common.h: (JSC::MacroAssemblerX86Common::loadFromTLSPtrNeedsMacroScratchRegister): (JSC::MacroAssemblerX86Common::storeToTLS32): (JSC::MacroAssemblerX86Common::storeToTLSPtrNeedsMacroScratchRegister): * assembler/MacroAssemblerX86_64.h: (JSC::MacroAssemblerX86_64::loadFromTLS64): was loading 32-bit instead of 64-bit (JSC::MacroAssemblerX86_64::storeToTLS64): * assembler/X86Assembler.h: (JSC::X86Assembler::movl_rm): (JSC::X86Assembler::movq_rm): * b3/testb3.cpp: (JSC::B3::testFastTLSLoad): (JSC::B3::testFastTLSStore): (JSC::B3::run): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::loadWasmContext): (JSC::AssemblyHelpers::storeWasmContext): (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister): (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister): * jit/Repatch.cpp: (JSC::webAssemblyOwner): * jit/ThunkGenerators.cpp: (JSC::throwExceptionFromWasmThunkGenerator): * runtime/Options.h: * runtime/VM.cpp: (JSC::VM::VM): * runtime/VM.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::loadWasmContext): (JSC::Wasm::storeWasmContext): (JSC::Wasm::B3IRGenerator::B3IRGenerator): (JSC::Wasm::getMemoryBaseAndSize): (JSC::Wasm::restoreWebAssemblyGlobalState): (JSC::Wasm::createJSToWasmWrapper): (JSC::Wasm::parseAndCompile): * wasm/WasmBinding.cpp: (JSC::Wasm::materializeImportJSCell): (JSC::Wasm::wasmToJs): (JSC::Wasm::wasmToWasm): * wasm/WasmContext.cpp: Added. (JSC::loadWasmContext): (JSC::storeWasmContext): * wasm/WasmContext.h: Added. Replaces "top" JSWebAssemblyInstance. * wasm/js/WebAssemblyFunction.cpp: (JSC::callWebAssemblyFunction): * wasm/js/WebAssemblyInstanceConstructor.h: 2017-03-24 JF Bastien <jfbastien@apple.com> WebAssembly: spec-tests/memory.wast.js fails in debug https://bugs.webkit.org/show_bug.cgi?id=169794 Reviewed by Keith Miller. The failure was due to empty memories (with maximum size 0). Those only occur in tests and in code that's trying to trip us. This patch adds memory mode "none" which represents no memory. It can work with either bounds checked or signaling code because it never contains loads and stores. The spec tests which were failing did the following: > (module (memory (data)) (func (export "memsize") (result i32) (current_memory))) > (assert_return (invoke "memsize") (i32.const 0)) > (module (memory (data "")) (func (export "memsize") (result i32) (current_memory))) > (assert_return (invoke "memsize") (i32.const 0)) > (module (memory (data "x")) (func (export "memsize") (result i32) (current_memory))) > (assert_return (invoke "memsize") (i32.const 1)) * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::memoryKind): * wasm/WasmMemory.cpp: (JSC::Wasm::tryGetFastMemory): (JSC::Wasm::releaseFastMemory): (JSC::Wasm::Memory::Memory): (JSC::Wasm::Memory::createImpl): (JSC::Wasm::Memory::create): (JSC::Wasm::Memory::grow): (JSC::Wasm::Memory::makeString): * wasm/WasmMemory.h: * wasm/WasmMemoryInformation.cpp: (JSC::Wasm::MemoryInformation::MemoryInformation): * wasm/js/JSWebAssemblyCodeBlock.cpp: (JSC::JSWebAssemblyCodeBlock::isSafeToRun): * wasm/js/JSWebAssemblyModule.cpp: (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::finishCreation): * wasm/js/JSWebAssemblyModule.h: (JSC::JSWebAssemblyModule::codeBlock): (JSC::JSWebAssemblyModule::codeBlockFor): 2017-03-24 Mark Lam <mark.lam@apple.com> Array memcpy'ing fast paths should check if we're having a bad time if they cannot handle it. https://bugs.webkit.org/show_bug.cgi?id=170064 <rdar://problem/31246098> Reviewed by Geoffrey Garen. * runtime/ArrayPrototype.cpp: (JSC::arrayProtoPrivateFuncConcatMemcpy): * runtime/JSArray.cpp: (JSC::JSArray::fastSlice): 2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use jsNontrivialString agressively for ToString(Int52) https://bugs.webkit.org/show_bug.cgi?id=170002 Reviewed by Sam Weinig. We use the same logic used for Int32 to use jsNontvirialString. After single character check, produced string is always longer than 1. Thus, we can use jsNontrivialString. * runtime/NumberPrototype.cpp: (JSC::int52ToString): 2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com> [JSC] Use WeakRandom for SamplingProfiler interval fluctuation https://bugs.webkit.org/show_bug.cgi?id=170045 Reviewed by Mark Lam. It is unnecessary to use cryptographicallyRandomNumber for SamplingProfiler interval fluctuation. Use WeakRandom instead. * runtime/SamplingProfiler.cpp: (JSC::SamplingProfiler::SamplingProfiler): (JSC::SamplingProfiler::timerLoop): * runtime/SamplingProfiler.h: 2017-03-23 Mark Lam <mark.lam@apple.com> Array.prototype.splice behaves incorrectly when the VM is "having a bad time". https://bugs.webkit.org/show_bug.cgi?id=170025 <rdar://problem/31228679> Reviewed by Saam Barati. * runtime/ArrayPrototype.cpp: (JSC::copySplicedArrayElements): (JSC::arrayProtoFuncSplice): 2017-03-23 Yusuke Suzuki <utatane.tea@gmail.com> [JSC][DFG] Make addShouldSpeculateAnyInt more conservative to avoid regression caused by Double <-> Int52 conversions https://bugs.webkit.org/show_bug.cgi?id=169998 Reviewed by Saam Barati. Double <-> Int52 and JSValue <-> Int52 conversions are not so cheap. Thus, Int52Rep is super carefully emitted. We make addShouldSpeculateAnyInt more conservative to avoid regressions caused by the above conversions. We select ArithAdd(Int52, Int52) only when this calculation is beneficial compared to added Int52Rep conversions. This patch tighten the conditions of addShouldSpeculateAnyInt. 1. Honor DoubleConstant. When executing imaging-darkroom, we have a thing like that, 132:< 2:loc36> DoubleConstant(Double|UseAsOther, AnyIntAsDouble, Double: 4607182418800017408, 1.000000, bc#114) 1320:< 1:loc38> Int52Rep(Check:Int32:@82, Int52|PureInt, Int32, Exits, bc#114) 1321:< 1:loc39> Int52Constant(Int52|PureInt, Boolint32Nonboolint32Int52, Double: 4607182418800017408, 1.000000, bc#114) 133:<!3:loc39> ArithSub(Int52Rep:@1320<Int52>, Int52Rep:@1321<Int52>, Int52|MustGen, Int52, CheckOverflow, Exits, bc#114) The LHS of ArithSub says predicting Boolint32, and the rhs says AnyIntAsDouble. Thus we select ArithSub(Int52, Int52) instead of ArithSub(Double, Double). However, it soon causes OSR exits. In imaging-darkroom, LHS's Int32 prediction will be broken. While speculating Int32 in the above situation is reasonable approach since the given LHS says predicting Int32, this causes severe performance regression. Previously, we always select ArithSub(Double, Double). So accidentally, we do not encounter this misprediction issue. One thing can be found that we have DoubleConstant in the RHS. It means that we have `1.0` instead of `1` in the code. We can see the code like `lhs - 1.0` instead of `lhs - 1` in imaging-darkroom. It offers good information that lhs and the resulting value would be double. Handling the above ArithSub in double seems more appropriate rather than handling it in Int52. So, in this patch, we honor DoubleConstant. If we find DoubleConstant on one operand, we give up selecting Arith[Sub,Add](Int52, Int52). This change removes OSR exits occurr in imaging-darkroom right now. 2. Two Int52Rep(Double) conversions are not desirable. We allow AnyInt ArithAdd only when the one operand of the binary operation should be speculated AnyInt. It is a bit conservative decision. This is because Double to Int52 conversion is not so cheap. Frequent back-and-forth conversions between Double and Int52 rather hurt the performance. If the one operand of the operation is already Int52, the cost for constructing ArithAdd becomes cheap since only one Double to Int52 conversion could be required. This recovers some regression in assorted tests while keeping kraken crypto improvements. 3. Avoid frequent Int52 to JSValue conversions. Int52 to JSValue conversion is not so cheap. Thus, we would like to avoid such situations. So, in this patch, we allow Arith(Int52, Int52) with AnyIntAsDouble operand only when the node is used as number. By doing so, we avoid the case like, converting Int52, performing ArithAdd, and soon converting back to JSValue. The above 3 changes recover the regression measured in microbenchmarks/int52-back-and-forth.js and assorted benchmarks. And still it keeps kraken crypto improvements. baseline patched imaging-darkroom 201.112+-3.192 ^ 189.532+-2.883 ^ definitely 1.0611x faster stanford-crypto-pbkdf2 103.953+-2.325 100.926+-2.396 might be 1.0300x faster stanford-crypto-sha256-iterative 35.103+-1.071 ? 36.049+-1.143 ? might be 1.0270x slower * dfg/DFGGraph.h: (JSC::DFG::Graph::addShouldSpeculateAnyInt): == Rolled over to ChangeLog-2017-03-23 ==