| 2019-06-12 Yusuke Suzuki <ysuzuki@apple.com> |
| |
| [JSC] Polymorphic call stub's slow path should restore callee saves before performing tail call |
| https://bugs.webkit.org/show_bug.cgi?id=198770 |
| |
| Reviewed by Saam Barati. |
| |
| Polymorphic call stub is a bit specially patched in JS call site. Typical JS call site for tail calls |
| are the following. |
| |
| if (callee == patchableCallee) { |
| restore callee saves for tail call |
| prepare for tail call |
| jump to the target function |
| } |
| restore callee saves for slow path |
| call the slow path function |
| |
| And linking patches patchableCallee, target function, and slow path function. But polymorphic call stub |
| patches the above `if` statement with the jump to the stub. |
| |
| jump to the polymorphic call stub |
| |
| This is because polymorphic call stub wants to use CallFrameShuffler to get scratch registers. As a result, |
| "restore callee saves for tail call" thing needs to be done in the polymorphic call stubs. While it is |
| correctly done for the major cases, we have `slowPath` skips, and that path missed restoring callee saves. |
| This skip happens if the callee is non JSCell or non JS function, so typically, InternalFunction is handled |
| in that path. |
| |
| This patch does that skips after restoring callee saves. |
| |
| * bytecode/CallLinkInfo.cpp: |
| (JSC::CallLinkInfo::CallLinkInfo): |
| * bytecode/CallLinkInfo.h: |
| (JSC::CallLinkInfo::setUpCall): |
| (JSC::CallLinkInfo::calleeGPR): |
| (JSC::CallLinkInfo::setCalleeGPR): Deleted. |
| * jit/Repatch.cpp: |
| (JSC::revertCall): |
| (JSC::linkVirtualFor): |
| (JSC::linkPolymorphicCall): |
| * jit/Repatch.h: |
| * jit/ThunkGenerators.cpp: |
| (JSC::virtualThunkFor): |
| |
| 2019-06-12 Commit Queue <commit-queue@webkit.org> |
| |
| Unreviewed, rolling out r246322. |
| https://bugs.webkit.org/show_bug.cgi?id=198796 |
| |
| "It's a huge page load regression on iOS" (Requested by |
| saamyjoon on #webkit). |
| |
| Reverted changeset: |
| |
| "Roll out PAC cage" |
| https://bugs.webkit.org/show_bug.cgi?id=198726 |
| https://trac.webkit.org/changeset/246322 |
| |
| 2019-06-11 Alexey Shvayka <shvaikalesh@gmail.com> |
| |
| JSC should throw if proxy set returns falsish in strict mode context |
| https://bugs.webkit.org/show_bug.cgi?id=177398 |
| |
| Reviewed by Yusuke Suzuki. |
| |
| Throw TypeError exception if Proxy's `set` trap returns falsy value. |
| (step 6.c of https://tc39.es/ecma262/#sec-putvalue) |
| |
| * runtime/ProxyObject.cpp: |
| (JSC::ProxyObject::performPut): |
| (JSC::ProxyObject::put): |
| (JSC::ProxyObject::putByIndexCommon): |
| * runtime/ProxyObject.h: |
| |
| 2019-06-11 Alexey Shvayka <shvaikalesh@gmail.com> |
| |
| Error message for non-callable Proxy `construct` trap is misleading |
| https://bugs.webkit.org/show_bug.cgi?id=198637 |
| |
| Reviewed by Saam Barati. |
| |
| Just like other traps, Proxy `construct` trap is invoked with [[Call]], not [[Construct]]. |
| |
| * runtime/ProxyObject.cpp: |
| (JSC::performProxyConstruct): Tweak error message. |
| |
| 2019-06-10 Tadeu Zagallo <tzagallo@apple.com> |
| |
| AI BitURShift's result should not be unsigned |
| https://bugs.webkit.org/show_bug.cgi?id=198689 |
| <rdar://problem/51550063> |
| |
| Reviewed by Saam Barati. |
| |
| Treating BitURShift's result as unsigned in the abstract interpreter incorrectly overflows it. |
| This breaks the DFG and FTL, since they assume that BitURShift's result is an int32 value, but |
| get a double constant from AI. Since the result will be converted to unsigned by UInt32ToNumber, |
| all we have to do is store the result as a signed int32. |
| |
| * dfg/DFGAbstractInterpreterInlines.h: |
| |
| 2019-06-11 Michael Catanzaro <mcatanzaro@igalia.com> |
| |
| Unreviewed build warning fixes |
| |
| Silence -Wreturn-type warning |
| |
| * wasm/WasmTable.cpp: |
| (JSC::Wasm::Table::tryCreate): |
| |
| 2019-06-11 Saam Barati <sbarati@apple.com> |
| |
| Roll out PAC cage |
| https://bugs.webkit.org/show_bug.cgi?id=198726 |
| |
| Reviewed by Keith Miller. |
| |
| This patch rolls out: r245064, r245145, r245168, r245313, r245432, r245622. |
| |
| The resulting state we're in is we have Gigacage enabled on arm64. |
| There is no more PAC caging. |
| |
| We're doing this because there are performance issues with PAC caging |
| that we haven't resolved yet. |
| |
| * assembler/CPU.h: |
| (JSC::isARM64E): Deleted. |
| * assembler/MacroAssemblerARM64E.h: |
| (JSC::MacroAssemblerARM64E::tagArrayPtr): Deleted. |
| (JSC::MacroAssemblerARM64E::untagArrayPtr): Deleted. |
| (JSC::MacroAssemblerARM64E::removeArrayPtrTag): Deleted. |
| * b3/B3LowerToAir.cpp: |
| * b3/B3PatchpointSpecial.cpp: |
| (JSC::B3::PatchpointSpecial::admitsStack): |
| * b3/B3StackmapSpecial.cpp: |
| (JSC::B3::StackmapSpecial::forEachArgImpl): |
| (JSC::B3::StackmapSpecial::isArgValidForRep): |
| * b3/B3Validate.cpp: |
| * b3/B3ValueRep.cpp: |
| (JSC::B3::ValueRep::addUsedRegistersTo const): |
| (JSC::B3::ValueRep::dump const): |
| (WTF::printInternal): |
| * b3/B3ValueRep.h: |
| (JSC::B3::ValueRep::ValueRep): |
| (JSC::B3::ValueRep::isReg const): |
| * dfg/DFGOperations.cpp: |
| (JSC::DFG::newTypedArrayWithSize): |
| * dfg/DFGSpeculativeJIT.cpp: |
| (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): |
| (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): |
| (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage): |
| (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): |
| (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): |
| * dfg/DFGSpeculativeJIT.h: |
| * dfg/DFGSpeculativeJIT64.cpp: |
| (JSC::DFG::SpeculativeJIT::compile): |
| * ftl/FTLLowerDFGToB3.cpp: |
| (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage): |
| (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset): |
| (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): |
| (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet): |
| (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet): |
| (JSC::FTL::DFG::LowerDFGToB3::caged): |
| (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): |
| (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr): Deleted. |
| (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag): Deleted. |
| * heap/ConservativeRoots.cpp: |
| (JSC::ConservativeRoots::genericAddPointer): |
| * jit/AssemblyHelpers.h: |
| (JSC::AssemblyHelpers::cageConditionally): |
| * jit/IntrinsicEmitter.cpp: |
| (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter): |
| * jit/JITPropertyAccess.cpp: |
| (JSC::JIT::emitDirectArgumentsGetByVal): |
| (JSC::JIT::emitIntTypedArrayGetByVal): |
| (JSC::JIT::emitFloatTypedArrayGetByVal): |
| (JSC::JIT::emitIntTypedArrayPutByVal): |
| (JSC::JIT::emitFloatTypedArrayPutByVal): |
| * jit/PolymorphicCallStubRoutine.cpp: |
| (JSC::PolymorphicCallNode::clearCallLinkInfo): |
| * jit/RegisterSet.h: |
| * llint/LowLevelInterpreter64.asm: |
| * runtime/ArrayBuffer.cpp: |
| (JSC::SharedArrayBufferContents::SharedArrayBufferContents): |
| (JSC::SharedArrayBufferContents::~SharedArrayBufferContents): |
| (JSC::ArrayBufferContents::ArrayBufferContents): |
| (JSC::ArrayBufferContents::destroy): |
| (JSC::ArrayBufferContents::tryAllocate): |
| (JSC::ArrayBufferContents::makeShared): |
| (JSC::ArrayBufferContents::copyTo): |
| * runtime/ArrayBuffer.h: |
| (JSC::SharedArrayBufferContents::data const): |
| (JSC::ArrayBufferContents::data const): |
| (JSC::ArrayBuffer::data): |
| (JSC::ArrayBuffer::data const): |
| (JSC::ArrayBuffer::byteLength const): |
| * runtime/ArrayBufferView.cpp: |
| (JSC::ArrayBufferView::ArrayBufferView): |
| * runtime/ArrayBufferView.h: |
| (JSC::ArrayBufferView::baseAddress const): |
| (JSC::ArrayBufferView::setRangeImpl): |
| (JSC::ArrayBufferView::getRangeImpl): |
| (JSC::ArrayBufferView::byteLength const): Deleted. |
| * runtime/CachedTypes.cpp: |
| (JSC::CachedScopedArgumentsTable::encode): |
| (JSC::CachedScopedArgumentsTable::decode const): |
| * runtime/CagedBarrierPtr.h: |
| (JSC::CagedBarrierPtr::CagedBarrierPtr): |
| (JSC::CagedBarrierPtr::set): |
| (JSC::CagedBarrierPtr::get const): |
| (JSC::CagedBarrierPtr::getMayBeNull const): |
| (JSC::CagedBarrierPtr::operator== const): |
| (JSC::CagedBarrierPtr::operator!= const): |
| (JSC::CagedBarrierPtr::operator bool const): |
| (JSC::CagedBarrierPtr::setWithoutBarrier): |
| (JSC::CagedBarrierPtr::operator* const): |
| (JSC::CagedBarrierPtr::operator-> const): |
| (JSC::CagedBarrierPtr::operator[] const): |
| (JSC::CagedBarrierPtr::getUnsafe const): Deleted. |
| (JSC::CagedBarrierPtr::at const): Deleted. |
| * runtime/DataView.cpp: |
| (JSC::DataView::DataView): |
| * runtime/DataView.h: |
| (JSC::DataView::get): |
| (JSC::DataView::set): |
| * runtime/DirectArguments.cpp: |
| (JSC::DirectArguments::visitChildren): |
| (JSC::DirectArguments::overrideThings): |
| (JSC::DirectArguments::unmapArgument): |
| * runtime/DirectArguments.h: |
| * runtime/GenericArguments.h: |
| * runtime/GenericArgumentsInlines.h: |
| (JSC::GenericArguments<Type>::visitChildren): |
| (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor): |
| (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor): |
| (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor): |
| * runtime/GenericTypedArrayView.h: |
| * runtime/GenericTypedArrayViewInlines.h: |
| (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView): |
| * runtime/JSArrayBufferView.cpp: |
| (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext): |
| (JSC::JSArrayBufferView::JSArrayBufferView): |
| (JSC::JSArrayBufferView::finalize): |
| (JSC::JSArrayBufferView::slowDownAndWasteMemory): |
| * runtime/JSArrayBufferView.h: |
| (JSC::JSArrayBufferView::ConstructionContext::vector const): |
| (JSC::JSArrayBufferView::isNeutered): |
| (JSC::JSArrayBufferView::vector const): |
| (JSC::JSArrayBufferView::hasVector const): Deleted. |
| * runtime/JSGenericTypedArrayViewInlines.h: |
| (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized): |
| (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize): |
| (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): |
| * runtime/Options.h: |
| * runtime/ScopedArgumentsTable.cpp: |
| (JSC::ScopedArgumentsTable::clone): |
| (JSC::ScopedArgumentsTable::setLength): |
| * runtime/ScopedArgumentsTable.h: |
| * runtime/SymbolTable.h: |
| * wasm/WasmAirIRGenerator.cpp: |
| (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState): |
| (JSC::Wasm::AirIRGenerator::addCallIndirect): |
| * wasm/WasmB3IRGenerator.cpp: |
| (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): |
| (JSC::Wasm::B3IRGenerator::addCallIndirect): |
| * wasm/WasmBBQPlan.cpp: |
| (JSC::Wasm::BBQPlan::complete): |
| * wasm/WasmBinding.cpp: |
| (JSC::Wasm::wasmToWasm): |
| * wasm/WasmInstance.h: |
| (JSC::Wasm::Instance::cachedMemory const): |
| (JSC::Wasm::Instance::updateCachedMemory): |
| * wasm/WasmMemory.cpp: |
| (JSC::Wasm::Memory::Memory): |
| (JSC::Wasm::Memory::~Memory): |
| (JSC::Wasm::Memory::grow): |
| (JSC::Wasm::Memory::dump const): |
| * wasm/WasmMemory.h: |
| (JSC::Wasm::Memory::memory const): |
| * wasm/js/JSToWasm.cpp: |
| (JSC::Wasm::createJSToWasmWrapper): |
| * wasm/js/WebAssemblyFunction.cpp: |
| (JSC::WebAssemblyFunction::jsCallEntrypointSlow): |
| |
| 2019-06-10 Basuke Suzuki <Basuke.Suzuki@sony.com> |
| |
| [WinCairo] Remove build warning from RemoteInspector. |
| https://bugs.webkit.org/show_bug.cgi?id=198724 |
| |
| Reviewed by Joseph Pecoraro. |
| |
| In `RemoteInspectorConnectionClient.h`, an interface was defined with empty implementation. |
| This method is to be overwritten by sub classes so that parameter name is important |
| so they are commented out rather than just removing from the definition. |
| |
| * inspector/remote/RemoteInspector.h: |
| |
| 2019-06-10 Sam Weinig <weinig@apple.com> |
| |
| Remove Dashboard support |
| https://bugs.webkit.org/show_bug.cgi?id=198615 |
| |
| Reviewed by Ryosuke Niwa. |
| |
| * Configurations/FeatureDefines.xcconfig: |
| |
| 2019-06-10 Devin Rousso <drousso@apple.com> |
| |
| Web Automation: add notifications for when remote automation is enabled/disabled |
| https://bugs.webkit.org/show_bug.cgi?id=198703 |
| <rdar://problem/50588975> |
| |
| Reviewed by Timothy Hatcher. |
| |
| * inspector/remote/RemoteInspectorConstants.h: |
| |
| 2019-06-10 Yusuke Suzuki <ysuzuki@apple.com> |
| |
| Unreviewed, build fix for non-DFG configurations, part 2 |
| https://bugs.webkit.org/show_bug.cgi?id=198023 |
| |
| * bytecode/CodeBlock.cpp: |
| (JSC::CodeBlock::finalizeUnconditionally): |
| |
| 2019-06-10 Yusuke Suzuki <ysuzuki@apple.com> |
| |
| Unreviewed, build fix for non-DFG configurations |
| https://bugs.webkit.org/show_bug.cgi?id=198023 |
| |
| * bytecode/CodeBlock.cpp: |
| (JSC::CodeBlock::finalizeUnconditionally): |
| |
| 2019-06-10 Yusuke Suzuki <ysuzuki@apple.com> |
| |
| [JSC] UnlinkedCodeBlock should be eventually jettisoned in VM mini mode |
| https://bugs.webkit.org/show_bug.cgi?id=198023 |
| |
| Reviewed by Saam Barati. |
| |
| While CodeBlock is periodically jettisoned, UnlinkedCodeBlock and UnlinkedFunctionExecutable can be retained almost forever in certain type of applications. |
| When we execute a program, which has UnlinkedProgramCodeBlock retained in CodeCache. And UnlinkedProgramCodeBlock holds array of UnlinkedFunctionExecutable. |
| And UnlinkedFunctionExecutables hold UnlinkedFunctionCodeBlocks once it is generated. So eventually, this tree gets larger and larger until we purge |
| UnlinkedProgramCodeBlock from CodeCache. This is OK in the browser case. We navigate to various other pages, and UnlinkedProgramCodeBlocks should eventually |
| be pruned from CodeCache with the new ones. So this tree won't be retained forever. But the behavior is different in the other applications that do not have |
| navigations. If they only have one program which holds all, we basically retain this tree during executing this application. The same thing can happen in |
| web applications which does not have navigation and keeps alive for a long time. Once we hit CodeCache limit by periodically executing a new script, we will |
| hit the uppermost of memory footprint. But until that, we increase our memory footprint. |
| |
| However, destroying these UnlinkedCodeBlocks and UnlinkedFunctionExecutables causes a tricky problem. In the browser environment, navigation can happen at any |
| time. So even if the given UnlinkedCodeBlock seems unused in the current page, it can be used when navigating to a new page which is under the same domain. |
| One example is initializing function in a script. It is only executed once per page. So once it is executed, it seems that this UnlinkedCodeBlock is unused. |
| But this will be used when we navigate to a new page. Pruning code blocks based on usage could cause performance regression. |
| |
| But if our VM is mini VM mode, the story is different. In mini VM mode, we focus on memory footprint rather than performance e.g. daemons. The daemon never |
| reuse these CodeCache since we do not have the navigation. |
| |
| This patch logically makes UnlinkedFunctionExecutable -> UnlinkedCodeBlock reference weak when VM is mini mode. If UnlinkedCodeBlock is used in previous GC |
| cycle, we retain it. But if it is not used, and if UnlinkedFunctionExecutable is only the cell keeping UnlinkedCodeBlock alive, we destroy it. It is a |
| heuristic. In a super pathological case, it could increase memory footprint. Consider the following example. |
| |
| UnlinkedFunctionExecutable(A1) -> UnlinkedCodeBlock(B1) -> UnlinkedFunctionExecutable(C1) -> UnlinkedCodeBlock(D1) |
| ^ |
| CodeBlock(E1) |
| |
| We could delete A1, B1, and C1 while keeping D1. But if we eventually re-execute the same code corresponding to A1, B1, C1, they will be newly created, and |
| we will create duplicate UnlinkedCodeBlock and instructions stream for D1. |
| |
| UnlinkedCodeBlock(D1) |
| ^ |
| CodeBlock(E1) |
| |
| UnlinkedFunctionExecutable(A2) -> UnlinkedCodeBlock(B2) -> UnlinkedFunctionExecutable(C2) -> UnlinkedCodeBlock(D2) |
| |
| But this does not happen in practice and even it happens, we eventually discard D1 and D2 since CodeBlock E1 will be jettisoned anyway. So in practice, we do |
| not see memory footprint increase. We tested it in Gmail and the target application, but both said memory footprint reduction (30 MB / 400 MB and 1 MB /6 MB). |
| While this affects on performance much on tests which has navigation (1-3 % regression in Speedometer2, note that JetStream2 does not show regression in x64, |
| while it is not enabling mini mode), we do not apply this to non mini mode VM until we come up with a good strategy to fasten performance of re-generation. |
| Personally I think flushing destroyed UnlinkedCodeBlock to the disk sounds promising. |
| |
| If UnlinkedCodeBlock is generated from bytecode cache, we do not make UnlinkedFunctionExecutable -> UnlinkedCodeBlock link weak because the decoder of the bytecode |
| cache assumes that generated JSCells won't be destroyed while the parent cells of that cell are live. This is true in the current implementation, and this assumption |
| will be broken with this patch. So, for now, we do not make this link weak. Currently, our target application does not use bytecode cache so it is OK. |
| |
| This patch also introduce simple heuristic. We are counting UnlinkedCodeBlock's age. And once the age becomes maximum size, we make UnlinkedFunctionExecutable -> |
| UnlinkedCodeBlock link weak. We also use execution counter information to reset this age: CodeBlock will reset undelying UnlinkedCodeBlock's age if it has executed |
| While this heuristic is quite simple, it has some effect in practice. Basically what happens with this heuristic is that UnlinkedFunctionExecutable -> |
| UnlinkedCodeBlock link strong. When GC happens, we are executing some CodeBlocks, which become live. And ScriptExecutables -> UnlinkedFunctionExecutables held |
| by this CodeBlock become also live. Then UnlinkedFunctionExecutables can mark the child UnlinkedCodeBlocks if it is not so old. |
| If some of parent UnlinkedFunctionExecutable becomes dead, child UnlinkedCodeBlocks tends to be dead unless some live CodeBlock holds it. But it is OK for a first |
| heuristics since this means that parent code block is now considered old, reachable UnlinkedCodeBlock will be used when the parent is executed again. So destroying |
| the tree is OK even if the tree may include some new UnlinkedCodeBlock. While we could make more sophisticated mechanism to manage these lifetime, I think this is a |
| good starting point. |
| |
| Based on measurement, we pick 7 as a maximum age. If we pick 0, we can get more memory reduction (1 - 1.5 MB!), while we ends up reparsing codes so many times. |
| It seems that 7 can reduce fair amount of memory while doing small # of reparsing on average (usually, 1, 2. Sometimes, 100. But not 300, which is the case in 0). |
| If we want to get more memory reduction for the sake of performance, we could decrease this age limit. |
| |
| Since we do not have an automated script right now so it is a bit difficult to measure memory footprint precisely. But manual testing shows that this patch improves |
| memory footprint of our target application from about 6.5 MB to about 5.9 MB. |
| |
| * bytecode/CodeBlock.cpp: |
| (JSC::CodeBlock::finalizeUnconditionally): |
| * bytecode/CodeBlock.h: |
| * bytecode/UnlinkedCodeBlock.cpp: |
| (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): |
| (JSC::UnlinkedCodeBlock::visitChildren): |
| * bytecode/UnlinkedCodeBlock.h: |
| (JSC::UnlinkedCodeBlock::age const): |
| (JSC::UnlinkedCodeBlock::resetAge): |
| * bytecode/UnlinkedFunctionExecutable.cpp: |
| (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): |
| (JSC::UnlinkedFunctionExecutable::visitChildren): |
| (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor): |
| (JSC::UnlinkedFunctionExecutable::decodeCachedCodeBlocks): |
| (JSC::UnlinkedFunctionExecutable::finalizeUnconditionally): |
| * bytecode/UnlinkedFunctionExecutable.h: |
| * heap/Heap.cpp: |
| (JSC::Heap::finalizeUnconditionalFinalizers): |
| * runtime/CachedTypes.cpp: |
| (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): |
| (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable): |
| * runtime/CodeSpecializationKind.h: |
| * runtime/Options.h: |
| * runtime/VM.cpp: |
| (JSC::VM::isInMiniMode): Deleted. |
| * runtime/VM.h: |
| (JSC::VM::isInMiniMode): |
| (JSC::VM::useUnlinkedCodeBlockJettisoning): |
| |
| 2019-06-10 Timothy Hatcher <timothy@apple.com> |
| |
| Integrate dark mode support for iOS. |
| https://bugs.webkit.org/show_bug.cgi?id=198687 |
| rdar://problem/51545643 |
| |
| Reviewed by Tim Horton. |
| |
| * Configurations/FeatureDefines.xcconfig: |
| |
| 2019-06-10 Adrian Perez de Castro <aperez@igalia.com> |
| |
| [JSC] Linker fails when unified sources are not in use |
| https://bugs.webkit.org/show_bug.cgi?id=198722 |
| |
| Reviewed by Keith Miller. |
| |
| Added missing inclusions of headers in several files which make use of inline functions. |
| |
| * b3/B3AtomicValue.cpp: |
| * b3/B3BlockInsertionSet.cpp: |
| * b3/B3FenceValue.cpp: |
| * b3/B3LowerMacrosAfterOptimizations.cpp: |
| * b3/B3PureCSE.cpp: |
| * b3/B3StackmapValue.cpp: |
| * b3/B3SwitchValue.cpp: |
| * b3/B3UseCounts.cpp: |
| * b3/B3VariableValue.cpp: |
| * b3/B3WasmAddressValue.cpp: |
| * b3/B3WasmBoundsCheckValue.cpp: |
| * ftl/FTLCompile.cpp: |
| * wasm/WasmSectionParser.cpp: |
| * wasm/WasmTable.cpp: |
| * wasm/WasmValidate.cpp: |
| |
| 2019-06-10 Keith Miller <keith_miller@apple.com> |
| |
| Make new Symbol/Promise API public |
| https://bugs.webkit.org/show_bug.cgi?id=198709 |
| |
| Reviewed by Saam Barati. |
| |
| We also need to #ifdef some tests when building for older |
| platforms because the signatures for some methods are outdated on |
| those platforms. |
| |
| * API/JSObjectRef.h: |
| * API/JSObjectRefPrivate.h: |
| * API/JSValue.h: |
| * API/JSValuePrivate.h: |
| * API/JSValueRef.h: |
| * API/tests/testapi.mm: |
| (testObjectiveCAPIMain): |
| |
| 2019-06-09 Commit Queue <commit-queue@webkit.org> |
| |
| Unreviewed, rolling out r246150, r246160, and r246166. |
| https://bugs.webkit.org/show_bug.cgi?id=198698 |
| |
| Regresses page loading time on iOS 13 (Requested by keith_m__ |
| on #webkit). |
| |
| Reverted changesets: |
| |
| "Reenable Gigacage on ARM64." |
| https://bugs.webkit.org/show_bug.cgi?id=198453 |
| https://trac.webkit.org/changeset/246150 |
| |
| "Unrevied build fix for FTL without Gigacage." |
| https://trac.webkit.org/changeset/246160 |
| |
| "Fix typo in cageWithoutUntagging" |
| https://bugs.webkit.org/show_bug.cgi?id=198617 |
| https://trac.webkit.org/changeset/246166 |
| |
| 2019-06-09 Yusuke Suzuki <ysuzuki@apple.com> |
| |
| [JSC] Use mergePrediction in ValuePow prediction propagation |
| https://bugs.webkit.org/show_bug.cgi?id=198648 |
| |
| Reviewed by Saam Barati. |
| |
| We are accidentally using setPrediction. This is wrong since prediction propagation (not processInvariant) |
| must extend the speculation types to ensure we eventually reach to the fixed point. setPrediction can discard |
| previously configured predictions, can lead to oscillation potentially. Use mergePrediction instead. |
| |
| * dfg/DFGPredictionPropagationPhase.cpp: |
| |
| 2019-06-07 Tadeu Zagallo <tzagallo@apple.com> |
| |
| AI should get GetterSetter structure from the base's GlobalObject for GetGetterSetterByOffset |
| https://bugs.webkit.org/show_bug.cgi?id=198581 |
| <rdar://problem/51099753> |
| |
| Reviewed by Saam Barati. |
| |
| For GetGetterSetterByOffset, when the abstract interpreter fails to read the property |
| from the object, it gets the GetterSetter structure from the CodeBlock's global object. |
| However, that's not correct, since the global object for the base object might differ |
| from the CodeBlock's. Instead, we try to get the global object from the base, when it's |
| a constant object. Otherwise, we can't infer the value and only set the type. |
| |
| * dfg/DFGAbstractInterpreterInlines.h: |
| (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): |
| |
| 2019-06-06 Devin Rousso <drousso@apple.com> |
| |
| Web Inspector: create CommandLineAPIHost lazily like the other agents |
| https://bugs.webkit.org/show_bug.cgi?id=196047 |
| <rdar://problem/49087835> |
| |
| Reviewed by Timothy Hatcher. |
| |
| * inspector/InjectedScriptManager.h: |
| * inspector/InjectedScriptManager.cpp: |
| (Inspector::InjectedScriptManager::connect): Added. |
| |
| 2019-06-06 Keith Miller <keith_miller@apple.com> |
| |
| Fix typo in cageWithoutUntagging |
| https://bugs.webkit.org/show_bug.cgi?id=198617 |
| |
| Reviewed by Saam Barati. |
| |
| * assembler/testmasm.cpp: |
| (JSC::testCagePreservesPACFailureBit): |
| * dfg/DFGSpeculativeJIT.cpp: |
| (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): |
| (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): |
| * jit/AssemblyHelpers.h: |
| (JSC::AssemblyHelpers::cageWithoutUntagging): |
| (JSC::AssemblyHelpers::cageConditionally): |
| (JSC::AssemblyHelpers::cageWithoutUntaging): Deleted. |
| |
| 2019-06-06 Alexey Shvayka <shvaikalesh@gmail.com> |
| |
| JSON.parse throws incorrect exception when called w/o arguments |
| https://bugs.webkit.org/show_bug.cgi?id=198574 |
| |
| Reviewed by Yusuke Suzuki. |
| |
| Always coerce first argument to string and attempt to parse it. |
| (steps 1-2 of https://tc39.github.io/ecma262/#sec-json.parse) |
| |
| * runtime/JSONObject.cpp: |
| (JSC::JSONProtoFuncParse): Remove argumentCount check. |
| |
| 2019-06-06 Keith Miller <keith_miller@apple.com> |
| |
| Unrevied build fix for FTL without Gigacage. |
| |
| * ftl/FTLLowerDFGToB3.cpp: |
| (JSC::FTL::DFG::LowerDFGToB3::caged): |
| |
| 2019-06-06 Michael Catanzaro <mcatanzaro@igalia.com> |
| |
| aarch64: ‘JSC::ARM64Assembler::LinkRecord::<unnamed union>::RealTypes::m_compareRegister’ is too small to hold all values of ‘JSC::ARM64Assembler::RegisterID’ {aka ‘enum JSC::ARM64Registers::RegisterID’} |
| https://bugs.webkit.org/show_bug.cgi?id=198014 |
| |
| Reviewed by Yusuke Suzuki. |
| |
| When building for aarch64, there is a huge warning spam here. It's impossible to see any |
| other warnings. This has been ongoing for so long I've begun to suspect that nobody works |
| on this architecture. |
| |
| Anyway, the problem is because we need eight bits to store all possible RegisterID values, |
| but the bitfield is only six bits wide. Fix it. The COMPILE_ASSERT checking the size of this |
| struct is still happy, so I presume the change is OK. |
| |
| * assembler/ARM64Assembler.h: |
| |
| 2019-06-06 Keith Miller <keith_miller@apple.com> |
| |
| Reenable Gigacage on ARM64. |
| https://bugs.webkit.org/show_bug.cgi?id=198453 |
| |
| Reviewed by Michael Saboff. |
| |
| This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the |
| old Gigacage however, arm64e uses both Gigacaging and PAC. In |
| order to ensure the PAC bits are not stripped in the caging |
| process we use the bit field insert instruction to take the low |
| bits from caging and the high bits from the PAC authentication. |
| |
| * assembler/MacroAssemblerARM64.h: |
| (JSC::MacroAssemblerARM64::bitFieldInsert64): |
| * assembler/MacroAssemblerARM64E.h: |
| * assembler/testmasm.cpp: |
| (JSC::testCagePreservesPACFailureBit): |
| (JSC::run): |
| * dfg/DFGSpeculativeJIT.cpp: |
| (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): |
| (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage): |
| (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset): |
| (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize): |
| * ftl/FTLLowerDFGToB3.cpp: |
| (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray): |
| (JSC::FTL::DFG::LowerDFGToB3::caged): |
| * jit/AssemblyHelpers.h: |
| (JSC::AssemblyHelpers::cageWithoutUntaging): |
| (JSC::AssemblyHelpers::cageConditionally): |
| (JSC::AssemblyHelpers::cage): Deleted. |
| * jit/JITPropertyAccess.cpp: |
| (JSC::JIT::emitIntTypedArrayGetByVal): |
| (JSC::JIT::emitFloatTypedArrayGetByVal): |
| (JSC::JIT::emitIntTypedArrayPutByVal): |
| (JSC::JIT::emitFloatTypedArrayPutByVal): |
| * llint/LowLevelInterpreter.asm: |
| * llint/LowLevelInterpreter64.asm: |
| * offlineasm/arm64.rb: |
| * offlineasm/instructions.rb: |
| * offlineasm/registers.rb: |
| * wasm/WasmAirIRGenerator.cpp: |
| (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState): |
| (JSC::Wasm::AirIRGenerator::addCallIndirect): |
| * wasm/WasmB3IRGenerator.cpp: |
| (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState): |
| (JSC::Wasm::B3IRGenerator::addCallIndirect): |
| * wasm/WasmBinding.cpp: |
| (JSC::Wasm::wasmToWasm): |
| * wasm/js/JSToWasm.cpp: |
| (JSC::Wasm::createJSToWasmWrapper): |
| * wasm/js/WebAssemblyFunction.cpp: |
| (JSC::WebAssemblyFunction::jsCallEntrypointSlow): |
| |
| 2019-06-06 Michael Saboff <msaboff@apple.com> |
| |
| [ARM64E]: Add disassembler support for authenticated instructions |
| https://bugs.webkit.org/show_bug.cgi?id=198562 |
| |
| Reviewed by Keith Miller. |
| |
| Added support for all the instructions supported in ARM64EAssembler.h. |
| |
| * disassembler/ARM64/A64DOpcode.cpp: |
| (JSC::ARM64Disassembler::A64DOpcodeDataProcessing1Source::format): |
| (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::format): |
| (JSC::ARM64Disassembler::A64DOpcodeHint::format): |
| (JSC::ARM64Disassembler::A64DOpcodeHint::opName): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::format): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpName): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::format): |
| * disassembler/ARM64/A64DOpcode.h: |
| (JSC::ARM64Disassembler::A64DOpcodeDataProcessing2Source::opNameIndex): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opName): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::opNum): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::mBit): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::sBit): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::wBit): |
| (JSC::ARM64Disassembler::A64DOpcodeLoadStoreAuthenticated::immediate10): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::authOpCode): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op2): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op3): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::op4): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::mBit): |
| (JSC::ARM64Disassembler::A64DOpcodeUnconditionalBranchRegister::rm): |
| (JSC::ARM64Disassembler::A64DOpcodeHint::opName): Deleted. |
| |
| 2019-06-05 Justin Michaud <justin_michaud@apple.com> |
| |
| [WASM-References] Add support for Anyref tables, Table.get and Table.set (for Anyref only). |
| https://bugs.webkit.org/show_bug.cgi?id=198398 |
| |
| Reviewed by Saam Barati. |
| |
| Create a new table subtype called FuncRefTable (note: Anyfunc was renamed to Funcref in the references spec). |
| Table now write-barriers and visits its children's wrapper objects. FuncRefTable caches some extra data to |
| support calling from wasm. A JSWebAssemblyTable is required to set an anyref element, but this is only because |
| we need to write barrier it (so it should not restrict how we implement threads). This patch does, however, |
| restrict the implementation of function references to require every Ref.func to have an associated wrapper. This |
| can be done statically, so this too should not restrict our threads implementation. |
| |
| * wasm/WasmAirIRGenerator.cpp: |
| (JSC::Wasm::AirIRGenerator::addTableGet): |
| (JSC::Wasm::AirIRGenerator::addTableSet): |
| (JSC::Wasm::AirIRGenerator::addCallIndirect): |
| * wasm/WasmB3IRGenerator.cpp: |
| (JSC::Wasm::B3IRGenerator::addLocal): |
| (JSC::Wasm::B3IRGenerator::addTableGet): |
| (JSC::Wasm::B3IRGenerator::addTableSet): |
| (JSC::Wasm::B3IRGenerator::addCallIndirect): |
| * wasm/WasmFormat.h: |
| (JSC::Wasm::TableInformation::TableInformation): |
| (JSC::Wasm::TableInformation::type const): |
| * wasm/WasmFunctionParser.h: |
| (JSC::Wasm::FunctionParser<Context>::parseExpression): |
| (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression): |
| * wasm/WasmSectionParser.cpp: |
| (JSC::Wasm::SectionParser::parseTableHelper): |
| * wasm/WasmTable.cpp: |
| (JSC::Wasm::Table::Table): |
| (JSC::Wasm::Table::tryCreate): |
| (JSC::Wasm::Table::grow): |
| (JSC::Wasm::Table::clear): |
| (JSC::Wasm::Table::set): |
| (JSC::Wasm::Table::get): |
| (JSC::Wasm::Table::visitChildren): |
| (JSC::Wasm::FuncRefTable::FuncRefTable): |
| (JSC::Wasm::FuncRefTable::setFunction): |
| (JSC::Wasm::Table::~Table): Deleted. |
| (JSC::Wasm::Table::clearFunction): Deleted. |
| (JSC::Wasm::Table::setFunction): Deleted. |
| * wasm/WasmTable.h: |
| (JSC::Wasm::Table::length const): |
| (JSC::Wasm::Table::type const): |
| (JSC::Wasm::Table::setOwner): |
| (JSC::Wasm::FuncRefTable::offsetOfFunctions): |
| (JSC::Wasm::FuncRefTable::offsetOfInstances): |
| (JSC::Wasm::Table::offsetOfFunctions): Deleted. |
| (JSC::Wasm::Table::offsetOfInstances): Deleted. |
| * wasm/WasmValidate.cpp: |
| (JSC::Wasm::Validate::addTableGet): |
| (JSC::Wasm::Validate::addTableSet): |
| (JSC::Wasm::Validate::addCallIndirect): |
| * wasm/js/JSWebAssemblyTable.cpp: |
| (JSC::JSWebAssemblyTable::JSWebAssemblyTable): |
| (JSC::JSWebAssemblyTable::finishCreation): |
| (JSC::JSWebAssemblyTable::visitChildren): |
| (JSC::JSWebAssemblyTable::grow): |
| (JSC::JSWebAssemblyTable::get): |
| (JSC::JSWebAssemblyTable::set): |
| (JSC::JSWebAssemblyTable::clear): |
| (JSC::JSWebAssemblyTable::getFunction): Deleted. |
| (JSC::JSWebAssemblyTable::clearFunction): Deleted. |
| (JSC::JSWebAssemblyTable::setFunction): Deleted. |
| * wasm/js/JSWebAssemblyTable.h: |
| * wasm/js/WebAssemblyModuleRecord.cpp: |
| (JSC::WebAssemblyModuleRecord::link): |
| (JSC::WebAssemblyModuleRecord::evaluate): |
| * wasm/js/WebAssemblyTableConstructor.cpp: |
| (JSC::constructJSWebAssemblyTable): |
| * wasm/js/WebAssemblyTablePrototype.cpp: |
| (JSC::webAssemblyTableProtoFuncGet): |
| (JSC::webAssemblyTableProtoFuncSet): |
| * wasm/wasm.json: |
| |
| 2019-06-05 Justin Michaud <justin_michaud@apple.com> |
| |
| WebAssembly: pow functions returns 0 when exponent 1.0 or -1.0 |
| https://bugs.webkit.org/show_bug.cgi?id=198106 |
| |
| Reviewed by Saam Barati. |
| |
| Fix bug caused by using fcsel sX instead of fcsel dX on an f64 value in moveDoubleConditionally32. |
| |
| * assembler/MacroAssemblerARM64.h: |
| (JSC::MacroAssemblerARM64::moveDoubleConditionally32): |
| |
| 2019-06-05 Alex Christensen <achristensen@webkit.org> |
| |
| Progress towards resurrecting Mac CMake build |
| https://bugs.webkit.org/show_bug.cgi?id=197132 |
| |
| Reviewed by Don Olmstead. |
| |
| * API/JSScript.mm: |
| (-[JSScript readCache]): |
| (-[JSScript sourceCode]): |
| (-[JSScript jsSourceCode]): |
| (-[JSScript writeCache:]): |
| * CMakeLists.txt: |
| |
| == Rolled over to ChangeLog-2019-06-05 == |
